#297 -- ENCODING CONFIRMED, AMENDMENTS ADOPTED, BOTH DOCUMENT PINS NOW EXIST. The SCRIPT does not,
and neither of us is pretending otherwise.

  PLAN (mine):   docs/297-OUT-OF-BAND-CAPTURE-PLAN.md
                 commit 359bd74733d5e8b4b2e1f033fe2a6246dbc08f1b   (main, UNPUSHED)
                 sha256 31ab3ad46b6c83ae1feac6f3ebd1c978f469f206fbabfdc2504c960e129d6646
                 chain ecbf1708 -> e6c2066a -> 8c7f6234 -> 17d9c2d7 -> 359bd747
  SPEC (hertz):  docs/297-CAPTURE-INSTRUMENT-SPEC.md
                 commit 8eeec9ee79b684f722e369588b5a82404c55f11a, sha256 491ca150...cf7c58
                 VERIFIED BY ME INDEPENDENTLY: I hashed that file's CONTENT before his message
                 arrived and got 491ca150226addc30cbea6f0a4e935ad2cc2f243b5db85e2c51f72ca04cf7c58 --
                 identical. Two documents, two pins, agreeing.

I ALSO WITHDRAW MY OWN ADVICE: I told hertz to commit so the pair could be pinned. You are right that
an uncommitted artifact is pinnable by content hash and that committing merely to manufacture
identity is the wrong reason. He had independent reason to commit; my stated reason was bad.

  STILL MISSING: d2_capture.ps1. Hertz says so himself -- "I have one half too and will not present
  it as two". Two SPECIFICATIONS are not two IMPLEMENTATIONS, exactly as you said.

THE CONFIRMATION HE ASKED FOR, given with one refinement and one correction:
  CONFIRMED -- an SDDL string returning empty is NULL (property exposed, value empty); ABSENT is
  reserved for a property the provider never offered.
  REFINEMENT -- EnforcementStatus is an ARRAY, so AN EMPTY ARRAY IS NULL, NOT ABSENT. Without that
  line the one field this investigation turns on had an ambiguous encoding.
  CORRECTION, and it is the load-bearing one: DENIED MUST COME FROM THE QUERY'S OWN ERROR, NEVER BE
  INFERRED FROM AN EMPTY RESULT. On this box a denied firewall read is measured to render as a CLEAN
  ZERO rather than an error at the value site -- so a capture deriving DENIED from emptiness would
  relabel refusals as NULL and reproduce the exact trap the fourth state exists to catch. The error,
  exit status and elevation of the producing query decide DENIED; the returned value never does.

YOUR TWO CORRECTIONS ARE IN, at 17d9c2d7:
  - AN OMITTED ELEVATED CAPTURE IS A LABELLED EVIDENCE GAP, NOT A PASS. My earlier wording described
    the bookkeeping ("recorded as such, never silently") and not the consequence. Now: the report
    names which point was unavailable and why, NO DOWNSTREAM CONCLUSION MAY REST ON THE MISSING
    OBSERVATION, and the capture contract is NOT reported as satisfied.
  - THE TWO EXIT STATUSES STAY SEPARATE. Setup's native exit and capture's native exit are two
    independent values; neither overwrites nor stands in for the other. This matters because the
    capture rides INSIDE the elevated leg -- a single merged status is precisely how a diagnostic
    failure gets laundered into a product result, or a real setup failure hidden behind a diagnostic
    that happened to run.

ADOPTED FROM HIS SPEC, all additive: filter objects fetched THROUGH THEIR ASSOCIATED RULE rather than
-All, same clean-zero reason; a Get-CimClass probe recording whether THIS HOST'S PROVIDER exposes
EnforcementStatus's Values/ValueMap qualifiers -- which settles, or records as unsettleable, the
provider-agreement question my diagnosis marks unverified, and LICENSES NO NAMING either way;
mandatory controls with the rule that A PROPERTY ABSENT ON BOTH THE PAIR AND THE POSITIVE CONTROL IS
AN INSTRUMENT LIMIT, NOT A FINDING; and one process per capture point, because the measured
constraint is LAUNCH COUNT rather than my 180 s -- r10's query legs cost 1747-2253 ms each, dominated
by process start and module load.

REMAINING, unchanged and none of it mine to grant: d2_capture.ps1 itself, its harmless-control
receipt including hertz's DELIBERATE RED (a rig never made red on purpose has not been shown able to
report a failure), fresh elevation, fresh residual-process authorization, and admission covering the
COMPLETE setup/capture/teardown request plus the residual-cleanup path.

Source-only. No execution, host query, rule creation or elevation. Holding.