dot-iu-cutter v0.1 — Capability Intake and Upgrade Loop Design (D4)

Date: 2026-05-15 Status: DESIGN DRAFT Baseline: rev5d §7.H, §1 (positive recursion) Scope: DESIGN ONLY.

---

1. Purpose

Define how the cutter absorbs improvements in Text-as-Code (Đ38) and Knowledge Graph (Đ39), produces impact diffs or no-impact records, and avoids staleness through periodic self-review. This is the engine of positive recursion (P10): the cutter must improve its own next generation.

2. Scope

• Capability Intake records (TAC + KG)
• Impact diff and No-Impact record
• Cutter Self-Review
• Upgrade loop (F3) lifecycle
• Feedback from D9/D11 instrumentation to extraction quality

Out of scope: registry mechanics (D5); thread lifecycle (D9); retrieval-side data (D11).

3. Dependencies

• rev5d §1, §7.H, §13.3
• D1 F3 entry, D2 manifest model, D9 intake quality consumers, D11 retrieval consumers
• Đ32 (risk for tool/policy changes), Đ37 (governance), Đ38 (Text-as-Code), Đ39 (KG)

4. Key Decisions

4.1 F3 Backbone

New capability → Impact diff → Review → {Patch policy/tool | NoImpact} → Report

Entry: a new TAC capability, a new KG capability, a new feature flag, a new policy threshold, or a retrieval/health metric crossing a tuning threshold.

4.2 Capability Intake Record (Q26, Q27; criterion 12, 13)

A capability intake record is a versioned PG row capturing:

Field	Purpose
capability_id	Deterministic ID
capability_name	Short identifier
source_law	Đ38 / Đ39 / Đ44 / Đ24 / Đ32 / etc.
status	proposed / under_review / accepted / rejected / superseded
kind	tac_capability / kg_capability / policy / threshold / tool_revision
impact	Scope: which flows, units, threads, audience affected
required_change	What the cutter must do differently
risk	Đ32 class
owner	Đ37 role
decision	Approved / Rejected / Deferred + rationale
evidence	Signals / reports that motivated this intake
dependencies	Other intake records, decisions, laws
effective_from	When the change takes effect

Both TAC and KG intake use the same envelope; kind distinguishes.

4.3 Impact Diff (criterion 16)

For each capability intake, produce a structured impact diff:

Surface	Diff content
Manifest schema	Field additions / changes
REVIEW checklist	New rules / removed rules
Health signals	New signals / classification changes
Thread / retrieval	New evidence types / new metrics
Audience filters	New visibility flags
Đ24 vocabulary	New terms (require Đ24 governance)
Risk classifier	Rule changes per Đ32

If no surface is affected → No-Impact record explicitly documenting why this capability does not change current behavior. No-Impact is a first-class artifact (parallel to NoAction in D3).

Rationale: criterion 16; rev5d §7.H.

4.4 Cutter Self-Review (Q28; criterion 14)

Triggered by:

• Milestones: every N cuts, every Y days.
• Release cycles: each TAC/KG release.
• Patterns: clusters of health signals (D3) indicating systemic bias.
• Complaints: user-reported regressions.

Self-Review checks:

1. Are health signals trending up or down?
2. Are retrieval metrics (D11) meeting targets?
3. Have schema gaps been closed?
4. Have new capability intakes been integrated correctly?
5. Are recommended actions (D3) being followed or routinely overridden?
6. Are auto-accept thresholds (D9) appropriate per outcome data?

Self-Review emits a structured report, routed to Decision Backlog Registry (D5).

4.5 Upgrade Decision Authority (Đ32, Đ37)

Capability acceptance authority depends on risk:

Risk class	Authority
Low	AI review only
Standard	Council / human reviewer
High	Đ32 full approval; legal/governance involvement

Any change to: manifest schema, REVIEW checklist, Đ24 vocabulary, audience filter policy, auto-accept gate — is always at least Standard risk, never low.

4.6 Patch / NoImpact Output (Q26, Q27)

Once approved:

• Patch path: update policy/tool revision; bump tool_revision; record cut-over date; old manifests remain at their tool_revision; new cuts use new revision.
• NoImpact path: record the No-Impact decision; no operational change.

Both paths emit a Report (PG-persisted; KB mirror).

4.7 Positive Recursion Closure (P10; criterion 41)

Capability intake closes the positive-recursion loop:

F1/F2 produces signals → D3 health → D5 backlog
  → D4 capability intake (TAC/KG progress + tuning)
  → Approved patch → F1/F2 behave better next cycle
  → Improvement measurable via D11 retrieval metrics

Each intake record must cite the signals / decisions that motivated it; this preserves traceability across cycles.

4.8 Versioning and Diffability (Đ38)

Intake records are versioned and diffable like manifests (D2). Each intake's effect on the cutter is a delta over the previous tool revision.

4.9 Anti-Stale Rules

The cutter is considered stale when:

• Self-Review has not run within policy interval.
• Health signals show systemic decline without intake response.
• A TAC/KG capability has shipped but no intake record exists.
• A backlog decision past next_review_date has not been re-evaluated.

Anti-stale rules surface as health signals (D3) and Decision Backlog entries (D5).

4.10 v0.1 Scope Limits

v0.1 defines:

• Capability intake envelope.
• Impact diff structure.
• No-Impact record structure.
• Self-Review trigger + report.
• Anti-stale rules.

v0.1 does NOT:

• Implement automatic policy patching.
• Auto-deploy tool revisions.
• Build self-modifying code paths.

All upgrades go through governance review per Đ32/Đ37.

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

Object	Target DB	Layer	Notes
capability_intake_record	directus	Kho	SSOT
impact_diff	directus	Não	JSONB envelope
no_impact_record	directus	Kho	Explicit no-impact decision
cutter_self_review_report	directus	Kho	PG-persisted; KB mirror
tool_revision	directus	Não	Tracks active dot-iu-cutter revision

6. Schema Gaps

1. capability_intake_record table — no current generic table; may collide with existing decision_log if present.
2. impact_diff structure — JSONB schema undefined.
3. no_impact_record — distinct from impact diff with decision='no_impact'.
4. tool_revision — cutter version tracking field on manifest envelope (D2) needs persistence.
5. Self-Review cadence policy — where stored; possibly Đ37 governance config.
6. Intake → signal traceability — bidirectional link table between intake and source signals.

7. Law References

Surface	Law
Risk approval for upgrades	Đ32
Roles for intake review	Đ37
Text-as-Code capabilities	Đ38
KG capabilities	Đ39
Vocabulary for capability classification	Đ24
PG placement	Đ33 / Đ43

8. Open Questions

1. Self-Review cadence defaults — defer to policy / D5.
2. Should impact_diff be auto-generated from a structured catalog of cutter surfaces, or hand-authored? Recommendation: hand-authored in v0.1; auto-generation is a later capability intake.
3. How does tool revision propagate to verifier (DOT-pair)? Both must be at the same revision for valid co-sign; recommendation: enforce in REPORT validation.

9. Coverage

Questions covered (primary): Q26, Q27, Q28. Questions covered (secondary): Q23, Q41.

Acceptance criteria covered:

• 12 (TAC Capability Intake)
• 13 (KG Capability Intake)
• 14 (Cutter Self-Review)
• 16 (impact diff / no-impact record)
• 41 (TAC/KG progress feeds intake quality)

Schema gaps: 6 named (see §6).

Law dependencies: Đ24, Đ32, Đ33/Đ43, Đ37, Đ38, Đ39.

Open questions: 3 (see §8).

Law conflicts encountered: none.