dd2: expand the DCM validation corpus

dav/use-cases/compute/idempotent-reconvergence.yaml

@@ -0,0 +1,63 @@
+uuid: uc-pipeline-idempotent-001
+handle: compute/idempotent-reconvergence
+scenario:
+  description: An application team re-applies an unchanged intent to an already-realized
+    resource. The system must recognize that the intent matches the current realized
+    state and produce a no-op — no new dispatch, no new provider calls, no duplicate
+    resources. This validates the idempotency guarantee that is critical for safe reconvergence
+    and rehydration.
+  actor:
+    persona: application-team-member
+    profile: standard
+  intent: Re-apply unchanged intent and verify no-op reconvergence
+  success_criteria:
+  - Re-applied intent is accepted and processed through the pipeline
+  - System detects that realized state already matches the intent
+  - No new provider dispatch occurs (no-op)
+  - No duplicate resources are created
+  - The no-op decision and its rationale are recorded in the audit trail
+  - Resource UUIDs remain stable (no reassignment)
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent compared against realized state
+  - domain: policy
+    interaction: validation policy evaluates the re-applied request
+  - domain: audit
+    interaction: no-op decision recorded with rationale
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- compute
+- idempotent
+- reconvergence
+- pipeline
+version: 1.0.0
+metadata:
+  admitted_at: '2026-06-30T22:00:00.000000+00:00'
+  admitted_dcm_version: preview
+  author: chris@croadfeldt
+  pipeline:
+    act: 3
+    sequence: 10
+    week: wk4
+    depends_on:
+    - uc-pipeline-composite-001
+  preconditions:
+  - Resource is realized and matches the previously declared intent
+  - Four-state stores are populated
+  postconditions:
+  - No new provider dispatch occurred
+  - Resource state is unchanged
+  - Audit trail records the no-op

dav/use-cases/compute/tenancy-data-model.yaml

@@ -0,0 +1,52 @@
+uuid: uc-tenancy-data-model
+handle: compute/tenancy-data-model
+version: 1.0.0
+scenario:
+  description: 'Validation UC for A2: confirm UDLM models the data behind data-plane tenant isolation
+    — resource tenancy fields binding a resource to its tenant, and the tenant_boundary DCMGroup that
+    network/storage attachments are confined to.'
+  actor:
+    persona: application-team-member
+    profile: standard
+  intent: Validate UDLM models resource tenancy fields and the tenant_boundary DCMGroup
+  success_criteria:
+  - A resource record models the tenancy fields binding it to its tenant
+  - The tenant boundary is modeled as a tenant_boundary DCMGroup
+  - Network and storage attachments reference the tenant boundary in the model
+  - An attachment crossing the tenant boundary is representable as a rejected/violating state
+  - The isolation decision is representable in the audit model
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: system_defaults_only
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: resource tenancy fields + tenant_boundary DCMGroup modeled
+  - domain: policy
+    interaction: tenant-isolation applicability representable
+  - domain: audit
+    interaction: isolation decision representable
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: trifecta-1.0
+  timestamp: '2026-06-29T00:00:00.000000+00:00'
+tags:
+- a2
+- tenancy
+- data-model-validation
+- trifecta
+- udlm
+- standard-profile
+metadata:
+  admitted_at: '2026-06-29T00:00:00.000000+00:00'
+  admitted_dcm_version: preview
+  promoted_from_run: null
+  initial_baseline_path: null
+  author: chris@croadfeldt
+  note: trifecta validation UC (Piotr-feedback DRs)

dav/use-cases/compute/vm-tenant-isolation-enforcement.yaml

@@ -0,0 +1,61 @@
+uuid: uc-tenant-iso-001
+handle: compute/vm-tenant-isolation-enforcement
+scenario:
+  description: A VM is provisioned for a team within a multi-tenant DCM deployment.
+    The platform must enforce tenant isolation at the data plane — the VM's network
+    and storage attachments are confined to the tenant boundary, and a tenant-isolation
+    policy is evaluated and applied before the attachments are realized. This is the
+    reusable data-plane tenancy building block, split out from compute/vm-standard-provision
+    (Piotr PR-65 #2) so the isolation concern is validated on its own.
+  actor:
+    persona: application-team-member
+    profile: standard
+  intent: Provision a VM whose network and storage attachments are confined to the
+    requesting team's tenant boundary
+  success_criteria:
+  - Tenant-isolation policy is evaluated and applied to the VM's network attachments
+  - Tenant-isolation policy is evaluated and applied to the VM's storage attachments
+  - Attachments that would cross the tenant boundary are rejected, not silently allowed
+  - The resource record carries the tenancy fields binding the VM to its tenant boundary
+  - The isolation decision (policies evaluated + outcome) is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: tenant-isolation policy evaluates network and storage attachments
+      against the tenant boundary
+  - domain: provider
+    interaction: network and storage providers realize attachments only within the
+      tenant boundary
+  - domain: data
+    interaction: resource record created with tenancy fields binding the VM to its
+      tenant_boundary DCMGroup
+  - domain: audit
+    interaction: isolation policies-evaluated and outcome recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-29T00:00:00.000000+00:00'
+tags:
+- compute
+- vm
+- tenancy
+- data-plane-isolation
+- standard-profile
+- foundational
+- split-from-vm-standard-provision
+version: 1.0.0
+metadata:
+  admitted_at: '2026-06-29T00:00:00.000000+00:00'
+  admitted_dcm_version: preview
+  promoted_from_run: null
+  initial_baseline_path: null
+  author: chris@croadfeldt

dav/use-cases/cross-domain/brownfield-adoption-capability.yaml

@@ -0,0 +1,54 @@
+uuid: uc-brownfield-adoption-capability
+handle: cross-domain/brownfield-adoption-capability
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-A: confirm DCM provides the capability to adopt an existing estate
+    in place (ingest hosts/groups/credentials as entities with zero resource recreation), track divergence
+    as drift during a coexistence window, perform the cutover authority flip (legacy->DCM-authoritative),
+    and remain reversible before cutover. This checks the CAPABILITY exists to support cross-domain/ansible-inventory-brownfield-ingestion.'
+  actor:
+    persona: platform-operator
+    profile: standard
+  intent: Validate DCM exposes the brownfield adopt-in-place + coexistence + cutover capability
+  success_criteria:
+  - DCM can ingest discovered resources as entities without recreating or restarting them (adopt-in-place)
+  - DCM tracks divergence between legacy-controlled state and ingested entities as drift during coexistence
+  - DCM supports a cutover that flips authority to the DCM API as the single control path
+  - Ingestion is reversible before cutover (removing DCM management leaves the estate as found)
+  - Post-cutover out-of-band change handling is a policy-configurable action (default reject+alert)
+  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: provider
+    interaction: information provider enumerates the existing estate for adopt-in-place
+  - domain: policy
+    interaction: coexistence policy classifies drift by phase; cutover flips management authority
+  - domain: data
+    interaction: entities adopted with brownfield provenance; no resource recreation
+  - domain: audit
+    interaction: adoption, drift, and cutover recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: trifecta-1.0
+  timestamp: '2026-06-29T00:00:00.000000+00:00'
+tags:
+- dr-a
+- brownfield
+- capability-validation
+- trifecta
+- standard-profile
+metadata:
+  admitted_at: '2026-06-29T00:00:00.000000+00:00'
+  admitted_dcm_version: preview
+  promoted_from_run: null
+  initial_baseline_path: null
+  author: chris@croadfeldt
+  note: trifecta validation UC (Piotr-feedback DRs)

dav/use-cases/cross-domain/brownfield-adoption-data-model.yaml

@@ -0,0 +1,54 @@
+uuid: uc-brownfield-adoption-data-model
+handle: cross-domain/brownfield-adoption-data-model
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-A: confirm UDLM models the data needed for brownfield adoption —
+    brownfield provenance on entities, a per-entity management_authority (legacy|dcm) that flips at cutover,
+    Discovered-state drift records, DCMGroup mappings for ingested groups, and vault-backed credential
+    resources replacing embedded plaintext.'
+  actor:
+    persona: platform-operator
+    profile: standard
+  intent: Validate UDLM models the brownfield adoption data (provenance, management authority, drift)
+  success_criteria:
+  - Each ingested entity carries provenance marking it brownfield
+  - Each entity carries a management_authority field with values legacy or dcm
+  - Discovered-state drift records are modeled and persist across the coexistence window
+  - Ingested inventory groups map to DCMGroup entities with membership preserved
+  - Embedded plaintext credentials become vault-backed credential resources in the model
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: cross_dependency_payload
+    policy_complexity: system_defaults_only
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: entities, DCMGroups, credential resources, and drift records modeled with brownfield
+      provenance
+  - domain: provider
+    interaction: config-management system represented as an information provider
+  - domain: audit
+    interaction: provenance and authority transitions recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: trifecta-1.0
+  timestamp: '2026-06-29T00:00:00.000000+00:00'
+tags:
+- dr-a
+- brownfield
+- data-model-validation
+- trifecta
+- udlm
+- standard-profile
+metadata:
+  admitted_at: '2026-06-29T00:00:00.000000+00:00'
+  admitted_dcm_version: preview
+  promoted_from_run: null
+  initial_baseline_path: null
+  author: chris@croadfeldt
+  note: trifecta validation UC (Piotr-feedback DRs)

dav/use-cases/cross-domain/composite-service-provision.yaml

@@ -0,0 +1,71 @@
+uuid: uc-pipeline-composite-001
+handle: cross-domain/composite-service-provision
+scenario:
+  description: An application team submits a composite service request (e.g., a
+    three-tier web application — web, app, database). DCM decomposes the composite
+    into constituents, resolves dependencies, evaluates validation policies
+    (including sovereignty constraints), selects providers via the placement engine,
+    and realizes each constituent in dependency order. This is the "easy consumption"
+    proof — a single intent produces a full running stack.
+  actor:
+    persona: application-team-member
+    profile: standard
+  intent: Provision a composite service from a single intent declaration
+  success_criteria:
+  - Composite service request is accepted and decomposed into constituents
+  - Dependencies are resolved and constituents are dispatched in the correct order
+    (dependency rounds)
+  - Validation policies (including sovereignty) are evaluated before each dispatch
+  - Each constituent is realized by the selected service provider
+  - All four states (intent, requested, realized, discovered) are populated for the
+    composite entity
+  - The composite entity status reflects OPERATIONAL when all required constituents
+    succeed
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multi_validation
+    provider_landscape: multi_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: validation policies evaluate sovereignty and business rules before
+      dispatch
+  - domain: provider
+    interaction: service providers realize each constituent
+  - domain: data
+    interaction: composite entity created across all four states
+  - domain: audit
+    interaction: full provisioning arc recorded with dependency ordering
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- cross-domain
+- composite-service
+- provision
+- full-stack
+- pipeline
+version: 1.0.0
+metadata:
+  admitted_at: '2026-06-30T22:00:00.000000+00:00'
+  admitted_dcm_version: preview
+  author: chris@croadfeldt
+  pipeline:
+    act: 2
+    sequence: 6
+    week: wk3
+    depends_on:
+    - uc-pipeline-catalog-001
+  preconditions:
+  - Composite service catalog item is registered and visible
+  - Actor holds a valid Keycloak token with tenant and role claims
+  postconditions:
+  - Composite service is realized with all constituents operational
+  - All four states reflect the complete provisioning arc
+  - Intent matches realized state