dot-iu-cutter v0.4 — cutter_verify Principal Design

document_path: knowledge/dev/laws/dieu44-trien-khai/v0.4-credential-design/dot-iu-cutter-v0.4-cutter-verify-principal-design-2026-05-16.md
revision: r1
date_authored: 2026-05-17
cycle_date_label: 2026-05-16
author: Agent (Claude Code CLI, Opus 4.7 1M)
phase: v0.4 — credential-cycle DESIGN (cutter_verify principal)
status: design_only_pending_gpt_review

⛔ DESIGN ONLY. cutter_verify is NOT created. NO GRANT. NO password. Target identity specification only.

---

§1 — Identity & Lane

role_name: cutter_verify
dot_lane: DOT-992 (verifier lane; the independent control opposite DOT-991)
purpose: the sole runtime write identity for the VERIFY phase
  (phases.verify_adapter). Its value is INDEPENDENCE — if the same DB
  principal both cut and verified, the verify attestation would not be an
  independent control. Distinct role = real separation of duty at the DB
  layer (strategy §2 rationale, OD-3 option B).
attributes (TARGET — not created here):
  LOGIN, NOSUPERUSER, NOCREATEDB, NOCREATEROLE, NOREPLICATION, NOBYPASSRLS,
  no group membership, scram-sha-256 password, CONNECTION LIMIT bounded
  (CD-9), search_path pinned to cutter_governance.
must_NOT: superuser, own objects, DDL, GRANT, membership in any role,
  write canonical_address_alias, touch public/other schemas, ever
  authenticate as / inherit cutter_ro / workflow_admin / directus /
  postgres, share a signing identity with the executor lane (D-3).
independence_invariant (G-VERIFY-SOD): a verify_result whose verifier
  signature shares identity with the checked executor signature is INVALID
  by design — enforced at the crypto/code layer; the distinct DB role and
  distinct secret are the supporting DB/process layers, not the sole
  control.

§2 — Phase Driven (from phases.verify() @689e53e)

verify():
  - reads cut_change_set + cut_change_set_affected_row + manifest pair +
    review_decision + executor dot_pair_signature to perform verification;
  - INSERT verify_result (sets verifier_signature_id; does NOT back-fill
    cut_change_set.verifier_signature_id — OD-6);
  - INSERT dot_pair_signature (verifier sig, DOT-992); chains
    prior_verify_result_id on re-verify (OD-5 append-only);
  - on force_fail / verify failure: INSERT a FORWARD compensating
    cut_change_set (+ cut_change_set_affected_row), INSERT an escalation
    decision_backlog_entry (+ its birth decision_backlog_history), then
    status CAS decision_backlog_entry → verify_failed_escalated;
  - on success: status CAS decision_backlog_entry → verified_complete +
    history. One verify txn (atomic per phase).
note: compensation is FORWARD (a new change set), never a DELETE/rollback
  of the original cut — preserves append-only.

§3 — cutter_verify Target Privileges (per table; APPLIED LATER)

legend: S=SELECT  I=INSERT  U(col)=column-scoped UPDATE  —=none
decision_backlog_entry ......... S, I, U(status)   (I = escalation entry on
                                                    fail; U(status) =
                                                    cut_applied→verified_
                                                    complete / verify_failed_
                                                    escalated only, code-gated)
decision_backlog_history ....... S, I              (status txn + escalation
                                                    birth row)
decision_backlog_dependency .... —                 (verify declares no deps)
decision_backlog_sweep_log ..... —                 (sweep is exec-only OD-SM-3)
manifest_envelope .............. S                  (read to verify)
manifest_unit_block ............ S                  (read to verify)
review_decision ................ S                  (read approved decision)
cut_change_set ................. S, I              (S=read cut under check;
                                                    I=FORWARD compensating
                                                    change set on failure)
cut_change_set_affected_row .... S, I              (compensating rows)
verify_result .................. S, I              (S to chain
                                                    prior_verify_result_id)
dot_pair_signature ............. S, I              (S=read executor sig to
                                                    verify + chain; I=verifier
                                                    sig DOT-992)
canonical_address_alias ........ —                 (OD-2 deferred; no grant)
schema-level: GRANT USAGE ON SCHEMA cutter_governance (no CREATE).
explicitly_NOT: DELETE, TRUNCATE, REFERENCES, TRIGGER, DDL, GRANT, any
  public/other-schema/observe-view/cutter_ro privilege, ALTER DEFAULT
  PRIVILEGES, any UPDATE on cut_change_set (it must NOT back-fill
  verifier_signature_id — OD-6 keeps that column NULL forever on the cut row).

§4 — SoD Tension: verify INSERTs cut_change_set (CD-8 / CD-10)

observation: granting cutter_verify INSERT on cut_change_set (for the
  FORWARD compensating change set on failure) means the verifier can create
  a change-set row. This slightly blurs "verify never cuts".
mitigation / rationale:
  - the compensating cut is the verifier's ESCALATION duty, not a normal
    CUT; it transitions to verify_failed_escalated (a non-success terminal-
    ish state), never to verified_complete;
  - it is FORWARD/append-only (new row), cannot alter or delete the
    original cut;
  - the executor signature on a compensating set is still DOT-991-keyed in
    the schema model — open decision CD-10: does the verifier sign the
    compensating set with DOT-992 (escalation authorship) or must a
    re-entered exec lane produce it? RECOMMEND v0.4: verifier authors the
    compensating set under DOT-992 as an escalation artefact, flagged
    distinctly; revisit if dry-run/real-adapter design shows a cleaner
    split. Surface to GPT.
alternative (CD-8): deny cutter_verify INSERT on cut_change_set and route
  compensation back through a re-triggered exec lane. Cleaner SoD, more
  orchestration complexity. RECOMMEND the verify-authored path for v0.4
  with explicit flagging; GPT decides.

§5 — Open Decisions Touching cutter_verify

CD-2  U(status) split (see exec doc) — verify owns only the post-cut
      transitions; code state-machine enforces.
CD-8  verify INSERT on cut_change_set vs route-back-to-exec.
CD-10 who signs the compensating change set (DOT-992 escalation vs DOT-991
      re-exec).
CD-1  column-scoped UPDATE grant for U(status) (same recommendation: yes).

§6 — Non-Scope

NOT here: CREATE ROLE cutter_verify, GRANT, password, .env key, login test,
  connection, dry-run. Specification only.

End of cutter_verify principal design (design only; not created).