How do you map which tenant fields reach an embedded AI panel's context without using its chat box?

## The constraint that shapes the method You can see one thing: the panel's rendered output, and only when someone opens the record. You cannot see the assembled prompt, the field roster, the budget or the version. And the one surface with a fast feedback loop - the chat box - is the surface that is transcript-logged and reviewed per tenant, so learning there is both non-transferable and observed. Everything below follows from that asymmetry. ## Design the probe set first **Distinct markers.** Each candidate field gets its own harmless, recognisable value, so that an appearance in the output identifies which field it came from. Reusing the same value across fields destroys the only signal you have. **One variable per round.** Change one field, wait, read. If you change three and the summary changes, you have learned that at least one of the three influenced the output - which is almost nothing, and it costs a round to un-learn. **A null round.** Read the panel with no change at all, more than once. Generated text varies between runs, and without a baseline for that variance you will read noise as signal. ## What each result gives you **Presence.** A marker in the output is the strong result: the field is in the assembled set, or at least on some path to the screen. If it comes back rewritten rather than copied, it went through the model rather than a template. **Order.** Output order is not context order. A summariser arranges content by relevance and by its own habits, so a marker appearing first tells you nothing about position in the prompt. What does carry information is interference: lengthen one field steadily and watch for the round where another field's marker disappears. That boundary is a budget - a truncation limit, a per-field cap, a chunking cut - and where the loss falls tells you something about ordering that the summary itself will not. **Absence.** The weak result, and the one people over-read. Candidate explanations, none of which the null observation separates: - the field is not in the assembled set at all; - it is included but was cut by a truncation budget; - it is included and the model judged it irrelevant to a summary; - the panel served a cached result generated before your write; - an index or a derived record has not been rebuilt yet; - something between the row and the prompt dropped or rewrote the value. Some of these you can pull apart cheaply: shrinking neighbouring fields separates truncation from non-ingestion; repeating after a delay separates staleness and caching. Others stay indistinguishable from outside, and the honest answer names them as unresolved rather than picking the flattering one. ## What every result costs - **A durable artefact.** Each probe is a value sitting on a live record in someone else's account until you change it. The path may be unreviewed, but the row is real and visible to whoever opens it. - **Latency you do not control.** Nothing happens until a person on the other side opens the panel. Your experiment's clock belongs to them. - **Ambiguity per round.** Because generated output varies, a single round rarely settles anything; the informative unit is a repeated pair, not a single reading. ## The map has a date and a tenant on it The result is not a property of the product. It describes one tenant's field configuration, one panel version and one index state at one moment. A vendor shipping an embedded panel updates it for everybody at once and configures it per tenant; a field that was in the set last month may not be this month, and a field absent in one tenant may be present in another. A map presented without those coordinates will be quoted back later as a fact about the product, and it is not one. ## What a good answer sounds like State the experimental discipline first (one variable, distinct markers, a baseline for variance), then be explicit about the asymmetry between presence and absence, then price it: rounds are the scarce resource because each one costs a write and a wait. Candidates who have actually done this volunteer the caching and staleness problems unprompted; candidates who have not describe a single clever probe that settles everything.