diff --git a/.gitignore b/.gitignore
index 4c6a2d6..c38e706 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,4 +7,5 @@ resources/
# OS files
.DS_Store
-
+GIT_INSTRUCTIONS.md
+PR_DESCRIPTION.md
diff --git a/GIT_INSTRUCTIONS.md b/GIT_INSTRUCTIONS.md
new file mode 100644
index 0000000..4fa9c8a
--- /dev/null
+++ b/GIT_INSTRUCTIONS.md
@@ -0,0 +1,43 @@
+# How to apply this content update
+
+## Prerequisites
+- Close PR #7 (this supersedes it)
+- You have push access to dcm-project/dcm-project.github.io
+
+## Steps
+
+```bash
+# 1. Clone the repo
+git clone git@github.com:dcm-project/dcm-project.github.io.git
+cd dcm-project.github.io
+
+# 2. Create branch
+git checkout -b content-update
+
+# 3. Remove old content (preserve everything else)
+rm -rf content/ static/
+git add -A
+git commit -m "Remove old content for replacement"
+
+# 4. Copy new content from the package
+cp -r /path/to/website-content/content .
+cp -r /path/to/website-content/static .
+
+# 5. Do NOT commit PR_DESCRIPTION.md or GIT_INSTRUCTIONS.md
+# (they're for your reference only)
+
+# 6. Add and commit
+git add -A
+git commit -m "Update content: fixed, deduplicated architecture (55 data model docs, 15 specs, 4 OpenAPI)
+
+Addresses all PR #7 review comments:
+- Eliminated duplicate data-model directories
+- Fixed all broken cross-references
+- Removed 116 duplicate files
+- Updated provider count (12), policy count (8), classification enum (8)
+- Synced all OpenAPI YAMLs with canonical schemas"
+
+# 7. Push and open PR
+git push origin content-update
+# Use PR_DESCRIPTION.md as the PR body
+```
diff --git a/PR_DESCRIPTION.md b/PR_DESCRIPTION.md
new file mode 100644
index 0000000..b652c55
--- /dev/null
+++ b/PR_DESCRIPTION.md
@@ -0,0 +1,47 @@
+# Replace content with fixed, deduplicated architecture
+
+**Closes PR #7** — this PR replaces the content from PR #7 with the complete, fixed architecture documentation. All review comments from PR #7 are addressed:
+
+## Issues fixed from PR #7
+
+- **@jenniferubah, @gabriel-farache:** Duplicate `data-model/` and `architecture/data-model/` directories → **eliminated**. Only `architecture/data-model/` exists now (55 docs with number prefixes).
+- **@gabriel-farache:** Broken links to foundations, provider-contract, policy-contract, capabilities matrix → **all fixed**. Zero broken cross-references verified.
+- **@gabriel-farache:** "links broken, I think all links should be reviewed" → **done**. Full automated cross-reference scan, zero broken links.
+- **@machacekondra:** Slug duplicates (e.g., `foundations.md` duplicating `00-foundations.md`) → **removed**. 53 slug duplicates eliminated.
+- **@machacekondra:** K8s operator SDK imperative vs declarative concern → addressed in updated `dcm-operator-sdk-api.md`
+- **@pkliczewski:** Accreditation flow diagrams, data_classification ownership, GitOps handling → all clarified in updated docs
+
+## What changed vs PR #7
+
+- 116 duplicate files removed (55 flat data-model copy + 53 slug dupes + 8 spec slug dupes)
+- Provider count: 11 → 12 (ITSM Provider added)
+- Policy count: 7 → 8 (ITSM Action added)
+- data_classification enum: 5 → 8 values (phi, pci, classified added)
+- All OpenAPI YAMLs synced with canonical schemas
+- Capabilities Matrix deduplicated (6 duplicate summary tables removed)
+- All Discussion Topics marked Resolved with cross-references
+
+## Content structure
+
+```
+content/
+├── _index.md
+└── docs/
+ ├── architecture/
+ │ ├── data-model/ ← 55 docs + _index.md (SINGLE location)
+ │ └── specifications/ ← 15 specs + 4 OpenAPI YAMLs + _index.md
+ ├── capabilities-matrix.md
+ ├── DISCUSSION-TOPICS.md
+ ├── taxonomy.md
+ ├── project-overview.md
+ ├── enhancements/
+ ├── implementations/
+ └── schemas/
+static/
+└── capabilities/
+ └── DCM-Capabilities-Matrix.csv
+```
+
+## How to apply
+
+This PR only touches `content/` and `static/`. No changes to `.github/workflows/`, `hugo.yaml`, `go.mod`, `go.sum`, `Makefile`, `assets/`, or `layouts/`.
diff --git a/content/_index.md b/content/_index.md
index 4115fd6..287c6b2 100644
--- a/content/_index.md
+++ b/content/_index.md
@@ -3,66 +3,53 @@ title: DCM Project
toc: false
---
-
+# Data Center Management
-{{< hextra/hero-headline >}}
- Data Center Management
-{{< /hextra/hero-headline >}}
+**Hyperscaler-like cloud experience for enterprise on-premises and sovereign cloud infrastructure.**
-
+DCM is an open-source governing framework that gives enterprise IT organizations the operational
+model and self-service capabilities of a public cloud provider — on infrastructure they own and control.
-{{< hextra/hero-subtitle >}}
- Hyperscaler-like cloud experience for
enterprise on-premises and sovereign cloud infrastructure
-{{< /hextra/hero-subtitle >}}
+{{< button href="/docs/project-overview" >}}What is DCM?{{< /button >}}
+{{< button href="/docs" >}}Documentation{{< /button >}}
+{{< button href="/docs/implementations" >}}Implementations{{< /button >}}
+{{< button href="https://github.com/dcm-project" >}}GitHub{{< /button >}}
-
-
-{{< hextra/hero-button text="Get Started" link="docs" >}}
-{{< hextra/hero-button text="View on GitHub" link="https://github.com/dcm-project" >}}
-
-
+---
-## About DCM
+## The Problem DCM Solves
-The Data Center Management (DCM) project provides a hyperscaler-like cloud experience for enterprise on-premises and sovereign cloud infrastructure. DCM is an **API-first, technology-agnostic framework** that relies on a declarative data model where the desired state of infrastructure is defined as code.
+Enterprise on-premises infrastructure is managed by dozens of disconnected tools and manual
+processes. A single VM can take weeks across five teams. No one has a trustworthy answer to:
+*what exists, what was requested, what was provisioned, and does current state match intended state?*
-The overarching goal is to define the configuration of an entire data center in version-controlled code, enabling rapid deployment and full environment recovery.
+DCM establishes a unified, declarative single source of truth for all infrastructure state
+and connects it to a policy-driven control plane that governs every lifecycle operation.
-
+## Three Foundational Abstractions
-## Core Principles
+{{< cards >}}
+ {{< card title="Data" icon="database" subtitle="Every artifact with a UUID, lifecycle state, and field-level provenance. Four states: Intent · Requested · Realized · Discovered." >}}
+ {{< card title="Provider" icon="plug" subtitle="11 typed provider contracts. Service, Information, Storage, Meta, Credential, Auth, Policy, Notification, Message Bus, ITSM, Peer DCM." >}}
+ {{< card title="Policy" icon="shield-check" subtitle="7 typed policy schemas. GateKeeper · Validation · Transformation · Orchestration Flow · Recovery · Governance Matrix · Lifecycle." >}}
+{{< /cards >}}
-{{< hextra/feature-grid >}}
- {{< hextra/feature-card
- title="🔌 API-First Design"
- subtitle="Technology-agnostic framework built on modern API principles for maximum flexibility."
- style="background: radial-gradient(ellipse at 50% 80%,rgba(194,97,254,0.15),hsla(0,0%,100%,0));"
- >}}
- {{< hextra/feature-card
- title="☁️ Cloud-Native Approach"
- subtitle="Moving away from monolithic management toward distributed, cloud-native principles."
- style="background: radial-gradient(ellipse at 50% 80%,rgba(62,151,255,0.15),hsla(0,0%,100%,0));"
- >}}
- {{< hextra/feature-card
- title="📚 Service Catalog"
- subtitle="Comprehensive catalog system for managing services and infrastructure offerings."
- >}}
- {{< hextra/feature-card
- title="⚖️ Rules Engine"
- subtitle="Built-in governance and policy enforcement through a flexible rules engine."
- >}}
-{{< /hextra/feature-grid >}}
+## Who Benefits
-
+{{< cards >}}
+ {{< card title="Application Teams" icon="users" subtitle="Self-service catalog. Request infrastructure. Receive provisioned resources. No tickets, no manual coordination." >}}
+ {{< card title="Platform Engineers" icon="cog" subtitle="Single control plane. Policy-governed standards. Automatic drift detection. Consistency is structural." >}}
+ {{< card title="Security & Compliance" icon="lock-closed" subtitle="Policy-as-code tested before activation. Tamper-evident audit trail. Continuous accreditation monitoring." >}}
+ {{< card title="Regulated Industries" icon="building-library" subtitle="FedRAMP · CMMC · HIPAA · SOC 2 · ISO 27001 · DoD IL2–IL6. Compliance by construction." >}}
+{{< /cards >}}
---
-
-
-## Explore More
+## Explore
{{< cards >}}
- {{< card link="docs" title="Documentation" icon="book-open" subtitle="Guides, tutorials, and technical documentation" >}}
- {{< card link="docs/enhancements" title="Enhancements" icon="light-bulb" subtitle="Enhancement proposals documenting new features and changes" >}}
- {{< card link="blog" title="Blog & Updates" icon="newspaper" subtitle="Latest news, releases, and articles" >}}
+ {{< card link="docs/project-overview" title="Project Overview" icon="information-circle" subtitle="What DCM is, what it does, who it benefits, where it operates." >}}
+ {{< card link="docs/architecture" title="Architecture" icon="template" subtitle="55 data model docs · 15 specs · 299 capabilities across 38 domains." >}}
+ {{< card link="docs/implementations" title="Implementations" icon="rocket-launch" subtitle="Reference implementations. Example #1: Summit 2026 demo on OpenShift." >}}
+ {{< card link="https://github.com/dcm-project" title="GitHub" icon="code-bracket" subtitle="Source, issues, and contributions." >}}
{{< /cards >}}
diff --git a/content/about/_index.md b/content/about/_index.md
deleted file mode 100644
index a0835da..0000000
--- a/content/about/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: About DCM
----
-
-# About the DCM Project
-
-DCM (Data Center Management) is an open-source platform for managing data center resources.
-
-More information coming soon.
-
diff --git a/content/blog/_index.md b/content/blog/_index.md
deleted file mode 100644
index 2f5ee7e..0000000
--- a/content/blog/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Blog
----
-
-# DCM Blog
-
-Stay updated with the latest news, releases, and technical articles about the DCM project.
-
-Blog posts coming soon.
-
diff --git a/content/docs/AI-ONBOARDING.md b/content/docs/AI-ONBOARDING.md
new file mode 100644
index 0000000..fce634f
--- /dev/null
+++ b/content/docs/AI-ONBOARDING.md
@@ -0,0 +1,107 @@
+# Using the DCM AI Prompt for Architecture Exploration
+
+**Purpose:** The DCM AI prompt (`DCM-AI-PROMPT.md`) is a 5,772-line comprehensive knowledge base covering every architectural decision, capability, data structure, and cross-reference in DCM. When loaded into Claude or another capable LLM, it enables conversational exploration of the architecture — faster than reading documentation.
+
+---
+
+## How to Use It
+
+### Option 1: Claude.ai (Recommended)
+
+1. Go to [claude.ai](https://claude.ai)
+2. Start a new conversation
+3. Attach `DCM-AI-PROMPT.md` as a file (drag and drop, or use the attachment button)
+4. Ask your question
+
+The prompt stays active for the entire conversation. You can ask follow-up questions without re-uploading.
+
+### Option 2: Claude Projects
+
+1. Create a Project in Claude
+2. Add `DCM-AI-PROMPT.md` to the Project's knowledge base
+3. Every conversation in that Project automatically has the full architecture context
+
+This is the best option for ongoing use — the prompt is always available without re-uploading.
+
+### Option 3: Other LLMs
+
+The prompt works with any LLM that supports large context windows (128K+ tokens). Upload `DCM-AI-PROMPT.md` as context. The prompt is plain Markdown with no tool-specific formatting.
+
+---
+
+## Example Questions
+
+### Understanding a concept
+> "How does the override model work?"
+> → 2-paragraph answer explaining the 5 mechanisms with severity ordering
+
+> "What's the difference between Internal and External policy evaluation?"
+> → Comparison of the two modes with when to use each
+
+> "What happens when a sovereignty policy blocks a request?"
+> → Full flow: POLICY_BLOCKED state, consumer guidance, resolution options
+
+### Finding specific details
+> "What are the 5 provider types and when would I use each?"
+> → Table with type, capability, data direction, and example
+
+> "What SQL tables exist and what's in each one?"
+> → Full schema overview with 18 tables, their purposes, and RLS details
+
+> "What events does the system emit during a VM provision?"
+> → Ordered list of events with payloads from intent through realization
+
+### Implementation guidance
+> "I'm building a new service provider. What endpoints do I need to implement?"
+> → Provider contract requirements by level (Level 1: basic, Level 2: discovery, Level 3: full)
+
+> "How do I write a GateKeeper policy that blocks VMs over 16 CPUs for a specific tenant?"
+> → Example Rego policy with match conditions, output schema, and test cases
+
+> "How does the three-tier app example work end to end?"
+> → Full walkthrough with YAML payloads, dependency resolution, and binding field injection
+
+### Cross-cutting questions
+> "Does the architecture cover [specific capability] from PR #50?"
+> → Yes/no with specific doc references and capability IDs
+
+> "What would change if we added a new provider type?"
+> → Schema migration needed, contract extension points, capabilities to declare
+
+---
+
+## What the Prompt Covers
+
+The prompt contains 125 sections organized into these areas:
+
+| Area | Sections | What's in it |
+|------|----------|-------------|
+| Foundational Abstractions | 0-3 | Data, Provider, Policy — the three pillars |
+| Data Model | 4-14 | Four states, layers, entities, relationships, groups |
+| Control Plane | 15-16 | 9 services, pipeline flow, request routing |
+| Providers | 16-22 | 6 types, contracts, naturalization, discovery |
+| Policy | 17, 23-28 | 8 types, evaluation model, overrides, templates |
+| Audit & Security | 29-35 | Merkle tree, stage signing, governance matrix, zero trust |
+| API Specifications | 36-40 | Consumer API (74 paths), Admin API (61 paths), Provider Callback |
+| Capabilities | 41 | 331 capabilities across 39 domains |
+| SQL Schema | 42 | 18 tables with column definitions |
+| Event Catalog | 43 | 109 events across 23 domains |
+| Implementation | 44-50 | Deployment, profiles, test framework |
+
+---
+
+## Tips
+
+- **Be specific.** "How does policy evaluation work?" gets a better answer than "Tell me about policies."
+- **Ask for examples.** "Show me the YAML payload at each stage of a VM provision" gets concrete data structures.
+- **Ask for cross-references.** "Which docs should I read for provider development?" gets a prioritized list.
+- **Ask for comparisons.** "How does this differ from Crossplane / Kessel / KRO?" gets an informed comparison.
+- **Ask implementation questions.** "What Go interfaces would a new service provider need?" gets code-level guidance.
+
+---
+
+## Where to Find the Prompt
+
+- **DCM repo:** `architecture/ai/DCM-AI-PROMPT.md`
+- **Website:** Published at `dcm-project.github.io/docs/architecture/ai/DCM-AI-PROMPT/`
+- **Examples repo:** Copied into `docs/DCM-AI-PROMPT.md` for reference
diff --git a/content/docs/DCM-Capabilities-Matrix.md b/content/docs/DCM-Capabilities-Matrix.md
new file mode 100644
index 0000000..721ce0c
--- /dev/null
+++ b/content/docs/DCM-Capabilities-Matrix.md
@@ -0,0 +1,715 @@
+# DCM — Foundational Capabilities Matrix
+
+> **Purpose:** This document defines the core operational capabilities required for DCM to perform lifecycle management as defined by the data model. Each capability maps to a consumer/service provider perspective and will be used to drive implementation work in Jira.
+>
+> **How to read this document:**
+> - **Capability Domain** — the architectural area the capability belongs to
+> - **Capability** — a discrete operational function; the smallest unit of independently implementable behavior
+> - **Consumer perspective** — what the end user / application team experiences
+> - **Service Provider perspective** — what the Service Provider or platform component must implement
+> - **Platform/Admin perspective** — what the platform engineer or SRE must configure or operate
+> - **Depends on** — other capabilities that must exist first
+
+---
+
+## 1. Identity and Access Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| IAM-001 | Actor Authentication | Authenticate to DCM via configured IdP | — | Register and configure Auth Providers; manage local user store | — |
+| IAM-002 | Session Token Management | Receive and use session tokens; token refresh | — | Configure session TTL, failover chain | IAM-001 |
+| IAM-003 | Role-Based Access Control | Receive role-appropriate service catalog and API responses | — | Declare role mappings; assign roles to actors | IAM-001 |
+| IAM-004 | Group Membership Resolution | Group memberships automatically applied from IdP | — | Map IdP groups to DCM groups; declare group-role relationships | IAM-001, IAM-003 |
+| IAM-005 | Multi-Factor Authentication | Satisfy per-session and step-up MFA challenges | — | Configure MFA methods; declare step-up operations | IAM-001 |
+| IAM-006 | SCIM Automated Provisioning | Actor created/updated/deprovisioned from IdP automatically | — | Configure SCIM endpoint and attribute mappings | IAM-001 |
+| IAM-007 | Tenant Scope Enforcement | Access restricted to authorized Tenants | — | Declare Tenant membership; configure cross-tenant policies | IAM-003, IAM-004 |
+| AUTH-002 | Multi-Auth-Provider Routing | — | — | Register multiple Auth Providers simultaneously; ingress routes by authentication signal | IAM-001 |
+| AUTH-003 | Auth Provider Trust Level Enforcement | Requests evaluated per provider trust level (authoritative / verified / advisory) | — | Configure trust level per registered Auth Provider | IAM-001 |
+| AUTH-004 | Auth Provider Artifact Versioning | — | — | Manage role/tenant mapping versioning through standard DCM artifact lifecycle; activate/deprecate mappings | IAM-003 |
+| AUTH-005 | Auth Provider Failover | Existing sessions remain valid on provider failure; new auth routes to failover chain | — | Configure failover chain; monitor provider health; manage session cache TTL | IAM-001 |
+| AUTH-006 | Auth Context in Audit Trail | — | — | Auth Provider identity and ingress context automatically recorded in all audit records | IAM-001 |
+| AUTH-007 | Auth Provider Credential Security | — | — | Enforce Auth Provider config credentials reference secrets management; no plaintext credentials | IAM-001 |
+| AUTH-008 | No Anonymous Access | — | — | Enforce authenticated access at all ingress surfaces across all profiles | IAM-001 |
+| AUTH-009 | Webhook and Message Bus Authentication | Authenticate webhook registrations | — | Enforce authentication on all inbound surfaces regardless of profile | IAM-001 |
+| AUTH-010 | Per-Actor Rate Limiting | Receive 429 responses when rate limit exceeded | — | Configure rate limits per actor; manage burst allowances | IAM-001 |
+| AUTH-011 | Git PR Identity Resolution | Git PR submissions resolve to same actor identity as API/UI login | — | Configure Auth Provider to trust Git server's identity assertion | IAM-001 |
+| AUTH-012 | SCIM Automated Provisioning | Actor created/updated/deprovisioned from IdP automatically via SCIM | — | Configure SCIM 2.0 endpoint; manage suspension-on-deprovision policy | IAM-001 |
+| AUTH-013 | In-Flight Request Continuity on Auth Failure | In-flight requests before auth failure are not interrupted | — | Configure session cache TTL; manage graceful degradation | IAM-001 |
+| AUTH-014 | Two-Tier MFA Enforcement | Satisfy per-session MFA at login and step-up MFA for high-risk operations | — | Configure per-session and step-up MFA; declare step-up trigger operations | IAM-005 |
+| AUTH-015 | Built-In Auth Provider Storage Backend | — | — | Configure built-in Auth Provider storage backend (SQLite for minimal/dev; PostgreSQL/MySQL for standard+) | IAM-001 |
+
+---
+
+## 2. Service Catalog
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| CAT-001 | Service Catalog Presentation | Browse available services filtered by RBAC | Declare catalog items for offered resource types | Activate catalog items; configure catalog visibility policies | IAM-003, IAM-007 |
+| CAT-002 | Service Schema Discovery | View field schemas, constraints, and edit constraints for a catalog item | Declare field schemas in Resource Type Spec | Configure constraint visibility level per profile | CAT-001 |
+| CAT-003 | Catalog Item Search and Filter | Search catalog by keyword, resource type, tag | — | Configure Search Index for catalog | CAT-001 |
+| CAT-004 | Catalog Item Versioning | Request a specific version of a catalog item | Publish new catalog item versions following semver | Manage version lifecycle; enforce deprecation timelines | CAT-001 |
+| CAT-005 | Cost Estimation | Receive estimated cost before submitting a request | Declare cost metadata on provider registration | Configure Cost Analysis component | CAT-001 |
+| CAT-006 | Dependency Visualization | See required dependencies for a catalog item before requesting | Declare dependency graph in Resource Type Spec | — | CAT-001 |
+| CAT-007 | Catalog Item Deprecation | Receive deprecation warnings on deprecated catalog items | Declare successor types in deprecation notice | Manage deprecation lifecycle; notify consumers | CAT-004 |
+
+---
+
+## 3. Request Lifecycle Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| REQ-001 | Submit Service Request | Submit a resource request via UI, API, or Git PR | — | Configure request ingress surfaces | IAM-007, CAT-001 |
+| REQ-002 | Intent State Capture | Request stored as versioned GitOps artifact before processing | — | Configure Intent Store; manage Git repository structure | REQ-001 |
+| REQ-003 | Layer Assembly | Request enriched with organizational defaults and context layers | Contribute Service Layers for resource types | Manage Core Layers; configure Layer Cache | REQ-002 |
+| REQ-004 | Policy Evaluation | Request validated, transformed, and gated by applicable policies | Contribute provider-specific policies | Manage Policy Engine; configure Policy Groups and Profiles | REQ-003 |
+| REQ-005 | Placement Engine Execution | Resource placed with the best available provider instance | Implement capacity reserve_query response | Configure placement constraints; manage provider priorities | REQ-004 |
+| REQ-006 | Requested State Persistence | Assembled payload stored as authoritative GitOps record | — | Configure Requested Store; manage storage redundancy | REQ-005 |
+| REQ-007 | Provider Dispatch | Request payload delivered to selected provider | Implement Services API to receive DCM payloads | Configure API Gateway and egress | REQ-006 |
+| REQ-008 | Request Status Tracking | Monitor request status from submitted through realized | Report realization status back to DCM | Configure observability for request tracking | REQ-007 |
+| REQ-009 | Request Cancellation | Cancel a pending request before realization | Handle cancellation payloads | Configure cancellation policies | REQ-002 |
+| REQ-010 | Git PR Request Ingress | Submit requests via Git Pull Request with policy dry-run feedback | — | Configure Git Request Watcher; manage repository structure | REQ-001, IAM-001 |
+
+---
+
+## 4. Provider Contract and Realization
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| PRV-001 | Provider Registration | — | Register provider with DCM: declare type, capabilities, sovereignty, cost metadata | Configure Provider Registry; validate sovereignty declarations | IAM-001 |
+| PRV-002 | Naturalization | — | Convert DCM unified payload to provider-native format | — | PRV-001, REQ-007 |
+| PRV-003 | Realization | — | Execute required actions to provision/configure/change resource | — | PRV-002 |
+| PRV-004 | Denaturalization | — | Convert provider-native result back to DCM unified format | — | PRV-003 |
+| PRV-005 | Realized State Reporting | — | Report realized payload and status to DCM API Gateway | Configure Realized State Store; manage Event Stream | PRV-004 |
+| PRV-006 | Capacity Reporting | — | Respond to reserve_query with current capacity and availability | Configure placement engine; manage capacity confidence | PRV-001 |
+| PRV-007 | Provider Health Reporting | — | Expose health check endpoint; report availability | Monitor provider health; configure trust score updates | PRV-001 |
+| PRV-008 | Sovereignty Declaration Maintenance | — | Notify DCM when sovereignty data changes within declared SLA | Monitor sovereignty changes; trigger re-evaluation | PRV-001 |
+| PRV-009 | Compound Service Orchestration | — | Compose sub-providers to deliver higher-order services; manage composition visibility | Configure composite provider federation eligibility | PRV-001, PRV-003 |
+| PRR-001 | OpenAPI Spec Declaration (GATE-SP-01) | — | Declare OpenAPI spec URL at registration; spec must be machine-readable and reachable | Validate spec URL reachability during approval pipeline | PRV-001 |
+| PRR-002 | Healthy API at Activation (GATE-SP-02) | — | Health endpoint returns `{"status": "healthy"}` at activation time | Enforce health check as activation precondition | PRV-001, HLT-001 |
+| PRR-003 | State Management Callback (GATE-SP-03) | — | Implement realized_state_push callback at all conformance levels | Validate callback endpoint reachability during approval | PRV-001 |
+| PRR-004 | Tenant Metadata Endpoint (GATE-SP-04) | — | Implement GET /api/v1/tenants/{uuid}/metadata returning usage data | Require for standard+ profile activation; enforce quota integration | PRV-001 |
+| PRR-005 | Prometheus Metrics (GATE-SP-05) | — | Expose required metric families at declared metrics_endpoint | Validate metric presence during approval; gate standard+ activation | PRV-001, HLT-005 |
+| PRR-006 | AEP.DEV Linting (GATE-SP-06) | — | Pass AEP linter against OpenAPI spec with no errors before registration; include linting report URL | Gate standard+ activation on linting pass; block activation on errors | PRV-001 |
+
+| PRV-010 | Provider Sandbox/Test Mode | Submit test requests targeting sandbox providers via `_test_context.target_provider_uuid`; sandbox providers visible in registry with `status: sandbox` | Register with `sandbox_mode: true`; implement full OIS contract; graduate to production via standard approval | Manage sandbox provider registry; review graduation requests; sandbox providers excluded from production placement | PRV-001, GATE-SP-01 || PRR-007 | Multi-Tenant Dispatch (GATE-SP-07) | — | Accept tenant_uuid in all dispatch payloads; return tenant-scoped resources | Gate standard+ activation on multi-tenant compatibility test | PRV-001 |
+
+---
+
+## 5. Resource Lifecycle Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| LCM-001 | Resource State Transitions | Trigger lifecycle actions: suspend, resume, decommission | Handle state transition payloads | Configure lifecycle policies; manage state machine | REQ-008 |
+| LCM-002 | Post-Realization Field Updates | Update editable fields on realized resources (targeted delta) | Handle delta update payloads; apply partial changes | Configure editable field declarations; manage edit policies | PRV-005 |
+| LCM-003 | Resource TTL Management | Declare and extend resource TTLs; receive expiry notifications | Handle TTL-triggered decommission payloads | Configure Lifecycle Constraint Enforcer; manage expiry policies | LCM-001 |
+| LCM-004 | Ownership Transfer | Transfer resource ownership to a different Tenant | — | Authorize and execute ownership transfers; record transfer history | IAM-007, LCM-001 |
+| LCM-005 | Rehydration | Replay a resource's intent state to a new provider or context | Receive and execute rehydration payloads | Manage rehydration leases; configure auth level requirements | REQ-002, PRV-003 |
+| LCM-006 | Billing State Management | — | — | Configure billing state policies; integrate with Cost Analysis | LCM-001 |
+| LCM-007 | Resource Decommission | Decommission resources individually or as part of group decommission | Handle decommission payloads; release resources | Manage decommission workflows; coordinate dependency teardown | LCM-001 |
+
+---
+
+## 6. Drift Detection and Remediation
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| DRF-001 | Active Discovery | — | Expose discovery endpoint; respond to interrogation queries | Configure discovery schedules; manage Discovered Store | PRV-005 |
+| DRF-002 | Drift Comparison | Receive drift notifications for owned resources | — | Configure drift detection policies; manage comparison logic | DRF-001, PRV-005 |
+| DRF-003 | Drift Notification | Receive actionable drift alerts with field-level detail | — | Configure drift notification channels and escalation policies | DRF-002 |
+| DRF-004 | Drift Remediation | Approve or reject automatic drift remediation | Execute remediation payloads | Configure remediation policies (revert/update/alert/escalate) | DRF-002, LCM-002 |
+| DRF-005 | Unsanctioned Change Detection | Receive alerts on unauthorized resource modifications | Report all external state changes to DCM | Configure unsanctioned change policies | DRF-001 |
+
+---
+
+## 7. Policy Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| POL-001 | Policy Authoring | — | Contribute provider-specific policy rules | Author and manage policies via API or GitOps ingress | IAM-003 |
+| POL-002 | Policy Validation and Shadow Mode | View shadow evaluation results on own requests | — | Configure shadow mode; review shadow results | POL-001 |
+| POL-003 | Policy Activation and Review | — | — | Manage policy review periods; authorize policy activation | POL-001, POL-002 |
+| POL-004 | Policy Group Management | — | — | Compose Policy Groups; manage profile assignments | POL-003 |
+| POL-005 | Profile Management | — | — | Configure deployment profiles; manage compliance domain groups | POL-004 |
+| POL-006 | External Policy Evaluation | — | Register as external evaluation endpoint; implement BBQ-001–009 governance | Configure external evaluation trust levels; manage trust elevation | PRV-001, POL-001 |
+| POL-007 | Policy Override and Constraint Visibility | View constraint details for service catalog fields | Declare constraint schemas on Resource Type Specs | Configure constraint visibility levels per profile | CAT-002, POL-003 |
+| POL-008 | Constraint Type Registry | — | — | Register constraint types with OpenAPI v3 schemas; configure emittable_by/consumable_by; manage core and organization tiers | POL-001 |
+| POL-009 | Evaluation Context and Multi-Pass Convergence | — | — | Configure max evaluation passes; monitor convergence; manage escalation for unresolvable conflicts | POL-001, POL-008 |
+| POL-010 | Policy Templates | — | Contribute policy templates with parameterized Rego | Register templates (Gatekeeper ConstraintTemplate pattern); validate parameter schemas and constraint type references | POL-001, POL-008 |
+| POL-011 | DCM Constraint Types Library | — | — | Manage auto-generated Rego library (data.dcm.constraint_types); sync with Constraint Type Registry | POL-008, POL-010 |
+| POL-012 | Data-Driven Policy Matching | — | — | Configure match sources (request payload, operation context, evaluation context, entity metadata); validate match fields at activation | POL-001 |
+| POL-013 | Lifecycle-Scoped Policy Evaluation | — | — | Configure lifecycle_scope per policy (which operation types trigger it); enforce profile minimums (fsi/sovereign require sovereignty policies on all operations); configure changed_field_filter for update/scale operations | POL-001, POL-012 |
+| POL-014 | Override Policies | — | — | Author override policies targeting specific policies for defined scopes; enforce expiry and review dates; cannot target hard enforcement policies | POL-001, POL-003 |
+| POL-015 | Exception Grants | — | — | Create time-bounded, scope-limited waivers with compensating controls; track usage count; enforce dual-approval for hard policies; manage renewal limits | POL-001, AUD-008 |
+| POL-016 | Manual Override | Submit override request for blocked request with justification | — | Grant single-request overrides; enforce dual-approval for hard policies; manage override authority roles | POL-001, IAM-001 |
+| POL-017 | Dual-Approval Escalation | — | — | Configure role separation requirements; manage approval workflow for hard policy overrides; enforce fsi/sovereign dual-approval on all overrides | POL-001 |
+| POL-018 | Compensating Control Substitution | — | — | Define substitute control sets that satisfy policy intent through different mechanisms; require compliance officer validation | POL-001 |
+| POL-019 | Override Approval Flow | Submit override request for blocked request; view pending overrides awaiting approval | — | Configure override notification routing (internal, webhook); configure timeout per profile; configure escalation rules; manage override authority roles | POL-016, IAM-001 |
+| POL-020 | Override Notification Routing | — | — | Configure per-profile notification channels (LISTEN/NOTIFY, webhook to ServiceNow/Jira/Slack); configure routing by policy domain and enforcement level; configure escalation timeouts | POL-019 |
+| POL-021 | Policy Block Resolution | View blocking details, resolution guidance with compliant values; choose resolution action (modify, request override, cancel, escalate) | — | Configure block timeout per profile; configure resolution guidance generation; manage escalation routing | POL-001 |
+
+---
+
+## 8. Data Layer Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| LAY-001 | Core Layer Authoring | — | — | Author and manage Core and Organizational Layers in GitOps | IAM-003 |
+| LAY-002 | Service Layer Contribution | — | Contribute Service Layers for offered resource types | Manage layer compatibility declarations | PRV-001, LAY-001 |
+| LAY-003 | Layer Cache Management | — | — | Manage Layer Cache synchronization; handle cache invalidation | LAY-001, LAY-002 |
+| LAY-004 | Layer Exclusion | Declare layer exclusions on specific requests | — | Configure which layers may be excluded; manage non-excludable declarations | REQ-003 |
+| LAY-005 | Layer Versioning and Lifecycle | — | — | Manage layer versions; handle deprecation; enforce immutability | LAY-001 |
+
+---
+
+## 9. Information and Data Integration
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| INF-001 | Information Provider Registration | — | Register Information Provider; declare authority scope and schema | Configure Information Provider Registry; manage authority layers | IAM-001 |
+| INF-002 | Information Provider Push | — | Push field value updates to DCM; respond to conflict notifications | Configure ingestion pipeline; manage conflict resolution policies | INF-001 |
+| INF-003 | Information Provider Pull / Discovery | — | Expose data query endpoint for DCM pull operations | Configure pull schedules; manage cache TTLs | INF-001 |
+| INF-004 | Write-Back | — | Implement write-back endpoint to receive DCM-initiated updates | Configure write-back triggers via policy | INF-001, INF-002 |
+| INF-005 | Confidence Score Visibility | View confidence bands on entity field values; query confidence aggregation API | — | Configure confidence scoring formula; manage trust score thresholds | INF-001 |
+| INF-006 | Conflict Resolution Management | — | — | Review and resolve contested field values; manage conflict escalation | INF-002 |
+
+---
+
+## 10. Ingestion and Brownfield Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| ING-001 | Resource Discovery and Ingestion | — | Expose discovery endpoints for brownfield resources | Configure ingestion pipeline; manage __transitional__ Tenant | DRF-001 |
+| ING-002 | Ingested Entity Review | — | — | Review ingested entities; resolve conflicts; promote to active Tenants | ING-001 |
+| ING-003 | Bulk Promotion | — | — | Execute bulk entity promotions with preview and rollback | ING-002 |
+| ING-004 | Catalog Item Association | — | — | Associate ingested entities with Resource Type Specs; create catalog items | ING-002, CAT-001 |
+
+---
+
+## 11. Audit and Compliance
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| AUD-001 | Audit Trail Access | Query audit records for own resources | — | Configure Audit Store; manage retention policies | IAM-003 |
+| AUD-002 | Compliance Reporting | — | — | Generate compliance reports; manage report schedules | AUD-001 |
+| AUD-003 | Merkle Tree Verification | — | — | Run inclusion proofs, consistency proofs, request chain verification; manage integrity incidents | AUD-001 |
+| AUD-004 | Cross-DCM Audit Correlation | — | — | Correlate audit records across DCM instances via correlation_id; authorize cross-DCM pulls | AUD-001, DCM-001 |
+| AUD-005 | Audit Record Retention Management | — | — | Configure reference-based retention; manage post-lifecycle retention | AUD-001 |
+| AUD-006 | Audit Granularity Configuration | — | — | Configure granularity level per profile (stage, mutation, field); enforce minimum for fsi/sovereign | AUD-001 |
+| AUD-007 | Signed Tree Heads | — | — | Configure STH interval; manage audit signing keys; publish STH for external verification | AUD-001 |
+| AUD-008 | Payload Chain of Custody | View chain-of-custody proof for own requests | Verify dispatched payload matches DCM's signed output | Verify full pipeline integrity via request chain verification API | AUD-003 |
+| AUD-009 | Inter-Stage Verification | — | — | Configure verification mode per profile (synchronous, asynchronous, disabled) | AUD-001 |
+
+---
+
+## 12. Observability and Operations
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| OBS-001 | Operational Dashboard | View health and status of own resources | — | Configure and manage observability dashboard | — |
+| OBS-002 | Metrics and Telemetry Export | — | Expose resource-level metrics to DCM | Configure observability export; integrate enterprise observability platform | — |
+| OBS-003 | Curated Event Stream Subscription | Subscribe to observability event types via Message Bus | — | Configure event stream publication policies; manage subscriber roles | OBS-002 |
+| OBS-004 | Alert and Notification Management | Receive resource and policy alerts via declared channels | — | Configure alert routing; manage notification channels and escalation | OBS-001 |
+
+| OBS-006 | SLA/SLO Declaration | View SLO status for owned resources (`GET /resources/{uuid}/slo-status`) | Declare resource_type SLOs in Resource Type Specification; report realization timing via callbacks | Configure SLO targets per resource type; view aggregate SLO performance report (`GET /admin/slo/report`) | RLM-001, LCM-001 |
+| OBS-007 | SLO Breach Detection and Notification | Receive `slo.breach_approaching` and `slo.breach_detected` events | — | Configure SLO breach routing and escalation; review aggregate breach reports | OBS-006, EVT-001 || OBS-005 | Cost Analysis and Attribution | View cost estimates and actuals for owned resources | Provide cost metadata; report utilization | Configure Cost Analysis component; manage cost attribution policies | PRV-006 |
+
+---
+
+## 13. Storage and State Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| STO-001 | Data Store Management | — | — | Configure PostgreSQL data domains (intent, requested, realized, discovered); manage schema, RLS, and tenant isolation | — |
+| STO-002 | Realized State Management | — | — | Configure realized_entities table; manage version retention and is_current flag | PRV-005 |
+| STO-003 | Discovered State Management | — | — | Configure discovered_records table; manage retention policies per profile | DRF-001 |
+| STO-004 | Search and Query | Use entity and catalog search | — | Configure materialized views and indexes; manage cache refresh | STO-001 |
+| STO-005 | Backup and Recovery | — | — | Configure PostgreSQL backup (PITR); test recovery; verify audit hash chain integrity | STO-001 |
+| STO-006 | Provenance Model Configuration | — | — | Select and configure provenance model (full_inline / deduplicated / tiered); manage tier transitions | STO-001 |
+| STO-007 | Sovereignty Partitioning | — | Declare sovereignty constraints at registration | Configure separate PostgreSQL instances per sovereignty zone; manage cross-zone prohibition | STO-001, GOV-001 |
+| STO-008 | Tenant-Scoped Storage Isolation | Data is isolated by tenant via RLS | — | Configure RLS policies per table; enforce STI-001 through STI-004 | STO-001, IAM-001 |
+| STO-009 | Tenant-Scoped Encryption (fsi/sovereign) | — | — | Configure per-tenant AES-256-GCM encryption via secrets management; manage key rotation | STO-008, CPX-001 |
+| STO-010 | Internal Secrets Management | — | — | Configure envelope encryption (KEK source: env var, K8s secret, or HSM); manage secrets table; optional Vault external backend | STO-001 |
+| STO-011 | Pipeline Event Routing | — | — | Configure LISTEN/NOTIFY for pipeline events; optional Kafka for high-throughput; manage consumption tracking | STO-001 |
+| STO-012 | Internal Authentication | — | — | Configure local actor accounts (argon2id hashes, DCM-issued JWT); optional OIDC/SAML external auth_provider | STO-001, IAM-001 |
+
+---
+
+## 14. DCM Federation and Multi-Instance
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| FED-001 | DCM Provider Registration | Submit requests that are routed to peer DCMs | Register as DCM Provider in peer instances | Configure DCM Provider registrations; manage federation trust | PRV-001, IAM-001 |
+| FED-002 | Federation Routing | Requests automatically routed to appropriate Regional/Sovereign DCM | Respond to reserve queries from Hub DCM | Configure federation placement policies; manage sovereignty pre-filters | FED-001, REQ-005 |
+| FED-003 | Federation Trust Management | — | — | Manage mTLS certificates; monitor federation trust scores; handle cert rotation | FED-001 |
+| FED-004 | Cross-DCM Drift Detection | Receive drift alerts for federated resources | Publish Discovered State events to federation Message Bus | Configure federated drift detection; manage alert-and-hold policies | FED-001, DRF-002 |
+| FED-005 | DCM Export and Import | — | — | Export and import DCM state packages; verify import trust scores | STO-001, STO-002 |
+
+---
+
+## 15. Platform Governance and Administration
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| GOV-001 | Tenant Management | — | — | Create, configure, and decommission Tenants; manage compliance overlays | IAM-007 |
+| GOV-002 | Group Management | — | — | Create and manage DCM Groups; configure sovereignty rules; manage time-bounded memberships | IAM-003 |
+| GOV-003 | Registry Management | — | Register and maintain Resource Type Specifications in organization registry | Manage registry sync; configure registry policies; manage Tier 3 types | PRV-001 |
+| GOV-004 | Resource Type Lifecycle | — | Manage deprecation notices; declare successor types; maintain migration guidance | Enforce deprecation timelines; manage sunset periods | GOV-003 |
+| GOV-005 | Platform Configuration Management | — | — | Manage platform-wide layers; configure profiles; manage deployment manifest | LAY-001, POL-005 |
+| GOV-006 | Bootstrap and Self-Hosting | — | — | Manage DCM self-deployment; verify bootstrap manifest; handle repave scenarios | STO-001 |
+
+| GOV-008 | Tenant Onboarding Workflow | Trigger onboarding completion: receive `tenant.onboarding_complete` when first entity OPERATIONAL | — | Execute full provisioning sequence: tenant entity, default groups, quota, admin actor, GitOps namespace, audit stream; dispatch `tenant.created` and member invitation events | IAM-001, STO-008 || GOV-007 | Sovereign Deployment Management | — | — | Manage air-gapped DCM instances; configure signed bundle import; manage offline registry | FED-001, STO-001 |
+
+---
+
+## 16. Accreditation Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| ACC-001 | Accreditation Submission | — | Submit accreditation records (BAA, ISO 27001, FedRAMP, etc.) referencing external certificate evidence | Register accrediting bodies; configure minimum accreditation types per profile | PRV-001 |
+| ACC-002 | Accreditation Review and Approval | — | Receive approval/rejection notification | Review submitted accreditations; verify certificate references; approve or reject via Admin API | ACC-001 |
+| ACC-003 | Accreditation Lifecycle Monitoring | Receive notification when a provider's accreditation is nearing expiry or revoked | Renew accreditations before expiry; submit renewal documentation | Monitor expiry timelines; fire P90D renewal warnings; handle accreditation gaps | ACC-001 |
+| ACC-004 | Accreditation Gap Response | Receive notification when a provider enters accreditation gap affecting owned resources | — | Configure Recovery Policy for accreditation gap events; manage affected entity remediation | ACC-003, POL-005 |
+| ACC-005 | Data Classification Enforcement | Receive enforcement feedback when request payload contains data the selected provider cannot handle | Declare max_data_classification_accepted in capability registration | Configure classification immutability rules; manage phi/sovereign classification locks | ACC-001, PRV-001 |
+| ACC-006 | DCM Deployment Accreditation | — | — | Register DCM deployment-level accreditations; expose to federation peers for trust verification | PRV-001, FED-001 |
+
+---
+
+## 17. Zero Trust and Security Posture
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| ZTS-001 | Mutual TLS Enforcement | All interactions authenticated via mTLS at the client side | Present valid mTLS certificate on every interaction; rotate certificates on declared schedule | Configure trust anchors; manage CA chain; enforce mTLS at all interaction boundaries | IAM-001 |
+| ZTS-002 | Scoped Interaction Credentials | Receive scoped short-lived credentials for authorized operations | Validate credential scope before executing operations; reject out-of-scope credentials | Configure credential lifetime per profile; manage credential issuance via secrets management | IAM-001, PRV-001 |
+| ZTS-003 | Certificate Rotation Management | — | Implement certificate rotation before expiry; use transition window to avoid downtime | Monitor certificate expiry; fire P14D rotation warnings; manage P7D transition window | ZTS-001 |
+| ZTS-004 | Zero Trust Posture Configuration | — | — | Configure zero_trust_posture per profile (none/boundary/full/hardware_attested); manage posture overrides | POL-005 |
+| ZTS-005 | Hardware Attestation (Sovereign Profile) | — | Present hardware-attested identity (TPM/HSM) for sovereign profile interactions | Configure hardware attestation requirements; manage HSM integration; enforce for sovereign profile | ZTS-001, ZTS-002 |
+
+| ZTS-007 | Provider OpenAPI Spec Signing (SEC-001) | — | Sign OpenAPI spec with mTLS private key at registration; rejected at GATE-SP-01 if unsigned | Verify signature during registration approval pipeline | PRV-001, ZTS-001 |
+| ZTS-008 | GitOps Secrets Scanning (SEC-002) | Commits with detected secrets rejected with `SECRETS_DETECTED` audit record | Ensure service layer SCM does not contain plaintext secrets | Configure scanning ruleset; review and remediate detected secrets | GOV-001, AUD-001 |
+| ZTS-009 | Software Bill of Materials (SBOM) Declaration (SEC-003) | — | Declare SBOM reference at registration (mandatory for fsi/sovereign) | Enforce SBOM requirement during registration approval for fsi/sovereign profiles | PRV-001, ACR-001 || ZTS-006 | Five-Check Boundary Enforcement | — | Pass all five boundary checks on every interaction: identity → authorization → accreditation → matrix → sovereignty | Monitor boundary check audit records; respond to INTERACTION_DENIED events | ZTS-001, ACC-001, GMX-001 |
+
+---
+
+## 18. Unified Governance Matrix
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| GMX-001 | Governance Matrix Rule Authoring | — | — | Author governance matrix rules in GitOps; declare match conditions across four axes (subject/data/target/context); declare field permissions | POL-001 |
+| GMX-002 | Boundary Enforcement Evaluation | Receive DENY response with governing rule_uuid and human-readable reason when a request crosses a prohibited boundary | Receive field-stripped or redacted payloads when STRIP_FIELD/REDACT decisions apply | Monitor GMX evaluation audit records; respond to DENY events | GMX-001, ZTS-006 |
+| GMX-003 | Field-Level Data Control | Receive request feedback when specific payload fields are stripped or redacted by active matrix rules | Receive filtered payloads; handle missing optional fields gracefully | Configure allowlist/blocklist field permissions per rule; manage STRIP_FIELD vs REDACT vs DENY_REQUEST escalation | GMX-001 |
+| GMX-004 | Sovereignty Zone Management | — | Declare operating sovereignty zones in provider registration | Register sovereignty zones; declare jurisdictions, regulatory frameworks, inter-zone agreements | PRV-001, GMX-001 |
+| GMX-005 | Compliance Domain Matrix Activation | — | — | Activate compliance domain matrix rules (HIPAA, GDPR, etc.) by enabling compliance domain in profile; rules apply automatically | POL-005, GMX-001 |
+| GMX-006 | Tenant and Resource-Type Matrix Overrides | — | — | Declare Tenant-level and resource-type-level matrix rules that tighten (never relax) platform defaults | GMX-001, GOV-001 |
+| GMX-007 | Matrix Rule Lifecycle Management | — | — | Manage governance matrix rule lifecycle (developing → proposed → active); use shadow mode for safe validation before activation | GMX-001, POL-002 |
+
+---
+
+## 19. Drift Reconciliation
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| DRC-001 | Drift Record Production | Receive drift records with field-level detail: realized value, discovered value, field criticality, severity, unsanctioned flag | — | Configure Drift Reconciliation Component; manage comparison algorithm and severity thresholds | DRF-001, PRV-005 |
+| DRC-002 | Unsanctioned Change Classification | Receive elevated-severity alert when change has no corresponding Requested State record | — | Configure unsanctioned change detection; manage severity escalation rules | DRC-001 |
+| DRC-003 | Drift Severity Classification | Receive severity-classified drift records (minor/significant/critical) based on field criticality × change magnitude | — | Declare field criticality in Resource Type Specifications; configure magnitude thresholds per profile | DRC-001, GOV-003 |
+| DRC-004 | Drift Resolution Tracking | View drift record status (open/acknowledged/resolved/escalated); receive resolved notification when next discovery confirms clean state | — | Monitor drift resolution rates; configure escalation policies for aged-open drift records | DRC-001, DRF-004 |
+| DRC-005 | Governance Matrix Drift Integration | — | — | Configure governance matrix check in drift comparison pipeline: expected provider changes are not flagged as drift | DRC-001, GMX-001 |
+
+
+## 20. Federated Contribution Model
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| FCM-001 | Consumer Policy Authoring | Author and submit tenant-domain policies (GateKeeper, Transformation, Recovery, Lifecycle, Orchestration Flow, Governance Matrix rules) via API or Flow GUI; receive PR URL and shadow mode results | — | Configure consumer policy authoring permissions (policy_author role); manage review requirements per profile | POL-001, IAM-003, IAM-007 |
+| FCM-002 | Provider Resource Type Publication | — | Publish Resource Type Specifications and Catalog Items for offered resource types via provider contribution API; receive registry PR for platform admin review | Manage provider contribution registry; configure review requirements for provider specs; manage Organization-tier registry | PRV-001, GOV-003 |
+| FCM-003 | Provider Service Layer Contribution | — | Contribute Service Layers for offered resource types; layers applied during request assembly for all consumers requesting that resource type | Review and activate provider-contributed layers; manage layer compatibility | PRV-001, LAY-002 |
+| FCM-004 | Consumer Resource Group and Definition Contribution | Author and manage resource groups, notification subscriptions, webhook registrations, and cross-tenant authorization records within own Tenant | — | Configure contribution permissions per role; manage Tenant-scoped artifact lifecycle | IAM-007, GOV-002 |
+| FCM-005 | Federation Contribution (Peer DCM) | — | Peer DCM contributes registry entries, policy templates, and service layers via federation channels | Manage federation contribution trust posture (verified/vouched/provisional); configure review requirements per trust posture; manage cross-DCM artifact lifecycle | FED-001, GOV-003, POL-003 |
+| FCM-006 | Contribution Review and Lifecycle | View contribution status (proposed, pending_review, active, withdrawn); withdraw a pending contribution; receive notification when contribution is approved or rejected | Receive notification when provider contributions are reviewed | Review and approve/reject contributions via Admin API; manage shadow review periods; assign new owners to orphaned artifacts | POL-002, POL-003 |
+| FCM-007 | Contributor Scope Enforcement | Receive clear DENY response when attempting to contribute outside permitted domain scope | Receive DENY when contributing specs for resource types not offered | Monitor Governance Matrix enforcement at contribution time; configure scope violation audit and notification | GMX-001, GMX-002 |
+
+---
+
+
+## 21. Scoring Model
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| SMX-001 | Operational GateKeeper Scoring | Receive risk score and score_drivers with request acknowledgment; understand why score is at its level | Declare `enforcement_class: operational` and `scoring_weight` on contributed GateKeeper policies | Configure operational GateKeeper policies with appropriate weights; manage per-policy enforcement class | POL-001, REQ-004 |
+| SMX-002 | Advisory Validation and Completeness Score | Receive advisory_warnings list with request acknowledgment; understand what optional improvements exist | Declare `output_class: advisory` on advisory Validation policies | Configure advisory Validation policies; manage completeness score thresholds | POL-001, REQ-004 |
+| SMX-003 | Actor Risk History Tracking | View own risk history score and contributing events via Consumer API | — | Monitor actor risk history; reset scores for trusted automation accounts; configure decay parameters | AUD-001, IAM-001 |
+| SMX-004 | Quota Pressure Scoring | Receive quota_pressure as a score driver when approaching Tenant quota limits | — | Configure per-resource-type quota limits; manage free_threshold parameter | IAM-007, REQ-004 |
+| SMX-005 | Provider Accreditation Richness Scoring | — | Benefit from lower risk contribution by maintaining rich accreditation portfolio | Configure accreditation richness weights; manage portfolio scoring | ACC-001, PRV-001 |
+| SMX-006 | Profile Scoring Threshold Management | — | — | Configure approval routing thresholds per profile (auto/reviewed/verified/authorized + custom tiers via named-tier list); manage signal weights; enforce SMX-008 (max auto_approve_below: 50) | POL-005, REQ-004 |
+| SMX-007 | Policy Enforcement Class Override | — | Contribute policies with declared enforcement_class; receive notification when profile overrides enforcement class | Declare per-profile enforcement class overrides; manage regulatory_mandate flag to protect compliance-class policies from demotion | POL-004, POL-005 |
+| SMX-008 | Score Audit Trail | Query risk score and routing decision for own requests; view score_drivers and advisory_warnings | — | Query full Score Record detail including signal breakdown and actor risk history; manage score audit retention | AUD-001, REQ-004 |
+| SMX-009 | Scoring Weight Range Enforcement | — | Declare operational GateKeeper scoring_weight between 1 and 100 | Enforce weight range at policy activation; reject out-of-range weights | SMX-001 |
+| SMX-010 | Score Breakdown Audit Inclusion | View score breakdown in request audit record | — | Configure score breakdown storage in Audit Store for all scored requests | SMX-001, AUD-001 |
+
+---
+
+
+## 22. Compound Service Composability
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| MPX-001 | Compound Service Request | Request a compound service as a single catalog item; receive composite entity UUID; track compound execution status via standard request status endpoint | Register as Compound Service with constituent specification; implement compound dispatch endpoint | Configure Compound Service registration; manage composite service catalog items | CAT-001, REQ-007, PRV-001 |
+| MPX-002 | Dependency-Ordered Constituent Execution | — | Execute constituents in declared dependency order; manage parallel rounds; respect depends_on declarations | Configure composition model; monitor execution round progress via status events | MPX-001, PRV-003 |
+| MPX-003 | Partial Delivery and DEGRADED State | Receive DEGRADED composite entity when partial delivery is accepted; choose to accept or reject degraded state | Declare partial_delivery_supported and required_for_delivery per constituent; return DEGRADED compound payload | Configure accept_degraded_delivery per profile; manage degraded notification urgency | MPX-001, PRV-005 |
+| MPX-004 | Compound Compensation | Receive notification and recovery decision when compound service fails; approve or reject compensation | Implement compensation in dependency-reverse order; guarantee idempotent decommission calls | Configure compensation timeout; manage PARTIALLY_COMPENSATED orphan detection | MPX-001, LCM-007, DRC-001 |
+| MPX-005 | Transparent Constituent Visibility | Query and manage DCM-visible constituent entities independently (when transparency mode); receive constituent-level drift alerts | Declare composition_visibility mode; register transparent constituents with deterministic UUIDs | Configure visibility mode per compound resource type; manage constituent entity lifecycle policies | MPX-001, DRF-001 |
+| MPX-006 | Compound Execution Status Tracking | Monitor compound execution round progress via request status; see component-level status during long-running compositions | Send intermediate status events to DCM during execution; declare status_reporting.interval | Monitor compound execution health; configure execution timeout alerts | MPX-001, REQ-008 |
+| MPX-007 | Nested Compound Service Composition | Request high-order compound services composed of other compound services (max depth 3) | Implement as a Compound Service that calls other Compound Services as constituents; declare max_nesting_depth | Configure nesting depth limits; manage nested compensation chains | MPX-001, PRV-009 |
+| MPX-008 | Compound Service Nesting Depth Enforcement | — | Declare nesting depth in Compound Service registration | Enforce maximum nesting depth of 3 at placement time; reject deeper compositions | MPX-001 |
+
+---
+
+
+## 23. Credential Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| CPX-001 | Resource Credential Issuance | Receive credential metadata and retrieval URL with realized resource; retrieve credential value via authenticated endpoint | Declare credential requirements in Resource Type Spec; receive credential issuance confirmation | Register service_provider with Credential.* resource types; configure credential types and lifetimes per resource type; manage issuance policies | PRV-005, ZTS-002 |
+| CPX-002 | DCM Interaction Credential Issuance | — | Validate scoped interaction credential on every DCM dispatch; reject interactions without valid scoped credential (CPX-002) | Configure interaction credential lifetime per profile; manage secrets table for DCM-internal credentials | ZTS-002, PRV-001 |
+| CPX-003 | Credential Rotation | Receive rotation notification before old credential expires; retrieve new credential during transition window | Implement rotate endpoint; honor transition window; notify DCM when rotation is complete | Configure rotation schedules and transition windows per credential type; manage pre-expiry rotation warnings | CPX-001, IAM-001 |
+| CPX-004 | Emergency Rotation and Security Event Response | Receive immediate notification on emergency rotation; retrieve new credential via fastest channel | Implement immediate revocation with no transition window on security_event trigger | Configure security event triggers; manage emergency rotation audit trail; notify platform admin | CPX-003, OBS-004 |
+| CPX-005 | Credential Revocation | Receive revocation notification when credentials are revoked (actor deprovisioned, entity decommissioned); confirm transition to new credential | Implement revoke endpoint with declared SLA; invalidate value immediately on emergency revocation | Manage Credential Revocation Registry; configure revocation cache TTL per profile (PT1M standard, PT30S fsi/sovereign); enforce CPX-007 (decommission blocks on credential revocation) | CPX-001, LCM-007 |
+| CPX-006 | Revocation Propagation | — | Refresh revocation cache within profile-governed TTL; validate credential UUID against cache at use time (not only at receipt) | Configure revocation cache TTL; monitor revocation propagation latency; alert on SLA violations | CPX-005, IAM-001 |
+| CPX-007 | Audit Trail for Credential Lifecycle | View own credential record history (issue, rotate, revoke events); every value retrieval audited with retrieval_uuid | — | Query full credential audit trail including retrieval count; manage credential audit retention | CPX-001, AUD-001 |
+| CPX-008 | IP-Bound Credentials for fsi/sovereign | — | — | Enforce IP binding (bound_to_ip) on all credentials issued for fsi and sovereign profiles | CPX-001, ZTS-002 |
+| CPX-009 | Algorithm and Key Usage Declaration | — | Declare algorithm and key_usage on credential records at issuance | Enforce declaration at issuance; reject credentials without declared algorithm | CPX-001 |
+| CPX-010 | Idle Credential Detection | Receive notification when credential reaches idle threshold | — | Configure idle_detection_threshold per profile; enforce alert-only action | CPX-001 |
+| CPX-011 | Compliance Domain Additive Credential Requirements | — | — | Enforce additive credential requirements when compliance domains are active on a profile | CPX-001, POL-005 |
+| CPX-012 | Credential Value Store Isolation (All Profiles) | — | — | Enforce credential values never stored in DCM stores in ALL profiles including minimal | CPX-001 |
+
+---
+
+
+## 24. Authority Tier Model
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| ATM-001 | Authority Tier Registry | Reference approval decisions by tier name; tier weight resolved dynamically from ordered list | Implement approval workflows that reference tier names (not hardcoded weights) | Manage the ordered authority tier list; control tier positions and gravity values | POL-005 |
+| ATM-002 | Custom Tier Definition | — | — | Contribute custom tiers between existing tiers; declare decision_gravity and dcm_gate semantics; requires verified-tier approval | ATM-001, FCM-001 |
+| ATM-003 | Dynamic Threshold Configuration | View which tier an action routes to | — | Configure profile approval_routing as named-tier threshold list; adjust score ranges when new tiers inserted | ATM-001, SMX-001 |
+| ATM-004 | Tier Registry Change Impact Detection | Receive notification when tier changes affect owned resources or pending approvals | — | Propose tier registry changes; receive tier impact diff report; review SECURITY_DEGRADATION and BROKEN_REFERENCE items; accept degradations via Admin API | ATM-001, AUD-001 |
+| ATM-005 | Degradation Review Gate | — | — | Review and explicitly accept each SECURITY_DEGRADATION item before a registry change activates; provide compensating control rationale; must hold verified or authorized tier reviewer role | ATM-004, IAM-001 |
+| ATM-006 | Profile Gap Detection | — | — | Receive PROFILE_GAP warnings when tier registry changes leave profile threshold lists incomplete; update threshold lists or acknowledge gap within approval window | ATM-003, ATM-004 |
+| ATM-007 | Tier Registry Audit Trail | Query historical tier registry versions and impact reports | — | Access full audit trail of all tier registry changes: proposal, impact assessment, degradation acceptances, activation | ATM-004, AUD-001 |
+| ATM-008 | Approval Record Tier Weight Snapshot | — | — | Store tier name and resolved weight at approval record creation; historical records retain weight for audit comparison across regime changes | ATM-001 |
+| ATM-009 | Tier Registry Degradation Gate | Receive notification when tier change produces degradation affecting owned resources | — | Block tier registry activation on SECURITY_DEGRADATION items; require verified-tier acceptance per item | ATM-001 |
+| ATM-010 | Broken Reference Gate | — | — | Block tier registry activation when BROKEN_REFERENCE items exist (removed tier still referenced in active config) | ATM-001 |
+| ATM-011 | Tier Change Impact Report | — | — | Generate and store tier impact report in Audit Store at proposal and activation time | ATM-001, AUD-001 |
+| ATM-012 | Profile Gap Warning on Tier Insertion | — | — | Detect PROFILE_GAP when new tier inserted but profile threshold list not updated; emit non-blocking warning | ATM-001, POL-005 |
+
+---
+
+
+## 25. Event Catalog
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| EVT-001 | Event Subscription | Subscribe to DCM events via notification service_provider or Message Bus; filter by event type, entity type, urgency; idempotency via event_uuid | Publish standard events when provider actions occur; use reverse-DNS prefix for non-standard events | Configure notification service_provider channels and audience routing | IAM-001, OBS-001 |
+| EVT-002 | Request Pipeline Events | Receive real-time status of own requests (submitted → intent_captured → policies_evaluated → requires_approval → approved → dispatched → realized/failed) | — | Configure request event delivery per profile; manage urgency routing | REQ-001 |
+| EVT-003 | Entity Lifecycle Events | Receive entity lifecycle events (realized, state_changed, ttl_warning, decommissioning, etc.) for owned entities and entities with stakes | — | Configure entity event delivery; manage stakeholder audience routing | LCM-001 |
+| EVT-004 | Security and Critical Events | Receive critical security events (audit chain alerts, sovereignty violations, unsanctioned provider writes) regardless of subscription preferences | — | Configure non-suppressable event delivery; manage security team routing | AUD-001, ZTS-001 |
+| EVT-005 | Approval Pipeline Events | Receive approval events (requires_approval, decision_recorded, quorum_reached, window_expiring, expired) for own requests and approvals | — | Configure reviewer notification routing; manage approval window alerts | ATM-001, IAM-001 |
+| EVT-006 | Provider and Infrastructure Events | — | Publish provider health events (registered, healthy, unhealthy, degraded); publish provider_update events on entity changes | Monitor provider health events; configure provider degradation alerts | PRV-001 |
+| EVT-007 | Tier Registry and Governance Events | — | — | Receive tier_registry events (proposed, impact_assessed, degradation_detected, activated); configure governance event routing | ATM-004 |
+
+---
+
+
+## 26. API Versioning
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| VER-001 | Version Discovery | Discover available API versions and their status via `GET /.well-known/dcm-api-versions`; learn current, supported, and deprecated versions; get changelog and migration guide URLs | Declare supported OIS version in capability registration | Monitor version adoption; manage sunset schedules | — |
+| VER-002 | Breaking Change Governance | Receive at least the profile-governed deprecation notice period before a breaking change takes effect; continue using deprecated versions until sunset date | Receive OIS version deprecation notice; migrate to new OIS version before sunset | Declare new major versions; configure deprecation timeline per profile; ensure VER-002 (breaking change definition) is applied | VER-001 |
+| VER-003 | Deprecation Headers | Receive `Deprecation`, `Sunset`, and `Link` headers on all responses from deprecated API versions (RFC 8594/RFC 9745); use these to drive migration priority | — | Configure header injection for deprecated versions; ensure headers are accurate | VER-002 |
+| VER-004 | Migration Guide | Access machine-readable migration guide at `GET /api/v{N}/migration-guide`; understand all breaking changes from previous version with migration instructions | Access OIS migration guide at `GET /provider/api/v{N}/migration-guide` | Maintain migration guides for all new major versions (required by VER-008) | VER-002 |
+| VER-005 | Preview Endpoints | Access preview endpoints at `/api/v{N}/preview/`; understand stability commitment is none; provide feedback before graduation | — | Mark endpoints as preview; graduate to stable in new major version | VER-001 |
+| VER-006 | Latest Alias Production Warning | — | — | Support `latest` version alias; emit response header discouraging production use | VER-001 |
+| VER-007 | Preview Endpoint Instability Declaration | — | — | Mark preview endpoints explicitly; may change or be removed without major version bump | VER-001 |
+| VER-009 | Provider Dispatch Compatibility | — | Maintain backward compatibility with DCM dispatch payloads from supported prior versions | Manage provider dispatch versioning; maintain supported version matrix | VER-001 |
+
+---
+
+
+## 27. Session Revocation
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| SES-001 | Session Lifecycle Management | View own active sessions; logout single session (DELETE /api/v1/auth/session); logout all sessions; revoke specific session by UUID | — | Force revoke sessions for any actor; view session store health | IAM-001, AUTH-001 |
+| SES-002 | Actor Deprovisioning Session Revocation | — | — | Parallel session + credential revocation on actor deprovisioning; deprovisioning not acknowledged until both complete (AUTH-016) | SES-001, CPX-005 |
+| SES-003 | Emergency Session Revocation | Receive critical notification on security-event session revocation | — | Trigger emergency revocation (security_event); revocation propagates within profile SLA (PT5S sovereign to PT30S standard) | SES-001, EVT-001 |
+| SES-004 | Token Introspection | — | Call POST /api/v1/auth/introspect to validate bearer tokens without maintaining own revocation cache | Configure introspection endpoint access; manage introspection scope grants | SES-001, IAM-001 |
+| SES-005 | Concurrent Session Enforcement | Oldest session auto-revoked when new session exceeds concurrent limit; receive notification via notification service_provider | — | Configure concurrent_sessions limit per profile; monitor session counts | SES-001 |
+| AUTH-017 | Session Revocation Propagation SLA | — | — | Propagate revocation to Session Revocation Registry within profile SLA (PT5S sovereign → PT30S standard) | SES-001 |
+| AUTH-018 | Per-Request Revocation Registry Check | — | Check Session Revocation Registry on each request bearing a bearer token | Configure revocation registry query path; manage registry availability | SES-001 |
+| AUTH-019 | Emergency Revocation No-Grace Period | Receive critical notification on emergency revocation | — | Emergency session revocation fires immediately with no grace period | SES-003 |
+| AUTH-020 | Introspection Endpoint Authentication | — | Authenticate introspection calls using provider interaction credential | Configure introspection scope grants; manage endpoint access | SES-004 |
+| AUTH-021 | Oldest Session Revocation on Limit | Receive notification when oldest session is auto-revoked | — | Configure concurrent_sessions limit; enforce oldest-first revocation order | SES-005 |
+| AUTH-022 | Refresh Token Invalidation on Session Revoke | — | — | Invalidate refresh token when parent session is revoked; return REVOKED_SESSION error on use | SES-001 |
+
+---
+
+## 28. Internal Component Authentication
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| ICOM-001 | Component Identity and mTLS | — | — | Manage Internal CA; issue and rotate component certificates; all inter-component calls use mTLS (ICOM-001) | ZTS-001, CPX-001 |
+| ICOM-002 | Component Bootstrap | — | — | Generate one-time bootstrap tokens (PT1H max lifetime); components acquire first certificate via bootstrap token; token invalidated after single use (ICOM-007) | ICOM-001 |
+| ICOM-003 | Internal Call Authorization | — | — | Declare allowed_sources per internal endpoint; declare allowed_targets per component; unauthorized source calls rejected with ICOM_UNAUTHORIZED_SOURCE audit record (urgency: high) | ICOM-001, AUD-001 |
+| ICOM-004 | Internal Interaction Credentials | — | — | Every internal call presents a scoped ZTS-002 interaction credential in addition to mTLS; credential scoped to specific operation and target component | ICOM-001, CPX-002, ZTS-002 |
+| ICOM-005 | Component Certificate Revocation | — | — | Compromised component certificates added to Internal CA CRL immediately; CRL cache refresh within profile SLA (PT15S sovereign to PT1M standard); ICOM_CERT_COMPROMISED audit record (urgency: critical) | ICOM-001, AUD-001 |
+| ICOM-006 | Component Certificate Maximum Validity | — | — | Issue internal component certificates with maximum validity P90D; enforce expiry and rotation | ICOM-001 |
+| ICOM-008 | Compromised Certificate Immediate CRL | — | — | Add compromised internal component certificates to Internal CA CRL immediately; propagate within PT60S | ICOM-001 |
+| ICOM-009 | Trust Anchor Registration | — | — | Register root or intermediate CA as trust anchor for internal mTLS; reject certificates not chaining to registered trust anchor | ICOM-001 |
+
+---
+
+
+## 29. Scheduled and Deferred Requests
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| SCH-001 | Request Scheduling | Submit requests with schedule.dispatch: at/window/recurring; SCHEDULED requests visible in GET /api/v1/requests; cancellable before dispatch; receive request.scheduled event | — | Manage Maintenance Windows; configure Request Scheduler; monitor scheduled queue depth | REQ-001 |
+| SCH-002 | Maintenance Windows | Reference maintenance windows in scheduled requests; view available windows at GET /api/v1/maintenance-windows | — | Create/manage/suspend maintenance windows; approve window schedules; configure platform-wide windows | SCH-001, GOV-001 |
+| SCH-003 | Dual Policy Evaluation | — | — | Understand that scheduled requests run GateKeeper at declaration AND at dispatch; dispatch-time failure → FAILED with schedule_policy_rejection (SCH-003) | SCH-001, POL-001 |
+| SCH-004 | Deadline Enforcement | Set not_after on scheduled requests; receive request.failed(schedule_deadline_missed) if deadline passes without dispatch | — | Monitor deadline miss rates; configure alerting on deadline misses | SCH-001, EVT-001 |
+| SCH-005 | Not-After Expiry Failure | Receive FAILED status when scheduled request expires before dispatch | — | Configure not_after enforcement; manage SCHEDULE_EXPIRED recovery policy | SCH-001 |
+| SCH-006 | Maintenance Window Platform Authorization | — | — | Require platform_admin or tenant_admin authority to create/modify Maintenance Windows | SCH-004 |
+
+---
+
+## 30. Request Dependency Graph
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| RDG-001 | Dependency Group Submission | Submit POST /api/v1/request-groups with requests and depends_on declarations; local refs within submission; receive group_uuid and per-request entity_uuids | — | Monitor group queue depth; configure max group size | REQ-001 |
+| RDG-002 | Field Injection | Declare inject_fields to pass realized output fields (e.g. IP address) from dependency into dependent request fields automatically at dispatch time | — | — | RDG-001, REQ-001 |
+| RDG-003 | PENDING_DEPENDENCY Status | Track dependent requests in PENDING_DEPENDENCY status; cancel pending requests individually or cancel whole group; receive request.pending_dependency and request.dependency_met events | — | Monitor PENDING_DEPENDENCY queue depth; detect stalled groups | RDG-001, EVT-001 |
+| RDG-004 | Group Failure Handling | Configure on_failure: cancel_remaining or continue; group-level timeout; group status via GET /api/v1/request-groups/{uuid} | — | Monitor group failure rates | RDG-001 |
+| RDG-005 | Group-Level Timeout Enforcement | Receive TIMEOUT failure when group-level timeout elapses | — | Configure group_timeout independent of individual request timeouts | RDG-001 |
+| RDG-006 | Single Group Membership Enforcement | — | — | Reject attempts to add a request to more than one dependency group | RDG-001 |
+
+---
+
+## 31. DCM Self-Health
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| HLT-001 | Liveness Probe | — | — | GET /livez: fast liveness check (PT5S max, no external calls); Kubernetes restarts pod on failure; unauthenticated | — |
+| HLT-002 | Readiness Probe | — | — | GET /readyz: checks Session Store, Audit Store, Policy Engine, Message Bus, Auth Provider connectivity; Kubernetes removes from LB on failure; startup sequence observable via readyz | — |
+| HLT-003 | Component Health Detail | — | — | GET /api/v1/admin/health: per-component status (pass/warn/fail), metrics, queue depths, provider/auth summary; admin auth required | IAM-001 |
+| HLT-004 | Prometheus Metrics | — | — | GET /metrics: Prometheus scrape endpoint; request pipeline, policy, session, drift, provider, internal CA metrics | OBS-001 |
+| HLT-005 | Prometheus Metrics Endpoint | — | — | Expose Prometheus-compatible metrics at GET /metrics including request throughput, store latency, policy eval time, provider health counters | HLT-001 |
+| HLT-006 | Startup Readiness via /readyz | — | — | Report PASSING on /readyz only after all required stores available and bootstrap complete | HLT-001 |
+
+---
+
+
+## 32. Operational Reference
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| OPS-001 | Data Store Partitioning | — | — | Declare partitioning strategy in deployment manifest; execute tenant-shard, per-tenant, or time-based archiving migration; configure shard routing and mirror lag monitoring | STO-001 |
+| OPS-002 | Store Migration | — | — | Execute dual-write migration between store implementations; maintain audit chain continuity across cutover; enforce profile-governed burn-in before source decommission | STO-001, AUD-001 |
+| OPS-003 | Disaster Recovery | — | — | Execute scenario-specific recovery procedures (component/store/full-CP/repave); meet profile-governed RTOs (PT1M–PT15M component, PT5M–PT2H store, PT5M–PT30M full-CP); complete post-recovery validation checklist | HLT-001, AUD-001 |
+| OPS-004 | Backup Management | — | — | Configure PostgreSQL backup schedules (PITR for all data domains); enforce P365D minimum audit retention | STO-001 |
+
+---
+
+
+## 33. Web Interfaces
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| GUI-001 | Consumer Portal — Catalog, Requests, Resources | Browse catalog; live cost estimate; submit requests with scheduling and dependency groups; live SSE status with constituent tracking; cross-resource drift report; consumer-scoped audit trail with correlation ID trace | — | — | CAT-001, REQ-001, SCH-001, RDG-001, EVT-002 |
+| GUI-002 | Consumer Portal — Live Request Status | Real-time status via SSE stream (status_change, progress_updated, approval events, heartbeat); constituent status for compound requests; approval flow inline; fallback to polling | — | — | REQ-001, EVT-002 |
+| GUI-003 | Consumer Portal — Resource Management | View/filter owned resources by state and type; lifecycle state badges; drift indicator; resource detail with Overview/Drift/Audit/Cost/Credentials/Relationships/Groups tabs; state-sensitive action buttons; bulk operations | — | — | LCM-001, DRF-001, AUD-001 |
+| GUI-004 | Consumer Portal — Session and Security | View active sessions; revoke individual or all other sessions; step-up MFA prompt for gated operations; tenant context selector; role-gated navigation (hide not disable) | — | — | SES-001, IAM-001 |
+| GUI-005 | Admin Panel — Platform Dashboard | Control plane component health grid; provider health summary; pending approvals count; open drift records by severity; request throughput; all driven by GET /api/v1/admin/health | — | Platform Admins, SREs configure dashboard widgets; role-gated sections | HLT-003 |
+| GUI-006 | Admin Panel — Governance and Approvals | Approval queue (all tenants); approval detail with risk score breakdown; authority tier registry editor (drag-and-drop reordering, impact report visualization, degradation acceptance flow); scoring threshold editor (auto_approve_below ≤ 50 hard-stop) | — | Policy Owners and Platform Admins | ATM-004, SMX-001 |
+| GUI-007 | Admin Panel — Audit and Compliance | Platform-wide cross-tenant audit trail; pre-built compliance reports (SOC 2, FedRAMP, HIPAA); audit chain integrity status; correlation ID trace; session and security event feed | — | Auditors, Security team, Platform Admins | AUD-001, SES-003 |
+| GUI-008 | Provider Management — Common Shell | Overview, configuration, health history, audit trail, and notification tabs for all 11 provider types; provider owner role gates access; Platform Admins see all providers | — | Provider owners manage own providers; Platform Admins manage all | PRV-001, IAM-001 |
+| GUI-009 | Provider Management — Type Extensions | Service Provider: capacity, managed entities, naturalization mapping, realization history; secrets management: inventory, rotation, revocation, external CA config, algorithm compliance; Auth Provider: session stats, SCIM sync, connection status; external policy evaluation: trust level, contribution pipeline | — | Provider owners access type-specific tabs for their provider type | GUI-008, PRV-001 |
+| GUI-011 | RHDH Plugin Suite | Use DCM capabilities within Red Hat Developer Hub (RHDH) or Backstage via Dynamic Plugins (@dcm/backstage-plugin-*); no RHDH rebuild required for updates | — | Configure RHDH app-config.yaml with DCM connection; configure Dynamic Plugin loading |
+| GUI-012 | Scaffolder Template Auto-Generation | DCM catalog items automatically generate Backstage Software Templates; new resource types appear as templates without UI code; field schema → JSON Schema → Scaffolder form | — | Configure @dcm/backstage-plugin-catalog-backend; template generation is automatic |
+| GUI-013 | DCM Entity Provider | DCMService (catalog items) and DCMResource (realized entities) appear in RHDH Software Catalog; entities sync every PT5M; search-indexed; tenancy enforced via namespace | — | Service account credential configuration; sync interval configuration |
+| GUI-014 | ITSM Integration Bridge | View ITSM references (ServiceNow, Jira) on resource entity Overview tab; link change records to DCM requests; see ITSM-sourced approval votes in request status; CMDB reference on entity pages | ITSM systems receive DCM lifecycle events via notification service_provider and call Admin API to record approval votes; CMDB sync via webhook subscription | Configure ITSM notification service_provider; map DCM event → ITSM action; configure CMDB field mapping | EVT-001, GUI-002 |
+| GUI-010 | Unified Shell | Single DCM web application with role-gated surfaces: Consumer Portal (all actors), Admin Panel (platform roles), Provider Management (provider_owner role), Flow GUI link (policy_owner/sre); one login, one session; no separate applications | — | Platform Admins configure which surfaces are available | IAM-001, SES-001 |
+
+---
+
+
+## 34. ITSM Integration
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| ITSM-001 | ITSM integration Registration | — | Register as ITSM integration with declared capabilities (supported_actions, itsm_system, field_mapping_ref, cmdb_ci_type_map); implement standard OIS health check | Register ITSM integrations; review and approve ITSM integration registrations; configure inbound webhook authentication | PRV-001, CPX-001 |
+| ITSM-002 | Outbound ITSM Record Creation | View ITSM references on resource entities (change request, incident, CMDB CI links with deep links to ITSM system) | Receive action requests from DCM; create/update records in ITSM system; return record ID for storage on entity | Configure ITSM Policies (create_change_request, create_incident, update_cmdb_ci); configure block_until_created for compliance gates | ITSM-001, POL-001 |
+| ITSM-003 | Inbound ITSM Approval Routing | — | Verify HMAC signature on inbound webhook; forward ITSM approval decisions to DCM Admin API approval vote endpoint | Configure inbound webhook secret (secrets management); monitor approval routing from ITSM systems (ServiceNow CAB, Jira workflow) | ITSM-001, CPX-001, ATM-001 |
+| ITSM-004 | ITSM Policy Authoring | — | — | Author ITSM Action policies with template expressions; configure shadow validation; configure on_failure behavior; use block_until_created for pipeline gates (with mandatory timeout per ITSM-005) | ITSM-001, POL-001 |
+| ITSM-005 | CMDB Synchronization | View CMDB CI reference on resource entities; CI auto-created on realization, auto-retired on decommission | Receive create_cmdb_ci and retire_cmdb_ci actions; maintain dcm_entity_uuid correlation on CMDB CI records | Configure CMDB CI type mapping per resource type; monitor CMDB sync failures | ITSM-001, ITSM-002 |
+| ITSM-006 | ITSM Field Mapping Declaration | — | — | Declare field mappings between DCM entity fields and ITSM CI types in ITSM integration config; validate against Resource Type Specs | ITSM-001 |
+| ITSM-007 | ITSM Policy Template Expression Validation | — | — | Validate template expressions in ITSM Policy action_payload at policy activation; reject unresolvable expressions | ITSM-001, POL-003 |
+
+---
+
+
+## 35. Provider Callback Authentication
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|
+| PCA-001 | Two-Layer Provider Callback Authentication | — | Present valid mTLS certificate (Layer 1) and provider callback credential (Layer 2) on every call to DCM callback endpoints | Configure DCM CA trust anchor; issue provider callback credentials at activation; enforce both layers | PRV-001, ZTS-001 |
+| PCA-002 | Provider Callback Credential Scope Enforcement | — | Use callback credential scoped to own provider_uuid only; cannot act on other providers | Enforce credential scope at validation; reject cross-provider credential use | PRV-001 |
+| PCA-003 | Entity-Level Callback Authorization | — | Receive 403 ENTITY_NOT_OWNED_BY_PROVIDER when pushing state for entities not dispatched to this provider | Enforce per-call entity ownership check independent of credential validity | PRV-001, REQ-007 |
+| PCA-004 | Scope Violation Auto-Suspension | Receive critical notification when owned provider is suspended due to scope violations | — | Auto-suspend provider and notify platform admin after 5 consecutive scope violations within PT1H | PRV-001, ZTS-001 |
+| PCA-005 | Callback Credential Issued by secrets management | — | Retrieve callback credential via secrets management at activation; not directly from API Gateway | Issue callback credentials exclusively through secrets management; reject direct credential issuance requests | PRV-001, CPX-001 |
+| PCA-006 | Registration Token Single-Use Enforcement | — | Use registration token for initial registration only; obtain callback credential after activation | Invalidate registration token after first successful use regardless of expiry timestamp | PRV-001 |
+| PCA-007 | Sovereignty Change Re-Registration | — | Submit new registration with new registration token when sovereignty declaration changes | Require new registration token and approval pipeline for sovereignty declaration changes | PRV-001, GMX-004 |
+| PCA-008 | Callback Credential Pre-Expiry Rotation | — | Implement credential refresh; receive new credential before old expires during transition window | Initiate rotation before expiry; maintain transition window (50% of credential lifetime) | PRV-001, CPX-001 |
+| PCA-009 | IP-Bound Callback Credentials for fsi/sovereign | — | Present callback calls from declared bound_to_ip address for fsi/sovereign profiles | Enforce IP binding on callback credentials for fsi and sovereign profiles | PCA-001, CPX-008 |
+| PCA-010 | All Inbound Provider Calls Produce Audit Records | — | — | Write audit record for every inbound provider call including rejected calls; no silent failures | PCA-001, AUD-001 |
+
+---
+
+
+## 36. Workload Analysis
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|| WLA-001 | Automated Workload Classification | View workload profile for owned resources; see archetype, resource type match, confidence | Report resource metadata via discovery for classification input | Configure classification ruleset version; review low-confidence classifications manually | DRC-001, INF-001 |
+| WLA-002 | Migration Readiness Scoring | View containerization score and migration blockers for owned resources | Report workload characteristics that inform migration scoring | Configure migration readiness thresholds; integrate MTA Information Provider | WLA-001 |
+| WLA-003 | MTA Information Provider Integration | — | Implement workload_analysis information type OR delegate to MTA | Register MTA as Information Provider; configure analysis trigger policies | WLA-001, INF-001 |
+| WLA-004 | On-Demand Re-Analysis | Request re-analysis when resource role changes (`POST /resources/{uuid}/workload-profile:analyze`) | — | Trigger re-analysis for any resource; override archetype manually with reason | WLA-001 |
+| WLA-005 | WorkloadProfile Audit Chain | View analysis history for owned resources | — | Query full analysis history including superseded profiles | WLA-001, AUD-001 |
+| WLA-006 | Low-Confidence Manual Review Gate | Receive notification when owned resource requires manual classification | — | Review and resolve low-confidence classifications; unblock ingestion | WLA-001, LCM-001 |
+
+---
+
+
+## 37. Accreditation Monitoring
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|| ACM-001 | Tier 1 External Registry Verification | — | Declare `external_registry_id` at registration for FedRAMP, CMMC, ISO 27001 | Configure registry poll intervals; review status change alerts; manage `external_registry_id` accuracy | PRV-001, ACR-001 |
+| ACM-002 | Tier 2 Document Currency Verification | — | Maintain current `certificate_ref` and `audit_report_ref` URLs pointing to valid, accessible documents | Configure `max_age` per framework; review document expiry alerts; upload new reports when notified | PRV-001, ACR-001 |
+| ACM-003 | Tier 3 Contract Webhook Integration | — | Configure contract management webhook for BAA and DoD IL accreditations | Register contract system; configure inbound webhook credential; receive BAA/contract lifecycle events | PRV-001, ACR-001 |
+| ACM-004 | Verification Staleness Enforcement | — | Ensure monitoring infrastructure can reach DCM to deliver verification events | Configure stale_after thresholds and stale_action per profile; enforce sovereign/fsi minimum tier requirements | ACM-001, ACR-001 |
+| ACM-005 | Immediate Revocation on External Revoke | Receive notification when provider accreditation is revoked; understand service impact | — | Review `accreditation.status_changed` events; confirm immediate revocations; trigger recovery policy | ACM-001, ACR-001 |
+| ACM-006 | Verification Currency in Scoring | — | Maintain verification currency to maximize accreditation richness score | Monitor verification multiplier impact on provider placement; prioritize externally verified providers | ACM-001, SMX-001 |
+| ACM-007 | Manual Override in Air-Gapped Mode | — | — | Manually update `last_verified_at` with justification in air-gapped deployments; maintain audit trail of manual verifications | ACR-001, AUD-001 |
+
+---
+
+
+## 38. Location Topology Management
+
+| ID | Capability | Consumer | Service Provider | Platform/Admin | Depends On |
+|----|-----------|---------|---------|---------------|-----------|| LOC-001 | Location Type Registry | Browse available location types (standard and custom) | Declare supported locations in provider registration capability declaration | Register custom location types; manage standard type definitions; deprecate types | PRV-001 |
+| LOC-002 | Location Node Management | Browse available locations via `GET /api/v1/locations`; filter by resource type, data classification, sovereignty zone | Declare which location nodes (DC, Zone, etc.) the provider serves at registration | Create, version, and retire location layer instances via GitOps; update mutable capacity fields | LOC-001 |
+| LOC-003 | Location Selection at Request Time | Submit `location_uuid` or `location_handle` with service request; select at any level (Country through Rack); DCM refines to specific DC at placement | — | Configure default location selection rules; enforce location-based placement policies | LOC-001, LOC-002 |
+| LOC-004 | Location Layer Assembly | Transparent — full location context injected into payload automatically | Receive full location context in dispatch payload (location.country_code, location.zone_code, location.dc_code, etc.) | Configure layer assembly order; define location-level field overrides | LOC-002, DLM-001 |
+| LOC-005 | Location-Based Sovereignty Enforcement | See sovereignty zone and data residency on each location node | Declare sovereignty capabilities per served location | Configure `max_data_classification` per location; enforce cross-border policies at location layer | LOC-002, GOV-001 |
+| LOC-006 | Location Hierarchy Navigation | Browse parent/child location relationships; query ancestors of a selected node | — | Manage location hierarchy; validate acyclicity on layer submission | LOC-001, LOC-002 |
+| LOC-007 | Custom Location Types | Use custom location types in selection (e.g., Fleet/Ship in Navy context) | Declare support for resources at custom location types | Register and manage custom types; define level insertion point in hierarchy | LOC-001 |
+| LOC-008 | Location Capacity Visibility | See `capacity_status` (available/limited/full) and `providers_available` count per location | Report capacity scoped to location during reserve query | Update mutable capacity fields (e.g., rack_units_available) without a new layer version | LOC-002, PRV-001 |
+
+---
+
+
+
+
+## 39. Subscription Management (SUB)
+
+| ID | Capability | Consumer | Provider | Platform/Admin | Dependencies |
+|----|-----------|----------|----------|----------------|-------------|
+| SUB-001 | Create subscription | Submit subscription request with tier and terms | Acknowledge subscription, provision initial entities | Approve subscription creation | CAT-001, REQ-001, POL-001 |
+| SUB-002 | Manage subscription lifecycle | Suspend, resume, cancel own subscriptions | Report managed entity status | Force-cancel, view all subscriptions | LCM-001, AUD-001 |
+| SUB-003 | Change subscription tier | Request tier upgrade/downgrade | Adjust capacity for managed entities | Approve tier changes requiring admin | POL-001, POL-003 |
+| SUB-004 | Subscription renewal | Approve/decline renewal; view renewal status | Honor renewed terms | Configure renewal policies | SCH-001, POL-001 |
+| SUB-005 | Provider-originated updates | Approve/reject non-auto updates | Submit updates via standard callback | View update audit trail | PRV-003, AUD-001 |
+| SUB-006 | Update channel management | Configure auto_apply per channel | Declare available update channels | Set organization-wide channel policies | POL-001, POL-003 |
+| SUB-007 | Subscription cost attribution | View subscription cost | Declare cost model per tier | Configure cost allocation rules | — |
+| SUB-008 | Entitlement enforcement | View remaining capacity | Stay within entitlement bounds | Override entitlements in exceptional cases | POL-002 |
+| SUB-009 | Grace period management | View grace period; request extension | Continue health reporting during grace | Configure grace period defaults | LCM-001 |
+| SUB-010 | Subscription audit trail | View own subscription audit history | — | View all subscription audit records | AUD-001, AUD-002 |
+
+## Capability Count Summary
+
+| Domain | Capabilities |
+|--------|-------------|
+| Identity and Access Management | 21 |
+| Service Catalog | 7 |
+| Request Lifecycle Management | 10 |
+| Provider Contract and Realization | 16 |
+| Resource Lifecycle Management | 7 |
+| Drift Detection and Remediation | 5 |
+| Policy Management | 7 |
+| Data Layer Management | 5 |
+| Information and Data Integration | 6 |
+| Ingestion and Brownfield Management | 4 |
+| Audit and Compliance | 5 |
+| Observability and Operations | 6 |
+| Storage and State Management | 8 |
+| DCM Federation and Multi-Instance | 5 |
+| Platform Governance and Administration | 7 |
+| Accreditation Management | 6 |
+| Zero Trust and Security Posture | 8 |
+| Unified Governance Matrix | 7 |
+| Drift Reconciliation | 5 |
+| Federated Contribution Model | 7 |
+| Scoring Model | 10 |
+| Compound Service Composability | 8 |
+| secrets management Model | 12 |
+| Authority Tier Model | 12 |
+| Event Catalog | 7 |
+| API Versioning | 8 |
+| Session Revocation | 11 |
+| Internal Component Authentication | 8 |
+| Scheduled and Deferred Requests | 6 |
+| Request Dependency Graph | 6 |
+| DCM Self-Health | 6 |
+| Operational Reference | 4 |
+| Web Interfaces | 14 |
+| ITSM Integration | 7 |
+| Provider Callback Authentication | 10 |
+| Workload Analysis | 5 |
+| Accreditation Monitoring | 6 |
+| Location Topology Management | 7 |
+| Subscription Management | 10 |
+| **Total** | **309** |
+---
+
+## Dependency Map — Critical Path Capabilities
+
+These capabilities block the most downstream work and should be implemented first:
+
+```
+IAM-001 (Actor Authentication)
+ └── IAM-002 (Session Tokens) → IAM-003 (RBAC) → IAM-007 (Tenant Scope)
+ └── CAT-001 (Service Catalog)
+ └── REQ-001 (Submit Request)
+ └── REQ-002 (Intent State) → REQ-003 (Layer Assembly)
+ └── REQ-004 (Policy Evaluation) → REQ-005 (Placement)
+ └── REQ-007 (Provider Dispatch)
+ └── PRV-003 (Realization) → PRV-005 (Realized State)
+ └── LCM-001 (State Transitions)
+ └── DRF-001 (Discovery) → DRF-002 (Drift)
+
+PRV-001 (Provider Registration) — parallel critical path
+ └── PRV-002 (Naturalization) → PRV-003 (Realization)
+ └── PRV-006 (Capacity Reporting) → REQ-005 (Placement)
+```
+
+**Minimum viable DCM capability set (to demonstrate end-to-end lifecycle):**
+
+IAM-001 → IAM-002 → IAM-003 → IAM-007 → CAT-001 → REQ-001 → REQ-002 → REQ-003 → REQ-004 → REQ-005 → REQ-006 → REQ-007 → PRV-001 → PRV-002 → PRV-003 → PRV-004 → PRV-005 → LCM-001 → DRF-001 → DRF-002 → AUD-001
+
+**21 capabilities for a functional end-to-end demonstration.**
+
+**Note:** FCM-001 through FCM-007 (Federated Contribution Model) are not on the critical path — they extend DCM's multi-user capabilities but are not required for the initial end-to-end lifecycle demonstration.
+
+---
+
+*Document maintained by the DCM Project. For questions or contributions see [GitHub](https://github.com/dcm-project).*
diff --git a/content/docs/DISCUSSION-TOPICS.md b/content/docs/DISCUSSION-TOPICS.md
new file mode 100644
index 0000000..8829094
--- /dev/null
+++ b/content/docs/DISCUSSION-TOPICS.md
@@ -0,0 +1,614 @@
+# DCM — Discussion Topics
+
+> **Status Update (2026-03):** The DCM architecture has been substantially completed. All original 19 architecture review items, 10 session-added items, and 21 community questions have been resolved. The items below represent topics for ongoing community discussion and future evolution.
+>
+> **Current state:** 0 unresolved architectural questions · 331 capabilities across 39 domains · 58 data model documents · 15 specifications · 4 OpenAPI schemas · 6 JSON schemas · 5 provider types · 2 policy evaluation modes · 9 control plane services
+>
+> **Foundation:** Three abstractions (Data · Provider · Policy) · Unified Governance Matrix · Federated Contribution Model · Full OPA/Rego validation complete
+
+## Open Community Discussion Topics
+
+### 1. Kubernetes / CNCF Strategy (community decisions)
+- CNCF submission scope: Operator Interface Spec as specification project first; DCM project after Level 2 reference implementation
+- SIG App Delivery and SIG Cluster Lifecycle engagement before Sandbox submission
+- Named adopters and TOC sponsor: project team action items
+- Level 2 conformance scope now formally defined
+
+### 2. Implementation Decisions (engineering decisions)
+- KubeVirt reference implementation timeline → team estimates against defined Level 2 scope
+- SDK language support beyond Go → community SDKs encouraged; Go SDK is reference implementation
+- Non-Kubernetes container runtime support → implementation detail
+
+### 3. Future Evolution Topics
+- Normative data specifications (JSON Schema / OpenAPI) — the code-generation layer
+- AI/ML Provider type — as DCM becomes AI-ready, a dedicated ML workload provider type
+- Billing Provider type — deeper integration with enterprise billing and showback systems
+- CMDB Provider type — dedicated contract for CMDB integration
+- Multi-cloud federation model — extending DCM federation to public cloud providers
+- GitOps PR UX improvements — better tooling for policy review workflow
+
+
+### 5. Kessel Integration (pre-implementation evaluation)
+- Evaluation document written: `44-kessel-integration-evaluation.md`
+- **Action required:** Discussion with Kessel development team to validate assumptions before any implementation work begins
+- Key questions: API stability, sovereign/air-gapped deployment model, SpiceDB schema extensibility, resource type registry extensibility, HA/DR patterns
+- **Do not implement until alignment confirmed** — document is for discussion only
+- Two integration paths evaluated: Kessel Relations as Auth Provider (checks 1-2 of five-check model), Kessel Inventory as Discovered State data store
+- 10 blocking items identified in doc 44 Section 10
+
+### 4. Governance Questions
+- Community governance model — how will the DCM project make decisions once public?
+- Certified Profile Program — self-certified vs project-reviewed for compliance profiles
+- Registry tier promotion — Tier 3 (Organization) to Tier 2 (Verified Community) pathway
+
+---
+
+*See [00-foundations.md](data-model/00-foundations.md) for the three-abstraction model that resolved the major architectural questions.*
+
+
+---
+
+**Original discussion topics (archived):**
+
+# DCM — Topics for Discussion and Modification
+
+**Document Status:** 🔄 Active
+**Purpose:** A living document capturing topics that require further discussion, design decisions that need revisiting, and new capabilities to be incorporated into the DCM architecture and data model.
+**Process:** When a topic is resolved, move it to the appropriate architecture or data model document and mark it resolved here with a reference to where it was documented.
+
+---
+
+## How to Use This Document
+
+- **Add** any topic that surfaces during design, review, or implementation that needs a decision or deeper discussion
+- **Tag** each item with its area, priority, and status
+- **Resolve** items by documenting the decision in the appropriate document and updating the status here
+- **Never delete** resolved items — keep the full history for audit and traceability
+
+---
+
+## Status Key
+
+| Status | Meaning |
+|--------|---------|
+| 🔴 Blocking | Must be resolved before dependent work can proceed |
+| 🟡 Active | Under active discussion |
+| 🟢 Resolved | Decision made — documented in referenced document |
+| ⚪ Parked | Acknowledged but deferred — revisit later |
+
+---
+
+## Priority Key
+
+| Priority | Meaning |
+|----------|---------|
+| P1 | Critical — affects foundational architecture |
+| P2 | High — affects multiple components or documents |
+| P3 | Medium — affects a specific component or document |
+| P4 | Low — enhancement or refinement |
+
+---
+
+## Open Topics
+
+---
+
+### TOPIC-001 — Webhook Integration
+
+**Area:** Control Plane, Provider Contract, Egress
+**Priority:** P2
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** Notification Model (doc 23) supersedes standalone webhooks. Webhooks are one delivery channel within the notification model. Full event taxonomy in doc 33 (Event Catalog). See AI Prompt Sections 14, 25, 48.
+**Raised:** 2026-03
+
+#### Description
+
+DCM needs a webhook integration model that allows external systems to be notified of DCM events and state changes in real time. Webhooks are a standard integration pattern that complements the existing API-first model and Message Bus — they enable a push-based notification model for consumers, providers, and external systems that cannot or do not poll DCM.
+
+#### Use Cases
+
+**Consumer Notifications**
+- Notify a consumer's CI/CD pipeline when a resource request transitions to REALIZED state
+- Notify an application team when their Resource/Service Entity enters DEGRADED state
+- Notify a Tenant owner when an ownership transfer is initiated or completed
+- Notify consumers when a dependency graph node fails during realization
+
+**Provider Notifications**
+- Notify a provider when a new request payload is dispatched to them
+- Notify a provider when DCM initiates a discovery request
+- Notify a provider when a decommission is requested for one of their entities
+
+**External System Integration**
+- Notify an external ITSM system (ServiceNow, Jira) when a request is created, updated, or completed
+- Notify a monitoring system when Entity lifecycle state changes
+- Notify a FinOps platform when new Resource/Service Entities are realized or decommissioned
+- Notify a compliance system when GateKeeper policies fire or sovereignty constraints are applied
+
+**Operational Notifications**
+- Notify SRE teams when provider capacity falls below threshold
+- Notify security teams when unsanctioned changes are detected
+- Notify auditors when specific policy types are triggered
+
+#### Design Questions to Resolve
+
+1. **Webhook registration model** — how do consumers, providers, and external systems register webhooks with DCM? Is registration via the Consumer API, Provider Registration, or a dedicated Webhook API?
+
+2. **Event taxonomy** — what is the full list of events DCM can emit via webhook? Should this be an extensible registry similar to the Resource Type Registry?
+
+3. **Payload format** — should webhook payloads use the DCM unified data model format, or a simplified event notification format? Should the full state payload be included or just a reference + event type?
+
+4. **Authentication and security** — how does DCM authenticate outbound webhook calls? Options include: HMAC signatures, OAuth tokens, mTLS, API keys. How does the receiving system verify the webhook is genuinely from DCM?
+
+5. **Retry and reliability** — what is DCM's obligation if a webhook delivery fails? Should DCM retry? How many times? With what backoff strategy? What happens if a webhook endpoint is consistently unavailable?
+
+6. **Ordering guarantees** — are webhook events delivered in order? What happens if events arrive out of order at the receiving end?
+
+7. **Filtering** — can webhook registrations declare filters — only receive events of specific types, for specific Resource Types, for specific Tenants, or for specific Resource Groups?
+
+8. **Policy Engine integration** — should GateKeeper and other policy types be able to trigger webhook notifications as a policy action? This would make webhooks a first-class policy response alongside ALERT, REVERT, etc.
+
+9. **Provider webhook obligations** — should providers be required to support webhook endpoints as part of their Provider Contract? Or is webhook support optional for providers?
+
+10. **Tenant scoping** — should webhook registrations be scoped to a Tenant, meaning a webhook can only receive events for resources owned by the registering Tenant? Or should there be platform-level webhooks that span Tenants (for SRE/Audit personas)?
+
+11. **Webhook versioning** — as DCM evolves, webhook payload schemas will change. How are webhook payload versions managed? Should webhook registrations declare which payload schema version they expect?
+
+12. **Relationship to Message Bus** — DCM already has a Message Bus component. What is the distinction between webhook integration and Message Bus integration? Are webhooks the outbound consumer-facing layer on top of the Message Bus?
+
+#### Initial Design Thoughts
+
+Webhooks fit naturally as an **Egress capability** — they are outbound notifications from DCM to external systems, which is consistent with the existing Egress zone in the architecture (Messaging Protocol, Interoperability API).
+
+The webhook registration model should likely be part of the **Consumer API** for consumer-facing webhooks and part of the **Provider Registration** for provider-facing webhooks.
+
+Webhook events should be **typed and versioned** — consistent with DCM's universal versioning model. An event type like `entity.state.changed` should have a version, and webhook registrations should declare which version they support.
+
+Webhook payloads should carry **provenance information** — the event payload should include enough context to trace back to the originating request, entity, and policy that caused the event. This is consistent with DCM's auditability requirements.
+
+**Policy Engine integration** is particularly interesting — if the Policy Engine can fire webhooks as a response action, it enables real-time governance notifications without requiring consumers to poll DCM. This aligns with the DCM goal of getting actionable information to the right people as fast as possible.
+
+#### References
+- [Resource/Service Entities](data-model/06-resource-service-entities.md) — provider lifecycle events
+- [Service Dependencies](data-model/07-service-dependencies.md) — dependency failure notifications
+- Architecture: Egress zone, Message Bus, API Gateway
+
+---
+
+### TOPIC-002 — Intent Store and Intent Payload Structure
+
+**Area:** Data Model
+**Priority:** P1
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** Intent State fully specified in doc 02 (Four States), doc 04 (Examples), consumer-api-spec. Resource type referenced by FQN or UUID (both accepted). See AI Prompt Sections 4, 5, 80.
+**Raised:** 2026-03
+
+#### Description
+
+The Intent State is captured when a consumer submits a request but the exact structure of the Intent payload has not been formally specified. The Intent payload is the consumer's raw declared desire — what they asked for before any processing, enrichment, or policy application. It needs a formal definition that is consistent with the four-state model and the layering model.
+
+#### Questions to Resolve
+
+1. What fields are required in an Intent payload vs optional?
+2. How does the Intent payload reference a Resource Type — by UUID, by fully qualified name, or both?
+3. How does the Intent payload declare its Tenant membership?
+4. How does the Intent payload declare dependency requirements at the intent level?
+5. How does the Intent payload declare group memberships?
+6. How is the Intent payload versioned — does it carry a version or is it always a snapshot?
+
+#### References
+- [Context and Purpose](data-model/00-context-and-purpose.md) — four states
+- [Layering and Versioning](data-model/03-layering-and-versioning.md) — Request Layer
+- [Resource Grouping](data-model/08-resource-grouping.md) — Tenant and group membership
+
+---
+
+### TOPIC-003 — GateKeeper vs Validation Policy Distinction
+
+**Area:** Policy Engine
+**Priority:** P2
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** GateKeeper has enforcement_class (compliance=boolean deny, operational=risk score). Validation has output_class (structural=boolean fail, advisory=completeness score). GateKeeper can both block AND modify. See doc 29 (Scoring Model), AI Prompt Sections 17, 61.
+**Raised:** 2026-03
+
+#### Description
+
+The distinction between GateKeeper and Validation policy categories needs better examples and a clearer formal definition. Both involve checking data against rules, but GateKeeper has override authority while Validation is pass/fail only. The boundary between them needs to be unambiguous.
+
+#### Questions to Resolve
+
+1. What is the precise trigger condition that makes a policy a GateKeeper vs a Validation policy?
+2. Can a GateKeeper policy both block AND modify in the same execution?
+3. Are there cases where Validation and GateKeeper would produce different outcomes for the same rule?
+4. Should GateKeeper policies require explicit authorization (e.g., only CISO-owned policies can be GateKeeper)?
+
+#### References
+- [Layering and Versioning](data-model/03-layering-and-versioning.md) — Policy Layer section
+
+---
+
+### TOPIC-004 — Audit vs Observability Component Separation
+
+**Area:** Control Plane
+**Priority:** P3
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** Definitively separate (AUD-013). Opposite trade-offs: audit is 100% accuracy, append-only, 7+ year retention; observability is statistical sampling, downsampled, operational window. Cannot be combined. See doc 16, AI Prompt Section 37.3.
+**Raised:** 2026-03
+
+#### Description
+
+The original architecture documents noted that Audit and Observability were separated for a reason that was later forgotten. This needs to be formally resolved — are they truly separate components with distinct responsibilities, or should they be merged?
+
+#### Initial Thinking
+
+**Audit** — focused on compliance evidence and transaction traceability. Reads provenance data intrinsic to data objects. Produces compliance reports, audit trails, and interrogation capability for Auditors, Security teams, and SRE personas. Historical record oriented.
+
+**Observability** — focused on operational visibility — metrics, health, performance, real-time monitoring. Consumes provider lifecycle events, Entity state changes, and system health data. Operational present-state oriented.
+
+These are likely genuinely separate concerns. Audit is about what happened and why. Observability is about what is happening now.
+
+#### Questions to Resolve
+
+1. Are Audit and Observability separate Atomic Components with separate APIs?
+2. Do they share a data store or maintain separate stores?
+3. How do provider lifecycle events flow to both components?
+
+---
+
+### TOPIC-005 — Message Bus Consumer Ingress Question
+
+**Area:** Control Plane, Consumer Ingress
+**Priority:** P3
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** Message Bus supports bidirectional integration. Inbound messages processed as authenticated API calls via registered webhook actor identity. Same Policy Engine evaluation as any API call. See doc 18, AI Prompt Section 25.
+**Raised:** 2026-03
+
+#### Description
+
+The original architecture documents raised an unresolved question: should the Message Bus be offered as consumer ingress (inbound) in addition to egress (outbound)? The API-first principle suggests it should be egress only, but there are valid integration scenarios where external systems need to push data into DCM asynchronously.
+
+#### Questions to Resolve
+
+1. Should consumers be able to submit requests via the Message Bus, or only via the Consumer API?
+2. If Message Bus ingress is supported, how are requests authenticated and authorized?
+3. How does Message Bus ingress interact with the Intent State capture — is the message treated as an Intent payload?
+
+---
+
+### TOPIC-006 — Cache Architecture
+
+**Area:** Data Model, Control Plane
+**Priority:** P2
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** Hybrid push-pull model. Caches placed closest to consumption, subject to sovereignty. GitOps and Event Streams always authoritative; caches are derived projections. Sovereign DCM uses signed bundles only. See CACHE-001 through CACHE-004, AI Prompt Section 40.2-40.4.
+**Raised:** 2026-03
+
+#### Description
+
+Several unresolved questions exist about where data caches live, how they are synchronized, and which cache is authoritative when caches diverge. This has implications for distributed DCM deployments and sovereignty scenarios.
+
+#### Questions to Resolve
+
+1. Where should data caches live? Hub DCM? Regional DCM? Sovereign DCM? All locations?
+2. Should cache synchronization be push, pull, or both?
+3. Which cache is authoritative when caches diverge?
+4. What mechanism maintains consistency across distributed caches?
+5. How do cache architecture decisions interact with sovereignty constraints — can cached data cross sovereignty boundaries?
+
+---
+
+### TOPIC-007 — Cross-Tenant Dependencies
+
+**Area:** Data Model, Multi-Tenancy
+**Priority:** P2
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** Relationship nature governs cross-tenant: constituent=never, operational=dual authorization, informational=unless deny_all. explicit_only is default stance. cross_tenant_authorization DCMGroup required. See doc 09, REL-010/011/012, XTA-001-005, AI Prompt Sections 11.13-11.14, 21.6.
+**Raised:** 2026-03
+
+#### Description
+
+The dependency model currently assumes dependencies are resolved within a single Tenant. However, real-world deployments will have cross-tenant dependencies — a Payments Tenant application that depends on a shared DNS service owned by a Platform Tenant. The data model needs to formally address how cross-tenant dependencies are declared, resolved, and governed.
+
+#### Questions to Resolve
+
+1. How is a cross-tenant dependency declared — does it reference the Tenant UUID of the dependency owner?
+2. What authorization is required for a cross-tenant dependency? Does the owning Tenant need to approve?
+3. How does cost attribution work for cross-tenant service consumption?
+4. How does drift detection work when a dependency is in another Tenant?
+5. Can a GateKeeper policy block cross-tenant dependencies?
+
+---
+
+### TOPIC-008 — Provider Trust Validation Mechanism
+
+**Area:** Service Providers, Provider Contract
+**Priority:** P1
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** Registration spec defines full approval pipeline (auto/reviewed/verified/authorized). Provider Callback Auth (doc 43, PCA-001-010) specifies two-layer mTLS + credential model. Trust levels: trusted/verified/untrusted. Accreditation model (doc 26) governs ongoing trust. See AI Prompt Sections 53.2, 76.
+**Raised:** 2026-03
+
+#### Description
+
+The Provider Contract includes a Trust Contract — providers must be validated and certified to participate in the DCM ecosystem. The mechanism for establishing, maintaining, and revoking trust has not been designed.
+
+#### Questions to Resolve
+
+1. What is the certification process for a new provider?
+2. What technical mechanism validates trust at request time?
+3. How is trust revoked if a provider violates their contract?
+4. Should trust be per-provider or per-catalog-item?
+5. How does the trust chain interact with sovereignty requirements?
+
+---
+
+### TOPIC-009 — Physical Shared Infrastructure Tenancy
+
+**Area:** Data Model, Tenancy
+**Priority:** P2
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** Three ownership patterns: Whole Allocation (indivisible, provider retains), Allocation (pool yields sub-resources), Shareable (one resource, multiple stakeholders). Physical infrastructure owned by __platform__ Tenant. See doc 04b, OWN-001 through OWN-008, AI Prompt Sections 8.3, 46.2.
+**Raised:** 2026-03
+
+#### Description
+
+The current model assigns every Resource/Service Entity to exactly one DCM Tenant. This works cleanly for most cases but edge cases exist for truly shared physical infrastructure — a rack, a network switch, a power circuit — where the ownership model may be genuinely joint or ambiguous.
+
+#### Questions to Resolve
+
+1. Is jointly-owned physical infrastructure a valid DCM use case, or is it always owned by a Platform/Infrastructure Tenant?
+2. If joint ownership is valid, how is it modeled without breaking the single-Tenant rule?
+3. Does the Whole Allocation model cover all physical infrastructure scenarios?
+
+---
+
+### TOPIC-010 — Embedded Technology-Specific Data Bundles
+
+**Area:** Data Model
+**Priority:** P3
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** native_passthrough field sanctioned for genuinely untranslatable provider-specific data. Always audit-logged (content if transparent, hash if opaque). Opaque passthrough blocked in fsi/sovereign by default. See DATA-001, AI Prompt Section 40.5.
+**Raised:** 2026-03
+
+#### Description
+
+The original data model discussion raised the question of whether the data model should allow embedded target-technology-specific data bundles — for example, a Terraform HCL block or an Ansible vars file embedded directly in an entity definition. The authors noted "not convinced this is something we want."
+
+#### Questions to Resolve
+
+1. Should technology-specific data bundles be allowed in entity definitions?
+2. If allowed, must they be in clear text and appropriate for Git storage?
+3. How would embedded bundles interact with the portability model — they would clearly be portability-breaking?
+4. Is there a better mechanism — such as a provider-specific extension field with an appropriate portability classification?
+
+---
+
+## Resolved Topics
+
+---
+
+### TOPIC-R001 — Field Override Control Mechanism
+
+**Area:** Data Model, Policy Engine, Layering
+**Priority:** P1
+**Status:** 🟢 Resolved
+**Raised:** 2026-03
+**Resolved:** 2026-03
+
+#### Decision
+
+Field override control is implemented as a **standard Policy Engine mechanism** using a graduated three-level model: Level 1 (no declaration — fully overridable), Level 2 (simple `override: allow|constrained|immutable`), Level 3 (full actor matrix with per-actor permissions, trusted grants, and expansion rules). The Policy Engine is the sole authority for setting override control. The Request Payload Processor enforces structural layer rules only.
+
+#### Documented In
+- [Data Layers and Assembly Process](data-model/03-layering-and-versioning.md) — Section 5a
+- [Context and Purpose](data-model/00-context-and-purpose.md) — Section 4.4
+
+---
+
+### TOPIC-R002 — Storage/Networking Bundling vs Dependency Model (Q53)
+
+**Area:** Data Model, Entity Relationships, Service Dependencies
+**Priority:** P1
+**Status:** 🟢 Resolved
+**Raised:** 2026-03
+**Resolved:** 2026-03
+
+#### Decision
+
+The conflict between the enhancement documents (storage bundled in VM schema) and the data model (separate first-class entities) is resolved through a **universal Entity Relationship model**:
+
+- Bundled consumer declarations are expanded by the Request Payload Processor into first-class Resource/Service Entities with their own UUIDs
+- The relationship between parent and child entities is expressed using the universal relationship model — bidirectional, UUID-keyed, with lifecycle policies
+- The same relationship model is used for ALL entity relationships — compute to storage, application to web server, resource to business unit — minimizing variance
+- Lifecycle policies (destroy|retain|detach|notify on parent destroy/suspend/modify) replace the ephemeral/persistent classification
+- Expansion rules live in the Resource Type Specification — portable and declarative
+- The dependency graph concept is unified into the Entity Relationship Graph
+
+#### Documented In
+- [Entity Relationships](data-model/09-entity-relationships.md) — complete relationship model
+- [Information Providers](data-model/10-information-providers.md) — external data relationships
+- [Service Dependencies](data-model/07-service-dependencies.md) — updated to reference entity relationships
+
+---
+
+### TOPIC-R003 — Information Provider Model
+
+**Area:** Data Model, Provider Contract
+**Priority:** P1
+**Status:** 🟢 Resolved
+**Raised:** 2026-03
+**Resolved:** 2026-03
+
+#### Decision
+
+Information Providers are a first-class provider type in DCM. They follow the same registration, health check, trust, and contract model as Service Providers where applicable. Key decisions:
+
+- Information types live in the same DCM registry as Resource Types — distinguished by category prefix (Business.*, Identity.*, Compliance.*, Operations.*)
+- Standard vs extended data — DCM only relies on standard fields for operational decisions; organizations can extend with domain-specific fields
+- Stable external key model — DCM UUID wraps external UUID; if external system changes its UUID, only the reference record changes
+- Three-mode verification — scheduled (Mode 1), provider push (Mode 2, contractual obligation), on-demand (Mode 3, fallback)
+- Internal business data follows the standard resource entity model when DCM owns it; external references use the Information Provider model
+
+#### Documented In
+- [Information Providers](data-model/10-information-providers.md)
+- [Entity Relationships](data-model/09-entity-relationships.md) — external relationship structure
+- [Resource Type Hierarchy](data-model/05-resource-type-hierarchy.md) — information type categories added
+
+---
+
+---
+
+### TOPIC-011 — Enhancement Document Compatibility Findings
+
+**Area:** Data Model, Provider Contract, Policy Engine, Catalog
+**Priority:** P1
+**Status:** 🟢 Resolved
+**Resolved:** 2026-03
+**Resolution:** All cross-cutting gaps resolved: field-level provenance (doc 00, Section 4.3), UUIDs (universal identity requirement), portability classification (doc 05), sovereignty declarations (doc A provider contract), tenancy (doc 15 universal groups), versioning (semver throughout), deprecation (five-status lifecycle). Enhancement docs superseded by current architecture.
+**Raised:** 2026-03
+
+#### Description
+
+A compatibility review of six DCM enhancement documents against the data model identified areas of strong alignment and cross-cutting gaps that need resolution before the enhancements can be considered fully aligned with the data model.
+
+#### Cross-Cutting Gaps (affect all or most enhancements)
+
+1. **Field-Level Provenance** — absent in all enhancement documents. The Policy Engine spec mutates request payloads without recording provenance. The KubeVirt SP returns minimal status rather than full DCM-format realized payloads.
+
+2. **UUIDs as Primary Identifiers** — most specs use `name` as the natural key rather than UUID as the primary key. The data model requires UUIDs as primary identifiers on all entities.
+
+3. **Portability Classification** — absent from all provider and catalog specs. Every field must declare `universal|conditional|provider-specific|exclusive` classification.
+
+4. **Sovereignty Declarations** — entirely absent from SP Registration and KubeVirt SP. Provider registration must include sovereignty capability declarations as a contractual obligation.
+
+5. **Tenant Support** — explicitly deferred in V1 in the Policy Engine spec. The data model treats Tenant as mandatory and non-overridable. A clear migration path from V1 to Tenant support is needed.
+
+6. **Universal Versioning** — catalog items use `apiVersion: v1alpha1` rather than Major.Minor.Revision. All definitions require universal versioning.
+
+7. **Deprecation Model** — absent from all enhancement documents. All definitions require the `active → deprecated → retired` lifecycle.
+
+#### Document-Specific Gaps
+
+**SP Registration Flow:**
+- Registration payload missing: sovereignty declarations, ownership model declaration, dependency declarations, capacity model mode declaration
+- Uses `name` as natural key rather than UUID as primary key
+- Capacity data (totalCpu, totalMemory) treated as static rather than dynamic — needs reconciliation with three-mode capacity model
+
+**Service Type Definitions:**
+- `providerHints` not formally marked as portability-breaking — silently bypasses portability enforcement
+- Storage and networking bundled with compute — conflicts with the service dependency model which treats these as separate dependent services with their own lifecycle
+- No UUIDs on field definitions, no provenance metadata, no versioning beyond v1alpha1
+
+**Service Provider Health Check:**
+- Covers liveness only — insufficient for full Provider Lifecycle Events contract
+- Does not address DEGRADATION, MAINTENANCE, UNSANCTIONED_CHANGE, CAPACITY_CHANGE events
+- Binary 200/non-200 model needs to coexist with structured event payload model
+
+**Policy Engine:**
+- `selected_provider` as a direct policy output conflicts with the data model's specificity narrowing model for provider selection
+- No policy versioning or GitOps integration — data model requires policies maintained via GitOps
+- No provenance recording on field mutations — data model requires provenance on every modification
+- Constraint immutability model is compatible and can be mapped to `override_preference` field metadata
+
+**Catalog Item Schema:**
+- No UUIDs, no Tenant scoping, no portability classification, no deprecation model, no provenance
+- `editable` field concept is valuable and not explicitly covered in data model — worth incorporating into the Resource Type Specification field definition
+- `dependsOn` conditional field pattern maps to `conditional` portability classification but needs formal alignment
+
+**KubeVirt Service Provider:**
+- Realized payload returns minimal status rather than complete DCM-format payload — Denaturalization requirement not met
+- No unsanctioned change detection — only VMI phase changes reported
+- Registration gaps same as SP Registration Flow spec
+- `namespace` in response payload is provider-native concept with no DCM equivalent
+
+#### Questions to Resolve
+
+1. Should the enhancement documents be updated to align with the data model, or should the data model be adjusted where the enhancements reveal practical implementation constraints?
+2. For the storage/networking bundling vs. dependency model tension — is this a V1 simplification that gets resolved in V2, or does the data model need a "monolithic service" concept?
+3. For `selected_provider` in the Policy Engine — should provider selection remain a policy output, or should it be moved to a dedicated placement component that consumes narrowed field sets from the Policy Engine?
+4. What is the migration path from V1 (no Tenant support) to Tenant-mandatory?
+5. Should the `editable` field concept from the Catalog Item Schema be formally incorporated into the Resource Type Specification?
+
+#### References
+- SP Registration: https://github.com/dcm-project/enhancements/blob/main/enhancements/sp-registration-flow/sp-registration-flow.md
+- Service Types: https://github.com/dcm-project/enhancements/blob/main/enhancements/service-type-definitions/service-type-definitions.md
+- Health Check: https://github.com/dcm-project/enhancements/blob/main/enhancements/service-provider-health-check/service-provider-health-check.md
+- Policy Engine: https://github.com/dcm-project/enhancements/blob/main/enhancements/policy-engine/policy-engine.md
+- Catalog Item: https://github.com/dcm-project/enhancements/blob/main/enhancements/catalog-item-schema/catalog-item-schema.md
+- KubeVirt SP: https://github.com/dcm-project/enhancements/blob/main/enhancements/kubevirt-sp/kubevirt-sp.md
+
+---
+
+Copy the following template and fill in the fields:
+
+```markdown
+### TOPIC-NNN — Title
+
+**Area:**
+**Priority:**
+**Status:** 🟡 Active
+**Raised:**
+
+#### Description
+
+
+
+#### Questions to Resolve
+
+1.
+
+#### References
+-
+```
+
+---
+
+*This document is maintained by the DCM Project team. Add topics freely — no topic is too small if it needs a decision.*
+
+---
+
+### 6. Universal Lightspeed Interface for Operations (future concept)
+
+**Note captured for future exploration.**
+
+A universal operations interface concept — working title "Lightspeed" — for DCM. Intent is a unified, high-velocity operational surface for all DCM actions regardless of the underlying provider, resource type, or lifecycle stage. Think of it as the operational equivalent of what the unified data model is to data: a single consistent interaction model for humans and automation alike across the full DCM estate.
+
+**Initial thoughts to explore:**
+- Single interface for any operation on any resource managed by DCM — no provider-specific tooling, no context switching
+- "Lightspeed" implies minimal friction: operations that currently take multiple steps, approvals, and tool handoffs should be expressible and executable in a single interaction
+- Applicable to both human operators (Web UI / CLI) and automation (agentic workflows, AIOps)
+- Likely surfaces DCM's existing policy engine, lifecycle model, and unified data model as the execution layer — the interface is the innovation, not new backend capability
+- Could be the primary surface for DCM's "AI Ready" design principle (README): agentic workflows operating over DCM's control plane via a natural-language-capable interface that still enforces all policy, sovereignty, and accreditation constraints
+
+**Questions to answer when this gets scoped:**
+- Is this a new GUI surface, a CLI, an AI agent interface, or all three?
+- How does it relate to the existing Web UI spec and Flow GUI spec?
+- What does "lightspeed" mean operationally — sub-second execution, zero-confirmation for pre-approved patterns, predictive pre-staging?
+- How does it interact with the Authority Tier model — can it auto-route approval gates without interrupting the operator's flow?
+- Is this the primary interface for the AIOps layer referenced in the README?
+
+**Status:** Concept note — no design work started. Capture for roadmap planning.
+
+### 7. Spectral AEP Linter + CI Workflow Adoption (PR #18 review)
+
+**Source:** [PR #18](https://github.com/dcm-project/dcm/pull/18) by Fale — first draft of Interoperability API and Service Spec design guidelines.
+
+**PR #18 disposition:** The interoperability API and object design RFC are superseded by the current architecture (4 canonical OpenAPI specs, 58 data model docs). Several conventions in PR #18 (camelCase fields, PascalCase enums, YAML content type, K8s apiVersion/kind/spec/status structure) contradict the team's established patterns (snake_case fields, UPPER_SNAKE_CASE enums, JSON, flat REST entities). PR should be closed with acknowledgment and pointer to current architecture.
+
+**What to adopt:** The `.spectral.yaml` AEP linter config and the GitHub Actions CI workflow that validates OpenAPI specs against AEP rules. This enforces PRR-006 (AEP.DEV Linting) in CI.
+
+**Blockers before adoption:**
+- The team's greenfield specs use OpenAPI 3.1.0; the AEP Spectral ruleset was built for 3.0.x. Must test for false positives on 3.1 constructs before enabling CI enforcement.
+- Determine scope: lint only greenfield specs in `src/api/v1alpha1/`, or also the canonical specs in `dcm/schemas/openapi/`?
+- Decide if this goes in dcm-examples only, or also in the dcm architecture repo for the canonical specs.
+
+**Status:** Future — pending OpenAPI 3.1 compatibility verification.
+
diff --git a/content/docs/README.md b/content/docs/README.md
new file mode 100644
index 0000000..31d1438
--- /dev/null
+++ b/content/docs/README.md
@@ -0,0 +1,135 @@
+# DCM — Data Center Management
+
+Data Center Management (DCM) is an open-source governing framework for enterprise on-premises and sovereign cloud infrastructure. It provides a hyperscaler-like cloud experience — the operational model and self-service capabilities of a public cloud provider — on infrastructure that organizations own and control.
+
+**GitHub:** https://github.com/dcm-project | **License:** Apache 2.0
+
+---
+
+## What DCM Is
+
+DCM is the governing control plane that sits above provisioning tools, automation platforms, and infrastructure systems — making them coherent, governed, and self-service. It is not a deployment tool or a configuration manager. It is the management plane that connects them.
+
+**[Full project description →](project-overview.md)** — what DCM is, what it does, why, who benefits, and where it operates.
+
+---
+
+## Architecture in One Sentence
+
+DCM is built on three foundational abstractions — **Data**, **Provider**, and **Policy** — connected by a policy-driven event loop. Every concept maps to one of these three. See [00-foundations.md](data-model/00-foundations.md).
+
+---
+
+## Documentation Structure
+
+### Foundation Documents (read these first)
+
+| Document | Purpose |
+|----------|---------|
+| [project-overview.md](project-overview.md) | What DCM is, what it does, who it benefits, where it operates |
+| [00-foundations.md](data-model/00-foundations.md) | The three abstractions — Data, Provider, Policy |
+| [00-design-priorities.md](data-model/00-design-priorities.md) | Design priority framework — decision hierarchy for all contributors |
+| [A-provider-contract.md](data-model/A-provider-contract.md) | Unified Provider base contract + 11 typed extensions |
+| [B-policy-contract.md](data-model/B-policy-contract.md) | Unified Policy base contract + 7 output schemas |
+
+### Data Model (55 documents)
+
+| Range | Coverage |
+|-------|---------|
+| 00–05 | Context, foundations, entity types, four states, layering, ownership, resource types |
+| 06–12 | Resource/service entities, dependencies, grouping, relationships, information providers, storage providers, audit |
+| 13–19 | Ingestion, policy profiles, universal groups, universal audit, deployment, webhooks, auth providers |
+| 20–27 | Registry governance, advanced information providers, federation, notifications, operational models, control plane, accreditation, governance matrix |
+| 28–35 | Federated contribution, scoring model, meta provider, credential provider, authority tier, event catalog, API versioning, session revocation |
+| 36–42 | Internal component auth, scheduled requests, dependency graph, self-health, standards catalog, operational reference, ITSM integration |
+| 43–49 | Provider callback auth, Kessel evaluation, consistency review, workload analysis, accreditation monitor, location topology, implementation specifications |
+| A, B | Unified Provider Contract, Unified Policy Contract |
+
+### Specifications (15 documents)
+
+Consumer API · Admin API · Operator Interface · OPA Integration · Flow GUI · Admin GUI · Consumer GUI · Provider GUI · Registration · Examples · Use Case Examples · Kubernetes Compatibility · Operator SDK · RHDH Integration · CNCF Strategy
+
+### Example Implementations
+
+| Path | Purpose |
+|------|---------|
+| [implementations/example-01-summit-demo/](implementations/example-01-summit-demo/) | Summit 2026 Demo — Intelligent Placement, Rehydration, Application as a Service on OpenShift |
+
+
+### AI Model Prompt
+
+[DCM-AI-PROMPT.md](DCM-AI-PROMPT.md) — load into any AI model to provide full project context. 103 sections covering the complete architecture, all decisions, implementation guidance, and working instructions.
+
+---
+
+## Key Numbers
+
+| Metric | Value |
+|--------|-------|
+| Foundational abstractions | 3 (Data, Provider, Policy) |
+| Provider types | 11 (unified base contract + typed capability extensions) |
+| Policy types | 7 (unified base contract + typed output schemas) |
+| Entity lifecycle states | 4 (Intent · Requested · Realized · Discovered) |
+| Capabilities | 299 across 38 domains |
+| Data model documents | 55 |
+| Specifications | 15 |
+| Consumer API paths | 63 |
+| Admin API paths | 57 |
+| Unresolved architectural questions | 0 |
+
+---
+
+## Core Principles
+
+1. **Declarative** — data describes desired state, not procedures
+2. **API-First** — every capability available via standard AEP-aligned API
+3. **Policy-Governed** — all business logic through the Policy Engine, never hard-coded
+4. **Idempotent** — applying the same data multiple times produces the same result
+5. **Immutable if Versioned** — published versions never change; changes produce new versions
+6. **Provider-Agnostic** — DCM defines contracts, not implementations
+7. **GitOps-Native** — intent and policy artifacts are Git-native
+8. **Federated** — all authorized actor types contribute within permitted scope
+9. **Compliance by Construction** — audit trail, provenance, and sovereignty enforcement are structural
+
+---
+
+## Capabilities Matrix
+
+[DCM-Capabilities-Matrix.md](DCM-Capabilities-Matrix.md) — 299 capabilities across 38 domains including: Identity and Access, Service Catalog, Request Lifecycle, Provider Contract, Resource Lifecycle, Drift Detection, Policy Management, Data Layer, Information Integration, Ingestion, Audit, Observability, Storage, Federation, Platform Governance, Accreditation, Zero Trust, Governance Matrix, Scoring Model, Meta Provider, Credential Provider, Authority Tier, Event Catalog, API Versioning, Session Revocation, Internal Component Auth, Scheduled Requests, Dependency Graph, Self-Health, Operational Reference, Web Interfaces, ITSM Integration, Provider Callback Auth, Workload Analysis, Accreditation Monitoring, and Location Topology.
+
+---
+
+## How DCM Works
+
+DCM's runtime is a **policy-driven event loop**: every data state change triggers Policy Engine evaluation, policies produce typed outputs (approve/halt/enrich/route/recover), outputs invoke Providers or produce new Data, and new Data triggers new events. There is no hard-coded pipeline — the pipeline is the sum of active Policies.
+
+A request flows through: **intent declared** → **layer assembly** (Core Layers + Service Layers + Transformation Policies inject and lock required fields) → **policy evaluation** (Validation, GateKeeper, Placement) → **Requested State written** → **dispatch to Provider** (Naturalization → execution → Denaturalization) → **Realized State written** → **ongoing drift monitoring**.
+
+Every business rule is a Policy artifact stored in Git, versioned, tested in shadow mode before activation, and enforced deterministically. Adding a new approval step, changing placement rules, or building a named workflow requires writing a policy — not changing code.
+
+Providers wrap existing automation (Ansible, Terraform, vendor APIs). They implement one base contract and translate between DCM's unified data model and their native format. Organizations do not replace their automation — they govern it.
+
+**[Full technical walkthrough →](project-overview.md#how-dcm-works)**
+
+---
+
+## Ethos
+
+Four design priorities — applied in order when they conflict:
+
+1. **Security is the baseline.** Security properties are present in every profile. Profiles control enforcement strictness and operational burden — not whether the property applies. The `minimal` profile is "security with minimal overhead" — not "minimal security."
+
+2. **The governed path must also be the easy path.** Self-service is how governance scales. If consuming resources through DCM is harder than raising a ticket, teams route around it. The entire scoring, auto-approval, and visual policy authoring system exists to make the governed path the path of least resistance.
+
+3. **Compliance is constructed, not audited.** Audit evidence, field-level provenance, and sovereignty enforcement are structural products of every operation — not reconstructed from logs after the fact. An auditor can answer "who touched this data and when" directly from DCM's audit store.
+
+4. **No silent behavior.** Every operation produces an observable artifact. Every state transition produces an audit record. Every policy decision produces a typed output. When something goes wrong, "what happened and why" is always answerable from the system's own output.
+
+**[Full ethos document →](project-overview.md#ethos)**
+
+---
+
+
+## Contributing
+
+DCM is open-source. Community contributions welcome via GitHub at https://github.com/dcm-project
diff --git a/content/docs/WALKTHROUGH.md b/content/docs/WALKTHROUGH.md
new file mode 100644
index 0000000..721a78f
--- /dev/null
+++ b/content/docs/WALKTHROUGH.md
@@ -0,0 +1,581 @@
+# DCM End-to-End Walkthrough — VM Provision
+
+**Purpose:** Trace a single request through the entire DCM pipeline with real data structures at every stage. This is the single document to read if you want to understand how DCM works in practice.
+
+**Time to read:** ~20 minutes
+**Prerequisites:** None — this document is self-contained.
+
+---
+
+## The Scenario
+
+A developer on the AppTeam tenant requests a standard Linux VM for a payments API server. The request must comply with EU data residency requirements. The VM requires an IP address — DCM automatically resolves this dependency by requesting an IP from the appropriate IPAM provider, governed by core sovereignty policies and service-specific subnet policies. We follow this request from the consumer's API call through to a running VM and its first discovery cycle.
+
+---
+
+## Stage 1: Consumer Submits Intent
+
+The developer calls the Consumer API:
+
+```
+POST /api/v1/requests
+Authorization: Bearer
+Content-Type: application/json
+
+{
+ "catalog_item_uuid": "compute-vm-standard-uuid",
+ "fields": {
+ "cpu_count": 4,
+ "memory_gb": 8,
+ "storage_gb": 100,
+ "os_family": "rhel",
+ "environment": "production",
+ "name": "payments-api-server-01"
+ }
+}
+```
+
+**What the consumer declares:** What they need. Not where it runs, not which provider, not which datacenter. Just the desired outcome.
+
+**What DCM creates — Intent State:**
+
+```yaml
+entity_uuid: f5e6d7c8-e9f0-a1b2-c3d4-e5f6a7b8c9d0
+resource_type: Compute.VirtualMachine
+tenant_uuid: a1b2c3d4-e5f6-a7b8-c9d0-e1f2a3b4c5d6 # AppTeam
+submitted_by: b2c3d4e5-actor-uuid
+submitted_at: 2026-03-15T09:00:00Z
+
+fields:
+ cpu_count: 4
+ memory_gb: 8
+ storage_gb: 100
+ os_family: rhel
+ environment: production
+ name: "payments-api-server-01"
+```
+
+**What happens immediately:**
+- Authorization check: actor has `request:compute:vm` permission in AppTeam tenant
+- Sovereignty check: AppTeam's tenant has `data_residency: EU-WEST` — this will constrain placement later
+- The `entity_uuid` is assigned now and will never change — it links every stage of this request's lifecycle
+
+**Audit leaf written:** `INTENT_CAPTURED` — SHA-256 hash of the intent payload, signed by the API gateway service.
+
+> **Key concept:** The consumer never chooses a provider or a datacenter. The control plane handles that.
+
+---
+
+## Stage 2: Layer Assembly
+
+The Request Processor assembles the full payload by merging data layers in precedence order. Layers are organizational data — datacenter configs, environment defaults, tenant overrides, compliance requirements.
+
+**Layer chain resolved (highest to lowest precedence):**
+
+```
+1. system/core/datacenter-layer.yaml → data_center: "EU-WEST-DC1"
+2. system/core/environment-layer.yaml → monitoring defaults, log retention
+3. system/compliance/eu-west-layer.yaml → backup_policy: "daily-30d-eu-west"
+4. org/appteam-defaults-layer.yaml → monitoring_agent: "datadog-agent:7.42"
+5. providers/openstack/vm-defaults-layer.yaml → provider-specific defaults
+6. Consumer intent → cpu_count: 4, memory_gb: 8, ...
+```
+
+**Resulting merged payload (selected fields with provenance):**
+
+```yaml
+cpu_count:
+ value: 4
+ provenance: { source_type: consumer, source_uuid: f5e6d7c8-entity }
+
+memory_gb:
+ value: 8
+ provenance: { source_type: consumer }
+
+data_center:
+ value: "EU-WEST-DC1"
+ provenance: { source_type: base_layer, source_uuid: dc-layer-uuid }
+
+environment:
+ value: production
+ provenance:
+ origin: { source_type: intermediate_layer, value: dev }
+ modifications:
+ - previous: dev → modified: production, source_type: consumer # consumer override
+
+monitoring_agent:
+ value: "datadog-agent:7.42"
+ provenance: { source_type: intermediate_layer, source_uuid: appteam-defaults-uuid }
+
+backup_policy:
+ value: "daily-30d-eu-west"
+ provenance: { source_type: intermediate_layer, source_uuid: eu-west-compliance-uuid }
+```
+
+**Key concept:** The consumer declared 6 fields. After assembly, there are 10+ fields. The extra fields come from layers — organizational data that the consumer doesn't need to know about but that provisioning requires.
+
+**Key concept:** Every field carries provenance — where the value came from and what modified it. This is how auditors trace any value back to its origin.
+
+**Audit leaf written:** `ASSEMBLY_COMPLETE` — hash of the assembled payload with layer chain reference.
+
+---
+
+## Stage 3: Policy Evaluation
+
+The Policy Engine evaluates all matching policies against the assembled payload. Evaluation follows a three-phase model:
+
+### Phase 1: GateKeeper + Validation (pass/fail, no mutations)
+
+```
+Policy: vm-size-limits (GateKeeper)
+ Match: resource_type = Compute.VirtualMachine, lifecycle_scope = initial_provisioning
+ Result: APPROVED — 4 CPU within AppTeam's 16 CPU quota
+
+Policy: approved-os-images (GateKeeper, tenant-scoped)
+ Match: resource_type = Compute.VirtualMachine, tenant_uuid = AppTeam
+ Result: APPROVED — rhel is in AppTeam's approved images list
+
+Policy: eu-data-residency (GateKeeper, hard enforcement)
+ Match: data_residency = EU-WEST
+ Result: APPROVED — data_center value "EU-WEST-DC1" is within EU-WEST zone
+```
+
+### Phase 2: Transformation (mutations applied)
+
+```
+Policy: inject-monitoring-endpoint (Transformation)
+ Match: environment = production, has monitoring_agent
+ Action: INJECT field monitoring_endpoint
+ Result:
+ monitoring_endpoint:
+ value: "https://metrics.internal.eu-west.example.com"
+ provenance: { source_type: policy, source_uuid: inject-monitoring-policy-uuid,
+ reason: "Standard endpoint for EU-WEST production resources" }
+```
+
+The transformation pass runs again to check for convergence. No new mutations — converged in 1 pass.
+
+### Phase 3: Post-mutation GateKeeper
+
+```
+Policy: vm-size-limits — re-evaluated after transformations
+ Result: APPROVED (no relevant mutations occurred)
+```
+
+**All policies pass. Request proceeds to placement.**
+
+**Audit leaves written:** One per policy evaluation with result, constraint emissions, and hash of the payload at evaluation time.
+
+> **What if a policy blocked?** The request would enter `POLICY_BLOCKED` state and the consumer would receive resolution guidance — compliant values, override options, cancel, or escalate. See ADR-009.
+
+---
+
+## Stage 4: Dependency Resolution
+
+Before placement can proceed, DCM checks the Resource Type Specification for `Compute.VirtualMachine` and finds a **type-level dependency**:
+
+```yaml
+# From the Resource Type Specification for Compute.VirtualMachine
+resource_type: Compute.VirtualMachine
+type_level_dependencies:
+ - required_resource_type: Network.IPAddress
+ dependency_type: hard
+ cardinality: one_to_one
+ description: "Every VM requires exactly one IP address"
+ payload_fields: # fields to inject from the realized IP into the VM payload
+ - source: "address"
+ target: "assigned_ip_address"
+ - source: "subnet"
+ target: "network_subnet"
+ - source: "gateway"
+ target: "network_gateway"
+```
+
+The VM cannot be dispatched until this dependency is satisfied. DCM creates a **sub-request** for the IP address — the consumer never sees this; it's an internal orchestration step driven by the resource type definition.
+
+**IP Address sub-request created:**
+
+```yaml
+entity_uuid: aabb1122-ip-uuid
+resource_type: Network.IPAddress
+tenant_uuid: a1b2c3d4-e5f6-a7b8-c9d0-e1f2a3b4c5d6 # same tenant as parent VM
+parent_entity_uuid: f5e6d7c8-e9f0-a1b2-c3d4-e5f6a7b8c9d0 # linked to the VM
+
+fields:
+ address_family: IPv4
+ purpose: vm_interface
+ environment: production
+ attachment_ref: f5e6d7c8-e9f0-a1b2-c3d4-e5f6a7b8c9d0 # the VM this IP is for
+```
+
+> **Key concept:** The consumer requested a VM. DCM knows a VM requires an IP address because the resource type spec declares it. The consumer doesn't manage IP allocation — DCM does.
+
+**Audit leaf written:** `DEPENDENCY_CREATED` — hash of IP sub-request + parent VM entity_uuid.
+
+---
+
+## Stage 5: IP Address — Policy Evaluation and Provider Selection
+
+The IP sub-request goes through its own policy evaluation pipeline — the same three-phase model as the parent VM, but with policies scoped to `Network.IPAddress`.
+
+### Core Policies (system-scoped, apply to all IP allocations)
+
+```
+Policy: ip-sovereignty-zone (GateKeeper, hard enforcement)
+ Match: resource_type = Network.IPAddress, data_residency = EU-WEST
+ Check: IP pool must be in EU-WEST sovereignty zone
+ Result: APPROVED — only EU-WEST pools will be considered
+
+Policy: ip-subnet-isolation (GateKeeper, system-scoped)
+ Match: resource_type = Network.IPAddress, environment = production
+ Check: Production IPs must come from production-designated subnets
+ Result: APPROVED — filters candidate pools to production subnets only
+```
+
+### Service Provider Policies (provider-scoped, specific to IPAM capabilities)
+
+```
+Policy: ipam-pool-selection (Transformation, provider-scoped)
+ Match: resource_type = Network.IPAddress, purpose = vm_interface
+ Action: Enriches request with pool selection criteria
+ Result: INJECT pool_selector field
+ pool_selector:
+ value: { zone: "eu-west", environment: "production", address_family: "IPv4" }
+ provenance: { source_type: policy, source_uuid: ipam-pool-selection-uuid,
+ reason: "Production VM interfaces use production pool in matching zone" }
+
+Policy: ip-address-format (Validation, provider-scoped)
+ Match: resource_type = Network.IPAddress
+ Check: address_family is valid (IPv4 or IPv6), purpose is recognized
+ Result: PASSED
+```
+
+### Placement selects IP Provider
+
+```
+Sovereignty pre-filter:
+ Eligible IPAM providers must satisfy data_residency: EU-WEST
+ → 2 IPAM providers in EU-WEST zone
+
+Pool capacity query:
+ EU-WEST-IPAM-1 (InfoBlox): pool 10.1.0.0/16, 65,420 available → confidence 98%
+ EU-WEST-IPAM-2 (NetBox): pool 10.2.0.0/16, 12,100 available → confidence 91%
+
+Selection: EU-WEST-IPAM-1 (highest confidence, largest available pool)
+```
+
+**Audit leaves written:** One per IP policy evaluation + `IP_PLACEMENT_COMPLETE`.
+
+---
+
+## Stage 6: IP Address Realization
+
+The IP provider (InfoBlox IPAM) receives the sub-request, naturalizes it to its native API, and allocates an address:
+
+```
+DCM sub-request → InfoBlox API call:
+
+POST /wapi/v2.12/record:host
+{
+ "name": "payments-api-server-01.eu-west.internal",
+ "ipv4addrs": [{ "ipv4addr": "func:nextavailableip:10.1.0.0/16" }],
+ "comment": "DCM entity aabb1122-ip-uuid, tenant AppTeam"
+}
+```
+
+**IP provider callback:**
+
+```yaml
+entity_uuid: aabb1122-ip-uuid
+status: OPERATIONAL
+provider_entity_id: "record:host/ZG5z:10.1.45.23"
+
+realized_fields:
+ address: "10.1.45.23"
+ subnet: "10.1.0.0/16"
+ gateway: "10.1.0.1"
+ dns_name: "payments-api-server-01.eu-west.internal"
+ lease_type: static
+ pool_ref: "10.1.0.0/16"
+```
+
+> **Key concept:** The IP address is now a first-class DCM entity. It has its own entity_uuid, its own realized state, its own audit trail. When the VM is decommissioned, DCM knows to release this IP back to the pool.
+
+**Audit leaf written:** `IP_REALIZED` — hash of realized IP state + IPAM provider signature.
+
+---
+
+## Stage 7: Dependency Injection and VM Placement
+
+Now the IP dependency is satisfied. DCM injects the realized IP data into the VM's payload via **dependency payload passing**:
+
+```yaml
+# VM payload enriched with dependency data
+fields:
+ cpu_count: { value: 4, provenance: {...} }
+ memory_gb: { value: 8, provenance: {...} }
+ storage_gb: { value: 100, provenance: {...} }
+ # ... all previously assembled fields ...
+
+ # Injected from realized IP address dependency
+ assigned_ip_address:
+ value: "10.1.45.23"
+ provenance:
+ source_type: dependency_payload
+ source_uuid: aabb1122-ip-uuid # the IP entity
+ dependency_type: Network.IPAddress
+ timestamp: 2026-03-15T09:01:15Z
+ network_subnet:
+ value: "10.1.0.0/16"
+ provenance: { source_type: dependency_payload, source_uuid: aabb1122-ip-uuid }
+ network_gateway:
+ value: "10.1.0.1"
+ provenance: { source_type: dependency_payload, source_uuid: aabb1122-ip-uuid }
+
+dependencies_satisfied:
+ - dependency_type: Network.IPAddress
+ entity_uuid: aabb1122-ip-uuid
+ status: SATISFIED
+ satisfied_at: 2026-03-15T09:01:15Z
+```
+
+The Placement Engine now scores VM providers (same as before, but the payload now includes the IP):
+
+```
+Sovereignty pre-filter:
+ Eligible VM providers must satisfy data_residency: EU-WEST
+ → 3 OpenStack instances in EU-WEST zone
+
+Reserve query results:
+ EU-WEST-Prod-1: capacity available, confidence 94%
+ EU-WEST-Prod-2: capacity available, confidence 87%
+ EU-WEST-Prod-3: insufficient capacity — excluded
+
+Selection: EU-WEST-Prod-1 (highest confidence score)
+```
+
+**Requested State committed (write-once):**
+
+```yaml
+entity_uuid: f5e6d7c8-e9f0-a1b2-c3d4-e5f6a7b8c9d0
+resource_type: Compute.VirtualMachine
+assembled_at: 2026-03-15T09:01:18Z
+
+fields:
+ cpu_count: { value: 4, provenance: {...} }
+ memory_gb: { value: 8, provenance: {...} }
+ storage_gb: { value: 100, provenance: {...} }
+ os_family: { value: rhel, provenance: {...} }
+ environment: { value: production, provenance: {...} }
+ name: { value: "payments-api-server-01", provenance: {...} }
+ data_center: { value: "EU-WEST-DC1", provenance: {...} }
+ monitoring_agent: { value: "datadog-agent:7.42", provenance: {...} }
+ backup_policy: { value: "daily-30d-eu-west", provenance: {...} }
+ monitoring_endpoint: { value: "https://metrics...", provenance: {...} }
+ assigned_ip_address: { value: "10.1.45.23", provenance: { source_type: dependency_payload } }
+ network_subnet: { value: "10.1.0.0/16", provenance: { source_type: dependency_payload } }
+ network_gateway: { value: "10.1.0.1", provenance: { source_type: dependency_payload } }
+
+placement:
+ selected_provider_uuid: eu-west-prod-1-provider-uuid
+ sovereignty_satisfied: true
+
+dependencies:
+ - type: Network.IPAddress
+ entity_uuid: aabb1122-ip-uuid
+ status: SATISFIED
+```
+
+**Audit leaf written:** `PLACEMENT_COMPLETE` — hash of requested state + placement decision + dependency references.
+
+> **Key concept:** Requested State is write-once. It now includes both the assembled fields AND the dependency data from the IP allocation. This is the permanent auditable record of exactly what was approved for provisioning.
+
+---
+
+## Stage 8: VM Provider Dispatch (Naturalization)
+
+The Request Orchestrator sends the enriched payload to the selected VM provider. The provider **naturalizes** the DCM unified payload — including the dependency-injected IP address — into its native API format:
+
+```
+DCM unified payload → OpenStack Nova API call:
+
+POST /servers
+{
+ "server": {
+ "name": "payments-api-server-01",
+ "flavorRef": "m1.xlarge", ← resolved from cpu_count: 4 + memory_gb: 8
+ "imageRef": "rhel-9.3-latest", ← resolved from os_family: rhel
+ "networks": [{
+ "uuid": "eu-west-net-uuid",
+ "fixed_ip": "10.1.45.23" ← from dependency: Network.IPAddress
+ }],
+ "availability_zone": "eu-west-az1",
+ "metadata": {
+ "dcm_entity_uuid": "f5e6d7c8-e9f0-a1b2-c3d4-e5f6a7b8c9d0",
+ "dcm_tenant": "AppTeam",
+ "dcm_ip_entity_uuid": "aabb1122-ip-uuid",
+ "backup_policy": "daily-30d-eu-west"
+ }
+ }
+}
+```
+
+**Key concept:** The VM provider receives the IP address as a known field in the payload — it doesn't call the IPAM system itself. DCM resolved the dependency, allocated the IP through the proper provider with full policy evaluation, and injected the result. The VM provider just uses it.
+
+**Audit leaf written:** `DISPATCH_SENT` — hash of naturalized payload + provider identity.
+
+---
+
+## Stage 9: VM Provider Callback (Denaturalization)
+
+The provider provisions the VM with the pre-allocated IP, then **denaturalizes** the result back into DCM's unified format:
+
+```
+POST /api/v1/provider/entities/f5e6d7c8-.../status
+Authorization: Bearer
+
+{
+ "operation_uuid": "...",
+ "status": "OPERATIONAL",
+ "provider_entity_id": "vm-0a1b2c3d",
+ "realized_fields": {
+ "cpu_count": 4,
+ "memory_gb": 8,
+ "storage_gb": 102, ← actual (rounded up)
+ "assigned_ip_address": "10.1.45.23", ← confirmed: matches dependency
+ "hypervisor_host": "compute-node-07", ← provider-assigned
+ "console_url": "https://console.eu-west.example.com/vm/0a1b2c3d"
+ }
+}
+```
+
+**Realized State recorded:**
+
+```yaml
+entity_uuid: f5e6d7c8-e9f0-a1b2-c3d4-e5f6a7b8c9d0
+realized_at: 2026-03-15T09:03:12Z
+lifecycle_state: OPERATIONAL
+
+fields:
+ cpu_count: 4
+ memory_gb: 8
+ storage_gb: 102
+ assigned_ip_address: "10.1.45.23"
+ hypervisor_host: "compute-node-07"
+ console_url: "https://console.eu-west..."
+ provider_entity_id: "vm-0a1b2c3d"
+
+dependencies:
+ - type: Network.IPAddress
+ entity_uuid: aabb1122-ip-uuid
+ realized_value: "10.1.45.23"
+```
+
+**Consumer receives status update via webhook/polling.**
+
+**Audit leaf written:** `REALIZED` — hash of realized state + provider signature.
+
+---
+
+## Stage 10: Discovery Cycle (Drift Detection)
+
+24 hours later, the Discovery service polls the provider:
+
+```yaml
+discovered_at: 2026-03-16T09:00:00Z
+provider_entity_id: "vm-0a1b2c3d"
+status: ACTIVE
+
+cpu_count: 4 # matches Realized — no drift
+memory_gb: 8 # matches
+storage_gb: 102 # matches
+assigned_ip_address: "10.1.45.23" # matches
+```
+
+**Drift comparison: Realized ≡ Discovered. No drift detected.**
+
+Discovery also polls the IP entity independently:
+
+```yaml
+discovered_at: 2026-03-16T09:00:05Z
+provider_entity_id: "record:host/ZG5z:10.1.45.23"
+status: ACTIVE
+
+address: "10.1.45.23" # matches IP Realized State
+lease_type: static # matches
+```
+
+If someone had manually changed the VM's IP outside DCM, the discovered IP on the VM would differ from the dependency record — that's drift on both the VM entity and the IP entity.
+
+> **Key concept:** Both the VM and the IP are independently discoverable DCM entities. Drift detection runs on each. The dependency relationship means drift on the IP triggers review of the VM too.
+
+---
+
+## Stage 11: The Audit Trail
+
+At the end of this lifecycle, the Merkle tree contains these leaves (at mutation granularity). Note how both the VM and the IP dependency have their own complete audit chains:
+
+```
+VM Request:
+ Leaf 1: INTENT_CAPTURED hash(intent_payload) signed by api-gateway
+ Leaf 2: ASSEMBLY_COMPLETE hash(assembled_payload) signed by request-processor
+ Leaf 3: POLICY_EVAL:vm-size hash(eval_context + result) signed by policy-engine
+ Leaf 4: POLICY_EVAL:os-images hash(eval_context + result) signed by policy-engine
+ Leaf 5: POLICY_EVAL:residency hash(eval_context + result) signed by policy-engine
+ Leaf 6: POLICY_EVAL:monitoring hash(eval_context + mutation) signed by policy-engine
+
+IP Dependency Sub-Request:
+ Leaf 7: DEPENDENCY_CREATED hash(ip_sub_request + parent_vm_uuid) signed by orchestrator
+ Leaf 8: IP_POLICY:sovereignty hash(eval_context + result) signed by policy-engine
+ Leaf 9: IP_POLICY:subnet-iso hash(eval_context + result) signed by policy-engine
+ Leaf 10: IP_POLICY:pool-select hash(eval_context + mutation) signed by policy-engine
+ Leaf 11: IP_PLACEMENT_COMPLETE hash(ip_requested_state + ipam_selection) signed by placement
+ Leaf 12: IP_DISPATCH_SENT hash(naturalized_infoblox_request) signed by orchestrator
+ Leaf 13: IP_REALIZED hash(ip_realized_state) signed by ipam-provider
+
+VM Continues After Dependency Satisfied:
+ Leaf 14: DEPENDENCY_SATISFIED hash(ip_realized_fields + vm_entity_uuid) signed by orchestrator
+ Leaf 15: PLACEMENT_COMPLETE hash(vm_requested_state + placement + deps) signed by placement
+ Leaf 16: DISPATCH_SENT hash(naturalized_nova_payload) signed by orchestrator
+ Leaf 17: REALIZED hash(vm_realized_state) signed by vm-provider
+```
+
+Any auditor can:
+- **Inclusion proof:** Verify leaf 8 (IP sovereignty check) exists in the tree
+- **Consistency proof:** Verify the tree has only grown since the last signed tree head
+- **Dependency chain:** Follow leaf 7→13 for the complete IP allocation audit, then leaf 14→17 for the VM
+- **Policy provenance:** Trace why the IP came from InfoBlox pool 10.1.0.0/16 (leaves 9-11: subnet isolation + pool selection policies)
+- **Non-repudiation:** Every leaf is signed by the service that produced it (Ed25519)
+
+---
+
+## Summary: What Happened in 3 Minutes
+
+| Time | Stage | What happened |
+|------|-------|---------------|
+| T+0s | 1. Intent | Consumer declared 6 fields via API |
+| T+0.5s | 2. Assembly | 5 layers merged in, provenance tracked for all 10+ fields |
+| T+1s | 3. Policy (VM) | 4 policies evaluated — all passed. 1 field injected by transformation |
+| T+1.1s | 4. Dependencies | VM requires Network.IPAddress — sub-request created automatically |
+| T+1.3s | 5. Policy (IP) | 4 IP policies evaluated — sovereignty, subnet isolation, pool selection, format |
+| T+1.5s | 6. IP Realized | IPAM provider allocated 10.1.45.23 from EU-WEST production pool |
+| T+1.6s | 7. Injection | Realized IP injected into VM payload via dependency payload passing |
+| T+2s | 7. Placement (VM) | 3 VM providers scored, 1 selected based on sovereignty + confidence |
+| T+3s | 8. Dispatch | Payload naturalized to OpenStack Nova API with pre-allocated IP |
+| T+192s | 9. Callback | Provider returned realized state — VM running at 10.1.45.23 |
+| T+86400s | 10. Discovery | Both VM and IP confirmed matching realized state — no drift |
+
+**Consumer declared 6 fields. DCM handled everything else:** layer assembly, policy validation, data enrichment, IP allocation through the proper IPAM provider with full sovereignty and subnet policies, provider selection, API translation, state tracking, audit trail (17 Merkle leaves across 2 entities), and drift detection on both the VM and its IP dependency.
+
+---
+
+## Where to Go Next
+
+- **To understand layers:** Doc 03 (Layering and Versioning)
+- **To understand policies:** Doc B (Policy Contract) — start with §1-7
+- **To understand providers:** Doc A (Provider Contract) — start with §1-5
+- **To understand dependencies:** Doc 07 (Service Dependencies) — type-level deps, payload passing, resolution order
+- **To understand audit:** Doc 16 (Universal Audit) — start with §1-3, then §8 for Merkle tree
+- **To see the three-tier app example:** Doc 04 §8 (compound resource type specification with binding fields)
+- **To see the IP allocation example:** Doc 04 §4 (IP Address Allocation with pool model)
+- **To see all ADRs:** [Architecture Decision Records](adr/README.md)
diff --git a/content/docs/_index.md b/content/docs/_index.md
index 4585ceb..a61c8b2 100644
--- a/content/docs/_index.md
+++ b/content/docs/_index.md
@@ -2,13 +2,20 @@
title: Documentation
type: docs
sidebar:
- open: true
+ open: false
---
# DCM Documentation
-Documentation for the DCM project.
+Documentation for the DCM (Data Center Management) project — an open-source governing
+framework for enterprise on-premises and sovereign cloud infrastructure.
-## Documentation Sections
+**New here?** Start with the [Project Overview](/docs/project-overview).
-- **[Enhancements](enhancements/)** - Enhancement proposals documenting new features, architectural decisions, and significant changes to the DCM project.
+{{< cards >}}
+ {{< card link="project-overview" title="Project Overview" icon="information-circle" subtitle="What DCM is, why it exists, who it benefits, and where it operates." >}}
+ {{< card link="architecture" title="Architecture" icon="template" subtitle="Data model (55 docs), specifications (15 docs), and OpenAPI schemas." >}}
+ {{< card link="capabilities-matrix" title="Capabilities Matrix" icon="table-cells" subtitle="299 capabilities across 38 domains." >}}
+ {{< card link="taxonomy" title="Taxonomy" icon="book-open" subtitle="Precise vocabulary for the DCM architecture." >}}
+ {{< card link="implementations" title="Implementations" icon="rocket-launch" subtitle="Reference implementations. Example #1: Summit 2026 demo on OpenShift." >}}
+{{< /cards >}}
diff --git a/content/docs/architecture/_index.md b/content/docs/architecture/_index.md
new file mode 100644
index 0000000..5d16d7e
--- /dev/null
+++ b/content/docs/architecture/_index.md
@@ -0,0 +1,37 @@
+---
+title: Architecture
+type: docs
+weight: 1
+sidebar:
+ open: true
+---
+
+# DCM Architecture
+
+The DCM architecture is documented across three layers:
+
+{{< cards >}}
+ {{< card link="data-model" title="Data Model" icon="database" subtitle="55 documents covering all entity types, four states, policies, providers, and lifecycle management." >}}
+ {{< card link="specifications" title="Specifications" icon="document-text" subtitle="15 specification documents: Consumer API, Admin API, Operator Interface, OPA Integration, Flow GUI, and more." >}}
+ {{< card link="ai-prompt" title="AI Prompt" icon="chip" subtitle="Full project context for AI models — 103 sections covering all architecture decisions." >}}
+{{< /cards >}}
+
+---
+
+## Architecture in One Sentence
+
+DCM is built on three foundational abstractions — **Data**, **Provider**, and **Policy** — connected by a policy-driven event loop. Every concept maps to one of these three. See [00-foundations.md](data-model/00-foundations.md).
+
+---
+
+## Key Numbers
+
+| | |
+|-|-|
+| Data model documents | 55 |
+| Specification documents | 15 |
+| API paths | 63 consumer · 57 admin · 5 operator · 7 provider callback |
+| Capabilities | 299 across 38 domains |
+| Provider types | 11 |
+| Policy types | 7 |
+| Unresolved architectural questions | 0 |
diff --git a/content/docs/architecture/adr/001-why-dcm-exists.md b/content/docs/architecture/adr/001-why-dcm-exists.md
new file mode 100644
index 0000000..7c1bf56
--- /dev/null
+++ b/content/docs/architecture/adr/001-why-dcm-exists.md
@@ -0,0 +1,31 @@
+# ADR-001: Why DCM Exists
+
+**Status:** Accepted
+**Date:** March 2026
+
+## Context
+
+Enterprise data centers run hundreds of thousands of resources — VMs, containers, network segments, storage volumes — across multiple infrastructure platforms. Today, each platform has its own provisioning workflow, API, data format, and lifecycle model. The result:
+
+- **No unified view of what's deployed.** Intended state, deployed state, and actual state diverge silently. Nobody can answer "what's running, who owns it, and does it match what was approved?"
+- **No consistent governance.** Policy enforcement is tribal knowledge. Security reviews are manual gates. Compliance is verified after the fact rather than enforced at request time.
+- **No common abstraction.** A team requesting a VM goes through one process; requesting a database goes through another; requesting a three-tier application requires manually coordinating both plus networking.
+
+Public cloud solves this with unified control planes (AWS CloudFormation, Azure Resource Manager, GCP Deployment Manager). On-premises infrastructure has no equivalent.
+
+## Decision
+
+Build DCM — a management plane for enterprise data center infrastructure that provides:
+- A unified data model and API across all infrastructure platforms
+- Policy-as-code enforcement on every request before provisioning
+- Full lifecycle management from request through decommission with tamper-evident audit
+- A provider abstraction that makes any infrastructure platform consumable through the same interface
+
+DCM is **not** a provisioning tool. It is the governance and orchestration layer that sits above provisioning tools (Ansible, Terraform, operators) and governs what gets requested, approved, built, owned, and decommissioned.
+
+## Consequences
+
+- DCM must be infrastructure-agnostic — it cannot favor any single platform
+- The data model must be extensible to any resource type without code changes
+- Policy evaluation must be mandatory, not optional — governance is the value proposition
+- Audit must be tamper-evident to satisfy regulated environments (the primary adopters)
diff --git a/content/docs/architecture/adr/002-three-abstractions.md b/content/docs/architecture/adr/002-three-abstractions.md
new file mode 100644
index 0000000..a211aa8
--- /dev/null
+++ b/content/docs/architecture/adr/002-three-abstractions.md
@@ -0,0 +1,27 @@
+# ADR-002: Three Foundational Abstractions — Data, Provider, Policy
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 00 (Foundations)
+
+## Context
+
+A management plane for infrastructure must handle many concerns: data storage, external integrations, governance rules, audit trails, placement decisions, dependency resolution, lifecycle events, and more. Without a unifying model, the architecture becomes a collection of ad-hoc services with unclear boundaries.
+
+## Decision
+
+Every component of DCM maps to exactly one of three foundational abstractions:
+
+**DATA** — Everything stored and versioned. The unified data model, entity lifecycle states, field-level provenance, data layers, and audit records. Data flows through a deterministic pipeline: Intent → Requested → Realized → Discovered.
+
+**PROVIDER** — Everything external. Any system DCM interacts with through a defined contract. Providers receive data from DCM, act on it, and return data to DCM. Six provider types cover all external interactions: service, information, meta, auth, peer_dcm, and process.
+
+**POLICY** — Everything that decides. Rules that fire when data matches conditions and produce typed outputs: allow/deny, validation, field mutations, recovery actions, orchestration directives. Policies govern every transition and transformation in DCM.
+
+The interaction model: Data changes trigger Policy evaluation. Policy decisions may mutate Data or select Providers. Providers produce new Data. The cycle repeats.
+
+## Consequences
+
+- Any new capability must map to one of these three abstractions — if it doesn't fit, the abstraction model needs revision, not a fourth pillar
+- Documentation, APIs, and code are organized around these three concepts
+- Team members only need deep knowledge of 1-2 abstractions for their area of work
diff --git a/content/docs/architecture/adr/003-four-lifecycle-states.md b/content/docs/architecture/adr/003-four-lifecycle-states.md
new file mode 100644
index 0000000..2fa45a6
--- /dev/null
+++ b/content/docs/architecture/adr/003-four-lifecycle-states.md
@@ -0,0 +1,29 @@
+# ADR-003: Four Lifecycle States
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 02 (Four States)
+
+## Context
+
+A resource entity goes through multiple stages: the consumer declares intent, the system processes and approves, the provider provisions, and discovery observes what actually exists. If we track this as a single mutable record, we lose the ability to answer: "What did they ask for? What did we approve? What got built? What exists now?"
+
+These four questions are the foundation of governance, audit, compliance, and drift detection.
+
+## Decision
+
+Every resource entity flows through four immutable states:
+
+1. **Intent** — What the consumer asked for (raw declaration, no processing)
+2. **Requested** — What was approved after layer assembly and policy evaluation (write-once)
+3. **Realized** — What the provider actually created (snapshot from provider callback)
+4. **Discovered** — What exists right now (independent observation via polling)
+
+The `entity_uuid` links all four states for the same resource. States are immutable — updates create new records. Drift is the delta between Realized and Discovered. Compliance is provable because Requested State records the policy-approved payload.
+
+## Consequences
+
+- Every resource has exactly 4 records linked by entity_uuid
+- Drift detection is a comparison: Realized ≠ Discovered
+- Rehydration (disaster recovery) re-enters at Intent with current policies
+- Audit can trace any resource from consumer's original ask through to what's running
diff --git a/content/docs/architecture/adr/004-service-catalog-consumer-experience.md b/content/docs/architecture/adr/004-service-catalog-consumer-experience.md
new file mode 100644
index 0000000..6a6d528
--- /dev/null
+++ b/content/docs/architecture/adr/004-service-catalog-consumer-experience.md
@@ -0,0 +1,38 @@
+# ADR-004: Service Catalog and Consumer Experience
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 05 (Resource Type Hierarchy), Doc 06 (Resource/Service Entities)
+
+## Context
+
+Consumers need a way to discover what services are available and request them. The service catalog must abstract away infrastructure complexity — a developer requesting a VM should not need to know which hypervisor, which datacenter, or which network configuration is required.
+
+## Decision
+
+A four-level hierarchy separates what consumers see from what providers implement:
+
+1. **Resource Type Category** — Broad groupings (Compute, Network, Storage, Database)
+2. **Resource Type** — Specific resource kinds (Compute.VirtualMachine, Network.VLAN)
+3. **Resource Type Specification** — Vendor-neutral field schemas, constraints, lifecycle rules
+4. **Provider Catalog Item** — A specific provider's offering (pricing, SLAs, availability)
+
+Consumers browse the catalog, select a catalog item, and submit a request with only the fields they care about (e.g., CPU count, memory, OS). DCM handles everything else: layer assembly, policy evaluation, provider selection, dependency resolution.
+
+**Consumer request surface** is a JSON payload via the Consumer API:
+
+```json
+POST /api/v1/requests
+{ "catalog_item_uuid": "...", "fields": { "cpu_count": 4, "memory_gb": 8, "os_family": "rhel" } }
+```
+
+## Open Question — Application Definition Language
+
+The current consumer interface is an API call with a JSON payload. This works for single resources. For multi-resource applications (three-tier web app, data pipeline, ML training environment), the consumer needs a way to define the application as a whole. This is an open design question — see [ADR-016: Application Definition Language](016-application-definition-language.md).
+
+## Consequences
+
+- Resource types are vendor-neutral; provider catalog items are provider-specific
+- Multiple providers can offer catalog items for the same resource type
+- Consumers never choose a provider directly — placement does that
+- The catalog is queryable via API; RHDH provides the frontend
diff --git a/content/docs/architecture/adr/005-provider-abstraction.md b/content/docs/architecture/adr/005-provider-abstraction.md
new file mode 100644
index 0000000..c15b2e0
--- /dev/null
+++ b/content/docs/architecture/adr/005-provider-abstraction.md
@@ -0,0 +1,33 @@
+# ADR-005: Why Providers Exist and What They Do
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc A (Provider Contract)
+
+## Context
+
+DCM must interact with many external systems: hypervisors, container platforms, network controllers, IPAM systems, identity services, other DCM instances, ITSM tools, and more. Each has its own API, data format, and operational model. Without a common abstraction, DCM becomes tightly coupled to specific infrastructure platforms.
+
+## Decision
+
+A **Provider** is any external system DCM interacts with through a defined contract. All providers share a base contract (registration, health check, sovereignty declaration, accreditation, zero trust authentication). What varies is the capability — what operations the provider exposes and what data flows in which direction.
+
+Five provider types:
+
+| Type | What it does | Example |
+|------|-------------|---------|
+| **Service** | Provisions and manages infrastructure resources | OpenStack Nova, KubeVirt, ACM |
+| **Information** | Serves authoritative external data | CMDB, DNS, IPAM (InfoBlox) |
+| **Meta** | Composes multiple providers into a compound service | Three-tier app, full-stack environment |
+| **Auth** | Authenticates identities | Keycloak, LDAP, FreeIPA |
+| **Peer DCM** | Another DCM instance for federation | Cross-region DCM |
+| **Process** | Executes workflows without producing resources | Approval chains, ITSM integration |
+
+The key mechanism is **Naturalization/Denaturalization**: DCM sends a unified payload to the provider. The provider translates (naturalizes) it into its native API format, acts on it, then translates (denaturalizes) the result back into DCM's unified format.
+
+## Consequences
+
+- Adding a new infrastructure platform means writing one provider — not changing DCM core
+- Consumers don't know or care which provider fulfills their request
+- Provider selection is policy-driven (placement), not consumer-chosen
+- All provider interactions are audited and sovereignty-checked
diff --git a/content/docs/architecture/adr/006-policy-engine.md b/content/docs/architecture/adr/006-policy-engine.md
new file mode 100644
index 0000000..5e17fd0
--- /dev/null
+++ b/content/docs/architecture/adr/006-policy-engine.md
@@ -0,0 +1,33 @@
+# ADR-006: Why Policy-as-Code and What It Governs
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc B (Policy Contract)
+
+## Context
+
+Enterprise infrastructure requires governance: sizing limits, security constraints, compliance rules, sovereignty requirements, cost controls, naming conventions. Today this governance is tribal knowledge enforced by manual review gates. Manual gates are slow, inconsistent, and unauditable.
+
+## Decision
+
+Every request is policy-evaluated before provisioning. Policies are code artifacts (Rego), not configuration. They fire automatically when data matches conditions and produce typed outputs.
+
+**What policies govern:**
+- **Who can request what** (GateKeeper: allow/deny based on role, tenant, resource type)
+- **Whether the request is valid** (Validation: field constraints, range checks, format)
+- **How the request is enriched** (Transformation: inject monitoring agents, set backup policies, apply naming conventions)
+- **What happens when things fail** (Recovery: retry, requeue, compensate)
+- **How pipeline stages are ordered** (Orchestration Flow: dependency sequencing)
+- **What crosses boundaries** (Governance Matrix: sovereignty, data classification)
+
+**Key design choices:**
+- Multi-pass evaluation with convergence — transformation policies can inject fields that other policies depend on
+- Lifecycle-scoped — a CPU-sizing policy fires on provisioning and scaling, not on hostname changes
+- Override model with 5 mechanisms — governance is not rigid; legitimate exceptions are handled through audited overrides
+
+## Consequences
+
+- No request bypasses policy evaluation — this is mandatory, not opt-in
+- Policies are versioned, have lifecycle (developing → active → retired), and support shadow mode for safe testing
+- Every policy evaluation produces an audit record regardless of outcome
+- Policy complexity is managed through templates (Gatekeeper ConstraintTemplate pattern) and a Constraint Type Registry
diff --git a/content/docs/architecture/adr/007-placement-engine.md b/content/docs/architecture/adr/007-placement-engine.md
new file mode 100644
index 0000000..1872601
--- /dev/null
+++ b/content/docs/architecture/adr/007-placement-engine.md
@@ -0,0 +1,32 @@
+# ADR-007: How DCM Decides Where Things Run
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 50 (Placement), Doc 14 (Profiles)
+
+## Context
+
+When a consumer requests a VM, they don't specify which provider or datacenter. Multiple providers may be capable of fulfilling the request. DCM must select the best provider based on sovereignty requirements, capacity, compliance, cost, and organizational policy.
+
+## Decision
+
+The Placement Engine selects providers through a multi-stage scoring process:
+
+1. **Sovereignty pre-filter** — Eliminate providers that don't satisfy data residency requirements (e.g., EU-WEST resources can only go to EU-WEST providers). This is a hard gate, not a score.
+
+2. **Capability filter** — Eliminate providers that don't support the requested resource type or lack required capabilities.
+
+3. **Reserve query** — Query remaining providers for capacity availability and get confidence scores.
+
+4. **Policy-driven scoring** — Apply placement policies that score providers on criteria like cost, performance tier, organizational preference, and existing affinity (e.g., co-locate with related resources).
+
+5. **Selection** — Highest-scoring provider wins. Ties broken by configurable rules.
+
+For compound services (compound resource type specifications), placement runs per-constituent — the database may land on a different provider than the app server, each scored independently but subject to the same sovereignty constraints.
+
+## Consequences
+
+- Consumers never choose providers — placement is always policy-driven
+- Adding new providers to a zone automatically makes them candidates for placement
+- Placement decisions are audited with full scoring rationale
+- Provider health affects placement — unhealthy providers are excluded
diff --git a/content/docs/architecture/adr/008-dependency-resolution.md b/content/docs/architecture/adr/008-dependency-resolution.md
new file mode 100644
index 0000000..142bd4f
--- /dev/null
+++ b/content/docs/architecture/adr/008-dependency-resolution.md
@@ -0,0 +1,32 @@
+# ADR-008: How Resources Know What They Need
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 07 (Service Dependencies), Doc 30 (Meta Provider Model)
+
+## Context
+
+Infrastructure resources have dependencies. A VM needs an IP address. A database needs a network port. A three-tier application needs all of its components provisioned in the right order with runtime values (IP addresses, connection strings) flowing from one resource to the next.
+
+## Decision
+
+Dependencies are declared at two levels:
+
+**Type-level** (in the Resource Type Specification): "Every VM requires exactly one IP address." These are portable, provider-agnostic, and apply to all implementations of the resource type. DCM automatically creates sub-requests for type-level dependencies.
+
+**Binding fields** (in compound service definitions): "The backend's db_host field gets its value from the database's realized ip_address." These connect resources via runtime values — the output of one resource becomes the input of another.
+
+**How it works:**
+1. Request Processor reads the resource type spec and identifies dependencies
+2. Dependencies without parents are dispatched first (topological sort)
+3. When a dependency is realized, its output values are injected into dependent resources via dependency payload passing (with full provenance tracking)
+4. Dependent resources are dispatched after their dependencies are satisfied
+
+For compound services, the compound resource type spec declares the full dependency graph with binding fields.
+
+## Consequences
+
+- Consumers don't manage dependencies — they request a catalog item and DCM resolves the graph
+- Each dependency is a first-class DCM entity with its own audit trail and lifecycle
+- Decommission reverses the dependency order — dependents are torn down before their dependencies
+- Circular dependencies are detected at resource type registration time, not at request time
diff --git a/content/docs/architecture/adr/009-api-gateway-control-plane.md b/content/docs/architecture/adr/009-api-gateway-control-plane.md
new file mode 100644
index 0000000..479618d
--- /dev/null
+++ b/content/docs/architecture/adr/009-api-gateway-control-plane.md
@@ -0,0 +1,39 @@
+# ADR-009: Why an API Gateway and What the Control Plane Services Do
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 25 (Control Plane Services), OpenAPI Specs
+
+## Context
+
+DCM has multiple consumers (developers, platform engineers, admins, providers, external systems) that interact via different APIs with different authorization scopes. Internally, DCM has multiple services that process requests through a pipeline. These services need a single entry point that handles authentication, routing, rate limiting, and API versioning.
+
+## Decision
+
+The **API Gateway** is the single entry point for all external traffic. It handles:
+- Authentication (JWT validation, API key verification)
+- Route multiplexing (consumer API, admin API, provider callback API)
+- Rate limiting and throttling per tenant
+- TLS termination
+- API versioning (v1, v1alpha1)
+
+Behind the gateway, **9 control plane services** process requests through the pipeline:
+
+| Service | What it does |
+|---------|-------------|
+| API Gateway | Routes external traffic to internal services |
+| Catalog Manager | Serves the service catalog and resource type registry |
+| Request Processor | Assembles layers, resolves dependencies, builds requested state |
+| Policy Engine | Evaluates all matching policies against the request payload |
+| Placement Engine | Scores and selects providers for fulfillment |
+| Request Orchestrator | Dispatches to providers, manages async callbacks, handles retries |
+| Audit Service | Records tamper-evident audit trail with Merkle tree |
+| Discovery Service | Polls providers for current state, detects drift |
+| Provider Manager | Manages provider registration, health monitoring, sovereignty declarations |
+
+## Consequences
+
+- All external traffic goes through one endpoint — simplifies network policy and TLS
+- Services communicate internally via direct calls or PostgreSQL LISTEN/NOTIFY
+- Each service has its own health endpoint and can be scaled independently
+- The pipeline is deterministic: assembly → policy → placement → dispatch → callback
diff --git a/content/docs/architecture/adr/010-audit-tamper-evidence.md b/content/docs/architecture/adr/010-audit-tamper-evidence.md
new file mode 100644
index 0000000..83ffe2a
--- /dev/null
+++ b/content/docs/architecture/adr/010-audit-tamper-evidence.md
@@ -0,0 +1,31 @@
+# ADR-010: Why Tamper-Evident Audit and How It Works
+
+**Status:** Accepted
+**Date:** April 2026
+**Docs:** Doc 16 (Universal Audit)
+
+## Context
+
+Regulated industries (financial services, government, healthcare) require provable audit trails. "We logged it" is insufficient — auditors need mathematical proof that records haven't been modified or deleted after the fact. This is a hard requirement for sovereign cloud deployments.
+
+## Decision
+
+DCM uses a **Merkle tree** audit model (RFC 9162 — the same pattern used in Certificate Transparency):
+
+- Every pipeline stage produces a signed audit record (Ed25519 signature)
+- Records are leaves in a Merkle tree — a binary hash tree where modifying any leaf changes the root hash
+- **Inclusion proofs** prove a specific record exists in the tree
+- **Consistency proofs** prove the tree has only grown (no deletions)
+- **Signed tree heads** provide non-repudiation by the DCM instance
+
+**Configurable granularity** because not every deployment needs the same detail:
+- **Stage** (~6 leaves/request): one leaf per pipeline stage — sufficient for dev/homelab
+- **Mutation** (~15-30 leaves/request): one leaf per field change — standard for production
+- **Field** (mutation + per-field hashes): required for FedRAMP/sovereign deployments
+
+## Consequences
+
+- Any modification to audit records is mathematically detectable
+- Auditors can independently verify the audit trail without trusting DCM
+- Granularity is profile-governed — organizations choose their audit depth
+- Three SQL tables support the model: audit_records, signed_tree_heads, merkle_tree_nodes
diff --git a/content/docs/architecture/adr/011-sovereignty-data-residency.md b/content/docs/architecture/adr/011-sovereignty-data-residency.md
new file mode 100644
index 0000000..b48d052
--- /dev/null
+++ b/content/docs/architecture/adr/011-sovereignty-data-residency.md
@@ -0,0 +1,28 @@
+# ADR-011: Why Sovereignty Is a First-Class Concept
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 14 (Profiles), Doc B §18 (Overrides), Doc 26 (Governance Matrix)
+
+## Context
+
+Organizations operating in regulated industries or across jurisdictions face data residency requirements: EU data must stay in EU, classified data must stay on approved infrastructure, healthcare data must meet HIPAA locality requirements. Public clouds handle this with regions. On-premises infrastructure has no equivalent enforcement mechanism.
+
+## Decision
+
+Sovereignty is enforced at three levels:
+
+1. **Provider declaration** — Every provider declares its sovereignty zones and data residency scope at registration. This is not self-reported trust — it's validated against the accreditation model.
+
+2. **Policy enforcement** — Sovereignty policies are GateKeeper policies with hard enforcement. They fire on every lifecycle operation (not just initial provisioning). A resource in EU-WEST stays in EU-WEST for its entire lifecycle, including updates, scaling, and rehydration.
+
+3. **Placement pre-filter** — The placement engine eliminates non-compliant providers before scoring begins. Sovereignty is a hard gate, not a soft preference.
+
+**Override governance:** Sovereignty policies can be overridden, but only through dual-approval (two approvers from different roles). Every override is audited at field granularity.
+
+## Consequences
+
+- Sovereignty violations are caught at request time, not after deployment
+- Cross-zone data movement is impossible without explicit, audited override
+- Rehydration (disaster recovery) respects current sovereignty policies — rebuilding in a non-compliant zone is blocked
+- Profiles (minimal, standard, fsi, sovereign) set sovereignty enforcement minimums
diff --git a/content/docs/architecture/adr/012-data-assembly-layering.md b/content/docs/architecture/adr/012-data-assembly-layering.md
new file mode 100644
index 0000000..467d517
--- /dev/null
+++ b/content/docs/architecture/adr/012-data-assembly-layering.md
@@ -0,0 +1,29 @@
+# ADR-012: How Organizational Data Merges with Consumer Requests
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 03 (Layering and Versioning)
+
+## Context
+
+When a consumer requests a VM with 4 CPUs, the provisioning system needs much more information: which datacenter, which network, what monitoring agent, what backup policy, what compliance requirements apply. This organizational data shouldn't be the consumer's responsibility — they just want a VM.
+
+## Decision
+
+**Data Layers** carry organizational context that gets merged into every request:
+
+- **System layers** — Datacenter configurations, environment defaults, compliance requirements
+- **Tenant layers** — Organization-specific overrides (monitoring agents, naming conventions)
+- **Provider layers** — Provider-specific defaults (image mappings, flavor resolution)
+- **Consumer intent** — What the consumer actually asked for
+
+Layers merge in precedence order (system → tenant → provider → consumer). Consumer values override layer defaults. Every field in the merged payload carries **provenance** — where the value came from and what modified it.
+
+**Layers are Data, not Logic.** Layers provide values. Policies provide decisions. A layer says "the datacenter is EU-WEST-DC1." A policy says "EU-WEST resources must use the EU-WEST monitoring endpoint." This separation means layers can be managed by infrastructure teams while policies are managed by security/governance teams.
+
+## Consequences
+
+- Consumers declare only what they need — organizational data is injected automatically
+- Adding a new datacenter or changing a monitoring agent is a layer change, not a code change
+- Provenance on every field answers "why does this VM have this backup policy?"
+- Layer conflicts are resolved deterministically by precedence order
diff --git a/content/docs/architecture/adr/013-override-exception-governance.md b/content/docs/architecture/adr/013-override-exception-governance.md
new file mode 100644
index 0000000..9922d43
--- /dev/null
+++ b/content/docs/architecture/adr/013-override-exception-governance.md
@@ -0,0 +1,28 @@
+# ADR-013: How to Handle Legitimate Exceptions Without Undermining Governance
+
+**Status:** Accepted
+**Date:** April 2026
+**Docs:** Doc B §18 (Override Model)
+
+## Context
+
+Policies will block legitimate requests. A data residency policy may block a valid exception for a disaster recovery scenario. A sizing policy may block a temporary capacity burst for a product launch. If the only options are "change the policy" or "work around the system," governance degrades.
+
+## Decision
+
+Five override mechanisms, layered from least to most disruptive:
+
+1. **Override Policy** — A planned exception registered in advance (e.g., "DR events may use US-EAST zone")
+2. **Exception Grant** — A pre-authorized waiver with compensating controls and expiry
+3. **Manual Override** — Immediate single-request authorization with written justification
+4. **Compensating Control** — Replace a blocked requirement with an equivalent risk-reduction measure
+5. **Dual-Approval** — Required modifier for hard-enforcement policies (two approvers, different roles)
+
+**The consumer experience:** When a policy blocks a request, the consumer sees the blocking reason, compliant value suggestions, and four options: modify the request, request an override, cancel, or escalate. Override is one path among four — not the default.
+
+## Consequences
+
+- Every override is audited with full Merkle tree leaf
+- Frequently-overridden policies are surfaced in metrics for policy review
+- Block timeout auto-cancels requests where the consumer takes no action
+- The governance model is flexible without being permissive
diff --git a/content/docs/architecture/adr/014-multi-tenancy-isolation.md b/content/docs/architecture/adr/014-multi-tenancy-isolation.md
new file mode 100644
index 0000000..32c0af0
--- /dev/null
+++ b/content/docs/architecture/adr/014-multi-tenancy-isolation.md
@@ -0,0 +1,24 @@
+# ADR-014: How Tenants Are Separated
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 11 (Data Store Contracts), Doc 15 (Universal Groups)
+
+## Context
+
+DCM serves multiple teams (tenants) within an organization. Each tenant's data, resources, policies, and audit trails must be isolated. A developer on Team A must not see Team B's resources, and Team A's policies must not affect Team B's requests (unless they're system-level policies that apply to everyone).
+
+## Decision
+
+**Row-Level Security (RLS)** in PostgreSQL enforces tenant isolation at the database layer. Every query is automatically scoped to the actor's tenant — application code cannot accidentally leak cross-tenant data.
+
+Tenants are **DCMGroups** with type `tenant_boundary`. Groups can be nested (organization → department → team) and support the universal group model for flexible organizational mapping.
+
+**Policy domain precedence** respects tenancy: system > platform > tenant > resource_type > entity. A system-level sizing policy applies to all tenants. A tenant-level naming convention applies only to that tenant.
+
+## Consequences
+
+- Tenant isolation is enforced by the database, not application logic — defense in depth
+- Cross-tenant operations (ownership transfer, shared resources) require explicit policy authorization
+- RLS adds a small query overhead (~2-5%) — acceptable for the security guarantee
+- 18 SQL tables all include tenant_uuid columns with RLS policies
diff --git a/content/docs/architecture/adr/015-minimal-infrastructure.md b/content/docs/architecture/adr/015-minimal-infrastructure.md
new file mode 100644
index 0000000..a6f3d45
--- /dev/null
+++ b/content/docs/architecture/adr/015-minimal-infrastructure.md
@@ -0,0 +1,30 @@
+# ADR-015: Why PostgreSQL Is the Only Required Dependency
+
+**Status:** Accepted
+**Date:** March 2026
+**Docs:** Doc 11 (Data Store Contracts), Doc 17 (Deployment)
+
+## Context
+
+Infrastructure management platforms often require heavy middleware stacks: message brokers, secret managers, identity providers, search engines. This creates a bootstrap problem — you need significant infrastructure just to manage infrastructure. It also blocks adoption in resource-constrained environments (homelab, edge, evaluation).
+
+## Decision
+
+PostgreSQL is the only required dependency. DCM implements internal equivalents for every capability that optional services provide:
+
+| Capability | Internal (default) | External (optional) |
+|-----------|-------------------|-------------------|
+| Events | PostgreSQL LISTEN/NOTIFY | Kafka |
+| Secrets | Envelope-encrypted table | Vault |
+| Auth | Built-in bcrypt + JWT | Keycloak/OIDC |
+| Search | PostgreSQL full-text + GIN | OpenSearch |
+| Notifications | PostgreSQL LISTEN/NOTIFY + webhooks | External notification service |
+
+Every optional dependency follows the same pattern: internal by default, externally delegable by configuration. The same API surface is exposed regardless of which implementation is active.
+
+## Consequences
+
+- Bootstrap is `docker-compose up` with one PostgreSQL container
+- Production deployments can delegate to Kafka, Vault, Keycloak when scale or policy requires it
+- Internal implementations have performance ceilings (LISTEN/NOTIFY: ~1K events/sec vs Kafka: millions)
+- Every new cross-cutting service must implement the internal path first
diff --git a/content/docs/architecture/adr/016-application-definition-language.md b/content/docs/architecture/adr/016-application-definition-language.md
new file mode 100644
index 0000000..39365e1
--- /dev/null
+++ b/content/docs/architecture/adr/016-application-definition-language.md
@@ -0,0 +1,114 @@
+# ADR-016: Application Definition Language
+
+**Status:** OPEN — Design Decision Required
+**Date:** April 2026
+**Raised by:** Ondra (machacekondra), repeatedly
+
+## Context
+
+DCM currently has two consumer interfaces:
+
+1. **Single resource** — A JSON payload to the Consumer API: `POST /api/v1/requests { "catalog_item_uuid": "...", "fields": {...} }`
+2. **Compound service** — A compound resource type spec that defines constituent resources, dependencies, and binding fields in YAML
+
+The single-resource API works well for atomic resources. The compound service definition (compound service model) works for platform engineers who define reusable application templates. But there is a gap:
+
+**How does a consumer define a custom application?** Not a pre-defined catalog item, but an ad-hoc composition: "I need a database, two app servers, and a load balancer, and here's how they connect." Today, this requires a platform engineer to create a compound resource type spec first.
+
+Comparable projects have made different choices:
+- **Radius** uses Bicep (a DSL) for application definitions, with Recipes (Terraform/Bicep templates) for infrastructure implementation
+- **KRO** uses ResourceGraphDefinitions with CEL expressions, generating CRDs from the definition
+- **Crossplane** uses Compositions with embedded resource templates and patch sets
+
+## The Question
+
+What is DCM's application definition language? Options to evaluate:
+
+### Option A: API-Only (Current State)
+Consumers submit JSON payloads. Compound services require pre-defined compound resource type specs. Platform engineers author specs; consumers consume them.
+
+**Pros:** Simple, API-first, no custom language to learn
+**Cons:** No self-service composition. Every new application pattern requires a platform engineer.
+
+### Option B: YAML Application Manifests
+A YAML document defining resources, dependencies, and binding fields — similar to the compound resource type spec but authored by consumers, not platform engineers.
+
+```yaml
+apiVersion: dcm.io/v1
+kind: Application
+metadata:
+ name: pet-clinic
+spec:
+ resources:
+ - name: database
+ type: Database.PostgreSQL
+ fields: { engine: postgresql, storage_gb: 50 }
+ - name: backend
+ type: Compute.VirtualMachine
+ depends_on: [database]
+ bindings:
+ - from: database.ip_address
+ to: config.db_host
+ fields: { cpu_count: 4, memory_gb: 8 }
+ - name: frontend
+ type: Compute.VirtualMachine
+ depends_on: [backend]
+ bindings:
+ - from: backend.ip_address
+ to: config.api_host
+ fields: { cpu_count: 2, memory_gb: 4, replicas: 2 }
+```
+
+**Pros:** Declarative, GitOps-friendly, reviewable, versionable
+**Cons:** New format to learn. Validation complexity. How does this interact with the service catalog?
+
+### Option C: Reference Existing DSL (Bicep, CEL, HCL)
+Adopt an existing language like Radius does with Bicep or KRO does with CEL. Leverage existing tooling and developer familiarity.
+
+**Pros:** Existing tooling, IDE support, community
+**Cons:** Tight coupling to an external project. Bicep is Azure-originated. CEL is K8s-specific. HCL is HashiCorp-specific.
+
+### Option D: Catalog Composition via API
+Consumers compose applications by linking multiple catalog requests through the API, declaring dependencies between them. No new language — just structured API calls.
+
+```json
+POST /api/v1/applications
+{
+ "name": "pet-clinic",
+ "components": [
+ { "name": "database", "catalog_item_uuid": "pg-standard", "fields": {...} },
+ { "name": "backend", "catalog_item_uuid": "vm-standard", "fields": {...},
+ "depends_on": ["database"],
+ "bindings": [{ "from": "database.ip_address", "to": "config.db_host" }] }
+ ]
+}
+```
+
+**Pros:** API-first, no DSL, consistent with existing patterns
+**Cons:** JSON is verbose for complex compositions. Not as readable/reviewable as YAML. No GitOps-friendly file format.
+
+## Evaluation Criteria
+
+1. **Consumer UX** — How easy is it for a developer to define a three-tier app?
+2. **Platform engineer UX** — How easy is it to create reusable templates?
+3. **GitOps compatibility** — Can definitions be stored in Git and applied via PR?
+4. **Validation** — Can DCM validate the definition before execution?
+5. **Existing tooling** — Does it work with existing editors, linters, CI pipelines?
+6. **Consistency with DCM patterns** — Does it align with the API-first, JSON, snake_case conventions?
+
+## Recommendation
+
+This decision needs team input. The author's preliminary assessment:
+
+**Option B (YAML manifests) or Option D (API composition) are most aligned** with DCM's existing patterns. Option B is better for GitOps. Option D is better for API-first consistency. They could coexist — the YAML manifest could be a file format that the API endpoint accepts.
+
+**Option C (external DSL) is least aligned** — it introduces a dependency on an external project's language and tooling, which conflicts with DCM's technology-agnostic principle.
+
+**Regardless of choice, the compound resource type spec remains the implementation mechanism.** The application definition language is a consumer-facing UX that ultimately produces a compound resource type spec (or equivalent) for execution.
+
+## Actions Required
+
+- [ ] Team discussion to evaluate options
+- [ ] Prototype consumer UX for three-tier app with top 2 options
+- [ ] Evaluate interaction with RHDH (Backstage) scaffolding templates
+- [ ] Decision by [date TBD]
diff --git a/content/docs/architecture/adr/README.md b/content/docs/architecture/adr/README.md
new file mode 100644
index 0000000..2bf1325
--- /dev/null
+++ b/content/docs/architecture/adr/README.md
@@ -0,0 +1,24 @@
+# Architecture Decision Records
+
+Short, reviewable summaries of the major architectural decisions in DCM. Each ADR answers **"Why does this exist and what does it do?"** — not implementation details.
+
+**Reading order:** ADRs 001-003 establish the foundations. Read those first, then jump to whichever ADRs are relevant to your area.
+
+| ADR | Decision | One-Line Summary |
+|-----|----------|-----------------|
+| [001](001-why-dcm-exists.md) | Why DCM Exists | Unified management plane for on-prem infrastructure — the governance layer above provisioning tools |
+| [002](002-three-abstractions.md) | Three Foundational Abstractions | Everything in DCM is Data, Provider, or Policy — no exceptions |
+| [003](003-four-lifecycle-states.md) | Four Lifecycle States | Intent → Requested → Realized → Discovered — immutable states linked by entity_uuid |
+| [004](004-service-catalog-consumer-experience.md) | Service Catalog & Consumer UX | Four-level hierarchy from resource types to catalog items; consumers declare what, not how |
+| [005](005-provider-abstraction.md) | Provider Abstraction | 5 provider types with naturalization/denaturalization; any platform, same interface |
+| [006](006-policy-engine.md) | Policy Engine | Policy-as-code on every request; 8 policy types from gatekeeping to orchestration flow |
+| [007](007-placement-engine.md) | Placement Engine | Multi-stage scoring: sovereignty pre-filter → capability → capacity → policy scoring |
+| [008](008-dependency-resolution.md) | Dependency Resolution | Type-level dependencies trigger automatic sub-requests; binding fields inject runtime values |
+| [009](009-api-gateway-control-plane.md) | API Gateway & Control Plane | Single entry point routing to 9 internal services; deterministic pipeline |
+| [010](010-audit-tamper-evidence.md) | Audit & Tamper Evidence | Merkle tree (RFC 9162) with configurable granularity; mathematically provable integrity |
+| [011](011-sovereignty-data-residency.md) | Sovereignty & Data Residency | First-class enforcement on every lifecycle operation; dual-approval for overrides |
+| [012](012-data-assembly-layering.md) | Data Assembly & Layering | Organizational data merges with consumer requests; field-level provenance on everything |
+| [013](013-override-exception-governance.md) | Override & Exception Governance | 5 mechanisms from planned exceptions to dual-approval; governance with flexibility |
+| [014](014-multi-tenancy-isolation.md) | Multi-Tenancy & Isolation | PostgreSQL RLS enforces tenant isolation at the database layer |
+| [015](015-minimal-infrastructure.md) | Minimal Infrastructure | PostgreSQL is the only required dependency; everything else is optional |
+| [016](016-application-definition-language.md) | Application Definition Language | **OPEN** — How should consumers define multi-resource applications? Options under evaluation |
diff --git a/content/docs/architecture/ai-prompt.md b/content/docs/architecture/ai-prompt.md
new file mode 100644
index 0000000..f03cf9a
--- /dev/null
+++ b/content/docs/architecture/ai-prompt.md
@@ -0,0 +1,5895 @@
+## SECTION 0 — THE THREE FOUNDATIONAL ABSTRACTIONS (READ FIRST)
+
+DCM is built on three foundational abstractions. Every concept maps to one or more of these three. There is no fourth.
+
+### DATA — Everything That Exists
+Any structured artifact with a type, UUID, lifecycle state, fields, data classification, and provenance. Entities, layers, policies, accreditations, audit records, groups, relationships, sovereignty zones, registration tokens — all Data.
+
+**Universal Data properties:** UUID (stable across full lifecycle) · typed · lifecycle state · artifact metadata (handle, version, status, owned_by) · field-level provenance · data_classification per field · immutable if versioned
+
+**Data lifecycle stages (four states):** Intent State (consumer declaration) → Requested State (assembled, policy-validated) → Realized State (provider-confirmed) → Discovered State (independently observed). These are the same entity at four lifecycle stages stored in different stores optimized for each access pattern.
+
+**Data is assembled via layers** in deterministic precedence order. Every field carries provenance of its origin and all modifications.
+
+### PROVIDER — Everything External
+Any external component DCM calls or that calls DCM. All providers implement the **unified base contract** (registration, health, sovereignty, accreditation, governance matrix enforcement, zero trust) plus a **typed capability extension** that declares what operations they expose.
+
+**Five provider types (all implement the same base contract):**
+Service Provider (realize resources — including Credential.*, Notification.*, ITSM.* resource types) · Information Provider (serve authoritative external data) · Auth Provider (authenticate identities) · Peer DCM (federation — another DCM instance IS a typed provider) · Process Provider (execute workflows without producing resources)
+
+**Adding a new provider type** = implement base contract + define capability extension. No core changes.
+
+### POLICY — Everything That Decides
+Any rule artifact that fires when Data matches conditions, produces a typed output, and is enforced at a declared level. Policies govern every transition, transformation, and constraint.
+
+**Eight policy types (all implement the same base contract):**
+GateKeeper (allow/deny) · Validation (pass/fail) · Transformation (field mutations) · Recovery (failure actions) · Orchestration Flow (pipeline ordering) · Governance Matrix Rule (boundary control) · Lifecycle Policy (relationship event actions) · ITSM Action (side-effect ITSM record creation)
+
+**Policies ARE the orchestration.** Pipeline steps are policies firing on payload type events. Static flows = Orchestration Flow policies with `ordered: true`. Dynamic flows = conditional policies. Adding/removing pipeline steps = adding/removing policies.
+
+**Adding a new policy type** = define a new output schema. Base contract inherited automatically.
+
+### THE RUNTIME — Connecting the Three
+```
+Event (Data state change)
+ → Policy Engine evaluates all matching Policies
+ → Policies produce decisions / mutations / actions
+ → Actions invoke Providers or produce new Data
+ → New Data triggers new Events
+ → Repeat
+```
+
+Control plane "components" are runtime specializations — not a fourth abstraction:
+- Request Orchestrator = event bus (runtime)
+- Policy Engine = policy evaluator (runtime)
+- Placement Engine = GateKeeper policy specialized for provider selection
+- Cost Analysis = Information Provider (internal; data derivation)
+- Lifecycle Constraint Enforcer = scheduled Recovery Policy trigger
+- Discovery Scheduler = scheduled Provider invocation
+- Notification Router = Transformation Policy + notification service invocation
+- Drift Reconciliation = Data comparison producing Drift Record artifacts
+- Search Index = PostgreSQL store contract (queryable projection)
+
+### THE CORE ETHOS
+Effective at the core mission · Easy to use · Easy to implement · Easy to extend and integrate
+
+**Foundation documents:** 00-foundations.md (three abstractions) · A-provider-contract.md (unified provider base) · B-policy-contract.md (unified policy base)
+
+---
+
+# DCM Project — AI Model Prompt Script
+
+**Purpose:** This script provides an AI model with the full context needed to participate effectively in DCM project work. It should be provided at the start of any AI-assisted session involving DCM architecture, documentation, code, or design work.
+
+**Usage:** Paste this document into the AI model's context at the start of a session. Follow with the specific task or question.
+
+**Maintainers:** Update this document whenever significant architectural decisions are made, new concepts are established, or open questions are resolved.
+
+**Last Updated:** 2026-03
+**Status:** Architecture complete — 0 unresolved questions — Ready for implementation
+
+**Note on section structure:** This prompt was built cumulatively across multiple design sessions. Sections 0–57 establish the architecture. Sections 58+ record subsequent additions and refinements. Capability counts, path counts, and domain counts in earlier sections reflect the state at the time that section was written. The authoritative current counts are: **331 capabilities across 39 domains · 58 data model docs · 15 specifications · 16 ADRs · 74 consumer API paths · 61 admin API paths · 109 event payloads across 23 domains · 5 provider types · 2 policy evaluation modes · 9 control plane services · 104 prompt sections.** When earlier sections conflict with later sections, the later section is authoritative. **Infrastructure (doc 51):** 5 provider types: service_provider, information_provider, auth_provider, peer_dcm, process_provider. Credentials and notifications are service_provider resource types. 2 policy evaluation modes: Internal (DCM evaluates via OPA) and External (external provider evaluates). Four data domains (Intent, Requested, Realized, Discovered) in a single PostgreSQL-compatible database. One required infrastructure: PostgreSQL-compatible DB. Authentication (local accounts + JWT), secrets (envelope encryption), and event routing (LISTEN/NOTIFY) are handled internally. OIDC IdP, Vault, Kafka, Redis, Git are optional deployment enhancements. 9 control plane services.
+
+---
+
+## SECTION 0b — DESIGN PRIORITY ORDER (applies to all decisions)
+
+> **Full specification:** [00-design-priorities.md](data-model/00-design-priorities.md) — includes decision framework, profile scaling table, and DPO-001–006 system policies.
+
+**Priority 1 — Security (industry best practices):** Security properties are architecturally present in ALL profiles. What profiles control is enforcement strictness, threshold values, and automation level — not whether security applies. A `minimal` profile is "security with minimal operational overhead" — not "minimal security."
+
+**Priority 2 — Ease of use:** The secure path must be the easy path. If the right path is also the hard path, teams will find other paths. Auto-approval for ordinary requests, policy authoring without Rego expertise, and profile defaults that eliminate configuration burden all serve this priority.
+
+**Priority 3 — Extensibility/grouping:** Profile system, compliance domain overlays, policy groups, and registry governance enable adaptability through configuration, not code. New compliance requirements are policy additions. New deployment contexts are profile configurations.
+
+**Priority 4 — Fit for purpose (always required):** DCM must manage data center infrastructure lifecycle end-to-end. Everything above serves this purpose. A system that cannot provision, track, and decommission a VM has failed.
+
+**Implication for all design decisions:** When security and convenience conflict, security wins — but find a way to make the secure option easy. When extensibility and fit for purpose conflict, fit for purpose wins. When a profile tempts you to disable a security property rather than raise its threshold, the priority order says: keep the property, raise the threshold.
+
+---
+
+## SECTION 1 — PROJECT IDENTITY
+
+You are assisting with the **DCM (Data Center Management)** project, an open-source strategic framework developed by the Red Hat FlightPath team developed by the Red Hat FlightPath Team.
+
+**Key facts:**
+- DCM is NOT a provisioning tool — it is a **governing framework**
+- DCM is a **top-down orchestration and policy enforcement layer**
+- DCM enables enterprises to achieve a "Private Cloud" / "Sovereign Cloud" experience with public cloud efficiencies on-premises
+- DCM is **API-first, data-driven, and policy-governed**
+- DCM is inspired by Kubernetes' declarative control plane model
+- GitHub: https://github.com/dcm-project
+- Website: https://dcm-project.github.io
+
+**Authors:** Chris Roadfeldt (Principal Architect), Ryan Goodson (Senior Principal Architect), Adam Seeley (Global Director) — Red Hat FlightPath.
+
+**Vision:** To make life better for all customers, internal teams, and future-looking entities.
+
+**Mission:** Seamlessly manage the complete lifecycle of all data center infrastructure by providing a policy-governed, data-driven, and unified platform to enable and ensure sovereignty.
+
+---
+
+## SECTION 2 — THE PROBLEM DCM SOLVES
+
+Organizations face these core challenges that DCM addresses:
+
+1. **Fragmented Operations** — disparate tools, no unified management, functionality trapped in monoliths
+2. **No Single Source of Truth** — multiple CMDBs diverge, no trustworthy representation of infrastructure state
+3. **High Time-to-Market** — a single VM lifecycle may be managed by dozens of teams; firewall changes can take weeks
+4. **The Private Cloud Gap** — "Private Cloud" ≠ "On-Premises Compute"; a true private cloud requires networking, storage, identity, catalog, FinOps, observability, auditing, and risk management
+5. **Drift and State Discrepancy** — no reconciliation between discovered inventory and intended inventory
+6. **Sovereignty Requirements** — organizations must enforce data residency, compliance, and operational control across their infrastructure
+
+**The definitional clarification DCM makes:**
+- Private Cloud ≠ On-Premises Compute
+- Private Cloud > On-Premises IaaS
+- Private Cloud = Hyperscale experience for on-premises infrastructure
+
+---
+
+## SECTION 3 — FOUNDATIONAL PRINCIPLES
+
+These three constraints apply to ALL data, entities, and operations in DCM **universally and without exception:**
+
+### 3.1 Declarative
+Data describes **what something is or should be**, not how to achieve it. Every entity is a complete, self-describing statement of state. The procedures required to achieve that state are the concern of the Service Provider, not the data model.
+
+### 3.2 Idempotent in Operation
+Applying the same data to the same system multiple times must always produce the same result. No operation on DCM data should have different outcomes based on how many times it has been applied.
+
+### 3.3 Immutable if Versioned
+Once a version of any entity is published, it cannot be modified. Changes produce a new version. Previous versions remain intact and accessible forever.
+
+---
+
+## SECTION 4 — THE DCM DATA MODEL
+
+**The data model is the most foundational element of DCM.** Everything in DCM acts on data in some way — reading, validating, triggering, enriching, gatekeeping, parsing, transforming, or comparing. The data model is the lingua franca — the API between all components.
+
+### 4.1 Universal Identity Requirement
+Every data object in DCM **must have a UUID**. This applies without exception to: resource definitions, catalog items, data layers, policies, policy sets, components, service providers, consumers, requests, and all other entities. UUIDs are used for provenance anchoring, dependency mapping, audit fidelity, and cross-state correlation.
+
+### 4.2 The Four States
+DCM tracks every resource through four distinct states. Together they provide complete visibility into what was wanted, what was asked for, what was built, and what actually exists.
+
+| State | Description | Store | Created By |
+|-------|-------------|-------|------------|
+| **Intent** | What the consumer wants — raw declared desire before any processing | Intent Store | Consumer (Web UI / API) |
+| **Requested** | Fully processed, policy-validated, enriched payload submitted to a provider | Request Store | Request Payload Processor |
+| **Realized** | What was actually provisioned, returned by the provider in DCM unified format | Realized Store | Service Provider (via Denaturalization) |
+| **Discovered** | What actually exists, as independently interrogated by a provider during discovery | Discovered Store | Service Provider (via Discovery) |
+
+**Key operations across states:**
+- **Drift Detection:** Discovered State vs. Realized State
+- **Request Validation:** Requested State vs. Policy definitions
+- **Intent Portability:** Intent State → re-process through current policies → new Requested State
+- **Brownfield Ingestion:** Discovered State → enrichment → Realized State (lifecycle ownership)
+
+**State lifecycle flow:**
+```
+Consumer Request → INTENT → (Policy Engine) → REQUESTED → (Service Provider) → REALIZED
+ ↕ compare
+ DISCOVERED ────────► Drift Detection
+```
+
+### 4.3 Field-Level Provenance and Data Lineage
+This is a **structural requirement** of the data model — not a logging concern.
+
+For any field, at any point in the pipeline, it must be possible to determine:
+- What is the current value?
+- Where did this value originate? (catalog item, layer, policy, consumer input, discovery)
+- Has it been modified? If so — what changed it, which entity (by UUID), when, what was the previous value, and why?
+- What is the complete chain of custody from origin to current value?
+
+**Provenance is carried within the data object itself** — co-located with the data, not in an external log.
+
+Every component that modifies data carries a **provenance obligation** — it must record its UUID, operation type, timestamp, and reason for every field it modifies. This is non-optional.
+
+Conceptual provenance structure per field:
+```yaml
+field_name:
+ value:
+ metadata:
+ override:
+ basis_for_value:
+ baseline_value:
+ locked_by_policy_uuid:
+ locked_at_level:
+ constraint_schema:
+ provenance:
+ origin:
+ value:
+ source_type:
+ source_uuid:
+ timestamp:
+ modifications:
+ - sequence: 1
+ previous_value:
+ modified_value:
+ source_type:
+ source_uuid:
+ operation_type:
+ actor:
+ timestamp:
+ reason:
+```
+The `metadata` block is set exclusively by the Policy Engine. `operation_type: lock` is used when a GateKeeper sets `override: immutable`. `operation_type: grant` is used when a trusted_grant is issued.
+
+### 4.4 Universal Versioning
+All entities, definitions, and data objects in DCM follow one versioning scheme: **Major.Minor.Revision**
+
+| Component | Trigger |
+|-----------|---------|
+| **Major** | Breaking changes to the contract |
+| **Minor** | Additive changes, backward compatible |
+| **Revision** | Data/configuration changes, no contract impact |
+
+This applies universally to: resource types, layers, policies, catalog items, provider registrations, registry entries, and all other definitions.
+
+### 4.5 Universal Artifact Status Lifecycle
+Every DCM artifact — layers, policies, resource types, catalog items, provider registrations — follows a five-status lifecycle:
+
+| Status | Meaning | Applied? | Shadow? |
+|--------|---------|---------|---------|
+| `developing` | In development | No — dev mode only | No |
+| `proposed` | Submitted for review/validation | No | Yes — policies shadow-execute against real traffic, output captured not applied |
+| `active` | Live and governing | Yes | Yes — audit records |
+| `deprecated` | Being phased out, replacement available | Yes — with warning | Yes |
+| `retired` | End of life | No | No — terminal |
+
+**Status transitions:** `developing → proposed → active → deprecated → retired`
+Deprecated artifacts must include: replacement UUID, deprecation reason, migration guidance, sunset date.
+
+**Previously:** The model had only `active → deprecated → retired`. The `developing` and `proposed` statuses were added to support the full artifact development workflow — especially the shadow execution validation model for policies.
+
+### 4.6 Artifact Metadata Standard
+Every DCM artifact carries a universal metadata block — applies to all artifacts without exception:
+- `uuid` — immutable, DCM-assigned at creation
+- `handle` — human-readable stable ID: `{domain}/{layer_type}/{name}` e.g. `platform/core/security-cpu-limits`
+- `version` — Major.Minor.Revision
+- `status` — five-status lifecycle (Section 4.5)
+- `created_by` — audit record (who submitted): UUID optional + display_name required
+- `owned_by` — accountability record (who is responsible, receives notifications): UUID optional + display_name required
+- `created_via` — ingestion path: `pr | api | migration | system`
+- `modifications` — append-only history of all changes with who/when/why
+
+**Contact modes:** UUID+display_name when Identity Provider registered; display_name+email standalone/air-gapped. Both supported.
+
+### 4.7 Provider Types
+All five provider types follow the same base contract (registration, health check, trust, sovereignty, accreditation, governance matrix enforcement, zero trust, provenance emission). See Section 0 for the complete list. The four original categories and their data ownership model:
+
+| Type | Purpose | DCM Owns Result? |
+|------|---------|-----------------|
+| **Service Provider** | Realizes resources — KubeVirt, VMware, AAP, Terraform | Yes |
+| **Information Provider** | Serves authoritative external data DCM references but does not own | No — external system is authoritative |
+| **Meta Provider** | Composes multiple providers into higher-order services | Yes |
+
+
+The five provider types (service_provider, information_provider, auth_provider, peer_dcm, process_provider) all implement the same base contract. Capabilities that were formerly separate provider types (credentials, notifications, ITSM, message bus, storage, policy evaluation, registry) are now either internal to DCM or handled by service_providers with specialized resource types. See [A-provider-contract.md](data-model/A-provider-contract.md) for the unified contract.
+
+---
+
+## SECTION 5 — THE FOUR STATES AND STORAGE MODEL
+
+### 5.1 The Four States
+
+Every DCM entity exists across four independently maintained state records:
+
+| State | Question | Store Type | Characteristics |
+|-------|----------|------------|----------------|
+| **Intent State** | What did the consumer ask for? | GitOps | Immutable, branched, PR reviewed, CI/CD triggered |
+| **Requested State** | What was approved and dispatched? | GitOps | Immutable, committed, CD triggered, full provenance |
+| **Realized State** | What did the provider actually build? | Event Stream | Append-only, entity-keyed stream, high-frequency |
+| **Discovered State** | What actually exists right now? | Event Stream (ephemeral) | Machine-generated, drift detection source |
+
+### 5.2 Storage Architecture — Contract, Not Implementation
+
+DCM defines store **contracts** — what capabilities, guarantees, and obligations each store must satisfy. Implementation technology is a deployment choice. PostgreSQL is the single required infrastructure.
+
+```
+GitOps Stores: Intent, Requested, Layers, Policies
+Event Stream Stores: Realized, Discovered, Audit events
+Search Index: Queryable projection of GitOps stores (non-authoritative)
+Audit Store: Compliance-grade, immutable, long-retention
+Observability Store: Time-series metrics, traces, logs
+```
+
+### 5.3 The Entity UUID — Universal Key
+The entity UUID is assigned at Intent State creation and links the entity across all four states and all stores. Given an entity UUID, DCM can reconstruct the complete lifecycle history from any store.
+
+### 5.4 CI/CD Integration
+GitOps stores are the natural CI/CD integration point:
+- **CI pipeline** fires on branch/update: policy pre-validation (dry run), cost estimation, sovereignty check, auto-approve evaluation — results posted as PR comments
+- **CD pipeline** fires on merge: layer assembly, full policy evaluation (binding), provider dispatch
+- **Third rail — direct API ingress**: bypasses PR workflow, not governance. Same pipeline, no human review unless required by policy.
+
+### 5.5 Rehydration — Three Sources, Six Modes
+
+Rehydration uses a prior state record as the starting point for a new request. Governance always applies — rehydration is a new request, not a shortcut.
+
+**Three sources:** Intent Store (full assembly runs), Requested Store (assembly skipped, governance runs), Realized Store (provider fields stripped, assembly skipped, governance runs)
+
+**Two axes — six modes:**
+
+| Mode | re_evaluate | policy_version | Use Case |
+|------|-------------|----------------|----------|
+| Faithful | false | current | Same provider, current governance |
+| Provider-Portable | true | current | New provider, current governance |
+| Historical Exact | false | pinned | Same provider, historical governance (audit evidence) |
+| Historical Portable | true | pinned | New provider, historical governance |
+
+**Placement flag on Requested/Realized rehydration:**
+```yaml
+placement:
+ re_evaluate: false # Honor original provider selection (default)
+ # re_evaluate: true # Strip provider, run placement policies fresh
+governance:
+ apply_all_policies: true # Always true — never skippable
+ policy_version: current # current | pinned (pinned requires elevated auth)
+```
+
+**Named concept:** Provider-Portable Rehydration — rehydration with provider selection re-evaluated through current placement policies and current provider landscape.
+
+**Partial Q54 resolution:** Policies set placement constraints. The placement component selects the specific provider within those constraints. Policies never name a specific provider — that would be portability-breaking.
+
+### 5.6 Audit, Provenance, and Observability — Three Distinct Concerns
+
+| Concern | What It Is | Audience | Retention |
+|---------|-----------|----------|-----------|
+| **Provenance** | Field-level data lineage embedded in every payload | System | Permanent — part of the data |
+| **Audit** | Compliance-grade queryable record of all actions | Auditors, Compliance | Regulatory period (7+ years FSI) |
+| **Observability** | Real-time metrics, traces, logs | SRE, Platform Engineers | Operational window (90 days) |
+
+Audit is a **separate component** fed by provenance events emitted by all store contracts (contractual obligation). Surfaced through the DCM API Gateway — not a separate endpoint.
+
+All DCM capabilities — catalog, requests, entities, policies, audit, observability — are surfaced through a **unified API Gateway hierarchy**.
+
+---
+
+## SECTION 6 — DATA LAYERS AND THE ASSEMBLY PROCESS
+
+### 6.1 Layers vs Policies — The Clear Distinction
+
+**Layers are data.** They carry static configuration, defaults, metadata, and context assembled into the request payload. A layer answers: "what values should these fields have?" Layers are passive — they declare values but do not execute logic. They come first in assembly (Steps 1-4).
+
+**Policies are logic.** They evaluate the assembled payload and enforce rules, inject derived values, and make decisions. A policy answers: "given this data, is it valid? what should change? should this proceed?" Policies execute — they run code. They come after layers (Steps 5-9).
+
+**The flow is strictly unidirectional:**
+```
+Steps 1-4: LAYERS assembled → merged payload produced (data)
+Steps 5-9: POLICIES execute → payload evaluated and acted upon (logic)
+```
+
+**The decision rule:** Value that should appear in payload → Layer. Rule about whether payload is correct → Policy. Value derived by evaluating payload → Policy (Transformation type).
+
+**What belongs in layers:** infrastructure defaults, organizational context, service configuration defaults, compliance metadata, business context labels.
+
+**What belongs in policies:** validation rules, compliance enforcement, derived value injection, placement constraints, approval gates, security enforcement.
+
+A policy that repeatedly injects the same static value into every request → that value belongs in a layer. A layer that contains conditional logic → that logic belongs in a policy.
+
+### 6.2 Layer Domain Model (mirrors Policy domain)
+
+| Domain | Authority | Can Override |
+|--------|----------|-------------|
+| `system` | DCM built-in — highest | Nothing above system |
+| `platform` | Platform team | tenant, service, provider |
+| `tenant` | Tenant Admin | service, provider within Tenant |
+| `service` | Service Provider | provider |
+| `provider` | Provider owner | Nothing above provider |
+| `request` | Consumer — lowest | Nothing above request |
+
+### 6.3 The Full Layer Structure
+
+Every layer carries: artifact_metadata (standard), domain + priority (authority), concern_tags (discoverability), compatibility (resource_types, versions, profile_constraints), activation_condition (Q23 — conditional inclusion), fields with per-field override metadata (override: allow/constrained/immutable, basis_for_value), and usage context (description, applies_when, excludes_when, conflicts_with).
+
+**activation_condition** — layer only included if condition evaluates true during Step 2. Conditions reference: request fields, tenant attributes, resource type fields, resolved core layer fields, ingress fields. Enables role-specific layers, GPU-only layers, PCI-scope-only layers.
+
+### 6.4 Layer Groups
+
+Layer Groups are `DCMGroup` with `group_class: layer_grouping` — cohesive collections of related layers. Same model as Policy Groups. Enables discovery ("show me all PCI compliance layers"), composition, and governance.
+
+### 6.5 Consumer Layer Exclusion (Q21)
+
+Consumers declare `layer_exclusions` with mandatory reason. Excluded layers removed in Step 2, produce no fields, cannot satisfy validation requirements. GateKeeper policies may declare layers non-excludable (LAY-001).
+
+### 6.6 Service Layer Versioning (Q22)
+
+Service Layers independently versioned. Providers declare semver compatibility constraints (`^1.0.0`, `~1.2`). Cache entries carry version — invalidated when registered version changes (LAY-002).
+
+### 6.7 Conditional Layer Inclusion (Q23)
+
+`activation_condition` on layer evaluated in Step 2. False → layer excluded. Conditions reference request, tenant, resource type, core layer, and ingress fields. Recorded in assembly provenance (LAY-003).
+
+### 6.8 Dependency Layer Chains (Q24)
+
+Each service dependency has its own independent layer chain. Inherits parent's resolved placement fields (read-only). Does NOT inherit parent consumer declarations or type-specific layers. Layer exclusions declarable per-dependency (LAY-004).
+
+### 6.9 The Nine-Step Assembly Process
+
+Step 1 (Intent Capture) → Step 2 (Layer Resolution — with exclusions and activation_conditions) → Step 3 (Layer Merge — priority ordering, field-level provenance) → Step 4 (Request Layer Application) → Step 5 (Pre-Placement Policies: Transformation → Validation → GateKeeper) → Step 6 (Placement Engine Loop: reserve query + loop policy phase per candidate) → Step 7 (Post-Placement Policies) → Step 8 (Requested State Storage) → Step 9 (Provider Dispatch)
+
+### 6.10 Layer System Policies
+- `LAY-001` — Consumer layer exclusions with mandatory reason; GateKeeper can lock layers as non-excludable
+- `LAY-002` — Service Layers independently versioned; semver compatibility on provider; cache invalidation on version change
+- `LAY-003` — activation_condition on layers evaluated in Step 2; results recorded in provenance
+- `LAY-004` — Each dependency has own layer chain; inherits parent resolved placement; no consumer declaration inheritance
+
+## SECTION 7 — RESOURCE TYPE HIERARCHY AND SERVICE CATALOG
+
+The Resource Type Hierarchy is how DCM achieves **resource portability** — expressing what a consumer needs independently of which specific provider delivers it.
+
+### 7.1 The DCM Resource Type Registry
+- DCM maintains an official registry of standard Resource Types
+- Registry is **open** — community and implementors can propose new types
+- All registry entries are **vendor-neutral by hard requirement**
+- Exception: `exclusive` classification where one provider is the sole implementor
+- Registry entries are versioned, immutable once published, and can be deprecated
+
+### 7.2 Four Hierarchy Levels
+
+**Level 1 — Resource Type Category** (broadest)
+Organizational container. Examples: `Compute`, `Network`, `Storage`, `Platform`, `Security`, `Observability`, `Data`
+
+**Level 2 — Resource Type** (abstract)
+Defines a class of resource. Must be vendor-neutral. Examples: `Compute.VirtualMachine`, `Network.FirewallRule`
+
+**Level 3 — Resource Type Specification** (standard contract)
+The data contract for a Resource Type — all fields with types, constraints, and portability classifications.
+
+**Level 4 — Provider Catalog Item** (concrete)
+A specific provider's implementation of a Resource Type Specification.
+
+### 7.3 Portability Classification
+Every field in every Resource Type Specification carries a portability classification:
+
+| Classification | Meaning | Portability |
+|---|---|---|
+| `universal` | All providers must support it | Fully portable |
+| `conditional` | Some providers support it | Portable to supporting providers |
+| `provider-specific` | One provider only | Portability-breaking — must be marked |
+| `exclusive` | One provider for entire tech stack | Not applicable — declared |
+
+**Hard requirements:**
+- All `universal` fields MUST be supported by ALL implementing providers
+- `provider-specific` fields MUST be marked portability-breaking
+- Consumers MUST be warned when their request contains portability-breaking fields
+- Portability warning enforcement is **organizational policy**: `block` | `warn` | `allow`
+
+### 7.4 Inheritance
+Resource Types support inheritance. Rules:
+- Child inherits ALL parent fields — none can be removed or redefined
+- Child may add new fields
+- Child portability can only be equal to or more restrictive than parent
+- Each level is independently versioned with parent UUID reference
+
+### 7.5 Request Resolution — Specificity Narrowing
+Provider selection is **never explicit**. It emerges from progressive specificity:
+```
+Resource Type declared → matches all providers for that type
+Universal fields specified → still matches all providers
+Conditional fields specified → narrows to supporting providers
+Provider-specific fields used → narrows to single provider (portability warning issued)
+Placement/sovereignty applied → final provider selected by Policy Engine
+```
+
+---
+
+## SECTION 8 — RESOURCE/SERVICE ENTITIES
+
+### 8.1 Core Terminology
+
+| Term | Definition |
+|------|-----------|
+| **Resource/Service Request** | What a consumer submits to DCM — the declared intent to consume a resource or service. The consumer side of the transaction. |
+| **Resource/Service Entity** | The "thing" produced by a provider as a result of fulfilling a request — the allocation made real. The provider side of the transaction. |
+
+### 8.2 DCM as Authoritative Owner — Always
+DCM is ALWAYS the system of record for Resource/Service Entity data. DCM is ALWAYS authoritative for the resource definition. DCM ALWAYS owns the lifecycle. This applies regardless of the operational ownership model.
+
+Providers are **custodians** of the underlying infrastructure — they are not the system of record.
+
+### 8.3 Four Ownership Models
+
+| Model | Description | Example |
+|-------|-------------|---------|
+| **Allocation** | Provider retains internal ownership. Consumer owns the Entity (the allocation). Provider has reclaim rights on decommission. | VM, Container, IP Address |
+| **Cost Analysis Information Provider** | Specialized Information Provider supplying cost estimates, placement cost signals, cost actuals, and budget alerts; DCM provides input data; provider performs calculations |
+| **Orchestration Flow Policy** | Named workflow artifact: Orchestration Flow Policy with `ordered: true`; declares explicit step sequence using payload type vocabulary; first-class Data artifact; versioned, GitOps-managed, profile-bound |
+| **Request Orchestrator** | Runtime event bus; routes lifecycle events to Policy Engine; has no pipeline logic; both named workflows and dynamic policies are evaluated through it |
+| **orchestration (DCM)** | Two-level composable model: Level 1 = named Orchestration Flow Policies (explicit sequence); Level 2 = dynamic policies (conditional, inline); both evaluated by Policy Engine; adding a step = adding to a workflow Policy; adding conditional behavior = writing a dynamic policy |
+| **Provider Catalog Item** | What a specific Service Provider offers consumers: specific resource allocation or process with cost, availability, SLAs; linked to Resource Type Specification version |
+| **cross_tenant_authorization** | DCMGroup with group_class: cross_tenant_authorization; grants one Tenant permission to reference/allocate/stake another Tenant's resources; revocation places active allocations in PENDING_REVIEW |
+| **foundation Tenants** | Three system Tenants created at bootstrap: __platform__, __transitional__, __system__; cannot be decommissioned; declared in bootstrap manifest |
+| **QUOTA_EXCEEDED** | GateKeeper rejection code when resource quota policy fires at Step 5 (pre-placement) |
+| **Federated Contribution Model** | DCM defaults to federated data creation — all authorized actor types (platform admin, consumer/tenant, service provider, peer DCM) can contribute Data artifacts within their domain scope via the GitOps PR model; see doc 28 |
+| **contributor** | Actor type that authored a Data artifact; recorded in artifact_metadata.contributed_by; determines review requirements; platform_admin / consumer / service_provider / peer_dcm |
+| **contributed_by** | Artifact metadata block recording contributor_type, actor UUID, contribution_method, pr_url, reviewed_by; immutable once set |
+| **DPO-001–006** | Design Priority system policies. DPO-001: security properties present in all profiles (not controlled by profiles). DPO-002: every security requirement needs an ease-of-use mechanism. DPO-005: minimal profile = "security with minimal overhead" not "minimal security". DPO-006: when security and ease conflict, redesign ease-of-use, not security. |
+| **FCM-001–008** | Federated Contribution Model system policies; key: FCM-002 (domain scope violations = hard DENY), FCM-003 (GitOps PR for all), FCM-008 (contributor scope limits absolute) |
+| **Unified Governance Matrix** | Single enforcement point for all cross-boundary decisions; four axes (subject/data/target/context); hard vs soft enforcement; field-level granularity (allowlist/blocklist/paths); profile-bound defaults; GMX-001–010 |
+| **governance_matrix_rule** | Artifact declaring match conditions across four axes and a decision (ALLOW/DENY/ALLOW_WITH_CONDITIONS/STRIP_FIELD/REDACT/AUDIT_ONLY) with hard or soft enforcement |
+| **sovereignty_zone** | Registered DCM artifact declaring geopolitical/regulatory boundary; rules reference zones by ID; inter-zone agreements declared explicitly |
+| **STRIP_FIELD** | Governance matrix decision: remove named fields from payload and proceed; if stripped field is required → DENY_REQUEST |
+| **REDACT** | Governance matrix decision: replace field value with ``; field presence preserved; receiver knows field exists but not its value |
+| **Provider Type Registry** | Three-tier registry of approved provider types; each entry declares permissions, default_approval_method, enabled_in_profiles, capability_schema_ref |
+| **registration_token** | Pre-issued by platform admin; scoped to provider_type/handle_pattern/zone; single_use; grants_auto_approval flag; value presented once only |
+| **approval_method** | Registration approval: auto | reviewed | verified | authorized; resolved as most_restrictive(provider_type_default, profile_min, token_effect) |
+| **Drift Reconciliation Component** | Control plane component; compares Discovered vs Realized State; produces drift records and events; never writes to Realized Store; DRC-001–005 |
+| **drift_record** | Artifact produced by Drift Reconciliation; field-by-field comparison result with severity classification; unsanctioned flag; status tracking through resolution |
+| **Placement Engine** | Six-step algorithm: sovereignty filter → accreditation filter → capability filter → reserve query → tie-breaking (policy/priority/affinity/cost/load/hash) → confirm; PLC-001–006 |
+| **reserve_query** | Parallel capacity queries to all eligible provider candidates; PT5M capacity hold; non-responders and insufficient-capacity providers excluded |
+| **consistent hash** | Final placement tie-breaker: SHA-256(request_uuid+resource_type+sorted_candidates); deterministic; never round-robin |
+| **Lifecycle Constraint Enforcer** | Monitors TTL/expiry/max_execution_time; fires expiry actions through standard pipeline; grace period before action; Process Resources: immediate FAILED on breach; LCE-001–005 |
+| **Search Index** | Non-authoritative queryable projection of GitOps stores; indexes key fields; returns git_path for full payload; max staleness PT5M; always rebuildable; SIX-001–004 |
+| **Admin API** | Platform admin REST interface: Tenant lifecycle, provider review, accreditation approval, discovery trigger, orphan resolution, recovery decisions, quota management, Search Index rebuild, bootstrap operations |
+| **PENDING_EXPIRY_ACTION** | Entity state when expiry action fails to execute; Lifecycle Constraint Enforcer retries per Recovery Policy; Platform Admin notified urgency: high |
+| **data_classification** | First-class field metadata: public/internal/confidential/restricted/phi/pci/sovereign/classified; phi/sovereign/classified are immutable once set |
+| **Accreditation** | Formal versioned attestation that a component satisfies a compliance framework; issued by an Accreditor; carries validity period; lifecycle: developing→proposed→active→expired/revoked |
+| **Accreditor** | Entity that issues accreditations: government body, regulatory body, QSA, certification body, or internal audit team |
+| **Accreditation Gap** | Missing, expired, or revoked accreditation required for an active interaction; always high/critical severity; Recovery Policy governs response |
+| **Data/Capability Authorization Matrix** | Policy Group artifact (concern_type: data_authorization_boundary) declaring what data fields and capabilities are permitted across interaction boundaries given data classification and accreditation level |
+| **zero_trust_posture** | Sixth Policy Group concern type; four levels: none/boundary/full/hardware_attested; profile defaults: minimal=none, dev/standard=boundary, prod/fsi=full, sovereign=hardware_attested |
+| **Five-check boundary model** | Identity → Authorization → Accreditation → Matrix → Sovereignty; all five checks at every DCM interaction boundary; all produce audit records |
+| **Federation tunnel** | Mutually authenticated, encrypted, scoped DCM-to-DCM channel; zero trust model; establishes secure transport only, not implicit trust; per-message signing; scoped non-transferable credentials |
+| **hard_constraint** | Data/Capability Matrix declaration that cannot be overridden by any policy; sovereign/classified data never crossing federation boundaries is a hard_constraint |
+| **STRIP_FIELD** | Matrix enforcement action: remove non-permitted field from payload and proceed; if stripped field is required → escalates to DENY_REQUEST |
+| **DENY_REQUEST** | Matrix enforcement action: block entire interaction; entity enters PENDING_REVIEW; notification dispatched |
+| **Request Orchestrator** | DCM control plane event bus; routes lifecycle events to Policy Engine; coordinates pipeline via event-condition-action; does not contain hardcoded pipeline logic |
+| **Cost Analysis Component** | Internal DCM control plane component; three functions: pre-request estimation, placement input, ongoing attribution; not a billing system; not a provider type |
+| **Module** | DCM capability extension adding new functions; distinct from Profile (which configures behavior) |
+| **orchestration_flow** | Policy Group concern_type for static sequential flows; ordered: true; both static and dynamic flows compose through the same Policy Engine |
+| **payload_type** | Closed vocabulary of event types the Request Orchestrator publishes; policies pattern-match on payload type + state |
+| **OPA integration** | Reference implementation for Mode 3 External Policy Evaluators; DCM payload as OPA input document; built-in Rego functions provided by DCM |
+| **Flow GUI** | Visual policy composer and orchestration manager; execution graph view, policy canvas, shadow mode dashboard, flow simulation |
+| **__platform__** | Immutable system Tenant owning DCM control plane resources; created at bootstrap before Policy Engine comes online |
+| **__transitional__** | Immutable system Tenant holding brownfield entities during INGEST phase |
+| **bootstrap manifest** | Signed manifest declaring initial system Tenants, bootstrap admin, and initial profile; hash-verified at every DCM startup |
+| **cross_tenant_authorization** | DCMGroup with this group_class formally grants one Tenant access to another's resources; has lifecycle (duration, renewal, revocation); revocation places active allocations in PENDING_REVIEW |
+| **drift_criticality** | Field-level property in Resource Type Spec (low/medium/high/critical); combined with change magnitude to produce drift severity |
+| **Ingress API** | Infrastructure-layer entry point for all inbound DCM requests; sets ingress block; routes to Consumer/Provider/Admin API surfaces |
+| **Provider Catalog Item** | Provider-specific instantiation of a Resource Type Specification; what consumers actually request; distinct from the Resource Type Specification itself |
+| **Recovery Policy** | Formal DCM policy type mapping trigger conditions (DISPATCH_TIMEOUT, PARTIAL_REALIZATION, etc.) to response actions; same authoring model as GateKeeper/Validation/Transformation |
+| **recovery_posture** | Fifth Policy Group concern_type governing failure and ambiguity response; binds a recovery profile group to the deployment |
+| **DRIFT_RECONCILE** | Recovery action: schedule discovery; let drift detection resolve actual state |
+| **DISCARD_AND_REQUEUE** | Recovery action: best-effort cleanup; new request cycle created immediately |
+| **NOTIFY_AND_WAIT** | Recovery action: notify human; wait for explicit decision up to declared deadline |
+| **TIMEOUT_PENDING** | Infrastructure Resource Entity state: dispatch timeout fired; recovery policy evaluating |
+| **LATE_REALIZATION_PENDING** | Entity state: provider responded after timeout; NOTIFY_AND_WAIT recovery decision pending |
+| **INDETERMINATE_REALIZATION** | Entity state: state ambiguous; drift detection resolving |
+| **COMPENSATION_FAILED** | Entity state: compound service rollback itself failed; orphan detection active |
+| **orphan_candidate** | Resource discovered at provider with no corresponding Realized State record; surfaced to platform admin for human resolution |
+| **Discovery Scheduler** | DCM control plane component maintaining priority queue of discovery requests; dispatches to provider discovery endpoints |
+| **recovery-automated-reconciliation** | Built-in recovery profile: trust drift detection; accept late responses; appropriate for dev/standard |
+| **recovery-notify-and-wait** | Built-in recovery profile: notify human; never act automatically; appropriate for prod/fsi/sovereign |
+| **notification service** | Ninth DCM provider type; translates unified notification envelope to delivery channel; handles delivery, retry, dead letter, and delivery confirmation callbacks |
+| **Notification Router** | DCM control plane component that resolves notification audiences and routes envelopes to notification services |
+| **audience resolution** | Deriving notification recipients by traversing the entity relationship graph from the changed entity at event time |
+| **notification_uuid** | Idempotency key on notification envelopes; notification services use this to deduplicate on retry |
+| **audience_role** | owner / stakeholder / approver / observer — why this actor is in the notification audience |
+| **stakeholder_reason** | Notification envelope field explaining which relationship caused the actor to be in the stakeholder audience |
+| **Tier 1 / Tier 2 / Tier 3 notifications** | Mandatory system (non-suppressable) / Tenant defaults / Actor subscriptions — three subscription tiers that compose |
+| **NOT-001 through NOT-008** | Notification model system policies |
+| **write-once snapshot store** | Realized Store implementation model: each record is a complete immutable entity state snapshot; no event replay; direct point-in-time lookup; supersession chain links snapshots |
+| **corresponding_requested_state_uuid** | Mandatory non-nullable field on every Realized State snapshot; traces every Realized State change to an authorized request |
+| **Provider Update Notification** | Formal API for providers to report authorized state changes; DCM evaluates via Policy Engine; approved → new Requested State + Realized State; rejected → drift event |
+| **notification_uuid** | Idempotency key on Provider Update Notifications; safe to resend on provider crash |
+| **pre-authorized update** | Category of provider update pre-approved by GateKeeper policy; processed automatically without per-change human review |
+| **Whole Allocation** | Entire resource allocated as indivisible unit. Provider retains ownership. Consumer has exclusive use. Not subdivided or shared. | Dedicated Bare Metal (provider-owned) |
+| **Full Transfer** | Provider transfers complete ownership to consumer's DCM Tenant. Consumer controls full lifecycle including decommission. | Transferred Bare Metal, Licensed asset |
+| **Hybrid Transfer** | Ownership can transfer multiple times. Current owner is always exactly one DCM Tenant. Every transfer is tracked and auditable. | Bare Metal reallocated between tenants |
+
+Every Provider Catalog Item must declare which ownership model(s) it supports.
+
+### 8.4 Resource/Service Entity Lifecycle
+```
+REQUESTED → PENDING → PROVISIONING → REALIZED → OPERATIONAL
+ │
+ ┌───────────┼───────────┐
+ ▼ ▼ ▼
+ DEGRADED MAINTENANCE SUSPENDED
+ │
+ DECOMMISSIONING → DECOMMISSIONED
+```
+`DECOMMISSIONED` is the only terminal state. Records are retained permanently and are immutable.
+
+### 8.5 Process Resource Entities
+A distinct entity class for ephemeral execution resources — automation jobs, playbooks, pipelines, workflows.
+- Ephemeral lifecycle — exists for duration of execution
+- Execution record retained permanently after terminal state
+- Must belong to a DCM Tenant
+- Must be in provenance chain of any Resource/Service Entity they affect
+- Lifecycle: `REQUESTED → INITIATED → EXECUTING → COMPLETED | FAILED | CANCELLED`
+
+### 8.6 Provider Capacity Model — Three Modes
+- **Mode 1 — Dynamic Query**: DCM queries provider on-demand during request processing
+- **Mode 2 — Provider Registration (preferred)**: Provider registers capacity on configurable schedule — default minimum twice daily
+- **Mode 3 — Provider Denial (mandatory)**: Provider validates fulfillment capability before executing. Denies with `INSUFFICIENT_RESOURCES`. Triggers immediate DCM capacity rating update.
+
+All three modes are always available. Mode 3 is mandatory for all providers.
+
+### 8.7 Provider Lifecycle Events
+Any provider event affecting Resource/Service Entity availability or operational characteristics MUST be reported to DCM immediately. This is a non-negotiable contractual obligation.
+
+When DCM receives a provider event, the Policy Engine evaluates and determines response:
+`ALERT | REVERT | UPDATE_DEFINITION | INVESTIGATE | DECOMMISSION | ESCALATE`
+
+DCM acts as the **Tenant advocate** — protecting Tenant interests in all provider interactions.
+
+---
+
+## SECTION 9 — SERVICE DEPENDENCIES
+
+### 9.1 Why Dependencies Must Be Declared in Advance
+Dependencies must be declared in the data model — not discovered at runtime. This is required for:
+- **Auditability** — complete dependency graph known before execution
+- **Cost Analysis** — full resource footprint known before provisioning
+- **Placement** — Policy Engine needs complete resource footprint for optimal placement
+- **Idempotency** — same request always produces same dependency graph
+
+### 9.2 Hybrid Dependency Declaration Model
+
+**Type-Level Dependencies (Resource Type Specification)**
+- Portable and provider-agnostic
+- Apply to all Provider Catalog Items implementing that Resource Type
+- Use Resource Type UUIDs — not provider-specific references
+- Required for all implementations
+
+**Provider-Specific Dependencies (Provider Catalog Item)**
+- Provider-specific additions beyond type-level dependencies
+- Must be marked `portability_breaking: true`
+- Visible to Policy Engine and consumers as portability warnings
+
+### 9.3 Dependency Types and Cardinality
+
+| Type | Behavior |
+|------|---------|
+| `hard` | Must be realized before/alongside dependent. Failure fails dependent. |
+| `soft` | Preferred but not blocking. Failure recorded but does not block. |
+| `conditional` | Required only if specific request payload conditions are met. |
+
+| Cardinality | Description |
+|-------------|-------------|
+| `one_to_one` | Exactly one dependency resource required |
+| `one_to_many` | One or more dependency resources required |
+| `one_to_optional` | Zero or one dependency resource |
+| `one_to_range` | Specific numeric range required |
+
+### 9.4 Dependency Graph
+When a request is processed, a complete **Dependency Graph** is constructed — all resources that must be created including all transitive dependencies. Each resource appears exactly once. Circular references are invalid.
+
+The graph is attached to the Requested State. Nodes updated to REALIZED as providers fulfill each dependency.
+
+### 9.5 Dependency Payload Passing
+When a dependency is realized, its Realized State payload is passed to the dependent provider. The dependent resource's Requested State payload is enriched with the dependency entity's UUID and relevant realized data. Recorded in field-level provenance with `source_type: dependency_payload`.
+
+### 9.6 Failure Handling — Configurable per Request or Policy
+
+| Mode | Behavior |
+|------|---------|
+| `fail_all` | Any hard dependency failure fails entire request. Partially realized nodes decommissioned. |
+| `fail_dependent` | Failure fails only the dependent and its dependents. Independent branches continue. |
+| `retry` | Failed dependencies retried with same or alternative provider. |
+| `partial_complete` | Request marked partially complete. Failed nodes flagged for retry or manual intervention. |
+
+### 9.7 Rehydration and Dependencies
+Rehydration uses **Intent State** — not Realized State — to reconstruct the dependency graph. This ensures current policies and standards are applied. Resources can be rehydrated to a different provider as long as type-level dependencies are satisfiable.
+
+---
+
+## SECTION 10 — UNIVERSAL GROUP MODEL AND TENANCY
+
+> The Universal Group Model (document 15-universal-groups.md) supersedes the separate Tenant and Resource Group models for new implementations. All existing constructs map 1:1 to `group_class` values. Existing UUIDs and API surfaces are preserved.
+
+### 10.1 Universal Group Structure
+Every grouping construct in DCM is a `DCMGroup` with:
+- `group_class` — determines system behavior (see 10.2)
+- `group_subclass` — advisory label, no system behavior
+- `member_types_permitted` — what can be a member
+- `exclusivity` — one or many groups of this class per member
+- `enforcement_model` — advisory | enforced | mandatory (tenant_boundary: profile-governed)
+- `lifecycle_policy` — on_group_destroy: **detach (default)** | notify | cascade | retain
+- `former_group_membership` records retained permanently after detach
+- `group_destruction_record` retained in Audit Store permanently
+- Time-bounded membership: `valid_from / valid_until` on every membership
+
+### 10.2 Group Classes
+
+| group_class | Purpose | enforcement |
+|-------------|---------|------------|
+| `tenant_boundary` | Ownership/isolation boundary (replaces Tenant) | profile-governed |
+| `resource_grouping` | Flexible entity tagging (replaces Resource Groups) | advisory |
+| `policy_collection` | Policy cohesion unit (replaces Policy Group) | advisory |
+| `policy_profile` | Deployment configuration (replaces Policy Profile) | enforced |
+| `layer_grouping` | Related layers for a context | advisory |
+| `composite` | Cross-type organizational unit | configurable |
+| `federation` | Peer-group association (federated Tenants) | advisory |
+
+### 10.3 DCM Tenant — tenant_boundary group_class
+Every resource entity must belong to exactly one `tenant_boundary` group (GRP-001). Provides: ownership, isolation, cost attribution, policy scope, drift detection scope, rehydration scope, audit scope, sovereignty boundary.
+
+**Structurally locked invariants** (cannot be overridden by any policy):
+- One tenant_boundary group per resource — always
+- Constituent relationships never cross tenant_boundary boundaries — at any nesting level
+
+**Profile-governed enforcement:** `minimal` profile → advisory; `standard`/`prod`/`fsi`/`sovereign` → mandatory. A GateKeeper policy fires when advisory tenancy detected in prod/fsi/sovereign deployment (GRP-011).
+
+### 10.4 Nested Tenants
+A `tenant_boundary` group can have `parent_group_uuid` pointing to another `tenant_boundary` group. The parent-child relationship is a governance and cost relationship — NOT ownership transfer.
+
+**Parent can:** aggregate cost, apply governance overlay, query aggregate audit, declare child lifecycle policies
+**Parent cannot:** own child resources, cross child isolation boundaries, override more-restrictive child policies
+
+**Governance inheritance — most restrictive wins (GRP-009):**
+```
+Most restrictive policy at ANY nesting level wins
+ Child policies that are more restrictive than parent → child wins
+ Parent policies cascade where child has no policy or is less restrictive
+ Platform policies govern all tenant_boundary groups
+```
+
+### 10.5 Federated Tenants
+A `federation` group contains peer `tenant_boundary` groups. Enables shared policy application, cross-federation visibility, and consolidated reporting. Does NOT grant governance authority — member Tenants remain independent (GRP-010).
+
+### 10.6 Composite Groups
+A `composite` group permits all member types — resource entities, policies, layers, and other groups. Enables "everything about Payments" as one organizational unit.
+
+Policy targeting composite groups defaults to all member types. Declare `member_type_filter` to narrow. Policy linting warns if composite is targeted without filter (GRP-012).
+
+### 10.7 GRP System Policies
+GRP-001 through GRP-014. Key: GRP-001 (one tenant_boundary per resource), GRP-003 (no circular nesting), GRP-005 (detach is default on destroy), GRP-006 (resource in leaf Tenant always), GRP-009 (most restrictive wins in nesting), GRP-011 (advisory tenancy in prod triggers notification), GRP-013 (former_group_membership permanent), GRP-014 (destruction record permanent).
+
+### 10.5 DCM System Policies for Grouping
+
+| Policy | Rule |
+|--------|------|
+| `TEN-001` | Every Resource/Service Entity must belong to exactly one DCM Tenant |
+| `TEN-002` | A Tenant must exist before resources can be created in it |
+| `GRP-003` | Circular nesting in Resource Groups is invalid |
+| `GRP-004` | Custom Resource Groups must implement the full Resource Group Interface |
+| `GRP-005` | Exclusive membership groups must reject violating membership requests |
+
+---
+
+## SECTION 11 — ENTITY RELATIONSHIPS
+
+### 11.1 Design Principle
+**Single model. Minimum variance. Simple by default.** Every relationship in DCM — VM requires storage, application contains web server, resource references Business Unit — uses the same structure. No separate binding mechanism, no separate dependency graph, no separate business data association. One universal model.
+
+### 11.2 Universal Relationship Structure
+Every relationship is a first-class data object with its own UUID. Recorded **bidirectionally** — on both participating entities. The same `relationship_uuid` appears on both sides.
+
+```yaml
+relationship:
+ relationship_uuid:
+ this_entity_uuid:
+ this_role:
+ related_entity_uuid:
+ related_entity_type:
+ related_entity_role:
+ information_provider_uuid:
+ information_type:
+ relationship_type:
+ nature:
+ lifecycle_policy:
+ on_related_destroy:
+ on_related_suspend:
+ on_related_modify:
+ status:
+ provenance:
+```
+
+### 11.3 Relationship Types (fixed vocabulary)
+
+| Type | Inverse | Meaning |
+|------|---------|---------|
+| `requires` | `required_by` | Cannot function without the related entity |
+| `depends_on` | `dependency_of` | Uses the related entity but can degrade without it |
+| `contains` | `contained_by` | Logical container for the related entity |
+| `references` | `referenced_by` | References without owning or requiring |
+| `peer` | `peer` | Equal relationship |
+| `manages` | `managed_by` | Has lifecycle management authority |
+
+### 11.4 Relationship Nature
+
+| Nature | Lifecycle Policy | Example |
+|--------|-----------------|---------|
+| `constituent` | Required | VM requires its boot disk |
+| `operational` | Required | Web server depends on load balancer |
+| `informational` | Not applicable | Resource references its Business Unit |
+
+### 11.5 Lifecycle Policy Authority
+```
+Resource Type Specification default (lowest)
+ → Provider Catalog Item default
+ → Consumer declaration
+ → DCM System Policy (non-overridable)
+```
+
+### 11.6 Relationship Roles
+Standard roles: `compute`, `storage`, `networking`, `security`, `database`, `web`, `app`, `cache`, `queue`, `pipeline`, `identity`, `monitoring`, `business_unit`, `cost_center`, `product_owner`, `regulatory_scope`
+
+Custom roles: extensible — organizations register domain-specific roles (e.g., `trading_engine`, `risk_calculator`). Semantic labels only — do not affect system behavior.
+
+### 11.7 Where Relationships Are Declared
+- **Resource Type Specification** — declares possible relationships (ceiling)
+- **Catalog Item** — declares actual relationships for an offering (can only restrict)
+- **Request time** — consumer declares instance relationships
+- **External data** — same model for Business Unit, Cost Center, Person, etc.
+
+### 11.8 Bundled Declaration Expansion
+When consumer bundles storage/networking in a compute request:
+1. **Processor** creates Resource/Service Entity stubs (PENDING) with UUIDs
+2. **Processor** creates bidirectional Relationship records
+3. **Processor** applies lifecycle policy hierarchy
+4. **Policy Engine** validates binding type and lifecycle policy
+5. **Service Provider** provisions natively, returns realized payloads in DCM format
+6. **DCM** updates entities PENDING → REALIZED, activates relationships
+
+### 11.9 The Entity Relationship Graph
+All relationships form a traversable graph. Used for: rehydration (full graph traversal), cost rollup (accumulates across constituent relationships), drift detection (discovered vs realized graph comparison), decommission ordering (lifecycle policies at each edge), placement (pre-realization footprint), impact analysis (change propagation).
+
+### 11.10 Supersedes Dependency Graph
+The Entity Relationship model unifies the previously separate dependency graph concept. The dependency graph IS the relationship graph at pre-realization time — same structure, different lifecycle state.
+
+### 11.11 Lifecycle Policy Conflict Resolution (Q57 resolved)
+Lifecycle policy fields on relationships are **just fields**. They carry the same `override` metadata, the same provenance obligations, and resolve under the same Policy Engine authority hierarchy as any other DCM field. No special case — minimum variance.
+
+**Priority schema governs conflicts within a tier.** Highest numeric priority runs first. First policy to set `override: immutable` on a lifecycle policy field locks it. `immutable_ceiling: absolute` applies for compliance mandates that must survive future policy changes.
+
+**Ingestion conflict detection applies.** Two policies declaring conflicting lifecycle policies without priority differentiation → CONFLICT ERROR at ingestion.
+
+**DCM System Policies:**
+- `REL-008` — A `constituent` relationship lifecycle policy may not be set to `ignore` for `on_related_destroy`
+- `REL-009` — Lifecycle policy conflicts between policies are resolved by the standard Policy Engine authority hierarchy — no special case
+
+### 11.12 Relationship Type × Nature Matrix (valid combinations)
+
+The two relationship dimensions form an explicit matrix. Invalid combinations are rejected by the Policy Engine at request time (REL-013).
+
+| | `constituent` | `operational` | `informational` |
+|---|---|---|---|
+| **`requires`** | ✅ Core constituent | ✅ Hard operational dependency | ❌ Invalid |
+| **`depends_on`** | ✅ Soft constituent | ✅ **Allocated resource cell** | ✅ Awareness |
+| **`contains`** | ✅ Ownership container | ⚠️ Rare — justify explicitly | ❌ Invalid |
+| **`references`** | ❌ Invalid | ❌ Invalid | ✅ **Business context cell** |
+| **`peer`** | ❌ Invalid | ✅ Operational peers | ✅ Informational peers |
+| **`manages`** | ✅ Component management | ✅ Operational management | ✅ Audit management |
+
+- `operational` + `depends_on` = **allocated resource cell** — cross-tenant allocations live here
+- `informational` + `references` = **business context cell** — Business Unit, Cost Center etc.
+
+### 11.13 Cross-Tenant Relationships (Q59 resolved)
+
+Relationship **nature** governs cross-tenant permissions:
+
+| Nature | Cross-Tenant? | Rule |
+|--------|--------------|------|
+| `constituent` | ❌ Never | REL-010 |
+| `operational` | ✅ With dual authorization | REL-011 |
+| `informational` | ✅ Unless deny_all | REL-012 |
+
+**Hard tenancy declaration** on Tenant entity:
+```yaml
+hard_tenancy:
+ cross_tenant_relationships: operational_only
+ # deny_all | operational_only | informational_only | allow_all
+```
+
+### 11.14 Allocated Resource Model (Q59 extension, Q61 partial)
+
+An **Allocated Resource** is a pre-defined discrete slice of a parent resource made available by the owning Tenant for consuming Tenants to claim. It becomes a **first-class entity** in the consuming Tenant's scope with its own UUID, lifecycle, and governance.
+
+**Relationship:** `depends_on` + `operational` + `cross_tenant: true` + `allocation_uuid`
+
+**Parent pre-defines** `available_allocations` — consuming Tenant claims → DCM creates allocated entity + relationship → parent tracks in `active_allocations` with `notification_endpoint`.
+
+**Lifecycle events** propagate from parent to all active allocations per each allocation's `parent_lifecycle_policy`:
+`on_parent_destroy | on_parent_suspend | on_parent_maintenance | on_parent_degrade | on_parent_capacity_change`
+
+**System policies:** REL-013 (invalid matrix combinations rejected), REL-014 (claim requires available allocation record)
+
+### 11.15 Shared Resource Model — Same-Tenant (Q61 resolved)
+
+A **Shared Resource** is an entity within a single Tenant that has active relationships from multiple parent entities. DCM maintains `active_relationship_count` — the number of active constituent/operational relationships. Informational relationships never count (REL-016).
+
+**`sharing_model` on entity:**
+```yaml
+sharing_model:
+ shareable: true
+ sharing_scope: tenant
+ active_relationship_count: 3 # DCM-maintained
+ minimum_relationship_count: 0
+ on_last_relationship_released:
+```
+
+**`shareability` on Resource Type Specification:**
+- `shareability.allowed: true` — instances can have multiple active relationships
+- `shareability.allowed: false` (e.g., `Compute.BootDisk`) — second relationship rejected (REL-017)
+- `max_active_relationships` — optional cap (e.g., license seat limits)
+
+**Destruction deferral (REL-015):** Destructive lifecycle actions on shared resources are deferred until `active_relationship_count` reaches `minimum_relationship_count`. Deferred destruction is recorded in `deferred_destruction_record`.
+
+### 11.16 Lifecycle Action Hierarchy — Save Overrides Destroy (REL-018)
+
+When multiple relationships produce different lifecycle action recommendations on a shared resource, the most conservative action wins:
+
+```
+retain > notify > suspend > detach > cascade > destroy
+```
+
+`retain` always beats `destroy` — the save_overrides_destroy rule. Applies automatically per REL-018.
+
+**Conflict detection (REL-019):** When recommendations differ, a `lifecycle_conflict_record` is created:
+- Severity `info` — hierarchy resolved cleanly (e.g., retain beats destroy non-adjacent)
+- Severity `warning` — adjacent levels or `notify` is the winning action — notifications sent
+- Severity `critical` — immutable lifecycle lock overridden by REL-018 — platform admin notified
+
+**Unified model:** Same-tenant sharing (`active_relationship_count`) and cross-tenant allocation (`active_allocations`) are the same reference-counting concept at different scopes. Both defer destructive actions until the last relationship/allocation is released.
+
+---
+
+## SECTION 12 — INFORMATION PROVIDERS
+
+### 12.1 Purpose
+Information Providers are a first-class DCM provider type that serves authoritative external data DCM needs to reference but does not own (HR systems, finance systems, CMDBs). DCM references but never caches or owns external data.
+
+### 12.2 Provider Types — Data Ownership
+
+DCM has five provider types (see Section 0 for the complete list). The data ownership question is most relevant to these four categories:
+
+| Type | Purpose | DCM Owns Result? |
+|------|---------|-----------------|
+| **Service Provider** | Realizes resources — KubeVirt, VMware, AAP, etc. | Yes |
+| **Information Provider** | Serves authoritative external data DCM references but does not own | No — external system is authoritative |
+| **Meta Provider** | Composes multiple providers into higher-order services | Yes |
+
+
+All five provider types follow the same base contract: registration, health check, trust, sovereignty, accreditation, governance matrix enforcement, zero trust, and provenance emission obligation.
+
+### 12.3 Same Contract as Service Providers
+Information Providers follow the same registration, health check, trust, and capacity model as Service Providers where applicable. Capacity = query capacity (requests/sec). Naturalization/Denaturalization = translating native format to DCM unified format.
+
+### 12.4 Standard vs Extended Data
+- **Standard data** — DCM-defined fields. Used for lookups, policy evaluation, operational decisions. Portable across all implementations.
+- **Extended data** — organization-defined fields. Carried in payload for downstream consumers. DCM core does not rely on extended data for operational decisions.
+
+### 12.5 Stable External Key Model
+```yaml
+external_entity_reference:
+ uuid:
+ external_uuid:
+ information_provider_uuid:
+ information_type_name: Business.BusinessUnit
+ lookup_method:
+ primary_key: external_uuid
+ fallback_keys:
+ - field: code
+ value: "BU-PAY"
+ display_name:
+ verification:
+ last_verified:
+ verification_status:
+```
+DCM UUID wraps external UUID — if external system changes its UUID, only this record changes. All relationships remain valid.
+
+### 12.6 Three-Mode Verification
+- **Mode 1** — DCM-initiated scheduled verification (configurable frequency)
+- **Mode 2** — Information Provider push (contractual obligation — same as SP lifecycle events)
+- **Mode 3** — On-demand verification fallback when reference is stale
+
+### 12.7 Information Types in the Registry
+Same DCM registry as Resource Types — distinguished by category prefix:
+- `Business.*` — BusinessUnit, CostCenter, ProductOwner
+- `Identity.*` — Person, ServiceAccount, Group
+- `Compliance.*` — RegulatoryScope, AuditFramework
+- `Operations.*` — Runbook, SLA, SupportContract
+
+---
+
+## SECTION 13 — KUBERNETES SUPERSET STRATEGY
+
+### 13.1 Position
+DCM is a **superset of Kubernetes** — extending Kubernetes' declarative, controller-based model upward to provide unified management across multiple clusters, infrastructure types, and organizational boundaries. Kubernetes manages the execution plane. DCM manages the management plane.
+
+### 13.2 What DCM Adds Beyond Kubernetes
+
+| Capability | Kubernetes | DCM |
+|------------|-----------|-----|
+| Scope | Single cluster | Multi-cluster, multi-infrastructure |
+| Tenancy | Namespace isolation | First-class Tenant ownership model |
+| Policy | RBAC + admission webhooks | Full Policy Engine — Validation/Transformation/GateKeeper |
+| Data lineage | Not provided | Field-level provenance on all data |
+| Cost attribution | Not provided | Full lifecycle cost analysis |
+| Drift detection | Controller reconciles | Four-state model — Intent/Requested/Realized/Discovered |
+| Service catalog | Not provided | Self-service catalog with RBAC-governed presentation |
+| Sovereignty | Not provided | Placement constraints, compliance evidence |
+| Non-Kubernetes resources | Not provided | VMware, bare metal, OpenStack managed through same model |
+
+### 13.3 Operator Integration — The Adapter Pattern
+Kubernetes operators become DCM Service Providers through the DCM Operator Interface Specification. The pattern:
+```
+DCM Control Plane → Operator Adapter (Service Provider) → Kubernetes Operator → Cluster
+```
+The adapter handles Naturalization (DCM Requested State → Kubernetes CR) and Denaturalization (CR status → DCM Realized State).
+
+### 13.4 Native Support Strategy
+Goal: influence the Kubernetes operator ecosystem to adopt DCM as a superset. Three-phase approach:
+1. **Generic Operator Adapter** — declarative field mappings, no operator changes needed
+2. **DCM Operator SDK** — Go library, adds DCM support with minimal code changes, one day to Level 1
+3. **Upstream contributions** — contribute DCM support directly to priority operators (KubeVirt, CloudNativePG, Strimzi, Cert-Manager)
+
+### 13.5 Conformance Levels
+- **Level 1** — Registration + health + basic status reporting. One day with SDK. Unlocks: catalog, health monitoring, basic cost tracking.
+- **Level 2** — + Capacity + lifecycle events + full realized payloads + field mappings. 2-3 days. Unlocks: placement, drift detection, cross-cluster management.
+- **Level 3** — + Sovereignty + provenance + discovery + decommission confirmation. 3-5 days. Unlocks: full audit chain, brownfield ingestion, sovereignty enforcement.
+
+### 13.6 CNCF Strategy
+Target CNCF Sandbox submission. FSI consortium (leading FSI consortium members) provides multi-organization adopter evidence. Key artifacts needed before submission: DCM Operator Interface Spec v1.0, SDK v0.1.0, KubeVirt Level 2 reference implementation, conformance test suite, governance model.
+
+### 13.7 Key Kubernetes-to-DCM Concept Mappings
+| Kubernetes | DCM |
+|-----------|-----|
+| CRD | Resource Type Specification |
+| Custom Resource | Requested State → Realized State |
+| Reconciliation loop | Realization + Drift Detection |
+| Namespace | DCM Tenant boundary |
+| ownerReference | Entity Relationship (contains/contained_by) |
+| Finalizers | Lifecycle policy enforcement |
+| Labels/Annotations | DCM entity metadata |
+| Kubernetes conditions | DCM lifecycle states |
+
+---
+
+## SECTION 14 — WEBHOOK INTEGRATION
+
+### 14.1 Purpose
+Webhooks provide a **push-based notification model** for consumers, providers, and external systems that cannot or do not poll DCM. They complement the API-first model and Message Bus by enabling real-time outbound event notifications.
+
+### 14.2 Architectural Position
+Webhooks are an **Egress capability** — outbound notifications from DCM to external systems. They fit within the existing Egress zone alongside the Messaging Protocol and Interoperability API.
+
+### 14.3 Core Use Cases
+
+| Audience | Example Events |
+|----------|---------------|
+| **Consumer/CI-CD** | Resource request transitions to REALIZED; Entity enters DEGRADED state; dependency graph node fails |
+| **Provider** | New request payload dispatched; discovery request initiated; decommission requested |
+| **External Systems** | ITSM notification on request create/update/complete; FinOps platform on Entity realization/decommission |
+| **Operational** | Provider capacity below threshold; unsanctioned change detected; GateKeeper policy fired |
+| **Compliance** | Sovereignty constraint applied; ownership transfer initiated/completed; audit-relevant policy triggered |
+
+### 14.4 Key Design Principles (Established)
+- Webhook events are **typed and versioned** — consistent with DCM universal versioning model
+- Webhook payloads carry **provenance information** — sufficient context to trace back to the originating request, entity, and policy
+- **Policy Engine integration** — the Policy Engine can fire webhooks as a response action (alongside ALERT, REVERT, UPDATE_DEFINITION, etc.)
+- Webhook registrations are **scoped** — consumer-facing webhooks registered via Consumer API; provider-facing webhooks registered via Provider Registration
+- Events should align with a **DCM Event Type Registry** — extensible, versioned, following the same registry model as Resource Types
+
+### 14.5 Open Design Questions
+See [DISCUSSION-TOPICS.md — TOPIC-001](DISCUSSION-TOPICS.md) for the full list of design questions. Key unresolved items:
+- Webhook registration model and API
+- Full event taxonomy and registry structure
+- Payload format — full state vs reference + event type
+- Authentication model for outbound webhook calls
+- Retry and reliability obligations
+- Ordering guarantees
+- Relationship to the Message Bus
+- Whether provider webhook support is mandatory in the Provider Contract
+- Tenant vs platform-level scoping
+
+### 14.6 Status
+**Under active discussion** — see DISCUSSION-TOPICS.md TOPIC-001. Do not make implementation assumptions until design questions are resolved.
+
+---
+
+## SECTION 15 — DCM ARCHITECTURE COMPONENTS
+
+### 15.1 The Five Domains
+DCM is organized into five horizontal domains from bottom to top:
+
+| Domain | Persona | Content |
+|--------|---------|---------|
+| **Data Center Domain** | CIO | Physical infrastructure — Compute, GPU, RAM, Storage, Networking, HSM |
+| **Resource Domain** | SRE | Declarative resources — VMs, containers, pods, clusters, external IPs |
+| **Control Plane Domain** | CTO | Policy, Validate & Placement, Audit, Orchestration |
+| **Application Domain** | Engineering | Data Center Pipeline, CI/CD |
+| **Value Domain** | Line of Business | Software Build & Deploy, business outcomes |
+
+### 15.2 Control Plane Components
+
+| Component | Purpose |
+|-----------|---------|
+| **API Gateway** | Central clearing house — ingress for consumers, egress to providers |
+| **Job Queue** | Manages asynchronous task execution |
+| **Request Payload Processor** | Assembles, enriches, and merges data layers into complete request payload |
+| **Policy Engine** | Validates, transforms, gates, and enriches data based on policy definitions |
+| **IDM / IAM** | Authentication and identity — source of truth for personas and RBAC |
+| **Service Catalog** | Presents available services/resources per RBAC policy |
+| **Orchestration** | Coordinates multi-step workflows and manages request lifecycle |
+| **Cost Analysis** | Tracks service costs throughout the full resource lifecycle |
+| **Audit** | Records all operations — reads provenance intrinsic to data objects |
+| **Observability** | Monitoring, logging, and metrics |
+| **Resource Discovery** | Interrogates providers to discover existing resource state |
+| **Message Bus** | Async communication between control plane and external systems |
+
+### 15.3 Data Stores — PostgreSQL Store Contracts
+
+All DCM stores use **PostgreSQL** as the single required infrastructure. DCM defines store contracts for each data domain. Four store contract types:
+
+| Contract Type | Stores | Key Characteristics |
+|--------------|--------|-------------------|
+| **GitOps Store** | Intent, Requested, Layer, Policy | Branch/PR/merge semantics, immutable history, CI/CD hooks, Search Index companion |
+| **Event Stream Store** | Realized, Discovered, Audit events | Append-only, entity-keyed streams, replayable, high-throughput |
+| **Audit Store** | Compliance audit records | Compliance-grade, immutable, long-retention (7+ years FSI), hash-verified |
+| **Observability Store** | Metrics, traces, logs | Time-series, short-to-medium retention, OpenTelemetry format |
+
+**Search Index** — non-authoritative queryable projection of GitOps stores. Rebuilt from Git on demand. Git always wins on disagreement.
+
+**DCM-internal caches** (Layer Cache, Policy Cache, Catalog Cache) — not data stores. Non-authoritative, cache-aside pattern, invalidated on writes.
+
+### 15.4 Consumer Ingress
+- **Web UI** — web interface for human consumers
+- **Consumer API** — API interface for programmatic consumers and external systems
+
+### 15.5 Egress
+- **Messaging Protocol** — protocol translation to external systems
+- **Interoperability API** — common API spec and data model for Service Provider communication
+
+---
+
+## SECTION 16 — SERVICE PROVIDERS
+
+### 16.1 Core Principle
+DCM is **not concerned with how a provider accomplishes its work** — only with:
+- The data that crosses the boundary (conformant data in, conformant data out)
+- The trust and contractual obligations the provider has declared and honored
+
+### 16.2 Naturalization and Denaturalization
+- **Naturalization** — provider transforms DCM unified data into its own tool-specific format for execution
+- **Denaturalization** — provider transforms tool-specific results back into DCM unified format for return to the control plane
+
+### 16.3 Provider Contract Dimensions
+Providers must honor a multi-dimensional contract:
+
+**Data Contract**
+- Accept DCM unified data format
+- Return complete DCM unified data format (not just status codes)
+- Implement Naturalization and Denaturalization
+
+**Sovereignty Contract**
+- Explicitly declare which sovereignty dimensions they can satisfy
+- Declaration is binding — if declared, it must be delivered
+- Sovereignty dimensions: Data/Content, Operational, Security/Compliance, Placement/Mobility
+
+**Capability Contract**
+- Declare which Resource Types they implement
+- Declare which lifecycle operations they support (CRUD + Discovery)
+- Declare what they do NOT support
+
+**Lifecycle Contract**
+- Support all declared lifecycle states
+- Participate in Discovery when requested
+- Report Realized State completely and accurately
+- Handle drift detection requests
+
+**Query Contract**
+- Support `reserve_query` — atomic: verify constraints + return metadata + place hold
+- Support `capacity_query` (informational, no hold)
+- Support `metadata_query` (informational, no hold)
+- Declare which query types and metadata fields are supported in provider registration
+- Complete missing metadata in realized payload or discovery loop
+- `reserve_query` response must include `missing_metadata` for any requested fields not returned
+
+**Trust Contract** *(validation mechanism — to be detailed)*
+- Providers must be validated and certified to participate
+- Trust is established at onboarding
+- Chain of trust must be maintained
+
+**Compliance/Audit Contract**
+- Maintain audit trail of actions taken
+- Make audit data available to DCM in DCM unified format
+- Must not take actions outside of DCM-initiated requests (for managed resources)
+
+**SLA/Operational Contract**
+- Response time expectations
+- Availability requirements
+- Error handling and reporting standards
+- Retry and idempotency guarantees
+
+### 16.4 Provider Types
+- **Atomic Providers** — manage a single fundamental resource type (VM, IP, VLAN, container)
+- **Meta Providers** — compose multiple providers as components of their own service
+- **Process Providers** — purely process-based workflow or automation
+- **External Policy Evaluators** — supply policies; Mode 4 evaluates/enriches via black box query
+- **event routing services** — bidirectional bridge to external message buses (Kafka, AMQP, NATS, etc.)
+- **credential management services** — resolve secrets from external stores (Vault, AWS SM, Azure KV, CyberArk, etc.)
+- **Auth Providers** — authenticate identities and resolve permissions (OIDC, LDAP, AD, FreeIPA, etc.)
+- **Real-world providers** are typically combinations of the above
+
+---
+
+## SECTION 17 — THE POLICY ENGINE
+
+### 17.1 Purpose
+The Policy Engine is the **single authoritative logic gate for all business rules** in DCM. It enforces governance without embedding business logic into the control plane. It is the **sole authority for field override control** — no other component sets override metadata on fields.
+
+### 17.2 Policy Categories
+
+| Category | Description | Modifies Data? | Example |
+|----------|-------------|----------------|---------|
+| **Transformation** | Enriches or modifies the payload. Adds missing fields, applies standards. All changes recorded in provenance. May set `override: constrained`. | Yes | Inject PCI-compliant cryptography standard |
+| **Validation** | Checks payload against rules. Pass/fail — no field modification. Failure rejects request. | No | VM class allowed in DMZ Zone A |
+| **GateKeeper** | Highest authority. Overrides any field including consumer input. Sets `override: immutable`. Halts execution. | Yes — overrides everything | Block request violating sovereignty |
+
+### 17.3 Policy Hierarchy
+Three-tier execution — Global first, User last. Within each tier sorted by priority (higher value = higher authority):
+
+```
+Global (Super Admin) — runs first, highest authority
+Tenant (Tenant Admin) — runs second
+User (End User) — runs last, lowest authority
+```
+
+A Global policy cannot be overridden by Tenant or User. Field locks set by higher-authority policies cannot be unlocked by lower-authority policies.
+
+### 17.4 Policy Implementation
+- **Engine:** OPA (Open Policy Agent) with Rego policy language
+- **Storage:** GitOps — all policies in Git, versioned, immutable once published
+- **Execution:** Stored-policy model — OPA pre-loads policies; evaluation calls pre-loaded modules
+- **Outputs:** `rejected` (bool), `patch` (field mutations), `constraints` (JSON Schema locks), provider placement constraints (NOT direct provider naming)
+
+### 17.5 Policy Rules
+- Policies operate only on policy definition, core data, and request payload data
+- Outcomes must be **deterministic** — same input always produces same output for a given version
+- All modifications recorded in field-level provenance with policy UUID, tier level, and reason
+- Policies follow the five-status lifecycle: `developing → proposed → active → deprecated → retired`
+
+### 17.6 Policy Scope
+- **Core Policies** — all DCM actions regardless of provider
+- **Service Policies** — specific to a Service Provider's services
+- **Organizational Policies** — defined by the implementing organization
+- **Domain Policies** — scoped to a specific domain or business unit
+
+### 17.7 Proposed Policy — Shadow Execution
+When a policy is in `proposed` status it runs in **shadow mode** against real request traffic:
+- Executes alongside active policies on every relevant request
+- Output captured in `proposed_evaluation_record` — what it would have done
+- Output is **never applied** to the actual request
+- Feeds the Validation Dashboard for reviewer analysis before activation
+- Impact categories: `none | low | medium | high | critical`
+- Activation requires approval after review period
+
+### 17.8 Policy and Override Control
+The Policy Engine exclusively sets `override_control` metadata. Three levels (see Section 6.10–6.11):
+- Level 1 — no declaration → fully overridable (default)
+- Level 2 — simple `override: allow|constrained|immutable`
+- Level 3 — full `override_matrix` with per-actor permissions and trusted grants
+
+### 17.9 Policy Placement Phase
+Every policy declares when in the assembly process it executes:
+- `pre` — before placement (default) — no provider context
+- `loop` — inside the placement loop — has reserve query response data
+- `post` — after placement confirmed — has full placement block
+- `both` — pre and post
+
+### 17.10 Policy Required Context
+Policies declare what fields they need and what to do when fields are absent:
+```yaml
+required_context:
+ - field: placement.provider_metadata.sovereignty_certifications
+ if_absent:
+ if_absent_reason:
+```
+If no policy declares `required_context` for an absent field → `implicit_approval` recorded in `policy_gap_record`. The system has no implicit opinion beyond what policies state.
+
+---
+
+## SECTION 18 — KEY USE CASES
+
+### 18.1 Datacenter Rehydration (Repave)
+Reconstruct ALL required components and configurations from code after catastrophic failure (ransomware, DR event, mandatory 90-day repave). Industry benchmark: leading FSI organization 60-day repave. DCM must beat this. Key metric: TTR (Time to Recovery).
+
+### 18.2 Intelligent Placement
+Automated placement of resources and workloads based on metadata, policies from CMDB/CISO/platform teams. Consumer declares criteria (location, SLA, security zones) — DCM determines optimal placement automatically.
+
+### 18.3 Application as a Service
+Meta Service Provider that consumes application code and provides its full execution lifecycle. Consumer defines metadata for required technologies or SLAs — provider handles the rest.
+
+### 18.4 Regional Sovereignty
+Enforce workload placement within specific regions or sovereignty constraints. CISO/CCO-driven policy ensuring data residency and jurisdictional compliance.
+
+### 18.5 Data Enrichment
+System enriches consumer requests with ancillary implementation details the consumer should not need to know. Consumer declares intent — DCM fills in the details.
+
+### 18.6 Greening the Brownfield — Unified Ingestion Model
+Bring existing unmanaged infrastructure under DCM lifecycle management using the unified ingestion model (see Section 20 and data model document 13-ingestion-model.md). The same three-step pattern applies to both brownfield ingestion and V1 migration:
+
+```
+1. INGEST — bring the entity into DCM with whatever identity/metadata is available
+2. ENRICH — associate business data, ownership, Tenant assignment, relationships
+3. PROMOTE — transition from holding state to full DCM lifecycle ownership
+```
+
+**Brownfield flow:** Service Provider performs discovery → DCM identifies unmanaged Discovered State records → Entity stubs created (state: INGESTED, Tenant: `__transitional__`) → Business data and Tenant assigned → Promotion authorized → Discovered State promoted to Realized State → Drift detection active from this point.
+
+**V1 Migration flow:** V1 resources inventoried → Auto-assignment attempted via signals (resource groups, business unit, request history) → Auto-assignable resources assigned in bulk → Manually assignable resources surfaced in admin queue → Orphaned resources assigned to `__transitional__` → Enrichment and promotion → Migration complete when `__transitional__` Tenant is empty.
+
+**Key concepts:**
+- `__transitional__` Tenant — system-managed holding area for unassigned ingested entities. Cannot be deleted or used for new provisioning. Governance policy enforces max residency and escalation.
+- `ingestion_record` — provenance record on every ingested entity: source, confidence, assignment method, enrichment history, promotion timestamp
+- Ingestion confidence: `high` (strong signal) | `medium` (inferred) | `low` (orphaned)
+- Entities in `INGESTED` or `ENRICHING` state cannot be parents for allocated resource claims or hard dependencies for new requests
+
+---
+
+## SECTION 19 — DIGITAL SOVEREIGNTY
+
+DCM addresses four dimensions of digital sovereignty:
+
+| Dimension | DCM Enabler | Impact |
+|-----------|-------------|--------|
+| **Data and Content Sovereignty** | Data Model, Policy Engine, Validated Providers | Data residency and jurisdictional compliance |
+| **Operational Sovereignty** | Policy Engine | Sovereign Execution Posture, Hard Tenancy enforcement |
+| **Security and Compliance Sovereignty** | Audit, GRC | Evidence for strict regional mandates |
+| **Mobility, Placement, Modernization** | Policy Engine, Providers, Data Model | Automated placement, provider mobility, brownfield ingestion |
+
+**Sovereign Execution Posture** — the target end state where all operations are governed, auditable, and compliant with sovereignty requirements. This is the north star concept of DCM.
+
+---
+
+## SECTION 20 — INGESTION MODEL
+
+The Ingestion Model is the **unified mechanism for bringing entities that exist outside DCM's lifecycle control into DCM governance**. It covers V1 Migration, Brownfield Discovery, and Manual Import — all follow the same pattern.
+
+### 20.1 Three-Step Pattern
+```
+INGEST → ENRICH → PROMOTE → OPERATIONAL
+```
+
+### 20.2 Ingestion Lifecycle States
+
+| State | Tenant | New Requests? | Parent for Allocations? | New Relationships? |
+|-------|--------|--------------|------------------------|-------------------|
+| `INGESTED` | `__transitional__` or assigned | No | No | Informational only |
+| `ENRICHING` | Assigned | No | No | Operational (read-only) |
+| `PROMOTED` | Assigned | Yes | Yes | All types |
+
+### 20.3 The `__transitional__` Tenant
+System-managed holding Tenant for unassigned ingested entities:
+- Cannot be deleted, renamed, or used for new resource provisioning
+- Governance policy enforces `max_residency_days` and escalation action
+- Hard tenancy: `operational_only` by default
+- `created_via: system` — artifact metadata
+
+### 20.4 Ingestion Record
+Every ingested entity carries an `ingestion_record` in provenance:
+- `ingestion_source` — `v1_migration | brownfield_discovery | manual_import`
+- `assigned_tenant_uuid` — real Tenant or null if still in `__transitional__`
+- `assignment_method` — `auto | manual | transitional`
+- `assignment_signal` — human-readable description of what drove auto-assignment
+- `ingestion_confidence` — `high | medium | low`
+- `enrichment_status` — `pending | partial | complete`
+- `enrichment_history` — append-only log of all enrichment actions
+- `promoted_at` — when entity reached PROMOTED state
+
+### 20.5 Auto-Assignment Signal Priority
+DCM attempts auto-assignment in this order (configurable):
+1. Explicit ownership metadata (high confidence)
+2. Resource group membership (high confidence)
+3. Request history (high confidence)
+4. Network/location context (medium confidence)
+5. Naming convention (medium confidence)
+6. Provider context (medium confidence)
+7. No signal → `__transitional__` (low confidence)
+
+### 20.6 V1 Migration (Q55 resolved)
+V1 resources have no `tenant_uuid`. V2 requires one (TEN-001). Migration uses the ingestion model:
+- Pre-migration analysis pass classifies all V1 resources: `auto_assignable | manually_assignable | orphaned`
+- Auto-assignable → bulk Tenant assignment + ingestion record
+- Manually assignable → admin queue for human review and assignment
+- Orphaned → `__transitional__` Tenant + governance timer
+- Migration complete when `__transitional__` Tenant is empty
+
+### 20.7 Brownfield Ingestion
+Unmanaged discovered entities follow the same ingestion model:
+- Service Provider discovery creates Discovered State records
+- DCM identifies unmanaged Discovered State records (no matching Realized State)
+- Entity stubs created (state: INGESTED, source: brownfield_discovery)
+- Enriched → promoted → Discovered State becomes initial Realized State
+- Drift detection active from promotion forward
+
+### 20.8 DCM System Policies for Ingestion
+
+| Policy | Rule |
+|--------|------|
+| `ING-001` | Every ingested entity must be assigned to one Tenant — real or `__transitional__` — before V2 eligibility |
+| `ING-002` | Entities in `INGESTED` or `ENRICHING` state may not be parents for allocated resource claims |
+| `ING-003` | `__transitional__` Tenant cannot be deleted, renamed, or used for new provisioning |
+| `ING-004` | Every ingested entity must carry an `ingestion_record` in provenance |
+| `ING-005` | Entities in `__transitional__` beyond `max_residency_days` must trigger configured escalation |
+| `ING-006` | Brownfield entities may not be promoted without explicit actor authorization |
+| `ING-007` | At brownfield promotion, Discovered State is promoted to Realized State — DCM assumes lifecycle ownership |
+
+---
+
+## SECTION 21 — POLICY ORGANIZATION: GROUPS, PROFILES, AND POLICY PROVIDERS
+
+### 21.1 Three-Level Policy Organization
+```
+Policy Profile — complete use-case configuration (composed of groups)
+ │
+Policy Groups — single-concern policy collections (composed of policies)
+ │
+Policies — individual Transformation / Validation / GateKeeper rules
+ │ optionally sourced from
+External Policy Evaluators — external authoritative policy sources (fifth provider type)
+```
+
+### 21.2 Policy Groups
+A **Policy Group** is a cohesive collection of policies addressing a single identifiable concern.
+
+**Concern types:** `security | compliance | operational | recovery_posture | zero_trust_posture | data_authorization_boundary | orchestration_flow`
+
+**Key fields:** `handle` (domain/group/name), `concern_type`, `concern_tags`, `extends` (inherits parent), `policies` (constituent policies), `activation_scope` (resource types, tenant tags, regions), `conflicts_with` (explicit conflict declarations), `source` (local or external_policy_evaluator)
+
+**DCM built-in groups include:** core-minimal, dev-defaults, ephemeral-resources, audit-basic, audit-compliance, data-classification, cost-governance, sla-enforcement, hard-tenancy, explicit-cross-tenant, zero-trust, encryption-baseline, pci-dss, gdpr-eu, nist-800-53, iso-27001, fsi-audit, lifecycle-ttl-enforcement, air-gap, kubevirt, openstack, vmware
+
+### 21.3 Policy Profiles
+A **Policy Profile** is a complete DCM configuration for a specific use case composed of Policy Groups.
+
+**Six DCM built-in profiles (least to most restrictive):**
+
+| Profile | Handle | Tenancy | Enforcement | Cross-Tenant | Audit |
+|---------|--------|---------|-------------|-------------|-------|
+| `minimal` | `system/profile/minimal` | Optional — auto-created | Advisory only | allow_all | None |
+| `dev` | `system/profile/dev` | Recommended | Warn only | operational_only | Basic 90-day |
+| `standard` | `system/profile/standard` | Required | Blocking | explicit_only | Compliance-grade |
+| `prod` | `system/profile/prod` | Required | Blocking + SLA | explicit_only | Compliance-grade |
+| `fsi` | `system/profile/fsi` | Hard tenancy | Blocking | explicit_only | 7-year retention |
+| `sovereign` | `system/profile/sovereign` | Hard tenancy | Blocking | deny_all | 10-year retention |
+
+**Profile inheritance chain:** `system/profile/sovereign` extends `system/profile/fsi` extends `system/profile/prod` extends `system/profile/standard` extends `system/profile/dev` extends `system/profile/minimal`
+
+**Profile activation levels (more specific wins):**
+```yaml
+installation_config: default_profile: minimal
+platform_config: active_profile: prod; minimum_tenant_profile: dev
+tenant_config: active_profile: fsi # must be >= minimum_tenant_profile
+```
+
+**Profile shadow validation:** proposed profiles run in shadow mode before activation — same as proposed policies.
+
+### 21.4 External Policy Evaluator (Fifth Provider Type)
+A **External Policy Evaluator** is a fifth DCM provider type — an external authoritative source supplying policies into DCM or evaluating/enriching data via external logic.
+
+**Four delivery modes:**
+
+| Mode | Name | `delivery.mode` value | Logic Lives In |
+|------|------|----------------------|---------------|
+| 1 | DCM Native Push/Pull | `push` / `pull` / `webhook` | DCM Policy Engine |
+| 2 | OPA/Rego Bundle | `opa_bundle` | DCM Policy Engine (OPA) |
+| 3 | External Schema (naturalization) | `external_schema` | DCM Policy Engine (post-translation) |
+| 4 | Black Box Query-Enrichment | `black_box_query` | External provider — opaque to DCM |
+
+**Modes 1-3** deliver policy rules. **Mode 4** is a query-response interface — DCM sends data, external system evaluates and/or enriches, returns structured result.
+
+**Mode 4 can:**
+- **Evaluate** — return pass/fail, score, or recommendation
+- **Enrich** — inject additional fields into the payload (risk scores, compliance citations, cost predictions, org context, case references)
+- **Both** — multi_factor result combining decision + enrichment
+
+**Mode 4 governance requirements:**
+- Data sovereignty check before ANY query is sent (BBQ-001, BBQ-003)
+- Data minimization — only declared fields sent (BBQ-002)
+- Full audit record per query-response cycle (BBQ-004) including `audit_token` for cross-system correlation
+- Default failure behavior is `gatekeep` — unknown is not safe (BBQ-005)
+- Injected enrichment fields carry standard field-level provenance with `source_type: black_box_provider` + `audit_token` (BBQ-007)
+- Override control applies to injected fields — GateKeeper can refuse enrichment (BBQ-008)
+- Mode 4 enrichment providers require minimum `transformation` trust level (BBQ-009)
+
+**Trust levels (all modes):**
+- `trusted` → GateKeeper authority (dual approval elevation required)
+- `verified` → Transformation/Validation only; Mode 4 enrichment minimum
+- `untrusted` → advisory only
+
+**`on_update` (Modes 1-3):** `proposed` (shadow validation) | `active` (immediate — trusted only)
+**On provider failure:** policies deprecated with configurable sunset; Mode 4 → `on_unavailable` behavior fires
+
+### 21.5 Lifecycle Time Constraints
+First-class field on any resource entity. Follow standard data model precedence and override control.
+
+**Two types:**
+- `ttl` — ISO 8601 duration relative to reference_point (created_at | realization_timestamp | last_modified)
+- `expires_at` — absolute ISO 8601 timestamp
+
+When both declared, earliest wins (LTC-004). GateKeeper can lock as `override: immutable`.
+
+**`on_expiry` actions:** `destroy | suspend | notify | review`
+
+Expiry enforcement is a DCM control plane function — not a provider concern. Failed expiry action → `PENDING_EXPIRY_ACTION` state + escalation (LTC-005).
+
+### 21.6 Cross-Tenancy Authorization — Explicit_Only Default
+Default stance is now **`explicit_only`** — informational sharing is NOT open by default. Every cross-tenant relationship of any nature requires an explicit `cross_tenant_authorization` record.
+
+**Authorization specifies who/what/when/where:**
+```yaml
+cross_tenant_authorization:
+ authorized_consumer_tenant_uuid: # WHO
+ permitted_fields: [field1, field2] # WHAT — empty = all fields
+ valid_from/valid_until: # WHEN
+ permitted_in_regions: [eu-west] # WHERE
+ authorization_level:
+ # Hierarchy: field_specific > resource_specific > tenant_global (more specific wins)
+```
+
+All cross-tenant authorization decisions are policy-driven and DCM-enforced (XTA-004).
+
+### 21.7 Rehydration Tenancy Controls
+Tenancy controls, sovereignty directives, and cross-tenant authorizations **always use current policies during rehydration — cannot be pinned**.
+
+**`policy_version: pinned`** governs resource configuration policies only. Tenancy/sovereignty always current.
+
+When rehydration conflicts with current tenancy controls → entity enters **PENDING_REVIEW** state:
+- Allocation not automatically released
+- Notifications: entity owner, both Tenant admins, platform admin
+- Resolution: re_authorize | release | escalate
+- A policy may declare automatic resolution behavior (RHY-004)
+
+### 21.8 System Policy Summary
+
+**LTC:** LTC-001 through LTC-005 — lifecycle time constraint enforcement
+**XTA:** XTA-001 through XTA-005 — cross-tenancy authorization model
+**RHY:** RHY-001 through RHY-004 — rehydration tenancy controls
+**DEP:** DEP-001 through DEP-003 — cross-tenant dependency rules
+**BBQ:** BBQ-001 through BBQ-009 — Mode 4 black box query-enrichment governance
+
+---
+
+## SECTION 22 — UNIVERSAL GROUP MODEL
+
+DCM collapses all grouping constructs into a single **DCMGroup** entity with `group_class` metadata. One mental model, one API, one registry. See `15-universal-groups.md` for the complete model.
+
+### 22.1 Group Classes
+
+| group_class | Replaces | member_types_permitted | exclusivity |
+|-------------|---------|----------------------|------------|
+| `tenant_boundary` | Tenant | resource_entity, group | one (structural lock) |
+| `resource_grouping` | Resource Group | resource_entity | many |
+| `policy_collection` | Policy Group | policy | many |
+| `policy_profile` | Policy Profile | group | many |
+| `layer_grouping` | Layer grouping | layer | many |
+| `provider_grouping` | Provider collections | provider | many |
+| `composite` | (new) | all types | many |
+| `federation` | (new) | group (tenant_boundary) | many |
+
+### 22.2 Structural Invariants (non-overridable)
+- `GRP-INV-001` — resource_entity belongs to exactly one tenant_boundary group
+- `GRP-INV-002` — constituent relationships cannot cross tenant_boundary boundaries
+- `GRP-INV-003` — destroying parent tenant_boundary requires explicit resolution of all children first
+- `GRP-INV-004` — resource in child tenant_boundary belongs to child — never parent
+- `GRP-INV-005` — circular group membership invalid
+- `GRP-INV-006` — group cannot be a member of itself
+
+### 22.3 Composite Groups
+`member_types_permitted: [resource_entity, policy, layer, group, provider]`. Policies targeting composite groups apply to all member types by default. Narrow with `member_type_filter`.
+
+### 22.4 Nested Tenants
+`tenant_boundary` group with `parent_group_uuid`. Parent has governance overlay and cost rollup — not ownership. Policy inheritance direction is profile-governed (opt_in for minimal/dev/fsi/sovereign; opt_out for standard/prod).
+
+### 22.5 Federated Tenants
+`federation` group containing `tenant_boundary` groups as peers. Members remain fully independent. Enables shared governance, consolidated reporting, scoped cross-member visibility.
+
+### 22.6 API Backward Compatibility
+`GET /tenants` → `GET /groups?group_class=tenant_boundary`. All existing UUIDs and API endpoints preserved.
+
+---
+
+## SECTION 23 — UNIVERSAL AUDIT MODEL
+
+Every modification to every DCM artifact produces an audit record. No exceptions. See `16-universal-audit.md` for the complete model.
+
+### 23.1 Four Required Fields
+**Date/time** (ISO 8601 microseconds) | **Who** (composite actor chain) | **What** (subject entity) | **Action** (closed vocabulary)
+
+### 23.2 Two-Stage Audit — Synchronous Commit + Async Enrichment
+
+**Stage 1 (synchronous, < 1ms, in critical path):**
+```yaml
+commit_log_entry:
+ entry_uuid:
+ sequence: # monotonically increasing
+ timestamp: # AUTHORITATIVE audit timestamp
+ entity_uuid / entity_type / action / actor_uuid / tenant_uuid
+ change_fingerprint:
+ status: pending_forward
+```
+Written using Raft consensus — confirmed when quorum (2/3 or 3/5) of Commit Log replicas acknowledge. Operation returns success after Stage 1. Stage 1 timestamp is the authoritative audit timestamp (AUD-013).
+
+**Stage 2 (asynchronous, out of critical path):**
+Audit Forward Service enriches minimal Commit Log entry → full audit_record → hash chain computed → written to Audit Store with retry. Full record visible seconds to minutes after Stage 1.
+
+### 23.3 Composite Actor Chain — The "Who"
+```yaml
+actor:
+ immediate:
+ type:
+ uuid / display_name
+ authorized_by:
+ uuid / authorization_method:
+ request_uuid / policy_uuid / correlation_id
+```
+
+### 23.4 Action Vocabulary (closed — AUD-007)
+`CREATE | MODIFY | STATE_TRANSITION | DELETE | ACTIVATE | DEACTIVATE | DEPRECATE | RETIRE | MEMBER_ADD | MEMBER_REMOVE | RELATIONSHIP_CREATE | RELATIONSHIP_RELEASE | AUTHORIZE | REVOKE | EVALUATE | ENRICH | LOCK | HOLD_PLACE | HOLD_CONFIRM | HOLD_RELEASE | DRIFT_DETECT | DRIFT_RESOLVE | INGEST | PROMOTE | EXPIRE | REHYDRATE | QUERY | DISCOVER | LOGIN | LOGOUT | CONFIG_CHANGE`
+
+### 23.5 Retention — Reference-Based
+- `retention_status: live` — any referenced entity non-retired → retain unconditionally
+- `retention_status: all_retired` → apply governing policy
+- Post-lifecycle defaults: dev=P90D, standard=P3Y, prod/fsi=P7Y (DEFAULT), sovereign=P10Y
+
+### 23.6 Tamper-Evidence — Hash Chain
+`record_hash` (SHA-256 of record) + `previous_record_hash` (preceding record for this entity) + `chain_sequence`. Chain breaks detectable and trigger security alerts (AUD-010).
+
+### 23.7 Recoverability
+- DCM crash after Stage 1 → Audit Forward Service replays `pending_forward` entries on restart (AUD-011)
+- Audit Store unavailable → Commit Log accumulates; Audit Forward Service retries when recovered
+- Commit Log quorum unavailable → operation aborted — no silent change
+
+### 23.8 System Policies
+- `AUD-001` — Every modification produces Commit Log entry synchronously; Commit Log write failure aborts operation
+- `AUD-002` — Audit records append-only and immutable while retention obligations apply
+- `AUD-003` — Audit records survive at least as long as any referenced entity is live
+- `AUD-004` — Post-lifecycle retention governed by policy; default P7Y
+- `AUD-005` — Actor field must identify immediate actor + authorized_by chain
+- `AUD-006` — record_hash + previous_record_hash hash chain required
+- `AUD-007` — Action field must use closed vocabulary
+- `AUD-008` — Audit Store must support queries by entity_uuid, actor_uuid, action, timestamp range, tenant_uuid, request_uuid, retention_status
+- `AUD-009` — Audit Forward Service delivers with exponential backoff retry; cleared only after Audit Store confirmation AND retention window
+- `AUD-010` — Hash chain verification first-class; chain breaks trigger immediate security alerts
+- `AUD-011` — On restart, Audit Forward Service replays all pending_forward entries before accepting new operations
+- `AUD-012` — Commit Log uses Raft consensus with quorum writes
+- `AUD-013` — Stage 1 Commit Log timestamp is authoritative audit timestamp
+
+---
+
+## SECTION 24 — DEPLOYMENT AND REDUNDANCY
+
+Every DCM component and store is designed for redundancy by default. Everything containerized. Profile-governed. Self-hosting. See `17-deployment-redundancy.md` for the complete model.
+
+### 24.1 Core Principles
+- **Redundant by default** — every component and store has a redundancy model
+- **Everything containerized** — all components run as Kubernetes pods; no bare-metal DCM
+- **Profile-governed** — replica counts and quorum set by active Profile; not per-component
+- **Stateless control plane** — all state in external stores; any pod can fail and be replaced
+- **Self-hosting** — DCM's own deployment is a DCM resource; DCM manages itself
+
+### 24.2 Redundancy Matrix by Profile
+
+| Profile | CP Replicas | Store Replicas | Write Quorum | Zone Spread | Geo-Replication |
+|---------|------------|---------------|-------------|------------|----------------|
+| `minimal` | 1 | 1 | No | No | No |
+| `dev` | 1 | 1 | No | No | No |
+| `standard` | 3 | 3 | 2/3 | Preferred | No |
+| `prod` | 3 | 3 | 2/3 | Required | Yes |
+| `fsi` | 5 | 5 | 3/5 | Required | Yes |
+| `sovereign` | 5 | 5 | 3/5 | Required | Within boundary |
+
+### 24.3 Store Redundancy Model
+
+| Store | Implementation | Write Quorum | Notes |
+|-------|---------------|-------------|-------|
+| Commit Log | etcd (Raft) | 2/3 | Stage 1 audit; < 1ms write |
+| GitOps Store | Gitea/equivalent | 2/3 | Intent, Requested, Layers, Policies |
+| Event Stream | Kafka/equivalent | 2/3 | Realized, Discovered, Audit events |
+| Audit Store | Elasticsearch/equivalent | 2/3 | Indexed, queryable, compliance-grade |
+| Search Index | Elasticsearch/equivalent | 1 | Non-authoritative — rebuildable from Git |
+
+### 24.4 Pod Security Model (all components)
+`run_as_non_root: true` | `run_as_user: 65534` | `read_only_root_filesystem: true` | `allow_privilege_escalation: false` | `capabilities.drop: [ALL]` | mTLS for all inter-component communication (RED-009)
+
+### 24.5 Self-Hosting
+DCM's own deployment is declared as a `dcm_deployment` DCM resource in Git. DCM runs drift detection on its own components. Bootstrap sequence: bootstrap installer → reads `dcm_deployment` from Git → provisions to target redundant state → hands off.
+
+### 24.6 The Repave Scenario
+DCM lost entirely → bootstrap installer on new cluster → reads `dcm_deployment` from Git → provisions itself → rehydrates customer workloads in dependency order → drift detection validates. Recovery bounded by infrastructure provisioning speed — not backup restoration.
+
+### 24.7 System Policies
+- `RED-001` — All DCM components run as containers in Kubernetes pods
+- `RED-002` — All control plane components stateless
+- `RED-003` — Profiles above `minimal`: replicas >= 3 with anti-affinity
+- `RED-004` — Profiles above `minimal`: quorum writes with write_quorum >= 2
+- `RED-005` — Commit Log uses Raft consensus with quorum writes
+- `RED-006` — DCM deployment declared as DCM resource in Git
+- `RED-007` — DCM runs drift detection on its own components
+- `RED-008` — Rolling updates must not reduce replicas below min_available
+- `RED-009` — All component communication uses mTLS
+- `RED-010` — Bootstrap manifest is the only DCM config outside DCM's management scope
+
+---
+
+## SECTION 25 — WEBHOOKS, MESSAGING, AND EXTERNAL INTEGRATION
+
+### 25.1 The Three Integration Mechanisms
+- **Outbound Webhooks** — DCM pushes event notifications to external HTTP endpoints
+- **Inbound Webhooks** — External systems push requests, queries, and events to DCM
+- **event routing service** — Persistent bidirectional event streaming with external message buses
+
+All three are authenticated, authorized, and audited identically to any other DCM API call. No privileged back-channel.
+
+### 25.2 Universal Ingress/Egress Actor Model
+
+Every request carries an immutable `ingress` block set by the DCM ingress layer:
+```yaml
+ingress:
+ surface:
+ protocol:
+ authenticated_via:
+ actor:
+ uuid / type / display_name / identity_source
+ auth_provider_uuid / auth_provider_type
+ roles / tenant_scope / groups / permissions
+ authorized_by: {method, authorizing_entity_uuid, expiry}
+ session_uuid / mfa_verified
+ external_identity: {provider, subject, claims}
+ webhook_registration_uuid / service_provider_uuid / parent_request_uuid
+ source_ip # audit only — never used for authorization
+```
+The ingress block is immutable — policies may read but never modify it. Carried verbatim into audit records. Policies can act on any ingress field (surface, actor.roles, auth_provider_type, mfa_verified, etc.).
+
+Egress calls carry DCM's authenticated identity via the `egress` block: component, authenticated_via, credential_ref, originating_request_uuid.
+
+### 25.3 Outbound Webhooks
+Optional and policy-governed. Profile sets defaults — fsi/sovereign may require via Policy Group.
+
+Key properties:
+- **Schema adapters** — consumer pins to a schema version; DCM transforms forever; 90-day deprecation notice
+- **Managed secret rotation** — automatic with transition window; consumer notified via signed event
+- **Endpoint health** — suspend-not-delete on failure; full config retained for reactivation
+- **Versioned registrations** — standard DCM artifact lifecycle; Git-managed
+- **Sovereignty-aware** — delivery blocked if endpoint jurisdiction incompatible with Tenant sovereignty
+
+Delivery: at-least-once; per-entity ordering guaranteed; cross-entity ordering not guaranteed; `event_uuid` is idempotency key.
+
+### 25.4 Inbound Webhooks
+DCM exposes typed authenticated endpoints:
+- `POST /webhooks/inbound/request` — submit service request
+- `POST /webhooks/inbound/query` — query entity state/catalog
+- `POST /webhooks/inbound/event` — push provider state change / CI/CD signal
+- `POST /webhooks/inbound/ingestion` — push brownfield ingestion data
+- `POST /webhooks/inbound/data` — push enrichment or information data
+
+Callers must be registered as **webhook actors** with role, tenant_scope, permitted_operations, and rate_limit. Full Policy Engine evaluation — same as any other API call. Returns 202 Accepted + request_uuid for async operations.
+
+### 25.5 event routing service (Sixth Provider Type)
+Persistent bidirectional event streaming. Supports: kafka, amqp, nats, mqtt, azure_service_bus, aws_eventbridge, gcp_pubsub, rabbitmq, custom.
+
+Inbound messages processed as authenticated API calls via registered webhook actor identity. Same Policy Engine evaluation as inbound webhooks.
+
+Architecture: internal Message Bus → Message Bus Bridge Service ↔ external message bus.
+
+### 25.6 Webhook System Policies
+WHK-001 through WHK-014 — see doc 18. Key: ING-008 (ingress block immutable), ING-009 (full actor context required), ING-010 (egress authenticated), ING-011 (no anonymous access), ING-012 (webhook/message bus always authenticated).
+
+---
+
+## SECTION 26 — AUTHENTICATION, AUTHORIZATION, AND AUTH PROVIDERS
+
+### 26.1 Auth Provider — The Eighth Provider Type
+An **Auth Provider** answers two questions: (1) is this identity who they claim to be? and (2) what are they permitted to do? Every authentication mode is an Auth Provider implementation.
+
+**Authentication is always required — no anonymous access in any profile.** The difference between profiles is how much effort setup requires.
+
+### 26.2 Built-In Auth Provider (zero configuration)
+Always registered, cannot be deregistered. Supports:
+- **Static API key** — generated at bootstrap, shown once, 30 seconds to start
+- **Local users** — `dcm user create --username admin --role platform_admin`
+- **GitHub/GitLab OAuth** — opt-in, requires client_id + secret
+
+### 26.3 Auth Modes by Profile
+
+| Profile | Auth Modes | Setup Effort |
+|---------|-----------|-------------|
+| `minimal` | Static API key, Local user/password | 30 seconds – 2 min |
+| `dev` | + GitHub/GitLab OAuth, FreeIPA/AD direct bind | 5–15 minutes |
+| `standard` | + OIDC via broker, AD/FreeIPA direct | 30–60 minutes |
+| `prod` | + OIDC direct, MFA configurable | 1–2 hours |
+| `fsi` | + mTLS required, MFA required | 4–8 hours |
+| `sovereign` | + Air-gapped OIDC/mTLS | 1–2 days |
+
+No anonymous access in any profile. No static API key in standard+. mTLS required in fsi/sovereign.
+
+### 26.4 LDAP / FreeIPA / Active Directory
+FreeIPA: direct LDAP bind with optional Kerberos SSO and HBAC enforcement. Ideal for Red Hat / Linux-first environments.
+
+Active Directory: LDAP bind with `LDAP_MATCHING_RULE_IN_CHAIN` (OID 1.2.840.113556.1.4.1941) for nested group resolution. `sAMAccountName` or UPN for user lookup. Automatic DC failover.
+
+Both support: group_role_map (external groups → DCM roles), tenant_mapping (external groups → DCM Tenants), group_sync (interval-based re-sync), multiple domain controllers for failover.
+
+### 26.5 Multiple Auth Providers and Routing
+Multiple providers registered simultaneously. Ingress layer routes based on authentication signal (mtls_client_cert → mtls provider; bearer_token → OIDC or API key provider; basic_auth → LDAP; hmac_signature → webhook provider; none → reject).
+
+Auth providers can be chained: authentication (LDAP bind) → enrichment (LDAP groups) → augmentation (OIDC userinfo for rich claims like department, cost_center).
+
+### 26.6 credential management service (Seventh Provider Type)
+Cross-cutting dependency for all secret resolution. Supports: hashicorp_vault, aws_secrets_manager, azure_key_vault, gcp_secret_manager, kubernetes_secrets, cyberark, delinea, external_api, dcm_internal.
+
+All provider registrations, webhook configurations, and Auth Provider connections reference credentials via:
+```yaml
+secret_ref:
+ service_provider_uuid:
+ secret_path: "dcm/path/to/secret"
+ version: latest
+```
+Credentials never stored in Git. Never appear in audit record values (only secret_path logged). Cached in memory with configurable TTL.
+
+### 26.7 Auth Provider Health
+On unhealthy: existing sessions remain valid until TTL expiry; new auth attempts route to fallback_provider_uuid or are rejected. On_unhealthy options: alert, fallback_to_next, block_new_sessions.
+
+### 26.8 System Policies
+AUTH-001 through AUTH-010 — see doc 19. Key: AUTH-008 (no anonymous access in any profile), AUTH-009 (webhook/message bus always authenticated), AUTH-007 (credentials always via credential management service).
+
+---
+
+## SECTION 27 — REGISTRY GOVERNANCE
+
+### 27.1 The Three-Tier Registry
+
+| Tier | Name | Maintained By | Contains |
+|------|------|--------------|---------|
+| 1 | DCM Core | DCM Project team | Universal types (Compute.VirtualMachine, Network.VLAN, etc.) |
+| 2 | Verified Community | Named community maintainers | Technology-specific types (OpenStack.HeatStack, KubeVirt.VirtualMachine) |
+| 3 | Organization | Deploying organization | Organization-specific/proprietary types |
+
+### 27.2 The Federated Registry Model
+Not centralized, not fully distributed — federated:
+```
+DCM Project Registry (origin) → Organization Registry (local mirror) → Air-gapped Registry (offline copy)
+```
+Every DCM deployment has exactly one active **Resource Type Registry** (sub-type of Information Provider). Air-gapped deployments use signed bundles verified against the organization's public key — no external connectivity required.
+
+### 27.3 PR-Based Proposal Workflow (Q9)
+Resource Type proposals are Pull Requests against the registry repository. Automated gates before review: schema validation, FQN conflict check, dependency resolution, breaking change detection, test case coverage. Shadow validation in `proposed` status is mandatory before `active` promotion.
+
+**Review periods by change type:** Revision=3 days, Minor/Tier2=7 days, Tier1=14 days, Breaking=21 days, Deprecation=30 days, Emergency=waived (7-day shadow minimum).
+
+### 27.4 Deprecation Lifecycle — Default Policies (Q11)
+Deprecation lifecycle is governed by **default DCM system policies** (REG-DP-001 through REG-DP-007), overridable via standard policy priority. FSI/sovereign profiles lock sunset periods as immutable.
+
+| Policy | Default | Overridable? |
+|--------|---------|-------------|
+| `REG-DP-001` | 30-day notification before deprecation | Yes |
+| `REG-DP-002` | Sunset: Tier 1=P12M, Tier 2=P6M | Yes (locked in fsi/sovereign) |
+| `REG-DP-003` | Migration window: P90D after retirement | Yes |
+| `REG-DP-004` | Successor type required in deprecation notice | Yes |
+| `REG-DP-005` | Retired types reject new requests | **No — structural** |
+| `REG-DP-006` | Existing realizations → DEPRECATED_RUNTIME | Yes |
+| `REG-DP-007` | Emergency migration floor: P30D | **No — floor** |
+
+DEPRECATED_RUNTIME: eligible for modify/decommission; not eligible for rehydration using deprecated type; drift detection continues.
+
+### 27.5 Version Resolution Policy (Q12)
+Strictly enforced — no silent resolution to different version. DCM never auto-upgrades across major versions.
+
+`version_policy` options: `exact` | `compatible` (^major) | `latest_minor` (~minor) | `latest`
+
+Profile defaults: minimal=latest, dev/standard/prod=compatible, fsi/sovereign=exact.
+
+### 27.6 Provider Tie-Breaking Hierarchy (Q13)
+When multiple providers satisfy all placement criteria equally:
+1. **Policy preference** — Transformation policy injected preference_score or preferred_provider_uuid
+2. **Provider priority** — numeric field on registration (default: 50; higher = preferred)
+3. **Tenant affinity** — Policy Group declares preferred providers for resource types
+4. **Cost analysis** — if Cost Analysis has current data AND cost is determinable and comparable (skip if not)
+5. **Least loaded** — capacity utilization from reserve_query (skip if data unavailable)
+6. **Consistent hash** — SHA-256(request_uuid + resource_type + sorted_candidate_uuids); deterministic, never round-robin
+
+Cost ranks above operational load because it is a business decision. 5% threshold — candidates within 5% cost are treated as equal.
+
+### 27.7 Resource Type Registry — Policy Governed (Q14)
+The Resource Type Registry is fully policy-governed. Policies act on registry sync, activation, bundle import, and version upgrades. Profile-appropriate registry policy groups activated by default:
+
+| Group | Profile | Behavior |
+|-------|---------|---------|
+| `system/group/registry-minimal` | minimal | Advisory; pull everything; warn only |
+| `system/group/registry-dev` | dev | Warn on unverified sources; Tier 1+2 |
+| `system/group/registry-standard` | standard | Block unverified; sovereignty filter |
+| `system/group/registry-prod` | prod | Vendor allowlist; audit all syncs; major version manual approval |
+| `system/group/registry-fsi` | fsi | Exact pinning; immutable sunset; dual-approval syncs |
+| `system/group/registry-sovereign` | sovereign | Signed bundles only; offline; no external connectivity |
+
+### 27.8 System Policies
+REG-001 through REG-007 and REG-DP-001 through REG-DP-007 — see doc 20.
+
+---
+
+## SECTION 28 — STORAGE ARCHITECTURE
+
+### 28.1 Git Repository Structure (Q79)
+Handle-based directory structure. Four repos: Intent, Requested, Layers, Policies. Minimal/dev may use monorepo; standard+ use separate repos. `main` is authoritative. Tenant isolation under `{tenant-uuid}` directories. DCM service account handles all Git reads/writes — no direct Tenant Git access.
+
+```
+dcm-intent/tenants/{tenant-uuid}/requests/{request-uuid}/intent.yaml
+dcm-requested/tenants/{tenant-uuid}/requests/{request-uuid}/requested-payload.yaml
+dcm-layers/{domain}/{type}/{name}/v{Major}.{Minor}.{Revision}.yaml
+dcm-policies/{domain}/{type}/{name}/v{Major}.{Minor}.{Revision}.yaml
+```
+
+### 28.2 Multi-Region Replication (Q80)
+Declared capability on store configuration. Active Profile determines minimum requirements:
+- minimal/dev: 1 replica, no multi-region
+- standard: 3 replicas, strong/bounded consistency
+- prod/fsi/sovereign: 3-5 replicas, strong consistency, geo-replicated
+- sovereign: multi-region required but within sovereignty boundary only
+
+(STO-001)
+
+### 28.3 Data Store Failure Handling (Q81)
+Per store type — policy-governed:
+- **Commit Log:** quorum unavailable → abort operation (no silent changes)
+- **GitOps Stores:** unavailable → queue writes locally (max size + max age); explicit reject on exhaustion
+- **Event Stream:** producer queues locally; consumer resumes from last offset on recovery
+- **Audit Store:** two-stage model — accumulates in Commit Log; operations not blocked
+- **Search Index:** non-authoritative; degrades gracefully; full rebuild on recovery
+
+(STO-002)
+
+### 28.4 Search Index — Separate Sub-Type (Q82)
+Separate PostgreSQL store contract — distinct from GitOps stores. Non-authoritative, rebuildable from authoritative stores. Consistency lag declared (e.g., PT5M). API queries may specify `freshness: authoritative` to bypass index. (STO-003)
+
+### 28.5 Audit Store — Specialized Sub-Type (Q83)
+Specialized PostgreSQL store contract — NOT the same as Event Stream. Properties: append-only with immutability enforcement, hash chain integrity, reference-based retention tracking, compliance-grade multi-dimensional queries. Event Stream is the delivery channel; Audit Store is the compliance destination. (STO-004)
+
+---
+
+## SECTION 29 — PROVIDER SOVEREIGNTY DECLARATIONS
+
+### 29.1 Obligation
+Every provider registration (Service, Information, Message Bus, Policy, Auth Provider) MUST include a `sovereignty_declaration` block. Contractual obligation — not optional metadata.
+
+### 29.2 What Sovereignty Declaration Covers
+- **operating_jurisdictions** — countries and legal jurisdictions where provider physically operates
+- **legal_frameworks** — applicable frameworks (GDPR, HIPAA, FedRAMP, ITAR, etc.)
+- **data_residency_guarantee** — data never leaves declared jurisdictions (true/false)
+- **data_transit_jurisdictions** — jurisdictions data transits through during operations
+- **external_dependencies** — external connectivity requirements, air_gap_capable flag, external services with data sharing details
+- **sub_processors** — third-party sub-processors with jurisdiction and data handled
+- **government_access_risk** — which governments can legally compel access
+- **certifications** — current certifications with validity periods (ISO-27001, SOC2, PCI-DSS, FedRAMP)
+- **audit_rights** — customer audit rights and notice periods
+- **change_notification** — mandatory notification events and SLA (e.g., PT24H)
+
+### 29.3 Change Notification and DCM Response
+Provider MUST notify DCM when any sovereignty data changes. DCM treats sovereignty changes as discovered drift → Policy Engine re-evaluation:
+- **No violations:** update record, emit webhook event, notify Tenants (informational)
+- **Violations found:** for each affected resource, policy declares action:
+ - `notify_only` — inform Tenant; no automatic action
+ - `pause` — suspend resource; Tenant must act
+ - `migrate` — Provider-Portable Rehydration to compliant provider (sequential)
+ - `emergency_migrate` — parallel provisioning before decommission
+
+Sovereignty violation record created in Audit Store. Notifications: Tenant owner, platform admin, data_protection_officer.
+
+### 29.4 Auto-Migration
+Policy declares `migrate` or `emergency_migrate` → DCM uses Provider-Portable Rehydration. Non-compliant provider excluded from placement candidate set. Full audit trail linking violation record to migration request. (SOV-001 through SOV-005)
+
+---
+
+## SECTION 30 — GIT PR INGRESS
+
+### 30.1 Concept
+DCM supports `git_pr_merge` and `git_pr_open` as ingress surfaces. Teams submit standard DCM resource definition YAML as Pull Requests. DCM's Git Request Watcher monitors designated repositories.
+
+### 30.2 Git Actor Identity Resolution
+**DCM trusts the Git server's authentication assertion — not user-declared Git configuration.** Git `user.email` self-declaration is ignored — spoofing vector.
+
+Resolution methods (all go through registered Auth Provider):
+- `oidc_subject_lookup` — Git server OAuth subject → OIDC Auth Provider → DCM actor
+- `ldap_username_lookup` — Git server username → LDAP/AD Auth Provider → DCM actor
+- `ssh_key_fingerprint` — key fingerprint → DCM SSH key registry → DCM actor
+- `webhook_service_account` — CI/CD service account → registered webhook actor
+
+**The resolved actor has IDENTICAL roles, groups, and tenant scope to the same user logging in via web UI.** Git PR ingress does not grant different permissions than any other surface. Same Auth Provider, same group mappings, same tenant scope enforcement.
+
+**Unresolvable identity → explicit PR rejection comment** with actionable guidance. Never silently ignored.
+
+### 30.3 PR Lifecycle
+1. PR opened → DCM resolves author → Auth Provider → shadow policy evaluation posted as PR comments
+2. Human review + Git branch protection approvals
+3. PR merged → actor re-verified at merge time (not assumed from PR open) → full nine-step assembly → realization result posted as PR comment
+4. Realized state committed to `realized/` directory (optional)
+
+### 30.4 The git_context in ingress block
+```yaml
+ingress:
+ surface: git_pr_merge
+ actor:
+ git_context:
+ repository / pr_number / pr_url / merge_commit
+ pr_author / pr_reviewers / pr_approved_by
+ # pr_approved_by: DCM resolves reviewer Git identities via same Auth Provider
+```
+
+### 30.5 Policy Use Cases
+- Require specific approvers in pr_approved_by before processing
+- Require MFA for Git PR merges in prod Tenants
+- Restrict resource types submittable via Git PR
+- Require actor to be in authorized Tenant group
+- Post shadow evaluation results as PR comments
+
+### 30.6 System Policies
+GIT-001 through GIT-008 — see doc 18. AUTH-011 — Git identity resolution uses registered Auth Provider; same role/group/tenant scope as any other ingress.
+
+---
+
+## SECTION 31 — ENTITY AND DEPENDENCY GAPS
+
+### 31.1 Ownership Transfers (Q25)
+Ownership transfers are **unlimited by default**. Each transfer is immutably recorded with a monotonically incrementing `transfer_number` and mandatory reason field. Policy may declare a maximum per resource type via GateKeeper. ENT-001.
+
+### 31.2 Bare Metal Indivisibility (Q26)
+`Compute.BareMetal` declares `allocation_model: whole_unit` and `shareability.allowed: false` (structural lock). Placement holds are exclusive — no concurrent holds on the same server. Provider must report full physical identity (serial_number, hardware_profile) in realized payload and notify DCM of any sharing attempt. ENT-002.
+
+### 31.3 Capacity Confidence Actions (Q27)
+Confidence ratings trigger policy-governed automatic actions:
+- `HIGH` → proceed (all profiles)
+- `MEDIUM` → proceed_with_warning (minimal/dev) or refresh_before_placement (prod/fsi/sovereign)
+- `LOW` → proceed_with_warning (minimal), refresh_before_placement (dev/standard), reject (prod/fsi/sovereign)
+
+LOW confidence triggers a Mode 1 Information Provider query before finalizing placement in standard+ profiles. Policy Group overrides per resource type. ENT-003.
+
+### 31.4 Process Resource Execution Time (Q28)
+`max_execution_time` is **mandatory** on Process Resource entities. Enforced by the Lifecycle Constraint Enforcer as a standard TTL. Profile governs default `on_max_exceeded`:
+- minimal/dev: `notify`
+- standard/prod: `escalate`
+- fsi/sovereign: `terminate`
+
+ENT-004.
+
+### 31.5 SUSPENDED State Billing (Q29)
+`billing_state` is a first-class field on all entities: `billable | non_billable | reduced_rate`. Policy injects `billing_state` and `billing_metadata` (rate_multiplier, billable_components) during state transitions. Cost Analysis component consumes the field — DCM carries the billing signal, policy decides the billing model. ENT-005.
+
+### 31.6 Dependency Graph Versioning (Q30)
+Dependency graphs versioned as part of their parent catalog item — not independently. New required dependency or removed dependency = **major (breaking) version bump**. New optional dependency = minor bump. Constraint change = revision bump. Dependency graph version captured in assembly provenance. ENT-006.
+
+### 31.7 Dependency Graph Storage (Q31)
+Not a separate entity. Three levels:
+- Declared graph: embedded in Resource Type Specification (GitOps)
+- Resolved graph: embedded in `placement.yaml` in Requested State
+- Realized graph: Realized State events per dependency
+
+ENT-007.
+
+### 31.8 Dependency Graph Depth (Q33)
+Profile-governed maximum: minimal=20, dev=15, standard/prod=10, fsi/sovereign=7. Requests exceeding max depth rejected with clear error. Circular dependency detection always enforced regardless of depth configuration. ENT-008.
+
+### 31.9 Meta Provider Composition Visibility (Q34)
+Meta Providers declare `composition_visibility`:
+- `opaque` — consumer sees only top-level service; sub-resources not in DCM; drift on realized payload only
+- `transparent` — all sub-resources registered as DCM entities; full drift detection
+- `selective` — provider declares which sub-resources are DCM-visible
+
+ENT-009.
+
+### 31.10 System Policies
+ENT-001 through ENT-009 — see docs 06 and 07.
+
+---
+
+## SECTION 32 — INFORMATION PROVIDER CONFIDENCE SCORING AND AUTHORITY
+
+### 32.1 Confidence Scoring — 0 to 100
+Every Information Provider field value carries a confidence score (0-100). DCM computes scores — providers do not self-declare. Score bands for policy use: very_high (81-100), high (61-80), medium (41-60), low (21-40), very_low (0-20).
+
+**Formula:**
+```
+confidence_score = min(100, base_score × freshness_multiplier × corroboration_multiplier × authority_multiplier)
+```
+
+| Factor | Values |
+|--------|--------|
+| Base score | primary_authoritative=90, secondary=70, discovered=60, advisory=50, self_reported=40, inferred=30 |
+| Freshness | <1h=1.00, <1d=0.95, <7d=0.85, <30d=0.70, >30d=0.50 |
+| Corroboration | 1 source=1.00, 2 agree=1.10, 3+ agree=1.15, disagree=0.60 |
+| Authority | primary=1.00, secondary=0.85, advisory=0.70 |
+
+### 32.2 Authority as Layer Data
+Authority scope and priority for Information Providers are declared in **platform or system domain layers** — not just policies. This is static organizational knowledge ("our CMDB is authoritative for business unit data"). Layer-defined authority establishes the default; policies act on confidence scores at runtime.
+
+### 32.3 Ingestion-Time Conflict Detection
+Conflict detection at ingestion time (7-step flow): schema validation → authority scope check → confidence score computation → conflict detection → resolution policy → entity record update → INGEST audit record.
+
+**Resolution strategies:** `higher_authority_wins` | `higher_confidence_wins` | `higher_priority_wins` | `escalate` | `merge` (array fields only)
+
+Authority scope conflicts detected at **registration time** — two providers claiming primary authority for the same field cannot both go active without explicit resolution.
+
+### 32.4 Write-Back (Q63)
+Optional declared capability. Policy triggers write-back — never automatic. Produces ENRICH audit records. Credentials via credential management service. (INF-002)
+
+### 32.5 Extended Schema Versioning (Q64)
+Semver semantics: field removal/type change = major (breaking); new optional field = minor; constraint change = revision. Migration plan required for major bumps. (INF-003)
+
+### 32.6 Well-Known Provider Registry (Q65)
+Three-tier registry (Core/Community/Organization) — same governance model as Resource Type Registry. Separate registries, shared infrastructure. (INF-004)
+
+### 32.7 Air-Gapped Verification (Q66)
+Three modes: pre-verified signed bundle, internal mTLS (for internal providers), periodic online re-verification with cached tokens. Profile governs cache expiry behavior. (INF-005)
+
+### 32.8 System Policies
+INF-001 through INF-008 — see docs 10 and 21.
+
+---
+
+## SECTION 33 — DCM FEDERATION AND CROSS-INSTANCE COORDINATION
+
+### 33.1 Three Relationship Types
+- **Peer DCM** — same organizational level; share resources/information
+- **Parent-Child DCM** — hierarchical; parent has governance overlay; does not own child resources
+- **Hub DCM** — specialized parent as resource allocation clearinghouse
+
+All use the Universal Group Model: federation group (peers) or tenant_boundary nesting (parent-child).
+
+### 33.2 Provider Federation Eligibility
+Every provider registration declares `federation_eligibility`:
+- `mode: none` — cannot participate in any federation (sovereign/classified providers)
+- `mode: selective` — only with explicitly declared partners
+- `mode: open` — any trusted DCM peer (sovereignty checks always apply)
+
+**Layer-defined defaults** in `platform` domain layer. Individual registrations may be **more restrictive** — never more permissive without GateKeeper approval.
+
+**Federation scope declares:** permitted resource types + operations, data sharing permissions, max concurrent allocations. Remote DCMs CANNOT decommission local resources through a tunnel.
+
+**Storage providers default to `mode: none`** — data sovereignty prohibits storage federation unless explicitly authorized.
+
+### 33.3 The DCM Provider — Ninth Provider Type
+Wraps another DCM instance's API. Always mTLS (non-configurable). Sovereignty checks mandatory before tunnel establishment. Local DCM policies govern ALL resources from any tunnel.
+
+**Non-negotiable primary concerns on all tunnels:**
+- Sovereignty: verified before establishment; data classification checked per egress
+- Authentication: always mTLS — no API key or bearer token
+- Authorization: local policies govern; remote policies cannot override
+- Audit: records in BOTH DCM instances; shared correlation_id
+- Observability: cross-DCM allocation visible in both instances
+
+### 33.4 Cross-DCM Confidence Scoring
+```
+cross_dcm_confidence = source_resource_confidence × (tunnel_trust_score / 100)
+```
+Federation trust score (0-100): factors include identity verification, sovereignty compatibility, certifications currency, audit trail integrity, uptime, compliance.
+
+### 33.5 DCM Export/Import
+Signed export package: tenants, layers, policies, provider registrations (not credentials), entity intent/requested states, groups, audit records with hash chain. Never export credentials.
+
+Import trust score (0-100): source verification + sovereignty compatibility + data completeness + schema compatibility + audit trail integrity. Low score → reject or escalate.
+
+### 33.6 System Policies
+DCM-001 through DCM-008 — see doc 22.
+
+---
+
+## SECTION 34 — OPERATIONAL AND PERFORMANCE GAPS
+
+### 34.1 Field-Level Provenance Models (Q7, Q8)
+
+**Three configurable models — organization chooses; profile provides default:**
+
+**Model A — Full Inline**
+All provenance stored on entity record. Simplest queries, highest storage cost, no tooling required.
+- ✅ Auditors read one record — regulatory clarity
+- ✅ No dependency on layer chain store
+- ❌ Very high storage volume at scale
+- ❌ Write amplification
+
+**Model B — Deduplicated (Content-Addressed) ← RECOMMENDED**
+Layer chain is the deduplication key. Classical content-addressed dedup (like Git objects, Docker layers). Only delta fields store unique provenance. 95-99% storage reduction for standardized deployments. Lossless because layer chains are immutable.
+- ✅ Dramatic storage reduction
+- ✅ Full audit reconstruction always possible
+- ✅ Write performance highest (layer-matching fields free)
+- ❌ Chain traversal tooling required for queries
+- ❌ Layer chain must be retained while any entity references it
+
+**Model C — Tiered Archive**
+Hot (full detail) → warm (change events) → cold (hash anchors). Degrades gracefully.
+- ✅ Balances cost and access speed
+- ✅ Compliant for long retention
+- ❌ Cross-tier queries for long time ranges
+- ❌ Cold tier requires full records from warm/hot for reconstruction
+
+**Model B+C — Combined**
+Maximum efficiency: content-addressed dedup + tiered archival of chains and deltas.
+
+**Profile defaults:**
+
+| Profile | Provenance Group | Rationale |
+|---------|----------------|-----------|
+| minimal, dev | `system/group/provenance-full-inline` | Simplicity; scale not a concern |
+| standard, prod | `system/group/provenance-deduplicated` | Scale matters; tooling justified |
+| fsi, sovereign | `system/group/provenance-full-inline` | Regulatory clarity; self-contained |
+
+Organizations override by swapping the active provenance Policy Group.
+
+**Audit completeness guarantee (OPS-002):** Regardless of model, full provenance is always reconstructable from entity record + layer chain store + Audit Store combined.
+
+### 34.2 Background Conflict Validation (Q85)
+Event-triggered (primary) on layer ingestion/update — async, non-blocking. Scheduled weekly sweep as safety net. Both triggers produce same conflict record format and audit trail. (OPS-003)
+
+### 34.3 Policy Minimum Review Periods (Q86)
+Change-type minimum periods: GateKeeper=14d, Validation=7d, Transformation=3d. Profile multipliers: minimal=0×, dev=0.5×, standard=1×, prod=1.5×, fsi/sovereign=2×. DCM enforces — not bypassable except emergency activation with dual-approval audit. (OPS-004)
+
+### 34.4 Shadow Evaluation Store (Q87)
+Dedicated **Validation Store** (not Audit Store). Queryable and modifiable. Links to Audit Store EVALUATE events via audit_record_uuid. Default retention P90D after policy promotion/retirement. (OPS-005)
+
+### 34.5 Artifact Status Extensions (Q88)
+Five standard statuses (developing/proposed/active/deprecated/retired) are invariant — no custom additions. Organizations use status_metadata for workflow state (purely informational, no system behavior). Policy gates status transitions based on status_metadata field values. (OPS-006)
+
+### 34.6 System Policies
+OPS-001 through OPS-006 — see docs 03 and 06.
+
+---
+
+## SECTION 35 — PROFILE COMPOSITION — POSTURE AND COMPLIANCE DOMAINS
+
+### 35.1 The Two-Dimensional Profile Model
+
+**Profiles compose two orthogonal dimensions:**
+
+```
+Complete Profile = Deployment Posture Group + Compliance Domain Group(s)
+```
+
+**Dimension 1 — Deployment Posture** (vertical axis): How DCM infrastructure behaves — redundancy, enforcement strictness, audit retention, tenancy model.
+
+| Posture Group | Key Behaviors |
+|--------------|--------------|
+| `system/group/posture-minimal` | Advisory; single instance; no redundancy |
+| `system/group/posture-dev` | Warn-not-block; basic logging |
+| `system/group/posture-standard` | Full enforcement; 3-replica; explicit cross-tenant |
+| `system/group/posture-prod` | Full enforcement + SLA; geo-replicated |
+| `system/group/posture-hardened` | 5-replica; 7-year audit; dual approval |
+| `system/group/posture-sovereign` | Air-gap; deny_all; 10-year audit; signed bundles |
+
+**Dimension 2 — Compliance Domain** (horizontal): Which regulatory frameworks govern data and resources.
+
+| Compliance Group | Domain |
+|----------------|--------|
+| `system/group/compliance-fsi` | Financial Services — Basel III, SOX, Dodd-Frank |
+| `system/group/compliance-pci-dss` | Payment Card Industry — PCI-DSS v4 |
+| `system/group/compliance-hipaa` | Healthcare — HIPAA/HITECH PHI |
+| `system/group/compliance-fedramp-moderate` | US Federal Moderate — NIST 800-53 Moderate |
+| `system/group/compliance-fedramp-high` | US Federal High — NIST 800-53 High |
+| `system/group/compliance-dod-il2` through `il6` | DoD Impact Levels |
+| `system/group/compliance-government` | Government/public sector |
+| `system/group/compliance-gdpr` | EU GDPR data protection |
+| `system/group/compliance-iso27001` | ISO 27001 information security |
+| `system/group/compliance-nist-800-53` | NIST 800-53 security framework |
+| `system/group/compliance-soc2` | SOC 2 service organization controls |
+| `system/group/compliance-nerc-cip` | Critical infrastructure energy/utilities |
+| `system/group/compliance-sovereign` | Sovereign/classified — air-gap, HSM, signed bundles |
+
+### 35.2 Built-In Profile Compositions
+
+The six core profiles are posture+compliance compositions:
+
+```
+minimal = posture-minimal
+dev = posture-dev
+standard = posture-standard
+prod = posture-prod
+fsi = posture-hardened + compliance-fsi + compliance-pci-dss + compliance-iso27001
+sovereign = posture-sovereign + compliance-sovereign
+```
+
+**Extended built-in profiles:**
+
+| Profile | Extends | Compliance Groups Added |
+|---------|---------|------------------------|
+| `system/profile/hipaa-prod` | prod | compliance-hipaa, compliance-iso27001 |
+| `system/profile/hipaa-sovereign` | sovereign | compliance-hipaa |
+| `system/profile/fedramp-moderate` | prod | compliance-fedramp-moderate, compliance-nist-800-53 |
+| `system/profile/fedramp-high` | sovereign | compliance-fedramp-high, compliance-nist-800-53 |
+| `system/profile/government` | prod | compliance-government, compliance-nist-800-53 |
+| `system/profile/dod-il4` | sovereign | compliance-dod-il4, compliance-fedramp-high, compliance-nist-800-53 |
+| `system/profile/dod-il5` | dod-il4 | compliance-dod-il5 |
+| `system/profile/dod-il6` | dod-il5 | compliance-dod-il6, compliance-sovereign |
+
+### 35.3 HIPAA Compliance Group Key Controls
+- PHI field classification enforcement (phi: true tag required)
+- PHI access control (phi_authorized role required)
+- Audit retention: P6Y minimum
+- AES-256 at rest, TLS 1.3 in transit for PHI
+- Breach notification workflow via sovereignty_violation_record
+- BAA tracking: providers declare baa_in_place in sovereignty_declaration
+- Minimum Necessary standard on Mode 4 data_request_spec
+
+### 35.4 Government/DoD Key Controls
+- Data classification mandatory on all resources
+- Cross-boundary controls for classification levels
+- Audit retention: P10Y minimum
+- DoD IL4+: CUI handling markers; foreign sub-processor exclusion
+- DoD IL5+: sovereign posture within US boundary
+- DoD IL6: classified + HSM required for key management
+
+### 35.5 Tenant-Level Compliance Overlay
+**One DCM deployment, multiple compliance postures per Tenant:**
+```yaml
+tenant_config:
+ active_profile: system/profile/prod # posture from platform
+ compliance_groups:
+ - system/group/compliance-hipaa # this Tenant handles PHI
+ - system/group/compliance-pci-dss # this Tenant processes payments
+```
+Clinical Tenants (HIPAA) + Billing Tenants (HIPAA + PCI-DSS) + Admin Tenants (standard) — all on same DCM platform.
+
+### 35.6 System Policies
+- `PROF-001` — Profiles compose posture + compliance domain groups
+- `PROF-002` — Compliance groups apply at platform or Tenant level; additive not replacing
+- `PROF-003` — DCM ships built-in compliance groups for all major domains
+- `PROF-004` — implementation_posture groups (provenance model etc.) are independent of compliance domain
+
+---
+
+## SECTION 36 — GROUPING AND RELATIONSHIP GAPS
+
+### 36.1 Group Subclass Registry (Q35)
+No separate registry needed. `group_class` is the closed system-behavior set. `group_subclass` is open and advisory — freely declared, never validated. DCM ships a community subclass catalog as a non-authoritative reference (same infrastructure as well-known provider registry). GRP-011.
+
+### 36.2 Group Sovereignty Interaction (Q36)
+Class-specific sovereignty rules:
+- `tenant_boundary` — NEVER cross-sovereignty (structural, not configurable)
+- `resource_grouping` — permitted by default; policy may restrict for classified resources
+- `policy_collection` / `layer_grouping` — always permitted (governance artifacts, no data)
+- `composite` — governed by most restrictive member type
+- `federation` — permitted with DCM federation rules (DCM-003)
+
+GRP-012.
+
+### 36.3 Tenant Decommission Lifecycle (Q37)
+Mandatory four-phase staged decommission:
+1. **Pre-decommission validation** (blocking): resource state, cross-tenant relationships, compliance holds, rehydration leases, child groups resolved first
+2. **Resource decommission**: cascade (default) / retain (ORPHANED state) / notify (PENDING_DECOMMISSION)
+3. **Group membership cleanup**: remove from all memberships; empty federation groups → EMPTY state
+4. **Audit record archival**: all records enter post-lifecycle retention — NEVER destroyed
+
+Child tenant_boundary groups must be resolved BEFORE parent decommission (GRP-INV-003). GRP-013.
+
+### 36.4 Time-Bounded Group Membership (Q38)
+Already in Universal Group Model via `valid_from` / `valid_until` on every membership. Lifecycle Constraint Enforcer handles expiry. `on_expiry` actions: `remove` / `notify` (default) / `suspend_member`. `warn_before_expiry: P7D` standard. Expiry produces `MEMBER_REMOVE` audit record with `reason: membership_ttl_expired`. GRP-014.
+
+### 36.5 Group Policy Inheritance (Q39)
+Class-specific defaults, all profile-governed:
+- `tenant_boundary`: `opt_out` (standard/prod) — parent cascades unless child excludes; `opt_in` (minimal/dev/fsi/sovereign)
+- `federation`: always `opt_in` — peer consent required, not configurable
+- `composite`: `opt_out` by default, configurable
+- `resource_grouping` / `policy_collection`: not applicable
+
+GRP-015.
+
+### 36.6 Relationship Role Validation (Q58)
+Advisory by default. Resource Type Spec may declare `permitted_relationship_roles` with `role_validation: advisory | enforced`. Advisory → assembly warning for unknown roles. Enforced → unknown roles rejected at request time. DCM ships community role catalog as non-authoritative reference. REL-020.
+
+### 36.7 Relationship Graph Depth (Q60)
+Profile-governed max: minimal=25, dev=20, standard/prod=15, fsi/sovereign=10. Circular detection always enforced. Depth = graph traversal distance between any two entities (NOT count of relationships on one entity). REL-021.
+
+### 36.8 System Policies
+GRP-011 through GRP-015 — see doc 15. REL-020, REL-021 — see doc 09.
+
+---
+
+## SECTION 37 — AUDIT AND OBSERVABILITY GAPS
+
+### 37.1 Information Provider Trust Score Validation (Q15)
+
+Dual-trigger model — same pattern as conflict validation:
+
+**Event-triggered (primary):** push fails schema validation → degraded; push conflicts with primary authority → degraded; health check fails → degraded; sovereignty declaration change → re-evaluated; registration update → re-verification triggered.
+
+**Scheduled (safety net):** daily health check; weekly full re-verification (identity, sovereignty, certifications, schema). fsi/sovereign: daily full re-verification.
+
+**Trust score → source_trust mapping:**
+- Score ≥ 80: `verified` → confidence multiplier 1.00
+- Score 60-79: `degraded` → confidence multiplier 0.75
+- Score < 60: `suspended` → no new pushes accepted; score = 0
+
+(INF-009)
+
+### 37.2 Confidence Scoring — The Hybrid Descriptor Model (Q15 extended)
+
+**Three-tier model:**
+- **Confidence Descriptor** (primary — stored): `authority_level` + `corroboration` + `source_trust` + `last_updated_at`
+- **Derived Score** (0-100, computed on demand): mathematical composition for placement and conflict resolution
+- **Derived Band** (very_high/high/medium/low/very_low, computed on demand): what humans and policies use
+
+**Who sets each field:**
+- `authority_level`: set at registration from authority declaration layer (static per field per provider)
+- `corroboration`: computed at ingestion (confirmed/single_source/contested based on multi-provider comparison)
+- `source_trust`: maintained by trust scoring system (event-triggered + scheduled)
+- `last_updated_at`: set at each push event
+
+**Score formula:** `min(100, base(authority_level) × freshness_mult × corroboration_mult × trust_mult)`
+
+**Freshness is computed at query time** from `now - last_updated_at` — never stored (avoids staleness). Score and band computed at query time for the same reason.
+
+**Audit reconstruction:** authority_level (from registration) + corroboration (from ingestion event) + source_trust (from trust audit) + last_updated_at (from push event) → score and band fully reconstructable from stored facts.
+
+**Configurable derivation:** base scores, freshness thresholds, and band thresholds configurable via Policy Group — stored as versioned policy artifacts.
+
+### 37.3 Audit vs Observability — Definitively Separate (Q16)
+
+| | Audit | Observability |
+|--|-------|--------------|
+| Purpose | WHAT HAPPENED + WHO authorized | SYSTEM HEALTH + PERFORMANCE |
+| Consumers | Auditors, compliance, legal | SREs, operators, dashboards |
+| Write rate | Low (per action) | Very high (per second) |
+| Retention | P7Y+ | Days to months |
+| Mutability | Never — append-only | Downsampling acceptable |
+| Accuracy | 100% required | Statistical sampling OK |
+| Failure | Missing = compliance violation | Missing = operational inconvenience |
+
+They cannot be combined without violating one contract or the other. Observability may reference audit record UUIDs for correlation. AUD-013.
+
+### 37.4 Curated Observability Event Stream (Q17)
+
+DCM publishes a curated event stream via Message Bus — NOT raw metrics. Policy governs what is published, subscriber roles, and redaction. Published by default: component.health_changed, resource.state_transition, capacity.threshold_crossed, drift.detected, security.gatekeeper_triggered, provider.confidence_changed. NOT published by default: metrics.raw (explicit policy opt-in required).
+
+Observability events on Message Bus do NOT replace audit records. OBS-001.
+
+### 37.5 System Policies
+- `INF-009` — dual-trigger trust score; degraded/suspended states; policy governs thresholds
+- `AUD-013` — audit and observability definitively separate; different contracts/consumers
+- `OBS-001` — curated observability event stream via Message Bus; policy-filtered; raw metrics opt-in only
+
+---
+
+## SECTION 38 — OVERRIDE CONTROL AND ENHANCEMENT GAPS
+
+### 38.1 The Complete Field Lifecycle Contract
+
+Three questions together define the full field governance model across a resource's lifecycle:
+
+```
+ASSEMBLY TIME (Q50 — override_preference):
+ Which layers can set this field?
+ immutable → only this layer and higher-domain layers
+ constrained → any layer within declared bounds
+ allow → any layer
+
+CATALOG PRESENTATION (Q52 — constraint_visibility):
+ What does the consumer see about this field's constraints?
+ full → constraint + bounds + reason + suggestions
+ summary → bounds only
+ hidden → enforced silently
+
+POST-REALIZATION (Q56 — editability):
+ Can the consumer change this field after provisioning?
+ editable: false → requires reprovisioning
+ editable: true → targeted delta update permitted (within edit_constraints)
+```
+
+### 38.2 Override Preference Enforcement (Q50)
+
+`override: allow | constrained | immutable` on layer fields is enforced by the Request Payload Processor during assembly **Step 3 (Layer Merge)**. No separate GateKeeper policy needed.
+
+**Authority rule:** `immutable` prevents overrides from lower-authority domains only. A platform domain `immutable` field blocks tenant/service/provider/request — but system domain can still override. Higher authority always wins.
+
+**GateKeeper escalation:** A GateKeeper policy may additionally lock an `allow` or `constrained` field at runtime — for compliance mandates the layer author didn't anticipate.
+
+**Enforcement:** If a lower-priority layer or consumer sets an `immutable` field → assembly halts with clear error identifying the conflicting layer and locking layer.
+
+LAY-005.
+
+### 38.3 Constraint Schema Visibility (Q52)
+
+Constrained fields expose their constraint schema to consumers in the Service Catalog UI and Consumer API at a policy-governed disclosure level.
+
+**Disclosure levels:** `full` (constraint + bounds + reason + suggestions), `summary` (bounds only), `hidden` (silently enforced)
+
+**Profile defaults:** minimal/dev/standard → full; prod/fsi → summary; sovereign → hidden
+
+**API:** `GET /api/v1/catalog/items/{id}/schema` returns field schemas at the declared visibility level for the authenticated consumer's Tenant profile.
+
+Policy may override per field or resource type.
+
+LAY-006.
+
+### 38.4 Post-Realization Field Editability (Q56)
+
+**Editability is orthogonal to override_preference:**
+- `override` governs assembly time (which layers can set the field during request construction)
+- `editable` governs post-realization (can the consumer update the field on a running resource)
+
+**Declared on Resource Type Specification:**
+```yaml
+fields:
+ cpu_count: editable: true; edit_constraints: {range: 1-32}; requires_restart: true
+ hostname: editable: false; non_editable_reason: "Requires reprovisioning"
+ dns_servers: editable: true; requires_restart: false
+ region: editable: false; non_editable_reason: "Region immutable post-realization"
+```
+
+**Update request flow:** validate editable → validate edit_constraints → evaluate edit_policy → produce delta Requested State → dispatch delta to provider → update Realized State
+
+**Critical:** Updates are targeted deltas — **layers do NOT re-run**. Only changed fields validated and dispatched. Layer chain NOT re-assembled for updates.
+
+Editable fields and edit_constraints visible in Service Catalog at same constraint_visibility level as constraint schemas.
+
+ENT-010.
+
+### 38.5 System Policies
+- `LAY-005` — override: allow/constrained/immutable enforced at Step 3; immutable = lower-authority only; GateKeeper may additionally lock
+- `LAY-006` — constraint schema visible at full/summary/hidden level; profile-governed; API endpoint
+- `ENT-010` — editability first-class on Resource Type Spec; independent of override_preference; updates = targeted deltas; layers do not re-run
+
+---
+
+## SECTION 39 — FOUR STATES OPERATIONAL GAPS
+
+### 39.1 Entity UUID Preservation on Rehydration (Q75)
+
+Entity UUIDs are **preserved on rehydration** — UUID is the stable logical identity across all provider migrations, sovereignty changes, and lifecycle events. All external references (CMDB, cost attribution, audit trails, relationships, dependencies) use UUID. Generating a new UUID would silently break all references.
+
+What changes: the **provider-side identifier** (actual VM ID, container name, resource handle). Recorded in `rehydration_history`:
+```yaml
+entity:
+ uuid: # PRESERVED
+ rehydration_history:
+ - rehydration_uuid:
+ from_realized_entity_id: "vm-12345" # no longer valid
+ to_realized_entity_id: "vm-67890" # new provider ID
+ trigger / from_provider / to_provider / rehydrated_by
+ intent_state_ref / previous_requested_state_ref / new_requested_state_ref
+```
+
+**Rehydration is transactional** — failure preserves pre-rehydration state completely; no UUID change, no partial state. RHY-005.
+
+### 39.2 Pinned Authentication Level for Rehydration (Q76)
+
+Entities may declare `rehydration_constraints.min_auth_level` — a minimum floor the rehydrating actor must meet. Prevents privilege escalation through the rehydration mechanism.
+
+Auth levels (ascending): `api_key → ldap_password → oidc → oidc_mfa → hardware_token → hardware_token_mfa`
+
+**Profile enforcement:** minimal/dev = not enforced; standard = advisory warn; prod = enforced reject; fsi = enforced + dual approval on mismatch; sovereign = dual approval always.
+
+**Automated rehydration** (DCM service account for provider migration): requires `allow_delegated_rehydration: true` OR platform admin manual authorization → full audit trail preserving accountability. RHY-006.
+
+### 39.3 Concurrent Rehydration Handling (Q77)
+
+**Exclusive rehydration lease per entity** — only one rehydration active at a time.
+
+```yaml
+rehydration_lease:
+ entity_uuid / lease_uuid / acquired_by / acquired_at
+ lease_ttl: PT2H # expires if rehydration hangs
+ trigger / status: active|completed|failed|expired
+```
+
+**Concurrent request:**
+- Active lease + higher priority incoming → escalate to platform admin; queue
+- Active lease + same/lower priority → reject with retry guidance; REHYDRATION_BLOCKED audit
+
+**Priority (1=highest):** security/compliance emergency → manual platform admin → automated sovereignty migration → provider decommission → manual consumer request
+
+**TTL expiry:** marks rehydration `failed`; releases lease; triggers drift detection for partial completion assessment. RHY-007.
+
+### 39.4 Discovered State Retention (Q78)
+
+Ephemeral operational data — NOT the source of truth (Realized State is). Three modes:
+
+| Mode | Behavior |
+|------|---------|
+| `rolling_window` | Keep last N days; useful for trending |
+| `event_driven` | Retain until drift_resolved; ensures investigation has snapshot |
+| `hybrid` (recommended) | min_retention + retain_until_drift_resolved + max_retention ceiling |
+
+**Profile defaults:**
+- minimal: rolling P3D
+- dev: rolling P7D
+- standard/prod: hybrid P24-48H min / P30D max
+- fsi/sovereign: hybrid P7D min / P90D max
+
+**Audit relationship:** Discovered State records are NOT in the Audit Store (too high-volume, too ephemeral). Drift events triggered by Discovered State ARE in the Audit Store with discovery snapshot UUID reference. After snapshot expires: audit record preserved; snapshot no longer available. RHY-008.
+
+### 39.5 Complete Rehydration Policy Set
+RHY-001 through RHY-008 — see doc 02.
+
+---
+
+## SECTION 40 — ARCHITECTURE GAPS: CACHE MODEL, INGESTION, DEPLOYMENT
+
+### 40.1 DCM Deployment Topology — Hub/Regional/Sovereign
+
+The Ship/Shore/Enclave terminology from defense IT contexts has been replaced throughout with universally understood terms aligned to DCM's federation model:
+
+| Former Term | Replacement | Meaning |
+|-------------|-------------|---------|
+| Shore | **Cost Analysis Information Provider** | Specialized Information Provider supplying cost estimates, placement cost signals, cost actuals, and budget alerts; DCM provides input data; provider performs calculations |
+| **Orchestration Flow Policy** | Named workflow artifact: Orchestration Flow Policy with `ordered: true`; declares explicit step sequence using payload type vocabulary; first-class Data artifact; versioned, GitOps-managed, profile-bound |
+| **Request Orchestrator** | Runtime event bus; routes lifecycle events to Policy Engine; has no pipeline logic; both named workflows and dynamic policies are evaluated through it |
+| **orchestration (DCM)** | Two-level composable model: Level 1 = named Orchestration Flow Policies (explicit sequence); Level 2 = dynamic policies (conditional, inline); both evaluated by Policy Engine; adding a step = adding to a workflow Policy; adding conditional behavior = writing a dynamic policy |
+| **Provider Catalog Item** | What a specific Service Provider offers consumers: specific resource allocation or process with cost, availability, SLAs; linked to Resource Type Specification version |
+| **cross_tenant_authorization** | DCMGroup with group_class: cross_tenant_authorization; grants one Tenant permission to reference/allocate/stake another Tenant's resources; revocation places active allocations in PENDING_REVIEW |
+| **foundation Tenants** | Three system Tenants created at bootstrap: __platform__, __transitional__, __system__; cannot be decommissioned; declared in bootstrap manifest |
+| **QUOTA_EXCEEDED** | GateKeeper rejection code when resource quota policy fires at Step 5 (pre-placement) |
+| **Federated Contribution Model** | DCM defaults to federated data creation — all authorized actor types (platform admin, consumer/tenant, service provider, peer DCM) can contribute Data artifacts within their domain scope via the GitOps PR model; see doc 28 |
+| **contributor** | Actor type that authored a Data artifact; recorded in artifact_metadata.contributed_by; determines review requirements; platform_admin / consumer / service_provider / peer_dcm |
+| **contributed_by** | Artifact metadata block recording contributor_type, actor UUID, contribution_method, pr_url, reviewed_by; immutable once set |
+| **DPO-001–006** | Design Priority system policies. DPO-001: security properties present in all profiles (not controlled by profiles). DPO-002: every security requirement needs an ease-of-use mechanism. DPO-005: minimal profile = "security with minimal overhead" not "minimal security". DPO-006: when security and ease conflict, redesign ease-of-use, not security. |
+| **FCM-001–008** | Federated Contribution Model system policies; key: FCM-002 (domain scope violations = hard DENY), FCM-003 (GitOps PR for all), FCM-008 (contributor scope limits absolute) |
+| **Unified Governance Matrix** | Single enforcement point for all cross-boundary decisions; four axes (subject/data/target/context); hard vs soft enforcement; field-level granularity (allowlist/blocklist/paths); profile-bound defaults; GMX-001–010 |
+| **governance_matrix_rule** | Artifact declaring match conditions across four axes and a decision (ALLOW/DENY/ALLOW_WITH_CONDITIONS/STRIP_FIELD/REDACT/AUDIT_ONLY) with hard or soft enforcement |
+| **sovereignty_zone** | Registered DCM artifact declaring geopolitical/regulatory boundary; rules reference zones by ID; inter-zone agreements declared explicitly |
+| **STRIP_FIELD** | Governance matrix decision: remove named fields from payload and proceed; if stripped field is required → DENY_REQUEST |
+| **REDACT** | Governance matrix decision: replace field value with ``; field presence preserved; receiver knows field exists but not its value |
+| **Provider Type Registry** | Three-tier registry of approved provider types; each entry declares permissions, default_approval_method, enabled_in_profiles, capability_schema_ref |
+| **registration_token** | Pre-issued by platform admin; scoped to provider_type/handle_pattern/zone; single_use; grants_auto_approval flag; value presented once only |
+| **approval_method** | Registration approval: auto | reviewed | verified | authorized; resolved as most_restrictive(provider_type_default, profile_min, token_effect) |
+| **Drift Reconciliation Component** | Control plane component; compares Discovered vs Realized State; produces drift records and events; never writes to Realized Store; DRC-001–005 |
+| **drift_record** | Artifact produced by Drift Reconciliation; field-by-field comparison result with severity classification; unsanctioned flag; status tracking through resolution |
+| **Placement Engine** | Six-step algorithm: sovereignty filter → accreditation filter → capability filter → reserve query → tie-breaking (policy/priority/affinity/cost/load/hash) → confirm; PLC-001–006 |
+| **reserve_query** | Parallel capacity queries to all eligible provider candidates; PT5M capacity hold; non-responders and insufficient-capacity providers excluded |
+| **consistent hash** | Final placement tie-breaker: SHA-256(request_uuid+resource_type+sorted_candidates); deterministic; never round-robin |
+| **Lifecycle Constraint Enforcer** | Monitors TTL/expiry/max_execution_time; fires expiry actions through standard pipeline; grace period before action; Process Resources: immediate FAILED on breach; LCE-001–005 |
+| **Search Index** | Non-authoritative queryable projection of GitOps stores; indexes key fields; returns git_path for full payload; max staleness PT5M; always rebuildable; SIX-001–004 |
+| **Admin API** | Platform admin REST interface: Tenant lifecycle, provider review, accreditation approval, discovery trigger, orphan resolution, recovery decisions, quota management, Search Index rebuild, bootstrap operations |
+| **PENDING_EXPIRY_ACTION** | Entity state when expiry action fails to execute; Lifecycle Constraint Enforcer retries per Recovery Policy; Platform Admin notified urgency: high |
+| **data_classification** | First-class field metadata: public/internal/confidential/restricted/phi/pci/sovereign/classified; phi/sovereign/classified are immutable once set |
+| **Accreditation** | Formal versioned attestation that a component satisfies a compliance framework; issued by an Accreditor; carries validity period; lifecycle: developing→proposed→active→expired/revoked |
+| **Accreditor** | Entity that issues accreditations: government body, regulatory body, QSA, certification body, or internal audit team |
+| **Accreditation Gap** | Missing, expired, or revoked accreditation required for an active interaction; always high/critical severity; Recovery Policy governs response |
+| **Data/Capability Authorization Matrix** | Policy Group artifact (concern_type: data_authorization_boundary) declaring what data fields and capabilities are permitted across interaction boundaries given data classification and accreditation level |
+| **zero_trust_posture** | Sixth Policy Group concern type; four levels: none/boundary/full/hardware_attested; profile defaults: minimal=none, dev/standard=boundary, prod/fsi=full, sovereign=hardware_attested |
+| **Five-check boundary model** | Identity → Authorization → Accreditation → Matrix → Sovereignty; all five checks at every DCM interaction boundary; all produce audit records |
+| **Federation tunnel** | Mutually authenticated, encrypted, scoped DCM-to-DCM channel; zero trust model; establishes secure transport only, not implicit trust; per-message signing; scoped non-transferable credentials |
+| **hard_constraint** | Data/Capability Matrix declaration that cannot be overridden by any policy; sovereign/classified data never crossing federation boundaries is a hard_constraint |
+| **STRIP_FIELD** | Matrix enforcement action: remove non-permitted field from payload and proceed; if stripped field is required → escalates to DENY_REQUEST |
+| **DENY_REQUEST** | Matrix enforcement action: block entire interaction; entity enters PENDING_REVIEW; notification dispatched |
+| **Request Orchestrator** | DCM control plane event bus; routes lifecycle events to Policy Engine; coordinates pipeline via event-condition-action; does not contain hardcoded pipeline logic |
+| **Cost Analysis Component** | Internal DCM control plane component; three functions: pre-request estimation, placement input, ongoing attribution; not a billing system; not a provider type |
+| **Module** | DCM capability extension adding new functions; distinct from Profile (which configures behavior) |
+| **orchestration_flow** | Policy Group concern_type for static sequential flows; ordered: true; both static and dynamic flows compose through the same Policy Engine |
+| **payload_type** | Closed vocabulary of event types the Request Orchestrator publishes; policies pattern-match on payload type + state |
+| **OPA integration** | Reference implementation for Mode 3 External Policy Evaluators; DCM payload as OPA input document; built-in Rego functions provided by DCM |
+| **Flow GUI** | Visual policy composer and orchestration manager; execution graph view, policy canvas, shadow mode dashboard, flow simulation |
+| **__platform__** | Immutable system Tenant owning DCM control plane resources; created at bootstrap before Policy Engine comes online |
+| **__transitional__** | Immutable system Tenant holding brownfield entities during INGEST phase |
+| **bootstrap manifest** | Signed manifest declaring initial system Tenants, bootstrap admin, and initial profile; hash-verified at every DCM startup |
+| **cross_tenant_authorization** | DCMGroup with this group_class formally grants one Tenant access to another's resources; has lifecycle (duration, renewal, revocation); revocation places active allocations in PENDING_REVIEW |
+| **drift_criticality** | Field-level property in Resource Type Spec (low/medium/high/critical); combined with change magnitude to produce drift severity |
+| **Ingress API** | Infrastructure-layer entry point for all inbound DCM requests; sets ingress block; routes to Consumer/Provider/Admin API surfaces |
+| **Provider Catalog Item** | Provider-specific instantiation of a Resource Type Specification; what consumers actually request; distinct from the Resource Type Specification itself |
+| **Recovery Policy** | Formal DCM policy type mapping trigger conditions (DISPATCH_TIMEOUT, PARTIAL_REALIZATION, etc.) to response actions; same authoring model as GateKeeper/Validation/Transformation |
+| **recovery_posture** | Fifth Policy Group concern_type governing failure and ambiguity response; binds a recovery profile group to the deployment |
+| **DRIFT_RECONCILE** | Recovery action: schedule discovery; let drift detection resolve actual state |
+| **DISCARD_AND_REQUEUE** | Recovery action: best-effort cleanup; new request cycle created immediately |
+| **NOTIFY_AND_WAIT** | Recovery action: notify human; wait for explicit decision up to declared deadline |
+| **TIMEOUT_PENDING** | Infrastructure Resource Entity state: dispatch timeout fired; recovery policy evaluating |
+| **LATE_REALIZATION_PENDING** | Entity state: provider responded after timeout; NOTIFY_AND_WAIT recovery decision pending |
+| **INDETERMINATE_REALIZATION** | Entity state: state ambiguous; drift detection resolving |
+| **COMPENSATION_FAILED** | Entity state: compound service rollback itself failed; orphan detection active |
+| **orphan_candidate** | Resource discovered at provider with no corresponding Realized State record; surfaced to platform admin for human resolution |
+| **Discovery Scheduler** | DCM control plane component maintaining priority queue of discovery requests; dispatches to provider discovery endpoints |
+| **recovery-automated-reconciliation** | Built-in recovery profile: trust drift detection; accept late responses; appropriate for dev/standard |
+| **recovery-notify-and-wait** | Built-in recovery profile: notify human; never act automatically; appropriate for prod/fsi/sovereign |
+| **notification service** | Ninth DCM provider type; translates unified notification envelope to delivery channel; handles delivery, retry, dead letter, and delivery confirmation callbacks |
+| **Notification Router** | DCM control plane component that resolves notification audiences and routes envelopes to notification services |
+| **audience resolution** | Deriving notification recipients by traversing the entity relationship graph from the changed entity at event time |
+| **notification_uuid** | Idempotency key on notification envelopes; notification services use this to deduplicate on retry |
+| **audience_role** | owner / stakeholder / approver / observer — why this actor is in the notification audience |
+| **stakeholder_reason** | Notification envelope field explaining which relationship caused the actor to be in the stakeholder audience |
+| **Tier 1 / Tier 2 / Tier 3 notifications** | Mandatory system (non-suppressable) / Tenant defaults / Actor subscriptions — three subscription tiers that compose |
+| **NOT-001 through NOT-008** | Notification model system policies |
+| **write-once snapshot store** | Realized Store implementation model: each record is a complete immutable entity state snapshot; no event replay; direct point-in-time lookup; supersession chain links snapshots |
+| **corresponding_requested_state_uuid** | Mandatory non-nullable field on every Realized State snapshot; traces every Realized State change to an authorized request |
+| **Provider Update Notification** | Formal API for providers to report authorized state changes; DCM evaluates via Policy Engine; approved → new Requested State + Realized State; rejected → drift event |
+| **notification_uuid** | Idempotency key on Provider Update Notifications; safe to resend on provider crash |
+| **pre-authorized update** | Category of provider update pre-approved by GateKeeper policy; processed automatically without per-change human review |
+| **Whole Allocation** | Ownership pattern: consumer owns the entire resource entity outright in their Tenant; no pool involved |
+| **Allocation** | Ownership pattern: pool yields independently-owned sub-resources; consumer owns their allocation; AllocationRecord relationship links to pool |
+| **Shareable** | Ownership pattern: one resource, multiple stakeholders; consumers hold stakes (relationships) only; no consumer owns any portion |
+| **AllocationRecord** | Cross-tenant relationship from an allocation entity back to its source pool entity |
+| **stake_strength** | Relationship property on shareable resource attachments: required (blocks decommission) / preferred / optional |
+| **PENDING_REVIEW** | Formal Infrastructure Resource Entity lifecycle state for conflicts requiring human resolution (sovereignty, cross-tenant auth revocation, ownership transfer conflicts) |
+| **Consumer API** | DCM REST API for consumers: catalog browsing, request submission, resource management, audit trail access |
+| **Consumer Request Status** | Lifecycle: ACKNOWLEDGED → ASSEMBLING → AWAITING_APPROVAL → APPROVED → DISPATCHED → PROVISIONING → COMPLETED/FAILED/CANCELLED |
+| **01-entity-types.md** | Entity type taxonomy: Infrastructure Resource, Composite Resource, Process Resource; sub-types and invariants |
+| **04-examples.md** | Worked examples: VM end-to-end, IP allocation, VLAN sharing, brownfield ingestion, drift remediation; Git repo structure |
+| **04b-ownership-sharing-allocation.md** | Authoritative ownership model: whole allocation, allocation, shareable; policies OWN-001 through OWN-008 |
+| **federation routing** | Hub DCM applies placement engine logic at the DCM instance level; Regional DCMs are DCM Provider instances; sovereignty is a hard pre-filter; same tie-breaking hierarchy as provider selection |
+| **independent_with_overlap** | Certificate rotation model: old cert valid P30D after new cert issued; allows peers to update trust stores without coordinated downtime |
+| **alert_and_hold** | Federated drift detection response when peer DCM is unavailable: do not assume drift; hold state; escalate to platform admin after PT24H |
+| **AUDIT_STORE_UNAVAILABLE** | Gap record inserted in Audit Store hash chain after recovery from Audit Store failure; timestamps the exact outage window; makes gap explicit and auditable |
+| **confidence aggregation** | Per-entity endpoint computing overall confidence band (= lowest field band); identifies contested and stale fields; computed on demand never stored |
+| **explicit_no_filter** | Composite group declaration suppressing the no member_type filter linting warning; confirms broad targeting is intentional |
+| **certified profile** | DCM profile carrying formal third-party certification metadata (HIPAA assessor, FedRAMP JAB, PCI QSA); promoted to Tier 1; applies to artifact not deployment |
+| **POLICY_PROVIDER_ELEVATED** | Audit action recorded when a External Policy Evaluator's mode level is elevated; always produced regardless of profile |
+| **tier_certifications** | Certification metadata on Resource Type Specs or profiles from recognized certifying bodies; filter criterion, not structural tier boundary |
+| **tier_3_to_tier_2_promotion** | PR-based pathway for organizations to promote internal Tier 3 Resource Types to Verified Community (Tier 2); requires production deployment, OSS license, named maintainer, migration path |
+| **independent operation mode** | Resource Type Registry state when upstream registry is permanently unavailable; existing types continue; new community type adoption requires governance decision |
+| **SCIM 2.0** | System for Cross-domain Identity Management; optional Auth Provider capability for automated actor provisioning from enterprise IdPs; provisions actors and group memberships; roles not SCIM-provisioned |
+| **step-up MFA** | Additional MFA challenge at sensitive operations within an already-authenticated session; declared per operation by policy; step-up token TTL PT10M |
+| **actor.type** | Audit record field: human / service_account / system; enables filtering between human-initiated and automated lifecycle operations in queries and dashboards |
+| **system_actor** | Audit record block on system-initiated records: identifies DCM component, trigger event, and authorizing policy UUID |
+| **Merkle root proof** | Federation-level audit integrity mechanism: Hub DCM computes Merkle root of all Regional DCM chain tips daily; any chain break detectable against stored root |
+| **per-instance hash chain** | Each DCM instance (Hub/Regional/Sovereign) maintains its own independent hash chain; not merged cross-instance; cross-referenced via correlation_id |
+| **AUTH-012 through AUTH-015** | Auth Provider gap policies: SCIM provisioning, failover handling, two-tier MFA, pluggable user store |
+| **AUD-014 through AUD-017** | Universal Audit gap policies: hash chain verification modes, Commit Log capacity, system-initiated records, distributed hash chains |
+| **Hub DCM** | Central/global instance; governance origin; authoritative registry |
+| Ship | **Regional DCM** | Distributed regional instance; manages resources in its region |
+| Enclave | **Sovereign DCM** | Air-gapped/compliance-isolated; signed bundle updates only |
+
+These map directly onto the DCM federation model (DCM-001 through DCM-008, doc 22).
+
+### 40.2 Cache Placement (Q1)
+Caches placed closest to consumption point, subject to sovereignty constraints:
+- **Layer + Catalog caches**: Regional DCM (closest to assembly); Hub DCM is authoritative origin
+- **Information Provider caches**: co-located with source; never cross sovereignty boundary
+- **Search Index**: Hub DCM primary; Regional DCM optional mirror; Sovereign DCM local index
+- **Sovereign DCM caches**: always local static; populated from signed bundles; no live sync
+
+CACHE-001.
+
+### 40.3 Cache Synchronization (Q2)
+**Hybrid push-pull model:** Pull on profile-governed schedule (minimal=P4H through fsi/sovereign=P5M); push invalidation via Message Bus for time-sensitive events (layer_updated, policy_activated, sovereignty_change). Pull failure → serve cached. Push failure → queue+retry within PT1H. Sovereign DCM: signed bundle import only. CACHE-002.
+
+### 40.4 Cache Authoritativeness (Q3)
+GitOps stores and Event Streams always authoritative. Caches are derived projections — never authoritative. Cache divergence → rebuild from nearest authoritative store → CACHE_DIVERGENCE_DETECTED Audit event. Regional DCMs send cache state hash in heartbeats to Hub DCM; mismatch → forced refresh. CACHE-003, CACHE-004.
+
+### 40.5 Native Passthrough (Q5)
+Core data model does not embed technology-specific data. `native_passthrough` field sanctioned for genuinely untranslatable provider-specific data. Always audit-logged (content if transparent; hash if opaque). Opaque passthrough blocked in fsi/sovereign profiles by default. DATA-001.
+
+### 40.6 Physical State Representation (Q6)
+Intent/Requested → YAML in Git. Realized → Event Stream → Realized Store. Discovered → Discovered Store (ephemeral). Resolved by STO-001 through STO-005.
+
+### 40.7 Ingestion Model Gaps
+
+**Signal priority configurable (Q1):** Platform domain layer declares priority order. explicit_tenant_tag always first; default_tenant always last; middle signals reorderable. ING-012.
+
+**Bulk promotion (Q2):** Supported with profile-governed limits (minimal=unlimited → sovereign=25 per batch). Preview required. PT24H rollback. BULK_PROMOTE audit record. ING-013.
+
+**Max ingestion sources per entity (Q3):** Profile-governed (5 standard/prod; 3 fsi/sovereign). Warn or reject on exceed. ING-014.
+
+**Ingestion → Service Catalog (Q4):** Ingested entities promotable to catalog items. Bidirectional drift detection between entity and catalog item. ING-015.
+
+### 40.8 Deployment Redundancy Gaps
+
+**Bootstrap manifest verification (Q1):** GitOps stored + hash-verified at every startup. Tampering prevents startup. Operator-signed. RED-011.
+
+**Sovereign Kubernetes upgrades (Q2):** Pre-staged images via signed bundles. DCM maintenance mode during upgrade. Startup verification before resuming queued requests. RED-012.
+
+**Non-Kubernetes runtimes (Q3):** Kubernetes required for production. Podman/Docker Compose for dev/community only. DCM Operator is Kubernetes-native. RED-013.
+
+**Minimum hardware specs (Q4):** Declared as DCM Resource definitions per profile; enforced by placement engine. minimal=2cpu/4Gi/20Gi/1 replica → fsi/sovereign=32cpu/64Gi/500Gi/5 replicas. RED-014.
+
+**DCM self-hosted drift detection (Q5):** DCM is a DCM-managed resource — same drift detection. Bootstrap hash provides independent Operator verification. Audit hash chain breaks externally detectable. RED-015.
+
+---
+
+## SECTION 41 — SECURITY, AUTH, AND AUDIT REFINEMENTS
+
+### 41.1 SCIM 2.0 User Provisioning (Auth Q1)
+
+SCIM 2.0 is an optional Auth Provider capability for enterprise deployments. Automates actor lifecycle from enterprise IdPs (Okta, Azure AD, Ping, JumpCloud).
+
+**What SCIM manages:** DCM actor records (create/update/deactivate), DCM group memberships from IdP groups.
+
+**What SCIM does NOT manage:** Roles — they require explicit DCM policy authorization. This prevents privilege escalation through the SCIM channel.
+
+**Deprovisioning:** `suspend` by default (reversible; sessions terminated; leases released; in-flight requests complete first). AUTH-012.
+
+### 41.2 Auth Provider Failover — In-Flight Requests (Auth Q2)
+
+**In-flight requests (already authenticated):** Continue to completion — session token carries resolved roles/groups/tenant scope; Auth Provider not needed for assembly.
+
+**New requests, provider down:** Follow declared failover chain. Sessions valid for declared TTL (PT8H default) regardless of provider availability.
+
+**Session expiry during outage:** Requires re-auth via available failover provider. All providers unavailable → reject new authentication with clear error.
+
+Failover chain: primary LDAP → OIDC backup → local users (last resort). AUTH-013.
+
+### 41.3 Two-Tier MFA — Per-Session and Step-Up (Auth Q3)
+
+**Per-session MFA:** Validated at login; captured in `ingress.actor.mfa_verified`.
+
+**Step-up MFA:** Additional challenge at sensitive operations even within a valid MFA session. Policy declares which operations require step-up:
+- platform_policy_activate, provider_decommission, tenant_decommission
+- sovereignty_zone_change, auth_provider_update, manual_rehydration (if entity requires hardware_token_mfa)
+
+Step-up token TTL: PT10M. Profile defaults: minimal/dev = no MFA; standard = recommended; prod = per-session required + destructive ops step-up; fsi = per-session + all policy changes; sovereign = hardware token + all admin ops. AUTH-014.
+
+### 41.4 Built-In Auth Provider Storage Backend (Auth Q4)
+
+Pluggable storage backend following the data store model. SQLite (minimal/dev) → PostgreSQL (standard+). FSI/sovereign require encryption at rest. Local store should contain bootstrap users, service accounts, API keys only — not enterprise users. AUTH-015.
+
+### 41.5 Hash Chain Verification Modes (Audit Q1)
+
+Three independent levels:
+- **Continuous write:** Hash computed on every write — this IS chain construction; always active
+- **Scheduled sweep:** Background verification: standard=weekly, prod=daily, fsi/sovereign=every 6 hours
+- **On-demand:** Operator-triggered for any time range (max P365D per run)
+
+Failure: security alert + integrity incident; new writes continue (halting writes is itself a security risk). AUD-014.
+
+### 41.6 Commit Log Capacity and Overflow (Audit Q2)
+
+Configurable max capacity (default 10Gi) with declared overflow policy:
+- `alert_and_continue` (minimal/dev/standard/prod) — availability priority
+- `reject_new_ops` (fsi/sovereign) — audit completeness priority; operating unaudited is a compliance violation
+
+Backpressure: alert at 75%, urgent at 90%. P7D max age triggers escalation regardless of capacity. AUD-015.
+
+### 41.7 System-Initiated Audit Records (Audit Q3)
+
+`actor.type` field on all audit records: `human | service_account | system`
+
+System records include `system_actor` block: component + trigger + authorizing_policy_uuid. Full audit records — appear in all queries and compliance reports. Enables dashboard filtering: "show only human-initiated changes" vs "show only automated lifecycle operations". AUD-016.
+
+### 41.8 Distributed Hash Chain Integrity (Audit Q4)
+
+Per-instance hash chains — each DCM instance (Hub, Regional, Sovereign) has its own independent chain. Federation-level integrity via daily Merkle root proof at Hub DCM. Cross-instance queries: parallel chains with cross-references via `correlation_id` — not merged. Per-instance verification always local; federation verification requires Hub DCM connectivity. AUD-017.
+
+---
+
+## SECTION 42 — POLICY AND REGISTRY REFINEMENTS
+
+### 42.1 Community Profile and Group Submissions (Policy Q1)
+
+Organizations submit custom profiles and policy groups to the DCM community registry via same PR-based workflow as Resource Types — Tier 2. Requirements: documented use case, at least one production deployment reference, test results, named maintainer. Same lifecycle as Resource Types (shadow validation before active, deprecation, sunset). PROF-005.
+
+### 42.2 Certified Profile Program (Policy Q2)
+
+Certified profiles carry third-party certification metadata (HIPAA assessor, FedRAMP JAB, PCI QSA). Certified profiles promoted to Tier 1 (DCM Core). Certification applies to the profile artifact only — not to any specific deployment. Community-contributed Tier 2 profiles that obtain certification can be promoted to Tier 1. PROF-006.
+
+### 42.3 External Policy Evaluator Trust Elevation Approval (Policy Q3)
+
+Trust elevation (increasing mode level) requires formal approval workflow. Profile-governed approver requirements:
+- standard: 1 platform_admin
+- prod: platform_admin + security_owner (min 2)
+- fsi: platform_admin + security_owner + compliance_officer (dual approval)
+- sovereign: 3 approvers + change control ticket
+
+P7D shadow period after elevation before outputs become binding. POLICY_PROVIDER_ELEVATED audit record. PROF-007.
+
+### 42.4 Dev Profile Resource TTL Configurability (Policy Q4)
+
+Default TTL declared in system domain layer; overridable at platform domain level. Per-resource-type overrides supported (VMs: P7D, Storage: P14D, DNS: P3D). on_expiry action configurable: notify (consumers can extend) vs destroy. PROF-008.
+
+### 42.5 Air-Gapped External Policy Evaluator Delivery (Policy Q5)
+
+Signed bundle model — same as registry bundles. Mode 3 bundles include OPA Rego files. Mode 4 in sovereign profiles: endpoint must be within sovereignty boundary — external AI service calls blocked by BBQ-001 sovereignty check. PROF-009.
+
+### 42.6 No Fourth Registry Tier (Registry Q1)
+
+Certification metadata within existing tier structure — no structural fourth tier. filter: tier_certifications provides equivalent discovery. REG-008.
+
+### 42.7 Tier 3 to Tier 2 Promotion (Registry Q2)
+
+PR-based promotion pathway with additional requirements: production deployment + OSS-compatible license + named community maintainer + documented migration path from Tier 3 handle. Current Tier 3 users notified. REG-009.
+
+### 42.8 Upstream Registry Permanently Unavailable (Registry Q3)
+
+Organization Registry mirror is self-sufficient — upstream loss is a governance decision, not an operational crisis. Three options: designate community mirror as new upstream / fork the registry / continue as independent installation. Existing operations never interrupted. REG-010.
+
+### 42.9 Provider Cost Metadata Source (Registry Q4)
+
+Static declaration or dynamic Cost Analysis sourcing; hybrid recommended (Cost Analysis preferred, static fallback, fallback_max_age: PT24H). Placement engine cost analysis step uses freshest available source — no changes to tie-breaking model. REG-011.
+
+---
+
+## SECTION 43 — FEDERATION, OBSERVABILITY, AND FINAL REFINEMENTS
+
+### 43.1 DCM-to-DCM Certificate Rotation (Federation Q1)
+
+Independent rotation per instance with P30D overlap period. Peers notified via Message Bus 60 days before expiry. Automatic renewal triggers 90 days before expiry. Overlap allows peers to update trust stores without coordinated downtime. DCM-009.
+
+### 43.2 Federation Routing — Full Placement Engine at DCM Level (Federation Q2 — Extended)
+
+**Hub DCM federation routing follows the same placement engine logic as provider selection.** Regional DCMs are treated as DCM Provider instances.
+
+**Sovereignty is a hard pre-filter — not a tie-breaker:**
+- Filter eligible Regional DCMs by sovereignty compatibility before the placement loop
+- No eligible Regional DCMs after filter → reject with clear error
+
+**Tie-breaking hierarchy at the DCM instance level (same as provider selection):**
+1. Policy preference (policy declares preferred Regional DCM)
+2. Federation priority (numeric priority on DCM Provider registration)
+3. Tenant affinity (Tenant's resources prefer a specific Regional DCM)
+4. Sovereignty match quality (exact over partial match)
+5. Geographic affinity (closest regional to consumer)
+6. Least loaded (capacity utilization)
+7. Consistent hash (deterministic tiebreaker)
+
+**Sub-regional routing:** Regional DCM acts as Hub for its children — same logic recursive within federation depth limit. Load balancing is step 6 (least loaded) — not a primary strategy.
+
+DCM-010.
+
+### 43.3 Federated Drift Detection Ownership (Federation Q3)
+
+Provider-side DCM discovers; consumer-side DCM compares against its Requested State. Discovered State events published via federation Message Bus with correlation_id + consumer_dcm_uuid tag. Peer DCM unavailable = alert-and-hold (not assumed drift); max hold PT24H then escalate. DCM-011.
+
+### 43.4 Cross-DCM Audit Correlation (Federation Q4)
+
+No full synchronization. correlation_id reference model — each DCM keeps its own authoritative audit trail. On-demand pull for compliance investigations requires platform admin auth + sovereignty check + peer DCM authorization. DCM-012.
+
+### 43.5 Maximum Federation Depth (Federation Q5)
+
+Profile-governed: minimal/dev=5, standard/prod=3, fsi/sovereign=2. Measured as hops from deepest instance to Hub DCM. Depth 3 covers Hub → Regional → Sub-Regional → Edge. DCM-013.
+
+### 43.6 Audit Provenance Scattered Resolutions
+
+- **Q1 (Audit Store architecture):** Already resolved as STO-004 — specialized PostgreSQL store contract; see doc 11.
+- **Q2 (Air-gapped replication):** Live sync for Regional DCMs; signed bundle export for Sovereign DCMs; sovereignty check required; hash chain preserved; AUD-018.
+- **Q3 (Default dashboard):** Grafana bundled for minimal/dev/standard; enterprise integration recommended for prod; required for fsi; local-only for sovereign; OBS-002.
+- **Q4 (Failing Data Store):** Two-stage model handles it — Commit Log (etcd) independent of data stores; AUDIT_STORE_UNAVAILABLE gap record on recovery; hash chain makes gap explicit; AUD-019.
+
+### 43.7 Universal Groups — Composite Linting (Q1)
+
+Linting warning (not error) when composite group policy targeting has no member_type filter. Operator may suppress with explicit_no_filter: true. GRP-016.
+
+### 43.8 Information Provider — Confidence Aggregation (Q2) and Override Notifications (Q3)
+
+**Confidence aggregation API:** GET /api/v1/entities/{uuid}/confidence — overall band = lowest field band (conservative); computed on demand; identifies contested and stale fields. INF-010.
+
+**Override notifications:** Provider opt-in via conflict_notification in registration; webhook or Message Bus; overriding value may be redacted by policy for confidentiality. INF-011.
+
+---
+
+## SECTION 44 — FOUNDATIONAL CAPABILITIES MATRIX
+
+### 44.1 Overview
+
+DCM has 95 foundational capabilities across 15 domains. Each capability has a unique ID (domain prefix + sequence number), three perspectives (Consumer, Producer, Platform/Admin), and declared dependencies. This matrix drives Jira ticket creation and implementation planning.
+
+### 44.2 Minimum Viable Capability Set (21 capabilities for end-to-end demo)
+
+IAM-001 → IAM-002 → IAM-003 → IAM-007 → CAT-001 → REQ-001 → REQ-002 → REQ-003 → REQ-004 → REQ-005 → REQ-006 → REQ-007 → PRV-001 → PRV-002 → PRV-003 → PRV-004 → PRV-005 → LCM-001 → DRF-001 → DRF-002 → AUD-001
+
+### 44.3 Domain Summary
+
+| Prefix | Domain | Count |
+|--------|--------|-------|
+| IAM | Identity and Access Management | 7 |
+| CAT | Service Catalog | 7 |
+| REQ | Request Lifecycle Management | 10 |
+| PRV | Provider Contract and Realization | 9 |
+| LCM | Resource Lifecycle Management | 7 |
+| DRF | Drift Detection and Remediation | 5 |
+| POL | Policy Management | 7 |
+| LAY | Data Layer Management | 5 |
+| INF | Information and Data Integration | 6 |
+| ING | Ingestion and Brownfield Management | 4 |
+| AUD | Audit and Compliance | 5 |
+| OBS | Observability and Operations | 5 |
+| STO | Storage and State Management | 6 |
+| FED | DCM Federation and Multi-Instance | 5 |
+| GOV | Platform Governance and Administration | 7 |
+| **Total** | | **95** |
+
+### 44.4 Perspectives
+
+- **Consumer** — what the end user / application team experiences or can do
+- **Producer** — what the Service Provider or platform component must implement
+- **Platform/Admin** — what the platform engineer or SRE must configure or operate
+
+Empty perspective = that capability does not have a direct touchpoint for that role.
+
+### 44.5 Key Dependency Chain
+
+```
+IAM-001 (Auth) → IAM-003 (RBAC) → CAT-001 (Catalog) → REQ-001 (Submit)
+ → REQ-003 (Layers) → REQ-004 (Policy) → REQ-005 (Placement) → REQ-007 (Dispatch)
+ → PRV-001 (Provider Reg) → PRV-003 (Realization) → PRV-005 (Realized State)
+ → LCM-001 (State Transitions) → DRF-001 (Discovery) → DRF-002 (Drift)
+```
+
+### 44.6 Resources
+- Interactive map: DCM-Capabilities-Map.html
+- CSV for Jira import: DCM-Capabilities-Matrix.csv
+- Markdown reference: DCM-Capabilities-Matrix.md
+- Taxonomy: DCM-Taxonomy.md
+
+---
+
+## SECTION 45 — DCM TAXONOMY
+
+The DCM Taxonomy is the authoritative vocabulary for all DCM work — code, documentation, Jira tickets, design discussions. Four parts:
+
+### 45.1 Core Vocabulary (key terms)
+- **Service Provider** — provisions/configures/manages infrastructure; implements naturalization, realization, denaturalization, capacity reporting, sovereignty maintenance. *NOT "producer."*
+- **Hub DCM** — central/global instance; authoritative registry origin. *NOT "Shore."*
+- **Regional DCM** — distributed regional instance; treated as DCM Provider by Hub placement engine. *NOT "Ship."*
+- **Sovereign DCM** — air-gapped/compliance-isolated; signed bundle updates only. *NOT "Enclave."*
+- **Layer** — passive data (what values should fields have); distinct from Policy (executable logic)
+- **Policy** — executable rule evaluating assembled payload; distinct from Layer
+- **Confidence Descriptor** — primary data model for Information Provider confidence: authority_level + corroboration + source_trust + last_updated_at (stored); score + band derived at query time
+- **Rehydration** — replaying Intent State to new provider; UUID always preserved
+- **Targeted Delta** — post-realization field update; does not re-run layer assembly chain
+- **Fulfillment** — complete process from consumer submission to Service Provider realization
+- **Reserve Query** — placement engine asking providers "can you fulfill this right now?"
+
+### 45.2 Anti-Vocabulary (terms to avoid)
+| Avoid | Use Instead |
+|-------|-------------|
+| Producer | **Service Provider** |
+| Shore / Ship / Enclave | **Hub DCM** / **Regional DCM** / **Sovereign DCM** |
+| Realize / Realization | **Provision** / **Install** / **Fulfill** |
+| Widgets | Specific resource type name |
+| Data Center | **Region** / **Zone** |
+| User (generic) | **Developer**, **Application Owner**, **Platform Engineer** |
+| Service (unqualified) | **Catalog Item** / **Resource Type** / **Service Provider** |
+| Manage (unqualified) | **Provision** / **Configure** / **Monitor** / **Decommission** |
+
+### 45.3 Roles and Personas
+Developer/Application Owner (consumer), Platform Engineer (platform ops), Policy Owner (governance), Platform Admin (highest-privilege ops), SRE (operational health), Tenant Admin (tenant management), Service Provider Team (provider integration).
+
+### 45.4 Capability Domain Prefixes
+IAM, CAT, REQ, PRV, LCM, DRF, POL, LAY, INF, ING, AUD, OBS, STO, FED, GOV — see Section 44.
+
+---
+
+## SECTION 46 — GROUP 1: MISSING DOCUMENTS
+
+### 46.1 01-entity-types.md — Entity Types Taxonomy
+
+Three primary entity types in DCM:
+
+**Infrastructure Resource Entity** — persistent, full lifecycle (REQUESTED → PENDING → PROVISIONING → REALIZED → OPERATIONAL → SUSPENDED → DECOMMISSIONED). Owned by exactly one Tenant. Drift detection active. TTL management. `PENDING_REVIEW` is a valid state for sovereignty/tenancy conflicts during rehydration — not an error state; requires human resolution.
+
+**Composite Resource Entity** — Meta Provider composition of multiple Infrastructure Resource Entities. Owns its UUID; constituents own theirs. `lifecycle_state` reflects aggregate health — OPERATIONAL only when all required constituents OPERATIONAL. Two-level drift detection (composite + constituent). Staged decommission (composite first, then constituents in reverse dependency order). `composition_visibility: opaque|transparent|selective`.
+
+**Process Resource Entity** — ephemeral execution (automation jobs, playbooks, pipelines). Short lifecycle (REQUESTED → INITIATED → EXECUTING → terminal). No SUSPENDED state. No PENDING_REVIEW. `max_execution_time` mandatory — no default. Must record `affected_entity_uuids` if any infrastructure modifications made.
+
+Entity sub-types: Shared Resource Entity (`ownership_model: shareable`), Allocatable Pool Resource (pool entity), Allocation entity (`ownership_model: allocation`).
+
+Entity identity invariants: UUID never changes (including rehydration); single Tenant ownership always; provider entity ID is separate from DCM UUID; audit records preserved per retention policy.
+
+### 46.2 04b-ownership-sharing-allocation.md — Ownership, Sharing, and Allocation
+
+**The three ownership patterns — use these terms precisely:**
+
+**Whole Allocation** — consumer receives entire resource entity; owns it outright in their Tenant; no pool involved; full lifecycle control; decommission is straightforward.
+
+**Allocation** — pool resource (owned by platform Tenant) yields new independently-owned sub-resources. Consumer owns their allocation outright. AllocationRecord relationship links allocation → pool. Decommissioning the allocation releases it back to the pool. Pool entity unaffected. Example: IPAddressPool → IPAddress entities.
+
+**Shareable** — single resource owned by one Tenant; multiple consumers hold stakes (relationships) but own nothing. No new entity created per consumer. Decommission deferred while required stakes active. Consumer holds an `attached_to` or `depends_on` relationship with declared `stake_strength: required|preferred|optional`. Example: VLAN shared by multiple VMs.
+
+**Critical distinction:** Shareable = one resource, multiple stake-holders. Allocation = one pool, multiple independently-owned sub-resources. Never confuse these.
+
+Hybrid case: an allocation from a shareable pool. Consumer owns their /28 subnet (allocation). The parent /16 is shareable (NetworkOps owns it, multiple /28s have stakes in it).
+
+OWN-001 through OWN-008 policies govern these patterns.
+
+### 46.3 04-examples.md — Worked Examples and Git Repository Structure
+
+**Git repository structure (resolves Q54 deferred item):**
+- Intent Store: `intent-store/{tenant-uuid}/{resource-type-category}/{resource-type}/{entity-uuid}/intent.yaml`
+- Requested Store: `requested-store/{tenant-uuid}/{resource-type-category}/{resource-type}/{entity-uuid}/` with: `requested.yaml`, `assembly-provenance.yaml`, `placement.yaml`, `dependencies.yaml`
+- Provider selection is in `placement.yaml` — not encoded in directory structure (Q54 resolved)
+
+**Five worked examples:**
+1. VM provision end-to-end (layer assembly, policy evaluation, placement, all four states)
+2. IP Address allocation (pool → consumer-owned allocation entity, AllocationRecord relationship)
+3. VLAN attachment (shareable ownership — stake relationship, decommission deferral)
+4. Brownfield ingestion (INGEST → ENRICH → PROMOTE with CMDB Information Provider)
+5. Drift detection and remediation (unsanctioned memory change, severity, ESCALATE, UPDATE_DEFINITION resolution)
+
+### 46.4 consumer-api-spec.md — Consumer API Specification
+
+Consumer API base URL: `/api/v1/`. Three ingress surfaces: REST API (this spec), Web UI, Git PR.
+
+**Authentication:** Bearer token from `/api/v1/auth/token`. Tenant context via `X-DCM-Tenant` header — always required when actor has multiple Tenants. Step-up MFA via `X-DCM-StepUp-Token` for sensitive operations.
+
+**Service Catalog:** `GET /api/v1/catalog` (list, filtered by RBAC), `GET /api/v1/catalog/{uuid}` (describe with full schema, constraints, cost estimate), `GET /api/v1/catalog/search`.
+
+**Request submission:** `POST /api/v1/requests` → 202 with entity_uuid and status_url. Consumer request status lifecycle: ACKNOWLEDGED → ASSEMBLING → AWAITING_APPROVAL → APPROVED → DISPATCHED → PROVISIONING → COMPLETED|FAILED|CANCELLED. `DELETE /api/v1/requests/{uuid}` for cancellation (only before PROVISIONING).
+
+**Resource management:** `GET /api/v1/resources` (list), `GET /api/v1/resources/{uuid}` (describe with confidence scores, drift status, editable flags), `PATCH /api/v1/resources/{uuid}` (targeted delta for editable fields), `POST /suspend`, `DELETE` (decommission with deferred response if stakes active), `POST /rehydrate`.
+
+**Audit:** `GET /api/v1/resources/{uuid}/audit` with chain_integrity field, `GET /api/v1/audit/correlation/{id}` for cross-state timeline.
+
+Three conformance levels: Level 1 (read-only), Level 2 (standard), Level 3 (full including rehydration and audit).
+
+### 46.5 Context-and-Purpose Fix
+
+Section 5 subsections were incorrectly numbered 3.1/3.2/3.3 — corrected to 5.1/5.2/5.3. Q6 garbled row in open questions table — corrected.
+
+### 46.6 Q54 Resolution
+
+Git repository structure is independent of provider selection. Provider selection is stored in `placement.yaml` within the entity's directory. The deferred note in the four states doc has been updated to reference the worked examples document for the complete layout.
+
+---
+
+## SECTION 47 — STORE ARCHITECTURE: INTENT, REQUESTED, REALIZED, DISCOVERED
+
+### 47.1 The Four Stores — Corrected Model
+
+| Store | Type | Implementation | Why |
+|-------|------|---------------|-----|
+| Intent | GitOps (required) | GitHub/GitLab/Gitea | PR workflow is first-class feature, not implementation detail |
+| Requested | Write-once store (PostgreSQL) | GitOps (reference); PostgreSQL (production scale) | Machine-generated; no PR benefit; Git degrades at scale |
+| Realized | Write-once Snapshot Store | PostgreSQL; CockroachDB | Snapshot-based (not event stream); request-traceable only |
+| Discovered | Ephemeral Snapshot Stream | Kafka; EventStoreDB | High-frequency; never a rehydration source; ephemeral |
+
+**Intent Store must be GitOps** — the PR workflow, branch-per-request, and human review are architectural features.
+
+**Requested Store should NOT be GitOps at production scale** — Git throughput degrades under high-frequency machine writes; PR mechanics add latency with no benefit for machine-generated content. Write-once document store with hash-chain integrity satisfies the contract.
+
+**Realized Store is NOT an event stream** — it is a write-once snapshot store. Each record is a complete entity state, not a field-level event. This makes rehydration a direct lookup (not a replay) and makes point-in-time queries trivial.
+
+**Discovered Store remains an event stream** — high-frequency, machine-generated, ephemeral; never a rehydration source.
+
+### 47.2 The Fundamental Realized Store Constraint
+
+> **Realized State only changes when an authorized request produces a corresponding Requested State record. No exceptions.**
+
+Three write sources — all require `corresponding_requested_state_uuid` (non-nullable):
+1. `initial_realization` — provider confirms first provisioning
+2. `consumer_update` — consumer targeted delta approved and confirmed
+3. `provider_update` — DCM approves a Provider Update Notification
+
+**What does NOT write to Realized Store:**
+- Drift detection (reads only)
+- Discovery cycles (writes to Discovered Store only)
+- Unsanctioned provider changes (become drift events)
+- Direct admin writes (bypassing the request pipeline is forbidden)
+
+**Drift is always unsanctioned** — there are no "legitimate drift events." Every authorized change goes through a request and produces a Requested State record. If Discovered State differs from Realized State without a corresponding Requested State record, it is drift.
+
+### 47.3 Provider Update Notification
+
+Formal mechanism for providers to report authorized state changes (auto-scaling, auto-healing, maintenance). Not drift — the provider is asserting the change was authorized.
+
+**DCM processing pipeline:**
+```
+Provider submits POST /api/v1/provider/entities/{uuid}/update-notification
+ → Authentication (provider mTLS)
+ → Policy Engine evaluates (pre-authorized? requires consumer approval?)
+ → APPROVED: create provider_update Requested State → write Realized State snapshot
+ → REQUIRES_APPROVAL: entity enters PENDING_REVIEW; consumer notified
+ → REJECTED: Realized State unchanged; discrepancy becomes drift
+```
+
+**Pre-authorization:** Providers declare update capabilities at registration. Organizations pre-authorize categories of updates via GateKeeper policy (e.g., auto-scale within 2× bounds). Pre-authorized updates are processed automatically.
+
+**Consumer approval API:** `GET /api/v1/resources/{uuid}/provider-notifications` and `POST /approve` or `/reject`. On approval → new Requested State + Realized State. On rejection → drift event.
+
+**Idempotency:** `notification_uuid` is the idempotency key. Safe to resend on provider crash.
+
+**Level 2 conformance requirement** in the Operator Interface Specification for providers implementing auto-scaling, auto-healing, or provider-side maintenance.
+
+### 47.4 Realized State Snapshot Structure
+
+```yaml
+realized_state_snapshot:
+ realized_state_uuid:
+ entity_uuid:
+ realized_at:
+ source_type: initial_realization | consumer_update | provider_update
+ corresponding_requested_state_uuid: # mandatory, not nullable
+ supersedes_realized_state_uuid:
+ superseded_by_realized_state_uuid:
+ fields: { # complete entity state }
+```
+
+### 47.5 Rehydration from Realized State
+
+Rehydration picks a specific snapshot — direct lookup by `realized_state_uuid` or by timestamp. Not a replay. Not a projection. A complete entity state that was explicitly authorized through DCM's governance pipeline. The supersession chain enables historical rehydration ("rehydrate as of March 15").
+
+### 47.6 New Policies
+
+- `STO-007`: Realized Store is write-once snapshot; every write requires non-nullable `corresponding_requested_state_uuid`; enforcement at store API level
+- `STO-008`: Intent Store requires GitOps; Requested Store requires write-once semantics (GitOps reference impl; write-once document stores supported at scale)
+- `RSE-010`: Realized State only changes via authorized request; drift detection never writes to Realized Store
+- `RSE-011`: Provider Update Notifications evaluated by Policy Engine before any Realized State change
+- `RSE-012`: Categories of provider updates may be pre-authorized via GateKeeper policy
+- `RSE-013`: Provider updates requiring consumer approval place entity in PENDING_REVIEW
+
+---
+
+## SECTION 48 — NOTIFICATION MODEL
+
+### 48.1 Core Principle: Relationship Graph Determines Audience
+
+The audience for every notification is derived from the **entity relationship graph at event time** — not from a manually maintained subscriber list. When VLAN-100 is decommissioned, every VM attached to it gets notified automatically through their relationship edges. No subscription management required.
+
+### 48.2 notification service — Ninth Provider Type
+
+| # | Type |
+|---|------|
+| 1-8 | (existing providers) |
+| **9** | **notification service** — translates DCM unified envelope to delivery channel (Slack, PagerDuty, email, ServiceNow, webhook, SMS); handles delivery, retry, dead letter; reports delivery status back to DCM |
+
+notification services register with DCM declaring supported channels, sovereignty, and delivery guarantees. Organizations configure which channel to use per subscription.
+
+### 48.3 Three Subscription Tiers
+
+**Tier 1 — Mandatory system notifications (non-suppressable):** Security events, sovereignty violations, audit chain breaks. Always delivered to Security Team + Platform Admin. Cannot be filtered.
+
+**Tier 2 — Tenant defaults:** Tenant admin configures baseline for all resources in Tenant — which event categories fire, which channels, urgency routing.
+
+**Tier 3 — Actor subscriptions:** Individual actors subscribe to specific events on specific resources or resource types.
+
+Tiers compose: Tier 1 always fires; Tier 2 applies to all Tenant resources; Tier 3 adds specifics. Actor subscriptions can add channels but cannot suppress Tier 1.
+
+### 48.4 Audience Resolution Algorithm (6 steps)
+
+1. Direct owner of changed entity (role: owner)
+2. Traverse relationship graph — for each relationship: check event relevance, check min stake_strength, resolve related entity's owner (role: stakeholder)
+3. Approval requirements — add approvers (role: approver)
+4. Mandatory system audiences (Security Team, Platform Admin for security events)
+5. Actor subscription overrides (can add; cannot remove mandatory)
+6. Deduplicate; same actor via multiple paths → one notification with all roles listed
+
+### 48.5 Event Taxonomy (closed vocabulary — 7 categories)
+
+1. **Request lifecycle:** acknowledged, requires_approval, approved, dispatched, completed, failed, cancelled, gatekeeper_rejected
+2. **Resource lifecycle:** realized, state_changed, ttl_warning, ttl_expired, suspended, resumed, decommissioning, decommissioned, decommission_deferred, ownership_transferred, pending_review
+3. **Drift and discovery:** drift.detected, drift.severity_escalated, drift.resolved, drift.escalated, unsanctioned_change.detected
+4. **Provider update:** submitted, requires_approval, approved, rejected, auto_approved
+5. **Dependency and relationship:** dependency.state_changed, stakeholder.resource_decommissioning, allocation.pool_capacity_low, cross_tenant_auth.revoked
+6. **Governance:** policy.activated, external_policy_evaluator.trust_elevated, profile.changed, catalog_item.deprecated
+7. **Security/system (mandatory):** audit.chain_integrity_alert, sovereignty.violation, federation.tunnel_degraded, security.unsanctioned_provider_write
+
+### 48.6 Notification Envelope (unified — all channels)
+
+Key fields: notification_uuid (idempotency), correlation_id (links to audit record), event_type, urgency (critical/high/medium/low), entity info, audience role + stakeholder_reason (WHY this actor is in audience), context (previous/new state, changed_fields), action (type/url/deadline for approvals), deep links.
+
+### 48.7 Provider Update + Notifications Integration
+
+`provider_update.requires_approval` fires → consumer receives notification with `action.type: approve`, `action.deadline` (default PT24H). Approved → `provider_update.approved` + `entity.state_changed` to stakeholders. Rejected → `provider_update.rejected` + drift event.
+
+### 48.8 Webhooks Are Now a Notification Channel
+
+Outbound webhooks (doc 18) are superseded by the Notification Model. Webhooks are one channel type within a notification service. Existing webhook registrations are auto-converted to actor-level subscriptions with a webhook-type notification service — no migration needed.
+
+### 48.9 Delivery Pipeline
+
+Event → Audit record → Notification Router resolves audience → Subscription resolution → Envelope generation per actor → Route to notification service(s) → Provider delivers → Delivery confirmation → NOTIFICATION_DISPATCHED audit record.
+
+### 48.10 Policies
+
+NOT-001 through NOT-008. Key: audience derived from relationship graph (NOT-001); mandatory notifications never suppressable (NOT-002); cross-tenant notifications sovereignty-checked (NOT-003); every dispatch is audited (NOT-004); notification service must be registered for external delivery (NOT-007); event taxonomy is closed vocabulary (NOT-008).
+
+REL-022 through REL-024: traversal depth declared in Resource Type Spec; default depth 1; sovereignty respected; same actor via multiple paths → one notification with all roles.
+
+---
+
+## SECTION 49 — GROUP 2: OPERATIONAL MODELS
+
+### 49.1 Three Timeout Scopes
+
+All three independently configurable and audited:
+- **Assembly timeout** — max time for Request Payload Processor nine-step assembly (standard: PT3M; prod: PT2M)
+- **Dispatch timeout** — max time waiting for provider realization after dispatch (standard/prod: PT30M-PT1H; resource-type overrides for legitimately long types)
+- **Reserve-query timeout** — max time for a single provider to respond to reserve query (prod: PT5S); on timeout: skip that candidate, continue placement loop
+
+### 49.2 Cancellation — Three Scenarios
+
+1. **Before dispatch:** Clean cancel; no provider interaction; entity → CANCELLED
+2. **After dispatch, provider not started:** DCM sends cancellation; provider confirms; entity → CANCELLED
+3. **During PROVISIONING:** Provider capability-dependent:
+ - Supports cancellation: send cancel; provider attempts rollback; outcome → Recovery Policy
+ - No cancellation support: CANCEL_PENDING; wait for completion; LATE_RESPONSE_RECEIVED fires
+
+Cancellation is always best-effort — never guaranteed. Provider declares `supports_cancellation` and `partial_rollback_possible` at registration.
+
+### 49.3 Discovery Scheduling — Three Trigger Types
+
+1. **Scheduled (cron):** Each Resource Type Spec declares discovery interval; profile overrides; profile_min=PT4H minimal, PT5M fsi/sovereign
+2. **Event-triggered:** After entity.realized (PT30S delay), drift.resolved (PT60S), provider.degraded (immediate), TIMEOUT_PENDING (PT5M orphan detection), COMPENSATION_FAILED (immediate)
+3. **On-demand:** `POST /api/v1/admin/discovery/trigger` by platform admin; also used by CI/CD pre-validation and brownfield ingestion
+
+Discovery Scheduler component maintains priority queue (Critical → High → Standard → Background). Queue depth bounded per profile.
+
+### 49.4 Recovery Policy Model — The Unified Framework
+
+Recovery Policies are a formal DCM policy type (alongside GateKeeper, Validation, Transformation). Same authoring, GitOps store, shadow mode, activation workflow, and audit trail.
+
+**Trigger vocabulary (closed):** ASSEMBLY_TIMEOUT, DISPATCH_TIMEOUT, RESERVE_QUERY_ALL_EXHAUSTED, LATE_RESPONSE_RECEIVED, CANCELLATION_SENT, CANCELLATION_CONFIRMED, CANCELLATION_FAILED, PARTIAL_REALIZATION, COMPENSATION_IN_PROGRESS, COMPENSATION_FAILED
+
+**Action vocabulary (closed):** DRIFT_RECONCILE, DISCARD_AND_REQUEUE, DISCARD_NO_REQUEUE, ACCEPT_LATE_REALIZATION, COMPENSATE_AND_FAIL, NOTIFY_AND_WAIT (with deadline + on_deadline_exceeded), ESCALATE, RETRY (with backoff + max_attempts + on_exhaustion)
+
+### 49.5 Four Built-in Recovery Profile Groups
+
+| Group | Posture | Profile Default |
+|-------|---------|----------------|
+| `recovery-automated-reconciliation` | Trust drift detection to converge | minimal/dev/standard |
+| `recovery-discard-and-requeue` | Clean up and restart on ambiguity | (opt-in) |
+| `recovery-notify-and-wait` | Notify human; never act automatically | prod/fsi/sovereign |
+| `recovery-aggressive-retry` | Retry everything before giving up | (opt-in) |
+
+Binding hierarchy: resource-type override > Tenant override > profile default > system default (automated-reconciliation).
+
+`recovery_posture` is a Policy Group concern_type (alongside security, compliance, operational, zero_trust_posture, data_authorization_boundary, orchestration_flow).
+
+### 49.6 Late Response Pipeline
+
+Provider responds after DCM timeout:
+1. Late Response Handler activates (entity in TIMEOUT_PENDING state)
+2. Cancel the pending cancellation if not yet sent
+3. Write realized payload to Realized Store
+4. Entity → LATE_REALIZATION_PENDING (if NOTIFY_AND_WAIT) or action per policy (if DRIFT_RECONCILE or DISCARD_AND_REQUEUE)
+
+NOTIFY_AND_WAIT consumer interface: `GET /api/v1/resources/{uuid}/recovery-decisions` and `POST` with chosen action. Platform admin can resolve any entity's pending decision via Admin API.
+
+### 49.7 Compound Service Compensation
+
+Declared per component in service definition:
+- `required_for_delivery: atomic` — failure triggers full compensation rollback
+- `required_for_delivery: partial` — failure → DEGRADED (not FAILED); no compensation triggered
+- `compensation_on_failure: decommission_immediately | release_allocation | skip | notify`
+- `compensation_order: ` — reverse order = first-decommissioned; lowest compensation_order runs last in reverse
+
+Partial delivery policy: `min_required_components` declares minimum for DEGRADED delivery; `auto_retry_optional_components` retries failed optional components.
+
+### 49.8 Five New Lifecycle States
+
+| State | Entry | Recovery Trigger |
+|-------|-------|-----------------|
+| TIMEOUT_PENDING | Dispatch timeout fired | DISPATCH_TIMEOUT |
+| LATE_REALIZATION_PENDING | Late response received + NOTIFY_AND_WAIT | LATE_RESPONSE_RECEIVED |
+| INDETERMINATE_REALIZATION | DRIFT_RECONCILE action taken | — |
+| COMPENSATION_IN_PROGRESS | Compound rollback underway | — |
+| COMPENSATION_FAILED | Rollback itself failed | COMPENSATION_FAILED |
+
+### 49.9 Orphan Detection Pipeline
+
+Triggers: timeout with cancellation sent, cancellation failed, compensation failed, DISCARD_NO_REQUEUE. Queries provider for resources matching Requested State characteristics in the provisioning time window, excluding known Realized State UUIDs. Creates ORPHAN_CANDIDATE records; notifies platform admin (urgency: high); human resolves (manual decommission, adopt into DCM, or mark false positive).
+
+### 49.10 Policies
+
+OPS-010 through OPS-019. Key: cancellation always best-effort (OPS-011); recovery policies are formal DCM policy type (OPS-014); four built-in recovery profiles (OPS-015); binding hierarchy resource-type > Tenant > profile (OPS-016); compensation in reverse dependency order (OPS-017); orphan detection on any uncertain cleanup (OPS-018); NOTIFY_AND_WAIT deadline always has on_deadline_exceeded action (OPS-019).
+
+---
+
+## SECTION 50 — GROUPS 3, 4, AND 5: FINAL ARCHITECTURE GAPS
+
+### 50.1 Cost Analysis — Information Provider Model (Group 3)
+
+Cost Analysis is an **Information Provider** — not a built-in DCM component. DCM does not calculate costs; it provides input data and consumes cost signals. Integration target: Red Hat Cost Management or any external cost management platform.
+
+**DCM provides to Cost Analysis:** entity lifecycle events (realized/suspended/decommissioned with billing_state), provider catalog item declared costs, provider capacity utilization, request payload previews for pre-request estimates.
+
+**Cost Analysis provides to DCM:** pre-request cost estimates (pulled by service catalog and CI pipeline), placement cost signals (pulled during placement Step 4), cost actuals (pushed after billing period), budget alerts (pushed when thresholds approached).
+
+**Fallback chain:** Cost Analysis provider → static declared cost (provider registration) → resource type default estimate → no estimate. Staleness thresholds govern fallback (PT24H standard; PT1H sovereign).
+
+CMP-001, CMP-002.
+
+### 50.2 Orchestration — Reconciled Model (Replaces Conflicting Earlier Statements)
+
+DCM orchestration operates at two levels that compose through the same Policy Engine and event bus:
+
+**Level 1 — Named Workflow Artifacts (explicit, visible, auditable):**
+An Orchestration Flow Policy with `concern_type: orchestration_flow` and `ordered: true` is a named workflow. It declares steps in explicit sequence using the closed payload type vocabulary as step identifiers. Named workflows are first-class Data artifacts — versioned, GitOps-managed, profile-bound, same lifecycle as all other artifacts. The request lifecycle pipeline is a built-in system Orchestration Flow Policy that cannot be deactivated but can be extended. Workflows are triggered: by events on the Request Orchestrator, by schedule (via Discovery Scheduler pattern), manually via Admin API, or by output of another policy.
+
+**Level 2 — Dynamic Policies (conditional, inline):**
+GateKeeper, Transformation, Recovery, Governance Matrix, and Lifecycle Policies fire when their match conditions are satisfied — within or alongside workflow steps. They are not declared in workflow artifacts; they evaluate whenever payload state matches their conditions.
+
+**How they compose:** A named workflow step fires when its declared payload type event occurs. Dynamic policies also fire on the same event if their conditions match. Both are evaluated by the same Policy Engine. Both are triggered by events on the Request Orchestrator event bus. The workflow provides the explicit sequence skeleton; dynamic policies provide conditional behavior within it.
+
+**The "Orchestrator" term** in earlier sections refers to the combination of: Request Orchestrator (event bus) + Orchestration Flow Policy evaluation (named workflows) + Policy Engine (dynamic policy evaluation). There is no separate "Orchestrator" component — the Request Orchestrator is the event bus, and workflows are Policies.
+
+**Adding an explicit pipeline step** = add a step to an Orchestration Flow Policy artifact.
+**Adding conditional behavior** = write a GateKeeper, Transformation, or Recovery policy.
+**Both are Data artifacts evaluated by the Policy Engine.**
+
+### 50.3 Ingress API vs Consumer API (Group 5 fix)
+
+The **Ingress API** is the network infrastructure layer (API Gateway) — TLS termination, auth validation, rate limiting, ingress block population, routing. It routes to three logical API surfaces on distinct path prefixes:
+- `/api/v1/` → **Consumer API** (catalog, requests, resource management, audit)
+- `/api/v1/provider/` → **Provider API** (callbacks, update notifications, cancellation)
+- `/api/v1/admin/` → **Admin API** (discovery triggers, orphan review, tenant management)
+
+The Ingress API is not a separate service — it is the API Gateway component. CMP-007.
+
+### 50.4 Consumer Rate Limiting and Quota Model (Group 5 fix)
+
+**Request rate quotas** — enforced at Ingress API level per actor; returns 429 with Retry-After. Configured in platform-domain layer.
+
+**Resource quotas** — enforced by GateKeeper policies at Step 5 (pre-placement). No hardcoded mechanism — quotas are declared policies. Quota exceeded → QUOTA_EXCEEDED GateKeeper rejection. Quota increase requests submitted via `Process.QuotaIncreaseRequest` catalog item → Orchestrator routes to platform admin for approval → GateKeeper policy updated.
+
+CMP-006.
+
+### 50.5 Drift Severity — Three-Tier Classification (Group 4 fix)
+
+**Tier 1 — Field criticality** (declared in Resource Type Spec): `drift_criticality: minor|significant|critical` per field.
+
+**Tier 2 — Magnitude thresholds** (system layer, overridable at platform/tenant): >50% change on significant field upgrades to critical; 10+ changed items upgrades minor to significant.
+
+**Tier 3 — Provider and consumer injection:** Providers suggest severity in update notifications (raise only). Consumers override sensitivity on specific entities (raise or lower — entity owner controls their resource's sensitivity).
+
+**Resolution:** highest severity from all three tiers wins.
+
+### 50.6 Cross-Tenant Authorization Lifecycle (Group 4 fix)
+
+`cross_tenant_authorization` is a DCMGroup with `group_class: cross_tenant_authorization`. Created by: granting Tenant admin (standard), Platform Admin (emergency), or pre-authorization policy (automated). Has declared duration or perpetual. On revocation: all active allocations/stakes under that authorization enter PENDING_REVIEW; notifications to both Tenant admins and affected resource owners; PT72H default resolution deadline; on_deadline_exceeded recovery policy fires. CTX-001 through CTX-004.
+
+### 50.7 Bootstrap Tenant Creation Sequence (Group 4 fix)
+
+Three foundation Tenants created during bootstrap (declared in bootstrap manifest, cannot be decommissioned):
+- `__platform__` — owns DCM's own control plane resources
+- `__transitional__` — holds brownfield entities during ingestion
+- `__system__` — owns system-level artifacts
+
+Bootstrap sequence: verify manifest → initialize storage → create foundation Tenants → create initial Platform Admin actor → activate system layers/policies/recovery profiles → register built-in providers → ready. RED-016.
+
+### 50.8 Catalog Item vs Resource Type Clarification (Group 5 fix)
+
+**Resource Type** — classification category; vendor-neutral; declares field schema expectations; groups catalog items for portability.
+
+**Resource Type Specification** — versioned formal definition in registry; providers implement against this.
+
+**Provider Catalog Item** — what a specific provider offers to consumers: specific options, cost, availability, SLAs, linked to a Resource Type Specification version. Can be a resource allocation OR a process (automation job, playbook, pipeline). *Consumers request by Resource Type; DCM resolves to a catalog item.*
+
+Anti-vocabulary: never say "catalog item" when you mean "resource type specification." Never say "resource type" when you mean a specific offering.
+
+### 50.9 BBQ-001 and Federation Routing Reconciliation (Group 5 fix)
+
+These operate at different scopes — complementary not conflicting:
+- **DCM-010 sovereignty pre-filter (Hub level):** Which Regional DCMs are eligible for this request?
+- **BBQ-001 check (Regional DCM level):** Is this Mode 4 External Policy Evaluator endpoint within my sovereignty boundary?
+
+Hub selects Regional DCM using DCM-010. Regional DCM applies BBQ-001 for its own Mode 4 queries. Hub sovereignty pre-filter does NOT bypass Regional DCM's BBQ-001 check.
+
+---
+
+## SECTION 51 — ACCREDITATION, DATA AUTHORIZATION MATRIX, AND ZERO TRUST
+
+### 51.1 Three Interconnected Models
+
+Three models compose to govern trust and data handling across all DCM boundaries:
+1. **Accreditation** — is this component certified to handle this data type?
+2. **Data/Capability Authorization Matrix** — given certification, what data/capabilities are permitted across this boundary?
+3. **Zero Trust** — is this specific call, right now, from who it claims to be, permitted to do what it's attempting?
+
+All three checks run at every interaction boundary. All five boundary checks (identity → authorization → accreditation → matrix → sovereignty) produce audit records regardless of outcome.
+
+### 51.2 Data Classification — First-Class Field Metadata
+
+Eight classification levels: `public | internal | confidential | restricted | phi | pci | sovereign | classified`
+
+Carried as `data_classification` on every field in every DCM payload. Declared in: Resource Type Specification (default per field), Data Layer (domain-wide override), explicit field instance (highest precedence). `phi`, `sovereign`, `classified` are **immutable once set** — no layer or policy may downgrade them (ACC-003). Default for unclassified fields: `internal`.
+
+### 51.3 Accreditation Model
+
+First-class versioned artifacts. Seven types (ascending trust): `self_declared`, `first_party`, `third_party`, `qsa_assessment`, `baa`, `regulatory_certification`, `sovereign_authorization`. Lifecycle: developing → proposed → active → deprecated → retired. Renewal warning P90D before expiry. On expiry/revocation: **Accreditation Gap** record created; Recovery Policy evaluates response; affected entities potentially blocked.
+
+Accreditations cover: `data_classifications`, `capabilities`, `geographic_scope`. DCM deployments themselves carry accreditations (enabling federated trust verification). Providers declare accreditations via `POST /api/v1/provider/accreditations` → proposed → platform admin activates.
+
+### 51.4 Data/Capability Authorization Matrix
+
+Policy Group artifact with `concern_type: data_authorization_boundary`. Activated as part of compliance domain group (HIPAA domain → HIPAA boundary matrix). Three sections:
+
+**Outbound data permissions:** `data_classification × required_accreditation_type → ALLOW | STRIP_FIELD | DENY_REQUEST | WARN_AND_ALLOW`. PHI requires BAA — no BAA → DENY_REQUEST. Restricted requires third_party — no third_party → STRIP_FIELD.
+
+**Capability permissions:** STORE_AT_REST on PHI requires BAA. REPLICATE_CROSS_REGION on PHI requires BAA + replication target also has BAA. EXPORT_TO_EXTERNAL_SYSTEM on PHI/restricted/sovereign requires regulatory_cert.
+
+**Inbound data permissions:** What provider may return; which partition stores it; consumer visibility requirements.
+
+**Federation boundary matrix:** `sovereign` and `classified` data = `hard_constraint: true` → NEVER crosses any federation boundary regardless of accreditation. This cannot be overridden by any policy.
+
+**Enforcement pipeline:** Classification inventory → Accreditation resolution → Matrix evaluation per field → ALLOW/STRIP/DENY/WARN → Audit record.
+
+### 51.5 Zero Trust Interaction Model
+
+**Network position grants zero trust.** Five checks at every boundary:
+1. Identity verification (mTLS mutual; certificate pinning; hardware attestation for sovereign)
+2. Authorization verification (explicit permission; scoped credential; not revoked)
+3. Accreditation check (target holds required cert; current; in-scope)
+4. Data/Capability Matrix check (fields and capabilities permitted)
+5. Sovereignty check (BBQ-001; endpoint within boundary)
+
+All five produce audit records on pass AND fail.
+
+**Credentials:** Scoped (minimum necessary operation), short-lived (PT15M for fsi/sovereign; PT30M prod; PT1H standard), non-transferable. Bound to specific entity + provider + operation type.
+
+### 51.6 Zero Trust Posture — Sixth Policy Group Concern Type
+
+Four levels: `none` (minimal) → `boundary` (dev/standard; external boundaries only) → `full` (prod/fsi; everywhere including internal) → `hardware_attested` (sovereign; TPM/HSM required).
+
+Profile defaults: minimal=none, dev/standard=boundary, prod/fsi=full, sovereign=hardware_attested.
+
+### 51.7 Federation Tunnel Zero Trust
+
+Federation tunnels = secure transport, not implicit trust. Structure: mTLS with certificate pinning + per-message signing (ed25519) + replay protection (nonce + PT5M window). Federation credentials scoped to specific operation + specific tunnel + specific resource types. Non-transferable.
+
+Hub-spoke: Hub presents its own credential to Regional DCMs. Regional DCM credentials are never relayed. Each DCM instance verifies the Hub's accreditation before accepting federation messages.
+
+Data boundary: sovereign/classified NEVER crosses federation tunnel (hard_constraint). fsi: max classification = restricted within same jurisdiction. sovereign: internal only, same instance.
+
+### 51.8 Policies
+
+ZT-001 through ZT-005 (zero trust) + ACC-001 through ACC-006 (accreditation). Key:
+- ZT-001: network position = zero trust
+- ZT-003: sovereign/classified never crosses any boundary (hard constraint)
+- ZT-004: federation tunnel = secure transport, not trust
+- ACC-003: phi/sovereign/classified classification is immutable
+- ACC-004: matrix enforced at every outbound boundary before dispatch
+- ACC-006: zero_trust_posture is the sixth Policy Group concern type
+
+---
+
+## SECTION 52 — PERSONAS
+
+| Persona | Primary Concern |
+|---------|----------------|
+| **Consumer** | Self-service access to resources and services |
+| **Service Provider** | Exposing services through DCM catalog |
+| **Auditor** | End-to-end transaction review and validation |
+| **Policy Creator** | Defining and maintaining governance policies |
+| **SRE** | Stability, uptime, drift reconciliation, brownfield management |
+| **CTO** | Accelerate innovation, reduce risk, enable sovereignty |
+| **CIO/MD** | Lifecycle management, agility, IT investment maximization |
+| **CISO/CCO** | Sovereignty enforcement, compliance, risk reduction |
+| **Application Owner** | Focus on application code, not infrastructure specifics |
+| **Line of Business** | Business outcomes — new products, revenue, compliance |
+
+---
+
+## SECTION 53 — GOVERNANCE MATRIX, REGISTRATION, AND DRIFT RECONCILIATION
+
+### 53.1 Unified Governance Matrix (doc 27)
+
+The **single enforcement point** for all cross-boundary data and capability decisions in DCM. Supersedes the Data/Capability Authorization Matrix in doc 26 Section 4. Evaluates every interaction using four axes:
+
+**Axis 1 — Subject (who):** actor | service_provider | information_provider | auth_provider | peer_dcm | process_provider | system. With identity (specific UUID or trust_posture or accreditation_level) and tenant scope.
+
+**Axis 2 — Data (what):** classification (exact/in/minimum/maximum), resource_type, field_paths (allowlist/blocklist/any with dot-notation paths including wildcards `fields.phi_*`), capability (read/write/store/replicate/export/notify/execute/discover/query/federate).
+
+**Axis 3 — Target (where):** type, specific provider/peer UUID, sovereignty_zone (match/not_in), jurisdiction (includes/excludes/intersects country codes), trust_posture (minimum), accreditation_held (includes/not_includes).
+
+**Axis 4 — Context (under what conditions):** profile (posture/compliance_domains), zero_trust_posture (minimum level), tls_mutual, hardware_attestation, federated, cross_jurisdiction, cross_tenant.
+
+**Decisions:** ALLOW | DENY | ALLOW_WITH_CONDITIONS | STRIP_FIELD | REDACT | AUDIT_ONLY
+
+**Hard vs soft enforcement:** Hard rules cannot be relaxed by any downstream rule — ever. GMX-004: sovereign/classified data DENY to all external targets is always hard regardless of profile. Soft rules can be tightened by more-specific domain rules.
+
+**Field-level granularity:** allowlist mode (only named fields cross boundary), blocklist mode (named fields stripped/redacted), passthrough. STRIP_FIELD removes field; REDACT replaces value with ``; if stripped field is required → escalates to DENY_REQUEST (GMX-010).
+
+**Profile-bound defaults:** minimal (pass public/internal; hard DENY sovereign/classified), dev (add confidential with TLS), standard (restricted requires third_party accreditation; PHI denied by default), prod (verified peers only for confidential+; notification fields stripped for restricted), fsi (cross-jurisdiction hard DENY for regulated data; PHI requires BAA+verified+full-ZT), sovereign (no sensitive data in federation; hardware attestation required for all federation).
+
+**Compliance domain rules:** Automatically added when domain active. HIPAA: minimum_necessary principle; PHI audit all interactions; no export without regulatory cert. GDPR: EU residency hard rule; personal identifier fields stripped outside EU zones.
+
+**Sovereignty zones:** Registered artifacts declaring jurisdictions, regulatory frameworks, inter-zone agreements, and required provider accreditation. Rules reference zones by ID, not raw country codes.
+
+**Evaluation algorithm:** Hard DENY first → any hard DENY = terminal DENY. Soft constraints by domain precedence (entity > resource_type > tenant > platform > system); DENY > STRIP_FIELD > ALLOW. Conditions evaluated for ALLOW_WITH_CONDITIONS. Field permissions applied. Audit record always written. GMX-001 through GMX-010.
+
+### 53.2 Registration Specification (dcm-registration-spec.md)
+
+**Provider Type Registry:** Three-tier (Core/Community/Organization). Each entry declares permissions, default_approval_method, default_trust_level, enabled_in_profiles, capability_schema_ref. Five provider types: service_provider (reviewed), information_provider (reviewed), auth_provider (verified), peer_dcm (verified), process_provider (reviewed).
+
+**Registration token model:** Pre-issued by platform admin (POST /api/v1/admin/registration-tokens). Scoped to provider_type, handle_pattern, sovereignty_zone. single_use. grants_auto_approval flag. Token value presented once — never retrievable. Max trust level bounded by token scope.
+
+**Approval method resolution:** most_restrictive(provider_type_default, profile_min_method, token_grants_auto). Profile can only tighten. Token can relax to auto ONLY if profile.allow_token_auto_approval=true. Committee approval cannot be relaxed by token.
+
+**Profile defaults:** minimal/dev → reviewed, token auto-approval enabled. standard → reviewed, token auto-approval enabled (max trust: standard). prod → reviewed; high-trust types require verified; no token auto-approval. fsi → verified everything; minimum_accreditation: third_party. sovereign → authorized everything; minimum_accreditation: regulatory_certification; hardware_attestation required.
+
+**Registration pipeline:** SUBMITTED → VALIDATING (8 automated checks: provider type enabled, governance matrix pre-check, registration token, certificate, sovereignty declaration, capability consistency, health endpoint, accreditation) → PENDING_APPROVAL → ACTIVE. Approval methods: auto (immediate), reviewed (one admin), verified (two independent admins), authorized (DCMGroup quorum).
+
+**Per-type capability schemas:** service_provider (resource types, capacity model, cancellation support, discovery, naturalization format, cost metadata), information_provider (data domains, authority level, query capacity, confidence model), auth_provider (auth modes, MFA methods, RBAC model, token lifetime), peer_dcm (federation scope, trust level, mTLS certificate), process_provider (workflow types, execution engine, callback pattern).
+
+**Federated trust postures:** verified (manually approved; full scope), vouched (Hub-introduced; bounded scope), provisional (crypto-verified; catalog_query only if profile permits). Approval: dev auto-promotes provisional; standard reviewed for verified; prod/fsi verified; sovereign authorized+hardware-attestation. Profile federation_policy block declares all parameters.
+
+**Ongoing lifecycle:** health monitoring (polling; degraded → reduced routing; failure_threshold → UNAVAILABLE; 2×threshold → drift triggered), certificate rotation (P90D default; P14D warning; P7D transition window), capability amendments (simplified flow), graceful deregistration (entity migration plan required), forced deregistration (verified/authorized; entities → INDETERMINATE_REALIZATION; Recovery Policy fires).
+
+### 53.3 Drift Reconciliation Component (doc 25 Section 7)
+
+Control plane component that compares Discovered State vs Realized State. Read-only — never writes to Realized Store. Produces drift records and events into Request Orchestrator.
+
+**Algorithm:** discovery.cycle_complete event → field-by-field comparison per entity → field criticality (from Resource Type Spec) × change magnitude (profile-governed thresholds) → severity matrix (minor/significant/critical) → unsanctioned check (no corresponding Requested State? → elevate one level; fire unsanctioned_change.detected) → drift_record created → drift.detected event → Policy Engine evaluates response.
+
+**Drift record:** entity_uuid, discovery_snapshot_uuid, realized_state_uuid, overall_severity, unsanctioned flag, drifted_fields (field_path, realized_value, discovered_value, field_criticality, change_magnitude, field_severity, elevated_for_unsanctioned), status (open/acknowledged/resolved/escalated).
+
+**Resolution tracking:** Drift record status updated when REVERT (next discovery shows clean) or UPDATE_DEFINITION (new Realized State written) or ACCEPT or entity DECOMMISSIONED. drift.resolved event published.
+
+**Governance matrix integration:** Checks if a governance matrix rule permits the provider to make this type of change. If yes: warning (provider should have submitted update notification). Still treated as drift — provider must use the Provider Update Notification API.
+
+DRC-001 through DRC-005. Nine control plane components now fully defined in doc 25.
+
+---
+
+
+
+## SECTION 54 — FEDERATED CONTRIBUTION MODEL (doc 28)
+
+### Core Principle
+DCM defaults to a federated model for data creation, import, usage, and lifecycle. Every authorized actor type can contribute Data artifacts within their permitted domain scope. The same GitOps PR flow and lifecycle (developing → proposed → active → deprecated → retired) applies to all contributors. Profile-bound auto-approval governs what requires human review.
+
+### Four Contributor Types
+1. **Platform Admin** — all artifact types, all domains, no restrictions
+2. **Consumer/Tenant** — tenant-domain policies, resource groups, notification subscriptions, webhook registrations, cross-tenant authorization records, request layers
+3. **Service Provider** — resource type specs (types they offer), provider catalog items, service layers, provider-domain policies
+4. **Peer DCM** — registry entries, policy templates, service layers (via federation channels, scoped by trust posture)
+
+### Contributor Permission Boundaries (hard DENY — Governance Matrix enforced)
+- Consumers cannot contribute system or platform domain policies
+- Providers cannot contribute specs for resource types they don't offer
+- Provisional peers: registry entries only (no policies; authorized approval)
+- Vouched peers: registry entries + service layers only (reviewed always)
+- Verified peers: registry entries + policy templates + service layers (reviewed standard+; auto dev)
+
+### Universal Contribution Pipeline
+Submit → Governance Matrix evaluates contributor permissions → proposed status (shadow mode for policies) → review flow (auto / reviewed / verified / authorized per profile + artifact type + contributor) → active → lifecycle by contributor (deprecate/retire) → platform admin override at any time
+
+### Contribution Artifact Types by Contributor
+- Consumer: tenant policies (all 7 types), resource groups, notification subs, webhooks, cross-tenant auth records, request layers
+- Provider: Resource Type Specs (their types), catalog items, service layers, provider-domain GateKeeper/Validation policies
+- Peer DCM: registry entries, policy templates (verified peers), service layers (verified/vouched)
+
+### Contribution Store Directory Structure
+`dcm-policy-store/system/` (platform admin) · `platform/` (platform admin) · `tenant//` (consumer) · `provider//` (provider) · `federated//` (peer DCM)
+`dcm-registry/core/` (DCM project) · `community//` (community) · `organization//` (org)
+
+Every artifact includes `contributed_by` block: contributor_type, actor/tenant/provider/peer_dcm UUID, contribution_method (api/flow_gui/git_pr/federation_push), pr_url, reviewed_by. Immutable once set.
+
+### Profile-Governed Auto-Approval
+- minimal/dev: most contributions auto-approved; shadow optional
+- standard: consumer/provider policies → reviewed; shadow default on, P7D review period
+- prod: governance matrix rules → verified; provider specs → reviewed; shadow P14D
+- fsi: all consumer/provider contributions → verified; shadow P30D; must review all divergence cases
+- sovereign: all → authorized; shadow P30D; orphaned artifacts auto-retire
+
+### Consumer API Contribution Endpoints (Section 9)
+`POST /api/v1/contribute/policy` (generates PR, activates shadow mode) · `POST /api/v1/contribute/resource-group` (activates immediately) · `GET /api/v1/contribute` (list contributions) · `DELETE /api/v1/contribute/{uuid}` (withdraw, closes PR)
+
+### Organization Sub-Tiers (Registry)
+Three-tier model extended to all artifact types: `organization/platform` (platform admin authored), `organization/provider` (provider authored, scoped to their types), `organization/tenant` (consumer authored, scoped to their Tenant). Lower sub-tier = lower inherent trust = may require additional review.
+
+### FCM-001 through FCM-008 System Policies
+FCM-001: contributor recorded in contributed_by; immutable. FCM-002: domain scope violations = hard DENY. FCM-003: all contributions via GitOps PR (except auto-approve). FCM-004: policies enter shadow mode by default. FCM-005: platform admin override always available; audited. FCM-006: orphaned artifacts don't auto-deactivate (except sovereign). FCM-007: federation contribution scoped by trust posture. FCM-008: contributor scope limits absolute.
+
+---
+
+## SECTION 55 — TERMINOLOGY GLOSSARY
+
+| Term | Definition |
+|------|-----------|
+| **DCM** | Data Center Management — the framework itself |
+| **Sovereign Execution Posture** | Target state where all operations are governed, auditable, and sovereignty-compliant |
+| **Hard Tenancy** | Strict isolation between tenants at the infrastructure level |
+| **UDM** | Unified Data Model — the centralized data schema and single source of truth |
+| **Naturalization** | Converting UDM format to provider-specific format for execution |
+| **Denaturalization** | Converting provider-specific results back to UDM format |
+| **Greening the Brownfield** | Bringing existing unmanaged resources under DCM lifecycle management |
+| **Intent Portability** | Replaying an Intent State through current policies to produce a new Requested State |
+| **Resource Type** | Abstract, vendor-neutral definition of a class of resource |
+| **Provider Catalog Item** | Concrete provider implementation of a Resource Type Specification |
+| **Portability-Breaking** | A field or operation that ties a request to a specific provider |
+| **CMDB** | Configuration Management Database — DCM aims to replace the fragmented multi-CMDB problem |
+| **GRC** | Governance, Risk, and Compliance |
+| **TTR** | Time to Recovery — key metric for rehydration use case |
+| **MTTD** | Mean Time to Deploy or Detect |
+| **MTTR** | Mean Time to Recovery/Repair |
+| **FSI** | Financial Services Institution |
+| **IaC** | Infrastructure as Code |
+| **GitOps** | Managing infrastructure definitions through Git workflows |
+| **CRUD** | Create, Read, Update, Delete — full lifecycle operations |
+| **IPU** | In-Place Upgrade |
+| **EOL** | End of Life |
+| **Field-Level Provenance** | Structural mechanism carrying data lineage within each data object |
+| **Data Lineage** | Complete chain of custody of any field value from origin through all modifications |
+| **Base Layer** | Foundation entity for a resource — every layer chain starts here |
+| **Core Layer** | Type-agnostic data layer carrying organizational and infrastructure context |
+| **Service Layer** | Type-scoped data layer carrying service-specific configuration — must declare Resource Type scope |
+| **Request Layer** | Consumer's declared intent — becomes Intent State on submission |
+| **Layer Chain** | Ordered sequence of layers merged to produce an assembled payload |
+| **Assembly Process** | Seven-step process by which the Request Payload Processor builds a Requested State payload |
+| **GateKeeper Policy** | Highest-authority policy that can override any field including consumer input |
+| **Transformation Policy** | Policy that enriches or modifies payload fields — all changes recorded in provenance |
+| **Validation Policy** | Policy that checks payload against rules — pass/fail, no field modification |
+| **Resource/Service Request** | What a consumer submits to DCM — declared intent to consume a resource or service |
+| **Resource/Service Entity** | The "thing" produced by a provider fulfilling a request — the allocation made real |
+| **DCM Tenant** | Mandatory first-class ownership boundary for all Resource/Service Entities |
+| **Allocation Model** | Provider retains infrastructure ownership; consumer owns the Entity allocation |
+| **Whole Allocation Model** | Entire resource allocated as indivisible unit; provider retains ownership |
+| **Full Transfer Model** | Provider transfers complete ownership of underlying resource to consumer Tenant |
+| **Hybrid Transfer Model** | Ownership can transfer multiple times; always exactly one owning Tenant |
+| **Process Resource Entity** | Ephemeral execution resource — playbook, pipeline, workflow. Permanent execution record. |
+| **Dependency Graph** | Complete map of all resources required to fulfill a request including transitive dependencies |
+| **Type-Level Dependency** | Portable, provider-agnostic dependency declared at Resource Type Specification level |
+| **Provider-Specific Dependency** | Additional dependency declared at Provider Catalog Item level — must be marked portability-breaking |
+| **Resource Group** | Flexible composable grouping entity — functions like a structured tag |
+| **Custom Resource Group** | Implementor-defined grouping entity with full parity to DCM Default Resource Group |
+| **Tenant Advocate** | DCM's role in protecting Tenant interests in all provider interactions |
+| **DCM System Policy** | Non-overridable policy built into DCM — cannot be disabled or overridden by organizational policy |
+| **Webhook** | Push-based outbound notification from DCM to an external system triggered by a DCM event |
+| **Commit Log** | Stage 1 audit store — minimal record, Raft consensus quorum write, sub-millisecond; Audit Forward Service reads from it to produce full audit records |
+| **Audit Forward Service** | DCM component that enriches Commit Log entries into full audit_record structures and delivers them to the Audit Store asynchronously with retry |
+| **Self-Hosting** | DCM's own deployment is a DCM resource; DCM manages itself through the same model used for customer infrastructure |
+| **dcm_deployment** | The DCM resource declaring DCM's own deployment — profile, replica counts, store implementations, redundancy configuration |
+| **Bootstrap manifest** | The minimal configuration outside DCM's management scope used to bootstrap DCM before it can manage itself |
+| **Redundancy by Default** | DCM architectural principle: every component and store has a redundancy model; `minimal` profile sets replicas: 1; all others set replicas >= 3 |
+| **Quorum Write** | Write confirmed durable only when a majority of replicas acknowledge it; used by Commit Log and all durable stores in standard+ profiles |
+| **Raft** | Consensus protocol used by Commit Log (etcd) for quorum writes; guarantees durability even if minority of replicas fail |
+| **DCMGroup** | Universal group entity — all grouping constructs in DCM expressed as DCMGroup with group_class |
+| **group_class** | Determines system behavior of a DCMGroup — closed built-in set: tenant_boundary, resource_grouping, policy_collection, policy_profile, layer_grouping, composite, federation |
+| **Cost Analysis Information Provider** | Specialized Information Provider supplying cost estimates, placement cost signals, cost actuals, and budget alerts; DCM provides input data; provider performs calculations |
+| **Orchestration Flow Policy** | Named workflow artifact: Orchestration Flow Policy with `ordered: true`; declares explicit step sequence using payload type vocabulary; first-class Data artifact; versioned, GitOps-managed, profile-bound |
+| **Request Orchestrator** | Runtime event bus; routes lifecycle events to Policy Engine; has no pipeline logic; both named workflows and dynamic policies are evaluated through it |
+| **orchestration (DCM)** | Two-level composable model: Level 1 = named Orchestration Flow Policies (explicit sequence); Level 2 = dynamic policies (conditional, inline); both evaluated by Policy Engine; adding a step = adding to a workflow Policy; adding conditional behavior = writing a dynamic policy |
+| **Provider Catalog Item** | What a specific Service Provider offers consumers: specific resource allocation or process with cost, availability, SLAs; linked to Resource Type Specification version |
+| **cross_tenant_authorization** | DCMGroup with group_class: cross_tenant_authorization; grants one Tenant permission to reference/allocate/stake another Tenant's resources; revocation places active allocations in PENDING_REVIEW |
+| **foundation Tenants** | Three system Tenants created at bootstrap: __platform__, __transitional__, __system__; cannot be decommissioned; declared in bootstrap manifest |
+| **QUOTA_EXCEEDED** | GateKeeper rejection code when resource quota policy fires at Step 5 (pre-placement) |
+| **Federated Contribution Model** | DCM defaults to federated data creation — all authorized actor types (platform admin, consumer/tenant, service provider, peer DCM) can contribute Data artifacts within their domain scope via the GitOps PR model; see doc 28 |
+| **contributor** | Actor type that authored a Data artifact; recorded in artifact_metadata.contributed_by; determines review requirements; platform_admin / consumer / service_provider / peer_dcm |
+| **contributed_by** | Artifact metadata block recording contributor_type, actor UUID, contribution_method, pr_url, reviewed_by; immutable once set |
+| **DPO-001–006** | Design Priority system policies. DPO-001: security properties present in all profiles (not controlled by profiles). DPO-002: every security requirement needs an ease-of-use mechanism. DPO-005: minimal profile = "security with minimal overhead" not "minimal security". DPO-006: when security and ease conflict, redesign ease-of-use, not security. |
+| **FCM-001–008** | Federated Contribution Model system policies; key: FCM-002 (domain scope violations = hard DENY), FCM-003 (GitOps PR for all), FCM-008 (contributor scope limits absolute) |
+| **Unified Governance Matrix** | Single enforcement point for all cross-boundary decisions; four axes (subject/data/target/context); hard vs soft enforcement; field-level granularity (allowlist/blocklist/paths); profile-bound defaults; GMX-001–010 |
+| **governance_matrix_rule** | Artifact declaring match conditions across four axes and a decision (ALLOW/DENY/ALLOW_WITH_CONDITIONS/STRIP_FIELD/REDACT/AUDIT_ONLY) with hard or soft enforcement |
+| **sovereignty_zone** | Registered DCM artifact declaring geopolitical/regulatory boundary; rules reference zones by ID; inter-zone agreements declared explicitly |
+| **STRIP_FIELD** | Governance matrix decision: remove named fields from payload and proceed; if stripped field is required → DENY_REQUEST |
+| **REDACT** | Governance matrix decision: replace field value with ``; field presence preserved; receiver knows field exists but not its value |
+| **Provider Type Registry** | Three-tier registry of approved provider types; each entry declares permissions, default_approval_method, enabled_in_profiles, capability_schema_ref |
+| **registration_token** | Pre-issued by platform admin; scoped to provider_type/handle_pattern/zone; single_use; grants_auto_approval flag; value presented once only |
+| **approval_method** | Registration approval: auto | reviewed | verified | authorized; resolved as most_restrictive(provider_type_default, profile_min, token_effect) |
+| **Drift Reconciliation Component** | Control plane component; compares Discovered vs Realized State; produces drift records and events; never writes to Realized Store; DRC-001–005 |
+| **drift_record** | Artifact produced by Drift Reconciliation; field-by-field comparison result with severity classification; unsanctioned flag; status tracking through resolution |
+| **Placement Engine** | Six-step algorithm: sovereignty filter → accreditation filter → capability filter → reserve query → tie-breaking (policy/priority/affinity/cost/load/hash) → confirm; PLC-001–006 |
+| **reserve_query** | Parallel capacity queries to all eligible provider candidates; PT5M capacity hold; non-responders and insufficient-capacity providers excluded |
+| **consistent hash** | Final placement tie-breaker: SHA-256(request_uuid+resource_type+sorted_candidates); deterministic; never round-robin |
+| **Lifecycle Constraint Enforcer** | Monitors TTL/expiry/max_execution_time; fires expiry actions through standard pipeline; grace period before action; Process Resources: immediate FAILED on breach; LCE-001–005 |
+| **Search Index** | Non-authoritative queryable projection of GitOps stores; indexes key fields; returns git_path for full payload; max staleness PT5M; always rebuildable; SIX-001–004 |
+| **Admin API** | Platform admin REST interface: Tenant lifecycle, provider review, accreditation approval, discovery trigger, orphan resolution, recovery decisions, quota management, Search Index rebuild, bootstrap operations |
+| **PENDING_EXPIRY_ACTION** | Entity state when expiry action fails to execute; Lifecycle Constraint Enforcer retries per Recovery Policy; Platform Admin notified urgency: high |
+| **data_classification** | First-class field metadata: public/internal/confidential/restricted/phi/pci/sovereign/classified; phi/sovereign/classified are immutable once set |
+| **Accreditation** | Formal versioned attestation that a component satisfies a compliance framework; issued by an Accreditor; carries validity period; lifecycle: developing→proposed→active→expired/revoked |
+| **Accreditor** | Entity that issues accreditations: government body, regulatory body, QSA, certification body, or internal audit team |
+| **Accreditation Gap** | Missing, expired, or revoked accreditation required for an active interaction; always high/critical severity; Recovery Policy governs response |
+| **Data/Capability Authorization Matrix** | Policy Group artifact (concern_type: data_authorization_boundary) declaring what data fields and capabilities are permitted across interaction boundaries given data classification and accreditation level |
+| **zero_trust_posture** | Sixth Policy Group concern type; four levels: none/boundary/full/hardware_attested; profile defaults: minimal=none, dev/standard=boundary, prod/fsi=full, sovereign=hardware_attested |
+| **Five-check boundary model** | Identity → Authorization → Accreditation → Matrix → Sovereignty; all five checks at every DCM interaction boundary; all produce audit records |
+| **Federation tunnel** | Mutually authenticated, encrypted, scoped DCM-to-DCM channel; zero trust model; establishes secure transport only, not implicit trust; per-message signing; scoped non-transferable credentials |
+| **hard_constraint** | Data/Capability Matrix declaration that cannot be overridden by any policy; sovereign/classified data never crossing federation boundaries is a hard_constraint |
+| **STRIP_FIELD** | Matrix enforcement action: remove non-permitted field from payload and proceed; if stripped field is required → escalates to DENY_REQUEST |
+| **DENY_REQUEST** | Matrix enforcement action: block entire interaction; entity enters PENDING_REVIEW; notification dispatched |
+| **Request Orchestrator** | DCM control plane event bus; routes lifecycle events to Policy Engine; coordinates pipeline via event-condition-action; does not contain hardcoded pipeline logic |
+| **Cost Analysis Component** | Internal DCM control plane component; three functions: pre-request estimation, placement input, ongoing attribution; not a billing system; not a provider type |
+| **Module** | DCM capability extension adding new functions; distinct from Profile (which configures behavior) |
+| **orchestration_flow** | Policy Group concern_type for static sequential flows; ordered: true; both static and dynamic flows compose through the same Policy Engine |
+| **payload_type** | Closed vocabulary of event types the Request Orchestrator publishes; policies pattern-match on payload type + state |
+| **OPA integration** | Reference implementation for Mode 3 External Policy Evaluators; DCM payload as OPA input document; built-in Rego functions provided by DCM |
+| **Flow GUI** | Visual policy composer and orchestration manager; execution graph view, policy canvas, shadow mode dashboard, flow simulation |
+| **__platform__** | Immutable system Tenant owning DCM control plane resources; created at bootstrap before Policy Engine comes online |
+| **__transitional__** | Immutable system Tenant holding brownfield entities during INGEST phase |
+| **bootstrap manifest** | Signed manifest declaring initial system Tenants, bootstrap admin, and initial profile; hash-verified at every DCM startup |
+| **cross_tenant_authorization** | DCMGroup with this group_class formally grants one Tenant access to another's resources; has lifecycle (duration, renewal, revocation); revocation places active allocations in PENDING_REVIEW |
+| **drift_criticality** | Field-level property in Resource Type Spec (low/medium/high/critical); combined with change magnitude to produce drift severity |
+| **Ingress API** | Infrastructure-layer entry point for all inbound DCM requests; sets ingress block; routes to Consumer/Provider/Admin API surfaces |
+| **Provider Catalog Item** | Provider-specific instantiation of a Resource Type Specification; what consumers actually request; distinct from the Resource Type Specification itself |
+| **Recovery Policy** | Formal DCM policy type mapping trigger conditions (DISPATCH_TIMEOUT, PARTIAL_REALIZATION, etc.) to response actions; same authoring model as GateKeeper/Validation/Transformation |
+| **recovery_posture** | Fifth Policy Group concern_type governing failure and ambiguity response; binds a recovery profile group to the deployment |
+| **DRIFT_RECONCILE** | Recovery action: schedule discovery; let drift detection resolve actual state |
+| **DISCARD_AND_REQUEUE** | Recovery action: best-effort cleanup; new request cycle created immediately |
+| **NOTIFY_AND_WAIT** | Recovery action: notify human; wait for explicit decision up to declared deadline |
+| **TIMEOUT_PENDING** | Infrastructure Resource Entity state: dispatch timeout fired; recovery policy evaluating |
+| **LATE_REALIZATION_PENDING** | Entity state: provider responded after timeout; NOTIFY_AND_WAIT recovery decision pending |
+| **INDETERMINATE_REALIZATION** | Entity state: state ambiguous; drift detection resolving |
+| **COMPENSATION_FAILED** | Entity state: compound service rollback itself failed; orphan detection active |
+| **orphan_candidate** | Resource discovered at provider with no corresponding Realized State record; surfaced to platform admin for human resolution |
+| **Discovery Scheduler** | DCM control plane component maintaining priority queue of discovery requests; dispatches to provider discovery endpoints |
+| **recovery-automated-reconciliation** | Built-in recovery profile: trust drift detection; accept late responses; appropriate for dev/standard |
+| **recovery-notify-and-wait** | Built-in recovery profile: notify human; never act automatically; appropriate for prod/fsi/sovereign |
+| **notification service** | Ninth DCM provider type; translates unified notification envelope to delivery channel; handles delivery, retry, dead letter, and delivery confirmation callbacks |
+| **Notification Router** | DCM control plane component that resolves notification audiences and routes envelopes to notification services |
+| **audience resolution** | Deriving notification recipients by traversing the entity relationship graph from the changed entity at event time |
+| **notification_uuid** | Idempotency key on notification envelopes; notification services use this to deduplicate on retry |
+| **audience_role** | owner / stakeholder / approver / observer — why this actor is in the notification audience |
+| **stakeholder_reason** | Notification envelope field explaining which relationship caused the actor to be in the stakeholder audience |
+| **Tier 1 / Tier 2 / Tier 3 notifications** | Mandatory system (non-suppressable) / Tenant defaults / Actor subscriptions — three subscription tiers that compose |
+| **NOT-001 through NOT-008** | Notification model system policies |
+| **write-once snapshot store** | Realized Store implementation model: each record is a complete immutable entity state snapshot; no event replay; direct point-in-time lookup; supersession chain links snapshots |
+| **corresponding_requested_state_uuid** | Mandatory non-nullable field on every Realized State snapshot; traces every Realized State change to an authorized request |
+| **Provider Update Notification** | Formal API for providers to report authorized state changes; DCM evaluates via Policy Engine; approved → new Requested State + Realized State; rejected → drift event |
+| **notification_uuid** | Idempotency key on Provider Update Notifications; safe to resend on provider crash |
+| **pre-authorized update** | Category of provider update pre-approved by GateKeeper policy; processed automatically without per-change human review |
+| **Whole Allocation** | Ownership pattern: consumer owns the entire resource entity outright in their Tenant; no pool involved |
+| **Allocation** | Ownership pattern: pool yields independently-owned sub-resources; consumer owns their allocation; AllocationRecord relationship links to pool |
+| **Shareable** | Ownership pattern: one resource, multiple stakeholders; consumers hold stakes (relationships) only; no consumer owns any portion |
+| **AllocationRecord** | Cross-tenant relationship from an allocation entity back to its source pool entity |
+| **stake_strength** | Relationship property on shareable resource attachments: required (blocks decommission) / preferred / optional |
+| **PENDING_REVIEW** | Formal Infrastructure Resource Entity lifecycle state for conflicts requiring human resolution (sovereignty, cross-tenant auth revocation, ownership transfer conflicts) |
+| **Consumer API** | DCM REST API for consumers: catalog browsing, request submission, resource management, audit trail access |
+| **Consumer Request Status** | Lifecycle: ACKNOWLEDGED → ASSEMBLING → AWAITING_APPROVAL → APPROVED → DISPATCHED → PROVISIONING → COMPLETED/FAILED/CANCELLED |
+| **01-entity-types.md** | Entity type taxonomy: Infrastructure Resource, Composite Resource, Process Resource; sub-types and invariants |
+| **04-examples.md** | Worked examples: VM end-to-end, IP allocation, VLAN sharing, brownfield ingestion, drift remediation; Git repo structure |
+| **04b-ownership-sharing-allocation.md** | Authoritative ownership model: whole allocation, allocation, shareable; policies OWN-001 through OWN-008 |
+| **federation routing** | Hub DCM applies placement engine logic at the DCM instance level; Regional DCMs are DCM Provider instances; sovereignty is a hard pre-filter; same tie-breaking hierarchy as provider selection |
+| **independent_with_overlap** | Certificate rotation model: old cert valid P30D after new cert issued; allows peers to update trust stores without coordinated downtime |
+| **alert_and_hold** | Federated drift detection response when peer DCM is unavailable: do not assume drift; hold state; escalate to platform admin after PT24H |
+| **AUDIT_STORE_UNAVAILABLE** | Gap record inserted in Audit Store hash chain after recovery from Audit Store failure; timestamps the exact outage window; makes gap explicit and auditable |
+| **confidence aggregation** | Per-entity endpoint computing overall confidence band (= lowest field band); identifies contested and stale fields; computed on demand never stored |
+| **explicit_no_filter** | Composite group declaration suppressing the no member_type filter linting warning; confirms broad targeting is intentional |
+| **certified profile** | DCM profile carrying formal third-party certification metadata (HIPAA assessor, FedRAMP JAB, PCI QSA); promoted to Tier 1; applies to artifact not deployment |
+| **POLICY_PROVIDER_ELEVATED** | Audit action recorded when a External Policy Evaluator's mode level is elevated; always produced regardless of profile |
+| **tier_certifications** | Certification metadata on Resource Type Specs or profiles from recognized certifying bodies; filter criterion, not structural tier boundary |
+| **tier_3_to_tier_2_promotion** | PR-based pathway for organizations to promote internal Tier 3 Resource Types to Verified Community (Tier 2); requires production deployment, OSS license, named maintainer, migration path |
+| **independent operation mode** | Resource Type Registry state when upstream registry is permanently unavailable; existing types continue; new community type adoption requires governance decision |
+| **SCIM 2.0** | System for Cross-domain Identity Management; optional Auth Provider capability for automated actor provisioning from enterprise IdPs; provisions actors and group memberships; roles not SCIM-provisioned |
+| **step-up MFA** | Additional MFA challenge at sensitive operations within an already-authenticated session; declared per operation by policy; step-up token TTL PT10M |
+| **actor.type** | Audit record field: human / service_account / system; enables filtering between human-initiated and automated lifecycle operations in queries and dashboards |
+| **system_actor** | Audit record block on system-initiated records: identifies DCM component, trigger event, and authorizing policy UUID |
+| **Merkle root proof** | Federation-level audit integrity mechanism: Hub DCM computes Merkle root of all Regional DCM chain tips daily; any chain break detectable against stored root |
+| **per-instance hash chain** | Each DCM instance (Hub/Regional/Sovereign) maintains its own independent hash chain; not merged cross-instance; cross-referenced via correlation_id |
+| **AUTH-012 through AUTH-015** | Auth Provider gap policies: SCIM provisioning, failover handling, two-tier MFA, pluggable user store |
+| **AUD-014 through AUD-017** | Universal Audit gap policies: hash chain verification modes, Commit Log capacity, system-initiated records, distributed hash chains |
+| **Hub DCM** | Central/global DCM instance; authoritative registry origin; governance authority; replaces "Shore" terminology |
+| **Regional DCM** | Distributed regional DCM instance; manages resources in its region; caches from Hub DCM; replaces "Ship" terminology |
+| **Sovereign DCM** | Air-gapped or compliance-isolated DCM instance; local static caches from signed bundles; replaces "Enclave" terminology |
+| **native_passthrough** | Sanctioned field for provider-specific data that cannot be expressed in the unified model; always audit-logged; opaque mode blocked in fsi/sovereign |
+| **BULK_PROMOTE** | Audit action for bulk entity promotion; single audit record with full member list; requires preview + approval in prod+ profiles |
+| **CACHE policies** | CACHE-001 through CACHE-004 — cache placement, sync, authoritativeness, consistency |
+| **DATA-001** | Policy: core data model does not embed technology-specific data; native_passthrough sanctioned with governance |
+| **RED-011 through RED-015** | Deployment redundancy gap policies: bootstrap verification, K8s upgrades, runtime support, hardware specs, self-hosted drift |
+| **ING-012 through ING-015** | Ingestion gap policies: signal priority configurable, bulk promotion, max sources, catalog promotion |
+| **rehydration_history** | Immutable record on entity of all rehydration events: trigger, from/to provider, from/to provider-side IDs, actor, state refs |
+| **rehydration_lease** | Exclusive time-bounded lock per entity during rehydration; prevents concurrent rehydrations; TTL prevents orphans |
+| **min_auth_level** | Entity rehydration constraint declaring minimum actor authentication level required; profile governs enforcement |
+| **allow_delegated_rehydration** | Entity flag permitting DCM service accounts to rehydrate automatically; requires platform admin authorization audit trail |
+| **REHYDRATION_BLOCKED** | Audit event recorded when a concurrent rehydration attempt is rejected due to active lease |
+| **hybrid retention mode** | Discovered State retention: minimum window + retain until drift resolved + hard maximum ceiling |
+| **rolling_window retention** | Discovered State retention: keep last N days regardless of drift status |
+| **override: allow/constrained/immutable** | Layer field metadata declaring override intent; enforced by Request Payload Processor at Step 3; immutable prevents lower-authority overrides only; GateKeeper may additionally lock |
+| **constraint_visibility** | Policy-governed disclosure level for constrained fields: full (constraint+bounds+reason+suggestions), summary (bounds only), hidden (silently enforced) |
+| **editable** | Resource Type Spec field declaration: can this field be modified post-realization via a targeted delta update (true) or only via reprovisioning (false) |
+| **edit_constraints** | Bounds declared on editable fields: range, list, enum; validated at update time; same constraint types as assembly-time constraints |
+| **requires_restart** | Editable field flag indicating whether a provider restart action is needed to apply the update |
+| **targeted delta** | Update mechanism for editable fields: applies only changed fields to Realized State; does NOT re-run the layer assembly chain |
+| **non_editable_reason** | Human-readable explanation on non-editable fields explaining why reprovisioning is required to change them |
+| **confidence_descriptor** | Primary confidence data model: authority_level (from registration), corroboration (from ingestion), source_trust (from trust system), last_updated_at (from push) — stored fields |
+| **freshness** | Derived confidence field computed at query time from (now - last_updated_at) vs thresholds: high (<1h), medium (<1d), low (<7d), stale (>7d) |
+| **corroboration** | Confidence descriptor field: confirmed (2+ sources agree), single_source, contested (sources disagree) |
+| **source_trust** | Confidence descriptor field maintained by trust scoring system: verified (score ≥80), degraded (60-79), suspended (<60) |
+| **OBS-001** | Policy: DCM publishes curated Observability Event Stream via Message Bus; policy-filtered; raw metrics opt-in; does not replace audit records |
+| **AUD-013** | Policy: Audit and Observability are definitively separate components — opposite trade-offs; cannot be combined |
+| **group_subclass** | Advisory label on a DCMGroup — no system behavior; used for organization-specific semantics (e.g., cost_center, business_unit) |
+| **composite group** | DCMGroup with group_class: composite — permits cross-type membership (resources, policies, layers, groups) |
+| **federation group** | DCMGroup with group_class: federation — peer association of tenant_boundary groups; enables shared policies and consolidated reporting |
+| **nested Tenant** | A tenant_boundary group with parent_group_uuid pointing to another tenant_boundary group |
+| **federated Tenant** | A tenant_boundary group that is a member of a federation group |
+| **former_group_membership** | Permanent provenance record retained by a member after group destruction or membership expiry |
+| **group_destruction_record** | Permanent Audit Store record of a destroyed group including its full member list at destruction time |
+| **member_type_filter** | Policy targeting declaration narrowing scope within a composite group to specific member types |
+| **most_restrictive_wins** | Governance inheritance principle for nested Tenants — most restrictive policy at any level in the hierarchy applies |
+| **Nested Tenant** | tenant_boundary group with parent_group_uuid — child maintains isolation; parent has governance overlay and cost rollup |
+| **GRP-INV** | Universal group structural invariants — non-overridable regardless of enforcement_model or Profile |
+| **Universal Audit Record** | Uniform audit record produced by every DCM component for every change — date/time, who, what, action |
+| **Composite Actor Chain** | The who in an audit record — immediate actor + authorized_by human chain + originating request/policy |
+| **Action Vocabulary** | Closed set of audit record action values — free text rejected at write time (AUD-007) |
+| **Reference-Based Retention** | Audit records retained while any referenced entity is live — not fixed time schedule |
+| **Write-Ahead Log (WAL)** | Local audit delivery buffer — change + audit record written atomically; Audit Store delivery async with retry; WAL cleared after Audit Store confirms |
+| **Hash Chain** | Per-entity tamper-evident chain: record_hash + previous_record_hash; chain breaks detectable and trigger security alerts |
+| **Mode 4 External Policy Evaluator** | Black box query-enrichment policy provider — DCM sends query, external system evaluates and/or enriches, returns structured result; logic is opaque to DCM |
+| **Black Box Query-Enrichment** | Mode 4 operation where an external system simultaneously evaluates request data and injects enrichment fields into the payload |
+| **audit_token** | Provider-issued reference in Mode 4 responses enabling cross-system audit correlation between DCM audit trail and provider's internal logs |
+| **data_request_spec** | Mode 4 registration declaration of which fields the provider is authorized to receive, with classification ceiling per field |
+| **Policy Naturalization** | Translation of external policy schemas (OSCAL, XCCDF, CIS JSON) into DCM policy format — Mode 3 External Policy Evaluator mechanism |
+| **Policy Group** | Cohesive versioned collection of policies addressing a single identifiable concern — the unit of policy reuse |
+| **Policy Profile** | Complete DCM configuration for a specific use case — composed of Policy Groups |
+| **External Policy Evaluator** | Fifth DCM provider type — external authoritative source supplying policies into DCM |
+| **concern_type** | Policy Group classification: technology, compliance, sovereignty, business, operational, security |
+| **minimal profile** | Least restrictive built-in profile — advisory enforcement, auto-tenant, home lab / evaluation |
+| **sovereign profile** | Most restrictive built-in profile — hard tenancy, deny_all cross-tenant, maximum sovereignty |
+| **Lifecycle Constraint Enforcer** | DCM control plane component monitoring realized entities against time constraints |
+| **cross_tenant_authorization** | Explicit authorization record for cross-tenant relationship — specifies who, what, when, where |
+| **explicit_only** | Default cross-tenant hard tenancy setting — ALL cross-tenant requires explicit authorization |
+| **PENDING_REVIEW** | Entity state during paused rehydration tenancy conflict — awaiting resolution |
+| **Policy Gap Record** | Audit record for fields absent from reserve query with no applicable policy — records implicit_approval |
+| **Shared Resource** | An entity within a single Tenant with active relationships from multiple parent entities; governed by sharing_model and reference counting |
+| **sharing_model** | Entity-level declaration of shareability, active_relationship_count, and on_last_relationship_released behavior |
+| **active_relationship_count** | DCM-maintained count of active constituent/operational relationships on a shared resource |
+| **save_overrides_destroy** | The lifecycle action hierarchy rule: retain > notify > suspend > detach > cascade > destroy; most conservative action always wins |
+| **lifecycle_conflict_record** | Audit record created when multiple lifecycle action recommendations differ; carries severity, resolved action, and resolution rule |
+| **deferred_destruction_record** | Audit record created when a destructive lifecycle action is deferred because active_relationship_count is above minimum |
+| **Ingestion Model** | Unified DCM mechanism for bringing entities outside lifecycle control into DCM governance — covers V1 migration, brownfield discovery, and manual import |
+| **Ingestion Record** | Provenance record on every ingested entity — source, confidence, assignment method, enrichment history, promotion timestamp |
+| **`__transitional__` Tenant** | System-managed holding Tenant for unassigned ingested entities — cannot be deleted, renamed, or used for new provisioning |
+| **Ingestion Confidence** | `high | medium | low` — quality signal for auto-assignment; reflects how reliable the Tenant assignment is |
+| **Brownfield** | Existing infrastructure not yet under DCM lifecycle management — brought in via brownfield ingestion |
+| **V1 Migration** | Migration of pre-Tenant DCM V1 entities to V2 using the ingestion model |
+| **INGESTED state** | First ingestion lifecycle state — entity in DCM, minimal metadata, Tenant may be __transitional__ |
+| **ENRICHING state** | Second ingestion lifecycle state — Tenant assigned, metadata and relationships being completed |
+| **PROMOTED state** | Final ingestion lifecycle state — all requirements met, DCM assumes full lifecycle ownership |
+| **DCM Event Type** | A versioned, typed event that DCM can emit — follows universal versioning model |
+| **Event Type Registry** | DCM-maintained registry of standard event types — extensible like the Resource Type Registry |
+| **Webhook Registration** | Declaration by a consumer, provider, or external system of which DCM events they want to receive and where |
+| **Discussion Topics** | Living document (DISCUSSION-TOPICS.md) capturing unresolved design decisions and topics requiring further discussion |
+| **Override Preference** | Level 2 simple override declaration — single `override: allow|constrained|immutable` on a field |
+| **Override Matrix** | Level 3 per-actor permission matrix for fields requiring nuanced governance |
+| **Field Override Control** | Graduated mechanism (Levels 1-3) governing who can change what field, under what conditions |
+| **Structural Layer Rules** | Non-configurable rules enforced by the Request Payload Processor — layer immutability, precedence order, chain integrity |
+| **Business Override Rules** | Configurable override control rules enforced by the Policy Engine via override metadata |
+| **Trusted Grant** | Explicit expansion of override permissions issued by a higher-authority actor to a specific entity UUID |
+| **Actor Registry** | Extensible registry of override actors — built-in (policy.global, consumer_request, sre_override, etc.) plus custom actors |
+| **Basis for Value** | Field metadata documenting why a particular value was set |
+| **Baseline Value** | Field metadata recording the original default value before any override was applied |
+| **Entity Relationship** | Universal bidirectional relationship between any two entities — internal or external |
+| **Entity Relationship Graph** | Complete traversable graph of all entity relationships in DCM |
+| **Relationship UUID** | UUID identifying a specific relationship — same on both sides of the bidirectional record |
+| **Relationship Type** | Fixed vocabulary describing the nature of a relationship (requires, depends_on, contains, references, peer, manages) |
+| **Relationship Role** | Semantic label describing the function a related entity serves (compute, storage, networking, business_unit, etc.) |
+| **Relationship Nature** | Structural character of a relationship — constituent, operational, or informational |
+| **Lifecycle Policy** | Declares what happens to an entity when its related entity changes state |
+| **Bundled Declaration Expansion** | Processor mechanism expanding bundled fields (e.g., storage in VM request) into first-class entities and relationships |
+| **Information Provider** | DCM provider type serving authoritative external data DCM references but does not own |
+| **External Entity Reference** | Stable pointer record DCM uses to reference data in an external system |
+| **Standard Data** | DCM-defined fields on an information type — used for lookups and operational decisions |
+| **Extended Data** | Organization-defined fields added to an information type — carried in payload but not used for DCM core operations |
+| **Information Type** | Registry entry for a category of external data (Business.BusinessUnit, Identity.Person, etc.) |
+| **Stable External Key** | The external system's UUID used as the primary lookup anchor for an external entity reference |
+| **Trust But Verify** | DCM's approach to external references — trusts external data is correct, verifies references remain valid |
+| **DCM Operator Interface Specification** | The formal technical contract defining how Kubernetes operators integrate with DCM as Service Providers |
+| **DCM Operator SDK** | Go library implementing the Operator Interface Specification — enables Level 1 conformance in one day |
+| **Conformance Level** | The level of DCM integration an operator implements — Level 1 (basic), Level 2 (standard), Level 3 (full) |
+| **Naturalization (Kubernetes)** | Translating DCM Requested State into a Kubernetes CR |
+| **Denaturalization (Kubernetes)** | Translating Kubernetes CR status back into DCM Realized State format |
+| **Unsanctioned Change** | A change to a DCM-managed CR that did not originate from a DCM request — detected via missing DCM request annotation |
+| **Operator Adapter** | A component implementing the DCM Service Provider API on behalf of an operator that cannot be modified directly |
+| **CNCF Sandbox** | The initial CNCF maturity level — target for initial DCM project submission |
+| **Conformance Test Suite** | The test suite that validates an operator's implementation against the DCM Operator Interface Specification |
+| **Intent State** | The immutable record of a consumer's original declaration — captured before any assembly or policy evaluation |
+| **Requested State** | The fully assembled, policy-processed, provider-ready payload — the authoritative record of what DCM instructed a provider to build |
+| **Realized State** | The provider-confirmed record of what was actually built — append-only event stream keyed by entity UUID |
+| **Discovered State** | What DCM observes actually existing through active discovery — ground truth for drift detection |
+| **Data Store Contract** | The interface specification through which DCM defines persistence requirements — implemented by PostgreSQL |
+| **GitOps Store** | PostgreSQL store contract for Intent and Requested State — branch, PR, merge, CI/CD hook semantics |
+| **Event Stream Store** | PostgreSQL store contract for Realized and Discovered State — append-only, entity-keyed, replayable |
+| **Search Index** | Queryable projection of GitOps stores — explicitly non-authoritative, rebuilt from Git on demand |
+| **Provider-Portable Rehydration** | Rehydration with provider selection re-evaluated through current placement policies |
+| **Faithful Rehydration** | Rehydration honoring the original provider selection from the source record |
+| **Pinned Policy Version** | Rehydration using policies as of a specific historical timestamp — requires elevated authorization |
+| **Audit Component** | Separate DCM component aggregating provenance events from all stores — compliance-grade, long-retention |
+| **Observability Store** | Time-series metrics, traces, and logs — operational, not compliance-grade |
+| **Third Rail** | Direct API ingress path — bypasses PR workflow, never bypasses governance |
+| **Layer Domain** | Organizational and architectural home of a layer — system, platform, tenant, service, provider |
+| **Layer Handle** | Human-readable stable identifier for a layer — format: domain/layer_type/name |
+| **Priority Schema** | Hierarchical dotted-notation priority system for deterministic layer conflict resolution |
+| **Priority Value** | Numeric dotted-notation priority — higher value wins; no ceiling, infinitely insertable in both directions |
+| **Immutable Ceiling** | `immutable_ceiling: absolute` — explicit declaration that a field lock cannot be overridden by any future higher-priority policy; the nuclear option for true non-negotiables |
+| **Priority Label** | Semantic context for a priority value — human-readable, does not affect ordering |
+| **Reference Priority Taxonomy** | DCM's advisory priority category ranges — not enforced, organizations adopt/adapt/ignore |
+| **Artifact Metadata** | Universal metadata block on every DCM artifact — identity, ownership, creation, modification history, contact |
+| **created_by** | Artifact metadata field — the audit record of who physically submitted the artifact |
+| **owned_by** | Artifact metadata field — the accountability record of who is responsible and receives notifications |
+| **created_via** | Artifact metadata field — ingestion path: pr, api, migration, system |
+| **Proposed Shadow Execution** | Policy artifact in proposed status executing against real traffic — output captured, never applied |
+| **Proposed Evaluation Record** | Shadow output record for a proposed policy — what it would have done on a real request |
+| **Validation Dashboard** | Review interface showing aggregate shadow output for proposed policies before activation |
+
+---
+
+## SECTION 56 — COMMUNITY QUESTIONS RESOLVED
+
+All 21 previously open community/implementation questions are now resolved. Key decisions:
+
+### Kubernetes Compatibility (5 resolved)
+- **Namespace → Tenant mapping:** brownfield ingestion model handles pre-existing namespaces; each namespace maps to one DCM Tenant; resources without ownership go to `__transitional__` Tenant
+- **Cluster boundary:** DCM manages across multiple clusters; `Platform.KubernetesCluster` is a resource type DCM provisions, not DCM's own boundary; Tenant is the boundary
+- **Admission webhooks vs Policy Engine:** complementary layers — admission webhooks enforce cluster-native policy, DCM Policy Engine enforces DCM request policy; defense in depth, not duplication
+- **Kubernetes Information Provider:** separately deployed Information Provider following the unified base contract; no built-in providers in DCM
+- **Managed K8s (EKS/GKE/AKS):** managed clusters register as Service Providers of `Platform.ManagedKubernetesCluster`; DCM manages workloads within, not the control plane
+
+### CNCF Strategy (5 resolved)
+- **Submission scope:** Operator Interface Specification as a CNCF specification project first; DCM project submission follows after Level 2 reference implementation
+- **Named adopters:** minimum 2 named evaluators + 1 FSI design partner before submission; project team action item
+- **TOC sponsor:** target App Delivery TAG and Runtime TAG; SIG engagement surfaces sponsors; project team action item
+- **SIG engagement timing:** BEFORE Sandbox submission; SIG App Delivery and SIG Cluster Lifecycle; Cluster API overlap must be addressed pre-submission
+- **Level 2 timeline:** scope is now formally defined (dispatch/cancel/discover + realized state + governance matrix + health check); team estimates timeline against defined scope
+
+### Operator Interface Specification (6 resolved)
+- **CNCF submission:** specification project (not sandbox project requiring implementation); SIG engagement first
+- **Conformance certification:** self-certified via automated test suite (low friction gate) + optional DCM Verified badge via project review
+- **Cluster-scoped resources — two models:** (A) **Cluster as a catalog item (example):** When a Service Provider offers Kubernetes clusters as a resource type, a Tenant that owns a provisioned cluster entity owns all cluster-scoped resources within it — the cluster entity is the ownership boundary; (B) **Shared cluster infrastructure:** cluster-scoped resources governing shared multi-tenant cluster infrastructure belong to `__platform__` Tenant. Note: Cluster-as-a-Service is an example Service Provider implementation, not a DCM architectural feature — DCM treats the cluster as any other resource entity
+- **Non-Go frameworks:** spec is language-agnostic; Go SDK is reference implementation; community Java/Python SDKs encouraged; not maintained by DCM project in v1
+- **Cluster API as an example Service Provider:** A CAPI-based operator can register as a Service Provider for a `Platform.KubernetesCluster` resource type — this is an example of what DCM's Provider model enables, not a special architectural feature. DCM has no built-in knowledge of Kubernetes; a CAPI Service Provider is structurally identical to any other Service Provider. Once provisioned, the cluster entity can optionally register as a nested Service Provider for workload resources (the Meta Provider pattern — composing compute + network + storage + DNS + credentials)
+- **Level 0:** exists — label-based passive discovery, no operator code changes; DCM discovers and tracks but does not control; lowest adoption friction
+
+### Operator SDK (5 resolved)
+- **Language-agnostic adapter:** not needed — spec is language-agnostic; Go SDK is reference only
+- **DCM unavailability:** local durable queue (SQLite); replay on reconnect; DEGRADED mode on overflow with QUEUE_OVERFLOW audit + alert; never drop silently
+- **Dynamic field resolution:** Information Provider reference in field mapping; DCM resolves during layer assembly; keeps logic in Policy Engine with full provenance
+- **Testing framework:** mock DCM test harness ships as first-class SDK component; configurable failure/delay injection; required for Level 2 conformance
+- **Prometheus metrics:** mandatory; 6 standard metrics (registration_status, event_delivery_total, event_delivery_duration, queue_depth, dispatch_duration, discovery_cycle_duration); required for Level 2 conformance
+
+**Zero remaining unresolved architectural questions.** Remaining open items are project team action items (named adopters, TOC sponsor, KubeVirt timeline).
+
+---
+
+## SECTION 57 — PREVIOUSLY OPEN QUESTIONS (NOW CLOSED)
+
+These items are explicitly unresolved. Do not make assumptions about them — flag them and ask for guidance.
+
+| # | Question | Area |
+|---|----------|------|
+| 1 | Where should data caches live? (Hub DCM, Regional DCM, Sovereign DCM, all?) | Data Model |
+| 2 | Should cache synchronization be push, pull, or both? | Data Model |
+| 3 | Which cache is authoritative when caches diverge? | Data Model |
+| 4 | What mechanism maintains consistency across distributed caches? | Data Model |
+| 5 | Should the data model allow embedded target-technology-specific data bundles? | Data Model |
+| 6 | How are the four states represented physically? | Data Model |
+| 7 | Performance impact of field-level provenance at scale — optimization strategies? | Data Model |
+| 8 | Should provenance metadata be inline or in a linked provenance document? | Data Model |
+| 9 | What is the governance model for proposing new Resource Types to the registry? | Catalog |
+| 10 | Should the registry support a formal review/approval workflow? | Catalog |
+| 11 | What is the minimum sunset period for deprecated definitions? | Catalog |
+| 12 | Should version constraints in requests be strictly enforced or advisory? | Catalog |
+| 13 | How are conflicts resolved when multiple providers satisfy all narrowing criteria equally? | Catalog |
+| 14 | Should the registry be distributed or centralized? Sovereignty implications? | Catalog |
+| 15 | Trust validation mechanism for provider certification | Providers |
+| 16 | Audit vs. Observability — are these truly separate components? | Control Plane |
+| 17 | Message Bus — should it be exposed as consumer ingress or egress only? | Control Plane |
+| 18 | GateKeeper vs. Validation policy distinction — needs better examples | Policy Engine |
+| 19 | How are conflicting Service Layers at the same precedence level resolved? | Data Layers | ✅ Resolved — priority schema + ingestion conflict detection |
+| 20 | Should Core Layers be ordered within their precedence level? | Data Layers | ✅ Resolved — priority schema provides deterministic ordering |
+| 21 | Can a consumer explicitly exclude a layer from their request? | Data Layers |
+| 22 | How are Service Layers registered and versioned relative to their Service Provider registration version? | Data Layers |
+| 23 | Should assembly support conditional layer inclusion — a layer only applied if a specific field value is present? | Data Layers |
+| 24 | How does the layer chain interact with service dependencies — does each dependent service get its own chain? | Data Layers |
+| 25 | For Hybrid Transfer — what is the maximum number of ownership transfers allowed? | Entities |
+| 26 | For Whole Allocation of bare metal — how is indivisibility enforced at the provider level? | Entities |
+| 27 | Should capacity confidence ratings trigger automatic actions (e.g., LOW triggers Mode 1 query)? | Entities |
+| 28 | For Process Resources — should there be a maximum execution time before DCM escalates? | Entities |
+| 29 | How does SUSPENDED state interact with cost analysis — is a suspended Entity still billable? | Entities |
+| 30 | How are dependency graphs versioned relative to catalog item versions? | Dependencies |
+| 31 | Should the dependency graph be stored as a separate entity or embedded in the request payload? | Dependencies |
+| 32 | How are cross-tenant dependencies handled? | Dependencies | ✅ Resolved — governed by REL-010/011/012; DEP-001/002/003 for dependency graph specifics; explicit_only default; cross_tenant_authorization required |
+| 33 | Should there be a maximum dependency graph depth? | Dependencies |
+| 34 | How does the dependency graph interact with the Meta Provider model? | Dependencies |
+| 35 | Should DCM maintain a registry of well-known custom group types? | Grouping |
+| 36 | How does group membership interact with sovereignty — can a group span sovereignty boundaries? | Grouping |
+| 37 | When a Tenant is decommissioned, what happens to its resources and group memberships? | Grouping |
+| 38 | Should Resource Groups support time-bounded membership? | Grouping |
+| 39 | How are group-level policies inherited by nested child groups — opt-in or opt-out? | Grouping |
+| 40 | Webhook registration model — Consumer API, Provider Registration, or dedicated Webhook API? | Webhooks |
+| 41 | Full DCM event taxonomy and whether it should be a versioned registry | Webhooks |
+| 42 | Webhook payload format — full state payload vs reference + event type | Webhooks |
+| 43 | Webhook authentication model for outbound calls | Webhooks |
+| 44 | Webhook retry and reliability obligations | Webhooks |
+| 45 | Webhook ordering guarantees | Webhooks |
+| 46 | Relationship between webhooks and the Message Bus | Webhooks |
+| 47 | Should provider webhook support be mandatory in the Provider Contract? | Webhooks |
+| 48 | Tenant vs platform-level webhook scoping | Webhooks |
+| 49 | Should webhook registrations declare which payload schema version they expect? | Webhooks |
+| 50 | Should override_preference be declarable in layer definitions as a hint to the Policy Engine? | Override Control |
+| 51 | When immutable is set by a Global policy, can a higher-priority Global policy still override it? | Override Control | ✅ Resolved — execution order makes default immutable effectively absolute; immutable_ceiling: absolute provides explicit forward-looking protection |
+| 52 | Should constraint_schema on a constrained field be visible to consumers in the Service Catalog UI? | Override Control |
+| 53 | Enhancement gaps: storage/networking bundling vs. dependency model — V1 simplification or new concept needed? | Enhancements |
+| 54 | Enhancement gaps: selected_provider as policy output vs. placement component concern | Enhancements | ✅ Resolved — Placement Engine is a distinct named component; nine-step assembly; reserve query; placement loop with policy phases; policy_gap_record for implicit approval; post-placement policy pass |
+| 55 | Enhancement gaps: migration path from V1 (no Tenant) to Tenant-mandatory | Enhancements | ✅ Resolved — unified ingestion model; __transitional__ Tenant; three-step ingest/enrich/promote; ING-001 through ING-007; also covers brownfield ingestion |
+| 56 | Enhancement gaps: should editable field concept from Catalog Item Schema be incorporated into Resource Type Spec? | Enhancements |
+| 57 | How are relationship conflicts resolved — two policies declare different lifecycle policies for the same relationship? | Entity Relationships | ✅ Resolved — standard Policy Engine authority hierarchy; lifecycle policy fields are just fields; no special case; REL-008 and REL-009 |
+| 58 | Should relationship roles be validated against the role registry at request time, or is validation advisory? | Entity Relationships |
+| 59 | How does the relationship graph interact with multi-tenant scenarios — can a relationship cross Tenant boundaries? | Entity Relationships | ✅ Resolved — nature governs; constituent never; operational with dual auth; informational unless deny_all; REL-010/011/012; allocated resource model |
+| 60 | Should there be a maximum relationship graph depth? | Entity Relationships |
+| 61 | How are shared entities represented — an entity required by multiple parents? | Entity Relationships | ✅ Resolved — sharing_model with active_relationship_count; save_overrides_destroy hierarchy; lifecycle_conflict_record; REL-015 through REL-019 |
+| 62 | How are conflicting Information Provider push events handled — two providers claim authority for the same record? | Information Providers |
+| 63 | Should Information Providers support write-back — DCM updating external records via the provider? | Information Providers |
+| 64 | How is the extended schema versioned when a provider adds or removes extended fields? | Information Providers |
+| 65 | Should DCM maintain a registry of well-known Information Providers to simplify onboarding? | Information Providers |
+| 66 | How does Information Provider verification interact with air-gapped environments? | Information Providers |
+| 67 | Should CNCF submission be for DCM as a whole or for the Operator Interface Specification as a standalone standard? | CNCF Strategy |
+| 68 | Which FSI consortium members will be named as public adopters in the CNCF submission? | CNCF Strategy |
+| 69 | How does the Namespace-to-Tenant mapping work for clusters with pre-existing namespaces? | Kubernetes Compatibility |
+| 70 | How does DCM interact with Kubernetes admission webhooks — duplicate or complement Policy Engine? | Kubernetes Compatibility |
+| 71 | Should the Kubernetes Information Provider be a built-in DCM component or separately deployed? | Kubernetes Compatibility |
+| 72 | How does DCM interact with managed Kubernetes services (EKS, GKE, AKS) where cluster management is outside user control? | Kubernetes Compatibility |
+| 73 | Should the SDK support non-Go operator frameworks via a language-agnostic REST adapter? | SDK Design |
+| 74 | How should the SDK handle DCM endpoint unavailability — queue events locally or drop? | SDK Reliability |
+| 75 | Should the entity UUID be preserved or regenerated on rehydration? | Four States |
+| 76 | For pinned policy version rehydration — what is the minimum authorization level? | Four States |
+| 77 | How are concurrent rehydration requests for the same entity handled? | Four States |
+| 78 | Should the Discovered Store retain full history or only a configurable window? | Four States |
+| 79 | Git repository structure for Intent and Requested stores — deferred pending Q54 | Storage |
+| 80 | Should data stores support multi-region replication as a declared capability? | Storage |
+| 81 | How are store failures handled — failover, queuing, or rejection? | Storage |
+| 82 | Should the Search Index be a separate store contract or bundled with the primary store? | Storage |
+| 83 | Should the Audit Store be a specialized store contract or a general event stream? | Audit |
+| 84 | Should DCM provide a default observability dashboard or only the telemetry? | Observability |
+| 85 | Should the background conflict validation job run on schedule or be event-triggered? | Data Layers |
+| 86 | What is the minimum validation review period for a proposed policy before activation? | Policy Engine |
+| 87 | Should the proposed shadow evaluation record be stored in the Audit Store or a separate validation store? | Storage |
+| 88 | Should organizations be able to define their own artifact status extensions beyond the five standard statuses? | Artifact Metadata |
+
+---
+
+## SECTION 58 — EXAMPLES AND USE CASES (dcm-examples.md)
+
+### Orchestration Examples (8 scenarios)
+
+**1.1 Basic request lifecycle** — submit → layers_assembled (GateKeeper + Transformation fire) → placement (6-step) → dispatch → realized. Shows named workflow + dynamic policies composing on same events.
+
+**1.2 Human approval gate** — GateKeeper with `requires_approval: true` flag inserts AWAITING_APPROVAL step without modifying named workflow. Manager approves via API → pipeline resumes.
+
+**1.3 Policy-gated hard block** — GateKeeper denies unsupported OS. Consumer receives clear error with policy_uuid and suggestion. No requires_approval flag → terminal FAILED.
+
+**1.4 Compound service (Meta Provider)** — VM + IP + DNS + LoadBalancer. Dependency-ordered execution (parallel where no deps). DNS fails (partial delivery) → DEGRADED state. Recovery: NOTIFY_AND_WAIT. Consumer chooses: accept degraded or trigger DNS retry.
+
+**1.5 Drift detection + remediation** — Discovery finds memory_gb changed (unsanctioned). Drift: significant + unsanctioned → critical. Policy: ESCALATE. Consumer submits REVERT → new request cycle → next discovery clean.
+
+**1.6 Dispatch timeout + late response** — Provider silent for PT30M → TIMEOUT_PENDING → Recovery: NOTIFY_AND_WAIT (prod profile). Provider responds at T+45M → LATE_RESPONSE_RECEIVED. Consumer chooses DISCARD_AND_REQUEUE.
+
+**1.7 Federation-routed request** — Local providers at capacity. Placement queries Hub DCM (Peer DCM provider). Hub routes to Regional DCM B. Governance Matrix checked at each hop. Realized State flows back chain. entity_uuid preserved.
+
+**1.8 Brownfield ingestion** — Discovery finds unmanaged VM. Orchestration Flow Policy: discover → INGEST → ENRICH (CMDB query) → await operator → PROMOTE to tenant. Drift detection activated post-promotion.
+
+### Provider Examples (4 scenarios)
+
+**2.1 Service Provider dispatch cycle** — Full payload showing DCM unified format → naturalize to OpenStack Nova → execute → denaturalize back. Shows provenance on injected fields (monitoring_endpoint from policy).
+
+**2.2 Information Provider enrichment** — CMDB query during layer assembly. Response with confidence descriptor. Fields injected with source_type: information_provider and source_uuid.
+
+**2.3 External Policy Evaluator Mode 3 (OPA sidecar)** — Exact OPA HTTP API call format, input document structure, response parsing.
+
+**2.4 notification service delivery** — VLAN decommission event. Audience: owner (NetworkOps) + 2 stakeholders (required stakes) + 1 observer (optional stake). Per-actor envelopes with stakeholder_reason field. Slack message format.
+
+### Consumer API Examples (2 scenarios)
+
+**3.1 Complete request lifecycle** — catalog browse → describe (see constraints) → submit → poll status sequence → get realized resource with confidence scores.
+
+**3.2 Provider update approval** — Provider submits auto-scale notification → REQUIRES_CONSUMER_APPROVAL → consumer reviews pending notifications → approve → new Realized State.
+
+### Admin API Examples (2 scenarios)
+
+**4.1 Provider registration review** — List pending registrations (with validation results) → approve with review notes.
+
+**4.2 Orphan resolution** — List orphan candidates → investigate → adopt_into_dcm → entity promoted to full lifecycle.
+
+### Registration Flow Example (1 scenario)
+
+**5.1 Complete provider onboarding** — Admin issues registration token → provider submits registration payload (mTLS + token) → 8 automated validation checks shown → PENDING_APPROVAL → admin reviews → ACTIVE. Full capability declaration structure for Service Provider.
+
+---
+
+## SECTION 59 — CAPABILITIES MATRIX (167 capabilities, 26 domains)
+
+The DCM Capabilities Matrix contains 167 capabilities across 26 domains. Each capability row specifies what consumers, service providers, and platform admins can do, along with dependencies.
+
+**Current domain count: 26**
+IAM, CAT, REQ, PRV, LCM, DRF, POL, LAY, INF, ING, AUD, OBS, STO, FED, GOV, ACC, ZTS, GMX, DRC, FCM, SMX, MPX, CPX, DPO, ATM, EVT, VER (26 domain prefixes; see taxonomy for full names)
+
+**Recent additions (docs 29–34):**
+- SMX (Scoring Model, doc 29): risk scoring, approval routing, signal weights, governance matrix
+- MPX (Meta Provider, doc 30): compound service definition, constituent orchestration via dependency graph
+- CPX (credential management service, doc 31): credential lifecycle, rotation, revocation, profile-governed security
+- ATM (Authority Tier, doc 32): dynamic ordered tier list, custom tiers, degradation gate, impact detection
+- EVT (Event Catalog, doc 33): 82 event types, base envelope, payload schemas, EVT-001–007
+- VER (API Versioning, doc 34): breaking change definition, deprecation lifecycle, version discovery
+
+**SMX-008 hard constraint:** auto_approve_below ≤ 50 in ALL profiles
+**ATM-002 hard constraint:** auto tier max_score ≤ 50 in ALL profiles
+**CPX-001 absolute:** credential values NEVER in DCM stores in ANY profile
+**EVT-007:** audit.* critical events are non-suppressable
+
+
+## SECTION 60 — DOCUMENTATION STRUCTURE
+
+DCM documentation follows a hierarchical structure:
+
+```
+dcm-docs/ (internal working docs)
+├── README.md
+├── DCM-AI-PROMPT.md # This file
+├── DISCUSSION-TOPICS.md
+├── data-model/ # → website: /docs/architecture/data-model/
+│ ├── 00-context-and-purpose.md ✅
+│ ├── 02-four-states.md ✅
+│ ├── 03-layering-and-versioning.md ✅
+│ ├── 05-resource-type-hierarchy.md ✅
+│ ├── 06-resource-service-entities.md ✅
+│ ├── 07-service-dependencies.md ✅
+│ ├── 08-resource-grouping.md ✅
+│ ├── 09-entity-relationships.md ✅
+│ ├── 10-information-providers.md ✅
+│ ├── 11-storage-providers.md ✅
+│ └── 12-audit-provenance-observability.md ✅
+└── specifications/ # → website: /docs/architecture/specifications/
+ ├── dcm-operator-interface-spec.md ✅
+ ├── 11-kubernetes-compatibility.md ✅
+ ├── dcm-operator-sdk-api.md ✅
+ └── cncf-strategy.md ✅
+
+Website structure (Hugo / Hextra):
+content/
+├── _index.md # Homepage — 4 bottom cards
+└── docs/
+ ├── _index.md # Docs index
+ ├── architecture/
+ │ ├── _index.md # Architecture section — 3 cards
+ │ ├── overview.md # High Level Design ✅
+ │ ├── data-model/
+ │ │ ├── _index.md # Data Model section — 11 cards
+ │ │ └── (11 data model docs) ✅
+ │ └── specifications/
+ │ ├── _index.md # Specifications section — 4 cards
+ │ └── (4 specification docs) ✅
+ └── enhancements/
+ ├── _index.md
+ └── (existing enhancement stubs — unchanged)
+```
+
+---
+
+## SECTION 61 — SCORING MODEL (doc 29)
+
+### Governing Principle
+Questions of fact use boolean gates. Questions of degree use scoring. Secondary test: "Can a regulator accept 'the score was below threshold' as a complete explanation?" If not — boolean.
+
+### GateKeeper enforcement_class (required field)
+- `compliance` — boolean deny gate. Default and fail-safe if omitted. Used for: regulatory requirements (PHI→BAA, sovereign data), security hard requirements, anything where score-around creates legal liability.
+- `operational` — contributes `risk_score_contribution` (weight 1–100) to request risk score. Used for: cost ceilings, size limits, quota pressure, off-hours context, business rule preferences.
+
+### Validation output_class (required field)
+- `structural` — boolean pass/fail. Default and fail-safe. Missing required fields, type errors, broken references.
+- `advisory` — completeness score contribution + warning list. Never blocks. Recommended fields absent, unusual values, low confidence.
+
+### The Five Scoring Signals (aggregate → request_risk_score 0–100)
+1. **Operational GateKeeper score** (weight: 0.45 standard) — sum of risk_score_contribution from all fired operational GateKeepers, capped at 100
+2. **Completeness score** (weight: 0.15) — sum of advisory Validation contributions
+3. **Actor risk history score** (weight: 0.20) — decay-weighted (λ=0.1, half-life 7 days) history of actor's previous request outcomes; events: validation_failure(5), gatekeeper_deny(10), compliance_deny(20), policy_override(8), drift_caused(15), forced_decommission(12)
+4. **Quota pressure score** (weight: 0.10) — zero below 75% utilization; max(0, (util - 0.75) / 0.25) × 100 above
+5. **Provider accreditation richness** (weight: 0.10, inverse) — weighted portfolio sum; higher richness = lower provider risk contribution
+
+### Profile-Governed Thresholds → Approval Routing
+auto_approve (threshold)
+Default per profile: minimal(<45), dev(<40), standard(<25), prod(<15), fsi(<10), sovereign(<5)
+SMX-008 applies to ALL profiles including minimal — auto_approve_below may never exceed 50
+**SMX-008: auto_approve_below may never exceed 50 in any profile, including minimal.** minimal achieves higher effective auto-approval through lower signal weights, not higher thresholds.
+Signal weights must sum to 1.00 (validated at profile activation).
+
+### Profile Enforcement Class Overrides
+Profiles can promote operational→compliance or demote compliance→operational (non-regulatory only).
+SMX-003: policies with `regulatory_mandate: true` cannot be demoted. Set by platform admins. Audited.
+Threshold and override changes take effect immediately. Score Records are immutable — no retroactive changes.
+
+### Pipeline Sequence (doc 29, Section 8)
+1. Evaluate all policies
+2. Compliance GateKeeper fires → HALT (boolean deny, no score)
+3. Structural Validation fails → HALT (boolean fail, no score)
+4. Governance Matrix DENY → HALT (always boolean, never scored — SMX-004)
+5. Collect operational GateKeeper contributions → Signal 1
+6. Collect advisory Validation contributions → Signal 2
+7. Fetch actor risk history → Signal 3
+8. Calculate quota pressure → Signal 4
+9. Calculate provider accreditation richness → Signal 5
+10. Aggregate with profile weights → request_risk_score
+11. Apply profile thresholds → routing_decision
+12. Write Score Record to Audit Store (SMX-010: required for every scored request)
+13. Route: auto_approve | queue_for_review | queue_dual | queue_committee
+
+### What Is NEVER Scored
+Governance Matrix (SMX-004) · authentication · authorization · five-check boundary enforcement · lifecycle state transitions · unsanctioned change flag · TTL expiry · request status states
+
+### Score Exposure
+Consumer: risk_score, routing_decision, score_drivers (top 3, human-readable), advisory_warnings
+Platform admin: full Score Record — all signal breakdowns, weights, actor risk history detail
+Actor risk history never exposed to other consumers (privacy — SMX-007)
+
+### Score Record (immutable, Audit Store)
+score_record_uuid, request_uuid, entity_uuid, request_risk_score, routing_decision, routing_threshold_applied, profile_uuid, signal_breakdown (per signal: score, weight, weighted_contribution, fired_policies)
+
+### New API Endpoints
+Consumer: risk_score + advisory_warnings on POST /api/v1/requests response and GET status
+Admin: GET/PATCH /api/v1/admin/profiles/{name}/scoring · POST overrides · GET/POST /actors/{uuid}/risk-history · GET /scoring/audit
+Flow GUI: GET /flow/api/v1/graph/scoring-overlay · POST /flow/api/v1/simulate/score · Threshold slider in Profile Management view · Score breakdown panel in Simulation
+
+### SMX-001–010 System Policies
+SMX-001: GateKeeper must declare enforcement_class (compliance default). SMX-002: Validation must declare output_class (structural default). SMX-003: regulatory_mandate:true = no profile demotion. SMX-004: Governance Matrix always boolean. SMX-005: signal weights must sum to 1.00. SMX-006: Score Records immutable. SMX-007: actor risk history not exposed to other consumers. SMX-008: auto_approve_below ≤ 50. SMX-009: scoring_weight 1–100; aggregate capped at 100 before weighting. SMX-010: Score Record required for every scored request.
+
+### Capabilities
+SMX-001 through SMX-008 in Capabilities Matrix Domain 21. Total: 167 capabilities, 26 domains.
+
+---
+
+## SECTION 62 — META PROVIDER COMPOSABILITY MODEL (doc 30)
+
+### What a compound service definition Is (formerly "Meta Provider")
+
+> **Architecture update (April 2026):** "Meta Provider" is no longer a separate provider type. The concept is now **Compound Resource Type Specifications** — a Data concept in the Resource Type Registry, orchestrated by the Control Plane. Individual constituents are fulfilled by standard Service Providers. References to "Meta Provider" in earlier sections are historical. The authoritative model is 5 provider types: service_provider, information_provider, auth_provider, peer_dcm, process_provider.
+A **compound Service Provider** that uses other providers in the DCM catalog to fulfill a higher-order service. Its primary contribution is a **compound service definition** declaring constituent resource types, dependencies, and delivery requirements so DCM can place, sequence, and govern the constituents. The Meta Provider is NOT an orchestrator — it is a compound service definition plus a standard Service Provider for its own resource types.
+
+### Key Principle
+The Meta Provider declares the dependency graph. DCM executes it. Parallelism emerges from the graph — constituents with no unresolved dependencies dispatch concurrently. The Meta Provider does not manage sequencing, external placement, failure handling, or compensation.
+
+### provided_by (critical field on each constituent)
+- `self` — Meta Provider handles this constituent via standard Services API (naturalize/execute/denaturalize — same as any Service Provider)
+- `external` — DCM places with best available provider via Placement Engine (all sovereignty/accreditation/trust checks apply)
+- `` — DCM dispatches to specific named provider
+
+### depends_on → Execution Order
+Each constituent declares `depends_on: [component_id, ...]`. DCM reads this graph and dispatches in order — no dependencies first, then those whose dependencies are REALIZED. Parallelism within a round emerges from the graph. Meta Provider does NOT manage this.
+
+### required_for_delivery
+- `required` — failure triggers Recovery Policy; unrealized constituents cancelled
+- `partial` — failure noted; compound continues; composite status may be DEGRADED
+- `optional` — failure noted; execution continues unaffected
+
+### Division of Responsibility (authoritative — see doc 30 Section 4)
+**DCM:** catalog, layer assembly, policy/scoring, external placement (Placement Engine), dependency-ordered dispatch, failure handling (Recovery Policy), compensation (dependency-reverse decommission), composite Realized State assembly, drift detection, audit, lifecycle.
+**Meta Provider:** declares compound service definition; executes `self` constituents as standard Service Provider; implements standard decommission for `self` constituents.
+
+### Composite Entity Four States
+- **Intent:** Compound request stored as-is; no constituent expansion
+- **Requested:** DCM expands using compound service definition; Placement Engine resolves `external` providers; constituent blocks have component_id, provided_by, depends_on, required_for_delivery
+- **Realized:** DCM assembles from all constituent realized payloads; composite_status; synthesized composite_fields
+- **Discovered:** Via Meta Provider endpoint (opaque/selective) or per-constituent providers (transparent)
+
+### Composite Status — determined by DCM
+- `REALIZED` — all required constituents REALIZED
+- `DEGRADED` — required REALIZED; partial(s) failed; accepted if profile permits
+- `FAILED` — required constituent(s) failed → Recovery Policy → compensation in dependency-reverse order
+
+### Composition Visibility
+- `opaque` — top-level entity only; discovery via Meta Provider endpoint
+- `transparent` — all constituents as DCM entities; UUIDs = deterministic(parent_uuid + component_id); per-constituent drift detection
+- `selective` — declared sub-set as DCM entities
+
+### Rehydration
+Primary use case for dependency graph declaration. DCM sequences rehydration from `depends_on` graph in same order as provisioning. `external` constituents re-placed by Placement Engine. `self` constituents return to same Meta Provider.
+
+### Scoring
+Operational GateKeepers fire on compound payload (not per-constituent). Signal 5 (accreditation richness) = lowest richness score among required-constituent providers.
+
+### Nested Meta Providers
+Max depth 3 enforced by DCM at placement. Nested Meta Provider has no awareness it is a constituent — receives and responds with standard payloads.
+
+### MPX-001–MPX-008 System Policies
+MPX-001: self constituents use standard Services API. MPX-002: DCM derives ordering from depends_on. MPX-003: parallelism from graph, not Meta Provider. MPX-004: composite status determined by DCM. MPX-005: Recovery Policy governs failure/compensation. MPX-006: external placement by Placement Engine only. MPX-007: transparent UUIDs are deterministic. MPX-008: max nesting depth 3 enforced at placement.
+
+### Capabilities: MPX-001–MPX-007 (Domain 22 — 141 total across 23 domains)
+
+## SECTION 63 — CREDENTIAL PROVIDER MODEL (doc 31)
+
+### Two Credential Categories
+1. **DCM Interaction Credentials** — short-lived (PT15M–PT1H profile-governed), scoped to specific operation+entity+provider. Issued before every provider dispatch. Implements ZTS-002. Never stored beyond use.
+2. **Consumer-Facing Resource Credentials** — SSH keys, API keys, kubeconfigs, service account tokens, database passwords, x509 certificates. Issued as part of resource realization; delivered via Consumer API.
+
+### CPX-001 (most important): Values NEVER in DCM stores
+Credential values are never written to GitOps stores, Realized State Store, or Audit Store. DCM stores only metadata (UUID, type, scope, expiry, status). Values held by credential management service; retrieved via authenticated `value_retrieval_endpoint`.
+
+### Credential Record Fields
+credential_uuid, credential_type, status (active/rotating/revoked/expired), issued_at, valid_until, issued_to (actor/entity/component/provider UUID), scope (operations[], resource_types[], tenant_uuid), non_transferable:true, bound_to_ip (fsi/sovereign), value_retrieval_endpoint, value_retrieval_auth, rotation_of (parent UUID if rotation), service_provider_uuid, entity_uuid
+
+### Issuance Flows
+- **Resource credential:** after VM/resource realized → DCM sub-request to credential management service → metadata stored in Realized State → consumer retrieves value via authenticated endpoint
+- **Interaction credential:** before each provider dispatch → credential management service issues scoped cred → included in dispatch → expires PT15M regardless; new cred issued for each interaction
+- **Bootstrap:** special mechanism before credential management service is registered; see doc 17
+
+### Rotation Protocol
+Trigger types: pre_expiry (default), scheduled, security_event, actor_request, provider_initiated. Standard flow: issue new cred → transition window (both valid) → revoke old at window end → notify consumer. Window: P1D consumer creds; PT5M dcm_interaction; P7D x509. Emergency rotation (security_event): NO transition window — old revoked immediately; fastest-channel delivery of new.
+
+### Revocation Model
+Revocation Triggers: actor_deprovisioned, entity_decommissioned, security_event, provider_deregistered, actor_request, ttl_expired. Propagation: credential record → status:revoked → publish credential.revoked to Message Bus → all components refresh revocation cache within SLA (PT5M standard; PT1M fsi/sovereign) → credential management service invalidates stored value within SLA.
+
+### Use-Time Validation (CPX-002 enforcement)
+Providers must validate at use time (not just receipt): check revocation cache, verify valid_until, verify operation within scope, verify IP binding. Reject with 403 if any check fails. Cache refresh: ≤ PT1M standard; ≤ PT30S fsi/sovereign.
+
+### CPX-006: Actor Deprovisioning
+Triggers immediate revocation of ALL credentials issued to actor. Revocation events published to Message Bus BEFORE deprovisioning acknowledged.
+CPX-007: Entity decommissioning triggers revocation of all entity-scoped credentials before decommission confirmed. Decommission that cannot revoke enters COMPENSATION_IN_PROGRESS.
+
+### Consumer API Endpoints
+GET /api/v1/resources/{entity_uuid}/credentials — list credential metadata
+GET /api/v1/credentials/{uuid}/value — retrieve value (step_up_mfa if required); every retrieval audited with retrieval_uuid
+POST /api/v1/credentials/{uuid}/rotate — request rotation; returns old/new UUIDs + transition_window_ends
+
+### credential management service API Contract
+POST {issue_endpoint} · POST {rotate_endpoint} · DELETE {revoke_endpoint}/{uuid} · POST {validate_endpoint} (use-time check) · GET {list_endpoint}?entity_uuid=
+
+### Profile-Governed Credential Configuration (doc 31 Section 12)
+credential_profile block controls: permitted_credential_types (homelab: api_key/x509/ssh; sovereign: hsm_backed_key only) · max_lifetime per credential type per profile · scheduled_rotation_required (ALL profiles: true; minimal/dev allow manual trigger and P365D/P180D max intervals) · min_transition_window (minimal: PT0S; standard+: P1D) · value_retrieval_auth_required (minimal: bearer_token; prod: step_up_mfa; sovereign: mtls) · audit_every_retrieval (minimal: false; standard+: true) · idle_detection_threshold (minimal: P30D; dev: P14D; standard: P7D; prod: P3D; fsi: P1D; sovereign: PT12H — NEVER null) · ip_binding_required (minimal-prod: false; fsi/sovereign: true) · fips_140_level_required (minimal: 0; fsi: Level 2; sovereign: Level 3) · approved_algorithms (minimal: forbidden_algorithms list [MD5,SHA-1,DES,3DES,RSA<2048]; standard: Ed25519/ECDSA-P-384; fsi: FIPS-only; sovereign: HSM-generated only) · revocation_check_frequency (minimal: PT5M; fsi: PT30S; sovereign: PT15S) · revocation_sla (minimal: PT10M; sovereign: PT30S)
+
+### Compliance Domain Overlays (additive, never relaxing)
+hipaa: audit_every_retrieval:true, idle_detection:P7D, max rotation api_key:P90D
+pci_dss: max_rotation_interval:P90D (mandatory — req 8.3.9), min_password_complexity:12+4-classes
+fedramp_moderate: fips_level:1 · fedramp_high: fips_level:2, ip_binding:true · dod_il4: fips:2, ip_binding:true
+
+### AAL Mapping (NIST 800-63B)
+minimal/dev=AAL1 · standard=AAL2 (MFA for sensitive types) · prod=AAL2 (MFA all) · fsi=AAL2+ (hardware MFA, FIPS L2) · sovereign=AAL3 (hardware-bound, FIPS L3, tamper evidence)
+
+### New Fields on Credential Record
+algorithm (Ed25519/ECDSA-P-384/RSA-4096/HS256/etc.) · key_usage [authentication|signing|encryption] · retrieved_count_threshold (hours; idle alert threshold)
+
+### CPX-001–CPX-012 System Policies
+CPX-001: values never in DCM stores. CPX-002: every provider interaction must present scoped credential. CPX-003: revocation propagation within declared SLA. CPX-004: emergency rotation has no transition window. CPX-005: every value retrieval audited. CPX-006: actor deprovisioning revokes all actor credentials. CPX-007: entity decommission blocks on credential revocation. CPX-008: fsi/sovereign credentials must be IP-bound or hardware-attested.
+
+### Capabilities: CPX-001–CPX-007 (Domain 23 — 148 total across 23 domains)
+
+---
+
+## SECTION 64 — AUTHORITY TIER MODEL (doc 32 — 32-authority-tier-model.md)
+
+> **Full specification:** [32-authority-tier-model.md](data-model/32-authority-tier-model.md) — ordered tier list, custom tier contribution, dynamic threshold format, impact detection pipeline, ATM-001–ATM-012.
+
+### Core Model
+Authority tiers are a **named, ordered list**. Names are stable references; numeric weight is derived from list position at evaluation time — never hardcoded. Organizations can insert custom tiers between existing ones without breaking any existing name references.
+
+### Default Tier List (ordered)
+```
+auto → reviewed → verified → authorized
+```
+Position determines weight: auto=1, reviewed=2, verified=3, authorized=4.
+If org inserts `compliance_reviewed` after `verified`: auto=1, reviewed=2, verified=3, compliance_reviewed=4, authorized=5.
+All existing references to `authorized` still resolve correctly.
+
+### decision_gravity (stable severity vocabulary)
+- `none` → auto (automated; no human judgment)
+- `routine` → reviewed (standard authority; one qualified reviewer)
+- `elevated` → verified (elevated authority; separation of duties; two distinct reviewers)
+- `critical` → authorized (highest authority weight; DCMGroup + quorum required)
+
+decision_gravity is stable and position-independent. Custom tiers must declare consistent gravity.
+
+### Dynamic Threshold Format
+Profile thresholds are a named-tier list, NOT fixed column keys:
+```yaml
+approval_routing:
+ - { tier: auto, max_score: 24 } # ATM-002: never exceed 50
+ - { tier: reviewed, max_score: 59 }
+ - { tier: verified, max_score: 79 }
+ - { tier: authorized, max_score: 100 }
+```
+Custom tiers insert into this list. Existing tier names and ranges shift only for the affected range.
+
+### Custom Tiers
+Contributed via standard contribution pipeline; require `verified` tier approval (ATM-004). Must declare decision_gravity consistent with position (ATM-003). Cannot alter dcm_gate semantics of existing DCM system tiers (ATM-005).
+
+### Authorized Tier (dcmgroup_required: true)
+Requires a declared DCMGroup and quorum threshold. Organization defines: group composition (CTO, CISO, board, single delegate — any structure), how members deliberate, what external tools they use. DCM enforces that N members of the declared DCMGroup recorded decisions via Admin API. Organization provides everything else.
+
+### Tier Registry Change Impact Detection (doc 32 Section 7)
+When tier registry changes, DCM computes a **tier_impact_diff** — a structured comparison of proposed vs current ordered list — before activation:
+- **SECURITY_DEGRADATION**: tier's gravity or position decreased → blocks activation until reviewed and accepted (ATM-009)
+- **BROKEN_REFERENCE**: tier name removed but still referenced → blocks activation until resolved (ATM-010)
+- **PROFILE_GAP**: new tier inserted but profile threshold list not updated → warning, does not block (ATM-012)
+- **SECURITY_UPGRADE / STALE_WEIGHT**: informational, does not block
+
+Degradation review gate: each SECURITY_DEGRADATION must be accepted via `POST /api/v1/admin/tier-registry/{change_uuid}/accept-degradation` by a `verified` or `authorized` tier reviewer before activation.
+
+Impact report (ATM-011) stored in Audit Store for every registry change, at proposal and at activation.
+
+Admin API: POST /api/v1/admin/tier-registry/changes (propose) · GET .../impact (report) · POST .../accept-degradation · POST .../activate
+
+### ATM-001–ATM-012 System Policies
+ATM-001: tiers identified by name; weight derived from position. ATM-002: auto tier max_score ≤ 50. ATM-003: custom gravity consistent with position. ATM-004: custom tiers require verified-tier approval. ATM-005: custom tiers cannot change existing tier dcm_gate semantics. ATM-006: dcmgroup_required tiers must have DCMGroup declared before use. ATM-007: four gravity values are DCM vocabulary (org cannot add gravity values). ATM-008: approval records store weight at creation time for point-in-time audit.
+
+### Federation Tier Resolution
+Peer DCM instances may have different custom tier lists. Resolution strategy: `gravity_match` — match by decision_gravity, not tier name. Unknown peer tiers escalate to their declared gravity level.
+
+---
+
+## SECTION 65 — EVENT CATALOG (doc 33 — 33-event-catalog.md)
+
+> **Full specification:** [33-event-catalog.md](data-model/33-event-catalog.md) — authoritative source for all 82 DCM event types, payload schemas, urgency levels, EVT-001–EVT-007 system policies.
+
+### Base Envelope (all events share this)
+event_uuid (idempotency key — EVT-002: consumers must treat duplicates as already-processed) · event_type · event_schema_version · timestamp (from Commit Log — authoritative) · dcm_version · dcm_instance_uuid · subject (entity_uuid, entity_type, entity_handle, tenant_uuid, actor_uuid) · urgency (critical/high/medium/low/info) · payload (event-specific) · links (self, audit_record)
+
+### Event Domains (82 total across 26 domains)
+request.* (14): submitted → intent_captured → layers_assembled → policies_evaluated → requires_approval → approved → placement_complete → dispatched → compound_assembled → dependencies_resolved → realized/failed/gatekeeper_rejected/cancelled
+entity.* (13): realized, state_changed, modified, ttl_warning, ttl_expired, suspended, resumed, decommissioning, decommissioned, decommission_deferred, ownership_transferred, pending_review, expired
+drift.* (4): detected, severity_escalated, resolved, escalated
+provider.* (5): registered, deregistered, healthy, unhealthy, degraded
+provider_update.* (5): submitted, requires_approval, approved, rejected, auto_approved
+rehydration.* (5): started, paused, interrupted, completed, blocked
+policy.* (4): activated, deactivated, evaluated, shadow_result
+credential.* (4): rotating, revoked, idle, expired
+approval.* (4): decision_recorded, quorum_reached, window_expiring, expired
+tier_registry.* (4): proposed, impact_assessed, degradation_detected, activated
+audit.* (3): chain_integrity_alert, chain_break, forward_failed
+dependency.* (2): state_changed + stakeholder.resource_decommissioning
+allocation.* (2): pool_capacity_low, released
+ingestion.* (3): transitional_created, enriched, promotion_approved
+governance.* (3): catalog_item_deprecated, profile_changed, policy_trust_elevated
+security.*/sovereignty.*/federation.*/auth.*: unsanctioned_provider_write, sovereignty.violation, sovereignty.migration_required, federation.tunnel_degraded, auth.provider_failover
+
+### Urgency Levels
+critical (push + page if configured) · high (push) · medium (standard) · low (standard) · info (batch/webhook only)
+critical + audit.* events: NON-SUPPRESSABLE — EVT-005 and EVT-007
+
+### Schema Versioning
+event_schema_version increments ONLY on breaking changes (removing fields, changing types/semantics). Adding optional fields is NOT breaking. EVT-004.
+
+### Non-Standard Events
+Providers/extensions may publish non-standard events using reverse-DNS prefix (e.g. com.acme.custom_event). EVT-006.
+
+### EVT-001–EVT-007 System Policies
+EVT-001: all events must include base envelope. EVT-002: event_uuid is idempotency key. EVT-003: timestamp from Commit Log. EVT-004: schema version increments on breaking changes only. EVT-005: critical urgency → push delivery. EVT-006: non-standard events use reverse-DNS prefix. EVT-007: audit.* critical events are non-suppressable.
+
+---
+
+## SECTION 66 — API VERSIONING STRATEGY (doc 34 — 34-api-versioning-strategy.md)
+
+> **Full specification:** [34-api-versioning-strategy.md](data-model/34-api-versioning-strategy.md) — breaking change definition, deprecation lifecycle, version discovery, sunset behavior, VER-001–VER-009.
+
+### Versioning Model
+URL path versioning: `/api/v1/`, `/api/v2/`, etc. Version is per-API surface (Consumer, Admin, Provider/OIS, Flow GUI) — NOT per-endpoint. All endpoints in a surface share the same major version. Non-breaking changes do not change the URL.
+
+### Breaking Change Definition (VER-002)
+**Breaking:** removing fields/endpoints, changing field types, changing URL structure, tightening validation, changing HTTP status semantics, removing enum values, changing HTTP method.
+**NOT breaking:** adding optional fields, adding endpoints, expanding enums, relaxing validation, adding error codes, performance changes. When in doubt → treat as breaking.
+
+### Deprecation Lifecycle
+Profile-governed support windows:
+- minimal: 90 days notice, 180 days deprecated support
+- standard: 180 days / 365 days
+- prod: 365 days / 730 days (2 years)
+- fsi: 18 months / 3 years
+- sovereign: 2 years / 4 years
+
+Deprecated versions: fully functional until sunset. Bugs fixed; features not backported. `Deprecation`, `Sunset`, `Link` headers on every response (RFC 8594/RFC 9745). VER-003.
+
+### Version Discovery
+`GET /.well-known/dcm-api-versions` — lists all API surfaces, current/supported/deprecated versions, base URLs, changelog URLs.
+Per-version changelog: `GET /api/v{N}/changelog`
+Machine-readable migration guide (required by VER-008): `GET /api/v{N}/migration-guide`
+
+### Sunset Behavior
+After sunset: `410 Gone` with successor_version, migration_guide_url, sunset_date.
+Three events: `governance.api_version_deprecated`, `governance.api_version_sunset_warning` (30 days before), `governance.api_version_sunset`.
+
+### Version Negotiation
+URL path is authoritative. Optional `DCM-API-Version: v1` header for explicit pinning (returns 406 if sunsetted).
+`/api/latest/` alias exists but NOT for production — pin to specific version.
+
+### Preview Endpoints
+`/api/v{N}/preview/` — no stability commitment; may change without major version increment; not for production automation.
+
+### OIS (Provider API) Versioning
+Providers declare `ois_version` in capability registration. DCM maintains dispatch compatibility with all supported OIS versions during deprecation window. VER-009.
+
+### VER-001–VER-009 System Policies
+VER-001: URL path versioning only. VER-002: breaking change definition. VER-003: deprecation headers required. VER-004: deprecated versions fully functional until sunset. VER-005: support windows profile-governed. VER-006: latest alias not for production. VER-007: preview endpoints not stable. VER-008: migration guide required per new major version. VER-009: OIS dispatch compatibility during deprecation window.
+
+---
+
+## SECTION 67 — SESSION TOKEN REVOCATION (doc 35 — 35-session-revocation.md)
+
+> **Full specification:** [35-session-revocation.md](data-model/35-session-revocation.md) — session lifecycle, revocation triggers, revocation registry, token introspection, AUTH-016–AUTH-022.
+
+### Session Record
+session_uuid · actor_uuid · auth_provider_uuid · auth_method · mfa_verified · created_at · expires_at · status (active/refreshing/revoked/expired) · revocation_reason · revoked_at · revoked_by
+
+### Session Store
+Fast-queryable operational store (not GitOps-backed). Redis/Postgres (standard+) or in-memory (minimal/dev). Profile-governed TTLs: minimal PT8H → sovereign PT15M. Concurrent session limits: unlimited(minimal) → 1(sovereign).
+
+### Revocation Triggers
+actor_logout (single session, self) · actor_logout_all (all sessions, self) · actor_deprovisioned (all sessions — parallel with CPX-006) · actor_suspended · security_event (emergency, no grace period) · concurrent_limit_exceeded (oldest session evicted) · auth_provider_deregistered · credential_compromised · admin_forced_logout
+
+### Session Revocation Registry
+Fast-queryable store of revoked-but-not-yet-expired session UUIDs. ALL components that accept bearer tokens MUST check this on every request. Cache age: PT5M(minimal) → no cache(sovereign). AUTH-018.
+
+### Actor Deprovisioning (AUTH-016)
+Session revocation and credential revocation (CPX-006) are PARALLEL operations. Deprovisioning not acknowledged until BOTH complete. Neither blocks the other.
+
+### Emergency Revocation (AUTH-019)
+security_event trigger: immediate, no grace period. auth.security_session_revoked event: urgency critical, non-suppressable. SLA: PT30S(standard) → PT5S(sovereign).
+
+### Token Introspection
+POST /api/v1/auth/introspect (RFC 7662). Returns {active: true/false, session_uuid, actor_uuid, expires_at, mfa_verified, roles}. Requires introspection scope. AUTH-020.
+
+### Consumer API Session Endpoints
+DELETE /api/v1/auth/session (logout single) · DELETE /api/v1/auth/sessions (logout all) · GET /api/v1/auth/sessions (list active) · DELETE /api/v1/auth/sessions/{uuid} (revoke specific)
+Admin: POST /api/v1/admin/actors/{uuid}/revoke-sessions (force revoke, requires reason)
+
+### AUTH-016–AUTH-022 System Policies
+AUTH-016: deprovisioning fires session + credential revocation in parallel. AUTH-017: revocation SLA PT5M(minimal) → PT5S(sovereign). AUTH-018: all components check revocation registry. AUTH-019: emergency revocation = critical urgency, non-suppressable. AUTH-020: introspection endpoint requires introspection scope. AUTH-021: oldest session evicted at concurrent limit. AUTH-022: refresh tokens invalidated when parent session revoked.
+
+---
+
+## SECTION 68 — INTERNAL COMPONENT AUTHENTICATION (doc 36 — 36-internal-component-auth.md)
+
+> **Full specification:** [36-internal-component-auth.md](data-model/36-internal-component-auth.md) — component identity, Internal CA, bootstrap tokens, communication graph, ICOM-001–ICOM-009.
+
+### Two-Layer Enforcement
+Mesh layer (Istio/mTLS): prevents impersonation at transport. Application layer (DCM): enforces what each component is permitted to do. BOTH required. Network position grants zero trust — internal calls receive same boundary checks as external.
+
+### Component Identity
+Each component has: component_uuid · component_type · mTLS certificate (from Internal CA) · service_account_uuid · allowed_operations · allowed_targets list.
+
+### Component Types
+api_gateway · policy_engine · placement_engine · request_orchestrator · scoring_engine · drift_reconciler · lifecycle_enforcer · notification_router · audit_store · session_store · message_bus · service_provider_proxy
+
+### Communication Graph (enforced, not advisory)
+Consumer/Admin → API Gateway → Request Orchestrator → Policy Engine / Placement Engine / Scoring Engine
+All components → Session Store (revocation check) + credential management service Proxy (interaction creds)
+ICOM-004: components may ONLY call declared allowed_targets. Unauthorized source → 403 + ICOM_UNAUTHORIZED_SOURCE audit (urgency: high). ICOM-003.
+
+### Every Internal Call Requires
+1. mTLS certificate from Internal CA (transport identity)
+2. ZTS-002 scoped interaction credential (operation authorization) — scoped to specific operation + target component, valid PT5M max
+3. Correlation ID
+
+### Internal CA
+Per-deployment CA. Certificates: ECDSA-P-384, P90D lifetime, auto-renew P14D before expiry. CRL + OCSP endpoints. Internal CA root cert installed in ALL component trust stores at deploy time. ICOM-006, ICOM-009.
+
+### Bootstrap Protocol (ICOM-007)
+New component has no cert yet. Platform admin generates one-time bootstrap token (PT1H max). Component uses bootstrap token → gets first cert from Internal CA → token invalidated immediately. Kubernetes: token injected as Secret, deleted by component after cert acquisition. Unused tokens auto-expire at PT1H.
+
+### Certificate Compromise (ICOM-008)
+Compromised cert → added to Internal CA CRL immediately → all components refresh CRL within profile SLA (PT15S sovereign, PT1M standard) → ICOM_CERT_COMPROMISED audit (urgency: critical) → platform admin notified → new cert issued.
+
+### ICOM-001–ICOM-009 System Policies
+ICOM-001: mTLS required ALL internal calls, no exceptions. ICOM-002: interaction credential required IN ADDITION to mTLS. ICOM-003: unauthorized source → 403 + high-urgency audit. ICOM-004: components only call declared allowed_targets. ICOM-005: all internal calls audited. ICOM-006: component certs max P90D, Internal CA only. ICOM-007: bootstrap tokens one-time-use PT1H max. ICOM-008: compromised certs → CRL immediately. ICOM-009: Internal CA root in all trust stores; no external CA certs for internal comms.
+
+---
+
+## SECTION 69 — SCHEDULED AND DEFERRED REQUESTS (doc 37 — 37-scheduled-requests.md)
+
+> **Full specification:** [37-scheduled-requests.md](data-model/37-scheduled-requests.md) — scheduling model, dual policy evaluation, maintenance windows, Request Scheduler component, SCH-001–SCH-006.
+
+### Scheduling Model
+schedule.dispatch: immediate (default) | at (specific time with not_before/not_after) | window (maintenance window reference) | recurring (cron expression). Added as optional field on POST /api/v1/requests — no new submission endpoint.
+
+### SCHEDULED Status
+Request enters SCHEDULED status in Intent State after passing declaration-time GateKeeper. Visible in GET /api/v1/requests?status=SCHEDULED. Cancellable via DELETE /api/v1/requests/{uuid} before dispatch. request.scheduled event (info urgency).
+
+### Dual Policy Evaluation (SCH-001)
+GateKeeper runs at declaration time (fail fast) AND at dispatch time (validate against current state). Dispatch-time rejection → FAILED with schedule_policy_rejection (SCH-003). Data, quotas, policies may all change between declaration and dispatch.
+
+### Deadline Enforcement (SCH-005)
+not_after: if passed without dispatch → FAILED with schedule_deadline_missed. No retry. request.failed event (medium urgency).
+
+### Maintenance Windows
+Reusable named recurrence artifacts. Platform admin creates; consumers reference by window_uuid in schedule. Admin: POST /api/v1/admin/maintenance-windows. Consumer: GET /api/v1/maintenance-windows.
+
+### New Events (added to doc 33)
+request.scheduled · request.schedule_cancelled · request.schedule_deadline_missed (17 total in request.* domain)
+
+---
+
+## SECTION 70 — REQUEST DEPENDENCY GRAPH (doc 38 — 38-request-dependency-graph.md)
+
+> **Full specification:** [38-request-dependency-graph.md](data-model/38-request-dependency-graph.md) — consumer-declared cross-request ordering, field injection, PENDING_DEPENDENCY status, RDG-001–RDG-006.
+
+### What This Is
+Consumer-declared ordering of INDEPENDENT requests. Distinct from: type-level deps (doc 07, resolved automatically) and Meta Provider composition (doc 30, platform team defines). Use when no Meta Provider exists for the compound deployment.
+
+### Request Dependency Group
+POST /api/v1/request-groups — submit multiple requests with depends_on declarations using local refs. Response includes group_uuid and per-request entity_uuids. GET /api/v1/request-groups/{uuid} for group status. DELETE to cancel.
+
+### PENDING_DEPENDENCY Status
+Dependent request waits in PENDING_DEPENDENCY until dependency reaches wait_for: acknowledged|approved|dispatched|realized (default: realized). Quota counted at group submission, not at dispatch. RDG-004.
+
+### Field Injection
+inject_fields: pass realized output fields from dependency (e.g. IP address) into dependent request's fields automatically at dispatch time. Subject to Transformation policies. RDG-003.
+
+### Failure Handling
+on_failure: cancel_remaining (dependents → CANCELLED with dependency_failed) | continue (only directly-dependent requests fail). Group timeout: all non-terminal → FAILED with group_timeout. RDG-005.
+
+### Constraints (RDG-001, RDG-002, RDG-006)
+Circular deps rejected at submission (422) — must be a DAG. Max 50 requests per group. Request may belong to at most ONE group (409 on second add).
+
+### New Events (added to doc 33)
+request.pending_dependency · request.dependency_met · request.group_completed · request.group_failed
+
+---
+
+## SECTION 71 — DCM SELF-HEALTH ENDPOINTS (doc 39 — 39-dcm-self-health.md)
+
+> **Full specification:** [39-dcm-self-health.md](data-model/39-dcm-self-health.md) — liveness, readiness, component health, Prometheus metrics, HLT-001–HLT-006.
+
+### Three Endpoints
+GET /livez (liveness — PT5S max, no external calls, unauthenticated, Kubernetes restarts on fail) ·
+GET /readyz (readiness — checks Session Store + Audit Store + Policy Engine + Message Bus + Auth Provider, unauthenticated, Kubernetes removes from LB on fail) ·
+GET /api/v1/admin/health (per-component detail, admin auth required)
+
+### Liveness (/livez)
+{status: pass|fail}. Fail if: deadlocked, Internal CA unreachable. Responds within PT5S. No DB reads, no external calls. HLT-002.
+
+### Readiness (/readyz)
+{status: pass|warn|fail, checks: {session_store, audit_store, policy_engine, message_bus, auth_provider}}. Fail if ANY core dependency unreachable. Warn if optional component degraded. Used for startup probe (failureThreshold 30 × 10s = 300s startup allowance). HLT-003, HLT-006.
+
+### Component Health (/api/v1/admin/health)
+Full per-component status: api_gateway, request_orchestrator, policy_engine, placement_engine, scoring_engine, request_scheduler, drift_reconciler, lifecycle_enforcer, discovery_scheduler, notification_router, session_store, audit_store, message_bus, internal_ca. Plus providers{registered/healthy/degraded/unhealthy} and auth_providers summary.
+
+### Prometheus Metrics (/metrics)
+dcm_requests_total · dcm_request_duration_seconds · dcm_requests_pending_dependency_total · dcm_policy_evaluations_total · dcm_sessions_active_total · dcm_session_revocations_total · dcm_drift_open_records_total · dcm_providers_healthy_total · dcm_internal_ca_certificates_active. HLT-005.
+
+### Kubernetes Manifest
+livenessProbe: /livez PT5S timeout, 10s period, 3 failures.
+readinessProbe: /readyz PT10S timeout, 5s period, 6 failures.
+startupProbe: /readyz PT10S timeout, 10s period, 30 failures (allows 300s startup).
+
+---
+
+## SECTION 72 — STANDARDS AND COMPLIANCE CATALOG (doc 40 — 40-standards-catalog.md)
+
+> **Full specification:** [40-standards-catalog.md](data-model/40-standards-catalog.md) — authoritative source for all RFCs, protocols, cryptographic standards, CNCF projects, and compliance frameworks used in DCM.
+
+### Internet Standards (IETF RFCs) — Normative
+Auth/AuthZ: RFC 7519 (JWT) · RFC 7517 (JWK) · RFC 7662 (Token Introspection) · RFC 6749 (OAuth 2.0) · RFC 4511 (LDAP) · RFC 7643/7644 (SCIM 2.0)
+Transport: RFC 8446 (TLS 1.3, preferred) · RFC 5246 (TLS 1.2, minimum) · RFC 5280 (X.509/CRL) · RFC 6960 (OCSP)
+Certificate enrollment: RFC 7030 (EST, preferred) · RFC 8555 (ACME) · RFC 8894 (SCEP, optional) · RFC 4210 (CMP, optional)
+API lifecycle: RFC 8594 (Sunset header, VER-003) · RFC 9745 (Deprecation header, VER-003)
+Health/discovery: RFC 8615 (Well-Known URIs, /livez /readyz /.well-known/dcm-api-versions)
+Data: ISO 8601 (all timestamps and durations) · RFC 8259 (JSON, all API bodies)
+
+### Cryptographic Standards
+Permitted algorithms: ECDSA P-384 (Internal CA, all profiles), AES-256-GCM, SHA-256 minimum, SHA-384/512 for fsi+
+RSA permitted only ≥ 2048 bits
+TLS: 1.3 preferred, 1.2 minimum — TLS 1.0/1.1 strictly prohibited in ALL profiles
+FIPS 140-2 Level 1+ (standard/prod), Level 2+ (fsi/fedramp), Level 3 (sovereign/dod_il4)
+FORBIDDEN (all profiles, no exceptions): MD5, SHA-1, DES, 3DES, RC4, RSA < 2048
+
+### Authentication Assurance Levels (NIST SP 800-63B)
+minimal/dev: AAL1 (single factor OK) · standard/prod: AAL2 (MFA required) · fsi: AAL2+ (phishing-resistant) · sovereign: AAL3 (hardware authenticator)
+
+### Compliance Frameworks and DCM Profile/Overlay Mapping
+HIPAA → fsi profile + hipaa overlay · PCI DSS → pci_dss overlay (P90D max rotation, 12-month audit) · FedRAMP Moderate/High → fedramp_moderate/fedramp_high overlays (NIST 800-53) · DoD IL4 → dod_il4 overlay (FIPS 140-2 Level 2, hardware attestation) · GDPR → sovereignty constraints + data classification · ISO 27001 → all profiles (risk-based approach) · SOC 2 → standard+ (Type II audit trail) · NIST SP 800-53 → FedRAMP profiles
+
+### CNCF Ecosystem (Graduated Projects)
+Kubernetes (deployment, CRD operator, resource model) · OPA/Open Policy Agent (policy engine backend, Rego) · Prometheus (metrics, /metrics endpoint) · OpenTelemetry (tracing, correlation IDs) · Istio (internal mTLS service mesh) · Argo CD / Flux (GitOps delivery) · SPIFFE (workload identity concept — inspiration for ICOM component identity model)
+
+### Operational Standards (Normative)
+W3C SSE / Server-Sent Events (GET /api/v1/requests/{uuid}/stream — live status without polling) · OpenAPI 3.1 (REST API spec format — consumer, admin, OIS specs) · Unix cron / POSIX (recurring schedule expressions in doc 37) · IANA health+json (RFC 8615 — /livez /readyz health response format) · GitOps / OpenGitOps v1.0 (all DCM artifacts in Git; PR-based contribution)
+
+### External CA credential management services (Optional)
+HashiCorp Vault PKI (native API + EST/ACME; recommended enterprise PKI for fsi/sovereign; operates as subordinate CA) · Venafi TLS Protect (ACME/EST/REST) · EJBCA (ACME/CMP/SCEP) — all implemented as x509_certificate credential management services per doc 31; NOT Auth Providers
+
+### Policy Family → Standards Mapping (doc 40 Section 9)
+AUTH → RFC 6749/7519/7662/OIDC/SCIM · CPX → FIPS 140/RFC 5280/8555/7030/8894/4210 · ICOM → RFC 8446/5280/SPIFFE/FIPS 140 · VER → RFC 8594/9745 · SES → RFC 7662/7009 · HLT → RFC 8615/Kubernetes probes · ZTS → NIST SP 800-207/800-63B · SCH/RDG → industry scheduling/DAG patterns · SMX/ATM → organizational risk governance
+
+---
+
+## SECTION 73 — OPERATIONAL REFERENCE (doc 41 — 41-operational-reference.md)
+
+> **Full specification:** [41-operational-reference.md](data-model/41-operational-reference.md) — GitOps store partitioning, store migration playbook, disaster recovery scenarios, OPS-001–007.
+
+### GitOps Store Partitioning (Section 1)
+Three strategies: tenant-shard (hash(tenant_uuid) % N shards — recommended), per-tenant (one repo per tenant — MSP/strict isolation), time-based archiving (active vs cold archive repos). Triggers: >50k entities, clone time >PT30S, >500 tenants, repo >10GB. Layer Store partitioned by resource domain (Compute.*, Network.*, etc.). Shallow clones for read-only consumers; read mirrors for audit/drift.
+
+### Store Migration Playbook (Section 2)
+5-phase pattern: Prepare → Backfill → Validate → Cutover → Decommission (after burn-in). Dual-write mode during migration. Audit chain must be unbroken across cutover (OPS-002). Source stays read-only for burn-in period — DO NOT decommission early (OPS-003). Profile-governed burn-in: P7D(minimal) → P90D(fsi/sovereign). Rollback available during burn-in by re-pointing to source. Common paths: SQLite→PostgreSQL (evaluation→standard), PostgreSQL→CockroachDB (HA requirement), GitOps repo restructuring (monorepo→shards via git filter-repo).
+
+### Disaster Recovery Scenarios (Section 3)
+5 scenarios with RTO/RPO per profile:
+- S1 Component failure: pod restart; RTO PT1M(sovereign)–PT15M(minimal); RPO 0 (stateless)
+- S2 Store failure: failover/restore; RTO PT5M(fsi)–PT2H(minimal); RPO 0(GitOps)–PT15M(Audit)
+- S3 Full control plane loss: redeploy + store reconnect; RTO PT5M(fsi)–PT30M(minimal); RPO 0
+- S4 Partial region loss: federation reroutes; sovereignty-scoped may block until region recovers
+- S5 Repave (complete loss, Git intact): bootstrap from Git, restore operational stores from backup, rehydrate managed resources; RTO PT2H(fsi)–PT24H(minimal)
+
+Post-recovery validation checklist (Section 3.6): /livez pass, /readyz pass, audit chain verify, store validate, drift scan, cert status, write post-incident audit record. OPS-005.
+
+### OPS-001–007 System Policies
+OPS-001: partitioning declared in deployment manifest. OPS-002: audit chain continuity across migration. OPS-003: source read-only during burn-in; do not decommission early. OPS-004: RTO must be met per profile. OPS-005: post-recovery checklist written to audit store. OPS-006: Audit Store minimum P365D retention all profiles. OPS-007: Git remotes must have push access from 2+ geographically separated locations.
+
+---
+
+## SECTION 74 — WEB INTERFACE SPECIFICATIONS (3 specs)
+
+> **Consumer GUI:** [dcm-consumer-gui-spec.md](specifications/dcm-consumer-gui-spec.md) — Consumer Portal wrapping all 16 Consumer API sections, bounded by tenancy
+> **Admin GUI:** [dcm-admin-gui-spec.md](specifications/dcm-admin-gui-spec.md) — Admin Panel wrapping all Admin API sections, role-gated
+> **Provider GUI:** [dcm-provider-gui-spec.md](specifications/dcm-provider-gui-spec.md) — Provider management shell + 11 type-specific extension sets
+
+### Unified Shell Architecture (GUI-010)
+ONE application, THREE role-gated surfaces: Consumer Portal (all actors) + Admin Panel (platform_admin/sre/auditor/security/policy_owner/finops) + Provider Management (provider_owner role). One login, one session token — navigation adapts to highest privilege level. Flow GUI (policy authoring) is linked/embeddable within Admin Panel.
+
+### Consumer Portal (dcm-consumer-gui-spec.md — 20 sections)
+Tenancy: X-DCM-Tenant header; ContextSelector in masthead (hidden for single-tenant actors).
+Navigation (PatternFly grouped left nav): Service Catalog | MY WORK (Requests, Resources, Dependency Groups) | Approvals [badge] | GOVERNANCE (Cost & Quota, Audit Trail, Contributions) | SETTINGS (Notifications, Sessions). **Hide, not disable** — unavailable items hidden entirely.
+Key capability — Live Status (GUI-002): SSE stream (GET /api/v1/requests/{uuid}/stream); events: status_change, progress_updated, approval_required, approval_recorded, heartbeat; constituent_status array for compound/Meta Provider requests; fallback to polling.
+Key capability — Request form: rendered from catalog item schema; live cost estimate; scheduling section (at/window/recurring); dependency group linking with field injection declaration.
+Key capability — ITSM Bridge (GUI-014, section 8): ITSM references (ServiceNow/Jira change records, CMDB CIs) displayed on entity Overview tab; ITSM notification service translates DCM events → ITSM records; ITSM systems call Admin API to record approval votes (DCM records decision, ITSM runs CAB process); CMDB sync is one-way DCM→CMDB via notification service subscription.
+Key capability — Consumer Audit Trail (section 11): own resource audit trail with Correlation ID trace through full pipeline; filterable by operation/type/date; export CSV.
+Key capability — Drift Report (section 6.3): cross-resource drift view with severity sorting; Revert All Critical bulk action; export drift report.
+Security: MFA step-up inline (no page leave); strict CSP (connect-src self + DCM API origin only; no inline scripts).
+
+### Admin Panel (dcm-admin-gui-spec.md)
+Platform health dashboard: component health grid, provider health summary, pending approvals count — all from GET /api/v1/admin/health.
+Tier registry editor: drag-and-drop reorder; impact report shows SECURITY_DEGRADATION(red)/BROKEN_REFERENCE(orange)/PROFILE_GAP(yellow)/SECURITY_UPGRADE(green); activate blocked until all blocking items resolved.
+Scoring editor: visual slider with hard-stop — auto_approve_below slider maximum is 50 (SMX-008/ATM-002); signal weights must sum to 100%.
+Flow GUI accessible via link or embedded iframe for policy_owner/sre roles.
+
+### Provider Management (dcm-provider-gui-spec.md)
+Common shell for ALL 5 provider types: overview, config, health history, audit trail, notifications.
+Provider ownership: declared at registration (owner_team_uuid); provider_owner role scoped per provider UUID.
+Service Provider extensions: capacity management (manual override for emergencies), managed entities with drift indicators, naturalization mapping viewer, test naturalization tool, interim status config.
+credential management service extensions: inventory (metadata only — NEVER values), rotation management, revocation registry search, external CA config (protocol, chain, CRL/OCSP status), algorithm compliance view (forbidden algorithms must be zero).
+Auth Provider extensions: connection status with failover chain, SCIM sync status, session statistics by auth method.
+
+### Security Model (all GUI surfaces)
+Navigation: hide not disable. Roles from session token; re-checked on token refresh. Tenancy: X-DCM-Tenant enforced UI + API (defense in depth). Step-up MFA: inline prompt without page navigation; cached PT10M. CSP: connect-src self + DCM API; no inline scripts; no eval().
+
+### RHDH Integration (dcm-rhdh-integration-spec.md)
+PRIMARY deployment model. 6 plugin packages as Dynamic Plugins (no RHDH rebuild): @dcm/backstage-plugin (frontend) · @dcm/backstage-plugin-backend (proxy + SSE relay + auth) · @dcm/backstage-plugin-catalog-backend (entity provider: DCMService + DCMResource) · @dcm/backstage-plugin-scaffolder-backend (dcm:request:submit, dcm:request:wait with live log, dcm:request:group, dcm:catalog:refresh) · @dcm/backstage-permission-policy (DCM roles → Backstage permissions) · @dcm/backstage-plugin-auth-backend (RHDH as DCM OIDC provider).
+Auth: RHDH/Keycloak → OIDC token exchange → DCM session token (cached in RHDH backend by backstage user ref). Tenancy: RHDH Group context → X-DCM-Tenant header (via dcm-tenant-{uuid} group naming convention).
+Entity model: DCMService kind (catalog items, namespace=dcm-catalog) auto-generated from DCM API every PT5M. DCMResource kind (realized resources, namespace=dcm-tenant-uuid) auto-synced from Realized State. Both search-indexed in RHDH.
+Scaffolder = request form: each DCM catalog item generates one Backstage Software Template from its JSON Schema. Template wizard → dcm:request:submit → dcm:request:wait (live log: step N/M, constituent status) → dcm:catalog:refresh → entity appears in catalog. NO separate request form UI needed.
+PatternFly nav: NavGroup(MY WORK > Requests/Resources/Groups) · NavItem with NotificationBadge (Approvals [count]) · NavGroup(GOVERNANCE > Cost&Quota/Contributions) · NavGroup(SETTINGS > Notifications/Sessions). Tenant via RHDH ContextSelector in masthead.
+Pre-built RHDH value: RHSSO/Keycloak auth (no auth code) · RBAC plugin (no-code role management) · TechDocs (DCM docs in-portal) · ArgoCD plugin (layer store visibility) · AAP plugin (Ansible provider job status) · OCM plugin (cluster management alongside DCM).
+Migration: Standalone SPA → RHDH via Dynamic Plugin loading only; no data migration, no API changes; 5-phase migration ending in standalone SPA decommission.
+
+---
+
+## SECTION 75 — ITSM INTEGRATION (doc 42 — 42-itsm-integration.md)
+
+> **Full specification:** [42-itsm-integration.md](data-model/42-itsm-integration.md) — 12th provider type, 8th policy type, 6 example policies, ITSM-001–007, ITSM-POL-001–004.
+
+### Design Principle
+DCM replaces the infrastructure ticket as the provisioning mechanism. ITSM integration is ADDITIVE — never required for DCM to function. Non-blocking by default. Organizations opt into blocking gates explicitly.
+
+### ITSM Integration (via process_provider)
+Bidirectional: outbound (DCM events → ITSM records) + inbound (ITSM approvals → DCM votes). Implements full base Provider contract (PRV-001). Supported systems: ServiceNow, Jira Service Management, BMC Remedy/Helix, Freshservice, PagerDuty, Opsgenie, ManageEngine, Cherwell, TOPdesk, generic_rest.
+Key capabilities: create/update/close change_request, create/update/close incident, create/update/retire cmdb_ci, create service_request, inbound_approval, inbound_request_initiation.
+Credentials: auth via credential management service (ITSM-001). Inbound webhooks: HMAC-SHA256 verified (ITSM-003).
+
+### ITSM Action Policy (8th policy type)
+Side-effect policy — fires on DCM events, triggers ITSM action, does NOT block pipeline by default.
+Output schema: itsm_provider_uuid, action, action_payload (template expressions: {{ field }}), store_reference_on_entity, block_until_created, block_timeout, on_failure.
+ITSM-005: block_until_created REQUIRES block_timeout — pipeline never permanently stalled.
+ITSM-POL-002: NOT a GateKeeper substitute except via explicit block_until_created mechanism.
+ITSM-POL-004: Multiple ITSM Policies on same event fire INDEPENDENTLY.
+
+### 6 Policy Examples
+1. create_change_request on request.dispatched (ServiceNow) — log and continue
+2. block_until_created for PCI-scope tenants (compliance gate with PT30M timeout)
+3. create_cmdb_ci on entity.realized — with IP address from realized_fields
+4. create_incident on drift.detected (significant/critical severity, Jira)
+5. retire_cmdb_ci on entity.decommissioned
+6. close_change_request on request.realized
+
+### ITSM Entity References
+itsm_references[] on entity business data: system, record_type, record_id, record_url, status, last_synced_at. Preserved through entity lifecycle. In audit records.
+
+### recorded_via Field
+Already on approval vote API: dcm_admin_ui | servicenow | jira | slack_bot | api_direct | other. ITSM integration populates this on inbound approvals.
+
+### Event Catalog Additions
+itsm.record_created, itsm.record_updated, itsm.record_failed — new itsm.* domain (21st domain; 85 total events).
+
+### ITSM-001–007 + ITSM-POL-001–004
+ITSM-001: base Provider contract applies. ITSM-002: non-blocking by default. ITSM-003: inbound webhook HMAC auth. ITSM-004: references persist through lifecycle. ITSM-005: block_until_created mandatory timeout. ITSM-006: unmapped resource types silently skipped for CMDB sync. ITSM-007: missing template fields → warning + empty string (no block).
+
+---
+
+## SECTION 76 — PROVIDER CALLBACK AUTHENTICATION (doc 43 — 43-provider-callback-auth.md)
+
+**Purpose:** Specifies how Service Providers authenticate inbound calls to the DCM control plane (the Provider Callback API). Resolves the gap between the outbound credential model (DCM → Provider) and the inbound model (Provider → DCM).
+
+**Two-layer model:**
+- **Layer 1 — mTLS:** Provider presents its registered certificate on every TLS connection. DCM validates the chain against the registered CA and the stored certificate fingerprint for that provider_uuid. Proves transport-level identity.
+- **Layer 2 — Provider Callback Credential:** A `dcm_interaction` credential issued by the credential management service at provider activation time. Scoped to `provider_uuid` + `allowed_operations`. Short-lived (PT15M fsi/sovereign; PT1H standard). Presented as `Authorization: Bearer` on every callback call. Proves operation-level authorization.
+- Both layers are required. mTLS alone does not prove authorization. The credential alone cannot establish the connection.
+
+**Entity-level authorization (per call, independent of credential):**
+- `realized_state_push`: DCM verifies `credential.provider_uuid` matches the `provider_uuid` in the Requested State record for that `resource_id`. Prevents a provider from pushing state for entities it was not dispatched to.
+- `update_notification`: DCM verifies the calling provider is the current Realized State provider for the entity AND the `notification_type` was declared in the provider's registration.
+- `lifecycle_event`: DCM verifies the calling provider is the provider on record for the resource.
+
+**Credential lifecycle:**
+- Issued at provider activation; delivered via the activation response (retrieved via credential management service)
+- Rotated automatically by DCM before expiry (DCM initiates rotation; provider must implement refresh)
+- Transition window (50% of credential lifetime) during which both old and new credentials are accepted
+- Revoked immediately on: provider deregistration, 5+ scope violations in PT1H, admin explicit revocation, certificate expiry without rotation
+
+**Registration special case:**
+- Initial registration (`POST /api/v1/providers`) uses a registration token (single-use, admin-issued) not the callback credential — no callback credential exists until activation
+- Re-registration (same name, updating version/capabilities) uses the active callback credential
+- Re-registration that changes sovereignty declaration requires a new registration token and triggers a new approval pipeline
+
+**System policies:** PCA-001 through PCA-010. Key: PCA-003 (entity-level ownership check is independent of credential), PCA-004 (5 scope violations → auto-suspend), PCA-010 (all inbound calls produce audit records including rejected ones — no silent failures).
+
+
+## SECTION 77 — AEP API ALIGNMENT
+
+DCM's four OpenAPI specifications follow AEP (API Enhancement Proposals — aep.dev) conventions in three specific areas:
+
+**1. Custom methods (AEP-136):** Actions on resources use colon syntax. `POST /resources/{id}:suspend` not `POST /resources/{id}/suspend`. Applies to all state-transition and action operations in Consumer and Admin APIs (30 path conversions total: :suspend, :resume, :rehydrate, :rotate, :extend-ttl, :transfer, :bulk-decommission, :acknowledge, :revert, :approve, :reject, :reinstate, :trigger, :rebuild, :activate, :vote, :revoke-sessions, :accept-degradation, :rotate-credential, :read-all, and others).
+
+**2. Long-Running Operations (AEP-151):** Async operations that produce a trackable result return an `Operation` resource (not `202 Accepted` with no body). The `Operation` has: `name` (stable poll URL), `done` (boolean), `metadata` (stage/progress/resource_uuid), `response` (present when done=true, success), `error` (present when done=true, failure). 14 consumer-facing operations return Operation: submitRequest, createRequestGroup, updateResource, decommissionResource, suspendResource, resumeResource, rehydrateResource, initiateOwnershipTransfer, bulkDecommission, revertDrift, rotateCredential, contributePolicy, contributeResourceGroup (consumer API) + decommissionTenant (admin API). Fire-and-forget operations (capacity reports, interim status, lifecycle events, discovery triggers) retain `202 Accepted` — no Operation body.
+
+**3. Pagination (AEP-158):** `page_size` and `page_token` query parameters (not `limit`/`cursor`). Responses include `next_page_token`.
+
+**Deliberately NOT aligned:** Resource names (DCM retains bare UUIDs — immutability across ownership transfers is more important than AEP naming), timestamp field names (`created_at` not `create_time` — would require data model change with no functional benefit).
+
+**Operator API note:** The operator-facing Services API (dcm-operator-api.yaml) uses the callback pattern — operators are NOT consumer-facing LRO callers. `updateResource` in the operator spec uses `202 Accepted` (async with callback) + `200 OK` (sync with RealizedStatePayload), not an Operation resource.
+
+## SECTION 78 — KESSEL INTEGRATION EVALUATION (doc 44 — 44-kessel-integration-evaluation.md)
+
+**Status:** Pre-implementation evaluation. Discussion with Kessel team required before any implementation. No DCM architecture changes should be made based on this document until alignment is confirmed.
+
+**What Kessel is:**
+- **Kessel Relations:** Authorization service built on SpiceDB (Google Zanzibar / ReBAC). `CheckPermission(subject, permission, resource)` traverses relationship graph. Zookie consistency tokens for "read your own writes" guarantee.
+- **Kessel Asset Inventory:** Hybrid cloud resource state tracking (current-state snapshot store, gRPC streaming API). Integrates with Kessel Relations for auth-filtered inventory queries.
+
+**Integration Option A — Kessel Relations as DCM Auth Provider:**
+- Handles checks 1 and 2 of DCM's five-check boundary model (identity + authorization). Checks 3-5 (accreditation, data matrix, sovereignty) remain in DCM's Policy Engine — cannot be delegated.
+- DCM's entity relationship graph (operational: requires/constituent/shareable) must NOT go in Kessel Relations — only access-control relationships.
+- Approval gate quorum stays in DCM (Kessel answers "is actor authorized to vote?"; DCM tracks "how many have voted").
+- Integration path: new `auth_mode: kessel_rebac` Auth Provider registration.
+- Zookie tokens must be threaded through DCM request context for consistency.
+
+**Integration Option B — Kessel Inventory as Discovered State Store:**
+- Discovered State only (most ephemeral store, current-state snapshot). Intent, Requested, Realized stores remain in DCM — not replaceable by Kessel Inventory.
+- Drift detection logic stays in DCM's DRC component regardless — Kessel Inventory is a data source, not a drift engine.
+- Field-level provenance, lifecycle state machine, audit chain — all stay in DCM.
+- Integration path: snapshot store backed by Kessel Inventory. No data model changes.
+
+**Pros (Relations):** SpiceDB production-grade, Zanzibar consistency, scalable graph traversal, shared source of truth across Red Hat products, single CheckPermission call replaces multi-step group-lookup + policy-evaluation.
+
+**Pros (Inventory):** Feeds same discovered state to ACM/Insights/HCC, reduces DCM's operational burden for ephemeral store, gRPC streaming fits provider push pattern.
+
+**Cons (Relations):** Hard runtime dependency (unavailability = safe-deny mode), schema coupling requires coordinated evolution, quorum model doesn't fit, entity relationship graph stays in DCM anyway.
+
+**Cons (Inventory):** Four-state model mismatch (Kessel is upsert/current-state only), no field-level provenance, no drift detection, schema extensibility for DCM-specific types unconfirmed, project maturity risk.
+
+**18 questions for Kessel team documented in Section 6. 10 blocking items in Section 10.**
+
+**KESSEL-001 through KESSEL-007** are the proposed system policies — not active until Kessel alignment is complete.
+## SECTION 79 — CONSISTENCY REVIEW (doc 45 — 45-consistency-review.md)
+
+Full consistency review completed 2026-03. Key findings and fixes:
+
+**Fixed:** AEP colon paths applied to admin-api-spec.md (13 paths) and consumer-api-spec.md (4 remaining); stale entity_type values corrected (`allocated_resource`→`infrastructure_resource`, `resource_entity`→`infrastructure_resource`); stale scoring threshold keys replaced with named-tier format comments; `provider_id`→`provider_uuid` in DCM API endpoint paths; Operation (LRO) polling section added to consumer spec.
+
+**Canonical rules:** entity_type has exactly three values (infrastructure_resource, composite_resource, process_resource). Custom method paths use colon syntax in ALL docs. `provider_uuid` in DCM APIs; `resource_id` (operator-assigned) in callback APIs — these are intentionally distinct. Lifecycle state UPPERCASE in YAML, lowercase in prose — by design.
+
+**Three implementation decisions still needed:** (1) resource_type field: accept FQN string or require UUID at dispatch? (2) Operation polling: same endpoint as request status or separate? (3) API Gateway must map resource_id → entity_uuid at callback boundary.
+
+
+## SECTION 80 — IMPLEMENTATION DECISIONS RESOLVED (doc updates 2026-03)
+
+Three open implementation decisions have been resolved:
+
+**DECISION 1 — resource_type field: accept both FQN and UUID**
+- Consumers may supply resource_type as either FQN string (`Compute.VirtualMachine`) or Registry UUID
+- DCM resolves either form to the canonical (resource_type_uuid, resource_type_name) pair at request assembly time in the Request Payload Processor
+- FQN recommended for consumer use (stable across deployments; returned by service catalog)
+- UUID accepted for programmatic use where UUID was obtained from catalog API
+- Unresolvable references rejected at validation time: 422 + code RESOURCE_TYPE_NOT_FOUND
+- Dispatch payloads (CreateRequest/UpdateRequest) to operators ALWAYS carry both: resource_type_uuid + resource_type_name
+- Added to: dcm-common.json (resource_type_ref oneOf type), CatalogItem schema (oneOf in consumer YAML), doc 05, consumer spec, operator spec
+
+**DECISION 2 — operation.name → /api/v1/operations/{uuid} (separate AEP endpoint)**
+- operation_uuid == request_uuid — the same UUID serves both endpoints
+- GET /api/v1/operations/{uuid} → Operation schema (AEP-standard: done, metadata, response/error)
+- GET /api/v1/requests/{uuid}/status → RequestStatus schema (DCM-native: pipeline_stage, full history)
+- Both endpoints reflect the same underlying operation state
+- Operation.metadata includes request_uuid field so AEP clients can navigate to the rich view if needed
+- POST /api/v1/requests returns Operation with name = /api/v1/operations/{request_uuid}
+- Added to: consumer YAML (new GET /api/v1/operations/{operation_uuid} path, 61 paths total), Operation schema (request_uuid in metadata, dual-endpoint description), consumer spec (Operations polling section with dual-endpoint table)
+
+**DECISION 3 — resource_id → entity_uuid mapping (RESOLVED by existing data model)**
+- Not an open decision — already solved by the schema
+- DCM sends dcm_entity_uuid in every CreateRequest dispatch; operator echoes it in every response and callback
+- DCM uses entity_uuid for all routing; resource_id is operator's own correlation handle stored opaquely
+- API Gateway validates dcm_entity_uuid in each callback matches the entity under the calling provider's credential
+- Documented explicitly in operator interface spec
+
+
+## SECTION 81 — SPEC COMPLETION: K8S + OPERATOR SDK (2026-03)
+
+**11-kubernetes-compatibility.md** — Completed:
+- Document status header and related docs cross-references added
+- Section 2 intro: explains the superset relationship explicitly
+- Section 4 summary table: 7 DCM capabilities vs Kubernetes gaps, side-by-side
+- Comment lines cleaned from section 3a (code comment artifacts removed)
+- AEP alignment note added
+- All 5 open questions were already resolved; Resolution Notes complete
+- Status: ✅ Complete
+
+**dcm-operator-sdk-api.md** — Completed:
+- Document status header, related docs, AEP alignment note added
+- New Section 11: Callback Credential Management — automatic rotation, entity_uuid vs resource_id contract, DCM validation rule
+- resource_type_name field annotated: "FQN — always present alongside resource_type_uuid"
+- All 5 open questions were already resolved; Q10 header annotated
+- Status: ✅ Complete
+
+**All 14 specifications now have:** AEP alignment notes, document status headers, no stale slash-verb paths, consistent field naming.
+
+
+## SECTION 82 — PDF VALIDATION + THREE NEW ADDITIONS (2026-03)
+
+**PDF (Miro board) was validated against current architecture.** Core finding: PDF = original design intent; current docs = evolved, more detailed implementation. Structurally aligned. Three gaps identified and filled:
+
+**GAP 1 — Static Replace use case (dcm-examples.md sections 1.9 + 1.10):**
+- Static Replace = re-provision using existing Requested State verbatim, no layer enrichment, no policy re-evaluation. Deterministic rebuild.
+- Distinct from Rehydration (mode: intent) which replays original Intent State through current policies and layers.
+- `POST /api/v1/resources/{uuid}:rehydrate` with `mode: static` (same endpoint, different mode).
+- Precondition: application data on separate partition (VM OS/config is what gets rebuilt).
+- Orchestration Flow Policy specified (4-step: validate → decommission → dispatch original requested state → restore operational).
+- In-Place Upgrade (Leapp/IPU) also documented as Section 1.10 — upgrades OS in-place, preserves entity UUID, creates new Realized State delta record.
+
+**GAP 2 — Workload Analysis (new doc 46-workload-analysis.md):**
+- New capability: actively classifies discovered resources by operational characteristics.
+- Answers: "what is this resource?", "is it migratable?", "what lifecycle model applies?"
+- WorkloadProfile = process_resource_entity of type Analysis.WorkloadProfile.
+- Fires automatically as part of brownfield ingestion pipeline (DRC → WLA → Ingestion).
+- MTA (Migration Toolkit for Applications) is the reference Information Provider implementation.
+- 6 system policies WLA-001 through WLA-006.
+- API: GET /api/v1/resources/{uuid}/workload-profile, POST /api/v1/resources/{uuid}/workload-profile:analyze
+- Added to Capabilities Matrix as Domain 36 (6 capabilities: WLA-001 to WLA-006).
+
+**GAP 3 — Per-provider monitoring contract (registration spec + self-health doc):**
+- 7 Provider Readiness Gates (GATE-SP-01 through GATE-SP-07) added to registration spec Section 7.2.
+- Gates 1-3 required for all profiles; Gates 4-7 required for standard+.
+- GATE-SP-01: OpenAPI spec declared and reachable.
+- GATE-SP-02: Healthy API at activation.
+- GATE-SP-03: State Management callback implemented.
+- GATE-SP-04: Tenant Metadata endpoint (usage by tenant, quota consumed).
+- GATE-SP-05: Prometheus metrics (4 required families: dispatches_total, dispatch_duration_seconds, realizations_total, health_status).
+- GATE-SP-06: AEP.DEV linting passes (no errors in provider OpenAPI spec).
+- GATE-SP-07: Multi-tenant dispatch (accepts tenant_uuid).
+- Self-health doc (39-dcm-self-health.md) Section 7: Per-Provider Metrics Contract added.
+- Added to Capabilities Matrix as PRR-001 through PRR-007 in Provider Contract domain.
+- Matrix now: 37 domains / 287 capabilities.
+
+**PDF naming differences documented (not errors — terminology evolution):**
+Widget → Resource/Entity; Requested/Realized/Discovered Widget Store → State Stores;
+Widget Discovery → Discovery Scheduler; Interoperability API → Operator Interface;
+Provisioned Store → Realized State Store; Job Queue → Message Bus; Rules Engine → Policy Engine.
+
+
+## SECTION 83 — ACCREDITATION MONITOR (doc 47 — 47-accreditation-monitor.md)
+
+**Purpose:** Continuously verifies registered accreditations against authoritative external sources. Answers: "Is this accreditation still valid according to the issuing authority — not just the expiry date we were told?"
+
+**Four verification tiers (by automation depth):**
+- **Tier 1 — External Registry API (full automation):** FedRAMP (marketplace.fedramp.gov/api), CMMC 2.0 (cyberab.org/catalog), StateRAMP, ISO 27001 (iaf.nu CertSearch). Queries by external_registry_id; detects status changes including mid-cycle revocations.
+- **Tier 2 — Document Currency (partial automation):** SOC 2, PCI DSS AoC. Fetches document from certificate_ref/audit_report_ref, extracts date via PDF metadata or header parsing, validates against max_age threshold (default P365D).
+- **Tier 3 — Contract Webhook (event-driven):** HIPAA BAA, DoD IL. Inbound webhook from DocuSign/Ironclad/etc fires when BAA is signed, amended, or terminated. DCM processes: signed→active, amended→pending_review, terminated→revoked.
+- **Tier 4 — Expiry-Only (no external check):** Self-declared, internal, HIPAA BAA without contract system. Monitors declared valid_until only.
+
+**Key flows:**
+- Tier 1 poll detects Revoked status → immediate accreditation revocation → Accreditation Gap triggered (no admin confirmation required for revocations)
+- Tier 1 poll detects status change to non-revoked (e.g., Authorized → In Process) → status: pending_review → admin confirms
+- Registry unreachable → increment failure_count; no status change; fires verification_stale at threshold
+- stale_after exceeded → stale_action: warn/suspend/escalate (profile-governed: warn for dev/standard, suspend for prod, escalate for fsi/sovereign)
+
+**Accreditation record additions (doc 26 Section 3.3):** `verification` block with tier, registry_api/document_check/contract_webhook sub-blocks, stale_after, stale_action, verification_failure_count. `status` gains `pending_review` state. `gap_type` gains `verification_stale`.
+
+**Scoring Model addition (doc 29 Signal 5):** `verification_multipliers` — accreditation weight discounted based on verification currency: external_registry verified today = 1.0, expiry_only = 0.7, stale = 0.4, failed threshold = 0.1.
+
+**New events (doc 33 Section 20):** accreditation.verified, accreditation.status_changed, accreditation.registry_mismatch, accreditation.verification_stale, accreditation.document_expired, accreditation.contract_event, accreditation.expiry_approaching.
+
+**8 system policies: ACM-001 through ACM-008.** Key: ACM-002 (status change → pending_review except Revoked which is immediate), ACM-003 (registry unreachable does NOT revoke), ACM-004 (fsi/sovereign must use tier ≥ document_currency), ACM-007 (all verifications produce audit records — no silent checks).
+
+**Air-gapped mode:** Tiers fall back to expiry_only for unreachable registries. Retries after air_gapped_retry_interval (default P30D). Manual update of last_verified_at permitted with required justification.
+
+**Matrix:** Domain 37, ACM-001 through ACM-007. Total: 37 domains / 287 capabilities.
+
+
+## SECTION 84 — COMPREHENSIVE USE CASE EXAMPLES (dcm-use-case-examples.md)
+
+New specification: `specifications/dcm-use-case-examples.md` — 1,853 lines, 5 sections.
+
+**Shared context:** All examples use consistent fictitious actors (alice@corp, bob@corp, svc-pipeline@corp), tenants (payments-bu, web-platform-bu, platform-team), and providers (vmware-prod, netbox-prod, vault-prod, freeipa-prod, ceph-prod, rabbitmq-prod, servicenow-prod, webapp-meta) for cross-example coherence.
+
+**Section 1 — Data Model Examples (12 examples):**
+- 1.1 Four States: VM intent → layer assembly → requested state → realized state → discovered state → decommission
+- 1.2 Layer Assembly: 6-layer compose (base/DC/zone/BU/service/request) with full provenance
+- 1.3 Governance Matrix: PHI request denied — four-axis evaluation, HIPAA BAA missing on provider
+- 1.4 Scoring Model: 5-signal risk score (0-100), placement tie-breaking by accreditation richness + verification multiplier
+- 1.5 Authority Tier: 200-VM bulk request → CRITICAL tier → 3-step approval chain
+- 1.6 Entity Relationships: VM+IP+FirewallRule composite, decommission impact analysis
+- 1.7 Universal Groups: tenant boundary, resource group, cross-tenant read authorization
+- 1.8 Scheduled Requests: maintenance window + deferred OS patch via CI/CD
+- 1.9 Request Dependency Graph: DB→App→LB 3-node chain with field injection between nodes
+- 1.10 Workload Analysis: legacy VM discovered → classified (batch_processor, confidence:medium) → MTA score → ingested
+- 1.11 Accreditation Monitor: FedRAMP daily verify + mid-cycle revocation → immediate gap trigger
+- 1.12 Session Revocation: stolen laptop → all sessions revoked → in-flight request aborted safely
+
+**Section 2 — Provider Interaction Examples (6 new examples, 2.5–2.10):**
+- 2.5 Auth Provider (FreeIPA): registration, LDAP auth flow, group mapping → DCM roles
+- 2.6 Data Store: write-once snapshot registration, Realized State write
+- 2.7 event routing service (RabbitMQ): topic exchange, routing key pattern, multi-subscriber routing
+- 2.8 credential management service (Vault): AppRole registration, ephemeral bind-password fetch, dynamic DB creds, consumer SSH key retrieval with audit
+- 2.9 Meta Provider: compound WebApp (VM+IP+FW+DNS) decomposition, parallel + sequential constituent ordering, field injection
+- 2.10 ITSM integration (ServiceNow): incident creation on provider health change, field mapping, resolve on recovery
+
+**Section 3 — Registration Flow Examples (3 examples):**
+- 3.1 Information Provider (NetBox): token issuance, mTLS registration, 6-check validation, approval, assembly enrichment
+- 3.2 Auth Provider (Azure AD OIDC): secondary auth source for contractors, precedence ordering, TTL-scoped role mapping
+- 3.3 Meta Provider: constituent validation, circular dependency check, activation
+
+**Section 4 — OPA Policy Integration (2 examples):**
+- 4.1 Shadow mode: 30-day shadow evaluation, divergence reporting, admin review dashboard, promotion to active
+- 4.2 Bundle delivery: sidecar registration, 5-minute pull cycle, hot reload, evaluation call with input/output
+
+**Section 5 — GUI Examples (3 examples):**
+- 5.1 Consumer Portal: login → catalog → cost estimate → submit → progress polling → credential delivery
+- 5.2 Admin GUI Policy Flow: node-by-node pipeline visualization with shadow indicators and red blocking paths
+- 5.3 Admin GUI Drift Dashboard: severity summary, critical drift detail, revert/accept/investigate actions
+
+
+## SECTION 85 — EXAMPLES EXPANSION (dcm-examples.md)
+
+dcm-examples.md expanded from 1,058 lines to 2,189 lines. Now covers all 10 provider types, all 3 remaining policy types, and 8 new lifecycle/model flows. Full section inventory:
+
+**Section 6 — Provider Type Examples (NEW):**
+- 6.1 Data Store — state store write/read cycle (provenance emission, replica confirmation)
+- 6.2 Auth Provider — OIDC cutover from GitHub OAuth (shadow evaluation, zero-downtime cutover)
+- 6.3 credential management service — SSH key issuance post-VM-realization, 90-day TTL, auto-rotation at P45D
+- 6.4 Meta Provider — three-tier WebApp stack (VM→VM→LB→DNS with field injection between tiers)
+- 6.5 ITSM integration — ServiceNow Change Request lifecycle (create→approve→implement→close)
+- 6.6 event routing service — Kafka event bridge (entity lifecycle events, dead letter handling)
+
+**Section 7 — Policy Type Examples (NEW):**
+- 7.1 Transformation Policy — OS image auto-injection (immutable field, provenance annotation)
+- 7.2 Placement Policy — PHI VM with HIPAA BAA requirement (require/prefer/exclude model, audit trail)
+- 7.3 Shadow Execution — cost-cap policy rollout (parallel evaluation, divergence report, safe activation)
+
+**Section 8 — Lifecycle and Model Examples (NEW):**
+- 8.1 Scheduled Request — deferred provisioning via maintenance window (deadline handling, cancellation)
+- 8.2 Request Dependency Graph — three-tier app with realized field injection across tiers
+- 8.3 Authority Tier Routing — sovereign decommission requiring sequential platform_admin + CISO approval
+- 8.4 Rehydration (intent mode) — DR failover to new datacenter (contrast with Static Replace)
+- 8.5 Session Revocation — emergency security incident response (revoke-all, in-flight handling)
+- 8.6 Workload Analysis — brownfield VM classification via MTA (port scan, process list, classification pipeline)
+- 8.7 Scoring Model — placement tie-breaking with 5 signals (accreditation verification multiplier effect)
+- 8.8 Accreditation Monitor — FedRAMP status change detection (mid-cycle downgrade, pending_review flow)
+
+**Previously covered (Sections 1-5, unchanged):**
+Service Provider (dispatch cycle), Information Provider (assembly enrichment), External Policy Evaluator (OPA sidecar),
+notification service (audience graph), Consumer API lifecycle, Admin API flows, Registration onboarding,
+Brownfield ingestion, Static Replace, In-Place Upgrade.
+
+All 10 provider types: ✅ covered. All 7 policy output schemas: ✅ covered. All major model flows: ✅ covered.
+
+
+## SECTION 86 — LOCATION TOPOLOGY LAYER MODEL (doc 48)
+
+**New doc:** 48-location-topology-layers.md — specifies where resources can be allocated, how location data flows into requests as Core Layers, and how consumers select locations.
+
+**Core concept:** Location is not a string field. It is a resolved chain of versioned Core Layers — one per level of the topology hierarchy. When a consumer selects "DC1 — Frankfurt Alpha", DCM assembles Country → Region → Zone → Site → Data Center layers into the request payload, injecting all structured location data at each level.
+
+**Standard hierarchy (9 levels, configurable names, standard types):**
+- Level 1 Country (CTY) — jurisdiction, regulatory frameworks, ISO codes
+- Level 2 Region (RGN) — interconnects, latency profile, failover region
+- Level 3 Zone/AZ (AZ) — isolation boundary, HA peers, RPO/RTO
+- Level 4 Site/Campus (SITE) — physical address, security tier, facilities contacts
+- Level 5 Data Center (DC) — tier classification, power/cooling, PUE, certifications
+- Level 6 Hall/Pod (HALL) — optional; network segment, cooling type
+- Level 7 Cage/Enclosure (CAGE) — optional; tenant isolation, access control
+- Level 8 Rack (RACK) — rack units, power circuits, ToR switch
+- Level 9 Unit/Slot (UNIT) — optional; typically provider-managed
+
+**Authority model:** Each level has a designated owning authority (Data Center Operations, Network Operations, Facilities, Platform Governance). Changes require GitOps PRs approved by the owning authority. Upper levels (Country, Region, Zone) require platform_admin approval; lower levels (Hall, Cage, Rack) can be operator-approved.
+
+**Custom types:** Custom levels insertable anywhere using decimal level values (e.g., Fleet=3.5, Ship=4.5 in a Navy deployment). Navy example included in doc.
+
+**Priority bands:** Location layers occupy dedicated bands in the Core Layer priority space: Country=100.xx, Region=200.xx, Zone=300.xx, Site=400.xx, DC=500.xx, Hall=600.xx, Cage=700.xx, Rack=800.xx. Ensures specific always overrides general.
+
+**Consumer API (NEW):**
+- GET /api/v1/locations — list available location nodes (entitlement-filtered, filterable by resource_type, catalog_item, level, classification)
+- GET /api/v1/locations/{uuid} — full detail including hierarchy, sovereignty, compliance, capacity
+- ServiceRequest now accepts location_uuid or location_handle
+- Consumer selects at any level; Placement Engine refines to specific DC at dispatch
+
+**Admin API (NEW):**
+- GET/POST /api/v1/admin/location-types — manage location type registry
+- GET /api/v1/admin/locations — all location nodes (no entitlement filter)
+- PATCH /api/v1/admin/locations/{uuid} — update mutable fields (e.g., rack_units_available)
+
+**OpenAPI updates:** Consumer API now 63 paths; Admin API now 44 paths. LocationList, LocationSummary, LocationDetail schemas added to consumer API.
+
+**Placement Engine integration:** Location layers feed LOC-005 sovereignty enforcement (max_data_classification per DC), Step 1 sovereignty pre-filter, Step 3 capability filter, and Placement Policy expressions (input.payload.location.jurisdiction, etc.).
+
+**9 system policies: LOC-001 through LOC-009.**
+
+**Matrix:** 38 domains / 294 capabilities.
+
+
+## SECTION 87 — REFERENCE DATA LAYERS + LAYER-REFERENCED FIELD CONSTRAINTS
+
+**Core clarification applied:** Layer data is the source of allowed values for resource type fields. This is not new architecture — it is the `layer_reference` constraint type made explicit throughout the documentation.
+
+**Pattern:** A field in a Resource Type Specification can declare `constraint.type: layer_reference` with a `layer_type` name. At catalog item render time, DCM resolves the active instances of that layer type into the `allowed_values` list. The consumer selects from that list; DCM injects the full layer data into the assembled payload.
+
+**Standard reference data layer types:**
+- `location.data_center` — where resources can be placed (hierarchy: Country→Region→Zone→Site→DC→Hall→Cage→Rack)
+- `os_image` — approved OS images (Platform Security team)
+- `vm_size` — approved VM size profiles (Platform Team)
+- `network_zone` — available network zones (Network Operations)
+- `environment` — deployment environments (Platform Governance)
+- `storage_class` — storage tiers (Storage Operations)
+- `gpu_profile` — GPU configurations (Platform Team)
+
+**Governance model:** Reference Data Layer instances have IDENTICAL lifecycle, controls, security, and governance as Resource Types — `developing → proposed → active → deprecated → retired`, GitOps workflow, versioned, owned by declared authority, immutable once active. Adding a new approved OS image = adding a new `os_image` layer. No Resource Type Specification change needed.
+
+**Changes made this session:**
+
+doc 03 (layering): New Section 3.7 — Reference Data Layers. Defines the pattern, governance model, and YAML format for `os_image` and `vm_size` reference data layers. Updated Core Layers cross-ref.
+
+doc 05 (resource types): New Section 2.1b — Layer-Referenced Field Constraints. Explains why `layer_reference` is preferred over static enums. Complete table of standard layer types with owning authorities. Shows what the catalog item field constraint looks like when resolved (full `allowed_values` with structured data). Adds `layer_reference` and `layer_reference_list` to the field constraint type vocabulary, including `filter`, `display_field`, `value_field` sub-fields.
+
+consumer-api-spec.md Section 3.2: Catalog item field schema now shows four field examples:
+ - `cpu_count` — static `enum` constraint (unchanged)
+ - `os_image` — `layer_reference` to `os_image` type (resolved `allowed_values` with image metadata)
+ - `location` — `layer_reference` to `location.data_center` type (resolved with DC name, zone, certifications, capacity_status)
+ - `size` — `layer_reference` to `vm_size` type (resolved with CPU/RAM defaults)
+ Section 3.3 submit request shows layer UUIDs in the fields object with comments explaining DCM's resolution.
+
+doc 48 (location): New Section 0 — Pattern Context. Explicitly frames location as one application of the Reference Data Layer pattern. Section 8 (Consumer Selection Model) updated: location selection is via the catalog item field constraint, not a separate /locations endpoint. Shows how filter clause on the layer_reference constraint controls which DCs appear per catalog item.
+
+API changes: Removed standalone /api/v1/locations and /api/v1/locations/{uuid} consumer endpoints (wrong model — location is a field constraint, not a separate API). Admin API keeps /api/v1/admin/location-types and /api/v1/admin/locations (correct — admin manages the Reference Data Layer registry). Consumer API back to 61 paths.
+
+
+## SECTION 88 — RESOURCE TYPE AUTHORITY + UNIFIED LAYER MODEL CLARIFICATION
+
+**Core clarification:** All of DCM's data — Resource Type Specifications, Reference Data Layers, Service Layers, provider extension layers — is built on the same layer model with the same lifecycle, governance, ownership, and security model. This was architecturally correct but not explicitly stated.
+
+**What was already in the architecture (confirmed, no changes needed):**
+- Three-tier registry (DCM Core / Verified Community / Organization) — doc 20
+- Provider as Resource Type Publisher (doc 28 section 6.1)
+- Resource Type Specification vs Catalog Item distinction (doc 05 section 2.1a)
+- Portability classification (universal/conditional/provider-specific/exclusive) — doc 05 section 4
+- Provider-specific extension fields must be marked portability-breaking — doc 05 section 4
+- Layer domain model (system/platform/tenant/service/provider) — doc 03 section 4.1
+- Service Layers contributed by providers — doc 28 section 6.3
+- GitOps workflow for resource type proposals — doc 20 section 3.1
+
+**What was added (4 targeted additions):**
+
+**1. Resource Type Authority — Stewardship Model (doc 05 new Section 2.1c):**
+Every Resource Type Specification has a declared Resource Type Authority — the team responsible for defining, maintaining, evolving, and deprecating it. Same `owned_by` governance model as all other DCM artifacts. Required approver for all future version PRs. Standard authority assignments by category: Compute→Platform Team, Network→Network Ops, Storage→Storage Ops, Security→CISO, etc. Three tiers: DCM maintainers (Tier 1), named community maintainers (Tier 2), org domain teams (Tier 3).
+
+**2. Three-Way Field Constraint Model (doc 05 new Section 3a):**
+Resource Type Authorities choose per field:
+- Option 1 — layer_reference: valid values are active instances of a named layer type (location, OS images, network zones). Portable. Value governance delegated to the layer type's authority.
+- Option 2 — provider-declared constraint: ad-hoc enum/range in the Resource Type Spec or Catalog Item. CPU counts, memory ranges, protocol versions. Portable if values are vendor-neutral.
+- Option 3 — no constraint: free-form or provider judgment. Names, descriptions, provider-internal IDs.
+Decision guide table included. Key point: VM size is Option 2 or 3 by default — not layer-referenced unless the org explicitly wants a governed size catalog. This is an organizational decision, not an architectural mandate.
+
+**3. Provider Extension Layers (doc 05 Section 6.2 extended):**
+Providers can contribute extension layers (domain: provider) alongside their catalog item declaration — `provider_extension_layer_handles` field. These inject provider-specific fields during payload assembly only when that catalog item is selected. Cannot override platform/tenant layers. Same portability_breaking: true semantics as inline extensions. Resource Type Authority may adopt popular extensions as conditional fields in a future spec version.
+
+**4. Unified Layer Model Statement (doc 03 Section 3.7 + Section 4.1):**
+Explicit statement that Resource Type Specifications ARE data layer artifacts. Same lifecycle, same governance, same GitOps workflow, same authority model, same domain access control. The Resource Type Registry is a specialized layer store. All DCM data — type definitions, reference data, service configuration, provider extensions — lives in this one unified model.
+
+**Authority vs Publisher clarification (doc 28 Section 6.1):** Resource Type Authority defines the spec; Service Provider publishes the catalog item implementing it. Often the same team. May be different: platform team defines Compute.VirtualMachine; Nutanix, VMware, and bare metal teams independently register catalog items implementing it.
+
+
+## SECTION 89 — SECTION 9 EXAMPLES: RESOURCE TYPE + LAYER LIFECYCLE (dcm-examples.md)
+
+dcm-examples.md expanded from 2,189 to 3,381 lines. Section 9 added — 8 subsections showing
+the complete lifecycle of VM and WebApp resources from layer definition through rehydration.
+
+**9.1 Layer Definitions:** Full YAML for all foundational layers — OS image (Platform Security Team),
+location/DC (Data Center Operations), network zone (Network Operations), zone and country ancestor layers.
+Each with complete artifact_metadata, owned_by, domain, data blocks.
+
+**9.2 Resource Type Specifications:** Complete `Compute.VirtualMachine` v2.1.0 spec showing:
+- Universal fields: cpu_count/memory_gb/storage_gb (range constraints — intrinsic), os_image/location/
+ network_zone/environment (layer_reference — governed lists)
+- Conditional fields: high_availability, gpu_profile (layer_reference)
+- Extension point declaration for provider hypervisor config
+- Application.WebApp v1.0.0 spec: app_name/tier_level (static enum — intrinsic),
+ environment/location (layer_reference), web_replica_count/db_engine (range/enum).
+
+**9.3 Provider Catalog Items:** Two providers implementing Compute.VirtualMachine:
+- Nutanix EU-WEST: portable (portability_class: portable), narrows CPU/RAM enums,
+ contributes Service Layer with AHV hypervisor defaults, backup policy, monitoring agent.
+- VMware EU-WEST: non-portable (portability_class: provider-specific), contributes
+ Provider Extension Layer with vsphere_resource_pool/datastore_cluster/vmware_tools_version.
+
+**9.4-9.5 VM Request and Processing Pipeline:** Full 8-step trace from consumer submission through
+intent capture → layer reference resolution → layer assembly (showing each contributing layer and field
+provenance) → policy evaluation (GateKeeper, Validation, Transformation each shown) → placement →
+requested state write (with provenance on every field) → dispatch → realized state.
+
+**9.6 WebApp as a Service Request:** Meta Provider orchestration: DB first, then 3 web VMs with
+db_host injected from DB realization, then LoadBalancer with backend_pool injected from VM IPs.
+Tier 1 GateKeeper policies enforcing HA, minimum replicas, LTM requirement. Environment layer
+injecting production defaults (backup, TTL=null, approval tier, log retention).
+
+**9.7 VM Rehydration (DR failover DC1→DC2):** Shows location override in placement_constraints,
+fresh layer resolution against DC2 layer chain (different cluster_uuid in Nutanix Service Layer),
+certification gap warning (SOC 2 not at AMS-DC2), hostname preserved / FQDN updated, entity_uuid
+preserved across DC move. Static Replace vs Rehydration contrast explained in pipeline steps.
+
+**9.8 WebApp Rehydration (standards refresh — no incident):** Rolling replacement pattern for Tier 1.
+Shows: retired OS image → auto-upgrade Transformation policy substitutes RHEL 9.5; environment layer
+v1.2 injects new log_retention_days=365 and vulnerability scanning; new Tier 1 GateKeeper bumps
+replica count 3→4; DB unchanged (no OS dependency). Full audit record showing every field change,
+its source layer/policy, and version.
+
+
+## SECTION 90 — DOCUMENTATION CLEANUP PASS (2026-03)
+
+No prior implementations exist — DCM is at v1. All migration/backward-compat/update language
+removed from documentation. Every doc is the authoritative first-version spec.
+
+**Removed entirely:**
+- All 38 Active Development Notice blockquotes across every data model and specification doc
+- `## 7. V1 Migration` section from doc 13 — V1 concept has no basis in first implementation; `v1_migration` ingestion_source type renamed `legacy_import`; `v1_identifier` → `legacy_identifier`
+- `## 7. Migration from Current Constructs` section from doc 15 (universal groups)
+- `## 9. Migration Path — Standalone SPA → RHDH` from RHDH spec — replaced with clean "Deployment Options" section (standalone_spa vs rhdh are configuration choices, not migration paths)
+
+**Reframed (concept kept, backward-looking framing removed):**
+- doc 06 section 7a.6: "Updated table (supersedes 7.2)" → "Provider Lifecycle Events"
+- doc 07: "dependency graph superseded by entity relationships" → scope cross-reference
+- doc 08: "superseded by Universal Group Model" → "Related: see Universal Group Model"
+- doc 09: "This document supersedes dependency graph concept" → plain cross-reference
+- doc 13: "V1 migration and brownfield ingestion are the same" → "same ingestion model for all sources"
+- doc 18: "outbound webhook superseded by Notification Model" → "one delivery channel within Notification Model"
+- doc 23: "This model supersedes standalone webhooks" → "outbound webhooks are one delivery channel"
+- doc 26: "Section 4 superseded by Governance Matrix" → scope statement
+- doc 27: "This document supersedes Section 4 of doc 26" → cross-reference
+- doc 11 (k8s): "Migration Path — Kubernetes-Native to DCM-Managed" → "Incremental Adoption"
+- doc 34: "Client Migration Path" → "Version Upgrade Path"; "backward compat" → "version-compatible"; "deprecation window" → "until version is sunset"
+- doc 15: "preserve backward compatibility with existing API consumers" → "for convenience"
+- OIS spec: "during the deprecation window" → "until the OIS version is sunset"
+
+**Verification:** 12 stale patterns — all clean after cleanup pass.
+
+---
+
+## SECTION 91 — SYNC AUDIT AND FULL RESYNC (2026-03)
+
+Full Hugo content sync performed. State before sync:
+- 5 data model docs missing from Hugo entirely (43-provider-callback-auth, 44-kessel-evaluation, 45-consistency-review, 46-workload-analysis, 47-accreditation-monitor)
+- 44 of 53 data model docs stale (primarily -5 line delta from Active Development Notice removal)
+- 7 specs stale (dcm-examples, dcm-registration-spec, dcm-operator-interface-spec, dcm-rhdh-integration-spec, 11-kubernetes-compatibility, consumer-api-spec, dcm-operator-sdk-api)
+- Capabilities Matrix and DISCUSSION-TOPICS stale
+- AI prompt had one stale matrix reference: "36 domains / 281 capabilities" (from Provider Readiness Gates session before Accreditation Monitor domain was added)
+
+**After sync:** All 53 data model docs × 2 Hugo locations: in sync. All 14 specs: in sync. All top-level docs: in sync. AI prompt matrix refs updated to 37/287.
+
+---
+
+## SECTION 92 — ARCHITECTURE GAPS ANALYSIS (2026-03)
+
+Systematic scan of all docs, schemas, and capabilities matrix. Summary:
+
+**Tier 1 — Spec gaps (documented capability, API endpoints missing):**
+- Federation Admin API (doc 22 architecture complete; no OpenAPI paths for tunnel management, peer listing, trust posture)
+- Scheduled/Deferred Requests maintenance-windows endpoints (doc 37 specifies them; not in admin YAML)
+- Workload Analysis endpoints (doc 46 specifies GET /workload-profile and :analyze; not in consumer YAML)
+- Accreditation Monitor contract-event and :configure-webhook endpoints (doc 47; not in admin YAML)
+
+**Tier 2 — Implementation gaps (no specification exists):**
+- Cost Analysis component internal model (376 refs; no spec for how it calculates)
+- Cross-region data replication model (multi-region assumed; consistency + sovereignty enforcement at replication layer unspecified)
+- Secret zero / initial credential bootstrap (day-0 sequence has no spec; chicken-and-egg problem every deployer hits)
+- Multi-tenancy at storage layer (row-level security, tenant-scoped encryption — not specified)
+- Rate limiting implementation (policy references it; enforcement mechanics unspecified)
+- Audit log hash chain implementation (tamper evidence concept documented; implementation not specified)
+
+**Tier 3 — Security posture gaps:**
+- No threat model document (attack surfaces, adversary profiles, STRIDE analysis)
+- No supply chain security spec (SBOM, provider package signing, operator container provenance)
+- No secrets scanning spec for GitOps stores
+
+**Tier 4 — Experience gaps:**
+- New tenant onboarding flow not specified
+- Pre-request cost estimation UX not specified end-to-end
+- Provider sandbox/test mode not specified
+- Capacity forecasting model not specified
+- SLA/SLO tracking not specified
+
+**Two ownership ambiguities:**
+- Who issues operation_uuid — API Gateway or Request Orchestrator?
+- Who owns the Credential Revocation Registry?
+
+---
+
+## SECTION 93 — LIGHTSPEED INTERFACE CONCEPT + DISCUSSION TOPICS (2026-03)
+
+**DISCUSSION-TOPICS.md updated:** Item 6 added — "Universal Lightspeed Interface for Operations."
+
+Concept: a universal, high-velocity operational surface for all DCM actions regardless of provider, resource type, or lifecycle stage. Operations that currently require multiple tool hops, context switching, and approval interruptions should be expressible and executable in a single interaction.
+
+**Key design questions captured for future roadmap:**
+- New GUI surface, CLI, AI agent interface, or all three?
+- How does it relate to existing Web UI spec and Flow GUI spec?
+- What does "lightspeed" mean operationally — sub-second execution, zero-confirmation for pre-approved patterns, predictive pre-staging?
+- How does it interact with Authority Tier model — can it auto-route approval gates without interrupting operator flow?
+- Is this the primary interface for the AIOps layer referenced in the README?
+
+**Status:** Concept only — no design work started. Future roadmap item.
+
+
+## SECTION 94 — ALL ARCHITECTURE GAPS ADDRESSED (2026-03)
+
+All gaps from Section 92 gap analysis resolved.
+
+**Tier 1 — API Endpoint Gaps (all closed):**
+- Federation Admin API: 6 new admin YAML paths including GET/POST /api/v1/admin/federation/peers, :set-trust-posture, :suspend, /routed-requests, GET/PATCH /api/v1/admin/federation/config. Schemas: FederationPeer, FederationPeerRegistration, FederationConfig.
+- Scheduled Requests: 3 new admin paths for maintenance windows: GET/POST /maintenance-windows, GET/PATCH/DELETE /maintenance-windows/{uuid}, GET /maintenance-windows/{uuid}/scheduled-requests. Schemas: MaintenanceWindow, MaintenanceWindowCreate, MaintenanceWindowPatch.
+- Workload Analysis: 2 new consumer paths — GET /resources/{uuid}/workload-profile, POST /resources/{uuid}/workload-profile:analyze. WorkloadProfile schema added.
+- Accreditation Monitor: 3 new admin paths — :verify, :configure-webhook, /contract-event.
+- Final counts: consumer 63 paths / 33 schemas; admin 57 paths / 27 schemas.
+
+**Tier 2 — Implementation Gaps (doc 49 — 49-implementation-specifications.md, 728 lines):**
+- Rate Limiting (sec 2): Token bucket at API Gateway. Per-actor bucket, profile-governed parameters (60/min minimal to 600/min prod), PT120S TTL on state. 5 policies RLM-001 through RLM-005.
+- Audit Hash Chain (sec 3): SHA-256 with canonical concatenation (0x1F separator). GENESIS anchor for chain start. Continuous per-write verification + periodic sweep (PT1H sovereign, PT12H prod). Chain resealing endpoint: POST /api/v1/admin/audit/entities/{uuid}:reseal-chain.
+- Multi-Tenancy at Storage Layer (sec 4): GitOps=directory namespace, EventStream=per-tenant stream, Snapshot=PostgreSQL RLS + AES-256-GCM per-tenant key, Search=index namespace. Cryptographic tenant deletion via key revocation. 4 policies STI-001 through STI-004.
+- Cross-Region Replication (sec 5): Per-store replication model. Sovereignty-aware routing enforced at replication layer. Lag monitoring with degraded/unavailable state transitions. Last-write-wins + vector clocks for conflict resolution.
+- Secret Zero Bootstrap (sec 6): Bootstrap manifest with internal CA + pre-shared component credentials replaced by mTLS within PT5M of CA startup. credential management service takes CA key ownership on registration. Air-gapped options: embedded vault / operator passphrase / HSM. 4 policies BOOT-001 through BOOT-004.
+
+**Ownership Ambiguities (sec 7) — Both resolved:**
+- operation_uuid: issued by API Gateway at ingress (operation_uuid == request_uuid). API Gateway writes initial Operation; Request Orchestrator updates via shared fast store.
+- Credential Revocation Registry: owned by credential management service. Key: credential_uuid to revocation metadata. TTL: max(credential_ttl, P90D). Session Revocation Registry is separate — owned by Auth component.
+
+**Tier 3 — Security Posture (sec 8):**
+- Threat model: 5 boundaries (Consumer Ingress, Provider Interface, Admin, Internal Component, Storage). Highest-risk: credential management service compromise and Internal CA compromise — mitigated by air-gapped credential management service and HSM-backed CA for sovereign profiles.
+- Supply chain: provider OpenAPI spec signing (mTLS private key; rejected at GATE-SP-01 if unsigned), container image provenance via Sigstore/Cosign, GitOps secrets scanning, SBOM mandatory for fsi/sovereign. 5 policies SEC-001 through SEC-005.
+
+**Tier 4 — Experience Gaps (sec 9):**
+- New Tenant Onboarding (sec 9.1): full sequence — entity, groups, quota, admin actor, Git namespace, audit stream, member invitations, onboarding_complete event.
+- Pre-Request Cost Estimation UX (sec 9.2): catalog display then POST /cost/estimate with fields then dry_run: true for placement preview then actual submit.
+- Provider Sandbox/Test Mode (sec 9.3): sandbox_mode: true in registration, excluded from production placement, explicit targeting via _test_context, graduation path to production.
+- SLA/SLO Tracking (sec 9.4): SLO declared in Resource Type Specification (time_to_operational, uptime, drift_detection_latency), continuous measurement from audit records, breach events, consumer status endpoint, admin aggregate report endpoint.
+
+
+## SECTION 95 — CONTINUED: MATRIX + SPEC CLEANUP (2026-03)
+
+**Capabilities Matrix updated:** 38 domains / 299 capabilities (was 294).
+New capabilities added from doc 49 implementation specifications:
+- OBS-006: SLA/SLO Declaration (Resource Type Spec + consumer status endpoint + admin report)
+- OBS-007: SLO Breach Detection and Notification
+- STO-007: Cross-Region Sovereignty-Aware Replication (routing enforced at replication layer)
+- STO-008: Tenant-Scoped Storage Isolation (RLS + per-tenant stream + index namespace)
+- STO-009: Tenant-Scoped Encryption for fsi/sovereign (AES-256-GCM, credential management service managed)
+- ZTS-007: Provider OpenAPI Spec Signing (SEC-001, mandatory at GATE-SP-01)
+- ZTS-008: GitOps Secrets Scanning (SEC-002, SECRETS_DETECTED rejection)
+- ZTS-009: SBOM Declaration (SEC-003, mandatory fsi/sovereign)
+- PRV-010: Provider Sandbox/Test Mode
+- GOV-008: Tenant Onboarding Workflow
+
+**Admin API:** Added `GET /api/v1/admin/workload-analysis` — aggregate workload profile view across all tenants with archetype/confidence/resource_type filtering and archetype_distribution histogram. Admin API now: 57 paths / 27 schemas.
+
+**All 15 specification docs now have Document Status headers.** 7 specs updated: cncf-strategy, consumer-api-spec, dcm-admin-api-spec, dcm-flow-gui-spec, dcm-opa-integration-spec, dcm-operator-interface-spec, dcm-registration-spec.
+
+**Open markers: 0.** No TODO/FIXME, no Active Dev Notices, no superseded-by language, no V1 Migration references anywhere in the corpus.
+
+**Current state:** 55 data model docs / 15 specifications / 4 OpenAPI schemas / 38 domains / 299 capabilities / 97 prompt sections.
+
+
+## SECTION 96 — PROJECT OVERVIEW DOCUMENT (project-overview.md)
+
+New canonical document added: `project-overview.md` (located at dcm-docs root and Hugo /docs/project-overview).
+
+**Purpose:** Single authoritative description of DCM for any audience — engineers, business stakeholders, executives, or community members encountering the project for the first time. Referenced from README and Hugo navigation as the first document to read.
+
+**Content:**
+- What DCM Is: governing control plane above provisioning tools; not a deployment tool; the management plane that connects existing automation
+- Architecture in one sentence + event loop diagram
+- The Problem DCM Solves: 5 specific problems (fragmented ops, long TTM, private cloud gap, unreliable data, compliance overhead)
+- What DCM Does: three abstractions in full — Data (4 states), Policy (7 types with table), Provider (11 types with table)
+- What this enables: self-service consumer experience; standards enforced structurally
+- Who Benefits: Consumers, Platform Engineers, Security/Compliance, SRE, Auditors, FinOps — each with specific value statement
+- Where DCM Operates: deployment topology table (single-region/federated/hub-regional/sovereign), data sovereignty model, target environments with compliance frameworks listed
+- Key Facts table: accurate current counts (55 docs, 15 specs, 299 caps/38 domains, 63 consumer paths, 61 admin paths)
+- 9 Core Design Principles
+
+**README.md updated:** Accurate counts, new project-overview link as first doc in foundation table, all doc ranges updated (55 data model docs, 15 specs), AI prompt described as 98 sections.
+
+**Hugo updated:**
+- Root _index.md: replaced thin 'About DCM' with full What/Who/Three Abstractions/Benefits layout; Active Dev Notice removed
+- docs/_index.md: replaced Active Dev Notice with navigation cards including project-overview link
+- architecture/overview.md: Active Development Notice removed
+- /docs/project-overview.md: new Hugo page from project-overview.md
+
+
+## SECTION 97 — HOW + ETHOS SECTIONS ADDED
+
+**project-overview.md expanded** from 164 to 327 lines. Two new sections added:
+
+**## How DCM Works** (5 subsections):
+- The Event Loop: policy-driven event loop diagram showing event → Policy Engine → typed outputs → Providers/Data → new events
+- The Request Lifecycle: 5-step numbered sequence from intent declaration through layer assembly, policy evaluation, dispatch, and ongoing lifecycle
+- How Policy Replaces Hard-Coded Logic: why every business rule is a Policy artifact and what that means operationally
+- How Providers Integrate: base contract + capability extension model; organizations wrap existing automation, not replace it
+- How Data Sovereignty Is Enforced: structural property evaluated at every boundary; Governance Matrix always boolean; no scoring override
+
+**## Ethos** (5 subsections):
+- Security Is the Baseline, Not a Feature: minimal profile = security with minimal overhead, not minimal security; secure path must also be easy path
+- The Governed Path Must Also Be the Easy Path: self-service is the delivery mechanism for governance; if governed path is harder, teams route around it
+- Compliance Is Constructed, Not Audited: audit evidence and provenance are structural products of operations, not reconstructed post-hoc
+- The Architecture Should Be Easy to Implement and Extend: three-abstraction test; no core changes for new capabilities that fit Data/Provider/Policy
+- No Silent Behavior: every operation produces an observable artifact; every state transition audited; every decision has typed output
+
+**README.md updated** with condensed How + Ethos sections: event loop summary, request lifecycle in one paragraph, four design priority ethos statements, links to full sections in project-overview.md.
+
+
+## SECTION 98 — SUMMIT 2026 ROADMAP ALIGNMENT (2026-03)
+
+Source: DCM Technical Roadmap Summit 2026 presentation (Red Hat FlightPath Team).
+
+**Origin story from roadmap:**
+- Initial inspiration: US Navy warships disconnected for months, needing consistent updates in short windows
+- Summit 2025: Market gap identified for private cloud framework 'from Idea to Infrastructure'
+- June 2025: Banking consortium workshop identified three needs: automated workload placement, automated DC rehydration, standards-based APIs
+- Summit 2026: First public showcase of DCM Control Plane
+
+**Three Summit demo use cases:**
+1. Datacenter Rehydration — show rehydration meta process (CIO persona: restore after ransomware/90-day redeploy cycle)
+2. Intelligent Placement — show business logic via policies (CTO persona: metadata-driven infrastructure placement)
+3. Application as a Service — show Meta Service Provider (App Owner persona: full execution lifecycle from code)
+
+**Three post-Summit use cases:**
+1. Greening the Brownfield — discover unmanaged resources via Service Providers or CMDB import; lifecycle ownership transfer
+2. New Data Center Deployment — bootstrap new DC; automated workload migration from legacy DC
+3. Application Modernization — MTA integration; platform migration + code enhancement recommendations
+
+**MVP Roadmap phases:**
+- March 1: API gateway + Catalog API + policy in pipeline + data stores + initial rules (control plane core only)
+- April 1: Service Catalog Web UI + Service Providers (VM, OCP Cluster, Web App, X2Ansible, Networking, Firewall) + Rehydration trigger + Placement + Consumer API + SP integration specs
+- May 1: On-prem deploy + external message bus + observability + 3rd party module integration + long-term storage + IDM integration
+
+**Demo pipeline (slide 17) maps exactly to DCM architecture:**
+- App Request = Consumer POST /api/v1/requests
+- Requested Store = Intent State (GitOps)
+- Customize Region layer = Transformation Policy (Core Layer injection)
+- Tier Region Policy (OPA Rego) = GateKeeper/Validation Policy (Mode 3 OPA)
+- App Declaration = Requested State (assembled payload)
+- Declared Store = Requested State Store
+- Egress = Service Provider dispatch via Operator Interface
+- VM Service Provider Mock API = mock Service Provider for demo
+
+**Architecture coverage: FULL.** All three demos and all three MVP phases are architecturally specified.
+
+**Outstanding implementation decisions (ordered by urgency):**
+- Q6 (blocking): resource_uuid vs entity_uuid in Operation.metadata — must decide before code
+- Q7 (blocking): expires_at (26 refs) vs valid_until (canonical) — fix before session model implementation
+- Q1 (pre-March): Technology stack — recommended: NATS JetStream / custom Go API gateway / OPA sidecar / Gitea / PostgreSQL+Alembic
+- Q8 (pre-March): Intelligent Placement is best March 1 demo candidate (pipeline-only, mock SP)
+- Q2 (pre-April): Mock providers confirmed by slides (VM Service Provider Mock API explicit)
+- Q3 (pre-April): ACM — treat as Information Provider (feeds cluster inventory), not Service Provider
+- Q4 (pre-April): X2Ansible — needs resource type spec for AAP job template/workflow as DCM resource
+- Q5 (pre-April): Firewall — handle as FirewallRule sub-resource of Networking Meta Provider
+- Q9 (pre-April): RHDH vs Consumer GUI — RHDH is likely Summit target (Red Hat branding on slides)
+- Q10 (pre-April): 'Data Center Pipeline' = RHDH scaffolding sitting above DCM Consumer API; consistent with RHDH integration spec
+
+
+## SECTION 99 — IMPLEMENTATION DECISIONS + EXAMPLE #1 (2026-03)
+
+**Field name decisions (final):**
+- resource_uuid: KEEP (AEP standard) — Operation.metadata already correct; entity_uuid is correct everywhere else in the model
+- expires_at: KEEP (valid_until replaced) — 77 refs across 20 files + 1 OpenAPI schema replaced; valid_until is now gone from corpus
+
+**Technology stack (Red Hat sanctioned open source):**
+- Event bus: AMQ Streams (Apache Kafka on OpenShift) — Kafka CR via AMQ Streams operator
+- API Gateway: Custom Go service — thin, controllable for demo; Service Mesh handles mTLS
+- Policy engine: OPA (Open Policy Agent) — Mode 3 sidecar + standalone Deployment for complex policies
+- Git server: GitLab CE (self-hosted) — Intent Store, Requested Store, Policy Store
+- Database: PostgreSQL — CrunchyData PGO operator
+- Service Mesh / mTLS: OpenShift Service Mesh (Istio/Envoy) — STRICT PeerAuthentication across all namespaces
+- Secret Management: HashiCorp Vault + External Secrets Operator
+- Auth / IDM: Keycloak (Red Hat SSO) — OIDC; DCM Auth Provider implementation
+- Observability: OpenTelemetry + Prometheus + Grafana (OpenShift Monitoring stack)
+- Front End: RHDH (Red Hat Developer Hub / Backstage) + DCM plugin
+- Deployment automation: Ansible Automation Platform
+- Certificate management: cert-manager
+
+**Provider decisions:**
+- Real providers (not mocks) — exercises architecture portability
+- VM as a Service: DCM → AAP → KVM/libvirt or OpenStack Nova
+- Network Port: DCM → Netbox (IPAM) or OpenStack Neutron
+- OCP Cluster: DCM → ACM Shim (Go service) → ACM API → ClusterDeployment (Hive)
+- ACM also as Information Provider: feeds cluster inventory/capacity into placement engine
+- Web App: Meta Provider composing VM + Network Port + OCP Cluster (optional)
+- X2Ansible: deferred. Firewall: deferred.
+
+**New document: implementations/example-1-summit/IMPLEMENTATION.md** (1029 lines)
+Contents:
+- Purpose and scope (3 Summit demos + portability validation goal)
+- Technology stack table (all Red Hat sanctioned choices)
+- Architecture overview ASCII diagram (3 namespaces: dcm-system, dcm-providers, dcm-infra)
+- Provider specs: VM, Network Port, OCP Cluster (ACM Shim), Web App Meta Provider
+- All 3 demo use case flows: Intelligent Placement, DC Rehydration, App as a Service
+- Namespace + Pod design (API Gateway with OPA sidecar, Orchestrator, Policy Engine, Provider pods)
+- Full OpenShift file structure (ansible/ + openshift/ + config/ directories)
+- Key Kubernetes resources: Kafka topics, Istio mTLS PeerAuthentication, ExternalSecret CRs
+- Configuration files: dev profile YAML, Tier Region Policy Rego (matches slide 17 exactly), VM catalog item YAML
+- Ansible playbooks: site.yml master, group_vars, Kafka role task, provider registration task
+- Portability notes: what changes vs what doesn't when providers are replaced
+- Demo seed data: tenants, users, resource types, catalog items, Core Layers, sample policies
+
+**Namespaces:** dcm-system (control plane), dcm-providers (all providers), dcm-infra (supporting infra)
+**Deployment:** Ansible site.yml → prerequisites → infra → dcm-control-plane → dcm-providers → dcm-demo-data
+
+## SECTION 100 — EXAMPLE IMPLEMENTATION #1 — SUMMIT DEMO (2026-03)
+
+New artifact: `implementations/example-01-summit-demo/` — 57 files / 5,683 lines.
+Labeled as Example Implementation #1. Isolated from core architecture docs.
+Purpose: validate DCM architecture/data model and demonstrate portability.
+Providers built here may be replaced — this is an exercise in the Provider contract.
+
+**Implementation decisions applied:**
+- `resource_uuid` in Operation.metadata (AEP convention — kept as-is, already correct)
+- `expires_at` for token/session expiry (already canonical in schemas — 0 occurrences of valid_until)
+- Technology: AMQ Streams (Kafka), GitLab CE, PostgreSQL (CrunchyData PGO), OPA sidecar, Keycloak, Vault, OpenShift Service Mesh, RHDH
+- All Red Hat sanctioned OSS where possible
+
+**Directory structure:**
+- `openshift/` — 27 YAML manifests: namespace, RBAC, all control plane deployments, all provider deployments, storage, auth, vault, service mesh, RHDH, monitoring
+- `ansible/` — 12 files: site.yml master playbook + inventory + 10 roles (operators, storage, auth, vault, service-mesh, control-plane, providers, rhdh, seed-data)
+- `config/` — 13 files: PostgreSQL schema (RLS + hash chain tables), OPA policies (Rego), Keycloak realm, DCM profile/layers/catalog-items
+- `docs/` — 5 files: README, ARCHITECTURE mapping, deployment guide, demo script, provider dev guide
+
+**Control plane (8 Go services, each a separate container/Deployment):**
+dcm-api-gateway, dcm-request-orchestrator, dcm-policy-engine, dcm-placement-engine, dcm-request-processor, dcm-audit, dcm-catalog, dcm-discovery
+
+**Storage stack:** PostgreSQL (Snapshot Store + Operations + Audit), GitLab CE (GitOps Store), AMQ Streams/Kafka (Event Stream), OpenSearch (Search Index)
+
+**Service Providers (5):**
+- dcm-provider-vm: wraps AAP/Ansible for VM provisioning (OIS Level 2)
+- dcm-provider-ocp-cluster: wraps RHOCP/CAPI (OIS Level 2)
+- dcm-provider-network: wraps AAP for network ports/VLANs (OIS Level 2)
+- dcm-provider-acm-shim: shim wrapping ACM API as standard DCM provider; ClusterRole grants ACM ManagedCluster/Placement/ManifestWork access
+- dcm-provider-webapp: Meta Provider composing VM + Network + OCP Cluster (OIS Level 1; sequential with rollback)
+
+**OPA Rego policies (Summit demo):**
+- tier-region.rego: GateKeeper (compliance) — enforces zone ⊆ tier allowed zones. Matches slide 17 demo exactly.
+- vm-sizing.rego: Validation (structural) — CPU/RAM/storage bounds by environment
+- placement-weights.rego: Transformation — 5-signal scoring (capacity 35%, affinity 10%, cost 20%, perf 20%, risk 15%)
+
+**Security posture:**
+- STRICT mTLS via OpenShift Service Mesh across all components (Boundary 4)
+- Per-component ServiceAccounts with minimum RBAC
+- Vault: per-provider policies (vm provider can only read dcm/data/providers/vm/*)
+- PostgreSQL RLS: dcm_app role cannot query across tenant boundaries
+- Keycloak PKCE for RHDH consumer authentication
+- Audit records: append-only enforced by SQL trigger + REVOKE UPDATE/DELETE
+
+**Demo script covers 3 use cases:**
+1. Intelligent Placement (March 1): tier-region.rego enforces zone policy; pipeline visible in RHDH
+2. Datacenter Rehydration (April 1): simulate DC loss; :rehydrate endpoint replays Intent through current policies
+3. Application as a Service (April 1): single request → webapp Meta Provider sequences Network + VM + OCP Cluster
+
+**Deploy single command:** `cd ansible && ansible-playbook site.yml -i inventory/hosts.yml`
+**BOOT-002:** Bootstrap admin password CHANGE_ME_BOOT002 must be rotated on first login.
+
+
+## SECTION 101 — FULL SYNC COMPLETE (2026-03)
+
+Complete documentation sync performed. All artifacts now in sync.
+
+**Current corpus state:**
+- Data model: 55 documents (00-foundations through 49-implementation-specifications + A-provider-contract + B-policy-contract)
+- Specifications: 15 documents (all with Document Status headers)
+- OpenAPI schemas: consumer 63 paths/33 schemas, admin 57 paths/27 schemas, operator 5 paths/12 schemas, callback 7 paths/11 schemas
+- Capabilities Matrix: 38 domains / 299 capabilities (verified: summary count matches row count)
+- AI Prompt: 103 sections, 0 duplicates
+- Open markers (TODO/FIXME/Active Dev Notice/superseded-by/V1 Migration): 0
+- Example Implementation #1: 57 files / 5,683 lines
+
+**Hugo website state (fully synced):**
+- /docs/data-model: 55 files
+- /docs/architecture/data-model: 109 files (55 source + 54 duplicates from earlier build — source is /docs/data-model)
+- /docs/architecture/specifications: 24 files (15 specs + 4 OpenAPI YAMLs + indexes)
+- /docs/implementations/example-01-summit-demo: 5 pages (README, architecture mapping, deployment guide, demo script, provider dev guide)
+- Active Development Notices: removed from all files (3 remaining instances cleared in this sync)
+- Navigation: root _index, docs _index, architecture _index, implementations _index all updated with current content
+
+**README.md (135 lines):** accurate counts, implementation section added, AI prompt section count updated to 103.
+
+**project-overview.md (328 lines):** accurate counts, reference implementation entry added to Key Facts table.
+
+**DISCUSSION-TOPICS.md:** 6 items including Lightspeed Interface concept (item 6) and Kessel evaluation (item 4).
+
+**Implementation status:** Example #1 fully specified. Architecture fully ready for implementation. Remaining pre-coding decisions: event bus tech, API gateway tech, policy engine runtime, Git server — all documented in prompt section 99 (Summit Roadmap Alignment). All field names resolved (resource_uuid per AEP, expires_at for token expiry).
+
+
+## SECTION 102 — WORKING INSTRUCTIONS FOR AI MODELS
+
+When working on this project, apply these instructions in addition to the numbered guidance in SECTION 60 (Documentation Structure):
+
+172. **DCM defaults to federated data creation** — platform admins are not the only contributors; consumers author tenant-domain policies; providers publish resource type specs and service layers; peer DCMs contribute registry entries; all via GitOps PR with profile-governed review
+173. **Contributor domain scope is hard DENY at submission** — consumers cannot contribute system/platform policies regardless of declared domain; providers cannot contribute specs for types they don't offer; enforced by Governance Matrix at contribution time (FCM-002)
+174. **All contributed policies enter shadow mode by default** — proposed status with shadow evaluation before activation; shadow_review_period is profile-governed (P7D standard → P30D fsi/sovereign); platform admin reviews divergence cases before promoting
+175. **Orphaned artifacts do not auto-deactivate** — when contributor's access is revoked, their active artifacts remain active until platform admin assigns new owner or explicitly retires; exception: sovereign profile auto-retires orphaned artifacts (FCM-006)
+176. **GateKeeper enforcement_class is required and fail-safe** — if omitted, treated as compliance (boolean deny). Operational-class GateKeepers never halt the request; they contribute a weighted risk_score_contribution to the aggregate. The aggregate risk score determines approval routing, not individual policy outcomes.
+177. **Validation output_class is required and fail-safe** — if omitted, treated as structural (boolean halt). Advisory-class Validations never halt requests; they accumulate completeness score and warning list surfaced to the consumer.
+178. **Governance Matrix is always boolean — never scored** — SMX-004 is absolute. Scoring cannot be used to route around data sovereignty or regulatory boundaries. The Governance Matrix evaluates before the scoring pipeline runs.
+179. **Profile thresholds determine routing, not individual policies** — the approval routing decision (auto/review/dual/authorized) emerges from the aggregate risk score crossing profile-configured thresholds, not from individual policy flags. Changing governance sensitivity = adjusting thresholds in the profile.
+180. **SMX-008 is a hard system constraint** — auto_approve_below may never exceed 50 in any profile. Platform admins cannot override this. Profiles submitted with auto_approve_below > 50 fail validation.
+181. **Meta Provider is a compound service definition + standard Service Provider** — not an orchestrator. It declares the dependency graph so DCM can place, sequence, and govern constituents. For `self` constituents it executes as any Service Provider does. DCM handles all orchestration, placement, failure, and compensation.
+182. **Composite Entity has ONE entity UUID** that links Intent, Requested, Realized, and Discovered states; the UUID is assigned at Intent creation and is stable throughout the lifecycle including rehydration
+183. **DEGRADED is a valid terminal state** — not an error; a DEGRADED entity enters standard OPERATIONAL lifecycle; profile governs whether degraded delivery is accepted; Recovery Policy governs failure/compensation decisions
+184. **Parallelism emerges from the dependency graph** — constituents with no unresolved dependencies dispatch concurrently within DCM's pipeline; the Meta Provider does not manage this
+186. **Credential values are NEVER stored in DCM** (CPX-001) — only metadata is stored; values are held by the credential management service; retrieved via authenticated endpoint; this applies to ALL credential types including dcm_interaction credentials
+187. **Every provider dispatch requires a scoped interaction credential** (CPX-002) — issued before dispatch, scoped to the specific operation+entity+provider, expires PT15M; provider must validate at use time not just receipt; check revocation cache on each use
+189. **Security properties are present in ALL profiles — minimal profile is "security with minimal operational overhead" not "minimal security"** — rotation required in all profiles (minimal: P365D max, manual OK); idle detection on in all profiles (minimal: P30D); algorithm baseline in all profiles (minimal: forbidden list); CPX-001 (values never in DCM stores) is absolute — homelab (minimal) uses bearer_token retrieval, no scheduled rotation, no FIPS; sovereign uses mtls+hardware attestation, FIPS Level 3, PT15S revocation cache; same API contract, same data model, same CPX-001 (values never in DCM stores)
+196. **API versioning is per-surface not per-endpoint** (VER-001) — Consumer, Admin, Provider/OIS, Flow GUI each have their own major version; all endpoints within a surface share the version; when in doubt whether a change is breaking, it is (VER-002); prod support window is 2 years deprecated after 1 year notice; sovereign is 4 years deprecated after 2 years notice; deprecated versions return Deprecation + Sunset headers (RFC 8594/RFC 9745)
+197. **Consumer API has 16 sequential sections (reorganized)** — sections were renumbered 1–16 in logical order: Auth(2), Catalog(3), Requests(4), Resources(5), Drift(6), Groups(7), Approvals(8), Cost(9), Notifications(10), Search(11), Audit(12), Errors(13), Contributions(14), Credentials(15), Conformance(16); old 5b/5c/6b/7b numbering is gone
+198. **Admin API base URL is /api/v1/admin/ (version-first)** — NOT /admin/api/v1/; all 40 admin endpoints use /api/v1/admin/; this is the authoritative form used everywhere in the specs and data model docs
+199. **Consumer API has idempotency (1.5), rate limiting (1.6), request IDs (1.7), and standard envelope (1.8)** — POST requests support Idempotency-Key header (PT24H retention); rate limits are profile-governed (60/min minimal → 600/min sovereign) with Retry-After on 429; all list responses use {"items":[...],"total":N,"next_cursor":"..."} envelope; X-DCM-Request-ID and X-DCM-Correlation-ID on all responses
+200. **OIS health check response is normative (not optional)** — providers MUST return {status: pass|warn|fail, version, dcm_registration_status}; missing/malformed body = warn; 3 consecutive non-200 = provider.unhealthy event; response format follows RFC 8615 / IANA health+json
+201. **Doc 35 (35-session-revocation.md) is complete** — session lifecycle: intent→requested→realized store model; AUTH-016 (deprovisioning revokes sessions AND credentials in parallel); AUTH-017 (revocation SLA: PT5M minimal → PT5S sovereign); AUTH-018 (ALL components check revocation registry on every bearer token request — no exceptions); AUTH-019 (emergency revocation = critical urgency, non-suppressable); AUTH-020 (introspection endpoint authenticated); AUTH-021 (oldest session revoked on concurrent limit breach); AUTH-022 (refresh tokens invalidated on parent session revocation); session endpoints: DELETE /api/v1/auth/session, DELETE /api/v1/auth/sessions, GET /api/v1/auth/sessions, DELETE /api/v1/auth/sessions/{uuid}; admin: POST /api/v1/admin/actors/{uuid}/revoke-sessions
+202. **Doc 36 (36-internal-component-auth.md) is complete** — ICOM-001 (all internal calls mTLS); ICOM-002 (scoped interaction credential required IN ADDITION to mTLS on every call); ICOM-003 (unauthorized source → 403 + audit); ICOM-004 (components may only call declared allowed_targets); ICOM-005 (all internal calls audited); ICOM-006 (P90D max cert validity); ICOM-007 (bootstrap tokens one-time-use, PT1H max); ICOM-008 (compromised cert → CRL immediately); ICOM-009 (Internal CA root in all trust stores at deploy); component communication graph is declared and enforced — not implicit; every call: mTLS cert (transport identity) + ZTS-002 interaction credential (operation authorization)
+203. **Session revocation and internal component auth complete the zero trust model** — external boundary: provider↔DCM uses mTLS + scoped credentials (CPX-001–CPX-012); internal boundary: component↔component uses Internal CA mTLS + ZTS-002 interaction credentials (ICOM-001–ICOM-009); actor sessions: Auth Provider issues tokens; Session Revocation Registry checked on every request (AUTH-018); credentials: credential management service manages values that never touch DCM stores (CPX-001); together these four surfaces cover the complete trust boundary
+
+201. **35-session-revocation.md (AUTH-016–AUTH-022)** — session revocation and credential revocation are PARALLEL on actor deprovisioning (not sequential); revocation registry must be checked on EVERY request by ALL components; sovereign profile: no revocation registry cache; emergency revocation (security_event) is critical urgency + non-suppressable; refresh tokens are invalidated when parent session is revoked (AUTH-022)
+202. **36-internal-component-auth.md (ICOM-001–ICOM-009)** — network position grants ZERO trust for internal calls — same five-check boundary model as external; every internal call requires BOTH mTLS cert AND ZTS-002 interaction credential; bootstrap tokens are one-time-use PT1H max; unauthorized source component → 403 + high-urgency audit; component certs from Internal CA only, max P90D, never external CA
+203. **SES and ICOM domains added to capabilities matrix** — matrix is now 177 capabilities across 28 domains; SES-001–SES-005 (session lifecycle, deprovisioning, emergency revocation, introspection, concurrent enforcement); ICOM-001–ICOM-005 (mTLS, bootstrap, call authorization, interaction credentials, cert revocation)
+204. **Domain prefix totals now 28** — IAM CAT REQ PRV LCM DRF POL LAY INF ING AUD OBS STO FED GOV ACC ZTS GMX DRC FCM SMX MPX CPX DPO ATM EVT VER SES ICOM; README and taxonomy both updated to 177/28
+205. **Doc 37 (Scheduled Requests): dual policy evaluation** — GateKeeper runs at declaration AND at dispatch; dispatch-time rejection = FAILED not retried; schedule field is optional addition to existing POST /api/v1/requests body; SCHEDULED status is cancellable; not_after deadline miss = terminal FAILED (SCH-005)
+206. **Doc 38 (Request Dependency Graph): distinct from type-level and Meta Provider deps** — consumer-declared ad-hoc ordering for independent requests; POST /api/v1/request-groups; PENDING_DEPENDENCY status counts against quota at submission not dispatch; max 50 requests per group; circular deps → 422 at submission; field injection passes realized outputs into dependent request fields automatically
+207. **Doc 39 (DCM Self-Health): three endpoints, different purposes** — /livez (liveness, PT5S max, no external calls, Kubernetes restarts pod on fail) vs /readyz (readiness, checks 5 core dependencies, Kubernetes removes from LB) vs /api/v1/admin/health (per-component detail, admin auth required, Prometheus metrics at /metrics); all follow RFC 8615 / IANA health+json
+208. **Capabilities matrix now 189 across 31 domains** — SES(5) ICOM(5) SCH(4) RDG(4) HLT(4) added; domain prefixes: IAM CAT REQ PRV LCM DRF POL LAY INF ING AUD OBS STO FED GOV ACC ZTS GMX DRC FCM SMX MPX CPX DPO ATM EVT VER SES ICOM SCH RDG HLT (31 total)
+209. **40-standards-catalog.md is the authoritative source for all DCM standards** — forbidden algorithms (MD5, SHA-1, DES, 3DES, RC4, RSA<2048) are prohibited in ALL profiles with no exceptions; TLS 1.0/1.1 prohibited in ALL profiles; ECDSA P-384 is the mandated algorithm for Internal CA certs; AAL mapping: minimal/dev=AAL1, standard/prod=AAL2, fsi=AAL2+, sovereign=AAL3; doc 40 Section 8 maps every standard to the docs that use it
+209. **External CAs belong in the credential management service (NOT Auth Provider)** — Auth Provider authenticates identity; credential management service manages credential lifecycle; External CAs (Vault PKI, Venafi, EJBCA, AWS ACM PCA) are x509_certificate credential management services using ACME(RFC 8555)/EST(RFC 7030)/SCEP/CMP protocols; ICOM-009 updated — trust anchor is any registered CA root, not just built-in Internal CA; doc 36 profile table: cert lifetime P180D(minimal) → P14D(sovereign); sovereign requires HSM-backed certs if hardware_attested posture
+210. **Live updates: SSE stream + OIS interim status** — GET /api/v1/requests/{uuid}/stream (text/event-stream, closes on terminal status) for browser/CLI without polling; events: status_change, progress_updated, approval_required, approval_recorded, heartbeat(30s); OIS providers POST /api/v1/provider/entities/{uuid}/status for interim progress with step_current/step_total/constituent_status; request.progress_updated event added to doc 33; rate-limited: max 1 interim status per 10s per entity
+211. **Profile coverage added to docs 36-39** — doc36 cert lifetime table(P180D minimal→P14D sovereign), algorithm min table; doc37 max scheduling horizon(P365D minimal→P7D sovereign), concurrent scheduled limit, maintenance window approval tier; doc38 max group size(100 minimal→5 sovereign), group timeout max, field injection validation strictness, nesting depth; doc39 metrics scraping restrictions(sovereign internal only), /api/v1/admin/health MFA requirements(fsi/sovereign)
+212. **40-standards-catalog.md is the authoritative standards reference** — 19 RFCs, 3 cryptographic standards tables (permitted algorithms, forbidden algorithms, FIPS levels), 6 compliance frameworks, 7 CNCF ecosystem projects, W3C SSE, OpenAPI 3.1, SPIFFE (informative), HashiCorp Vault PKI / Venafi / EJBCA as External CA credential management service backends (NOT Auth Providers); Section 9 maps all 17 policy families to their standards basis; usage map tracks which standards appear in which documents
+213. **41-operational-reference.md covers the three operational gaps** — GitOps partitioning (3 strategies; tenant-shard recommended; trigger thresholds table), store migration (5-phase dual-write playbook; never decommission source before burn-in; audit chain continuity required OPS-002), DR (5 scenarios; post-recovery validation checklist mandatory OPS-005; Audit Store minimum P365D retention all profiles OPS-006); RTO: PT1M sovereign component → PT24H minimal repave
+214. **Three GUI specs define the unified DCM web application** — one application with role-gated surfaces: Consumer Portal (all actors — catalog, SSE live status with constituent tracking, resources, approvals, cost, sessions), Admin Panel (platform roles — health dashboard, tier registry drag-drop editor with hard-stops, scoring slider max 50), Provider Management (provider_owner role — 5 provider types with common shell + type-specific tabs; Credential management shows metadata never values; algorithm compliance must show zero forbidden algorithm violations)
+215. **Doc 42 adds 12th provider type (ITSM integration) and 8th policy type (ITSM Action Policy)** — ITSM is ADDITIVE (DCM never requires it); ITSM Action Policy is side-effect only (non-blocking default); block_until_created requires block_timeout (never permanently stalls pipeline, ITSM-005); recorded_via field already existed on approval vote — ITSM inbound approvals use it; 6 policy examples covering ServiceNow + Jira for provisioning, CMDB sync, incident on drift, decommission; itsm.* event domain adds 3 events (85 total, 21 domains)
+215. **Consumer GUI ITSM bridge (GUI-011, section 8 of dcm-consumer-gui-spec.md)** — ITSM is a CONSUMER of DCM events, not a source of truth; DCM is the system of record; CMDB sync is one-way DCM→CMDB via notification service subscription to entity.* events; ITSM approval votes call POST /api/v1/admin/approvals/{uuid}/vote — the CAB process happens in ITSM, DCM just records the outcome; ITSM references stored as business data fields on entities; Audit Trail (section 11) is consumer-scoped own-resource view; cross-tenant audit is Admin Panel only
+215. **RHDH/Backstage is the PRIMARY consumer GUI deployment model** — 6 Dynamic Plugin packages (no RHDH rebuild); Scaffolder IS the request form (auto-generated templates from catalog item JSON Schema); DCMService + DCMResource entity kinds sync to RHDH catalog every PT5M; tenancy via RHDH Group context → X-DCM-Tenant; OIDC token exchange for auth delegation; PatternFly NavGroup/NavItem/NotificationBadge for sidebar; Approvals shows live pending count badge; all compliance enforced by DCM control plane — RHDH is a client
+195. **33-event-catalog.md is the SINGLE authoritative source for all DCM event types** — 82 events across 26 domains; all events share the base envelope (event_uuid, event_type, event_schema_version, timestamp from Commit Log, urgency, payload, links); consumers implement idempotency using event_uuid; critical urgency events are non-suppressable; non-standard events use reverse-DNS prefix; event_schema_version only increments on breaking changes
+194. **Tier registry changes are gated by impact detection** — any change that creates a SECURITY_DEGRADATION (tier gravity or position decreased) blocks activation until each degradation is explicitly accepted by a verified-tier or above reviewer via Admin API; BROKEN_REFERENCE also blocks; PROFILE_GAP is a warning that does not block; all changes produce an impact report in the Audit Store (ATM-009–012)
+193. **Authority tiers are named positions in an ordered list — not fixed enum values** — tier weight derived from list position at evaluation time; organizations insert custom tiers between existing ones without breaking existing name references; 'authorized' tier always means 'highest current gravity' regardless of what's been inserted before it; ATM-001: never hardcode tier weights
+192. **DCM provides the approval gate and audit trail — the review process is the organization's responsibility** — for authorized tier: DCM tracks quorum of a DCMGroup; the authorized deliberation and vote collection happen outside DCM; external systems (ServiceNow, Jira, Slack bots) can call Admin API to record votes; DCM does NOT build authorized management; for reviewed and verified: same principle — DCM holds the pipeline until the API receives the required decisions
+191. **The priority order is a decision framework, not a suggestion** — when security and ease of use conflict, security wins AND you must design an easy mechanism for the secure path; "it's too complex" is a reason to improve the ease-of-use design, not to reduce security; "minimal profile" means minimal overhead, never minimal security (DPO-005, DPO-006)
+190. **key_usage is declared at issuance and validated at use** (CPX-009) — a credential issued for authentication cannot be used for signing; credential management service must validate this at the validate endpoint; prevents algorithm confusion attacks
+188. **Actor deprovisioning and entity decommissioning trigger immediate credential revocation** (CPX-006, CPX-007) — deprovisioning publishes revocation events before the deprovisioning is acknowledged; decommission is blocked until all entity-scoped credentials are revoked
+185. **provided_by: external constituents are placed by DCM's Placement Engine** — all governance controls (sovereignty, accreditation, trust) apply; the Meta Provider has no influence over external constituent provider selection
+
+---
+
+## Session: Architecture Consistency and Policy Model (April 2026)
+
+**Summary:** Infrastructure consolidated to 1 required dependency (PostgreSQL). Auth, secrets, and events handled internally by default with optional external delegation. Policy evaluation model expanded with Evaluation Context, Constraint Type Registry, and Policy Templates. Full consistency pass across all 58 data model docs and 15 specifications.
+
+216. **One required infrastructure: PostgreSQL** — Authentication (local accounts + argon2id + DCM-issued JWT), secrets (envelope encryption with AES-256-GCM + KEK from environment), and event routing (LISTEN/NOTIFY) are all handled internally. External systems (OIDC IdP, Vault, Kafka, Redis, Git, service mesh) are optional deployment enhancements registered through the standard provider contract.
+
+217. **Internal/External pattern applied three times** — Policy evaluation (Internal: OPA evaluates; External: external provider evaluates). Secrets management (Internal: PostgreSQL secrets table + envelope encryption; External: Vault-compatible API). Authentication (Internal: actors table + argon2id + JWT; External: auth_provider — OIDC, SAML, LDAP). Same pattern, consistent across all three domains.
+
+218. **Data-driven policy matching** (doc B §2) — A policy fires when the data says it should fire. Any field from three sources (request payload, evaluation context, entity metadata) can be a match trigger. No pre-assignment of policies to resource types. Specificity ranges from universal (no conditions) to fully scoped (VMs in DMZ in zone A for application UUID XXXXX).
+
+219. **Evaluation Context with multi-pass convergence** (doc B §7) — Transient constraint space scoped to one request evaluation. Three phases per pass: collect constraints, resolve conflicts, apply and validate. Hard/soft constraint binding. Auto-resolution via declared `on_conflict` strategies. Maximum 3 passes (configurable). Unresolvable hard-hard conflicts escalate to human. Per-pass audit captures complete context snapshots.
+
+220. **Constraint Type Registry** (doc B §8) — Shared vocabulary for the Evaluation Context. Each constraint type has a canonical name, OpenAPI v3 schema, emittable_by/consumable_by declarations. 10 built-in types (zone_restriction, distribution_requirement, cost_ceiling, network_restriction, resource_limits, compliance_requirement, sovereignty_boundary, approval_requirement, scheduling_constraint, provider_restriction). Organizations register custom types. Validation at policy activation catches vocabulary mismatches at authoring time.
+
+221. **Policy Templates** (doc B §9) — Gatekeeper ConstraintTemplate pattern adapted for DCM. Templates define reusable Rego logic with parameter schemas and declared emitted/consumed constraint types. Policy artifacts are instances binding parameters and match conditions. DCM auto-generates `data.dcm.constraint_types` Rego library from the Constraint Type Registry — constructor functions enforce schemas at compile time.
+
+222. **Doc 11 rewritten** as "Data Store Contracts" (791→154 lines) — Enforcement rules for the four PostgreSQL data domains (append-only, RLS, hash chain, REVOKE grants). No storage provider abstraction.
+
+223. **Doc 31 rewritten** as "Credential Management" (979→154 lines) — Internal secrets via PostgreSQL envelope encryption (default). External via Vault-compatible API (optional). Consumer-facing credentials handled by service_provider with Credential.* resource types.
+
+224. **Doc A §7 rewritten** as 5 provider types (556→387 lines) — Removed Storage, Policy, Credential, Notification, Message Bus, Registry, ITSM as separate types. Added Process Provider (ephemeral workflow execution). Service Provider description updated to cover Credential.*/Notification.*/ITSM.* resource types.
+
+225. **Doc 14 §4 rewritten** — "External Policy Evaluators" (4 modes) → "Policy Evaluation Modes" (Internal/External). BBQ-001–009 governance preserved for External mode. Mode numbering removed.
+
+226. **Doc 02 §4 rewritten** — "data store Model" (old terminology) → "Data Domain Model" with PostgreSQL table enforcement. Git as optional ingress adapter, not a state store.
+
+227. **Capabilities matrix updated** — 309→331 capabilities. Added: POL-008 (Constraint Type Registry), POL-009 (Evaluation Context), POL-010 (Policy Templates), POL-011 (DCM Constraint Types Library), POL-012 (Data-Driven Matching), STO-010 (Internal Secrets), STO-011 (Pipeline Event Routing), STO-012 (Internal Authentication). Domain 13 (Storage) rewritten for PostgreSQL. Domain 23 renamed to Credential Management.
+
+228. **Bulk consistency pass** — Zero old provider type references remain outside AI prompt historical sections. Zero old store model references. Zero old policy mode references (Mode 3/4) in policy contexts (information provider retrieval modes correctly retained). All "3 required infrastructure" / "Vault required" / "Keycloak required" references updated.
+
+229. **Unified audit and payload integrity via Merkle tree** (doc 16 §8) — RFC 9162 (Certificate Transparency v2.0) pattern. Each audit record is a Merkle leaf with input/output payload hashes, service signature, and tree position. Inclusion proofs (O(log n)), consistency proofs, and request chain verification unify audit trail integrity and payload chain of custody into one mechanism. Satisfies NIST 800-53 AU-9(3), AU-10(2/3/5), SI-7; FIPS 186-5 (Ed25519); FedRAMP High AU-10.
+
+230. **Configurable audit granularity** (doc 16 §8.1) — Three levels: `stage` (~6 leaves/request — one per pipeline stage), `mutation` (~15-30 leaves — one per layer merge, policy evaluation, constraint resolution), `field` (mutation + per-field old/new value hashes). Profile defaults: minimal/dev → stage, standard/prod → mutation, fsi/sovereign → field (minimum, cannot downgrade). Inter-stage verification: synchronous (fsi/sovereign required), asynchronous, or disabled (homelab).
+
+231. **Lifecycle-scoped policy evaluation** (doc B §2.2–2.3) — 10 lifecycle operation types: initial_provisioning, update, scale, rehydration, decommission, ownership_transfer, subscription_renewal, drift_remediation, provider_migration, compliance_rescan. Each policy declares `lifecycle_scope` specifying which operations trigger it. `changed_field_filter` enables policies to fire only when specific fields change on update/scale operations (e.g., placement policies skip memory-only changes, sovereignty fires on zone/provider changes). Profile-governed minimums: fsi/sovereign require sovereignty and GateKeeper policies on ALL lifecycle operations — cannot be scoped down.
+
+232. **Policy Override Model** (doc B §18) — Five override mechanisms organized by severity: Override Policy (planned exceptions, full lifecycle, cannot target hard policies), Exception Grant (pre-authorized time-bounded waiver with compensating controls, dual-approval for hard), Manual Override (immediate single-request authorization, dual-approval for hard), Dual-Approval Escalation (required modifier for hard policy overrides — two individuals from different roles), Compensating Control Substitution (satisfy policy intent through different mechanisms without actually overriding). Every override produces a Merkle tree audit leaf. Profile-governed: fsi/sovereign require dual-approval on ALL overrides.
+
+233. **Test Framework Specification** (doc 52) — Automated self-reflecting test framework for data model and architecture validation. Generate→Execute→Verify→Analyze→Enhance loop. Machine-readable architecture summary (YAML) covering all fundamentals: 4 data domains, 5 provider types, 10 lifecycle operations, 8 policy types, 5 override mechanisms, 3 audit granularity levels. 56 named invariants across 7 categories: MATCH (7), EVAL (8), OVRD (9), LSCOPE (4), DATA (3), MRKL (6), RLS (3), PROV (7). Edge case categories: policy interaction (7 scenarios), provider (5), data integrity (5), lifecycle (5). Framework outputs enhancement proposals when gaps are discovered.
+
+234. **Override Approval Flow** (doc B §18.8) — When a policy blocks a request and no automatic resolution exists (no active override policy, exception grant, or compensating control), the request enters PENDING_OVERRIDE status. DCM publishes `override.required` event. Notification routing delivers to eligible approvers via internal (LISTEN/NOTIFY → Consumer Portal) and external (webhook to ServiceNow/Jira/Slack) channels. Approver(s) act via Admin API (`POST /api/v1/admin/overrides/{request_uuid}/approve`). For dual-approval: first approval recorded, second notification sent, pipeline held until both arrive or timeout. On approval: pipeline resumes from blocked stage with override injected into Evaluation Context. On timeout: request fails with OVERRIDE_TIMEOUT. Timeout is profile-governed (minimal/dev: PT24H, standard/prod: PT4H, fsi/sovereign: PT1H). `override_requests` table (18th SQL table) stores the complete approval record.
+
+235. **Override events and API** — 5 new events (override.required, override.first_approval, override.approved, override.rejected, override.expired) bring total to 109 event payloads across 23 domains. 4 new Admin API endpoints (list/get/approve/reject) bring admin paths to 61.
+
+236. **Policy Block Resolution** (doc B §18.8) — When a policy blocks a request and no automatic resolution exists, DCM does NOT silently enter an override queue. The request enters POLICY_BLOCKED status and the consumer is notified with actionable guidance: what blocked the request, why, compliant values to fix it, and four resolution options (modify request to be compliant, request override, cancel request, escalate to platform admin). Resolution guidance includes per-field suggestions derived from the blocking policy's constraint output. Consumer acts via `POST /api/v1/requests/{id}:resolve`. Only the "request override" option triggers the override approval flow (§18.9). This is the consumer-facing experience — §18.9 is the admin-facing approval mechanism.
+
+237. **Override approval is one resolution option, not the default** — The pipeline flow is: POLICY_EVALUATION → POLICY_BLOCKED (consumer notified with options) → consumer chooses action → if modify: re-enters pipeline from assembly → if request_override: PENDING_OVERRIDE → approval flow → if cancel: CANCELLED → if escalate: platform admin notified. Two separate timeouts: block timeout (how long before auto-cancel) and override timeout (how long approvers have). Both profile-governed.
+
+## SECTION 103 — APRIL 2026 SESSION: ADRs, WALKTHROUGH, PATTERN CATALOG, REQUIREMENTS (2026-04)
+
+### 103.1 Architecture Decision Records (Rewritten)
+
+16 ADRs in `architecture/adr/`, rewritten to answer "why does this exist?" not "how did we implement it?":
+
+| ADR | Title | One-Line |
+|-----|-------|---------|
+| 001 | Why DCM Exists | Unified management plane for on-prem — governance layer above provisioning tools |
+| 002 | Three Foundational Abstractions | Everything is Data, Provider, or Policy |
+| 003 | Four Lifecycle States | Intent → Requested → Realized → Discovered, immutable, linked by entity_uuid |
+| 004 | Service Catalog & Consumer UX | Four-level hierarchy; consumers declare what, not how |
+| 005 | Provider Abstraction | 6 types with naturalization/denaturalization; any platform, same interface |
+| 006 | Policy Engine | Policy-as-code on every request; 8 types; multi-pass convergence |
+| 007 | Placement Engine | Multi-stage scoring: sovereignty pre-filter → capability → capacity → policy |
+| 008 | Dependency Resolution | Type-level deps → automatic sub-requests; binding fields inject runtime values |
+| 009 | API Gateway & Control Plane | Single entry point; 9 services; deterministic pipeline |
+| 010 | Audit & Tamper Evidence | Merkle tree (RFC 9162); configurable granularity; provable integrity |
+| 011 | Sovereignty & Data Residency | First-class enforcement on every lifecycle op; dual-approval for overrides |
+| 012 | Data Assembly & Layering | Organizational data merges with consumer requests; field-level provenance |
+| 013 | Override & Exception Governance | 5 mechanisms from planned exceptions to dual-approval |
+| 014 | Multi-Tenancy & Isolation | PostgreSQL RLS at database layer |
+| 015 | Minimal Infrastructure | PostgreSQL only required dep; Internal/External delegation for everything else |
+| 016 | Application Definition Language | **OPEN** — How should consumers define multi-resource apps? 4 options under evaluation |
+
+ADR-016 is the key open design question raised by the engineering team (Ondra/machacekondra). Options: API-only, YAML manifests, external DSL (Bicep/CEL), API composition. Comparison to Radius and KRO included. Decision pending team discussion.
+
+### 103.2 End-to-End Walkthrough
+
+`architecture/WALKTHROUGH.md` — 581 lines, 11 stages tracing a VM provision including IP dependency resolution:
+
+1. Consumer submits intent (6 fields)
+2. Layer assembly (5 layers merge → 10+ fields with provenance)
+3. Policy evaluation (GateKeeper, Validation, Transformation — 4 policies)
+4. Dependency resolution (VM requires Network.IPAddress → sub-request created)
+5. IP policy evaluation (sovereignty, subnet isolation, pool selection — 4 policies)
+6. IP realization (InfoBlox IPAM allocates 10.1.45.23)
+7. Dependency injection + VM placement (IP injected, providers scored)
+8. VM dispatch (naturalization to OpenStack Nova with pre-allocated IP)
+9. VM callback (denaturalization, realized state)
+10. Discovery (both VM and IP independently polled, drift comparison)
+11. Audit trail (17 Merkle leaves across 2 entities)
+
+### 103.3 Deployment Pattern Catalog
+
+Patterns are compound Resource Type Specifications — reusable, provider-agnostic blueprints that define collections of resources with dependencies and binding fields. The Pattern Catalog is NOT a new architectural component — it is a curated view of the Resource Type Registry filtered to compound types. All existing DCM machinery (Meta Provider, dependency graphs, binding fields, placement) executes patterns.
+
+Example patterns: Standard Web Application (6 constituents), Secure Data Pipeline, Developer Sandbox, Regulated Database Service, Edge Compute Node.
+
+Pattern interaction with DCM features: each constituent independently policy-evaluated, independently placed, independently discoverable for drift, independently auditable. Decommission reverses dependency order. Rehydration rebuilds in dependency order with current policies.
+
+### 103.4 Platform Requirements Document
+
+`dcm-platform-requirements.md` — 700 lines following enterprise requirements template:
+- 5 personas (Consumer, Platform Engineer, Operator, Policy Owner, Administrator)
+- 31 use cases in summary table, 23 with detailed descriptions
+- Organized by lifecycle: Day 0 (5 UCs), Day 1 (5 UCs), Day 2 (4 UCs), Governance (2 UCs), Platform Ops (3 UCs), Federation (1 UC), Integration (1 UC), Pattern Catalog (1 UC + full overlay)
+- Architecture principles, success outcomes, priority summary (16 P0, 9 P1, 6 P2)
+- 4 open design questions documented
+
+### 103.5 PR Reviews
+
+**PR #50 (selrahal — Nova OpenAPI spec):** Architecture covers via Naturalization/Denaturalization. Nova spec belongs in dcm-examples. OpenStack Nova provider added with registration YAML, deployment manifest, and Go service.
+
+**PR #18 (Fale — Interoperability API + object design RFC):** Superseded by current architecture. Conventions conflict with team's established patterns (camelCase vs snake_case, YAML vs JSON, K8s structure vs flat REST, OpenAPI 3.0.4 vs 3.1.0). Spectral AEP linter worth adopting after 3.1 compatibility testing. Added as DISCUSSION-TOPICS item 7.
+
+### 103.6 Escalation Routing Fix
+
+Doc B §18.8 updated: policy block escalation routes to the responsible policy domain owner (sovereignty admin, security admin, cost admin) — not generic "platform admin." Routing configurable per policy domain and profile. Fixed in doc B, walkthrough, HTML presentation, and requirements document.
+
+### 103.7 Documentation Review Strategy
+
+Engineering team feedback incorporated. Key decisions:
+- ADRs rewritten outward-facing per Ondra's feedback ("why does this exist, not how we implemented it")
+- NotebookLM recommended over raw AI prompt for reproducible onboarding (Piotr's point)
+- Domain-split PRs with reviewer assignments (Gabriel's point)
+- Use cases drive architecture and priorities (Piotr and Ygal's point)
+- Reading guide (proposal 1), session changelogs (proposal 7) still needed
+
+### 103.8 Meta Provider Removal
+
+**Decision:** `meta_provider` removed as a provider type (6 → 5 types). Compound service composition is a **Data** concept (Compound Resource Type Specifications in the Resource Type Registry) orchestrated by the **Control Plane** (Request Processor, Request Orchestrator). Individual constituents are fulfilled by standard **Service Providers**.
+
+**What changed:**
+- Provider type count: 6 → 5 (service_provider, information_provider, auth_provider, peer_dcm, process_provider)
+- Doc 30 retitled: "Meta Provider Model" → "Compound Resource Type Specifications"
+- `provided_by: self` → `provided_by: ` (a named service provider)
+- Pattern Catalog uses compound specs, not a meta provider type
+- SQL CHECK constraint updated (meta_provider removed from provider_type enum)
+- All ADRs, walkthrough, requirements, pattern overlay, examples repo updated
+- Historical sections in AI prompt retain "Meta Provider" references with architectural note
+
+**What didn't change:**
+- The compound Resource Type Specification YAML format — identical
+- Consumer experience — still requests a catalog item, gets a composed application
+- Dependency graphs, binding fields, compensation — all still work identically
+- Platform engineer authoring — still defines compound specs the same way
+
+### 103.9 Authoritative Counts Update
+
+| Metric | Value |
+|--------|-------|
+| Data model docs | 58 |
+| Specifications | 15 |
+| ADRs | 16 (+ README) |
+| OpenAPI schemas | 4 |
+| Capabilities | 331 across 39 domains |
+| SQL tables | 18 |
+| Consumer API paths | 74 |
+| Admin API paths | 61 |
+| Event payloads | 109 across 23 domains |
+| Provider types | 5 |
+| Policy evaluation modes | 2 |
+| Control plane services | 9 |
+| Required infrastructure | 1 (PostgreSQL) |
+| Test invariants | 60 |
+| Use cases (Jira) | 30 epics, 249 stories |
+| Use cases (requirements doc) | 31 total, 23 detailed |
+| Prompt sections | 104 |
+
diff --git a/content/docs/architecture/data-model/00-context-and-purpose.md b/content/docs/architecture/data-model/00-context-and-purpose.md
new file mode 100644
index 0000000..4bac891
--- /dev/null
+++ b/content/docs/architecture/data-model/00-context-and-purpose.md
@@ -0,0 +1,379 @@
+# DCM Data Model — Context and Purpose
+
+
+
+**Document Status:** ✅ Complete
+**Related Documents:** [Entity Types](01-entity-types.md) | [Ownership, Sharing, and Allocation](04b-ownership-sharing-allocation.md) | [Four States](02-four-states.md) | [Layering and Versioning](03-layering-and-versioning.md) | [Examples](04-examples.md)
+
+> **Foundation Document Reference**
+>
+> This document is a detailed reference for a specific domain of the DCM architecture.
+> The three foundational abstractions — Data, Provider, and Policy — are defined in
+> [00-foundations.md](00-foundations.md). All concepts in this document map to one or
+> more of those three abstractions.
+> See also: [Provider Contract](A-provider-contract.md) | [Policy Contract](B-policy-contract.md)
+>
+> **This document maps to: DATA**
+>
+> The Data abstraction — foundational data model, provenance, four lifecycle states
+
+
+
+---
+
+## 1. Purpose
+
+The DCM Data Model is the foundational layer upon which the entire DCM framework operates. It is not a storage mechanism or a database schema — it is the **lingua franca of DCM**. Every component in the DCM architecture communicates through the data model in some form, whether reading, writing, validating, enriching, transforming, or comparing data.
+
+The data model exists to solve a problem that is endemic to enterprise IT: **there is no single, trustworthy, consistent representation of infrastructure state**. Tools proliferate, CMDBs diverge, and the result is that no one knows with confidence what exists, what was requested, what was provisioned, or whether the current state matches the intended state.
+
+The DCM Data Model establishes a **unified, versioned, declarative single source of truth** for all infrastructure state across the full lifecycle of every resource DCM manages.
+
+---
+
+## 2. Role in the DCM Architecture
+
+The data model is not owned by any single component — it is the contract between all components. Every major DCM capability acts on data in a specific and well-defined way:
+
+| Component | Relationship to Data |
+|-----------|---------------------|
+| Request Payload Processor | Assembles and enriches data into a complete request payload |
+| Policy Engine | Reads, validates, transforms, and gates data based on policy definitions |
+| Service Provider | Consumes data (via Naturalization) and returns data (via Denaturalization) |
+| Orchestration | Coordinates component interactions based on data state and dependencies |
+| Audit | Records data at every state transition for compliance evidence |
+| Drift Reconciliation | Compares versions of data across states to detect and remediate drift |
+| Cost Analysis | Derives cost information from data throughout the resource lifecycle |
+| Resource Discovery | Produces data representing the current discovered state of resources |
+| IDM / IAM | Gates access to data and operations based on identity and role |
+| Service Catalog | Exposes available services based on data definitions and RBAC policy |
+
+This means the data model is effectively the **API between all DCM components** — even components that do not communicate directly are coupled through the data model. A well-designed data model makes every component easier to build, test, and evolve independently.
+
+---
+
+## 3. Universal Identity Requirement
+
+Every data object in DCM must have a **UUID (Universally Unique Identifier)**. This is not optional — it is a foundational requirement that applies to every entity in the data model without exception.
+
+UUIDs serve several critical functions:
+
+- **Unambiguous reference** — any component, policy, layer, catalog item, or process that touches a data object can reference it precisely and without ambiguity
+- **Provenance anchoring** — every change recorded in a data object's lineage references the UUID of the entity that caused the change
+- **Dependency mapping** — relationships between resources, services, and components are expressed as UUID references, never by name alone
+- **Audit fidelity** — audit records reference UUIDs, ensuring that even if names or labels change, the audit trail remains accurate and traceable
+- **Cross-state correlation** — the same resource across Intent, Requested, Realized, and Discovered states can be correlated via UUID chains
+
+This applies to all entities including but not limited to: resource definitions, catalog items, data layers, policies, policy sets, components, service providers, consumers, and requests.
+
+---
+
+## 4. Field-Level Provenance and Data Lineage
+
+One of the most critical requirements of the DCM Data Model is the ability to trace the complete lineage of any piece of data at any stage of the pipeline. This is not a logging concern — it is a **structural requirement of the data model itself**.
+
+### 4.1 The Requirement
+
+At any point in the DCM pipeline, for any field in any data object, it must be possible to answer:
+
+- What is the current value of this field?
+- Where did this value originate? (catalog item, base layer, intermediate layer, policy, consumer input, discovery)
+- Has this value been modified since origination?
+- If modified:
+ - What is the complete history of modifications?
+ - Which entity caused each modification? (identified by UUID)
+ - What type of entity caused it? (policy, layer, component, provider)
+ - When did each modification occur?
+ - What was the value before each modification?
+ - Why was the modification made? (enrichment, validation, transformation, gatekeeping)
+- What is the complete chain of custody of this field from origin to current value?
+
+### 4.2 Why Field-Level Lineage Matters
+
+Document-level versioning alone is insufficient for DCM's requirements. Consider a resource request flowing through the pipeline:
+
+1. Consumer selects a catalog item — catalog item UUID recorded
+2. Base resource definition layer applied — base layer UUID recorded, fields established
+3. Intermediate layers applied — each layer UUID recorded, field overrides recorded
+4. Policy Engine validates — policy UUID recorded, validation outcome recorded
+5. Policy Engine enriches — policy UUID recorded, enriched field values and their source recorded
+6. Policy Engine transforms — policy UUID recorded, transformation recorded with before/after values
+7. Request payload submitted — complete provenance chain intact across all fields
+
+Without field-level provenance, it is impossible to determine after the fact whether a specific field value came from a consumer request, a data layer, a security policy, or a business rule. This ambiguity is unacceptable in a governed, auditable system.
+
+### 4.3 Provenance as a Structural Element
+
+Field-level provenance must be carried within the data object itself — not in an external log. This ensures that:
+
+- The data and its lineage are always co-located and cannot be separated
+- Any consumer of the data can inspect its lineage without querying an external system
+- Provenance survives data export, migration, and portability scenarios
+- The audit capability reads provenance that is intrinsic to the data, not reconstructed from logs
+
+### 4.4 Provenance Metadata Structure
+
+Every field that can be created or modified by any DCM process carries provenance metadata alongside its value. The conceptual structure is:
+
+```yaml
+field_name:
+ value:
+ metadata:
+ # Simple override declaration (Level 2) — most fields only need this
+ override:
+ # OR matrix declaration (Level 3) — for actor-specific governance
+ override_matrix:
+ default:
+ actors:
+ trusted_grants:
+
+ # Always present regardless of level
+ basis_for_value:
+ baseline_value:
+ locked_by_policy_uuid:
+ locked_at_level:
+ constraint_schema:
+
+ provenance:
+ origin:
+ value:
+ source_type:
+ source_uuid:
+ timestamp:
+ modifications:
+ - sequence: 1
+ previous_value:
+ modified_value:
+ source_type:
+ source_uuid:
+ operation_type:
+ actor:
+ timestamp:
+ reason:
+```
+
+**Note:** The `metadata` block is set exclusively by the Policy Engine. Data layers and the Request Payload Processor never set override control. `operation_type: lock` is used when a GateKeeper policy sets `override: immutable`. `operation_type: grant` is used when a trusted_grant is issued. The three levels of override control are: Level 1 (no declaration — fully overridable), Level 2 (simple `override:` property), Level 3 (full `override_matrix:` with per-actor permissions). See the Layering and Assembly document Section 5a for the complete model.
+
+### 4.5 Provenance Obligations
+
+Every DCM component that reads and modifies data carries a provenance obligation:
+
+| Component | Provenance Obligation |
+|-----------|----------------------|
+| Request Payload Processor | Record source UUID and type for every field assembled from layers and catalog items |
+| Policy Engine | Record policy UUID, operation type, and reason for every field it enriches, transforms, or validates |
+| Service Provider (Denaturalization) | Record provider UUID and timestamp for every field returned in the realized payload |
+| Resource Discovery | Record provider UUID, discovery timestamp, and interrogation method for every field in the discovered payload |
+| Data Layers | Each layer must declare its UUID so downstream provenance records can reference it |
+| Catalog Items | Each catalog item must declare its UUID so downstream provenance records can reference it |
+
+Provenance recording is **not optional** for any component that modifies data. A component that modifies data without recording provenance violates the data model contract.
+
+### 4.6 Relationship to Audit
+
+The Audit capability in DCM reads provenance data that is intrinsic to every data object. This means:
+
+- Audit does not reconstruct history from logs — it reads lineage that was recorded at the point of change
+- Any data object can be audited at any time, in any state, by any authorized persona
+- The audit trail is as durable and immutable as the data itself
+- Compliance evidence is produced from the data, not from a separate audit system that could diverge from the data
+
+---
+
+## 5. Foundational Constraints
+
+The DCM Data Model is governed by three foundational constraints that apply universally and without exception:
+
+### 5.1 Declarative
+
+Data in DCM describes **what something is or should be**, not how to achieve it. Every entity in the data model is a complete, self-describing statement of state. The procedures required to achieve that state are the concern of the Service Provider, not the data model.
+
+This means:
+- A resource definition declares its desired configuration, not the steps to configure it
+- A policy declares its conditions and outcomes, not its execution logic
+- A layer declares its overrides, not the merge algorithm used to apply them
+
+### 5.2 Idempotent in Operation
+
+Applying the same data to the same system multiple times must always produce the same result. No operation on DCM data should have different outcomes based on how many times it has been applied.
+
+This is critical for:
+- **Drift reconciliation** — reapplying desired state to a drifted resource must produce correct results
+- **DC rehydration** — replaying the full set of declared states must reconstruct the environment correctly
+- **Retry scenarios** — failed operations can be safely retried without risk of inconsistent state
+- **Audit and compliance** — the same data, applied by anyone at any time, produces the same verifiable outcome
+
+### 5.3 Immutable if Versioned
+
+Once a version of any entity is published, it cannot be modified. If a change is required, a new version must be created. The previous version remains intact and accessible.
+
+This constraint is what makes the following capabilities trustworthy:
+- **Audit trails** — every state at every point in time is preserved and verifiable
+- **Drift detection** — comparison between states is meaningful because neither state can change retroactively
+- **Intent portability** — a previously declared intent can be replayed against current policies with confidence that the original intent is unchanged
+- **Rollback** — reverting to a previous version is always possible because previous versions are never destroyed
+- **Chain of trust** — the provenance of any configuration can be traced through an unbroken chain of immutable versions
+
+---
+
+## 5a. Artifact Metadata Standard
+
+Every DCM artifact — layers, policies, resource types, catalog items, provider registrations, entity definitions, and all other defined or stored objects — carries a universal **Artifact Metadata** block. This is a structural requirement that applies to all artifacts without exception.
+
+### The Purpose
+
+Artifact metadata answers: **who created this, when, who owns it, what changed, and how do we contact them?** It is the identity and accountability record for the artifact itself — distinct from field-level provenance which tracks data value lineage.
+
+### The Five Artifact Statuses
+
+All DCM artifacts follow a five-status lifecycle:
+
+| Status | Meaning | Key Behavior |
+|--------|---------|-------------|
+| `developing` | In active development | Dev mode / dev pipeline only. Not applied in production. |
+| `proposed` | Submitted for validation | Shadow execution for policies — output captured, not applied. In PR review for data artifacts. |
+| `active` | Live and governing | Applied to all relevant requests. |
+| `deprecated` | Being phased out | Still works, replacement available, warning on use. |
+| `retired` | End of life | Cannot be used. Terminal status. |
+
+### Key Design Decisions
+
+**created_by vs owned_by:** Deliberately separate. The creator is the audit record — who physically submitted the artifact. The owner is the accountability record — who is responsible and receives notifications for conflicts, deprecation warnings, and policy violations.
+
+**Contact info — two modes:** When an Identity Provider is registered, the `uuid` field links to the IdP record and `display_name` is a non-authoritative display cache. In standalone/air-gapped mode, `uuid` is absent and `display_name` + `email` are the primary identity fields. Both modes are fully supported.
+
+**created_via:** Declares the ingestion path — `pr` (full GitOps review history), `api` (direct submission), `migration` (imported, limited provenance), `system` (DCM-created). Makes audit quality transparent.
+
+**Proposed shadow execution:** Policy artifacts in `proposed` status execute in shadow mode against real traffic — output is captured and reported but never applied. Enables safe validation before activation.
+
+See [Data Layers and Assembly — Section 4b](03-layering-and-versioning.md) for the complete artifact metadata structure and all field definitions.
+
+---
+
+## 6. The Four States
+
+DCM tracks the lifecycle of every resource through four distinct states. Together, these four states provide complete visibility into the gap between what was wanted, what was asked for, what was built, and what actually exists.
+
+### 6.1 Intent State
+
+The **Intent State** represents what a consumer wants to happen. It is the declared desire, captured at the moment a consumer initiates a request, before any processing, validation, or enrichment has occurred.
+
+- **When it is created:** When a consumer submits a request via the Web UI or Consumer API
+- **Where it is stored:** Intent Store
+- **Key characteristic:** Captures the consumer's raw intent — what they asked for in their own terms
+- **Primary use:** Source for Intent Portability — replaying an intent through current policies to produce a new request for a different environment or provider
+
+### 6.2 Requested State
+
+The **Requested State** represents the fully processed, policy-validated, and enriched payload that has been submitted to a Service Provider for execution. It is the output of the Request Payload Processor after all policies have been applied and all data layers have been merged.
+
+- **When it is created:** When the Request Payload Processor completes processing and submits to the API Gateway
+- **Where it is stored:** Request Store
+- **Key characteristic:** Represents a complete, validated, provider-ready declaration of desired state
+- **Primary use:** Record of what was formally requested; input to audit and drift processes
+
+### 6.3 Realized State
+
+The **Realized State** represents what was actually provisioned or executed by a Service Provider, returned to DCM in unified data model format via Denaturalization. It is the ground truth of what was built.
+
+- **When it is created:** When a Service Provider completes execution and returns the realized payload to the API Gateway
+- **Where it is stored:** Realized Store
+- **Key characteristic:** Must be a complete representation of the provisioned resource in DCM unified format — not a status code, but a full state description
+- **Primary use:** Baseline for drift detection; source of truth for audit and reporting; input to cost analysis
+
+### 6.4 Discovered State
+
+The **Discovered State** represents what actually exists in the environment as interrogated by a Service Provider during a discovery operation. It is an independent observation of reality, not derived from any previous DCM state.
+
+- **When it is created:** When a Service Provider completes a discovery cycle and returns the discovered payload to DCM
+- **Where it is stored:** Discovered Store
+- **Key characteristic:** Produced independently of the Realized State — it is what is actually there, regardless of what was supposed to be there
+- **Primary use:** Drift detection (compared against Realized State); brownfield ingestion (pathway to lifecycle ownership of unmanaged resources)
+
+### 6.5 State Relationships and Lifecycle Flow
+
+The four states relate to each other as follows:
+
+```
+Consumer Request
+ │
+ ▼
+┌─────────────┐
+│ INTENT │ ◄── What the consumer wants
+│ STATE │
+└──────┬──────┘
+ │ Policy Engine processes, enriches, validates
+ ▼
+┌─────────────┐
+│ REQUESTED │ ◄── What was formally submitted to the provider
+│ STATE │
+└──────┬──────┘
+ │ Service Provider executes
+ ▼
+┌─────────────┐
+│ REALIZED │ ◄── What was actually built
+│ STATE │
+└──────┬──────┘
+ │
+ │ ┌─────────────┐
+ │ Compare ◄─────────│ DISCOVERED │ ◄── What actually exists now
+ │ │ STATE │
+ ▼ └─────────────┘
+ Drift Detection
+```
+
+**Key operations across states:**
+- **Drift Detection:** Discovered State vs. Realized State
+- **Request Validation:** Requested State vs. Policy definitions
+- **Intent Portability:** Intent State → re-process through current policies → new Requested State
+- **Brownfield Ingestion:** Discovered State → enrichment → Realized State (lifecycle ownership)
+
+---
+
+## 7. Data as the Provider Contract Boundary
+
+The data model defines the boundary between DCM and its Service Providers. DCM is explicitly **not concerned with how a provider accomplishes its work** — only with the data that crosses the boundary in both directions.
+
+This means:
+- Providers are interchangeable as long as they honor the data contract
+- New providers can be added without changing DCM's core data model
+- Provider implementation can evolve independently of DCM
+- The contract is enforced at the data level — conformant data in, conformant data out
+
+The two mechanisms that enforce this boundary are:
+- **Naturalization** — the provider's responsibility to transform DCM unified data into its own tool-specific format for execution
+- **Denaturalization** — the provider's responsibility to transform its tool-specific result data back into DCM unified format for return to the control plane
+
+This separation of concerns is what makes DCM technology-agnostic while maintaining a consistent and trustworthy data model across all providers.
+
+---
+
+## 8. Open Questions
+
+The following questions remain unresolved and require decisions before the data model specification can be considered complete:
+
+| # | Question | Impact | Status |
+|---|----------|--------|--------|
+| 1 | Where should data caches live? | Cache architecture, latency, sovereignty | ✅ Resolved — caches at Regional DCM level; Info Provider caches co-located with source; Sovereign DCM uses local static from signed bundles (CACHE-001) |
+| 2 | Should cache synchronization be push, pull, or both? | Consistency model | ✅ Resolved — hybrid push-pull; pull on schedule; push for time-sensitive events via Message Bus (CACHE-002) |
+| 3 | Which cache is authoritative when caches diverge? | Conflict resolution | ✅ Resolved — GitOps stores always authoritative; caches are projections; divergence triggers rebuild from authoritative store (CACHE-003) |
+| 4 | What mechanism maintains consistency across distributed caches? | Data integrity | ✅ Resolved — hash-based heartbeat divergence detection + push invalidation; PT2H staleness alert; signed bundles for Sovereign DCM (CACHE-004) |
+| 5 | Should the data model allow embedded target-technology-specific data bundles? | Portability | ✅ Resolved — native_passthrough field sanctioned; always audit-logged; opaque mode blocked in fsi/sovereign (DATA-001) |
+| 6 | How are the four states represented physically? | Physical model | ✅ Resolved — Intent/Requested in Git; Realized in Event Stream; Discovered in Discovered Store (STO-005) |
+| 7 | What is the performance impact of field-level provenance at scale? What optimization strategies are acceptable? | Scalability, storage cost | ✅ Resolved — three configurable provenance models: full_inline, deduplicated (Model B recommended), tiered; profile-appropriate Policy Groups; see docs 03 and 06 (OPS-001) |
+| 8 | Should provenance metadata be stored inline with field data or in a linked provenance document? | Data model structure, query performance | ✅ Resolved — three-level structure: implicit chain ref, inline delta, linked history document; all reconstructable from stored facts; see doc 03 (OPS-002) |
+
+---
+
+## 9. Related Concepts
+
+- **Sovereign Execution Posture** — the target end state the data model enables by providing a verified, auditable chain of custody through the full resource lifecycle
+- **CMDB Replacement** — DCM's four-state model is intended to replace the fragmented multi-CMDB problem by becoming the singular resource domain
+- **GitOps** — all entities in the data model are stored in Git, enabling version control, change tracking, and standard software lifecycle practices
+- **Data Lineage** — the complete chain of custody of any field value from its origin through every modification, recorded within the data object itself
+- **Field-Level Provenance** — the structural mechanism by which data lineage is captured, carried, and made available for audit and compliance purposes
+- **UUID** — the universal identity mechanism that makes provenance references, dependency mapping, and cross-state correlation unambiguous and durable
+
+---
+
+*Document maintained by the DCM Project. For questions or contributions see [GitHub](https://github.com/dcm-project).*
diff --git a/content/docs/architecture/data-model/00-design-priorities.md b/content/docs/architecture/data-model/00-design-priorities.md
new file mode 100644
index 0000000..db26240
--- /dev/null
+++ b/content/docs/architecture/data-model/00-design-priorities.md
@@ -0,0 +1,312 @@
+# DCM Design Priorities
+
+**Document Status:** ✅ Stable — Foundational reference
+**Document Type:** Architecture Reference — Design Philosophy
+**Related Documents:** [Foundational Abstractions](00-foundations.md) | [Policy Profiles](14-policy-profiles.md) | [Scoring Model](29-scoring-model.md) | [credential management service Model](31-credential-provider-model.md)
+
+> **This document maps to: DATA + PROVIDER + POLICY**
+>
+> Design priorities govern every decision across all three abstractions. They are not guidelines — they are the decision framework used when priorities conflict. Every contributor, implementer, and reviewer should apply this framework.
+> See also: [Provider Contract](A-provider-contract.md) | [Policy Contract](B-policy-contract.md)
+
+---
+
+## The Four Priorities
+
+Every design decision in DCM is evaluated against this hierarchy. When priorities conflict, higher priorities win. When there is no conflict, all four apply simultaneously.
+
+---
+
+### Priority 1 — Industry Best Practices for Security
+
+Security is not a feature, a profile option, or a compliance checkbox. It is the baseline that every other design decision must respect.
+
+**What this means:**
+
+Security properties — value separation, rotation, audit trails, idle detection, algorithm baselines, scoped credentials, revocation propagation, shadow mode evaluation — are **architecturally present in every profile**. What profiles control is enforcement strictness, threshold values, and automation level — not whether the security property applies.
+
+**The `minimal` profile is "security with minimal operational overhead" — not "minimal security."**
+
+A `minimal` profile deployment:
+- Rotates credentials (at longer intervals with manual triggers acceptable — not never)
+- Detects idle credentials (at a generous P30D threshold — not never)
+- Requires algorithm baselines (via forbidden list — not null)
+- Runs shadow mode on contributed policies (always — not optionally)
+- Audits first credential retrieval (always — not sometimes)
+- Maintains revocation registry (at PT5M cache TTL — not disabled)
+
+The security model is present and correct. The enforcement strictness and automation burden are reduced.
+
+**When security and convenience conflict, security wins** — but the design must find a way to make the secure option easy. A security model that is routinely bypassed because it is too burdensome has failed at both security and usability. The profile system is the mechanism: the right profile makes secure behavior automatic, not effortful.
+
+**Security properties that are non-negotiable in all profiles:**
+
+| Property | Rule | Reference |
+|----------|------|-----------|
+| Credential values never in DCM stores | CPX-001 — absolute, no profile exception | doc 31 |
+| Governance Matrix always boolean | SMX-004 — scoring never applies to boundary decisions | doc 29 |
+| Every provider dispatch requires scoped interaction credential | CPX-002 | doc 31 |
+| Shadow mode on all contributed policies | FCM-004 | doc 28 |
+| auto_approve_below ≤ 50 in all profiles | SMX-008 | doc 29 |
+| First credential retrieval always audited | CPX-005 | doc 31 |
+| Forbidden algorithm baseline always enforced | CPX-009 (no null approved_algorithms) | doc 31 |
+| Revocation registry always maintained | CPX-003 | doc 31 |
+
+---
+
+### Priority 2 — Ease of Use
+
+DCM exists to enable self-service for application teams. If the right path is also the hard path, teams will find other paths — and those other paths are ungoverned.
+
+**What this means:**
+
+The secure path must also be the easy path. Profile defaults should work for most deployments without customization. Ordinary requests should auto-approve without human intervention. Policy authoring should not require Rego expertise for common patterns. The Flow GUI, scoring model, and consumer contribution endpoints all exist to make governed behavior less operationally burdensome.
+
+**Ease of use serves security.** An organization that finds DCM too cumbersome and routes requests outside DCM has eliminated all of DCM's security benefits. A homelab team that circumvents credential management because it's too complex has no credential management.
+
+**The design principle:** When implementing a security requirement, simultaneously design the ease-of-use mechanism that makes it effortless to comply with. The scoring model's auto-approval threshold (not making every request require human review) is ease of use in service of security.
+
+**Things that should be easy in all profiles:**
+- Requesting a standard resource (auto-approve for clean requests)
+- Authoring a common policy without Rego expertise (visual condition builder)
+- Retrieving a credential after resource provisioning (direct API call)
+- Understanding why a request was scored a certain way (score_drivers field)
+- Contributing a policy (API endpoint, not manual GitOps PR)
+
+---
+
+### Priority 3 — Extensibility and Capability Grouping
+
+The profile system, compliance domain overlays, policy groups, capability extensions, and registry governance make DCM adaptable to arbitrary organizational requirements without code changes.
+
+**What this means:**
+
+New compliance requirements should be expressible as policy additions within the existing framework. New provider types should fit the existing Provider base contract. New deployment contexts should be addressable through profile configuration. A platform that requires modifying source code for each new deployment context is not a platform — it is a template.
+
+**Grouping is the mechanism for extensibility.** Compliance domain overlays compose with base profiles. Policy groups compose with profile policies. Capability extensions compose with base provider contracts. The three-abstraction model (Data, Provider, Policy) is the foundation that makes all of this compositional.
+
+**Extensibility must not compromise security or usability.** An extension mechanism that allows downstream users to disable security properties (rather than scale them) fails priority 1. An extension mechanism that requires expertise to configure fails priority 2. The profile system's hard constraints (SMX-008: auto_approve ≤ 50; CPX-001: no values in DCM stores) are precisely the boundaries that prevent extensibility from undermining security.
+
+---
+
+### Priority 4 — Fit for Purpose (Always Required)
+
+DCM must manage data center infrastructure lifecycle. All of the above is in service of this purpose. An architecturally beautiful system that cannot provision a VM, track its drift, and decommission it cleanly has failed at its reason for existing.
+
+**What this means:**
+
+Design decisions that serve priorities 1–3 but break the end-to-end lifecycle (request → provision → operate → decommission) are not acceptable. Every capability added must have a clear answer to "how does this serve the lifecycle management mission?"
+
+Fit for purpose is not a fourth priority that can be traded against the first three — it is a precondition. If a design cannot fulfill its stated purpose, priorities 1–3 become irrelevant. This is why it is listed fourth rather than first: it is assumed, not aspirational.
+
+---
+
+## Applying the Priorities — Decision Framework
+
+When facing a design decision where priorities seem to conflict, apply this sequence:
+
+```
+1. Does this design decision compromise a non-negotiable security property?
+ YES → redesign until it does not. No exceptions.
+
+2. Does the secure option create significant operational burden?
+ YES → design the ease-of-use mechanism simultaneously.
+ The secure path must also be the easy path.
+ If you cannot make it easy enough, reconsider whether the
+ security property is correctly scoped.
+
+3. Can this behavior be expressed through the existing profile/policy/extension system?
+ YES → use it. Do not add new mechanisms when existing ones suffice.
+ NO → extend the existing mechanism before creating a new one.
+
+4. Does this design decision support the complete lifecycle?
+ NO → do not proceed until it does.
+```
+
+### Common Misapplications
+
+**"We can disable X in the minimal profile for simplicity."**
+Wrong application. The minimal profile scales down operational burden, not security properties. The question is: what is the minimum viable implementation of X that requires no operational overhead? That is what minimal profile gets.
+
+**"Security is too complex for our users, so we'll make it optional."**
+Wrong application. If security is too complex, the design of the security mechanism needs to improve (priority 2). Making security optional removes it — that fails priority 1. Design a simpler mechanism that achieves the same security outcome.
+
+**"We need a new mechanism for this capability."**
+Wrong starting point (priority 3 failure). The question is: can this be expressed through profiles, policies, provider capability extensions, or compliance overlays? Usually yes. If genuinely not, extend the nearest existing mechanism rather than creating a new one.
+
+**"This edge case isn't part of the lifecycle."**
+Wrong framing (priority 4). Every edge case in the lifecycle — partial realization, compensation, drift remediation, credential revocation on decommission — is part of the lifecycle. Fit for purpose means handling the complete lifecycle, not just the happy path.
+
+---
+
+## Profile Scaling Model
+
+The profile system is the primary mechanism for expressing priorities 1–3 simultaneously. Understanding what profiles control — and what they do not — is essential to applying the priority order correctly.
+
+**Profiles control:**
+- Enforcement strictness (how strictly a security property is enforced)
+- Threshold values (how long, how often, how many)
+- Automation level (automated vs manual trigger)
+- Approval tier (auto-approve vs human review vs verified vs authorized)
+- Review periods (how long shadow mode runs before promotion)
+
+**Profiles do not control:**
+- Whether a security property is present (it always is)
+- Which non-negotiable constraints apply (CPX-001, SMX-004, SMX-008, etc.)
+- Whether the audit trail is maintained (always maintained; retention varies)
+- Whether the data model is valid (schema conformance is not profile-dependent)
+
+### Profile Scaling Table
+
+This table shows how representative security properties scale across profiles. "Present" means the property is architecturally required — what varies is the configuration.
+
+| Security Property | minimal | dev | standard | prod | fsi | sovereign |
+|------------------|---------|-----|----------|------|-----|-----------|
+| Credential rotation | Required; P365D max; manual OK | Required; P180D max; manual OK | Required; automated | Required; strict interval | Required; P90D max | Required; hardware-triggered |
+| Idle detection threshold | P30D | P14D | P7D | P3D | P1D | PT12H |
+| Algorithm baseline | Forbidden list | Forbidden list | Approved list | Approved list | FIPS-only | HSM-generated only |
+| Shadow mode on contribution | Always on | Always on | Always on | Always on | Always on | Always on |
+| First retrieval audit | Always | Always | Always | Always | Always | Always |
+| Revocation cache TTL | PT5M | PT5M | PT1M | PT1M | PT30S | PT15S |
+| Auto-approve threshold | ≤ 45 | ≤ 40 | ≤ 25 | ≤ 15 | ≤ 10 | ≤ 5 |
+| Step-up MFA for credentials | Optional | Optional | Sensitive types | All types | Hardware MFA | mTLS |
+| FIPS level | None required | None required | None required | Level 1 | Level 2 | Level 3 |
+| IP binding | Not required | Not required | Not required | Not required | Required | Required |
+| Hub contribution auto-approve | Yes | Yes | Yes | No (human review) | No (verified) | No (authorized) |
+
+---
+
+---
+
+## Approval Tier Model
+
+DCM defines four approval tiers that apply to requests, policy contributions, provider registrations, and any pipeline decision requiring human authorization. Understanding the model is critical: **DCM provides the gate and the audit trail. The review process is the organization's responsibility.**
+
+> **Full specification:** See [Authority Tier Model](32-authority-tier-model.md) for the complete ordered tier list, custom tier contribution model, dynamic threshold format, and ATM-001–ATM-008 system policies.
+
+### What DCM Does vs What Organizations Provide
+
+| Tier | Required authority level | DCM provides | Organization provides | DCM gate condition |
+|------|-------------------------|-------------|----------------------|-------------------|
+| `auto` | None — `decision_gravity: none`; system confidence sufficient | Structural and governance validation; automatic activation on pass | Nothing — fully automated | All validation checks pass |
+| `reviewed` | Standard authority — `decision_gravity: routine`; one qualified reviewer in the relevant domain | Approval record; eligible reviewer notification via notification service; pipeline hold; decision recording via Admin API; activation or rejection | Who constitutes a qualified reviewer; the review process; recording the decision via DCM API or an external system that calls it | One actor with reviewer role records a decision via the Admin API |
+| `verified` | Elevated authority — `decision_gravity: elevated`; independent confirmation required; separation of duties | Approval record requiring two independent decisions; enforces distinct actors (same actor cannot provide both); eligible reviewer notification; pipeline hold | Who constitutes qualified reviewers; both review processes; may use external workflow tools that call the DCM API | Two distinct actors with reviewer role each record a decision via the Admin API |
+| `authorized` | Senior/governing authority — `decision_gravity: critical`; highest organizational weight; most consequential decisions | Approval record specifying the required DCMGroup and threshold (N of M); group member notification; pipeline hold; individual decision tracking via Admin API; threshold evaluation; activation when N reached | Who constitutes the authority group (one person with delegated authority, a CTO, a CISO and legal counsel, a change board — the organization decides); how they deliberate; what external tools they use; DCM records decisions, not deliberation | N members of the declared DCMGroup record decisions via the Admin API within the declared window |
+
+### Tier Extensibility
+
+The four default tiers (`auto`, `reviewed`, `verified`, `authorized`) are DCM system defaults. Organizations can add custom tiers by inserting them into the ordered list between existing tiers. The tier name is stable; numeric weight is derived from list position at evaluation time.
+
+Example: An organization adds `compliance_reviewed` between `verified` and `authorized`:
+```
+auto → reviewed → verified → compliance_reviewed → authorized
+```
+All existing references to `authorized` continue to work. Only the threshold ranges in the affected profile need updating. See [Authority Tier Model](32-authority-tier-model.md).
+
+### The `authorized` Tier — What DCM Builds vs What It Does Not Not
+
+DCM does **not** build an authorized group management system. It does not track deliberation, run voting sessions, manage agendas, or coordinate review meetings.
+
+DCM builds:
+
+1. **DCMGroup membership management** — which actors constitute the authorized group; configurable by platform admins
+2. **Quorum declaration** — `N of M` threshold declared in the profile or per-decision configuration
+3. **Notification routing** — when a decision enters `pending_authorized` state, the notification service fires to all DCMGroup members
+4. **Vote recording API** — the Admin API endpoint that authorized group members (or external systems acting on their behalf) call to record `approve` or `reject`
+5. **Quorum tracking** — DCM counts votes and advances the pipeline when N is reached
+6. **Audit trail** — every vote is audited with actor UUID, timestamp, decision, and the system that recorded it
+
+External systems (ServiceNow, Jira, email workflows, Slack bots) connect to DCM by calling the vote recording API. A Slack bot that collects emoji reactions from group members and then calls DCM's Admin API is a valid implementation — DCM doesn't care how the organization collected the vote, only that an authorized group member recorded it.
+
+### Admin API as the Integration Point
+
+The Admin API approval endpoint is designed to be called by external systems, not only by humans in a DCM UI:
+
+```
+POST /api/v1/admin/approvals/{approval_uuid}:vote
+Authorization: Bearer # any actor who is a member of the required DCMGroup
+
+{
+ "decision": "approve | reject",
+ "reason": "",
+ "recorded_via": "dcm_admin_ui | servicenow | jira | slack_bot | api_direct | other",
+ "external_reference": ""
+}
+
+Response 200:
+{
+ "approval_uuid": "",
+ "voter_uuid": "",
+ "decision": "approve",
+ "votes_recorded": 2,
+ "quorum_required": 3,
+ "quorum_reached": false,
+ "pipeline_status": "pending_authorized"
+}
+
+# When quorum is reached:
+{
+ "approval_uuid": "",
+ "voter_uuid": "",
+ "decision": "approve",
+ "votes_recorded": 3,
+ "quorum_required": 3,
+ "quorum_reached": true,
+ "pipeline_status": "activating"
+}
+```
+
+The `recorded_via` field provides the audit trail provenance — DCM knows whether the vote came through its own UI, a ServiceNow integration, a Jira plugin, or a direct API call. This is not enforced — it is informational for audit purposes.
+
+### Deadline and Escalation
+
+DCM manages the approval window (the time within which a decision must be reached) and fires escalation notifications when the window is approaching:
+
+```yaml
+approval_window:
+ reviewed: PT72H # 3 days; configurable per profile
+ verified: PT72H
+ authorized: P7D # 7 days for deliberation; configurable
+ on_expiry:
+ reviewed: escalate # escalate to platform admin
+ verified: escalate
+ authorized: reject # authorized tier that cannot reach threshold in window → reject
+```
+
+When the window expires without a decision, DCM fires an escalation notification and either rejects (for authorized) or escalates to the next approval tier (for reviewed and verified). The organization can configure these windows to match their actual governance processes.
+
+### DPO Alignment
+
+The approval tier model directly implements all four design priorities:
+
+1. **Security:** Approval tiers are the enforcement mechanism for governance. The gate is DCM's responsibility — it cannot be bypassed, and every decision is audited.
+2. **Ease of use:** The Admin API as integration point means organizations use whatever workflow tools they already have. DCM does not require them to adopt a new process tool.
+3. **Extensibility:** The `recorded_via` field and `external_reference` field make the approval tier model composable with arbitrary external systems without DCM needing to integrate with each one.
+4. **Fit for purpose:** The tier model enables governance of every pipeline decision (request approval, policy contribution, provider registration, federation contribution) through a single consistent mechanism.
+
+## Documentation Requirements
+
+Every document in the DCM data model should:
+
+1. **Reference the priority order** where design decisions are made that involve tradeoffs
+2. **Explain non-negotiable security properties** with clear rationale
+3. **Document what profiles control vs what they do not** for each security-relevant configuration
+4. **Identify the ease-of-use mechanism** that accompanies every security requirement
+5. **State fit-for-purpose scope** explicitly — what lifecycle operations does this document govern?
+
+---
+
+## System Policies
+
+| Policy | Rule |
+|--------|------|
+| `DPO-001` | Security properties are architecturally present in all profiles. Profiles control enforcement strictness, thresholds, and automation level — not whether the property exists. |
+| `DPO-002` | Every security requirement must be accompanied by an ease-of-use mechanism that makes compliance effortless for the common case. A security model routinely bypassed because of complexity has failed. |
+| `DPO-003` | New capabilities should be expressed through the existing profile/policy/provider extension system before creating new mechanisms. Extensibility is achieved through composition, not proliferation. |
+| `DPO-004` | Fit for purpose is a precondition, not a priority. All four priorities apply only within the constraint that the system can fulfill its lifecycle management mission. |
+| `DPO-005` | The `minimal` profile is "security with minimal operational overhead" — not "minimal security." Design decisions that disable security properties rather than scaling them violate DPO-001. |
+| `DPO-006` | When security and ease of use conflict, redesign the ease-of-use mechanism — not the security requirement. The secure path must also be the easy path. |
+
+---
+
+*Document maintained by the DCM Project. For questions or contributions see [GitHub](https://github.com/dcm-project).*
diff --git a/content/docs/architecture/data-model/00-foundations.md b/content/docs/architecture/data-model/00-foundations.md
new file mode 100644
index 0000000..5a7deda
--- /dev/null
+++ b/content/docs/architecture/data-model/00-foundations.md
@@ -0,0 +1,301 @@
+# DCM — Foundational Abstractions
+
+
+**Document Status:** ✅ Complete
+**Document Type:** Architecture Foundation — Read This First
+**Related Documents:** [Data Model Context](00-context-and-purpose.md) | [Provider Contract](A-provider-contract.md) | [Policy Contract](B-policy-contract.md)
+
+---
+
+## 1. The Three Abstractions
+
+DCM is built on three foundational abstractions. Every concept in the architecture is an instance of one of these three — or a combination of them. There is no fourth.
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ DATA │
+│ │
+│ Everything that exists, is stored, has a lifecycle, and flows │
+│ through the system. Entities, layers, policies, accreditations, │
+│ audit records, groups, relationships — all Data. │
+└──────────────────────────┬──────────────────────────────────────┘
+ │ flows through
+ ┌────────────┴────────────┐
+ ▼ ▼
+┌─────────────────────┐ ┌─────────────────────────────────────┐
+│ PROVIDER │ │ POLICY │
+│ │ │ │
+│ Every external │ │ Every rule that fires on Data, │
+│ component DCM │ │ decides what happens, transforms │
+│ calls or that │ │ values, or enforces constraints. │
+│ calls DCM. │ │ │
+│ Twelve typed │ │ Eight typed output schemas. │
+│ capability │ │ One evaluation algorithm. │
+│ extensions. │ │ Same lifecycle for all. │
+│ One base contract. │ │ │
+└─────────────────────┘ └─────────────────────────────────────┘
+```
+
+**The runtime that connects them:**
+
+```
+Event (Data state change)
+ → Policy Engine evaluates all matching Policies
+ → Policies produce decisions / mutations / actions
+ → Actions invoke Providers or produce new Data
+ → New Data triggers new Events
+ → Repeat
+```
+
+This is the complete DCM operational model. Everything else is a typed specialization of these three abstractions operating through this loop.
+
+---
+
+## 2. DATA — Everything That Exists
+
+**Definition:** Data is any structured artifact in DCM with a type, fields, classification, provenance, and lifecycle state. Data is always versioned, always identified by UUID, and always carries provenance describing where each field value came from.
+
+**The universal properties of all Data:**
+- **UUID** — every Data artifact has a universally unique identifier, stable across its full lifecycle
+- **Type** — every Data artifact has a declared type that determines its schema and valid field set
+- **Lifecycle state** — every Data artifact is in exactly one lifecycle state at any moment
+- **Artifact metadata** — every Data artifact carries a standard metadata block (handle, version, status, owned_by, created_by, created_via)
+- **Provenance** — every field in every Data artifact carries lineage metadata describing its origin and all modifications
+- **Data classification** — every field carries a classification (public → classified) governing what may cross interaction boundaries
+- **Immutability if versioned** — once a version is published, it cannot be modified; changes produce new versions
+- **Contributor identity** — every Data artifact records who contributed it (platform admin, consumer/tenant, service provider, or peer DCM) and what review it received before activation. DCM defaults to a federated contribution model — all authorized actor types can create Data within the bounds their role permits. See [Federated Contribution Model](28-federated-contribution-model.md).
+
+**The complete Data taxonomy:**
+
+| Data Type | Description | Storage |
+|-----------|-------------|---------|
+| **Resource Entity** | A realized infrastructure resource; the primary managed thing | Realized Store |
+| **Process Entity** | An ephemeral execution (job, playbook, pipeline) | Realized Store |
+| **Composite Entity** | A Meta Provider composition of Resource Entities | Realized Store |
+| **Intent State** | Consumer's raw declaration before processing | Intent Store (GitOps) |
+| **Requested State** | Fully assembled, policy-validated provider payload | Requested Store |
+| **Discovered State** | What actually exists per discovery observation | Discovered Store |
+| **Data Layer** | A versioned artifact contributing fields to assembly | Layer Store (GitOps) |
+| **Resource Type Specification** | Schema definition for a resource type | Registry |
+| **Provider Catalog Item** | Provider-specific instantiation of a Resource Type Spec | Registry |
+| **Policy** | A rule artifact with match conditions and output schema | Policy Store (GitOps) |
+| **Policy Group** | A collection of policies grouped by concern_type | Policy Store (GitOps) |
+| **Policy Profile** | A composition: one posture + zero or more compliance domains | Policy Store (GitOps) |
+| **Accreditation** | A compliance certification artifact | Accreditation Store |
+| **Sovereignty Zone** | A geopolitical/regulatory boundary artifact | Config Store |
+| **Registration Token** | A scoped authorization artifact for provider registration | Token Store |
+| **DCMGroup** | A grouping artifact (tenant_boundary, resource_grouping, etc.) | Config Store |
+| **Drift Record** | A comparison result artifact | Operational Store |
+| **Audit Record** | An immutable event record | Audit Store |
+| **Governance Matrix Rule** | A boundary control rule artifact | Policy Store (GitOps) |
+| **Orphan Candidate** | A potentially untracked resource artifact | Operational Store |
+
+**How Data flows — the four lifecycle stages:**
+
+Every Resource Entity flows through four stages. These are not four separate things — they are the same entity at four different lifecycle stages, stored as four data domains in DCM's PostgreSQL database, each with distinct immutability and access patterns:
+
+```
+Consumer Intent
+ │ raw consumer declaration
+ ▼
+Intent State ──────────────────────────────────── intent_records (append-only)
+ │ layer assembly + policy evaluation
+ ▼
+Requested State ────────────────────────────────── requested_records (append-only)
+ │ provider execution
+ ▼
+Realized State ─────────────────────────────────── realized_entities (versioned snapshots)
+ │ independent observation
+ ▼
+Discovered State ───────────────────────────────── discovered_records (ephemeral)
+```
+
+**How Data is composed — the layering model:**
+
+Data fields are assembled from multiple contributing layers in a deterministic precedence order. See [Data Model Context](00-context-and-purpose.md) and [Layering and Versioning](03-layering-and-versioning.md) for the complete assembly algorithm.
+
+---
+
+## 3. PROVIDER — Everything External
+
+**Definition:** A Provider is any external component that DCM interacts with through a defined contract. Providers receive Data from DCM, act on it, and return Data to DCM. The contract governs how this exchange happens — not what the Provider does internally.
+
+**The universal properties of all Providers:**
+- **Registration** — every Provider registers with DCM, declaring its capabilities, sovereignty, and accreditation
+- **Health check** — every Provider exposes a health endpoint; DCM monitors it continuously
+- **Sovereignty declaration** — every Provider declares where it operates and what jurisdictions it covers
+- **Accreditation** — every Provider declares its compliance certifications; DCM enforces these via the Governance Matrix
+- **Governance Matrix enforcement** — every interaction with a Provider is subject to the Governance Matrix before data crosses the boundary
+- **Zero trust** — every Provider interaction is authenticated and authorized; no implicit trust from network position
+- **Lifecycle** — every Provider registration goes through a defined lifecycle (SUBMITTED → VALIDATING → ACTIVE → DEREGISTERED)
+
+**The complete Provider taxonomy:**
+
+| Provider Type | Capability | Data direction |
+|--------------|-----------|---------------|
+| **Service Provider** | Realizes infrastructure resources | DCM → Provider → DCM |
+| **Information Provider** | Serves authoritative external data | DCM queries → Provider responds |
+| **data store** | Persists DCM state | DCM reads/writes ↔ Provider |
+
+| **External Policy Evaluator** | Evaluates policies externally | DCM sends payload → Provider decides |
+| **credential management service** | Manages secrets and credentials | DCM requests → Provider issues |
+| **Auth Provider** | Authenticates identities | DCM verifies → Provider confirms |
+| **notification service** | Delivers notifications | DCM sends envelope → Provider delivers |
+| **event routing service** | Async event streaming | DCM publishes/subscribes ↔ Provider |
+| **Resource Type Registry** | Serves the resource type registry | DCM pulls → Provider serves |
+| **Peer DCM** | Another DCM instance (federation) | DCM ↔ DCM via federation tunnel |
+| **ITSM integration** | Bidirectional integration with ITSM systems (ServiceNow, Jira, Remedy, etc.); creates/updates ITSM records from DCM events; routes ITSM approvals back to DCM | DCM → ITSM (outbound) / ITSM → DCM (inbound) |
+
+**The unified Provider base contract** is defined in [A-provider-contract.md](A-provider-contract.md). All twelve Provider types implement this base contract. What varies is the capability declaration — what operations the Provider exposes and what data flows in which direction.
+
+**Peer DCM as Provider:** A federated DCM instance is a typed Provider. The federation tunnel is the Provider's communication channel. Federation routing is policy-governed provider selection. There is no separate "federation abstraction" — federation is the Provider abstraction applied across DCM instances.
+
+---
+
+## 4. POLICY — Everything That Decides
+
+**Definition:** A Policy is a rule artifact that fires when Data matches declared conditions, produces a typed output (decision, mutation, action, or directive), and is enforced according to a declared level. Policies govern every transition, transformation, and constraint in DCM.
+
+**The universal properties of all Policies:**
+- **Match conditions** — every Policy declares when it fires, using the four governance matrix axes (subject, data, target, context) or payload type + field conditions
+- **Typed output schema** — every Policy produces one of seven output types; the output type determines how the Policy Engine applies the result
+- **Enforcement level** — hard (cannot be overridden) or soft (can be tightened by more-specific policies)
+- **Domain precedence** — policies at more-specific domains win within their concern type; system > platform > tenant > resource_type > entity
+- **Lifecycle** — every Policy follows the standard artifact lifecycle (developing → proposed → active → deprecated → retired)
+- **Shadow mode** — proposed Policies execute against real traffic without applying results; safe validation before activation
+- **Audit** — every Policy evaluation produces an audit record regardless of outcome
+
+**The complete Policy taxonomy:**
+
+| Policy Type | Fires on | Output |
+|-------------|---------|--------|
+| **GateKeeper** | Request payload | `allow` or `deny` with reason |
+| **Validation** | Request payload | `pass` or `fail` with field-level details |
+| **Transformation** | Request payload | `mutations[]` — field additions, changes, locks |
+| **Recovery** | Failure/timeout trigger condition | `action` + parameters (DRIFT_RECONCILE, DISCARD_AND_REQUEUE, etc.) |
+| **Orchestration Flow** | Payload type events | `flow_directive` — sequence ordering for pipeline steps |
+| **Governance Matrix Rule** | Any cross-boundary interaction | `ALLOW / DENY / ALLOW_WITH_CONDITIONS / STRIP_FIELD / REDACT / AUDIT_ONLY` |
+| **Lifecycle Policy** | Relationship events | `action` on the related entity (save, destroy, notify, cascade) |
+| **ITSM Action** | DCM events (state transitions, drift, realization) | `itsm_action` — create/update/close ITSM records; non-blocking by default |
+
+**The unified Policy base contract** is defined in [B-policy-contract.md](B-policy-contract.md). All eight Policy types implement this base contract. What varies is the output schema.
+
+**Policies as orchestration — two levels that compose:**
+
+*Level 1 — Named Workflow Artifacts (explicit, visible, auditable):*
+An Orchestration Flow Policy with `concern_type: orchestration_flow` and `ordered: true` is a named workflow. It declares steps in explicit sequence. Named workflows are first-class Data artifacts — versioned, GitOps-managed, profile-bound. Adding an explicit pipeline step = adding a step to a workflow Policy artifact.
+
+*Level 2 — Dynamic Policies (conditional, inline):*
+GateKeeper, Transformation, Recovery, and Governance Matrix Policies fire when their match conditions are satisfied — within or alongside workflow steps, without being declared in the workflow. Adding conditional behavior = writing a dynamic policy.
+
+Both levels are evaluated by the same Policy Engine and triggered through the same Request Orchestrator event bus. They compose naturally: a named workflow provides the sequence skeleton; dynamic policies provide conditional behavior within it.
+
+**The Governance Matrix as Policy:** The Governance Matrix rules (doc 27) are typed Policies with the `boundary_control` output schema. They fire at every cross-boundary interaction. They follow the same match conditions, enforcement levels, and lifecycle as all other Policies. The governance matrix is not a separate system — it is the Policy abstraction applied at interaction boundaries.
+
+---
+
+## 5. The Runtime — Connecting the Three
+
+The Request Orchestrator and Policy Engine are the runtime that connects the three abstractions. They are not a fourth abstraction — they are the implementation machinery.
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Request Orchestrator │
+│ (event bus — not a sequencer) │
+│ │
+│ Receives events → routes to Policy Engine │
+│ Policy Engine evaluates all matching Policies │
+│ Results: invoke Providers OR produce new Data │
+│ New Data → new events → new Policy evaluations │
+└─────────────────────────────────────────────────────────┘
+```
+
+**Key runtime properties:**
+- The Request Orchestrator contains no pipeline logic — Policies define what happens
+- Every pipeline step is a Policy firing on a payload type event
+- Parallel execution: Policies with no data dependencies evaluate concurrently
+- Static flows: Orchestration Flow Policies with `ordered: true`
+- Dynamic flows: conditional Policies that fire based on payload state
+
+**Control plane components as runtime specializations (nine total):**
+
+The components in [Control Plane Components](25-control-plane-components.md) are specialized runtime implementations, not separate abstractions:
+
+| Component | Abstraction it implements |
+|-----------|--------------------------|
+| Request Orchestrator | The runtime event bus |
+| Policy Engine | The runtime Policy evaluator |
+| Placement Engine | Policy evaluation specialized for provider selection |
+| Cost Analysis | Information Provider (internal; data derivation) |
+| Lifecycle Constraint Enforcer | Scheduled Recovery Policy trigger |
+| Discovery Scheduler | Scheduled Provider invocation |
+| Notification Router | Transformation Policy + notification service invocation |
+| Drift Reconciliation | Data comparison producing new Data (drift records) |
+| Search Index | PostgreSQL store contract (queryable projection) |
+
+---
+
+## 6. Extension Points
+
+DCM is designed to be extended without modifying the core. Every extension fits within the three abstractions:
+
+**Extending Data:** New entity types, new artifact types, new resource types, new group classes — all are typed extensions of the Data abstraction. Register them in the Resource Type Registry or DCMGroup registry.
+
+**Extending Providers:** New provider types (a Billing Provider, a CMDB Provider, an AI/ML Provider) — implement the unified Provider base contract with a new capability declaration extension. Register in the Provider Type Registry.
+
+**Extending Policies:** New policy types, new governance matrix rules, new orchestration flows — implement the unified Policy base contract with a new output schema. Register in the Policy Store via GitOps.
+
+**The extension principle:** If you can express it as Data, Provider, or Policy — it belongs in DCM. If you cannot express it within these three abstractions, it is either a runtime implementation detail or a genuinely novel concept that should be explicitly identified and documented as such.
+
+---
+
+## 7. The Core Ethos
+
+These three abstractions serve DCM's core ethos:
+
+**Effective at the core mission** — managing the lifecycle of infrastructure resources across a sovereign private cloud. The Data abstraction ensures every resource is tracked, versioned, and auditable. The Provider abstraction ensures every external integration is governed and trustworthy. The Policy abstraction ensures every decision is declared, reproducible, and auditable.
+
+**Easy to use** — consumers interact with Data (submit an intent, receive a resource). Policies govern what happens without consumers needing to understand them. Providers handle the implementation details.
+
+**Easy to implement** — implementors implement one base contract (Provider) with a typed capability extension. The Policy Engine handles all policy evaluation. The Data model handles all storage and provenance.
+
+**Easy to extend and integrate** — add a new provider type by implementing the base contract. Add a new policy type by defining an output schema. Add a new data type by defining a schema. No core changes required.
+
+---
+
+*Document maintained by the DCM Project. For questions or contributions see [GitHub](https://github.com/dcm-project).*
+
+
+---
+
+## Design Priority Order
+
+> **Full specification:** See [Design Priorities](00-design-priorities.md) for the complete priority framework, decision framework, profile scaling table, and DPO-001–006 system policies.
+
+
+Every design decision in DCM is evaluated against this priority order. When priorities conflict, higher priorities win. When there is no conflict, all four apply simultaneously.
+
+**1. Industry best practices for security**
+Security is not a feature or a profile option. It is the baseline that every other design decision must respect. Where security and convenience conflict, security wins — but the design must find a way to make the secure path the easy path. A security model that is routinely bypassed because it is too burdensome has failed at both security and usability.
+
+*In practice:* Security properties — value separation, non-transferable credentials, scoped permissions, rotation, audit, revocation propagation — are architecturally present in every profile. What profiles control is the enforcement strictness, operational automation, and threshold values. A `minimal` profile does not disable security; it implements security with minimal operational overhead.
+
+**2. Ease of use**
+DCM exists to enable self-service for application teams. If the right path is also the hard path, teams will find other paths. The goal is to make secure, governed, auditable infrastructure management the path of least resistance — not the path of compliance obligation.
+
+*In practice:* Profile defaults should eliminate configuration burden for common cases. The standard pipeline should auto-approve ordinary requests without human intervention. Policy authoring should not require Rego expertise for common patterns. The Flow GUI, scoring model, and contribution endpoints all serve this priority.
+
+**3. Extensibility and capability grouping**
+The profile system, compliance domain overlays, policy groups, and registry governance exist to make DCM adaptable to arbitrary organizational requirements without code changes. This priority serves at scale — a platform that can only be configured by modifying source code is not a platform.
+
+*In practice:* New compliance requirements should be expressible as policy additions within the existing framework. New provider types should fit the existing Provider base contract. New deployment contexts should be addressable through profile configuration.
+
+**4. Fit for purpose (always required)**
+DCM must actually manage data center infrastructure lifecycle. All of the above is in service of this purpose — not independent of it. An architecturally beautiful system that cannot provision a VM, track its drift, and decommission it cleanly has failed at its reason for existing.
+
+*In practice:* Design decisions that serve priorities 1–3 but break the end-to-end lifecycle (request → provision → operate → decommission) are not acceptable. Every capability added must have a clear answer to "how does this serve the lifecycle management mission?"
+
+---
+
+**The implication for profiles:** A `minimal` profile is "security with minimal operational overhead" — not "minimal security." The security architecture is present and correct in every profile. What varies is how much automation, how strict the thresholds, and how much manual intervention is acceptable. This is the principle that makes DCM trustworthy in a homelab and in a sovereign government deployment using the same codebase.
+
diff --git a/content/docs/architecture/data-model/01-entity-types.md b/content/docs/architecture/data-model/01-entity-types.md
new file mode 100644
index 0000000..fd62cb9
--- /dev/null
+++ b/content/docs/architecture/data-model/01-entity-types.md
@@ -0,0 +1,346 @@
+# DCM Data Model — Entity Types
+
+
+**Document Status:** ✅ Complete
+**Document Type:** Architecture Reference
+
+> **Foundation Document Reference**
+>
+> This document is a detailed reference for a specific domain of the DCM architecture.
+> The three foundational abstractions — Data, Provider, and Policy — are defined in
+> [00-foundations.md](00-foundations.md). All concepts in this document map to one or
+> more of those three abstractions.
+> See also: [Provider Contract](A-provider-contract.md) | [Policy Contract](B-policy-contract.md)
+>
+> **This document maps to: DATA**
+>
+> The Data abstraction — typed entity extensions (Infrastructure Resource, Composite, Process)
+
+
+**Related Documents:** [Context and Purpose](00-context-and-purpose.md) | [Four States](02-four-states.md) | [Resource Type Hierarchy](05-resource-type-hierarchy.md) | [Resource/Service Entities](06-resource-service-entities.md) | [Ownership, Sharing, and Allocation](04b-ownership-sharing-allocation.md)
+
+---
+
+## 1. Purpose
+
+This document defines the complete taxonomy of entity types in DCM. Every resource, service, group, and process managed by DCM is an entity — and every entity belongs to one of the types defined here. The entity type determines the lifecycle state machine, the ownership model, the decommission behavior, and which data model fields are applicable.
+
+Understanding entity types is prerequisite to understanding:
+- How lifecycle states are assigned and transition
+- How ownership and allocation interact
+- How drift detection operates at different levels
+- How decommission cascades through dependent entities
+
+---
+
+## 2. The Three Primary Entity Types
+
+DCM defines three primary entity types. Every entity is exactly one of these.
+
+### 2.1 Infrastructure Resource Entity
+
+An **Infrastructure Resource Entity** is a realized physical or virtual infrastructure resource that persists across time and has a full operational lifecycle.
+
+**Characteristics:**
+- Persists after provisioning — it continues to exist and consume resources until explicitly decommissioned
+- Owned by exactly one Tenant at any point in time
+- Has a full bidirectional lifecycle including OPERATIONAL and SUSPENDED states
+- Subject to drift detection — its Realized State is continuously compared against Discovered State
+- Subject to TTL management — may declare an expiry after which decommission is triggered
+- May have relationships to other entities — dependencies, attachments, allocations, business data
+- Carries field-level provenance across its full lifecycle
+
+**Lifecycle State Machine:**
+
+```
+ ┌─────────────────────────────────┐
+ │ REQUESTED │
+ │ (Intent State assembled, │
+ │ Requested State committed) │
+ └───────────────┬─────────────────┘
+ │ Provider dispatch
+ ▼
+ ┌─────────────────────────────────┐
+ │ PENDING │
+ │ (Awaiting provider capacity │
+ │ or dependency resolution) │
+ └───────────────┬─────────────────┘
+ │ Provider begins work
+ ▼
+ ┌─────────────────────────────────┐
+ │ PROVISIONING │
+ │ (Provider actively realizing) │
+ └───────────────┬─────────────────┘
+ │ Provider confirms realization
+ ▼
+ ┌─────────────────────────────────┐
+ │ REALIZED │
+ │ (Provider-confirmed, DCM has │
+ │ full Realized State record) │
+ └───────────────┬─────────────────┘
+ │ Passes health checks
+ ▼
+ ┌─────────────────────────────────┐ ◄── Primary operational state
+ │ OPERATIONAL │ Drift detection active
+ │ (Active, healthy, in use) │ Cost analysis active
+ └───┬───────────────────┬─────────┘ Policy evaluation active
+ │ │
+ Suspend │ │ Decommission request
+ request ▼ ▼
+ ┌──────────────────┐ ┌──────────────────────┐
+ │ SUSPENDED │ │ DECOMMISSIONING │
+ │ (Paused, not in │ │ (Provider removing, │
+ │ active use, │ │ dependencies │
+ │ may be billed │ │ being released) │
+ │ at reduced rate)│ └──────────┬───────────┘
+ └────────┬─────────┘ │
+ │ Resume │ Provider confirms removal
+ │ or decommission ▼
+ │ ┌──────────────────────┐
+ └─────────────► DECOMMISSIONED │ ◄── Terminal state
+ │ (Removed from infra, │
+ │ audit records │
+ │ preserved) │
+ └──────────────────────┘
+
+Any state except DECOMMISSIONED:
+ PROVISIONING_FAILED → rolls back to REQUESTED or terminal FAILED
+ PENDING_REVIEW → sovereignty/tenancy conflict during rehydration (see Section 2.1.2)
+```
+
+**Applicable to:** VirtualMachine, VLAN, IPAddress, StorageVolume, Container, LoadBalancer, DNSRecord, FirewallRule, NetworkPort, Subnet, and all other persistent infrastructure resource types.
+
+#### 2.1.1 Infrastructure Resource Entity Data Model
+
+```yaml
+infrastructure_resource_entity:
+ # Universal artifact metadata
+ uuid: # stable across full lifecycle including rehydration
+ handle: # human-readable stable identifier
+ resource_type: # e.g., Compute.VirtualMachine
+ resource_type_spec_version:
+ lifecycle_state:
+ created_at:
+ updated_at:
+
+ # Ownership
+ owned_by_tenant_uuid: # exactly one Tenant; mandatory
+ created_by_actor_uuid:
+
+ # Ownership model — see doc 04b
+ ownership_model:
+ # whole_allocation: consumer owns this entity outright
+ # allocation: this entity is an allocation carved from a pool (consumer owns it)
+ # shareable: consumer has a stake; ownership remains with pool owner
+
+ # If this is an allocation from a pool resource
+ allocated_from_pool_uuid: # UUID of the pool entity; null if not an allocation
+ allocation_ref_uuid: # UUID of the AllocationRecord relationship
+
+ # If this is a shareable stake
+ shared_resource_uuid: # UUID of the shared resource; null if not a stake
+
+ # Provider details (populated after REALIZED)
+ provider_uuid:
+ provider_entity_id: # provider's own identifier (e.g., "vm-12345")
+ provider_entity_id_history: [...] # history of provider IDs (rehydration changes these)
+
+ # Lifecycle constraints
+ ttl:
+ ttl_expires_at:
+ on_expiry:
+ billing_state:
+
+ # Rehydration
+ rehydration_constraints:
+ min_auth_level:
+ allow_delegated_rehydration:
+ rehydration_history: [...]
+
+ # Drift tracking
+ last_discovered_at:
+ drift_status:
+ last_drift_severity:
+
+ # Relationships (see doc 09)
+ relationships: [...]
+
+ # Field-level provenance on all data fields (see doc 00, Section 4)
+ # [all resource-type-specific fields carry provenance metadata]
+```
+
+#### 2.1.2 PENDING_REVIEW State
+
+`PENDING_REVIEW` is a formal lifecycle state for Infrastructure Resource Entities (not Process Resources). An entity enters `PENDING_REVIEW` when an automated operation detects a conflict that requires human resolution before the operation can proceed:
+
+| Trigger | Description |
+|---------|-------------|
+| Rehydration sovereignty conflict | Rehydration discovers the target provider no longer satisfies the entity's sovereignty constraints |
+| Cross-tenant authorization revoked | An authorization enabling a cross-tenant resource reference was revoked while the resource is still allocated |
+| Ownership transfer conflict | An ownership transfer request conflicts with active relationships that prevent transfer |
+
+An entity in `PENDING_REVIEW`:
+- Is not actively drifting from its Realized State (the underlying resource is unchanged)
+- Has an active `pending_review_record` on the entity with trigger, timestamp, and resolution options
+- Generates notifications to the entity owner, Tenant admin, and platform admin
+- Remains in `PENDING_REVIEW` until a resolution action is taken (re_authorize, release, escalate, or manual override)
+- Is never automatically resolved — all resolutions require explicit human or policy authorization
+
+### 2.2 Composite Resource Entity
+
+A **Composite Resource Entity** is produced by a compound resource type specification that orchestrates multiple constituent Infrastructure Resource Entities to deliver a higher-order service. The composite is a first-class entity — it has its own UUID, Tenant ownership, and lifecycle. Its constituents each retain their own entity identity.
+
+**Characteristics:**
+- Represents the logical aggregate, not a physical resource
+- Owned by exactly one Tenant (the Tenant that requested the composite service)
+- Constituents may be owned by the same Tenant or may be allocations/stakes in pool resources owned by another Tenant
+- Drift detection operates at two levels: the composite level (is the composite healthy as a whole?) and the constituent level (is each underlying resource still in its expected state?)
+- Decommission is staged: composite decommissioned first, then constituents in reverse dependency order
+
+**Lifecycle state machine:** Same as Infrastructure Resource Entity. The composite's `lifecycle_state` reflects the aggregate health of all constituents — a composite is OPERATIONAL only when all required constituents are OPERATIONAL.
+
+**Constituent relationship:** Each constituent is recorded as a `constituent_of` relationship from the constituent to the composite. The composite holds `has_constituent` relationships to each constituent. The composite UUID is the correlation key across all constituent audit records.
+
+```yaml
+composite_resource_entity:
+ uuid:
+ resource_type: # e.g., ApplicationStack.WebApp
+ lifecycle_state:
+ owned_by_tenant_uuid:
+ composition_visibility:
+ # opaque: consumers see composite only; constituents hidden
+ # transparent: consumers see composite and all constituents
+ # selective: policy declares which constituents are visible
+
+ constituents:
+ - constituent_entity_uuid:
+ role:
+ required_for_composite_operational:
+ # If a required constituent fails, the composite enters DEGRADED
+ constituent_lifecycle_state:
+ composite_health:
+```
+
+### 2.3 Process Resource Entity
+
+A **Process Resource Entity** represents an ephemeral execution — an automation job, playbook, pipeline, workflow, or script execution. It does not persist after completion. Its lifecycle is terminal-focused: every Process Resource Entity ends in either COMPLETED, FAILED, or CANCELLED.
+
+**Characteristics:**
+- Does not persist after reaching a terminal state — no ongoing Realized State to manage
+- Must declare `max_execution_time` — mandatory, not optional
+- If max_execution_time is exceeded, the process enters FAILED state and DCM generates a `PROCESS_TIMEOUT` event
+- If the process modifies any Infrastructure Resource Entity, it must record the modified entity UUIDs in its provenance
+- Owned by the Tenant that initiated the execution
+- Subject to audit — every process execution produces a full audit trail
+
+**Lifecycle state machine:**
+
+```
+REQUESTED → INITIATED → EXECUTING → COMPLETED (terminal)
+ → FAILED (terminal)
+ → CANCELLED (terminal — requires explicit cancel request)
+```
+
+No SUSPENDED state. No PENDING_REVIEW state. Process Resources are ephemeral — they do not enter states that require ongoing management.
+
+```yaml
+process_resource_entity:
+ uuid:
+ resource_type: # e.g., Automation.AnsiblePlaybook
+ lifecycle_state:
+ owned_by_tenant_uuid:
+ created_by_actor_uuid:
+
+ max_execution_time: # mandatory
+ started_at:
+ completed_at:
+ execution_timeout_at: # computed: started_at + max_execution_time
+
+ # Entities this process modified (mandatory if any modifications made)
+ affected_entity_uuids: [, ...]
+
+ # Execution details
+ provider_uuid: # which automation provider executed this
+ provider_job_id: # provider's own job identifier
+ exit_status:
+ execution_log_ref: # reference to log store entry
+
+ # Provenance on all execution parameters carries field-level lineage
+```
+
+---
+
+## 3. Sub-Types and Specializations
+
+### 3.1 Shared Resource Entity (Infrastructure Resource sub-type)
+
+A **Shared Resource Entity** is an Infrastructure Resource Entity where multiple consumers hold stakes — references, attachments, or dependencies — without any consumer owning an allocation of the resource. The resource has a single owner (typically a platform or network operations Tenant). Consumers reference it through relationships.
+
+See [Ownership, Sharing, and Allocation](04b-ownership-sharing-allocation.md) for the complete model.
+
+**Examples:** VLAN, NetworkSegment, SharedStorageCluster, DNS Zone, NTP Server, Certificate Authority.
+
+**Key property:** `ownership_model: shareable`
+
+Decommission is deferred while any active stakeholder relationships exist. The `minimum_relationship_count` on the resource type spec declares the safe minimum — typically 0 (can be decommissioned when all stakes are released) but may be higher for infrastructure that must always have at least one consumer.
+
+### 3.2 Allocatable Pool Resource (Infrastructure Resource sub-type)
+
+An **Allocatable Pool Resource** is an Infrastructure Resource Entity that serves as a pool from which consumers receive owned allocations. The pool itself is owned by a platform Tenant. Each allocation request produces a new, independently owned Infrastructure Resource Entity carved from the pool.
+
+See [Ownership, Sharing, and Allocation](04b-ownership-sharing-allocation.md) for the complete model.
+
+**Examples:** IPAddressPool (allocates IPAddress entities), SubnetPool (allocates Subnet entities), VLANPool (allocates VLAN entities), StoragePool (allocates StorageVolume entities).
+
+**Key property:** `ownership_model: whole_allocation` on the pool entity; allocation products have `ownership_model: allocation`.
+
+The pool tracks available capacity. Allocation requests go through the placement engine like any other resource request. The produced allocation entity is owned by the requesting Tenant.
+
+---
+
+## 4. Entity Identity Invariants
+
+These invariants apply to all entity types without exception:
+
+| Invariant | Rule |
+|-----------|------|
+| UUID stability | An entity's UUID never changes across its full lifecycle, including rehydration and provider migration |
+| Single Tenant ownership | Every Infrastructure Resource Entity and Process Resource Entity is owned by exactly one Tenant at all times |
+| Composite constituent ownership | A Composite Resource Entity's constituents are owned individually — the composite UUID does not override constituent Tenant ownership |
+| Immutable Realized State | Realized State events are append-only; a new event is created for every state change |
+| Audit trail preservation | Audit records for an entity are never destroyed while any related entity is active; preservation policy governs post-terminal retention |
+| Provider ID separation | The entity UUID is the DCM stable identity; the provider entity ID is the provider's own reference. These are separate and the provider ID may change on rehydration |
+
+---
+
+## 5. Entity Type to Resource Type Mapping
+
+Not all resource types produce the same entity type. The entity type is declared in the Resource Type Specification:
+
+```yaml
+resource_type_spec:
+ fqn: Compute.VirtualMachine
+ entity_type: infrastructure_resource # infrastructure_resource | composite_resource | process_resource
+ ownership_model: whole_allocation # whole_allocation | allocation | shareable
+ allocatable_from_pool_type: null # if allocation: the pool resource type this comes from
+ pool_resource_type: null # if pool: declare this is a pool resource
+ shareable: false # if shareable: true
+```
+
+---
+
+## 6. Related Policies
+
+| Policy | Rule |
+|--------|------|
+| `ENT-001` | Every Infrastructure Resource Entity must be owned by exactly one Tenant at all times |
+| `ENT-002` | Process Resource Entities must declare max_execution_time — this field has no default and is not optional |
+| `ENT-003` | Process Resource Entities must record all affected entity UUIDs if any infrastructure modifications are made during execution |
+| `ENT-004` | Composite Resource Entity lifecycle_state reflects aggregate constituent health — OPERATIONAL only when all required constituents are OPERATIONAL |
+| `ENT-005` | PENDING_REVIEW is a valid Infrastructure Resource Entity state requiring human resolution — it is never an error state and never automatically resolved |
+| `ENT-006` | The entity UUID is immutable across the full entity lifecycle including rehydration, provider migration, and ownership transfer |
+
+---
+
+*Document maintained by the DCM Project. For questions or contributions see [GitHub](https://github.com/dcm-project).*
diff --git a/content/docs/architecture/data-model/02-four-states.md b/content/docs/architecture/data-model/02-four-states.md
new file mode 100644
index 0000000..55223be
--- /dev/null
+++ b/content/docs/architecture/data-model/02-four-states.md
@@ -0,0 +1,818 @@
+# DCM Data Model — The Four States
+
+
+
+**Document Status:** ✅ Complete
+**Related Documents:** [Context and Purpose](00-context-and-purpose.md) | [Entity Relationships](09-entity-relationships.md) | [data stores](11-storage-providers.md) | [Audit, Provenance, and Observability](12-audit-provenance-observability.md)
+
+> **Foundation Document Reference**
+>
+> This document is a detailed reference for a specific domain of the DCM architecture.
+> The three foundational abstractions — Data, Provider, and Policy — are defined in
+> [00-foundations.md](00-foundations.md). All concepts in this document map to one or
+> more of those three abstractions.
+> See also: [Provider Contract](A-provider-contract.md) | [Policy Contract](B-policy-contract.md)
+>
+> **This document maps to: DATA**
+>
+> The Data abstraction — four lifecycle stages and their storage models
+
+
+
+---
+
+## 1. Purpose
+
+The four states are the foundational model for how DCM tracks the complete lifecycle of any resource or service. Every entity in DCM exists in one or more of these states simultaneously. The states are not sequential stages — they are parallel, independently maintained records that together provide a complete, auditable picture of what was requested, what was approved, what was built, and what actually exists.
+
+The four states answer four distinct questions:
+
+| State | Question Answered | Data Domain |
+|-------|------------------|-------------|
+| **Intent State** | What did the consumer ask for? | `intent_records` — append-only, immutable |
+| **Requested State** | What was approved and dispatched to the provider? | `requested_records` — append-only, immutable |
+| **Realized State** | What did the provider actually build? | `realized_entities` — versioned snapshots, `is_current` flag |
+| **Discovered State** | What does DCM observe actually existing right now? | `discovered_records` — ephemeral, refreshed per discovery run |
+
+> **Infrastructure note (doc 51):** All four data domains are stored in a single PostgreSQL-compatible database. The logical distinctions (immutability rules, versioning model, query patterns) are preserved via table design, `REVOKE UPDATE/DELETE`, and RLS. Git, Kafka, and Redis are optional deployment enhancements, not architectural requirements. See [51-infrastructure-optimization.md](51-infrastructure-optimization.md).
+
+---
+
+## 2. State Definitions
+
+### 2.1 Intent State
+
+The **Intent State** is the immutable record of a consumer's original declaration. It is captured at the moment a request is submitted — before any layer assembly, before any policy evaluation, before any provider selection.
+
+**Characteristics:**
+- Immutable once created — the consumer's original intent is never modified
+- Stored in a GitOps store — branched, reviewed, merged
+- The CI/CD pipeline operates on the Intent State — policy pre-validation, cost estimation, sovereignty check, approval workflow
+- Versioned via Git history — every revision of an intent is traceable
+- Supports human review and debate via the PR mechanism
+- The entity UUID is assigned at Intent State creation — it follows the entity through all subsequent states
+
+**When created:** Every request submission, every rehydration operation, every drift remediation authorization
+
+**Content:** The consumer's raw declaration in DCM Unified Data Model format — what they want, not what will be built
+
+### 2.2 Requested State
+
+The **Requested State** is the fully assembled, policy-processed, provider-ready payload. It is produced by the Request Payload Processor from the Intent State — after layer assembly, after all policy evaluation, after provider selection.
+
+**Characteristics:**
+- Immutable once created — a new Requested State is created for each request cycle
+- Stored in a GitOps store — committed, versioned, triggering CD pipeline
+- The CD pipeline dispatches from the Requested State to the provider
+- Contains the complete assembled payload with full field-level provenance
+- Contains the results of all policy evaluations — which policies ran, what they did, what they locked
+- Contains provider selection — which provider will realize this request
+- Is the authoritative record of what DCM instructed a provider to build
+
+**When created:** After Intent State approval (merge), after successful policy processing
+
+**Content:** The complete assembled payload in DCM Unified Data Model format, with full provenance chain, policy evaluation results, provider selection, and override control metadata
+
+### 2.3 Realized State
+
+The **Realized State** is the provider-confirmed record of what was actually built. It is produced by the provider after successful realization — the denaturalized result of the provider's execution, translated back to DCM Unified Data Model format.
+
+**Characteristics:**
+- Write-once complete snapshots — each Realized State record is a full entity state, never modified after writing
+- Every Realized State record is traceable to exactly one Requested State record — no exceptions
+- Stored in a realized_entities table keyed by entity UUID
+- Contains provider-specific details not in the Requested State — assigned IPs, generated passwords, actual storage sizes, provider-internal IDs
+- Is the authoritative record of what actually exists from DCM's perspective
+- Drift is detected by comparing the most recent Realized State snapshot against Discovered State
+- Carries a supersession chain — each snapshot knows which snapshot it superseded and which superseded it
+
+**Three write sources (all require a corresponding Requested State record):**
+
+| Source | Requested State record type | Example |
+|--------|---------------------------|---------|
+| Initial realization | `initial_realization` | Consumer provisions a new VM |
+| Consumer update request | `consumer_update` | Consumer patches an editable field |
+| Provider update notification | `provider_update` | Provider reports an authorized state change (auto-healing, maintenance) |
+
+**What does NOT write to the Realized Store:**
+- Drift detection — drift only compares, never writes
+- Discovery cycles — discovery writes to Discovered Store only
+- Unsanctioned provider changes — these are drift events until DCM evaluates and explicitly approves them
+
+**When created:** When a provider confirms realization of any authorized request (initial, consumer update, or approved provider update notification)
+
+**Content:** Complete entity state snapshot in DCM Unified Data Model format, with provider-added fields, full field-level provenance including provider attribution, and supersession chain references
+
+### 2.4 Discovered State
+
+The **Discovered State** is what DCM observes actually existing through active discovery — polling providers, querying Kubernetes APIs, interrogating infrastructure. It is the ground truth of what physically exists, independent of what DCM thinks exists.
+
+**Characteristics:**
+- Append-only snapshot stream — each discovery cycle produces a new snapshot
+- Stored in an pipeline_events table (ephemeral) — recent history retained, older snapshots archived or discarded
+- High-frequency and machine-generated — not appropriate for human review
+- Used exclusively for drift detection — comparing against Realized State
+- May contain resources DCM did not provision — brownfield resources discovered for ingestion
+
+**When created:** On every discovery cycle, on demand for specific entities
+
+**Content:** Raw discovered resource state in DCM Unified Data Model format, with discovery metadata (timestamp, discovery method, provider interrogated)
+
+
+### 2.5 Recovery States
+
+Five additional states apply to Infrastructure Resource Entities when the normal provisioning lifecycle encounters timeouts, cancellation failures, or partial realization. These states are governed by Recovery Policies (see [Operational Models](24-operational-models.md) Section 5).
+
+| State | Meaning | Entry Trigger |
+|-------|---------|--------------|
+| `TIMEOUT_PENDING` | Dispatch timeout fired; cancellation sent to provider | `DISPATCH_TIMEOUT` recovery trigger |
+| `LATE_REALIZATION_PENDING` | Provider responded after timeout; NOTIFY_AND_WAIT active | `LATE_RESPONSE_RECEIVED` recovery trigger |
+| `INDETERMINATE_REALIZATION` | State ambiguous; drift detection resolving | `DRIFT_RECONCILE` recovery action |
+| `COMPENSATION_IN_PROGRESS` | Compound service rollback underway | `PARTIAL_REALIZATION` trigger |
+| `COMPENSATION_FAILED` | Rollback itself failed; orphaned resources possible | Compensation step failure |
+
+See [Operational Models](24-operational-models.md) for the complete recovery state machine and Recovery Policy model.
+
+
+---
+
+## 3. The Entity UUID — Universal Linking Key
+
+Every entity has a single UUID assigned at Intent State creation. This UUID is the universal key linking the entity across all four states and all stores:
+
+```
+Intent Store: file path includes entity_uuid, content declares entity_uuid
+Requested Store: file path includes entity_uuid, content declares entity_uuid
+Realized Store: event stream keyed by entity_uuid
+Discovered Store: snapshot stream keyed by entity_uuid (matched via provider labels)
+Audit Store: all provenance events indexed by entity_uuid
+Search Index: entity_uuid → git_path mapping for Git stores
+```
+
+Given an entity UUID, DCM can reconstruct the complete history of that entity across its entire lifecycle — from the consumer's original intent through every state transition to the current discovered state.
+
+---
+
+## 4. Physical Representation — Data Domain Model
+
+All four states are stored in DCM's PostgreSQL-compatible database as distinct data domains. Each domain has specific immutability rules, access patterns, and enforcement mechanisms — but they share a single infrastructure dependency. See [Infrastructure Requirements](51-infrastructure-optimization.md) for the prescribed infrastructure model and [Data Store Contracts](#41-data-store-contracts) below for the enforcement rules.
+
+Git is available as an optional ingress adapter — consumers who prefer PR-based workflows can submit intent via Git. But Git is an ingress path, not a state store. DCM's state lives in PostgreSQL.
+
+### 4.1 Data Store Contracts
+
+Each data domain enforces its contract through PostgreSQL-native mechanisms:
+
+| Domain | Table | Immutability | Enforcement |
+|--------|-------|-------------|-------------|
+| **Intent** | `intent_records` | Append-only — new intent creates a new row, previous intents never modified | `REVOKE UPDATE, DELETE` on table; RLS per tenant |
+| **Requested** | `requested_records` | Append-only — each policy evaluation produces a new version with full provenance | `REVOKE UPDATE, DELETE` on table; RLS per tenant |
+| **Realized** | `realized_entities` | Versioned snapshots — each state change creates a new row with `is_current` flag | Append-on-change semantics; `is_current` enforces single latest; RLS per tenant |
+| **Discovered** | `discovered_records` | Ephemeral — each discovery run produces fresh snapshots; previous runs retained for trend analysis | Grouped by `discovery_run_uuid`; RLS per tenant |
+
+**Pipeline events** flow between control plane services via the `pipeline_events` table with PostgreSQL `LISTEN/NOTIFY` for real-time routing. For high-throughput deployments, Kafka can be added alongside as an optional enhancement.
+
+**Audit records** are stored in `audit_records` with a SHA-256 hash chain (each record's hash includes the previous record's hash), append-only enforcement (`REVOKE UPDATE, DELETE` + trigger-based immutability guard), and per-entity chain sequence numbers.
+
+### 4.2 Realized State Snapshot Model
+
+The Realized domain uses a **snapshot model** — each record is a complete entity state, not a delta. This makes rehydration a direct lookup rather than an event replay, and point-in-time queries ("what was the state on March 15?") are direct lookups.
+
+```yaml
+realized_state_snapshot:
+ realized_uuid: # this snapshot's identity
+ entity_uuid: # stable entity identity across versions
+ realized_at:
+
+ # Always traceable to a request — mandatory, not nullable
+ source_type:
+ request_uuid:
+
+ # Versioning
+ version_major:
+ version_minor:
+ version_revision:
+ is_current: # only one current per entity_uuid
+
+ # Complete entity state at this point — all fields, all provenance
+ fields:
+ # [full entity state in DCM Unified Data Model format]
+
+ # Provider-added fields
+ provider_metadata:
+ provider_entity_id:
+ provider_reported_at:
+```
+
+**Why snapshots instead of events:** Rehydration requires a complete entity state, not a replay of field-level events. The Realized domain is written only when an authorized change completes — it does not need high-frequency write throughput.
+
+### 4.3 Query and Caching
+
+For read-heavy workloads (catalog browsing, placement lookups, resource listing), PostgreSQL materialized views provide derived projections optimized for specific query patterns. These views are explicitly non-authoritative — the base tables always win if a view and a table disagree.
+
+For deployments requiring geographically distributed read performance, Redis can be added as an optional caching layer in front of materialized views.
+
+---
+
+## 5. Rehydration
+
+Rehydration is the process of using a previously stored state record as the starting point for a new request. It is not a shortcut around governance — **all relevant governance policies always apply regardless of rehydration source.** Rehydration is a new request that happens to start from a known prior state.
+
+### 5.1 Three Rehydration Sources
+
+**From Intent State:**
+- The consumer's original declaration is replayed
+- Full layer assembly runs — current layers applied
+- All governance policies run — current policies applied
+- Provider selection runs fresh
+- Most likely to produce a different result than the original — policies and layers may have changed
+- Use cases: upgrade resource to current standards, apply new sovereignty constraints, environment refresh
+
+**From Requested State:**
+- The previously assembled, policy-processed payload is loaded
+- Layer assembly is skipped — layers were already applied
+- All governance policies run — current policies applied
+- Provider selection: configurable via flag (see Section 5.3)
+- Use cases: reproduce a resource as closely as possible to the approved specification
+
+**From Realized State:**
+- The provider-confirmed realized payload is loaded
+- Provider-specific fields are stripped — DCM unified format only
+- Layer assembly is skipped
+- All governance policies run — current policies applied
+- Provider selection: configurable via flag
+- Use cases: exact reproduction for disaster recovery, environment cloning, replacing a failed resource
+
+### 5.2 The Common Governance Pipeline
+
+Regardless of rehydration source, all requests flow through the same governance pipeline:
+
+```
+Rehydration source selected and loaded
+ │
+ │ Source payload becomes the basis for a new Intent State record
+ │ New entity UUID assigned (or existing UUID preserved — policy decision)
+ │ Rehydration provenance recorded: source_store, source_record_uuid,
+ │ rehydration_reason, requested_by_uuid, rehydration_timestamp
+ ▼
+If source = Intent:
+ │ Full layer assembly runs (Steps 1-7)
+ │ Current layers applied
+ ▼
+If source = Requested or Realized:
+ │ Layer assembly skipped
+ │ Payload loaded as pre-assembled
+ │ If source = Realized: provider-specific fields stripped
+ ▼
+Placement evaluation
+ │ See Section 5.3 — configurable
+ ▼
+Policy Engine — ALL governance policies applied
+ │ Authorization policies: does this actor have permission to rehydrate?
+ │ Transformation policies: current enrichment applied
+ │ Validation policies: current constraints checked
+ │ GateKeeper policies: current field locks applied
+ │ Gatekeeping policies: is this resource type still permitted?
+ │
+ │ Governance is NEVER skippable — not for any rehydration source,
+ │ not for any actor, not for any urgency claim
+ ▼
+New Requested State produced and stored
+ │ New record — never overwrites the source record
+ │ Source record remains immutable
+ │ Provenance chain links to source record
+ ▼
+Provider dispatch
+ │ Dispatched to selected provider
+ ▼
+New Realized State events produced
+ │ New event stream or continuation of existing stream
+ │ Provenance links to rehydration Requested State
+```
+
+### 5.3 Placement Flag — Provider-Portable Rehydration
+
+When rehydrating from Requested State or Realized State, provider selection is configurable via an explicit flag in the rehydration request:
+
+```yaml
+rehydration_request:
+ uuid:
+ source_store:
+ source_record_uuid:
+
+ placement:
+ re_evaluate: false
+ # false (default): honor provider selection from source record
+ # Use when: original provider is available and appropriate
+ # Result: resource reproduced on same provider
+ #
+ # true: strip provider selection, run placement policies fresh
+ # Use when: original provider unavailable, decommissioned,
+ # at capacity, or no longer sovereign-compliant
+ # Result: placement policies select provider from current landscape
+ # Named concept: Provider-Portable Rehydration
+
+ placement_constraints:
+ # Optional — additional constraints for re-evaluation
+ # Only applicable when re_evaluate: true
+ exclude_provider_uuids: [, ...]
+ require_region:
+ require_sovereignty_capability:
+
+ governance:
+ apply_all_policies: true
+ # Always true — governance is never skippable
+ # Included explicitly for auditability — the rehydration record
+ # must declare that governance was applied
+
+ policy_version: current
+ # current (default): apply today's policies
+ # pinned: apply policies as of a specific timestamp
+ # Use when: exact historical reproduction required
+ # (audit evidence, regulatory examination, environment reconstruction)
+ # Requires elevated authorization — bypasses current GateKeeper policies
+ # Only SRE and Admin actors may use pinned policy version
+
+ pinned_timestamp:
+ # Required when policy_version: pinned
+
+ rehydration_reason:
+ requested_by_uuid:
+```
+
+### 5.4 The Four Rehydration Modes
+
+Two independent axes — placement and policy version — produce four distinct rehydration configurations:
+
+| Mode | re_evaluate | policy_version | Use Case |
+|------|-------------|----------------|----------|
+| **Faithful** | false | current | Same provider, current governance |
+| **Provider-Portable** | true | current | New provider, current governance |
+| **Historical Exact** | false | pinned | Same provider, historical governance (audit evidence) |
+| **Historical Portable** | true | pinned | New provider, historical governance |
+
+Historical modes require elevated authorization. All modes run governance — the difference is whether governance uses current or pinned policies.
+
+### 5.5 Rehydration Tenancy and Sovereignty Controls
+
+**Tenancy controls, sovereignty directives, and cross-tenant authorizations are always evaluated against current policies during rehydration — they cannot be pinned to historical versions.**
+
+The `policy_version: pinned` setting governs resource configuration policies only. It does not apply to:
+- Tenancy boundary enforcement
+- Sovereignty constraints
+- Cross-tenant authorization requirements
+
+```yaml
+rehydration:
+ policy_version: pinned # governs resource configuration policies
+ # The following ALWAYS use current policies — cannot be pinned:
+ tenancy_controls: always_current
+ sovereignty_controls: always_current
+ cross_tenant_authorizations: always_current
+```
+
+**When rehydration conflicts with current tenancy controls:**
+
+If the current policy environment produces a tenancy or sovereignty constraint that conflicts with a cross-tenant allocation valid at original request time — for example, the consuming Tenant's authorization was revoked since the original request — the rehydration is **paused**, not failed or silently bypassed:
+
+```
+Rehydration detects cross-tenant authorization conflict
+ │
+ ▼
+Entity enters PENDING_REVIEW state
+ │ Allocation is not automatically released
+ │ Rehydration_tenancy_conflict_record created
+ ▼
+Notifications dispatched:
+ │ entity owner, owning Tenant admin,
+ │ consuming Tenant admin, platform admin
+ ▼
+Resolution options:
+ re_authorize → issue new cross_tenant_authorization for this allocation
+ release → release the allocation, entity decommissioned
+ escalate → refer to platform admin for manual decision
+ │
+ └── A policy may declare automatic resolution:
+ "on rehydration conflict → re_authorize if consuming Tenant
+ still meets sovereignty requirements"
+```
+
+**System policies for rehydration tenancy:**
+
+| Policy | Rule |
+|--------|------|
+| `RHY-001` | Tenancy, sovereignty, and cross-tenant authorizations always use current policies during rehydration — cannot be pinned |
+| `RHY-002` | Rehydration that conflicts with current tenancy/sovereignty pauses and enters PENDING_REVIEW |
+| `RHY-003` | A paused rehydration allocation is not automatically released — requires explicit resolution |
+| `RHY-004` | A policy may declare automatic resolution behavior for rehydration tenancy conflicts |
+
+### 5.6 Partial Resolution of Q54 — Provider Selection
+
+The placement flag model clarifies the Q54 question (selected_provider as policy output vs placement component). The emerging answer:
+
+**Policies set placement constraints — the placement component selects the provider.**
+
+A GateKeeper policy may output: "must be in region EU-WEST, must support sovereignty capability PCI-DSS." The placement component reads these constraints and selects the specific provider within those constraints. The policy does not name the provider. The placement component names the provider.
+
+This is consistent with the portability model — a policy that names a specific provider would be portability-breaking. Policies set constraints. Placement honors constraints and selects.
+
+---
+
+## 6. Drift Detection
+
+Drift is the difference between what DCM believes exists (Realized State) and what actually exists (Discovered State).
+
+### 6.1 Drift Detection Flow
+
+```
+Discovery cycle completes
+ │ Provider interrogated → Discovered State snapshot written
+ ▼
+Drift Detection component
+ │ Loads latest Discovered State for entity UUID
+ │ Loads latest Realized State events for entity UUID
+ │ Field-by-field comparison
+ ▼
+No drift detected
+ │ Discovery timestamp updated
+ │ No action
+ ▼
+Drift detected
+ │ Drift record created with:
+ │ - entity_uuid
+ │ - drifted_fields: [{field_path, realized_value, discovered_value}]
+ │ - discovery_timestamp
+ │ - drift_severity:
+ ▼
+Policy Engine evaluates drift
+ │ Drift response policy determines action:
+ │ REVERT: submit a rehydration request from Realized State to restore
+ │ UPDATE_DEFINITION: promote discovered state to new Realized State
+ │ ALERT: notify personas, no automatic action
+ │ ESCALATE: trigger human review workflow
+ │
+ │ Response determined by drift severity, resource type,
+ │ resource ownership, and organizational policy
+ ▼
+Audit Store records drift event with full provenance
+```
+
+
+### 6.3 Drift Severity Classification
+
+Drift severity is determined by combining three independent tiers. The final severity is the highest tier that applies.
+
+**Tier 1 — Field criticality (declared in Resource Type Specification):**
+
+```yaml
+resource_type_spec:
+ fields:
+ display_name:
+ drift_criticality: minor # non-functional change
+ cpu_count:
+ drift_criticality: significant
+ memory_gb:
+ drift_criticality: significant
+ security_group_ids:
+ drift_criticality: critical # security-relevant change
+ firewall_rules:
+ drift_criticality: critical
+```
+
+**Tier 2 — Profile/layer magnitude thresholds:**
+
+```yaml
+# system/drift/severity-thresholds layer (overridable at platform/tenant domain)
+drift_severity_thresholds:
+ significant_field_magnitude_upgrade:
+ percentage_change_threshold: 50 # >50% change upgrades significant → critical
+ minor_field_magnitude_upgrade:
+ item_count_threshold: 10 # 10+ changed items upgrades minor → significant
+```
+
+**Tier 3 — Provider and consumer injection:**
+
+Providers may suggest severity in update notifications (raise only):
+```yaml
+provider_drift_hint:
+ field: memory_gb
+ suggested_severity: critical
+ reason: "Memory decrease on running workload risks OOM"
+```
+
+Consumers may override sensitivity on specific entities (raise or lower):
+```yaml
+entity:
+ drift_sensitivity_overrides:
+ - field: cpu_count
+ override_criticality: critical
+ reason: "Production payments workload — any CPU change is critical"
+```
+
+**Resolution rule:** The Drift Detection component takes the highest severity from all three tiers. Provider injection can raise but not lower the Tier 1/2 result. Consumer injection can raise or lower (entity owner controls their own resource's sensitivity). Profile governs whether consumer lowering is permitted.
+
+
+
+### 6.3 Drift Severity Classification
+
+Drift severity is determined by two independent dimensions declared in the Resource Type Specification — field criticality and change magnitude. The combination produces a deterministic severity classification for any drift event.
+
+#### Field Criticality (declared per field in Resource Type Spec)
+
+```yaml
+resource_type_spec:
+ fqn: Compute.VirtualMachine
+ fields:
+ display_name:
+ drift_criticality: low # cosmetic; never affects function
+ cpu_count:
+ drift_criticality: medium # affects performance; not security
+ memory_gb:
+ drift_criticality: medium
+ security_group_ids:
+ drift_criticality: critical # security boundary field; always critical
+ os_image:
+ drift_criticality: critical # security posture; always critical
+ storage_gb:
+ drift_criticality: medium
+ network_interface_ids:
+ drift_criticality: high # connectivity; significant operational impact
+```
+
+**Criticality levels:** `low | medium | high | critical`
+
+#### Change Magnitude (profile-governed thresholds)
+
+```yaml
+drift_magnitude_thresholds:
+ profile_defaults:
+ standard:
+ minor: change_pct < 10%
+ significant: change_pct 10-50%
+ critical: change_pct > 50% OR value_disappeared OR type_changed
+ prod:
+ minor: change_pct < 5%
+ significant: change_pct 5-25%
+ critical: change_pct > 25% OR value_disappeared OR type_changed
+```
+
+#### Severity Matrix
+
+| Field Criticality | Change Magnitude | Drift Severity |
+|------------------|-----------------|----------------|
+| low | any | minor |
+| medium | minor | minor |
+| medium | significant | significant |
+| medium | critical | significant |
+| high | minor | significant |
+| high | significant | significant |
+| high | critical | critical |
+| critical | any | critical |
+
+**Unsanctioned changes** (no corresponding Requested State record) are always elevated one severity level above what the matrix produces. A `significant` unsanctioned change becomes `critical`.
+
+**Multi-field drift:** when multiple fields drift simultaneously, the overall severity is the highest severity among all drifted fields.
+
+
+### 6.2 Unsanctioned Changes
+
+A specific category of drift — a change made directly to a resource without a corresponding DCM request. Detected by:
+- Kubernetes: CR spec change without DCM request annotation
+- VMware/OpenStack: resource modification not traceable to a DCM Requested State record
+- General: any Discovered State field value that differs from Realized State without a Requested State record explaining the change
+
+Unsanctioned changes are always reported to the Policy Engine as `UNSANCTIONED_CHANGE` events. Policy determines the response.
+
+---
+
+## 7. CI/CD Integration
+
+The GitOps stores are the natural integration point for CI/CD pipelines. DCM does not prescribe a specific CI/CD tool — the GitOps store contract requires hook support, and the CI/CD tool is a deployment choice.
+
+### 7.1 CI Pipeline (Intent State)
+
+Triggered on: branch creation or update (new or revised intent)
+
+```
+CI pipeline executes:
+ 1. Policy pre-validation (dry run — no state changes)
+ → Reports: which policies would apply, what they would do
+ 2. Cost estimation
+ → Reports: estimated cost for lifecycle of this resource
+ 3. Dependency graph validation
+ → Reports: all required dependent resources, any conflicts
+ 4. Sovereignty constraint check
+ → Reports: which sovereignty constraints apply, any violations
+ 5. Authorization check
+ → Reports: does this actor have permission to request this resource type?
+ 6. Auto-approve evaluation
+ → Reports: can this be merged automatically, or does it require human review?
+
+All results posted as PR comments on the Intent State branch
+Consumer and approvers can review and debate before merge
+```
+
+### 7.2 CD Pipeline (Requested State)
+
+Triggered on: Intent State merge (PR merged to main)
+
+```
+CD pipeline executes:
+ 1. Request Payload Processor assembles full payload
+ 2. Full policy evaluation (binding — not dry run)
+ 3. Provider selection (or re-evaluation if placement flag set)
+ 4. Requested State committed to Git store
+ 5. Provider dispatch via API Gateway
+ 6. Status monitoring — poll or receive callbacks until terminal state
+ 7. Status written back to PR or status file
+ 8. Consumer notification
+```
+
+### 7.3 The Third Rail — Direct API Ingress
+
+Not all requests come through the GitOps PR workflow. Some requests come through direct API submission — automated systems, CI/CD pipelines, Terraform providers, programmatic consumers. These bypass the human review workflow but not governance.
+
+Direct API ingress:
+- Creates an Intent State record (the submitted payload becomes the intent)
+- Runs the same CI validation pipeline but non-interactively
+- If auto-approve policy permits: proceeds directly to assembly and dispatch
+- If human review required: creates a PR for review before proceeding
+- Same governance pipeline regardless of ingress path
+
+The three ingress paths — PR workflow, direct API, and programmatic (Terraform/Ansible) — all converge on the same governance pipeline. The ingress path affects the review workflow; it never affects governance.
+
+---
+
+## 7a. Four States Operational Gaps — Q75 through Q78
+
+### 7a.1 Entity UUID Preservation on Rehydration (Q75)
+
+Entity UUIDs are **preserved on rehydration**. The UUID represents the stable logical identity of the resource across provider migrations, sovereignty changes, and lifecycle events. All external references — CMDB records, cost attribution, audit trails, cross-tenant relationships, dependency declarations — reference the entity by UUID. Generating a new UUID on rehydration would silently break all of those references.
+
+What changes on rehydration is the **provider-side identifier** — the actual VM ID, container name, or resource handle at the provider. These are recorded in the rehydration history:
+
+```yaml
+entity:
+ uuid: # PRESERVED across all rehydrations
+ rehydration_history:
+ - rehydration_uuid:
+ rehydrated_at:
+ trigger:
+ from_provider_uuid:
+ to_provider_uuid:
+ from_realized_entity_id: "vm-12345" # provider's ID — no longer valid
+ to_realized_entity_id: "vm-67890" # new provider's ID after rehydration
+ rehydrated_by:
+ intent_state_ref:
+ previous_requested_state_ref:
+ new_requested_state_ref:
+```
+
+**Rehydration is transactional:** If the target provider cannot accept the entity (capacity unavailable, sovereignty mismatch discovered mid-rehydration), the original entity remains in its current state with no UUID change and no partial state. Failure preserves the pre-rehydration state completely.
+
+### 7a.2 Pinned Authentication Level for Rehydration (Q76)
+
+Entities may declare a minimum authentication level required to rehydrate them. This prevents escalation of privilege through the rehydration mechanism — a resource provisioned with hardware-token MFA authorization should not be re-instantiatable by a simple API key.
+
+```yaml
+entity:
+ rehydration_constraints:
+ min_auth_level: hardware_token_mfa
+ # Ascending levels: api_key | ldap_password | oidc | oidc_mfa |
+ # hardware_token | hardware_token_mfa
+ auth_level_source:
+ allow_delegated_rehydration: false
+ # true = DCM service accounts may rehydrate if explicitly authorized
+```
+
+**Profile-governed enforcement:**
+
+| Profile | Enforcement |
+|---------|------------|
+| `minimal` | Not enforced — any auth level may rehydrate |
+| `dev` | Not enforced |
+| `standard` | Advisory — warn if rehydrating actor has lower auth |
+| `prod` | Enforced — reject if rehydrating actor has lower auth |
+| `fsi` | Enforced — dual approval required if auth level mismatch |
+| `sovereign` | Enforced — dual approval always; logged in classified audit |
+
+**Automated rehydration:** When DCM triggers rehydration automatically (sovereignty violation, provider decommission), the rehydration uses DCM's internal service account. This requires `allow_delegated_rehydration: true` OR a platform admin must manually authorize the operation. Authorization produces an audit record preserving accountability even when the action is automated.
+
+### 7a.3 Concurrent Rehydration Handling (Q77)
+
+Rehydration requests acquire an **exclusive rehydration lease** per entity. Only one rehydration may be active per entity at any time.
+
+```yaml
+rehydration_lease:
+ entity_uuid:
+ lease_uuid:
+ acquired_by:
+ acquired_at:
+ lease_ttl: PT2H # expires after 2 hours if not released
+ trigger:
+ status:
+```
+
+**Concurrent request handling:**
+
+```
+Second rehydration attempt arrives for entity
+ │
+ ├── No active lease → acquire lease; proceed
+ │
+ └── Active lease exists:
+ Priority higher than active → escalate to platform admin; queue
+ Same or lower priority → reject:
+ "Rehydration in progress — lease held since ; retry after PT2H"
+ REHYDRATION_BLOCKED audit event recorded
+```
+
+**Priority ordering:**
+1. Security/compliance emergency (sovereignty violation at fsi/sovereign)
+2. Manual platform admin rehydration
+3. Automated sovereignty migration
+4. Provider decommission migration
+5. Manual consumer rehydration request
+
+**Lease TTL expiry:** If rehydration hangs or crashes, the lease expires after TTL. DCM marks the rehydration `failed` in rehydration_history, releases the lease, and triggers drift detection to assess partial completion at the provider.
+
+### 7a.4 Discovered State Retention (Q78)
+
+Discovered State is ephemeral operational data — not the authoritative source of truth (Realized State is). It is a snapshot used for drift detection. Three retention modes, all profile-governed:
+
+```yaml
+discovered_state_retention:
+ mode: # hybrid recommended
+
+ rolling_window:
+ retention: P7D # keep last 7 days; useful for trending
+
+ event_driven:
+ retain_until: drift_resolved # keep until associated drift record resolved
+ # Ensures drift investigation has the discovery snapshot that triggered it
+
+ hybrid: # recommended — combines both
+ minimum_retention: P24H
+ retain_until: drift_resolved # extend beyond minimum until drift resolved
+ maximum_retention: P30D # hard ceiling regardless of drift status
+```
+
+**Profile-governed defaults:**
+
+| Profile | Mode | Min Retention | Max Retention |
+|---------|------|--------------|--------------|
+| `minimal` | `rolling_window` | — | P3D |
+| `dev` | `rolling_window` | — | P7D |
+| `standard` | `hybrid` | P24H | P30D |
+| `prod` | `hybrid` | P48H | P30D |
+| `fsi` | `hybrid` | P7D | P90D |
+| `sovereign` | `hybrid` | P7D | P90D |
+
+**Discovered State and the Audit Store:**
+
+Discovered State records are **NOT** stored in the Audit Store — they are too high-volume and too ephemeral for compliance-grade storage. However, drift events triggered by Discovered State ARE recorded in the Audit Store with a reference to the discovery snapshot UUID. After the Discovered State expires, the audit record still exists — it cannot link to the full snapshot, but the drift event itself is preserved.
+
+---
+
+## 7b. Rehydration System Policies — Complete Set
+
+| Policy | Rule |
+|--------|------|
+| `RHY-001` | Tenancy and sovereignty are always current on rehydration — they cannot be pinned to historical state. |
+| `RHY-002` | Sovereignty conflicts discovered during rehydration place the entity in PENDING_REVIEW state. |
+| `RHY-003` | Resource allocations are not automatically released on rehydration. |
+| `RHY-004` | Rehydration leases have TTL to prevent orphaned lease states. |
+| `RHY-005` | Entity UUIDs are preserved on rehydration. The UUID represents stable logical identity across provider migrations. Provider-side identifiers change on rehydration and are recorded in rehydration_history. Rehydration is transactional — failure preserves pre-rehydration state without UUID change. |
+| `RHY-006` | Entities may declare min_auth_level for rehydration. Profile governs enforcement. Automated rehydration by DCM service accounts requires allow_delegated_rehydration: true OR platform admin manual authorization with full audit trail. |
+| `RHY-007` | Rehydration requests acquire an exclusive lease per entity before proceeding. Only one rehydration may be active per entity. Concurrent requests are queued (higher priority) or rejected (same/lower). Lease TTL prevents indefinite blocking. Expiry triggers drift detection for partial completion assessment. |
+| `RHY-008` | Discovered State retention is profile-governed: rolling_window, event_driven, or hybrid. Discovered State is never stored in the Audit Store. Drift events triggered by Discovered State are recorded in the Audit Store with discovery snapshot UUID reference. Maximum retention: P30D for standard/prod; P90D for fsi/sovereign. |
+
+---
+
+## 8. Open Questions
+
+| # | Question | Impact | Status |
+|---|----------|--------|--------|
+| 1 | Git repository structure for Intent and Requested stores | Store design | ✅ Resolved — handle-based directory structure; 4 repos; tenant isolation (STO-005) |
+| 2 | Should the entity UUID be preserved or regenerated on rehydration? | Entity identity | ✅ Resolved — UUID preserved; rehydration_history records provider-side ID changes; transactional (RHY-005) |
+| 3 | For pinned policy version rehydration — what is the minimum authorization level required? | Security | ✅ Resolved — min_auth_level on entity; profile-governed enforcement; delegated rehydration requires explicit authorization (RHY-006) |
+| 4 | How are concurrent rehydration requests for the same entity handled? | Concurrency | ✅ Resolved — exclusive rehydration lease; priority ordering; TTL expiry triggers drift detection (RHY-007) |
+| 5 | Should the Discovered Store retain full history or only a configurable window? | Retention | ✅ Resolved — hybrid mode recommended; profile-governed min/max; event-driven until drift resolved; max P30-90D (RHY-008) |
+| 6 | How does the Search Index handle Git store unavailability? | Reliability | ✅ Resolved — serve degraded (warn + direct to authoritative); rebuild on recovery (STO-002) |
+
+---
+
+## 9. Related Concepts
+
+- **data store** — the formal provider type for all DCM stores
+- **Entity UUID** — the universal linking key across all four states
+- **Rehydration** — using a prior state record as the starting point for a new request
+- **Provider-Portable Rehydration** — rehydration with provider selection re-evaluated
+- **Drift Detection** — comparing Realized State against Discovered State
+- **Unsanctioned Change** — a resource modification not traceable to a DCM request
+- **CI/CD Integration** — GitOps stores as the natural CI/CD integration point
+- **Search Index** — queryable projection of GitOps stores, explicitly non-authoritative
+
+---
+
+*Document maintained by the DCM Project. For questions or contributions see [GitHub](https://github.com/dcm-project).*
diff --git a/content/docs/architecture/data-model/03-layering-and-versioning.md b/content/docs/architecture/data-model/03-layering-and-versioning.md
new file mode 100644
index 0000000..08871f8
--- /dev/null
+++ b/content/docs/architecture/data-model/03-layering-and-versioning.md
@@ -0,0 +1,2164 @@
+# DCM Data Model — Data Layers and the Assembly Process
+
+
+
+**Document Status:** ✅ Complete
+**Related Documents:** [Context and Purpose](00-context-and-purpose.md) | [Entity Types](01-entity-types.md) | [Four States](02-four-states.md) | [Resource Type Hierarchy](05-resource-type-hierarchy.md)
+
+> **Foundation Document Reference**
+>
+> This document is a detailed reference for a specific domain of the DCM architecture.
+> The three foundational abstractions — Data, Provider, and Policy — are defined in
+> [00-foundations.md](00-foundations.md). All concepts in this document map to one or
+> more of those three abstractions.
+> See also: [Provider Contract](A-provider-contract.md) | [Policy Contract](B-policy-contract.md)
+>
+> **This document maps to: DATA**
+>
+> The Data abstraction — how Data is assembled from layers
+
+
+
+---
+
+## 1. Purpose
+
+Data Layers are the mechanism by which DCM assembles a complete, contextually correct request payload from a set of composable, reusable data definitions. Rather than requiring consumers to specify every field of every resource they request, layers allow standards, organizational context, service-specific configuration, and consumer intent to be declared independently and merged into a unified payload at request time.
+
+Layers are the answer to the question: **how does a single consumer request become a complete, policy-validated, provider-ready payload?**
+
+The layering model enables:
+- **Reuse** — a base configuration defined once is inherited by thousands of resources
+- **Standardization** — organizational standards are encoded in layers, not in every individual request
+- **Separation of concerns** — infrastructure teams own core and service layers; consumers own request layers; policy owners own policy layers
+- **Scale** — 36 layer definitions can govern 40,000 VMs without duplication
+- **Auditability** — every field in the merged payload knows which layer set it and why
+
+---
+
+## 1a. Layers vs Policies — The Clear Distinction
+
+Layers and policies are the two foundational mechanisms of DCM's assembly process. They are complementary and distinct — understanding the difference is critical to using DCM correctly.
+
+### Layers Are Data
+
+A layer is a **declarative, immutable, versioned unit of data**. It carries static configuration values, organizational defaults, compliance metadata, and contextual information. A layer answers the question: **"what values should these fields have?"**
+
+Layers are **passive** — they declare values but do not execute logic. They do not evaluate the payload, make branching decisions, or enforce rules. The assembly process merges them in priority order. Layers come first.
+
+**What belongs in a layer:**
+- Infrastructure defaults (DNS servers, NTP servers, MTU values)
+- Organizational context (data center location, rack assignment, environment tier)
+- Service-specific configuration defaults (VM sizing defaults, storage class preferences)
+- Compliance metadata (data classification labels, retention tags, jurisdiction markers)
+- Provider-specific configuration (provider default settings, tooling parameters)
+- Business context (cost center defaults, environment labels, team tags)
+
+### Policies Are Logic
+
+A policy is an **executable rule** that evaluates the assembled payload and takes action. A policy answers the question: **"given this data, is it valid? what should change? should this proceed?"**
+
+Policies **execute** — they run logic (OPA Rego, DCM native rules, external evaluation calls). They can read every layer-provided value, validate correctness, transform fields, inject derived values, and gate requests. Policies come after layers — they operate on the assembled result.
+
+**What belongs in a policy:**
+- Validation rules ("this field must be present and within these bounds")
+- Compliance enforcement ("all resources must have a classification label")
+- Derived value injection ("inject cost center from OIDC claims")
+- Placement constraints ("must be in EU sovereignty zone")
+- Approval gates ("resources above X size require manager approval")
+- Security enforcement ("encryption must be enabled — if not, enable it or reject")
+
+### The Flow Is Strictly Unidirectional
+
+```
+Steps 1-4: LAYERS assembled → merged payload produced
+ │ Layers contribute field values
+ │ Higher priority layers override lower priority
+ │ Immutable fields locked at this stage
+ │
+ ▼
+Steps 5-9: POLICIES execute → payload evaluated and acted upon
+ │ Policies read assembled payload
+ │ Transformation: modify/inject derived fields
+ │ Validation: verify correctness
+ │ GateKeeper: approve or reject
+ │
+ ▼
+Provider-ready payload dispatched
+```
+
+Policies cannot set static configuration — that is a layer's job. A policy that finds itself repeatedly injecting the same static value into every request should be refactored: that value belongs in a layer.
+
+Layers cannot enforce rules — that is a policy's job. A layer that contains conditional logic or rule evaluation is being misused — that logic belongs in a policy.
+
+### The Decision Rule for Practitioners
+
+> "Is this a **value** that should appear in the payload? → **Layer**
+> Is this a **rule** about whether the payload is correct? → **Policy**
+> Is this a **value derived by evaluating** the payload? → **Policy** (Transformation type)"
+
+### The Analogy
+
+- Layers are the **ingredients** — pre-measured, pre-arranged, versioned
+- Policies are the **chef** — decides what to do with the ingredients, can add derived elements, makes judgment calls, can reject the dish entirely
+
+Both are necessary. Neither replaces the other.
+
+---
+
+## 2. What is a Layer?
+
+A Layer is a **declarative, immutable, versioned unit of data** that contributes some or all of its fields to a merged payload. Layers do not execute — they declare. The assembly process is what merges them.
+
+Every layer:
+- Has a **UUID** that uniquely identifies it
+- Has a **version** following the universal Major.Minor.Revision scheme
+- Is **immutable once published** — changes produce a new version
+- Carries a **reference to its parent entity** (UUID and version)
+- Has an **origination timestamp**
+- Can be **deprecated** following the universal deprecation model
+- Contributes **provenance metadata** for every field it sets — any field set by a layer records that layer's UUID as its source
+
+Layers are stored in Git following GitOps practices. They are the configuration source of truth — not the assembled payload.
+
+---
+
+## 3a. Provenance Model Configuration
+
+### 3a.1 The Three Provenance Models
+
+Field-level provenance tracks which layer set each field, which policy modified it, and the full change history. DCM supports three configurable models — organizations choose based on their scale, compliance requirements, and operational preferences. The active Profile provides a recommended default via its activated Policy Group.
+
+**Model A — Full Inline**
+All provenance stored explicitly on every entity record. Every field carries its complete provenance inline: source layer, modifying policies, previous values, timestamps, actor chain.
+
+| Aspect | Detail |
+|--------|--------|
+| Storage cost | Very high — scales with entities × fields × changes |
+| Query simplicity | Highest — all provenance in one record, no traversal |
+| Write performance | Lowest — every field change requires provenance write |
+| Audit clarity | Highest — regulators see everything in one record |
+| Tooling required | Minimal |
+| Best for | Small deployments; FSI/sovereign (regulatory clarity); home lab |
+
+**Model B — Deduplicated (Content-Addressed) ← RECOMMENDED**
+Classical content-addressed deduplication applied to provenance. The layer chain is the deduplication key — every entity sharing the same configuration references the same chain rather than storing a copy. Only fields deviating from the chain store unique delta records.
+
+```
+Full provenance = layer chain content (deduplicated, shared) + entity deltas (unique per entity)
+```
+
+**Why lossless:** Layer chains are immutable. A reference to `layer-chain-abc123` always resolves to exactly the same data — no cache invalidation, no drift. This is what makes the deduplication lossless for audit. The reference always reconstructs the original.
+
+**Storage reduction:** 95-99% for standardized deployments (many entities, few unique chains). 36 layer definitions serving 40,000 VMs produces 36 chain references, not 8 million field provenance entries.
+
+| Aspect | Detail |
+|--------|--------|
+| Storage cost | Low — scales with unique configurations, not entity count |
+| Query simplicity | Medium — chain traversal required for layer-set fields |
+| Write performance | Highest — only deltas write; chain-matching fields are free |
+| Audit clarity | Complete — full reconstruction always possible |
+| Tooling required | Moderate — chain traversal tooling |
+| Best for | Standard and prod deployments; large-scale environments |
+
+**Analogous to:** Git content-addressed objects, Docker image layers, ZFS block deduplication — all content-addressed, deduplicated, lossless.
+
+**Model C — Tiered Archive**
+Hot/warm/cold storage tiers with decreasing detail. Recent provenance at full detail and fast access; older provenance compressed to change events; oldest compressed to hash anchors only (tamper-evidence without full reconstruction).
+
+| Aspect | Detail |
+|--------|--------|
+| Storage cost | Medium — time-dependent, degrades gracefully |
+| Query simplicity | Medium — cross-tier joins for long time ranges |
+| Write performance | Medium |
+| Audit clarity | Full detail in hot tier; change events in warm; anchors in cold |
+| Tooling required | Moderate — tier promotion jobs, consistency checks |
+| Best for | Large deployments with long retention requirements |
+
+**Models B and C are orthogonal** — combine them for maximum efficiency: deduplicate at the entity level (Model B) AND tier the storage of chains and deltas (Model C). This is the highest-efficiency option for very large-scale deployments with long retention requirements.
+
+### 3a.2 Configurable Provenance Model
+
+The provenance model is declared in the DCM deployment configuration and activated via a Policy Group:
+
+```yaml
+provenance_config:
+ model:
+
+ # Model A — Full Inline
+ full_inline:
+ include_previous_values: true
+ include_actor_chain: true
+ include_policy_rationale: true
+
+ # Model B — Deduplicated (Content-Addressed)
+ layer_chain_ref:
+ store_layer_derivable: false # do not store fields matching chain default
+ delta_detail_level:
+ history_document_retention: P7Y
+ chain_store_retention: P7Y # chains retained while any entity references them
+
+ # Model C — Tiered Archive
+ tiered:
+ hot_tier_duration: P30D # full detail, fast access
+ warm_tier_duration: P365D # change events only
+ cold_tier_duration: P10Y # hash anchors only
+ warm_tier_detail:
+
+ # Model B + C — Deduplicated + Tiered (maximum efficiency)
+ layer_chain_ref_tiered:
+ chain_store_hot: P365D # chains fast for 1 year
+ chain_store_warm: P7Y # chains slower for 7 years
+ delta_store_hot: P90D # deltas fast for 90 days
+ delta_store_warm: P7Y # deltas slower for 7 years
+```
+
+### 3a.3 Profile-Appropriate Provenance Policy Groups
+
+DCM ships four provenance Policy Groups. The active Profile activates the appropriate group by default. Organizations override by swapping the active group.
+
+| Group Handle | Model | Profile Default | Concern Type |
+|-------------|-------|----------------|-------------|
+| `system/group/provenance-full-inline` | A — Full Inline | minimal, dev, fsi, sovereign | implementation_posture |
+| `system/group/provenance-deduplicated` | B — Deduplicated | standard, prod | implementation_posture |
+| `system/group/provenance-tiered-archive` | C — Tiered | (available — not default) | implementation_posture |
+| `system/group/provenance-deduplicated-tiered` | B+C — Combined | (available for large-scale) | implementation_posture |
+
+**To change provenance model:**
+```yaml
+# Override profile default — swap the active provenance group
+tenant_config:
+ policy_group_overrides:
+ replace:
+ - from: system/group/provenance-full-inline
+ to: system/group/provenance-deduplicated
+ reason: "Deploying at scale — switching to deduplicated model"
+```
+
+### 3a.4 The Audit Completeness Guarantee
+
+Regardless of provenance model, full provenance must always be reconstructable:
+
+```
+OPS-002 Regardless of provenance model, full provenance must always be
+ reconstructable for any entity from the combination of: entity
+ record, layer chain store, and Audit Store. The provenance model
+ governs where data is stored and how it is accessed — not whether
+ it is available.
+```
+
+For Model B: chain reference + entity deltas → full provenance (lossless, immutable source)
+For Model C: hot tier (full) OR warm tier (events) + cold tier (anchors prove integrity)
+For Model A: entity record alone is sufficient
+
+### 3a.5 System Policies
+
+| Policy | Rule |
+|--------|------|
+| `OPS-001` | Field-level provenance model is configurable: full_inline, layer_chain_ref (deduplicated), tiered, or layer_chain_ref_tiered. Profile activates the appropriate Policy Group as default. Organizations override by replacing the active provenance group. Model B (layer_chain_ref) is the recommended default for standard+ profiles. |
+| `OPS-002` | Regardless of provenance model, full provenance must always be reconstructable from the combination of entity record, layer chain store, and Audit Store. The provenance model governs storage location and access pattern — not data availability. |
+
+---
+
+
+### 2a. Layer Contributors
+
+Every layer type has a declared contributor type. The contributor determines what review is required before the layer becomes active in assembly. See [Federated Contribution Model](28-federated-contribution-model.md) Section 3 for the full contributor permission table.
+
+| Layer Type | Contributor | Domain | Review |
+|-----------|-------------|--------|--------|
+| Base Layer | Platform Admin | system | auto |
+| Core Layer | Platform Admin | platform | auto |
+| Intermediate / Customization Layer | Platform Admin, Consumer/Tenant | platform, tenant | per profile |
+| Service Layer | Platform Admin, Service Provider | provider | reviewed (standard+) |
+| Request Layer | Consumer/Tenant | tenant | auto (applied directly to request) |
+| Policy Layer | All contributor types | per contributor role | per profile + contributor type |
+
+The Request Layer is the only layer type that does not require a PR review — it is a consumer's direct field declarations on a specific request. All other layers flow through the GitOps PR model.
+
+
+## 3. Layer Types
+
+DCM defines six layer types. Each has a distinct purpose, scope, ownership model, and position in the assembly precedence chain.
+
+### 3.1 Base Layer
+
+**Purpose:** The foundation entity for a resource. Defines the minimum required fields and their default values for a given resource context. Everything starts with a Base Layer.
+
+**Scope:** Can be type-agnostic (a universal base) or type-scoped (a base specific to a Resource Type). A Base Layer that is type-scoped must declare its Resource Type.
+
+**Ownership:** DCM platform or platform implementor.
+
+**Characteristics:**
+- Every layer chain must begin with a Base Layer
+- Base Layers contain only universal fields — no provider-specific data
+- A Base Layer for a typed resource must conform to the Resource Type Specification's universal field requirements
+- Multiple Base Layers can exist for the same context — the applicable one is selected based on the request context
+
+**Examples:**
+- CIS Benchmark base configuration
+- Baseline OS configuration
+- DMZ network base configuration
+
+---
+
+### 3.2 Core Layers
+
+**Purpose:** Provide data that is applicable across any resource type. Core Layers carry organizational, infrastructure, and contextual data that is not specific to any one service.
+
+**Scope:** Type-agnostic by default. Core Layers apply to all resource types unless explicitly scoped. This is the primary distinction from Service Layers.
+
+**Ownership:** DCM platform, infrastructure teams, or platform implementors.
+
+**Characteristics:**
+- Applied to every request regardless of resource type
+- Cannot contain service-specific or provider-specific data
+- Carry location, organizational, and infrastructure context
+- Stored in the Core Layer Store
+- Cached in the Service Layer Cache at deployment time
+
+**Examples:**
+- Data Center layer (DC1, DC2)
+- Zone layer (Zone 1, Zone 2)
+- Rack layer
+- Geographic region layer
+- Environment layer (production, staging, development)
+
+> **Location Topology:** Location layers are one application of the Reference Data
+> Layer pattern (Section 3.7). The standard schema for each location level —
+> Country, Region, Zone, Site, Data Center, Hall, Cage, and Rack — is specified
+> in [Location Topology Layer Model](48-location-topology-layers.md), including
+> field definitions, priority bands, authority model, and hierarchy assembly.
+
+---
+
+### 3.3 Intermediate / Customization Layers
+
+**Purpose:** Provide organizational or contextual overrides and customizations that sit between the base standards and the service-specific configuration. These layers encode the organizational hierarchy and deployment context.
+
+**Scope:** Can be type-agnostic or type-scoped. Scope is declared per layer.
+
+**Ownership:** Organizational teams, domain owners, platform implementors.
+
+**Characteristics:**
+- Stack between Core Layers and Service Layers in the precedence chain
+- Encode organizational structure (business unit, enclave, logical unit)
+- Allow organizational customization without modifying base standards
+- The Git repo hierarchy typically mirrors the intermediate layer hierarchy
+
+**Examples:**
+- Ship layer (in Navy context: specific vessel configuration)
+- Enclave layer (isolated network segment configuration)
+- Business unit layer
+- DMZ customization layer
+- Production web tier layer
+
+---
+
+### 3.4 Service Layers
+
+**Purpose:** Provide service-specific data required to build a complete request payload for a specific Resource Type. Service Layers are the bridge between general organizational context and provider-ready configuration.
+
+**Scope:** **Must be type-scoped.** A Service Layer without a declared Resource Type scope is invalid. The scope inheritance behavior is configurable per Service Layer declaration.
+
+**Type Scope Declaration:**
+```yaml
+type_scope:
+ resource_type_uuid:
+ resource_type_fully_qualified_name:
+ scope_inheritance:
+ # exact: applies only to the declared Resource Type
+ # descendants: applies to the declared Resource Type and all child types via inheritance
+```
+
+**Ownership:** Service Providers or service domain teams. Stored in Service Layer SCM (source control management). Registered with DCM as part of Service Provider registration.
+
+**Characteristics:**
+- Only applied when the request resource type matches the layer's declared type scope
+- Carry service-specific configuration, defaults, and constraints
+- Must not contain provider-specific data unless marked as portability-breaking
+- Cached in the Service Layer Cache at Service Provider registration time
+
+**Examples:**
+- VM sizing layer (small, medium, large configurations for `Compute.VirtualMachine`)
+- Web server configuration layer for `Compute.VirtualMachine`
+- Network port configuration layer for `Network.Port`
+- CL Web Service Data Layer for `Compute.VirtualMachine` (exact scope)
+- General compute placement layer for `Compute.VirtualMachine` and descendants
+
+---
+
+### 3.5 Request Layer
+
+**Purpose:** Carries the consumer's declared intent. The Request Layer is what the consumer provides — the fields they explicitly specify for their resource request.
+
+**Scope:** Scoped to the Resource Type the consumer is requesting.
+
+**Ownership:** Consumer (via Web UI or Consumer API).
+
+**Characteristics:**
+- Created at the time the consumer submits a request
+- Contains only what the consumer explicitly declares — it does not need to be complete
+- The gap between what the consumer declares and what the provider needs is filled by the lower layers in the chain
+- Has higher precedence than all data layers below it — consumer-declared values override layer defaults
+- Is the direct source of the **Intent State** — the Request Layer as submitted by the consumer is stored in the Intent Store before any processing occurs
+- After assembly and policy processing, the enriched payload becomes the **Requested State**
+
+**Examples:**
+- Consumer requests a VM with `cpu_count: 8`, `ram_gb: 32`, `os: RHEL9`, `environment: production`
+- Consumer requests a firewall rule with source/target network and port
+
+---
+
+### 3.6 Policy Layers
+
+**Purpose:** Policy Layers are not data layers in the traditional sense — they do not add fields to the merge chain. Instead, they operate on the assembled payload after the data layers have been merged. They are the governance layer of the assembly process.
+
+**Scope:** Scoped by policy type and domain. Core Policies apply to all requests. Service Policies apply to specific Resource Types. Organizational and domain policies apply to specific organizational scopes.
+
+**Ownership:** Policy creators, security teams, compliance teams, organizational domain owners.
+
+**Policy Layer Types and Their Behavior:**
+
+| Policy Type | Behavior | Precedence Effect |
+|-------------|----------|-------------------|
+| **Validation** | Checks data against rules. Does not modify data. Returns pass/fail. If fail, request is rejected. | No precedence — pass/fail only |
+| **Transformation** | Enriches or modifies data in the payload. Adds missing fields, applies standards, fills gaps. | Adds to or modifies the assembled payload — recorded in provenance |
+| **GateKeeper** | Highest authority. Can override any field regardless of what was declared in lower layers or the Request Layer. Can halt execution entirely. Used for sovereignty constraints, security mandates, and hard compliance rules. | Overrides everything — including consumer input |
+
+**Characteristics:**
+- Policies operate only on the policy definition, core data, and the data in the request payload
+- Policy outcomes are deterministic — same input always produces same output for a given policy version
+- All policy modifications are recorded in field-level provenance with policy UUID, operation type, and reason
+- Policies are versioned using the universal versioning scheme
+- Policies are maintained via GitOps practices
+
+---
+
+### 3.7 Reference Data Layers
+
+**All of DCM's data — including Resource Type Specifications — is built on the same
+layer model.** A Resource Type Specification is itself a data layer artifact: versioned,
+owned by a declared Resource Type Authority, stored in GitOps, subject to the standard
+lifecycle, and subject to the same domain-based access control as all other layers. The
+only distinction is that Resource Type Specifications live in the Resource Type Registry
+(which is itself a specialized layer store) rather than the Core Layer Store.
+
+This unified model means:
+- The same governance tooling manages resource type definitions, reference data, and
+ service configuration
+- The same lifecycle (developing → proposed → active → deprecated → retired) applies
+ to all three
+- The same ownership declarations, the same GitOps workflow, the same authority tiers
+- Provider extension layers (domain: `provider`) extend resource types for a specific
+ catalog item without modifying the Resource Type Specification itself — they are
+ injected during payload assembly only when that catalog item is selected
+
+**Purpose:** Provide governed, versioned sets of allowed values for use as field
+constraints in Resource Type Specifications and Provider Catalog Items. Reference Data
+Layers are the source of truth for any enumerated choice a consumer makes when
+requesting a resource.
+
+**Scope:** Declared per layer type. A Reference Data Layer of type `os_image` is only
+valid as a constraint source for fields that declare `layer_type: os_image`. Reference
+Data Layers are not injected into the assembled request payload in the same way as other
+layers — they are resolved at catalog render time to produce the `allowed_values` list
+for a field constraint.
+
+**Ownership:** The team or authority responsible for governing that category of data.
+
+| Layer Type | Owning Authority | What it governs |
+|------------|-----------------|-----------------|
+| `location.*` | Data Center Operations | Where resources can be placed |
+| `os_image` | Platform Security / OS Team | Approved OS images and versions |
+| `vm_size` | Platform Team | Approved VM size profiles |
+| `network_zone` | Network Operations | Available network zones and their properties |
+| `environment` | Platform Governance | Deployment environments and their policy sets |
+| `storage_class` | Storage Operations | Available storage tiers |
+| `gpu_profile` | Platform Team | Approved GPU configurations |
+
+**Characteristics:**
+- Same lifecycle as all other layers: `developing → proposed → active → deprecated → retired`
+- Same governance: GitOps workflow, owned by declared authority, approved by designated tier
+- Same versioning: `Major.Minor.Revision` — breaking changes require a major bump
+- Same security: domain-based access control, same policy enforcement
+- **Not merged into the request payload directly** — they are resolved at catalog render time
+ to produce the field constraint `allowed_values` list
+- **Their structured data IS injected** when a consumer selects a value: selecting a
+ location layer injects all location context; selecting an OS image layer injects
+ image UUID, SHA, version, and EOL date into the payload
+
+**Adding a new allowed value** for any layer-referenced field means adding a new
+Reference Data Layer instance of the appropriate type. No changes to the Resource Type
+Specification, the catalog item, or any policy. The new value becomes available to
+all catalog items that reference that layer type on the next sync cycle.
+
+**Retiring an allowed value** means retiring the Reference Data Layer instance.
+Existing resources that used that value are unaffected. Future requests cannot
+select it.
+
+**Example — OS Image layer:**
+
+```yaml
+layer:
+ artifact_metadata:
+ uuid:
+ handle: "platform/os-images/rhel-9-4-approved"
+ version: "1.0.0"
+ status: active
+ owned_by:
+ display_name: "Platform Security Team"
+ group_handle: "groups/platform-security"
+ created_via: pr
+
+ layer_type: reference_data
+ reference_data_type: os_image
+ scope: type_agnostic
+
+ priority:
+ value: "150.01.0"
+ label: "platform.reference.os-image.rhel-9-4"
+ category: platform_reference
+
+ data:
+ image_name: "RHEL 9.4"
+ image_uuid: "img-rhel-9-4-20260315"
+ image_sha256: "a1b2c3d4..."
+ os_family: rhel
+ major_version: 9
+ minor_version: 4
+ release_date: "2026-03-15"
+ eol_date: "2032-05-31"
+ approved_for_classifications: [public, internal, confidential, restricted]
+ cis_benchmark_version: "CIS RHEL 9 Benchmark v1.0"
+ fips_compliant: true
+
+ concern_tags: [os-image, rhel, approved, fips-compliant]
+```
+
+**Example — VM Size layer:**
+
+```yaml
+layer:
+ artifact_metadata:
+ uuid:
+ handle: "platform/vm-sizes/medium-general-purpose"
+ version: "2.1.0"
+ status: active
+ owned_by:
+ display_name: "Platform Team"
+ group_handle: "groups/platform-team"
+ created_via: pr
+
+ layer_type: reference_data
+ reference_data_type: vm_size
+ scope: type_agnostic # applies across providers for Compute.VirtualMachine
+
+ data:
+ size_name: "Medium — General Purpose"
+ size_code: "gp-medium"
+ display_name: "Medium (8 CPU / 32 GB)"
+ cpu_count: 8
+ memory_gb: 32
+ storage_gb: 80
+ network_bandwidth_gbps: 10
+ approved_for_workloads: [web, application, database, batch]
+ cost_tier: standard
+
+ concern_tags: [vm-size, general-purpose, approved]
+```
+
+---
+
+
+## 4. Layer Identity — Domain, Handle, and Priority
+
+Every layer has a formal identity model with three components that together make it uniquely identifiable, locatable, and orderable within DCM.
+
+### 4.1 Layer Domain
+
+The **Layer Domain** mirrors the Policy domain model exactly. It declares ownership, storage location, and authorization scope. The same domain hierarchy, the same authority model, the same override precedence.
+
+| Domain | Meaning | Authorization | Can Override |
+|--------|---------|--------------|-------------|
+| `system` | DCM built-in layers — ship with DCM | DCM maintainers only | Nothing above system |
+| `platform` | Platform team layers — apply across all Tenants | Platform team | tenant, service, provider |
+| `tenant` | Tenant-specific layers — scoped to one Tenant | Tenant Admin | service, provider within Tenant |
+| `service` | Service Provider contributed layers | Service Provider owner | provider |
+| `provider` | Provider Catalog Item layers | Provider owner | Nothing above provider |
+| `request` | Consumer-declared values in the request itself | Consumer | Nothing above request — lowest authority |
+
+A lower-domain layer cannot override a higher-domain layer.
+
+**Provider extension layers** (`domain: provider`) are contributed by Service Providers
+as part of their catalog item registration. They add provider-specific fields to the
+assembled payload for their offering only. They cannot override platform or tenant layers.
+They carry the same portability implications as inline `provider_specific_extensions` in
+the catalog item declaration — any request using them is non-portable and must be
+explicitly marked. See [Resource Type Hierarchy](05-resource-type-hierarchy.md) Section 6.2
+for the catalog item `provider_extension_layer_handles` declaration. A `tenant` layer cannot override a `platform` layer. This is enforced at ingestion — the conflict detection pipeline checks domain authority before allowing a merge.
+
+**Domain mirrors policy authority:** Just as system-domain policies have highest authority in the Policy Engine, system-domain layers have highest authority in the assembly process. The same mental model applies to both.
+
+### 4.2 Layer Groups — DCMGroup with group_class: layer_grouping
+
+Just as Policy Groups organize policies into cohesive concern-based collections, **Layer Groups** organize layers. A Layer Group is a `DCMGroup` with `group_class: layer_grouping` — a versioned, audited, GitOps-managed collection of related layers.
+
+Layer Groups enable:
+- **Discovery** — "show me all layers related to PCI compliance"
+- **Composition** — include a group in a profile rather than listing individual layers
+- **Governance** — activate or deactivate a concern's worth of layers in one operation
+
+```yaml
+# A Layer Group — DCMGroup with group_class: layer_grouping
+dcm_group:
+ artifact_metadata:
+ uuid:
+ handle: "platform/layer-groups/pci-network-standards"
+ version: "1.0.0"
+ status: active
+ group_class: layer_grouping
+ concern_tags: [pci-dss, networking, standards]
+ members:
+ - member_uuid:
+ member_type: layer
+ member_role: network_segmentation_defaults
+ - member_uuid:
+ member_type: layer
+ member_role: firewall_baseline
+ - member_uuid:
+ member_type: layer
+ member_role: tls_minimum_version
+```
+
+### 4.3 The Full Layer Structure
+
+Every layer carries: identity, domain and authority, compatibility metadata, per-field override metadata, and usage context. This mirrors the richness of a Policy registration.
+
+```yaml
+layer:
+ artifact_metadata:
+ uuid:
+ handle: "platform/core/default-dns-config"
+ version: "1.2.0"
+ status: active
+ owned_by:
+ display_name: "Platform Infrastructure Team"
+ notification_endpoint:
+ created_via: pr # pr | api | migration | system
+
+ # DOMAIN AND AUTHORITY
+ domain: platform
+ priority:
+ value: "500.20.0"
+ label: "platform.networking.dns"
+ category: platform
+ rationale: "Platform DNS infrastructure — primary and secondary resolvers"
+
+ # CONCERN TAGS — for discoverability and grouping
+ concern_tags: [networking, dns, platform-defaults]
+
+ # COMPATIBILITY METADATA — what this layer applies to
+ compatibility:
+ resource_types: [Compute.VirtualMachine, Compute.Container]
+ resource_type_versions: "^1.0.0"
+ provider_types: [] # empty = all providers
+ profile_constraints: [] # empty = all profiles; or: [standard, prod, fsi]
+ domains_applicable: [platform, tenant, service, provider] # which domains may use this
+
+ # CONDITIONAL INCLUSION (Q23) — activation condition
+ activation_condition:
+ # Layer only included if this condition evaluates true during Step 2 (Layer Resolution)
+ field: tenant.tags
+ operator: not_contains # equals|not_equals|exists|not_exists|contains|in|not_in
+ value: custom-dns
+ # Compound conditions:
+ # conditions:
+ # operator: and # and | or
+ # rules:
+ # - field: request.gpu_requested
+ # operator: equals
+ # value: true
+ # - field: ingress.actor.roles
+ # operator: contains
+ # value: developer
+
+ # FIELDS — with per-field override metadata
+ fields:
+ dns_servers:
+ value: [10.0.0.53, 10.0.0.54]
+ metadata:
+ override: allow # allow | constrained | immutable
+ basis_for_value: "Platform DNS infrastructure — primary and secondary"
+ provenance_note: "Set by platform infrastructure team per INFRA-2024-089"
+ dns_search_domain:
+ value: corp.example.com
+ metadata:
+ override: immutable # lower layers cannot override this field
+ locked_by_policy_uuid:
+ basis_for_value: "Corporate domain — cannot be customized per SECURITY-2024-034"
+
+ # USAGE CONTEXT — human documentation embedded in the artifact
+ usage:
+ description: "Default DNS configuration for all platform VMs and containers"
+ applies_when: "All requests unless consumer declares layer exclusion or tenant has custom-dns tag"
+ excludes_when: "Tenant has custom_dns tag; consumer declares explicit layer exclusion"
+ supersedes: [] # handles of layers this replaces
+ conflicts_with: [] # handles of layers this conflicts with — detected at ingestion
+
+ # SOURCE OF TRUTH
+ scm_location:
+ repository: https://git.corp.example.com/dcm-layers
+ path: platform/core/default-dns-config/v1.2.0.yaml
+ commit:
+```
+
+### 4.4 Layer Handle
+
+The **Layer Handle** is the human-readable, stable identifier for a layer within DCM.
+
+**Format:** `{domain}/{concern_or_type}/{name}`
+
+**Examples:**
+```
+platform/core/cis-benchmark-linux
+platform/core/security-cpu-limits
+tenant/service/payments-vm-standards
+system/base/universal-defaults
+service/service/kubevirt-vm-defaults
+provider/service/cloudnativepg-database-config
+```
+
+**Git path from handle:**
+```
+{layer_store_root}/{domain}/{concern_or_type}/{name}/v{Major}.{Minor}.{Revision}.yaml
+
+# Example:
+dcm-layers/platform/core/security-cpu-limits/v1.2.0.yaml
+dcm-layers/tenant/{tenant-uuid}/service/payments-vm-standards/v1.0.0.yaml
+```
+
+### 4.5 Priority Schema
+
+The **Priority Schema** is the deterministic ordering mechanism for resolving conflicts between layers of the same type and scope.
+
+**Format:** `{integer}.{integer}.{integer}...` — unlimited depth
+
+**Comparison:** Left-to-right, segment by segment. **Higher numeric value = higher priority** (higher value = higher priority). No ceiling — you can always go higher.
+
+```
+900.10 beats 800.10 (900 > 800 at segment 1)
+900.20 beats 900.10 (20 > 10 at segment 2)
+900.10.5 beats 900.10 (longer path with matching prefix)
+900.10.10 beats 900.10.5 (10 > 5 at segment 3)
+```
+
+**Reference Priority Taxonomy (advisory — not enforced by DCM):**
+
+| Suggested Range | Category | Rationale |
+|-----------------|----------|-----------|
+| `900.*` | Compliance | Regulatory mandates — highest authority |
+| `800.*` | Security | Security standards |
+| `700.*` | Sovereignty | Data residency constraints |
+| `600.*` | Operations | SRE and operational standards |
+| `500.*` | Platform | Platform-level defaults |
+| `400.*` | Service | Service-specific configuration |
+| `300.*` | Organization | Organizational defaults |
+| `200.*` | Site | Location-specific overrides |
+| `100.*` | Custom | Implementor-defined — lowest standard category |
+
+Higher number = higher priority. Organizations adopt, adapt, or ignore this taxonomy — DCM resolves conflicts purely by numeric comparison.
+
+---
+
+## 4b. Artifact Metadata Standard
+
+Every DCM artifact — layers, policies, resource types, catalog items, provider registrations, entity definitions, and all other defined or stored objects — carries a standard **Artifact Metadata** block. This is a structural requirement, not optional.
+
+The artifact metadata block answers: **who created this, when, who owns it, what changed, and how do we contact them?**
+
+### 4b.1 Universal Artifact Metadata Structure
+
+```yaml
+artifact_metadata:
+
+ # Identity
+ uuid:
+ handle:
+
+ # Versioning
+ version:
+ status:
+
+ # Status detail — populated per status
+ status_detail:
+ # When status: proposed
+ proposed_at:
+ proposed_by:
+ uuid:
+ display_name:
+ email:
+ shadow_execution:
+ enabled:
+ started_at:
+ evaluation_count:
+ validation_dashboard_url:
+
+ # When status: deprecated
+ deprecated_at:
+ deprecated_by:
+ uuid:
+ display_name:
+ replacement_uuid:
+ replacement_handle:
+ deprecation_reason:
+ migration_guidance:
+ sunset_date:
+
+ # When status: retired
+ retired_at:
+ retired_by:
+ uuid:
+ display_name:
+
+ # Origination
+ created_by:
+ uuid:
+ display_name:
+ email:
+ notification_endpoint:
+ created_at:
+ created_via:
+ # pr: submitted via GitOps PR workflow — full review history available
+ # api: submitted via direct API
+ # migration: imported from external system — provenance depth may be limited
+ # system: created by DCM itself (entity stubs, system artifacts)
+
+ # Ownership — may differ from creator
+ owned_by:
+ uuid:
+ display_name:
+ email:
+ notification_endpoint:
+ # Note: created_by is the audit record (who physically submitted it)
+ # owned_by is the accountability record (who is responsible and gets notified)
+
+ # Modification history — append-only
+ modifications:
+ - sequence: 1
+ modified_by:
+ uuid: