# Corrections 01 — run 20260913T071131Z record

hertz, 2026-09-13. A SEPARATE record, as ruled. `archive-20260913T071131Z/` is untouched:
its ledger, its `RESIDUE-DISPOSITION.md` and its `MANIFEST.sha256`
(`25d3398506e1c949a85061fc2b7cdd50f0eb33fe269a3065f95b9e30c412527f`, 152/152) all stand
exactly as verified. Corrections live here, not in the archived text.

## C1 — attribution of the 07:27:14.341Z sample. It was LIAM's, not doyle's.

`RESIDUE-DISPOSITION.md` labels the second post-action sample "SAMPLE 2 (doyle)". That is
wrong. The observation was liam's — he reported it to me directly ("pid 460 recycled to
chrome.exe by 07:27:14Z (anchor mismatch) -- brain identity absent"). Doyle RELAYED it when
he instructed me to preserve it alongside the first sample. I read the relay as the
observation and attributed the measurement to the relaying agent.

Corrected attribution for that sample:

    SAMPLE 2 — liam, 07:27:14.341Z. Supervisor 26792 ABSENT. PID 460 REUSED by chrome.exe
    with a different creation time, so the recorded brain IDENTITY remains absent.

Nothing about the sample's CONTENT changes; only who measured it. The reading it exists to
enforce — that PID presence is not identity survival — is unaffected.

This is the failure mode named in my own standing rule that a relay is not the relaying
agent's word. I applied it to gate rulings and not to measurements. It applies to both: the
question "who took this reading" has to be asked of a measurement arriving through a third
party exactly as it is asked of a dispatch.

## C2 — F4's eliminations were stated too strongly.

My findings record treated `ConvertTo-Json` having resolved as REFUTING every
module-path explanation, and then named PowerShell 3.0 as "the remaining shape". Both
overreach, and I withdraw both.

What the artifact actually supports: `ConvertTo-Json`, `New-Object System.Text.UTF8Encoding`
and `[System.IO.File]::WriteAllBytes` all executed in the same leg, while `Get-FileHash`
raised CommandNotFound. That is consistent with more than one cause — a partially resolved
or shadowed module, a command-visibility restriction, and an older engine among them. One
cmdlet from a module resolving does not establish that the module's whole command surface
was reachable, so it cannot refute a module-path problem.

Standing statement: **the cause is not established, and no single remaining explanation is
named.** The actionable item is unchanged and is the only thing F4 should have asserted —
the document records no engine version and no language mode, so the question is not
answerable from saved evidence.

## C3 — "complete document" must not be read as contract-complete evidence.

F3 establishes that t1's JSON and base64 were both written before the failing hash call, so
"the elevated capture never ran" is false. It establishes nothing more than that. t1's
native exit remains 2, and its document carries the same F1 and F2 schema defects as t2 and
t3 — so it is a PERSISTED document, not satisfied evidence. Where my findings record says
"complete document" it means bytes on disk, complete and parseable; it does not mean the
capture contract was met, and the contract was not met.

## C4 — new, from re-reading the run rather than from a correction.

The run contains **zero array-valued properties**: across all 43 records in t2, 189 property
states are NO_RULE, 32 PRESENT, 1 ABSENT, and `is_array` is false on every one of them. So
the multi-value / empty-array path — the thing the D2 raw-value design exists to measure —
was never exercised by this run at all. That is independent of F1: fixing the `matches`
unwrapping would not by itself have produced a single array-valued observation here, because
the subject rules were absent and the positive control carries no array property that came
back present.

Consequence for the authorized fixture work: singleton / multiple-match / synthetic NO_RULE
documents are necessary but not sufficient. An array-valued property (cardinality 0, 1 and
n) has to ride through the REAL validator too, or the array path stays unexercised end to
end exactly as it is now.

## C5 — why the one control that touched this boundary did not catch F1.

`rig-d2/raw-array-control.ps1` is the only control that checked serialization. It asserts
against `$r.value | ConvertTo-Json`, and where a one-element array came back unrolled it
RECONSTRUCTS the expected text by hand:

    if ($r.value -is [System.Array] -and @($r.value).Count -le 1) {
        $j = '[' + ... + ']'   # ConvertTo-Json unrolls these
    }

That unrolling is an artifact of the control's own PIPELINE usage, not of the document: in
`d2_capture.ps1` the value arrays are assigned straight into a hashtable key
(`$rec['value'] = @($out.ToArray())` at :109 and :161) and nested one-element arrays DO
survive `$doc | ConvertTo-Json -Depth 12`. The control met unwrapping, attributed it to the
encoder, wrote a workaround, and recorded 23 PASS.

So the defect was not missed for lack of a control. It was missed because the control
encoded the unwrapping as an EXPECTATION instead of asking whether the written document had
it — and `matches`, which reaches the document through a FUNCTION RETURN rather than a
hashtable assignment, is where the same-looking behaviour is real. A workaround written to
make a check pass is a place a defect can live.