dot-iu-cutter v0.1 — Operational Design (D1)

Date: 2026-05-15 Status: DESIGN DRAFT (Checkpoint 0 approved baseline) Baseline: rev5d Scope: DESIGN ONLY. No code, no DDL, no migration.

1. Purpose

Define the operating model of dot-iu-cutter v0.1 as a lifecycle, not a text splitter. Establish the three flows (Cut, Health/Correction, Upgrade) as the only operational surface, anchored on existing TAC/IU PG runtime and on C1A as binding segmentation law.

2. Scope

This deliverable defines:

Source resolution and command semantics
The MARK → REVIEW → CUT → VERIFY → REPORT state machine
Round-trip verification and rollback model
DOT-pair / dual-engine verification posture
Operability boundaries (single-command vs escalated path)
Compatibility with current TAC PG runtime

Out of scope (covered by other deliverables):

Manifest field schema → D2
Health signals / split-merge lifecycle → D3
Capability intake → D4
Decision backlog → D5
Assembly axis metadata → D6
Threading retrieval → D9, D11
Legal mapping → D10

3. Dependencies

rev5d §2, §3, §4, §6, §11 (forbidden scope)
C1A (Đ38-trien-khai) — segmentation law
Đ38 Text-as-Code — manifest as code, diffable
Đ37 — owner/reviewer/escalation
Đ32 — risk approval for non-trivial actions
Existing TAC schema: tac_logical_unit, tac_unit_version, tac_publication, fn_iu_create

4. Key Decisions

4.1 Three Flows Only

Flow	Trigger	Backbone
F1 — Cut	User command "Cắt luật A"	Resolve → Mark → Review → Cut → Verify → Report
F2 — Health / Correction	Health Report, complaint, signal	Observe → Detect → Review → Split/Merge/Edge/Thread/Context-Pack/NoAction → Verify → Report
F3 — Upgrade	Capability intake (TAC/KG progress)	New capability → Impact diff → Review → Patch policy/tool or NoImpact → Report

Any future capability that does not reduce to these flows is out of scope for v0.1.

Rationale: rev5d §6 and P12. Three flows preserve simplicity at the operation layer.

4.2 Decision/Execution Separation

MARK + REVIEW decide; CUT executes only from a PASSed manifest.
A failed REVIEW never invokes CUT.
CUT is mechanical: it does not re-decide boundaries.

Rationale: P2.

4.3 Source Resolution Contract (Q1, Q2, Q3)

Command form: Cắt luật A (or equivalent for non-law artifacts).

Resolution sequence:

Identify candidate source. Search KB by canonical address; if ambiguous, escalate to human (Đ37).
Determine source-of-truth class. KB markdown? TAC source? Publication snapshot? Authority defined by Đ24/Đ37/Đ32 constraints.
Collision check. Has this source already been cut? Query TAC for existing tac_logical_unit parented to this source revision.
History check. Prior MARK manifests, prior cuts, supersession chains.
Decision: proceed to MARK, or block (with reason) and route to Decision Backlog Registry (D5).

Schema gap noted: no current cut_history_index view linking source-path × revision × cut-result. Recorded as gap; do not invent.

4.4 MARK Stage

Input: source content + source revision.
Output: a manifest (full field set defined in D2).
Constraint: MARK does NOT mutate the source. Manifest is decision artifact only.
Manifest is PG-persisted as the SSOT (Đ38, P14). KB markdown export is a mirror.
C1A 3-question test, SR rules, OD-PILOT, NL1–NL4, length triggers applied here.

4.5 REVIEW Stage (Q8, Q9, Q10)

Default reviewer: independent AI review (separate context from MARK).
Human escalation triggers (Đ37): ambiguity, new vocabulary, suspected data loss, legal/governance change, high-risk per Đ32.
REVIEW checks: no-loss, no-overlap, source coverage, C1A compliance, semantic cohesion, title clarity, section_type/unit_kind/hierarchy/body policy/length flag validity, canonical parent, birth gate readiness.
REVIEW emits PASS / FAIL / NEEDS_HUMAN.

4.6 CUT Stage (Q11)

Pre-condition: manifest in PASS state.
Execution: deterministic, mechanical creation of tac_logical_unit rows + tac_unit_version via existing fn_iu_create gateway.
No re-decision of boundaries during CUT.
Birth-gate enforcement per Đ0-G applies to each new IU.

4.7 VERIFY Stage (Q12)

Axis-1 round-trip verification (mandatory): render units by publication/render order → compare with source revision → 0 drift = PASS.
Axis-2 sanity (advisory in v0.1, mandatory hooks): metadata coverage for semantic assembly (per D6).
Failure → automatic rollback (Q13).

4.8 ROLLBACK Model (Q14)

Each CUT execution records a rollback key (change-set ID referencing all rows created/modified).
Rollback is exact-key: reverses only that change-set.
No partial publish: VERIFY failure aborts the whole change-set before publication state.
Rollback events go to Decision Backlog Registry (D5) for governance trail.

4.9 REPORT Stage

Result envelope: PASS/FAIL/NEEDS_HUMAN, manifest reference, rollback key, drift count, reviewer identity, escalation links.
Reports are PG-persisted (Đ38, P14). KB markdown report is a mirror for human reading.

4.10 Single-Command Boundary (Q18)

Single command is allowed when: low-risk + manifest PASS + no human escalation triggers + no existing collision + C1A 3-question test passes deterministically.
Escalated path is required otherwise.
The user issues "Cắt luật A"; the system itself decides which path applies.

4.11 State Machine (Q19)

F1: idle → resolving → marking → reviewing → (cutting|escalated) → verifying → reporting → idle
                                       ↓
                                  failed → rollback → reporting → idle

F2 and F3 reuse the same state vocabulary with different entry triggers; see D3 and D4 respectively.

4.12 Beyond Laws (Q20)

The cutter applies to any document type. Differences are encoded in section_type / unit_kind vocabulary (per Đ24; no parallel taxonomy). The state machine does not change by document type.

4.13 Persistence (Q21)

Manifests, reviews, cuts, rollbacks, reports — all PG rows / JSONB in TAC schema.
Versioned, diffable, reviewable.
Markdown is documentation mirror, not authority.

Rationale: P14, rev5d §13.3.

4.14 DOT-Pair / Dual-Engine Verification (Q36)

The cutter operates as a DOT pair:

dot-iu-cutter (executor) — performs MARK/CUT/VERIFY.
dot-iu-cutter-verify (independent verifier) — runs the round-trip and metadata coverage tests in a separate context, signs the result.

Both must agree before REPORT emits PASS. Disagreement → NEEDS_HUMAN.

Rationale: Acceptance criterion 28 + S178 A+3 paired-DOT pattern.

4.15 TAC Runtime Compatibility (Q34)

The design does NOT propose schema rewrites. It assumes:

tac_logical_unit is the canonical unit row.
tac_unit_version carries versioning.
tac_publication carries publication membership.
fn_iu_create is the birth gateway.

All new fields required by this design surface are recorded as schema gaps (see §6) and routed to D7 (UOSL compat) and D10 (Legal Alignment) for governance.

4.16 PG-Driven Assembly (Q35)

CUT must produce PG rows and relations (not text artifacts) as primary outputs. Any markdown is a downstream view rendered from PG.

5. PG Storage per Object (Design Intent — No DDL)

Object	Target DB	Layer	Notes
Source resolution log	directus	Não	F1 audit; query-side
Manifest envelope	directus (TAC schema)	Kho	SSOT
Review decision	directus (TAC schema)	Não	reviewer, status, signals
Cut change-set	directus (TAC schema)	Kho	rows + rollback key
Verify result	directus (TAC schema)	Não	drift count, axis-2 metadata coverage
Report envelope	directus (TAC schema)	Não	mirrored to KB

6. Schema Gaps

cut_history_index — view linking source-path × revision × cut-result. Required for Q3 collision check.
rollback_key field — explicit per-change-set rollback identifier on TAC rows; current presence unclear.
reviewer_identity field — capture independent-review provenance; absent or unclear in current TAC schema.
DOT-pair signature record — dual-signature envelope for executor + verifier.
birth_gate_class field — distinguish base/draft/runtime per Đ0-G; required by §4.15.

Each gap is named, not solved. DDL deferred.

7. Law References

Surface	Law
Segmentation rules	C1A (Đ38-trien-khai)
Manifest as code	Đ38
Reviewer/escalation	Đ37
Risk approval	Đ32
Vocabulary discipline	Đ24
PG target location	Đ33 / Đ43
Birth gate	Đ0-G

8. Open Questions

Should dot-iu-cutter-verify be a separate code path or a re-invocation of the executor in verify mode? (Recommendation: separate path, paired-DOT pattern from S178 A+3.)
Where does the independent-AI reviewer run — same process or separate execution context? (Recommendation: separate context to preserve independence.)
How is collision-check authority resolved for cross-revision source updates? (Defer to D2 manifest contract.)

9. Coverage

Questions covered (primary): Q1, Q2, Q3, Q11, Q12, Q13, Q14, Q18, Q19, Q20, Q34, Q35. Questions covered (secondary): Q5, Q8, Q21, Q36.

Acceptance criteria covered:

1 (C1A inherit)
2 (3 flows)
5 (round-trip verify)
6 (rollback)
17 (no hardcoding to infra state)
18 (dogfood TAC)
26 (acknowledge current TAC)
28 (DOT-pair / dual-engine)

Schema gaps: 5 named (see §6).

Law dependencies: C1A, Đ24, Đ32, Đ33/Đ43, Đ37, Đ38, Đ0-G.

Open questions: 3 (see §8).

Law conflicts encountered: none. Proceed.