#297 -- FIELD CONTRACT SETTLED, ALL SIX CORRECTIONS IN, t1 ADOPTED. One half of the pair is pinned;
the other is written but UNCOMMITTED, so I am not presenting two pins I do not have.

  MY PIN:  docs/297-OUT-OF-BAND-CAPTURE-PLAN.md
           commit 8c7f62342503fce9846da7f5611d7a8805ed7903   (main, UNPUSHED)
           sha256 bff5a9fb2edff31451c3bac48551006a823b4908c4e4da256b91bb69354dc172
           chain: ecbf1708 (predecessor) -> e6c2066a (six corrections) -> 8c7f6234 (t1)
           traceable-reqs exit 0.

  HERTZ'S HALF: docs/297-CAPTURE-INSTRUMENT-SPEC.md EXISTS ON DISK, 17120 bytes, and is UNTRACKED --
           it has no commit and therefore no pin. I did not commit it; it is his file in a shared
           checkout and committing another agent's work under my trailer would misattribute it.
           HERTZ: commit it and send doyle the pin, and the pair is complete.

THE SIX CORRECTIONS ARE ALL IN, and two of them correct ME rather than the document:
  1. No single "currently active profile" -- per-interface categories and per-profile states are
     recorded separately, for ALL interfaces, never collapsed into one host value.
  2. Creation is the setup command's START/END INTERVAL, not an instant; a provider timestamp is
     recorded additionally and labelled as the provider's. InstanceID is NOT assumed unique across
     deletion and recreation and is never the binding key -- records bind to run + measured pre-setup
     absence + store + name + setup interval.
  3. The 180 s cleanup bound is a REPORTING DEADLINE. If fresh pid-naming authorization is needed:
     stop activity, preserve identities, report CLEANUP PENDING. THE RUN IS NOT CLEAN AT 480 s.
  4. My "no projection change could supply LocalUser" OVERSTATED it -- a projection could join
     associated-filter data; we are CHOOSING out-of-band capture, not declaring production collection
     impossible. Corrected in place.
  5. My checkpoint claim that absent/empty is the EXPECTED PersistentStore value was WRONG. The
     documentation qualifying EnforcementStatus to an ActiveStore retrieval does not predict a value.
     Preserve whatever PersistentStore returns and assign it NO enforcement meaning.
     TracePolicyStoreSource is used where the docs require it and WHETHER IT WAS USED IS RECORDED.
  6. Three separate grants, all SPENT: r10 setup and teardown were NONCE-bound, residual cleanup was
     PID-specific. Fresh elevation and fresh residual-process authorization are SEPARATE prerequisites.

t1 ADOPTED, and I put it in the PLAN rather than the rig because it is a property of the REQUEST:
the elevated capture is the only elevated read available, and ONE NONCE IS ONE EXECUTION -- it cannot
be added after the handoff is answered without a second handoff and a second nonce. So THE SEQ-001
SETUP REQUEST MUST NAME THE ELEVATED CAPTURE AND ITS OUTPUT PATH in the same request that creates the
pair; if it does not, that capture point DOES NOT EXIST for the run and the run proceeds with the
unelevated points only, recorded as such rather than silently. One line, no extra nonce. Hertz's
recommendation, adopted verbatim in effect.

WORTH YOUR ATTENTION IN HERTZ'S SPEC, because it names the real reason r10 could not discriminate:
D1 is rendered from the PRODUCT'S OWN QUERY const, so it projects exactly the eight fields the
product projects and no others. THE RIG INHERITED THE BLIND SPOT OF THE THING IT WAS STUDYING. That
is why the answer is a second, differently-sourced instrument rather than an edit to the first -- and
it is a sharper statement of the gap than the one I sent you.

NO BLOCKER ON THE CONTRACT. The remaining gates are the ones already named: fresh elevation, fresh
residual-process authorization, and admission of plan, rig and cleanup path. Source-only; no build,
host query, rule creation, elevation or execution. Holding.