# This directory is EVIDENCE OF A WRONG MODEL, not product validation

doyle, PSL5EUYZ. Read this before reading anything else here.

`enforcement_gate.py` and `test_enforcement_gate.py` are **frozen as they ran**, deliberately not
corrected, because the 31/31 result is only useful as a record of what I got wrong. They are
**not** validation of the product and must never be cited as such.

## Two errors, both mine

### 1. The acceptance contract was wrong: `[1,1]` must REJECT

The agreed contract is **only exactly `[1]` succeeds**. My table has a cell
`("repeated success codes", [success, success], ACCEPT)` and my `classify()` accepts any non-empty
sequence whose elements are all the success code. That is membership-flavoured acceptance wearing
the language of equality, which is precisely the failure the cell was supposed to guard against.

The source of the error is mine and it was avoidable: todlando's draft listed `[1,1]` in the
**refuse** set — "refuses [], [0], [2], [5], [20], [1,1], [1,5], [5,20]. The [1,1] and [1,5] cells
exist specifically to catch equality silently becoming membership." I read the sentence about what
those cells are *for* and filed `[1,1]` under accept anyway. He wrote it correctly; I inverted it.

So 31/31 green was a suite agreeing with a wrong contract. A green tally is worth nothing if the
oracle is wrong, and this is that, preserved.

### 2. It is a parallel implementation of the Rust gate, which should not exist

`enforcement_gate.py` re-implements the product's decision in another language. Its behaviour on
Python-specific shapes — tuples, `bool` as an `int` subclass, `list` vs `str` iteration — is
**Python's semantics, not the product's transport contract**, so agreement with it proves nothing
about the product. The real coverage has to exercise the actual Rust decision and deserialization
paths, and the extraction regression has to exercise the **production PowerShell expression**
rather than feeding numeric data to a second implementation.

## What survives from this work

The *case shapes* are still right and carry forward into the Rust migration: duplicate and
mixed-value rejection boundaries, representative malformed JSON, and null transport. What does not
carry forward: the Python implementation, the Python-specific shapes, and the redundant
per-accessor-spelling rows.

## One thing I over-corrected, recorded so it is not re-litigated

I told todlando that "Full is the published MOF name for value 1" was a documentation claim "not
supported by the evidence", on the strength of `MAPPING=UNRESOLVED` / Values qualifier absent in
`subject.out`. That went too far, and he accepted it from me, so the correction is owed in both
directions. **The Microsoft specification is separate documentation evidence.** A missing Values
qualifier on this host says the mapping is not derivable *from this capture*; it does not
invalidate the documented meaning of the code. What the capture establishes is that raw 1 renders
as `Enforced` here. What makes 1 the *success* code is the specification — not an oracle derived
from the capture.

Frozen: `REPR-PIN.sha256` covers the files as they ran. Not corrected, not re-run.