dot-iu-cutter v0.5 — Operations-First Design Principle Addendum

Date: 2026-05-18 Authority: User directive + GPT operating ruling Scope: Applies to all future Information Unit / dot-iu-cutter design, authoring, command-review, and automation phases.

1. User directive

The user explicitly added the following operating principle:

principle_name: Operations-First Design
constitutional_reference: Nguyên tắc 14 / Hiến pháp vận hành nội bộ
user_wording_summary: >
  Khi thiết kế phải nhìn từ vận hành. Không nhìn kỹ thuật trước.

This addendum makes that principle binding for future phases.

---

2. Meaning

Design must begin from the desired operational experience, not from database tables, DDL, code, or implementation mechanics.

The target operational experience is:

target_experience:
  user_command: "Cắt Hiến pháp" or "Cắt 10 văn bản này"
  human_time: seconds_to_minutes
  agent_work: automated_stepwise_execution
  human_attention: exception_only
  report: concise PASS / FAIL / BLOCKED plus links to technical details

Technical mechanisms still matter, but they must serve this operational model.

---

3. Required design order

Future designs must follow this order:

design_order:
  1_operational_goal:
    question: Người vận hành muốn ra lệnh gì và nhận kết quả gì?

  2_workflow_state_machine:
    question: Quy trình gồm các state/gate nào? State nào auto, state nào cần duyệt?

  3_marking_and_review_model:
    question: Đánh dấu source/span/address/marker hàng loạt thế nào, review exception thế nào?

  4_safety_and_verification:
    question: Làm sao biết đúng/sai, rollback/compensation thế nào?

  5_data_schema_and_code:
    question: Cần bảng/code/index gì để phục vụ workflow trên?

Do not start future design from schema/code first unless the task is explicitly a low-level implementation task already derived from an approved operational workflow.

---

4. Batch Marking principle

The expensive human-facing work should be concentrated in marking and exception review.

batch_marking_principle:
  preferred_flow:
    - MARK batch of documents
    - produce mark_manifest
    - review exceptions / low-confidence items
    - approve manifest
    - CUT / VERIFY / STORE automatically
    - report final result

  batch_target:
    familiar_documents: 10_documents_per_batch_or_more
    overnight_mode: allowed_for_large_batches

  human_review_focus:
    - unknown_marker
    - low_confidence_span
    - duplicate_address
    - span_overlap
    - checksum_drift
    - grammar_mismatch
    - reconstruction_failure

After a mark manifest is approved, the rest should be automated unless a verification gate fails.

---

5. Modes of operation

Future workflow design should support at least these modes:

modes:
  quick_mode:
    use_case: source_family and grammar already ratified
    behavior: mark -> cut -> verify -> report
    human_gate: exception_only

  reviewed_mode:
    use_case: important or new source
    behavior: mark -> review_manifest -> cut -> verify -> report
    human_gate: manifest approval

  overnight_mode:
    use_case: larger batches
    behavior: run automatically, collect exceptions, no improvisation
    human_gate: morning exception report

---

6. Reporting principle

Reports must be layered so the user does not need to follow internal technical detail unless needed.

report_layers:
  operator_report:
    audience: user / operator
    content:
      - PASS / FAIL / BLOCKED
      - documents processed
      - items cut
      - exceptions
      - next action

  technical_report:
    audience: GPT / Agent / engineer
    content:
      - commands
      - catalog checks
      - checksums
      - rollback state
      - verification details

  closeout_report:
    audience: governance / KB
    content:
      - final state
      - artifacts produced
      - live data changes
      - deferred items

Future prompts should avoid requiring the user to read low-level logs when an operator-level summary is sufficient.

---

7. Implication for current Constitution path

The current path may continue because it is finishing first-time infrastructure and Constitution ratification. However, after the first Constitution dry-run/production evidence, a dedicated workflow design phase should be opened:

recommended_future_phase:
  name: v0_6_batch_marking_review_queue_and_cut_factory
  goal: turn manual phase-by-phase operation into one-command workflow
  outcome:
    - mark_manifest contract
    - review_queue contract
    - approved_manifest contract
    - batch workflow state machine
    - exception handling
    - operator report template

---

8. Binding rule for future Agent prompts

Future Agent prompts should include this rule when appropriate:

Design from operations first. Start with the intended operator workflow and exception model, then derive schema/code/commands. Do not lead with technical mechanism unless the phase is explicitly implementation-only.

Final status

status: OPERATIONS_FIRST_PRINCIPLE_ADDED_TO_DESIGN_AUTHORITY
applies_to_future_phases: true