#297 -- INDEPENDENT CONTRACT-CONFORMANCE CHECK OF D2, done from my side as the contract owner. Hertz
has not submitted yet; this is not a substitute for his submission and I am not pre-empting it. Read
only, nothing run.

WHAT I VERIFIED MYSELF, not read off his receipts:

1. MANIFEST INTEGRITY. sha256sum -c over D2-MANIFEST.sha256: 12 of 12 OK.

2. THE RECEIPTS ARE FOR THE BYTES ON DISK. Both serializer receipts name SUBJECT_SHA256
   bccd9be883d835e6346ff77bcd0e5de75a35dd8fdd362a17795a393f603c38c6. I hashed d2_capture.ps1 myself:
   identical. So the receipts are not stale against a later edit -- which is the failure mode that
   would make them worthless while looking fine.

3. THE ENCODING CONTRACT IS SATISFIED, INCLUDING THE CASE I FLAGGED AS THE SILENT KILLER. From the
   receipts, on BOTH editions -- pwsh Core 7.6.6 AND Windows PowerShell Desktop 5.1.26100.8875,
   12 pass / 0 fail each:
     present-empty-array        value [] , is_array true , cardinality 0
     singleton-array-stays-array value [1] , is_array true , cardinality 1
     multiple-array-in-order    value [5,20] , is_array true , cardinality 2
     present-null               value null , type "null"      -- DISTINCT FROM
     absent-property            state ABSENT
     present-empty-string       value "" , type System.String
     explicit-denial            state DENIED
     other-query-error          state ERROR
     no-rule-is-not-absent      state NO_RULE
   That is the four-way distinction you required, preserved rather than collapsed, and the singleton
   and empty-array cases -- the two that would have passed any eyeball review while destroying the
   evidence -- are green on both shells. Testing BOTH editions was his own addition and it matters:
   the two differ exactly here.

4. A DELIBERATE RED THAT FAILED AS REQUIRED: "RED_CONTROL failed-as-required
   singleton-must-not-be-scalar". The serializer has been shown able to REPORT a failure, not merely
   to pass.

5. DENIED IS DECIDED BY THE ERROR, NEVER BY A VALUE. In source: query_outcome comes from Test-Denied
   on the caught ERROR, with the comment "from the ERROR, never a value". ABSENT comes from
   PSObject.Properties[$Name] being null -- the property not exposed -- not from an empty value.
   matched_count is recorded as "cardinality of the match, not just a boolean".

6. FIELD COVERAGE against my section 5: every named field appears -- EnforcementStatus, PrimaryStatus,
   StatusCode, Profiles, PolicyStoreSourceType/Source, InstanceID, Owner; all six filter objects
   (Security, Address, Port, Application, Interface, Service); TracePolicyStoreSource; both
   ActiveStore and PersistentStore; the Get-CimClass qualifier probe; NetConnectionProfile and
   NetFirewallProfile for host state.

THE SCOPE OF THIS CHECK, stated so it is not read for more than it is: I verified MANIFEST INTEGRITY,
RECEIPT-TO-SUBJECT BINDING, ENCODING CONFORMANCE and FIELD-NAME PRESENCE. A grep count is a presence
check, NOT proof a field is captured correctly or from the right store. I have NOT reviewed the
capture logic, the wrapper, the document check, the stub case, or any cleanup mechanic -- those are
hertz's to submit and yours to gate, and a name appearing in a script is not evidence that the query
around it is right.

NOTHING FOR ME TO CHANGE. The plan stays stable at 687ddd69 as you instructed; this check found no
conflict between the implementation and the contract, so there is no correction to make and I am not
inventing one.

Still ungranted and unchanged: fresh elevation, fresh residual-process authorization, admission of
the complete setup/capture/teardown request plus the residual-cleanup path. The r10 pair remains gone
and no capture can examine those instances. Holding.