dot-iu-cutter v0.1 — Gate 2 Review: Core Cutter Correctness

Date: 2026-05-15
Reviewer: GPT
Review Gate: Gate 2 — Core Cutter Correctness
Files reviewed: D1 Operational Design, D2 Manifest and Operator Contract, D6 Assembly Axes Metadata Contract
Scope: Review only. No implementation, no migration, no PG mutation.

---

1. Verdict

gate_2_status: PASS_WITH_NOTES
core_cut_flow_blocker_found: false
manifest_contract_blocker_found: false
round_trip_blocker_found: false
rollback_design_blocker_found: false
ready_for_gate_3: true
ready_for_implementation: false

Gate 2 passes for design review purposes. The core cutter model is coherent: MARK/REVIEW/CUT are separated, CUT is deterministic from a PASSed manifest, round-trip verification is mandatory for Axis 1, rollback is explicitly change-set based, and metadata for both assembly axes is defined.

However, several design decisions remain open and must be closed before implementation planning.

---

2. What Was Checked

2.1 Core state model

Checked whether D1 defines a stable operational path:

Resolve → Mark → Review → Cut → Verify → Report

Result: PASS.

2.2 Decision/execution separation

Checked whether MARK/REVIEW decide and CUT only executes a PASSed manifest.

Result: PASS.

2.3 Manifest as execution contract

Checked whether D2 defines a sufficient manifest envelope and per-unit block contract.

Result: PASS_WITH_NOTES.

2.4 Round-trip verification

Checked whether Axis-1 reconstruction is mandatory and precise.

Result: PASS.

2.5 Rollback

Checked whether failed verification or failed cut has a rollback route.

Result: PASS_WITH_SCHEMA_GAPS.

2.6 Two assembly axes

Checked whether D6 defines enough metadata for both:

1. Document Reconstruction
2. Semantic Domain Assembly

Result: PASS_WITH_NOTES.

---

3. Findings

3.1 MARK / REVIEW / CUT separation is correctly designed

D1 and D2 both preserve the core rule:

• MARK emits a manifest.
• REVIEW independently evaluates the manifest.
• CUT executes only a PASSed manifest.
• CUT does not re-decide boundaries.

This satisfies the main correctness requirement.

3.2 Manifest contract is sufficiently rich

D2 defines both manifest-level fields and per-unit block fields. It covers:

• source identity and revision;
• source spans;
• title;
• section_type / unit_kind;
• parent / hierarchy;
• C1A rule references;
• 3-question test result;
• risk class;
• body source policy;
• render order;
• canonical address;
• edge readiness hooks.

This is sufficient for design review.

3.3 Round-trip verification is correctly mandatory for Axis 1

D1 and D6 require:

render units by publication/render order → compare with source revision → 0 drift = PASS

Any drift causes failure and rollback. This is the right gate for document reconstruction.

3.4 Axis-2 verification is intentionally advisory in v0.1

D6 defines semantic assembly verification hooks, but makes Axis-2 failure advisory in v0.1.

This is acceptable because semantic threading/retrieval instrumentation is not yet mature. However, the implementation plan must not silently drop Axis-2. It must preserve the hook and route failures/signals into health review.

3.5 Rollback design is conceptually correct but schema-dependent

D1 defines exact-key rollback using a cut change-set and rollback key. This is correct.

But implementation depends on schema gaps:

• cut_change_set;
• rollback_key;
• verify_result;
• report envelope;
• cut_history_index.

These must be handled in a separate migration/design phase before implementation.

3.6 DOT-pair / dual-engine verification is defined, but needs boundary clarification

D1 defines:

• dot-iu-cutter as executor;
• dot-iu-cutter-verify as independent verifier;
• both must agree before PASS report.

This satisfies the gate conceptually.

Clarification needed later: whether VERIFY inside executor is a precheck and dot-iu-cutter-verify is final co-sign, or whether only the verifier owns final VERIFY. This does not block Gate 2 but must be closed before implementation planning.

3.7 Per-unit block storage is intentionally unresolved

D2 leaves per-unit blocks as child rows vs JSONB array. That is acceptable at design review stage, but it is a P0/P1 decision before migration planning.

3.8 Two-axis metadata is sufficient as a design contract

D6 covers:

• Axis 1: source_path, source_revision, source_span, render_order, parent, canonical_address, publication_membership, body_source_policy.
• Axis 2: section_type, unit_kind, labels, semantic_role, candidate_edges, edge_readiness_notes, universal_edges compatibility, vector readiness, thread/lifecycle hints.

This is strong enough to support the later Semantic Thread and Retrieval layers.

---

4. Required Closures Before Implementation Planning

These do not block Gate 3 review, but they block implementation planning:

1. Decide per-unit block storage shape: child rows vs JSONB.
2. Define exact source-span unit: byte offsets, line ranges, AST spans, or canonical text span.
3. Define canonical form for round-trip comparison, including whitespace, headings, generated numbering, tables, code blocks.
4. Define rollback_key / cut_change_set schema in a separate migration design.
5. Clarify DOT-pair boundary: executor precheck vs verifier final co-sign.
6. Decide whether Axis-2 verification remains advisory for MVP or has any hard-fail cases.
7. Confirm canonical_address format and collision policy.
8. Confirm body_source_policy enum under Điều 24 vocabulary governance.

---

5. Gate 2 Conclusion

gate_2_result: PASS_WITH_NOTES
next_gate: Gate 3 — Semantic Thread + Retrieval
implementation_allowed: false

Proceed to Gate 3 review: D9 Cross-Temporal Semantic Threading, D11 Thread Retrieval and User Interaction, D3 Segmentation Health.