dot-iu-cutter v0.1 — User Decision Pack

Date: 2026-05-15 Status: PLANNING — pending User decision Trigger: User PASS_DESIGN_WITH_NOTES + Review Control §3 (User Decision queue) Baseline: 11 design deliverables + 4 Gate reviews Scope: PLANNING ONLY. No code, no DDL, no migration, no PG mutation, no UI build.

---

1. Purpose

Tổng hợp 7 quyết định nằm trong thẩm quyền User cần chốt trước khi P0 migration design hoặc implementation planning được phép. Mỗi quyết định trình bày: options, recommendation, tradeoff, risk, default proposal nếu User không override.

Default proposal không tự áp dụng — chỉ áp dụng khi:

• User pass design phase, VÀ
• User không chọn override trong window thiết lập bởi governance closure, VÀ
• Default phù hợp với risk class hiện tại (Đ32).

Nếu Đ32 yêu cầu nâng risk class lên Standard+, default tự động được hold đến khi User confirm.

2. Hard Boundaries

no_code: true
no_ddl: true
no_migration: true
no_pg_mutation: true
no_user_data_changed: true
defaults_are_proposals_only: true
defaults_do_not_auto_apply_for_high_risk: true
implementation_planning_blocked: true

3. Decisions Summary

#	Decision	Affects	Risk
1	Auto-accept thresholds (semantic threading)	D9 implementation scope	Standard
2	Retrieval target values (thread_hit_rate, fallback_rate, etc.)	D11 metrics	Standard
3	Audience definitions (Employee / Partner / Customer / AI-Agent)	D11 access-control	High (security)
4	Backlog scope (cutter-only vs federated)	D5 scope	Standard
5	Per-unit block shape (child rows vs JSONB)	D2 PG model	Standard
6	wrong_audience_result handling	D11 access-control	High (security)
7	Context Pack caching policy	D11 retrieval performance	Low

---

4. Decision 1 — Auto-Accept Thresholds (Semantic Threading)

Question: Thread membership candidate có thể được auto-accept với threshold nào?

Source: D9 §4.4 (risk gate), Gate 3 §3.4 (PASS_WITH_POLICY_GAPS), D8 §9 item 8.

Constraints (binding):

• Auto-accept chỉ áp dụng khi 5 điều kiện đồng thời (D9 §4.4): low risk + ≥2 independent signals + no negative knowledge conflict + policy explicitly allows + thread/domain in allowlist.
• High-risk (legal/governance/code-impact) NEVER auto-accept — luôn route human reviewer.
• Đ32 risk gate is binding.

Options:

Option	Confidence threshold	Signal count	Domain allowlist
A. Conservative	≥ 0.85	≥ 3	starter ≤ 2 domains
B. Balanced (recommended)	≥ 0.75	≥ 2	starter ≤ 5 domains
C. Permissive	≥ 0.60	≥ 2	unrestricted
D. Hold (no auto-accept v0.1)	n/a	n/a	all manual review

Tradeoff:

• A: low false-positive, high reviewer load, slow enrichment.
• B: balanced; aligns with rev5d §13.1.5 spirit.
• C: fast enrichment, but high false-positive → noise + retrieval degradation → negative recursion.
• D: safest, but breaks positive recursion loop (P10) at v0.1 — every membership requires human, unsustainable.

Risk if wrong:

• Too permissive → semantic graph poisoning; wrong threads dominate retrieval; trust loss.
• Too conservative → reviewer fatigue; auto-accept never fires → P10 doesn't close.

Default proposal if User does not override:

• Option B (Balanced): confidence ≥ 0.75, signals ≥ 2, domain allowlist starts with 2 domains (e.g. birth_gate, segmentation) → expand via Decision Backlog as evidence accumulates.
• Re-evaluation cadence: every Self-Review cycle (cross-link Decision 8).
• All thresholds stored in PG policy table; tunable via D4 capability intake.

---

5. Decision 2 — Retrieval Target Values

Question: Initial maturity targets cho retrieval metrics (D11 §4.8)?

Source: D11 §4.8 (defined metrics + ambition), D8 §9 item 12.

Constraints:

• thread_hit_rate initial target ≥ 80%, strategic > 90% (rev5d §14.4) — text-mentioned but unconfirmed.
• All metrics require_instrumentation — actual measurement gated by D11 instrumentation phase.

Options for thread_hit_rate initial target:

Option	thread_hit_rate target	fallback_vector_rate ceiling	wrong_thread_rate ceiling
A. Strict	≥ 90%	≤ 5%	≤ 1%
B. Standard (recommended)	≥ 80%	≤ 15%	≤ 3%
C. Soft	≥ 70%	≤ 25%	≤ 5%

Tradeoff:

• A: forces high thread maturity before retrieval shippable; long lead time.
• B: matches rev5d §14.4 mature-target; realistic for v0.1+1 production.
• C: easy to hit but undermines value of thread-first retrieval.

Risk if wrong:

• Too strict → retrieval blocked indefinitely; AI/Agent falls back to vector silently.
• Too soft → metric ceremony without operational discipline; goals dilute.

Default proposal if User does not override:

• Option B: thread_hit_rate ≥ 80%, fallback ≤ 15%, wrong_thread ≤ 3%.
• Additional metrics: context_sufficiency_rate ≥ 70%, agent_extra_search_rate ≤ 20%, user_reject_rate ≤ 10%.
• Strategic ambition ≥ 90% thread_hit_rate (rev5d §14.4) deferred to v0.2.
• Initial values become Decision Backlog entries (kind = threshold_tune); re-evaluated every Self-Review.

---

6. Decision 3 — Audience Definitions (Employee / Partner / Customer / AI-Agent)

Question: Formal definition của 4 audience classes; data classification mapping; default visibility rule.

Source: D11 §4.10 (rev5d §14.2), Gate 3 §3.7 (PASS_WITH_IMPLEMENTATION_CLOSURES), G-5 governance gap.

Constraints:

• Audience scope is access-control, not filter (rev5d §14.2).
• wrong_audience_result is security event (Decision 6).
• Đ24 controls visibility / readiness / publication vocabulary — cross-law dependency.
• Đ32 risk approval for any audience policy change.

Decision components:

Component	Options
Audience classes	3 / 4 / 5
Default visibility	internal-only by default vs public-by-default
Classification scheme	binary (public/internal) vs tiered (public/partner/employee/internal/restricted)

Options:

Option	Classes	Default	Scheme
A. Conservative (recommended)	AI-Agent / Employee / Partner / Customer	internal-only	tiered 5-level
B. Minimal	AI-Agent / Internal / External	internal-only	binary
C. Broad	AI-Agent / Employee / Partner / Customer / Public-Anon	public-by-default-after-published	tiered 5-level

Tradeoff:

• A: clean 4-class model from rev5d §14.2; tiered scheme supports nuance; safest default.
• B: simpler but loses Partner/Customer distinction → retrieval can't differentiate.
• C: dangerous default — anything published becomes public unless explicitly restricted.

Risk if wrong:

• Wrong audience surface → information leakage → Đ32 high-risk security event.
• Audience semantics drift between teams → enforcement breaks.
• Đ24 vocabulary fragmentation if not ratified centrally.

Default proposal if User does not override:

• Option A: 4 audience classes (AI-Agent / Employee / Partner / Customer), default visibility = internal-only, tiered 5-level scheme (public / partner / employee / internal / restricted).
• Default readiness gate: published required for Customer & Partner.
• Đ24 ratification mandatory before any retrieval-side filter active.
• Cross-link with G-5 Access-Control Authority for policy ownership.
• This decision held at HIGH RISK class — default does NOT auto-apply; User must confirm or council must ratify.

---

7. Decision 4 — Backlog Scope (Cutter-Only vs Federated)

Question: Decision Backlog Registry chỉ phục vụ dot-iu-cutter, hay federated across all DOT pairs?

Source: D5 §8 (open question 3), Review Control §3 (User Decision queue).

Options:

Option	Scope	Tradeoff summary
A. Cutter-only (recommended for v0.1)	Only dot-iu-cutter producers	Bounded; simpler; aligned with v0.1 boundary
B. Federated	All DOT pairs share registry	Consolidated governance; cross-DOT cross-link
C. Hybrid	Cutter-only namespace, federated index	Compatibility now, federation later

Tradeoff:

• A: simpler PG schema; clear ownership; v0.1 scope honored. Risk: future federation requires migration.
• B: cross-DOT visibility now; harder governance; broader Đ37 ownership; v0.2+ feature creep.
• C: namespace-prefixed entries in same table; future-compat; slightly heavier schema.

Risk if wrong:

• A → later federation = schema migration + cross-DOT entry consolidation.
• B → over-scoped governance; D5 design over-engineered for v0.1.
• C → namespace ambiguity if conventions slip.

Default proposal if User does not override:

• Option A: cutter-only registry in v0.1. Federation deferred to a future capability intake (D4) when needed.
• Markdown mirror path: knowledge/dev/laws/dieu44-trien-khai/registry/.
• Federation upgrade path documented as future schema gap.

---

8. Decision 5 — Per-Unit Block Shape (Child Rows vs JSONB)

Question: Manifest per-unit blocks là child rows trong separate table hay JSONB array trên manifest_envelope?

Source: D2 §8 open question 1, D7 §8 open question 4, Gate 2 §3.7 (P0/P1 decision), P0 Schema §5.2 critical decision.

THIS IS A CRITICAL PRE-P0 DECISION — P0-2 migration design cannot start without it.

Options:

Option	Storage	Pros	Cons
A. Child rows (recommended)	Separate manifest_unit_block table; FK to envelope	Queryable per-field; index-friendly; joinable with tac_logical_unit; diff-friendly	More rows; FK overhead; envelope-block ordering managed explicitly
B. JSONB array	JSONB column on envelope	Flexible schema; single row per manifest version	Worse query perf for per-unit filter; harder to index axis-2 fields; diff at JSONB level
C. Hybrid	Core fields as child rows; JSONB for flexible extras	Best query perf for stable fields; flex for vocab churn	Schema split; two systems to maintain

Tradeoff:

• A: PG-native query power; Đ38 manifest-as-code diff disciplined; recommended for v0.1 production-quality.
• B: faster iteration during early UOSL flux; but axis-2 metadata (D6) requires per-field query → JSONB indexes get heavy.
• C: pragmatic but doubles schema complexity.

Risk if wrong:

• A → flexible vocab changes need migration; manageable via Đ24 ratification cadence.
• B → axis-2 queryability degrades at scale; retrieval/health analytics slow.
• C → maintenance burden; "core vs extra" boundary becomes political.

Default proposal if User does not override:

• Option A (Child rows). Justification:
  • Aligns with Đ38 manifest-as-code (diffability at row level).
  • Axis-2 metadata (D6) needs queryable section_type / unit_kind / candidate_edges.
  • PG-native (P14).
  • Diff materialized view (D2 §4.11) easier with row-level.
• Vocabulary churn risk mitigated by Đ24 ratification gates and capability intake (D4).
• Some flex fields (e.g. edge_readiness_notes, review_flags) can live as JSONB columns on child rows — hybrid only where flex is needed.

---

9. Decision 6 — wrong_audience_result Handling

Question: Khi retrieval trả về content sai audience scope, hành động là gì?

Source: D11 §4.10 (access-control guardrail), rev5d §14.2, Gate 3 §3.7, G-5 governance gap, D11 §8 open question 4.

Constraints (binding):

• wrong_audience_result IS a security event, not search-quality (rev5d §14.2).
• Cannot be silently downgraded to "noisy retrieval" signal.
• Đ32 escalation mandatory (high-risk class).

Options:

Option	Block response	Log event	Escalate	Auto-rollback
A. Block + Log + Escalate (recommended)	YES	YES	YES (Đ37 + G-5 Authority)	NO (no auto-rollback of response)
B. Block + Log only	YES	YES	NO	NO
C. Log only (response delivered)	NO	YES	YES	NO
D. Block + Log + Escalate + Auto-rollback	YES	YES	YES	YES

Tradeoff:

• A: stops leak; preserves audit; routes to security owner; doesn't try to "fix" the response — human handles.
• B: stops leak but no security routing — guardrail violated.
• C: leak proceeds — never acceptable for security event.
• D: auto-rollback of response (e.g. recall message) is risky — may cause additional leakage in attempt to recall; D11 §8 recommendation is NOT auto-rollback.

Risk if wrong:

• Wrong option → real information leakage at scale.
• Auto-rollback path may amplify exposure (recall messages flagged as "interesting" by recipients).

Default proposal if User does not override:

• Option A (Block + Log + Escalate, no auto-rollback).
• Block response at retrieval boundary; emit wrong_audience_result event; route to Đ37 escalation queue + Access-Control Authority (G-5).
• Audit trail: consumer_contract_log (D11 §5).
• Đ32 risk class: HIGH (always).
• This decision held at HIGH RISK class — default does NOT auto-apply; User must confirm or G-5 Authority must ratify.

---

10. Decision 7 — Context Pack Caching Policy

Question: Thread Context Pack có cache để giảm assembly cost hay luôn fresh-assemble?

Source: D11 §4.4 (Context Pack), D11 §8 open question 5, D8 §9 item 16.

Options:

Option	Strategy	Tradeoff
A. Always fresh (recommended for v0.1)	Build pack on every query	Always reflects latest thread state; no cache-invalidation bug
B. Cache with TTL	Pack cached N minutes	Faster; risk of stale results
C. Cache with invalidation hooks	Cache; invalidate on thread mutation events	Best perf; most complex (CDC hookup)
D. Hybrid	Cache stable portions; freshen volatile portions	Middle ground; design complexity

Tradeoff:

• A: simplest; matches D11 §8 recommendation; perf cost mitigated by Qdrant + thread centroid pre-computation.
• B: easy perf win but stale data dangerous in Health-correction flow (Split/Merge) — recently-changed thread returns old pack.
• C: best perf; requires CDC instrumentation (missing instrumentation #5) — not available v0.1.
• D: over-engineering at v0.1.

Risk if wrong:

• A → perf bottleneck at scale; mitigated by observability + later capability intake.
• B → stale pack after split/merge; user sees outdated thread.
• C → CDC dependency adds blocker.
• D → maintenance burden.

Default proposal if User does not override:

• Option A (Always fresh) for v0.1.
• Add caching as a future D4 capability intake when retrieval load justifies it AND CDC plumbing exists.
• thread_context_pack_cache table (D11 §5) reserved but unimplemented in v0.1.

---

11. Cross-Reference to Governance Closure Package

Decision	Governance gap cross-link
1. Auto-accept thresholds	G-1 (Threading roles) — Domain Owner + Council ratify
2. Retrieval targets	G-3 (Capability-intake reviewer) — Council via D4
3. Audience definitions	G-5 (Access-Control Authority) — Authority + Council
4. Backlog scope	G-2 (Backlog custodian) — Custodian implements
5. Per-unit block shape	G-3 (Capability-intake reviewer) — Council via D4
6. wrong_audience_result handling	G-5 (Access-Control Authority) — Authority + Đ32
7. Context Pack caching	G-3 — deferred to future intake

12. Cross-Reference to P0 Schema

Decision	P0 item unblocked
5. Per-unit block shape	P0-2 (manifest_envelope + manifest_unit_block) — CRITICAL
4. Backlog scope	P0-5 (decision_backlog_entry) — scope field
3. Audience definitions	P0-2 risk_class enum (cross-link), P3 audience_filter_policy
6. wrong_audience handling	P3 consumer_contract_log

13. Confirmation Block

decisions_needed: 7
defaults_proposed: 7
defaults_auto_apply_if_low_risk: 5 (Decisions 1, 2, 4, 5, 7)
defaults_held_for_explicit_confirm: 2 (Decisions 3 and 6 — HIGH RISK / security)
no_code: true
no_ddl: true
no_migration: true
no_pg_mutation: true
no_user_data_changed: true
implementation_planning_blocked: true

14. Status

package_status: READY_FOR_USER_DECISION
decisions_for_user: 7
decisions_marked_high_risk: 2 (audience_definitions, wrong_audience_handling)
defaults_proposed: all 7
defaults_held_pending_user_for_high_risk: true
cross_link_to_governance_closure: true
cross_link_to_p0_schema: true
implementation_unblock_dependency: 5 (Decisions 3, 5 critical; 1, 4, 6 important)

15. Coverage of Review Findings

Review source	Addressed in this pack
Review Control §3 (User Decision queue, 8 items)	7 of 8 (Decision 8 — Self-Review cadence — handled in G-3 closure scope)
Gate 3 §3.4 (auto-accept policy gap)	Decision 1
Gate 3 §3.7 (access-control implementation closures)	Decisions 3, 6
Gate 2 §3.7 (per-unit block shape)	Decision 5
D5 §8 (backlog scope question)	Decision 4
D11 §8 (retrieval open questions)	Decisions 2, 6, 7
D8 §9 (open questions consolidated)	7 of 26 user-facing items