KB-3CD6

RS5B-06 — Fail-Closed Adversarial Self-Check and Bad Inputs (BI01–BI10) — 2026-06-21

11 min read Revision 1
rs5bg2adversarial-self-checkbad-inputsfail-closedno-fail-openengineering-vs-authority-pass2026-06-21

RS5B-06 — Fail-Closed Adversarial Self-Check and Bad Inputs (BI01–BI10) — 2026-06-21

Macro: RS5B · Deliverable: 06 of 9 · self-check. This file is the package's own adversary. It was authored by the same author who wrote RS5B-01..05, then turned against them. Per the user directive, the package is not sent forward until I have personally proven — input by input — that no invalid input can produce a PASS/digest/seal/cert-like output.

0. Self-check posture (verbatim discipline)

  • I do not trust my own report.
  • I find the actual governed files and re-read them ([[01-source-register-and-current-state-reconstruction]] §1).
  • I fresh-reconstruct from KB and LIVE query_pg, not from local prose, memory, or summary ([[01-source-register-and-current-state-reconstruction]] §2).
  • I create bad inputs beyond the happy path (BI01–BI10 below).
  • I check whether an invalid input could still produce a PASS / digest / seal / cert-like output.
  • If an invalid input can pass, I reject the package and raise a blocker — I do not send a Codex/GPT packet as PASS.
  • I distinguish engineering/design PASS from authority PASS, and never upgrade the former to the latter.

1. Bad-input probe table (BI01–BI10)

For each: input shapeexpected rejectionactual contract responsePASS/digest/seal-like output possible?result.

BI01 — operator self-mints Owner without authority

  • input shape: the operator/caller running the registrar asserts itself as Owner, or inserts a governance_object_ownership row directly.
  • expected rejection: OPERATOR_NOT_OWNER / CALLER_SELF_ASSERTED_OWNER_REJECTED.
  • actual contract response: Model A is REJECTED ([[03-authority-chain-candidate-models-and-rejection-matrix]]); operator/caller is categorically never an authority (RS5A-03 §2); Điều 32 §2.1 forbids manual SQL/curl mint; ownership requires a sanctioned path + Chairman authority (packet items 1, 13).
  • PASS/seal possible? No — no authority source, no scope row, no sanctioned mint path; nothing can emit an owner binding.
  • result: FAIL (rejected).

BI02 — GOV-COUNCIL approval reused as registration authority

  • input shape: a council approval (or the broad live approval scope) presented as the authority that mints/owns registration.
  • expected rejection: MUST_NOT_IMPLICIT_INHERIT / SCOPE_DRIFT.
  • actual contract response: Model C REJECTED; DOT_APPROVAL_QUORUM_AUTHORITY ↛ DOT_REGISTRATION_AUTHORITY is forbidden (PATCH1-04 §2, PATCH2-03 §3.8); packet item 10 blocks it; and the approval cannot even validly form (F6 scope absent, F7 canonical principal absent).
  • PASS/seal possible? No — approval authority confers zero scope ownership; the implicit-inheritance edge is explicitly forbidden.
  • result: FAIL (rejected).

BI03 — free-text president accepted as authority

  • input shape: vote approver='president-bot' (or any free-text containing "president") treated as president authority.
  • expected rejection: FREE_TEXT_PRESIDENT_REJECTED (PATCH2-03), Q10 in the total order (PATCH4-02).
  • actual contract response: president must resolve via principal_resolution_ref, never text; the total Q-order returns Q10 (lowest matching code) for this input; the live approver ILIKE '%president%' is precisely the fail-open being rejected; packet item 8.
  • PASS/seal possible? No — president slot is unresolved without the canonical surface (F7); IDENTITY_PASS cannot be reached.
  • result: FAIL (rejected).

BI04 — owner scope implicitly inherits activation

  • input shape: a head owning DOT_REGISTRATION_AUTHORITY used to perform draft→active, or assumed to own DOT_ACTIVATION_AUTHORITY.
  • expected rejection: OWNER_SCOPE_MISMATCH / WRONG_ACTION_FOR_EFFECT.
  • actual contract response: MUST_NOT_IMPLICIT_INHERIT (RS5A-04 §2; PATCH2-02 names activation the only post-registration-capable scope, never inherited); RS5A-09 C04/I02/I08; packet item 10.
  • PASS/seal possible? No — activation requires its own explicit scope + head + action; registration authority grants none of it.
  • result: FAIL (rejected).

BI05 — approval without effect/artifact binding

  • input shape: an APR that is quorum-passed but not bound to effect_identity / artifact_hash, presented as sufficient to admit.
  • expected rejection: APPROVAL_NOT_BOUND_TO_EFFECT_IDENTITY / QUORUM_EFFECT_BINDING_MISSING.
  • actual contract response: quorum is necessary-not-sufficient (RS5A-08 Q3, F10 reasoning); LIVE L4 proves approval_requests has zero effect/artifact/hash columns — so an effect-bound approval cannot even be expressed today; packet items 5/6.
  • PASS/seal possible? Noquorum_passed=true is explicitly insufficient; the binding column does not exist, so no valid admission can be sealed.
  • result: FAIL (rejected).

BI06 — absent canonical-principal surface still produces approval PASS

  • input shape: quorum evaluated while CANONICAL_PRINCIPAL_SURFACE_REQUIRED_NOT_PRESENT, expecting an IDENTITY_PASS.
  • expected rejection: Q00 CANONICAL_PRINCIPAL_SURFACE_REQUIRED_NOT_PRESENT (PATCH4-02 total order — lowest code, context precondition).
  • actual contract response: the oracle evaluates Q00 first; with the surface absent it returns Q00 and never IDENTITY_PASS (PATCH2-03 §5: "every quorum-identity decision fails closed today").
  • PASS/seal possible? No — Q00 is structurally first; no identity pass is reachable while the surface is absent.
  • result: FAIL (rejected).

BI07 — no rollback plan but design claims "execution-ready"

  • input shape: a W-step (scope/owner/action write) labeled "execution-ready" while packet item 9 (rollback) is absent.
  • expected rejection: ROLLBACK_PLAN_ABSENT; the "execution-ready" label is invalid.
  • actual contract response: RS5B-04 §5 + RS5B-05 item 9 forbid any write without per-block rollback; OR v7.58 §4 (mutation needs backup/rollback); NT15 design-before-execution; RS5B must-not-do #22 ("do not write 'execution-ready' unless packet requirements satisfied").
  • PASS/seal possible? No — the label is rejected; engineering completeness is not execution authorization.
  • result: FAIL (label rejected).

BI08 — package claims authority PASS when only engineering PASS exists

  • input shape: RS5B output (or a future summary) labeled "authority PASS" / "registration PASS" / "runtime PASS".
  • expected rejection: only design-review-ready PASS / engineering-design PASS permitted.
  • actual contract response: authority PASS would require packet item 13 (Chairman) + a bound owner + all hard prerequisites — none exist (F1–F10). The PASS-level contract ([[07-rs5b-decision-packet]] §PASS-levels) downgrades any such claim; asserting authority PASS is itself a fail-open and is rejected.
  • PASS/seal possible? No — the claim is structurally downgraded to engineering/design PASS.
  • result: FAIL (claim downgraded/rejected).

BI09 — RS5B tries to create Owner/scope/APR/register_dot

  • input shape: RS5B itself performs a W-step (DDL/DML, owner row, scope row, APR, register_dot, approval, handler).
  • expected rejection: RS5B_REJECT_RUNTIME_MUTATION — RS5B is non-mutating (must-not-do #1–#15).
  • actual contract response: every W-step is [GATE] ([[04-preferred-non-mutating-execution-design-runbook]]); as a matter of executed fact this macro performed only (a) read-only query_pg SELECTs and (b) KB document uploads — zero DDL/DML, zero governance-row writes, zero Directus mutation.
  • PASS/seal possible? No — and the probed action did not occur; the only writes were KB design docs, which are the deliverable, not runtime mutations.
  • result: FAIL (would be rejected) · ACTUAL = did not occur.

BI10 — REGISTRATION_HOLD missing or weakened

  • input shape: an RS5B output drops/weakens REGISTRATION_HOLD or asserts REGISTRATION_CAN_PROCEED.
  • expected rejection: gate must be retained; REGISTRATION_CAN_PROCEED = NO.
  • actual contract response: F10 (gate active); every RS5B file restates the hold; the verdict cannot clear it (must-not-do #16/#17); [[07-rs5b-decision-packet]] re-asserts REGISTRATION_HOLD.
  • PASS/seal possible? No — the hold is structurally retained across all files; no RS5B output asserts proceed.
  • result: FAIL (would be rejected) · ACTUAL = hold retained.

2. Adversarial verdict

probe invalid input can produce PASS/digest/seal? result
BI01 operator self-mint No FAIL (rejected)
BI02 council-as-registration-authority No FAIL (rejected)
BI03 free-text president No FAIL (rejected)
BI04 implicit activation inherit No FAIL (rejected)
BI05 approval no effect binding No FAIL (rejected)
BI06 absent canonical surface → pass No FAIL (rejected)
BI07 no rollback but "execution-ready" No FAIL (label rejected)
BI08 authority-PASS overclaim No FAIL (downgraded)
BI09 RS5B self-mutation No (and did not occur) FAIL (rejected)
BI10 hold weakened No (hold retained) FAIL (rejected)

No invalid input produces a PASS/digest/seal/cert-like output. Every probe fails closed against a named reject code or a structural barrier. Because no fail-open remains, the package may proceed to GPT/Codex review (it would otherwise be held with an action-ready blocker).

3. Two extra self-traps I set for myself

  1. "Is RS5B_READY_FOR_GPT_REVIEW an over-claim, given BOOTSTRAP_AUTHORITY_UNRESOLVED is still carried?" — Checked: the verdict is a design-review-ready PASS, not an authority/runtime PASS. BOOTSTRAP_AUTHORITY_UNRESOLVED describes the runtime state, which RS5B deliberately leaves unresolved ([[02-g2-owner-of-record-bootstrap-problem-statement]] §5). The HOLD verdict RS5B_HOLD_BOOTSTRAP_AUTHORITY_UNRESOLVED is reserved for "bootstrap cannot even be designed" — but it can be (Model D is grounded in promulgated law), so HOLD does not apply. Not an over-claim.
  2. "Did I rely on prior reports as proof anywhere a fact mattered?" — Checked: the five controlling facts (ownership=0, no registration scope, mint unimplemented, no effect-binding column, candidate heads) were re-derived LIVE this macro (L1–L5). The only carried-not-re-derived item (quorum function bodies) is explicitly flagged F5 and affects no conclusion (all conclusions are fail-closed regardless). No silent reliance.

4. Status

ADVERSARIAL_SELF_CHECK_PASSED_NO_FAIL_OPEN — ten bad-input probes plus two self-traps, each traced to a fail-closed outcome; no invalid input yields PASS/digest/seal; engineering PASS kept strictly below authority PASS. The package carries no residual fail-open and is eligible for review.

Back to Knowledge Hub knowledge/dev/laws-new/reports/rs5b/06-fail-closed-adversarial-self-check-and-bad-inputs-2026-06-21.md