Incomex AI Portal
KB-5797

RS5B-PATCH2-02 — Canonical-Operation Effect-Identity Correction (R1) — 2026-06-21

10 min read Revision 1
rs5b-patch2g2effect-identitycanonical-operationbusiness-onlypurity-preservedfail-closed2026-06-21

RS5B-PATCH2-02 — Canonical-Operation Effect-Identity Correction (R1) — 2026-06-21

Macro: RS5B-PATCH2 · Deliverable 02 of 6 · design-only · scoped correction. Closes: Codex residual R1 — effect_identity hardcodes operation = "register_dot" (Codex §4, §10.1). Supersedes: the formula in RS5B-PATCH1-02 §2 (and its register_dot-specific ancestor framing where used as the general RS5B founding formula). Does not supersede RS4A-PATCH2-02 §1 in its register_dot-specific domain (still valid — see §6).

1. The corrected general formula

effect_identity = H(
    protocol_version,              # versioned hashing/canonicalization contract
    canonical_operation,           # governed action/effect type for THIS act — NOT hardcoded
    canonical_target_object_type,  # generalized target type (e.g. "dot", "governance_scope", "owner_of_record")
    canonical_target_object_ref,   # the governed object reference within that type
    canonical_artifact_identity,   # canonical_path @ origin (symlink/.. resolved)
    canonical_artifact_hash        # trusted attested artifact hash (NEVER request_proposed)
)

This supersedes the hardcoded operation = "register_dot" line. The operation field is now canonical_operation, and the single target field canonical_target_dot_code is generalized to the pair (canonical_target_object_type, canonical_target_object_ref) so non-DOT founding acts (scope, owner-of-record) have a real business target. RS5B-05 element 4 ("object being owned: (object_type, object_ref)") maps directly onto this pair.

2. canonical_operation — definition and rules

Definition: canonical_operation is the governed action/effect type for the specific act being authorized. It is one value drawn from a governed vocabulary of operations. register_dot is exactly one possible value.

Rules:

  1. Per-act operation. Each governed act has its own canonical_operation. Distinct operations ⇒ distinct effect_identity ⇒ distinct authorizations.
  2. register_dot is not the default. Founding owner-of-record designation MUST NOT be identified as register_dot. Scope creation MUST NOT be identified as register_dot.
  3. Authority change ≠ new effect. A change in authority fields (founding_authority_ref, approval evidence, authority policy, owner scope/head, nonce, window) does NOT create a new effect. A new effect requires a change to canonical_operation or to the business target (canonical_target_object_type / canonical_target_object_ref / canonical_artifact_identity / canonical_artifact_hash). This is the §4 "must not infer a new effect from authority changes" requirement made structural — and it is exactly what effect_identity purity already guarantees, because authority fields are not hashed into it.
  4. Purity unchanged (must-not-do #19 respected). effect_identity continues to EXCLUDE all authority/credential/execution fields: owner scope/head/policy, approvals/quorum evidence, APR/owner-row IDs, principal references, nonce, attempts/runs, timestamps, operator, session, host, authorization window, and founding_authority_ref. These live only in authorization_binding_digest (unchanged from RS5B-PATCH1; Codex §5 PASS).

3. Design-level example vocabulary (NOT runtime rows)

The following are design examples only, to show that canonical_operation is per-act. They are NOT created as runtime rows, NOT a new registry, and NOT finalized values.

governed act (RS5B founding scope) canonical_operation (design example) distinct from register_dot?
register_dot admission "register_dot" this IS register_dot (the only place the literal is used)
founding owner-of-record designation "designate_owner_of_record" / "founding_owner_designation" yes
governance scope creation "create_governance_scope" yes
DOT activation "activate_dot" yes

Final operation strings are to be finalized by the future separately-authorized lane (P2+), not here.

4. Vocabulary presence — fail-closed declaration

A governed vocabulary of canonical operations for effect_identity does not yet exist as runtime rows. (Direct KB search for canonical_operation returns no document defining such a vocabulary; the nearest live surface is apr_action_types — 14 APR action types, which are an APR-layer construct and notably do not include register_dot — i.e. a related-but-distinct surface, not an effect-identity operation vocabulary.)

Therefore, at design time:

  • CANONICAL_OPERATION_VOCABULARY_REQUIRED_NOT_PRESENT is the fail-closed posture: when an act's governed canonical_operation cannot be resolved against a present, governed vocabulary, the contract HOLDs the act; it does NOT default to register_dot, does NOT invent a row, and does NOT emit a PASS.

This mirrors how RS5B already treats CANONICAL_PRINCIPAL_SURFACE_REQUIRED_NOT_PRESENT and BOOTSTRAP_AUTHORITY_UNRESOLVED: a required surface that is absent yields a fail-closed HOLD, never a silent default.

5. Operation-domain bad inputs (OP-BI) — fail-closed, guards R1

These are design fixtures (not executed tests) that adversarially probe R1. They are kept separate from the BI-E1..BI-E7 set (deliverable 05) so that set stays exactly the seven Codex reviewed.

id input shape evaluation layer expected canonical rejection why no competing code PASS/seal/digest? result
OP-BI-1 a founding owner-of-record designation act computes effect_identity with canonical_operation = "register_dot" operation-domain (effect-identity construction) WRONG_CANONICAL_OPERATION_FOR_EFFECT the act's governed operation is owner-designation, not register_dot; mislabel is detected at construction before any binding No FAIL (rejected)
OP-BI-2 a scope-creation act labeled canonical_operation = "register_dot" operation-domain WRONG_CANONICAL_OPERATION_FOR_EFFECT same as OP-BI-1; scope creation is a distinct governed operation No FAIL (rejected)
OP-BI-3 the same canonical_operation + same business target presented as a NEW effect solely because authority changed (different founding_authority_ref / approval / policy / owner) effect-identity purity / dedup AUTHORITY_CHANGE_IS_NOT_NEW_EFFECT authority is excluded from effect_identity; identical operation+target ⇒ identical effect ⇒ one effect, not two No (no second effect minted) FAIL (no new registration)
OP-BI-4 an act whose governed canonical_operation cannot be resolved against any present, governed vocabulary operation-vocabulary resolution CANONICAL_OPERATION_VOCABULARY_REQUIRED_NOT_PRESENT absent required surface ⇒ fail-closed HOLD; default-to-register_dot is forbidden No FAIL / HOLD (no default, no invented row)

Every OP-BI fails closed. No invalid input produces a PASS, seal, digest, certificate, authority token, or registration-ready label.

6. Relationship to the accepted RS4A-PATCH2 register_dot formula

RS4A-PATCH2-02 §1 defines effect_identity with operation = "register_dot" (and canonical_target_dot_code). That formula remains valid in its register_dot-specific domain — it is the register_dot specialization of the general formula in §1 above, obtained by setting:

canonical_operation         = "register_dot"
canonical_target_object_type = "dot"
canonical_target_object_ref  = canonical_target_dot_code

What R1 forbids is using that register_dot-specific formula as the general RS5B founding formula. PATCH2 does not reopen RS4A-PATCH2; it generalizes the founding case and leaves register_dot admission unchanged.

7. New reject codes / labels introduced by R1 closure

All are design-level, fail-closed clarifications — not new runtime blockers beyond the carried set (consistent with how RS5B-PATCH1 introduced AUTHORIZATION_BINDING_MISSING_EFFECT / EFFECT_IDENTITY_IMPURE as made-explicit codes):

  • WRONG_CANONICAL_OPERATION_FOR_EFFECT — an act's effect_identity uses an operation that is not the governed operation for that act (e.g. a founding designation labeled register_dot).
  • AUTHORITY_CHANGE_IS_NOT_NEW_EFFECT — authority-only change presented as a new effect; rejected (one effect).
  • CANONICAL_OPERATION_VOCABULARY_REQUIRED_NOT_PRESENT — required canonical-operation surface absent; fail-closed HOLD, no default, no invented row.

8. R1 self-attestation

  1. The general formula contains canonical_operation, not operation = "register_dot". ✓
  2. register_dot appears only as the example value for register_dot admission (§3) and as the register_dot specialization (§6). ✓
  3. Founding owner-designation and scope creation are explicitly forbidden from being identified as register_dot (rule 2, OP-BI-1/2). ✓
  4. Authority changes do not mint a new effect (rule 3, OP-BI-3). ✓
  5. effect_identity purity is preserved; founding_authority_ref stays in the binding (rule 4). ✓
  6. Canonical-operation vocabulary absence declared REQUIRED_NOT_PRESENT; no rows invented (§4, OP-BI-4). ✓

R1 status: CLOSED_DESIGN_ONLY. REGISTRATION_HOLD retained · CAN_PROCEED = NO · 0 mutations.

Back to Knowledge Hub knowledge/dev/laws-new/reports/rs5b-patch2/02-canonical-operation-effect-identity-correction-2026-06-21.md