From 93af6089a370b2105294fd55bbdb0b23bf9578dc Mon Sep 17 00:00:00 2001 From: Chris Roadfeldt Date: Tue, 16 Jun 2026 16:26:47 -0500 Subject: [PATCH 1/2] dav: import the DCM validation corpus Adds the DAV validation corpus (dav/) -- the use-case set DCM is validated against -- so the spec ships with its conformance dogfood. Single-concern; independent of the UDLM/DCM split. Signed-off-by: Chris Roadfeldt --- dav/CHANGELOG.md | 110 +++++++++++ dav/README.md | 136 +++++++++++++ dav/schemas/use_case.schema.json | 180 ++++++++++++++++++ .../vm-provision-with-provider-failure.yaml | 67 +++++++ .../compute/vm-standard-provision.yaml | 52 +++++ ...nsible-inventory-brownfield-ingestion.yaml | 83 ++++++++ .../sovereign-decommission-with-peer.yaml | 57 ++++++ .../cross-domain/tenant-onboarding.yaml | 67 +++++++ .../data/persistent-volume-provision.yaml | 58 ++++++ .../audit-merkle-tree-verification.yaml | 63 ++++++ ...minimal-profile-policy-scope-boundary.yaml | 83 ++++++++ .../governance/policy-override-approval.yaml | 62 ++++++ .../auth-provider-drift-detection.yaml | 53 ++++++ .../udlm-universal-telemetry-export.yaml | 80 ++++++++ 14 files changed, 1151 insertions(+) create mode 100644 dav/CHANGELOG.md create mode 100644 dav/README.md create mode 100644 dav/schemas/use_case.schema.json create mode 100644 dav/use-cases/compute/vm-provision-with-provider-failure.yaml create mode 100644 dav/use-cases/compute/vm-standard-provision.yaml create mode 100644 dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml create mode 100644 dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml create mode 100644 dav/use-cases/cross-domain/tenant-onboarding.yaml create mode 100644 dav/use-cases/data/persistent-volume-provision.yaml create mode 100644 dav/use-cases/governance/audit-merkle-tree-verification.yaml create mode 100644 dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml create mode 100644 dav/use-cases/governance/policy-override-approval.yaml create mode 100644 dav/use-cases/identity/auth-provider-drift-detection.yaml create mode 100644 dav/use-cases/observability/udlm-universal-telemetry-export.yaml diff --git a/dav/CHANGELOG.md b/dav/CHANGELOG.md new file mode 100644 index 0000000..cdb8c2b --- /dev/null +++ b/dav/CHANGELOG.md @@ -0,0 +1,110 @@ +# DCM Validation Corpus — Changelog + +## 2026-04-26 — Migration into the DCM repo + +Moved from `croadfeldt/dcm-self-test-corpus` to `croadfeldt/dcm/dav/` +following ADR-001 (DAV as standalone consumer-agnostic framework, DCM +as its first consumer). + +Path renames: +- `use_cases/` → `use-cases/` (hyphen, matching DCM convention) +- `use_cases/cross_domain/` → `use-cases/cross-domain/` +- `schema/` → `schemas/` (plural, matching DCM convention) + +Internal updates: +- All cross-domain UC `handle:` fields rewritten from `cross_domain/x` + to `cross-domain/x` to match the new directory layout. +- `analysis.schema.json` moved to the DAV repo (`engine/src/dav/schemas/`) + since it describes DAV output, not corpus content. +- `dav-version.yaml` removed; provenance now tracked via `git rev-parse + HEAD` of the DCM repo itself. + +The dimension vocabulary value `policy_complexity: cross_domain_constraint` +intentionally retains its underscore form — it's a controlled vocabulary +term, not a path. + +Vocabulary rename (same date): the dimension value +`resource_complexity: compound_service` was renamed to +`composite_service` to match the architecture's adoption of "Composite +Service" as the canonical catalog-level term (Meta Provider was retired +as a provider type; what was previously called a compound service is +now a Composite Service registered by an ordinary Service Provider). +The UC `cross-domain/tenant-onboarding.yaml` was updated to use the new +value. Historical entries below mentioning `compound_service` describe +the value as it was when those entries were written — the actual +vocabulary value in use today is `composite_service`. + + +## Unreleased + +### Added + +- Six additional hand-authored use cases expanding Phase 1a coverage + across new domains, profiles, and failure shapes: + - `data/persistent-volume-provision` (uc-seed-004a, dev profile) — + happy-path storage provisioning; introduces the `data` domain. + - `governance/policy-override-approval` (uc-seed-005a, prod profile) + — soft-policy override workflow with human-in-loop approval; + exercises the override_requests machinery. + - `compute/vm-provision-with-provider-failure` (uc-seed-006a, + standard profile) — recovery policy path when a service provider + becomes unreachable mid-realization; first use of the + `recovery_policy` dimension value. + - `governance/audit-merkle-tree-verification` (uc-seed-007a, sovereign + profile) — cryptographic verification of historical audit events + via Merkle inclusion and consistency proofs with sovereignty-scoped + key material. + - `cross-domain/tenant-onboarding` (uc-seed-008a, fsi profile) — + atomic onboarding of a new FSI tenant across identity, policy, + data, and provider domains; first use of `compound_service` and + `compliance_gated` in the corpus. + - `governance/minimal-profile-policy-scope-boundary` (uc-seed-009a, + minimal profile) — negative architectural claim: FSI-scoped + policies (data-residency, dual-approval, encryption-at-rest-mandatory) + must NOT evaluate against minimal-profile requests. Exercises + the profile inheritance boundary at the bottom of the profile + chain. + +- Two new domain directories: `use-cases/data/` and `use-cases/governance/`. + +- Profile coverage expanded: `dev`, `fsi`, and `minimal` now represented + (previously only `standard`, `prod`, `sovereign`). + +- Controlled-vocabulary cell coverage expanded: + - `lifecycle_phase`: adds `modification` (override and audit-verification + flows). + - `resource_complexity`: adds `compound_service` (tenant onboarding). + - `policy_complexity`: adds `recovery_policy`, `system_defaults_only`. + - `provider_landscape`: adds `multiple_eligible`, `mixed`. + - `governance_context`: adds `audit_heavy`, `compliance_gated`, + `no_governance`. + - `failure_mode`: adds `provider_failure`. + +### Initial seed (previously released) + +- Initial seed with 3 hand-authored use cases covering foundational + scenarios across three domains: + - `compute/vm-standard-provision` — happy-path VM creation in the + standard profile. Foundational baseline. + - `cross-domain/sovereign-decommission-with-peer` — edge case + exercising peer_dcm coordination during sovereign-profile + decommission with peer disconnection failure mode. + - `identity/auth-provider-drift-detection` — drift detection + between DCM's identity cache and the authoritative IdP, with + human-escalation policy path. + +- Schema definitions (`schema/use_case.schema.json`, + `schema/analysis.schema.json`) matching DCM self-test engine + v1.0 canonical schemas. + +- Governance documentation: contribution workflow, review criteria, + retirement policy, controlled-vocabulary reference. + +### Notes + +- No baselines yet. Baselines will be generated when the stage 2 + engine first runs these cases against the current DCM spec. +- Repository currently at `croadfeldt/dcm-self-test-corpus` during + the validation phase. Migration to `dcm-project/dcm-self-test-corpus` + is planned once the process has accumulated ~25 validated cases + and demonstrated its value through a full PR cycle. diff --git a/dav/README.md b/dav/README.md new file mode 100644 index 0000000..79055d7 --- /dev/null +++ b/dav/README.md @@ -0,0 +1,136 @@ +# DCM Validation Corpus + +The curated body of use cases that define what the DCM (Data Center +Management) architecture is contractually required to support. This +corpus is consumed by [DAV](https://github.com/croadfeldt/dav) (DCM +Architecture Validation), which runs each use case through an LLM- +driven analysis to verify the architecture supports the scenario. + +## What lives here + +``` +dav/ +├── README.md (this file) +├── CHANGELOG.md (corpus evolution) +├── schemas/ +│ └── use_case.schema.json (UC YAML structure) +└── use-cases/ + ├── compute/ (VMs, bare metal, containers) + ├── cross-domain/ (scenarios crossing 2+ domains) + ├── data/ (data services, storage) + ├── governance/ (policy, compliance, audit) + └── identity/ (authn/authz, IdP integration) +``` + +The DAV analysis output schema (`analysis.schema.json`) lives in the +DAV repo at `engine/src/dav/schemas/`, since it describes DAV's output +format rather than corpus content. + +## Use case format + +Every use case is a YAML file conforming to `schemas/use_case.schema.json`. + +Filename convention: `.yaml` — a use case with +handle `compute/vm-standard-provision` lives at +`use-cases/compute/vm-standard-provision.yaml`. The handle's first +segment is the domain (matching the directory); the second segment +matches the filename. + +UUID convention: `uc-` generated at creation time; stable for the +life of the use case. + +## How DAV consumes this + +DAV's Tekton pipeline clones the DCM repo and walks `dav/use-cases/**` +loading every YAML it finds. A typical PipelineRun parameterizes: + +``` +--param consumer-spec-repo-url=https://github.com/croadfeldt/dcm.git +--param consumer-corpus-repo-url=https://github.com/croadfeldt/dcm.git +--param corpus-uc-subpath=dav/use-cases +``` + +(spec and corpus point at the same repo; the corpus subpath is the +new location.) + +For full DAV usage see the DAV README. + +## Contribution workflow + +Use cases enter the corpus via: + +1. **Direct hand authoring.** Open a PR adding a new YAML under the + appropriate domain. CI (eventually) runs DAV's stage 2 against the + new case and the architect spot-checks the result. +2. **Promotion from a DAV exploration run.** An architect reviews a + generated case in DAV's Review Console and clicks "promote to + corpus," which opens a PR against this directory with the YAML + pre-filled. + +## Review criteria for corpus admission + +A use case gets merged when: + +- ✅ Schema-valid against `schemas/use_case.schema.json` +- ✅ Dimensions are internally consistent (not contradictory) +- ✅ Scenario is concrete enough that DAV's analysis can engage with it +- ✅ Success criteria are testable (or at least observable in the spec) +- ✅ Tags are useful for filtering (domain, complexity, edge flags) +- ✅ Not a near-duplicate of an existing case +- ✅ Initial DAV run produces a verdict an architect agrees with + +## Retirement + +A use case can be retired only via a PR with explicit rationale: + +- The architecture has genuinely moved past supporting it (NOT "we + broke it and didn't fix the spec to match") +- It was superseded by a more precise or comprehensive case +- It was admitted in error (e.g., duplicates an existing case) + +Retirement moves the YAML to `retired//` rather than deleting it, +preserving the historical record. + +## Controlled vocabularies + +Dimension values are constrained. Valid values as of schema v1.0: + +- **profile**: `minimal | dev | standard | prod | fsi | sovereign` +- **lifecycle_phase**: `new_request | modification | decommission | + drift_detection | brownfield_ingestion | rehydration_faithful | + rehydration_provider_portable | rehydration_historical_exact | + rehydration_historical_portable | expiry_enforcement` +- **resource_complexity**: `single_no_deps | hard_dependencies | + composite_service | conditional_soft_deps | process_resource | + cross_dependency_payload` +- **policy_complexity**: `system_defaults_only | single_gatekeeper | + multi_policy_chain | conflicting_policies | orchestration_flow_static | + dynamic_conditional_flow | cross_domain_constraint | + human_escalation_required | governance_matrix_enforcement | + recovery_policy` +- **provider_landscape**: `single_eligible | multiple_eligible | + none_eligible | peer_dcm_required | process_provider | mixed` +- **governance_context**: `no_governance | standard_governance | + audit_heavy | compliance_gated | sovereignty_enforced` +- **failure_mode**: `happy_path | provider_failure | policy_violation | + peer_dcm_disconnect | data_inconsistency | rollback_required | + partial_fulfillment | timeout | resource_exhaustion` + +Note: `policy_complexity: cross_domain_constraint` is a vocabulary term +and intentionally retains the underscore form. Directory names use +hyphens (`cross-domain/`); the dimension value does not. + +These vocabularies evolve alongside DCM itself. Additions require a +schema bump and updates to DAV's `core/consumer_profile.py`. + +## License + +Apache 2.0 (matches the DCM project). + +## History + +This corpus previously lived at `croadfeldt/dcm-self-test-corpus`. It +moved to its current location in the DCM repo following ADR-001, which +made DAV a standalone consumer-agnostic framework with DCM as its first +consumer. The old corpus repo is archived; PR history through that +move is preserved there. diff --git a/dav/schemas/use_case.schema.json b/dav/schemas/use_case.schema.json new file mode 100644 index 0000000..9c9db6d --- /dev/null +++ b/dav/schemas/use_case.schema.json @@ -0,0 +1,180 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "title": "DCM Use Case", + "type": "object", + "required": [ + "uuid", + "handle", + "version", + "scenario", + "generated_by" + ], + "properties": { + "uuid": { + "type": "string", + "pattern": "^uc-" + }, + "handle": { + "type": "string", + "pattern": ".*/.*" + }, + "version": { + "type": "string" + }, + "tags": { + "type": "array", + "items": { + "type": "string" + } + }, + "scenario": { + "type": "object", + "required": [ + "description", + "actor", + "intent", + "success_criteria", + "dimensions", + "profile" + ], + "properties": { + "description": { + "type": "string" + }, + "actor": { + "type": "object", + "required": [ + "persona", + "profile" + ], + "properties": { + "persona": { + "type": "string" + }, + "profile": { + "enum": [ + "minimal", + "dev", + "standard", + "prod", + "fsi", + "sovereign" + ] + } + } + }, + "intent": { + "type": "string" + }, + "success_criteria": { + "type": "array", + "items": { + "type": "string" + }, + "minItems": 1 + }, + "dimensions": { + "type": "object", + "required": [ + "lifecycle_phase", + "resource_complexity", + "policy_complexity", + "provider_landscape", + "governance_context", + "failure_mode" + ], + "properties": { + "lifecycle_phase": { + "type": "string" + }, + "resource_complexity": { + "type": "string" + }, + "policy_complexity": { + "type": "string" + }, + "provider_landscape": { + "type": "string" + }, + "governance_context": { + "type": "string" + }, + "failure_mode": { + "type": "string" + } + } + }, + "profile": { + "enum": [ + "minimal", + "dev", + "standard", + "prod", + "fsi", + "sovereign" + ] + }, + "expected_domain_interactions": { + "type": "array", + "items": { + "type": "object", + "required": [ + "domain", + "interaction" + ], + "properties": { + "domain": { + "type": "string" + }, + "interaction": { + "type": "string" + } + } + } + } + } + }, + "generated_by": { + "type": "object", + "required": [ + "mode", + "source" + ], + "properties": { + "mode": { + "enum": [ + "regression", + "pr-targeted", + "authoring" + ] + }, + "source": { + "enum": [ + "corpus", + "llm-unguided", + "llm-guided", + "human-authored" + ] + }, + "model": { + "type": [ + "string", + "null" + ] + }, + "prompt_version": { + "type": [ + "string", + "null" + ] + }, + "timestamp": { + "type": "string" + } + } + }, + "metadata": { + "type": "object" + } + } +} \ No newline at end of file diff --git a/dav/use-cases/compute/vm-provision-with-provider-failure.yaml b/dav/use-cases/compute/vm-provision-with-provider-failure.yaml new file mode 100644 index 0000000..edc4059 --- /dev/null +++ b/dav/use-cases/compute/vm-provision-with-provider-failure.yaml @@ -0,0 +1,67 @@ +uuid: uc-seed-006a +handle: compute/vm-provision-with-provider-failure +scenario: + description: An application team submits a VM provisioning request. The policy + checks pass and the service provider accepts the dispatch, but partway through + realization the provider becomes unreachable. The recovery policy must classify + the partial-realization state, decide whether to requeue against another eligible + provider, hold the request pending provider recovery, or fail the request and + release any partially-allocated resources. The tenant must not be left with + orphaned partially-provisioned state. + actor: + persona: application-team-member + profile: standard + intent: Provision a VM under conditions where the primary service provider fails + mid-realization + success_criteria: + - Provider unreachability is detected within the dispatch timeout, not indefinitely + pending + - Partially-allocated resources are either reconciled to a completed state or cleanly + released + - Recovery policy decision is explicit and audit-recorded (requeue / hold / fail) + - If another eligible provider exists and policy permits, the request is requeued + automatically + - The tenant's requested state never shows a resource in an indeterminate state + without a matching recovery record + dimensions: + lifecycle_phase: new_request + resource_complexity: single_no_deps + policy_complexity: recovery_policy + provider_landscape: multiple_eligible + governance_context: standard_governance + failure_mode: provider_failure + profile: standard + expected_domain_interactions: + - domain: provider + interaction: service provider accepts dispatch then becomes unreachable mid-realization + - domain: policy + interaction: recovery policy classifies partial-realization state and selects + action + - domain: provider + interaction: if policy selects requeue, alternate eligible provider is dispatched + - domain: data + interaction: partial-realization state tracked, reconciled or released per recovery + decision + - domain: audit + interaction: failure detection, recovery decision, and final outcome recorded + with provider identities +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-23T04:45:00.000000+00:00' +tags: +- compute +- vm +- failure-mode +- recovery-policy +- standard-profile +- provider-unreachable +version: 1.0.0 +metadata: + admitted_at: '2026-04-23T04:45:00.000000+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/compute/vm-standard-provision.yaml b/dav/use-cases/compute/vm-standard-provision.yaml new file mode 100644 index 0000000..e0bce0f --- /dev/null +++ b/dav/use-cases/compute/vm-standard-provision.yaml @@ -0,0 +1,52 @@ +uuid: uc-seed-001a +handle: compute/vm-standard-provision +scenario: + description: An application team requests a new virtual machine with standard multi-tenant + isolation. The platform must enforce tenancy at the data plane, run the appropriate + policy checks before allocation, and produce an auditable record of the provisioning. + actor: + persona: application-team-member + profile: standard + intent: Provision a new VM in the standard profile, scoped to the team's tenant + success_criteria: + - VM is created and reachable from within the tenant boundary + - Tenant isolation policy is applied to network and storage attachments + - Provisioning is recorded in the audit trail with actor, intent, and outcome + - "The request is idempotent \u2014 repeating it does not create duplicate VMs" + dimensions: + lifecycle_phase: new_request + resource_complexity: single_no_deps + policy_complexity: single_gatekeeper + provider_landscape: single_eligible + governance_context: standard_governance + failure_mode: happy_path + profile: standard + expected_domain_interactions: + - domain: policy + interaction: tenant-isolation gatekeeper evaluates request + - domain: provider + interaction: service provider allocates VM resource + - domain: data + interaction: resource record created with tenancy fields + - domain: audit + interaction: provisioning event recorded +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-20T18:41:39.738396+00:00' +tags: +- compute +- vm +- happy-path +- standard-profile +- single-provider +- foundational +version: 1.0.0 +metadata: + admitted_at: '2026-04-20T18:41:39.738428+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml b/dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml new file mode 100644 index 0000000..7465af1 --- /dev/null +++ b/dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml @@ -0,0 +1,83 @@ +uuid: uc-seed-bfi-001 +handle: cross-domain/ansible-inventory-brownfield-ingestion +scenario: + description: An operations team manages an existing estate (bare metal, VMs, + hypervisors, appliances, network gear) through configuration-management + inventory (e.g. Ansible) - hosts, groups, per-host variables, and embedded + credentials. They migrate management to DCM by ingesting that inventory as + brownfield entities WITHOUT recreating or moving any running resource. + Inventory groups become DCMGroups; host definitions become resource + entities with their attributes; embedded plaintext credentials become + vault-backed credential resources; and telemetry collection is + auto-established for every ingested entity per the provider contract + observability obligation. The inventory remains authoritative during a + coexistence window - ingestion is additive and reversible until cutover. + actor: + persona: platform-operator + profile: standard + intent: Adopt an existing configuration-management inventory into DCM as + first-class entities, groups, and credentials - in place, with zero + resource recreation and no management gap during transition + success_criteria: + - Every inventory host is ingested as a resource entity with its attributes + (vars) preserved and its provenance recorded as brownfield + - Inventory groups (including nested groups) map to DCMGroups with + membership preserved, so group-scoped policy and observability apply + immediately (OBS-008) + - Resources are ADOPTED in place - no resource is recreated, restarted, or + migrated as a side effect of ingestion (adopt-not-recreate) + - Embedded plaintext credentials are detected, converted to vault-backed + credential resources, and flagged for rotation; no plaintext credential + survives ingestion into entity definitions + - Telemetry collection is established for every ingested entity per the + provider-contract observability obligation (PRV-007) without per-entity + manual configuration + - During coexistence, changes made via the legacy inventory are detected as + drift against the ingested entities rather than silently diverging + - Ingestion is reversible before cutover - removing DCM management leaves + the estate exactly as found + dimensions: + lifecycle_phase: brownfield_ingestion + resource_complexity: cross_dependency_payload + policy_complexity: multi_policy_chain + provider_landscape: mixed + governance_context: standard_governance + failure_mode: happy_path + profile: standard + expected_domain_interactions: + - domain: data + interaction: inventory hosts/groups/vars ingested as entities, DCMGroups, + and attributes with brownfield provenance + - domain: provider + interaction: configuration-management system acts as an information + provider for discovery; credential conversion via credential resources + - domain: policy + interaction: ingestion scope, credential-handling, and coexistence drift + rules policy-evaluated + - domain: audit + interaction: every adopted entity, group mapping, and credential + conversion recorded with before/after provenance +generated_by: + mode: authoring + source: ai-assisted + model: claude-opus-4-8 + prompt_version: seed-1.0 + timestamp: '2026-06-07T21:30:00.000000+00:00' +tags: +- brownfield +- ingestion +- ansible +- inventory +- migration +- dcmgroup +- credentials +- adopt-in-place +- coexistence +- standard-profile +version: 1.0.0 +metadata: + admitted_at: '2026-06-07T21:30:00.000000+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml b/dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml new file mode 100644 index 0000000..682c89b --- /dev/null +++ b/dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml @@ -0,0 +1,57 @@ +uuid: uc-seed-002a +handle: cross-domain/sovereign-decommission-with-peer +scenario: + description: A sovereign-profile tenant initiates decommissioning of a resource + that has been replicated to a peer DCM instance for disaster-recovery compliance. + The decommission must coordinate with the peer to ensure both replicas are released + and the audit trail is consistent across both DCM instances. + actor: + persona: sovereign-tenant-admin + profile: sovereign + intent: Decommission a resource such that both the local and the peer replica are + released + success_criteria: + - Local replica is released only after peer acknowledges the decommission + - If the peer is unreachable, the decommission is held in a pending state, not silently + completed + - Final audit record includes the peer acknowledgement evidence + - Sovereign data-residency constraints are not violated during the wind-down + dimensions: + lifecycle_phase: decommission + resource_complexity: hard_dependencies + policy_complexity: cross_domain_constraint + provider_landscape: peer_dcm_required + governance_context: sovereignty_enforced + failure_mode: peer_dcm_disconnect + profile: sovereign + expected_domain_interactions: + - domain: policy + interaction: sovereignty policy evaluates residency at decommission + - domain: provider + interaction: peer_dcm provider coordinates with remote DCM + - domain: provider + interaction: service provider releases local resource + - domain: data + interaction: resource record marked released with peer-ack metadata + - domain: audit + interaction: cross-DCM audit record stitched together +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-20T18:41:39.741639+00:00' +tags: +- cross-domain +- decommission +- sovereign +- peer-dcm +- edge-case +- failure-mode +version: 1.0.0 +metadata: + admitted_at: '2026-04-20T18:41:39.741660+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/cross-domain/tenant-onboarding.yaml b/dav/use-cases/cross-domain/tenant-onboarding.yaml new file mode 100644 index 0000000..25c1e69 --- /dev/null +++ b/dav/use-cases/cross-domain/tenant-onboarding.yaml @@ -0,0 +1,67 @@ +uuid: uc-seed-008a +handle: cross-domain/tenant-onboarding +scenario: + description: A platform engineer onboards a new tenant into the FSI-profile DCM + deployment. Onboarding must provision the tenant identity boundary, bind the + appropriate policy profile and compliance domain overlays, establish storage + and compute quota allocations, configure auth provider claims mapping, and + produce a single atomic onboarding record such that either all steps complete + or none persist. The new tenant must be immediately governed by FSI policies + before any resource is requestable under its name. + actor: + persona: platform-engineer + profile: fsi + intent: Onboard a new tenant as an atomic operation with full policy and quota + binding before the tenant can request any resources + success_criteria: + - Tenant identity boundary is created and linked to the FSI profile + - Compliance domain overlays appropriate to the tenant's declared regulatory scope + are bound to the tenant + - Storage and compute quotas are allocated with the requested ceilings + - Auth provider claims mapping is configured to resolve tenant membership + - Partial-completion of onboarding is not observable to downstream consumers; either + the tenant is fully governed or the partial state is rolled back + - FSI policy enforcement is active on the tenant before its first resource request + is accepted + dimensions: + lifecycle_phase: new_request + resource_complexity: composite_service + policy_complexity: cross_domain_constraint + provider_landscape: mixed + governance_context: compliance_gated + failure_mode: happy_path + profile: fsi + expected_domain_interactions: + - domain: data + interaction: tenant identity boundary entity created with profile binding + - domain: policy + interaction: FSI profile policies and compliance overlays bound to tenant + - domain: data + interaction: storage and compute quota allocations recorded against tenant + - domain: provider + interaction: auth provider configured with tenant claims mapping + - domain: policy + interaction: onboarding atomicity enforced by orchestration flow policy + - domain: audit + interaction: single onboarding record stitches all sub-operations together +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-23T04:45:00.000000+00:00' +tags: +- cross-domain +- tenant +- onboarding +- fsi-profile +- atomic-composition +- identity-policy-data +- compound-service +version: 1.0.0 +metadata: + admitted_at: '2026-04-23T04:45:00.000000+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/data/persistent-volume-provision.yaml b/dav/use-cases/data/persistent-volume-provision.yaml new file mode 100644 index 0000000..a8deba4 --- /dev/null +++ b/dav/use-cases/data/persistent-volume-provision.yaml @@ -0,0 +1,58 @@ +uuid: uc-seed-004a +handle: data/persistent-volume-provision +scenario: + description: A development team requests a new persistent block volume attached + to an existing VM in their tenant. The storage provider must allocate the volume + from the tenant's eligible storage class, enforce tenancy at the storage plane, + respect any data-residency constraints, and produce an auditable record including + capacity consumed against tenant quota. + actor: + persona: application-team-member + profile: dev + intent: Provision a persistent block volume and attach it to an existing VM in + the tenant + success_criteria: + - Volume is created in a storage class the tenant is authorized to consume + - Volume is attached to the target VM without cross-tenant exposure + - Tenant quota is updated to reflect the new consumption + - Provisioning and attachment are recorded in the audit trail + dimensions: + lifecycle_phase: new_request + resource_complexity: cross_dependency_payload + policy_complexity: single_gatekeeper + provider_landscape: single_eligible + governance_context: standard_governance + failure_mode: happy_path + profile: dev + expected_domain_interactions: + - domain: policy + interaction: tenant-isolation gatekeeper evaluates volume request against tenant's + storage class eligibility + - domain: provider + interaction: storage provider allocates block volume in eligible class + - domain: provider + interaction: service provider attaches volume to target VM + - domain: data + interaction: volume record created with tenancy and VM reference, quota incremented + - domain: audit + interaction: provisioning and attachment recorded with actor, intent, outcome +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-23T04:45:00.000000+00:00' +tags: +- data +- storage +- volume +- happy-path +- dev-profile +- cross-resource-dependency +version: 1.0.0 +metadata: + admitted_at: '2026-04-23T04:45:00.000000+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/governance/audit-merkle-tree-verification.yaml b/dav/use-cases/governance/audit-merkle-tree-verification.yaml new file mode 100644 index 0000000..6dc3c8d --- /dev/null +++ b/dav/use-cases/governance/audit-merkle-tree-verification.yaml @@ -0,0 +1,63 @@ +uuid: uc-seed-007a +handle: governance/audit-merkle-tree-verification +scenario: + description: A compliance auditor requests cryptographic verification that a specific + set of historical audit events has not been tampered with since the events were + recorded. DCM must produce signed tree heads and merkle inclusion proofs for the + requested events, and the auditor's independent verification against the tree + heads must succeed. Under a sovereign profile, the signing key material must + remain within sovereignty boundaries. The verification is a query over existing + audit state — it modifies no tenant resources, only reads and produces proofs. + actor: + persona: compliance-auditor + profile: sovereign + intent: Cryptographically verify that a named range of audit events has not been + tampered with + success_criteria: + - Signed tree heads are retrievable for every audit epoch covering the requested + event range + - Inclusion proofs are produced for each requested event and verify against the + tree heads + - Consistency proofs demonstrate the tree heads form a coherent append-only sequence + - Signing key material used for tree heads never leaves the sovereignty boundary + - Verification failure on any event is surfaced with the specific event and proof + step that failed + dimensions: + lifecycle_phase: modification + resource_complexity: single_no_deps + policy_complexity: cross_domain_constraint + provider_landscape: single_eligible + governance_context: audit_heavy + failure_mode: happy_path + profile: sovereign + expected_domain_interactions: + - domain: audit + interaction: merkle tree heads retrieved for requested audit epochs + - domain: audit + interaction: inclusion proofs generated for each event in range + - domain: audit + interaction: consistency proofs generated between epoch tree heads + - domain: policy + interaction: sovereignty policy verifies signing key material residency + - domain: data + interaction: audit event records looked up by handle and epoch +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-23T04:45:00.000000+00:00' +tags: +- governance +- audit +- merkle +- cryptographic-verification +- sovereign-profile +- compliance +version: 1.0.0 +metadata: + admitted_at: '2026-04-23T04:45:00.000000+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml b/dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml new file mode 100644 index 0000000..22a8f47 --- /dev/null +++ b/dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml @@ -0,0 +1,83 @@ +uuid: uc-seed-009a +handle: governance/minimal-profile-policy-scope-boundary +scenario: + description: A developer in a minimal-profile personal sandbox tenant provisions + a VM with an attached persistent volume and a network attachment to a resource + in a different region. This same combination of actions, if performed by an + fsi-profile tenant, would trigger (a) data-residency enforcement prohibiting + the cross-region attachment, (b) dual-approval requirement for the privileged + cross-boundary operation, and (c) mandatory encryption-at-rest on the provisioned + volume. Under minimal profile, none of those policies should apply to the request + because they are not bound to the minimal profile group — the request should + proceed with only the policies minimal profile actually carries, which is + effectively system defaults only. The architectural question this exercises is + whether DCM's profile-group binding correctly prevents FSI-scoped policies from + evaluating against minimal-profile requests, and whether the audit record makes + it clear that those policies were not evaluated, rather than silently passing. + actor: + persona: individual-developer + profile: minimal + intent: Provision a VM with attached volume and cross-region network attachment + under a minimal profile, with FSI-scope policies correctly not applied + success_criteria: + - Request succeeds because no policies bound to the minimal profile group reject it + - FSI-scoped policies (data-residency, dual-approval, encryption-at-rest-mandatory) + do not evaluate against this request + - Audit record explicitly shows which policies were evaluated, and does NOT list + the FSI-scoped policies as either passed or skipped with false-positive framing + - No silent fallback evaluates FSI policies with soft enforcement and records a + pass; those policies must simply be out of scope + - The same request shape submitted under an fsi-profile tenant would fail on at + least data-residency and dual-approval (this criterion is about the profile + boundary being real, not about this specific run) + dimensions: + lifecycle_phase: new_request + resource_complexity: cross_dependency_payload + policy_complexity: system_defaults_only + provider_landscape: mixed + governance_context: no_governance + failure_mode: happy_path + profile: minimal + expected_domain_interactions: + - domain: policy + interaction: policy engine determines which policy groups apply based on tenant's + profile (minimal) — FSI-scoped groups are excluded by construction + - domain: policy + interaction: any gatekeepers bound to minimal-profile group evaluate (system + defaults only for this profile) + - domain: provider + interaction: service provider allocates VM in the minimal tenant + - domain: provider + interaction: storage provider allocates volume without forced encryption-at-rest + (FSI-scoped, not bound to minimal) + - domain: provider + interaction: network provider establishes cross-region attachment without + residency rejection (FSI-scoped, not bound to minimal) + - domain: data + interaction: request record created with profile=minimal and the resolved + policy group set for audit + - domain: audit + interaction: audit record lists policies-evaluated explicitly and does not falsely + record FSI-scoped policies as skipped-and-passed +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-23T04:45:00.000000+00:00' +tags: +- governance +- policy +- profile-boundary +- minimal-profile +- negative-policy-claim +- fsi-policies-out-of-scope +- cross-region +- system-defaults-only +version: 1.0.0 +metadata: + admitted_at: '2026-04-23T04:45:00.000000+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/governance/policy-override-approval.yaml b/dav/use-cases/governance/policy-override-approval.yaml new file mode 100644 index 0000000..15b0c58 --- /dev/null +++ b/dav/use-cases/governance/policy-override-approval.yaml @@ -0,0 +1,62 @@ +uuid: uc-seed-005a +handle: governance/policy-override-approval +scenario: + description: A platform engineer requests a time-bounded override of a soft-enforcement + governance policy that is currently blocking a business-critical deployment. The + override request must be evaluated against the policy's override eligibility rules, + routed for approval by the authorized approver role, and the resulting override + (if granted) must be recorded with scope, duration, and rationale. Hard-enforcement + policies must remain unoverridable. This exercises the override_requests workflow + as a modification to the policy-application state for the matched request scope. + actor: + persona: platform-engineer + profile: prod + intent: Obtain time-bounded override of a soft policy to unblock a business-critical + deployment + success_criteria: + - Override eligibility is evaluated against the policy's own override rules, not + globally permitted + - Approval is routed to the role authorized for this override class, not the requester + - Granted overrides are scoped in time and narrowed to the specific matched request + - Hard-enforcement policies are rejected as unoverridable without approval attempt + - Override grant and subsequent policy-suppressed events are audit-linked + dimensions: + lifecycle_phase: modification + resource_complexity: single_no_deps + policy_complexity: human_escalation_required + provider_landscape: single_eligible + governance_context: standard_governance + failure_mode: happy_path + profile: prod + expected_domain_interactions: + - domain: policy + interaction: override request evaluated against policy's override eligibility + declaration + - domain: policy + interaction: approval routed to authorized approver role + - domain: data + interaction: override record created with scope, duration, approver, rationale + - domain: policy + interaction: subsequent policy evaluations honor active override for matched scope + - domain: audit + interaction: override grant and every suppressed policy event are linked for review +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-23T04:45:00.000000+00:00' +tags: +- governance +- policy +- override +- human-in-loop +- prod-profile +- approval-workflow +version: 1.0.0 +metadata: + admitted_at: '2026-04-23T04:45:00.000000+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/identity/auth-provider-drift-detection.yaml b/dav/use-cases/identity/auth-provider-drift-detection.yaml new file mode 100644 index 0000000..a71d766 --- /dev/null +++ b/dav/use-cases/identity/auth-provider-drift-detection.yaml @@ -0,0 +1,53 @@ +uuid: uc-seed-003a +handle: identity/auth-provider-drift-detection +scenario: + description: The DCM control plane detects that the identity provider's view of + a tenant's user group membership no longer matches DCM's cached view. Drift detection + must identify the discrepancy, evaluate whether it is permissible under the tenant's + governance policy, and either remediate or escalate for human review. + actor: + persona: platform-engineer + profile: prod + intent: Detect and respond to drift between DCM's identity cache and the authoritative + IdP + success_criteria: + - Drift is detected within one reconciliation cycle of the source change + - Discrepancies are classified by severity based on policy (silent fixup vs escalation) + - Automated remediation only runs for governance-approved drift categories + - Escalation produces a reviewable record including before/after state + dimensions: + lifecycle_phase: drift_detection + resource_complexity: cross_dependency_payload + policy_complexity: human_escalation_required + provider_landscape: single_eligible + governance_context: standard_governance + failure_mode: data_inconsistency + profile: prod + expected_domain_interactions: + - domain: provider + interaction: auth provider polls IdP for canonical state + - domain: data + interaction: compare cached vs canonical identity state + - domain: policy + interaction: classify drift severity and remediation path + - domain: audit + interaction: record drift detection, classification, and action +generated_by: + mode: authoring + source: human-authored + model: null + prompt_version: seed-1.0 + timestamp: '2026-04-20T18:41:39.744440+00:00' +tags: +- identity +- auth +- drift-detection +- prod-profile +- human-in-loop +version: 1.0.0 +metadata: + admitted_at: '2026-04-20T18:41:39.744455+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt diff --git a/dav/use-cases/observability/udlm-universal-telemetry-export.yaml b/dav/use-cases/observability/udlm-universal-telemetry-export.yaml new file mode 100644 index 0000000..395c7d0 --- /dev/null +++ b/dav/use-cases/observability/udlm-universal-telemetry-export.yaml @@ -0,0 +1,80 @@ +uuid: uc-seed-obs-001 +handle: observability/udlm-universal-telemetry-export +scenario: + description: A platform operations team connects its existing observability + tooling (metrics TSDB, log aggregator, alerting pipeline, SIEM) to DCM + without writing bespoke adapters. All telemetry the platform produces — + resource metrics, lifecycle events, audit records, policy decisions, log + streams — is exported as UDLM-modeled data with discoverable schemas, so + any consuming tool subscribes to the same uniform entity and event + vocabulary. The export is policy-scoped (a subscriber sees only what its + authorization and data-classification policies allow), retention-governed, + and itself auditable. This is the UDLM goal stated as a use case - one + universal way to export data, consumable by any tool. + actor: + persona: platform-operator + profile: standard + intent: Establish a universal telemetry export so monitoring, alerting, + logging, and audit tooling consume DCM data through one UDLM-modeled + interface instead of per-tool integrations + success_criteria: + - Telemetry entities (metrics, events, log records, audit records) are + exposed as UDLM-modeled data with schemas discoverable by the consumer + at subscription time - no out-of-band schema agreement + - A curated event stream subscription delivers lifecycle, drift, policy, + and audit events to the subscriber via the message bus using the + published event catalog vocabulary + - Resource-level metrics are exported through the observability export + surface so an external metrics store can scrape or receive them without + a DCM-specific adapter + - Export scope is policy-evaluated per subscriber - data classification + and tenancy boundaries restrict what each consumer receives + - Subscription creation, schema discovery, and export access are recorded + in the audit trail with actor, intent, and outcome + - A second, different consuming tool can be attached using the same + discovery and subscription path with no export-side changes + dimensions: + lifecycle_phase: new_request + resource_complexity: composite_service + policy_complexity: multi_policy_chain + provider_landscape: multiple_eligible + governance_context: audit_heavy + failure_mode: happy_path + profile: standard + expected_domain_interactions: + - domain: data + interaction: telemetry entities and event catalog exposed as UDLM-modeled, + schema-discoverable data + - domain: provider + interaction: information provider serves export/discovery endpoints; + message bus delivers the curated event stream + - domain: policy + interaction: subscriber authorization, data-classification scoping, and + retention policy evaluated for the export + - domain: audit + interaction: subscription lifecycle and export access recorded in the + tamper-evident audit chain +generated_by: + mode: authoring + source: ai-assisted + model: claude-opus-4-8 + prompt_version: seed-1.0 + timestamp: '2026-06-07T18:30:00.000000+00:00' +tags: +- observability +- udlm +- telemetry-export +- monitoring +- alerting +- logging +- universal-consumption +- happy-path +- standard-profile +- foundational +version: 1.0.0 +metadata: + admitted_at: '2026-06-07T18:30:00.000000+00:00' + admitted_dcm_version: preview + promoted_from_run: null + initial_baseline_path: null + author: chris@croadfeldt From 3707b455258109260e08a5a525782c42fde80912 Mon Sep 17 00:00:00 2001 From: croadfeldt Date: Tue, 7 Jul 2026 23:16:59 -0500 Subject: [PATCH 2/2] sync: update to current upstream (dcm main) Brings this PR's files up to the current DCM spec state (post UDLM/DCM separation, AEP alignment, taxonomy reconciliation, and review resolutions). Content-only update on existing paths. Signed-off-by: croadfeldt --- dav/README.md | 2 +- dav/schemas/use_case.schema.json | 73 ++++++++++++----- .../compute/vm-standard-provision.yaml | 28 ++++--- ...nsible-inventory-brownfield-ingestion.yaml | 2 +- .../sovereign-decommission-with-peer.yaml | 42 ++++++---- .../cross-domain/tenant-onboarding.yaml | 60 ++++++++------ .../data/persistent-volume-provision.yaml | 4 +- ...minimal-profile-policy-scope-boundary.yaml | 80 +++++++++---------- .../auth-provider-drift-detection.yaml | 53 +++++++----- .../udlm-universal-telemetry-export.yaml | 77 +++++++++--------- 10 files changed, 246 insertions(+), 175 deletions(-) diff --git a/dav/README.md b/dav/README.md index 79055d7..caf1a25 100644 --- a/dav/README.md +++ b/dav/README.md @@ -103,7 +103,7 @@ Dimension values are constrained. Valid values as of schema v1.0: - **resource_complexity**: `single_no_deps | hard_dependencies | composite_service | conditional_soft_deps | process_resource | cross_dependency_payload` -- **policy_complexity**: `system_defaults_only | single_gatekeeper | +- **policy_complexity**: `system_defaults_only | single_gating | multi_policy_chain | conflicting_policies | orchestration_flow_static | dynamic_conditional_flow | cross_domain_constraint | human_escalation_required | governance_matrix_enforcement | diff --git a/dav/schemas/use_case.schema.json b/dav/schemas/use_case.schema.json index 9c9db6d..6fad545 100644 --- a/dav/schemas/use_case.schema.json +++ b/dav/schemas/use_case.schema.json @@ -1,6 +1,7 @@ { "$schema": "http://json-schema.org/draft-07/schema#", "title": "DCM Use Case", + "description": "A DCM validation use case: an architecture scenario DAV evaluates against the DCM/UDLM spec. The scenario describes intent, actor, and expected behavior; dimensions classify it along the controlled vocabularies so coverage can be measured; generated_by + metadata carry provenance.", "type": "object", "required": [ "uuid", @@ -12,23 +13,28 @@ "properties": { "uuid": { "type": "string", - "pattern": "^uc-" + "pattern": "^uc-", + "description": "Stable unique id, server-owned. Form: 'uc-' for generated UCs, or a 'uc-' for intentional seed handles. Never reused." }, "handle": { "type": "string", - "pattern": ".*/.*" + "pattern": ".*/.*", + "description": "Human-readable '/' path (e.g. 'compute/vm-standard-provision'). The leading segment groups the UC by domain; must match the file's location." }, "version": { - "type": "string" + "type": "string", + "description": "Semantic version of this UC's content (e.g. '1.0.0'). Bumped when the scenario materially changes." }, "tags": { "type": "array", "items": { "type": "string" - } + }, + "description": "Free-form labels for search/grouping (domain, profile, failure-mode, foundational, etc.). Not validated against a vocabulary." }, "scenario": { "type": "object", + "description": "The use case itself — what is being validated.", "required": [ "description", "actor", @@ -39,19 +45,23 @@ ], "properties": { "description": { - "type": "string" + "type": "string", + "description": "Prose statement of the scenario: the situation, what the platform must do, and why. The primary text the evaluator reasons over." }, "actor": { "type": "object", + "description": "Who initiates the scenario.", "required": [ "persona", "profile" ], "properties": { "persona": { - "type": "string" + "type": "string", + "description": "The role driving the request (e.g. 'application-team-member', 'platform-operator', 'compliance-auditor')." }, "profile": { + "description": "The actor's operating profile (capability-set preset). See scenario.profile.", "enum": [ "minimal", "dev", @@ -64,17 +74,20 @@ } }, "intent": { - "type": "string" + "type": "string", + "description": "The outcome the actor wants, stated as intent (the 'what', not the 'how'). DCM is intent-based; this is the consumer's declared goal." }, "success_criteria": { "type": "array", "items": { "type": "string" }, - "minItems": 1 + "minItems": 1, + "description": "Observable, checkable conditions that must all hold for the scenario to pass. Each is a discrete assertion the evaluation tests against the spec." }, "dimensions": { "type": "object", + "description": "Classifies the UC along DCM's controlled vocabularies so corpus coverage is measurable. Values are drawn from the consumer-profile vocabulary — SOURCE OF TRUTH: examples/dcm-reference-profile.yaml (mirrored into engine consumer_profile). Kept as described strings here (not hard enums) deliberately, so the schema does not become a second, drift-prone copy of that vocabulary; the engine enum-constrains at eval time.", "required": [ "lifecycle_phase", "resource_complexity", @@ -85,26 +98,33 @@ ], "properties": { "lifecycle_phase": { - "type": "string" + "type": "string", + "description": "Where in the resource lifecycle the scenario sits. Vocabulary (dcm-reference-profile.yaml): new_request, modification, decommission, drift_detection, brownfield_ingestion, rehydration_{faithful,provider_portable,historical_exact,historical_portable}, expiry_enforcement." }, "resource_complexity": { - "type": "string" + "type": "string", + "description": "Shape/dependency complexity of the requested resource(s). Vocabulary: single_no_deps, hard_dependencies, compound_service, conditional_soft_deps, process_resource, cross_dependency_payload." }, "policy_complexity": { - "type": "string" + "type": "string", + "description": "Policy-evaluation complexity exercised. Vocabulary: system_defaults_only, single_gating (formerly single_gatekeeper), multi_policy_chain, conflicting_policies, orchestration_flow_static, dynamic_conditional_flow, cross_domain_constraint, human_escalation_required, governance_matrix_enforcement, recovery_policy." }, "provider_landscape": { - "type": "string" + "type": "string", + "description": "The provider-eligibility situation for placement. Vocabulary: single_eligible, multiple_eligible, none_eligible, peer_dcm_required, meta_provider_composed, process_provider, mixed." }, "governance_context": { - "type": "string" + "type": "string", + "description": "The governance/compliance posture in force. Vocabulary: no_governance, standard_governance, audit_heavy, compliance_gated, sovereignty_enforced." }, "failure_mode": { - "type": "string" + "type": "string", + "description": "The failure (or happy_path) the scenario exercises. Vocabulary: happy_path, provider_failure, policy_violation, peer_dcm_disconnect, data_inconsistency, rollback_required, partial_fulfillment, timeout, resource_exhaustion." } } }, "profile": { + "description": "The deployment/operating profile (a platform capability-set preset) the scenario runs under. Profiles are capability sets, not a strict hierarchy; named values are presets. minimal=least overhead (not least security), sovereign=in-boundary/air-gap-capable.", "enum": [ "minimal", "dev", @@ -116,6 +136,7 @@ }, "expected_domain_interactions": { "type": "array", + "description": "The cross-domain interactions the scenario should drive, one entry per (domain, interaction). Used to check the UC touches the right Data/Policy/Provider/Audit surfaces.", "items": { "type": "object", "required": [ @@ -124,10 +145,12 @@ ], "properties": { "domain": { - "type": "string" + "type": "string", + "description": "The DCM domain touched: typically data, policy, provider, or audit." }, "interaction": { - "type": "string" + "type": "string", + "description": "What happens in that domain during the scenario." } } } @@ -136,12 +159,14 @@ }, "generated_by": { "type": "object", + "description": "Provenance of how this UC was authored/generated.", "required": [ "mode", "source" ], "properties": { "mode": { + "description": "Why the UC was produced: 'authoring' (deliberately written), 'regression' (captured from a run), 'pr-targeted' (written to exercise a specific PR/change).", "enum": [ "regression", "pr-targeted", @@ -149,10 +174,12 @@ ] }, "source": { + "description": "Origin of the content: human-authored, AI-assisted (human+model), drawn from the corpus, or LLM-produced (guided/unguided).", "enum": [ "corpus", "llm-unguided", "llm-guided", + "ai-assisted", "human-authored" ] }, @@ -160,21 +187,25 @@ "type": [ "string", "null" - ] + ], + "description": "The model that produced the UC, if LLM-sourced; null for human-authored." }, "prompt_version": { "type": [ "string", "null" - ] + ], + "description": "Version of the authoring prompt used, if LLM-sourced; null otherwise." }, "timestamp": { - "type": "string" + "type": "string", + "description": "ISO-8601 time the UC was generated/authored." } } }, "metadata": { - "type": "object" + "type": "object", + "description": "Admission/lifecycle bookkeeping (when admitted, under which DCM version, author, baseline lineage). Not part of the scenario semantics." } } -} \ No newline at end of file +} diff --git a/dav/use-cases/compute/vm-standard-provision.yaml b/dav/use-cases/compute/vm-standard-provision.yaml index e0bce0f..12176a5 100644 --- a/dav/use-cases/compute/vm-standard-provision.yaml +++ b/dav/use-cases/compute/vm-standard-provision.yaml @@ -1,33 +1,36 @@ uuid: uc-seed-001a handle: compute/vm-standard-provision scenario: - description: An application team requests a new virtual machine with standard multi-tenant - isolation. The platform must enforce tenancy at the data plane, run the appropriate - policy checks before allocation, and produce an auditable record of the provisioning. + description: An application team requests a new virtual machine in the standard + profile. The platform must run the applicable policy checks before allocation, + allocate the VM through an eligible service provider, and produce an auditable + record of the provisioning. This use case is scoped to standard VM provisioning + only; the data-plane tenant-isolation concern is validated separately by + compute/vm-tenant-isolation-enforcement. actor: persona: application-team-member profile: standard - intent: Provision a new VM in the standard profile, scoped to the team's tenant + intent: Provision a new VM in the standard profile success_criteria: - - VM is created and reachable from within the tenant boundary - - Tenant isolation policy is applied to network and storage attachments + - VM is created and reachable for the requesting team + - Applicable (resolved-profile) policies are evaluated before allocation - Provisioning is recorded in the audit trail with actor, intent, and outcome - - "The request is idempotent \u2014 repeating it does not create duplicate VMs" + - "The request is idempotent — repeating it does not create duplicate VMs" dimensions: lifecycle_phase: new_request resource_complexity: single_no_deps - policy_complexity: single_gatekeeper + policy_complexity: single_validation provider_landscape: single_eligible governance_context: standard_governance failure_mode: happy_path profile: standard expected_domain_interactions: - domain: policy - interaction: tenant-isolation gatekeeper evaluates request + interaction: resolved-profile validation evaluates the request before allocation - domain: provider - interaction: service provider allocates VM resource + interaction: service provider allocates the VM resource - domain: data - interaction: resource record created with tenancy fields + interaction: resource record created - domain: audit interaction: provisioning event recorded generated_by: @@ -43,10 +46,11 @@ tags: - standard-profile - single-provider - foundational -version: 1.0.0 +version: 1.1.0 metadata: admitted_at: '2026-04-20T18:41:39.738428+00:00' admitted_dcm_version: preview promoted_from_run: null initial_baseline_path: null author: chris@croadfeldt + edited: '2026-06-29 — split out data-plane tenant isolation (Piotr PR-65 #2); see compute/vm-tenant-isolation-enforcement' diff --git a/dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml b/dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml index 7465af1..db35bbd 100644 --- a/dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml +++ b/dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml @@ -59,7 +59,7 @@ scenario: conversion recorded with before/after provenance generated_by: mode: authoring - source: ai-assisted + source: llm-guided model: claude-opus-4-8 prompt_version: seed-1.0 timestamp: '2026-06-07T21:30:00.000000+00:00' diff --git a/dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml b/dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml index 682c89b..6b62b82 100644 --- a/dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml +++ b/dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml @@ -1,20 +1,30 @@ uuid: uc-seed-002a handle: cross-domain/sovereign-decommission-with-peer scenario: - description: A sovereign-profile tenant initiates decommissioning of a resource - that has been replicated to a peer DCM instance for disaster-recovery compliance. - The decommission must coordinate with the peer to ensure both replicas are released - and the audit trail is consistent across both DCM instances. + description: A resource has been replicated to a peer DCM instance for + disaster-recovery. Decommissioning it is a PEER-COORDINATED operation — a + two-phase release across both DCM instances with a single, consistent + cross-DCM audit trail. (This is distinct from rehydration — rehydrate replays + Intent into a new Requested state on another provider; this releases both + existing replicas.) The peer-coordination mechanic is profile-independent; the + SOVEREIGN profile is what MANDATES it here — sovereign data-residency requires + that a DR replica exists and that its release is residency-checked and + coordinated, not silently dropped. The peer must satisfy the provenance floor + (its attested capability set must cover what this transaction requires) for the + coordinated release to preserve end-to-end provenance. actor: persona: sovereign-tenant-admin profile: sovereign intent: Decommission a resource such that both the local and the peer replica are - released + released, with a consistent cross-DCM audit record success_criteria: - - Local replica is released only after peer acknowledges the decommission - - If the peer is unreachable, the decommission is held in a pending state, not silently - completed - - Final audit record includes the peer acknowledgement evidence + - Local replica is released only after the peer acknowledges the decommission + - If the peer is unreachable, the decommission is held in a pending state, not + silently completed + - The peer's attested capability set is verified to meet the transaction's + provenance requirements before coordination proceeds + - Final audit record includes the peer acknowledgement evidence and is consistent + across both DCM instances - Sovereign data-residency constraints are not violated during the wind-down dimensions: lifecycle_phase: decommission @@ -26,15 +36,16 @@ scenario: profile: sovereign expected_domain_interactions: - domain: policy - interaction: sovereignty policy evaluates residency at decommission + interaction: sovereignty policy mandates the peer replica + residency check at + decommission; verifies peer meets the provenance floor before coordinating - domain: provider - interaction: peer_dcm provider coordinates with remote DCM + interaction: peer_dcm provider coordinates the two-phase release with the remote DCM - domain: provider - interaction: service provider releases local resource + interaction: service provider releases the local resource only after peer-ack - domain: data interaction: resource record marked released with peer-ack metadata - domain: audit - interaction: cross-DCM audit record stitched together + interaction: cross-DCM audit record stitched together consistently generated_by: mode: authoring source: human-authored @@ -46,12 +57,15 @@ tags: - decommission - sovereign - peer-dcm +- peer-coordinated +- provenance-floor - edge-case - failure-mode -version: 1.0.0 +version: 1.1.0 metadata: admitted_at: '2026-04-20T18:41:39.741660+00:00' admitted_dcm_version: preview promoted_from_run: null initial_baseline_path: null author: chris@croadfeldt + edited: '2026-06-29 — reframe peer-coordinated (not rehydrate), sovereign-as-mandate, peer provenance floor (Piotr PR-65 #4)' diff --git a/dav/use-cases/cross-domain/tenant-onboarding.yaml b/dav/use-cases/cross-domain/tenant-onboarding.yaml index 25c1e69..f9bd530 100644 --- a/dav/use-cases/cross-domain/tenant-onboarding.yaml +++ b/dav/use-cases/cross-domain/tenant-onboarding.yaml @@ -1,28 +1,34 @@ uuid: uc-seed-008a handle: cross-domain/tenant-onboarding scenario: - description: A platform engineer onboards a new tenant into the FSI-profile DCM - deployment. Onboarding must provision the tenant identity boundary, bind the - appropriate policy profile and compliance domain overlays, establish storage - and compute quota allocations, configure auth provider claims mapping, and - produce a single atomic onboarding record such that either all steps complete - or none persist. The new tenant must be immediately governed by FSI policies - before any resource is requestable under its name. + description: A platform engineer onboards a new tenant into a DCM deployment whose + instance profile is fsi. Onboarding is a single atomic operation that provisions + the tenant identity boundary, binds the tenant to the instance's resolved profile + (the platform default — near-term the instance applies one profile deployment-wide), + composes the appropriate compliance/sovereignty overlay (Sovereignty Zone + + Accreditation — a SEPARATE axis from the profile) for the tenant's declared + regulatory scope, establishes storage and compute quota allocations, and configures + the tenant's auth-provider claims mapping (identity is delegated to the IdP; DCM + holds the claims-mapping reference, not a membership store). There is no separate + bespoke tenant-to-profile mapping table — the binding is the profile (a capability + set) bound via a policy_profile DCMGroup; profile selection per tenant is a future + capability. Either all onboarding steps complete or none persist. actor: persona: platform-engineer profile: fsi - intent: Onboard a new tenant as an atomic operation with full policy and quota - binding before the tenant can request any resources + intent: Onboard a new tenant as an atomic operation, bound to the instance profile + with its compliance overlay and quotas, before it can request any resources success_criteria: - - Tenant identity boundary is created and linked to the FSI profile - - Compliance domain overlays appropriate to the tenant's declared regulatory scope - are bound to the tenant + - Tenant identity boundary is created and bound to the instance's resolved profile + (the platform default) via a policy_profile DCMGroup — no separate mapping artifact + - The compliance/sovereignty overlay (Sovereignty Zone + Accreditation) for the + tenant's declared regulatory scope is composed with the profile, not folded into it - Storage and compute quotas are allocated with the requested ceilings - - Auth provider claims mapping is configured to resolve tenant membership - - Partial-completion of onboarding is not observable to downstream consumers; either - the tenant is fully governed or the partial state is rolled back - - FSI policy enforcement is active on the tenant before its first resource request - is accepted + - Auth-provider claims mapping is configured (delegated identity; DCM stores the + reference, not cached membership) + - Partial onboarding is not observable downstream; either the tenant is fully + governed or the partial state is rolled back + - The instance profile's policies are active on the tenant before its first request dimensions: lifecycle_phase: new_request resource_complexity: composite_service @@ -33,15 +39,18 @@ scenario: profile: fsi expected_domain_interactions: - domain: data - interaction: tenant identity boundary entity created with profile binding + interaction: tenant identity boundary (tenant_boundary DCMGroup) created, bound + to the instance profile (policy_profile DCMGroup) - domain: policy - interaction: FSI profile policies and compliance overlays bound to tenant + interaction: instance-profile policies + composed compliance/sovereignty overlay + bound to the tenant - domain: data - interaction: storage and compute quota allocations recorded against tenant + interaction: storage and compute quota allocations recorded against the tenant - domain: provider - interaction: auth provider configured with tenant claims mapping + interaction: auth provider configured with the tenant claims-mapping reference + (delegated identity) - domain: policy - interaction: onboarding atomicity enforced by orchestration flow policy + interaction: onboarding atomicity enforced by an orchestration flow policy - domain: audit interaction: single onboarding record stitches all sub-operations together generated_by: @@ -56,12 +65,13 @@ tags: - onboarding - fsi-profile - atomic-composition -- identity-policy-data -- compound-service -version: 1.0.0 +- approved-list-profile +- compliance-overlay-separate-axis +version: 1.1.0 metadata: admitted_at: '2026-04-23T04:45:00.000000+00:00' admitted_dcm_version: preview promoted_from_run: null initial_baseline_path: null author: chris@croadfeldt + edited: '2026-06-29 — instance-profile binding (approved-list model), drop bespoke mapping, compliance as separate axis (Piotr PR-65 #5 / DR-B)' diff --git a/dav/use-cases/data/persistent-volume-provision.yaml b/dav/use-cases/data/persistent-volume-provision.yaml index a8deba4..61e03a3 100644 --- a/dav/use-cases/data/persistent-volume-provision.yaml +++ b/dav/use-cases/data/persistent-volume-provision.yaml @@ -19,14 +19,14 @@ scenario: dimensions: lifecycle_phase: new_request resource_complexity: cross_dependency_payload - policy_complexity: single_gatekeeper + policy_complexity: single_validation provider_landscape: single_eligible governance_context: standard_governance failure_mode: happy_path profile: dev expected_domain_interactions: - domain: policy - interaction: tenant-isolation gatekeeper evaluates volume request against tenant's + interaction: tenant-isolation gating evaluates volume request against tenant's storage class eligibility - domain: provider interaction: storage provider allocates block volume in eligible class diff --git a/dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml b/dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml index 22a8f47..dd866e3 100644 --- a/dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml +++ b/dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml @@ -1,35 +1,35 @@ uuid: uc-seed-009a handle: governance/minimal-profile-policy-scope-boundary scenario: - description: A developer in a minimal-profile personal sandbox tenant provisions - a VM with an attached persistent volume and a network attachment to a resource - in a different region. This same combination of actions, if performed by an - fsi-profile tenant, would trigger (a) data-residency enforcement prohibiting - the cross-region attachment, (b) dual-approval requirement for the privileged - cross-boundary operation, and (c) mandatory encryption-at-rest on the provisioned - volume. Under minimal profile, none of those policies should apply to the request - because they are not bound to the minimal profile group — the request should - proceed with only the policies minimal profile actually carries, which is - effectively system defaults only. The architectural question this exercises is - whether DCM's profile-group binding correctly prevents FSI-scoped policies from - evaluating against minimal-profile requests, and whether the audit record makes - it clear that those policies were not evaluated, rather than silently passing. + description: A developer in a minimal-profile sandbox provisions a VM with an + attached persistent volume and a cross-region network attachment. Under the + minimal profile, the FSI-scoped policies (data-residency, dual-approval for the + privileged cross-boundary operation, mandatory encryption-at-rest) are NOT part + of the request's RESOLVED PROFILE, so they must not evaluate; the request proceeds + under only the policies the minimal profile carries (effectively system defaults). + The architectural property this validates is DCM's policy-applicability model — + which policies fire is determined BY CONSTRUCTION from the request's resolved + profile (the profile selected from the platform's approved list, or the platform + default), and a policy not in that set is OUT OF SCOPE — neither evaluated nor + recorded as skipped-and-passed. The same request shape resolved under an + fsi profile WOULD fail (data-residency + dual-approval), which is what makes the + boundary real. (Per the approved-list model there is no floor/ceiling — the + platform governs applicability via its approved list + default, not a strictness + rank.) actor: persona: individual-developer profile: minimal intent: Provision a VM with attached volume and cross-region network attachment - under a minimal profile, with FSI-scope policies correctly not applied + under a minimal resolved profile, with FSI-scoped policies correctly out of scope success_criteria: - - Request succeeds because no policies bound to the minimal profile group reject it + - Request succeeds because no policy in the minimal resolved profile rejects it - FSI-scoped policies (data-residency, dual-approval, encryption-at-rest-mandatory) - do not evaluate against this request - - Audit record explicitly shows which policies were evaluated, and does NOT list - the FSI-scoped policies as either passed or skipped with false-positive framing - - No silent fallback evaluates FSI policies with soft enforcement and records a - pass; those policies must simply be out of scope - - The same request shape submitted under an fsi-profile tenant would fail on at - least data-residency and dual-approval (this criterion is about the profile - boundary being real, not about this specific run) + are NOT in the resolved profile and do not evaluate + - The audit record uses three distinct outcomes — evaluated-pass, evaluated-fail, + out-of-scope — and lists FSI-scoped policies as OUT OF SCOPE, not skipped-and-passed + - No silent fallback evaluates FSI policies with soft enforcement and records a pass + - The same request shape resolved under an fsi profile would fail on at least + data-residency and dual-approval (the boundary is real, not run-specific) dimensions: lifecycle_phase: new_request resource_complexity: cross_dependency_payload @@ -40,25 +40,24 @@ scenario: profile: minimal expected_domain_interactions: - domain: policy - interaction: policy engine determines which policy groups apply based on tenant's - profile (minimal) — FSI-scoped groups are excluded by construction + interaction: the engine resolves the request's profile and selects that profile's + policies by construction — FSI-scoped policies are out of scope, not evaluated - domain: policy - interaction: any gatekeepers bound to minimal-profile group evaluate (system - defaults only for this profile) + interaction: policies in the minimal resolved profile evaluate (system defaults + for this profile) - domain: provider - interaction: service provider allocates VM in the minimal tenant + interaction: service provider allocates the VM in the minimal sandbox - domain: provider - interaction: storage provider allocates volume without forced encryption-at-rest - (FSI-scoped, not bound to minimal) + interaction: storage provider allocates the volume without forced encryption-at-rest + (FSI-scoped, out of scope for minimal) - domain: provider - interaction: network provider establishes cross-region attachment without - residency rejection (FSI-scoped, not bound to minimal) + interaction: network provider establishes the cross-region attachment without + residency rejection (FSI-scoped, out of scope for minimal) - domain: data - interaction: request record created with profile=minimal and the resolved - policy group set for audit + interaction: request record stores the resolved profile + its policy set for audit - domain: audit - interaction: audit record lists policies-evaluated explicitly and does not falsely - record FSI-scoped policies as skipped-and-passed + interaction: audit record lists policies-evaluated with three-state outcomes; does + not record out-of-scope FSI policies as skipped-and-passed generated_by: mode: authoring source: human-authored @@ -68,16 +67,17 @@ generated_by: tags: - governance - policy -- profile-boundary +- resolved-profile - minimal-profile - negative-policy-claim -- fsi-policies-out-of-scope -- cross-region +- out-of-scope-not-skipped-pass +- three-state-audit - system-defaults-only -version: 1.0.0 +version: 1.1.0 metadata: admitted_at: '2026-04-23T04:45:00.000000+00:00' admitted_dcm_version: preview promoted_from_run: null initial_baseline_path: null author: chris@croadfeldt + edited: '2026-06-29 — resolved-profile membership + three-state audit honesty; approved-list (no floor/ceiling) (Piotr PR-65 #7 / DR-E)' diff --git a/dav/use-cases/identity/auth-provider-drift-detection.yaml b/dav/use-cases/identity/auth-provider-drift-detection.yaml index a71d766..625c92a 100644 --- a/dav/use-cases/identity/auth-provider-drift-detection.yaml +++ b/dav/use-cases/identity/auth-provider-drift-detection.yaml @@ -1,37 +1,47 @@ uuid: uc-seed-003a handle: identity/auth-provider-drift-detection scenario: - description: The DCM control plane detects that the identity provider's view of - a tenant's user group membership no longer matches DCM's cached view. Drift detection - must identify the discrepancy, evaluate whether it is permissible under the tenant's - governance policy, and either remediate or escalate for human review. + description: DCM delegates identity to the IdP and does NOT keep an authoritative + membership cache (see identity/connected-delegation). Under a sovereign / + disconnected deployment, DCM is permitted to hold a point-in-time IDENTITY + PROJECTION (provenance=observed) so it can keep operating while the IdP is + unreachable. This use case detects that such a projection (or a previously + materialized authorization decision) has DIVERGED from the IdP once connectivity + or a reconciliation cycle allows comparison — classifies the divergence under the + tenant's governance policy, and either remediates or escalates for human review. + This is explicitly the disconnected/sovereign + audit case; in a connected + deployment DCM delegates live and there is no cache to drift. actor: - persona: platform-engineer - profile: prod - intent: Detect and respond to drift between DCM's identity cache and the authoritative - IdP + persona: sovereign-tenant-admin + profile: sovereign + intent: Detect and respond to divergence between DCM's disconnected identity + projection and the authoritative IdP, under sovereign/disconnected operation success_criteria: - - Drift is detected within one reconciliation cycle of the source change - - Discrepancies are classified by severity based on policy (silent fixup vs escalation) - - Automated remediation only runs for governance-approved drift categories - - Escalation produces a reviewable record including before/after state + - Divergence is detected within one reconciliation cycle of connectivity/comparison + - The identity projection is provenance-marked observed and is never treated as the + system of record for membership + - Discrepancies are classified by severity per governance policy (silent fixup vs + escalation) + - Automated remediation only runs for governance-approved divergence categories + - Escalation produces a reviewable, audited record including before/after state dimensions: lifecycle_phase: drift_detection resource_complexity: cross_dependency_payload policy_complexity: human_escalation_required provider_landscape: single_eligible - governance_context: standard_governance + governance_context: sovereignty_enforced failure_mode: data_inconsistency - profile: prod + profile: sovereign expected_domain_interactions: - domain: provider - interaction: auth provider polls IdP for canonical state + interaction: auth provider re-resolves canonical state from the IdP (authoritative) - domain: data - interaction: compare cached vs canonical identity state + interaction: compare the observed point-in-time projection vs canonical IdP state - domain: policy - interaction: classify drift severity and remediation path + interaction: classify divergence severity and remediation path; gate on whether a + projection is permitted (disconnected/sovereign) - domain: audit - interaction: record drift detection, classification, and action + interaction: record divergence detection, classification, and action generated_by: mode: authoring source: human-authored @@ -42,12 +52,15 @@ tags: - identity - auth - drift-detection -- prod-profile +- delegated-identity +- disconnected-projection +- sovereign-profile - human-in-loop -version: 1.0.0 +version: 1.1.0 metadata: admitted_at: '2026-04-20T18:41:39.744455+00:00' admitted_dcm_version: preview promoted_from_run: null initial_baseline_path: null author: chris@croadfeldt + edited: '2026-06-29 — re-scope to disconnected/sovereign projection drift; DCM delegates, holds references not membership (Piotr PR-65 #8 / DR-C)' diff --git a/dav/use-cases/observability/udlm-universal-telemetry-export.yaml b/dav/use-cases/observability/udlm-universal-telemetry-export.yaml index 395c7d0..429a597 100644 --- a/dav/use-cases/observability/udlm-universal-telemetry-export.yaml +++ b/dav/use-cases/observability/udlm-universal-telemetry-export.yaml @@ -1,38 +1,35 @@ uuid: uc-seed-obs-001 handle: observability/udlm-universal-telemetry-export scenario: - description: A platform operations team connects its existing observability - tooling (metrics TSDB, log aggregator, alerting pipeline, SIEM) to DCM - without writing bespoke adapters. All telemetry the platform produces — - resource metrics, lifecycle events, audit records, policy decisions, log - streams — is exported as UDLM-modeled data with discoverable schemas, so - any consuming tool subscribes to the same uniform entity and event - vocabulary. The export is policy-scoped (a subscriber sees only what its - authorization and data-classification policies allow), retention-governed, - and itself auditable. This is the UDLM goal stated as a use case - one - universal way to export data, consumable by any tool. + description: A platform operations team connects its existing observability tooling + (metrics TSDB, log aggregator, alerting pipeline, SIEM) to DCM. Rather than DCM + writing N per-tool adapters, DCM exposes ONE UDLM-modeled, schema-discoverable + export surface over STANDARD TRANSPORTS — OTLP, Prometheus scrape, and a message-bus + subscription against the published event catalog. "No bespoke adapters" means no + DCM-side per-tool integration code — any tool that speaks a standard transport + consumes the same uniform entity/event vocabulary directly. Where a consumer speaks + a proprietary protocol, a thin standard exporter sits at the CONSUMER edge (one per + protocol, outside DCM), not inside DCM. The export is policy-scoped (a subscriber + sees only what its authorization and data-classification policies allow), + retention-governed, and itself auditable. actor: persona: platform-operator profile: standard - intent: Establish a universal telemetry export so monitoring, alerting, - logging, and audit tooling consume DCM data through one UDLM-modeled - interface instead of per-tool integrations + intent: Establish a universal telemetry export so monitoring, alerting, logging, and + audit tooling consume DCM data through one UDLM-modeled interface over standard + transports, with no DCM-side per-tool adapters success_criteria: - - Telemetry entities (metrics, events, log records, audit records) are - exposed as UDLM-modeled data with schemas discoverable by the consumer - at subscription time - no out-of-band schema agreement - - A curated event stream subscription delivers lifecycle, drift, policy, - and audit events to the subscriber via the message bus using the - published event catalog vocabulary - - Resource-level metrics are exported through the observability export - surface so an external metrics store can scrape or receive them without - a DCM-specific adapter - - Export scope is policy-evaluated per subscriber - data classification - and tenancy boundaries restrict what each consumer receives - - Subscription creation, schema discovery, and export access are recorded - in the audit trail with actor, intent, and outcome - - A second, different consuming tool can be attached using the same - discovery and subscription path with no export-side changes + - Telemetry entities (metrics, events, log records, audit records) are exposed as + UDLM-modeled data with schemas discoverable by the consumer at subscription time + - A curated event-stream subscription delivers lifecycle, drift, policy, and audit + events via the message bus using the published event-catalog vocabulary + - Resource metrics are exported over a standard transport (OTLP / Prometheus scrape) + consumable with no DCM-specific adapter + - Export scope is policy-evaluated per subscriber (data classification + tenancy) + - Subscription creation, schema discovery, and export access are recorded in the + audit trail + - A second, different consuming tool attaches via the same discovery/subscription + path with no export-side change (proof the surface is uniform, not per-tool) dimensions: lifecycle_phase: new_request resource_complexity: composite_service @@ -43,20 +40,20 @@ scenario: profile: standard expected_domain_interactions: - domain: data - interaction: telemetry entities and event catalog exposed as UDLM-modeled, + interaction: telemetry entities + event catalog exposed as UDLM-modeled, schema-discoverable data - domain: provider - interaction: information provider serves export/discovery endpoints; + interaction: information provider serves export/discovery over standard transports; message bus delivers the curated event stream - domain: policy - interaction: subscriber authorization, data-classification scoping, and - retention policy evaluated for the export + interaction: subscriber authorization, data-classification scoping, and retention + policy evaluated for the export - domain: audit - interaction: subscription lifecycle and export access recorded in the - tamper-evident audit chain + interaction: subscription lifecycle and export access recorded in the tamper-evident + audit chain generated_by: mode: authoring - source: ai-assisted + source: llm-guided model: claude-opus-4-8 prompt_version: seed-1.0 timestamp: '2026-06-07T18:30:00.000000+00:00' @@ -64,17 +61,19 @@ tags: - observability - udlm - telemetry-export -- monitoring -- alerting -- logging +- standard-transports +- otlp +- prometheus +- message-bus - universal-consumption - happy-path - standard-profile - foundational -version: 1.0.0 +version: 1.1.0 metadata: admitted_at: '2026-06-07T18:30:00.000000+00:00' admitted_dcm_version: preview promoted_from_run: null initial_baseline_path: null author: chris@croadfeldt + edited: '2026-06-29 — honest adapter model: one UDLM surface over standard transports, edge translators outside DCM (Piotr PR-65 #9)'