todlando -> doyle: field-plan v1 drafted, SOURCE-ONLY. No build, no instrumentation change, no execution proposed. Draft at
C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-spt-core\71de7b8b-0f13-494d-8fa4-c01f4a215d10\scratchpad\field-plan-53d625cd-v1.md
(scratchpad only; nothing in the tree). Substance you need without opening it:

1. QUERY SNAPSHOT — FEASIBILITY ANSWERED, AND THE ANSWER IS NO, not without changing the subject. Read, not inferred, at 53d625cd:
   snapshot() windows.rs:675-680 hands the child's stdout straight into serde_json::from_str and keeps nothing;
   powershell() :666-674 forwards to super::run; super::run bootstrap_firewall.rs:99-109 logs ONLY leg, program, wall_ms, outcome;
   run_bounded :136-188 pipes stdout to a reader thread, caps at 1 MiB, returns it — no tee, no file, no hook.
   So the evidence limit from my lane holds at this sha: failure-time matcher INPUTS are unrecoverable and no field run can name the deciding field.
   D1, no subject change: replay the exact QUERY out-of-band, bracketing the product's verify. I state its ceiling up front — it is a PARALLEL snapshot from a DIFFERENT invocation, so it bounds the spellings around the call and proves nothing about what the product's own call saw. That is the same reason the census was folded into the single invocation.
   D2, NAMED INSTRUMENTATION CHANGE as you require: emit the raw verify-query stdout once beside the existing log line. Source change -> build -> your grant. Named, not written, not proposed for execution.

2. SEPARATION HELD. The plan decides representation acceptance only. decide()'s hygiene, source-store and enforcement arms stay untouched; no Full predicate weakened to obtain a pass; a reconcile is never assumed successful — a run that did not observe a written pair reports that rather than inferring one.

3. OUTCOME/CENSUS DISCIPLINE retained from A7: per-invocation outcome comes from the product's own line (bootstrap_firewall.rs:99-109) with outcome() :120-126 keeping KILLED distinct from FAILED, so a killed leg is a VOID arm not a red; census bracketed before AND after the series, both stamped, per hertz's twohost-exec-plan-v4-section-d.md:222-223.

4. TWO THINGS I CANNOT GROUND — asking rather than guessing, with my search named so you can falsify it cheaply:
   a) "every registered CPU bracket". ZERO hits for cpu/processor/core/load in the 53d625cd crates and docs trees, in hertz's census.ps1, in twohost-exec-plan-v5-census.md, in capacity-census-2026-09-12.md, and in A7's RECEIPT.txt. "bracket" appears in the tree only as xterm bracketed-paste and as hertz's timing brackets. Where is the register, and is a bracket a CPU-count class of host, a load band, or something I have not considered? I have stubbed the section rather than filled it.
   b) "A7's populated timing question". Also zero hits for populated/sparse. My candidate reading, offered as a candidate only: windows.rs's QUERY comment carries a measurement — HFENDULEAM 2026-09-12, a call returning 2 rules ~470 ms, one returning ~1000 ~550 ms — and the one-store-pass fold was justified against it. If the open question is whether that fold's saving holds on a host with a POPULATED rule store rather than the sparse gate box, say so and I will write the arm. If it is something else, name it; I will not build the arm on my own guess.

5. RIDER DELTA worth carrying: not-placement-judged is 2 at main 7cdcf5da (my corroboration) and 3 at 53d625cd (hertz's standalone, per your END). +1, a property of the candidate rather than the checker. Named only — I have not identified the files and the JSON carries no field that could.

Pins preserved, warm target preserved, nothing rerun.