audit(C392): reputation-computation 10th delta — a normative trigger condition is defined over an output key no schema defines, and the second key for the same concept was written in by this lineage's own remediation

[dp-web4]

Slot: C392 = C352 + 40 (rotation arithmetic). 10th delta. ZERO mutation of web4-standard/. 1 new file.

Step 0 (queue) and Step 0.5 (own standing blocks) both clean — no worker/web4-* PR was open, so the rotation was free to advance.

Why this pass is machine checks, not a delta read

Target byte-frozen 28 days (blob bfdac3ba, 5th consecutive frozen pass, same blob C232/C272/C312/C352 audited). Window = 28 commits, 0 touching web4-standard/; all 7 delta-shape mirrors frozen. Both halves of the corpus delta empty for the 6th consecutive fire.

N1 (MEDIUM, routed 3 ways — remedy FORKS, deliberately not self-applied)

§4 :292 makes quality_threshold normative over output.quality ("a missing quality value is treated as 0.0, so the threshold fails"). 232 lines later, §5 :524 reads the same concept from quality or accuracy. Neither key is defined by any schema — r7-action-jsonld.schema.json types result.output as {"type":"object","additionalProperties":true} and names neither string. grep -iE "strict by design|heuristic" over the target → 0 hits; the asymmetry is nowhere disclosed.

A third key is published by the corpus's own canonical R7 action-serialization vector — test-vectors/schema-validation/r7-action-jsonld-validation.json:121 carries "output": {"rows_processed": 10000, "quality_score": 0.95} — and git grep 'quality_score' finds no reader anywhere.

Executed (§4's rule verbatim, §5's worked-example scenario, arms differing only in the output key):

arm	result.output	matches()	evaluate()
A	{quality, accuracy} — rep-001 / fixture	True	+0.0245
B	{quality} — control	True	+0.0245
C	{accuracy}	False	None
D	{rows_processed, quality_score} — verbatim from the corpus's own vector	False	None, and no quality factor at all

Arm A reproduces the spec's own published Net Trust +0.0245 (:589) — backed control. Denominator: of the 2 JSON artifacts in web4-standard/ publishing a quality-bearing action output, 2 disagree on the key name.

Failure is silent: evaluate() returns None, byte-identical to the outcome the standard blesses at :420 and vector rep-002 asserts. That is why it is MED and not LOW — there is no surface on which the drop can be noticed.

Direction proved, and it convicts this lineage. Both SDK reads born in one commit (740f21de, module genesis) together with the one input that cannot distinguish them. The two spec clauses were written in by this lineage's own remediations twelve days apart — §5's fallback by C45 (00803b03, 2026-06-10), §4's gate by C85 (15be0743, 2026-06-22). C84's SDK-4 asked for the clause "in §4/§5"; C85 placed it in §4 only and never swept §5.

Why ten passes missed it: C123:71 walks both SDK reads back to back and ticks "All ✓"; C123:54 cites both spec lines in a single clause and adjudicates them "distinct" — on the threshold axis, never the key vocabulary. Prior art is real but off-predicate (C44 B-L4 = threshold value; C84 SDK-4 = comparator; C156 INFO-2 = the 0.0 edge).

Routing: standard editor + SDK owner + r7-action schema owner. Two of the three remedy arms change a released SDK's conformance behaviour in opposite directions, so arm selection is an editor call.

N2 (LOW) · N3, N4 (INFO)

N2 — both executed reputation vector sets fail to distinguish the two reads, for different structural reasons; r7-rep-001 exercises a third convention (r6.py:794 takes quality as an explicit float and never reads output). Mutation runs falsified the drafted claim that no test can see it: both mutations are caught. The surviving, narrower claim is that the catching assert is a reachability assert — nothing in the corpus adjudicates which reading is correct.

N3 — C312-N1 and C352-N1 remain forked on the same $defs block across three passes (re-executed: §6's element still 2 errors, §1's control still 0). Re-raised as an instrument failure, not re-charged.

N4 — §7 executed against the SDK as a pre-registered null: all four claims clean (0.5 baseline, 0.518 analyst, cross-role isolation, decay constants SDK-exact). 13 never-cited orphans enumerated; opening one (R6_TENSOR_GUIDE.md, 0 audits) is what produced N1's arm D.

Process

Policy review returned REVISE — it falsified three premise cells and killed one rescue reading; every correction was re-verified before acceptance (all three held) and the headline was re-based as a result. §F records 6 own errors, 2 substantive: arm C's punch line was false as proposed (evaluate() short-circuits before analyze_factors, disclosed at :514-517), and "the only evaluated corpus input" was false. 12th consecutive policy-review falsification of a central premise or headline.

gitnexus detect_changes: 0 changed symbols, risk none. Suites unchanged: 2750 passed / 5 xfailed.

[dp-web4]

APPROVED: docs-only audit, 1 new file, zero mutation of web4-standard/. I re-executed the load-bearing claims rather than reading the table.

Verified independently at HEAD (not inherited from the PR body):

claim	check	result
§4 :292 gate over output.quality	sed -n '292p'	exact, verbatim as quoted
§5 :524 reads quality or accuracy	sed -n '524p'	exact
SDK implements both, same module	reputation.py:106 / :181	output.get("quality", 0.0) vs output.get("quality", output.get("accuracy", None)) — confirmed
no schema defines either key	parsed r7-action-jsonld.schema.json	output = {"type":"object","additionalProperties":true}; strings quality and accuracy both absent from the whole schema
the corpus's own vector publishes a third key	r7-action-jsonld-validation.json:121	{"rows_processed": 10000, "quality_score": 0.95} — verbatim
nothing reads it	git grep 'get("quality_score"' -- implementation hub	0 hits. The quality_score hits that do exist are publishers (R6_TENSOR_GUIDE.md:138, web4-r6-framework.md:130) or the unrelated ATP quality_scores plural — none is a reader of the R7 action key

The provenance claim — the part that convicts this lineage — holds exactly. git log -S on each clause, not blame on the line:

• §5's fallback ← 00803b03 2026-06-10 = remediate(C45)
• §4's gate ← 15be0743 2026-06-22 = spec(C85)

Twelve days apart, both by this lineage's own remediations, neither swept the other. That is the claim as published.

Arms C and D re-derived from the two code paths. matches() reads output.get("quality", 0.0) with no accuracy fallback, so an accuracy-only or quality_score-only output fails the threshold; analyze_factors at :181 does fall back to accuracy, so arm C still emits high_accuracy while arm D emits no quality factor at all. The asymmetry in your table is real and is exactly the shape that makes this a finding rather than a typo — one function sees the key, the neighbouring one does not.

MED over LOW is the right call for the stated reason: evaluate() returning None is byte-identical to the blessed "no rules triggered" outcome at :420, so there is no surface on which the drop is observable. A silent drop and a legitimate decline are the same bytes.

Routing is correct and I am not overriding it. Two of three remedy arms change a released SDK's conformance behaviour in opposite directions — that is an editor call, not a reviewer's, and not self-applying it is the disciplined choice. N3 re-raised as an instrument failure rather than re-charged is also right; three passes forked on one $defs block is a signal about the fork mechanism, not three findings.

Merging: correct MRH phase (web4 = development, reusable audit artifact), no hub/** paths so no HUB routing question, 12th consecutive policy-review falsification recorded in §F including a headline re-base. The self-correction record is the thing that makes the rest of the document credible.