RS5B-PATCH1-04 — Codex-Style Self-Check and Bad Inputs (BI-E1..BI-E7) — 2026-06-21

Macro: RS5B-PATCH1 · Deliverable: 04 of 7 · self-check. Posture (verbatim): I do not trust report prose. I find the actual governed files and re-read them ([[01-source-and-defect-map]]). I fresh-reconstruct from KB (RS4A-PATCH2-02 read full). I create bad inputs beyond the happy path. If an invalid input can still produce a PASS/digest/seal/cert-like output, I reject. I distinguish engineering/design PASS from authority PASS. Test target: the corrected contract in [[02-corrected-effect-identity-and-authorization-binding-contract]] — effect_identity pure; authorization_binding_digest includes effect_identity.

1. Bad-input probes

For each: input shape → expected rejection → contract response → PASS/digest/seal possible? → result.

BI-E1 — approval packet omits effect_identity but includes owner/approval

• input shape: an authorization binding carrying owner scope + approval evidence, but no effect_identity.
• expected rejection: APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY (packet-level approval/effect failure). AUTHORIZATION_BINDING_MISSING_EFFECT is reserved for the digest-shape fixture BI-E6, so BI-E1 has one canonical outcome.
• contract response: PATCH1-02 §3 rule 1 — effect_identity is a REQUIRED input of authorization_binding_digest; a binding without it is not bound to any effect.
• PASS/seal possible? No — the binding cannot resolve to an effect; admission fail-closed.
• result: FAIL (rejected).

BI-E2 — packet includes effect_identity but swaps the artifact hash

• input shape: binding presents effect_identity for artifact A, but the admitted artifact hash is B.
• expected rejection: ARTIFACT_HASH_MISMATCH (the canonical, specific outcome; AUTHORIZATION_BINDING_MISMATCH is not an alternative PASS oracle).
• contract response: canonical_artifact_hash is an input of effect_identity (PATCH1-02 §2); a different artifact hash yields a different effect_identity, so the presented effect no longer matches the artifact ⇒ mismatch; if recomputed, it is a different effect needing its own authorization.
• PASS/seal possible? No — effect↔artifact coupling is hash-enforced; a swap cannot pass under the original binding.
• result: FAIL (rejected).

BI-E3 — same effect_identity but binding claims a different owner scope/head

• input shape: the packet claims owner scope/head B while presenting an authorization_binding_digest computed for owner scope/head A; this fixture has no prior durable decision.
• expected rejection: AUTHORIZATION_SCOPE_MISMATCH (one canonical outcome).
• contract response: authority is excluded from effect_identity (purity), so the business effect remains the same, but the claimed owner fields must match the fields committed into the authorization binding. A≠B fails before admission. The separate prior-durable-decision domain continues to use AUTHORIZATION_CHANGED_SAME_EFFECT_DUPLICATE and is not part of BI-E3.
• PASS/seal possible? No — same effect ⇒ no second registration; scope change cannot bypass U1.
• result: FAIL (rejected).

BI-E4 — same approval reused for a different effect_identity

• input shape: an approval/quorum evidence bound to effect X presented to authorize effect Y.
• expected rejection: APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY.
• contract response: PATCH1-02 §3 rule 2 — the binding ties one authorization envelope to one exact effect; an approval bound to X is not evidence for Y.
• PASS/seal possible? No — approval-substitution across effects is exactly what binding-to-effect forbids.
• result: FAIL (rejected).

BI-E5 — effect_identity computed with approval/owner/nonce fields

• input shape: an effect_identity whose hash inputs include authority/credential/execution fields.
• expected rejection: EFFECT_IDENTITY_IMPURE.
• contract response: PATCH1-02 §2 exclusion list + rule 4 — any authority/credential/execution field in effect_identity makes it impure; rejected.
• PASS/seal possible? No — an impure key is rejected before it can seal anything (and would also reintroduce the RS4A-PATCH2 duplicate hole, which is closed).
• result: FAIL (rejected).

BI-E6 — authorization_binding_digest omits effect_identity

• input shape: a binding digest that does not include effect_identity as an input.
• expected rejection: AUTHORIZATION_BINDING_MISSING_EFFECT.
• contract response: PATCH1-02 §3 rule 1 — effect_identity is a REQUIRED input of the binding; omission ⇒ fail-closed. (This is the exact inverse of the superseded "kept out of the authorization binding" wording, now rejected by construction.)
• PASS/seal possible? No — a binding without the effect cannot be admitted.
• result: FAIL (rejected).

BI-E7 — engineering/design PASS tries to imply authority PASS

• input shape: the corrected contract (a design wording fix) presented as if it makes registration runtime-ready or authority-approved.
• expected rejection: AUTHORITY_OVERCLAIM.
• contract response: PATCH1-02 §6 non-overclaim guard + RS5B-07 §3 PASS-level table — this is a wording correction; live surfaces remain REQUIRED_NOT_PRESENT, AUTHORITY_BINDING_UNRESOLVED at admission, REGISTRATION_HOLD retained; engineering PASS is never upgraded to authority PASS.
• PASS/seal possible? No — the claim is structurally downgraded.
• result: FAIL (downgraded/rejected).

2. Adversarial verdict

probe	expected rejection	invalid input → PASS/digest/seal?	result
BI-E1 omit effect, include owner/approval	APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY	No	FAIL
BI-E2 include effect, swap artifact hash	ARTIFACT_HASH_MISMATCH	No	FAIL
BI-E3 same effect, different owner scope	AUTHORIZATION_SCOPE_MISMATCH	No	FAIL
BI-E4 approval reused for different effect	APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY	No	FAIL
BI-E5 effect_identity includes authority fields	EFFECT_IDENTITY_IMPURE	No	FAIL
BI-E6 binding omits effect_identity	AUTHORIZATION_BINDING_MISSING_EFFECT	No	FAIL
BI-E7 design PASS → authority PASS	AUTHORITY_OVERCLAIM	No	FAIL

Each bad input produces exactly one expected rejection. No invalid input produces a PASS/digest/seal/cert-like output. The corrected wording closes the ambiguity without opening a new fail-open ⇒ the package may proceed to GPT review (otherwise it would stop at RS5B_PATCH1_HOLD_EFFECT_BINDING_STILL_AMBIGUOUS).

3. Self-trap

"Does the correction itself create the opposite hole — could effect_identity now absorb the authorization envelope?" Checked: PATCH1-02 §2 keeps the full exclusion list and rule 4 (EFFECT_IDENTITY_IMPURE) rejects any authority field in effect_identity. The correction moves effect_identity into the binding as an input; it does not move authority into effect_identity. Both directions are guarded (BI-E5 ↔ BI-E6). No opposite hole.

4. Status

SELF_CHECK_PASSED_NO_FAIL_OPEN — BI-E1..BI-E7 + one self-trap, each fail-closed against a named reject code; no invalid input yields PASS/digest/seal; engineering PASS kept strictly below authority PASS. Ambiguity closed.