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

Macro: RS5B-PATCH2 · Deliverable 05 of 6 · design-only · scoped correction. Purpose: restate the seven Codex-reviewed bad-input fixtures with BI-E1 and BI-E6 placed in disjoint layers (R2), then run the mandatory Codex-style self-test. These are design fixtures, not executed tests.

1. Updated BI-E1..BI-E7

For each: input shape · evaluation layer · expected canonical rejection · why no other rejection competes · PASS/seal/digest possible? · result.

BI-E6 — authorization_binding_digest input schema OMITS effect_identity (Layer 1, evaluated first)

• input shape: the declared/computed authorization_binding_digest input schema/list does not contain effect_identity as an input.
• evaluation layer: Layer 1 — digest-shape / binding-schema (checked before approval evidence).
• expected rejection: AUTHORIZATION_BINDING_MISSING_EFFECT.
• why no competing code: with effect_identity absent from the schema there is nothing for approval to bind to, so BI-E1 (Layer 2) is not evaluated; the discriminator P = (effect_identity ∈ digest schema) is false ⇒ only this code is reachable.
• PASS/seal/digest possible? No — a binding without the effect cannot be admitted; fail-closed.
• result: FAIL (rejected).

BI-E1 — digest INCLUDES effect_identity, but approval evidence is not bound to it (Layer 2)

• input shape: the authorization_binding_digest schema includes effect_identity = E, but approval_evidence_ref / approval_ref has no effect-bound link, or is bound to a different effect E′ ≠ E.
• evaluation layer: Layer 2 — approval/evidence binding (reached only if Layer 1 passed, i.e. P is true).
• expected rejection: APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY.
• why no competing code: Layer 1 has already confirmed effect_identity is present, so AUTHORIZATION_BINDING_MISSING_EFFECT (BI-E6) cannot fire here; the discriminator P is true ⇒ only this code is reachable.
• PASS/seal/digest possible? No — approval not bound to the exact effect cannot authorize it; fail-closed.
• result: FAIL (rejected).

R2 disjointness restated: BI-E6 and BI-E1 are separated by the single binary predicate P = (effect_identity ∈ authorization_binding_digest input schema). ¬P ⇒ BI-E6 only; P ⇒ BI-E1 domain only. No input matches both. Secondary safeguard precedence: AUTHORIZATION_BINDING_MISSING_EFFECT < APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY.

BI-E2 — digest INCLUDES effect_identity but the artifact hash is swapped

• input shape: binding presents effect_identity for artifact A; the admitted artifact hash is B.
• evaluation layer: business-target check (after Layers 1–2).
• expected rejection: ARTIFACT_HASH_MISMATCH.
• why no competing code: canonical_artifact_hash is an input of effect_identity (PATCH2-02 §1); a different artifact hash yields a different effect_identity, so the presented effect no longer matches the artifact. (AUTHORIZATION_BINDING_MISMATCH is not an alternative PASS oracle.)
• PASS/seal/digest possible? No — effect↔artifact coupling is hash-enforced.
• result: FAIL (rejected).

BI-E3 — same effect_identity but binding claims a different owner scope/head (no prior durable decision)

• input shape: packet claims owner scope/head B while presenting an authorization_binding_digest computed for owner scope/head A; no prior durable decision.
• evaluation layer: business-target / scope check.
• expected rejection: AUTHORIZATION_SCOPE_MISMATCH.
• why no competing code: authority is excluded from effect_identity (purity), so the business effect is unchanged, but claimed owner fields must match the fields committed into the binding; A ≠ B fails. The prior-durable-decision domain (AUTHORIZATION_CHANGED_SAME_EFFECT_DUPLICATE) is explicitly excluded from BI-E3.
• PASS/seal/digest 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 (Y is present in the digest schema, so Layer 1 passes).
• evaluation layer: Layer 2 — approval/evidence binding (same layer as BI-E1; the cross-effect special case).
• expected rejection: APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY.
• why no competing code: the binding ties one authorization envelope to one exact effect; approval bound to X is not evidence for Y. BI-E4 and BI-E1 yield the same code (no two-codes-for-one-input conflict); both are Layer-2 failures.
• PASS/seal/digest 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/authority fields

• input shape: an effect_identity whose hash inputs include authority/credential/execution fields (incl. founding_authority_ref).
• evaluation layer: purity guard (orthogonal shape check on the effect itself; before Layer 2).
• expected rejection: EFFECT_IDENTITY_IMPURE.
• why no competing code: the general formula (PATCH2-02 §1–§2) excludes all authority/credential/execution fields; any such field makes the key impure ⇒ rejected before it can bind or seal.
• PASS/seal/digest possible? No — an impure key is rejected; would also reintroduce the closed RS4A-PATCH2 duplicate hole.
• result: FAIL (rejected).

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

• input shape: the corrected contract (a design wording fix) presented as if it makes registration runtime-ready or authority-approved.
• evaluation layer: PASS-level guard (non-overclaim).
• expected rejection: AUTHORITY_OVERCLAIM.
• why no competing code: this is a wording correction; live surfaces remain REQUIRED_NOT_PRESENT, AUTHORITY_BINDING_UNRESOLVED at admission, REGISTRATION_HOLD retained; engineering PASS is never upgraded.
• PASS/seal/digest possible? No — the claim is structurally downgraded.
• result: FAIL (downgraded/rejected).

2. Adversarial verdict table

probe	layer	expected rejection	invalid input → PASS/digest/seal?	result
BI-E6 digest schema omits effect_identity	L1 digest-shape	AUTHORIZATION_BINDING_MISSING_EFFECT	No	FAIL
BI-E1 digest has effect, approval not bound to it	L2 approval-binding	APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY	No	FAIL
BI-E2 effect present, artifact hash swapped	business-target	ARTIFACT_HASH_MISMATCH	No	FAIL
BI-E3 same effect, different owner scope	business-target	AUTHORIZATION_SCOPE_MISMATCH	No	FAIL
BI-E4 approval reused for different effect	L2 approval-binding	APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY	No	FAIL
BI-E5 effect_identity includes authority fields	purity guard	EFFECT_IDENTITY_IMPURE	No	FAIL
BI-E7 design PASS → authority PASS	PASS-level guard	AUTHORITY_OVERCLAIM	No	FAIL

Operation-domain fixtures (OP-BI-1..4, guarding R1) are in PATCH2-02 §5; all fail-closed (WRONG_CANONICAL_OPERATION_FOR_EFFECT, AUTHORITY_CHANGE_IS_NOT_NEW_EFFECT, CANONICAL_OPERATION_VOCABULARY_REQUIRED_NOT_PRESENT).

3. Mandatory Codex-style self-test (from the macro addendum §D)

1. Does any general effect_identity formula still contain operation="register_dot"? → No. General formula uses canonical_operation (PATCH2-02 §1). → not HOLD_OPERATION_STILL_HARDCODED.
2. Is register_dot used only as an example for register_dot admission? → Yes (PATCH2-02 §3 example row + §6 specialization). → not HOLD_OPERATION_STILL_HARDCODED.
3. Can one malformed input satisfy both BI-E1 and BI-E6? → No (predicate P partitions inputs; layered evaluation, PATCH2-03 §2–§3). → not HOLD_BI_DOMAIN_STILL_OVERLAPS.
4. Does BI-E6 clearly cover digest-schema/input omission of effect_identity? → Yes (Layer 1, §1 above). → not HOLD_BI_DOMAIN_STILL_OVERLAPS.
5. Does BI-E1 clearly cover approval evidence not bound to an existing effect_identity? → Yes (Layer 2, §1 above). → not HOLD_BI_DOMAIN_STILL_OVERLAPS.
6. Does PATCH2 create runtime rows, scopes, Owner, APR, register_dot, approval, handler, or P2 authorization? → No. KB-only, design-only. → not REJECT_RUNTIME_MUTATION.
7. Does PATCH2 imply authority/runtime/registration PASS? → No. design-review-ready only; HOLD retained. → not REJECT_AUTHORITY_OVERCLAIM.

All seven gates pass. No invalid input produces a PASS, seal, digest, certificate, authority token, or registration-ready label. REGISTRATION_HOLD retained · CAN_PROCEED = NO · 0 mutations.