diff --git a/crp/cap/ai/architecture/enterprise/ai-operating-model-architecture.meta.yaml b/crp/cap/ai/architecture/enterprise/ai-operating-model-architecture.meta.yaml
index 55386c0..1651a59 100644
--- a/crp/cap/ai/architecture/enterprise/ai-operating-model-architecture.meta.yaml
+++ b/crp/cap/ai/architecture/enterprise/ai-operating-model-architecture.meta.yaml
@@ -1,11 +1,6 @@
 id: ai-operating-model-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","togaf-adm-discipline","architecture-decision-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/architecture/governance/ai-evaluation-and-control-architecture.meta.yaml b/crp/cap/ai/architecture/governance/ai-evaluation-and-control-architecture.meta.yaml
index 5d84d58..6967164 100644
--- a/crp/cap/ai/architecture/governance/ai-evaluation-and-control-architecture.meta.yaml
+++ b/crp/cap/ai/architecture/governance/ai-evaluation-and-control-architecture.meta.yaml
@@ -1,11 +1,6 @@
 id: ai-evaluation-and-control-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","architecture-decision-rigor","architecture-compliance-review"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/architecture/solution/agentic-solution-architecture.meta.yaml b/crp/cap/ai/architecture/solution/agentic-solution-architecture.meta.yaml
index 30e5fae..c48f4da 100644
--- a/crp/cap/ai/architecture/solution/agentic-solution-architecture.meta.yaml
+++ b/crp/cap/ai/architecture/solution/agentic-solution-architecture.meta.yaml
@@ -1,11 +1,6 @@
 id: agentic-solution-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","architecture-decision-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/architecture/solution/grounding-and-context-architecture.meta.yaml b/crp/cap/ai/architecture/solution/grounding-and-context-architecture.meta.yaml
index 844d32e..0c7b1f2 100644
--- a/crp/cap/ai/architecture/solution/grounding-and-context-architecture.meta.yaml
+++ b/crp/cap/ai/architecture/solution/grounding-and-context-architecture.meta.yaml
@@ -1,11 +1,6 @@
 id: grounding-and-context-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","architecture-decision-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/architecture/solution/model-selection-and-boundary-fit.meta.yaml b/crp/cap/ai/architecture/solution/model-selection-and-boundary-fit.meta.yaml
index 0c0d2fd..118ba62 100644
--- a/crp/cap/ai/architecture/solution/model-selection-and-boundary-fit.meta.yaml
+++ b/crp/cap/ai/architecture/solution/model-selection-and-boundary-fit.meta.yaml
@@ -1,11 +1,6 @@
 id: model-selection-and-boundary-fit
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","strategic-fit"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/consulting/ai-adoption-roadmapping.meta.yaml b/crp/cap/ai/consulting/ai-adoption-roadmapping.meta.yaml
index 16e387e..f785693 100644
--- a/crp/cap/ai/consulting/ai-adoption-roadmapping.meta.yaml
+++ b/crp/cap/ai/consulting/ai-adoption-roadmapping.meta.yaml
@@ -1,11 +1,6 @@
 id: ai-adoption-roadmapping
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","portfolio-prioritization","strategy-narrative-structure"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/consulting/ai-center-of-excellence-design.meta.yaml b/crp/cap/ai/consulting/ai-center-of-excellence-design.meta.yaml
index 748f5ca..176a4e9 100644
--- a/crp/cap/ai/consulting/ai-center-of-excellence-design.meta.yaml
+++ b/crp/cap/ai/consulting/ai-center-of-excellence-design.meta.yaml
@@ -1,11 +1,6 @@
 id: ai-center-of-excellence-design
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","ai-operating-model-architecture","ai-adoption-roadmapping"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/consulting/ai-readiness-assessment.meta.yaml b/crp/cap/ai/consulting/ai-readiness-assessment.meta.yaml
index f55966e..6a05fbf 100644
--- a/crp/cap/ai/consulting/ai-readiness-assessment.meta.yaml
+++ b/crp/cap/ai/consulting/ai-readiness-assessment.meta.yaml
@@ -1,11 +1,6 @@
 id: ai-readiness-assessment
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","strategy-diagnosis","strategic-fit"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/consulting/ai-use-case-framing.meta.yaml b/crp/cap/ai/consulting/ai-use-case-framing.meta.yaml
index 887e9b1..a2b584d 100644
--- a/crp/cap/ai/consulting/ai-use-case-framing.meta.yaml
+++ b/crp/cap/ai/consulting/ai-use-case-framing.meta.yaml
@@ -1,11 +1,6 @@
 id: ai-use-case-framing
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","strategy-diagnosis"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/consulting/ai-value-risk-prioritization.meta.yaml b/crp/cap/ai/consulting/ai-value-risk-prioritization.meta.yaml
index e0c01e7..ddc60d2 100644
--- a/crp/cap/ai/consulting/ai-value-risk-prioritization.meta.yaml
+++ b/crp/cap/ai/consulting/ai-value-risk-prioritization.meta.yaml
@@ -1,11 +1,6 @@
 id: ai-value-risk-prioritization
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","portfolio-prioritization","strategic-fit"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/engineering/agent-loop-and-state-design.meta.yaml b/crp/cap/ai/engineering/agent-loop-and-state-design.meta.yaml
index ed8e54d..6d131aa 100644
--- a/crp/cap/ai/engineering/agent-loop-and-state-design.meta.yaml
+++ b/crp/cap/ai/engineering/agent-loop-and-state-design.meta.yaml
@@ -1,11 +1,6 @@
 id: agent-loop-and-state-design
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning","abstraction-boundary-discipline","change-impact-analysis"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/engineering/context-engineering-discipline.meta.yaml b/crp/cap/ai/engineering/context-engineering-discipline.meta.yaml
index 5b4c18e..212796b 100644
--- a/crp/cap/ai/engineering/context-engineering-discipline.meta.yaml
+++ b/crp/cap/ai/engineering/context-engineering-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: context-engineering-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning","clarification-before-guessing"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/engineering/evaluation-driven-iteration.meta.yaml b/crp/cap/ai/engineering/evaluation-driven-iteration.meta.yaml
index 4375a4b..e03259c 100644
--- a/crp/cap/ai/engineering/evaluation-driven-iteration.meta.yaml
+++ b/crp/cap/ai/engineering/evaluation-driven-iteration.meta.yaml
@@ -1,11 +1,6 @@
 id: evaluation-driven-iteration
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning","critical-peer-discipline"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/engineering/expert-continuity-briefing.meta.yaml b/crp/cap/ai/engineering/expert-continuity-briefing.meta.yaml
index b65b6f6..d6fc555 100644
--- a/crp/cap/ai/engineering/expert-continuity-briefing.meta.yaml
+++ b/crp/cap/ai/engineering/expert-continuity-briefing.meta.yaml
@@ -1,13 +1,16 @@
 id: expert-continuity-briefing
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-23T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning","statement-extraction-rigor","fact-interpretation-separation"]
 conflicts: []
 do_not_use_when: ["the task is a project or repository reboot handover rather than discussion continuity","simple summarization is sufficient and no receiving expert must continue the work directly"]
-distinguish_from: ["statement-extraction-rigor: extracts relevant source statements without building a continuity-ready expert brief","decision-structuring-discipline: structures decision artifacts instead of preserving full discussion continuity","context-engineering-discipline: shapes model context boundaries instead of producing a transfer brief for a receiving expert","project handover protocol/report: governs reboot and repository handover rather than discussion continuity"]
+distinguish_from:
+  - id: statement-extraction-rigor
+    boundary: "extracts relevant source statements without building a continuity-ready expert brief"
+  - id: decision-structuring-discipline
+    boundary: "structures decision artifacts instead of preserving full discussion continuity"
+  - id: context-engineering-discipline
+    boundary: "shapes model context boundaries instead of producing a transfer brief for a receiving expert"
+  - id: project handover protocol/report
+    boundary: "governs reboot and repository handover rather than discussion continuity"
 sources: []
diff --git a/crp/cap/ai/engineering/failure-mode-and-guardrail-design.meta.yaml b/crp/cap/ai/engineering/failure-mode-and-guardrail-design.meta.yaml
index 1ac3c16..030259b 100644
--- a/crp/cap/ai/engineering/failure-mode-and-guardrail-design.meta.yaml
+++ b/crp/cap/ai/engineering/failure-mode-and-guardrail-design.meta.yaml
@@ -1,11 +1,6 @@
 id: failure-mode-and-guardrail-design
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning","critical-peer-discipline","change-impact-analysis"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/engineering/prompt-contract-design.meta.yaml b/crp/cap/ai/engineering/prompt-contract-design.meta.yaml
index 5664c47..dd0d741 100644
--- a/crp/cap/ai/engineering/prompt-contract-design.meta.yaml
+++ b/crp/cap/ai/engineering/prompt-contract-design.meta.yaml
@@ -1,11 +1,6 @@
 id: prompt-contract-design
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning","interface-contract-first"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/engineering/tool-use-and-action-boundary-design.meta.yaml b/crp/cap/ai/engineering/tool-use-and-action-boundary-design.meta.yaml
index 9ce7cdd..4167bff 100644
--- a/crp/cap/ai/engineering/tool-use-and-action-boundary-design.meta.yaml
+++ b/crp/cap/ai/engineering/tool-use-and-action-boundary-design.meta.yaml
@@ -1,11 +1,6 @@
 id: tool-use-and-action-boundary-design
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning","interface-contract-first","change-impact-analysis"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/ai/index.md b/crp/cap/ai/index.md
index 752dc57..d18e07a 100644
--- a/crp/cap/ai/index.md
+++ b/crp/cap/ai/index.md
@@ -6,42 +6,42 @@ This index exposes the local capability selection surface for `ai`.
 
 ### Enterprise
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ai-operating-model-architecture` | `ai-operating-model-architecture.md` | Design an explicit AI operating model before scaling ownership, controls, or delivery expectations. | Use when an organization or multi-team initiative needs clear AI roles, lifecycle ownership, and control points. | `[]` | `[decision-gates, togaf-adm-discipline, architecture-decision-rigor]` | `[]` | `[]` |
+| `ai-operating-model-architecture` | `ai-operating-model-architecture.md` | Design an explicit AI operating model before scaling ownership, controls, or delivery expectations. | Use when an organization or multi-team initiative needs clear AI roles, lifecycle ownership, and control points. | `[]` | `[]` | `[decision-gates, togaf-adm-discipline, architecture-decision-rigor]` | `[]` |
 
 ### Governance
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ai-evaluation-and-control-architecture` | `ai-evaluation-and-control-architecture.md` | Define how AI behavior is evaluated, monitored, constrained, and interrupted across the runtime lifecycle. | Use when an AI solution needs explicit quality, safety, oversight, or escalation controls. | `[]` | `[decision-gates, architecture-decision-rigor, architecture-compliance-review]` | `[]` | `[]` |
+| `ai-evaluation-and-control-architecture` | `ai-evaluation-and-control-architecture.md` | Define how AI behavior is evaluated, monitored, constrained, and interrupted across the runtime lifecycle. | Use when an AI solution needs explicit quality, safety, oversight, or escalation controls. | `[]` | `[]` | `[decision-gates, architecture-decision-rigor, architecture-compliance-review]` | `[]` |
 
 ### Solution
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `agentic-solution-architecture` | `agentic-solution-architecture.md` | Decompose agentic solutions into bounded runtime concerns before implementation detail accumulates. | Use when designing or reviewing a system that reasons, invokes tools, persists state, or escalates actions. | `[]` | `[decision-gates, architecture-decision-rigor]` | `[]` | `[]` |
-| `grounding-and-context-architecture` | `grounding-and-context-architecture.md` | Design grounding and context boundaries so generated outputs remain traceable, bounded, and reviewable. | Use when a solution depends on retrieved knowledge, source material, memory, or other contextual inputs. | `[]` | `[decision-gates, architecture-decision-rigor]` | `[]` | `[]` |
-| `model-selection-and-boundary-fit` | `model-selection-and-boundary-fit.md` | Choose model boundaries that fit the actual problem, control needs, and fallback strategy. | Use when deciding whether and how AI capabilities should be introduced into a solution. | `[]` | `[decision-gates, strategic-fit]` | `[]` | `[]` |
+| `agentic-solution-architecture` | `agentic-solution-architecture.md` | Decompose agentic solutions into bounded runtime concerns before implementation detail accumulates. | Use when designing or reviewing a system that reasons, invokes tools, persists state, or escalates actions. | `[]` | `[]` | `[decision-gates, architecture-decision-rigor]` | `[]` |
+| `grounding-and-context-architecture` | `grounding-and-context-architecture.md` | Design grounding and context boundaries so generated outputs remain traceable, bounded, and reviewable. | Use when a solution depends on retrieved knowledge, source material, memory, or other contextual inputs. | `[]` | `[]` | `[decision-gates, architecture-decision-rigor]` | `[]` |
+| `model-selection-and-boundary-fit` | `model-selection-and-boundary-fit.md` | Choose model boundaries that fit the actual problem, control needs, and fallback strategy. | Use when deciding whether and how AI capabilities should be introduced into a solution. | `[]` | `[]` | `[decision-gates, strategic-fit]` | `[]` |
 
 ## Consulting
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ai-adoption-roadmapping` | `ai-adoption-roadmapping.md` | Stage AI adoption from pilot to scaled operation with explicit maturity and control gates. | Use when an organization needs a sequenced path from experimentation to governed scale. | `[]` | `[decision-gates, portfolio-prioritization, strategy-narrative-structure]` | `[]` | `[]` |
-| `ai-center-of-excellence-design` | `ai-center-of-excellence-design.md` | Design an AI enablement model that scales standards, support, and governance without becoming a delivery bottleneck. | Use when an organization needs a reusable structure for AI enablement across teams or business units. | `[]` | `[decision-gates, ai-operating-model-architecture, ai-adoption-roadmapping]` | `[]` | `[]` |
-| `ai-readiness-assessment` | `ai-readiness-assessment.md` | Assess whether an organization or initiative is ready to design, deploy, and control AI responsibly. | Use when deciding whether an AI initiative should start, scale, or pause. | `[]` | `[decision-gates, strategy-diagnosis, strategic-fit]` | `[]` | `[]` |
-| `ai-use-case-framing` | `ai-use-case-framing.md` | Frame AI initiatives around concrete problems, outcomes, and constraints before solution design begins. | Use when a team proposes an AI or agentic initiative and the business value or problem boundary is still fluid. | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` | `[]` |
-| `ai-value-risk-prioritization` | `ai-value-risk-prioritization.md` | Prioritize AI initiatives by balancing value, feasibility, readiness, risk, and control burden. | Use when multiple AI opportunities compete for investment, attention, or implementation capacity. | `[]` | `[decision-gates, portfolio-prioritization, strategic-fit]` | `[]` | `[]` |
+| `ai-adoption-roadmapping` | `ai-adoption-roadmapping.md` | Stage AI adoption from pilot to scaled operation with explicit maturity and control gates. | Use when an organization needs a sequenced path from experimentation to governed scale. | `[]` | `[]` | `[decision-gates, portfolio-prioritization, strategy-narrative-structure]` | `[]` |
+| `ai-center-of-excellence-design` | `ai-center-of-excellence-design.md` | Design an AI enablement model that scales standards, support, and governance without becoming a delivery bottleneck. | Use when an organization needs a reusable structure for AI enablement across teams or business units. | `[]` | `[]` | `[decision-gates, ai-operating-model-architecture, ai-adoption-roadmapping]` | `[]` |
+| `ai-readiness-assessment` | `ai-readiness-assessment.md` | Assess whether an organization or initiative is ready to design, deploy, and control AI responsibly. | Use when deciding whether an AI initiative should start, scale, or pause. | `[]` | `[]` | `[decision-gates, strategy-diagnosis, strategic-fit]` | `[]` |
+| `ai-use-case-framing` | `ai-use-case-framing.md` | Frame AI initiatives around concrete problems, outcomes, and constraints before solution design begins. | Use when a team proposes an AI or agentic initiative and the business value or problem boundary is still fluid. | `[]` | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` |
+| `ai-value-risk-prioritization` | `ai-value-risk-prioritization.md` | Prioritize AI initiatives by balancing value, feasibility, readiness, risk, and control burden. | Use when multiple AI opportunities compete for investment, attention, or implementation capacity. | `[]` | `[]` | `[decision-gates, portfolio-prioritization, strategic-fit]` | `[]` |
 
 ## Engineering
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `agent-loop-and-state-design` | `agent-loop-and-state-design.md` | Design agent loops and state transitions so work remains resumable, bounded, and interruptible. | Use when an AI system iterates across planning, tool use, review, or multi-step execution. | `[]` | `[deterministic-reasoning, abstraction-boundary-discipline, change-impact-analysis]` | `[]` | `[]` |
-| `context-engineering-discipline` | `context-engineering-discipline.md` | Shape context deliberately so the model receives the right information, in the right form, at the right boundary. | Use when model quality depends on retrieved material, memory, task state, or instruction layering. | `[]` | `[deterministic-reasoning, clarification-before-guessing]` | `[]` | `[]` |
-| `evaluation-driven-iteration` | `evaluation-driven-iteration.md` | Improve AI behavior through explicit evaluation evidence rather than taste, anecdotes, or prompt folklore. | Use when changing prompts, context design, workflows, models, or guardrails to improve outcome quality. | `[]` | `[deterministic-reasoning, critical-peer-discipline]` | `[]` | `[]` |
-| `expert-continuity-briefing` | `expert-continuity-briefing.md` | Transform a running discussion into a continuity brief that enables another expert or agent to continue the work without material loss of goal, reasoning state, decisions, evidence, or next actions. | Use when an ongoing discussion, advisory thread, or reasoning session must be transferred so another expert can continue without reconstructing the material context from scratch. | the task is a project or repository reboot handover rather than discussion continuity<br>simple summarization is sufficient and no receiving expert must continue the work directly | `[deterministic-reasoning, statement-extraction-rigor, fact-interpretation-separation]` | `[]` | statement-extraction-rigor: extracts relevant source statements without building a continuity-ready expert brief<br>decision-structuring-discipline: structures decision artifacts instead of preserving full discussion continuity<br>context-engineering-discipline: shapes model context boundaries instead of producing a transfer brief for a receiving expert<br>project handover protocol/report: governs reboot and repository handover rather than discussion continuity |
-| `failure-mode-and-guardrail-design` | `failure-mode-and-guardrail-design.md` | Design guardrails from concrete AI failure modes instead of generic caution language. | Use when an AI system can influence decisions, actions, data exposure, or downstream automation. | `[]` | `[deterministic-reasoning, critical-peer-discipline, change-impact-analysis]` | `[]` | `[]` |
-| `prompt-contract-design` | `prompt-contract-design.md` | Design prompts and instructions as bounded contracts rather than informal text craft. | Use when stable AI behavior depends on instruction structure, constraint enforcement, or output boundaries. | `[]` | `[deterministic-reasoning, interface-contract-first]` | `[]` | `[]` |
-| `tool-use-and-action-boundary-design` | `tool-use-and-action-boundary-design.md` | Separate reasoning from external actions so tool invocation stays controlled, reviewable, and permission-bounded. | Use when an AI system calls tools, writes data, triggers workflows, or acts on external systems. | `[]` | `[deterministic-reasoning, interface-contract-first, change-impact-analysis]` | `[]` | `[]` |
+| `agent-loop-and-state-design` | `agent-loop-and-state-design.md` | Design agent loops and state transitions so work remains resumable, bounded, and interruptible. | Use when an AI system iterates across planning, tool use, review, or multi-step execution. | `[]` | `[]` | `[deterministic-reasoning, abstraction-boundary-discipline, change-impact-analysis]` | `[]` |
+| `context-engineering-discipline` | `context-engineering-discipline.md` | Shape context deliberately so the model receives the right information, in the right form, at the right boundary. | Use when model quality depends on retrieved material, memory, task state, or instruction layering. | `[]` | `[]` | `[deterministic-reasoning, clarification-before-guessing]` | `[]` |
+| `evaluation-driven-iteration` | `evaluation-driven-iteration.md` | Improve AI behavior through explicit evaluation evidence rather than taste, anecdotes, or prompt folklore. | Use when changing prompts, context design, workflows, models, or guardrails to improve outcome quality. | `[]` | `[]` | `[deterministic-reasoning, critical-peer-discipline]` | `[]` |
+| `expert-continuity-briefing` | `expert-continuity-briefing.md` | Transform a running discussion into a continuity brief that enables another expert or agent to continue the work without material loss of goal, reasoning state, decisions, evidence, or next actions. | Use when an ongoing discussion, advisory thread, or reasoning session must be transferred so another expert can continue without reconstructing the material context from scratch. | the task is a project or repository reboot handover rather than discussion continuity<br>simple summarization is sufficient and no receiving expert must continue the work directly | statement-extraction-rigor: extracts relevant source statements without building a continuity-ready expert brief<br>decision-structuring-discipline: structures decision artifacts instead of preserving full discussion continuity<br>context-engineering-discipline: shapes model context boundaries instead of producing a transfer brief for a receiving expert<br>project handover protocol/report: governs reboot and repository handover rather than discussion continuity | `[deterministic-reasoning, statement-extraction-rigor, fact-interpretation-separation]` | `[]` |
+| `failure-mode-and-guardrail-design` | `failure-mode-and-guardrail-design.md` | Design guardrails from concrete AI failure modes instead of generic caution language. | Use when an AI system can influence decisions, actions, data exposure, or downstream automation. | `[]` | `[]` | `[deterministic-reasoning, critical-peer-discipline, change-impact-analysis]` | `[]` |
+| `prompt-contract-design` | `prompt-contract-design.md` | Design prompts and instructions as bounded contracts rather than informal text craft. | Use when stable AI behavior depends on instruction structure, constraint enforcement, or output boundaries. | `[]` | `[]` | `[deterministic-reasoning, interface-contract-first]` | `[]` |
+| `tool-use-and-action-boundary-design` | `tool-use-and-action-boundary-design.md` | Separate reasoning from external actions so tool invocation stays controlled, reviewable, and permission-bounded. | Use when an AI system calls tools, writes data, triggers workflows, or acts on external systems. | `[]` | `[]` | `[deterministic-reasoning, interface-contract-first, change-impact-analysis]` | `[]` |
diff --git a/crp/cap/analysis/index.md b/crp/cap/analysis/index.md
index 93ac8f9..0ae1be7 100644
--- a/crp/cap/analysis/index.md
+++ b/crp/cap/analysis/index.md
@@ -4,27 +4,27 @@ This index exposes the local capability selection surface for `analysis`.
 
 ## Organization
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `function-deduplication` | `function-deduplication.md` | Remove duplicate function statements without losing meaningful distinctions. | Use when a normalized function set may contain duplicate or near-duplicate function statements. | `[]` | `[function-extraction]` | `[]` | `[]` |
-| `function-extraction` | `function-extraction.md` | Extract normalized business or organizational functions from source material. | Use when source material contains business or organizational work statements that must be normalized into functions. | `[]` | `[statement-extraction-rigor]` | `[]` | `[]` |
-| `function-ownership-allocation` | `function-ownership-allocation.md` | Allocate clear accountability for each materially relevant function without collapsing ownership into informal group responsibility. | Use when assigning accountability for materially relevant functions across teams, roles, or organizational units. | `[]` | `[function-extraction]` | `[]` | `[]` |
-| `value-stream-organization-design` | `value-stream-organization-design.md` | Design target organizations around end-to-end value flow instead of accidental internal boundaries. | Use when designing or reviewing organizational structures against end-to-end value flow. | `[]` | `[function-extraction, function-deduplication, function-ownership-allocation]` | `[]` | `[]` |
+| `function-deduplication` | `function-deduplication.md` | Remove duplicate function statements without losing meaningful distinctions. | Use when a normalized function set may contain duplicate or near-duplicate function statements. | `[]` | `[]` | `[function-extraction]` | `[]` |
+| `function-extraction` | `function-extraction.md` | Extract normalized business or organizational functions from source material. | Use when source material contains business or organizational work statements that must be normalized into functions. | `[]` | `[]` | `[statement-extraction-rigor]` | `[]` |
+| `function-ownership-allocation` | `function-ownership-allocation.md` | Allocate clear accountability for each materially relevant function without collapsing ownership into informal group responsibility. | Use when assigning accountability for materially relevant functions across teams, roles, or organizational units. | `[]` | `[]` | `[function-extraction]` | `[]` |
+| `value-stream-organization-design` | `value-stream-organization-design.md` | Design target organizations around end-to-end value flow instead of accidental internal boundaries. | Use when designing or reviewing organizational structures against end-to-end value flow. | `[]` | `[]` | `[function-extraction, function-deduplication, function-ownership-allocation]` | `[]` |
 
 ## Role Assessment
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `comparison-dimension-discipline` | `comparison-dimension-discipline.md` | Ensure that comparative analysis uses stable, decision-relevant dimensions instead of ad hoc framing. | Use when comparing alternatives, roles, proposals, or candidate options that need a stable evaluation frame. | `[]` | `[statement-extraction-rigor, fact-interpretation-separation]` | `[]` | `[]` |
-| `evidence-typing-discipline` | `evidence-typing-discipline.md` | Keep material claims traceable by marking whether they are directly observed or inferred. | Use when materially relevant claims, findings, or recommendations depend on source evidence or observed outputs. | `[]` | `[fact-interpretation-separation]` | `[]` | `[]` |
-| `fact-interpretation-separation` | `fact-interpretation-separation.md` | Separate observed statements from inference, synthesis, and judgment. | Use when deriving interpretations, conclusions, or recommendations from source statements or observed evidence. | `[]` | `[statement-extraction-rigor]` | `[]` | `[]` |
-| `statement-extraction-rigor` | `statement-extraction-rigor.md` | Extract all materially relevant statements from source material without collapsing distinct claims. | Use when extracting materially relevant statements from documents, transcripts, requirements, or review artifacts. | `[]` | `[deterministic-reasoning]` | `[]` | `[]` |
+| `comparison-dimension-discipline` | `comparison-dimension-discipline.md` | Ensure that comparative analysis uses stable, decision-relevant dimensions instead of ad hoc framing. | Use when comparing alternatives, roles, proposals, or candidate options that need a stable evaluation frame. | `[]` | `[]` | `[statement-extraction-rigor, fact-interpretation-separation]` | `[]` |
+| `evidence-typing-discipline` | `evidence-typing-discipline.md` | Keep material claims traceable by marking whether they are directly observed or inferred. | Use when materially relevant claims, findings, or recommendations depend on source evidence or observed outputs. | `[]` | `[]` | `[fact-interpretation-separation]` | `[]` |
+| `fact-interpretation-separation` | `fact-interpretation-separation.md` | Separate observed statements from inference, synthesis, and judgment. | Use when deriving interpretations, conclusions, or recommendations from source statements or observed evidence. | `[]` | `[]` | `[statement-extraction-rigor]` | `[]` |
+| `statement-extraction-rigor` | `statement-extraction-rigor.md` | Extract all materially relevant statements from source material without collapsing distinct claims. | Use when extracting materially relevant statements from documents, transcripts, requirements, or review artifacts. | `[]` | `[]` | `[deterministic-reasoning]` | `[]` |
 
 ## Specification
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ambiguity-detection` | `ambiguity-detection.md` | Detect terms or clauses that allow materially different interpretations. | Use when reviewing text, specifications, contracts, or guidance that may allow materially different readings. | `[]` | `[statement-extraction-rigor]` | `[]` | `[]` |
-| `contradiction-detection` | `contradiction-detection.md` | Detect when two statements cannot both be true within the same scope and time frame. | Use when reviewing statements, requirements, or contracts for claims that may not both hold in the same scope and time frame. | `[]` | `[fact-interpretation-separation]` | `[]` | `[]` |
-| `overlap-detection` | `overlap-detection.md` | Detect materially relevant duplication of responsibility, output, or control intent. | Use when reviewing responsibilities, outputs, or control boundaries for possible duplication. | `[]` | `[statement-extraction-rigor]` | `[]` | `[]` |
-| `semantic-conflict-detection` | `semantic-conflict-detection.md` | Detect materially incompatible intent, behavior, or governance semantics even when statements are not literally contradictory. | Use when reviewing policies, processes, models, or interfaces that may be materially incompatible without being literally contradictory. | `[]` | `[fact-interpretation-separation, contradiction-detection]` | `[]` | `[]` |
+| `ambiguity-detection` | `ambiguity-detection.md` | Detect terms or clauses that allow materially different interpretations. | Use when reviewing text, specifications, contracts, or guidance that may allow materially different readings. | `[]` | `[]` | `[statement-extraction-rigor]` | `[]` |
+| `contradiction-detection` | `contradiction-detection.md` | Detect when two statements cannot both be true within the same scope and time frame. | Use when reviewing statements, requirements, or contracts for claims that may not both hold in the same scope and time frame. | `[]` | `[]` | `[fact-interpretation-separation]` | `[]` |
+| `overlap-detection` | `overlap-detection.md` | Detect materially relevant duplication of responsibility, output, or control intent. | Use when reviewing responsibilities, outputs, or control boundaries for possible duplication. | `[]` | `[]` | `[statement-extraction-rigor]` | `[]` |
+| `semantic-conflict-detection` | `semantic-conflict-detection.md` | Detect materially incompatible intent, behavior, or governance semantics even when statements are not literally contradictory. | Use when reviewing policies, processes, models, or interfaces that may be materially incompatible without being literally contradictory. | `[]` | `[]` | `[fact-interpretation-separation, contradiction-detection]` | `[]` |
diff --git a/crp/cap/analysis/organization/function-deduplication.meta.yaml b/crp/cap/analysis/organization/function-deduplication.meta.yaml
index bafe577..36c97d9 100644
--- a/crp/cap/analysis/organization/function-deduplication.meta.yaml
+++ b/crp/cap/analysis/organization/function-deduplication.meta.yaml
@@ -1,11 +1,6 @@
 id: function-deduplication
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["function-extraction"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/organization/function-extraction.meta.yaml b/crp/cap/analysis/organization/function-extraction.meta.yaml
index 2ad82c7..454ab91 100644
--- a/crp/cap/analysis/organization/function-extraction.meta.yaml
+++ b/crp/cap/analysis/organization/function-extraction.meta.yaml
@@ -1,11 +1,6 @@
 id: function-extraction
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["statement-extraction-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/organization/function-ownership-allocation.meta.yaml b/crp/cap/analysis/organization/function-ownership-allocation.meta.yaml
index 5cce4b2..1d5057e 100644
--- a/crp/cap/analysis/organization/function-ownership-allocation.meta.yaml
+++ b/crp/cap/analysis/organization/function-ownership-allocation.meta.yaml
@@ -1,11 +1,6 @@
 id: function-ownership-allocation
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["function-extraction"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/organization/value-stream-organization-design.meta.yaml b/crp/cap/analysis/organization/value-stream-organization-design.meta.yaml
index b42103f..66c8b68 100644
--- a/crp/cap/analysis/organization/value-stream-organization-design.meta.yaml
+++ b/crp/cap/analysis/organization/value-stream-organization-design.meta.yaml
@@ -1,11 +1,6 @@
 id: value-stream-organization-design
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["function-extraction","function-deduplication","function-ownership-allocation"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/role-assessment/comparison-dimension-discipline.meta.yaml b/crp/cap/analysis/role-assessment/comparison-dimension-discipline.meta.yaml
index 4f58f66..6f478a7 100644
--- a/crp/cap/analysis/role-assessment/comparison-dimension-discipline.meta.yaml
+++ b/crp/cap/analysis/role-assessment/comparison-dimension-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: comparison-dimension-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["statement-extraction-rigor","fact-interpretation-separation"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/role-assessment/evidence-typing-discipline.meta.yaml b/crp/cap/analysis/role-assessment/evidence-typing-discipline.meta.yaml
index b1721ab..3a530b6 100644
--- a/crp/cap/analysis/role-assessment/evidence-typing-discipline.meta.yaml
+++ b/crp/cap/analysis/role-assessment/evidence-typing-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: evidence-typing-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["fact-interpretation-separation"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/role-assessment/fact-interpretation-separation.meta.yaml b/crp/cap/analysis/role-assessment/fact-interpretation-separation.meta.yaml
index 30c6d54..d214198 100644
--- a/crp/cap/analysis/role-assessment/fact-interpretation-separation.meta.yaml
+++ b/crp/cap/analysis/role-assessment/fact-interpretation-separation.meta.yaml
@@ -1,11 +1,6 @@
 id: fact-interpretation-separation
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["statement-extraction-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/role-assessment/statement-extraction-rigor.meta.yaml b/crp/cap/analysis/role-assessment/statement-extraction-rigor.meta.yaml
index 22a7a5a..1ce16a5 100644
--- a/crp/cap/analysis/role-assessment/statement-extraction-rigor.meta.yaml
+++ b/crp/cap/analysis/role-assessment/statement-extraction-rigor.meta.yaml
@@ -1,11 +1,6 @@
 id: statement-extraction-rigor
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/specification/ambiguity-detection.meta.yaml b/crp/cap/analysis/specification/ambiguity-detection.meta.yaml
index 0a82087..ed881d7 100644
--- a/crp/cap/analysis/specification/ambiguity-detection.meta.yaml
+++ b/crp/cap/analysis/specification/ambiguity-detection.meta.yaml
@@ -1,11 +1,6 @@
 id: ambiguity-detection
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["statement-extraction-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/specification/contradiction-detection.meta.yaml b/crp/cap/analysis/specification/contradiction-detection.meta.yaml
index 12ead53..c8ffd9e 100644
--- a/crp/cap/analysis/specification/contradiction-detection.meta.yaml
+++ b/crp/cap/analysis/specification/contradiction-detection.meta.yaml
@@ -1,11 +1,6 @@
 id: contradiction-detection
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["fact-interpretation-separation"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/specification/overlap-detection.meta.yaml b/crp/cap/analysis/specification/overlap-detection.meta.yaml
index cf44c10..cbf394d 100644
--- a/crp/cap/analysis/specification/overlap-detection.meta.yaml
+++ b/crp/cap/analysis/specification/overlap-detection.meta.yaml
@@ -1,11 +1,6 @@
 id: overlap-detection
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["statement-extraction-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/analysis/specification/semantic-conflict-detection.meta.yaml b/crp/cap/analysis/specification/semantic-conflict-detection.meta.yaml
index 174d5d0..4b500ad 100644
--- a/crp/cap/analysis/specification/semantic-conflict-detection.meta.yaml
+++ b/crp/cap/analysis/specification/semantic-conflict-detection.meta.yaml
@@ -1,11 +1,6 @@
 id: semantic-conflict-detection
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["fact-interpretation-separation","contradiction-detection"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/architecture/domain/application-integration-architecture.meta.yaml b/crp/cap/architecture/domain/application-integration-architecture.meta.yaml
index a2e8903..14533e8 100644
--- a/crp/cap/architecture/domain/application-integration-architecture.meta.yaml
+++ b/crp/cap/architecture/domain/application-integration-architecture.meta.yaml
@@ -1,15 +1,16 @@
 id: application-integration-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["segment-architecture-stewardship","architecture-decision-rigor"]
 conflicts: []
 do_not_use_when: ["when the problem is primarily data governance or technology platform architecture","when one concrete solution change needs realization governance more than domain architecture"]
-distinguish_from: ["data-governance-architecture","technology-platform-architecture","solution-realization-architecture"]
+distinguish_from:
+  - id: data-governance-architecture
+    boundary: "TBD"
+  - id: technology-platform-architecture
+    boundary: "TBD"
+  - id: solution-realization-architecture
+    boundary: "TBD"
 sources:
   - title: "Architecture Roles and Skills - Segment Architect (Business and Technical)"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/domain/business-service-architecture.meta.yaml b/crp/cap/architecture/domain/business-service-architecture.meta.yaml
index e5c65bb..f7e3440 100644
--- a/crp/cap/architecture/domain/business-service-architecture.meta.yaml
+++ b/crp/cap/architecture/domain/business-service-architecture.meta.yaml
@@ -1,15 +1,18 @@
 id: business-service-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["segment-architecture-stewardship","capability-map-governance"]
 conflicts: []
 do_not_use_when: ["when data, application, or technology-domain concerns dominate the architecture problem","when the task is generic strategic planning without a business-architecture boundary"]
-distinguish_from: ["capability-map-governance","data-governance-architecture","application-integration-architecture","technology-platform-architecture"]
+distinguish_from:
+  - id: capability-map-governance
+    boundary: "TBD"
+  - id: data-governance-architecture
+    boundary: "TBD"
+  - id: application-integration-architecture
+    boundary: "TBD"
+  - id: technology-platform-architecture
+    boundary: "TBD"
 sources:
   - title: "Architecture Roles and Skills - Segment Architect (Business and Technical)"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/domain/data-governance-architecture.meta.yaml b/crp/cap/architecture/domain/data-governance-architecture.meta.yaml
index afcade2..03a69b8 100644
--- a/crp/cap/architecture/domain/data-governance-architecture.meta.yaml
+++ b/crp/cap/architecture/domain/data-governance-architecture.meta.yaml
@@ -1,15 +1,16 @@
 id: data-governance-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["segment-architecture-stewardship"]
 conflicts: []
 do_not_use_when: ["when the main concern is application-service decomposition rather than data governance and lifecycle control","when the task is low-level schema hygiene without data-landscape architecture implications"]
-distinguish_from: ["application-integration-architecture","technology-platform-architecture","domain-modeling-rigor"]
+distinguish_from:
+  - id: application-integration-architecture
+    boundary: "TBD"
+  - id: technology-platform-architecture
+    boundary: "TBD"
+  - id: domain-modeling-rigor
+    boundary: "TBD"
 sources:
   - title: "Architecture Roles and Skills - Segment Architect (Business and Technical)"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/domain/segment-architecture-stewardship.meta.yaml b/crp/cap/architecture/domain/segment-architecture-stewardship.meta.yaml
index 91e1655..d7ffb0f 100644
--- a/crp/cap/architecture/domain/segment-architecture-stewardship.meta.yaml
+++ b/crp/cap/architecture/domain/segment-architecture-stewardship.meta.yaml
@@ -1,15 +1,16 @@
 id: segment-architecture-stewardship
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["togaf-adm-discipline","baseline-target-gap-analysis"]
 conflicts: []
 do_not_use_when: ["when the task is enterprise-wide cross-segment integration rather than stewardship of one segment","when the task is detailed realization of one concrete solution rather than segment evolution"]
-distinguish_from: ["enterprise-architecture-integration","solution-realization-architecture","capability-map-governance"]
+distinguish_from:
+  - id: enterprise-architecture-integration
+    boundary: "TBD"
+  - id: solution-realization-architecture
+    boundary: "TBD"
+  - id: capability-map-governance
+    boundary: "TBD"
 sources:
   - title: "Architecture Roles and Skills - Segment Architect (Business and Technical)"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/domain/technology-platform-architecture.meta.yaml b/crp/cap/architecture/domain/technology-platform-architecture.meta.yaml
index 836b13a..000111a 100644
--- a/crp/cap/architecture/domain/technology-platform-architecture.meta.yaml
+++ b/crp/cap/architecture/domain/technology-platform-architecture.meta.yaml
@@ -1,15 +1,16 @@
 id: technology-platform-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["segment-architecture-stewardship"]
 conflicts: []
 do_not_use_when: ["when the dominant concern is application-service architecture or data governance rather than platform and infrastructure design","when the task is an operational runbook without architecture-level platform decisions"]
-distinguish_from: ["application-integration-architecture","data-governance-architecture","solution-realization-architecture"]
+distinguish_from:
+  - id: application-integration-architecture
+    boundary: "TBD"
+  - id: data-governance-architecture
+    boundary: "TBD"
+  - id: solution-realization-architecture
+    boundary: "TBD"
 sources:
   - title: "Architecture Roles and Skills - Segment Architect (Business and Technical)"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/enterprise/architecture-practice-leadership.meta.yaml b/crp/cap/architecture/enterprise/architecture-practice-leadership.meta.yaml
index abc18fd..c1918ee 100644
--- a/crp/cap/architecture/enterprise/architecture-practice-leadership.meta.yaml
+++ b/crp/cap/architecture/enterprise/architecture-practice-leadership.meta.yaml
@@ -1,15 +1,16 @@
 id: architecture-practice-leadership
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["togaf-adm-discipline","strategic-fit"]
 conflicts: []
 do_not_use_when: ["when the task is detailed segment or solution design rather than architecture-practice leadership","when a conformance verdict is needed rather than leadership, sponsorship, or mandate creation"]
-distinguish_from: ["enterprise-architecture-integration","architecture-compliance-review","strategic-fit"]
+distinguish_from:
+  - id: enterprise-architecture-integration
+    boundary: "TBD"
+  - id: architecture-compliance-review
+    boundary: "TBD"
+  - id: strategic-fit
+    boundary: "TBD"
 sources:
   - title: "Architecture Roles and Skills - Chief Architect"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/enterprise/capability-map-governance.meta.yaml b/crp/cap/architecture/enterprise/capability-map-governance.meta.yaml
index a1bcee2..2c0c8fd 100644
--- a/crp/cap/architecture/enterprise/capability-map-governance.meta.yaml
+++ b/crp/cap/architecture/enterprise/capability-map-governance.meta.yaml
@@ -1,15 +1,14 @@
 id: capability-map-governance
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["togaf-adm-discipline"]
 conflicts: []
 do_not_use_when: ["when the task is detailed process, org-chart, or application mapping rather than stable capability architecture","when segment or solution realization questions dominate over capability-map control logic"]
-distinguish_from: ["business-service-architecture","enterprise-architecture-integration"]
+distinguish_from:
+  - id: business-service-architecture
+    boundary: "TBD"
+  - id: enterprise-architecture-integration
+    boundary: "TBD"
 sources:
   - title: "The TOGAF Standard, 10th Edition"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/enterprise/enterprise-architecture-integration.meta.yaml b/crp/cap/architecture/enterprise/enterprise-architecture-integration.meta.yaml
index ffd0389..ff951a0 100644
--- a/crp/cap/architecture/enterprise/enterprise-architecture-integration.meta.yaml
+++ b/crp/cap/architecture/enterprise/enterprise-architecture-integration.meta.yaml
@@ -1,15 +1,16 @@
 id: enterprise-architecture-integration
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["togaf-adm-discipline","capability-map-governance"]
 conflicts: []
 do_not_use_when: ["when scope is only one segment or one concrete solution","when the main need is executive sponsorship and practice mandate rather than enterprise integration"]
-distinguish_from: ["architecture-practice-leadership","segment-architecture-stewardship","transition-architecture-planning"]
+distinguish_from:
+  - id: architecture-practice-leadership
+    boundary: "TBD"
+  - id: segment-architecture-stewardship
+    boundary: "TBD"
+  - id: transition-architecture-planning
+    boundary: "TBD"
 sources:
   - title: "Architecture Roles and Skills - Enterprise Architect"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/enterprise/togaf-adm-discipline.meta.yaml b/crp/cap/architecture/enterprise/togaf-adm-discipline.meta.yaml
index c320c52..9c0dc7b 100644
--- a/crp/cap/architecture/enterprise/togaf-adm-discipline.meta.yaml
+++ b/crp/cap/architecture/enterprise/togaf-adm-discipline.meta.yaml
@@ -1,15 +1,14 @@
 id: togaf-adm-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates"]
 conflicts: []
 do_not_use_when: ["when the task is a local modeling or compliance question that does not depend on TOGAF lifecycle framing","when role-specific architecture leadership or realization design is needed more than phase-aware discipline"]
-distinguish_from: ["enterprise-architecture-integration","transition-architecture-planning"]
+distinguish_from:
+  - id: enterprise-architecture-integration
+    boundary: "TBD"
+  - id: transition-architecture-planning
+    boundary: "TBD"
 sources:
   - title: "The TOGAF Standard, 10th Edition"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/governance/architecture-compliance-review.meta.yaml b/crp/cap/architecture/governance/architecture-compliance-review.meta.yaml
index 7dbdc21..1bd95cf 100644
--- a/crp/cap/architecture/governance/architecture-compliance-review.meta.yaml
+++ b/crp/cap/architecture/governance/architecture-compliance-review.meta.yaml
@@ -1,15 +1,16 @@
 id: architecture-compliance-review
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["togaf-adm-discipline","archimate-cross-layer-consistency"]
 conflicts: []
 do_not_use_when: ["when the task is to create architecture direction rather than evaluate conformance against approved principles, standards, or decisions","when no architecture baseline exists to review against"]
-distinguish_from: ["architecture-practice-leadership","enterprise-architecture-integration","solution-realization-architecture"]
+distinguish_from:
+  - id: architecture-practice-leadership
+    boundary: "TBD"
+  - id: enterprise-architecture-integration
+    boundary: "TBD"
+  - id: solution-realization-architecture
+    boundary: "TBD"
 sources:
   - title: "The TOGAF Standard, 10th Edition"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/index.md b/crp/cap/architecture/index.md
index 7e88652..3539bc9 100644
--- a/crp/cap/architecture/index.md
+++ b/crp/cap/architecture/index.md
@@ -4,40 +4,40 @@ This index exposes the local capability selection surface for `architecture`.
 
 ## Domain
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `application-integration-architecture` | `application-integration-architecture.md` | Shape application-domain architecture through explicit service boundaries, interoperability, and application landscape evolution. | Use when a segment or domain architecture task is application-focused and must govern application responsibilities, interfaces, or integration patterns. | when the problem is primarily data governance or technology platform architecture<br>when one concrete solution change needs realization governance more than domain architecture | `[segment-architecture-stewardship, architecture-decision-rigor]` | `[]` | data-governance-architecture<br>technology-platform-architecture<br>solution-realization-architecture |
-| `business-service-architecture` | `business-service-architecture.md` | Shape business-domain architecture through explicit capability, service, process, organization, and metric relationships. | Use when a segment or domain architecture task is business-focused and must govern business capabilities and services rather than only technical assets. | when data, application, or technology-domain concerns dominate the architecture problem<br>when the task is generic strategic planning without a business-architecture boundary | `[segment-architecture-stewardship, capability-map-governance]` | `[]` | capability-map-governance<br>data-governance-architecture<br>application-integration-architecture<br>technology-platform-architecture |
-| `data-governance-architecture` | `data-governance-architecture.md` | Shape data-domain architecture through explicit governance, integration, migration, protection, and lifecycle control. | Use when a segment or domain architecture task is data-focused and must govern data ownership, flow, protection, integration, or migration across the landscape. | when the main concern is application-service decomposition rather than data governance and lifecycle control<br>when the task is low-level schema hygiene without data-landscape architecture implications | `[segment-architecture-stewardship]` | `[]` | application-integration-architecture<br>technology-platform-architecture<br>domain-modeling-rigor |
-| `segment-architecture-stewardship` | `segment-architecture-stewardship.md` | Shape and govern one business or technical segment as a coherent architecture responsibility instead of a loose collection of systems. | Use when a business or technical segment must be translated from strategy into governed architecture change, policies, standards, and segment evolution. | when the task is enterprise-wide cross-segment integration rather than stewardship of one segment<br>when the task is detailed realization of one concrete solution rather than segment evolution | `[togaf-adm-discipline, baseline-target-gap-analysis]` | `[]` | enterprise-architecture-integration<br>solution-realization-architecture<br>capability-map-governance |
-| `technology-platform-architecture` | `technology-platform-architecture.md` | Shape technology-domain architecture through explicit platform, network, device, infrastructure, and interoperability decisions. | Use when a segment or domain architecture task is technology-focused and must govern platform standards, infrastructure boundaries, or technical interoperability. | when the dominant concern is application-service architecture or data governance rather than platform and infrastructure design<br>when the task is an operational runbook without architecture-level platform decisions | `[segment-architecture-stewardship]` | `[]` | application-integration-architecture<br>data-governance-architecture<br>solution-realization-architecture |
+| `application-integration-architecture` | `application-integration-architecture.md` | Shape application-domain architecture through explicit service boundaries, interoperability, and application landscape evolution. | Use when a segment or domain architecture task is application-focused and must govern application responsibilities, interfaces, or integration patterns. | when the problem is primarily data governance or technology platform architecture<br>when one concrete solution change needs realization governance more than domain architecture | data-governance-architecture: TBD<br>technology-platform-architecture: TBD<br>solution-realization-architecture: TBD | `[segment-architecture-stewardship, architecture-decision-rigor]` | `[]` |
+| `business-service-architecture` | `business-service-architecture.md` | Shape business-domain architecture through explicit capability, service, process, organization, and metric relationships. | Use when a segment or domain architecture task is business-focused and must govern business capabilities and services rather than only technical assets. | when data, application, or technology-domain concerns dominate the architecture problem<br>when the task is generic strategic planning without a business-architecture boundary | capability-map-governance: TBD<br>data-governance-architecture: TBD<br>application-integration-architecture: TBD<br>technology-platform-architecture: TBD | `[segment-architecture-stewardship, capability-map-governance]` | `[]` |
+| `data-governance-architecture` | `data-governance-architecture.md` | Shape data-domain architecture through explicit governance, integration, migration, protection, and lifecycle control. | Use when a segment or domain architecture task is data-focused and must govern data ownership, flow, protection, integration, or migration across the landscape. | when the main concern is application-service decomposition rather than data governance and lifecycle control<br>when the task is low-level schema hygiene without data-landscape architecture implications | application-integration-architecture: TBD<br>technology-platform-architecture: TBD<br>domain-modeling-rigor: TBD | `[segment-architecture-stewardship]` | `[]` |
+| `segment-architecture-stewardship` | `segment-architecture-stewardship.md` | Shape and govern one business or technical segment as a coherent architecture responsibility instead of a loose collection of systems. | Use when a business or technical segment must be translated from strategy into governed architecture change, policies, standards, and segment evolution. | when the task is enterprise-wide cross-segment integration rather than stewardship of one segment<br>when the task is detailed realization of one concrete solution rather than segment evolution | enterprise-architecture-integration: TBD<br>solution-realization-architecture: TBD<br>capability-map-governance: TBD | `[togaf-adm-discipline, baseline-target-gap-analysis]` | `[]` |
+| `technology-platform-architecture` | `technology-platform-architecture.md` | Shape technology-domain architecture through explicit platform, network, device, infrastructure, and interoperability decisions. | Use when a segment or domain architecture task is technology-focused and must govern platform standards, infrastructure boundaries, or technical interoperability. | when the dominant concern is application-service architecture or data governance rather than platform and infrastructure design<br>when the task is an operational runbook without architecture-level platform decisions | application-integration-architecture: TBD<br>data-governance-architecture: TBD<br>solution-realization-architecture: TBD | `[segment-architecture-stewardship]` | `[]` |
 
 ## Enterprise
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `architecture-practice-leadership` | `architecture-practice-leadership.md` | Create the strategic, governance, and sponsorship conditions for an effective architecture practice across the enterprise. | Use when architecture work needs executive alignment, practice leadership, or cross-domain mandate before downstream enterprise, segment, or solution work can succeed. | when the task is detailed segment or solution design rather than architecture-practice leadership<br>when a conformance verdict is needed rather than leadership, sponsorship, or mandate creation | `[togaf-adm-discipline, strategic-fit]` | `[]` | enterprise-architecture-integration<br>architecture-compliance-review<br>strategic-fit |
-| `capability-map-governance` | `capability-map-governance.md` | Use capability maps as stable architecture control artifacts rather than as proxies for projects or org charts. | Use when creating, reviewing, or governing capability maps as architecture control artifacts. | when the task is detailed process, org-chart, or application mapping rather than stable capability architecture<br>when segment or solution realization questions dominate over capability-map control logic | `[togaf-adm-discipline]` | `[]` | business-service-architecture<br>enterprise-architecture-integration |
-| `enterprise-architecture-integration` | `enterprise-architecture-integration.md` | Create enterprise-wide integration, interoperability, governance, and roadmap coherence across multiple architecture segments. | Use when architecture work must align principles, policies, roadmaps, or interoperability across multiple segments instead of one local domain or one solution. | when scope is only one segment or one concrete solution<br>when the main need is executive sponsorship and practice mandate rather than enterprise integration | `[togaf-adm-discipline, capability-map-governance]` | `[]` | architecture-practice-leadership<br>segment-architecture-stewardship<br>transition-architecture-planning |
-| `togaf-adm-discipline` | `togaf-adm-discipline.md` | Keep architecture work phase-aware, decision-oriented, and traceable to the intent of TOGAF ADM. | Use when architecture work claims TOGAF alignment or needs phase-aware architecture discipline. | when the task is a local modeling or compliance question that does not depend on TOGAF lifecycle framing<br>when role-specific architecture leadership or realization design is needed more than phase-aware discipline | `[decision-gates]` | `[]` | enterprise-architecture-integration<br>transition-architecture-planning |
+| `architecture-practice-leadership` | `architecture-practice-leadership.md` | Create the strategic, governance, and sponsorship conditions for an effective architecture practice across the enterprise. | Use when architecture work needs executive alignment, practice leadership, or cross-domain mandate before downstream enterprise, segment, or solution work can succeed. | when the task is detailed segment or solution design rather than architecture-practice leadership<br>when a conformance verdict is needed rather than leadership, sponsorship, or mandate creation | enterprise-architecture-integration: TBD<br>architecture-compliance-review: TBD<br>strategic-fit: TBD | `[togaf-adm-discipline, strategic-fit]` | `[]` |
+| `capability-map-governance` | `capability-map-governance.md` | Use capability maps as stable architecture control artifacts rather than as proxies for projects or org charts. | Use when creating, reviewing, or governing capability maps as architecture control artifacts. | when the task is detailed process, org-chart, or application mapping rather than stable capability architecture<br>when segment or solution realization questions dominate over capability-map control logic | business-service-architecture: TBD<br>enterprise-architecture-integration: TBD | `[togaf-adm-discipline]` | `[]` |
+| `enterprise-architecture-integration` | `enterprise-architecture-integration.md` | Create enterprise-wide integration, interoperability, governance, and roadmap coherence across multiple architecture segments. | Use when architecture work must align principles, policies, roadmaps, or interoperability across multiple segments instead of one local domain or one solution. | when scope is only one segment or one concrete solution<br>when the main need is executive sponsorship and practice mandate rather than enterprise integration | architecture-practice-leadership: TBD<br>segment-architecture-stewardship: TBD<br>transition-architecture-planning: TBD | `[togaf-adm-discipline, capability-map-governance]` | `[]` |
+| `togaf-adm-discipline` | `togaf-adm-discipline.md` | Keep architecture work phase-aware, decision-oriented, and traceable to the intent of TOGAF ADM. | Use when architecture work claims TOGAF alignment or needs phase-aware architecture discipline. | when the task is a local modeling or compliance question that does not depend on TOGAF lifecycle framing<br>when role-specific architecture leadership or realization design is needed more than phase-aware discipline | enterprise-architecture-integration: TBD<br>transition-architecture-planning: TBD | `[decision-gates]` | `[]` |
 
 ## Governance
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `architecture-compliance-review` | `architecture-compliance-review.md` | Review target states and solution directions against architecture principles, standards, and approved decisions. | Use when reviewing target states, architectures, or solution directions against approved architecture principles and standards. | when the task is to create architecture direction rather than evaluate conformance against approved principles, standards, or decisions<br>when no architecture baseline exists to review against | `[togaf-adm-discipline, archimate-cross-layer-consistency]` | `[]` | architecture-practice-leadership<br>enterprise-architecture-integration<br>solution-realization-architecture |
+| `architecture-compliance-review` | `architecture-compliance-review.md` | Review target states and solution directions against architecture principles, standards, and approved decisions. | Use when reviewing target states, architectures, or solution directions against approved architecture principles and standards. | when the task is to create architecture direction rather than evaluate conformance against approved principles, standards, or decisions<br>when no architecture baseline exists to review against | architecture-practice-leadership: TBD<br>enterprise-architecture-integration: TBD<br>solution-realization-architecture: TBD | `[togaf-adm-discipline, archimate-cross-layer-consistency]` | `[]` |
 
 ## Modeling
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `archimate-cross-layer-consistency` | `archimate-cross-layer-consistency.md` | Keep ArchiMate models consistent across business, application, data, and technology layers. | Use when reviewing ArchiMate models across multiple layers, views, or lifecycle updates. | when the main task is choosing viewpoints rather than validating cross-layer model consistency | `[archimate-viewpoint-selection]` | `[]` | archimate-viewpoint-selection |
-| `archimate-viewpoint-selection` | `archimate-viewpoint-selection.md` | Select modeling viewpoints by stakeholder question and decision need, not by template habit. | Use when selecting or reviewing ArchiMate views for stakeholder communication or design decisions. | when the relevant problem is cross-layer inconsistency rather than viewpoint fit for a stakeholder question | `[togaf-adm-discipline]` | `[]` | archimate-cross-layer-consistency |
+| `archimate-cross-layer-consistency` | `archimate-cross-layer-consistency.md` | Keep ArchiMate models consistent across business, application, data, and technology layers. | Use when reviewing ArchiMate models across multiple layers, views, or lifecycle updates. | when the main task is choosing viewpoints rather than validating cross-layer model consistency | archimate-viewpoint-selection: TBD | `[archimate-viewpoint-selection]` | `[]` |
+| `archimate-viewpoint-selection` | `archimate-viewpoint-selection.md` | Select modeling viewpoints by stakeholder question and decision need, not by template habit. | Use when selecting or reviewing ArchiMate views for stakeholder communication or design decisions. | when the relevant problem is cross-layer inconsistency rather than viewpoint fit for a stakeholder question | archimate-cross-layer-consistency: TBD | `[togaf-adm-discipline]` | `[]` |
 
 ## Solution
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `baseline-target-gap-analysis` | `baseline-target-gap-analysis.md` | Make baseline, target, and gap statements comparable before solution design proceeds. | Use when comparing current and target states before solution design or transition planning. | when no baseline or target state can be stated yet<br>when the main task is sequencing transition states rather than comparing states | `[togaf-adm-discipline]` | `[]` | transition-architecture-planning<br>solution-realization-architecture |
-| `solution-realization-architecture` | `solution-realization-architecture.md` | Shape a concrete solution change into an interoperable topology and implementable transition architecture without losing architectural intent. | Use when a concrete solution must be specified, staged, and governed from requirements through target roadmap and implementation change. | when the task is enterprise or segment governance without a concrete solution scope<br>when the task is generic project planning or handover without architecture realization content | `[baseline-target-gap-analysis, transition-architecture-planning, architecture-decision-rigor]` | `[]` | segment-architecture-stewardship<br>transition-architecture-planning<br>agentic-solution-architecture |
-| `transition-architecture-planning` | `transition-architecture-planning.md` | Stage architecture evolution through deliberate intermediate states instead of assuming one-step transformation. | Use when architecture evolution must be staged through deliberate intermediate states. | when baseline and target have not been compared yet<br>when the task is a single target-state compliance check rather than staged change design | `[baseline-target-gap-analysis]` | `[]` | baseline-target-gap-analysis<br>solution-realization-architecture |
+| `baseline-target-gap-analysis` | `baseline-target-gap-analysis.md` | Make baseline, target, and gap statements comparable before solution design proceeds. | Use when comparing current and target states before solution design or transition planning. | when no baseline or target state can be stated yet<br>when the main task is sequencing transition states rather than comparing states | transition-architecture-planning: TBD<br>solution-realization-architecture: TBD | `[togaf-adm-discipline]` | `[]` |
+| `solution-realization-architecture` | `solution-realization-architecture.md` | Shape a concrete solution change into an interoperable topology and implementable transition architecture without losing architectural intent. | Use when a concrete solution must be specified, staged, and governed from requirements through target roadmap and implementation change. | when the task is enterprise or segment governance without a concrete solution scope<br>when the task is generic project planning or handover without architecture realization content | segment-architecture-stewardship: TBD<br>transition-architecture-planning: TBD<br>agentic-solution-architecture: TBD | `[baseline-target-gap-analysis, transition-architecture-planning, architecture-decision-rigor]` | `[]` |
+| `transition-architecture-planning` | `transition-architecture-planning.md` | Stage architecture evolution through deliberate intermediate states instead of assuming one-step transformation. | Use when architecture evolution must be staged through deliberate intermediate states. | when baseline and target have not been compared yet<br>when the task is a single target-state compliance check rather than staged change design | baseline-target-gap-analysis: TBD<br>solution-realization-architecture: TBD | `[baseline-target-gap-analysis]` | `[]` |
diff --git a/crp/cap/architecture/modeling/archimate-cross-layer-consistency.meta.yaml b/crp/cap/architecture/modeling/archimate-cross-layer-consistency.meta.yaml
index c0ef64e..e3456b5 100644
--- a/crp/cap/architecture/modeling/archimate-cross-layer-consistency.meta.yaml
+++ b/crp/cap/architecture/modeling/archimate-cross-layer-consistency.meta.yaml
@@ -1,15 +1,12 @@
 id: archimate-cross-layer-consistency
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["archimate-viewpoint-selection"]
 conflicts: []
 do_not_use_when: ["when the main task is choosing viewpoints rather than validating cross-layer model consistency"]
-distinguish_from: ["archimate-viewpoint-selection"]
+distinguish_from:
+  - id: archimate-viewpoint-selection
+    boundary: "TBD"
 sources:
   - title: "The TOGAF Standard, 10th Edition"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/modeling/archimate-viewpoint-selection.meta.yaml b/crp/cap/architecture/modeling/archimate-viewpoint-selection.meta.yaml
index afa9bf1..ecf1663 100644
--- a/crp/cap/architecture/modeling/archimate-viewpoint-selection.meta.yaml
+++ b/crp/cap/architecture/modeling/archimate-viewpoint-selection.meta.yaml
@@ -1,15 +1,12 @@
 id: archimate-viewpoint-selection
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["togaf-adm-discipline"]
 conflicts: []
 do_not_use_when: ["when the relevant problem is cross-layer inconsistency rather than viewpoint fit for a stakeholder question"]
-distinguish_from: ["archimate-cross-layer-consistency"]
+distinguish_from:
+  - id: archimate-cross-layer-consistency
+    boundary: "TBD"
 sources:
   - title: "The TOGAF Standard, 10th Edition"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/solution/baseline-target-gap-analysis.meta.yaml b/crp/cap/architecture/solution/baseline-target-gap-analysis.meta.yaml
index 4750285..bb88dd8 100644
--- a/crp/cap/architecture/solution/baseline-target-gap-analysis.meta.yaml
+++ b/crp/cap/architecture/solution/baseline-target-gap-analysis.meta.yaml
@@ -1,15 +1,14 @@
 id: baseline-target-gap-analysis
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["togaf-adm-discipline"]
 conflicts: []
 do_not_use_when: ["when no baseline or target state can be stated yet","when the main task is sequencing transition states rather than comparing states"]
-distinguish_from: ["transition-architecture-planning","solution-realization-architecture"]
+distinguish_from:
+  - id: transition-architecture-planning
+    boundary: "TBD"
+  - id: solution-realization-architecture
+    boundary: "TBD"
 sources:
   - title: "The TOGAF Standard, 10th Edition"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/solution/solution-realization-architecture.meta.yaml b/crp/cap/architecture/solution/solution-realization-architecture.meta.yaml
index 25adada..2fc69a8 100644
--- a/crp/cap/architecture/solution/solution-realization-architecture.meta.yaml
+++ b/crp/cap/architecture/solution/solution-realization-architecture.meta.yaml
@@ -1,15 +1,16 @@
 id: solution-realization-architecture
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["baseline-target-gap-analysis","transition-architecture-planning","architecture-decision-rigor"]
 conflicts: []
 do_not_use_when: ["when the task is enterprise or segment governance without a concrete solution scope","when the task is generic project planning or handover without architecture realization content"]
-distinguish_from: ["segment-architecture-stewardship","transition-architecture-planning","agentic-solution-architecture"]
+distinguish_from:
+  - id: segment-architecture-stewardship
+    boundary: "TBD"
+  - id: transition-architecture-planning
+    boundary: "TBD"
+  - id: agentic-solution-architecture
+    boundary: "TBD"
 sources:
   - title: "Architecture Roles and Skills - Solution Architect"
     organization: "The Open Group"
diff --git a/crp/cap/architecture/solution/transition-architecture-planning.meta.yaml b/crp/cap/architecture/solution/transition-architecture-planning.meta.yaml
index 0abe260..2366cf5 100644
--- a/crp/cap/architecture/solution/transition-architecture-planning.meta.yaml
+++ b/crp/cap/architecture/solution/transition-architecture-planning.meta.yaml
@@ -1,15 +1,14 @@
 id: transition-architecture-planning
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["baseline-target-gap-analysis"]
 conflicts: []
 do_not_use_when: ["when baseline and target have not been compared yet","when the task is a single target-state compliance check rather than staged change design"]
-distinguish_from: ["baseline-target-gap-analysis","solution-realization-architecture"]
+distinguish_from:
+  - id: baseline-target-gap-analysis
+    boundary: "TBD"
+  - id: solution-realization-architecture
+    boundary: "TBD"
 sources:
   - title: "The TOGAF Standard, 10th Edition"
     organization: "The Open Group"
diff --git a/crp/cap/engineering/index.md b/crp/cap/engineering/index.md
index 92d8c75..e2033de 100644
--- a/crp/cap/engineering/index.md
+++ b/crp/cap/engineering/index.md
@@ -4,14 +4,14 @@ This index exposes the local capability selection surface for `engineering`.
 
 ## Principles
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `abstraction-boundary-discipline` | `abstraction-boundary-discipline.md` | Align module and service boundaries with change, policy, and responsibility boundaries instead of file convenience. | Use when defining or reviewing module, service, or subsystem boundaries. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `architecture-decision-rigor` | `architecture-decision-rigor.md` | Keep architecture decisions explicit, comparable, and reviewable before they shape the system. | Use when making or reviewing significant architecture decisions. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `change-impact-analysis` | `change-impact-analysis.md` | Make the blast radius of non-trivial changes explicit before implementation commits the system to hidden coupling. | Use when preparing or reviewing non-trivial changes with possible cross-boundary effects. | `[]` | `[architecture-decision-rigor, abstraction-boundary-discipline]` | `[]` | `[]` |
-| `composition-over-subtyping` | `composition-over-subtyping.md` | Prefer explicit composition of behavior over deep inheritance or subtype trees. | Use when designing extensible behavior or type relationships. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `domain-modeling-rigor` | `domain-modeling-rigor.md` | Domain concepts must be explicit, stable, and mapped to unambiguous model boundaries. | Use when modeling domain concepts or reviewing domain-facing contracts and APIs. | `[]` | `[deterministic-reasoning]` | `[]` | `[]` |
-| `functional-error-modeling` | `functional-error-modeling.md` | Error states and optional values must be explicit in domain contracts. | Use when defining or reviewing domain contracts that carry recoverable failures or optional values. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `immutability-by-default` | `immutability-by-default.md` | Keep state transitions explicit and bounded so domain behavior remains predictable and composable. | Use when designing or reviewing stateful domain behavior and mutation boundaries. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `interface-contract-first` | `interface-contract-first.md` | Define semantic boundary contracts before implementation details accumulate around them. | Use when defining or reviewing interface boundaries before implementation details spread. | `[]` | `[domain-modeling-rigor, abstraction-boundary-discipline]` | `[]` | `[]` |
-| `side-effect-boundary-discipline` | `side-effect-boundary-discipline.md` | Keep side effects explicit, bounded, and testable. | Use when designing or reviewing IO-heavy logic, process control, or external action boundaries. | `[]` | `[immutability-by-default, functional-error-modeling]` | `[]` | `[]` |
+| `abstraction-boundary-discipline` | `abstraction-boundary-discipline.md` | Align module and service boundaries with change, policy, and responsibility boundaries instead of file convenience. | Use when defining or reviewing module, service, or subsystem boundaries. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `architecture-decision-rigor` | `architecture-decision-rigor.md` | Keep architecture decisions explicit, comparable, and reviewable before they shape the system. | Use when making or reviewing significant architecture decisions. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `change-impact-analysis` | `change-impact-analysis.md` | Make the blast radius of non-trivial changes explicit before implementation commits the system to hidden coupling. | Use when preparing or reviewing non-trivial changes with possible cross-boundary effects. | `[]` | `[]` | `[architecture-decision-rigor, abstraction-boundary-discipline]` | `[]` |
+| `composition-over-subtyping` | `composition-over-subtyping.md` | Prefer explicit composition of behavior over deep inheritance or subtype trees. | Use when designing extensible behavior or type relationships. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `domain-modeling-rigor` | `domain-modeling-rigor.md` | Domain concepts must be explicit, stable, and mapped to unambiguous model boundaries. | Use when modeling domain concepts or reviewing domain-facing contracts and APIs. | `[]` | `[]` | `[deterministic-reasoning]` | `[]` |
+| `functional-error-modeling` | `functional-error-modeling.md` | Error states and optional values must be explicit in domain contracts. | Use when defining or reviewing domain contracts that carry recoverable failures or optional values. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `immutability-by-default` | `immutability-by-default.md` | Keep state transitions explicit and bounded so domain behavior remains predictable and composable. | Use when designing or reviewing stateful domain behavior and mutation boundaries. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `interface-contract-first` | `interface-contract-first.md` | Define semantic boundary contracts before implementation details accumulate around them. | Use when defining or reviewing interface boundaries before implementation details spread. | `[]` | `[]` | `[domain-modeling-rigor, abstraction-boundary-discipline]` | `[]` |
+| `side-effect-boundary-discipline` | `side-effect-boundary-discipline.md` | Keep side effects explicit, bounded, and testable. | Use when designing or reviewing IO-heavy logic, process control, or external action boundaries. | `[]` | `[]` | `[immutability-by-default, functional-error-modeling]` | `[]` |
diff --git a/crp/cap/engineering/principles/abstraction-boundary-discipline.meta.yaml b/crp/cap/engineering/principles/abstraction-boundary-discipline.meta.yaml
index 5b2693f..2387add 100644
--- a/crp/cap/engineering/principles/abstraction-boundary-discipline.meta.yaml
+++ b/crp/cap/engineering/principles/abstraction-boundary-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: abstraction-boundary-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["domain-modeling-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/engineering/principles/architecture-decision-rigor.meta.yaml b/crp/cap/engineering/principles/architecture-decision-rigor.meta.yaml
index 981660d..4dda16d 100644
--- a/crp/cap/engineering/principles/architecture-decision-rigor.meta.yaml
+++ b/crp/cap/engineering/principles/architecture-decision-rigor.meta.yaml
@@ -1,11 +1,6 @@
 id: architecture-decision-rigor
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["domain-modeling-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/engineering/principles/change-impact-analysis.meta.yaml b/crp/cap/engineering/principles/change-impact-analysis.meta.yaml
index b369f40..cff615f 100644
--- a/crp/cap/engineering/principles/change-impact-analysis.meta.yaml
+++ b/crp/cap/engineering/principles/change-impact-analysis.meta.yaml
@@ -1,11 +1,6 @@
 id: change-impact-analysis
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["architecture-decision-rigor","abstraction-boundary-discipline"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/engineering/principles/composition-over-subtyping.meta.yaml b/crp/cap/engineering/principles/composition-over-subtyping.meta.yaml
index 8af79fe..499a166 100644
--- a/crp/cap/engineering/principles/composition-over-subtyping.meta.yaml
+++ b/crp/cap/engineering/principles/composition-over-subtyping.meta.yaml
@@ -1,11 +1,6 @@
 id: composition-over-subtyping
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["domain-modeling-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/engineering/principles/domain-modeling-rigor.meta.yaml b/crp/cap/engineering/principles/domain-modeling-rigor.meta.yaml
index 3b3658a..6a7ed5a 100644
--- a/crp/cap/engineering/principles/domain-modeling-rigor.meta.yaml
+++ b/crp/cap/engineering/principles/domain-modeling-rigor.meta.yaml
@@ -1,11 +1,6 @@
 id: domain-modeling-rigor
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/engineering/principles/functional-error-modeling.meta.yaml b/crp/cap/engineering/principles/functional-error-modeling.meta.yaml
index 0008a39..467218f 100644
--- a/crp/cap/engineering/principles/functional-error-modeling.meta.yaml
+++ b/crp/cap/engineering/principles/functional-error-modeling.meta.yaml
@@ -1,11 +1,6 @@
 id: functional-error-modeling
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["domain-modeling-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/engineering/principles/immutability-by-default.meta.yaml b/crp/cap/engineering/principles/immutability-by-default.meta.yaml
index 7966729..3205364 100644
--- a/crp/cap/engineering/principles/immutability-by-default.meta.yaml
+++ b/crp/cap/engineering/principles/immutability-by-default.meta.yaml
@@ -1,11 +1,6 @@
 id: immutability-by-default
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["domain-modeling-rigor"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/engineering/principles/interface-contract-first.meta.yaml b/crp/cap/engineering/principles/interface-contract-first.meta.yaml
index 28e1b5a..700481a 100644
--- a/crp/cap/engineering/principles/interface-contract-first.meta.yaml
+++ b/crp/cap/engineering/principles/interface-contract-first.meta.yaml
@@ -1,11 +1,6 @@
 id: interface-contract-first
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["domain-modeling-rigor","abstraction-boundary-discipline"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/engineering/principles/side-effect-boundary-discipline.meta.yaml b/crp/cap/engineering/principles/side-effect-boundary-discipline.meta.yaml
index 235e203..63b83da 100644
--- a/crp/cap/engineering/principles/side-effect-boundary-discipline.meta.yaml
+++ b/crp/cap/engineering/principles/side-effect-boundary-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: side-effect-boundary-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-20T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["immutability-by-default","functional-error-modeling"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/foundation/clarification-before-guessing.meta.yaml b/crp/cap/foundation/clarification-before-guessing.meta.yaml
index 10b21b3..00aa46b 100644
--- a/crp/cap/foundation/clarification-before-guessing.meta.yaml
+++ b/crp/cap/foundation/clarification-before-guessing.meta.yaml
@@ -1,11 +1,6 @@
 id: clarification-before-guessing
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/foundation/critical-peer-discipline.meta.yaml b/crp/cap/foundation/critical-peer-discipline.meta.yaml
index 8d6c687..991d61b 100644
--- a/crp/cap/foundation/critical-peer-discipline.meta.yaml
+++ b/crp/cap/foundation/critical-peer-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: critical-peer-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/foundation/deterministic-reasoning.meta.yaml b/crp/cap/foundation/deterministic-reasoning.meta.yaml
index cdb9244..85582c3 100644
--- a/crp/cap/foundation/deterministic-reasoning.meta.yaml
+++ b/crp/cap/foundation/deterministic-reasoning.meta.yaml
@@ -1,11 +1,6 @@
 id: deterministic-reasoning
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: []
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/foundation/index.md b/crp/cap/foundation/index.md
index 1a92b96..a564c53 100644
--- a/crp/cap/foundation/index.md
+++ b/crp/cap/foundation/index.md
@@ -2,9 +2,9 @@
 
 This index exposes the local capability selection surface for `foundation`.
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `clarification-before-guessing` | `clarification-before-guessing.md` | Resolve missing or contradictory context through explicit clarification instead of fabricated certainty. | Use when mandatory decision context is missing, contradictory, or underspecified. | `[]` | `[deterministic-reasoning]` | `[]` | `[]` |
-| `critical-peer-discipline` | `critical-peer-discipline.md` | Act as a rigorous peer that surfaces weak assumptions, material trade-offs, and non-compliant requests instead of passively affirming them. | Use when reviewing requests, proposals, plans, or recommendations for material weakness or non-compliance. | `[]` | `[deterministic-reasoning]` | `[]` | `[]` |
+| `clarification-before-guessing` | `clarification-before-guessing.md` | Resolve missing or contradictory context through explicit clarification instead of fabricated certainty. | Use when mandatory decision context is missing, contradictory, or underspecified. | `[]` | `[]` | `[deterministic-reasoning]` | `[]` |
+| `critical-peer-discipline` | `critical-peer-discipline.md` | Act as a rigorous peer that surfaces weak assumptions, material trade-offs, and non-compliant requests instead of passively affirming them. | Use when reviewing requests, proposals, plans, or recommendations for material weakness or non-compliance. | `[]` | `[]` | `[deterministic-reasoning]` | `[]` |
 | `deterministic-reasoning` | `deterministic-reasoning.md` | Keep reasoning explicit, traceable, and stable under incomplete or conflicting context. | Use when reasoning under incomplete, conflicting, or partially evidenced context must remain explicit and stable. | `[]` | `[]` | `[]` | `[]` |
-| `task-understanding-confirmation` | `task-understanding-confirmation.md` | Confirm the understood task framing before substantive execution starts so analysis, implementation, or recommendations do not proceed from a misread request. | Use when a new substantive request or a materially reframed task must be confirmed before solution content, analysis, or execution begins. | the interaction already operates inside a confirmed task frame and no material scope change occurred | `[deterministic-reasoning, clarification-before-guessing]` | `[]` | clarification-before-guessing: resolves missing or contradictory context whereas this capability confirms the task framing even when context is already sufficient<br>interaction-contract: defines deterministic collaboration behavior for strategy work rather than a general pre-execution confirmation gate<br>decision-gates: controls when strategic recommendations may become final and does not confirm task framing before execution |
+| `task-understanding-confirmation` | `task-understanding-confirmation.md` | Confirm the understood task framing before substantive execution starts so analysis, implementation, or recommendations do not proceed from a misread request. | Use when a new substantive request or a materially reframed task must be confirmed before solution content, analysis, or execution begins. | the interaction already operates inside a confirmed task frame and no material scope change occurred | clarification-before-guessing: resolves missing or contradictory context whereas this capability confirms the task framing even when context is already sufficient<br>interaction-contract: defines deterministic collaboration behavior for strategy work rather than a general pre-execution confirmation gate<br>decision-gates: controls when strategic recommendations may become final and does not confirm task framing before execution | `[deterministic-reasoning, clarification-before-guessing]` | `[]` |
diff --git a/crp/cap/foundation/task-understanding-confirmation.meta.yaml b/crp/cap/foundation/task-understanding-confirmation.meta.yaml
index 69ad6cb..8b6b018 100644
--- a/crp/cap/foundation/task-understanding-confirmation.meta.yaml
+++ b/crp/cap/foundation/task-understanding-confirmation.meta.yaml
@@ -1,13 +1,14 @@
 id: task-understanding-confirmation
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-24T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning","clarification-before-guessing"]
 conflicts: []
 do_not_use_when: ["the interaction already operates inside a confirmed task frame and no material scope change occurred"]
-distinguish_from: ["clarification-before-guessing: resolves missing or contradictory context whereas this capability confirms the task framing even when context is already sufficient","interaction-contract: defines deterministic collaboration behavior for strategy work rather than a general pre-execution confirmation gate","decision-gates: controls when strategic recommendations may become final and does not confirm task framing before execution"]
+distinguish_from:
+  - id: clarification-before-guessing
+    boundary: "resolves missing or contradictory context whereas this capability confirms the task framing even when context is already sufficient"
+  - id: interaction-contract
+    boundary: "defines deterministic collaboration behavior for strategy work rather than a general pre-execution confirmation gate"
+  - id: decision-gates
+    boundary: "controls when strategic recommendations may become final and does not confirm task framing before execution"
 sources: []
diff --git a/crp/cap/index.md b/crp/cap/index.md
index 961fa32..91fab66 100644
--- a/crp/cap/index.md
+++ b/crp/cap/index.md
@@ -16,193 +16,193 @@ It complements the domain-local indexes, which stay focused on composition-orien
 
 ##### Enterprise
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ai-operating-model-architecture` | `ai-operating-model-architecture.md` | Design an explicit AI operating model before scaling ownership, controls, or delivery expectations. | Use when an organization or multi-team initiative needs clear AI roles, lifecycle ownership, and control points. | `[]` | `[decision-gates, togaf-adm-discipline, architecture-decision-rigor]` | `[]` | `[]` |
+| `ai-operating-model-architecture` | `ai-operating-model-architecture.md` | Design an explicit AI operating model before scaling ownership, controls, or delivery expectations. | Use when an organization or multi-team initiative needs clear AI roles, lifecycle ownership, and control points. | `[]` | `[]` | `[decision-gates, togaf-adm-discipline, architecture-decision-rigor]` | `[]` |
 
 ##### Governance
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ai-evaluation-and-control-architecture` | `ai-evaluation-and-control-architecture.md` | Define how AI behavior is evaluated, monitored, constrained, and interrupted across the runtime lifecycle. | Use when an AI solution needs explicit quality, safety, oversight, or escalation controls. | `[]` | `[decision-gates, architecture-decision-rigor, architecture-compliance-review]` | `[]` | `[]` |
+| `ai-evaluation-and-control-architecture` | `ai-evaluation-and-control-architecture.md` | Define how AI behavior is evaluated, monitored, constrained, and interrupted across the runtime lifecycle. | Use when an AI solution needs explicit quality, safety, oversight, or escalation controls. | `[]` | `[]` | `[decision-gates, architecture-decision-rigor, architecture-compliance-review]` | `[]` |
 
 ##### Solution
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `agentic-solution-architecture` | `agentic-solution-architecture.md` | Decompose agentic solutions into bounded runtime concerns before implementation detail accumulates. | Use when designing or reviewing a system that reasons, invokes tools, persists state, or escalates actions. | `[]` | `[decision-gates, architecture-decision-rigor]` | `[]` | `[]` |
-| `grounding-and-context-architecture` | `grounding-and-context-architecture.md` | Design grounding and context boundaries so generated outputs remain traceable, bounded, and reviewable. | Use when a solution depends on retrieved knowledge, source material, memory, or other contextual inputs. | `[]` | `[decision-gates, architecture-decision-rigor]` | `[]` | `[]` |
-| `model-selection-and-boundary-fit` | `model-selection-and-boundary-fit.md` | Choose model boundaries that fit the actual problem, control needs, and fallback strategy. | Use when deciding whether and how AI capabilities should be introduced into a solution. | `[]` | `[decision-gates, strategic-fit]` | `[]` | `[]` |
+| `agentic-solution-architecture` | `agentic-solution-architecture.md` | Decompose agentic solutions into bounded runtime concerns before implementation detail accumulates. | Use when designing or reviewing a system that reasons, invokes tools, persists state, or escalates actions. | `[]` | `[]` | `[decision-gates, architecture-decision-rigor]` | `[]` |
+| `grounding-and-context-architecture` | `grounding-and-context-architecture.md` | Design grounding and context boundaries so generated outputs remain traceable, bounded, and reviewable. | Use when a solution depends on retrieved knowledge, source material, memory, or other contextual inputs. | `[]` | `[]` | `[decision-gates, architecture-decision-rigor]` | `[]` |
+| `model-selection-and-boundary-fit` | `model-selection-and-boundary-fit.md` | Choose model boundaries that fit the actual problem, control needs, and fallback strategy. | Use when deciding whether and how AI capabilities should be introduced into a solution. | `[]` | `[]` | `[decision-gates, strategic-fit]` | `[]` |
 
 #### Consulting
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ai-adoption-roadmapping` | `ai-adoption-roadmapping.md` | Stage AI adoption from pilot to scaled operation with explicit maturity and control gates. | Use when an organization needs a sequenced path from experimentation to governed scale. | `[]` | `[decision-gates, portfolio-prioritization, strategy-narrative-structure]` | `[]` | `[]` |
-| `ai-center-of-excellence-design` | `ai-center-of-excellence-design.md` | Design an AI enablement model that scales standards, support, and governance without becoming a delivery bottleneck. | Use when an organization needs a reusable structure for AI enablement across teams or business units. | `[]` | `[decision-gates, ai-operating-model-architecture, ai-adoption-roadmapping]` | `[]` | `[]` |
-| `ai-readiness-assessment` | `ai-readiness-assessment.md` | Assess whether an organization or initiative is ready to design, deploy, and control AI responsibly. | Use when deciding whether an AI initiative should start, scale, or pause. | `[]` | `[decision-gates, strategy-diagnosis, strategic-fit]` | `[]` | `[]` |
-| `ai-use-case-framing` | `ai-use-case-framing.md` | Frame AI initiatives around concrete problems, outcomes, and constraints before solution design begins. | Use when a team proposes an AI or agentic initiative and the business value or problem boundary is still fluid. | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` | `[]` |
-| `ai-value-risk-prioritization` | `ai-value-risk-prioritization.md` | Prioritize AI initiatives by balancing value, feasibility, readiness, risk, and control burden. | Use when multiple AI opportunities compete for investment, attention, or implementation capacity. | `[]` | `[decision-gates, portfolio-prioritization, strategic-fit]` | `[]` | `[]` |
+| `ai-adoption-roadmapping` | `ai-adoption-roadmapping.md` | Stage AI adoption from pilot to scaled operation with explicit maturity and control gates. | Use when an organization needs a sequenced path from experimentation to governed scale. | `[]` | `[]` | `[decision-gates, portfolio-prioritization, strategy-narrative-structure]` | `[]` |
+| `ai-center-of-excellence-design` | `ai-center-of-excellence-design.md` | Design an AI enablement model that scales standards, support, and governance without becoming a delivery bottleneck. | Use when an organization needs a reusable structure for AI enablement across teams or business units. | `[]` | `[]` | `[decision-gates, ai-operating-model-architecture, ai-adoption-roadmapping]` | `[]` |
+| `ai-readiness-assessment` | `ai-readiness-assessment.md` | Assess whether an organization or initiative is ready to design, deploy, and control AI responsibly. | Use when deciding whether an AI initiative should start, scale, or pause. | `[]` | `[]` | `[decision-gates, strategy-diagnosis, strategic-fit]` | `[]` |
+| `ai-use-case-framing` | `ai-use-case-framing.md` | Frame AI initiatives around concrete problems, outcomes, and constraints before solution design begins. | Use when a team proposes an AI or agentic initiative and the business value or problem boundary is still fluid. | `[]` | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` |
+| `ai-value-risk-prioritization` | `ai-value-risk-prioritization.md` | Prioritize AI initiatives by balancing value, feasibility, readiness, risk, and control burden. | Use when multiple AI opportunities compete for investment, attention, or implementation capacity. | `[]` | `[]` | `[decision-gates, portfolio-prioritization, strategic-fit]` | `[]` |
 
 #### Engineering
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `agent-loop-and-state-design` | `agent-loop-and-state-design.md` | Design agent loops and state transitions so work remains resumable, bounded, and interruptible. | Use when an AI system iterates across planning, tool use, review, or multi-step execution. | `[]` | `[deterministic-reasoning, abstraction-boundary-discipline, change-impact-analysis]` | `[]` | `[]` |
-| `context-engineering-discipline` | `context-engineering-discipline.md` | Shape context deliberately so the model receives the right information, in the right form, at the right boundary. | Use when model quality depends on retrieved material, memory, task state, or instruction layering. | `[]` | `[deterministic-reasoning, clarification-before-guessing]` | `[]` | `[]` |
-| `evaluation-driven-iteration` | `evaluation-driven-iteration.md` | Improve AI behavior through explicit evaluation evidence rather than taste, anecdotes, or prompt folklore. | Use when changing prompts, context design, workflows, models, or guardrails to improve outcome quality. | `[]` | `[deterministic-reasoning, critical-peer-discipline]` | `[]` | `[]` |
-| `expert-continuity-briefing` | `expert-continuity-briefing.md` | Transform a running discussion into a continuity brief that enables another expert or agent to continue the work without material loss of goal, reasoning state, decisions, evidence, or next actions. | Use when an ongoing discussion, advisory thread, or reasoning session must be transferred so another expert can continue without reconstructing the material context from scratch. | the task is a project or repository reboot handover rather than discussion continuity<br>simple summarization is sufficient and no receiving expert must continue the work directly | `[deterministic-reasoning, statement-extraction-rigor, fact-interpretation-separation]` | `[]` | statement-extraction-rigor: extracts relevant source statements without building a continuity-ready expert brief<br>decision-structuring-discipline: structures decision artifacts instead of preserving full discussion continuity<br>context-engineering-discipline: shapes model context boundaries instead of producing a transfer brief for a receiving expert<br>project handover protocol/report: governs reboot and repository handover rather than discussion continuity |
-| `failure-mode-and-guardrail-design` | `failure-mode-and-guardrail-design.md` | Design guardrails from concrete AI failure modes instead of generic caution language. | Use when an AI system can influence decisions, actions, data exposure, or downstream automation. | `[]` | `[deterministic-reasoning, critical-peer-discipline, change-impact-analysis]` | `[]` | `[]` |
-| `prompt-contract-design` | `prompt-contract-design.md` | Design prompts and instructions as bounded contracts rather than informal text craft. | Use when stable AI behavior depends on instruction structure, constraint enforcement, or output boundaries. | `[]` | `[deterministic-reasoning, interface-contract-first]` | `[]` | `[]` |
-| `tool-use-and-action-boundary-design` | `tool-use-and-action-boundary-design.md` | Separate reasoning from external actions so tool invocation stays controlled, reviewable, and permission-bounded. | Use when an AI system calls tools, writes data, triggers workflows, or acts on external systems. | `[]` | `[deterministic-reasoning, interface-contract-first, change-impact-analysis]` | `[]` | `[]` |
+| `agent-loop-and-state-design` | `agent-loop-and-state-design.md` | Design agent loops and state transitions so work remains resumable, bounded, and interruptible. | Use when an AI system iterates across planning, tool use, review, or multi-step execution. | `[]` | `[]` | `[deterministic-reasoning, abstraction-boundary-discipline, change-impact-analysis]` | `[]` |
+| `context-engineering-discipline` | `context-engineering-discipline.md` | Shape context deliberately so the model receives the right information, in the right form, at the right boundary. | Use when model quality depends on retrieved material, memory, task state, or instruction layering. | `[]` | `[]` | `[deterministic-reasoning, clarification-before-guessing]` | `[]` |
+| `evaluation-driven-iteration` | `evaluation-driven-iteration.md` | Improve AI behavior through explicit evaluation evidence rather than taste, anecdotes, or prompt folklore. | Use when changing prompts, context design, workflows, models, or guardrails to improve outcome quality. | `[]` | `[]` | `[deterministic-reasoning, critical-peer-discipline]` | `[]` |
+| `expert-continuity-briefing` | `expert-continuity-briefing.md` | Transform a running discussion into a continuity brief that enables another expert or agent to continue the work without material loss of goal, reasoning state, decisions, evidence, or next actions. | Use when an ongoing discussion, advisory thread, or reasoning session must be transferred so another expert can continue without reconstructing the material context from scratch. | the task is a project or repository reboot handover rather than discussion continuity<br>simple summarization is sufficient and no receiving expert must continue the work directly | statement-extraction-rigor: extracts relevant source statements without building a continuity-ready expert brief<br>decision-structuring-discipline: structures decision artifacts instead of preserving full discussion continuity<br>context-engineering-discipline: shapes model context boundaries instead of producing a transfer brief for a receiving expert<br>project handover protocol/report: governs reboot and repository handover rather than discussion continuity | `[deterministic-reasoning, statement-extraction-rigor, fact-interpretation-separation]` | `[]` |
+| `failure-mode-and-guardrail-design` | `failure-mode-and-guardrail-design.md` | Design guardrails from concrete AI failure modes instead of generic caution language. | Use when an AI system can influence decisions, actions, data exposure, or downstream automation. | `[]` | `[]` | `[deterministic-reasoning, critical-peer-discipline, change-impact-analysis]` | `[]` |
+| `prompt-contract-design` | `prompt-contract-design.md` | Design prompts and instructions as bounded contracts rather than informal text craft. | Use when stable AI behavior depends on instruction structure, constraint enforcement, or output boundaries. | `[]` | `[]` | `[deterministic-reasoning, interface-contract-first]` | `[]` |
+| `tool-use-and-action-boundary-design` | `tool-use-and-action-boundary-design.md` | Separate reasoning from external actions so tool invocation stays controlled, reviewable, and permission-bounded. | Use when an AI system calls tools, writes data, triggers workflows, or acts on external systems. | `[]` | `[]` | `[deterministic-reasoning, interface-contract-first, change-impact-analysis]` | `[]` |
 
 ## Analysis
 
 #### Organization
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `function-deduplication` | `function-deduplication.md` | Remove duplicate function statements without losing meaningful distinctions. | Use when a normalized function set may contain duplicate or near-duplicate function statements. | `[]` | `[function-extraction]` | `[]` | `[]` |
-| `function-extraction` | `function-extraction.md` | Extract normalized business or organizational functions from source material. | Use when source material contains business or organizational work statements that must be normalized into functions. | `[]` | `[statement-extraction-rigor]` | `[]` | `[]` |
-| `function-ownership-allocation` | `function-ownership-allocation.md` | Allocate clear accountability for each materially relevant function without collapsing ownership into informal group responsibility. | Use when assigning accountability for materially relevant functions across teams, roles, or organizational units. | `[]` | `[function-extraction]` | `[]` | `[]` |
-| `value-stream-organization-design` | `value-stream-organization-design.md` | Design target organizations around end-to-end value flow instead of accidental internal boundaries. | Use when designing or reviewing organizational structures against end-to-end value flow. | `[]` | `[function-extraction, function-deduplication, function-ownership-allocation]` | `[]` | `[]` |
+| `function-deduplication` | `function-deduplication.md` | Remove duplicate function statements without losing meaningful distinctions. | Use when a normalized function set may contain duplicate or near-duplicate function statements. | `[]` | `[]` | `[function-extraction]` | `[]` |
+| `function-extraction` | `function-extraction.md` | Extract normalized business or organizational functions from source material. | Use when source material contains business or organizational work statements that must be normalized into functions. | `[]` | `[]` | `[statement-extraction-rigor]` | `[]` |
+| `function-ownership-allocation` | `function-ownership-allocation.md` | Allocate clear accountability for each materially relevant function without collapsing ownership into informal group responsibility. | Use when assigning accountability for materially relevant functions across teams, roles, or organizational units. | `[]` | `[]` | `[function-extraction]` | `[]` |
+| `value-stream-organization-design` | `value-stream-organization-design.md` | Design target organizations around end-to-end value flow instead of accidental internal boundaries. | Use when designing or reviewing organizational structures against end-to-end value flow. | `[]` | `[]` | `[function-extraction, function-deduplication, function-ownership-allocation]` | `[]` |
 
 #### Role Assessment
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `comparison-dimension-discipline` | `comparison-dimension-discipline.md` | Ensure that comparative analysis uses stable, decision-relevant dimensions instead of ad hoc framing. | Use when comparing alternatives, roles, proposals, or candidate options that need a stable evaluation frame. | `[]` | `[statement-extraction-rigor, fact-interpretation-separation]` | `[]` | `[]` |
-| `evidence-typing-discipline` | `evidence-typing-discipline.md` | Keep material claims traceable by marking whether they are directly observed or inferred. | Use when materially relevant claims, findings, or recommendations depend on source evidence or observed outputs. | `[]` | `[fact-interpretation-separation]` | `[]` | `[]` |
-| `fact-interpretation-separation` | `fact-interpretation-separation.md` | Separate observed statements from inference, synthesis, and judgment. | Use when deriving interpretations, conclusions, or recommendations from source statements or observed evidence. | `[]` | `[statement-extraction-rigor]` | `[]` | `[]` |
-| `statement-extraction-rigor` | `statement-extraction-rigor.md` | Extract all materially relevant statements from source material without collapsing distinct claims. | Use when extracting materially relevant statements from documents, transcripts, requirements, or review artifacts. | `[]` | `[deterministic-reasoning]` | `[]` | `[]` |
+| `comparison-dimension-discipline` | `comparison-dimension-discipline.md` | Ensure that comparative analysis uses stable, decision-relevant dimensions instead of ad hoc framing. | Use when comparing alternatives, roles, proposals, or candidate options that need a stable evaluation frame. | `[]` | `[]` | `[statement-extraction-rigor, fact-interpretation-separation]` | `[]` |
+| `evidence-typing-discipline` | `evidence-typing-discipline.md` | Keep material claims traceable by marking whether they are directly observed or inferred. | Use when materially relevant claims, findings, or recommendations depend on source evidence or observed outputs. | `[]` | `[]` | `[fact-interpretation-separation]` | `[]` |
+| `fact-interpretation-separation` | `fact-interpretation-separation.md` | Separate observed statements from inference, synthesis, and judgment. | Use when deriving interpretations, conclusions, or recommendations from source statements or observed evidence. | `[]` | `[]` | `[statement-extraction-rigor]` | `[]` |
+| `statement-extraction-rigor` | `statement-extraction-rigor.md` | Extract all materially relevant statements from source material without collapsing distinct claims. | Use when extracting materially relevant statements from documents, transcripts, requirements, or review artifacts. | `[]` | `[]` | `[deterministic-reasoning]` | `[]` |
 
 #### Specification
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ambiguity-detection` | `ambiguity-detection.md` | Detect terms or clauses that allow materially different interpretations. | Use when reviewing text, specifications, contracts, or guidance that may allow materially different readings. | `[]` | `[statement-extraction-rigor]` | `[]` | `[]` |
-| `contradiction-detection` | `contradiction-detection.md` | Detect when two statements cannot both be true within the same scope and time frame. | Use when reviewing statements, requirements, or contracts for claims that may not both hold in the same scope and time frame. | `[]` | `[fact-interpretation-separation]` | `[]` | `[]` |
-| `overlap-detection` | `overlap-detection.md` | Detect materially relevant duplication of responsibility, output, or control intent. | Use when reviewing responsibilities, outputs, or control boundaries for possible duplication. | `[]` | `[statement-extraction-rigor]` | `[]` | `[]` |
-| `semantic-conflict-detection` | `semantic-conflict-detection.md` | Detect materially incompatible intent, behavior, or governance semantics even when statements are not literally contradictory. | Use when reviewing policies, processes, models, or interfaces that may be materially incompatible without being literally contradictory. | `[]` | `[fact-interpretation-separation, contradiction-detection]` | `[]` | `[]` |
+| `ambiguity-detection` | `ambiguity-detection.md` | Detect terms or clauses that allow materially different interpretations. | Use when reviewing text, specifications, contracts, or guidance that may allow materially different readings. | `[]` | `[]` | `[statement-extraction-rigor]` | `[]` |
+| `contradiction-detection` | `contradiction-detection.md` | Detect when two statements cannot both be true within the same scope and time frame. | Use when reviewing statements, requirements, or contracts for claims that may not both hold in the same scope and time frame. | `[]` | `[]` | `[fact-interpretation-separation]` | `[]` |
+| `overlap-detection` | `overlap-detection.md` | Detect materially relevant duplication of responsibility, output, or control intent. | Use when reviewing responsibilities, outputs, or control boundaries for possible duplication. | `[]` | `[]` | `[statement-extraction-rigor]` | `[]` |
+| `semantic-conflict-detection` | `semantic-conflict-detection.md` | Detect materially incompatible intent, behavior, or governance semantics even when statements are not literally contradictory. | Use when reviewing policies, processes, models, or interfaces that may be materially incompatible without being literally contradictory. | `[]` | `[]` | `[fact-interpretation-separation, contradiction-detection]` | `[]` |
 
 ## Architecture
 
 #### Domain
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `application-integration-architecture` | `application-integration-architecture.md` | Shape application-domain architecture through explicit service boundaries, interoperability, and application landscape evolution. | Use when a segment or domain architecture task is application-focused and must govern application responsibilities, interfaces, or integration patterns. | when the problem is primarily data governance or technology platform architecture<br>when one concrete solution change needs realization governance more than domain architecture | `[segment-architecture-stewardship, architecture-decision-rigor]` | `[]` | data-governance-architecture<br>technology-platform-architecture<br>solution-realization-architecture |
-| `business-service-architecture` | `business-service-architecture.md` | Shape business-domain architecture through explicit capability, service, process, organization, and metric relationships. | Use when a segment or domain architecture task is business-focused and must govern business capabilities and services rather than only technical assets. | when data, application, or technology-domain concerns dominate the architecture problem<br>when the task is generic strategic planning without a business-architecture boundary | `[segment-architecture-stewardship, capability-map-governance]` | `[]` | capability-map-governance<br>data-governance-architecture<br>application-integration-architecture<br>technology-platform-architecture |
-| `data-governance-architecture` | `data-governance-architecture.md` | Shape data-domain architecture through explicit governance, integration, migration, protection, and lifecycle control. | Use when a segment or domain architecture task is data-focused and must govern data ownership, flow, protection, integration, or migration across the landscape. | when the main concern is application-service decomposition rather than data governance and lifecycle control<br>when the task is low-level schema hygiene without data-landscape architecture implications | `[segment-architecture-stewardship]` | `[]` | application-integration-architecture<br>technology-platform-architecture<br>domain-modeling-rigor |
-| `segment-architecture-stewardship` | `segment-architecture-stewardship.md` | Shape and govern one business or technical segment as a coherent architecture responsibility instead of a loose collection of systems. | Use when a business or technical segment must be translated from strategy into governed architecture change, policies, standards, and segment evolution. | when the task is enterprise-wide cross-segment integration rather than stewardship of one segment<br>when the task is detailed realization of one concrete solution rather than segment evolution | `[togaf-adm-discipline, baseline-target-gap-analysis]` | `[]` | enterprise-architecture-integration<br>solution-realization-architecture<br>capability-map-governance |
-| `technology-platform-architecture` | `technology-platform-architecture.md` | Shape technology-domain architecture through explicit platform, network, device, infrastructure, and interoperability decisions. | Use when a segment or domain architecture task is technology-focused and must govern platform standards, infrastructure boundaries, or technical interoperability. | when the dominant concern is application-service architecture or data governance rather than platform and infrastructure design<br>when the task is an operational runbook without architecture-level platform decisions | `[segment-architecture-stewardship]` | `[]` | application-integration-architecture<br>data-governance-architecture<br>solution-realization-architecture |
+| `application-integration-architecture` | `application-integration-architecture.md` | Shape application-domain architecture through explicit service boundaries, interoperability, and application landscape evolution. | Use when a segment or domain architecture task is application-focused and must govern application responsibilities, interfaces, or integration patterns. | when the problem is primarily data governance or technology platform architecture<br>when one concrete solution change needs realization governance more than domain architecture | data-governance-architecture: TBD<br>technology-platform-architecture: TBD<br>solution-realization-architecture: TBD | `[segment-architecture-stewardship, architecture-decision-rigor]` | `[]` |
+| `business-service-architecture` | `business-service-architecture.md` | Shape business-domain architecture through explicit capability, service, process, organization, and metric relationships. | Use when a segment or domain architecture task is business-focused and must govern business capabilities and services rather than only technical assets. | when data, application, or technology-domain concerns dominate the architecture problem<br>when the task is generic strategic planning without a business-architecture boundary | capability-map-governance: TBD<br>data-governance-architecture: TBD<br>application-integration-architecture: TBD<br>technology-platform-architecture: TBD | `[segment-architecture-stewardship, capability-map-governance]` | `[]` |
+| `data-governance-architecture` | `data-governance-architecture.md` | Shape data-domain architecture through explicit governance, integration, migration, protection, and lifecycle control. | Use when a segment or domain architecture task is data-focused and must govern data ownership, flow, protection, integration, or migration across the landscape. | when the main concern is application-service decomposition rather than data governance and lifecycle control<br>when the task is low-level schema hygiene without data-landscape architecture implications | application-integration-architecture: TBD<br>technology-platform-architecture: TBD<br>domain-modeling-rigor: TBD | `[segment-architecture-stewardship]` | `[]` |
+| `segment-architecture-stewardship` | `segment-architecture-stewardship.md` | Shape and govern one business or technical segment as a coherent architecture responsibility instead of a loose collection of systems. | Use when a business or technical segment must be translated from strategy into governed architecture change, policies, standards, and segment evolution. | when the task is enterprise-wide cross-segment integration rather than stewardship of one segment<br>when the task is detailed realization of one concrete solution rather than segment evolution | enterprise-architecture-integration: TBD<br>solution-realization-architecture: TBD<br>capability-map-governance: TBD | `[togaf-adm-discipline, baseline-target-gap-analysis]` | `[]` |
+| `technology-platform-architecture` | `technology-platform-architecture.md` | Shape technology-domain architecture through explicit platform, network, device, infrastructure, and interoperability decisions. | Use when a segment or domain architecture task is technology-focused and must govern platform standards, infrastructure boundaries, or technical interoperability. | when the dominant concern is application-service architecture or data governance rather than platform and infrastructure design<br>when the task is an operational runbook without architecture-level platform decisions | application-integration-architecture: TBD<br>data-governance-architecture: TBD<br>solution-realization-architecture: TBD | `[segment-architecture-stewardship]` | `[]` |
 
 #### Enterprise
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `architecture-practice-leadership` | `architecture-practice-leadership.md` | Create the strategic, governance, and sponsorship conditions for an effective architecture practice across the enterprise. | Use when architecture work needs executive alignment, practice leadership, or cross-domain mandate before downstream enterprise, segment, or solution work can succeed. | when the task is detailed segment or solution design rather than architecture-practice leadership<br>when a conformance verdict is needed rather than leadership, sponsorship, or mandate creation | `[togaf-adm-discipline, strategic-fit]` | `[]` | enterprise-architecture-integration<br>architecture-compliance-review<br>strategic-fit |
-| `capability-map-governance` | `capability-map-governance.md` | Use capability maps as stable architecture control artifacts rather than as proxies for projects or org charts. | Use when creating, reviewing, or governing capability maps as architecture control artifacts. | when the task is detailed process, org-chart, or application mapping rather than stable capability architecture<br>when segment or solution realization questions dominate over capability-map control logic | `[togaf-adm-discipline]` | `[]` | business-service-architecture<br>enterprise-architecture-integration |
-| `enterprise-architecture-integration` | `enterprise-architecture-integration.md` | Create enterprise-wide integration, interoperability, governance, and roadmap coherence across multiple architecture segments. | Use when architecture work must align principles, policies, roadmaps, or interoperability across multiple segments instead of one local domain or one solution. | when scope is only one segment or one concrete solution<br>when the main need is executive sponsorship and practice mandate rather than enterprise integration | `[togaf-adm-discipline, capability-map-governance]` | `[]` | architecture-practice-leadership<br>segment-architecture-stewardship<br>transition-architecture-planning |
-| `togaf-adm-discipline` | `togaf-adm-discipline.md` | Keep architecture work phase-aware, decision-oriented, and traceable to the intent of TOGAF ADM. | Use when architecture work claims TOGAF alignment or needs phase-aware architecture discipline. | when the task is a local modeling or compliance question that does not depend on TOGAF lifecycle framing<br>when role-specific architecture leadership or realization design is needed more than phase-aware discipline | `[decision-gates]` | `[]` | enterprise-architecture-integration<br>transition-architecture-planning |
+| `architecture-practice-leadership` | `architecture-practice-leadership.md` | Create the strategic, governance, and sponsorship conditions for an effective architecture practice across the enterprise. | Use when architecture work needs executive alignment, practice leadership, or cross-domain mandate before downstream enterprise, segment, or solution work can succeed. | when the task is detailed segment or solution design rather than architecture-practice leadership<br>when a conformance verdict is needed rather than leadership, sponsorship, or mandate creation | enterprise-architecture-integration: TBD<br>architecture-compliance-review: TBD<br>strategic-fit: TBD | `[togaf-adm-discipline, strategic-fit]` | `[]` |
+| `capability-map-governance` | `capability-map-governance.md` | Use capability maps as stable architecture control artifacts rather than as proxies for projects or org charts. | Use when creating, reviewing, or governing capability maps as architecture control artifacts. | when the task is detailed process, org-chart, or application mapping rather than stable capability architecture<br>when segment or solution realization questions dominate over capability-map control logic | business-service-architecture: TBD<br>enterprise-architecture-integration: TBD | `[togaf-adm-discipline]` | `[]` |
+| `enterprise-architecture-integration` | `enterprise-architecture-integration.md` | Create enterprise-wide integration, interoperability, governance, and roadmap coherence across multiple architecture segments. | Use when architecture work must align principles, policies, roadmaps, or interoperability across multiple segments instead of one local domain or one solution. | when scope is only one segment or one concrete solution<br>when the main need is executive sponsorship and practice mandate rather than enterprise integration | architecture-practice-leadership: TBD<br>segment-architecture-stewardship: TBD<br>transition-architecture-planning: TBD | `[togaf-adm-discipline, capability-map-governance]` | `[]` |
+| `togaf-adm-discipline` | `togaf-adm-discipline.md` | Keep architecture work phase-aware, decision-oriented, and traceable to the intent of TOGAF ADM. | Use when architecture work claims TOGAF alignment or needs phase-aware architecture discipline. | when the task is a local modeling or compliance question that does not depend on TOGAF lifecycle framing<br>when role-specific architecture leadership or realization design is needed more than phase-aware discipline | enterprise-architecture-integration: TBD<br>transition-architecture-planning: TBD | `[decision-gates]` | `[]` |
 
 #### Governance
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `architecture-compliance-review` | `architecture-compliance-review.md` | Review target states and solution directions against architecture principles, standards, and approved decisions. | Use when reviewing target states, architectures, or solution directions against approved architecture principles and standards. | when the task is to create architecture direction rather than evaluate conformance against approved principles, standards, or decisions<br>when no architecture baseline exists to review against | `[togaf-adm-discipline, archimate-cross-layer-consistency]` | `[]` | architecture-practice-leadership<br>enterprise-architecture-integration<br>solution-realization-architecture |
+| `architecture-compliance-review` | `architecture-compliance-review.md` | Review target states and solution directions against architecture principles, standards, and approved decisions. | Use when reviewing target states, architectures, or solution directions against approved architecture principles and standards. | when the task is to create architecture direction rather than evaluate conformance against approved principles, standards, or decisions<br>when no architecture baseline exists to review against | architecture-practice-leadership: TBD<br>enterprise-architecture-integration: TBD<br>solution-realization-architecture: TBD | `[togaf-adm-discipline, archimate-cross-layer-consistency]` | `[]` |
 
 #### Modeling
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `archimate-cross-layer-consistency` | `archimate-cross-layer-consistency.md` | Keep ArchiMate models consistent across business, application, data, and technology layers. | Use when reviewing ArchiMate models across multiple layers, views, or lifecycle updates. | when the main task is choosing viewpoints rather than validating cross-layer model consistency | `[archimate-viewpoint-selection]` | `[]` | archimate-viewpoint-selection |
-| `archimate-viewpoint-selection` | `archimate-viewpoint-selection.md` | Select modeling viewpoints by stakeholder question and decision need, not by template habit. | Use when selecting or reviewing ArchiMate views for stakeholder communication or design decisions. | when the relevant problem is cross-layer inconsistency rather than viewpoint fit for a stakeholder question | `[togaf-adm-discipline]` | `[]` | archimate-cross-layer-consistency |
+| `archimate-cross-layer-consistency` | `archimate-cross-layer-consistency.md` | Keep ArchiMate models consistent across business, application, data, and technology layers. | Use when reviewing ArchiMate models across multiple layers, views, or lifecycle updates. | when the main task is choosing viewpoints rather than validating cross-layer model consistency | archimate-viewpoint-selection: TBD | `[archimate-viewpoint-selection]` | `[]` |
+| `archimate-viewpoint-selection` | `archimate-viewpoint-selection.md` | Select modeling viewpoints by stakeholder question and decision need, not by template habit. | Use when selecting or reviewing ArchiMate views for stakeholder communication or design decisions. | when the relevant problem is cross-layer inconsistency rather than viewpoint fit for a stakeholder question | archimate-cross-layer-consistency: TBD | `[togaf-adm-discipline]` | `[]` |
 
 #### Solution
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `baseline-target-gap-analysis` | `baseline-target-gap-analysis.md` | Make baseline, target, and gap statements comparable before solution design proceeds. | Use when comparing current and target states before solution design or transition planning. | when no baseline or target state can be stated yet<br>when the main task is sequencing transition states rather than comparing states | `[togaf-adm-discipline]` | `[]` | transition-architecture-planning<br>solution-realization-architecture |
-| `solution-realization-architecture` | `solution-realization-architecture.md` | Shape a concrete solution change into an interoperable topology and implementable transition architecture without losing architectural intent. | Use when a concrete solution must be specified, staged, and governed from requirements through target roadmap and implementation change. | when the task is enterprise or segment governance without a concrete solution scope<br>when the task is generic project planning or handover without architecture realization content | `[baseline-target-gap-analysis, transition-architecture-planning, architecture-decision-rigor]` | `[]` | segment-architecture-stewardship<br>transition-architecture-planning<br>agentic-solution-architecture |
-| `transition-architecture-planning` | `transition-architecture-planning.md` | Stage architecture evolution through deliberate intermediate states instead of assuming one-step transformation. | Use when architecture evolution must be staged through deliberate intermediate states. | when baseline and target have not been compared yet<br>when the task is a single target-state compliance check rather than staged change design | `[baseline-target-gap-analysis]` | `[]` | baseline-target-gap-analysis<br>solution-realization-architecture |
+| `baseline-target-gap-analysis` | `baseline-target-gap-analysis.md` | Make baseline, target, and gap statements comparable before solution design proceeds. | Use when comparing current and target states before solution design or transition planning. | when no baseline or target state can be stated yet<br>when the main task is sequencing transition states rather than comparing states | transition-architecture-planning: TBD<br>solution-realization-architecture: TBD | `[togaf-adm-discipline]` | `[]` |
+| `solution-realization-architecture` | `solution-realization-architecture.md` | Shape a concrete solution change into an interoperable topology and implementable transition architecture without losing architectural intent. | Use when a concrete solution must be specified, staged, and governed from requirements through target roadmap and implementation change. | when the task is enterprise or segment governance without a concrete solution scope<br>when the task is generic project planning or handover without architecture realization content | segment-architecture-stewardship: TBD<br>transition-architecture-planning: TBD<br>agentic-solution-architecture: TBD | `[baseline-target-gap-analysis, transition-architecture-planning, architecture-decision-rigor]` | `[]` |
+| `transition-architecture-planning` | `transition-architecture-planning.md` | Stage architecture evolution through deliberate intermediate states instead of assuming one-step transformation. | Use when architecture evolution must be staged through deliberate intermediate states. | when baseline and target have not been compared yet<br>when the task is a single target-state compliance check rather than staged change design | baseline-target-gap-analysis: TBD<br>solution-realization-architecture: TBD | `[baseline-target-gap-analysis]` | `[]` |
 
 ## Engineering
 
 #### Principles
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `abstraction-boundary-discipline` | `abstraction-boundary-discipline.md` | Align module and service boundaries with change, policy, and responsibility boundaries instead of file convenience. | Use when defining or reviewing module, service, or subsystem boundaries. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `architecture-decision-rigor` | `architecture-decision-rigor.md` | Keep architecture decisions explicit, comparable, and reviewable before they shape the system. | Use when making or reviewing significant architecture decisions. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `change-impact-analysis` | `change-impact-analysis.md` | Make the blast radius of non-trivial changes explicit before implementation commits the system to hidden coupling. | Use when preparing or reviewing non-trivial changes with possible cross-boundary effects. | `[]` | `[architecture-decision-rigor, abstraction-boundary-discipline]` | `[]` | `[]` |
-| `composition-over-subtyping` | `composition-over-subtyping.md` | Prefer explicit composition of behavior over deep inheritance or subtype trees. | Use when designing extensible behavior or type relationships. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `domain-modeling-rigor` | `domain-modeling-rigor.md` | Domain concepts must be explicit, stable, and mapped to unambiguous model boundaries. | Use when modeling domain concepts or reviewing domain-facing contracts and APIs. | `[]` | `[deterministic-reasoning]` | `[]` | `[]` |
-| `functional-error-modeling` | `functional-error-modeling.md` | Error states and optional values must be explicit in domain contracts. | Use when defining or reviewing domain contracts that carry recoverable failures or optional values. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `immutability-by-default` | `immutability-by-default.md` | Keep state transitions explicit and bounded so domain behavior remains predictable and composable. | Use when designing or reviewing stateful domain behavior and mutation boundaries. | `[]` | `[domain-modeling-rigor]` | `[]` | `[]` |
-| `interface-contract-first` | `interface-contract-first.md` | Define semantic boundary contracts before implementation details accumulate around them. | Use when defining or reviewing interface boundaries before implementation details spread. | `[]` | `[domain-modeling-rigor, abstraction-boundary-discipline]` | `[]` | `[]` |
-| `side-effect-boundary-discipline` | `side-effect-boundary-discipline.md` | Keep side effects explicit, bounded, and testable. | Use when designing or reviewing IO-heavy logic, process control, or external action boundaries. | `[]` | `[immutability-by-default, functional-error-modeling]` | `[]` | `[]` |
+| `abstraction-boundary-discipline` | `abstraction-boundary-discipline.md` | Align module and service boundaries with change, policy, and responsibility boundaries instead of file convenience. | Use when defining or reviewing module, service, or subsystem boundaries. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `architecture-decision-rigor` | `architecture-decision-rigor.md` | Keep architecture decisions explicit, comparable, and reviewable before they shape the system. | Use when making or reviewing significant architecture decisions. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `change-impact-analysis` | `change-impact-analysis.md` | Make the blast radius of non-trivial changes explicit before implementation commits the system to hidden coupling. | Use when preparing or reviewing non-trivial changes with possible cross-boundary effects. | `[]` | `[]` | `[architecture-decision-rigor, abstraction-boundary-discipline]` | `[]` |
+| `composition-over-subtyping` | `composition-over-subtyping.md` | Prefer explicit composition of behavior over deep inheritance or subtype trees. | Use when designing extensible behavior or type relationships. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `domain-modeling-rigor` | `domain-modeling-rigor.md` | Domain concepts must be explicit, stable, and mapped to unambiguous model boundaries. | Use when modeling domain concepts or reviewing domain-facing contracts and APIs. | `[]` | `[]` | `[deterministic-reasoning]` | `[]` |
+| `functional-error-modeling` | `functional-error-modeling.md` | Error states and optional values must be explicit in domain contracts. | Use when defining or reviewing domain contracts that carry recoverable failures or optional values. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `immutability-by-default` | `immutability-by-default.md` | Keep state transitions explicit and bounded so domain behavior remains predictable and composable. | Use when designing or reviewing stateful domain behavior and mutation boundaries. | `[]` | `[]` | `[domain-modeling-rigor]` | `[]` |
+| `interface-contract-first` | `interface-contract-first.md` | Define semantic boundary contracts before implementation details accumulate around them. | Use when defining or reviewing interface boundaries before implementation details spread. | `[]` | `[]` | `[domain-modeling-rigor, abstraction-boundary-discipline]` | `[]` |
+| `side-effect-boundary-discipline` | `side-effect-boundary-discipline.md` | Keep side effects explicit, bounded, and testable. | Use when designing or reviewing IO-heavy logic, process control, or external action boundaries. | `[]` | `[]` | `[immutability-by-default, functional-error-modeling]` | `[]` |
 
 ## Foundation
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `clarification-before-guessing` | `clarification-before-guessing.md` | Resolve missing or contradictory context through explicit clarification instead of fabricated certainty. | Use when mandatory decision context is missing, contradictory, or underspecified. | `[]` | `[deterministic-reasoning]` | `[]` | `[]` |
-| `critical-peer-discipline` | `critical-peer-discipline.md` | Act as a rigorous peer that surfaces weak assumptions, material trade-offs, and non-compliant requests instead of passively affirming them. | Use when reviewing requests, proposals, plans, or recommendations for material weakness or non-compliance. | `[]` | `[deterministic-reasoning]` | `[]` | `[]` |
+| `clarification-before-guessing` | `clarification-before-guessing.md` | Resolve missing or contradictory context through explicit clarification instead of fabricated certainty. | Use when mandatory decision context is missing, contradictory, or underspecified. | `[]` | `[]` | `[deterministic-reasoning]` | `[]` |
+| `critical-peer-discipline` | `critical-peer-discipline.md` | Act as a rigorous peer that surfaces weak assumptions, material trade-offs, and non-compliant requests instead of passively affirming them. | Use when reviewing requests, proposals, plans, or recommendations for material weakness or non-compliance. | `[]` | `[]` | `[deterministic-reasoning]` | `[]` |
 | `deterministic-reasoning` | `deterministic-reasoning.md` | Keep reasoning explicit, traceable, and stable under incomplete or conflicting context. | Use when reasoning under incomplete, conflicting, or partially evidenced context must remain explicit and stable. | `[]` | `[]` | `[]` | `[]` |
-| `task-understanding-confirmation` | `task-understanding-confirmation.md` | Confirm the understood task framing before substantive execution starts so analysis, implementation, or recommendations do not proceed from a misread request. | Use when a new substantive request or a materially reframed task must be confirmed before solution content, analysis, or execution begins. | the interaction already operates inside a confirmed task frame and no material scope change occurred | `[deterministic-reasoning, clarification-before-guessing]` | `[]` | clarification-before-guessing: resolves missing or contradictory context whereas this capability confirms the task framing even when context is already sufficient<br>interaction-contract: defines deterministic collaboration behavior for strategy work rather than a general pre-execution confirmation gate<br>decision-gates: controls when strategic recommendations may become final and does not confirm task framing before execution |
+| `task-understanding-confirmation` | `task-understanding-confirmation.md` | Confirm the understood task framing before substantive execution starts so analysis, implementation, or recommendations do not proceed from a misread request. | Use when a new substantive request or a materially reframed task must be confirmed before solution content, analysis, or execution begins. | the interaction already operates inside a confirmed task frame and no material scope change occurred | clarification-before-guessing: resolves missing or contradictory context whereas this capability confirms the task framing even when context is already sufficient<br>interaction-contract: defines deterministic collaboration behavior for strategy work rather than a general pre-execution confirmation gate<br>decision-gates: controls when strategic recommendations may become final and does not confirm task framing before execution | `[deterministic-reasoning, clarification-before-guessing]` | `[]` |
 
 ## Strategy
 
 #### Analysis
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `portfolio-prioritization` | `portfolio-prioritization.md` | Prioritize strategic options through an explicit, justified evaluation frame. | Use when multiple strategic options compete for attention, sequencing, or investment and a ranked decision is required. | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` | `[]` |
-| `strategy-diagnosis` | `strategy-diagnosis.md` | Determine what is true, relevant, and causally important in the current strategic context before options or actions are prioritized. | Use when a strategic situation must be understood before recommending options, interventions, or commitments. | `[]` | `[decision-gates]` | `[]` | `[]` |
-| `strategy-narrative-structure` | `strategy-narrative-structure.md` | Structure strategic communication so direction, rationale, and consequences remain explicit. | Use when strategic reasoning must be communicated in a way that preserves diagnosis, logic, and consequences. | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` | `[]` |
+| `portfolio-prioritization` | `portfolio-prioritization.md` | Prioritize strategic options through an explicit, justified evaluation frame. | Use when multiple strategic options compete for attention, sequencing, or investment and a ranked decision is required. | `[]` | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` |
+| `strategy-diagnosis` | `strategy-diagnosis.md` | Determine what is true, relevant, and causally important in the current strategic context before options or actions are prioritized. | Use when a strategic situation must be understood before recommending options, interventions, or commitments. | `[]` | `[]` | `[decision-gates]` | `[]` |
+| `strategy-narrative-structure` | `strategy-narrative-structure.md` | Structure strategic communication so direction, rationale, and consequences remain explicit. | Use when strategic reasoning must be communicated in a way that preserves diagnosis, logic, and consequences. | `[]` | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` |
 
 #### Delivery
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `decision-structuring-discipline` | `decision-structuring-discipline.md` | Structure strategic decision artifacts so they are decision-ready, traceable, and explicit about gaps. | Use when preparing a strategic recommendation, board paper, or decision template for formal review or approval. | `[]` | `[decision-gates]` | `[]` | `[]` |
+| `decision-structuring-discipline` | `decision-structuring-discipline.md` | Structure strategic decision artifacts so they are decision-ready, traceable, and explicit about gaps. | Use when preparing a strategic recommendation, board paper, or decision template for formal review or approval. | `[]` | `[]` | `[decision-gates]` | `[]` |
 
 #### Evaluation
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `strategic-fit` | `strategic-fit.md` | Evaluate whether an initiative fits strategic direction, constraints, and execution reality. | Use when deciding whether an initiative should stop, continue, pilot, or scale. | `[]` | `[decision-gates, strategy-diagnosis, portfolio-prioritization, kpi-system]` | `[]` | `[]` |
+| `strategic-fit` | `strategic-fit.md` | Evaluate whether an initiative fits strategic direction, constraints, and execution reality. | Use when deciding whether an initiative should stop, continue, pilot, or scale. | `[]` | `[]` | `[decision-gates, strategy-diagnosis, portfolio-prioritization, kpi-system]` | `[]` |
 
 #### Goal Management
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `cadence-and-review-discipline` | `cadence-and-review-discipline.md` | Keep goals alive through explicit review cadence, evidence updates, learning, decisions, and adaptation instead of treating goals as static planning artifacts. | Use when goals, outcomes, OKRs, initiatives, or execution commitments need check-ins, progress review, scoring, adaptation, or closure. | `[]` | `[goal-quality-discipline, critical-peer-discipline]` | `[]` | `[]` |
-| `goal-cascade-and-alignment` | `goal-cascade-and-alignment.md` | Align goals across levels, teams, or domains so local goals contribute to shared intent without mechanical cascading, hidden conflicts, or ownership dilution. | Use when goals are translated, cascaded, aligned, decomposed, or reviewed across teams, levels, portfolios, or organizational boundaries. | `[]` | `[goal-quality-discipline, critical-peer-discipline]` | `[]` | `[]` |
-| `goal-quality-discipline` | `goal-quality-discipline.md` | Shape goals so they are material, outcome-oriented, understandable, owned, and usable for steering rather than vague aspiration or activity tracking. | Use when goals, objectives, outcomes, or target statements are proposed, reviewed, prioritized, or challenged. | `[]` | `[critical-peer-discipline]` | `[]` | `[]` |
-| `okr-discipline` | `okr-discipline.md` | Apply OKRs as a disciplined goal-setting and execution system that creates focus, alignment, measurable progress, learning, and accountability around the goals that matter most. | Use when OKRs are proposed, designed, reviewed, scored, or challenged for goal management, alignment, or execution focus. | Measuring ongoing operational health or business-as-usual without change intent — use kpi-system instead. | `[goal-quality-discipline, goal-cascade-and-alignment, cadence-and-review-discipline, critical-peer-discipline]` | `[]` | kpi-system: kpi-system defines stable measurement semantics for health indicators; okr-discipline defines goal-setting for change with measurable Key Results. OKRs drive change, KPIs monitor health.<br>goal-quality-discipline: goal-quality-discipline shapes any goal statement for materiality and clarity; okr-discipline applies the specific OKR framework structure (Objective + Key Results + classification + cadence). |
+| `cadence-and-review-discipline` | `cadence-and-review-discipline.md` | Keep goals alive through explicit review cadence, evidence updates, learning, decisions, and adaptation instead of treating goals as static planning artifacts. | Use when goals, outcomes, OKRs, initiatives, or execution commitments need check-ins, progress review, scoring, adaptation, or closure. | `[]` | `[]` | `[goal-quality-discipline, critical-peer-discipline]` | `[]` |
+| `goal-cascade-and-alignment` | `goal-cascade-and-alignment.md` | Align goals across levels, teams, or domains so local goals contribute to shared intent without mechanical cascading, hidden conflicts, or ownership dilution. | Use when goals are translated, cascaded, aligned, decomposed, or reviewed across teams, levels, portfolios, or organizational boundaries. | `[]` | `[]` | `[goal-quality-discipline, critical-peer-discipline]` | `[]` |
+| `goal-quality-discipline` | `goal-quality-discipline.md` | Shape goals so they are material, outcome-oriented, understandable, owned, and usable for steering rather than vague aspiration or activity tracking. | Use when goals, objectives, outcomes, or target statements are proposed, reviewed, prioritized, or challenged. | `[]` | `[]` | `[critical-peer-discipline]` | `[]` |
+| `okr-discipline` | `okr-discipline.md` | Apply OKRs as a disciplined goal-setting and execution system that creates focus, alignment, measurable progress, learning, and accountability around the goals that matter most. | Use when OKRs are proposed, designed, reviewed, scored, or challenged for goal management, alignment, or execution focus. | Measuring ongoing operational health or business-as-usual without change intent — use kpi-system instead. | kpi-system: kpi-system defines stable measurement semantics for health indicators; okr-discipline defines goal-setting for change with measurable Key Results. OKRs drive change, KPIs monitor health.<br>goal-quality-discipline: goal-quality-discipline shapes any goal statement for materiality and clarity; okr-discipline applies the specific OKR framework structure (Objective + Key Results + classification + cadence). | `[goal-quality-discipline, goal-cascade-and-alignment, cadence-and-review-discipline, critical-peer-discipline]` | `[]` |
 
 #### Governance
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `decision-gates` | `decision-gates.md` | Ensure that strategic recommendations are finalized only when the mandatory decision context is explicit. | Use when a strategic recommendation, prioritization, or decision artifact may move from provisional to final. | `[]` | `[interaction-contract]` | `[]` | `[]` |
+| `decision-gates` | `decision-gates.md` | Ensure that strategic recommendations are finalized only when the mandatory decision context is explicit. | Use when a strategic recommendation, prioritization, or decision artifact may move from provisional to final. | `[]` | `[]` | `[interaction-contract]` | `[]` |
 
 #### Metrics
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `kpi-system` | `kpi-system.md` | Define KPI-Domains and KPIs as stable, reviewable measurement semantics for strategic decisions, goal tracking, and operational steering. | Use when strategic choices, interventions, or reviews depend on explicit measurement semantics. | Setting stretch goals or defining change-oriented objectives with measurable key results — use okr-discipline instead. | `[deterministic-reasoning]` | `[]` | okr-discipline: okr-discipline defines goal-setting for intentional change with measurable Key Results; kpi-system defines stable measurement semantics for ongoing health monitoring and decision support. KPIs measure state, OKRs drive change. |
+| `kpi-system` | `kpi-system.md` | Define KPI-Domains and KPIs as stable, reviewable measurement semantics for strategic decisions, goal tracking, and operational steering. | Use when strategic choices, interventions, or reviews depend on explicit measurement semantics. | Setting stretch goals or defining change-oriented objectives with measurable key results — use okr-discipline instead. | okr-discipline: okr-discipline defines goal-setting for intentional change with measurable Key Results; kpi-system defines stable measurement semantics for ongoing health monitoring and decision support. KPIs measure state, OKRs drive change. | `[deterministic-reasoning]` | `[]` |
 
 #### Operation
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `technical-output-validation` | `technical-output-validation.md` | Validate technical outputs against strategic intent, declared quality criteria, and decision gates. | Use when technical output is used as supporting evidence for a strategic recommendation or decision. | `[]` | `[decision-gates, strategic-fit]` | `[]` | `[]` |
+| `technical-output-validation` | `technical-output-validation.md` | Validate technical outputs against strategic intent, declared quality criteria, and decision gates. | Use when technical output is used as supporting evidence for a strategic recommendation or decision. | `[]` | `[]` | `[decision-gates, strategic-fit]` | `[]` |
 
 #### Workflow
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `interaction-contract` | `interaction-contract.md` | Define deterministic collaboration behavior for strategy work. | Use when strategy work requires explicit clarification behavior, provisional/final signaling, and assumption handling. | `[]` | `[clarification-before-guessing]` | `[]` | `[]` |
+| `interaction-contract` | `interaction-contract.md` | Define deterministic collaboration behavior for strategy work. | Use when strategy work requires explicit clarification behavior, provisional/final signaling, and assumption handling. | `[]` | `[]` | `[clarification-before-guessing]` | `[]` |
diff --git a/crp/cap/strategy/analysis/portfolio-prioritization.meta.yaml b/crp/cap/strategy/analysis/portfolio-prioritization.meta.yaml
index 519e2c5..bb97272 100644
--- a/crp/cap/strategy/analysis/portfolio-prioritization.meta.yaml
+++ b/crp/cap/strategy/analysis/portfolio-prioritization.meta.yaml
@@ -1,11 +1,6 @@
 id: portfolio-prioritization
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","strategy-diagnosis"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/analysis/strategy-diagnosis.meta.yaml b/crp/cap/strategy/analysis/strategy-diagnosis.meta.yaml
index 5229b76..daf66f6 100644
--- a/crp/cap/strategy/analysis/strategy-diagnosis.meta.yaml
+++ b/crp/cap/strategy/analysis/strategy-diagnosis.meta.yaml
@@ -1,11 +1,6 @@
 id: strategy-diagnosis
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/analysis/strategy-narrative-structure.meta.yaml b/crp/cap/strategy/analysis/strategy-narrative-structure.meta.yaml
index fa9d790..1bf6885 100644
--- a/crp/cap/strategy/analysis/strategy-narrative-structure.meta.yaml
+++ b/crp/cap/strategy/analysis/strategy-narrative-structure.meta.yaml
@@ -1,11 +1,6 @@
 id: strategy-narrative-structure
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","strategy-diagnosis"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/delivery/decision-structuring-discipline.meta.yaml b/crp/cap/strategy/delivery/decision-structuring-discipline.meta.yaml
index 2cc72b8..386eab0 100644
--- a/crp/cap/strategy/delivery/decision-structuring-discipline.meta.yaml
+++ b/crp/cap/strategy/delivery/decision-structuring-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: decision-structuring-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/evaluation/strategic-fit.meta.yaml b/crp/cap/strategy/evaluation/strategic-fit.meta.yaml
index a18a573..7fe2773 100644
--- a/crp/cap/strategy/evaluation/strategic-fit.meta.yaml
+++ b/crp/cap/strategy/evaluation/strategic-fit.meta.yaml
@@ -1,11 +1,6 @@
 id: strategic-fit
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","strategy-diagnosis","portfolio-prioritization","kpi-system"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/goal-management/cadence-and-review-discipline.meta.yaml b/crp/cap/strategy/goal-management/cadence-and-review-discipline.meta.yaml
index 729dce3..0fd47ad 100644
--- a/crp/cap/strategy/goal-management/cadence-and-review-discipline.meta.yaml
+++ b/crp/cap/strategy/goal-management/cadence-and-review-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: cadence-and-review-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-04-30T00:00:00+02:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["goal-quality-discipline","critical-peer-discipline"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/goal-management/goal-cascade-and-alignment.meta.yaml b/crp/cap/strategy/goal-management/goal-cascade-and-alignment.meta.yaml
index 6f94c2a..4bcf670 100644
--- a/crp/cap/strategy/goal-management/goal-cascade-and-alignment.meta.yaml
+++ b/crp/cap/strategy/goal-management/goal-cascade-and-alignment.meta.yaml
@@ -1,11 +1,6 @@
 id: goal-cascade-and-alignment
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-04-30T00:00:00+02:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["goal-quality-discipline","critical-peer-discipline"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/goal-management/goal-quality-discipline.meta.yaml b/crp/cap/strategy/goal-management/goal-quality-discipline.meta.yaml
index 9042ee6..0b6ad77 100644
--- a/crp/cap/strategy/goal-management/goal-quality-discipline.meta.yaml
+++ b/crp/cap/strategy/goal-management/goal-quality-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: goal-quality-discipline
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-04-30T00:00:00+02:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["critical-peer-discipline"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/goal-management/okr-discipline.meta.yaml b/crp/cap/strategy/goal-management/okr-discipline.meta.yaml
index ed8d6f1..65c2077 100644
--- a/crp/cap/strategy/goal-management/okr-discipline.meta.yaml
+++ b/crp/cap/strategy/goal-management/okr-discipline.meta.yaml
@@ -1,11 +1,6 @@
 id: okr-discipline
 version: 0.3.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-05-04T00:00:00+02:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["goal-quality-discipline","goal-cascade-and-alignment","cadence-and-review-discipline","critical-peer-discipline"]
 conflicts: []
 do_not_use_when:
diff --git a/crp/cap/strategy/governance/decision-gates.meta.yaml b/crp/cap/strategy/governance/decision-gates.meta.yaml
index 322ef01..53fe164 100644
--- a/crp/cap/strategy/governance/decision-gates.meta.yaml
+++ b/crp/cap/strategy/governance/decision-gates.meta.yaml
@@ -1,11 +1,6 @@
 id: decision-gates
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["interaction-contract"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/index.md b/crp/cap/strategy/index.md
index 4fc3298..ac09bcf 100644
--- a/crp/cap/strategy/index.md
+++ b/crp/cap/strategy/index.md
@@ -4,53 +4,53 @@ This index exposes the local capability selection surface for `strategy`.
 
 ## Analysis
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `portfolio-prioritization` | `portfolio-prioritization.md` | Prioritize strategic options through an explicit, justified evaluation frame. | Use when multiple strategic options compete for attention, sequencing, or investment and a ranked decision is required. | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` | `[]` |
-| `strategy-diagnosis` | `strategy-diagnosis.md` | Determine what is true, relevant, and causally important in the current strategic context before options or actions are prioritized. | Use when a strategic situation must be understood before recommending options, interventions, or commitments. | `[]` | `[decision-gates]` | `[]` | `[]` |
-| `strategy-narrative-structure` | `strategy-narrative-structure.md` | Structure strategic communication so direction, rationale, and consequences remain explicit. | Use when strategic reasoning must be communicated in a way that preserves diagnosis, logic, and consequences. | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` | `[]` |
+| `portfolio-prioritization` | `portfolio-prioritization.md` | Prioritize strategic options through an explicit, justified evaluation frame. | Use when multiple strategic options compete for attention, sequencing, or investment and a ranked decision is required. | `[]` | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` |
+| `strategy-diagnosis` | `strategy-diagnosis.md` | Determine what is true, relevant, and causally important in the current strategic context before options or actions are prioritized. | Use when a strategic situation must be understood before recommending options, interventions, or commitments. | `[]` | `[]` | `[decision-gates]` | `[]` |
+| `strategy-narrative-structure` | `strategy-narrative-structure.md` | Structure strategic communication so direction, rationale, and consequences remain explicit. | Use when strategic reasoning must be communicated in a way that preserves diagnosis, logic, and consequences. | `[]` | `[]` | `[decision-gates, strategy-diagnosis]` | `[]` |
 
 ## Delivery
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `decision-structuring-discipline` | `decision-structuring-discipline.md` | Structure strategic decision artifacts so they are decision-ready, traceable, and explicit about gaps. | Use when preparing a strategic recommendation, board paper, or decision template for formal review or approval. | `[]` | `[decision-gates]` | `[]` | `[]` |
+| `decision-structuring-discipline` | `decision-structuring-discipline.md` | Structure strategic decision artifacts so they are decision-ready, traceable, and explicit about gaps. | Use when preparing a strategic recommendation, board paper, or decision template for formal review or approval. | `[]` | `[]` | `[decision-gates]` | `[]` |
 
 ## Evaluation
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `strategic-fit` | `strategic-fit.md` | Evaluate whether an initiative fits strategic direction, constraints, and execution reality. | Use when deciding whether an initiative should stop, continue, pilot, or scale. | `[]` | `[decision-gates, strategy-diagnosis, portfolio-prioritization, kpi-system]` | `[]` | `[]` |
+| `strategic-fit` | `strategic-fit.md` | Evaluate whether an initiative fits strategic direction, constraints, and execution reality. | Use when deciding whether an initiative should stop, continue, pilot, or scale. | `[]` | `[]` | `[decision-gates, strategy-diagnosis, portfolio-prioritization, kpi-system]` | `[]` |
 
 ## Goal Management
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `cadence-and-review-discipline` | `cadence-and-review-discipline.md` | Keep goals alive through explicit review cadence, evidence updates, learning, decisions, and adaptation instead of treating goals as static planning artifacts. | Use when goals, outcomes, OKRs, initiatives, or execution commitments need check-ins, progress review, scoring, adaptation, or closure. | `[]` | `[goal-quality-discipline, critical-peer-discipline]` | `[]` | `[]` |
-| `goal-cascade-and-alignment` | `goal-cascade-and-alignment.md` | Align goals across levels, teams, or domains so local goals contribute to shared intent without mechanical cascading, hidden conflicts, or ownership dilution. | Use when goals are translated, cascaded, aligned, decomposed, or reviewed across teams, levels, portfolios, or organizational boundaries. | `[]` | `[goal-quality-discipline, critical-peer-discipline]` | `[]` | `[]` |
-| `goal-quality-discipline` | `goal-quality-discipline.md` | Shape goals so they are material, outcome-oriented, understandable, owned, and usable for steering rather than vague aspiration or activity tracking. | Use when goals, objectives, outcomes, or target statements are proposed, reviewed, prioritized, or challenged. | `[]` | `[critical-peer-discipline]` | `[]` | `[]` |
-| `okr-discipline` | `okr-discipline.md` | Apply OKRs as a disciplined goal-setting and execution system that creates focus, alignment, measurable progress, learning, and accountability around the goals that matter most. | Use when OKRs are proposed, designed, reviewed, scored, or challenged for goal management, alignment, or execution focus. | Measuring ongoing operational health or business-as-usual without change intent — use kpi-system instead. | `[goal-quality-discipline, goal-cascade-and-alignment, cadence-and-review-discipline, critical-peer-discipline]` | `[]` | kpi-system: kpi-system defines stable measurement semantics for health indicators; okr-discipline defines goal-setting for change with measurable Key Results. OKRs drive change, KPIs monitor health.<br>goal-quality-discipline: goal-quality-discipline shapes any goal statement for materiality and clarity; okr-discipline applies the specific OKR framework structure (Objective + Key Results + classification + cadence). |
+| `cadence-and-review-discipline` | `cadence-and-review-discipline.md` | Keep goals alive through explicit review cadence, evidence updates, learning, decisions, and adaptation instead of treating goals as static planning artifacts. | Use when goals, outcomes, OKRs, initiatives, or execution commitments need check-ins, progress review, scoring, adaptation, or closure. | `[]` | `[]` | `[goal-quality-discipline, critical-peer-discipline]` | `[]` |
+| `goal-cascade-and-alignment` | `goal-cascade-and-alignment.md` | Align goals across levels, teams, or domains so local goals contribute to shared intent without mechanical cascading, hidden conflicts, or ownership dilution. | Use when goals are translated, cascaded, aligned, decomposed, or reviewed across teams, levels, portfolios, or organizational boundaries. | `[]` | `[]` | `[goal-quality-discipline, critical-peer-discipline]` | `[]` |
+| `goal-quality-discipline` | `goal-quality-discipline.md` | Shape goals so they are material, outcome-oriented, understandable, owned, and usable for steering rather than vague aspiration or activity tracking. | Use when goals, objectives, outcomes, or target statements are proposed, reviewed, prioritized, or challenged. | `[]` | `[]` | `[critical-peer-discipline]` | `[]` |
+| `okr-discipline` | `okr-discipline.md` | Apply OKRs as a disciplined goal-setting and execution system that creates focus, alignment, measurable progress, learning, and accountability around the goals that matter most. | Use when OKRs are proposed, designed, reviewed, scored, or challenged for goal management, alignment, or execution focus. | Measuring ongoing operational health or business-as-usual without change intent — use kpi-system instead. | kpi-system: kpi-system defines stable measurement semantics for health indicators; okr-discipline defines goal-setting for change with measurable Key Results. OKRs drive change, KPIs monitor health.<br>goal-quality-discipline: goal-quality-discipline shapes any goal statement for materiality and clarity; okr-discipline applies the specific OKR framework structure (Objective + Key Results + classification + cadence). | `[goal-quality-discipline, goal-cascade-and-alignment, cadence-and-review-discipline, critical-peer-discipline]` | `[]` |
 
 ## Governance
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `decision-gates` | `decision-gates.md` | Ensure that strategic recommendations are finalized only when the mandatory decision context is explicit. | Use when a strategic recommendation, prioritization, or decision artifact may move from provisional to final. | `[]` | `[interaction-contract]` | `[]` | `[]` |
+| `decision-gates` | `decision-gates.md` | Ensure that strategic recommendations are finalized only when the mandatory decision context is explicit. | Use when a strategic recommendation, prioritization, or decision artifact may move from provisional to final. | `[]` | `[]` | `[interaction-contract]` | `[]` |
 
 ## Metrics
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `kpi-system` | `kpi-system.md` | Define KPI-Domains and KPIs as stable, reviewable measurement semantics for strategic decisions, goal tracking, and operational steering. | Use when strategic choices, interventions, or reviews depend on explicit measurement semantics. | Setting stretch goals or defining change-oriented objectives with measurable key results — use okr-discipline instead. | `[deterministic-reasoning]` | `[]` | okr-discipline: okr-discipline defines goal-setting for intentional change with measurable Key Results; kpi-system defines stable measurement semantics for ongoing health monitoring and decision support. KPIs measure state, OKRs drive change. |
+| `kpi-system` | `kpi-system.md` | Define KPI-Domains and KPIs as stable, reviewable measurement semantics for strategic decisions, goal tracking, and operational steering. | Use when strategic choices, interventions, or reviews depend on explicit measurement semantics. | Setting stretch goals or defining change-oriented objectives with measurable key results — use okr-discipline instead. | okr-discipline: okr-discipline defines goal-setting for intentional change with measurable Key Results; kpi-system defines stable measurement semantics for ongoing health monitoring and decision support. KPIs measure state, OKRs drive change. | `[deterministic-reasoning]` | `[]` |
 
 ## Operation
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `technical-output-validation` | `technical-output-validation.md` | Validate technical outputs against strategic intent, declared quality criteria, and decision gates. | Use when technical output is used as supporting evidence for a strategic recommendation or decision. | `[]` | `[decision-gates, strategic-fit]` | `[]` | `[]` |
+| `technical-output-validation` | `technical-output-validation.md` | Validate technical outputs against strategic intent, declared quality criteria, and decision gates. | Use when technical output is used as supporting evidence for a strategic recommendation or decision. | `[]` | `[]` | `[decision-gates, strategic-fit]` | `[]` |
 
 ## Workflow
 
-| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |
+| ID | File | Purpose | Use When | Do Not Use When | Distinguish From | Requires | Conflicts |
 | --- | --- | --- | --- | --- | --- | --- | --- |
-| `interaction-contract` | `interaction-contract.md` | Define deterministic collaboration behavior for strategy work. | Use when strategy work requires explicit clarification behavior, provisional/final signaling, and assumption handling. | `[]` | `[clarification-before-guessing]` | `[]` | `[]` |
+| `interaction-contract` | `interaction-contract.md` | Define deterministic collaboration behavior for strategy work. | Use when strategy work requires explicit clarification behavior, provisional/final signaling, and assumption handling. | `[]` | `[]` | `[clarification-before-guessing]` | `[]` |
diff --git a/crp/cap/strategy/metrics/kpi-system.meta.yaml b/crp/cap/strategy/metrics/kpi-system.meta.yaml
index c178f33..d7ae8b4 100644
--- a/crp/cap/strategy/metrics/kpi-system.meta.yaml
+++ b/crp/cap/strategy/metrics/kpi-system.meta.yaml
@@ -1,11 +1,6 @@
 id: kpi-system
 version: 0.2.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-05-04T00:00:00+02:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["deterministic-reasoning"]
 conflicts: []
 do_not_use_when:
diff --git a/crp/cap/strategy/operation/technical-output-validation.meta.yaml b/crp/cap/strategy/operation/technical-output-validation.meta.yaml
index 9058f55..574784a 100644
--- a/crp/cap/strategy/operation/technical-output-validation.meta.yaml
+++ b/crp/cap/strategy/operation/technical-output-validation.meta.yaml
@@ -1,11 +1,6 @@
 id: technical-output-validation
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["decision-gates","strategic-fit"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/cap/strategy/workflow/interaction-contract.meta.yaml b/crp/cap/strategy/workflow/interaction-contract.meta.yaml
index 752077d..aeb54d5 100644
--- a/crp/cap/strategy/workflow/interaction-contract.meta.yaml
+++ b/crp/cap/strategy/workflow/interaction-contract.meta.yaml
@@ -1,11 +1,6 @@
 id: interaction-contract
 version: 0.1.0
-status: active
-approved_by: ["nemron"]
-approved_at: 2026-03-19T00:00:00+01:00
-scope: cognitive
 owner: nemron
-review_due: 2026-12-31
 requires: ["clarification-before-guessing"]
 conflicts: []
 do_not_use_when: []
diff --git a/crp/gov/prc/workflow.md b/crp/gov/prc/workflow.md
index a114901..b0020ad 100644
--- a/crp/gov/prc/workflow.md
+++ b/crp/gov/prc/workflow.md
@@ -102,7 +102,7 @@ This workflow executes **per Story**. Epic refinement and Story decomposition ar
 
 5. AI Strategy (`ai4x-ai-strategy`) — conditional
 - validates model/tool constraints, fallback behavior, and uncertainty policy
-- only when the Story involves AI/LLM behavior
+- only when the Story involves AI/LLM behavior or shapes agent capability consumption patterns
 
 6. Capability Governance (`ai4x-capability-governance`) — conditional
 - validates portfolio coverage, authors or revises capabilities, performs semantic fitness checks
@@ -131,7 +131,7 @@ The Tech Lead determines in Stage 1 which stages are needed for the current Stor
 | 2. Requirements Refinement | Conditional | Epic ACs are already sufficient for the Story scope |
 | 3. Architecture | Conditional | No module boundary or domain invariant changes |
 | 4. Critical Review A | Conditional | Stages 2 and 3 were both skipped |
-| 5. AI Strategy | Conditional | Story does not involve AI/LLM behavior |
+| 5. AI Strategy | Conditional | Story does not involve AI/LLM behavior and does not shape agent capability consumption patterns |
 | 6. Capability Governance | Conditional | Story does not involve cognitive capability authoring, evaluation, or portfolio change |
 | 7. Implementation | Always | — |
 | 8. Testing | Always | — |
diff --git a/utl/cap/checks/capability-indexes.mjs b/utl/cap/checks/capability-indexes.mjs
index 3089c44..693a21f 100644
--- a/utl/cap/checks/capability-indexes.mjs
+++ b/utl/cap/checks/capability-indexes.mjs
@@ -11,6 +11,46 @@ const capRoot = root;
 const writeMode = modeArg === "--write";
 let fail = 0;
 
+// --- Schema loading (AC-15) ---
+
+const schemaPath = process.env.AI4X_SCHEMA_PATH
+  ? path.resolve(process.env.AI4X_SCHEMA_PATH)
+  : path.resolve(
+      path.dirname(new URL(import.meta.url).pathname),
+      "../../../adm/gdl/dev/schemas/capability-meta.schema.yaml",
+    );
+
+if (!fs.existsSync(schemaPath)) {
+  process.stderr.write(`[ccp|ERROR]: central schema file not found: ${schemaPath}\n`);
+  process.exit(1);
+}
+
+let schemaRaw;
+try {
+  schemaRaw = YAML.parse(fs.readFileSync(schemaPath, "utf8"));
+} catch (err) {
+  process.stderr.write(`[ccp|ERROR]: central schema file is unparseable: ${schemaPath}: ${err instanceof Error ? err.message : String(err)}\n`);
+  process.exit(1);
+}
+
+if (schemaRaw == null || typeof schemaRaw !== "object" || schemaRaw.fields == null) {
+  process.stderr.write(`[ccp|ERROR]: central schema file is malformed (missing 'fields' block): ${schemaPath}\n`);
+  process.exit(1);
+}
+
+const schemaFields = schemaRaw.fields;
+// Determine which metadata fields to render in index tables from schema.
+// Include array fields with simple items (strings or objects with ≤ 2 properties).
+// Complex object arrays (e.g., sources with 5 properties) are excluded.
+const indexRenderableFields = Object.entries(schemaFields)
+  .filter(([, def]) => {
+    if (def.type !== "array") return false;
+    const props = def.items?.properties;
+    if (props && Object.keys(props).length > 2) return false;
+    return true;
+  })
+  .map(([name]) => name);
+
 function error(message) {
   fail += 1;
   process.stderr.write(`[ccp|ERROR]: ${message}\n`);
@@ -100,16 +140,21 @@ function getDirectCapabilities(absDir) {
       const metaPath = mdPath.replace(/\.md$/, ".meta.yaml");
       const markdown = fs.readFileSync(mdPath, "utf8");
       const meta = fs.existsSync(metaPath) ? readMeta(metaPath) : {};
-      return {
+      const cap = {
         id: path.basename(entry.name, ".md"),
         file: path.relative(absDir, mdPath).split(path.sep).join("/"),
         purpose: extractSection(markdown, "Purpose"),
         useWhen: extractSection(markdown, "Trigger"),
-        doNotUseWhen: asStringArray(meta.do_not_use_when),
-        requires: asStringArray(meta.requires),
-        conflicts: asStringArray(meta.conflicts),
-        distinguishFrom: asDistinguishFromArray(meta.distinguish_from),
       };
+      // Schema-driven: extract renderable array fields from metadata
+      for (const field of indexRenderableFields) {
+        if (field === "distinguish_from") {
+          cap[field] = asDistinguishFromArray(meta[field]);
+        } else {
+          cap[field] = asStringArray(meta[field]);
+        }
+      }
+      return cap;
     })
     .sort((a, b) => a.id.localeCompare(b.id));
 }
@@ -122,15 +167,35 @@ function formatTextArray(values) {
   return values.length === 0 ? "`[]`" : values.join("<br>");
 }
 
+function fieldToColumnHeader(field) {
+  return field.split("_").map((w) => w[0].toUpperCase() + w.slice(1)).join(" ");
+}
+
+function formatFieldValue(field, entry) {
+  const value = entry[field];
+  if (!Array.isArray(value) || value.length === 0) return "`[]`";
+  // ID-reference fields use code formatting
+  if (field === "requires" || field === "conflicts") return formatIdArray(value);
+  return formatTextArray(value);
+}
+
 function renderTable(entries) {
+  const fixedHeaders = ["ID", "File", "Purpose", "Use When"];
+  const metaHeaders = indexRenderableFields.map(fieldToColumnHeader);
+  const allHeaders = [...fixedHeaders, ...metaHeaders];
   const lines = [
-    "| ID | File | Purpose | Use When | Do Not Use When | Requires | Conflicts | Distinguish From |",
-    "| --- | --- | --- | --- | --- | --- | --- | --- |",
+    `| ${allHeaders.join(" | ")} |`,
+    `| ${allHeaders.map(() => "---").join(" | ")} |`,
   ];
   for (const entry of entries) {
-    lines.push(
-      `| \`${entry.id}\` | \`${entry.file}\` | ${entry.purpose} | ${entry.useWhen} | ${formatTextArray(entry.doNotUseWhen)} | ${formatIdArray(entry.requires)} | ${formatIdArray(entry.conflicts)} | ${formatTextArray(entry.distinguishFrom)} |`,
-    );
+    const fixedCells = [
+      `\`${entry.id}\``,
+      `\`${entry.file}\``,
+      entry.purpose,
+      entry.useWhen,
+    ];
+    const metaCells = indexRenderableFields.map((field) => formatFieldValue(field, entry));
+    lines.push(`| ${[...fixedCells, ...metaCells].join(" | ")} |`);
   }
   return lines.join("\n");
 }
diff --git a/utl/cap/checks/capability-meta.mjs b/utl/cap/checks/capability-meta.mjs
index 358f33f..38213ac 100755
--- a/utl/cap/checks/capability-meta.mjs
+++ b/utl/cap/checks/capability-meta.mjs
@@ -5,40 +5,47 @@ import YAML from "yaml";
 
 const rootArg = process.argv[2];
 const root = rootArg ? path.resolve(rootArg) : path.resolve(path.dirname(new URL(import.meta.url).pathname), "../../../crp/cap");
-const expectedScope = "cognitive";
 const capRoot = root;
 
-const allowedKeys = new Set([
-  "id",
-  "version",
-  "status",
-  "approved_by",
-  "approved_at",
-  "scope",
-  "review_due",
-  "owner",
-  "requires",
-  "conflicts",
-  "do_not_use_when",
-  "distinguish_from",
-  "sources",
-  "migration_note",
-]);
+// --- Schema loading (AC-11, AC-13, AC-14) ---
 
-const requiredKeys = [
-  "id",
-  "version",
-  "status",
-  "approved_by",
-  "approved_at",
-  "scope",
-  "do_not_use_when",
-  "distinguish_from",
-  "sources",
-];
-const allowedStatus = new Set(["draft", "active", "deprecated", "retired"]);
-const allowedSourceKeys = new Set(["title", "organization", "url", "kind", "accessed_at"]);
-const allowedSourceKinds = new Set(["standard", "architecture-guidance", "security-guidance", "adoption-guidance", "domain-reference"]);
+const schemaPath = process.env.AI4X_SCHEMA_PATH
+  ? path.resolve(process.env.AI4X_SCHEMA_PATH)
+  : path.resolve(
+      path.dirname(new URL(import.meta.url).pathname),
+      "../../../adm/gdl/dev/schemas/capability-meta.schema.yaml",
+    );
+
+if (!fs.existsSync(schemaPath)) {
+  process.stderr.write(`[ccp|ERROR]: central schema file not found: ${schemaPath}\n`);
+  process.exit(1);
+}
+
+let schemaRaw;
+try {
+  schemaRaw = YAML.parse(fs.readFileSync(schemaPath, "utf8"));
+} catch (err) {
+  process.stderr.write(`[ccp|ERROR]: central schema file is unparseable: ${schemaPath}: ${err instanceof Error ? err.message : String(err)}\n`);
+  process.exit(1);
+}
+
+if (schemaRaw == null || typeof schemaRaw !== "object" || schemaRaw.fields == null) {
+  process.stderr.write(`[ccp|ERROR]: central schema file is malformed (missing 'fields' block): ${schemaPath}\n`);
+  process.exit(1);
+}
+
+const schemaFields = schemaRaw.fields;
+const allowedKeys = new Set(Object.keys(schemaFields));
+const requiredKeys = Object.entries(schemaFields)
+  .filter(([, def]) => def.required === true)
+  .map(([name]) => name);
+
+// Derive source entry constraints from schema
+const sourcesSchema = schemaFields.sources?.items?.properties ?? {};
+const allowedSourceKeys = new Set(Object.keys(sourcesSchema));
+const allowedSourceKinds = sourcesSchema.kind?.enum
+  ? new Set(sourcesSchema.kind.enum)
+  : new Set();
 
 let requiredFail = 0;
 let advisoryFail = 0;
@@ -67,13 +74,6 @@ function parseMeta(metaPath) {
   return out;
 }
 
-function validateIsoDateTime(value) {
-  if (!/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d{3})?(Z|[+-]\d{2}:\d{2})$/.test(value)) {
-    return false;
-  }
-  return !Number.isNaN(Date.parse(value));
-}
-
 function validateIsoDate(value) {
   if (!/^\d{4}-\d{2}-\d{2}$/.test(value)) {
     return false;
@@ -152,29 +152,14 @@ for (const capabilityFile of capabilityFiles) {
 
   const id = String(parsed.id ?? "");
   const version = String(parsed.version ?? "");
-  const status = String(parsed.status ?? "");
-  const rawApprovedAt = parsed.approved_at;
-  const approvedAt = rawApprovedAt instanceof Date ? rawApprovedAt.toISOString() : String(rawApprovedAt ?? "");
-  const scope = String(parsed.scope ?? "");
   const owner = Object.prototype.hasOwnProperty.call(parsed, "owner") ? String(parsed.owner) : "";
-  const rawReviewDue = parsed.review_due;
-  const reviewDue = rawReviewDue instanceof Date
-    ? rawReviewDue.toISOString().slice(0, 10)
-    : Object.prototype.hasOwnProperty.call(parsed, "review_due") ? String(rawReviewDue) : "";
-  const migrationNote = Object.prototype.hasOwnProperty.call(parsed, "migration_note")
-    ? String(parsed.migration_note)
-    : "";
   const sources = Array.isArray(parsed.sources) ? parsed.sources : [];
 
-  const approvedBy = Array.isArray(parsed.approved_by) ? parsed.approved_by.map(String) : [];
   const requires = Array.isArray(parsed.requires) ? parsed.requires.map(String) : [];
   const conflicts = Array.isArray(parsed.conflicts) ? parsed.conflicts.map(String) : [];
   const doNotUseWhen = Array.isArray(parsed.do_not_use_when) ? parsed.do_not_use_when.map(String) : [];
-  const distinguishFrom = Array.isArray(parsed.distinguish_from) ? parsed.distinguish_from.map(String) : [];
+  const distinguishFrom = Array.isArray(parsed.distinguish_from) ? parsed.distinguish_from : [];
 
-  if (!Array.isArray(parsed.approved_by)) {
-    failRequired(`${path.relative(root, metaPath)}: approved_by must be an array`);
-  }
   if (Object.prototype.hasOwnProperty.call(parsed, "requires") && !Array.isArray(parsed.requires)) {
     failRequired(`${path.relative(root, metaPath)}: requires must be an array`);
   }
@@ -197,43 +182,30 @@ for (const capabilityFile of capabilityFiles) {
   if (!validateSemver(version)) {
     failRequired(`${path.relative(root, metaPath)}: version '${version}' must be semver`);
   }
-  if (!allowedStatus.has(status)) {
-    failRequired(`${path.relative(root, metaPath)}: invalid status '${status}'`);
-  }
-  if (!validateIsoDateTime(approvedAt)) {
-    failRequired(`${path.relative(root, metaPath)}: approved_at '${approvedAt}' must be ISO-8601 datetime`);
-  }
-  if (scope !== expectedScope) {
-    failRequired(`${path.relative(root, metaPath)}: scope '${scope}' must be '${expectedScope}'`);
-  }
-  if (status === "active" && approvedBy.length === 0) {
-    failRequired(`${path.relative(root, metaPath)}: status 'active' requires non-empty approved_by`);
-  }
   if (owner.length === 0) {
-    failAdvisory(`${path.relative(root, metaPath)}: owner should be set`);
+    failRequired(`${path.relative(root, metaPath)}: owner must be non-empty`);
   }
-  if (reviewDue.length > 0) {
-    if (!validateIsoDate(reviewDue)) {
-      failRequired(`${path.relative(root, metaPath)}: review_due '${reviewDue}' must be ISO date (YYYY-MM-DD)`);
-    } else {
-      const dueTs = Date.parse(`${reviewDue}T00:00:00Z`);
-      const nowTs = Date.now();
-      if (dueTs < nowTs) {
-        failAdvisory(`${path.relative(root, metaPath)}: review_due '${reviewDue}' is in the past`);
-      }
+  for (const entry of doNotUseWhen) {
+    if (String(entry).trim().length === 0) {
+      failRequired(`${path.relative(root, metaPath)}: do_not_use_when entries must be non-empty strings`);
     }
   }
-  if (status === "deprecated" && migrationNote.length === 0) {
-    failAdvisory(`${path.relative(root, metaPath)}: deprecated capability should include migration_note`);
-  }
-  for (const entry of [...doNotUseWhen, ...distinguishFrom]) {
-    if (entry.trim().length === 0) {
-      failRequired(`${path.relative(root, metaPath)}: do_not_use_when/distinguish_from entries must be non-empty strings`);
+  for (const entry of distinguishFrom) {
+    if (entry == null || typeof entry !== "object" || !entry.id || !entry.boundary) {
+      failRequired(`${path.relative(root, metaPath)}: distinguish_from entries must be objects with 'id' and 'boundary' properties`);
     }
   }
   for (let idx = 0; idx < sources.length; idx += 1) {
     const source = sources[idx] ?? {};
     const label = `${path.relative(root, metaPath)}: sources[${idx}]`;
+    // Reject unknown source properties (schema-derived)
+    if (allowedSourceKeys.size > 0) {
+      for (const key of Object.keys(source)) {
+        if (!allowedSourceKeys.has(key)) {
+          failRequired(`${label} unsupported key '${key}'`);
+        }
+      }
+    }
     const title = String(source.title ?? "");
     const organization = String(source.organization ?? "");
     const url = String(source.url ?? "");
diff --git a/utl/cap/checks/tst/capability-meta.sh b/utl/cap/checks/tst/capability-meta.sh
index 81ed518..a82fdff 100755
--- a/utl/cap/checks/tst/capability-meta.sh
+++ b/utl/cap/checks/tst/capability-meta.sh
@@ -19,12 +19,7 @@ MD
   cat >"${fixture}/cap/foundation/deterministic-reasoning.meta.yaml" <<'YAML'
 id: deterministic-reasoning
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
 requires: []
 conflicts: []
 do_not_use_when: []
@@ -37,12 +32,7 @@ MD
   cat >"${fixture}/cap/foundation/clarification-before-guessing.meta.yaml" <<'YAML'
 id: clarification-before-guessing
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
 requires: ["deterministic-reasoning"]
 conflicts: []
 do_not_use_when: []
@@ -55,12 +45,7 @@ MD
   cat >"${fixture}/cap/strategy/workflow/interaction-contract.meta.yaml" <<'YAML'
 id: interaction-contract
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
 requires: ["clarification-before-guessing"]
 conflicts: []
 do_not_use_when: []
@@ -85,12 +70,7 @@ MD
   cat >"${fixture}/cap/ai/engineering/context-engineering-discipline.meta.yaml" <<'YAML'
 id: context-engineering-discipline
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
 requires: ["clarification-before-guessing"]
 conflicts: []
 do_not_use_when: []
@@ -116,12 +96,7 @@ run_fail_unknown_requires() {
   cat >"${fixture}/cap/strategy/workflow/interaction-contract.meta.yaml" <<'YAML'
 id: interaction-contract
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
 requires: ["missing"]
 conflicts: []
 do_not_use_when: []
@@ -140,12 +115,7 @@ run_fail_requires_conflicts_overlap() {
   cat >"${fixture}/cap/strategy/workflow/interaction-contract.meta.yaml" <<'YAML'
 id: interaction-contract
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
 requires: ["clarification-before-guessing"]
 conflicts: ["clarification-before-guessing"]
 do_not_use_when: []
@@ -167,12 +137,7 @@ MD
   cat >"${fixture}/cap/foundation/critical-peer-discipline.meta.yaml" <<'YAML'
 id: critical-peer-discipline
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
 requires: ["deterministic-reasoning"]
 conflicts: ["interaction-contract"]
 do_not_use_when: []
@@ -185,48 +150,40 @@ YAML
   fi
 }
 
-run_fail_missing_sources() {
-  local fixture="${TMP_DIR}/missing-sources"
+run_fail_missing_owner() {
+  local fixture="${TMP_DIR}/missing-owner"
   make_ok_fixture "${fixture}"
   cat >"${fixture}/cap/strategy/workflow/interaction-contract.meta.yaml" <<'YAML'
 id: interaction-contract
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
-owner: qa
-review_due: 2026-12-31
 requires: ["clarification-before-guessing"]
 conflicts: []
 do_not_use_when: []
 distinguish_from: []
+sources: []
 YAML
   if "${CHECKER}" "${fixture}/cap" >/dev/null 2>&1; then
-    echo "expected failure for missing required sources field" >&2
+    echo "expected failure for missing required owner field" >&2
     return 1
   fi
 }
 
-run_fail_missing_do_not_use_when() {
-  local fixture="${TMP_DIR}/missing-do-not-use-when"
+run_fail_unknown_key() {
+  local fixture="${TMP_DIR}/unknown-key"
   make_ok_fixture "${fixture}"
   cat >"${fixture}/cap/strategy/workflow/interaction-contract.meta.yaml" <<'YAML'
 id: interaction-contract
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
+status: active
 requires: ["clarification-before-guessing"]
 conflicts: []
+do_not_use_when: []
 distinguish_from: []
 sources: []
 YAML
   if "${CHECKER}" "${fixture}/cap" >/dev/null 2>&1; then
-    echo "expected failure for missing do_not_use_when field" >&2
+    echo "expected failure for unknown key 'status'" >&2
     return 1
   fi
 }
@@ -241,12 +198,7 @@ MD
   cat >"${fixture}/cap/ai/architecture/solution/agentic-solution-architecture.meta.yaml" <<'YAML'
 id: agentic-solution-architecture
 version: 0.1.0
-status: active
-approved_by: ["qa"]
-approved_at: 2026-03-08T00:00:00+01:00
-scope: cognitive
 owner: qa
-review_due: 2026-12-31
 requires: ["deterministic-reasoning"]
 conflicts: []
 do_not_use_when: []
@@ -264,14 +216,63 @@ YAML
   fi
 }
 
+run_fail_invalid_distinguish_from() {
+  local fixture="${TMP_DIR}/invalid-df"
+  make_ok_fixture "${fixture}"
+  cat >"${fixture}/cap/strategy/workflow/interaction-contract.meta.yaml" <<'YAML'
+id: interaction-contract
+version: 0.1.0
+owner: qa
+requires: ["clarification-before-guessing"]
+conflicts: []
+do_not_use_when: []
+distinguish_from: ["some-plain-string"]
+sources: []
+YAML
+  if "${CHECKER}" "${fixture}/cap" >/dev/null 2>&1; then
+    echo "expected failure for string-format distinguish_from entry" >&2
+    return 1
+  fi
+}
+
+run_fail_schema_missing() {
+  local fixture="${TMP_DIR}/schema-missing"
+  make_ok_fixture "${fixture}"
+  if AI4X_SCHEMA_PATH="/nonexistent/schema.yaml" "${CHECKER}" "${fixture}/cap" >/dev/null 2>&1; then
+    echo "expected failure for missing schema file" >&2
+    return 1
+  fi
+  # Verify error message names the file
+  local stderr_output
+  stderr_output="$(AI4X_SCHEMA_PATH="/nonexistent/schema.yaml" "${CHECKER}" "${fixture}/cap" 2>&1 || true)"
+  if ! echo "${stderr_output}" | grep -q "schema file not found"; then
+    echo "expected error message to mention 'schema file not found'" >&2
+    return 1
+  fi
+}
+
+run_fail_schema_unparseable() {
+  local fixture="${TMP_DIR}/schema-unparseable"
+  make_ok_fixture "${fixture}"
+  local bad_schema="${TMP_DIR}/bad-schema.yaml"
+  echo "{{invalid yaml" >"${bad_schema}"
+  if AI4X_SCHEMA_PATH="${bad_schema}" "${CHECKER}" "${fixture}/cap" >/dev/null 2>&1; then
+    echo "expected failure for unparseable schema file" >&2
+    return 1
+  fi
+}
+
 run_ok
 run_ok_explicit_empty_sources
 run_fail_missing_meta
 run_fail_unknown_requires
 run_fail_requires_conflicts_overlap
 run_fail_asymmetric_conflict
-run_fail_missing_sources
-run_fail_missing_do_not_use_when
+run_fail_missing_owner
+run_fail_unknown_key
 run_fail_invalid_source_kind
+run_fail_invalid_distinguish_from
+run_fail_schema_missing
+run_fail_schema_unparseable
 
 echo "capability-meta.sh: OK"