From 688b6e087cd46664eda5091eb1416dc58e19ded1 Mon Sep 17 00:00:00 2001
From: Chris Roadfeldt <chris@roadfeldt.com>
Date: Tue, 28 Jul 2026 00:26:33 -0500
Subject: [PATCH] [DCM-08] DAV validation corpus

Republished from croadfeldt/dcm; see dcm-project/dcm#108.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---
 dav/CHANGELOG.md                              | 110 +++++++++
 dav/README.md                                 | 136 ++++++++++++
 dav/schemas/use_case.schema.json              | 210 ++++++++++++++++++
 dav/stress-testing-process.md                 |  73 ++++++
 dav/use-cases/DIMENSION-VOCABULARY.yaml       |  80 +++++++
 dav/use-cases/PERSONAS.yaml                   | 195 ++++++++++++++++
 ...1-solution-architecture-decomposition.yaml |  60 +++++
 .../compute/idempotent-reconvergence.yaml     |  66 ++++++
 dav/use-cases/compute/tenancy-data-model.yaml |  54 +++++
 .../vm-provision-with-provider-failure.yaml   |  71 ++++++
 .../compute/vm-standard-provision.yaml        |  59 +++++
 .../vm-tenant-isolation-enforcement.yaml      |  63 ++++++
 ...nsible-inventory-brownfield-ingestion.yaml |  86 +++++++
 .../brownfield-adoption-capability.yaml       |  57 +++++
 .../brownfield-adoption-data-model.yaml       |  58 +++++
 .../composite-service-provision.yaml          |  76 +++++++
 .../composite-service-to-catalog-item.yaml    |  67 ++++++
 .../cross-dcm-audit-data-model.yaml           |  54 +++++
 .../cross-domain/dynamic-rehydration.yaml     |  76 +++++++
 .../peer-coordination-capability.yaml         |  55 +++++
 .../profile-approved-list-data-model.yaml     |  59 +++++
 .../profile-resolution-capability.yaml        |  57 +++++
 .../provider-portable-rebuild.yaml            |  74 ++++++
 .../sovereign-decommission-with-peer.yaml     |  77 +++++++
 .../cross-domain/tenant-onboarding.yaml       |  82 +++++++
 .../data/four-state-store-conformance.yaml    |  64 ++++++
 .../data/persistent-volume-provision.yaml     |  64 ++++++
 .../governance/audit-chain-data-model.yaml    |  51 +++++
 .../audit-chain-output-verification.yaml      |  56 +++++
 .../audit-chain-proofs-capability.yaml        |  55 +++++
 .../audit-merkle-tree-verification.yaml       |  67 ++++++
 ...minimal-profile-policy-scope-boundary.yaml |  87 ++++++++
 .../policy-applicability-data-model.yaml      |  57 +++++
 .../governance/policy-override-approval.yaml  |  64 ++++++
 .../policy-resolution-capability.yaml         |  58 +++++
 .../sovereignty-validation-policy.yaml        |  69 ++++++
 .../001-field-provenance-chain.yaml           |  59 +++++
 .../002-audit-record-vs-object-history.yaml   |  54 +++++
 .../003-tamper-evidence-inclusion-proof.yaml  |  58 +++++
 ...004-tamper-evidence-consistency-proof.yaml |  59 +++++
 .../005-audit-store-outage-gap-record.yaml    |  56 +++++
 ...ernance-honesty-ungoverned-not-passed.yaml |  56 +++++
 ...-compliance-gate-blocks-nonconformant.yaml |  59 +++++
 ...-forensic-who-changed-when-authorized.yaml |  54 +++++
 ...009-synchronous-commit-before-success.yaml |  56 +++++
 ...010-fsi-field-level-audit-granularity.yaml |  57 +++++
 ...ross-site-audit-replication-hashchain.yaml |  62 ++++++
 ...-retention-outlives-referenced-entity.yaml |  56 +++++
 .../013-single-request-audit-record.yaml      |  54 +++++
 .../014-forensic-query-by-actor.yaml          |  53 +++++
 .../015-immutable-record-drift-detection.yaml |  57 +++++
 .../016-compliance-report-across-estate.yaml  |  56 +++++
 ...7-erasure-vs-immutable-audit-conflict.yaml |  60 +++++
 .../018-meta-audit-who-read-the-log.yaml      |  54 +++++
 .../019-clock-skew-cross-site-ordering.yaml   |  56 +++++
 ...20-policy-decision-version-provenance.yaml |  53 +++++
 .../001-provision-host-from-intent.yaml       |  49 ++++
 .../002-host-rehydration-replay-intent.yaml   |  58 +++++
 .../001-typed-outputs-declared-per-type.yaml  |  52 +++++
 ...02-undeclared-output-binding-rejected.yaml |  51 +++++
 .../003-fleet-output-coverage-queryable.yaml  |  51 +++++
 ...perative-playbook-to-composite-intent.yaml |  63 ++++++
 .../004-worked-example-currency-per-type.yaml |  51 +++++
 ...01-discovered-only-unclaimed-resource.yaml |  59 +++++
 .../002-adopt-preserving-entity-uuid.yaml     |  56 +++++
 ...elate-entity-across-discovery-sources.yaml |  56 +++++
 .../004-long-lived-unclaimed-antipattern.yaml |  61 +++++
 .../005-discovered-vs-realized-drift.yaml     |  59 +++++
 .../006-brownfield-estate-full-ingestion.yaml |  63 ++++++
 ...-discovered-resource-unknown-provider.yaml |  59 +++++
 .../008-adopt-attaching-intent.yaml           |  60 +++++
 ...stream-retention-vs-durable-inventory.yaml |  56 +++++
 .../010-adopt-resource-violating-policy.yaml  |  59 +++++
 ...1-rediscovery-idempotent-no-duplicate.yaml |  56 +++++
 .../012-discovered-orphan-no-owner.yaml       |  62 ++++++
 ...13-discovered-then-externally-retired.yaml |  59 +++++
 ...rtial-discovery-incomplete-attributes.yaml |  61 +++++
 .../015-brownfield-dependency-inference.yaml  |  62 ++++++
 ...-adopt-embedded-plaintext-credentials.yaml |  62 ++++++
 .../017-conflicting-discovery-sources.yaml    |  62 ++++++
 ...discover-sovereign-jurisdiction-adopt.yaml |  62 ++++++
 ...019-reject-adoption-unknown-udlm-type.yaml |  61 +++++
 ...covery-source-disconnect-partial-scan.yaml |  61 +++++
 ...01-single-provider-baseline-placement.yaml |  54 +++++
 .../002-multi-provider-scored-selection.yaml  |  57 +++++
 .../003-all-providers-capacity-exhausted.yaml |  57 +++++
 ...4-sovereignty-allowed-zones-placement.yaml |  60 +++++
 .../005-sovereign-no-in-zone-capacity.yaml    |  61 +++++
 ...006-attestation-floor-gates-placement.yaml |  57 +++++
 .../007-attestation-floor-none-qualify.yaml   |  57 +++++
 ...-time-sync-capability-floor-placement.yaml |  58 +++++
 ...-affinity-colocation-across-resources.yaml |  56 +++++
 ...010-anti-affinity-fault-domain-spread.yaml |  57 +++++
 .../011-validate-and-reserve-hold.yaml        |  56 +++++
 .../012-reservation-released-on-abort.yaml    |  60 +++++
 .../013-reservation-reconcile-stalemate.yaml  |  59 +++++
 ...t-criteria-from-parent-reserved-facts.yaml |  59 +++++
 .../015-in-place-capacity-expansion.yaml      |  57 +++++
 .../016-provider-capability-mismatch.yaml     |  57 +++++
 ...rovider-failure-mid-dispatch-rollback.yaml |  58 +++++
 .../018-peer-dcm-capacity-spillover.yaml      |  59 +++++
 ...-peer-dcm-disconnect-during-selection.yaml |  59 +++++
 .../020-gpu-class-scored-multi-provider.yaml  |  58 +++++
 .../001-additive-auto-adopted-continuous.yaml |  52 +++++
 .../002-additive-deferred-to-window.yaml      |  51 +++++
 .../003-breaking-full-ceremony.yaml           |  54 +++++
 .../004-out-of-window-refused.yaml            |  48 ++++
 .../005-staged-rollout-tiers.yaml             |  54 +++++
 .../006-expedite-break-glass.yaml             |  52 +++++
 .../007-freeze-queues-adoptions.yaml          |  53 +++++
 .../008-intra-estate-ordered-propagation.yaml |  55 +++++
 ...009-storage-array-maintenance-ordered.yaml |  67 ++++++
 .../010-mid-maintenance-failure-dr-hold.yaml  |  59 +++++
 .../011-dr-pairing-declared-and-walkable.yaml |  53 +++++
 ...share-cutover-verifiable-from-outputs.yaml |  55 +++++
 ...ows-sourced-from-information-provider.yaml |  56 +++++
 .../014-multi-source-authority-declared.yaml  |  56 +++++
 .../015-stale-knowledge-fails-closed.yaml     |  60 +++++
 ...16-change-policy-changes-are-governed.yaml |  58 +++++
 ...7-whole-provider-retirement-wind-down.yaml |  61 +++++
 .../001-additive-base-element-propagates.yaml |  54 +++++
 ...aking-base-underdeclared-bump-refused.yaml |  51 +++++
 ...breaking-base-blast-radius-enumerated.yaml |  55 +++++
 ...04-intra-registry-version-pin-refused.yaml |  50 +++++
 ...ization-pin-honored-with-visible-debt.yaml |  59 +++++
 .../006-pin-ahead-or-unknown-refused.yaml     |  49 ++++
 ...ue-green-unpin-promoted-on-clean-diff.yaml |  51 +++++
 ...-blue-green-promotion-refused-on-diff.yaml |  52 +++++
 .../009-element-scope-move-is-breaking.yaml   |  50 +++++
 ...-spec-declares-compilation-provenance.yaml |  55 +++++
 .../011-historical-chain-reconstruction.yaml  |  54 +++++
 .../012-provenance-mismatch-refused.yaml      |  51 +++++
 .../013-provider-internal-change-is-free.yaml |  54 +++++
 .../014-provider-surface-change-versions.yaml |  59 +++++
 ...-underdeclared-surface-change-refused.yaml |  54 +++++
 ...ability-evolves-without-sibling-churn.yaml |  59 +++++
 ...-envelope-set-semantics-and-whole-pin.yaml |  59 +++++
 .../018-capability-level-blue-green.yaml      |  56 +++++
 ...isplaced-plane-classification-refused.yaml |  58 +++++
 ...ance-stable-under-capability-movement.yaml |  64 ++++++
 ...2-operation-on-grandfathered-instance.yaml |  64 ++++++
 .../001-quota-headroom-check.yaml             |  61 +++++
 .../002-quota-exhaustion-blocks-request.yaml  |  63 ++++++
 ...3-quota-increase-request-budget-gated.yaml |  61 +++++
 .../004-budget-gate-routes-to-approval.yaml   |  67 ++++++
 .../005-per-tenant-cost-rollup.yaml           |  63 ++++++
 ...06-chargeback-shared-pool-attribution.yaml |  65 ++++++
 ...007-cost-follows-ownership-stake-edge.yaml |  59 +++++
 ...008-shared-allocatable-split-by-stake.yaml |  62 ++++++
 .../009-showback-vs-chargeback.yaml           |  60 +++++
 .../010-amortized-capex-vs-opex.yaml          |  65 ++++++
 .../011-focus-cost-columns-cluster.yaml       |  62 ++++++
 .../012-external-metering-no-cost-model.yaml  |  59 +++++
 ...apacity-reservation-cost-implications.yaml |  65 ++++++
 .../014-cost-based-provider-selection.yaml    |  64 ++++++
 .../015-cross-tenant-cost-leakage-denied.yaml |  64 ++++++
 .../016-multi-currency-fx-normalization.yaml  |  64 ++++++
 ...ission-releases-quota-final-statement.yaml |  65 ++++++
 .../018-usage-drift-exceeds-quota.yaml        |  63 ++++++
 .../019-commitment-discount-amortization.yaml |  65 ++++++
 .../020-unallocated-cost-tag-bucket.yaml      |  64 ++++++
 .../001-issue-scoped-credential.yaml          |  54 +++++
 .../002-value-never-stored-metadata-only.yaml |  57 +++++
 .../hammer-credentials/003-jit-issuance.yaml  |  58 +++++
 ...04-routine-rotation-parallel-validity.yaml |  59 +++++
 .../005-emergency-rotation-compromise.yaml    |  61 +++++
 .../006-expiry-mid-dispatch.yaml              |  59 +++++
 .../007-expiry-drift-detection.yaml           |  56 +++++
 .../008-revocation-sla-propagation.yaml       |  57 +++++
 .../009-actor-deprovision-cascade-revoke.yaml |  61 +++++
 .../010-decommission-blocked-unrevocable.yaml |  61 +++++
 .../011-credential-as-dependency.yaml         |  61 +++++
 .../012-bootstrap-first-provider.yaml         |  61 +++++
 .../013-unscoped-interaction-403.yaml         |  57 +++++
 ...014-cross-tenant-credential-isolation.yaml |  59 +++++
 .../015-cross-dcm-credential-scope.yaml       |  61 +++++
 .../016-sovereign-ip-binding.yaml             |  61 +++++
 .../017-fsi-hsm-attestation.yaml              |  61 +++++
 .../018-rehydration-reissue-credentials.yaml  |  61 +++++
 .../019-brownfield-credential-ingest.yaml     |  58 +++++
 .../020-credential-lifecycle-audit-trail.yaml |  55 +++++
 .../001-vm-provision-configure-patch-e2e.yaml |  63 ++++++
 ...mposite-workflow-3tier-ordered-update.yaml |  62 ++++++
 ...3-rolling-os-update-node-pool-partial.yaml |  64 ++++++
 .../004-patch-fail-midrun-rollback.yaml       |  62 ++++++
 ...-upgrade-job-exceeds-deadline-timeout.yaml |  61 +++++
 ...-drift-remediation-ansible-reconverge.yaml |  62 ++++++
 ...kup-then-restore-rehydration-faithful.yaml |  62 ++++++
 ...e-out-add-members-resource-exhaustion.yaml |  64 ++++++
 ...ay2-update-approval-ladder-escalation.yaml |  61 +++++
 .../010-awx-workflow-atomic-opaque-call.yaml  |  61 +++++
 .../011-cert-credential-rotation-day2.yaml    |  60 +++++
 ...are-update-baremetal-provider-failure.yaml |  64 ++++++
 ...-expiry-triggers-decommission-process.yaml |  61 +++++
 ...undle-layer-consumed-policy-violation.yaml |  63 ++++++
 ...load-provision-configure-image-update.yaml |  62 ++++++
 ...ss-provider-update-data-inconsistency.yaml |  64 ++++++
 ...mposite-decommission-partial-rollback.yaml |  63 ++++++
 .../018-sovereign-airgap-patch-attest.yaml    |  63 ++++++
 .../001-leaf-resource-clean-teardown.yaml     |  53 +++++
 ...-dangling-dependents-block-or-cascade.yaml |  54 +++++
 ...003-reverse-dependency-order-teardown.yaml |  55 +++++
 ...-shareable-pool-active-stakes-blocked.yaml |  55 +++++
 .../005-crypto-shred-kek-destroy.yaml         |  63 ++++++
 ...6-credential-unrevocable-compensation.yaml |  61 +++++
 .../007-composite-constituent-order.yaml      |  54 +++++
 .../008-free-allocation-back-to-pool.yaml     |  54 +++++
 .../009-partial-failure-compensation.yaml     |  60 +++++
 ...010-audit-retention-past-decommission.yaml |  53 +++++
 .../011-fault-domain-aware-teardown.yaml      |  59 +++++
 .../012-unrealized-intent-discard.yaml        |  50 +++++
 .../013-idempotent-re-decommission.yaml       |  54 +++++
 .../014-sovereign-in-region-destruction.yaml  |  60 +++++
 ...015-shared-credential-peer-dcm-in-use.yaml |  62 ++++++
 .../016-legal-hold-blocks-decommission.yaml   |  57 +++++
 ...17-grace-period-soft-then-hard-delete.yaml |  55 +++++
 .../018-cross-tenant-shared-pool-cascade.yaml |  59 +++++
 ...vider-unreachable-unconfirmed-destroy.yaml |  59 +++++
 .../020-cross-domain-dangling-payload.yaml    |  61 +++++
 ...01-faithful-single-stateless-baseline.yaml |  65 ++++++
 .../002-rehydrate-from-intent-only.yaml       |  67 ++++++
 .../003-uuid-preservation-across-rebuild.yaml |  64 ++++++
 .../004-provider-portable-single-happy.yaml   |  67 ++++++
 .../005-rehydrate-from-requested-only.yaml    |  64 ++++++
 .../006-rehydrate-from-realized-facts.yaml    |  65 ++++++
 .../007-idempotent-re-rehydration-noop.yaml   |  63 ++++++
 .../008-single-resource-data-migration.yaml   |  65 ++++++
 ...009-provider-gone-portable-substitute.yaml |  67 ++++++
 .../010-provider-gone-faithful-blocked.yaml   |  67 ++++++
 .../011-partial-dr-some-resources-fail.yaml   |  65 ++++++
 ...12-policy-changed-current-eval-blocks.yaml |  67 ++++++
 ...olicy-changed-pinned-config-preserved.yaml |  68 ++++++
 .../014-dependency-cycle-ordering.yaml        |  66 ++++++
 ...015-sovereignty-conflict-new-provider.yaml |  69 ++++++
 ...016-concurrent-rehydration-live-drift.yaml |  65 ++++++
 ...7-composite-per-constituent-migration.yaml |  66 ++++++
 .../018-full-stack-governance-matrix.yaml     |  67 ++++++
 .../019-peer-dcm-rehydration-disconnect.yaml  |  67 ++++++
 ...020-credential-expiry-mid-rehydration.yaml |  68 ++++++
 .../001-snapshot-vs-discovered.yaml           |  62 ++++++
 ...-unsanctioned-provider-change-flagged.yaml |  65 ++++++
 .../003-recovery-policy-fires-on-drift.yaml   |  64 ++++++
 .../004-reconciliation-loop-fixed-point.yaml  |  66 ++++++
 .../005-minor-drift-tolerated.yaml            |  63 ++++++
 .../006-significant-drift-remediated.yaml     |  65 ++++++
 .../007-critical-drift-halt-and-freeze.yaml   |  66 ++++++
 ...8-reconcile-budget-exhausted-escalate.yaml |  65 ++++++
 ...rized-provider-change-writes-realized.yaml |  64 ++++++
 .../010-drift-on-policy-locked-field.yaml     |  66 ++++++
 ...11-out-of-band-edit-diverges-realized.yaml |  67 ++++++
 .../012-remediation-redispatch-converge.yaml  |  66 ++++++
 .../013-drift-cascade-dependents.yaml         |  67 ++++++
 ...4-drift-detection-provider-disconnect.yaml |  68 ++++++
 ...-concurrent-drift-during-modification.yaml |  67 ++++++
 ...16-remediation-blocked-by-sovereignty.yaml |  69 ++++++
 .../017-flapping-no-fixed-point.yaml          |  67 ++++++
 ...8-correct-immutable-realized-directly.yaml |  66 ++++++
 ...lent-drift-below-discovery-resolution.yaml |  67 ++++++
 .../020-fleet-wide-drift-sweep-reconcile.yaml |  68 ++++++
 .../001-peer-provider-realization.yaml        |  58 +++++
 .../002-federated-routing-policy.yaml         |  58 +++++
 .../003-peer-disconnect-mid-order.yaml        |  60 +++++
 .../004-cross-dcm-causal-ordering.yaml        |  60 +++++
 .../005-cross-signed-audit-checkpoint.yaml    |  57 +++++
 .../006-split-brain-single-writer.yaml        |  60 +++++
 .../007-peer-ahead-model-version.yaml         |  59 +++++
 .../008-federated-contribution-admission.yaml |  57 +++++
 ...009-sovereign-peer-local-audit-export.yaml |  58 +++++
 .../010-peer-attestation-gate.yaml            |  61 +++++
 .../011-peer-catalog-discovery.yaml           |  50 +++++
 .../012-peer-liveness-heartbeat.yaml          |  56 +++++
 .../013-cross-dcm-hard-dependency.yaml        |  61 +++++
 .../014-federated-capacity-borrow.yaml        |  59 +++++
 .../015-peer-credential-scoping.yaml          |  58 +++++
 ...-peer-decommission-dangling-dependent.yaml |  60 +++++
 .../017-federated-drift-detection.yaml        |  59 +++++
 ...18-peer-provider-portable-rehydration.yaml |  64 ++++++
 .../019-cross-peer-policy-conflict.yaml       |  61 +++++
 .../020-peer-audit-chain-verification.yaml    |  60 +++++
 .../001-operational-dependency-cascade.yaml   |  63 ++++++
 .../002-operational-transitive-refusal.yaml   |  61 +++++
 .../003-request-dependency-atomic.yaml        |  62 ++++++
 ...04-request-vs-operational-distinction.yaml |  60 +++++
 .../005-convergence-window.yaml               |  63 ++++++
 .../006-soft-operational-does-not-block.yaml  |  60 +++++
 .../007-pending-converges-later.yaml          |  60 +++++
 .../008-surface-names-root.yaml               |  59 +++++
 .../009-surfacing-mandatory.yaml              |  58 +++++
 .../001-provision-spoke-via-hub.yaml          |  49 ++++
 .../002-move-cluster-between-hubs.yaml        |  51 +++++
 ...hub-jurisdiction-vs-spoke-sovereignty.yaml |  54 +++++
 .../004-self-managed-hub-rehydration.yaml     |  54 +++++
 .../001-cross-tenant-read-denied.yaml         |  58 +++++
 .../002-decommission-shared-pool-stakes.yaml  |  60 +++++
 .../003-per-tenant-profile-override.yaml      |  55 +++++
 .../004-tenant-quota-exhaustion.yaml          |  55 +++++
 .../005-shared-ipaddresspool-isolation.yaml   |  61 +++++
 ...6-ownership-transfer-whole-allocation.yaml |  57 +++++
 .../007-cross-tenant-uuid-reference.yaml      |  57 +++++
 .../008-tenant-scoped-rls-store-boundary.yaml |  57 +++++
 ...-decommission-unrevocable-credentials.yaml |  61 +++++
 .../010-tenant-boundary-dcmgroup.yaml         |  55 +++++
 .../011-new-tenant-onboarding.yaml            |  54 +++++
 .../012-tenant-scoped-audit-isolation.yaml    |  56 +++++
 .../013-noisy-neighbor-fair-share.yaml        |  60 +++++
 .../014-per-tenant-residency-enforcement.yaml |  58 +++++
 ...-cross-tenant-dependency-decommission.yaml |  58 +++++
 ...16-shared-pool-chargeback-attribution.yaml |  58 +++++
 ...-peer-dcm-tenant-federation-isolation.yaml |  62 ++++++
 .../018-tenant-scoped-drift-detection.yaml    |  58 +++++
 .../019-credential-expiry-mid-dispatch.yaml   |  62 ++++++
 .../020-brownfield-tenant-attribution.yaml    |  56 +++++
 .../001-cross-tenant-reference-refused.yaml   |  67 ++++++
 .../002-sovereignty-egress-refused.yaml       |  71 ++++++
 ...003-inline-credential-literal-refused.yaml |  64 ++++++
 ...004-undeclared-output-binding-refused.yaml |  68 ++++++
 ...-provider-capability-mismatch-refused.yaml |  69 ++++++
 .../006-masked-projection-write-refused.yaml  |  72 ++++++
 .../001-vlan-create-simple.yaml               |  53 +++++
 .../002-static-reservation-adr023.yaml        |  56 +++++
 ...03-connection-profile-nmstate-realize.yaml |  55 +++++
 .../004-dns-zone-record-create.yaml           |  53 +++++
 ...ddress-from-pool-allocation-ownership.yaml |  61 +++++
 .../006-address-pool-exhaustion.yaml          |  57 +++++
 .../007-vlan-shared-tenant-stakes.yaml        |  60 +++++
 .../008-vlan-reference-vs-inline.yaml         |  58 +++++
 ...ivity-ordering-network-before-compute.yaml |  56 +++++
 .../010-address-service-boot-dependency.yaml  |  58 +++++
 .../011-l3-gateway-nat-acl.yaml               |  57 +++++
 ...network-provider-failure-midprovision.yaml |  58 +++++
 .../013-dual-stack-ipv6-address.yaml          |  55 +++++
 .../014-bond-bridge-interface-topology.yaml   |  56 +++++
 .../015-cross-tenant-vlan-leakage-denied.yaml |  59 +++++
 ...vlan-decommission-dangling-interfaces.yaml |  57 +++++
 .../017-network-drift-manual-ip-change.yaml   |  56 +++++
 .../018-network-brownfield-ingestion.yaml     |  58 +++++
 .../019-sovereign-egress-region-lock.yaml     |  63 ++++++
 ...0-network-fabric-rehydration-ordering.yaml |  60 +++++
 ...nected-cross-dcm-resource-realization.yaml |  57 +++++
 ...2-connected-peer-capability-discovery.yaml |  56 +++++
 ...cted-federated-placement-across-peers.yaml |  56 +++++
 ...ross-dcm-dependency-spanning-boundary.yaml |  57 +++++
 ...peer-owned-reference-governed-resolve.yaml |  58 +++++
 ...ed-federated-blast-radius-across-peer.yaml |  58 +++++
 ...ected-peer-disconnect-mid-realization.yaml |  56 +++++
 ...d-peer-unreachable-placement-fallback.yaml |  58 +++++
 ...cted-degraded-federated-query-partial.yaml |  57 +++++
 ...connected-peer-reconnect-resync-drift.yaml |  57 +++++
 ...reign-peer-federation-residency-gated.yaml |  57 +++++
 ...ereign-cross-jurisdiction-peer-denied.yaml |  58 +++++
 ...reign-fsi-peer-attestation-gate-stale.yaml |  56 +++++
 ...eign-peer-realized-residency-verified.yaml |  56 +++++
 ...-cross-dcm-rehydration-pending-review.yaml |  59 +++++
 .../016-open-peer-capability-exchange.yaml    |  56 +++++
 ...7-open-federated-placement-permissive.yaml |  57 +++++
 .../018-dev-peer-federation-smoke-test.yaml   |  55 +++++
 ...-dev-peer-disconnect-recovery-sandbox.yaml |  57 +++++
 .../020-dev-cross-dcm-dependency-test.yaml    |  57 +++++
 .../001-precedence-chain-domain-order.yaml    |  67 ++++++
 .../002-hard-deny-unoverridable.yaml          |  67 ++++++
 .../003-governance-matrix-cross-boundary.yaml |  69 ++++++
 ...004-policy-blocked-resolution-options.yaml |  64 ++++++
 .../005-override-dual-approval.yaml           |  66 ++++++
 .../006-decidable-not-routed-to-review.yaml   |  61 +++++
 .../007-shadow-mode-evaluation.yaml           |  65 ++++++
 ...mpliance-revalidate-assembled-payload.yaml |  66 ++++++
 ...9-three-state-out-of-scope-not-passed.yaml |  63 ++++++
 ...ride-injected-as-constraint-on-resume.yaml |  68 ++++++
 ...011-policy-language-agnostic-contract.yaml |  62 ++++++
 .../012-baseline-single-validation-pass.yaml  |  59 +++++
 .../013-soft-enforcement-warns-allows.yaml    |  60 +++++
 .../014-tenant-cannot-loosen-system-deny.yaml |  63 ++++++
 .../015-override-expiry-mid-flight.yaml       |  65 ++++++
 ...16-override-scope-no-sibling-widening.yaml |  64 ++++++
 ...ation-of-duties-approver-is-requester.yaml |  65 ++++++
 ...18-shadow-divergence-gates-activation.yaml |  64 ++++++
 .../019-cross-tenant-matrix-denied.yaml       |  65 ++++++
 .../020-escalation-only-when-undecidable.yaml |  69 ++++++
 .../001-engine-migration-canary-cutover.yaml  |  52 +++++
 .../002-blue-green-engine-verification.yaml   |  52 +++++
 .../003-automation-staged-promotion.yaml      |  52 +++++
 ...-process-portability-structural-query.yaml |  50 +++++
 .../005-engine-upgrade-regression.yaml        |  51 +++++
 ...r-class-vm-vmware-to-ocpvirt-portable.yaml |  61 +++++
 ...r-class-nsx-to-ovn-remainder-surfaced.yaml |  62 ++++++
 ...er-class-ec2-to-ocpvirt-mover-timeout.yaml |  60 +++++
 ...ovider-class-target-capacity-rollback.yaml |  58 +++++
 ...er-class-residency-policy-blocks-port.yaml |  59 +++++
 ...class-vm-to-container-portable-subset.yaml |  57 +++++
 ...ss-container-to-vm-kernel-requirement.yaml |  55 +++++
 ...ype-class-vm-to-baremetal-performance.yaml |  56 +++++
 ...base-class-composite-port-spans-bases.yaml |  57 +++++
 ...ss-block-to-fileshare-storage-cousins.yaml |  56 +++++
 ...usin-placement-vm-container-baremetal.yaml |  56 +++++
 ...omposite-mixed-vm-container-baremetal.yaml |  56 +++++
 ...in-fallback-vm-exhausted-to-container.yaml |  57 +++++
 ...er-class-peer-dcm-disconnect-mid-port.yaml |  59 +++++
 ...class-partial-composite-db-tier-fails.yaml |  60 +++++
 ...r-class-rehydration-portable-new-uuid.yaml |  59 +++++
 ...-nonportable-native-standard-surfaced.yaml |  59 +++++
 ...-cross-provider-class-post-port-drift.yaml |  57 +++++
 ...e-class-brownfield-port-unknown-class.yaml |  56 +++++
 ...-class-decommission-source-after-port.yaml |  57 +++++
 ...ped-class-base-to-provider-resolution.yaml |  64 ++++++
 ...ss-capability-filter-narrows-eligible.yaml |  68 ++++++
 ...lass-element-custodied-not-translated.yaml |  63 ++++++
 ...r-class-element-survives-modification.yaml |  64 ++++++
 ...ferences-edge-baremetal-in-datacenter.yaml |  62 ++++++
 ...e-policy-over-all-pointing-to-dc-east.yaml |  65 ++++++
 ...al-projection-residency-onto-workload.yaml |  65 ++++++
 ...al-projection-unresolved-source-field.yaml |  66 ++++++
 ...-egress-release-confidentiality-block.yaml |  66 ++++++
 ...gress-admission-redact-high-assurance.yaml |  68 ++++++
 ...trant-policy-reconverges-on-injection.yaml |  63 ++++++
 ...cycle-detected-nondeterminism-stopped.yaml |  64 ++++++
 ...ation-restore-in-place-preserves-uuid.yaml |  65 ++++++
 ...ation-rebuild-new-uuid-pending-review.yaml |  69 ++++++
 ...15-sbom-cve-blast-radius-reverse-walk.yaml |  68 ++++++
 ...r-discovers-knowledge-records-timeout.yaml |  64 ++++++
 ...ection-covers-applies-on-intersection.yaml |  63 ++++++
 ...-layer-injection-skip-excludes-entity.yaml |  65 ++++++
 .../001-cross-border-migration-denied.yaml    |  68 ++++++
 .../002-data-at-rest-named-jurisdiction.yaml  |  64 ++++++
 ...-jurisdiction-falls-out-of-compliance.yaml |  71 ++++++
 ...-sub-processor-disclosure-requirement.yaml |  66 ++++++
 ...vernment-access-risk-gating-placement.yaml |  65 ++++++
 ...r-gapped-offline-sovereign-deployment.yaml |  68 ++++++
 ...residency-conflict-during-rehydration.yaml |  70 ++++++
 ...t-sovereign-profile-standard-platform.yaml |  69 ++++++
 ...ent-plane-attestation-data-vs-control.yaml |  70 ++++++
 ...fication-expiry-triggers-reevaluation.yaml |  70 ++++++
 ...11-residency-tag-validation-single-vm.yaml |  62 ++++++
 ...sovereign-region-placement-happy-path.yaml |  61 +++++
 ...-reject-request-no-compliant-provider.yaml |  65 ++++++
 .../014-data-residency-label-drift.yaml       |  66 ++++++
 ...ommission-in-jurisdiction-destruction.yaml |  66 ++++++
 .../016-cross-tenant-residency-isolation.yaml |  69 ++++++
 ...eer-dcm-federation-residency-boundary.yaml |  71 ++++++
 ...18-sovereign-backup-replica-residency.yaml |  66 ++++++
 ...9-brownfield-ingest-unknown-residency.yaml |  68 ++++++
 ...ncryption-key-residency-sovereign-kms.yaml |  69 ++++++
 .../001-allocate-volume-from-pool.yaml        |  57 +++++
 .../002-zfs-pool-dataset-hierarchy.yaml       |  55 +++++
 .../003-dataset-snapshot-restore.yaml         |  56 +++++
 .../004-file-share-export-host-dataset.yaml   |  58 +++++
 .../005-file-share-export-block-volume.yaml   |  60 +++++
 .../006-shared-pool-quota-enforcement.yaml    |  59 +++++
 .../007-thin-provision-overcommit-denied.yaml |  59 +++++
 .../008-volume-online-resize.yaml             |  56 +++++
 ...igrate-volume-cross-provider-identity.yaml |  61 +++++
 ...10-migrate-target-capability-mismatch.yaml |  61 +++++
 .../011-provider-failure-queue-writes.yaml    |  59 +++++
 ...12-write-once-snapshot-store-contract.yaml |  59 +++++
 ...mmutable-snapshot-early-delete-denied.yaml |  61 +++++
 .../014-consistency-model-declaration.yaml    |  56 +++++
 .../015-data-mobility-sovereignty-change.yaml |  61 +++++
 ...6-volume-residency-placement-enforced.yaml |  62 ++++++
 ...17-cross-tenant-volume-leakage-denied.yaml |  58 +++++
 .../018-dataset-replication-peer-dcm.yaml     |  62 ++++++
 .../019-data-migration-in-rehydration.yaml    |  60 +++++
 ...20-decommission-pool-dangling-volumes.yaml |  60 +++++
 ...ded-pool-drift-and-member-replacement.yaml |  58 +++++
 ...02-declare-hardware-raid-at-provision.yaml |  54 +++++
 ...003-composed-topology-fault-tolerance.yaml |  58 +++++
 ...backend-aggregation-and-pool-boundary.yaml |  56 +++++
 ...golden-vm-image-clean-promote-ocpvirt.yaml |  64 ++++++
 ...ntainer-image-cve-gate-reject-ocpvirt.yaml |  64 ++++++
 ...age-missing-attestation-reject-metal3.yaml |  66 ++++++
 ...004-new-cve-blast-radius-reverse-walk.yaml |  66 ++++++
 ...igh-impact-base-image-approval-ladder.yaml |  65 ++++++
 .../006-scan-job-deadline-timeout-vmware.yaml |  62 ++++++
 ...arch-image-partial-promotion-kubevirt.yaml |  65 ++++++
 .../008-bad-promote-rollback-ocpvirt.yaml     |  64 ++++++
 ...ifact-store-residency-firmware-metal3.yaml |  63 ++++++
 ...-cross-class-rollout-vm-and-container.yaml |  65 ++++++
 ...ncompatible-dependency-reject-ocpvirt.yaml |  65 ++++++
 ...012-peer-dcm-pull-disconnect-kubevirt.yaml |  64 ++++++
 ...013-supersede-canonical-image-ocpvirt.yaml |  62 ++++++
 ...po-quota-exhausted-large-image-vmware.yaml |  64 ++++++
 ...mware-package-attested-promote-metal3.yaml |  64 ++++++
 ...d-unmanaged-image-quarantine-kubevirt.yaml |  68 ++++++
 ...ation-expiry-demote-canonical-ocpvirt.yaml |  65 ++++++
 ...offline-mirror-package-promote-metal3.yaml |  65 ++++++
 .../001-reference-discipline-enforced.yaml    |  53 +++++
 .../002-adopts-registration-parity.yaml       |  49 ++++
 .../003-relationship-target-integrity.yaml    |  53 +++++
 .../001-string-matches-existing-element.yaml  |  47 ++++
 .../002-net-new-string-minted-at-scope.yaml   |  49 ++++
 ...03-proposed-promotes-through-curation.yaml |  49 ++++
 .../004-near-match-never-silently-bound.yaml  |  52 +++++
 ...strict-profile-unknown-string-refused.yaml |  47 ++++
 ...-vocabulary-changes-by-change-control.yaml |  54 +++++
 .../identity/actor-authentication.yaml        |  61 +++++
 .../auth-provider-drift-detection.yaml        |  72 ++++++
 .../identity/connected-delegation.yaml        |  69 ++++++
 .../identity-reference-data-model.yaml        |  59 +++++
 .../bare-metal-pxe-bootstrap.yaml             |  62 ++++++
 .../infrastructure/cluster-bootstrap.yaml     |  62 ++++++
 .../control-plane-deployment.yaml             |  60 +++++
 .../profile-based-deployment.yaml             |  67 ++++++
 .../001-external-consumer-conformance.yaml    |  60 +++++
 .../drift-detection-remediation.yaml          |  71 ++++++
 .../rehydration-rto-measurement.yaml          |  65 ++++++
 .../telemetry-export-capability.yaml          |  59 +++++
 .../telemetry-udlm-data-model.yaml            |  55 +++++
 .../udlm-universal-telemetry-export.yaml      |  83 +++++++
 .../osac/001-cloud-provider-registration.yaml |  60 +++++
 .../002-sovereign-capacity-advertisement.yaml |  59 +++++
 .../003-cloud-rehydration-from-intent.yaml    |  61 +++++
 .../004-provider-portability-new-cloud.yaml   |  59 +++++
 .../001-portfolio-rollup-and-gaps.yaml        |  60 +++++
 .../002-team-health-blocked-intents.yaml      |  59 +++++
 512 files changed, 31332 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/stress-testing-process.md
 create mode 100644 dav/use-cases/DIMENSION-VOCABULARY.yaml
 create mode 100644 dav/use-cases/PERSONAS.yaml
 create mode 100644 dav/use-cases/architecture/001-solution-architecture-decomposition.yaml
 create mode 100644 dav/use-cases/compute/idempotent-reconvergence.yaml
 create mode 100644 dav/use-cases/compute/tenancy-data-model.yaml
 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/compute/vm-tenant-isolation-enforcement.yaml
 create mode 100644 dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml
 create mode 100644 dav/use-cases/cross-domain/brownfield-adoption-capability.yaml
 create mode 100644 dav/use-cases/cross-domain/brownfield-adoption-data-model.yaml
 create mode 100644 dav/use-cases/cross-domain/composite-service-provision.yaml
 create mode 100644 dav/use-cases/cross-domain/composite-service-to-catalog-item.yaml
 create mode 100644 dav/use-cases/cross-domain/cross-dcm-audit-data-model.yaml
 create mode 100644 dav/use-cases/cross-domain/dynamic-rehydration.yaml
 create mode 100644 dav/use-cases/cross-domain/peer-coordination-capability.yaml
 create mode 100644 dav/use-cases/cross-domain/profile-approved-list-data-model.yaml
 create mode 100644 dav/use-cases/cross-domain/profile-resolution-capability.yaml
 create mode 100644 dav/use-cases/cross-domain/provider-portable-rebuild.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/four-state-store-conformance.yaml
 create mode 100644 dav/use-cases/data/persistent-volume-provision.yaml
 create mode 100644 dav/use-cases/governance/audit-chain-data-model.yaml
 create mode 100644 dav/use-cases/governance/audit-chain-output-verification.yaml
 create mode 100644 dav/use-cases/governance/audit-chain-proofs-capability.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-applicability-data-model.yaml
 create mode 100644 dav/use-cases/governance/policy-override-approval.yaml
 create mode 100644 dav/use-cases/governance/policy-resolution-capability.yaml
 create mode 100644 dav/use-cases/governance/sovereignty-validation-policy.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/001-field-provenance-chain.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/002-audit-record-vs-object-history.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/003-tamper-evidence-inclusion-proof.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/004-tamper-evidence-consistency-proof.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/005-audit-store-outage-gap-record.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/006-governance-honesty-ungoverned-not-passed.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/007-compliance-gate-blocks-nonconformant.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/008-forensic-who-changed-when-authorized.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/009-synchronous-commit-before-success.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/010-fsi-field-level-audit-granularity.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/011-cross-site-audit-replication-hashchain.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/012-retention-outlives-referenced-entity.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/013-single-request-audit-record.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/014-forensic-query-by-actor.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/015-immutable-record-drift-detection.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/016-compliance-report-across-estate.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/017-erasure-vs-immutable-audit-conflict.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/018-meta-audit-who-read-the-log.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/019-clock-skew-cross-site-ordering.yaml
 create mode 100644 dav/use-cases/hammer-audit-compliance/020-policy-decision-version-provenance.yaml
 create mode 100644 dav/use-cases/hammer-bare-metal/001-provision-host-from-intent.yaml
 create mode 100644 dav/use-cases/hammer-bare-metal/002-host-rehydration-replay-intent.yaml
 create mode 100644 dav/use-cases/hammer-binding-surface/001-typed-outputs-declared-per-type.yaml
 create mode 100644 dav/use-cases/hammer-binding-surface/002-undeclared-output-binding-rejected.yaml
 create mode 100644 dav/use-cases/hammer-binding-surface/003-fleet-output-coverage-queryable.yaml
 create mode 100644 dav/use-cases/hammer-binding-surface/004-imperative-playbook-to-composite-intent.yaml
 create mode 100644 dav/use-cases/hammer-binding-surface/004-worked-example-currency-per-type.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/001-discovered-only-unclaimed-resource.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/002-adopt-preserving-entity-uuid.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/003-correlate-entity-across-discovery-sources.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/004-long-lived-unclaimed-antipattern.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/005-discovered-vs-realized-drift.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/006-brownfield-estate-full-ingestion.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/007-discovered-resource-unknown-provider.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/008-adopt-attaching-intent.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/009-discovery-stream-retention-vs-durable-inventory.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/010-adopt-resource-violating-policy.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/011-rediscovery-idempotent-no-duplicate.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/012-discovered-orphan-no-owner.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/013-discovered-then-externally-retired.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/014-partial-discovery-incomplete-attributes.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/015-brownfield-dependency-inference.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/016-adopt-embedded-plaintext-credentials.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/017-conflicting-discovery-sources.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/018-discover-sovereign-jurisdiction-adopt.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/019-reject-adoption-unknown-udlm-type.yaml
 create mode 100644 dav/use-cases/hammer-brownfield-discovery/020-discovery-source-disconnect-partial-scan.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/001-single-provider-baseline-placement.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/002-multi-provider-scored-selection.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/003-all-providers-capacity-exhausted.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/004-sovereignty-allowed-zones-placement.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/005-sovereign-no-in-zone-capacity.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/006-attestation-floor-gates-placement.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/007-attestation-floor-none-qualify.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/008-time-sync-capability-floor-placement.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/009-affinity-colocation-across-resources.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/010-anti-affinity-fault-domain-spread.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/011-validate-and-reserve-hold.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/012-reservation-released-on-abort.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/013-reservation-reconcile-stalemate.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/014-dependent-criteria-from-parent-reserved-facts.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/015-in-place-capacity-expansion.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/016-provider-capability-mismatch.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/017-provider-failure-mid-dispatch-rollback.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/018-peer-dcm-capacity-spillover.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/019-peer-dcm-disconnect-during-selection.yaml
 create mode 100644 dav/use-cases/hammer-capacity-placement/020-gpu-class-scored-multi-provider.yaml
 create mode 100644 dav/use-cases/hammer-change-control/001-additive-auto-adopted-continuous.yaml
 create mode 100644 dav/use-cases/hammer-change-control/002-additive-deferred-to-window.yaml
 create mode 100644 dav/use-cases/hammer-change-control/003-breaking-full-ceremony.yaml
 create mode 100644 dav/use-cases/hammer-change-control/004-out-of-window-refused.yaml
 create mode 100644 dav/use-cases/hammer-change-control/005-staged-rollout-tiers.yaml
 create mode 100644 dav/use-cases/hammer-change-control/006-expedite-break-glass.yaml
 create mode 100644 dav/use-cases/hammer-change-control/007-freeze-queues-adoptions.yaml
 create mode 100644 dav/use-cases/hammer-change-control/008-intra-estate-ordered-propagation.yaml
 create mode 100644 dav/use-cases/hammer-change-control/009-storage-array-maintenance-ordered.yaml
 create mode 100644 dav/use-cases/hammer-change-control/010-mid-maintenance-failure-dr-hold.yaml
 create mode 100644 dav/use-cases/hammer-change-control/011-dr-pairing-declared-and-walkable.yaml
 create mode 100644 dav/use-cases/hammer-change-control/012-share-cutover-verifiable-from-outputs.yaml
 create mode 100644 dav/use-cases/hammer-change-control/013-windows-sourced-from-information-provider.yaml
 create mode 100644 dav/use-cases/hammer-change-control/014-multi-source-authority-declared.yaml
 create mode 100644 dav/use-cases/hammer-change-control/015-stale-knowledge-fails-closed.yaml
 create mode 100644 dav/use-cases/hammer-change-control/016-change-policy-changes-are-governed.yaml
 create mode 100644 dav/use-cases/hammer-change-control/017-whole-provider-retirement-wind-down.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/001-additive-base-element-propagates.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/002-breaking-base-underdeclared-bump-refused.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/003-breaking-base-blast-radius-enumerated.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/004-intra-registry-version-pin-refused.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/005-organization-pin-honored-with-visible-debt.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/006-pin-ahead-or-unknown-refused.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/007-blue-green-unpin-promoted-on-clean-diff.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/008-blue-green-promotion-refused-on-diff.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/009-element-scope-move-is-breaking.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/010-generated-spec-declares-compilation-provenance.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/011-historical-chain-reconstruction.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/012-provenance-mismatch-refused.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/013-provider-internal-change-is-free.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/014-provider-surface-change-versions.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/015-provider-underdeclared-surface-change-refused.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/016-capability-evolves-without-sibling-churn.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/017-envelope-set-semantics-and-whole-pin.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/018-capability-level-blue-green.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/019-misplaced-plane-classification-refused.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/020-realized-instance-stable-under-capability-movement.yaml
 create mode 100644 dav/use-cases/hammer-class-versioning/021-day2-operation-on-grandfathered-instance.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/001-quota-headroom-check.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/002-quota-exhaustion-blocks-request.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/003-quota-increase-request-budget-gated.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/004-budget-gate-routes-to-approval.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/005-per-tenant-cost-rollup.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/006-chargeback-shared-pool-attribution.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/007-cost-follows-ownership-stake-edge.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/008-shared-allocatable-split-by-stake.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/009-showback-vs-chargeback.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/010-amortized-capex-vs-opex.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/011-focus-cost-columns-cluster.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/012-external-metering-no-cost-model.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/013-capacity-reservation-cost-implications.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/014-cost-based-provider-selection.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/015-cross-tenant-cost-leakage-denied.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/016-multi-currency-fx-normalization.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/017-decommission-releases-quota-final-statement.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/018-usage-drift-exceeds-quota.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/019-commitment-discount-amortization.yaml
 create mode 100644 dav/use-cases/hammer-cost-quota/020-unallocated-cost-tag-bucket.yaml
 create mode 100644 dav/use-cases/hammer-credentials/001-issue-scoped-credential.yaml
 create mode 100644 dav/use-cases/hammer-credentials/002-value-never-stored-metadata-only.yaml
 create mode 100644 dav/use-cases/hammer-credentials/003-jit-issuance.yaml
 create mode 100644 dav/use-cases/hammer-credentials/004-routine-rotation-parallel-validity.yaml
 create mode 100644 dav/use-cases/hammer-credentials/005-emergency-rotation-compromise.yaml
 create mode 100644 dav/use-cases/hammer-credentials/006-expiry-mid-dispatch.yaml
 create mode 100644 dav/use-cases/hammer-credentials/007-expiry-drift-detection.yaml
 create mode 100644 dav/use-cases/hammer-credentials/008-revocation-sla-propagation.yaml
 create mode 100644 dav/use-cases/hammer-credentials/009-actor-deprovision-cascade-revoke.yaml
 create mode 100644 dav/use-cases/hammer-credentials/010-decommission-blocked-unrevocable.yaml
 create mode 100644 dav/use-cases/hammer-credentials/011-credential-as-dependency.yaml
 create mode 100644 dav/use-cases/hammer-credentials/012-bootstrap-first-provider.yaml
 create mode 100644 dav/use-cases/hammer-credentials/013-unscoped-interaction-403.yaml
 create mode 100644 dav/use-cases/hammer-credentials/014-cross-tenant-credential-isolation.yaml
 create mode 100644 dav/use-cases/hammer-credentials/015-cross-dcm-credential-scope.yaml
 create mode 100644 dav/use-cases/hammer-credentials/016-sovereign-ip-binding.yaml
 create mode 100644 dav/use-cases/hammer-credentials/017-fsi-hsm-attestation.yaml
 create mode 100644 dav/use-cases/hammer-credentials/018-rehydration-reissue-credentials.yaml
 create mode 100644 dav/use-cases/hammer-credentials/019-brownfield-credential-ingest.yaml
 create mode 100644 dav/use-cases/hammer-credentials/020-credential-lifecycle-audit-trail.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/001-vm-provision-configure-patch-e2e.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/002-composite-workflow-3tier-ordered-update.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/003-rolling-os-update-node-pool-partial.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/004-patch-fail-midrun-rollback.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/005-upgrade-job-exceeds-deadline-timeout.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/006-drift-remediation-ansible-reconverge.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/007-backup-then-restore-rehydration-faithful.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/008-scale-out-add-members-resource-exhaustion.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/009-day2-update-approval-ladder-escalation.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/010-awx-workflow-atomic-opaque-call.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/011-cert-credential-rotation-day2.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/012-firmware-update-baremetal-provider-failure.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/013-ttl-expiry-triggers-decommission-process.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/014-config-bundle-layer-consumed-policy-violation.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/015-container-workload-provision-configure-image-update.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/016-cross-provider-update-data-inconsistency.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/017-composite-decommission-partial-rollback.yaml
 create mode 100644 dav/use-cases/hammer-day0-day2-ops/018-sovereign-airgap-patch-attest.yaml
 create mode 100644 dav/use-cases/hammer-decommission/001-leaf-resource-clean-teardown.yaml
 create mode 100644 dav/use-cases/hammer-decommission/002-dangling-dependents-block-or-cascade.yaml
 create mode 100644 dav/use-cases/hammer-decommission/003-reverse-dependency-order-teardown.yaml
 create mode 100644 dav/use-cases/hammer-decommission/004-shareable-pool-active-stakes-blocked.yaml
 create mode 100644 dav/use-cases/hammer-decommission/005-crypto-shred-kek-destroy.yaml
 create mode 100644 dav/use-cases/hammer-decommission/006-credential-unrevocable-compensation.yaml
 create mode 100644 dav/use-cases/hammer-decommission/007-composite-constituent-order.yaml
 create mode 100644 dav/use-cases/hammer-decommission/008-free-allocation-back-to-pool.yaml
 create mode 100644 dav/use-cases/hammer-decommission/009-partial-failure-compensation.yaml
 create mode 100644 dav/use-cases/hammer-decommission/010-audit-retention-past-decommission.yaml
 create mode 100644 dav/use-cases/hammer-decommission/011-fault-domain-aware-teardown.yaml
 create mode 100644 dav/use-cases/hammer-decommission/012-unrealized-intent-discard.yaml
 create mode 100644 dav/use-cases/hammer-decommission/013-idempotent-re-decommission.yaml
 create mode 100644 dav/use-cases/hammer-decommission/014-sovereign-in-region-destruction.yaml
 create mode 100644 dav/use-cases/hammer-decommission/015-shared-credential-peer-dcm-in-use.yaml
 create mode 100644 dav/use-cases/hammer-decommission/016-legal-hold-blocks-decommission.yaml
 create mode 100644 dav/use-cases/hammer-decommission/017-grace-period-soft-then-hard-delete.yaml
 create mode 100644 dav/use-cases/hammer-decommission/018-cross-tenant-shared-pool-cascade.yaml
 create mode 100644 dav/use-cases/hammer-decommission/019-provider-unreachable-unconfirmed-destroy.yaml
 create mode 100644 dav/use-cases/hammer-decommission/020-cross-domain-dangling-payload.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/001-faithful-single-stateless-baseline.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/002-rehydrate-from-intent-only.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/003-uuid-preservation-across-rebuild.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/004-provider-portable-single-happy.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/005-rehydrate-from-requested-only.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/006-rehydrate-from-realized-facts.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/007-idempotent-re-rehydration-noop.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/008-single-resource-data-migration.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/009-provider-gone-portable-substitute.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/010-provider-gone-faithful-blocked.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/011-partial-dr-some-resources-fail.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/012-policy-changed-current-eval-blocks.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/013-policy-changed-pinned-config-preserved.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/014-dependency-cycle-ordering.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/015-sovereignty-conflict-new-provider.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/016-concurrent-rehydration-live-drift.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/017-composite-per-constituent-migration.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/018-full-stack-governance-matrix.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/019-peer-dcm-rehydration-disconnect.yaml
 create mode 100644 dav/use-cases/hammer-dr-rehydration/020-credential-expiry-mid-rehydration.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/001-snapshot-vs-discovered.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/002-unsanctioned-provider-change-flagged.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/003-recovery-policy-fires-on-drift.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/004-reconciliation-loop-fixed-point.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/005-minor-drift-tolerated.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/006-significant-drift-remediated.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/007-critical-drift-halt-and-freeze.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/008-reconcile-budget-exhausted-escalate.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/009-authorized-provider-change-writes-realized.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/010-drift-on-policy-locked-field.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/011-out-of-band-edit-diverges-realized.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/012-remediation-redispatch-converge.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/013-drift-cascade-dependents.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/014-drift-detection-provider-disconnect.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/015-concurrent-drift-during-modification.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/016-remediation-blocked-by-sovereignty.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/017-flapping-no-fixed-point.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/018-correct-immutable-realized-directly.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/019-silent-drift-below-discovery-resolution.yaml
 create mode 100644 dav/use-cases/hammer-drift-recovery/020-fleet-wide-drift-sweep-reconcile.yaml
 create mode 100644 dav/use-cases/hammer-federation/001-peer-provider-realization.yaml
 create mode 100644 dav/use-cases/hammer-federation/002-federated-routing-policy.yaml
 create mode 100644 dav/use-cases/hammer-federation/003-peer-disconnect-mid-order.yaml
 create mode 100644 dav/use-cases/hammer-federation/004-cross-dcm-causal-ordering.yaml
 create mode 100644 dav/use-cases/hammer-federation/005-cross-signed-audit-checkpoint.yaml
 create mode 100644 dav/use-cases/hammer-federation/006-split-brain-single-writer.yaml
 create mode 100644 dav/use-cases/hammer-federation/007-peer-ahead-model-version.yaml
 create mode 100644 dav/use-cases/hammer-federation/008-federated-contribution-admission.yaml
 create mode 100644 dav/use-cases/hammer-federation/009-sovereign-peer-local-audit-export.yaml
 create mode 100644 dav/use-cases/hammer-federation/010-peer-attestation-gate.yaml
 create mode 100644 dav/use-cases/hammer-federation/011-peer-catalog-discovery.yaml
 create mode 100644 dav/use-cases/hammer-federation/012-peer-liveness-heartbeat.yaml
 create mode 100644 dav/use-cases/hammer-federation/013-cross-dcm-hard-dependency.yaml
 create mode 100644 dav/use-cases/hammer-federation/014-federated-capacity-borrow.yaml
 create mode 100644 dav/use-cases/hammer-federation/015-peer-credential-scoping.yaml
 create mode 100644 dav/use-cases/hammer-federation/016-peer-decommission-dangling-dependent.yaml
 create mode 100644 dav/use-cases/hammer-federation/017-federated-drift-detection.yaml
 create mode 100644 dav/use-cases/hammer-federation/018-peer-provider-portable-rehydration.yaml
 create mode 100644 dav/use-cases/hammer-federation/019-cross-peer-policy-conflict.yaml
 create mode 100644 dav/use-cases/hammer-federation/020-peer-audit-chain-verification.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/001-operational-dependency-cascade.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/002-operational-transitive-refusal.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/003-request-dependency-atomic.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/004-request-vs-operational-distinction.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/005-convergence-window.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/006-soft-operational-does-not-block.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/007-pending-converges-later.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/008-surface-names-root.yaml
 create mode 100644 dav/use-cases/hammer-intent-fulfillment/009-surfacing-mandatory.yaml
 create mode 100644 dav/use-cases/hammer-multi-cluster/001-provision-spoke-via-hub.yaml
 create mode 100644 dav/use-cases/hammer-multi-cluster/002-move-cluster-between-hubs.yaml
 create mode 100644 dav/use-cases/hammer-multi-cluster/003-hub-jurisdiction-vs-spoke-sovereignty.yaml
 create mode 100644 dav/use-cases/hammer-multi-cluster/004-self-managed-hub-rehydration.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/001-cross-tenant-read-denied.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/002-decommission-shared-pool-stakes.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/003-per-tenant-profile-override.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/004-tenant-quota-exhaustion.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/005-shared-ipaddresspool-isolation.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/006-ownership-transfer-whole-allocation.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/007-cross-tenant-uuid-reference.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/008-tenant-scoped-rls-store-boundary.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/009-decommission-unrevocable-credentials.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/010-tenant-boundary-dcmgroup.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/011-new-tenant-onboarding.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/012-tenant-scoped-audit-isolation.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/013-noisy-neighbor-fair-share.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/014-per-tenant-residency-enforcement.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/015-cross-tenant-dependency-decommission.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/016-shared-pool-chargeback-attribution.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/017-peer-dcm-tenant-federation-isolation.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/018-tenant-scoped-drift-detection.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/019-credential-expiry-mid-dispatch.yaml
 create mode 100644 dav/use-cases/hammer-multi-tenancy/020-brownfield-tenant-attribution.yaml
 create mode 100644 dav/use-cases/hammer-must-reject/001-cross-tenant-reference-refused.yaml
 create mode 100644 dav/use-cases/hammer-must-reject/002-sovereignty-egress-refused.yaml
 create mode 100644 dav/use-cases/hammer-must-reject/003-inline-credential-literal-refused.yaml
 create mode 100644 dav/use-cases/hammer-must-reject/004-undeclared-output-binding-refused.yaml
 create mode 100644 dav/use-cases/hammer-must-reject/005-provider-capability-mismatch-refused.yaml
 create mode 100644 dav/use-cases/hammer-must-reject/006-masked-projection-write-refused.yaml
 create mode 100644 dav/use-cases/hammer-networking/001-vlan-create-simple.yaml
 create mode 100644 dav/use-cases/hammer-networking/002-static-reservation-adr023.yaml
 create mode 100644 dav/use-cases/hammer-networking/003-connection-profile-nmstate-realize.yaml
 create mode 100644 dav/use-cases/hammer-networking/004-dns-zone-record-create.yaml
 create mode 100644 dav/use-cases/hammer-networking/005-ipaddress-from-pool-allocation-ownership.yaml
 create mode 100644 dav/use-cases/hammer-networking/006-address-pool-exhaustion.yaml
 create mode 100644 dav/use-cases/hammer-networking/007-vlan-shared-tenant-stakes.yaml
 create mode 100644 dav/use-cases/hammer-networking/008-vlan-reference-vs-inline.yaml
 create mode 100644 dav/use-cases/hammer-networking/009-connectivity-ordering-network-before-compute.yaml
 create mode 100644 dav/use-cases/hammer-networking/010-address-service-boot-dependency.yaml
 create mode 100644 dav/use-cases/hammer-networking/011-l3-gateway-nat-acl.yaml
 create mode 100644 dav/use-cases/hammer-networking/012-network-provider-failure-midprovision.yaml
 create mode 100644 dav/use-cases/hammer-networking/013-dual-stack-ipv6-address.yaml
 create mode 100644 dav/use-cases/hammer-networking/014-bond-bridge-interface-topology.yaml
 create mode 100644 dav/use-cases/hammer-networking/015-cross-tenant-vlan-leakage-denied.yaml
 create mode 100644 dav/use-cases/hammer-networking/016-vlan-decommission-dangling-interfaces.yaml
 create mode 100644 dav/use-cases/hammer-networking/017-network-drift-manual-ip-change.yaml
 create mode 100644 dav/use-cases/hammer-networking/018-network-brownfield-ingestion.yaml
 create mode 100644 dav/use-cases/hammer-networking/019-sovereign-egress-region-lock.yaml
 create mode 100644 dav/use-cases/hammer-networking/020-network-fabric-rehydration-ordering.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/001-connected-cross-dcm-resource-realization.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/002-connected-peer-capability-discovery.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/003-connected-federated-placement-across-peers.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/004-connected-cross-dcm-dependency-spanning-boundary.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/005-connected-peer-owned-reference-governed-resolve.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/006-connected-federated-blast-radius-across-peer.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/007-disconnected-peer-disconnect-mid-realization.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/008-disconnected-peer-unreachable-placement-fallback.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/009-disconnected-degraded-federated-query-partial.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/010-disconnected-peer-reconnect-resync-drift.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/011-sovereign-peer-federation-residency-gated.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/012-sovereign-cross-jurisdiction-peer-denied.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/013-sovereign-fsi-peer-attestation-gate-stale.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/014-sovereign-peer-realized-residency-verified.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/015-sovereign-cross-dcm-rehydration-pending-review.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/016-open-peer-capability-exchange.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/017-open-federated-placement-permissive.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/018-dev-peer-federation-smoke-test.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/019-dev-peer-disconnect-recovery-sandbox.yaml
 create mode 100644 dav/use-cases/hammer-peer-dcm/020-dev-cross-dcm-dependency-test.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/001-precedence-chain-domain-order.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/002-hard-deny-unoverridable.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/003-governance-matrix-cross-boundary.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/004-policy-blocked-resolution-options.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/005-override-dual-approval.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/006-decidable-not-routed-to-review.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/007-shadow-mode-evaluation.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/008-compliance-revalidate-assembled-payload.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/009-three-state-out-of-scope-not-passed.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/010-override-injected-as-constraint-on-resume.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/011-policy-language-agnostic-contract.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/012-baseline-single-validation-pass.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/013-soft-enforcement-warns-allows.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/014-tenant-cannot-loosen-system-deny.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/015-override-expiry-mid-flight.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/016-override-scope-no-sibling-widening.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/017-separation-of-duties-approver-is-requester.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/018-shadow-divergence-gates-activation.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/019-cross-tenant-matrix-denied.yaml
 create mode 100644 dav/use-cases/hammer-policy-override/020-escalation-only-when-undecidable.yaml
 create mode 100644 dav/use-cases/hammer-process-migration/001-engine-migration-canary-cutover.yaml
 create mode 100644 dav/use-cases/hammer-process-migration/002-blue-green-engine-verification.yaml
 create mode 100644 dav/use-cases/hammer-process-migration/003-automation-staged-promotion.yaml
 create mode 100644 dav/use-cases/hammer-process-migration/004-process-portability-structural-query.yaml
 create mode 100644 dav/use-cases/hammer-process-migration/005-engine-upgrade-regression.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/001-cross-provider-class-vm-vmware-to-ocpvirt-portable.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/002-cross-provider-class-nsx-to-ovn-remainder-surfaced.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/003-cross-provider-class-ec2-to-ocpvirt-mover-timeout.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/004-cross-provider-class-target-capacity-rollback.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/005-cross-provider-class-residency-policy-blocks-port.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/006-cross-type-class-vm-to-container-portable-subset.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/007-cross-type-class-container-to-vm-kernel-requirement.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/008-cross-type-class-vm-to-baremetal-performance.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/009-cross-base-class-composite-port-spans-bases.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/010-cross-base-class-block-to-fileshare-storage-cousins.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/011-cross-cousin-placement-vm-container-baremetal.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/012-cross-cousin-composite-mixed-vm-container-baremetal.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/013-cross-cousin-fallback-vm-exhausted-to-container.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/014-cross-provider-class-peer-dcm-disconnect-mid-port.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/015-cross-provider-class-partial-composite-db-tier-fails.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/016-cross-provider-class-rehydration-portable-new-uuid.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/017-cross-provider-class-nonportable-native-standard-surfaced.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/018-cross-provider-class-post-port-drift.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/019-cross-base-class-brownfield-port-unknown-class.yaml
 create mode 100644 dav/use-cases/hammer-provider-portability/020-cross-provider-class-decommission-source-after-port.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/001-scoped-class-base-to-provider-resolution.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/002-scoped-class-capability-filter-narrows-eligible.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/003-provider-class-element-custodied-not-translated.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/004-provider-class-element-survives-modification.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/005-references-edge-baremetal-in-datacenter.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/006-references-edge-policy-over-all-pointing-to-dc-east.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/007-navigational-projection-residency-onto-workload.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/008-navigational-projection-unresolved-source-field.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/009-firewall-egress-release-confidentiality-block.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/010-firewall-ingress-admission-redact-high-assurance.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/011-reentrant-policy-reconverges-on-injection.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/012-policy-cycle-detected-nondeterminism-stopped.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/013-rehydration-restore-in-place-preserves-uuid.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/014-rehydration-rebuild-new-uuid-pending-review.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/015-sbom-cve-blast-radius-reverse-walk.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/016-scanner-discovers-knowledge-records-timeout.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/017-layer-injection-covers-applies-on-intersection.yaml
 create mode 100644 dav/use-cases/hammer-recent-model/018-layer-injection-skip-excludes-entity.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/001-cross-border-migration-denied.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/002-data-at-rest-named-jurisdiction.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/003-provider-jurisdiction-falls-out-of-compliance.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/004-sub-processor-disclosure-requirement.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/005-government-access-risk-gating-placement.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/006-air-gapped-offline-sovereign-deployment.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/007-residency-conflict-during-rehydration.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/008-per-tenant-sovereign-profile-standard-platform.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/009-enforcement-plane-attestation-data-vs-control.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/010-certification-expiry-triggers-reevaluation.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/011-residency-tag-validation-single-vm.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/012-sovereign-region-placement-happy-path.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/013-reject-request-no-compliant-provider.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/014-data-residency-label-drift.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/015-sovereign-decommission-in-jurisdiction-destruction.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/016-cross-tenant-residency-isolation.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/017-peer-dcm-federation-residency-boundary.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/018-sovereign-backup-replica-residency.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/019-brownfield-ingest-unknown-residency.yaml
 create mode 100644 dav/use-cases/hammer-sovereignty/020-encryption-key-residency-sovereign-kms.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/001-allocate-volume-from-pool.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/002-zfs-pool-dataset-hierarchy.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/003-dataset-snapshot-restore.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/004-file-share-export-host-dataset.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/005-file-share-export-block-volume.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/006-shared-pool-quota-enforcement.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/007-thin-provision-overcommit-denied.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/008-volume-online-resize.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/009-migrate-volume-cross-provider-identity.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/010-migrate-target-capability-mismatch.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/011-provider-failure-queue-writes.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/012-write-once-snapshot-store-contract.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/013-immutable-snapshot-early-delete-denied.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/014-consistency-model-declaration.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/015-data-mobility-sovereignty-change.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/016-volume-residency-placement-enforced.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/017-cross-tenant-volume-leakage-denied.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/018-dataset-replication-peer-dcm.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/019-data-migration-in-rehydration.yaml
 create mode 100644 dav/use-cases/hammer-storage-mobility/020-decommission-pool-dangling-volumes.yaml
 create mode 100644 dav/use-cases/hammer-storage-redundancy/001-degraded-pool-drift-and-member-replacement.yaml
 create mode 100644 dav/use-cases/hammer-storage-redundancy/002-declare-hardware-raid-at-provision.yaml
 create mode 100644 dav/use-cases/hammer-storage-redundancy/003-composed-topology-fault-tolerance.yaml
 create mode 100644 dav/use-cases/hammer-storage-redundancy/004-backend-aggregation-and-pool-boundary.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/001-golden-vm-image-clean-promote-ocpvirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/002-base-container-image-cve-gate-reject-ocpvirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/003-os-package-missing-attestation-reject-metal3.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/004-new-cve-blast-radius-reverse-walk.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/005-high-impact-base-image-approval-ladder.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/006-scan-job-deadline-timeout-vmware.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/007-multiarch-image-partial-promotion-kubevirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/008-bad-promote-rollback-ocpvirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/009-sovereign-artifact-store-residency-firmware-metal3.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/010-cross-class-rollout-vm-and-container.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/011-license-incompatible-dependency-reject-ocpvirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/012-peer-dcm-pull-disconnect-kubevirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/013-supersede-canonical-image-ocpvirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/014-repo-quota-exhausted-large-image-vmware.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/015-firmware-package-attested-promote-metal3.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/016-brownfield-unmanaged-image-quarantine-kubevirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/017-attestation-expiry-demote-canonical-ocpvirt.yaml
 create mode 100644 dav/use-cases/hammer-supply-chain-promotion/018-airgapped-offline-mirror-package-promote-metal3.yaml
 create mode 100644 dav/use-cases/hammer-type-standard/001-reference-discipline-enforced.yaml
 create mode 100644 dav/use-cases/hammer-type-standard/002-adopts-registration-parity.yaml
 create mode 100644 dav/use-cases/hammer-type-standard/003-relationship-target-integrity.yaml
 create mode 100644 dav/use-cases/hammer-vocabulary-intake/001-string-matches-existing-element.yaml
 create mode 100644 dav/use-cases/hammer-vocabulary-intake/002-net-new-string-minted-at-scope.yaml
 create mode 100644 dav/use-cases/hammer-vocabulary-intake/003-proposed-promotes-through-curation.yaml
 create mode 100644 dav/use-cases/hammer-vocabulary-intake/004-near-match-never-silently-bound.yaml
 create mode 100644 dav/use-cases/hammer-vocabulary-intake/005-strict-profile-unknown-string-refused.yaml
 create mode 100644 dav/use-cases/hammer-vocabulary-intake/006-curated-vocabulary-changes-by-change-control.yaml
 create mode 100644 dav/use-cases/identity/actor-authentication.yaml
 create mode 100644 dav/use-cases/identity/auth-provider-drift-detection.yaml
 create mode 100644 dav/use-cases/identity/connected-delegation.yaml
 create mode 100644 dav/use-cases/identity/identity-reference-data-model.yaml
 create mode 100644 dav/use-cases/infrastructure/bare-metal-pxe-bootstrap.yaml
 create mode 100644 dav/use-cases/infrastructure/cluster-bootstrap.yaml
 create mode 100644 dav/use-cases/infrastructure/control-plane-deployment.yaml
 create mode 100644 dav/use-cases/infrastructure/profile-based-deployment.yaml
 create mode 100644 dav/use-cases/integration/001-external-consumer-conformance.yaml
 create mode 100644 dav/use-cases/observability/drift-detection-remediation.yaml
 create mode 100644 dav/use-cases/observability/rehydration-rto-measurement.yaml
 create mode 100644 dav/use-cases/observability/telemetry-export-capability.yaml
 create mode 100644 dav/use-cases/observability/telemetry-udlm-data-model.yaml
 create mode 100644 dav/use-cases/observability/udlm-universal-telemetry-export.yaml
 create mode 100644 dav/use-cases/osac/001-cloud-provider-registration.yaml
 create mode 100644 dav/use-cases/osac/002-sovereign-capacity-advertisement.yaml
 create mode 100644 dav/use-cases/osac/003-cloud-rehydration-from-intent.yaml
 create mode 100644 dav/use-cases/osac/004-provider-portability-new-cloud.yaml
 create mode 100644 dav/use-cases/oversight/001-portfolio-rollup-and-gaps.yaml
 create mode 100644 dav/use-cases/oversight/002-team-health-blocked-intents.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..caf1a25
--- /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: `<trailing-handle-segment>.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-<hex>` 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/<date>/` 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_gating |
+  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..6c48abd
--- /dev/null
+++ b/dav/schemas/use_case.schema.json
@@ -0,0 +1,210 @@
+{
+  "$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",
+    "handle",
+    "version",
+    "scenario",
+    "generated_by"
+  ],
+  "properties": {
+    "uuid": {
+      "type": "string",
+      "pattern": "^uc-",
+      "description": "Stable unique id, server-owned. Form: 'uc-<uuid4>' for generated UCs, or a 'uc-<handle-slug>' for intentional seed handles. Never reused."
+    },
+    "handle": {
+      "type": "string",
+      "pattern": ".*/.*",
+      "description": "Human-readable '<domain>/<name>' path (e.g. 'compute/vm-standard-provision'). The leading segment groups the UC by domain; must match the file's location."
+    },
+    "version": {
+      "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",
+        "intent",
+        "success_criteria",
+        "dimensions",
+        "profile"
+      ],
+      "properties": {
+        "description": {
+          "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",
+              "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": [
+                "homelab",
+                "dev",
+                "standard",
+                "prod",
+                "fsi",
+                "sovereign"
+              ]
+            }
+          }
+        },
+        "intent": {
+          "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,
+          "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",
+            "policy_complexity",
+            "provider_landscape",
+            "governance_context",
+            "failure_mode"
+          ],
+          "properties": {
+            "lifecycle_phase": {
+              "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",
+              "description": "Shape/dependency complexity of the requested resource(s). Vocabulary (engine consumer_profile default): single_no_deps, hard_dependencies, composite_service, conditional_soft_deps, process_resource, cross_dependency_payload."
+            },
+            "policy_complexity": {
+              "type": "string",
+              "description": "The policy-evaluation complexity the scenario exercises. Vocabulary (engine consumer_profile default): system_defaults_only, single_validation, 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",
+              "description": "The provider landscape the scenario runs against. Vocabulary (engine consumer_profile default): single_eligible, multiple_eligible, none_eligible, peer_dcm_required, process_provider, mixed."
+            },
+            "governance_context": {
+              "type": "string",
+              "description": "The governance/compliance posture in force. Vocabulary: no_governance, standard_governance, audit_heavy, compliance_gated, sovereignty_enforced."
+            },
+            "failure_mode": {
+              "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": [
+            "homelab",
+            "dev",
+            "standard",
+            "prod",
+            "fsi",
+            "sovereign"
+          ]
+        },
+        "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": [
+              "domain",
+              "interaction"
+            ],
+            "properties": {
+              "domain": {
+                "type": "string",
+                "description": "The DCM domain touched: typically data, policy, provider, or audit."
+              },
+              "interaction": {
+                "type": "string",
+                "description": "What happens in that domain during the scenario."
+              }
+            }
+          }
+        }
+      }
+    },
+    "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",
+            "authoring"
+          ]
+        },
+        "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",
+            "human-authored"
+          ]
+        },
+        "model": {
+          "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",
+          "description": "ISO-8601 time the UC was generated/authored."
+        }
+      }
+    },
+    "metadata": {
+      "type": "object",
+      "description": "Admission/lifecycle bookkeeping (when admitted, under which DCM version, author, baseline lineage). Not part of the scenario semantics."
+    }
+  }
+}
diff --git a/dav/stress-testing-process.md b/dav/stress-testing-process.md
new file mode 100644
index 0000000..ea866c2
--- /dev/null
+++ b/dav/stress-testing-process.md
@@ -0,0 +1,73 @@
+# Stress-testing UDLM & DCM with DAV — a reusable process
+
+**What this is.** The repeatable procedure for pressure-testing the architecture (UDLM the data model, DCM
+the realization) by hammering it with **use cases** run through DAV's gap-analysis engine. A UC the
+architecture can't satisfy comes back `unsupported` / `partially_supported` — and *that verdict is a gap
+worth a decision*. The output of a run is two things: **a ranked list of architecture gaps**, and **candidate
+UDLM resource types** to close them.
+
+**Why it works.** DAV's whole value is *"propose use cases the architect didn't think of."* Hand-authored
+UCs test what you already have in mind; a few hundred **edge cases** — simple and complex, across the
+capabilities enterprises actually demand — find the corners the spec quietly doesn't cover. The engine turns
+"is this supported?" from an argument into a fingerprinted verdict.
+
+## The exemplar
+
+Your **canonical hand-authored UC set** — the reference set your architects curated — is the quality and style
+bar: scenario depth, the Data·Policy·Provider decomposition, dimension coverage, concrete capability. **Every
+generated UC is modeled on its shape.** Read a handful before generating so the corpus stays coherent, not a
+pile of shallow one-liners.
+
+## The process
+
+1. **Baseline — run the canonical sets.** Run your **canonical reference set** plus every scoping set tagged
+   **`hammer`** through the gap engine. Capture the verdict distribution (`supported` /
+   `partially_supported` / `unsupported`) and the gap factors. This is the "where do we stand today" snapshot
+   and the regression baseline for future runs.
+
+2. **Generate — hundreds of edge cases.** Fan out UC generation (parallel agents, or the console's UC-gen)
+   modeled on the exemplar: **simple AND complex**, covering the enterprise-capability surface (multi-tenant
+   isolation, sovereignty/residency, DR/rehydration, credential lifecycle, cost/chargeback, capacity &
+   quota, audit/compliance, federation, brownfield ingestion, decommission safety, day-2 drift, …). Volume is
+   the point — hundreds, not dozens. Organize into **scoping sets by capability/theme**.
+   - **Tag every generated UC with `generated_by` provenance** (`mode`, `source`, `model`, `prompt_version`).
+     This preserves an independent ground-truth signal: at any time you can slice "what does the framework
+     say about the UCs the *architect* wrote?" separately from verdicts on generated ones. Guards against
+     self-referential validation.
+
+3. **Analyze — run them through the engine.** Same gap-analysis pass. Rank by (a) how many distinct
+   high-priority UCs a single gap blocks (foundational gaps first) and (b) verdict severity.
+
+4. **Fill — where a gap meets a standard, add the type.** When a cluster of `unsupported` UCs needs a
+   capability the architecture lacks *and a real standard defines it*, create the new **UDLM resource type**
+   — never invent when a standard fits. Apply the adopt discipline: **standards-first**, produce the
+   **concrete field-level diff** (drop citation-only/ceremony adopts; a protocol RFC is not a data model),
+   be **net-negative on bespoke surface**, and ground every field in real **producers/consumers**. Ship as a
+   feature-branch PR (validators + estate-token gate green); the maintainer merges.
+
+5. **Report + admit — architect disposes.** Produce the run report: verdict distribution, the ranked gaps,
+   the new UCs/sets, and any proposed types with their standard + diff. **No auto-admission** — generated UCs
+   and new types are *candidates*; the architect reviews and admits. The framework proposes; the architect
+   disposes.
+
+## Both systems under test
+
+Run the same process against **UDLM** (does the *data model* express what the UC needs?) and **DCM** (does the
+*realization* — the runtime contracts, providers, policies — deliver it?). A UC can pass at the UDLM layer
+(the shape exists) yet gap at DCM (no provider/flow realizes it); keeping both in view is how the two-track
+model (intent vs realized) gets exercised, not just asserted.
+
+## Cadence
+
+Re-run after any material architecture change (a boundary sweep, a new capability program, a ratified ADR
+batch). The baseline from step 1 makes each run a regression check: gaps that were `unsupported` last time
+should be closing, and nothing previously `supported` should regress.
+
+## Discipline checklist
+
+- [ ] Generated UCs modeled on the reference set's depth (read a few first).
+- [ ] Every generated UC carries `generated_by` provenance.
+- [ ] Gaps ranked foundational-first (most UCs unblocked), not by raw count.
+- [ ] New types are standards-first with a concrete field diff — no ceremony adopts.
+- [ ] Nothing auto-admitted; the report is for the architect to disposition.
+- [ ] Baseline captured so the next run is a regression check.
diff --git a/dav/use-cases/DIMENSION-VOCABULARY.yaml b/dav/use-cases/DIMENSION-VOCABULARY.yaml
new file mode 100644
index 0000000..fb2b2fd
--- /dev/null
+++ b/dav/use-cases/DIMENSION-VOCABULARY.yaml
@@ -0,0 +1,80 @@
+# UC scenario-dimension vocabulary — the single source of truth
+#
+# What this settles: the closed set of legal values for each `scenario.dimensions.*` field in a
+# use case. The values were free strings enforced nowhere in-repo; the DAV engine carried its own
+# private list and silently quarantined anything outside it (2026-07-28 sweep, finding F1 — ~86%
+# of the corpus quarantined). This file is now authoritative; tests/check_uc_dimensions.py gates
+# every UC against it in both repos, and the DAV engine's runtime vocabulary MUST be reconciled
+# to this list (that is the one edit that lets the quarantined corpus back in).
+#
+# Discipline (per the capability-catalog lesson: synonyms silently miscount): one concept, one
+# value. Adding a value is a deliberate edit here first, then the UC. Near-duplicates were folded
+# to their majority form on 2026-07-27 (see `folded_aliases`).
+version: "1.0.0"
+dimensions:
+  lifecycle_phase:
+    - new_request
+    - modification
+    - day2_operations
+    - drift_detection
+    - decommission
+    - brownfield_ingestion
+    - rehydration_faithful
+    - rehydration_provider_portable
+    - provisioning
+    - recovery
+    - expiry_enforcement
+  resource_complexity:
+    - single_no_deps
+    - single_with_deps
+    - hard_dependencies
+    - composite_service
+    - cross_dependency_payload
+    - cross_domain_constraint
+    - full_stack
+    - multi_dependent
+  policy_complexity:
+    - no_policy
+    - system_defaults_only
+    - single_validation
+    - multi_validation
+    - multiple_interacting
+    - multi_policy_chain
+    - cross_domain_constraint
+    - governance_matrix_enforcement
+    - orchestration_flow_static
+    - recovery_policy
+    - human_escalation_required
+  provider_landscape:
+    - single_eligible
+    - multiple_eligible
+    - none_eligible
+    - mixed
+    - peer_dcm_required
+  governance_context:
+    - no_governance
+    - standard_governance
+    - internal_audit
+    - audit_heavy
+    - compliance_gated
+    - sovereignty_constrained
+    - sovereignty_enforced
+    - sovereign_mandate
+  failure_mode:
+    - happy_path
+    - policy_violation
+    - provider_failure
+    - single_provider_failure
+    - peer_dcm_disconnect
+    - component_failure
+    - infrastructure_loss
+    - data_inconsistency
+    - partial_fulfillment
+    - rollback_required
+    - resource_exhaustion
+    - timeout
+# Near-duplicates folded to majority form (2026-07-27) — the corpus edit accompanies this.
+folded_aliases:
+  lifecycle_phase: {decommissioning: decommission}
+  provider_landscape: {multi_eligible: multiple_eligible}
+  policy_complexity: {cross_domain: cross_domain_constraint}
diff --git a/dav/use-cases/PERSONAS.yaml b/dav/use-cases/PERSONAS.yaml
new file mode 100644
index 0000000..40d1f7a
--- /dev/null
+++ b/dav/use-cases/PERSONAS.yaml
@@ -0,0 +1,195 @@
+# Canonical persona set — the single source of truth for `scenario.actor.persona`.
+#
+# Why this file exists: the persona a use case is written from was a free string, enforced
+# nowhere, and had drifted to 12 distinct values across udlm + dcm (auditor vs compliance-auditor
+# vs compliance-officer; storage-admin/individual-developer singletons; sovereign-tenant-admin vs
+# tenant-admin). A DAV-private persona list would be the same fork DIM-001 just closed for the
+# dimension vocabulary, under a different name. This publishes the canonical set the model already
+# recognizes (docs/flows/by-persona.md) as a closed, single-sourced, CI-gated contract (PER-001),
+# so a consumer analyzing "from every stakeholder perspective" reads ONE list, not its own.
+#
+# `tier` groups personas by the NATURE of their stake, so a consumer's union-across-lenses can
+# treat a gap in one tier as different in kind from another:
+#   operational — build, operate, and consume the mechanism
+#   governance  — set, enforce, and validate the rules the platform must honor
+#   oversight   — accountable for outcomes; decide on risk and spend (the management chain)
+# The oversight tier demands aggregate/attestation/rollup surfaces, not per-resource mechanisms —
+# which is exactly what catches "the model surfaces a broken dependency to the operator but has no
+# portfolio-level gap rollup for the director."
+#
+# Each persona carries `objectives`: what a conforming spec must give that role — the platform
+# DEMANDS the persona makes. These are the per-lens analysis targets. Note the pleasing circularity
+# (DAV, 2026-07-27): ADR-003's own refusal-contract elements ARE implicit persona demands —
+# typed→platform-engineer, actionable→application-team-member, non-leaking→security-officer,
+# auditable→compliance-auditor, whole→application-team-member.
+#
+# Provenance: docs/flows/by-persona.md (the authored roles) + the high-frequency, clearly-distinct
+# roles already in dcm use (sre, security-officer, tenant-admin, finance-analyst); the oversight
+# chain (executive, director, manager); and the stakeholders the platform's own contracts imply but
+# no persona spoke for — provider-owner (ADR-005 / OIS), cloud-operator (OSAC — building sovereign
+# cloud providers, UC-04), information-provider-owner (INF- contract, change-control/013),
+# federation-peer-operator (FED- contract / peer DCMs), integrator (ADR-044 consumer surface),
+# sovereignty-authority (the
+# sovereignty-first data model), tenancy-authority (ADR-014 isolation + cross-tenant XTA), regulator
+# (AUD-006 external verification).
+# Mirror this file byte-identical to dav/use-cases/PERSONAS.yaml in croadfeldt/dcm.
+version: "1.0.0"
+
+personas:
+  # ---- operational: build, operate, and consume the mechanism ----
+  - id: solution-architect
+    tier: operational
+    framing: "an architect decomposing a whole architecture into ordered, portable resource requests"
+    objectives:
+      - "a whole architecture decomposes into typed resources with their dependency edges preserved"
+      - "portability holds — the same intent realizes across providers without a rewrite"
+
+  - id: application-team-member
+    tier: operational
+    framing: "an application owner whose team requests and consumes platform resources"
+    objectives:
+      - "I ask in portable terms and the system realizes it — no provider-native detail leaks up to me"
+      - "an unsatisfiable intent is surfaced to me, not buried in a field (actionable — ADR-003)"
+      - "a partial outcome is a whole, coherent result, never a silent half-realization (whole — ADR-003)"
+
+  - id: platform-operator
+    tier: operational
+    framing: "an operator modeling, registering, and running the estate"
+    objectives:
+      - "the dependency graph and realization ordering are first-class data I can query, not tribal knowledge"
+      - "a broken dependency surfaces with its blast radius before realization, naming the root"
+
+  - id: platform-engineer
+    tier: operational
+    framing: "an engineer building on and running day-2 of the platform"
+    objectives:
+      - "typed, stable error contracts I can branch on (typed — ADR-003)"
+      - "the dependency model distinguishes request vs operational natures (ADR-052)"
+
+  - id: sre
+    tier: operational
+    framing: "an SRE operating the running platform"
+    objectives:
+      - "defined enforcement points — no check-then-act races (ADR-011 validate-and-reserve)"
+      - "cascades are bounded and observable — a failure's reach is computed, not discovered in an incident"
+
+  - id: tenant-admin
+    tier: operational
+    framing: "a tenant administrator governing isolation and quota for a tenant"
+    objectives:
+      - "tenant isolation holds — no cross-tenant read or dispatch without an explicit, audited authorization"
+      - "quota and override are declared data, enforced at defined points, not ad hoc"
+
+  - id: finance-analyst
+    tier: operational
+    framing: "a finance analyst accountable for cost and usage"
+    objectives:
+      - "cost and usage are adopted from a standard (FOCUS) by reference, joinable to realized resources (T5)"
+      - "spend attributes to tenant, resource, and time without a bespoke parallel cost model"
+
+  - id: provider-owner
+    tier: operational
+    framing: "the owner operating a Service Provider that DCM registers and dispatches to"
+    objectives:
+      - "a stable, typed provider contract (OIS) I implement once — capability declared as data, not hard-coded into the platform (ADR-005)"
+      - "a sandbox-to-production graduation path with the conformance bar stated up front, so activation is predictable"
+      - "my provider stays swappable — the substrate never bakes in my native format; naturalization happens at my edge (T9 / DCM ADR-023)"
+
+  - id: cloud-operator
+    tier: operational
+    framing: "an operator building and running a sovereign cloud (e.g. OSAC) offered to the platform as a provider"
+    objectives:
+      - "my cloud's capacity and capabilities are declared as data and advertised for placement — the platform routes intent to me on capability, not hard-coded knowledge (PRV capability/capacity advertisement, §8.1a)"
+      - "building a new cloud provider adds a placement target without changing the substrate — intent places through the portable model, I naturalize at my edge and stay swappable (UC-04 OSAC placement; T9 / DCM ADR-023)"
+      - "my cloud is itself a UDLM-modeled estate — buildable and rehydratable from declared intent, its sovereignty (residency, jurisdiction) declared and provable"
+
+  - id: information-provider-owner
+    tier: operational
+    framing: "the owner operating an Information Provider that contributes authoritative data to the platform"
+    objectives:
+      - "my authoritative data is adopted by reference, not copied — the platform carries the join key and a version-pinned conformance reference (T5)"
+      - "my authority scope is respected — consumers resolve to me for the data I own, and my layer's provenance is preserved"
+
+  - id: federation-peer-operator
+    tier: operational
+    framing: "the operator of a peer DCM in a federation, receiving dispatched intent from other instances"
+    objectives:
+      - "cross-instance dispatch is sovereignty-scoped and on-behalf-of — I receive only what a peer is authorized to send, with the requester's identity intact"
+      - "I stay forward-compatible — unknown fields from a newer peer don't break me (must-ignore-unknown, ADR-044 / federation forward-compat)"
+
+  - id: integrator
+    tier: operational
+    framing: "an integrator building an external system on the UDLM data model — consuming or federating it"
+    objectives:
+      - "I declare the read surface I depend on and the registry gates on it; unknown fields I don't consume never break me (must-ignore-unknown, ADR-044)"
+      - "the contract is versioned with a compatibility promise I can pin to (ADR-051), so forward change doesn't silently break my integration"
+
+  # ---- governance: set, enforce, and validate the rules ----
+  - id: compliance-auditor
+    tier: governance
+    framing: "an auditor validating platform behavior after the fact"
+    objectives:
+      - "every decision and refusal leaves a tamper-evident record naming the identities and the deciding policy (auditable — ADR-003)"
+      - "field-level provenance traces every realized value to its origin"
+      - "audit integrity is provable — RFC 9162 Merkle inclusion/consistency proofs, not assertion (AUD-006)"
+
+  - id: security-officer
+    tier: governance
+    framing: "a security officer governing data exposure and trust boundaries"
+    objectives:
+      - "no reference or value leaves a boundary it was not released for (non-leaking — ADR-003; the policy information firewall)"
+      - "credential material is referenced, never carried inline in portable data"
+
+  - id: sovereignty-authority
+    tier: governance
+    framing: "a sovereignty authority accountable for where data and workloads may reside and move"
+    objectives:
+      - "residency and jurisdiction are declared constraints on the data, enforced before realization and on every cross-boundary move — not asserted after the fact"
+      - "a cross-border data flow is an explicit, governable edge I can see and deny (T4), never an opaque transfer"
+
+  - id: tenancy-authority
+    tier: governance
+    framing: "the party accountable for tenant isolation and cross-tenant authorization across the whole estate"
+    objectives:
+      - "tenant isolation holds across the whole estate — no tenant can read or dispatch into another, provable from the model, not asserted per-tenant (ADR-014)"
+      - "every cross-tenant flow is an explicit, audited authorization grant (the XTA capability), never an implicit reach"
+
+  - id: regulator
+    tier: governance
+    framing: "an external regulator or assessor validating platform behavior without trusting the operator"
+    objectives:
+      - "I verify audit integrity from a signed tree head and an inclusion proof alone — no access to the operator's database (RFC 9162 external verification, AUD-006)"
+      - "provenance and decisions are attributable to named identities and policies, independently checkable against the immutable record (ADR-051)"
+
+  # ---- oversight: accountable for outcomes; decide on risk and spend ----
+  - id: executive
+    tier: oversight
+    framing: "a CIO/CTO/CISO accountable for the platform's outcomes, risk, and spend at the organization level"
+    objectives:
+      - "I can trust that what is running is what was approved — attestation and immutable provenance, not a report someone typed (ADR-051, AUD-006)"
+      - "organizational risk exposure is computed and rolled up — sovereignty posture, blast radius, unmet obligations — not assembled by hand"
+      - "cost is governed at the org level against a standard, not reconciled from spreadsheets (T5/FOCUS)"
+
+  - id: director
+    tier: oversight
+    framing: "a director accountable for a portfolio of services and the teams that run them"
+    objectives:
+      - "my portfolio is one rolled-up view — health, compliance, and gaps across teams — derived from the graph, not chased team by team"
+      - "a gap or drift anywhere in the portfolio surfaces with its blast radius and the responsible team, before it becomes an incident"
+
+  - id: manager
+    tier: oversight
+    framing: "a manager accountable for a team's services — their delivery and operational health"
+    objectives:
+      - "my team's blocked or unsatisfiable intents surface with the root cause and owner (ADR-052 surfacing, scoped to the team)"
+      - "my team's capacity, cost, and policy posture are visible without standing up a bespoke report"
+
+# Drift → canonical. A use-case `scenario.actor.persona` may carry any key here; the PER-001 gate
+# resolves it to the canonical id. All folds ruled 2026-07-27 — each drift value decomposes into an
+# existing persona (rationale per line), so none needed its own.
+folded_aliases:
+  auditor: compliance-auditor              # by-persona.md names the role "compliance-auditor / auditor"
+  compliance-officer: compliance-auditor   # single-use drift synonym
+  individual-developer: application-team-member  # a solo consumer makes the same platform demands as a team consumer — no distinct lens
+  storage-admin: platform-operator         # operating one resource class is platform-operator scoped — no distinct nature
+  sovereign-tenant-admin: tenant-admin     # decomposes into tenant-admin + the sovereignty-authority lens; no separate persona
diff --git a/dav/use-cases/architecture/001-solution-architecture-decomposition.yaml b/dav/use-cases/architecture/001-solution-architecture-decomposition.yaml
new file mode 100644
index 0000000..dbaeba0
--- /dev/null
+++ b/dav/use-cases/architecture/001-solution-architecture-decomposition.yaml
@@ -0,0 +1,60 @@
+uuid: uc-8abcaeb0-79ce-4345-8152-845ef42394cc
+handle: architecture/solution-architecture-decomposition
+version: 1.0.0
+scenario:
+  description: >-
+    A solution-architect takes a whole architecture — a multi-tier application with its compute,
+    storage, network, and data dependencies — and decomposes it into typed, portable resource
+    requests with the dependency edges between them preserved. The output is not a diagram but an
+    intent: an ordered, dependency-aware set of resources the platform can realize, portable across
+    providers because nothing in it names a provider's native form. The architect's demand is that
+    the decomposition survives the round trip — the dependency structure they drew is the dependency
+    graph the platform realizes and orders against, and the same decomposition places onto any
+    eligible provider without a rewrite.
+  actor:
+    persona: solution-architect
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - cloud-operator
+    - provider-owner
+  intent: >-
+    Decompose a whole architecture into typed, portable resource requests with their dependency
+    edges preserved — an ordered intent the platform realizes and can place across providers without
+    a rewrite
+  success_criteria:
+  - The architecture decomposes into typed resources, each with its declared dependency edges
+  - The dependency structure the architect drew is the graph the platform orders realization against
+  - The decomposition is portable — nothing in it names a provider's native form
+  - The same decomposition is eligible to place onto any provider that satisfies the requirements
+  - The whole is realized as an ordered, dependency-aware set, not a flat list
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: full_stack
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the architecture becomes typed resources plus the dependency edges between them
+  - domain: policy
+    interaction: the dependency graph drives realization ordering; portability is validated
+  - domain: provider
+    interaction: the decomposition is eligible for any provider satisfying the requirements; none is named in it
+  - domain: audit
+    interaction: the decomposition, its dependency graph, and the realization order are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: osac-persona-coverage-2026-07-27
+  timestamp: '2026-07-27T19:00:00Z'
+tags:
+- architecture
+- solution-architect
+- decomposition
+- dependency-graph
+- portability
diff --git a/dav/use-cases/compute/idempotent-reconvergence.yaml b/dav/use-cases/compute/idempotent-reconvergence.yaml
new file mode 100644
index 0000000..bbcf9f7
--- /dev/null
+++ b/dav/use-cases/compute/idempotent-reconvergence.yaml
@@ -0,0 +1,66 @@
+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
+  perspectives:
+    - platform-operator
+    - sre
+  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
diff --git a/dav/use-cases/compute/tenancy-data-model.yaml b/dav/use-cases/compute/tenancy-data-model.yaml
new file mode 100644
index 0000000..94b4fe1
--- /dev/null
+++ b/dav/use-cases/compute/tenancy-data-model.yaml
@@ -0,0 +1,54 @@
+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
+  perspectives:
+    - tenancy-authority
+  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)
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..8141a5e
--- /dev/null
+++ b/dav/use-cases/compute/vm-provision-with-provider-failure.yaml
@@ -0,0 +1,71 @@
+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
+  perspectives:
+    - platform-operator
+    - sre
+    - tenancy-authority
+  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..e6e8fc0
--- /dev/null
+++ b/dav/use-cases/compute/vm-standard-provision.yaml
@@ -0,0 +1,59 @@
+uuid: uc-seed-001a
+handle: compute/vm-standard-provision
+scenario:
+  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
+  perspectives:
+    - compliance-auditor
+    - tenancy-authority
+  intent: Provision a new VM in the standard profile
+  success_criteria:
+  - 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 — repeating it does not create duplicate VMs"
+  dimensions:
+    lifecycle_phase: new_request
+    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: policy
+    interaction: resolved-profile validation evaluates the request before allocation
+  - domain: provider
+    interaction: service provider allocates the VM resource
+  - domain: data
+    interaction: resource record created
+  - 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.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/compute/vm-tenant-isolation-enforcement.yaml b/dav/use-cases/compute/vm-tenant-isolation-enforcement.yaml
new file mode 100644
index 0000000..5341222
--- /dev/null
+++ b/dav/use-cases/compute/vm-tenant-isolation-enforcement.yaml
@@ -0,0 +1,63 @@
+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
+  perspectives:
+    - tenancy-authority
+  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
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..5b21f82
--- /dev/null
+++ b/dav/use-cases/cross-domain/ansible-inventory-brownfield-ingestion.yaml
@@ -0,0 +1,86 @@
+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
+  perspectives:
+    - sre
+    - security-officer
+  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: llm-guided
+  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/brownfield-adoption-capability.yaml b/dav/use-cases/cross-domain/brownfield-adoption-capability.yaml
new file mode 100644
index 0000000..2110e4d
--- /dev/null
+++ b/dav/use-cases/cross-domain/brownfield-adoption-capability.yaml
@@ -0,0 +1,57 @@
+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
+  perspectives:
+    - sre
+    - security-officer
+  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)
diff --git a/dav/use-cases/cross-domain/brownfield-adoption-data-model.yaml b/dav/use-cases/cross-domain/brownfield-adoption-data-model.yaml
new file mode 100644
index 0000000..fe003d7
--- /dev/null
+++ b/dav/use-cases/cross-domain/brownfield-adoption-data-model.yaml
@@ -0,0 +1,58 @@
+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
+  perspectives:
+    - sre
+    - compliance-auditor
+    - security-officer
+  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)
diff --git a/dav/use-cases/cross-domain/composite-service-provision.yaml b/dav/use-cases/cross-domain/composite-service-provision.yaml
new file mode 100644
index 0000000..96dc85d
--- /dev/null
+++ b/dav/use-cases/cross-domain/composite-service-provision.yaml
@@ -0,0 +1,76 @@
+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
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - sovereignty-authority
+  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: multiple_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
diff --git a/dav/use-cases/cross-domain/composite-service-to-catalog-item.yaml b/dav/use-cases/cross-domain/composite-service-to-catalog-item.yaml
new file mode 100644
index 0000000..fc8ceb2
--- /dev/null
+++ b/dav/use-cases/cross-domain/composite-service-to-catalog-item.yaml
@@ -0,0 +1,67 @@
+uuid: uc-pipeline-catalog-001
+handle: cross-domain/composite-service-to-catalog-item
+scenario:
+  description: A platform engineer registers a composite service definition as a
+    catalog item in DCM. The composite service declares multiple constituent resource
+    types (e.g., web tier, app tier, database tier) with dependencies between them.
+    A process provider may convert an external format (e.g., likeC4) to DCM's native
+    composite service format before registration. DCM does not natively speak
+    customer-specific formats; UDLM is the core design language.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Register a composite service definition as a catalog item
+  success_criteria:
+  - Composite service definition is registered as a catalog item
+  - All constituent resource types are declared with dependencies
+  - Dependency graph is acyclic and validated
+  - Catalog item is visible in the service catalog
+  - Registration is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: process provider converts external format if needed; service provider
+      registers catalog item
+  - domain: data
+    interaction: catalog item and constituent definitions created
+  - domain: policy
+    interaction: validation policy checks composite definition completeness
+  - domain: audit
+    interaction: registration recorded
+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
+- catalog
+- 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: 5
+    week: wk3
+    depends_on:
+    - uc-pipeline-cp-001
+    - uc-pipeline-authn-001
+  preconditions:
+  - DCM control plane is deployed and accepting requests
+  - Actor holds a valid Keycloak token
+  postconditions:
+  - Composite service catalog item is registered and visible
+  - Constituent dependency graph is validated and stored
diff --git a/dav/use-cases/cross-domain/cross-dcm-audit-data-model.yaml b/dav/use-cases/cross-domain/cross-dcm-audit-data-model.yaml
new file mode 100644
index 0000000..fa0b24a
--- /dev/null
+++ b/dav/use-cases/cross-domain/cross-dcm-audit-data-model.yaml
@@ -0,0 +1,54 @@
+uuid: uc-cross-dcm-audit-data-model
+handle: cross-domain/cross-dcm-audit-data-model
+version: 1.0.0
+scenario:
+  description: 'Validation UC for A4: confirm UDLM models the data for peer-coordinated decommission —
+    peer-ack metadata on the released resource and a cross-DCM audit record stitched consistently across
+    both instances.'
+  actor:
+    persona: sovereign-tenant-admin
+    profile: sovereign
+  perspectives:
+    - federation-peer-operator
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Validate UDLM models peer-ack metadata and a consistent cross-DCM audit record
+  success_criteria:
+  - The released resource record models peer-acknowledgement metadata
+  - A cross-DCM audit record is modeled and is consistent across both instances
+  - Pending (held) state is representable when the peer is unreachable
+  - The peer's attested capability set at transaction time is recorded
+  - Residency-check evidence is captured in the model
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: system_defaults_only
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: peer-ack metadata + cross-DCM audit record modeled consistently
+  - domain: audit
+    interaction: cross-instance audit stitched
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: trifecta-1.0
+  timestamp: '2026-06-29T00:00:00.000000+00:00'
+tags:
+- a4
+- peer-dcm
+- data-model-validation
+- trifecta
+- udlm
+- sovereign-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)
diff --git a/dav/use-cases/cross-domain/dynamic-rehydration.yaml b/dav/use-cases/cross-domain/dynamic-rehydration.yaml
new file mode 100644
index 0000000..963468b
--- /dev/null
+++ b/dav/use-cases/cross-domain/dynamic-rehydration.yaml
@@ -0,0 +1,76 @@
+uuid: uc-pipeline-rehydrate-001
+handle: cross-domain/dynamic-rehydration
+scenario:
+  description: All managed resources are destroyed (simulating a disaster). The system
+    reads the stored intent states and dependency graph from the data model, derives
+    a rebuild plan dynamically (not a static replay), re-evaluates validation policies
+    (including sovereignty), resolves providers via the placement engine, and executes
+    the rebuild. This is the headline demo — proving that DCM can reconstruct a full
+    environment from its data model alone.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - sovereignty-authority
+  intent: Dynamically rebuild all resources from stored intent after total destruction
+  success_criteria:
+  - All resources are destroyed (realized state cleared)
+  - System derives a rebuild plan from stored intent and dependency graph
+  - The plan is computed dynamically, not replayed from a recorded sequence
+  - Validation policies (including sovereignty) are re-evaluated during rebuild
+  - Providers are resolved via the standard placement engine
+  - All resources are re-realized in the correct dependency order
+  - UUIDs are preserved across the destroy/rebuild cycle
+  - Post-rebuild realized state matches the original intent state
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: full_stack
+    policy_complexity: multi_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent state read, dependency graph computed, all four states repopulated
+  - domain: policy
+    interaction: validation policies re-evaluated including sovereignty
+  - domain: provider
+    interaction: service providers re-realize each resource
+  - domain: audit
+    interaction: full destroy and rebuild arc recorded
+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
+- rehydration
+- dynamic
+- rebuild
+- headline
+- 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: 4
+    sequence: 11
+    week: wk4
+    depends_on:
+    - uc-pipeline-composite-001
+    - uc-pipeline-4state-001
+  preconditions:
+  - Resources were previously realized and are now destroyed
+  - Intent state and dependency graph are preserved in the data stores
+  postconditions:
+  - All resources are re-realized matching original intent
+  - UUIDs are preserved
+  - Four-state stores are fully repopulated
diff --git a/dav/use-cases/cross-domain/peer-coordination-capability.yaml b/dav/use-cases/cross-domain/peer-coordination-capability.yaml
new file mode 100644
index 0000000..2450670
--- /dev/null
+++ b/dav/use-cases/cross-domain/peer-coordination-capability.yaml
@@ -0,0 +1,55 @@
+uuid: uc-peer-coordination-capability
+handle: cross-domain/peer-coordination-capability
+version: 1.0.0
+scenario:
+  description: 'Validation UC for A4: confirm DCM provides the peer-coordination capability — a two-phase
+    release across DCM instances, verifying the peer meets the provenance floor before coordinating, releasing
+    local only after peer-ack, and holding (not silently completing) when the peer is unreachable.'
+  actor:
+    persona: sovereign-tenant-admin
+    profile: sovereign
+  perspectives:
+    - federation-peer-operator
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Validate DCM can run a peer-coordinated two-phase release with hold-on-unreachable
+  success_criteria:
+  - DCM coordinates a two-phase release with a peer DCM instance
+  - The peer's attested capability set is verified to meet the provenance floor before coordinating
+  - Local release happens only after the peer acknowledges
+  - If the peer is unreachable the operation is held pending, not silently completed
+  - Residency constraints are checked during the coordinated 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: provider
+    interaction: peer_dcm provider coordinates the two-phase release
+  - domain: policy
+    interaction: sovereignty policy mandates the peer replica and verifies the provenance floor
+  - domain: audit
+    interaction: peer-ack evidence captured
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: trifecta-1.0
+  timestamp: '2026-06-29T00:00:00.000000+00:00'
+tags:
+- a4
+- peer-dcm
+- capability-validation
+- trifecta
+- sovereign-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)
diff --git a/dav/use-cases/cross-domain/profile-approved-list-data-model.yaml b/dav/use-cases/cross-domain/profile-approved-list-data-model.yaml
new file mode 100644
index 0000000..4c9d98b
--- /dev/null
+++ b/dav/use-cases/cross-domain/profile-approved-list-data-model.yaml
@@ -0,0 +1,59 @@
+uuid: uc-profile-approved-list-data-model
+handle: cross-domain/profile-approved-list-data-model
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-B: confirm UDLM models the approved-list profile data — the instance
+    approved_profiles set + default_profile, a profile as a named capability set, the tenant_boundary
+    and policy_profile DCMGroups, and the compliance/sovereignty overlay (Sovereignty Zone + Accreditation)
+    as a separate axis composed with the profile.'
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - compliance-auditor
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Validate UDLM models approved-list profiles, default, and the profile/overlay binding
+  success_criteria:
+  - The instance models an approved_profiles set and a default_profile
+  - A profile is modeled as a named, versioned capability set (not a fixed enum value)
+  - Tenant is a tenant_boundary DCMGroup bound to a policy_profile DCMGroup — no separate mapping artifact
+  - Compliance/sovereignty overlay (Sovereignty Zone + Accreditation) is a distinct, composable axis
+  - Quota allocations and claims-mapping references are modeled on the tenant
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: system_defaults_only
+    provider_landscape: mixed
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: approved_profiles, default_profile, capability-set profiles, DCMGroups, overlay, quotas
+      modeled
+  - domain: policy
+    interaction: profile binding expressed via policy_profile DCMGroup
+  - domain: audit
+    interaction: profile + overlay binding 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-b
+- profile
+- approved-list
+- data-model-validation
+- trifecta
+- udlm
+- fsi-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)
diff --git a/dav/use-cases/cross-domain/profile-resolution-capability.yaml b/dav/use-cases/cross-domain/profile-resolution-capability.yaml
new file mode 100644
index 0000000..8dc470a
--- /dev/null
+++ b/dav/use-cases/cross-domain/profile-resolution-capability.yaml
@@ -0,0 +1,57 @@
+uuid: uc-profile-resolution-capability
+handle: cross-domain/profile-resolution-capability
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-B: confirm DCM provides profile resolution (an instance declares
+    an approved list of profiles + a default; near-term the default applies instance-wide) and atomic
+    tenant onboarding (identity boundary + profile binding + quotas + auth claims, all-or-nothing).'
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - tenancy-authority
+  intent: Validate DCM resolves the instance profile from the approved list + default and onboards atomically
+  success_criteria:
+  - DCM resolves the instance profile from the platform approved list and default
+  - Tenant onboarding binds the tenant to the resolved profile via a policy_profile DCMGroup
+  - Onboarding is atomic — either all steps persist or none do
+  - A compliance/sovereignty overlay is composed with the profile, not folded into it
+  - Profiles are capability sets compared by content set-containment, not by rank
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: mixed
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: profile resolution from approved-list+default; onboarding atomicity enforced by orchestration
+      flow policy
+  - domain: data
+    interaction: tenant bound to instance profile; compliance overlay composed separately
+  - domain: provider
+    interaction: auth provider configured with the tenant claims-mapping reference
+  - domain: audit
+    interaction: atomic onboarding recorded as one record
+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-b
+- profile
+- approved-list
+- capability-validation
+- trifecta
+- fsi-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)
diff --git a/dav/use-cases/cross-domain/provider-portable-rebuild.yaml b/dav/use-cases/cross-domain/provider-portable-rebuild.yaml
new file mode 100644
index 0000000..b2b0d6b
--- /dev/null
+++ b/dav/use-cases/cross-domain/provider-portable-rebuild.yaml
@@ -0,0 +1,74 @@
+uuid: uc-pipeline-portable-001
+handle: cross-domain/provider-portable-rebuild
+scenario:
+  description: A service provider becomes unavailable during or after provisioning.
+    The placement engine re-resolves the affected resources onto an alternate eligible
+    provider. Provider-specific references are rewritten. The rebuild proceeds using
+    only the intent state and the new provider's capabilities. This UC validates that
+    DCM's provider abstraction enables true portability — resources are not locked
+    to a single provider.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Re-resolve and rebuild resources on an alternate provider after provider
+    failure
+  success_criteria:
+  - Provider unavailability is detected (via health check or explicit deregistration)
+  - Affected resources are re-resolved onto an alternate eligible provider
+  - Provider-specific references (naturalization) are rewritten for the new provider
+  - Resources are re-realized on the alternate provider
+  - Realized state matches the original intent (provider-neutral fields)
+  - The re-resolution and rebuild are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: multi_dependent
+    policy_complexity: multi_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: single_provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: original provider unavailable; alternate selected via placement engine
+  - domain: policy
+    interaction: validation policies re-evaluated for alternate provider
+  - domain: data
+    interaction: provider references rewritten; realized state updated
+  - domain: audit
+    interaction: portability event and re-resolution recorded
+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
+- portability
+- provider
+- rebuild
+- stretch
+- 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: 5
+    sequence: 13
+    week: wk5
+    depends_on:
+    - uc-pipeline-composite-001
+  preconditions:
+  - Resources are realized on a specific provider
+  - An alternate eligible provider is registered
+  - The original provider becomes unavailable
+  postconditions:
+  - Resources are re-realized on the alternate provider
+  - Intent-to-realized alignment is maintained
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..babe04b
--- /dev/null
+++ b/dav/use-cases/cross-domain/sovereign-decommission-with-peer.yaml
@@ -0,0 +1,77 @@
+uuid: uc-seed-002a
+handle: cross-domain/sovereign-decommission-with-peer
+scenario:
+  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
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Decommission a resource such that both the local and the peer replica are
+    released, with a consistent cross-DCM audit record
+  success_criteria:
+  - 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
+    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 mandates the peer replica + residency check at
+      decommission; verifies peer meets the provenance floor before coordinating
+  - domain: provider
+    interaction: peer_dcm provider coordinates the two-phase release with the remote DCM
+  - domain: provider
+    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 consistently
+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
+- peer-coordinated
+- provenance-floor
+- edge-case
+- failure-mode
+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
new file mode 100644
index 0000000..497dadd
--- /dev/null
+++ b/dav/use-cases/cross-domain/tenant-onboarding.yaml
@@ -0,0 +1,82 @@
+uuid: uc-seed-008a
+handle: cross-domain/tenant-onboarding
+scenario:
+  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
+  perspectives:
+    - compliance-auditor
+    - sovereignty-authority
+    - tenancy-authority
+    - regulator
+  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 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 (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
+    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 (tenant_boundary DCMGroup) created, bound
+      to the instance profile (policy_profile DCMGroup)
+  - domain: policy
+    interaction: instance-profile policies + composed compliance/sovereignty overlay
+      bound to the tenant
+  - domain: data
+    interaction: storage and compute quota allocations recorded against the tenant
+  - domain: provider
+    interaction: auth provider configured with the tenant claims-mapping reference
+      (delegated identity)
+  - domain: policy
+    interaction: onboarding atomicity enforced by an 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
+- 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/four-state-store-conformance.yaml b/dav/use-cases/data/four-state-store-conformance.yaml
new file mode 100644
index 0000000..06a0194
--- /dev/null
+++ b/dav/use-cases/data/four-state-store-conformance.yaml
@@ -0,0 +1,64 @@
+uuid: uc-pipeline-4state-001
+handle: data/four-state-store-conformance
+scenario:
+  description: A platform engineer verifies that the four-state data stores (intent,
+    requested, realized, discovered) conform to the UDLM specification. Each store
+    maintains the correct entity lifecycle, UUIDs are stable across states, and state
+    transitions follow the declared rules. This UC validates the data substrate that
+    all provisioning, drift detection, and rehydration UCs depend on.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Verify four-state data store conformance to the UDLM specification
+  success_criteria:
+  - Intent store preserves the original consumer declaration immutably
+  - Requested store records the policy-approved dispatch payload
+  - Realized store records provider-confirmed outcomes as authoritative
+  - Discovered store records independently observed current state
+  - Entity UUIDs are stable across all four states
+  - State transitions follow UDLM lifecycle rules (no skipping states)
+  - Four-state stores are queryable via the standard API
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: no_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: all four state stores are exercised and verified
+  - domain: audit
+    interaction: conformance verification recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- data
+- four-state
+- udlm
+- conformance
+- 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: 7
+    week: wk2-3
+    depends_on:
+    - uc-pipeline-cp-001
+  preconditions:
+  - DCM control plane is deployed with four-state stores initialized
+  postconditions:
+  - Four-state stores are UDLM-conformant and queryable
+  - Entity lifecycle transitions are validated
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..760794e
--- /dev/null
+++ b/dav/use-cases/data/persistent-volume-provision.yaml
@@ -0,0 +1,64 @@
+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
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+    - sovereignty-authority
+  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_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: policy
+    interaction: tenant-isolation gating 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-chain-data-model.yaml b/dav/use-cases/governance/audit-chain-data-model.yaml
new file mode 100644
index 0000000..4236c59
--- /dev/null
+++ b/dav/use-cases/governance/audit-chain-data-model.yaml
@@ -0,0 +1,51 @@
+uuid: uc-audit-chain-data-model
+handle: governance/audit-chain-data-model
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-D: confirm UDLM models the audit-chain data — audit events, epochs,
+    signed tree heads, and inclusion/consistency proofs as append-only, schema-defined artifacts addressable
+    by handle and epoch.'
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives: []
+  intent: Validate UDLM models the audit chain (events, epochs, tree heads, proofs) as append-only
+  success_criteria:
+  - Audit events are modeled as append-only artifacts addressable by handle and epoch
+  - Epochs and their signed tree heads are modeled
+  - Inclusion and consistency proofs are modeled as read-only derived artifacts
+  - The model enforces append-only semantics (no in-place mutation of recorded events)
+  - Signing/attestation metadata for tree heads is modeled
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: audit events, epochs, tree heads, and proofs modeled append-only
+  - domain: audit
+    interaction: proof artifacts derived read-only from the chain
+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-d
+- audit
+- data-model-validation
+- trifecta
+- udlm
+- sovereign-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)
diff --git a/dav/use-cases/governance/audit-chain-output-verification.yaml b/dav/use-cases/governance/audit-chain-output-verification.yaml
new file mode 100644
index 0000000..158893a
--- /dev/null
+++ b/dav/use-cases/governance/audit-chain-output-verification.yaml
@@ -0,0 +1,56 @@
+uuid: uc-audit-chain-output-verification
+handle: governance/audit-chain-output-verification
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-D (closes the produce->verify loop): an auditor takes the signed
+    tree heads + inclusion and consistency proofs DCM produced and independently re-verifies them; the
+    proofs validate for untampered events, and a tampered or missing event is detected. This validates
+    the OUTPUT of governance/audit-merkle-tree-verification, not just that proofs are produced.'
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - regulator
+  intent: Validate an auditor can independently re-verify the audit-chain proofs and detect tampering
+  success_criteria:
+  - Independently re-verifying inclusion proofs against the signed tree heads succeeds for untampered
+    events
+  - Consistency proofs confirm the tree heads form a coherent append-only sequence
+  - A tampered or removed event is detected (its proof fails verification)
+  - Verification is a read-only operation that modifies no tenant resources
+  - Under sovereign profile the signing key material never leaves the boundary during verification
+  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: auditor re-verifies inclusion and consistency proofs against signed tree heads
+  - domain: policy
+    interaction: sovereignty policy confirms signing-key residency during verification
+  - domain: data
+    interaction: audit events looked up by handle and epoch for proof generation
+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-d
+- audit
+- output-verification
+- produce-verify-loop
+- trifecta
+- sovereign-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)
diff --git a/dav/use-cases/governance/audit-chain-proofs-capability.yaml b/dav/use-cases/governance/audit-chain-proofs-capability.yaml
new file mode 100644
index 0000000..7b5a2c7
--- /dev/null
+++ b/dav/use-cases/governance/audit-chain-proofs-capability.yaml
@@ -0,0 +1,55 @@
+uuid: uc-audit-chain-proofs-capability
+handle: governance/audit-chain-proofs-capability
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-D: confirm DCM provides the transparency-log capability — produce
+    signed Merkle tree heads, inclusion proofs for requested events, and consistency proofs across epochs,
+    with signing key material kept in-boundary under sovereign profile. (Single-signer v1; external witness
+    validation is a tracked follow-up.)'
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - sovereignty-authority
+  intent: Validate DCM can produce signed tree heads + inclusion/consistency proofs with in-boundary signing
+  success_criteria:
+  - DCM produces signed tree heads for every audit epoch covering a requested range
+  - DCM produces inclusion proofs for each requested event
+  - DCM produces consistency proofs across epoch tree heads
+  - Signing key material is kept within the sovereignty boundary
+  - v1 is single-signer; split-view/equivocation is a known limitation pending external witnesses
+  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: DCM generates tree heads, inclusion proofs, and consistency proofs
+  - domain: policy
+    interaction: sovereignty policy pins signing-key residency
+  - domain: provider
+    interaction: information provider serves tree-heads and proofs
+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-d
+- audit
+- transparency-log
+- capability-validation
+- trifecta
+- sovereign-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)
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..b727a2e
--- /dev/null
+++ b/dav/use-cases/governance/audit-merkle-tree-verification.yaml
@@ -0,0 +1,67 @@
+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
+  perspectives:
+    - sovereignty-authority
+    - tenancy-authority
+    - regulator
+  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..d735b00
--- /dev/null
+++ b/dav/use-cases/governance/minimal-profile-policy-scope-boundary.yaml
@@ -0,0 +1,87 @@
+uuid: uc-seed-009a
+handle: governance/minimal-profile-policy-scope-boundary
+scenario:
+  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: homelab
+  perspectives:
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: Provision a VM with attached volume and cross-region network attachment
+    under a minimal resolved profile, with FSI-scoped policies correctly out of scope
+  success_criteria:
+  - Request succeeds because no policy in the minimal resolved profile rejects it
+  - FSI-scoped policies (data-residency, dual-approval, encryption-at-rest-mandatory)
+    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
+    policy_complexity: system_defaults_only
+    provider_landscape: mixed
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: homelab
+  expected_domain_interactions:
+  - domain: policy
+    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: policies in the minimal resolved profile evaluate (system defaults
+      for this profile)
+  - domain: provider
+    interaction: service provider allocates the VM in the minimal sandbox
+  - domain: provider
+    interaction: storage provider allocates the volume without forced encryption-at-rest
+      (FSI-scoped, out of scope for minimal)
+  - domain: provider
+    interaction: network provider establishes the cross-region attachment without
+      residency rejection (FSI-scoped, out of scope for minimal)
+  - domain: data
+    interaction: request record stores the resolved profile + its policy set for audit
+  - domain: audit
+    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
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-04-23T04:45:00.000000+00:00'
+tags:
+- governance
+- policy
+- resolved-profile
+- minimal-profile
+- negative-policy-claim
+- out-of-scope-not-skipped-pass
+- three-state-audit
+- system-defaults-only
+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/governance/policy-applicability-data-model.yaml b/dav/use-cases/governance/policy-applicability-data-model.yaml
new file mode 100644
index 0000000..69974fe
--- /dev/null
+++ b/dav/use-cases/governance/policy-applicability-data-model.yaml
@@ -0,0 +1,57 @@
+uuid: uc-policy-applicability-data-model
+handle: governance/policy-applicability-data-model
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-E: confirm UDLM models the data behind policy applicability — the
+    approved-list/default, the resolved profile and its policy set on the request record, and a three-state
+    policy outcome (evaluated-pass / evaluated-fail / out-of-scope) in the audit model.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Validate UDLM models resolved-profile policy sets and three-state audit outcomes
+  success_criteria:
+  - The request record models the resolved profile and the set of policies it carries
+  - 'The audit model represents three policy outcomes: evaluated-pass, evaluated-fail, out-of-scope'
+  - Out-of-scope is a first-class modeled outcome, not an absence or a pass
+  - Approved-list and default profile are modeled at the instance level
+  - Policy membership in a profile is modeled (which policies a profile carries)
+  dimensions:
+    lifecycle_phase: new_request
+    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: resolved profile + policy set on the request; three-state outcome modeled
+  - domain: policy
+    interaction: profile->policy membership modeled
+  - domain: audit
+    interaction: three-state outcome represented
+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-e
+- policy
+- 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)
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..be5d212
--- /dev/null
+++ b/dav/use-cases/governance/policy-override-approval.yaml
@@ -0,0 +1,64 @@
+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
+  perspectives:
+    - executive
+  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/governance/policy-resolution-capability.yaml b/dav/use-cases/governance/policy-resolution-capability.yaml
new file mode 100644
index 0000000..1fe419e
--- /dev/null
+++ b/dav/use-cases/governance/policy-resolution-capability.yaml
@@ -0,0 +1,58 @@
+uuid: uc-policy-resolution-capability
+handle: governance/policy-resolution-capability
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-E: confirm DCM provides policy applicability by resolved-profile
+    membership — it resolves the request profile (approved-list selection or platform default), evaluates
+    only the policies in that profile, and records a three-state audit outcome (evaluated-pass / evaluated-fail
+    / out-of-scope) with out-of-scope distinct from skipped-and-passed.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Validate DCM resolves the request profile and produces three-state policy outcomes
+  success_criteria:
+  - DCM resolves the request's profile and selects that profile's policies by construction
+  - Policies not in the resolved profile are not evaluated
+  - The audit outcome distinguishes evaluated-pass, evaluated-fail, and out-of-scope
+  - Out-of-scope policies are never recorded as skipped-and-passed (no silent soft-pass)
+  - No global policy fall-through evaluates policies outside the resolved profile
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: engine resolves profile, selects its policies, emits three-state outcomes
+  - domain: data
+    interaction: request stores the resolved profile and its policy set
+  - domain: audit
+    interaction: policies-evaluated listed honestly with three-state outcomes
+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-e
+- policy
+- resolved-profile
+- 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)
diff --git a/dav/use-cases/governance/sovereignty-validation-policy.yaml b/dav/use-cases/governance/sovereignty-validation-policy.yaml
new file mode 100644
index 0000000..c844202
--- /dev/null
+++ b/dav/use-cases/governance/sovereignty-validation-policy.yaml
@@ -0,0 +1,69 @@
+uuid: uc-pipeline-sov-001
+handle: governance/sovereignty-validation-policy
+scenario:
+  description: A platform engineer configures a sovereignty validation policy that
+    blocks resource placement in non-compliant zones. When a provisioning request
+    arrives, the validation policy (enforcement_class compliance) evaluates the request
+    against the declared sovereignty zone constraints. Non-compliant placements are
+    denied. This UC validates that sovereignty constraints are enforced as hard gates
+    in the provisioning pipeline.
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+  intent: Configure and enforce sovereignty validation policy for resource placement
+  success_criteria:
+  - Sovereignty validation policy is registered and active
+  - Placement requests within compliant zones are approved
+  - Placement requests to non-compliant zones are denied with a clear sovereignty
+    violation error
+  - Policy evaluation and outcome are recorded in the audit trail
+  - The policy operates correctly in shadow mode before enforcement
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereign_mandate
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty validation policy evaluates placement constraints
+  - domain: provider
+    interaction: placement engine selects only compliant providers
+  - domain: data
+    interaction: policy evaluation results stored
+  - domain: audit
+    interaction: sovereignty evaluation recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- governance
+- sovereignty
+- validation-policy
+- 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: 8
+    week: wk3
+    depends_on:
+    - uc-pipeline-cp-001
+  preconditions:
+  - DCM control plane is deployed
+  - Sovereignty zones are registered
+  - At least one validation policy with enforcement_class compliance is configured
+  postconditions:
+  - Sovereignty constraints are enforced at placement time
+  - Non-compliant placements are blocked
diff --git a/dav/use-cases/hammer-audit-compliance/001-field-provenance-chain.yaml b/dav/use-cases/hammer-audit-compliance/001-field-provenance-chain.yaml
new file mode 100644
index 0000000..5963619
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/001-field-provenance-chain.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-audit-001
+handle: audit/field-provenance-chain
+scenario:
+  description: 'A compliance auditor selects a single field on a realized resource — the residency region
+    on a production database — and asks the system to reconstruct its full provenance chain: the original
+    intent that set it, every modification that touched it, which policy evaluation admitted each change,
+    which actor requested it, and which provider realized it. The architecture must reassemble a per-field
+    lineage across the resource lifecycle from the four-state stores and the audit trail, not merely return
+    the current value. This probes whether audit is field-granular and lineage-navigable rather than record-granular.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - sovereignty-authority
+  intent: Reconstruct the complete provenance chain of one field across its entire lifecycle
+  success_criteria:
+  - The current value of the field is returned with its originating intent record
+  - Every modification that changed the field is listed in causal order
+  - Each change links to the policy evaluation that admitted it
+  - Each change links to the requesting actor and their authorization at that time
+  - Each change links to the provider action that realized it
+  - The chain is complete with no gaps between the first intent and current state
+  - Values the auditor is not entitled to see are redacted without breaking the chain
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: per-field intent and realized history assembled across all four states
+  - domain: policy
+    interaction: each field change joined to the admitting policy evaluation
+  - domain: provider
+    interaction: realizing provider action resolved for each change
+  - domain: audit
+    interaction: field-level lineage stitched from the audit trail into a single chain
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- provenance
+- lineage
+- field-level
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/002-audit-record-vs-object-history.yaml b/dav/use-cases/hammer-audit-compliance/002-audit-record-vs-object-history.yaml
new file mode 100644
index 0000000..89a9f9e
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/002-audit-record-vs-object-history.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-audit-002
+handle: audit/audit-record-vs-object-history
+scenario:
+  description: 'A security officer investigating an incident needs two distinct answers about a load balancer:
+    what the object looked like at each point in time (object history — the sequence of realized states),
+    and what the system recorded about who acted on it and what was decided (audit record — the immutable
+    trail of requests, evaluations, and dispatches). The architecture must keep these as separate, independently
+    queryable concerns and must not conflate a reconstructed object snapshot with an audit entry. This
+    tests whether the model distinguishes state-over-time from the governance record of how that state
+    came to be.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - compliance-auditor
+  intent: Retrieve object history and audit record as two distinct, non-conflated views
+  success_criteria:
+  - Object history returns the ordered realized-state snapshots of the resource
+  - Audit record returns the ordered governance events (request, evaluation, dispatch)
+  - The two views are produced by distinct queries against distinct stores
+  - An object snapshot is never returned as if it were an audit entry
+  - Each object-history transition can be correlated to the audit event that caused it
+  - A change present in object history without a corresponding audit event is flagged
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: realized-state history assembled as object snapshots over time
+  - domain: audit
+    interaction: governance event trail returned as a separate, correlatable view
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- object-history
+- separation-of-concerns
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/003-tamper-evidence-inclusion-proof.yaml b/dav/use-cases/hammer-audit-compliance/003-tamper-evidence-inclusion-proof.yaml
new file mode 100644
index 0000000..be4083a
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/003-tamper-evidence-inclusion-proof.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-audit-003
+handle: audit/tamper-evidence-inclusion-proof
+scenario:
+  description: 'An external regulator holds a signed receipt for a single audit event and demands cryptographic
+    proof that the event is committed in the tamper-evident log the operator claims to keep. The system
+    must return an RFC-9162-style Merkle inclusion proof: the audit path from the event''s leaf hash to
+    a signed tree head the regulator already trusts, verifiable offline without re-reading the whole log.
+    This probes whether the audit substrate is a verifiable append-only Merkle structure or merely a database
+    table asserted to be immutable.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - regulator
+  intent: Obtain a verifiable inclusion proof that one audit event is committed in the log
+  success_criteria:
+  - The audit event resolves to a stable leaf hash
+  - An inclusion proof (audit path to a signed tree head) is returned
+  - The proof verifies offline against a previously published tree head
+  - Verification fails if any node on the path is altered
+  - The tree head is signed by the operator's audit-log key
+  - No full re-scan of the log is required to verify inclusion
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: audit
+    interaction: Merkle inclusion proof generated from leaf hash to signed tree head
+  - domain: data
+    interaction: the audit event record is resolved to its canonical leaf hash from the log store
+  - domain: policy
+    interaction: retention/verifiability policy confirms the event is within a period whose tree head
+      is still published
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- tamper-evidence
+- merkle
+- rfc-9162
+- inclusion-proof
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/004-tamper-evidence-consistency-proof.yaml b/dav/use-cases/hammer-audit-compliance/004-tamper-evidence-consistency-proof.yaml
new file mode 100644
index 0000000..39ce639
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/004-tamper-evidence-consistency-proof.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-audit-004
+handle: audit/tamper-evidence-consistency-proof
+scenario:
+  description: 'A regulator recorded the operator''s signed audit tree head last quarter and records it
+    again this quarter. Before trusting any new inclusion proofs, the regulator demands an RFC-9162 consistency
+    proof showing the newer log is a strict append-only superset of the older one — nothing that was committed
+    has been removed, reordered, or rewritten. The system must prove append-only evolution between two
+    tree heads. This is the harder tamper-evidence property: not that an entry exists, but that history
+    was never edited. It likely exposes whether the architecture only asserts immutability rather than
+    proving it.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - regulator
+  intent: Prove the audit log evolved append-only between two signed tree heads
+  success_criteria:
+  - Both the old and new signed tree heads are retrievable
+  - A consistency proof between the two tree heads is returned
+  - The proof verifies the new log is a superset of the old with no rewrites
+  - Verification fails if any previously committed entry was removed or reordered
+  - The proof binds monotonically increasing tree sizes
+  - No entry committed under the old head is missing under the new head
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: audit
+    interaction: consistency proof generated between two signed tree heads
+  - domain: data
+    interaction: both tree heads are retrieved from the append-only audit store and their versions ordered
+  - domain: policy
+    interaction: append-only invariant policy asserts no entries were rewritten between the two heads
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- tamper-evidence
+- merkle
+- rfc-9162
+- consistency-proof
+- append-only
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/005-audit-store-outage-gap-record.yaml b/dav/use-cases/hammer-audit-compliance/005-audit-store-outage-gap-record.yaml
new file mode 100644
index 0000000..a14b364
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/005-audit-store-outage-gap-record.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-audit-005
+handle: audit/audit-store-outage-gap-record
+scenario:
+  description: 'The audit store becomes unreachable for ninety seconds during a burst of provisioning
+    activity. When it recovers, the architecture must not present an unbroken trail as if nothing happened.
+    Instead it must emit an explicit gap record: a first-class, tamper-evident marker stating that audit
+    continuity was interrupted, for how long, and that some events may be unrecorded — with the hash chain
+    sealing the boundary on both sides. Silent loss is the failure. This tests whether the audit substrate
+    models its own unavailability honestly rather than papering over it.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - compliance-auditor
+  intent: Ensure an audit-store outage yields an explicit gap record, never silent loss
+  success_criteria:
+  - The outage is detected and its start and end are timestamped
+  - An explicit gap record is written to the trail on recovery
+  - The gap record states that events during the window may be unrecorded
+  - The hash chain seals the entries immediately before and after the gap
+  - The trail contains no fabricated entries claiming continuity across the gap
+  - The gap record is itself tamper-evident and cannot be silently removed
+  - Downstream compliance queries surface the gap rather than hiding it
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: audit
+    interaction: outage detected and an explicit tamper-evident gap record written
+  - domain: data
+    interaction: affected requests marked as potentially unrecorded pending reconciliation
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- outage
+- gap-record
+- continuity
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/006-governance-honesty-ungoverned-not-passed.yaml b/dav/use-cases/hammer-audit-compliance/006-governance-honesty-ungoverned-not-passed.yaml
new file mode 100644
index 0000000..00a43bf
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/006-governance-honesty-ungoverned-not-passed.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-audit-006
+handle: audit/governance-honesty-ungoverned-not-passed
+scenario:
+  description: 'A request is submitted for a resource type that no policy is scoped to evaluate. Zero
+    policies match, so nothing rejects it. The architecture must record this outcome honestly as ungoverned
+    — "0 policies applied" — and must not report it as "passed" or "compliant." A green checkmark for
+    an unevaluated request is a governance lie that corrodes every audit conclusion built on it. This
+    tests whether the decision record distinguishes "evaluated and allowed" from "never evaluated," a
+    distinction FSI and sovereign auditors treat as load-bearing.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - sovereignty-authority
+  intent: Confirm a request no policy applied to is recorded as ungoverned, not passed
+  success_criteria:
+  - The evaluation records the count of policies that matched the request (zero)
+  - The outcome is labeled ungoverned, not passed or compliant
+  - The audit record distinguishes "evaluated and allowed" from "not evaluated"
+  - A compliance query can filter for ungoverned requests
+  - No green/pass status is emitted for the unevaluated request
+  - The absence of applicable policy is itself surfaced as a governance finding
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: zero matching policies detected and recorded as an ungoverned outcome
+  - domain: audit
+    interaction: outcome recorded as ungoverned, explicitly distinct from passed
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- governance-honesty
+- ungoverned
+- no-policy
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/007-compliance-gate-blocks-nonconformant.yaml b/dav/use-cases/hammer-audit-compliance/007-compliance-gate-blocks-nonconformant.yaml
new file mode 100644
index 0000000..cf18d78
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/007-compliance-gate-blocks-nonconformant.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-audit-007
+handle: audit/compliance-gate-blocks-nonconformant
+scenario:
+  description: 'A tenant admin submits a request to provision an unencrypted object store in a regulated
+    FSI profile that mandates encryption at rest. A compliance gate must evaluate the request before any
+    provider dispatch, find it non-conformant, and block it — returning a specific denial that names the
+    violated control, not a generic error. No provider call may occur for a blocked request. The denial
+    and its rationale must be audited. This tests that compliance is an enforced pre-dispatch gate, not
+    an after-the-fact report.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Verify a non-conformant request is blocked at the compliance gate pre-dispatch
+  success_criteria:
+  - The compliance gate evaluates the request before any provider dispatch
+  - The non-conformant request is denied, not realized
+  - The denial names the specific violated control (encryption-at-rest)
+  - No provider call occurs for the blocked request
+  - The block decision and rationale are recorded in the audit trail
+  - A corrected, conformant resubmission is admitted and proceeds
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: compliance gate evaluates conformance and blocks the request
+  - domain: provider
+    interaction: no dispatch occurs for the blocked request
+  - domain: audit
+    interaction: block decision recorded with the violated control named
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- compliance-gate
+- pre-dispatch
+- blocked
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/008-forensic-who-changed-when-authorized.yaml b/dav/use-cases/hammer-audit-compliance/008-forensic-who-changed-when-authorized.yaml
new file mode 100644
index 0000000..a763b13
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/008-forensic-who-changed-when-authorized.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-audit-008
+handle: audit/forensic-who-changed-when-authorized
+scenario:
+  description: 'After a production incident, a security officer asks the classic forensic triad about
+    a firewall rule that was loosened: who changed it, exactly when, and were they authorized to at that
+    moment. The architecture must answer all three from the audit trail — resolving the acting identity,
+    the precise commit time, and the authorization decision that was in force at that time (not the actor''s
+    current permissions). Answering authorization as-of-then, rather than as-of-now, is the hard part
+    and the point.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - compliance-auditor
+  intent: Answer who changed a resource, when, and whether they were authorized then
+  success_criteria:
+  - The acting identity for the change is resolved from the audit trail
+  - The precise commit timestamp of the change is returned
+  - The authorization decision in force at that time is retrieved
+  - Authorization is evaluated as-of-then, not from the actor's current permissions
+  - The policy or role grant that permitted the change is identified
+  - An unauthorized change would be surfaced as a violation, not silently accepted
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: audit
+    interaction: actor, timestamp, and as-of-then authorization resolved for the change
+  - domain: policy
+    interaction: authorization decision in force at change time retrieved
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- forensics
+- who-what-when
+- authorization
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/009-synchronous-commit-before-success.yaml b/dav/use-cases/hammer-audit-compliance/009-synchronous-commit-before-success.yaml
new file mode 100644
index 0000000..1316d61
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/009-synchronous-commit-before-success.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-audit-009
+handle: audit/synchronous-commit-before-success
+scenario:
+  description: 'A resource change is dispatched, but the audit store cannot durably commit the audit record
+    at that instant. The architecture must not return success to the caller. Under an audit_heavy contract,
+    the audit commit is synchronous and precedes acknowledgement: if the record cannot be written, the
+    operation fails closed and either rolls back or is held, so there is never a realized change that
+    lacks an audit entry. This tests the ordering guarantee "no unaudited change" — that audit is on the
+    critical path, not a best-effort async side effect.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Guarantee no change is acknowledged as successful before its audit record commits
+  success_criteria:
+  - The audit record commit is attempted before success is returned
+  - When the audit commit fails, the operation does not return success
+  - The change is rolled back or held so no unaudited realized state persists
+  - There exists no realized change without a corresponding committed audit entry
+  - The audit-commit failure is itself recorded once the store recovers
+  - A retry after recovery produces exactly one audit entry, not a duplicate
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: audit
+    interaction: synchronous audit commit gates the success acknowledgement
+  - domain: provider
+    interaction: dispatch rolled back or held when the audit commit cannot durably write
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- synchronous-commit
+- fail-closed
+- no-unaudited-change
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/010-fsi-field-level-audit-granularity.yaml b/dav/use-cases/hammer-audit-compliance/010-fsi-field-level-audit-granularity.yaml
new file mode 100644
index 0000000..b3b077a
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/010-fsi-field-level-audit-granularity.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-audit-010
+handle: audit/fsi-field-level-audit-granularity
+scenario:
+  description: 'An FSI profile mandates field-level audit granularity: every change to a regulated attribute
+    (account owner, residency, retention class) must be audited per field, and this granularity is a floor
+    that cannot be downgraded to coarser resource-level logging by any lower-precedence policy, tenant
+    setting, or performance override. An operator attempts to relax audit to resource-level to cut volume.
+    The architecture must refuse the downgrade for regulated fields and keep field-level capture. This
+    tests whether audit granularity is a non-negotiable profile mandate or a tunable knob.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Enforce field-level audit granularity as a floor that cannot be downgraded
+  success_criteria:
+  - Each change to a regulated field produces a distinct field-level audit entry
+  - An attempt to downgrade to resource-level audit for regulated fields is refused
+  - The refusal cites the FSI profile mandate as the reason
+  - Lower-precedence policy or tenant settings cannot lower the granularity floor
+  - The downgrade attempt is itself audited as a rejected governance change
+  - Non-regulated fields may still use coarser logging without affecting the floor
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: profile mandate enforces field-level granularity as a non-downgradable floor
+  - domain: audit
+    interaction: per-field entries captured and the downgrade attempt recorded as rejected
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- field-level
+- fsi
+- granularity-floor
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/011-cross-site-audit-replication-hashchain.yaml b/dav/use-cases/hammer-audit-compliance/011-cross-site-audit-replication-hashchain.yaml
new file mode 100644
index 0000000..b343d4c
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/011-cross-site-audit-replication-hashchain.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-audit-011
+handle: audit/cross-site-audit-replication-hashchain
+scenario:
+  description: 'A sovereign deployment replicates its audit log from a primary site to a DR site in a
+    second jurisdiction. The replica must be verifiably faithful: the hash chain (or Merkle head) computed
+    at the DR site must match the primary''s signed head, so a regulator can confirm the replica was neither
+    truncated nor altered in transit. During replication a single record is silently corrupted; the architecture
+    must detect the hash-chain break at the replica and refuse to certify the replica as consistent. This
+    probes whether audit replication carries integrity end-to-end or merely copies rows.
+
+    '
+  actor:
+    persona: sovereign-tenant-admin
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Replicate the audit log cross-site with verifiable hash-chain integrity
+  success_criteria:
+  - The DR replica recomputes the hash chain over the received records
+  - The replica's computed head is compared to the primary's signed head
+  - A matching head certifies the replica as a faithful copy
+  - A corrupted record breaks the chain and is detected at the replica
+  - The replica is not certified consistent when the chain fails to verify
+  - The integrity failure is recorded and the divergent record range is identified
+  - Cross-jurisdiction replication respects residency of the audit data itself
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: audit
+    interaction: hash chain recomputed at the replica and matched to the primary head
+  - domain: data
+    interaction: divergent record range identified when integrity verification fails
+  - domain: policy
+    interaction: residency constraint applied to the replicated audit data
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- replication
+- hash-chain
+- cross-site
+- sovereign
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/012-retention-outlives-referenced-entity.yaml b/dav/use-cases/hammer-audit-compliance/012-retention-outlives-referenced-entity.yaml
new file mode 100644
index 0000000..a43e504
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/012-retention-outlives-referenced-entity.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-audit-012
+handle: audit/retention-outlives-referenced-entity
+scenario:
+  description: 'A regulated retention policy requires audit records to be kept for seven years. A resource
+    referenced by those records is decommissioned in year two, and the tenant and provider that owned
+    it are later removed entirely. The audit records must remain intact, queryable, and self-describing
+    for the full retention period even though every entity they reference no longer exists. The architecture
+    must resolve references to tombstoned or removed entities without breaking the record. This tests
+    whether audit retention is independent of the lifecycle of the things it describes.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - tenancy-authority
+  intent: Keep audit records valid and queryable after every referenced entity is gone
+  success_criteria:
+  - Audit records survive decommission of the resource they describe
+  - Records remain intact after the owning tenant and provider are removed
+  - Queries against the records still resolve within the retention window
+  - References to removed entities resolve to tombstones, not dangling errors
+  - Each record remains self-describing without the live referenced entities
+  - Retention expiry is governed independently of referenced-entity lifecycles
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: audit
+    interaction: records retained and self-describing beyond referenced-entity lifetimes
+  - domain: data
+    interaction: references to removed entities resolved via tombstones
+  - domain: policy
+    interaction: retention window enforced independently of entity decommission
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- retention
+- tombstone
+- lifecycle-independence
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/013-single-request-audit-record.yaml b/dav/use-cases/hammer-audit-compliance/013-single-request-audit-record.yaml
new file mode 100644
index 0000000..ce74eb9
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/013-single-request-audit-record.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-audit-013
+handle: audit/single-request-audit-record
+scenario:
+  description: 'An application team member provisions one small VM with no dependencies under standard
+    governance. The architecture must produce exactly one coherent audit record for the request that captures
+    the actor, the intent submitted, the policy evaluation outcome, the provider dispatched to, and the
+    realized result — timestamped and durably stored. This is the baseline happy-path audit contract every
+    heavier scenario builds on: one request in, one complete and correct audit record out.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Provision a simple resource and get one complete, correct audit record
+  success_criteria:
+  - Exactly one audit record is produced for the request
+  - The record captures the requesting actor and the submitted intent
+  - The policy evaluation outcome is recorded
+  - The dispatched provider and realized result are recorded
+  - The record carries a durable, monotonic timestamp
+  - The record is retrievable by request id after completion
+  dimensions:
+    lifecycle_phase: new_request
+    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: policy
+    interaction: single validation evaluated and its outcome recorded
+  - domain: provider
+    interaction: single provider dispatched and result captured
+  - domain: audit
+    interaction: one complete audit record written and retrievable
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- baseline
+- single-record
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/014-forensic-query-by-actor.yaml b/dav/use-cases/hammer-audit-compliance/014-forensic-query-by-actor.yaml
new file mode 100644
index 0000000..51944b9
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/014-forensic-query-by-actor.yaml
@@ -0,0 +1,53 @@
+uuid: uc-hammer-audit-014
+handle: audit/forensic-query-by-actor
+scenario:
+  description: 'An investigation focuses on one departing employee. A security officer asks for every
+    action that identity took across the estate within a date range — every request, modification, and
+    decommission, across all resources and providers. The architecture must support actor-scoped forensic
+    query over the audit trail, returning a complete, ordered activity list for that identity without
+    the investigator having to walk each resource individually. This tests whether audit is queryable
+    by actor as a first-class axis, not only by resource.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - compliance-auditor
+  intent: Retrieve all actions by one identity across the estate in a time window
+  success_criteria:
+  - The audit trail is queryable by actor identity as a primary axis
+  - All actions by the identity in the window are returned across all resources
+  - Results include requests, modifications, and decommissions
+  - Results are ordered and complete for the specified window
+  - Actions the actor took across multiple providers are all included
+  - Results exclude actions by other identities
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: system_defaults_only
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: audit
+    interaction: actor-scoped query returns a complete ordered activity list
+  - domain: data
+    interaction: actions resolved across resources and providers for the identity
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- forensics
+- actor-query
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/015-immutable-record-drift-detection.yaml b/dav/use-cases/hammer-audit-compliance/015-immutable-record-drift-detection.yaml
new file mode 100644
index 0000000..b1f4b2d
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/015-immutable-record-drift-detection.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-audit-015
+handle: audit/immutable-record-drift-detection
+scenario:
+  description: 'A privileged operator with direct database access edits a committed audit row to soften
+    an embarrassing denial into an approval. Because audit records are immutable and hash-chained, the
+    edit must be detectable: a routine integrity scan recomputes the chain and finds the tampered record
+    no longer matches its stored digest, then reports drift on an immutable record and localizes it. The
+    architecture must treat any post-commit mutation of an audit record as a detectable integrity violation,
+    not an accepted update. This probes tamper-detection on the audit substrate itself.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - executive
+  intent: Detect out-of-band mutation of an immutable, hash-chained audit record
+  success_criteria:
+  - An integrity scan recomputes the hash chain over stored records
+  - A record altered out-of-band fails to match its stored digest
+  - The tampering is reported as drift on an immutable record
+  - The specific tampered record is localized within the chain
+  - The system refuses to treat the mutation as a valid update
+  - The detection event is itself recorded tamper-evidently
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: audit
+    interaction: hash-chain scan detects and localizes the out-of-band mutation
+  - domain: data
+    interaction: tampered record flagged as an integrity violation, not an update
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- tamper-detection
+- immutable
+- drift
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/016-compliance-report-across-estate.yaml b/dav/use-cases/hammer-audit-compliance/016-compliance-report-across-estate.yaml
new file mode 100644
index 0000000..140a1b9
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/016-compliance-report-across-estate.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-audit-016
+handle: audit/compliance-report-across-estate
+scenario:
+  description: 'Ahead of an annual audit, a compliance auditor requests a point-in-time conformance report
+    across the entire estate for one control: encryption-at-rest on all data stores. The architecture
+    must evaluate every in-scope resource against the control and return a per-resource conformant/non-conformant/ungoverned
+    breakdown — explicitly separating resources that passed evaluation from those no policy covered. The
+    report must be reproducible from the audit and state data for the stated as-of time. This tests estate-wide
+    compliance reporting that preserves the governed-versus-ungoverned honesty distinction at scale.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - executive
+  intent: Produce an estate-wide as-of conformance report for one control
+  success_criteria:
+  - Every in-scope resource is evaluated against the named control
+  - Each resource is classified conformant, non-conformant, or ungoverned
+  - Ungoverned resources are reported distinctly from conformant ones
+  - The report is scoped to a stated as-of point in time
+  - The report is reproducible from the audit and state data
+  - Non-conformant findings link to the specific resource and violated control
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: control evaluated across every in-scope resource
+  - domain: data
+    interaction: as-of resource states gathered for reproducible reporting
+  - domain: audit
+    interaction: per-resource conformance breakdown recorded with ungoverned distinct
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- compliance-report
+- estate-wide
+- as-of
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/017-erasure-vs-immutable-audit-conflict.yaml b/dav/use-cases/hammer-audit-compliance/017-erasure-vs-immutable-audit-conflict.yaml
new file mode 100644
index 0000000..35ff888
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/017-erasure-vs-immutable-audit-conflict.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-audit-017
+handle: audit/erasure-vs-immutable-audit-conflict
+scenario:
+  description: 'A data subject exercises a GDPR right-to-erasure request over personal data that appears
+    inside immutable, hash-chained audit records. Two mandates collide: erase the personal data, yet never
+    mutate an audit record. The architecture must reconcile them without lying — for example crypto-shredding
+    the field''s key while preserving the record''s hash and a tombstone attesting a lawful erasure occurred,
+    so tamper-evidence and the erasure obligation both hold. This is a genuine conflict and may well return
+    unsupported or partially_supported; that is the finding.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: Satisfy right-to-erasure over data inside immutable audit records without breaking integrity
+  success_criteria:
+  - The erasure request is recognized as targeting data inside immutable records
+  - The conflict between erasure and audit immutability is surfaced explicitly, not silently resolved
+  - Personal data is rendered irrecoverable (e.g. crypto-shredded) after erasure
+  - The audit record's hash and chain position remain intact and still verify
+  - A tombstone attests a lawful erasure occurred, by whom and under what basis
+  - No audit record is deleted or rewritten to satisfy the request
+  - If the architecture cannot reconcile both, it reports the limitation rather than faking success
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: erasure obligation and audit-immutability mandate reconciled or reported as conflicting
+  - domain: audit
+    interaction: hash preserved while the erased field is crypto-shredded and tombstoned
+  - domain: data
+    interaction: personal data rendered irrecoverable without deleting the audit record
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- gdpr
+- right-to-erasure
+- immutability-conflict
+- edge
+- likely-unsupported
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/018-meta-audit-who-read-the-log.yaml b/dav/use-cases/hammer-audit-compliance/018-meta-audit-who-read-the-log.yaml
new file mode 100644
index 0000000..a930a7d
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/018-meta-audit-who-read-the-log.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-audit-018
+handle: audit/meta-audit-who-read-the-log
+scenario:
+  description: 'Under an FSI mandate, reads of the audit log are themselves auditable: pulling another
+    tenant''s or a VIP account''s audit trail is a sensitive act that must leave its own trace. A security
+    officer queries the audit records for a high-profile account; the architecture must record that access
+    — who read which records, when, and under what authorization — into a meta-audit trail that is equally
+    tamper-evident, without creating an infinite regress. This probes whether the architecture models
+    access to the audit substrate as an audited event, a capability many systems lack.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - compliance-auditor
+    - tenancy-authority
+  intent: Ensure reads of the audit log are themselves recorded in a tamper-evident meta-audit
+  success_criteria:
+  - Reading audit records produces a meta-audit entry for the access
+  - The meta-audit entry records reader identity, records accessed, and time
+  - The authorization under which the read occurred is captured
+  - The meta-audit trail is itself tamper-evident
+  - Recording the read does not trigger infinite regress of meta-meta entries
+  - Unauthorized read attempts are recorded as denied accesses
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: audit
+    interaction: read access to the audit log recorded in a tamper-evident meta-audit trail
+  - domain: policy
+    interaction: authorization for the audit read evaluated and captured
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- meta-audit
+- access-logging
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/019-clock-skew-cross-site-ordering.yaml b/dav/use-cases/hammer-audit-compliance/019-clock-skew-cross-site-ordering.yaml
new file mode 100644
index 0000000..ee33558
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/019-clock-skew-cross-site-ordering.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-audit-019
+handle: audit/clock-skew-cross-site-ordering
+scenario:
+  description: 'Two sites in a federation each append to a shared logical audit history, and their wall
+    clocks disagree by several seconds. A forensic reconstruction must place events in their true causal
+    order even though timestamps alone would misorder cross-site events. The architecture must derive
+    ordering structurally — from the hash chain and causal links, not from clock values — so that a later
+    event with an earlier timestamp is still ordered correctly. This directly tests the principle that
+    audit ordering is structural, not clock-based, and is a likely gap if ordering leans on timestamps.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Reconstruct correct causal audit order across sites despite clock skew
+  success_criteria:
+  - Events from both sites are merged into one ordered history
+  - Ordering is derived from hash-chain and causal links, not wall-clock values
+  - A later event bearing an earlier timestamp is still ordered after its cause
+  - Clock skew between sites does not reorder causally dependent events
+  - The reconstruction is deterministic and reproducible
+  - Any events that are genuinely concurrent are marked as unordered, not falsely ordered
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: audit
+    interaction: causal order derived structurally from the hash chain across sites
+  - domain: data
+    interaction: concurrent events marked unordered rather than forced into a false sequence
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- ordering
+- clock-skew
+- structural-ordering
+- edge
+- likely-unsupported
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-audit-compliance/020-policy-decision-version-provenance.yaml b/dav/use-cases/hammer-audit-compliance/020-policy-decision-version-provenance.yaml
new file mode 100644
index 0000000..c899175
--- /dev/null
+++ b/dav/use-cases/hammer-audit-compliance/020-policy-decision-version-provenance.yaml
@@ -0,0 +1,53 @@
+uuid: uc-hammer-audit-020
+handle: audit/policy-decision-version-provenance
+scenario:
+  description: 'A policy set is revised on a Tuesday. A request evaluated the previous Friday was allowed
+    under the older rules; an auditor now asks why it was allowed. The architecture must reproduce the
+    decision against the exact policy version and inputs in force at evaluation time — not the current
+    policy set — and record which policy version, which rule, and which inputs produced the outcome. Evaluating
+    an old decision against today''s rules would be a false reconstruction. This tests whether policy-decision
+    provenance is versioned and replayable as-of the decision.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: prod
+  perspectives: []
+  intent: Explain a past allow decision against the policy version in force at the time
+  success_criteria:
+  - The audit record identifies the policy version used for the evaluation
+  - The specific rule that produced the outcome is identified
+  - The decision inputs at evaluation time are captured
+  - The decision is reproducible against the as-of policy version, not the current one
+  - Replaying against the current policy set does not overwrite the original outcome
+  - A later policy change does not retroactively alter the recorded decision
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: as-of policy version and rule resolved for the past decision
+  - domain: audit
+    interaction: decision inputs and policy version recorded for replayable provenance
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- audit
+- policy-provenance
+- versioned-decision
+- as-of
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-bare-metal/001-provision-host-from-intent.yaml b/dav/use-cases/hammer-bare-metal/001-provision-host-from-intent.yaml
new file mode 100644
index 0000000..4705f3a
--- /dev/null
+++ b/dav/use-cases/hammer-bare-metal/001-provision-host-from-intent.yaml
@@ -0,0 +1,49 @@
+uuid: uc-bare-metal-001
+handle: bare-metal/provision-host-from-intent
+version: 1.0.0
+scenario:
+  description: "A platform engineer declares a bare-metal host's full provisioning intent \u2014 image\
+    \ (url + checksum), root device hints, boot MAC, power target, boot mode \u2014 and the provider (Metal3/Ironic-class)\
+    \ provisions the physical machine from exactly that declaration. Nothing about the provisioned result\
+    \ depends on state outside the record: the intent IS the build instruction. Downstream, cluster bring-up\
+    \ binds on the provisioning_state output rather than polling provider internals."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Provision a physical host entirely from declared intent and bind downstream ordering on its
+    provisioning_state output
+  success_criteria:
+  - The provisioning request carries image, root_device_hints, boot_mac_address, online, boot_mode from
+    the record alone
+  - The provider reaches provisioned and the provisioning_state output publishes it
+  - A cluster/node-pool consumer binds on provisioning_state = provisioned, contract-checked
+  - The realized host's discovered facts (smbios, serial) correlate back to the record
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the provisioning intent is complete, portable record content
+  - domain: policy
+    interaction: validation confirms image checksum and admitted provider before dispatch
+  - domain: provider
+    interaction: a Metal3/Ironic-class provider executes the declaration verbatim
+  - domain: audit
+    interaction: the provision path and binding resolution are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: bare-metal-2026-07-24
+  timestamp: '2026-07-24T23:00:00.000000+00:00'
+tags:
+- bare-metal
+- provisioning-intent
+- metal3
+- binding
diff --git a/dav/use-cases/hammer-bare-metal/002-host-rehydration-replay-intent.yaml b/dav/use-cases/hammer-bare-metal/002-host-rehydration-replay-intent.yaml
new file mode 100644
index 0000000..b74f124
--- /dev/null
+++ b/dav/use-cases/hammer-bare-metal/002-host-rehydration-replay-intent.yaml
@@ -0,0 +1,58 @@
+uuid: uc-bare-metal-002
+handle: bare-metal/host-rehydration-replay-intent
+version: 1.0.0
+scenario:
+  description: "A physical host dies (board failure) and is replaced with different hardware in the same\
+    \ role. Rehydration replays the host's stored intent \u2014 same image and checksum, same root-device\
+    \ policy, new boot MAC discovered and updated \u2014 producing a functionally identical host under\
+    \ a new correlation identity, with lineage to the original. This is the bare-metal leg of the rehydration\
+    \ demo: the estate's intent, not any backup of the dead machine, is the recovery source; drift between\
+    \ the record's expectations and the replacement's discovered facts is surfaced, not silently absorbed."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Rebuild a failed physical host by replaying its stored provisioning intent onto replacement
+    hardware with lineage and honest drift
+  success_criteria:
+  - The replacement provisions from the record's image/hints with no reference to the dead host's runtime
+    state
+  - New hardware identity (smbios, serials, MACs) is discovered and the record's correlations update through
+    review
+  - Lineage from the replacement to the original is recorded (rebuild-from-intent semantics, new correlation
+    identity)
+  - Deltas between declared intent and replacement reality (e.g. smaller root device) fail loudly at provision,
+    not later
+  dimensions:
+    lifecycle_phase: recovery
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: infrastructure_loss
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: stored intent is the single recovery source; correlations update via review
+  - domain: policy
+    interaction: rehydration re-evaluates under current policy (RHY semantics)
+  - domain: provider
+    interaction: the provider provisions replacement hardware from replayed intent
+  - domain: audit
+    interaction: the rebuild, lineage, and discovered deltas are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: bare-metal-2026-07-24
+  timestamp: '2026-07-24T23:00:00.000000+00:00'
+tags:
+- bare-metal
+- rehydration
+- replay-intent
+- lineage
diff --git a/dav/use-cases/hammer-binding-surface/001-typed-outputs-declared-per-type.yaml b/dav/use-cases/hammer-binding-surface/001-typed-outputs-declared-per-type.yaml
new file mode 100644
index 0000000..2c65e65
--- /dev/null
+++ b/dav/use-cases/hammer-binding-surface/001-typed-outputs-declared-per-type.yaml
@@ -0,0 +1,52 @@
+uuid: uc-hammer-binding-surface-001
+handle: binding-surface/typed-outputs-declared-per-type
+version: 1.0.0
+scenario:
+  description: "A platform engineer composes a service that must bind a consumer (a load balancer backend\
+    \ pool) to a producer's realized facts (a VM's addresses). The binding is only contract-checkable\
+    \ if the producer TYPE declares typed Realized outputs (the E2 surface) \u2014 a registry review found\
+    \ the declared surfaces systemically inadequate for binding (median one thin boolean; five types empty\
+    \ and silent). This stresses that every realizable resource type publishes its output surface so bindings\
+    \ resolve against declarations, never string-splicing."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Bind a composite constituent to a producer type's declared Realized outputs and have the binding
+    validated against the type's output declaration
+  success_criteria:
+  - The producer type declares named, typed Realized outputs in its specification
+  - A binds_to edge with target_field resolves against the producer's output declaration
+  - A binding naming an undeclared output is rejected at validation time, not at runtime
+  - The realized entity publishes values for every declared output when it reaches Realized
+  - No consumer parses provider-native structures to obtain what an output should carry
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: composite_service
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the producer type's output declaration is the typed binding surface
+  - domain: policy
+    interaction: validation rejects bindings to undeclared outputs at request time
+  - domain: provider
+    interaction: the provider populates declared outputs at realization
+  - domain: audit
+    interaction: the binding resolution and output publication are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: binding-surface-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- typed-outputs
+- binding-surface
+- e2
+- composition
diff --git a/dav/use-cases/hammer-binding-surface/002-undeclared-output-binding-rejected.yaml b/dav/use-cases/hammer-binding-surface/002-undeclared-output-binding-rejected.yaml
new file mode 100644
index 0000000..c07ec47
--- /dev/null
+++ b/dav/use-cases/hammer-binding-surface/002-undeclared-output-binding-rejected.yaml
@@ -0,0 +1,51 @@
+uuid: uc-hammer-binding-surface-002
+handle: binding-surface/undeclared-output-binding-rejected
+version: 1.0.0
+scenario:
+  description: 'A service author wires a composite whose constituent binds to a field the producer type
+    never declared as an output (a typo, or an assumption imported from another provider''s shape). If
+    output declarations are absent or unenforced, the error surfaces as a runtime failure deep in realization.
+    This stresses the failure path: the gap must be caught at catalog/request validation with an error
+    naming the producer type, the missing output, and the declared alternatives.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Submit a composition binding to a nonexistent producer output and receive a validation-time
+    rejection that names the declared output surface
+  success_criteria:
+  - Validation fails before any provisioning is attempted
+  - The error names the producer type, the requested output, and the type's declared outputs
+  - A corrected binding to a declared output passes the same validation
+  - Types with legitimately empty outputs (non-realizable/knowledge families) are distinguishable from
+    types that merely forgot to declare
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: composite_service
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the output declaration is the authority the rejection cites
+  - domain: policy
+    interaction: the validation policy enforces declaration-or-reject
+  - domain: provider
+    interaction: no provider is dispatched for an invalid binding
+  - domain: audit
+    interaction: the rejection and its cited authority are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: binding-surface-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- typed-outputs
+- binding-surface
+- validation
+- failure-mode
diff --git a/dav/use-cases/hammer-binding-surface/003-fleet-output-coverage-queryable.yaml b/dav/use-cases/hammer-binding-surface/003-fleet-output-coverage-queryable.yaml
new file mode 100644
index 0000000..3a4e3c8
--- /dev/null
+++ b/dav/use-cases/hammer-binding-surface/003-fleet-output-coverage-queryable.yaml
@@ -0,0 +1,51 @@
+uuid: uc-hammer-binding-surface-003
+handle: binding-surface/fleet-output-coverage-queryable
+version: 1.0.0
+scenario:
+  description: "An architect needs to answer, for the whole registry: which resource types publish a Realized\
+    \ output surface, which are legitimately output-free (knowledge/reference families), and which are\
+    \ gaps. If this requires reading 46 spec files by hand, the gap class regrows silently with every\
+    \ new type. This stresses that output coverage is a queryable property of the registry \u2014 the\
+    \ same way conformance and profile coverage are \u2014 so the fleet-wide gap found once stays found."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Query the registry for output-surface coverage across all resource types and receive a complete
+    declared/exempt/gap classification
+  success_criteria:
+  - 'Every registered type is classified: outputs declared, exempt-by-family, or gap'
+  - The classification is derived from the registry, not from a hand-maintained list
+  - A newly registered realizable type without outputs appears as a gap immediately
+  - The query result is consumable by CI so the gap class cannot silently regrow
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: none_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the registry is the single source the coverage query reads
+  - domain: policy
+    interaction: a governance gate can require outputs on realizable types
+  - domain: provider
+    interaction: provider-declared types are held to the same output bar
+  - domain: audit
+    interaction: coverage snapshots are recordable for trend/attestation
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: binding-surface-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- typed-outputs
+- registry-coverage
+- governance
+- ci-ratchet
diff --git a/dav/use-cases/hammer-binding-surface/004-imperative-playbook-to-composite-intent.yaml b/dav/use-cases/hammer-binding-surface/004-imperative-playbook-to-composite-intent.yaml
new file mode 100644
index 0000000..d343c89
--- /dev/null
+++ b/dav/use-cases/hammer-binding-surface/004-imperative-playbook-to-composite-intent.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-binding-surface-004
+handle: binding-surface/imperative-playbook-to-composite-intent
+version: 1.0.0
+scenario:
+  description: "An infrastructure engineer replaces a working ~200-line imperative provisioning
+    playbook (VM create, host bridge plumbing, guest-image discovery by fetching a release
+    directory listing, hand-authored DNS A and PTR records, a post-provision filesystem-grow
+    play) with a single Composite catalog item. The probe that produced this case validated a
+    real playbook against the registry: the composite expresses the workload in a quarter of
+    the volume, and three playbook fragilities disappear structurally — the DNS record binds to
+    the VM's declared primary_ip output instead of repeating the address as a literal, the
+    guest image becomes a deferred-resolution vocabulary reference instead of runtime directory
+    grepping, and disk placement becomes storage-class tier intent instead of a filesystem
+    path with a migrate-later comment. Intent elements the model could not carry (vCPU
+    hot-resize ceiling, CPU passthrough mode, day-0 access bootstrap, thin-provisioning) were
+    filed as typed gaps rather than silently dropped."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+  intent: Express a complete single-VM workload (compute, static address on an isolated
+    segment, derived DNS, day-0 job) as one Composite catalog item that a provider can realize
+    without any imperative provisioning logic in the intent
+  success_criteria:
+  - The composite validates against the catalog-item contract and every constituent's
+    spec_defaults validate against its type's spec at full depth
+  - The DNS record's data arrives via a binding to the VM's declared primary_ip output and is
+    rejected if the output is not declared
+  - The guest image is a deferred-resolution reference; the intent document contains no
+    runtime discovery logic
+  - Provider mechanics (hypervisor packages, bridge plumbing, image download, guest
+    customization) appear nowhere in the intent
+  - Intent elements the model cannot express are surfaced as typed expressibility findings,
+    not silently dropped
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: composite_service
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the composite and every constituent payload validate against the registry contracts
+  - domain: policy
+    interaction: bindings to undeclared outputs are rejected at request time
+  - domain: provider
+    interaction: the provider owns all realization mechanics and populates declared outputs
+  - domain: audit
+    interaction: gaps found while authoring are recorded as findings with the source artifact as provenance
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: vm-live-probe-2026-07-25
+  timestamp: '2026-07-25T00:00:00Z'
+tags:
+- hammer
+- binding-surface
+- brownfield-migration
+- model-validation
diff --git a/dav/use-cases/hammer-binding-surface/004-worked-example-currency-per-type.yaml b/dav/use-cases/hammer-binding-surface/004-worked-example-currency-per-type.yaml
new file mode 100644
index 0000000..7261dc0
--- /dev/null
+++ b/dav/use-cases/hammer-binding-surface/004-worked-example-currency-per-type.yaml
@@ -0,0 +1,51 @@
+uuid: uc-a74fd0b0-3655-453f-9ff1-b6986f025835
+handle: binding-surface/worked-example-currency-per-type
+version: 1.0.0
+scenario:
+  description: "An engineer adopting a resource type starts from its worked example. A registry survey\
+    \ found examples drifting behind their specs (the VM example predated the type's reshape entirely\
+    \ \u2014 zero mentions of its current surface). This stresses the usability twin of the outputs gap:\
+    \ every type's worked example must exercise the CURRENT spec surface, and staleness must be detectable\
+    \ rather than discovered by a confused adopter."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Adopt a resource type via its worked example and find the example exercises the type's current
+    specification surface
+  success_criteria:
+  - Every registered type has at least one worked example
+  - The example validates against the type's current spec version
+  - Example staleness (fields absent from the example that the spec added) is mechanically detectable
+  - The example demonstrates the type's outputs being consumed where the type declares them
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: "the example is validated data, not prose \u2014 it tracks the spec"
+  - domain: policy
+    interaction: a currency gate can hold examples to the spec version
+  - domain: provider
+    interaction: examples show realistic provider interactions for the type
+  - domain: audit
+    interaction: example validation results are recordable
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: binding-surface-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- worked-examples
+- usability
+- currency
+- documentation
diff --git a/dav/use-cases/hammer-brownfield-discovery/001-discovered-only-unclaimed-resource.yaml b/dav/use-cases/hammer-brownfield-discovery/001-discovered-only-unclaimed-resource.yaml
new file mode 100644
index 0000000..8accdc1
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/001-discovered-only-unclaimed-resource.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-brownfield-001
+handle: brownfield-discovery/discovered-only-unclaimed-resource
+scenario:
+  description: 'A scan of a rack turns up a powered, cabled server that no team has ever declared. The
+    provider (a hardware-inventory information provider) emits a Discovered-state record with serial,
+    BMC address, and firmware, but there is NO corresponding Intent and no owning tenant. The system must
+    persist this as a first-class Discovered entity that carries brownfield provenance and a management_authority
+    of legacy, without inventing an Intent it does not have and without treating the absence of Intent
+    as an error. This probes whether the four-state model tolerates a Discovered-only entity — realized
+    reality with no declared intent — as a legitimate, queryable state.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - information-provider-owner
+    - compliance-auditor
+    - tenancy-authority
+  intent: Record a scanned, undeclared server as a Discovered-only entity with no Intent
+  success_criteria:
+  - The scanned resource is persisted as an entity in Discovered state
+  - The entity carries brownfield provenance and management_authority = legacy
+  - No Intent state is fabricated; the entity is valid with intent absent
+  - The entity is queryable and reportable as unclaimed (no owning tenant)
+  - A stable Entity UUID is assigned at discovery and does not change on re-scan
+  - The discovery event is recorded in the audit trail with source and timestamp
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: hardware-inventory information provider emits a Discovered-state record
+  - domain: data
+    interaction: Discovered-only entity persisted with brownfield provenance and stable UUID
+  - domain: audit
+    interaction: discovery event recorded with source, serial, and timestamp
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- discovered-state
+- unclaimed
+- no-intent
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/002-adopt-preserving-entity-uuid.yaml b/dav/use-cases/hammer-brownfield-discovery/002-adopt-preserving-entity-uuid.yaml
new file mode 100644
index 0000000..a88fc0a
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/002-adopt-preserving-entity-uuid.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-brownfield-002
+handle: brownfield-discovery/adopt-preserving-entity-uuid
+scenario:
+  description: 'A platform engineer adopts a previously Discovered server into DCM management. Adoption
+    must attach the entity to an owning tenant and flip management_authority from legacy to dcm WITHOUT
+    reassigning the Entity UUID that was minted at discovery. Any external correlation (BMC records, CMDB
+    rows, monitoring keyed on that UUID) must survive the transition. This validates that identity is
+    stable across the discovery-to-managed boundary — adoption is a state transition on an existing entity,
+    not the creation of a new one.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Adopt a discovered resource into management while preserving its Entity UUID
+  success_criteria:
+  - The adopted entity retains the exact Entity UUID assigned at discovery
+  - management_authority transitions from legacy to dcm at cutover
+  - The entity gains an owning tenant and enters the managed lifecycle
+  - No new entity is created and no duplicate UUID appears
+  - Adopt-in-place holds — the running resource is not restarted, recreated, or moved
+  - The authority transition is recorded with before/after provenance in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    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: entity transitioned to managed with UUID preserved and tenant attached
+  - domain: policy
+    interaction: adoption-scope validation confirms the entity is eligible for adoption
+  - domain: audit
+    interaction: management_authority legacy-to-dcm transition recorded with provenance
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- adoption
+- uuid-stability
+- adopt-in-place
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/003-correlate-entity-across-discovery-sources.yaml b/dav/use-cases/hammer-brownfield-discovery/003-correlate-entity-across-discovery-sources.yaml
new file mode 100644
index 0000000..1293f8c
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/003-correlate-entity-across-discovery-sources.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-brownfield-003
+handle: brownfield-discovery/correlate-entity-across-discovery-sources
+scenario:
+  description: 'The same physical host is reported by three independent discovery sources: a hardware-inventory
+    provider (by serial), an Ansible inventory (by hostname), and a network-scan provider (by MAC/IP).
+    The system must correlate all three observations into ONE entity using correlation_ids rather than
+    creating three near-duplicate entities. Each source identifier is retained on the entity as a correlation
+    key so future re-scans from any single source resolve to the same entity. This probes whether the
+    data model carries a multi-valued correlation_ids set and a deterministic correlation rule, or whether
+    it silently forks identity per source.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Correlate observations of one host from multiple discovery sources into a single entity
+  success_criteria:
+  - All three source observations resolve to exactly one entity
+  - The entity carries a correlation_ids set with the serial, hostname, and MAC/IP keys
+  - Re-scan from any single source resolves to the existing entity, creating no duplicate
+  - Conflicting non-key attributes are retained per-source rather than blindly overwritten
+  - The correlation decision and the keys that matched are recorded in the audit trail
+  - A stable Entity UUID spans all correlated observations
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: three information providers emit observations of the same host
+  - domain: data
+    interaction: observations merged into one entity via correlation_ids with per-source keys retained
+  - domain: audit
+    interaction: correlation decision and matched keys recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- correlation
+- correlation-ids
+- multi-source
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/004-long-lived-unclaimed-antipattern.yaml b/dav/use-cases/hammer-brownfield-discovery/004-long-lived-unclaimed-antipattern.yaml
new file mode 100644
index 0000000..6b14e54
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/004-long-lived-unclaimed-antipattern.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-brownfield-004
+handle: brownfield-discovery/long-lived-unclaimed-antipattern
+scenario:
+  description: 'A Discovered-only server has sat unclaimed for 180 days — the recorded antipattern: reality
+    the system knows about but no one governs. The architecture is expected to surface long-lived unclaimed
+    entities and force a decision — claim (adopt with an Intent) or retire (record as decommission-candidate)
+    — via a recovery policy, rather than letting Discovered-only entities accumulate indefinitely. This
+    probes whether there is any lifecycle pressure on Discovered-only state at all, or whether unclaimed
+    entities are inert forever. It likely comes back partially_supported or unsupported: the data model
+    can hold the age, but a policy that forces claim-or-retire may not exist.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Force a claim-or-retire decision on a resource unclaimed past a threshold
+  success_criteria:
+  - Entities in Discovered-only state past an age threshold are surfaced as a distinct class
+  - A recovery policy raises a claim-or-retire obligation for each such entity
+  - Claiming attaches an Intent and moves the entity into the managed lifecycle
+  - Retiring records the entity as a decommission-candidate without touching the running resource
+  - The age of the unclaimed state is tracked from the first discovery timestamp
+  - The unresolved-unclaimed condition is reported to governance as a standing finding
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: unclaimed age tracked from first-discovery timestamp on the Discovered entity
+  - domain: policy
+    interaction: recovery policy raises a claim-or-retire obligation past threshold
+  - domain: audit
+    interaction: standing unclaimed finding reported to governance
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- antipattern
+- unclaimed
+- claim-or-retire
+- recovery-policy
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/005-discovered-vs-realized-drift.yaml b/dav/use-cases/hammer-brownfield-discovery/005-discovered-vs-realized-drift.yaml
new file mode 100644
index 0000000..d36cd38
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/005-discovered-vs-realized-drift.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-brownfield-005
+handle: brownfield-discovery/discovered-vs-realized-drift
+scenario:
+  description: 'A host is under DCM management with a known realized state (16 cores, firmware 2.3). A
+    fresh discovery scan reports different reality — 32 cores, firmware 2.5 — because someone upgraded
+    it out-of-band. The system must detect the delta between the newly Discovered observation and the
+    recorded realized state, raise a drift record, and NOT silently overwrite realized state with the
+    discovery. Drift resolution (accept-as-new-realized, or restore-to-intent) must be an explicit, policy-governed
+    decision. This probes whether discovery feeds a drift-detection path distinct from the provider-realization
+    path.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+  intent: Detect out-of-band change as drift between discovered and realized state
+  success_criteria:
+  - The discovery observation is compared against the recorded realized state
+  - A drift record is raised capturing the specific attribute deltas
+  - Realized state is not silently overwritten by the discovery observation
+  - Drift resolution (accept-as-realized vs restore-to-intent) is a governed decision
+  - The drift record links the discovery source and timestamp to the affected entity
+  - The unresolved drift is visible to the owning tenant and to governance
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: discovery provider emits an observation diverging from realized state
+  - domain: data
+    interaction: discovered-vs-realized delta computed and persisted as a drift record
+  - domain: policy
+    interaction: drift-resolution policy governs accept-vs-restore decision
+  - domain: audit
+    interaction: drift record and its resolution recorded with source provenance
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- drift
+- discovered-vs-realized
+- out-of-band
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/006-brownfield-estate-full-ingestion.yaml b/dav/use-cases/hammer-brownfield-discovery/006-brownfield-estate-full-ingestion.yaml
new file mode 100644
index 0000000..2f43cc8
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/006-brownfield-estate-full-ingestion.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-brownfield-006
+handle: brownfield-discovery/brownfield-estate-full-ingestion
+scenario:
+  description: 'An operations team onboards an entire running datacenter estate at once — bare-metal hosts,
+    hypervisors, VMs, storage pools, network gear, and the dependency edges between them — by ingesting
+    several discovery sources in a single brownfield pass. Every resource becomes a Discovered/adopted
+    entity in place with brownfield provenance; groups become DCMGroups; and the derived dependency graph
+    must be internally consistent (no dangling edges, no cycles) before cutover. Nothing is recreated
+    or restarted. This is the full-stack stress of brownfield ingestion — many resource classes, many
+    dependencies, one coexistence window that remains reversible until cutover.
+
+    '
+  actor:
+    persona: platform-operator
+    profile: standard
+  perspectives:
+    - sre
+    - compliance-auditor
+  intent: Ingest a complete running estate as brownfield entities in place, with a consistent dependency
+    graph
+  success_criteria:
+  - Every discovered resource across all classes is ingested as an entity with brownfield provenance
+  - The derived dependency graph is acyclic and free of dangling edges before cutover
+  - Groups from the source inventories map to DCMGroups with membership preserved
+  - No resource is recreated, restarted, or migrated as a side effect of ingestion
+  - management_authority is legacy for all entities until an explicit per-scope cutover
+  - Ingestion is reversible before cutover — removing DCM management leaves the estate as found
+  - The full ingestion arc is recorded with per-entity provenance in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: multiple information providers supply hosts, VMs, storage, and network observations
+  - domain: data
+    interaction: all classes ingested as entities and DCMGroups with a validated dependency graph
+  - domain: policy
+    interaction: ingestion-scope, coexistence, and graph-consistency policies evaluated
+  - domain: audit
+    interaction: per-entity brownfield provenance and the ingestion arc recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- ingestion
+- full-stack
+- estate
+- dependency-graph
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/007-discovered-resource-unknown-provider.yaml b/dav/use-cases/hammer-brownfield-discovery/007-discovered-resource-unknown-provider.yaml
new file mode 100644
index 0000000..2aedd50
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/007-discovered-resource-unknown-provider.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-brownfield-007
+handle: brownfield-discovery/discovered-resource-unknown-provider
+scenario:
+  description: 'A discovery scan finds a running resource — a storage appliance exposing an unfamiliar
+    management API — that maps to no known provider capability. The system can record it as a Discovered
+    entity, but there is no provider able to claim, reconcile, or realize it. The architecture must represent
+    an entity whose provider is unknown WITHOUT blocking the rest of ingestion and without pretending
+    a provider exists. Adoption should be refused (or held) with a clear provider-gap finding rather than
+    a silent failure. This likely returns unsupported or partially_supported: Discovered state can hold
+    it, but a provider-less entity has no path into the managed lifecycle.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Record a discovered resource that maps to no known provider and surface the provider gap
+  success_criteria:
+  - The resource is persisted as a Discovered entity despite having no eligible provider
+  - The entity is flagged with a provider-unknown / provider-gap marker
+  - Adoption into the managed lifecycle is refused or held, not silently attempted
+  - The provider gap is reported as a finding that names the unrecognized management API
+  - The unresolvable entity does not block ingestion of the rest of the scan
+  - The provider-gap condition is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: no provider capability matches the discovered management API
+  - domain: data
+    interaction: entity persisted in Discovered state with a provider-unknown marker
+  - domain: audit
+    interaction: provider-gap finding recorded naming the unrecognized resource
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- provider-gap
+- unknown-provider
+- unsupported-probe
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/008-adopt-attaching-intent.yaml b/dav/use-cases/hammer-brownfield-discovery/008-adopt-attaching-intent.yaml
new file mode 100644
index 0000000..b5477a7
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/008-adopt-attaching-intent.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-brownfield-008
+handle: brownfield-discovery/adopt-attaching-intent
+scenario:
+  description: 'A team claims a Discovered-only host by authoring an Intent that matches its observed
+    reality — the act that moves a resource from "known but ungoverned" into the full managed lifecycle.
+    The system must attach the new Intent to the existing Discovered entity (preserving its UUID), reconcile
+    Intent against the discovered attributes, and — where Intent and reality already agree — treat realization
+    as a no-op adopt rather than a rebuild. Where Intent asks for more than reality provides, the delta
+    becomes managed work. This validates that Intent can be attached to an already-existing entity after
+    the fact, closing the Discovered-only gap.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Attach an Intent to a discovered resource to bring it under managed lifecycle
+  success_criteria:
+  - The authored Intent attaches to the existing Discovered entity without changing its UUID
+  - Intent is reconciled against the discovered attributes to compute any delta
+  - Where Intent matches reality, adoption is a no-op — no rebuild or restart occurs
+  - Where Intent exceeds reality, the delta is recorded as managed reconciliation work
+  - The entity leaves Discovered-only state and enters the governed lifecycle
+  - The intent-attachment and reconciliation outcome are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: hard_dependencies
+    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 attached to the existing entity and reconciled against discovered attributes
+  - domain: policy
+    interaction: validation confirms the attached Intent is admissible for the entity
+  - domain: provider
+    interaction: provider performs a no-op adopt where Intent already matches reality
+  - domain: audit
+    interaction: intent attachment and reconciliation delta recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- adoption
+- attach-intent
+- lifecycle-entry
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/009-discovery-stream-retention-vs-durable-inventory.yaml b/dav/use-cases/hammer-brownfield-discovery/009-discovery-stream-retention-vs-durable-inventory.yaml
new file mode 100644
index 0000000..b159c13
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/009-discovery-stream-retention-vs-durable-inventory.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-brownfield-009
+handle: brownfield-discovery/discovery-stream-retention-vs-durable-inventory
+scenario:
+  description: 'Discovery sources emit a high-volume stream of transient observations (a scan every five
+    minutes), but the durable inventory should hold entities, not raw observation history forever. The
+    architecture must distinguish a bounded-retention discovery stream from the durable entity store:
+    observations age out on a retention window, while the derived entities, their correlation_ids, and
+    the last-known Discovered state persist. An auditor must still be able to answer "when was this first
+    and last seen" from durable fields even after the raw stream has expired. This probes whether the
+    model separates ephemeral discovery telemetry from durable inventory, or conflates the two.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: standard
+  perspectives: []
+  intent: Separate bounded-retention discovery observations from durable inventory entities
+  success_criteria:
+  - Raw discovery observations are retained on a bounded window and then aged out
+  - Derived entities, correlation_ids, and last-known Discovered state persist durably
+  - First-seen and last-seen timestamps survive on the entity after the raw stream expires
+  - Aging out observations never deletes or orphans the durable entity
+  - An auditor can reconstruct discovery timing from durable fields alone
+  - Retention-window configuration and expiry events are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: discovery provider emits a high-volume stream of transient observations
+  - domain: data
+    interaction: bounded-retention stream separated from durable entity store with preserved first/last-seen
+  - domain: audit
+    interaction: retention configuration and observation-expiry events recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- retention
+- discovery-stream
+- durable-inventory
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/010-adopt-resource-violating-policy.yaml b/dav/use-cases/hammer-brownfield-discovery/010-adopt-resource-violating-policy.yaml
new file mode 100644
index 0000000..50175eb
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/010-adopt-resource-violating-policy.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-brownfield-010
+handle: brownfield-discovery/adopt-resource-violating-policy
+scenario:
+  description: 'An operator tries to adopt a discovered VM that violates current policy — it runs an end-of-life
+    OS and stores unencrypted data, both banned by the active compliance-gated profile. Adoption must
+    NOT be a blanket exception: the system evaluates the discovered attributes against current policy
+    at the moment of adoption and refuses to move the entity into fully-compliant managed state. The realistic
+    outcome is a governed middle ground — adopt into a quarantined/non-conformant managed state with a
+    remediation obligation, or refuse adoption entirely. This probes whether policy is enforced at the
+    adoption boundary and whether a non-conformant managed state exists at all.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Adopt a discovered resource that fails current policy without granting a blanket exception
+  success_criteria:
+  - Discovered attributes are evaluated against current policy at the point of adoption
+  - Adoption into fully-compliant managed state is refused for the violating entity
+  - The entity is either quarantined as non-conformant with a remediation obligation, or refused outright
+  - The specific violated policies (EOL OS, unencrypted data) are named in the finding
+  - No silent exception is granted; the non-conformance is visible to governance
+  - The adoption attempt and its policy verdict are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: discovered attributes surfaced for policy evaluation at adoption
+  - domain: policy
+    interaction: current compliance policy evaluated; adoption refused or quarantined
+  - domain: audit
+    interaction: violated policies and the adoption verdict recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- adoption
+- policy-violation
+- quarantine
+- fsi
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/011-rediscovery-idempotent-no-duplicate.yaml b/dav/use-cases/hammer-brownfield-discovery/011-rediscovery-idempotent-no-duplicate.yaml
new file mode 100644
index 0000000..924e62e
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/011-rediscovery-idempotent-no-duplicate.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-brownfield-011
+handle: brownfield-discovery/rediscovery-idempotent-no-duplicate
+scenario:
+  description: 'A discovery source re-scans on its normal cadence and reports the same host it reported
+    last cycle, with no attribute changes. The system must recognize the observation as a re-discovery
+    of an existing entity (via correlation_ids), update last-seen, and produce no new entity, no drift
+    record, and no state churn. This is the discovery-side idempotency guarantee — steady-state scanning
+    of an unchanged estate must be a no-op beyond refreshing liveness. A simple happy-path baseline against
+    which the drift and correlation edge cases are measured.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+  intent: Re-scan an unchanged host and confirm idempotent no-op discovery
+  success_criteria:
+  - The re-scan resolves to the existing entity via correlation_ids
+  - No duplicate entity is created
+  - last-seen is refreshed while first-seen is preserved
+  - No drift record is raised for an unchanged observation
+  - No managed state churn or provider dispatch results from the re-scan
+  - The re-discovery is recorded as a liveness refresh in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    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: provider
+    interaction: discovery source re-emits an unchanged observation
+  - domain: data
+    interaction: observation resolved to existing entity; last-seen refreshed, no duplicate
+  - domain: audit
+    interaction: liveness refresh recorded, no drift
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- rediscovery
+- idempotent
+- no-op
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/012-discovered-orphan-no-owner.yaml b/dav/use-cases/hammer-brownfield-discovery/012-discovered-orphan-no-owner.yaml
new file mode 100644
index 0000000..90f1fd0
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/012-discovered-orphan-no-owner.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-brownfield-012
+handle: brownfield-discovery/discovered-orphan-no-owner
+scenario:
+  description: 'Discovery finds a running VM on a managed hypervisor that belongs to no known tenant —
+    an orphan with a clear host dependency but no owning organization. The system must ingest it as a
+    Discovered entity, record the resolved dependency on its hypervisor, and flag it as owner-unknown
+    so it cannot be chargeback-attributed or governed until an owner is assigned. It must not be auto-assigned
+    to the hypervisor''s owner by inference. This probes whether the model tolerates a dependency-bearing
+    entity with a null owning tenant and surfaces ownership as an explicit gap.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - finance-analyst
+    - tenancy-authority
+  intent: Ingest an owner-unknown discovered VM and surface the missing ownership as a gap
+  success_criteria:
+  - The orphan VM is ingested as a Discovered entity with its hypervisor dependency resolved
+  - The entity carries an owner-unknown marker and a null owning tenant
+  - Ownership is not inferred or auto-assigned from the hosting hypervisor
+  - The entity is excluded from chargeback attribution until an owner is assigned
+  - The missing-owner condition is surfaced as a finding to governance
+  - The orphan discovery and its dependency edge are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: hypervisor information provider reports a VM with no tenant tag
+  - domain: data
+    interaction: entity ingested with resolved host dependency and null owning tenant
+  - domain: policy
+    interaction: ownership-required policy excludes the entity from chargeback and flags it
+  - domain: audit
+    interaction: orphan discovery and missing-owner finding recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- orphan
+- owner-unknown
+- chargeback
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/013-discovered-then-externally-retired.yaml b/dav/use-cases/hammer-brownfield-discovery/013-discovered-then-externally-retired.yaml
new file mode 100644
index 0000000..4c08d6b
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/013-discovered-then-externally-retired.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-brownfield-013
+handle: brownfield-discovery/discovered-then-externally-retired
+scenario:
+  description: 'A previously discovered and adopted host stops appearing in the discovery stream — it
+    was decommissioned out-of-band (pulled from the rack) without going through DCM''s decommission flow.
+    The system must detect the absence as drift (a managed entity whose reality has vanished), rather
+    than keeping it indefinitely as present or silently deleting it. Absence must be distinguished from
+    a missed scan: only sustained absence across a configured number of cycles converts to a presumed-retired/decommission-candidate
+    finding. This probes whether discovery models negative observations — the disappearance of expected
+    reality — at all.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+  intent: Detect a managed resource disappearing from discovery as drift, not a missed scan
+  success_criteria:
+  - Sustained absence across a configured number of scan cycles is detected
+  - A single missed scan does not trigger a retirement conclusion
+  - The vanished managed entity is flagged as presumed-retired / decommission-candidate
+  - The entity is not silently deleted; its record and history persist for review
+  - The discrepancy between realized (present) and discovered (absent) is raised as drift
+  - The presumed-retirement finding is recorded with the last-seen timestamp
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: discovery stream stops reporting a previously present host
+  - domain: data
+    interaction: sustained absence computed against last-seen and raised as a drift record
+  - domain: policy
+    interaction: absence-threshold policy converts sustained absence to a retirement candidate
+  - domain: audit
+    interaction: presumed-retirement finding recorded with last-seen timestamp
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- drift
+- negative-observation
+- presumed-retired
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/014-partial-discovery-incomplete-attributes.yaml b/dav/use-cases/hammer-brownfield-discovery/014-partial-discovery-incomplete-attributes.yaml
new file mode 100644
index 0000000..a84bd1d
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/014-partial-discovery-incomplete-attributes.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-brownfield-014
+handle: brownfield-discovery/partial-discovery-incomplete-attributes
+scenario:
+  description: 'A discovery source returns a partial record — it knows a host''s MAC and IP but its credentials
+    were rejected, so CPU, memory, and firmware are unknown. The system must ingest the entity with the
+    attributes it has, mark the missing attributes as unknown (not zero, not defaulted), and hold the
+    entity in an incomplete-discovery state that blocks adoption until the record is completed. A later
+    scan that fills the gaps must upgrade the same entity in place. This probes whether the model distinguishes
+    unknown from absent/zero and whether incompleteness gates adoption rather than silently producing
+    a wrong entity.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - security-officer
+  intent: Ingest a partially-discovered resource without defaulting unknown attributes
+  success_criteria:
+  - Known attributes (MAC, IP) are ingested; unknown attributes are marked unknown, not defaulted to zero
+  - The entity is held in an incomplete-discovery state that blocks adoption
+  - The reason for incompleteness (credential rejection) is recorded on the entity
+  - A later completing scan upgrades the same entity in place, preserving its UUID
+  - Adoption becomes possible only once required attributes are no longer unknown
+  - The incomplete-discovery condition and its later resolution are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: discovery source returns a partial record after credential rejection
+  - domain: data
+    interaction: entity ingested with unknown-marked attributes and an incomplete-discovery state
+  - domain: policy
+    interaction: completeness policy gates adoption until required attributes are known
+  - domain: audit
+    interaction: incompleteness cause and later completion recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- partial-discovery
+- unknown-vs-absent
+- completeness-gate
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/015-brownfield-dependency-inference.yaml b/dav/use-cases/hammer-brownfield-discovery/015-brownfield-dependency-inference.yaml
new file mode 100644
index 0000000..069f0dd
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/015-brownfield-dependency-inference.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-brownfield-015
+handle: brownfield-discovery/brownfield-dependency-inference
+scenario:
+  description: 'Discovery yields a set of independent entities — VMs, a database, a load balancer — but
+    the dependencies between them (the app tier talks to the DB; the LB fronts the app tier) are not declared
+    anywhere; they must be INFERRED from observed network flows and config. The system is asked to derive
+    candidate dependency edges from discovery signals and present them for confirmation, rather than assuming
+    a flat, dependency-free estate. Inferred edges must be marked as low-confidence until confirmed, and
+    must never be treated as authoritative hard_dependencies without human sign-off. This likely returns
+    partially_supported or unsupported: discovery observes resources, but flow-based dependency inference
+    may be beyond the model.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Infer candidate dependencies among discovered resources from observed signals
+  success_criteria:
+  - Candidate dependency edges are derived from observed network flows and configuration
+  - Inferred edges are marked low-confidence and distinct from declared dependencies
+  - No inferred edge is promoted to an authoritative hard dependency without confirmation
+  - Confirmed edges become part of the entity dependency graph; rejected ones are discarded
+  - The evidence behind each inferred edge (which flow/config) is retained
+  - Inference, confirmation, and rejection decisions are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: flow and config information providers supply dependency signals
+  - domain: data
+    interaction: low-confidence candidate edges derived and held distinct from declared edges
+  - domain: policy
+    interaction: confirmation policy governs promotion of inferred edges to the dependency graph
+  - domain: audit
+    interaction: inference evidence and confirm/reject decisions recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- dependency-inference
+- low-confidence
+- multi-dependent
+- unsupported-probe
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/016-adopt-embedded-plaintext-credentials.yaml b/dav/use-cases/hammer-brownfield-discovery/016-adopt-embedded-plaintext-credentials.yaml
new file mode 100644
index 0000000..418c561
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/016-adopt-embedded-plaintext-credentials.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-brownfield-016
+handle: brownfield-discovery/adopt-embedded-plaintext-credentials
+scenario:
+  description: 'A discovered application host carries embedded plaintext credentials in its config (a
+    DB password, an API token) that the discovery source surfaced. On adoption, no plaintext secret may
+    survive into the managed entity definition: each is converted to a vault-backed credential resource,
+    the entity references the vault handle, and each converted secret is flagged for rotation because
+    it was exposed. Adoption must fail closed if any detected plaintext cannot be vaulted. This validates
+    the credential-hygiene obligation at the discovery-to-managed boundary — a hard requirement for FSI-grade
+    brownfield onboarding.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Adopt a discovered host while vaulting all embedded plaintext credentials
+  success_criteria:
+  - Every embedded plaintext credential surfaced by discovery is detected
+  - Each is converted to a vault-backed credential resource referenced by handle from the entity
+  - No plaintext credential survives into the managed entity definition
+  - Each converted credential is flagged for rotation because it was exposed
+  - Adoption fails closed if any detected plaintext cannot be vaulted
+  - Each detection, conversion, and rotation flag is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: provider
+    interaction: discovery source surfaces embedded plaintext credentials on the host
+  - domain: data
+    interaction: credentials converted to vault-backed resources; entity holds only vault handles
+  - domain: policy
+    interaction: credential-hygiene policy enforces no-plaintext and rotation flags, failing closed
+  - domain: audit
+    interaction: detection, conversion, and rotation flags recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- credentials
+- vault
+- credential-hygiene
+- fsi
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/017-conflicting-discovery-sources.yaml b/dav/use-cases/hammer-brownfield-discovery/017-conflicting-discovery-sources.yaml
new file mode 100644
index 0000000..2a19ea5
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/017-conflicting-discovery-sources.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-brownfield-017
+handle: brownfield-discovery/conflicting-discovery-sources
+scenario:
+  description: 'Two discovery sources agree on identity (same host, correlated by serial) but DISAGREE
+    on a material attribute: the CMDB says 64 GB RAM, the live hardware scan says 128 GB. The system must
+    correlate them to one entity yet not silently pick a winner. It must record the conflict, apply a
+    source-precedence policy (live scan outranks stale CMDB) to choose an effective value, retain the
+    losing value with its source, and surface the conflict so the stale source can be corrected. This
+    probes whether the model supports per-attribute provenance and source precedence, or collapses to
+    last-writer-wins.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Reconcile conflicting attribute values from two correlated discovery sources
+  success_criteria:
+  - The two observations correlate to a single entity via matching keys
+  - The conflicting attribute is recorded as a conflict rather than silently overwritten
+  - A source-precedence policy selects the effective value (live scan over stale CMDB)
+  - The losing value is retained with its source for traceability
+  - The conflict is surfaced so the stale source can be reconciled
+  - The conflict and precedence decision are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: CMDB and live-scan providers emit conflicting values for one attribute
+  - domain: data
+    interaction: per-attribute provenance retained; effective value chosen, loser kept
+  - domain: policy
+    interaction: source-precedence policy resolves the conflict deterministically
+  - domain: audit
+    interaction: conflict and precedence decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- conflict
+- source-precedence
+- per-attribute-provenance
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/018-discover-sovereign-jurisdiction-adopt.yaml b/dav/use-cases/hammer-brownfield-discovery/018-discover-sovereign-jurisdiction-adopt.yaml
new file mode 100644
index 0000000..c238cc8
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/018-discover-sovereign-jurisdiction-adopt.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-brownfield-018
+handle: brownfield-discovery/discover-sovereign-jurisdiction-adopt
+scenario:
+  description: 'Discovery finds a running database in an in-country datacenter that falls under a sovereign
+    data residency mandate. Adoption must not proceed on hardware attributes alone — the residency jurisdiction
+    of the discovered resource must be captured at discovery and re-evaluated against the sovereign profile
+    at adoption. If the resource holds regulated data but its location or its dependency edges (a backup
+    target abroad) would breach residency, adoption into managed state must be gated until the breach
+    is resolved. This probes whether sovereignty is a cross-domain constraint enforced on brownfield adoption,
+    not just on new provisioning.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: Adopt a discovered resource under a sovereign residency mandate without breaching it
+  success_criteria:
+  - The residency jurisdiction of the discovered resource is captured at discovery
+  - Sovereignty is re-evaluated against the sovereign profile at the point of adoption
+  - Adoption is gated if the resource or its dependency edges would breach residency
+  - A cross-border dependency (e.g. a foreign backup target) is detected as a breach, not ignored
+  - Adoption proceeds only once the residency breach is resolved or waived by governance
+  - The residency evaluation and adoption gate are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: discovery reports the resource's location and its dependency targets
+  - domain: data
+    interaction: residency jurisdiction captured on the entity and its dependency edges
+  - domain: policy
+    interaction: sovereignty cross-domain constraint gates adoption on residency compliance
+  - domain: audit
+    interaction: residency evaluation and adoption gate recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- sovereignty
+- residency
+- adoption-gate
+- sovereign
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/019-reject-adoption-unknown-udlm-type.yaml b/dav/use-cases/hammer-brownfield-discovery/019-reject-adoption-unknown-udlm-type.yaml
new file mode 100644
index 0000000..1717fa4
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/019-reject-adoption-unknown-udlm-type.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-brownfield-019
+handle: brownfield-discovery/reject-adoption-unknown-udlm-type
+scenario:
+  description: 'Discovery finds a resource class UDLM has no type for — a specialized FPGA accelerator
+    card with no matching catalog type or schema. The system can note the raw observation, but there is
+    no UDLM type to model it as a first-class entity, so it cannot be adopted, governed, or realized.
+    The architecture must refuse adoption with a clear type-gap finding (naming the missing UDLM type)
+    rather than shoehorning it into a generic type and losing fidelity. This likely returns unsupported:
+    it exposes a catalog coverage gap that only a new UDLM type can close, and is exactly the kind of
+    finding the hammer round is meant to surface.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Refuse adoption of a discovered resource with no matching UDLM type and surface the type gap
+  success_criteria:
+  - The raw observation is noted but not modeled as a first-class typed entity
+  - Adoption is refused because no UDLM type matches the resource class
+  - The resource is not coerced into a generic type that would lose fidelity
+  - A type-gap finding names the missing UDLM type needed to model the resource
+  - The rest of the discovery scan proceeds unaffected by the unmodellable resource
+  - The type-gap and adoption refusal are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: discovery reports a resource class with no UDLM type
+  - domain: data
+    interaction: no first-class entity can be modeled; observation held as untyped with a type-gap marker
+  - domain: policy
+    interaction: type-coverage check refuses adoption of an unmodellable resource
+  - domain: audit
+    interaction: type-gap finding and refusal recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- type-gap
+- unknown-type
+- catalog-coverage
+- unsupported-probe
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-brownfield-discovery/020-discovery-source-disconnect-partial-scan.yaml b/dav/use-cases/hammer-brownfield-discovery/020-discovery-source-disconnect-partial-scan.yaml
new file mode 100644
index 0000000..c7fe607
--- /dev/null
+++ b/dav/use-cases/hammer-brownfield-discovery/020-discovery-source-disconnect-partial-scan.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-brownfield-020
+handle: brownfield-discovery/discovery-source-disconnect-partial-scan
+scenario:
+  description: 'A brownfield ingestion is running against a peer DCM''s discovery feed for a remote site
+    when that peer disconnects mid-scan, leaving the inventory partially populated — some hosts ingested,
+    some dependency edges dangling to not-yet-seen targets. The system must treat the partial scan as
+    incomplete rather than authoritative: entities already ingested are retained as provisional, dangling
+    edges are held pending, and cutover is blocked until the scan completes on reconnect. It must not
+    conclude that un-ingested resources were retired. This probes brownfield ingestion resilience under
+    a peer disconnect — resumability and partial-state integrity.
+
+    '
+  actor:
+    persona: platform-operator
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+  intent: Survive a peer-DCM disconnect mid-ingestion without corrupting the partial inventory
+  success_criteria:
+  - Entities ingested before the disconnect are retained as provisional, not authoritative
+  - Dangling dependency edges to unseen targets are held pending rather than dropped
+  - The system does not conclude that un-ingested resources were retired
+  - Cutover is blocked while the scan is known-incomplete
+  - On reconnect the ingestion resumes and completes without re-creating provisional entities
+  - The disconnect, partial state, and resumption are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peer DCM discovery feed disconnects mid-scan leaving inventory partial
+  - domain: data
+    interaction: ingested entities held provisional; dangling edges pending; no false retirement
+  - domain: policy
+    interaction: completeness policy blocks cutover while the scan is incomplete
+  - domain: audit
+    interaction: disconnect, partial state, and resumption recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- brownfield-discovery
+- peer-disconnect
+- partial-scan
+- resumable-ingestion
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/001-single-provider-baseline-placement.yaml b/dav/use-cases/hammer-capacity-placement/001-single-provider-baseline-placement.yaml
new file mode 100644
index 0000000..1310658
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/001-single-provider-baseline-placement.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-capacity-001
+handle: capacity/single-provider-baseline-placement
+scenario:
+  description: 'A platform engineer requests a single standalone VM in an environment where exactly one
+    provider is eligible and has ample capacity. The placement engine must query the provider, confirm
+    available capacity, reserve it, and realize the resource with no scoring contest. This is the baseline
+    capacity-and-placement path that every more complex case builds on; it must be a clean happy path
+    with a recorded reservation.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+  intent: Place a single VM on the only eligible provider with capacity
+  success_criteria:
+  - Placement engine identifies the single eligible provider
+  - Provider capacity query confirms headroom for the request
+  - Capacity is reserved before dispatch
+  - Resource is realized on the reserved provider
+  - Reservation is converted to an allocation on successful realization
+  - Placement decision and reservation id are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: single eligible provider queried, capacity reserved and allocated
+  - domain: policy
+    interaction: system default placement policy evaluated
+  - domain: audit
+    interaction: placement decision and reservation id recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:01.000000+00:00'
+tags:
+- capacity
+- placement
+- single-provider
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/002-multi-provider-scored-selection.yaml b/dav/use-cases/hammer-capacity-placement/002-multi-provider-scored-selection.yaml
new file mode 100644
index 0000000..c4af164
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/002-multi-provider-scored-selection.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-capacity-002
+handle: capacity/multi-provider-scored-selection
+scenario:
+  description: 'An application team requests a compute resource in a landscape where several providers
+    are eligible and have capacity. The placement engine must score candidates on declared capability
+    match and an attestation floor, breaking ties deterministically, then reserve on the winning provider
+    only. This tests that provider selection is a scored, explainable decision rather than first-fit,
+    and that the losing candidates are never reserved.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: prod
+  perspectives:
+    - provider-owner
+    - compliance-auditor
+  intent: Select the best-scoring provider among several eligible candidates
+  success_criteria:
+  - All eligible providers with capacity are enumerated as candidates
+  - Each candidate is scored on capability match and attestation level
+  - Candidates below the attestation floor are excluded before scoring
+  - A single winning provider is chosen by deterministic score ordering
+  - Only the winning provider receives a capacity reservation
+  - The score vector and selection rationale are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: candidate providers scored on capability and attestation, winner reserved
+  - domain: policy
+    interaction: attestation-floor validation excludes under-attested candidates
+  - domain: audit
+    interaction: score vector and selection rationale recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:02.000000+00:00'
+tags:
+- capacity
+- placement
+- provider-selection
+- scoring
+- attestation
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/003-all-providers-capacity-exhausted.yaml b/dav/use-cases/hammer-capacity-placement/003-all-providers-capacity-exhausted.yaml
new file mode 100644
index 0000000..5502041
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/003-all-providers-capacity-exhausted.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-capacity-003
+handle: capacity/all-providers-capacity-exhausted
+scenario:
+  description: 'A platform engineer submits a valid request but every eligible provider reports zero available
+    capacity at reservation time. The placement engine must exhaust the candidate set, fail closed with
+    a RESERVE_QUERY_ALL_EXHAUSTED condition, hold no partial reservation, and leave the resource in a
+    pending/blocked state that can be retried when capacity returns. This probes whether the architecture
+    models capacity exhaustion as a first-class, recoverable outcome rather than a hard error.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+  intent: Place a resource when no eligible provider has capacity
+  success_criteria:
+  - Every eligible provider is queried for capacity
+  - All candidates report insufficient capacity
+  - The engine raises RESERVE_QUERY_ALL_EXHAUSTED and fails closed
+  - No partial or speculative reservation is left held on any provider
+  - The resource is left in a retryable pending state, not realized
+  - The exhaustion outcome and the candidate set queried are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: all eligible providers queried and report exhausted capacity
+  - domain: policy
+    interaction: fail-closed placement policy blocks realization
+  - domain: audit
+    interaction: RESERVE_QUERY_ALL_EXHAUSTED outcome and candidate set recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:03.000000+00:00'
+tags:
+- capacity
+- exhaustion
+- reserve-query-all-exhausted
+- fail-closed
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/004-sovereignty-allowed-zones-placement.yaml b/dav/use-cases/hammer-capacity-placement/004-sovereignty-allowed-zones-placement.yaml
new file mode 100644
index 0000000..201547e
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/004-sovereignty-allowed-zones-placement.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-capacity-004
+handle: capacity/sovereignty-allowed-zones-placement
+scenario:
+  description: 'A compliance-bound tenant declares a workload that may only be placed within a sovereignty-defined
+    set of allowed zones. The placement engine must intersect the eligible-provider set with the allowed-zones
+    set before scoring, reserve capacity only inside the permitted geography, and reject any otherwise-cheaper
+    out-of-zone candidate. This validates that residency is a hard placement constraint applied ahead
+    of capacity scoring, not a soft preference.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Place a workload only within a sovereignty allowed-zones set
+  success_criteria:
+  - Allowed-zones set is resolved from the sovereignty policy for the tenant
+  - Candidate providers outside the allowed zones are excluded before scoring
+  - Only in-zone providers with capacity are scored and reserved
+  - A cheaper out-of-zone candidate is demonstrably rejected
+  - The realized resource resides in a permitted zone
+  - The zone constraint and the exclusion of out-of-zone candidates are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty allowed-zones constraint intersected with candidate set
+  - domain: provider
+    interaction: only in-zone providers scored and reserved
+  - domain: audit
+    interaction: zone constraint and out-of-zone exclusions recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:04.000000+00:00'
+tags:
+- capacity
+- placement
+- sovereignty
+- allowed-zones
+- residency
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/005-sovereign-no-in-zone-capacity.yaml b/dav/use-cases/hammer-capacity-placement/005-sovereign-no-in-zone-capacity.yaml
new file mode 100644
index 0000000..8313c5c
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/005-sovereign-no-in-zone-capacity.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-capacity-005
+handle: capacity/sovereign-no-in-zone-capacity
+scenario:
+  description: 'Under a strict sovereign mandate, a tenant requests placement but the only providers with
+    free capacity sit outside the mandated zones, while every in-zone provider is exhausted. The engine
+    must NOT relax the sovereignty constraint to satisfy capacity; it must fail closed with no placement.
+    This probes the collision of two hard constraints (residency and capacity) and confirms the architecture
+    never trades sovereignty for availability — a scenario that may return unsupported if no fail-closed
+    path exists.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Place under a sovereign mandate when only out-of-zone capacity exists
+  success_criteria:
+  - In-zone providers are queried and all report exhausted capacity
+  - Out-of-zone providers with capacity are identified but excluded by the mandate
+  - The sovereignty constraint is never relaxed to obtain capacity
+  - The request fails closed with no reservation held anywhere
+  - The resource is not realized outside the mandated zones
+  - The dual-constraint conflict and fail-closed decision are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: provider_failure
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereign mandate held firm against capacity pressure
+  - domain: provider
+    interaction: in-zone exhausted, out-of-zone excluded, no reservation made
+  - domain: audit
+    interaction: dual-constraint conflict and fail-closed outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:05.000000+00:00'
+tags:
+- capacity
+- sovereignty
+- exhaustion
+- fail-closed
+- constraint-conflict
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/006-attestation-floor-gates-placement.yaml b/dav/use-cases/hammer-capacity-placement/006-attestation-floor-gates-placement.yaml
new file mode 100644
index 0000000..c12d55b
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/006-attestation-floor-gates-placement.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-capacity-006
+handle: capacity/attestation-floor-gates-placement
+scenario:
+  description: 'An FSI tenant requires that workloads land only on nodes whose current attestation meets
+    a declared floor. Among a mixed pool of attested and unattested providers with capacity, the placement
+    engine must gate on live attestation evidence before scoring, admitting only nodes at or above the
+    floor. This tests attestation as an admission gate on placement rather than a post-hoc audit check.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - provider-owner
+    - compliance-auditor
+    - tenancy-authority
+  intent: Admit placement only on nodes meeting the attestation floor
+  success_criteria:
+  - Live attestation evidence is collected for each candidate provider
+  - Providers below the attestation floor are excluded from candidacy
+  - Only at-or-above-floor providers are scored and reserved
+  - The realized node's attestation state is captured at placement time
+  - A capacity-rich but under-attested provider is demonstrably rejected
+  - Attestation evidence and admission decisions are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: attestation-floor admission gate evaluated before scoring
+  - domain: provider
+    interaction: attested providers scored and reserved, unattested excluded
+  - domain: audit
+    interaction: attestation evidence and admission decisions recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:06.000000+00:00'
+tags:
+- capacity
+- placement
+- attestation-floor
+- admission-gate
+- fsi
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/007-attestation-floor-none-qualify.yaml b/dav/use-cases/hammer-capacity-placement/007-attestation-floor-none-qualify.yaml
new file mode 100644
index 0000000..ba78c9d
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/007-attestation-floor-none-qualify.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-capacity-007
+handle: capacity/attestation-floor-none-qualify
+scenario:
+  description: 'A compliance-gated request declares an attestation floor that no provider in the eligible
+    pool currently satisfies, though several have ample capacity. The placement engine must not down-rank
+    the floor to capture capacity; it must fail closed with no placement and surface that the blocker
+    is attestation, not capacity. This probes whether the architecture distinguishes an attestation-blocked
+    outcome from a capacity one, and may return unsupported if the two failure modes are conflated.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+  intent: Place under an attestation floor no eligible provider meets
+  success_criteria:
+  - Attestation evidence is gathered for all capacity-eligible providers
+  - No provider meets the declared attestation floor
+  - The floor is never lowered to admit an under-attested provider
+  - The request fails closed with attestation named as the distinct blocker
+  - No reservation is held on any provider
+  - The attestation-blocked outcome (distinct from exhaustion) is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: provider_failure
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: attestation floor held; blocker classified as attestation not capacity
+  - domain: provider
+    interaction: capacity-rich but under-attested providers all rejected
+  - domain: audit
+    interaction: attestation-blocked outcome recorded distinctly from exhaustion
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:07.000000+00:00'
+tags:
+- capacity
+- attestation-floor
+- fail-closed
+- blocker-classification
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/008-time-sync-capability-floor-placement.yaml b/dav/use-cases/hammer-capacity-placement/008-time-sync-capability-floor-placement.yaml
new file mode 100644
index 0000000..ed42774
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/008-time-sync-capability-floor-placement.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-capacity-008
+handle: capacity/time-sync-capability-floor-placement
+scenario:
+  description: 'An FSI trading workload requires nodes whose attested time-synchronization capability
+    (traceable, bounded-offset clock) meets a profile-defined floor for regulatory timestamping. The placement
+    engine must treat attested time-sync as a scored capability admission criterion, admitting only providers
+    whose current attested clock quality clears the floor. This tests capability-typed placement where
+    the deciding attribute is an operational, time-varying attestation, not a static provider label.
+
+    '
+  actor:
+    persona: sre
+    profile: fsi
+  perspectives:
+    - provider-owner
+    - compliance-auditor
+    - regulator
+  intent: Place only where attested time-sync capability meets the profile floor
+  success_criteria:
+  - The profile's time-sync capability floor is resolved for the request
+  - Each candidate's attested clock quality is evaluated against the floor
+  - Providers whose attested time-sync is below the floor are excluded
+  - Remaining candidates are scored on capability match and capacity
+  - The realized node's attested time-sync record is captured at placement
+  - The capability floor evaluation and exclusions are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: time-sync capability floor evaluated as an admission criterion
+  - domain: provider
+    interaction: providers with sufficient attested clock quality scored and reserved
+  - domain: audit
+    interaction: capability floor evaluation and node time-sync record captured
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:08.000000+00:00'
+tags:
+- capacity
+- placement
+- time-sync
+- capability-floor
+- attestation
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/009-affinity-colocation-across-resources.yaml b/dav/use-cases/hammer-capacity-placement/009-affinity-colocation-across-resources.yaml
new file mode 100644
index 0000000..2a3bc6c
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/009-affinity-colocation-across-resources.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-capacity-009
+handle: capacity/affinity-colocation-across-resources
+scenario:
+  description: 'An application team declares two resources — a latency-sensitive app tier and its in-memory
+    cache — that must be co-located on the same provider (or fault domain) via an affinity rule. The placement
+    engine must solve placement jointly: reserve capacity for both on a provider that can host the pair,
+    rather than placing each greedily. This tests whether affinity is a cross-resource placement constraint
+    the engine can satisfy in one coherent decision.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: prod
+  perspectives:
+    - provider-owner
+  intent: Co-locate two affine resources on the same provider
+  success_criteria:
+  - The affinity rule between the two resources is resolved before placement
+  - The engine finds a provider with capacity for both resources jointly
+  - Both resources are reserved on the same provider or fault domain
+  - Greedy independent placement that would violate affinity is avoided
+  - Both resources realize on the co-located target
+  - The affinity constraint and joint placement decision are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: affinity constraint resolved across the two resources
+  - domain: provider
+    interaction: joint capacity reservation on a single co-location target
+  - domain: audit
+    interaction: affinity constraint and joint placement decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:09.000000+00:00'
+tags:
+- capacity
+- placement
+- affinity
+- colocation
+- multi-resource
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/010-anti-affinity-fault-domain-spread.yaml b/dav/use-cases/hammer-capacity-placement/010-anti-affinity-fault-domain-spread.yaml
new file mode 100644
index 0000000..95dd67a
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/010-anti-affinity-fault-domain-spread.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-capacity-010
+handle: capacity/anti-affinity-fault-domain-spread
+scenario:
+  description: 'An SRE declares a three-replica HA service that must be spread across distinct fault domains
+    via an anti-affinity rule, so no single provider or domain failure takes more than one replica. The
+    placement engine must reserve capacity for each replica in a different fault domain, refusing to collapse
+    two replicas onto one domain even if that domain has the most headroom. This tests anti-affinity as
+    a hard spread constraint over a composite service.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - provider-owner
+  intent: Spread HA replicas across distinct fault domains via anti-affinity
+  success_criteria:
+  - The anti-affinity rule and fault-domain topology are resolved for the service
+  - Each of the three replicas is reserved in a distinct fault domain
+  - No two replicas are co-located in the same domain despite headroom skew
+  - If fewer than three distinct domains have capacity, placement fails closed
+  - All replicas realize on their assigned domains
+  - The spread constraint and per-replica domain assignments are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: anti-affinity spread constraint evaluated over fault-domain topology
+  - domain: provider
+    interaction: one reservation per distinct fault domain
+  - domain: audit
+    interaction: spread constraint and per-replica domain assignments recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:10.000000+00:00'
+tags:
+- capacity
+- placement
+- anti-affinity
+- fault-domain
+- high-availability
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/011-validate-and-reserve-hold.yaml b/dav/use-cases/hammer-capacity-placement/011-validate-and-reserve-hold.yaml
new file mode 100644
index 0000000..6117ad9
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/011-validate-and-reserve-hold.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-capacity-011
+handle: capacity/validate-and-reserve-hold
+scenario:
+  description: 'A platform engineer requests a multi-resource change where downstream steps must validate
+    before any capacity is committed. Per the validate-and-reserve model (ADR-011 — reservation precedes
+    realization so capacity is never oversubscribed), the engine must place a hold on provider capacity,
+    complete validation while the hold is live, and only then promote the reservation to an allocation.
+    This tests the two-phase reserve-then-commit boundary as an explicit, observable step.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+  intent: Hold capacity via reservation, then commit only after validation
+  success_criteria:
+  - A capacity reservation (hold) is placed before realization begins
+  - Validation runs against the reserved plan while the hold is live
+  - Held capacity is not counted as available to other requests
+  - On successful validation the reservation is promoted to an allocation
+  - No double-counting or oversubscription of provider capacity occurs
+  - The reserve, validate, and commit transitions are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: capacity held as a reservation, later promoted to allocation
+  - domain: policy
+    interaction: validate-and-reserve orchestration enforces reserve-before-commit
+  - domain: audit
+    interaction: reserve, validate, and commit transitions recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:11.000000+00:00'
+tags:
+- capacity
+- reservation
+- validate-and-reserve
+- adr-011
+- two-phase
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/012-reservation-released-on-abort.yaml b/dav/use-cases/hammer-capacity-placement/012-reservation-released-on-abort.yaml
new file mode 100644
index 0000000..c899bcc
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/012-reservation-released-on-abort.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-capacity-012
+handle: capacity/reservation-released-on-abort
+scenario:
+  description: 'A multi-resource request reserves capacity across providers, then a downstream validation
+    fails and the operation aborts before any resource is realized. Per the validate-and-reserve model
+    (ADR-011), the engine must release every held reservation on abort so capacity returns to the pool
+    and is not stranded. This tests reservation cleanup on the failure path — the guarantee that an aborted
+    request leaves no capacity leaks behind.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - security-officer
+  intent: Release all held capacity when a reserved operation aborts
+  success_criteria:
+  - Capacity reservations are placed across the required providers
+  - A downstream validation failure triggers an abort before realization
+  - Every held reservation is released as part of the abort
+  - Released capacity is returned to each provider's available pool
+  - No resource is realized and no reservation is left dangling
+  - The abort and each reservation release are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: held reservations released and capacity returned on abort
+  - domain: policy
+    interaction: recovery policy drives reservation cleanup on failure
+  - domain: audit
+    interaction: abort and per-reservation releases recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:12.000000+00:00'
+tags:
+- capacity
+- reservation
+- rollback
+- abort
+- adr-011
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/013-reservation-reconcile-stalemate.yaml b/dav/use-cases/hammer-capacity-placement/013-reservation-reconcile-stalemate.yaml
new file mode 100644
index 0000000..0b87e8a
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/013-reservation-reconcile-stalemate.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-capacity-013
+handle: capacity/reservation-reconcile-stalemate
+scenario:
+  description: 'After a reservation is placed, the provider''s out-of-band view of capacity diverges from
+    the engine''s reservation ledger: the provider reports the capacity as free while the engine believes
+    it is held, and repeated reconcile passes fail to converge. The engine must detect a RESERVATION_RECONCILE_STALEMATE,
+    stop retrying, and escalate to a human rather than looping or silently double-allocating. This probes
+    whether the architecture bounds reconciliation and has a defined stalemate exit — likely unsupported
+    if reconcile assumes eventual convergence.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - provider-owner
+  intent: Resolve a reservation-vs-provider reconcile that will not converge
+  success_criteria:
+  - A divergence between the reservation ledger and provider-reported capacity is detected
+  - Reconcile passes are bounded rather than retried indefinitely
+  - The engine raises RESERVATION_RECONCILE_STALEMATE after the bound is hit
+  - No silent double-allocation of the disputed capacity occurs
+  - The stalemate is escalated to a human operator for adjudication
+  - The divergence, bounded retries, and escalation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: human_escalation_required
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: provider-reported capacity diverges from the reservation ledger
+  - domain: policy
+    interaction: bounded reconcile with human-escalation on stalemate
+  - domain: audit
+    interaction: divergence, bounded retries, and escalation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:13.000000+00:00'
+tags:
+- capacity
+- reservation
+- reconcile-stalemate
+- data-inconsistency
+- escalation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/014-dependent-criteria-from-parent-reserved-facts.yaml b/dav/use-cases/hammer-capacity-placement/014-dependent-criteria-from-parent-reserved-facts.yaml
new file mode 100644
index 0000000..dba64f0
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/014-dependent-criteria-from-parent-reserved-facts.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-capacity-014
+handle: capacity/dependent-criteria-from-parent-reserved-facts
+scenario:
+  description: 'A composite request has a child resource whose placement criteria cannot be known until
+    its parent is placed — the child must land in the same zone and on capacity adjacent to the parent''s
+    reserved node, using facts (zone, rack, provider id) that only exist once the parent''s reservation
+    resolves. The engine must thread the parent''s reserved facts into the child''s placement criteria
+    (fulfillment sourced from the provider), rather than requiring all criteria up front. This tests provider-fulfilled,
+    dependency-derived placement.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Derive a child's placement criteria from its parent's reserved facts
+  success_criteria:
+  - The parent resource is placed and its reserved facts (zone, node, provider) captured
+  - The child's placement criteria are populated from the parent's reserved facts
+  - The child is not placed until the parent's reservation resolves
+  - The child reserves capacity consistent with the derived criteria
+  - Both resources realize with the parent-child placement relationship intact
+  - The fact-threading from parent reservation to child criteria is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: parent reservation yields facts consumed by child placement (fulfillment provider)
+  - domain: data
+    interaction: parent reserved facts threaded into child criteria payload
+  - domain: audit
+    interaction: parent-to-child fact threading recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:14.000000+00:00'
+tags:
+- capacity
+- placement
+- dependency-derived
+- fulfillment-provider
+- cross-dependency
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/015-in-place-capacity-expansion.yaml b/dav/use-cases/hammer-capacity-placement/015-in-place-capacity-expansion.yaml
new file mode 100644
index 0000000..b69f8e8
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/015-in-place-capacity-expansion.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-capacity-015
+handle: capacity/in-place-capacity-expansion
+scenario:
+  description: 'A tenant asks to grow a running resource''s capacity in place — more vCPU and memory on
+    an already-realized VM — without recreating it or changing its UUID. The architecture models create/reserve/realize
+    and destroy, but may have no in-place-expand primitive: the engine must either reserve the delta on
+    the same node and mutate the realized resource, or declare the modification unsupported and require
+    replace-and-migrate. This probes whether day-2 vertical scaling exists as a first-class capacity operation.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - provider-owner
+    - tenancy-authority
+  intent: Expand a running resource's capacity in place without recreation
+  success_criteria:
+  - The modification targets an already-realized resource by stable UUID
+  - The engine checks for delta capacity on the resource's current node
+  - Either the delta is reserved and the resource mutated in place, or
+  - The engine cleanly declares in-place expansion unsupported with a reason
+  - No silent recreate/destroy occurs under the guise of an in-place edit
+  - The expansion attempt and its outcome (applied or unsupported) are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: delta capacity checked on the current node for in-place growth
+  - domain: policy
+    interaction: modification validation decides in-place vs replace-and-migrate
+  - domain: audit
+    interaction: expansion attempt and applied-or-unsupported outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:15.000000+00:00'
+tags:
+- capacity
+- expansion
+- vertical-scale
+- day-2
+- possibly-unsupported
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/016-provider-capability-mismatch.yaml b/dav/use-cases/hammer-capacity-placement/016-provider-capability-mismatch.yaml
new file mode 100644
index 0000000..88ba1f4
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/016-provider-capability-mismatch.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-capacity-016
+handle: capacity/provider-capability-mismatch
+scenario:
+  description: 'A request declares a capability the only eligible provider cannot deliver — for example
+    a confidential-computing enclave or a specific accelerator class the provider does not expose — even
+    though that provider has raw capacity. The engine must match on declared capability, not just free
+    capacity, find no capable provider, and fail closed rather than place on an incapable node. This tests
+    capability as a hard match dimension distinct from capacity, and may return unsupported if selection
+    keys on capacity alone.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - sre
+    - provider-owner
+  intent: Place a request whose required capability no eligible provider offers
+  success_criteria:
+  - The required capability is resolved from the request declaration
+  - The eligible provider is checked for the capability, not merely free capacity
+  - The capability mismatch is detected despite available raw capacity
+  - The engine fails closed without placing on an incapable provider
+  - No reservation is made against the mismatched provider
+  - The capability mismatch (distinct from a capacity shortfall) is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: provider capability checked and found insufficient despite capacity
+  - domain: policy
+    interaction: capability-match validation fails closed
+  - domain: audit
+    interaction: capability mismatch recorded distinctly from a capacity shortfall
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:16.000000+00:00'
+tags:
+- capacity
+- provider-selection
+- capability-mismatch
+- fail-closed
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/017-provider-failure-mid-dispatch-rollback.yaml b/dav/use-cases/hammer-capacity-placement/017-provider-failure-mid-dispatch-rollback.yaml
new file mode 100644
index 0000000..43eabf9
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/017-provider-failure-mid-dispatch-rollback.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-capacity-017
+handle: capacity/provider-failure-mid-dispatch-rollback
+scenario:
+  description: 'The engine reserves capacity on the winning provider and begins dispatch, but the provider
+    fails mid-realization (API error, node lost). The engine must roll back the now-void reservation,
+    either retry on the next-best scored candidate or fail closed, and never leave the resource half-realized
+    or the reservation stranded. This tests the provider-failure recovery path on the dispatch boundary
+    — reservation integrity when a chosen provider dies after selection.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - provider-owner
+  intent: Recover placement when the selected provider fails mid-dispatch
+  success_criteria:
+  - Capacity is reserved on the winning provider and dispatch begins
+  - The provider fails partway through realization
+  - The void reservation is rolled back on the failed provider
+  - The engine either re-places on the next-best candidate or fails closed
+  - The resource is never left half-realized
+  - The failure, rollback, and re-placement (or fail-closed) are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: selected provider fails mid-dispatch, reservation rolled back
+  - domain: policy
+    interaction: recovery policy re-places on next candidate or fails closed
+  - domain: audit
+    interaction: failure, rollback, and re-placement outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:17.000000+00:00'
+tags:
+- capacity
+- provider-failure
+- rollback
+- recovery
+- dispatch
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/018-peer-dcm-capacity-spillover.yaml b/dav/use-cases/hammer-capacity-placement/018-peer-dcm-capacity-spillover.yaml
new file mode 100644
index 0000000..f73a289
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/018-peer-dcm-capacity-spillover.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-capacity-018
+handle: capacity/peer-dcm-capacity-spillover
+scenario:
+  description: 'Local providers are exhausted, so a request must spill over to a federated peer DCM that
+    advertises capacity. The engine must query the peer for eligible capacity, honor local policy (residency,
+    attestation) against the peer''s offered nodes, reserve across the DCM boundary, and realize on the
+    peer while keeping the resource governed by the originating DCM. This tests cross-DCM capacity borrowing
+    as a placement option with policy preserved over federation.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Spill placement to a peer DCM when local capacity is exhausted
+  success_criteria:
+  - Local providers are confirmed exhausted before considering the peer
+  - The peer DCM is queried for eligible capacity across the federation boundary
+  - Local policy (residency, attestation) is enforced against peer-offered nodes
+  - Capacity is reserved on the peer and the resource realized there
+  - Governance of the resource remains with the originating DCM
+  - The spillover decision and cross-DCM reservation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peer DCM queried and capacity reserved across the boundary
+  - domain: policy
+    interaction: originating policy enforced on peer-offered nodes
+  - domain: audit
+    interaction: spillover decision and cross-DCM reservation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:18.000000+00:00'
+tags:
+- capacity
+- placement
+- peer-dcm
+- federation
+- spillover
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/019-peer-dcm-disconnect-during-selection.yaml b/dav/use-cases/hammer-capacity-placement/019-peer-dcm-disconnect-during-selection.yaml
new file mode 100644
index 0000000..a133c5f
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/019-peer-dcm-disconnect-during-selection.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-capacity-019
+handle: capacity/peer-dcm-disconnect-during-selection
+scenario:
+  description: 'Mid-selection, the peer DCM that offered candidate capacity becomes unreachable after
+    the engine has begun scoring but before a reservation is confirmed. The engine must not hang or assume
+    the peer reservation succeeded; it must time out the peer, treat its candidates as unavailable, and
+    either complete selection on remaining local/peer candidates or fail closed. This tests placement
+    resilience to peer-DCM disconnect at the worst moment — an in-flight cross-boundary selection.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - provider-owner
+    - federation-peer-operator
+  intent: Keep placement safe when a peer DCM disconnects during selection
+  success_criteria:
+  - The peer DCM's candidates are in-flight when it becomes unreachable
+  - The engine bounds the peer interaction with a timeout rather than hanging
+  - The peer's candidates are treated as unavailable, not assumed reserved
+  - Selection completes on remaining candidates or fails closed
+  - No phantom reservation is attributed to the disconnected peer
+  - The disconnect, timeout, and resulting decision are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peer DCM disconnects mid-selection, candidates dropped after timeout
+  - domain: policy
+    interaction: recovery policy completes selection or fails closed without the peer
+  - domain: audit
+    interaction: disconnect, timeout, and resulting decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:19.000000+00:00'
+tags:
+- capacity
+- placement
+- peer-dcm
+- disconnect
+- resilience
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-capacity-placement/020-gpu-class-scored-multi-provider.yaml b/dav/use-cases/hammer-capacity-placement/020-gpu-class-scored-multi-provider.yaml
new file mode 100644
index 0000000..bc226e5
--- /dev/null
+++ b/dav/use-cases/hammer-capacity-placement/020-gpu-class-scored-multi-provider.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-capacity-020
+handle: capacity/gpu-class-scored-multi-provider
+scenario:
+  description: 'A data-science tenant requests a training workload requiring a specific GPU class with
+    a minimum count and interconnect capability. Several providers offer GPUs of differing generations
+    and free counts; the engine must filter to providers meeting the GPU-class and count floor, score
+    the survivors on capability fit and capacity headroom, and reserve on the best fit. This tests capability-typed,
+    quantity-constrained scoring for a scarce specialized resource under audit-heavy governance.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: prod
+  perspectives:
+    - provider-owner
+    - compliance-auditor
+    - tenancy-authority
+  intent: Select the best GPU-class provider meeting a count and interconnect floor
+  success_criteria:
+  - The required GPU class, minimum count, and interconnect capability are resolved
+  - Providers not meeting the GPU class or count floor are excluded
+  - Surviving providers are scored on capability fit and capacity headroom
+  - The best-fit provider is reserved for the full requested GPU count
+  - A provider with the right GPU class but insufficient count is not partially placed
+  - The GPU capability scoring and selection are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: GPU-class and count floor filtered, survivors scored and reserved
+  - domain: policy
+    interaction: capability and quantity validation gates the candidate set
+  - domain: audit
+    interaction: GPU capability scoring and selection recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:20.000000+00:00'
+tags:
+- capacity
+- provider-selection
+- gpu
+- capability-scoring
+- scarce-resource
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-change-control/001-additive-auto-adopted-continuous.yaml b/dav/use-cases/hammer-change-control/001-additive-auto-adopted-continuous.yaml
new file mode 100644
index 0000000..358c097
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/001-additive-auto-adopted-continuous.yaml
@@ -0,0 +1,52 @@
+uuid: uc-807d3061-57d9-4baf-9cfb-4a813473d453
+handle: change-control/additive-auto-adopted-continuous
+version: 1.0.0
+scenario:
+  description: 'A new optional element lands on the Compute Base Class upstream. A development estate''s
+    change-management policy declares continuous adoption for additive (compatible) changes: on its next
+    scheduled registry sync the estate re-pins automatically, downstream Compute.* records regenerate,
+    and the adoption is recorded — no human in the loop, because the policy put the human decision in
+    the policy itself, once.'
+  actor:
+    persona: platform-engineer
+    profile: dev
+  perspectives: []
+  intent: Have an additive class change adopted automatically where the estate's change policy declares
+    continuous adoption for compatible change classes
+  success_criteria:
+  - The estate's change-management policy declares adoption mode per change class (additive vs breaking),
+    not per event
+  - The additive change re-pins automatically at the next policy-declared sync point
+  - Downstream Compute.* records regenerate in the same orchestrated adoption run
+  - The adoption run is recorded with the change class, the policy that authorized it, and the artifacts
+    updated
+  - A breaking change arriving the same day does NOT auto-adopt — the policy branches on change class
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: data
+    interaction: change class read from the upstream change record's classification
+  - domain: policy
+    interaction: the estate's adoption-mode policy authorizes automatic re-pin for additive only
+  - domain: provider
+    interaction: regeneration of downstream records runs as an orchestrated job
+  - domain: audit
+    interaction: the adoption run and its authorizing policy are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T20:00:00Z'
+tags:
+- hammer
+- change-control
+- change-window
+- auto-adoption
+- additive
diff --git a/dav/use-cases/hammer-change-control/002-additive-deferred-to-window.yaml b/dav/use-cases/hammer-change-control/002-additive-deferred-to-window.yaml
new file mode 100644
index 0000000..74795ef
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/002-additive-deferred-to-window.yaml
@@ -0,0 +1,51 @@
+uuid: uc-c4ffe64b-6716-42c0-bd6c-4123428df66a
+handle: change-control/additive-deferred-to-window
+version: 1.0.0
+scenario:
+  description: The same additive Compute Base element reaches a production estate whose change-management
+    policy allows class re-pins only inside a weekly maintenance window. The change lands upstream mid-week;
+    the estate's debt list shows the pending adoption immediately; nothing changes until the window opens,
+    when the orchestrated adoption job re-pins, regenerates downstream Compute.* records, and closes the
+    debt entry — all inside the window.
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives: []
+  intent: Have a compatible class change adopted only inside the estate's declared maintenance window,
+    with the wait visible as debt rather than silent lag
+  success_criteria:
+  - The pending adoption appears on the estate's debt list the moment the upstream change is classified
+  - No estate artifact changes before the declared window opens
+  - The adoption job starts and completes inside the window, or defers whole to the next window — never
+    straddles
+  - Downstream Compute.* records regenerate in the same windowed run
+  - The adoption record carries the window identity and the policy that scheduled it
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: debt enumeration reflects the pending adoption before any change occurs
+  - domain: policy
+    interaction: the window policy gates when the re-pin may execute
+  - domain: provider
+    interaction: the windowed adoption job orchestrates re-pin plus downstream regeneration
+  - domain: audit
+    interaction: window identity and scheduling policy are part of the adoption record
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T20:00:00Z'
+tags:
+- hammer
+- change-control
+- change-window
+- maintenance-window
+- additive
diff --git a/dav/use-cases/hammer-change-control/003-breaking-full-ceremony.yaml b/dav/use-cases/hammer-change-control/003-breaking-full-ceremony.yaml
new file mode 100644
index 0000000..f7a6da8
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/003-breaking-full-ceremony.yaml
@@ -0,0 +1,54 @@
+uuid: uc-7f2e48bc-f671-4363-aebf-60e52212abd7
+handle: change-control/breaking-full-ceremony
+version: 1.0.0
+scenario:
+  description: 'A breaking Compute Base change (properly declared upstream, blast radius enumerated) reaches
+    a production estate. Its policy requires the full ceremony for breaking classes: blue/green dry-run
+    evidence first, a named approver''s sign-off on the diff, then execution only inside the maintenance
+    window, then post-adoption verification before the debt entry closes. Each gate is a policy clause;
+    the orchestration runs them in order and stops at the first unmet gate.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Adopt a breaking class change through the estate's full ceremony — evidence, approval, window,
+    verification — with each gate policy-declared and order-enforced
+  success_criteria:
+  - The ceremony's gates (evidence, approval, window, verification) are clauses of the estate's change
+    policy, not tribal process
+  - Blue/green diff evidence exists and is approved before the window gate is even evaluated
+  - Execution occurs only inside the window and only after approval
+  - Post-adoption verification runs before the debt entry closes; a verification failure halts closure
+  - The complete gate sequence and each gate's outcome are recorded as one adoption trail
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: ordered policy gates control the adoption sequence
+  - domain: data
+    interaction: the blue/green diff and blast radius are the evidence inputs
+  - domain: provider
+    interaction: orchestration executes gates in order and halts on the first unmet gate
+  - domain: audit
+    interaction: one adoption trail records every gate outcome
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T20:00:00Z'
+tags:
+- hammer
+- change-control
+- change-window
+- breaking
+- blue-green
+- approval
diff --git a/dav/use-cases/hammer-change-control/004-out-of-window-refused.yaml b/dav/use-cases/hammer-change-control/004-out-of-window-refused.yaml
new file mode 100644
index 0000000..edf165f
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/004-out-of-window-refused.yaml
@@ -0,0 +1,48 @@
+uuid: uc-8577b7d3-a4ae-455d-a675-3a365f97f0ed
+handle: change-control/out-of-window-refused
+version: 1.0.0
+scenario:
+  description: 'An operator attempts to re-pin a production estate to a new Compute Base revision on a
+    Tuesday afternoon, outside the estate''s declared maintenance window, with no expedite authorization.
+    The change-management policy refuses: typed (window violation), actionable (names the policy, the
+    window, and the expedite path), and recorded. The estate is untouched.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Have an out-of-window adoption attempt refused with the window, the policy, and the expedite
+    path named
+  success_criteria:
+  - The re-pin attempt outside the window is refused before any artifact changes
+  - The refusal is typed as a window violation and names the governing policy clause and the next window
+  - The refusal names the expedite path (what authorization would permit an out-of-window change)
+  - The refused attempt is recorded with actor, time, and target revision
+  - An identical attempt inside the window proceeds under the normal gates
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the window clause refuses out-of-window execution
+  - domain: audit
+    interaction: the refused attempt is recorded with full context
+  - domain: data
+    interaction: no estate artifact changes on the refused path
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T20:00:00Z'
+tags:
+- hammer
+- change-control
+- change-window
+- must-reject
diff --git a/dav/use-cases/hammer-change-control/005-staged-rollout-tiers.yaml b/dav/use-cases/hammer-change-control/005-staged-rollout-tiers.yaml
new file mode 100644
index 0000000..8749d1b
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/005-staged-rollout-tiers.yaml
@@ -0,0 +1,54 @@
+uuid: uc-a275be9c-dcfa-4217-8102-3c4c3b13fd2a
+handle: change-control/staged-rollout-tiers
+version: 1.0.0
+scenario:
+  description: 'An organization runs three estates on one registry: development (continuous adoption),
+    staging (windowed), production (full ceremony). A breaking Compute Base change rolls out as a staged
+    chain the policies themselves compose: development adopts first and soaks; its clean soak evidence
+    is a precondition in staging''s policy; staging''s clean adoption is a precondition in production''s.
+    A failure at any stage halts every later stage automatically — the chain is policy topology, not a
+    runbook.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Roll a breaking change through dev, staging, and production estates as a policy-composed chain
+    where each stage's evidence gates the next
+  success_criteria:
+  - Each estate's adoption policy names its predecessor's clean evidence as a precondition — the chain
+    is declared, not scripted
+  - Development adopts first under its continuous policy and produces soak evidence
+  - Staging's window gate does not open for this change until development's soak evidence exists
+  - A failure recorded at staging halts production's chain automatically
+  - The cross-estate rollout is reconstructible from the three adoption trails end to end
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: stage preconditions compose the rollout chain across estates
+  - domain: data
+    interaction: soak and adoption evidence are typed records the next stage's policy reads
+  - domain: provider
+    interaction: each stage's orchestration runs under its own estate's controls
+  - domain: audit
+    interaction: three linked adoption trails reconstruct the full rollout
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T20:00:00Z'
+tags:
+- hammer
+- change-control
+- staged-rollout
+- multi-estate
+- breaking
diff --git a/dav/use-cases/hammer-change-control/006-expedite-break-glass.yaml b/dav/use-cases/hammer-change-control/006-expedite-break-glass.yaml
new file mode 100644
index 0000000..a9864cd
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/006-expedite-break-glass.yaml
@@ -0,0 +1,52 @@
+uuid: uc-f5ff1b9a-7385-4f76-be68-5582143077e2
+handle: change-control/expedite-break-glass
+version: 1.0.0
+scenario:
+  description: 'A security fix lands upstream as a breaking class change and a regulated estate needs
+    it before the next quarterly window. The change policy''s expedite clause exists for exactly this:
+    out-of-window adoption requires an elevated approver, a named justification, and produces a flagged
+    audit record; the blue/green evidence gate still applies — expedite compresses the calendar, never
+    the evidence.'
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - compliance-auditor
+    - security-officer
+  intent: Adopt a security-critical breaking change out of window through the policy's expedite clause,
+    with elevated approval and undiminished evidence
+  success_criteria:
+  - The expedite clause is part of the declared policy, with its own approver role and justification requirement
+  - Expedited adoption still requires the blue/green evidence gate — no evidence gate is waivable
+  - The expedited run is flagged as out-of-window in the adoption record with the justification attached
+  - An expedite attempt without the elevated approval is refused like any out-of-window attempt
+  - The next scheduled window's report includes the expedited adoption for retrospective review
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the expedite clause compresses scheduling gates while preserving evidence gates
+  - domain: audit
+    interaction: flagged out-of-window record with justification and elevated approver
+  - domain: data
+    interaction: blue/green evidence remains the promotion input
+  - domain: provider
+    interaction: the expedited orchestration is the normal ceremony minus only the window wait
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T20:00:00Z'
+tags:
+- hammer
+- change-control
+- expedite
+- break-glass
+- security
diff --git a/dav/use-cases/hammer-change-control/007-freeze-queues-adoptions.yaml b/dav/use-cases/hammer-change-control/007-freeze-queues-adoptions.yaml
new file mode 100644
index 0000000..489ba04
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/007-freeze-queues-adoptions.yaml
@@ -0,0 +1,53 @@
+uuid: uc-e7242d14-123c-4e77-8e40-d8d3de9f919f
+handle: change-control/freeze-queues-adoptions
+version: 1.0.0
+scenario:
+  description: 'A regulated estate declares a change freeze for its audit period: all adoptions, including
+    additive auto-adoptions, are suspended. Upstream changes accumulate as queued, ordered debt; auto-adoption
+    resumes when the freeze lifts and drains the queue in arrival order under the normal per-class gates.
+    During the freeze an adoption attempt is refused citing the freeze; the debt list distinguishes frozen-queued
+    from ordinary lag.'
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Have a declared freeze suspend all adoptions with upstream changes queued as ordered, distinguishable
+    debt that drains under normal gates when the freeze lifts
+  success_criteria:
+  - The freeze is a dated policy clause; while active, every adoption path (including automatic) is suspended
+  - Adoption attempts during the freeze are refused citing the freeze clause and its end date
+  - Accumulated changes appear as queued debt, ordered and distinguished from ordinary pin-behind lag
+  - When the freeze lifts, the queue drains in arrival order, each item under its own change class gates
+  - The freeze period itself is part of the estate's audit trail — silence is provably policy, not neglect
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the freeze clause suspends adoption; per-class gates resume on lift
+  - domain: data
+    interaction: queued debt is typed distinctly from ordinary lag
+  - domain: audit
+    interaction: the freeze window and refused attempts are recorded
+  - domain: provider
+    interaction: the post-freeze drain is one orchestrated, ordered run
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T20:00:00Z'
+tags:
+- hammer
+- change-control
+- freeze
+- queued-adoption
+- regulated
diff --git a/dav/use-cases/hammer-change-control/008-intra-estate-ordered-propagation.yaml b/dav/use-cases/hammer-change-control/008-intra-estate-ordered-propagation.yaml
new file mode 100644
index 0000000..1017782
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/008-intra-estate-ordered-propagation.yaml
@@ -0,0 +1,55 @@
+uuid: uc-5dff5cce-219d-4b7f-826b-5b328f21d44c
+handle: change-control/intra-estate-ordered-propagation
+version: 1.0.0
+scenario:
+  description: Inside one estate, adopting a Compute Base change touches many downstream Compute.* records
+    whose workloads depend on each other. The adoption job derives its update order from the estate's
+    own dependency graph (the same edges that derive shutdown order), updates in batches with per-batch
+    verification, and halts leaving a recorded partial-adoption state if a batch fails verification —
+    never an unordered fleet-wide rewrite.
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Have an adoption propagate through downstream records in dependency-derived order with per-batch
+    verification and a recorded halt state on failure
+  success_criteria:
+  - The update order is derived from the estate's dependency edges, not hand-listed
+  - Updates execute in batches; each batch's verification must pass before the next begins
+  - A failed batch halts propagation with the partial-adoption state recorded (which records updated,
+    which pending)
+  - 'The halt state is resumable: a corrected batch re-verifies and propagation continues from where it
+    stopped'
+  - The completed adoption record includes the derived order and every batch verdict
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: hard_dependencies
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency edges derive the propagation order
+  - domain: provider
+    interaction: batched orchestration with per-batch verification executes the order
+  - domain: policy
+    interaction: batch-verification gates control progression
+  - domain: audit
+    interaction: derived order, batch verdicts, and any halt state are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T20:00:00Z'
+tags:
+- hammer
+- change-control
+- orchestration
+- dependency-order
+- batched
diff --git a/dav/use-cases/hammer-change-control/009-storage-array-maintenance-ordered.yaml b/dav/use-cases/hammer-change-control/009-storage-array-maintenance-ordered.yaml
new file mode 100644
index 0000000..3acf112
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/009-storage-array-maintenance-ordered.yaml
@@ -0,0 +1,67 @@
+uuid: uc-bbd05a8c-23f4-475f-bbb9-73fe4c292c39
+handle: change-control/storage-array-maintenance-ordered
+version: 1.0.0
+scenario:
+  description: 'A breaking change must be adopted on a storage array whose file shares serve ten client
+    applications. The impact set — the ten clients, their dependency edges, their tolerance classes —
+    is derived from the dependency graph, never hand-listed. Each client''s own availability policy sorts
+    it: three require continuity and are cut over to a verified DR replica first (a re-bind to the replica
+    shares'' declared typed outputs); seven tolerate the window and quiesce in reverse dependency order
+    in verified batches. Maintenance may not even be scheduled until the DR gate passes (replica healthy,
+    current, sized). After maintenance, post-verification proves the array publishes its expected outputs
+    before the forward-order restart, and a failback policy — not a habit — decides whether the continuity
+    clients return or the replica is promoted primary. One trail records the derived orders and every
+    gate verdict.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Execute disruptive storage-array maintenance under change control with a derived impact set,
+    per-client tolerance policies, DR-gated scheduling, output-surface cutover, and ordered quiesce/restart
+  success_criteria:
+  - The ten-client impact set and both orders (quiesce reverse, restart forward) are derived from dependency
+    edges, not authored
+  - Each client's tolerance class comes from its declared availability policy; the plan reads it
+  - The DR gate refuses maintenance scheduling (typed) until the replica is verified healthy, current,
+    and sized
+  - Continuity clients cut over by re-binding to the replica shares' declared typed outputs, with cutover
+    verification before the window opens
+  - Quiesce and restart run in derived order, batched, each batch verified before the next
+  - The failback decision is made by a declared policy and the chosen outcome (failback or replica-promoted)
+    is recorded
+  - One adoption trail carries the impact set, the derived orders, and every gate verdict end to end
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: cross_dependency_payload
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency edges derive impact set and both orders; typed outputs are the cutover surface
+  - domain: policy
+    interaction: window + per-client availability policies + DR-gate precondition + failback policy gate
+      every step
+  - domain: provider
+    interaction: array, replica, and orchestration jobs execute cutover, quiesce, maintenance, restart
+      under the gates
+  - domain: audit
+    interaction: 'one trail: impact set, orders, every batch and gate verdict'
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T21:00:00Z'
+tags:
+- hammer
+- change-control
+- storage-array
+- dr-cutover
+- ordered-shutdown
+- dependent-applications
diff --git a/dav/use-cases/hammer-change-control/010-mid-maintenance-failure-dr-hold.yaml b/dav/use-cases/hammer-change-control/010-mid-maintenance-failure-dr-hold.yaml
new file mode 100644
index 0000000..543714f
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/010-mid-maintenance-failure-dr-hold.yaml
@@ -0,0 +1,59 @@
+uuid: uc-71109224-8270-4bbe-ae62-937382d54b9a
+handle: change-control/mid-maintenance-failure-dr-hold
+version: 1.0.0
+scenario:
+  description: 'The same storage-array maintenance, but post-maintenance verification fails: the adopted
+    array does not publish its expected declared outputs. The flow halts in a recorded, resumable state
+    — the three continuity clients keep running on the DR replica untouched, the seven quiesced clients
+    stay down rather than restarting onto an unverified array, and the partial-adoption record states
+    exactly which steps completed. The operator''s decision point (repair and re-verify, or roll the maintenance
+    back) is reached with no user-facing outage having occurred and no unordered state anywhere. Recovery
+    resumes from the halt point; the trail records the failure, the hold, and the resolution as one history.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Have a failed post-maintenance verification halt the flow resumably with DR carrying continuity
+    clients and nothing restarted onto an unverified array
+  success_criteria:
+  - Post-maintenance verification failure halts the flow before any client restarts onto the unverified
+    array
+  - The continuity clients continue on the DR replica through the halt, untouched by the failure
+  - 'The halt state is recorded and resumable: completed steps, pending steps, and the failed verification
+    are all stated'
+  - The operator decision point (repair-and-reverify vs roll back) is explicit in the trail, not improvised
+  - Recovery resumes from the halt point in derived order; the trail reads failure, hold, and resolution
+    as one history
+  dimensions:
+    lifecycle_phase: recovery
+    resource_complexity: cross_dependency_payload
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: component_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: the halt state and completed/pending step sets are typed records
+  - domain: policy
+    interaction: restart onto an unverified array is refused by the verification gate
+  - domain: provider
+    interaction: DR replica continues serving; recovery orchestration resumes from the recorded point
+  - domain: audit
+    interaction: failure, hold, decision, and resolution form one continuous trail
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T21:00:00Z'
+tags:
+- hammer
+- change-control
+- storage-array
+- dr-hold
+- failure-recovery
+- resumable
diff --git a/dav/use-cases/hammer-change-control/011-dr-pairing-declared-and-walkable.yaml b/dav/use-cases/hammer-change-control/011-dr-pairing-declared-and-walkable.yaml
new file mode 100644
index 0000000..24e9d1c
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/011-dr-pairing-declared-and-walkable.yaml
@@ -0,0 +1,53 @@
+uuid: uc-b3d37518-5f21-40d6-bbdc-3527994a1154
+handle: change-control/dr-pairing-declared-and-walkable
+version: 1.0.0
+scenario:
+  description: A maintenance planner must determine, from the model alone, which storage pool is the DR
+    replica of the array under maintenance — its identity, the replication direction, and the sync mode
+    — before the DR gate can evaluate the replica's health outputs. The pairing is a declared, graph-walkable
+    model surface (a relationship or spec-level replication block with a resolvable reference), never
+    tribal knowledge or a runbook footnote. A planner asking 'where does this array fail over to' gets
+    a deterministic answer from a graph query, and an array with no declared DR pairing is distinguishable
+    from one whose pairing was simply never modeled.
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Derive the DR replica's identity, direction, and sync mode from a declared model surface so
+    the DR gate has a target to evaluate
+  success_criteria:
+  - The DR pairing (which pool/cluster replicates to which) is a declared model surface with a resolvable
+    reference to the peer
+  - Replication direction and sync mode are readable from the same surface
+  - A graph query answers 'where does this array fail over to' deterministically
+  - The DR gate consumes the pairing surface to locate the replica whose health outputs it evaluates
+  - No-pairing-declared is an explicit, distinguishable state, not an absence indistinguishable from unmodeled
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: the pairing relationship/reference is part of the storage types' declared surface
+  - domain: policy
+    interaction: the DR gate resolves the pairing before evaluating health
+  - domain: audit
+    interaction: the plan records which pairing surface the gate read
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T22:00:00Z'
+tags:
+- hammer
+- change-control
+- surface-probe
+- dr-pairing
+- storage-array
diff --git a/dav/use-cases/hammer-change-control/012-share-cutover-verifiable-from-outputs.yaml b/dav/use-cases/hammer-change-control/012-share-cutover-verifiable-from-outputs.yaml
new file mode 100644
index 0000000..b385781
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/012-share-cutover-verifiable-from-outputs.yaml
@@ -0,0 +1,55 @@
+uuid: uc-3010e002-7850-497b-9a73-45c5e5ad4782
+handle: change-control/share-cutover-verifiable-from-outputs
+version: 1.0.0
+scenario:
+  description: 'During a DR cutover, verification must confirm the replica share is actually serving —
+    from the share''s OWN declared outputs (serving state, active endpoints), not solely from client-side
+    probes. A share type whose declared output surface carries only a mount identifier supports the re-bind
+    but not the verification: the operator can point clients at the replica but cannot prove, from the
+    model''s binding surface, that the replica answers. Cutover verification reads producer-side declared
+    outputs and client-side status together, and the producer side must exist.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Verify a share cutover from the share's own declared outputs, not client probes alone
+  success_criteria:
+  - The share type declares outputs sufficient to verify serving state (state plus active endpoint), beyond
+    the mount identifier
+  - Cutover verification reads the replica share's declared outputs before client re-binds are declared
+    healthy
+  - A share that is mounted-but-not-serving is detectable from the producer's declared outputs
+  - The verification verdict cites the producer-side output values it read
+  - The same output surface serves the post-maintenance verification of the primary before restart
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: the share's declared outputs are the producer-side verification surface
+  - domain: policy
+    interaction: cutover and post-maintenance gates read producer outputs, not only client health
+  - domain: provider
+    interaction: the share provider populates the serving-state outputs at realization
+  - domain: audit
+    interaction: verification verdicts cite the output values read
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T22:00:00Z'
+tags:
+- hammer
+- change-control
+- surface-probe
+- thin-outputs
+- cutover-verification
+- storage-array
diff --git a/dav/use-cases/hammer-change-control/013-windows-sourced-from-information-provider.yaml b/dav/use-cases/hammer-change-control/013-windows-sourced-from-information-provider.yaml
new file mode 100644
index 0000000..1cf64a1
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/013-windows-sourced-from-information-provider.yaml
@@ -0,0 +1,56 @@
+uuid: uc-de27309a-b44c-4f1d-b33c-2ecdc29cb003
+handle: change-control/windows-sourced-from-information-provider
+version: 1.0.0
+scenario:
+  description: 'An organization''s maintenance windows and freeze calendar are not authored inside the
+    estate''s policies — they live in the organization''s change-management system (an ITSM-archetype
+    source of record). An information provider declares the change-calendar knowledge type as a capability
+    and supplies window and freeze records as Knowledge-family entities: schedule, scope, source, and
+    validity. The estate''s validation policy references those knowledge records by handle (adopt-by-reference,
+    never a re-typed copy); the window gate evaluates policy-against-knowledge at decision time; and when
+    the calendar changes upstream, the provider refreshes the records — the policy text never changes.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - information-provider-owner
+  intent: Source maintenance windows and freezes from an information provider as Knowledge-family records
+    the validation policy references, never copies
+  success_criteria:
+  - Window and freeze definitions are Knowledge-family records with schedule, scope, source, and validity
+    surfaces
+  - An information provider (provider kind information) declares the change-calendar knowledge type as
+    a capability it supplies
+  - The estate's validation policy references the knowledge records by handle — no window literal is re-typed
+    into policy text
+  - A calendar change upstream flows as a knowledge-record refresh; the referencing policy is untouched
+  - The gate's decision record cites the knowledge record revision it evaluated against
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: windows/freezes are Knowledge records with validity, referenced by handle
+  - domain: policy
+    interaction: the validation policy evaluates against referenced knowledge at decision time
+  - domain: provider
+    interaction: an information provider declares and refreshes the knowledge type
+  - domain: audit
+    interaction: decisions cite the knowledge revision they read
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T23:00:00Z'
+tags:
+- hammer
+- change-control
+- knowledge-source
+- information-provider
+- change-calendar
diff --git a/dav/use-cases/hammer-change-control/014-multi-source-authority-declared.yaml b/dav/use-cases/hammer-change-control/014-multi-source-authority-declared.yaml
new file mode 100644
index 0000000..35d93f3
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/014-multi-source-authority-declared.yaml
@@ -0,0 +1,56 @@
+uuid: uc-4635fb17-b84f-42b7-b649-76f763bbe07d
+handle: change-control/multi-source-authority-declared
+version: 1.0.0
+scenario:
+  description: 'Two sources can answer ''is the window open'': an internally-authored policy clause and
+    the external change-management system''s knowledge records. The consuming policy DECLARES which source
+    is authoritative for which scope (the adopt-by-reference discipline applied to authority): e.g. the
+    external calendar governs production windows, the internal clause governs a lab enclave the ITSM system
+    does not model. When both sources cover the same scope and disagree, and no authority is declared
+    for that scope, the gate refuses to decide — typed (conflicting-sources), naming both sources and
+    their answers — rather than silently picking one.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Declare source authority per scope for change-control knowledge, and refuse gating decisions
+    on undeclared conflicts instead of silently picking a source
+  success_criteria:
+  - The consuming policy declares, per scope, which source (internal clause or external knowledge) is
+    authoritative
+  - Scopes covered by exactly one source evaluate deterministically without a declaration
+  - A scope where declared authority exists evaluates against that source even when the other disagrees,
+    and the decision record notes the overridden source
+  - A scope with conflicting answers and no declared authority produces a typed conflicting-sources refusal
+    naming both sources and both answers
+  - The refusal is a gate outcome record; no adoption proceeds on an unresolved conflict
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: cross_domain_constraint
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: authority-per-scope declarations resolve multi-source answers; undeclared conflict refuses
+  - domain: data
+    interaction: both sources' answers and revisions are part of the decision record
+  - domain: audit
+    interaction: overrides and refusals are recorded with both sources named
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T23:00:00Z'
+tags:
+- hammer
+- change-control
+- knowledge-source
+- multi-source
+- authority
+- must-reject
diff --git a/dav/use-cases/hammer-change-control/015-stale-knowledge-fails-closed.yaml b/dav/use-cases/hammer-change-control/015-stale-knowledge-fails-closed.yaml
new file mode 100644
index 0000000..898950a
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/015-stale-knowledge-fails-closed.yaml
@@ -0,0 +1,60 @@
+uuid: uc-f9e53913-8c90-4c81-907b-8c390dfabd55
+handle: change-control/stale-knowledge-fails-closed
+version: 1.0.0
+scenario:
+  description: 'The information provider feeding the change calendar has not refreshed since before its
+    declared validity horizon — the window knowledge is stale. A gate that authorizes disruptive work
+    against a possibly-outdated calendar is worse than one that refuses: the window gate fails CLOSED
+    on stale knowledge — typed (stale-knowledge), naming the source, its last refresh, and its validity
+    horizon — and the expedite path remains available for genuine emergencies. Staleness is decidable
+    because Knowledge-family records carry a freshness surface (as-of, valid-until, refresh cadence);
+    the same surface serves every knowledge domain (a stale vulnerability feed is the same failure class
+    as a stale calendar).'
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - information-provider-owner
+  intent: Have gates fail closed on stale change-control knowledge, decidable from the Knowledge family's
+    declared freshness surface
+  success_criteria:
+  - Knowledge-family records carry a declared freshness surface (as-of, valid-until, refresh cadence)
+  - The window gate evaluates freshness before evaluating the window itself
+  - Stale knowledge produces a typed stale-knowledge refusal naming source, last refresh, and validity
+    horizon — never a decision on outdated data
+  - The expedite path (elevated approval, flagged audit) remains available during a staleness outage
+  - 'The freshness surface is family-level: the same elements govern every knowledge domain, not calendars
+    alone'
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: the Knowledge-family freshness surface makes staleness decidable
+  - domain: policy
+    interaction: the gate fails closed on staleness before evaluating content
+  - domain: provider
+    interaction: the information provider's refresh cadence is part of its declared contract
+  - domain: audit
+    interaction: staleness refusals record source, last refresh, and horizon
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-25T23:00:00Z'
+tags:
+- hammer
+- change-control
+- knowledge-source
+- freshness
+- fail-closed
+- must-reject
+- knowledge-family
diff --git a/dav/use-cases/hammer-change-control/016-change-policy-changes-are-governed.yaml b/dav/use-cases/hammer-change-control/016-change-policy-changes-are-governed.yaml
new file mode 100644
index 0000000..6fc0df7
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/016-change-policy-changes-are-governed.yaml
@@ -0,0 +1,58 @@
+uuid: uc-2b321e16-b492-4ba3-b73c-80b25d2c82dc
+handle: change-control/change-policy-changes-are-governed
+version: 1.0.0
+scenario:
+  description: 'An operator proposes loosening a production estate''s change policy — widening the maintenance
+    window and removing the approval gate for breaking adoptions. The change policy is itself a versioned
+    record, and changing the gate is governed BY a gate: policy changes run under a declared meta-policy
+    (who may change which clauses, with what approval, in what window), the proposed loosening is surfaced
+    with its own blast radius (every adoption path the clause governs), and the change takes effect only
+    prospectively — in-flight adoptions complete under the policy revision that admitted them (provenance
+    discipline, applied to policy). A policy change that would remove an evidence gate is refused outright:
+    scheduling clauses are the organization''s to loosen, evidence gates are not (ADR-046''s floor).'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Govern changes to change policies themselves — versioned, meta-policy-gated, prospective, with
+    evidence gates unloosenable
+  success_criteria:
+  - The change policy is a versioned record; changing it mints a new revision under the rotation rule
+  - 'A declared meta-policy governs policy changes: who may change which clauses, approval, window'
+  - The proposed change is surfaced with its blast radius — the adoption paths the clause governs
+  - 'Policy changes are prospective only: in-flight adoptions complete under the revision that admitted
+    them'
+  - A change removing an evidence gate is refused — scheduling clauses are loosenable, evidence gates
+    are not
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the meta-policy gates the gate; evidence-gate removal refuses
+  - domain: data
+    interaction: policy revisions carry rotation; in-flight work pins its admitting revision
+  - domain: audit
+    interaction: policy changes are the most audit-worthy changes in the estate
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-26T04:00:00Z'
+tags:
+- hammer
+- change-control
+- matrix-gap
+- policy-self-change
+- meta-policy
+- must-reject
diff --git a/dav/use-cases/hammer-change-control/017-whole-provider-retirement-wind-down.yaml b/dav/use-cases/hammer-change-control/017-whole-provider-retirement-wind-down.yaml
new file mode 100644
index 0000000..c78f876
--- /dev/null
+++ b/dav/use-cases/hammer-change-control/017-whole-provider-retirement-wind-down.yaml
@@ -0,0 +1,61 @@
+uuid: uc-f7c7bad1-36d2-4c55-8df2-933c4e9cd148
+handle: change-control/whole-provider-retirement-wind-down
+version: 1.0.0
+scenario:
+  description: 'A provider is leaving an estate entirely — every capability, not just one revision. Retirement
+    is a governed wind-down, not an event: the provider definition enters deprecation with a published
+    window; the blast radius is every instance whose realization provenance names the provider and every
+    binding through its capabilities'' covers_types; each affected workload migrates through the standard
+    machinery (provider swap via blue/green, per the estate''s change policy and windows) during the window;
+    new realizations against the departing provider are refused from deprecation onward while day-2 operations
+    on existing instances continue to the window''s end. The provider may not complete retirement while
+    instances remain realized under it — the realized-instances-are-pinned-consumers rule at whole-provider
+    scope. The trail reads as one wind-down: announcement, migrations, the empty final state.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Retire an entire provider from an estate as a governed wind-down with derived blast radius,
+    standard-machinery migrations, and no stranded instances
+  success_criteria:
+  - Whole-provider retirement enters deprecation with a published window; it is never immediate
+  - 'The blast radius is derived: instances via realization provenance, consumers via covers_types bindings'
+  - New realizations against the departing provider are refused from deprecation onward, typed with the
+    retirement named
+  - Day-2 operations on existing instances continue through the window; migrations run the standard provider-swap
+    blue/green under each workload's change policy
+  - Retirement cannot complete while any instance remains realized under the provider — the wind-down
+    trail ends at a provably empty state
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: deprecation window + refusal of new realizations + continued day-2 service
+  - domain: data
+    interaction: provenance and covers_types derive the complete blast radius
+  - domain: policy
+    interaction: each migration runs under its workload's own change policy
+  - domain: audit
+    interaction: one wind-down trail from announcement to provably empty
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: change-control-2026-07-25
+  timestamp: '2026-07-26T04:00:00Z'
+tags:
+- hammer
+- change-control
+- matrix-gap
+- provider-retirement
+- wind-down
diff --git a/dav/use-cases/hammer-class-versioning/001-additive-base-element-propagates.yaml b/dav/use-cases/hammer-class-versioning/001-additive-base-element-propagates.yaml
new file mode 100644
index 0000000..a7fadce
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/001-additive-base-element-propagates.yaml
@@ -0,0 +1,54 @@
+uuid: uc-19483bb1-4335-4042-9115-a5149ac82de8
+handle: class-versioning/additive-base-element-propagates
+version: 1.1.0
+scenario:
+  description: A registry maintainer adds an OPTIONAL element to a Base Class. Recompilation regenerates
+    every downstream Type Class, Provider Class, and generated flat spec in the same change; each regenerated
+    artifact keeps its identity uuid, takes a compatible version bump under the publish law, and lands
+    a new digest row in the pin manifest (ADR-051); the deterministic gates (fuzz, compat, catalog, identity
+    integrity) re-prove every descendant automatically. Downstream organizations pinned to earlier versions
+    are untouched until they re-pin — nothing propagates into an estate implicitly.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Evolve a Base Class additively and have every derived artifact regenerate, re-verify, and re-version
+    in one atomic registry change
+  success_criteria:
+  - The Base Class change and every regenerated descendant land in one atomic change set
+  - Every regenerated artifact keeps its identity uuid and carries a version bump the compat gate accepts
+    as sufficient, with its new (version, digest) row appended to the pin manifest
+  - The change record lists the standing gate suite that re-proved every regenerated spec (no per-change test authoring appears anywhere in the change)
+  - Every pin in the consumer manifests still resolves to its pre-change revision — the recorded (version,
+    digest) rows are append-only, so no pinned consumer's resolved bytes change
+  - The change record enumerates every regenerated artifact (the blast radius is explicit, not discovered)
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: class graph recompiles; every descendant re-versions atomically with digests recomputed
+  - domain: policy
+    interaction: compat gate classifies the change additive and accepts the declared bumps
+  - domain: provider
+    interaction: provider classes inherit the new optional element without redeclaration
+  - domain: audit
+    interaction: the change set records the full regeneration manifest
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- base-class
+- additive
+- recompilation
diff --git a/dav/use-cases/hammer-class-versioning/002-breaking-base-underdeclared-bump-refused.yaml b/dav/use-cases/hammer-class-versioning/002-breaking-base-underdeclared-bump-refused.yaml
new file mode 100644
index 0000000..c2428cc
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/002-breaking-base-underdeclared-bump-refused.yaml
@@ -0,0 +1,51 @@
+uuid: uc-97ff267a-8a57-4f8e-ac0c-8c3369a48ed3
+handle: class-versioning/breaking-base-underdeclared-bump-refused
+version: 1.0.0
+scenario:
+  description: 'A registry maintainer changes the SHAPE of an existing Base Class element (string to object)
+    but declares only a patch bump. The compat gate must refuse the change: shape changes are breaking,
+    the declared version increment is insufficient, and the refusal names the element, the classification,
+    and the required bump. The change never reaches the registry.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Have an under-declared breaking Base Class change refused at the gate with the required bump
+    named
+  success_criteria:
+  - The compat gate classifies the element shape change as breaking
+  - The change is refused because the declared bump is insufficient for the classification
+  - 'The refusal is typed and actionable: it names the element, the breaking classification, and the minimum
+    required bump'
+  - No downstream artifact is regenerated from the refused change
+  - The refusal exists as a durable typed gate-outcome record naming the change, the classification, and the declared-vs-required bumps
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the element diff is classified breaking by deterministic comparison
+  - domain: policy
+    interaction: the version-sufficiency rule refuses the under-declared bump
+  - domain: audit
+    interaction: the gate refusal and its classification are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- base-class
+- breaking-change
+- must-reject
diff --git a/dav/use-cases/hammer-class-versioning/003-breaking-base-blast-radius-enumerated.yaml b/dav/use-cases/hammer-class-versioning/003-breaking-base-blast-radius-enumerated.yaml
new file mode 100644
index 0000000..b569466
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/003-breaking-base-blast-radius-enumerated.yaml
@@ -0,0 +1,55 @@
+uuid: uc-d0afd979-1545-426b-8400-0eb5ba1ee1a7
+handle: class-versioning/breaking-base-blast-radius-enumerated
+version: 1.0.0
+scenario:
+  description: 'A registry maintainer makes a properly-declared BREAKING Base Class change (major bump).
+    Before merge, the change artifact enumerates the full blast radius computed from the class graph:
+    every Type Class and Provider Class that includes the element, every generated flat spec that re-renders,
+    and every known pinned consumer (via the consumer-conformance manifests) that will accumulate visible
+    debt. The merge recompiles everything in one release; no descendant is left referencing the old shape
+    inside the registry.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Make a breaking Base Class change with its full downstream impact enumerated and recompiled
+    atomically
+  success_criteria:
+  - 'The blast radius is computed from the class graph, not hand-listed: affected classes, regenerated
+    specs, and pinned consumers'
+  - Every affected descendant is regenerated with a matching breaking bump in the same release
+  - No artifact inside the registry references the pre-change element shape after merge
+  - Consumer-conformance manifests identify which downstream consumers now carry version debt
+  - The enumeration is part of the durable change record
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the class graph yields the affected-artifact set deterministically
+  - domain: policy
+    interaction: breaking classification demands and receives a major bump across the set
+  - domain: provider
+    interaction: provider classes re-render against the new base shape in the same release
+  - domain: audit
+    interaction: the blast-radius enumeration is preserved with the change
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- base-class
+- breaking-change
+- blast-radius
diff --git a/dav/use-cases/hammer-class-versioning/004-intra-registry-version-pin-refused.yaml b/dav/use-cases/hammer-class-versioning/004-intra-registry-version-pin-refused.yaml
new file mode 100644
index 0000000..41ff3d7
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/004-intra-registry-version-pin-refused.yaml
@@ -0,0 +1,50 @@
+uuid: uc-63ccfe2d-15df-4b67-b5c0-3140844f3657
+handle: class-versioning/intra-registry-version-pin-refused
+version: 1.0.0
+scenario:
+  description: 'A contributor authors a Type Class that pins its Base Class reference to a FIXED prior
+    version instead of referencing by handle. Inside one registry this is version skew: a single release
+    would carry two truths of the same Base Class. The registry refuses the pin at validation: intra-registry
+    class references are by handle and always compile against the release''s single current version —
+    the registry ref itself is the only intra-registry pin.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Have a version-pinned intra-registry class reference refused so a release stays single-truth
+  success_criteria:
+  - A Type or Provider Class declaring a fixed-version Base Class reference fails registry validation
+  - 'The refusal is typed and actionable: it names the reference, the skew rule, and the by-handle correction'
+  - Registry compilation always resolves class references to the release's current versions
+  - VERSIONING.md's registry-resolution scope states the registry ref is the sole intra-registry pin (the criterion is the citation resolving)
+  - The refusal is a gate outcome recorded with the change
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: class reference resolution is by handle against the release tree
+  - domain: policy
+    interaction: the single-truth rule refuses fixed-version intra-registry references
+  - domain: audit
+    interaction: the refusal records the attempted pin and the rule applied
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- pinning
+- single-source
+- must-reject
diff --git a/dav/use-cases/hammer-class-versioning/005-organization-pin-honored-with-visible-debt.yaml b/dav/use-cases/hammer-class-versioning/005-organization-pin-honored-with-visible-debt.yaml
new file mode 100644
index 0000000..56d528d
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/005-organization-pin-honored-with-visible-debt.yaml
@@ -0,0 +1,59 @@
+uuid: uc-375a39b1-9e71-4a23-ad09-ced55a0356db
+handle: class-versioning/organization-pin-honored-with-visible-debt
+version: 1.1.0
+scenario:
+  description: 'A downstream organization pins its estate to a specific Base Class revision — thing@version,
+    or thing@sha256:<hex> where the profile demands byte-exactness (ADR-051; the publish law makes the
+    version pin exact, the pin manifest resolves it to its recorded digest, and the digest pin verifies
+    the bytes) — while the registry moves ahead. The pin is honored completely: compilation
+    and realization in that estate use the pinned revision; nothing upstream propagates implicitly. The
+    cost is visibility, not capability: the version distance appears as enumerated debt (per class, per
+    pinned artifact) in the estate''s validation output, and a registry-ref bump deliberately re-opens
+    the list. Pinning behind is legal; being silently behind is not.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Pin an organization's estate to a specific class revision and retain full control with the drift
+    visible as enumerated debt
+  success_criteria:
+  - The estate's compilation and realization resolve the pinned revision — the manifest-recorded digest
+    for a @version pin, the named bytes for a @sha256 pin — not the registry head
+  - A digest pin is verified against the pin manifest before use; a version/digest mismatch is refused
+    with the digest authoritative
+  - No registry change alters the estate's behavior until the organization re-pins
+  - The version distance is enumerated per pinned artifact in the estate's own validation output
+  - The debt list re-opens automatically when the estate's registry ref advances
+  - Every estate artifact's compiled-against revision (version + digest) is present in the estate's validation
+    output as a record field
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: '@version and @digest pins resolve immutable published revisions deterministically'
+  - domain: policy
+    interaction: pin-behind is classified legal debt, never silent drift
+  - domain: provider
+    interaction: realization in the pinned estate uses the pinned class surface
+  - domain: audit
+    interaction: pin provenance is reconstructible per artifact
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- pinning
+- organizational-control
+- burn-down
diff --git a/dav/use-cases/hammer-class-versioning/006-pin-ahead-or-unknown-refused.yaml b/dav/use-cases/hammer-class-versioning/006-pin-ahead-or-unknown-refused.yaml
new file mode 100644
index 0000000..0155207
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/006-pin-ahead-or-unknown-refused.yaml
@@ -0,0 +1,49 @@
+uuid: uc-d75b2657-082d-4555-9826-a7c59d96c0bc
+handle: class-versioning/pin-ahead-or-unknown-refused
+version: 1.1.0
+scenario:
+  description: 'A downstream organization''s estate declares a class pin whose version or digest does not
+    exist in the registry ref the estate consumes — ahead of the registry, or fabricated. The pin is refused
+    at estate validation: a pin must resolve to a real published revision (a (handle, version) row in the
+    pin manifest, or recorded bytes for a @sha256 pin — ADR-051). The refusal distinguishes unknown-revision
+    from behind-but-legal, so legitimate debt is not conflated with broken references.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Have a pin that resolves to no real registry revision refused, distinct from legal pin-behind
+  success_criteria:
+  - A pin naming a version or digest absent from the consumed registry ref fails estate validation
+  - 'The refusal is typed: unknown-revision, distinct from the legal behind-with-debt state'
+  - The refusal names the pinned reference and the registry ref it failed to resolve against
+  - Legal behind pins in the same estate continue to validate with debt, unaffected
+  - The refusal is recorded in the estate's validation output
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: pin resolution is checked against the consumed registry ref
+  - domain: policy
+    interaction: unknown-revision refuses; behind-revision accrues debt
+  - domain: audit
+    interaction: the failed resolution is recorded with both sides named
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- pinning
+- must-reject
diff --git a/dav/use-cases/hammer-class-versioning/007-blue-green-unpin-promoted-on-clean-diff.yaml b/dav/use-cases/hammer-class-versioning/007-blue-green-unpin-promoted-on-clean-diff.yaml
new file mode 100644
index 0000000..388f920
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/007-blue-green-unpin-promoted-on-clean-diff.yaml
@@ -0,0 +1,51 @@
+uuid: uc-b7499564-c60e-4962-aeaa-f41760cc322b
+handle: class-versioning/blue-green-unpin-promoted-on-clean-diff
+version: 1.0.0
+scenario:
+  description: A pinned organization wants to move from Base Class revision A to current revision B without
+    trusting the compatibility claim blindly. The same intent corpus is compiled under blue (the pinned
+    revision) and green (the candidate revision) side by side; realizations are dry-run and their TYPED
+    OUTPUTS diffed. The diff is empty (or every difference is reviewed and approved), so the re-pin is
+    promoted, and the diff artifact is preserved as the promotion evidence. Unpinning becomes a tested
+    act, not a leap.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Promote a class re-pin through blue/green compilation with an empty-or-approved typed-output
+    diff as the gate
+  success_criteria:
+  - The identical intent corpus compiles under both the pinned and candidate class revisions
+  - Realization is dry-run under both; declared typed outputs are diffed mechanically
+  - Promotion requires the diff to be empty or every difference explicitly approved
+  - The diff artifact and approval are preserved as the promotion's audit evidence
+  - After promotion the estate's pins reference the new revision and the debt entry closes
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: composite_service
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: two compilations of one intent corpus under two class revisions
+  - domain: policy
+    interaction: the promotion gate is the typed-output diff, not the version claim
+  - domain: provider
+    interaction: dry-run realization produces comparable declared outputs under both revisions
+  - domain: audit
+    interaction: the diff and approval trail are the promotion evidence
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- blue-green
+- unpinning
+- typed-output-diff
diff --git a/dav/use-cases/hammer-class-versioning/008-blue-green-promotion-refused-on-diff.yaml b/dav/use-cases/hammer-class-versioning/008-blue-green-promotion-refused-on-diff.yaml
new file mode 100644
index 0000000..11b6207
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/008-blue-green-promotion-refused-on-diff.yaml
@@ -0,0 +1,52 @@
+uuid: uc-69cb89e7-f878-4739-b97c-01aacd6ed999
+handle: class-versioning/blue-green-promotion-refused-on-diff
+version: 1.0.0
+scenario:
+  description: 'The same blue/green re-pin exercise, but the typed-output diff is NOT clean: the candidate
+    revision changes a realized output the organization''s consumers bind against. Promotion is refused
+    with the diff as the typed reason; the estate remains on the pinned revision with its debt intact;
+    the refusal and diff are recorded. The claimed compatibility of the upstream change is now contradicted
+    by evidence — which is itself a finding routed back to the registry.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Have a class re-pin promotion refused when the typed-output diff contradicts the compatibility
+    claim
+  success_criteria:
+  - Promotion is refused when the typed-output diff shows unapproved differences
+  - 'The refusal is typed and actionable: it carries the diff, naming each changed output and its consumers'
+  - The estate remains on the pinned revision; nothing partially promotes
+  - The refusal and diff are recorded as audit evidence
+  - A finding-routing record (the P0-defined registry kind) is created carrying the contradicted claim with the diff as provenance
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: composite_service
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the output diff is computed from declared typed outputs, not provider internals
+  - domain: policy
+    interaction: unapproved differences refuse promotion atomically
+  - domain: audit
+    interaction: refusal, diff, and upstream finding are all recorded
+  - domain: provider
+    interaction: both revisions' dry-run realizations remain reproducible for review
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- blue-green
+- must-reject
+- typed-output-diff
diff --git a/dav/use-cases/hammer-class-versioning/009-element-scope-move-is-breaking.yaml b/dav/use-cases/hammer-class-versioning/009-element-scope-move-is-breaking.yaml
new file mode 100644
index 0000000..3aa0811
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/009-element-scope-move-is-breaking.yaml
@@ -0,0 +1,50 @@
+uuid: uc-ec36271c-de3a-456a-8826-30be80453634
+handle: class-versioning/element-scope-move-is-breaking
+version: 1.0.0
+scenario:
+  description: A registry maintainer moves an element from Base Class scope to Provider Class scope with
+    only a minor bump. Because portability is DERIVED from element scope, narrowing an element's scope
+    shrinks the portable surface of every type that carried it — a breaking change to the portability
+    contract even though no schema shape changed. The gate must classify scope narrowing as breaking and
+    refuse the under-declared bump.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Have an element scope narrowing classified as breaking because it shrinks the derived portable
+    surface
+  success_criteria:
+  - Moving an element to a narrower scope is classified breaking regardless of schema-shape stability
+  - The under-declared bump is refused with the portability impact named
+  - The refusal enumerates the types whose portable surface the move would shrink
+  - Scope widening (Provider to Type, Type to Base) is classified compatible
+  - The classification rule is deterministic gate logic, not review judgment
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: element scope position derives the portable surface
+  - domain: policy
+    interaction: scope narrowing is breaking by rule; the gate refuses the insufficient bump
+  - domain: audit
+    interaction: the refused move and its portability impact are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T15:00:00Z'
+tags:
+- hammer
+- class-versioning
+- portability
+- element-scope
+- must-reject
diff --git a/dav/use-cases/hammer-class-versioning/010-generated-spec-declares-compilation-provenance.yaml b/dav/use-cases/hammer-class-versioning/010-generated-spec-declares-compilation-provenance.yaml
new file mode 100644
index 0000000..c3c6d94
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/010-generated-spec-declares-compilation-provenance.yaml
@@ -0,0 +1,55 @@
+uuid: uc-95e9dce6-001b-4b56-9ec1-308ff10dbc3e
+handle: class-versioning/generated-spec-declares-compilation-provenance
+version: 1.1.0
+scenario:
+  description: 'A generated flat resource spec declares its complete compilation provenance in the artifact
+    itself: the exact revisions (handle, version, digest — the provenance block is a referrer, ADR-051)
+    of every Base, Type, and Provider class it was
+    compiled from, every shared-element layer and referenced common schema, and the generator version.
+    An auditor holding only the flat spec resolves the full chain without consulting anything but the
+    registry''s revision store — the pin guarantee (''the artifact contains its chain'') becomes verifiable
+    rather than asserted.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Have every generated flat spec declare its full compilation provenance — class chain, layers,
+    referenced schemas, generator — resolvable from the artifact alone
+  success_criteria:
+  - The flat spec carries a compilation-provenance block naming every input revision by handle, version,
+    and digest
+  - 'The block covers the full chain: Base, Type, and Provider classes, shared-element layers, and referenced
+    common schemas'
+  - A realized instance extends the chain with realization provenance — the provider definition/registration
+    revision and engine binding version that realized it
+  - The generator version that produced the artifact is part of the block
+  - An auditor resolves every named revision from the artifact alone against the revision store
+  - The provenance block changes exactly when a compilation input changes — never independently
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the provenance block is part of the generated artifact's declared surface
+  - domain: policy
+    interaction: generation is only accepted with a complete provenance block
+  - domain: audit
+    interaction: chain resolution from artifact to revision store is reconstructible
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T23:30:00Z'
+tags:
+- hammer
+- class-versioning
+- provenance
+- compiled-from
+- live-provenance
diff --git a/dav/use-cases/hammer-class-versioning/011-historical-chain-reconstruction.yaml b/dav/use-cases/hammer-class-versioning/011-historical-chain-reconstruction.yaml
new file mode 100644
index 0000000..d615283
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/011-historical-chain-reconstruction.yaml
@@ -0,0 +1,54 @@
+uuid: uc-929229bc-6257-4ed7-9033-80f13bf68b0c
+handle: class-versioning/historical-chain-reconstruction
+version: 1.1.0
+scenario:
+  description: 'An auditor must answer, for a resource definition as it stood at an arbitrary past revision:
+    which Base, Type, and Provider class revisions — and which layer revisions — produced it? Both
+    families resolve exactly (ADR-051): an immutable record is fetched by its identity uuid (a record
+    never changes); a mutable definition''s past revision is fetched by (handle, version), with the pin
+    manifest''s recorded digest verifying the bytes (the publish law froze that pair; git history is the
+    revision store). Because every generated artifact declares its compilation provenance, the answer is
+    a mechanical walk: fetch the past artifact revision, read its provenance block, resolve each named
+    input revision. The full historical chain reconstructs for any revision that ever existed, with no
+    reliance on memory, logs, or the current state of anything.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Reconstruct the complete class and layer chain of any historical artifact revision mechanically
+    from the revision store
+  success_criteria:
+  - Any past artifact revision is fetchable from the revision store — records by identity uuid, definitions
+    by (handle, version) with the recorded digest verifying the bytes
+  - Its provenance block names its input revisions, each itself fetchable the same way
+  - The reconstruction is purely mechanical — no logs, memory, or current-state consultation
+  - 'The walk terminates with the complete chain: classes, layers, schemas, generator version'
+  - Two auditors performing the walk independently obtain identical chains
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: immutable revisions + declared provenance make history a database
+  - domain: audit
+    interaction: historical reconstruction is deterministic and independently repeatable
+  - domain: policy
+    interaction: compliance queries about past contracts resolve without privileged knowledge
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T23:30:00Z'
+tags:
+- hammer
+- class-versioning
+- provenance
+- historical-provenance
+- reconstruction
diff --git a/dav/use-cases/hammer-class-versioning/012-provenance-mismatch-refused.yaml b/dav/use-cases/hammer-class-versioning/012-provenance-mismatch-refused.yaml
new file mode 100644
index 0000000..25d829e
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/012-provenance-mismatch-refused.yaml
@@ -0,0 +1,51 @@
+uuid: uc-8b804009-80a2-41e5-83cf-e997bd1c65c1
+handle: class-versioning/provenance-mismatch-refused
+version: 1.0.0
+scenario:
+  description: 'A generated flat spec''s provenance block claims it was compiled from a set of class revisions
+    — but recompiling from exactly those revisions does not reproduce the artifact (the artifact was hand-edited
+    after generation, or the block was not updated with a regeneration). The gate refuses: a provenance
+    claim that does not reproduce its artifact is integrity failure, typed, naming the divergence. Provenance
+    is only worth carrying if it is verified — an unverified compiled-from block is provenance theater.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Have a generated artifact whose declared provenance does not reproduce it refused at the gate
+    as an integrity failure
+  success_criteria:
+  - Recompiling from the block's named input revisions must reproduce the artifact byte-comparably
+  - A mismatch (hand-edit after generation, stale block) is refused, typed as provenance integrity failure
+  - 'The refusal names the divergence: which sections differ from the faithful recompilation'
+  - The check runs in CI on every change touching generated artifacts — verification, not trust
+  - A matching artifact passes with the verification recorded
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: provenance verification is recompile-and-compare, deterministic
+  - domain: policy
+    interaction: unverifiable provenance refuses at the gate
+  - domain: audit
+    interaction: verification outcomes are recorded with the change
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-25T23:30:00Z'
+tags:
+- hammer
+- class-versioning
+- provenance
+- provenance-integrity
+- must-reject
diff --git a/dav/use-cases/hammer-class-versioning/013-provider-internal-change-is-free.yaml b/dav/use-cases/hammer-class-versioning/013-provider-internal-change-is-free.yaml
new file mode 100644
index 0000000..2352791
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/013-provider-internal-change-is-free.yaml
@@ -0,0 +1,54 @@
+uuid: uc-defc9e70-2930-47fe-9ff7-8ced1016d389
+handle: class-versioning/provider-internal-change-is-free
+version: 1.0.0
+scenario:
+  description: 'A provider re-platforms its engine internals — new runtime, new dependencies, refactored
+    implementation — entirely past its naturalization boundary. Its declared surface (capabilities, adopted
+    standards, defaults, populated outputs) is unchanged, so the provider definition carries no consumer-facing
+    versioning obligation: consumers'' bindings, pins, and realizations are untouched, and the engine
+    binding version that realizations record in provenance is the only visible trace. The optional safety
+    net is the engine-upgrade regression: the same corpus dry-run under old and new engines diffs to empty
+    on declared outputs, proving the boundary held.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Change provider internals freely past the naturalization boundary with no consumer-facing version
+    obligation, provable by an empty output diff
+  success_criteria:
+  - The provider's declared surface is byte-identical before and after the internal change
+  - No consumer binding, pin, or realized contract changes; no consumer action is required
+  - Realization provenance records the new engine binding version — the only visible trace
+  - An optional engine-upgrade regression (same corpus, old vs new engine, declared-output diff) verifies
+    the boundary held with an empty diff
+  - A non-empty diff reclassifies the change as a surface change and routes it to the versioned path
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: internal freedom past the naturalization boundary; engine version in provenance
+  - domain: data
+    interaction: the declared surface is the comparison baseline; the output diff is the proof
+  - domain: audit
+    interaction: provenance carries the engine version; regression evidence recorded when run
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T00:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- naturalization-boundary
+- internal-freedom
diff --git a/dav/use-cases/hammer-class-versioning/014-provider-surface-change-versions.yaml b/dav/use-cases/hammer-class-versioning/014-provider-surface-change-versions.yaml
new file mode 100644
index 0000000..fd56cde
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/014-provider-surface-change-versions.yaml
@@ -0,0 +1,59 @@
+uuid: uc-2462fef2-d704-433b-abdb-f702133779b2
+handle: class-versioning/provider-surface-change-versions
+version: 1.1.0
+scenario:
+  description: 'A provider extends its declared surface: it begins populating an additional declared output
+    for a type it serves and registers one new capability. The surface change classifies additive, so
+    the provider definition takes a minor bump under the publish law — its identity uuid frozen, its new
+    revision''s digest recorded (ADR-051) — exactly as a type spec would. Later
+    it stops supporting a capability: that classifies breaking, takes the major-class bump under the standard
+    floors, and downstream estates see it exactly as they see an upstream class change — a visible debt/impact
+    entry, adopted under their own change policies, with blue/green available for the migration off the
+    dropped capability.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Version provider surface changes under the standard classification rules — additive minor, breaking
+    major, a bump always (identity frozen), downstream visibility always
+  success_criteria:
+  - Adding a populated output or capability classifies additive and takes a minor bump with the identity
+    uuid unchanged
+  - Dropping a capability or changing a populated output's shape classifies breaking under the standard
+    floors
+  - The provider-surface classification uses the same rule set as type/class compat — one classifier discipline,
+    two subjects
+  - Downstream estates see a provider surface change as visible impact under their change policies, never
+    as silent drift
+  - Blue/green (provider-swap or engine-regression form) is the migration instrument off a dropped capability
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the declared surface is the versioned contract
+  - domain: policy
+    interaction: the standard classification and floors apply unchanged
+  - domain: data
+    interaction: surface diffs are computed over declared capabilities/standards/outputs
+  - domain: audit
+    interaction: surface changes carry a version bump + recorded digest and appear in downstream impact
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T00:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- surface-versioning
+- capabilities
diff --git a/dav/use-cases/hammer-class-versioning/015-provider-underdeclared-surface-change-refused.yaml b/dav/use-cases/hammer-class-versioning/015-provider-underdeclared-surface-change-refused.yaml
new file mode 100644
index 0000000..df5f1cf
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/015-provider-underdeclared-surface-change-refused.yaml
@@ -0,0 +1,54 @@
+uuid: uc-b19e1b7a-6f56-4d92-898c-cbd223384fa6
+handle: class-versioning/provider-underdeclared-surface-change-refused
+version: 1.1.0
+scenario:
+  description: 'A provider stops populating a declared output it previously supplied — consumers bind
+    to that output — but submits the change under its already-published version. The gate refuses on both
+    counts: the surface diff classifies the dropped output as breaking (insufficient bump, same refusal
+    shape as an under-declared class change), and republishing a published (identity, version) with
+    different bytes is an integrity failure against the publish law (ADR-051 — the pin manifest''s
+    recorded digest is the detector). The refusal names the dropped output, the consumers bound to it
+    (from the estate''s bindings), and the required bump. Nothing propagates from a refused change.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Have an under-declared provider surface change refused with the dropped output, its bound consumers,
+    and the required bump named
+  success_criteria:
+  - Dropping a populated output classifies breaking; a revision bump is refused as insufficient
+  - A changed provider definition republished under its already-published version is refused as a publish-law
+    violation (recorded digest mismatch)
+  - The refusal names the dropped output and the consumers whose bindings depend on it
+  - The refusal states the required bump — typed and actionable
+  - No downstream impact entry is created from a refused change
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: surface classification + publish law refuse the under-declared change
+  - domain: data
+    interaction: bound consumers are derived from bindings, giving the refusal its blast context
+  - domain: audit
+    interaction: the refusal is a recorded gate outcome
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T00:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- surface-versioning
+- must-reject
diff --git a/dav/use-cases/hammer-class-versioning/016-capability-evolves-without-sibling-churn.yaml b/dav/use-cases/hammer-class-versioning/016-capability-evolves-without-sibling-churn.yaml
new file mode 100644
index 0000000..5a7322c
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/016-capability-evolves-without-sibling-churn.yaml
@@ -0,0 +1,59 @@
+uuid: uc-127dbcd8-6200-4e49-9ea6-05eef9371245
+handle: class-versioning/capability-evolves-without-sibling-churn
+version: 1.1.0
+scenario:
+  description: 'A provider serves both compute and storage capabilities. Its compute capability takes
+    a breaking contract change (an output shape changes) and majors — the version moves on that capability
+    alone, its capability_uuid frozen (ADR-051: the accreditation anchor survives the change; the new
+    revision''s digest is what re-attestation cites). The storage capability''s version, digest, and consumers
+    are completely untouched:
+    impact reaches exactly the consumers bound through the types the compute capability covers, and no
+    storage consumer sees a debt entry, a notification, or any version movement. The envelope does not
+    major — the capability set did not change.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Evolve one capability through a breaking change with impact scoped exactly to its bound consumers
+    and zero movement on sibling capabilities or the envelope
+  success_criteria:
+  - The breaking change majors the affected capability with its own version bump; its capability_uuid
+    is unchanged (frozen identity)
+  - The sibling capability's version and recorded digest are byte-identical before and after
+  - Impact entries appear only for consumers bound through the affected capability's covers_types
+  - 'The envelope version does not major — set semantics: no capability was added or removed'
+  - The provider definition version bumps (the whole-surface pin reflects any change) without carrying
+    capability-level meaning
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: capability-plane versioning isolates the change
+  - domain: data
+    interaction: covers_types computes the exact consumer blast radius
+  - domain: policy
+    interaction: classification routes to the capability, not the envelope
+  - domain: audit
+    interaction: the capability's version movement and scoped impact are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T01:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- two-plane
+- capability-plane
+- blast-radius
diff --git a/dav/use-cases/hammer-class-versioning/017-envelope-set-semantics-and-whole-pin.yaml b/dav/use-cases/hammer-class-versioning/017-envelope-set-semantics-and-whole-pin.yaml
new file mode 100644
index 0000000..2bc9706
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/017-envelope-set-semantics-and-whole-pin.yaml
@@ -0,0 +1,59 @@
+uuid: uc-5528b265-2393-4a31-a5c3-b19fd447107e
+handle: class-versioning/envelope-set-semantics-and-whole-pin
+version: 1.1.0
+scenario:
+  description: 'The same provider adds an entirely new capability (envelope minor — the set grew compatibly)
+    and later retires another (envelope major — the set shrank). Throughout, an estate that pinned the
+    provider definition revision (the whole-surface pin — definition@version, or definition@sha256:<hex>
+    for byte-exactness, ADR-051) is untouched by every one of these
+    movements until its own change policy adopts: envelope semver communicates set evolution to humans,
+    the definition revision gives conservative estates one pin for everything, and the two carry different
+    meanings by design.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Version the capability set through the envelope while whole-provider pins ride definition revisions,
+    each plane carrying its own meaning
+  success_criteria:
+  - Adding a capability bumps the envelope minor; retiring one bumps it major — set semantics only
+  - Capability-internal changes never drive envelope classification
+  - An estate pinned to a definition revision is untouched by all movements until it re-pins under its
+    change policy
+  - Consumers binding a specific capability identify it by its frozen capability_uuid and pin its revision
+    at a version or digest, never by envelope version
+  - The retired capability follows the deprecation lifecycle — pinned consumers keep resolving it through
+    the published window
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: envelope versions the set; definition revision pins the surface
+  - domain: policy
+    interaction: estate change policies gate adoption of either plane's movement
+  - domain: data
+    interaction: capability pins are version/digest-exact on a frozen identity, independent of envelope
+  - domain: audit
+    interaction: set changes and pin states are reconstructible
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T01:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- two-plane
+- envelope
+- whole-pin
+- deprecation
diff --git a/dav/use-cases/hammer-class-versioning/018-capability-level-blue-green.yaml b/dav/use-cases/hammer-class-versioning/018-capability-level-blue-green.yaml
new file mode 100644
index 0000000..69d77c9
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/018-capability-level-blue-green.yaml
@@ -0,0 +1,56 @@
+uuid: uc-7efe8e18-d034-47b5-a645-454a79cb5f0f
+handle: class-versioning/capability-level-blue-green
+version: 1.0.0
+scenario:
+  description: 'A provider needs to roll a breaking v2 of its compute capability without touching its
+    storage service. The v2 runs green under the standard promotion contract: the same intent corpus realizes
+    dry-run under compute-capability v1 (blue) and v2 (green), declared typed outputs diff, and promotion
+    of the capability re-pin happens only on a clean-or-approved diff — while the storage capability serves
+    live traffic on its current version throughout, unaware anything happened. Realization provenance
+    records which capability revision governed each realization, so the transition window is fully reconstructible.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Promote one capability's breaking version through blue/green while sibling capabilities serve
+    untouched, with capability revisions in realization provenance
+  success_criteria:
+  - 'Blue/green runs at capability granularity: the same corpus realizes under capability v1 and v2, outputs
+    diffed'
+  - Promotion of the capability re-pin requires a clean-or-approved diff (the standard evidence gate,
+    unwaived)
+  - Sibling capabilities serve on their current versions throughout, with no movement
+  - Realization provenance records the capability revision governing each realization across the transition
+  - A dirty diff refuses the capability promotion and routes the contradicted claim upstream — scoped
+    to the capability
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: composite_service
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: capability-scoped blue/green — staged provider evolution without whole-provider upgrades
+  - domain: data
+    interaction: typed-output diff at capability scope is the promotion gate
+  - domain: policy
+    interaction: the evidence gate applies unchanged at the finer granularity
+  - domain: audit
+    interaction: capability revisions in provenance make the transition reconstructible
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T01:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- two-plane
+- blue-green
+- capability-plane
diff --git a/dav/use-cases/hammer-class-versioning/019-misplaced-plane-classification-refused.yaml b/dav/use-cases/hammer-class-versioning/019-misplaced-plane-classification-refused.yaml
new file mode 100644
index 0000000..454618d
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/019-misplaced-plane-classification-refused.yaml
@@ -0,0 +1,58 @@
+uuid: uc-2e138eb9-4bf5-42d8-8325-1ed0e463e23b
+handle: class-versioning/misplaced-plane-classification-refused
+version: 1.1.0
+scenario:
+  description: 'A provider changes a capability''s contract (an output it populates changes shape) but
+    submits the change with the capability''s version untouched, bumping only the envelope. The
+    gate refuses on the plane violation: classification must land where the contract changed — the capability
+    — and an envelope bump is not a substitute for the capability''s own publish-law bump (ADR-051: the
+    capability''s recorded digest moved while its (identity, version) claimed nothing changed). The refusal
+    names the changed capability, its unmoved version, the consumers bound through its covers_types, and
+    the required capability-plane
+    bump. The symmetric case is also refused: majoring the envelope for a capability-internal change misstates
+    set semantics.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Have a contract change classified on the wrong versioning plane refused with the correct plane,
+    bump, and affected consumers named
+  success_criteria:
+  - A capability whose contract changed under an unmoved version is refused (publish-law violation at
+    the capability plane)
+  - An envelope bump is rejected as a substitute for capability-plane classification
+  - The refusal names the changed capability, the required capability bump, and the consumers bound via
+    covers_types
+  - An envelope major driven only by a capability-internal change is refused as misstated set semantics
+  - No impact entries propagate from a refused change
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: plane-correct classification is enforced, not advisory
+  - domain: data
+    interaction: the capability surface diff locates where the contract actually changed
+  - domain: audit
+    interaction: the plane violation and its correction path are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T01:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- two-plane
+- misplaced-plane
+- must-reject
diff --git a/dav/use-cases/hammer-class-versioning/020-realized-instance-stable-under-capability-movement.yaml b/dav/use-cases/hammer-class-versioning/020-realized-instance-stable-under-capability-movement.yaml
new file mode 100644
index 0000000..e6416e7
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/020-realized-instance-stable-under-capability-movement.yaml
@@ -0,0 +1,64 @@
+uuid: uc-aaa79575-8b28-4b14-8a16-51c203500ce2
+handle: class-versioning/realized-instance-stable-under-capability-movement
+version: 1.0.0
+scenario:
+  description: 'A VM was realized by a virtualization provider under VM resource type 1.1.0 and the provider''s
+    VM capability 1.2.0 — both recorded immutably in realization provenance. The provider then releases
+    VM capability 1.3.0. The running VM is untouched: no redeploy, no update, no reconciliation is triggered
+    by the capability movement, and its provenance continues to state 1.2.0 as the revision that governed
+    it — fact does not float. The movement IS surfaced: the instance carries a realized-under-vs-current
+    distance notice, typed distinctly from spec pin-lag debt, and the organization''s change policy owns
+    the decision — adopt by updating or re-realizing under 1.3.0 (through the window/ceremony gates, blue/green
+    if the capability change was breaking), or deliberately do nothing, which is a legitimate, recorded
+    choice. Breaking-ness matters at the next realization, never retroactively to a running instance.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Have a provider capability version movement leave realized instances untouched while surfacing
+    the distance for the organization's change policy to decide on
+  success_criteria:
+  - The capability movement (1.2.0 to 1.3.0) triggers no redeploy, update, or reconciliation of the realized
+    VM
+  - Realization provenance continues to record capability 1.2.0 as the governing revision — immutable
+    fact
+  - The realized-under-vs-current distance is surfaced at instance level, typed distinctly from spec pin-lag
+    debt
+  - Drift detection and reconciliation compare the instance against the revisions in its realization provenance,
+    never against current — the capability movement manufactures zero drift
+  - 'Adoption is a change-policy decision: update or re-realize under the estate''s gates (blue/green
+    when the capability change is breaking), or a recorded deliberate no-action'
+  - A subsequent NEW realization under the provider uses the current capability revision and records it
+    — the movement governs the future, never rewrites the past
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: capability movement changes nothing about existing realizations
+  - domain: data
+    interaction: immutable realization provenance vs surfaced current-distance are distinct surfaces
+  - domain: policy
+    interaction: the change policy owns adoption — including deliberate no-action
+  - domain: audit
+    interaction: the surfaced distance and the adoption (or no-action) decision are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T02:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- realized-stability
diff --git a/dav/use-cases/hammer-class-versioning/021-day2-operation-on-grandfathered-instance.yaml b/dav/use-cases/hammer-class-versioning/021-day2-operation-on-grandfathered-instance.yaml
new file mode 100644
index 0000000..9a1870a
--- /dev/null
+++ b/dav/use-cases/hammer-class-versioning/021-day2-operation-on-grandfathered-instance.yaml
@@ -0,0 +1,64 @@
+uuid: uc-2b6f7df6-51fd-42c2-98c7-fc15006b66db
+handle: class-versioning/day2-operation-on-grandfathered-instance
+version: 1.0.0
+scenario:
+  description: A VM realized under a provider's VM capability 1.2.0 needs a day-2 resize while the provider's
+    current capability is 1.3.0 (a breaking revision). Within 1.2.0's deprecation window the operation
+    succeeds under the contract that governs the instance — the provider operates instances realized under
+    any non-retired revision of the capability (mixed-version operation is part of the capability contract,
+    not a courtesy), and the operation's audit record names the governing capability revision. After 1.2.0
+    retires (its published window elapsed, the calendared forcing function), the same operation is refused
+    — typed as retired-revision, naming the retirement, the migration path (re-realize or update under
+    a current revision, blue/green when breaking), and the change-policy gates that path runs through.
+    The refusal is the beginning of a governed migration, never a surprise outage.
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Operate grandfathered instances under their governing capability revision within the deprecation
+    window, and refuse with a migration path after retirement
+  success_criteria:
+  - Within the deprecation window, day-2 operations on an instance realized under a prior capability revision
+    succeed under that revision's contract
+  - The operation's audit record names the governing capability revision (from realization provenance)
+  - 'Every voluntary touch is a declared decision point: the estate''s touch-trigger policy (adopt-on-touch,
+    offer-on-touch, or provenance-until-explicit) is evaluated with the instance''s provenance-distance
+    surfaced, and the chosen path is recorded'
+  - A capability revision with instances realized under it cannot retire before its published deprecation
+    window elapses
+  - After retirement, the operation is refused — typed retired-revision, naming the retirement, the migration
+    path, and the change-policy gates it runs through
+  - The migration itself is the standard governed adoption (window/ceremony, blue/green when breaking),
+    never an emergency improvisation
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: mixed-version operation within the window is contractual
+  - domain: data
+    interaction: realization provenance supplies the governing revision
+  - domain: policy
+    interaction: retirement is the calendared forcing function; migration runs the standard gates
+  - domain: audit
+    interaction: operations name their governing revision; refusals name the path forward
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: class-versioning-2026-07-25
+  timestamp: '2026-07-26T03:00:00Z'
+tags:
+- hammer
+- class-versioning
+- provider-versioning
+- grandfathered
+- must-reject
diff --git a/dav/use-cases/hammer-cost-quota/001-quota-headroom-check.yaml b/dav/use-cases/hammer-cost-quota/001-quota-headroom-check.yaml
new file mode 100644
index 0000000..d8872f1
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/001-quota-headroom-check.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-cost-quota-001
+handle: cost-quota/quota-headroom-check
+scenario:
+  description: 'A tenant-admin submits a new_request for a small VM whose declared resource footprint
+    fits comfortably inside the tenant''s remaining quota. The admission pipeline must read the tenant''s
+    quota allocation, compute current committed consumption from the intent store, and confirm sufficient
+    headroom before the request is accepted. This is the simple, happy-path baseline for quota enforcement:
+    the mechanism under test is quota headroom evaluation as a validation policy at admission time.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Provision a small VM that fits within remaining tenant quota
+  success_criteria:
+  - Request declared footprint (vCPU, memory, storage) is parsed at admission
+  - Tenant quota allocation is read from the data model
+  - Committed consumption is summed across the tenant's existing intents
+  - Headroom is computed and the request is confirmed to fit
+  - Request is admitted and dispatched to a single eligible provider
+  - The quota check and its computed headroom are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    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: tenant quota allocation and committed consumption read from intent store
+  - domain: policy
+    interaction: quota headroom validation evaluates the request footprint against remaining quota
+  - domain: audit
+    interaction: quota check result and computed headroom recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- quota
+- headroom
+- admission
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Tenant has a quota allocation defined in the data model
+  - Existing committed consumption is recorded in the intent store
+  postconditions:
+  - Request is admitted and realized
+  - Committed consumption reflects the new resource
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/002-quota-exhaustion-blocks-request.yaml b/dav/use-cases/hammer-cost-quota/002-quota-exhaustion-blocks-request.yaml
new file mode 100644
index 0000000..d8eab23
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/002-quota-exhaustion-blocks-request.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-cost-quota-002
+handle: cost-quota/quota-exhaustion-blocks-request
+scenario:
+  description: 'An application-team-member requests a GPU-backed workload whose footprint exceeds the
+    tenant''s remaining quota. The admission pipeline must reject the request before any provider dispatch,
+    returning a deterministic quota-exceeded verdict that names the exhausted dimension (e.g. GPU count)
+    and the amount over budget. No partial provisioning may occur. The mechanism under test is a hard
+    quota ceiling enforced as a blocking validation policy — a denial, not a queue.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: prod
+  perspectives:
+    - sre
+    - tenancy-authority
+  intent: Provision a GPU workload that exceeds remaining tenant quota
+  success_criteria:
+  - Request footprint is computed and compared against remaining quota
+  - The exhausted quota dimension (GPU count) is identified
+  - Request is denied at admission before any provider dispatch
+  - No resource is realized and no partial provisioning occurs
+  - Denial verdict names the exceeded dimension and the over-budget amount
+  - Committed consumption is left unchanged
+  - The denial and its rationale are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: remaining quota and committed consumption read for the GPU dimension
+  - domain: policy
+    interaction: hard quota ceiling validation denies the over-budget request
+  - domain: audit
+    interaction: quota-exceeded denial recorded with exhausted dimension and overage
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- quota
+- exhaustion
+- denial
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Tenant quota for the GPU dimension is nearly exhausted
+  - Requested footprint exceeds remaining GPU quota
+  postconditions:
+  - Request is denied
+  - No resource realized; committed consumption unchanged
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/003-quota-increase-request-budget-gated.yaml b/dav/use-cases/hammer-cost-quota/003-quota-increase-request-budget-gated.yaml
new file mode 100644
index 0000000..56684fe
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/003-quota-increase-request-budget-gated.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-cost-quota-003
+handle: cost-quota/quota-increase-request-budget-gated
+scenario:
+  description: 'A tenant-admin submits a modification that raises the tenant''s quota allocation to accommodate
+    a growing service. Because a quota increase commits future spend, the pipeline must treat the change
+    as budget-affecting: it must recompute the projected cost of the new ceiling, compare it against the
+    tenant''s approved budget envelope, and only then admit the change. The mechanism under test is whether
+    the architecture models a quota allocation as first-class, mutable, budget-bound intent rather than
+    a static provider limit.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Raise the tenant quota ceiling within the approved budget envelope
+  success_criteria:
+  - Quota-increase modification is accepted into the pipeline as intent
+  - Projected cost of the new ceiling is computed from the requested footprint
+  - Projected cost is compared against the tenant's budget envelope
+  - Increase within budget is admitted; the raised ceiling is persisted
+  - Committed consumption headroom reflects the new ceiling
+  - The recompute, the budget comparison, and the decision are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: current quota ceiling and budget envelope read; new ceiling persisted
+  - domain: policy
+    interaction: budget validation compares projected cost of the new ceiling to the envelope
+  - domain: audit
+    interaction: quota-increase decision and budget comparison recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- quota
+- budget
+- modification
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Tenant has an existing quota ceiling and a defined budget envelope
+  postconditions:
+  - Raised ceiling is persisted within budget
+  - Audit records the budget-gated decision
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/004-budget-gate-routes-to-approval.yaml b/dav/use-cases/hammer-cost-quota/004-budget-gate-routes-to-approval.yaml
new file mode 100644
index 0000000..4c32c48
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/004-budget-gate-routes-to-approval.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-cost-quota-004
+handle: cost-quota/budget-gate-routes-to-approval
+scenario:
+  description: 'A finance-analyst-governed prod tenant submits a request whose projected cost pushes cumulative
+    committed spend past a soft budget threshold. Rather than a hard denial, policy must route the request
+    to a human approval step: the pipeline pauses, emits an approval task naming the projected overage
+    and the approver role, and blocks realization until an explicit decision returns. The mechanism under
+    test is human_escalation_required as an orchestration outcome of a budget gate — does the architecture
+    support a pause-for-approval state, or does it only model allow/deny?
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Approve or reject spend that crosses a soft budget threshold
+  success_criteria:
+  - Projected cost of the request is computed and added to cumulative committed spend
+  - Cumulative spend is found to cross the soft budget threshold
+  - Request is neither admitted nor denied but paused pending approval
+  - An approval task is emitted naming the overage amount and approver role
+  - Realization is blocked until an explicit approval decision returns
+  - On approval the request proceeds; on rejection it is denied with rationale
+  - The pause, the approval task, and the final decision are recorded in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: cumulative committed spend and budget threshold read
+  - domain: policy
+    interaction: budget gate escalates the over-threshold request to human approval
+  - domain: provider
+    interaction: dispatch withheld until approval returns
+  - domain: audit
+    interaction: pause, approval task, and final decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- budget
+- approval
+- escalation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A soft budget threshold and an approver role are defined for the tenant
+  postconditions:
+  - Request is paused with an outstanding approval task
+  - Realization occurs only after explicit approval
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/005-per-tenant-cost-rollup.yaml b/dav/use-cases/hammer-cost-quota/005-per-tenant-cost-rollup.yaml
new file mode 100644
index 0000000..7039e2d
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/005-per-tenant-cost-rollup.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-cost-quota-005
+handle: cost-quota/per-tenant-cost-rollup
+scenario:
+  description: 'A finance-analyst asks for a per-tenant cost rollup across a multi-tenant estate: total
+    committed and consumed cost for every tenant, decomposed by resource type. The system must walk the
+    ownership edges from each tenant to its realized resources, attach a per-resource cost, and aggregate
+    up the tenant boundary. The mechanism under test is whether cost is a queryable, attributable attribute
+    of realized resources in the data model — or whether cost lives entirely outside UDLM and the rollup
+    can only be partially derived from footprint counts.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+    - executive
+  intent: Produce a per-tenant cost rollup decomposed by resource type
+  success_criteria:
+  - Every tenant's owned resources are enumerated via ownership edges
+  - A per-resource cost is attached to each realized resource
+  - Costs aggregate correctly up to the tenant boundary
+  - The rollup decomposes each tenant total by resource type
+  - Resources with no cost attribute are surfaced as an unpriced remainder
+  - The rollup query and its coverage are recorded in audit
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: system_defaults_only
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: ownership edges walked and per-resource cost attributes aggregated by tenant
+  - domain: audit
+    interaction: rollup query, per-tenant totals, and unpriced remainder recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- chargeback
+- rollup
+- multi-tenant
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Multiple tenants own realized resources in the data model
+  postconditions:
+  - A per-tenant, per-type cost rollup is produced
+  - Unpriced resources are explicitly reported
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/006-chargeback-shared-pool-attribution.yaml b/dav/use-cases/hammer-cost-quota/006-chargeback-shared-pool-attribution.yaml
new file mode 100644
index 0000000..e2f937f
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/006-chargeback-shared-pool-attribution.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-cost-quota-006
+handle: cost-quota/chargeback-shared-pool-attribution
+scenario:
+  description: 'Two tenants run workloads on a single shared storage pool. A finance-analyst needs a defensible
+    chargeback that splits the pool''s cost between the tenants by their actual consumption, not an even
+    split. The system must attribute a shared resource''s cost across multiple owning stakes, each proportional
+    to that stake''s declared or measured share. The mechanism under test is multi-owner cost attribution
+    over a shared allocatable — a case UDLM''s single-owner assumptions may not cleanly express, so expect
+    partial support.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Split a shared pool's cost across tenants by proportional consumption
+  success_criteria:
+  - The shared pool and its multiple consuming tenants are identified
+  - Each tenant's share of the pool (declared allocation or measured use) is resolved
+  - Pool cost is split proportionally across the consuming tenants
+  - The split sums exactly to the pool's total cost with no leakage or double-count
+  - Tenants with a stake but no cost mapping are surfaced as a gap
+  - The attribution basis and the resulting split are recorded in audit
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: shared pool, its stakes, and per-stake share resolved from the model
+  - domain: policy
+    interaction: attribution rule splits pool cost proportionally across stakes
+  - domain: audit
+    interaction: attribution basis and per-tenant split recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- chargeback
+- shared-pool
+- attribution
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A shared pool is consumed by two or more tenants
+  - Per-stake shares are declared or measurable
+  postconditions:
+  - Pool cost is split with no leakage or double-counting
+  - Any missing stake-to-cost mapping is reported as a gap
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/007-cost-follows-ownership-stake-edge.yaml b/dav/use-cases/hammer-cost-quota/007-cost-follows-ownership-stake-edge.yaml
new file mode 100644
index 0000000..30daec0
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/007-cost-follows-ownership-stake-edge.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-cost-quota-007
+handle: cost-quota/cost-follows-ownership-stake-edge
+scenario:
+  description: 'A shared database service is owned by a platform team but consumed under a stake edge
+    by an application team. When the application team''s stake is re-pointed to a different owning service,
+    the cost attribution must follow the stake edge, not the resource''s static creator. A finance-analyst
+    validates that after the re-point, accrued cost lands on the current stakeholder. The mechanism under
+    test is whether cost attribution traverses the live ownership/stake relationship in the graph rather
+    than a frozen creation record.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives: []
+  intent: Ensure cost attribution follows the current stake edge, not the creator
+  success_criteria:
+  - The resource, its creator, and its current stakeholder are distinguished
+  - Cost is attributed to the entity on the current stake edge
+  - After the stake edge is re-pointed, new accrual follows the new stakeholder
+  - Historical accrual remains attributed to the prior stakeholder for its window
+  - The attribution change and its effective boundary are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: stake edge resolved and re-pointed; cost attribution keyed to the live edge
+  - domain: policy
+    interaction: attribution constraint binds cost to the current stakeholder
+  - domain: audit
+    interaction: attribution change and its effective boundary recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- attribution
+- stake-edge
+- ownership
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A resource has a creator distinct from its current stakeholder
+  postconditions:
+  - New accrual follows the re-pointed stake edge
+  - Historical attribution is preserved per window
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/008-shared-allocatable-split-by-stake.yaml b/dav/use-cases/hammer-cost-quota/008-shared-allocatable-split-by-stake.yaml
new file mode 100644
index 0000000..5c398f7
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/008-shared-allocatable-split-by-stake.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-cost-quota-008
+handle: cost-quota/shared-allocatable-split-by-stake
+scenario:
+  description: 'A single physical GPU is time-sliced across three application teams via fractional allocations
+    recorded as stakes on the allocatable. A finance-analyst needs the GPU''s amortized cost split across
+    the three stakes exactly in proportion to their fractional allocation. The system must read the allocatable,
+    enumerate its fractional stakes, and divide cost by stake weight. The mechanism under test is stake-weighted
+    cost division over one allocatable resource — does the model carry fractional stake weights, or only
+    whole-resource ownership?
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Split one allocatable's cost across fractional stakes by weight
+  success_criteria:
+  - The allocatable and its fractional stakes are enumerated
+  - Each stake carries a resolvable fractional weight
+  - Cost is divided across stakes strictly by weight
+  - The split sums to the allocatable's total cost within rounding tolerance
+  - Rounding residue is assigned deterministically, not dropped
+  - Stakes lacking a weight are surfaced as an attribution gap
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: allocatable and its fractional stake weights read from the model
+  - domain: policy
+    interaction: stake-weighted division validates the split totals to the whole
+  - domain: audit
+    interaction: per-stake split and rounding residue assignment recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- allocatable
+- stake-weight
+- split
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - One allocatable is shared via fractional stakes summing to its capacity
+  postconditions:
+  - Cost is split by weight and reconciles to the whole
+  - Missing weights are reported
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/009-showback-vs-chargeback.yaml b/dav/use-cases/hammer-cost-quota/009-showback-vs-chargeback.yaml
new file mode 100644
index 0000000..74d51a7
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/009-showback-vs-chargeback.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-cost-quota-009
+handle: cost-quota/showback-vs-chargeback
+scenario:
+  description: 'The same estate must render two cost views: a non-binding showback that informs teams
+    of their consumption, and a binding chargeback that actually debits a tenant budget and decrements
+    quota. A finance-analyst switches a tenant from showback to chargeback mode. The system must treat
+    cost visibility and cost enforcement as separate policy modes over identical attribution data, and
+    only in chargeback mode may cost affect budget and quota. The mechanism under test is whether the
+    architecture separates cost reporting from cost enforcement as a policy toggle, or conflates the two.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Toggle a tenant between non-binding showback and binding chargeback
+  success_criteria:
+  - Showback and chargeback are modeled as distinct policy modes over one attribution set
+  - In showback mode cost is reported but budget and quota are untouched
+  - In chargeback mode the same cost debits budget and decrements quota
+  - Switching modes does not alter the underlying attribution data
+  - The mode in force is attached to each cost statement
+  - The mode change and its effective time are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: one attribution set read; mode flag toggled on the tenant
+  - domain: policy
+    interaction: showback vs chargeback policy modes decide whether cost binds to budget and quota
+  - domain: audit
+    interaction: mode change and each statement's governing mode recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- showback
+- chargeback
+- policy-mode
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Attribution data exists for the tenant
+  postconditions:
+  - Mode toggle changes enforcement without changing attribution
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/010-amortized-capex-vs-opex.yaml b/dav/use-cases/hammer-cost-quota/010-amortized-capex-vs-opex.yaml
new file mode 100644
index 0000000..523dd29
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/010-amortized-capex-vs-opex.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-cost-quota-010
+handle: cost-quota/amortized-capex-vs-opex
+scenario:
+  description: 'An on-prem estate mixes owned hardware (capex, depreciated on a schedule) with cloud-burst
+    capacity (opex, billed by usage). A finance-analyst needs a unified per-tenant cost that amortizes
+    the capex asset over its depreciation life and blends in metered opex for the same period. The system
+    must distinguish an asset''s cost basis (capital, amortized) from consumption-metered cost and combine
+    them on one statement. The mechanism under test is whether UDLM carries a cost-basis / depreciation
+    model at all — capex amortization is almost certainly outside the intent model, so expect unsupported
+    or partial.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+    - tenancy-authority
+  intent: Blend amortized capex and metered opex into one tenant cost view
+  success_criteria:
+  - Capex assets and opex-metered resources are distinguished in the estate
+  - Each capex asset carries a cost basis and depreciation schedule
+  - Amortized capex for the period is computed from the schedule
+  - Metered opex for the same period is computed from usage
+  - The two are combined into a single per-tenant cost for the period
+  - Absence of a depreciation model is reported explicitly rather than assumed zero
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: capex cost basis and depreciation schedule sought alongside opex usage
+  - domain: policy
+    interaction: amortization rule combines capex and opex for the period
+  - domain: audit
+    interaction: blended statement and any missing depreciation model recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- capex
+- opex
+- amortization
+- unsupported-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Estate mixes owned (capex) and burst (opex) capacity
+  postconditions:
+  - A blended cost is produced or the missing capex model is reported
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/011-focus-cost-columns-cluster.yaml b/dav/use-cases/hammer-cost-quota/011-focus-cost-columns-cluster.yaml
new file mode 100644
index 0000000..ccbd33f
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/011-focus-cost-columns-cluster.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-cost-quota-011
+handle: cost-quota/focus-cost-columns-cluster
+scenario:
+  description: 'A finance-analyst wants a cluster''s cost exported in FOCUS (FinOps Open Cost and Usage
+    Specification) shape: rows keyed by resource with the FOCUS columns BilledCost, EffectiveCost, ListCost,
+    BillingAccountId, ServiceCategory, ResourceId and ChargePeriod. The system must project its internal
+    cost and ownership data onto the FOCUS schema for a single cluster. The mechanism under test is whether
+    the model carries the fields FOCUS requires — several FOCUS columns (billed vs effective vs list cost,
+    billing account) have no obvious UDLM source, so expect a partial mapping with named gaps.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Export a cluster's cost in FOCUS-conformant columns
+  success_criteria:
+  - The cluster's resources are enumerated as FOCUS rows keyed by ResourceId
+  - ResourceId, ServiceCategory and ChargePeriod are populated from the model
+  - BillingAccountId is resolved from the owning tenant or reported as absent
+  - BilledCost, EffectiveCost and ListCost are distinguished, not collapsed to one
+  - FOCUS columns with no UDLM source are named explicitly as gaps
+  - The export's FOCUS-conformance coverage is recorded in audit
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: cluster resources and ownership projected onto FOCUS columns
+  - domain: policy
+    interaction: FOCUS-conformance validation checks required columns are populated
+  - domain: audit
+    interaction: conformance coverage and unmapped FOCUS columns recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- focus
+- finops
+- export
+- unsupported-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A cluster with owned resources exists in the model
+  postconditions:
+  - A FOCUS-shaped export is produced with gaps named
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/012-external-metering-no-cost-model.yaml b/dav/use-cases/hammer-cost-quota/012-external-metering-no-cost-model.yaml
new file mode 100644
index 0000000..86faffe
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/012-external-metering-no-cost-model.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-cost-quota-012
+handle: cost-quota/external-metering-no-cost-model
+scenario:
+  description: 'A finance-analyst asks DAV to compute the dollar cost of a running workload directly from
+    the UDLM model. But UDLM deliberately carries no pricing, rate-card, or metering data — cost is an
+    external metering concern. The system must recognize it can supply the workload''s resource footprint
+    and ownership (the join keys a metering system needs) but cannot itself compute a monetary cost, and
+    must say so rather than fabricate a number. The mechanism under test is honest boundary-drawing: the
+    architecture should return unsupported for monetary calculation while still exposing the footprint
+    an external meter joins against.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives: []
+  intent: Compute a workload's monetary cost from the model alone
+  success_criteria:
+  - The workload's resource footprint and ownership are resolved from the model
+  - No pricing, rate-card, or metering data is found in the model
+  - The system declines to compute a monetary cost rather than fabricating one
+  - The footprint and join keys an external meter would need are exposed
+  - The verdict names cost calculation as an external-metering responsibility
+  - The unsupported determination and the exposed join keys are recorded in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: footprint and ownership resolved; no pricing data present in the model
+  - domain: audit
+    interaction: unsupported monetary-cost verdict and exposed join keys recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- metering
+- external
+- boundary
+- unsupported-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - The model carries footprint and ownership but no pricing data
+  postconditions:
+  - Monetary cost is declined as external-metering scope
+  - Footprint join keys are exposed for an external meter
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/013-capacity-reservation-cost-implications.yaml b/dav/use-cases/hammer-cost-quota/013-capacity-reservation-cost-implications.yaml
new file mode 100644
index 0000000..495c6a5
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/013-capacity-reservation-cost-implications.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-cost-quota-013
+handle: cost-quota/capacity-reservation-cost-implications
+scenario:
+  description: 'A platform-engineer reserves a block of GPU capacity for a tenant ahead of a seasonal
+    workload. The reservation commits capacity — and therefore cost — whether or not it is consumed. The
+    pipeline must debit the reserved capacity against the tenant''s quota and budget at reservation time,
+    not at consumption time, and keep accruing while the reservation is idle. The mechanism under test
+    is whether the architecture models a reservation as a cost-bearing, quota- consuming intent distinct
+    from realized usage — reserved-but-idle cost is a classic showback blind spot.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - finance-analyst
+    - provider-owner
+    - tenancy-authority
+  intent: Reserve capacity and account its cost from reservation, not consumption
+  success_criteria:
+  - A capacity reservation is created as intent distinct from realized usage
+  - Reserved capacity is debited against quota at reservation time
+  - Reserved cost accrues against budget while the reservation sits idle
+  - Reserved and consumed cost are reported as separate lines, not merged
+  - Releasing the reservation stops accrual and restores quota
+  - The reservation, its accrual, and its release are recorded in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: reservation recorded as intent; quota debited independent of usage
+  - domain: policy
+    interaction: reservation validation commits cost and quota at reserve time
+  - domain: provider
+    interaction: capacity held against the reservation
+  - domain: audit
+    interaction: reservation, idle accrual, and release recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- reservation
+- capacity
+- accrual
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A tenant has quota and budget headroom for a reservation
+  postconditions:
+  - Reserved capacity accrues cost while idle
+  - Release restores quota and stops accrual
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/014-cost-based-provider-selection.yaml b/dav/use-cases/hammer-cost-quota/014-cost-based-provider-selection.yaml
new file mode 100644
index 0000000..e17f840
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/014-cost-based-provider-selection.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-cost-quota-014
+handle: cost-quota/cost-based-provider-selection
+scenario:
+  description: 'A request is eligible for three providers with different price points. The platform-engineer
+    expects the placement engine to select the cheapest eligible provider that still satisfies all policy
+    constraints (residency, capability). The system must rank eligible providers by cost and choose the
+    lowest that passes every non-cost gate. The mechanism under test is whether cost is a first-class
+    input to placement — UDLM placement is capability- and policy- driven, so a cost-ranked tiebreak may
+    be partial or absent.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+  intent: Place a workload on the cheapest policy-compliant eligible provider
+  success_criteria:
+  - The set of eligible providers is resolved for the request
+  - Non-cost policy gates (residency, capability) filter the eligible set
+  - Surviving providers are ranked by cost
+  - The cheapest compliant provider is selected and dispatched
+  - If no provider carries cost data, selection falls back and reports the missing signal
+  - The ranking basis and the selection rationale are recorded in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: eligible providers and any per-provider cost signal read
+  - domain: policy
+    interaction: policy gates filter, then cost ranks the surviving providers
+  - domain: provider
+    interaction: cheapest compliant provider is dispatched
+  - domain: audit
+    interaction: ranking basis and selection rationale recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- placement
+- provider-selection
+- cost-ranking
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Multiple eligible providers exist with differing cost
+  postconditions:
+  - The cheapest compliant provider is selected
+  - Missing cost signal is reported when present
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/015-cross-tenant-cost-leakage-denied.yaml b/dav/use-cases/hammer-cost-quota/015-cross-tenant-cost-leakage-denied.yaml
new file mode 100644
index 0000000..7f65966
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/015-cross-tenant-cost-leakage-denied.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-cost-quota-015
+handle: cost-quota/cross-tenant-cost-leakage-denied
+scenario:
+  description: 'A tenant-admin for tenant A issues a cost query that, through a shared pool join, would
+    return line items attributable to tenant B. The system must scope every cost statement to the requester''s
+    tenant boundary and refuse to leak another tenant''s cost detail — returning only A''s proportional
+    share of any shared resource, never B''s itemization. The mechanism under test is tenant isolation
+    on the cost/attribution plane: a chargeback engine that joins across a shared pool is a prime cross-tenant
+    leakage vector.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - finance-analyst
+    - security-officer
+  intent: Query cost and confirm no other tenant's detail leaks through shared joins
+  success_criteria:
+  - The cost query is scoped to the requesting tenant's boundary
+  - Shared-resource lines return only the requester's proportional share
+  - No other tenant's itemized cost detail is returned
+  - An attempt to widen scope past the tenant boundary is denied
+  - The scoping decision and the denied widening are recorded in audit
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: cross_dependency_payload
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: cost query joined across a shared pool but filtered to the tenant boundary
+  - domain: policy
+    interaction: tenant-isolation matrix denies cross-tenant cost disclosure
+  - domain: audit
+    interaction: scoping and denied scope-widening recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- multi-tenancy
+- isolation
+- leakage
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Tenants A and B share a pool with joinable cost lines
+  postconditions:
+  - Only the requester's share is returned
+  - Cross-tenant disclosure is denied and logged
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/016-multi-currency-fx-normalization.yaml b/dav/use-cases/hammer-cost-quota/016-multi-currency-fx-normalization.yaml
new file mode 100644
index 0000000..39d6131
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/016-multi-currency-fx-normalization.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-cost-quota-016
+handle: cost-quota/multi-currency-fx-normalization
+scenario:
+  description: 'A global finance-analyst rolls up cost across regions billed in different currencies (USD,
+    EUR, JPY) into one reporting currency. Correct normalization requires per-line currency tags and an
+    FX rate at the charge period — neither of which UDLM is likely to carry. The system must either normalize
+    using present currency and rate metadata or declare that currency and FX are outside the model and
+    the rollup cannot be trusted as a single-currency total. The mechanism under test is multi-currency
+    awareness; expect unsupported.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - sovereignty-authority
+    - executive
+  intent: Roll up multi-region cost into a single reporting currency
+  success_criteria:
+  - Per-region cost lines are enumerated across currencies
+  - Each line is checked for a currency tag and a charge-period FX rate
+  - If currency and FX are present, lines normalize to the reporting currency
+  - If absent, the rollup declines to assert a single-currency total
+  - Missing currency/FX metadata is named as the blocking gap
+  - The normalization attempt and its coverage are recorded in audit
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: per-line currency tags and FX rates sought across regions
+  - domain: policy
+    interaction: normalization constraint requires currency and FX before asserting a total
+  - domain: audit
+    interaction: normalization coverage and missing FX metadata recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- currency
+- fx
+- normalization
+- unsupported-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Cost lines span multiple billing currencies
+  postconditions:
+  - A single-currency total is asserted only if currency and FX are present
+  - Otherwise the gap is reported
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/017-decommission-releases-quota-final-statement.yaml b/dav/use-cases/hammer-cost-quota/017-decommission-releases-quota-final-statement.yaml
new file mode 100644
index 0000000..12dbb2f
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/017-decommission-releases-quota-final-statement.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-cost-quota-017
+handle: cost-quota/decommission-releases-quota-final-statement
+scenario:
+  description: 'A tenant-admin decommissions a service. On teardown the pipeline must stop cost accrual
+    at the decommission instant, release the resource''s footprint back to the tenant''s quota, and emit
+    a final cost statement covering the resource''s full lifetime up to that instant. No cost may accrue
+    after decommission and the freed quota must be immediately available to new requests. The mechanism
+    under test is lifecycle-coupled cost and quota release — orphaned accrual on a torn-down resource
+    is a common billing defect.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - finance-analyst
+    - tenancy-authority
+  intent: Decommission a service, release its quota, and close its cost
+  success_criteria:
+  - Decommission clears the resource's realized state
+  - Cost accrual stops precisely at the decommission instant
+  - The resource's footprint is released back to tenant quota
+  - Freed quota is immediately usable by a subsequent request
+  - A final cost statement covering the full lifetime is emitted
+  - No cost accrues after the decommission instant
+  - The teardown, quota release, and final statement are recorded in audit
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: realized state cleared; footprint returned to quota
+  - domain: policy
+    interaction: decommission validation closes accrual and releases quota
+  - domain: provider
+    interaction: provider tears the resource down
+  - domain: audit
+    interaction: teardown, quota release, and final cost statement recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- decommission
+- quota-release
+- final-statement
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A realized service consumes quota and accrues cost
+  postconditions:
+  - Quota is released and accrual is closed
+  - Freed quota is immediately reusable
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/018-usage-drift-exceeds-quota.yaml b/dav/use-cases/hammer-cost-quota/018-usage-drift-exceeds-quota.yaml
new file mode 100644
index 0000000..4f37b4e
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/018-usage-drift-exceeds-quota.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-cost-quota-018
+handle: cost-quota/usage-drift-exceeds-quota
+scenario:
+  description: 'An sre runs drift detection and finds a workload whose realized consumption has grown
+    past the quota its intent declared — a provider-side autoscale expanded it beyond the committed ceiling.
+    The system must detect the divergence between declared-quota intent and realized consumption, flag
+    the over-quota drift, and surface the unbudgeted overage rather than silently absorbing it. The mechanism
+    under test is quota drift detection: does the model reconcile realized usage against the quota intent,
+    or does quota only gate admission and never re-check?
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - compliance-auditor
+  intent: Detect realized consumption that has drifted past declared quota
+  success_criteria:
+  - Realized consumption is compared against the declared-quota intent
+  - The over-quota drift is detected and the exceeded dimension identified
+  - The unbudgeted overage amount is quantified
+  - The drift is flagged for remediation rather than silently absorbed
+  - Remediation options (reclaim, raise quota, charge overage) are surfaced
+  - The detected drift and its overage are recorded in audit
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: realized consumption reconciled against declared-quota intent
+  - domain: policy
+    interaction: recovery policy flags over-quota drift and proposes remediation
+  - domain: audit
+    interaction: drift detection and unbudgeted overage recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- drift
+- quota-overage
+- reconciliation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A workload's realized use has grown past its declared quota
+  postconditions:
+  - Over-quota drift is flagged with a quantified overage
+  - Remediation options are surfaced
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/019-commitment-discount-amortization.yaml b/dav/use-cases/hammer-cost-quota/019-commitment-discount-amortization.yaml
new file mode 100644
index 0000000..797a483
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/019-commitment-discount-amortization.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-cost-quota-019
+handle: cost-quota/commitment-discount-amortization
+scenario:
+  description: 'A tenant holds a one-year committed-use discount that must be amortized across the workloads
+    that consume the committed capacity, so each tenant''s chargeback reflects the discounted effective
+    rate rather than list price. A finance-analyst validates that consumers under the commitment are billed
+    at the effective rate and that unused commitment is accounted as waste against the tenant, not hidden.
+    The mechanism under test is commitment/discount amortization — reserved-instance economics require
+    an effective-vs-list rate model UDLM almost certainly lacks, so expect partial or unsupported.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+    - tenancy-authority
+  intent: Amortize a committed-use discount across its consumers at the effective rate
+  success_criteria:
+  - The commitment, its term, and its committed capacity are identified
+  - Consumers drawing on the committed capacity are enumerated
+  - Each consumer is charged the effective (discounted) rate, not list
+  - Unused commitment is accounted as waste against the committing tenant
+  - Effective and list rates are reported distinctly, not collapsed
+  - Absence of an effective-rate model is reported rather than assumed
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: commitment terms, committed capacity, and consumers resolved from the model
+  - domain: policy
+    interaction: amortization rule applies the effective rate and books unused commitment as waste
+  - domain: audit
+    interaction: effective-vs-list rates and commitment waste recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- commitment
+- discount
+- amortization
+- unsupported-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A tenant holds a committed-use discount with consumers
+  postconditions:
+  - Consumers are billed at the effective rate or the gap is reported
+  - Unused commitment is booked as waste
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-cost-quota/020-unallocated-cost-tag-bucket.yaml b/dav/use-cases/hammer-cost-quota/020-unallocated-cost-tag-bucket.yaml
new file mode 100644
index 0000000..70faea2
--- /dev/null
+++ b/dav/use-cases/hammer-cost-quota/020-unallocated-cost-tag-bucket.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-cost-quota-020
+handle: cost-quota/unallocated-cost-tag-bucket
+scenario:
+  description: 'A finance-analyst runs tag-based cost allocation across the estate, but a subset of resources
+    carry no owning tag — no tenant, cost center, or stake. The system must route the cost of untagged
+    resources into an explicit unallocated bucket rather than dropping it or spreading it silently, so
+    the unallocated total is visible and can be driven to zero. It must also surface which resources are
+    untagged so they can be remediated. The mechanism under test is allocation completeness: does the
+    architecture guarantee every cost lands somewhere, with an auditable unallocated remainder?
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Allocate estate cost by tag and expose the untagged remainder
+  success_criteria:
+  - Every resource is checked for an owning allocation tag
+  - Tagged-resource cost is allocated to its owner
+  - Untagged-resource cost is routed to an explicit unallocated bucket
+  - The unallocated total is reported, never silently dropped or spread
+  - The specific untagged resources are listed for remediation
+  - Allocated plus unallocated cost reconciles to the estate total
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: resources scanned for allocation tags; untagged set identified
+  - domain: policy
+    interaction: allocation-completeness validation routes untagged cost to the unallocated bucket
+  - domain: audit
+    interaction: unallocated total, untagged resource list, and reconciliation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- cost-quota
+- tag-allocation
+- unallocated
+- completeness
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Some estate resources lack an owning allocation tag
+  postconditions:
+  - Untagged cost lands in a visible unallocated bucket
+  - Allocated plus unallocated reconciles to the total
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/001-issue-scoped-credential.yaml b/dav/use-cases/hammer-credentials/001-issue-scoped-credential.yaml
new file mode 100644
index 0000000..467e79a
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/001-issue-scoped-credential.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-credentials-001
+handle: credentials/issue-scoped-credential
+scenario:
+  description: 'A platform engineer requests a new credential scoped to a single provider and a single
+    interaction (deploy-only) for an application service. The system must mint a Credential resource whose
+    model record carries scope, provider binding, issuer, and validity window as metadata only — never
+    the secret value. This exercises the baseline credential issuance path and the CPX-001 metadata-only
+    invariant on the simplest possible request.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - security-officer
+  intent: Issue a provider-scoped, interaction-scoped credential for a service
+  success_criteria:
+  - Credential resource is created with a stable UUID
+  - Record captures scope (provider + interaction) as structured metadata
+  - Validity window (not_before / not_after) is recorded
+  - The secret value is never written to any of the four state stores
+  - Issuer identity and issuing policy are recorded
+  - Credential is usable only for the declared provider and interaction
+  dimensions:
+    lifecycle_phase: new_request
+    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: policy
+    interaction: issuance policy validates requested scope against actor entitlement
+  - domain: data
+    interaction: credential metadata persisted, secret value excluded by construction
+  - domain: audit
+    interaction: issuance event recorded with issuer, scope, and validity
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- issuance
+- scoping
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/002-value-never-stored-metadata-only.yaml b/dav/use-cases/hammer-credentials/002-value-never-stored-metadata-only.yaml
new file mode 100644
index 0000000..d6ceb93
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/002-value-never-stored-metadata-only.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-credentials-002
+handle: credentials/value-never-stored-metadata-only
+scenario:
+  description: 'A security officer audits the DCM data model to prove that no credential secret material
+    (private keys, passwords, tokens, client secrets) is ever persisted in any of the four state stores.
+    The system must demonstrate that Credential records hold only metadata — reference/handle, scope,
+    issuer, fingerprint, validity — and that the actual value lives exclusively in an external secret
+    backend. This directly exercises the CPX-001 invariant that value is never stored in the model.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Prove no credential secret value is persisted anywhere in the model
+  success_criteria:
+  - Every Credential record is confirmed to contain metadata only
+  - A non-secret reference/handle points to the external secret backend
+  - A fingerprint or public half may be present; the secret half never is
+  - No intent, realized, dispatch, or drift store contains secret material
+  - The audit confirms the invariant holds across all credential records
+  - The report is reproducible without exposing any secret value
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: all four stores scanned; only metadata found for credentials
+  - domain: policy
+    interaction: metadata-only invariant enforced as a structural constraint
+  - domain: audit
+    interaction: invariant-proof report recorded without leaking secret values
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- cpx-001
+- metadata-only
+- audit
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/003-jit-issuance.yaml b/dav/use-cases/hammer-credentials/003-jit-issuance.yaml
new file mode 100644
index 0000000..15104c1
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/003-jit-issuance.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-credentials-003
+handle: credentials/jit-issuance
+scenario:
+  description: 'An SRE runs a dispatch whose policy forbids standing credentials: the provider interaction
+    requires a credential to be minted just-in-time at dispatch, scoped to that single interaction, and
+    automatically expired seconds after use. The system must issue the credential inline as part of the
+    dispatch flow, bind it to the exact provider call, and record its short-lived lifecycle. This tests
+    whether credential issuance can be an inline step of an orchestration flow rather than a standing
+    resource created ahead of time.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - security-officer
+  intent: Mint a single-use credential just-in-time inside a provider dispatch
+  success_criteria:
+  - No standing credential exists before the dispatch begins
+  - Credential is issued inline as a step of the dispatch flow
+  - Scope is bound to exactly one provider interaction
+  - Validity window is short-lived and recorded
+  - Credential is marked expired/consumed immediately after the interaction
+  - The full JIT issue-use-expire arc is captured in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: orchestration_flow_static
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: policy mandates JIT issuance and forbids standing credentials
+  - domain: provider
+    interaction: provider interaction consumes the freshly minted credential
+  - domain: data
+    interaction: short-lived credential metadata created and retired within the flow
+  - domain: audit
+    interaction: issue-use-expire lifecycle recorded as one arc
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- jit
+- ephemeral
+- orchestration
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/004-routine-rotation-parallel-validity.yaml b/dav/use-cases/hammer-credentials/004-routine-rotation-parallel-validity.yaml
new file mode 100644
index 0000000..42a5131
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/004-routine-rotation-parallel-validity.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-credentials-004
+handle: credentials/routine-rotation-parallel-validity
+scenario:
+  description: 'A platform engineer rotates a provider API credential that is in active use by several
+    running services. The rotation policy requires a parallel-validity window: the new credential must
+    be issued and accepted before the old one is retired, so no in-flight interaction fails. The system
+    must model both credential versions as valid simultaneously for the overlap window, cut consumers
+    over to the new version, then retire the old one only after the window closes. This tests whether
+    the model supports overlapping-validity rotation rather than an atomic swap.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - security-officer
+  intent: Rotate an in-use credential with a parallel-validity overlap window
+  success_criteria:
+  - New credential version is issued while the old remains valid
+  - Both versions are simultaneously valid during the overlap window
+  - Consumers are cut over to the new version without failed interactions
+  - Old version is retired only after the overlap window closes
+  - Dependency edges to the credential remain stable across rotation
+  - The rotation timeline and overlap window are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: rotation policy enforces parallel-validity before retirement
+  - domain: data
+    interaction: two credential versions coexist; consumer edges updated
+  - domain: provider
+    interaction: providers accept the new version before the old is retired
+  - domain: audit
+    interaction: overlap window and cutover recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- rotation
+- parallel-validity
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/005-emergency-rotation-compromise.yaml b/dav/use-cases/hammer-credentials/005-emergency-rotation-compromise.yaml
new file mode 100644
index 0000000..1d22e5d
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/005-emergency-rotation-compromise.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-005
+handle: credentials/emergency-rotation-compromise
+scenario:
+  description: 'A security officer declares a credential compromised and triggers an emergency rotation
+    with NO transition window: the old credential must be invalidated immediately, before any parallel-validity
+    overlap, even though live interactions are using it. The system must revoke-and-reissue atomically,
+    accept that in-flight interactions on the old credential will fail, and prove the old value can no
+    longer authenticate anywhere. This deliberately conflicts with the parallel-validity rotation path
+    and likely surfaces as partially_supported or unsupported — a finding.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Immediately kill a compromised credential with no overlap window
+  success_criteria:
+  - Old credential is invalidated immediately with no overlap
+  - New credential is issued as part of the same emergency action
+  - In-flight interactions on the old credential are forced to fail
+  - The compromised value cannot authenticate to any provider afterward
+  - All consumers are notified they must re-acquire the new credential
+  - The compromise declaration and emergency rotation are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: provider_failure
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: recovery policy authorizes zero-window emergency rotation
+  - domain: provider
+    interaction: providers reject the compromised value immediately
+  - domain: data
+    interaction: old credential marked invalid without an overlap window
+  - domain: audit
+    interaction: compromise event and forced failures recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- rotation
+- compromise
+- emergency
+- likely-unsupported
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/006-expiry-mid-dispatch.yaml b/dav/use-cases/hammer-credentials/006-expiry-mid-dispatch.yaml
new file mode 100644
index 0000000..c0e73d0
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/006-expiry-mid-dispatch.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-credentials-006
+handle: credentials/expiry-mid-dispatch
+scenario:
+  description: 'A multi-step dispatch is in flight when the credential it is using crosses its not_after
+    boundary between two provider interactions. The system must detect the mid-dispatch expiry, stop using
+    the now-invalid credential, and either fail the dispatch cleanly with a resumable checkpoint or re-acquire
+    a fresh credential and continue — without leaving a half-realized resource. This probes whether credential
+    validity is re-checked per interaction rather than only at dispatch start, and is a strong candidate
+    for partially_supported.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - security-officer
+  intent: Handle a credential that expires between steps of an active dispatch
+  success_criteria:
+  - Credential expiry is detected before the next interaction uses it
+  - The dispatch does not proceed with an expired credential
+  - Either a clean resumable failure or a fresh-credential continuation occurs
+  - No resource is left in a half-realized, inconsistent state
+  - Dispatch and realized states remain reconcilable afterward
+  - The mid-dispatch expiry and chosen recovery are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: per-interaction validity check gates the next step
+  - domain: provider
+    interaction: provider call is blocked once the credential is expired
+  - domain: data
+    interaction: dispatch checkpoint preserved to avoid a half-realized resource
+  - domain: audit
+    interaction: mid-dispatch expiry and recovery path recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- expiry
+- dispatch
+- likely-partial
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/007-expiry-drift-detection.yaml b/dav/use-cases/hammer-credentials/007-expiry-drift-detection.yaml
new file mode 100644
index 0000000..34e7cbb
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/007-expiry-drift-detection.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-credentials-007
+handle: credentials/expiry-drift-detection
+scenario:
+  description: 'A credential in the model has an intent that says it should be valid, but its external
+    secret backend shows it has already expired or been rotated out-of-band. The system''s drift detection
+    must flag the divergence between the intended credential state and the realized backend state, and
+    surface it as remediable drift rather than silently trusting the model. This tests whether credential
+    validity is a first-class drift signal, not just a static attribute.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - security-officer
+  intent: Detect that a credential expired out-of-band as drift against intent
+  success_criteria:
+  - Intended credential validity is compared against the backend's realized state
+  - An expired-but-intended-valid credential is flagged as drift
+  - The drift record identifies the affected credential and its consumers
+  - A remediation (rotate or revoke) is proposed, not auto-trusted
+  - No secret value is read or stored during drift comparison
+  - The drift finding is recorded in audit
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intended validity compared against realized backend state
+  - domain: policy
+    interaction: drift policy classifies the expiry divergence as remediable
+  - domain: audit
+    interaction: credential drift finding and proposed remediation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- drift
+- expiry
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/008-revocation-sla-propagation.yaml b/dav/use-cases/hammer-credentials/008-revocation-sla-propagation.yaml
new file mode 100644
index 0000000..b663270
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/008-revocation-sla-propagation.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-credentials-008
+handle: credentials/revocation-sla-propagation
+scenario:
+  description: 'A security officer revokes a credential that is referenced by many consumers across multiple
+    providers. Policy sets a hard SLA: every consumer and provider must observe the revocation and stop
+    accepting the credential within a bounded time. The system must fan the revocation out to all dependents,
+    confirm propagation to each, and prove that none can still authenticate after the SLA elapses. This
+    tests whether revocation is a tracked, acknowledged, SLA-bounded propagation rather than a single
+    flag flip.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives: []
+  intent: Revoke a credential and confirm SLA-bounded propagation to all consumers
+  success_criteria:
+  - All consumers referencing the credential are enumerated from the dependency graph
+  - Revocation is fanned out to every consumer and provider
+  - Each dependent's acknowledgement of the revocation is tracked
+  - No dependent can authenticate with the credential after the SLA window
+  - Any consumer that fails to acknowledge within SLA is escalated
+  - Propagation timeline and per-consumer acknowledgements are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph enumerates every credential consumer
+  - domain: policy
+    interaction: SLA policy bounds and verifies propagation completeness
+  - domain: provider
+    interaction: each provider stops accepting the revoked credential
+  - domain: audit
+    interaction: per-consumer acknowledgement and SLA compliance recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- revocation
+- sla
+- propagation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/009-actor-deprovision-cascade-revoke.yaml b/dav/use-cases/hammer-credentials/009-actor-deprovision-cascade-revoke.yaml
new file mode 100644
index 0000000..4036fec
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/009-actor-deprovision-cascade-revoke.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-009
+handle: credentials/actor-deprovision-cascade-revoke
+scenario:
+  description: 'A tenant admin deprovisions an actor (a departing engineer''s service identity). Every
+    credential issued to that actor must be revoked as a cascade, and any resource that depended on those
+    credentials must be flagged so it can be re-credentialed under a new owner rather than silently losing
+    access. The system must find all credentials keyed to the actor, revoke them, and expose the downstream
+    impact. This tests whether actor lifecycle is coupled to credential lifecycle.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - security-officer
+  intent: Revoke all of a deprovisioned actor's credentials and surface the blast radius
+  success_criteria:
+  - All credentials issued to the actor are enumerated
+  - Every one of those credentials is revoked on deprovision
+  - Resources depending on the revoked credentials are flagged for re-credentialing
+  - No credential keyed to the actor remains valid afterward
+  - Downstream services are not silently left without access
+  - The cascade revocation and impacted resources are recorded in audit
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: all credentials keyed to the actor and their dependents enumerated
+  - domain: policy
+    interaction: deprovision policy mandates cascade revocation
+  - domain: provider
+    interaction: providers stop honoring the revoked actor credentials
+  - domain: audit
+    interaction: cascade revocation and re-credentialing flags recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- deprovision
+- cascade
+- revocation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/010-decommission-blocked-unrevocable.yaml b/dav/use-cases/hammer-credentials/010-decommission-blocked-unrevocable.yaml
new file mode 100644
index 0000000..859e340
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/010-decommission-blocked-unrevocable.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-010
+handle: credentials/decommission-blocked-unrevocable
+scenario:
+  description: 'A platform engineer decommissions an entity whose credential cannot be revoked — the issuing
+    provider is unreachable, or the credential was minted by an offline HSM that is no longer available
+    to process a revocation. Policy forbids completing a decommission while a live credential remains
+    un-revocable, because that leaves a dangling secret that can still authenticate. The system must block
+    the decommission, explain why, and require human escalation. This likely surfaces as unsupported or
+    human_escalation_required — a finding about un-revocable credentials.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - security-officer
+  intent: Decommission an entity whose credential cannot be revoked
+  success_criteria:
+  - The credential tied to the entity is found to be un-revocable
+  - The decommission is blocked rather than completed with a dangling secret
+  - The reason (issuer unreachable / offline HSM) is clearly surfaced
+  - Human escalation is required to force or defer the decommission
+  - No entity state is destroyed while the credential remains live
+  - The blocked decommission and escalation are recorded in audit
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: provider_failure
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: policy blocks decommission while a credential is un-revocable
+  - domain: provider
+    interaction: revocation attempt fails; issuer/HSM is unreachable
+  - domain: data
+    interaction: entity retained; decommission not applied
+  - domain: audit
+    interaction: blocked decommission and escalation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- decommission
+- unrevocable
+- escalation
+- likely-unsupported
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/011-credential-as-dependency.yaml b/dav/use-cases/hammer-credentials/011-credential-as-dependency.yaml
new file mode 100644
index 0000000..1e8a302
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/011-credential-as-dependency.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-011
+handle: credentials/credential-as-dependency
+scenario:
+  description: 'An application team declares a VM whose intent includes `requires: Credential.SSHKey`
+    — the VM cannot be realized until an SSH key credential exists and is bound to it. The placement and
+    dependency engine must treat the credential as a first-class node in the dependency graph, order its
+    issuance before the VM''s realization, and refuse to realize the VM if the credential dependency is
+    unmet. This tests whether Credential is a real dependable resource type, not just an out-of-band side
+    input.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - security-officer
+  intent: Realize a VM that hard-depends on an SSH key credential
+  success_criteria:
+  - The VM intent's requires-Credential.SSHKey edge is parsed into the dependency graph
+  - Credential issuance is ordered before VM realization
+  - The VM is not realized while the credential dependency is unmet
+  - The realized VM references the credential by non-secret handle only
+  - Destroying the credential marks the VM dependency as broken
+  - The dependency ordering is recorded in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: credential modeled as a dependency node ahead of the VM
+  - domain: policy
+    interaction: unmet credential dependency blocks VM realization
+  - domain: provider
+    interaction: VM provider consumes the credential handle at realization
+  - domain: audit
+    interaction: dependency ordering and binding recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- dependency
+- ssh-key
+- ordering
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/012-bootstrap-first-provider.yaml b/dav/use-cases/hammer-credentials/012-bootstrap-first-provider.yaml
new file mode 100644
index 0000000..f29b55b
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/012-bootstrap-first-provider.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-012
+handle: credentials/bootstrap-first-provider
+scenario:
+  description: 'On a greenfield estate, the very first provider must be onboarded — but issuing any credential
+    normally requires an already-trusted provider to mint or attest it. This is the bootstrap chicken-and-egg:
+    there is no prior credential authority to lean on. The system must define how the first provider''s
+    initial credential is established (an out-of-band root of trust, a one-time bootstrap token, operator
+    attestation) and record it as such. This deliberately probes the origin of trust and is a strong candidate
+    for unsupported.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - compliance-auditor
+    - security-officer
+    - sovereignty-authority
+  intent: Establish the first provider credential with no pre-existing authority
+  success_criteria:
+  - The absence of any prior credential authority is recognized
+  - A defined bootstrap mechanism (out-of-band root, one-time token, operator attestation) is used
+  - The first credential is marked as bootstrap-origin, not peer-issued
+  - Subsequent credentials can chain their trust from this root
+  - No circular dependency on an as-yet-nonexistent provider is required
+  - The bootstrap origin and its trust basis are recorded in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: bootstrap policy defines the root-of-trust for the first credential
+  - domain: provider
+    interaction: first provider is admitted using a bootstrap-origin credential
+  - domain: data
+    interaction: credential recorded as bootstrap-origin with no peer issuer
+  - domain: audit
+    interaction: bootstrap trust basis recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- bootstrap
+- chicken-and-egg
+- root-of-trust
+- likely-unsupported
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/013-unscoped-interaction-403.yaml b/dav/use-cases/hammer-credentials/013-unscoped-interaction-403.yaml
new file mode 100644
index 0000000..70aab52
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/013-unscoped-interaction-403.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-credentials-013
+handle: credentials/unscoped-interaction-403
+scenario:
+  description: 'A provider receives an interaction request carrying a credential that is valid but scoped
+    to a different provider or a different interaction (e.g., a deploy-scoped credential used to attempt
+    a delete). The provider must reject the request with a 403 rather than honoring it, and the system
+    must record the scope-violation attempt. This tests the participate/expose trust-plane boundary: possession
+    of a valid credential is not sufficient — scope must match the interaction.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - compliance-auditor
+    - security-officer
+  intent: Use a valid but out-of-scope credential and confirm the provider refuses it
+  success_criteria:
+  - The credential is confirmed valid but scoped to a different provider/interaction
+  - The provider rejects the interaction with a 403 (scope violation)
+  - The requested action does not occur
+  - The scope mismatch is detected from credential metadata, not the secret value
+  - The refused attempt is surfaced as a security-relevant event
+  - The 403 and scope-violation reason are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: scope check compares credential scope to the requested interaction
+  - domain: provider
+    interaction: provider returns 403 and performs no action
+  - domain: audit
+    interaction: scope-violation attempt recorded as security-relevant
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- scope
+- authorization
+- forbidden
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/014-cross-tenant-credential-isolation.yaml b/dav/use-cases/hammer-credentials/014-cross-tenant-credential-isolation.yaml
new file mode 100644
index 0000000..35b7d4d
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/014-cross-tenant-credential-isolation.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-credentials-014
+handle: credentials/cross-tenant-credential-isolation
+scenario:
+  description: 'A tenant admin in tenant A attempts to reference or reuse a credential that belongs to
+    tenant B — by handle, fingerprint, or dependency edge. The system must enforce tenant isolation: credentials
+    are scoped to their owning tenant, and no cross-tenant reference, listing, or reuse is permitted.
+    This tests whether the credential model prevents cross-tenant leakage even when an actor knows the
+    target credential''s non-secret handle.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - security-officer
+  intent: Attempt to reuse another tenant's credential and confirm it is denied
+  success_criteria:
+  - The credential's owning tenant is recorded and enforced
+  - Tenant A cannot list, reference, or reuse tenant B's credential
+  - Knowing the non-secret handle does not grant cross-tenant access
+  - No dependency edge from tenant A to tenant B's credential can be created
+  - The blocked cross-tenant attempt is surfaced as a security event
+  - The denial is recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: tenant-isolation policy denies cross-tenant credential reference
+  - domain: data
+    interaction: credential ownership scoped to tenant; no cross-tenant edge allowed
+  - domain: audit
+    interaction: cross-tenant reuse attempt recorded as denied
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- multi-tenancy
+- isolation
+- leakage
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/015-cross-dcm-credential-scope.yaml b/dav/use-cases/hammer-credentials/015-cross-dcm-credential-scope.yaml
new file mode 100644
index 0000000..8166444
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/015-cross-dcm-credential-scope.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-015
+handle: credentials/cross-dcm-credential-scope
+scenario:
+  description: 'A federated request routes an interaction to a peer DCM, carrying a credential issued
+    by the local DCM and scoped only to local providers. The peer DCM must decide whether it can honor
+    a foreign-issued credential: either it recognizes a federation trust relationship and accepts the
+    scoped credential, or it rejects it and requires a peer-issued or federation-brokered credential.
+    This tests credential scope and trust across a DCM federation boundary and may surface as partially_supported.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+    - security-officer
+  intent: Present a locally-issued credential to a peer DCM across federation
+  success_criteria:
+  - The credential's issuer and scope are evaluated at the peer DCM boundary
+  - A recognized federation trust relationship is required to honor it
+  - Absent trust, the peer DCM rejects the foreign credential
+  - No implicit trust is granted purely because the credential is valid locally
+  - The federation trust decision is explicit and recorded
+  - The cross-DCM credential decision is captured in audit on both sides
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: federation trust policy evaluates the foreign credential's scope
+  - domain: provider
+    interaction: peer DCM accepts or rejects the credential per federation trust
+  - domain: data
+    interaction: issuer and scope compared against federation trust records
+  - domain: audit
+    interaction: cross-DCM credential decision recorded on both DCMs
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- federation
+- peer-dcm
+- trust
+- likely-partial
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/016-sovereign-ip-binding.yaml b/dav/use-cases/hammer-credentials/016-sovereign-ip-binding.yaml
new file mode 100644
index 0000000..ff69b6d
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/016-sovereign-ip-binding.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-016
+handle: credentials/sovereign-ip-binding
+scenario:
+  description: 'A sovereign profile mandates that a credential is only valid when presented from a specific
+    set of source IP ranges inside the sovereign boundary — an IP-bound credential. The system must record
+    the IP-binding constraint as credential metadata and ensure providers refuse the credential when presented
+    from any out-of-boundary address. An interaction from outside the permitted ranges must be denied
+    even with the correct secret. This tests whether credential validity can be constrained by network
+    context under a sovereign mandate.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - security-officer
+    - sovereignty-authority
+  intent: Enforce that a credential is only valid from sovereign-boundary source IPs
+  success_criteria:
+  - The IP-binding constraint is recorded as credential metadata
+  - Providers accept the credential only from permitted source IP ranges
+  - An interaction from an out-of-boundary IP is denied despite a valid secret
+  - The permitted ranges are tied to the sovereign boundary definition
+  - Binding enforcement does not require storing the secret value
+  - Denied out-of-boundary attempts are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: provider_failure
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty policy enforces the credential IP-binding constraint
+  - domain: provider
+    interaction: provider rejects presentation from out-of-boundary IPs
+  - domain: data
+    interaction: IP-binding constraint stored as credential metadata
+  - domain: audit
+    interaction: out-of-boundary denial recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- sovereignty
+- ip-binding
+- fsi
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/017-fsi-hsm-attestation.yaml b/dav/use-cases/hammer-credentials/017-fsi-hsm-attestation.yaml
new file mode 100644
index 0000000..2d9923f
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/017-fsi-hsm-attestation.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-017
+handle: credentials/fsi-hsm-attestation
+scenario:
+  description: 'An FSI profile requires that a high-value credential be minted and held in a hardware
+    security module, and that every use be gated by an HSM attestation proving the key never left the
+    hardware boundary. The system must record the attestation requirement, verify a valid attestation
+    before permitting the interaction, and deny use if attestation is missing or stale. This tests whether
+    credential use can be gated on hardware attestation under a compliance mandate, and probes the attestation-gated
+    trust plane.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - security-officer
+  intent: Gate credential use on a valid HSM attestation
+  success_criteria:
+  - The HSM-attestation requirement is recorded as credential metadata
+  - A valid, fresh attestation is verified before each gated interaction
+  - Use is denied when attestation is missing, stale, or invalid
+  - The attestation proves the key never left the HSM boundary
+  - No secret key material is exported or stored in the model
+  - Attestation checks and any denials are recorded in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: provider_failure
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: governance matrix requires HSM attestation for credential use
+  - domain: provider
+    interaction: provider verifies attestation before honoring the credential
+  - domain: data
+    interaction: attestation requirement and results recorded as metadata
+  - domain: audit
+    interaction: attestation verification and denials recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- hsm
+- attestation
+- fsi
+- compliance
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/018-rehydration-reissue-credentials.yaml b/dav/use-cases/hammer-credentials/018-rehydration-reissue-credentials.yaml
new file mode 100644
index 0000000..d867918
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/018-rehydration-reissue-credentials.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-credentials-018
+handle: credentials/rehydration-reissue-credentials
+scenario:
+  description: 'After total destruction, the estate is rehydrated from stored intent. Because credential
+    secret values were never stored in the model (CPX-001), rehydration cannot restore the old secrets
+    — it must re-issue fresh credentials that satisfy the same intent (same scope, same bindings) and
+    re-wire every dependent to the new credential. The system must recognize that credentials are re-issued
+    rather than restored, preserve credential UUIDs and scope while the underlying secret is new, and
+    re-bind consumers. This tests whether the rehydration model correctly handles resources whose value
+    is intentionally absent.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - security-officer
+  intent: Rehydrate an estate by re-issuing credentials rather than restoring secrets
+  success_criteria:
+  - Rehydration recognizes credential secrets were never stored and cannot be restored
+  - Fresh credentials are re-issued to satisfy the original credential intent
+  - Credential UUID and scope are preserved; only the underlying secret is new
+  - All dependents are re-bound to the re-issued credentials
+  - Dependency ordering re-issues credentials before their dependents are realized
+  - The re-issue-not-restore decision is recorded in audit
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: credential intent read; secret absent by construction; UUID/scope preserved
+  - domain: policy
+    interaction: rehydration policy mandates re-issue over restore for credentials
+  - domain: provider
+    interaction: providers mint fresh secrets satisfying the original scope
+  - domain: audit
+    interaction: re-issue-not-restore arc recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- rehydration
+- reissue
+- cpx-001
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/019-brownfield-credential-ingest.yaml b/dav/use-cases/hammer-credentials/019-brownfield-credential-ingest.yaml
new file mode 100644
index 0000000..c2ff14e
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/019-brownfield-credential-ingest.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-credentials-019
+handle: credentials/brownfield-credential-ingest
+scenario:
+  description: 'A platform engineer onboards an existing estate whose providers already have credentials
+    minted out-of-band. Brownfield ingestion must discover these pre-existing credentials and record them
+    as Credential resources — capturing scope, issuer, fingerprint, and validity as metadata only — without
+    ever ingesting or storing the secret value. Credentials that cannot be characterized (unknown scope
+    or issuer) must be flagged rather than silently trusted. This tests whether the credential model can
+    absorb pre-existing secrets under the CPX-001 metadata-only invariant.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - security-officer
+  intent: Ingest pre-existing provider credentials as metadata-only records
+  success_criteria:
+  - Pre-existing credentials are discovered during brownfield ingestion
+  - Each becomes a Credential record with scope, issuer, fingerprint, and validity metadata
+  - No secret value is ingested or stored at any point
+  - Credentials with unknown scope or issuer are flagged, not silently trusted
+  - Ingested credentials are linked to the resources that depend on them
+  - The ingestion and any flags are recorded in audit
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: existing credentials recorded as metadata-only Credential resources
+  - domain: policy
+    interaction: ingestion policy flags uncharacterizable credentials
+  - domain: provider
+    interaction: provider inventory reveals the pre-existing credentials
+  - domain: audit
+    interaction: ingestion results and flags recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- brownfield
+- ingestion
+- metadata-only
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-credentials/020-credential-lifecycle-audit-trail.yaml b/dav/use-cases/hammer-credentials/020-credential-lifecycle-audit-trail.yaml
new file mode 100644
index 0000000..69508c0
--- /dev/null
+++ b/dav/use-cases/hammer-credentials/020-credential-lifecycle-audit-trail.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-credentials-020
+handle: credentials/credential-lifecycle-audit-trail
+scenario:
+  description: 'A compliance auditor requests a complete, tamper-evident history of a single credential:
+    every issuance, rotation, use-scope grant, revocation, and expiry event, with issuer and justification,
+    and never the secret value. The system must reconstruct the credential''s full lifecycle from the
+    audit domain across all phases and prove no event is missing. This tests whether credential lifecycle
+    events are consistently and completely captured for compliance review.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - security-officer
+  intent: Produce a complete tamper-evident lifecycle history for one credential
+  success_criteria:
+  - Every lifecycle event (issue, rotate, grant, revoke, expire) is present
+  - Each event records issuer, timestamp, scope change, and justification
+  - The secret value appears nowhere in the history
+  - The history is tamper-evident and independently verifiable
+  - Gaps or missing events are detectable, not silently absent
+  - The reconstructed lifecycle is itself recorded as an audit query
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: audit
+    interaction: full credential lifecycle reconstructed from recorded events
+  - domain: data
+    interaction: event references resolved without exposing secret values
+  - domain: policy
+    interaction: completeness and tamper-evidence requirements enforced
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- credentials
+- audit
+- lifecycle
+- compliance
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-day0-day2-ops/001-vm-provision-configure-patch-e2e.yaml b/dav/use-cases/hammer-day0-day2-ops/001-vm-provision-configure-patch-e2e.yaml
new file mode 100644
index 0000000..a19e768
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/001-vm-provision-configure-patch-e2e.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-day0-day2-ops-001
+handle: day0-day2-ops/vm-provision-configure-patch-e2e
+scenario:
+  description: A platform engineer requests a standard application VM and expects it carried the whole
+    way from bare provision to a patched, running host. Day 0 realizes the VM resource on the owning hypervisor
+    provider; Day 1 fires an Automation.AnsiblePlaybook bound to that VM to install the base role and
+    app runtime; Day 2 runs an Automation.Job that applies the current security patch set. The two processes
+    operate on the same realized VM — they are bound to it, not containers of it — and each run must record
+    a terminal outcome (COMPLETED) against the resource it converged.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - security-officer
+  intent: Provision a VM and carry it end to end through configuration and its first patch cycle
+  success_criteria:
+  - Day 0 realizes the VM resource and records its provider-assigned UUID
+  - The configure playbook is bound to the realized VM and runs to a COMPLETED terminal outcome
+  - The patch job is bound to the same VM UUID and does not create a new resource
+  - Each process run records a terminal outcome (COMPLETED/FAILED/CANCELLED), never a maintained state
+  - The resource-to-process bindings are represented as bound-to edges, not containment
+  - The full Day 0 -> Day 1 -> Day 2 arc is captured in the audit trail as one lineage
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: hypervisor realizes the VM, then executes the bound configure playbook and patch job
+  - domain: data
+    interaction: records the VM resource and the bound-to edges to both process runs
+  - domain: policy
+    interaction: validates the provision request and admits the Day 2 patch under the standard change
+      policy
+  - domain: audit
+    interaction: records the provision, configure, and patch as one end-to-end lineage
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- new_request
+- lifecycle
+- vm
+- bound-process
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - A hypervisor provider is eligible and healthy
+  - The configure playbook and patch job are registered as Automation entities
+  postconditions:
+  - The VM is realized, configured, and carries the current patch level
+  - Both process runs are recorded terminal against the VM
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/002-composite-workflow-3tier-ordered-update.yaml b/dav/use-cases/hammer-day0-day2-ops/002-composite-workflow-3tier-ordered-update.yaml
new file mode 100644
index 0000000..deb1285
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/002-composite-workflow-3tier-ordered-update.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-day0-day2-ops-002
+handle: day0-day2-ops/composite-workflow-3tier-ordered-update
+scenario:
+  description: 'An SRE updates a three-tier application (web, app, database) where the tiers must be touched
+    in dependency order: database last-drained first is wrong — the update must go database, then app,
+    then web to preserve compatibility. DCM itself sequences a composite Automation.Workflow across three
+    separate Automation.Job calls, one per tier, each bound to that tier''s realized resource. DCM owns
+    the ordering between the calls; each call is an atomic process against its resource. This probes whether
+    a composite process is modeled as DCM-sequenced discrete calls rather than one opaque blob.'
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+  intent: Update a 3-tier app tier-by-tier in dependency order via a DCM-sequenced composite process
+  success_criteria:
+  - DCM sequences the three per-tier job calls in dependency order (database, app, web)
+  - Each per-tier job is bound to that tier resource and runs as a discrete atomic call
+  - DCM owns the ordering between calls; ordering is not delegated to a single opaque provider job
+  - A tier update only starts after the prior tier reports a COMPLETED terminal outcome
+  - The composite workflow records an aggregate terminal outcome over its constituent calls
+  - The dependency graph among the three tiers is consulted to derive the update order
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: cross_dependency_payload
+    policy_complexity: orchestration_flow_static
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: reads the inter-tier dependency graph to derive update ordering
+  - domain: provider
+    interaction: executes each per-tier Automation.Job as a discrete bound call
+  - domain: policy
+    interaction: enforces the static orchestration flow that gates each tier on the prior one
+  - domain: audit
+    interaction: records the composite workflow and each constituent call outcome
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- composite-process
+- ordering
+- 3-tier
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The three tiers are realized and their dependency edges recorded
+  - Per-tier update jobs are registered
+  postconditions:
+  - All three tiers carry the new version
+  - The composite workflow is recorded terminal with its call sequence
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/003-rolling-os-update-node-pool-partial.yaml b/dav/use-cases/hammer-day0-day2-ops/003-rolling-os-update-node-pool-partial.yaml
new file mode 100644
index 0000000..0e70b54
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/003-rolling-os-update-node-pool-partial.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-day0-day2-ops-003
+handle: day0-day2-ops/rolling-os-update-node-pool-partial
+scenario:
+  description: 'A platform operator rolls an OS security-package update across a 12-node pool one node
+    at a time. An Automation.Job is fired per node, bound to that node resource; three nodes fail the
+    update (package conflict) while nine succeed. The system must not treat the batch as all-or-nothing:
+    the nine successful nodes stay updated and recorded, the three failures are surfaced with their per-node
+    terminal FAILED outcome, and the pool is left in a known partially-updated state rather than rolled
+    fully back.'
+  actor:
+    persona: platform-operator
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - security-officer
+  intent: Roll an OS-package update across a node pool and correctly record a partial outcome
+  success_criteria:
+  - A per-node update job is bound to each node and runs independently
+  - Nine successful node updates are retained, not reverted because siblings failed
+  - Three failed node updates record a per-node FAILED terminal outcome
+  - The pool is reported in a partially-fulfilled state with the exact success/failure split
+  - No successful node is rolled back solely because a sibling node failed
+  - The remaining un-updated nodes are identifiable for a follow-up remediation run
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: executes the per-node update job and returns per-node outcomes
+  - domain: data
+    interaction: records per-node update state and the resulting partial pool state
+  - domain: policy
+    interaction: applies the rolling-update chain (max-unavailable, health gate) per node
+  - domain: audit
+    interaction: records the partial outcome with the per-node success/failure split
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- rolling-update
+- partial
+- node-pool
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - A 12-node pool is realized and under management
+  - A per-node OS update job is registered
+  postconditions:
+  - Nine nodes updated, three flagged failed
+  - The pool is recorded partially fulfilled with a remediation set
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/004-patch-fail-midrun-rollback.yaml b/dav/use-cases/hammer-day0-day2-ops/004-patch-fail-midrun-rollback.yaml
new file mode 100644
index 0000000..9e543f6
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/004-patch-fail-midrun-rollback.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-day0-day2-ops-004
+handle: day0-day2-ops/patch-fail-midrun-rollback
+scenario:
+  description: 'A platform operator applies a kernel patch to a production database host via an Automation.Job
+    bound to that host. The job fails mid-run: the new kernel is staged but the host will not come back
+    to a healthy state. Because the resource has hard dependents (application VMs), the system must invoke
+    the recovery policy and roll the host back to its pre-patch snapshot, restoring the exact prior realized
+    state before the failed process, and mark the patch attempt FAILED without leaving the host wedged.'
+  actor:
+    persona: platform-operator
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Recover a resource to its pre-patch state when a bound patch job fails mid-run
+  success_criteria:
+  - The patch job is bound to the database host and records a FAILED terminal outcome on failure
+  - The recovery policy fires because the host has hard dependents
+  - The host is rolled back to its exact pre-patch realized state (snapshot restore)
+  - No partial/half-patched state is left as the resources recorded realized state
+  - The failed attempt is retained in history for audit, distinct from the restored state
+  - Dependent application VMs are re-validated as healthy after the rollback
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: rollback_required
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: runs the patch job, reports mid-run failure, executes the snapshot restore
+  - domain: policy
+    interaction: triggers the recovery policy and mandates rollback given hard dependents
+  - domain: data
+    interaction: restores the pre-patch realized state and preserves the failed-attempt record
+  - domain: audit
+    interaction: records the failure, the rollback decision, and the restored state
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- rollback
+- recovery
+- patch
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - A pre-patch snapshot of the host exists
+  - The host has hard dependents recorded
+  postconditions:
+  - The host is restored to its pre-patch state
+  - The failed patch attempt is auditable, dependents healthy
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/005-upgrade-job-exceeds-deadline-timeout.yaml b/dav/use-cases/hammer-day0-day2-ops/005-upgrade-job-exceeds-deadline-timeout.yaml
new file mode 100644
index 0000000..013a87b
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/005-upgrade-job-exceeds-deadline-timeout.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-day0-day2-ops-005
+handle: day0-day2-ops/upgrade-job-exceeds-deadline-timeout
+scenario:
+  description: 'An SRE launches a major in-place upgrade of a large storage appliance as a long-running
+    Automation.Job bound to that appliance, with a hard maintenance-window deadline. The job runs past
+    the deadline without reaching a terminal outcome. The system must enforce the deadline: cancel/time-out
+    the process, record a terminal TIMEOUT rather than leaving it RUNNING forever, and flag the appliance
+    as in an indeterminate upgrade state needing operator inspection before any retry.'
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+  intent: Enforce a deadline on a long-running upgrade job and record a terminal timeout
+  success_criteria:
+  - The upgrade job is bound to the appliance and carries an explicit deadline
+  - When the deadline passes with no terminal outcome, the process is timed out
+  - The process records a terminal TIMEOUT/CANCELLED outcome, never an eternal RUNNING
+  - The appliance is flagged as in an indeterminate upgrade state pending inspection
+  - No automatic retry fires until an operator clears the indeterminate flag
+  - The deadline breach and forced termination are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: timeout
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: runs the upgrade job and is signalled to cancel on deadline breach
+  - domain: policy
+    interaction: enforces the maintenance-window deadline and the no-auto-retry gate
+  - domain: data
+    interaction: records the terminal timeout and the indeterminate appliance state
+  - domain: audit
+    interaction: records the deadline breach and forced termination
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- timeout
+- deadline
+- upgrade
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - A maintenance window with a hard deadline is set
+  - The upgrade job is registered with that deadline
+  postconditions:
+  - The job is terminated with a TIMEOUT outcome
+  - The appliance is flagged indeterminate, retry gated
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/006-drift-remediation-ansible-reconverge.yaml b/dav/use-cases/hammer-day0-day2-ops/006-drift-remediation-ansible-reconverge.yaml
new file mode 100644
index 0000000..b6b04c8
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/006-drift-remediation-ansible-reconverge.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-day0-day2-ops-006
+handle: day0-day2-ops/drift-remediation-ansible-reconverge
+scenario:
+  description: 'Continuous drift detection finds that a managed web host has drifted from its declared
+    intent: a sysctl and a firewall rule were changed out of band. The detected drift binds an Automation.AnsiblePlaybook
+    to that host to re-converge it back to declared intent. The playbook runs to a COMPLETED terminal
+    outcome and the host''s realized state is re-reconciled to match intent — the process operates on
+    the resource, it does not replace or contain it.'
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+    - security-officer
+  intent: Re-converge a drifted resource to declared intent via a bound remediation playbook
+  success_criteria:
+  - Drift is detected as a delta between declared intent and realized state
+  - A remediation Automation.AnsiblePlaybook is bound to the drifted host
+  - The playbook runs to a COMPLETED terminal outcome
+  - Post-run realized state matches declared intent (drift closed)
+  - The remediation operates on the existing resource; no new resource is created
+  - The drift event and its remediation are linked in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: computes the intent-vs-realized delta and reconciles realized state after remediation
+  - domain: policy
+    interaction: selects the recovery/remediation policy for the detected drift
+  - domain: provider
+    interaction: runs the bound re-converge playbook against the host
+  - domain: audit
+    interaction: links the drift detection event to its remediation run
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- drift_detection
+- remediation
+- reconverge
+- ansible
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The host has a declared intent baseline
+  - A drift-remediation playbook is registered
+  postconditions:
+  - The host realized state matches intent again
+  - Drift event and remediation are linked in audit
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/007-backup-then-restore-rehydration-faithful.yaml b/dav/use-cases/hammer-day0-day2-ops/007-backup-then-restore-rehydration-faithful.yaml
new file mode 100644
index 0000000..49e550e
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/007-backup-then-restore-rehydration-faithful.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-day0-day2-ops-007
+handle: day0-day2-ops/backup-then-restore-rehydration-faithful
+scenario:
+  description: 'An SRE takes a scheduled backup of a stateful FSI database via an Automation.Job bound
+    to that database, producing a restore point. Later the database is corrupted, and a restore process
+    rehydrates it faithfully from that backup — same identity, same provider, byte-faithful state as of
+    the restore point. This is a two-process arc: the backup process produces the artifact the restore
+    process consumes, both bound to the same resource identity.'
+  actor:
+    persona: sre
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - compliance-auditor
+  intent: Back up a stateful resource and later faithfully rehydrate it from that backup
+  success_criteria:
+  - The backup job is bound to the database and produces a referenceable restore point
+  - The restore process consumes exactly that restore-point artifact
+  - 'Rehydration is faithful: same resource identity and same owning provider'
+  - The rehydrated state matches the backup as of the restore-point timestamp
+  - Backup and restore are recorded as two bound processes over one resource identity
+  - The chain of custody from backup artifact to restore is auditable
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: provider
+    interaction: runs the backup job and later the faithful restore against the same database
+  - domain: data
+    interaction: records the restore point and re-establishes the rehydrated realized state
+  - domain: policy
+    interaction: enforces the FSI backup/restore policy chain (retention, integrity check)
+  - domain: audit
+    interaction: records the backup artifact chain of custody through to restore
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- rehydration_faithful
+- backup
+- restore
+- fsi
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - A backup schedule and restore-point store exist
+  - The database identity is stable across the arc
+  postconditions:
+  - A restore point is produced and later consumed
+  - The database is faithfully rehydrated and auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/008-scale-out-add-members-resource-exhaustion.yaml b/dav/use-cases/hammer-day0-day2-ops/008-scale-out-add-members-resource-exhaustion.yaml
new file mode 100644
index 0000000..8bfb4a9
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/008-scale-out-add-members-resource-exhaustion.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-day0-day2-ops-008
+handle: day0-day2-ops/scale-out-add-members-resource-exhaustion
+scenario:
+  description: An application team scales out a composite service by adding four worker constituents;
+    each new worker must be provisioned and then configured by a bound Automation.Job before it joins
+    the service. Two workers provision, but the provider runs out of capacity for the remaining two —
+    resource_exhaustion. The service must integrate the two configured workers, surface the two that could
+    not be placed, and not falsely report the new members as ready when their configure process never
+    ran.
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - sre
+    - provider-owner
+  intent: Scale out a composite by adding and configuring new members, handling capacity exhaustion
+  success_criteria:
+  - Each new worker is provisioned then configured by a bound Automation.Job before joining
+  - A member is only reported ready after its configure process reaches COMPLETED
+  - The two placed-and-configured workers join the composite
+  - The two unplaced workers are surfaced as resource_exhaustion, not silently dropped
+  - No unconfigured worker is falsely counted as an active member
+  - The composite records its new constituent set and the shortfall
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: resource_exhaustion
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: provisions new workers until capacity is exhausted, runs configure jobs on the placed
+      ones
+  - domain: policy
+    interaction: enforces the cross-domain constraint that gates membership on successful configure
+  - domain: data
+    interaction: updates the composite constituent set and records the placement shortfall
+  - domain: audit
+    interaction: records the scale-out attempt, exhaustion, and final member set
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- scale-out
+- resource_exhaustion
+- composite
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The composite service is realized and scalable
+  - A member-configure job is registered
+  postconditions:
+  - Two members added and configured
+  - Two flagged unplaced; composite reports the shortfall
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/009-day2-update-approval-ladder-escalation.yaml b/dav/use-cases/hammer-day0-day2-ops/009-day2-update-approval-ladder-escalation.yaml
new file mode 100644
index 0000000..0d5699c
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/009-day2-update-approval-ladder-escalation.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-day0-day2-ops-009
+handle: day0-day2-ops/day2-update-approval-ladder-escalation
+scenario:
+  description: 'A platform operator requests a day-2 configuration update to a production FSI payments
+    service. Because the change touches a compliance-gated resource, it cannot proceed on the operator''s
+    authority alone: the policy requires a human approval ladder (operator -> change-manager -> security-officer)
+    before the bound Automation.Job may run. The system must hold the process at the gate, request the
+    escalating approvals, and only dispatch the update once all rungs approve.'
+  actor:
+    persona: platform-operator
+    profile: fsi
+  perspectives:
+    - security-officer
+  intent: Gate a day-2 update behind a human approval ladder before the bound process runs
+  success_criteria:
+  - The update is recognized as touching a compliance-gated resource
+  - The bound update job is held at the gate and not dispatched on operator authority alone
+  - A human approval ladder (operator, change-manager, security-officer) is required
+  - The process only dispatches after every ladder rung approves
+  - A rejection at any rung stops the update and records who rejected and why
+  - Each approval and the final dispatch decision are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: enforces the human approval ladder before allowing dispatch
+  - domain: audit
+    interaction: records each approval rung and the final gate decision
+  - domain: provider
+    interaction: dispatches the update job only after full approval
+  - domain: data
+    interaction: records the held-then-approved process state against the resource
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- approval-ladder
+- escalation
+- compliance
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The resource is marked compliance-gated
+  - An approval ladder policy is configured
+  postconditions:
+  - The update runs only after all approvals
+  - Every approval and the dispatch are auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/010-awx-workflow-atomic-opaque-call.yaml b/dav/use-cases/hammer-day0-day2-ops/010-awx-workflow-atomic-opaque-call.yaml
new file mode 100644
index 0000000..45a284b
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/010-awx-workflow-atomic-opaque-call.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-day0-day2-ops-010
+handle: day0-day2-ops/awx-workflow-atomic-opaque-call
+scenario:
+  description: 'A platform engineer triggers a day-2 reconfiguration that the provider implements as an
+    AWX workflow of many internal jobs. From DCM''s view this is ONE atomic Automation.Workflow call bound
+    to the target resource: DCM dispatches it, waits, and receives a single terminal outcome. DCM does
+    not sequence or see the internal jobs — the internal fan-out is opaque and owned by the provider.
+    This is the atomic-vs-composite boundary: opaque provider orchestration is one call, not a DCM-sequenced
+    composite.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Invoke a provider AWX workflow as a single opaque atomic process call
+  success_criteria:
+  - DCM dispatches the AWX workflow as one atomic Automation.Workflow call
+  - DCM receives a single terminal outcome for the whole call
+  - The provider's internal jobs are opaque to DCM and not individually sequenced by DCM
+  - DCM does not model or gate the internal fan-out steps
+  - The single call is bound to the target resource it operates on
+  - The atomic call outcome is recorded against the resource in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: runs the AWX workflow internally and returns one terminal outcome
+  - domain: data
+    interaction: records the single atomic call bound to the resource
+  - domain: policy
+    interaction: validates the single day-2 call against the standard change policy
+  - domain: audit
+    interaction: records the atomic call and its terminal outcome
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- atomic-process
+- opaque
+- awx
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The AWX workflow is registered as a single Automation entity
+  - The target resource is realized
+  postconditions:
+  - The workflow runs as one opaque call
+  - DCM records a single terminal outcome, no internal steps
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/011-cert-credential-rotation-day2.yaml b/dav/use-cases/hammer-day0-day2-ops/011-cert-credential-rotation-day2.yaml
new file mode 100644
index 0000000..23b4454
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/011-cert-credential-rotation-day2.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-day0-day2-ops-011
+handle: day0-day2-ops/cert-credential-rotation-day2
+scenario:
+  description: A security officer rotates the TLS certificate and service credential on a running FSI
+    API gateway without downtime. A day-2 Automation.Job bound to the gateway installs the new cert/credential
+    and reloads the service in place. The gateway resource identity is unchanged — the process operates
+    on the running resource; the multi-policy chain enforces validity dating, key strength, and that the
+    old credential is revoked only after the new one is confirmed live.
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives: []
+  intent: Rotate a running resource cert/credential in place via a bound day-2 process
+  success_criteria:
+  - The rotation job is bound to the running gateway and runs in place
+  - The gateway resource identity is unchanged by the rotation
+  - The new certificate/credential is validated (validity dates, key strength) before install
+  - The old credential is revoked only after the new one is confirmed live
+  - The rotation runs to a COMPLETED terminal outcome with no service replacement
+  - The rotation and revocation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: enforces the cert/credential validity and revoke-after-confirm policy chain
+  - domain: provider
+    interaction: runs the in-place rotation and service reload on the gateway
+  - domain: data
+    interaction: records the new credential binding against the unchanged resource identity
+  - domain: audit
+    interaction: records the rotation and the post-confirm revocation
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- rotation
+- credentials
+- fsi
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The gateway is running and manageable in place
+  - A new cert/credential source is available
+  postconditions:
+  - The gateway carries the new cert/credential
+  - The old credential is revoked and the rotation auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/012-firmware-update-baremetal-provider-failure.yaml b/dav/use-cases/hammer-day0-day2-ops/012-firmware-update-baremetal-provider-failure.yaml
new file mode 100644
index 0000000..710deca
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/012-firmware-update-baremetal-provider-failure.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-day0-day2-ops-012
+handle: day0-day2-ops/firmware-update-baremetal-provider-failure
+scenario:
+  description: A platform engineer schedules a BIOS/BMC firmware update on a bare-metal host inside a
+    maintenance window, run as an Automation.Job bound to that host. The provider fails mid-flash — the
+    flash aborts and the host is in a fragile firmware state. The system must treat this as a provider_failure,
+    invoke recovery (fall back to the backup firmware bank / retry the flash), keep the host cordoned
+    inside the window, and not report the update succeeded while the host is unhealthy.
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Update bare-metal firmware in a window and recover from a mid-flash provider failure
+  success_criteria:
+  - The firmware job is bound to the bare-metal host and runs only inside the maintenance window
+  - A mid-flash provider failure is recorded as a provider_failure, not a success
+  - 'Recovery fires: fall back to the backup firmware bank or retry the flash'
+  - The host stays cordoned until it returns to a healthy firmware state
+  - No success is reported while the host firmware state is fragile/unverified
+  - The failure and recovery actions are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: runs the firmware flash, reports mid-flash failure, executes bank fallback/retry
+  - domain: policy
+    interaction: confines the job to the window and mandates recovery on provider failure
+  - domain: data
+    interaction: records the fragile firmware state and the recovered state
+  - domain: audit
+    interaction: records the provider failure and the recovery actions
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- firmware
+- provider_failure
+- recovery
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - A maintenance window is scheduled and the host cordoned
+  - A backup firmware bank exists
+  postconditions:
+  - The host recovers to a healthy firmware state
+  - The failure and recovery are fully auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/013-ttl-expiry-triggers-decommission-process.yaml b/dav/use-cases/hammer-day0-day2-ops/013-ttl-expiry-triggers-decommission-process.yaml
new file mode 100644
index 0000000..74c8f6e
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/013-ttl-expiry-triggers-decommission-process.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-day0-day2-ops-013
+handle: day0-day2-ops/ttl-expiry-triggers-decommission-process
+scenario:
+  description: A finance analyst set a 14-day TTL on a set of dev sandbox VMs to cap spend. At expiry,
+    the system must autonomously enforce the TTL by firing a decommission Automation.Job bound to each
+    expired VM — the expiry policy triggers a bound teardown process, it does not merely flag the resource.
+    The process runs to a terminal outcome, the realized state is cleared, and the intent is marked expired,
+    closing the cost exposure without a human ticket.
+  actor:
+    persona: finance-analyst
+    profile: dev
+  perspectives:
+    - security-officer
+  intent: Enforce a resource TTL at expiry by firing a bound decommission process
+  success_criteria:
+  - At TTL expiry the policy autonomously fires a decommission job bound to each expired VM
+  - Expiry triggers a bound teardown process, not merely a flag on the resource
+  - Each decommission process runs to a terminal outcome (COMPLETED)
+  - Realized state for the expired VMs is cleared and intent marked expired
+  - The cost exposure is closed without a manual ticket
+  - The expiry trigger and the teardown are linked in the audit trail
+  dimensions:
+    lifecycle_phase: expiry_enforcement
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: policy
+    interaction: evaluates the TTL and fires the expiry-enforcement decommission trigger
+  - domain: provider
+    interaction: runs the bound decommission job on each expired VM
+  - domain: data
+    interaction: clears realized state and marks intent expired
+  - domain: audit
+    interaction: links the expiry trigger to each teardown outcome
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- expiry_enforcement
+- ttl
+- decommission
+- cost
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - Dev VMs carry a 14-day TTL
+  - A decommission job is registered
+  postconditions:
+  - Expired VMs are torn down at TTL
+  - Intent marked expired and the arc auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/014-config-bundle-layer-consumed-policy-violation.yaml b/dav/use-cases/hammer-day0-day2-ops/014-config-bundle-layer-consumed-policy-violation.yaml
new file mode 100644
index 0000000..a665b06
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/014-config-bundle-layer-consumed-policy-violation.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-day0-day2-ops-014
+handle: day0-day2-ops/config-bundle-layer-consumed-policy-violation
+scenario:
+  description: A platform engineer applies a shared configuration bundle as a layer that a day-2 Automation.Job
+    consumes to configure a fleet of app hosts. One setting in the bundle (an open SSH cipher) violates
+    the platform hardening policy. The system must evaluate the bundle-plus-process against policy before
+    the process runs, reject the run as a policy_violation, and identify the offending setting — the process
+    must not partially apply a non-compliant bundle to the bound resources.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Apply a config bundle via a consuming process, blocked when the bundle violates policy
+  success_criteria:
+  - The configuration bundle is modeled as a layer the process consumes, distinct from the process
+  - The bundle-plus-process is evaluated against policy before the process runs
+  - The run is rejected as a policy_violation when the bundle breaches hardening policy
+  - The specific offending setting is identified in the rejection
+  - No partial application of the non-compliant bundle to the bound hosts occurs
+  - The rejected run and the violated policy are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: evaluates the config bundle against hardening policy and rejects the violating setting
+  - domain: data
+    interaction: represents the bundle as a consumed layer bound to the process and target hosts
+  - domain: provider
+    interaction: is prevented from running the process until the bundle passes policy
+  - domain: audit
+    interaction: records the policy violation and the blocked run
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- config-bundle
+- policy_violation
+- layer
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - A shared config bundle and a consuming job are registered
+  - A hardening policy is in force
+  postconditions:
+  - The non-compliant run is blocked
+  - The offending setting and violated policy are auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/015-container-workload-provision-configure-image-update.yaml b/dav/use-cases/hammer-day0-day2-ops/015-container-workload-provision-configure-image-update.yaml
new file mode 100644
index 0000000..0764514
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/015-container-workload-provision-configure-image-update.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-day0-day2-ops-015
+handle: day0-day2-ops/container-workload-provision-configure-image-update
+scenario:
+  description: 'A tenant admin deploys a containerized workload: Day 0 realizes the workload resource
+    on a Kubernetes provider; Day 1 an Automation.Job bound to it applies config (secrets, env, connection
+    strings); Day 2 an image-update process rolls the workload to a new container image tag. All three
+    touch the same workload identity — the image-update process operates on the running workload, it does
+    not re-provision it — and each step records a terminal outcome against the resource.'
+  actor:
+    persona: tenant-admin
+    profile: dev
+  perspectives:
+    - security-officer
+    - tenancy-authority
+  intent: Provision, configure, then image-update a container workload as one bound lifecycle
+  success_criteria:
+  - Day 0 realizes the container workload on the Kubernetes provider
+  - Day 1 configure job is bound to the workload and reaches a COMPLETED outcome
+  - Day 2 image-update process rolls the same workload identity to the new image tag
+  - The image update operates on the running workload; it does not re-provision it
+  - Each of the three steps records a terminal outcome against the workload
+  - The provision -> configure -> image-update arc is one auditable lineage
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: provider
+    interaction: realizes the workload, runs the configure job, then the image-update roll
+  - domain: data
+    interaction: records the workload identity and its bound configure/update process runs
+  - domain: policy
+    interaction: admits each step under the static day-0/1/2 orchestration flow
+  - domain: audit
+    interaction: records the three steps as one workload lineage
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- new_request
+- container
+- image-update
+- lifecycle
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - A Kubernetes provider is eligible
+  - Configure and image-update jobs are registered
+  postconditions:
+  - The workload is realized, configured, and on the new image
+  - All three steps are terminal and auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/016-cross-provider-update-data-inconsistency.yaml b/dav/use-cases/hammer-day0-day2-ops/016-cross-provider-update-data-inconsistency.yaml
new file mode 100644
index 0000000..272f6d5
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/016-cross-provider-update-data-inconsistency.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-day0-day2-ops-016
+handle: day0-day2-ops/cross-provider-update-data-inconsistency
+scenario:
+  description: An SRE updates a composite service whose constituents span the local DCM and a peer DCM
+    in another sovereign domain. The local calls report COMPLETED, but the peer DCM's realized state for
+    its constituents diverges from what the local record believes — a data_inconsistency between the two
+    authorities. The system must detect the divergence, refuse to declare the composite updated, and quarantine
+    the inconsistent constituents for reconciliation rather than trusting the stale local view.
+  actor:
+    persona: sre
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Update a cross-domain composite and correctly handle divergent realized state across DCMs
+  success_criteria:
+  - The composite update spans local DCM and a peer DCM in another domain
+  - Divergence between local record and the peer DCM's realized state is detected
+  - The composite is NOT declared updated while a data_inconsistency stands
+  - Inconsistent constituents are quarantined for reconciliation, not trusted from the stale local view
+  - The authoritative source for each constituent is honored (peer owns its realized state)
+  - The detected inconsistency and quarantine are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: cross_dependency_payload
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: issues update calls across local and peer DCM constituents
+  - domain: data
+    interaction: detects realized-state divergence and quarantines inconsistent constituents
+  - domain: policy
+    interaction: enforces the peer-authority and sovereignty reconciliation policy chain
+  - domain: audit
+    interaction: records the divergence detection and quarantine decision
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- peer-dcm
+- data_inconsistency
+- sovereign
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The composite spans a local and a peer DCM
+  - Peer connectivity and authority mapping exist
+  postconditions:
+  - The composite is held un-updated pending reconciliation
+  - Divergent constituents are quarantined and auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/017-composite-decommission-partial-rollback.yaml b/dav/use-cases/hammer-day0-day2-ops/017-composite-decommission-partial-rollback.yaml
new file mode 100644
index 0000000..9369df3
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/017-composite-decommission-partial-rollback.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-day0-day2-ops-017
+handle: day0-day2-ops/composite-decommission-partial-rollback
+scenario:
+  description: 'An application team decommissions a composite service at end of life via a DCM-sequenced
+    composite process that tears the constituents down in reverse-dependency order. The teardown of the
+    shared datastore constituent fails partway — its dependents are already gone but it will not delete
+    cleanly. The system must invoke rollback: because a clean teardown cannot complete, it must restore
+    the already-removed constituents to their prior state so the composite is left whole (not half-destroyed)
+    pending manual resolution.'
+  actor:
+    persona: application-team-member
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Decommission a composite in reverse-dependency order and roll back a partial teardown failure
+  success_criteria:
+  - The composite decommission is sequenced in reverse-dependency order across bound teardown calls
+  - A failure of the datastore teardown records a FAILED terminal outcome for that call
+  - 'Rollback fires: already-removed constituents are restored to their prior state'
+  - The composite is left whole (not half-destroyed) pending manual resolution
+  - No constituent is left orphaned or stranded by the partial teardown
+  - The partial teardown and the rollback are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: rollback_required
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: reads the dependency graph for reverse order and restores removed constituents on rollback
+  - domain: provider
+    interaction: executes each bound teardown call and reports the datastore failure
+  - domain: policy
+    interaction: mandates rollback when a composite teardown cannot complete cleanly
+  - domain: audit
+    interaction: records the partial teardown and the rollback to a whole composite
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- decommission
+- composite-process
+- rollback
+- teardown
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The composite and its internal dependency graph are recorded
+  - Per-constituent teardown calls exist
+  postconditions:
+  - The composite is restored whole after the partial failure
+  - The failure and rollback are auditable
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-day0-day2-ops/018-sovereign-airgap-patch-attest.yaml b/dav/use-cases/hammer-day0-day2-ops/018-sovereign-airgap-patch-attest.yaml
new file mode 100644
index 0000000..c62f29e
--- /dev/null
+++ b/dav/use-cases/hammer-day0-day2-ops/018-sovereign-airgap-patch-attest.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-day0-day2-ops-018
+handle: day0-day2-ops/sovereign-airgap-patch-attest
+scenario:
+  description: 'A security officer applies a day-2 security patch to workloads in an air-gapped sovereign
+    enclave. There is no outbound network: a signed patch bundle is imported across the boundary, its
+    signature and provenance verified, then an Automation.Job bound to the target workloads applies it
+    entirely in-boundary. A governance matrix enforces which roles may import, verify, and apply, and
+    every step must be attested so the whole patch is provably in-boundary and authorized.'
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Apply an imported signed patch inside an air-gapped enclave under governance-matrix control
+  success_criteria:
+  - The signed patch bundle is imported across the boundary and its signature/provenance verified before
+    use
+  - The patch job runs entirely in-boundary with no outbound network dependency
+  - A governance matrix enforces distinct roles for import, verify, and apply
+  - The patch job is bound to the target workloads and reaches a terminal outcome
+  - Every step is attested so the patch is provably in-boundary and authorized
+  - The import, verification, apply, and attestation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: enforces the governance matrix over import/verify/apply roles and in-boundary constraint
+  - domain: audit
+    interaction: attests and records every step of the in-boundary patch
+  - domain: provider
+    interaction: applies the verified patch bundle in-boundary to the bound workloads
+  - domain: data
+    interaction: records the verified bundle and its binding to the target workloads
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: day0-day2-ops-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- day0-day2
+- modification
+- sovereign
+- air-gap
+- attestation
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-day0-day2-ops
+  preconditions:
+  - The enclave is air-gapped with a controlled import path
+  - A signed patch bundle and governance matrix exist
+  postconditions:
+  - The patch is applied in-boundary and attested
+  - The full arc is auditable within the enclave
+  note: batch=day0-day2-ops-2026-07-22
diff --git a/dav/use-cases/hammer-decommission/001-leaf-resource-clean-teardown.yaml b/dav/use-cases/hammer-decommission/001-leaf-resource-clean-teardown.yaml
new file mode 100644
index 0000000..a6560bb
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/001-leaf-resource-clean-teardown.yaml
@@ -0,0 +1,53 @@
+uuid: uc-hammer-decommission-001
+handle: decommission/leaf-resource-clean-teardown
+scenario:
+  description: 'A platform engineer decommissions a single realized resource that nothing else depends
+    on — a scratch VM at the end of a sprint. The system must confirm the resource has no dependents,
+    dispatch a destroy to the owning provider, clear the realized state, and mark the intent retired.
+    This is the baseline decommission path that every harder case builds on: no cascade, no compensation,
+    just a clean single-resource teardown recorded end to end.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: dev
+  perspectives: []
+  intent: Decommission an unshared leaf resource and confirm clean teardown
+  success_criteria:
+  - Dependency check confirms the resource has zero dependents before teardown begins
+  - Destroy is dispatched to the owning provider and acknowledged
+  - Realized state for the resource is cleared
+  - Intent is marked retired (not deleted) so the decommission remains auditable
+  - Resource UUID is not reassigned to any new resource
+  - The full decommission arc is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph queried, realized state cleared, intent marked retired
+  - domain: provider
+    interaction: destroy dispatched to owning provider and acknowledged
+  - domain: audit
+    interaction: decommission decision and completion recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- teardown
+- leaf
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/002-dangling-dependents-block-or-cascade.yaml b/dav/use-cases/hammer-decommission/002-dangling-dependents-block-or-cascade.yaml
new file mode 100644
index 0000000..246cef7
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/002-dangling-dependents-block-or-cascade.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-decommission-002
+handle: decommission/dangling-dependents-block-or-cascade
+scenario:
+  description: 'An application team requests decommission of a database that three running services still
+    depend on. The system must NOT silently destroy the database and strand its dependents. It must either
+    refuse the decommission and surface the dangling dependents, or offer an explicit cascade that tears
+    the dependents down first in reverse-dependency order. This probes whether the data model''s dependency
+    graph is consulted as a hard gate on destroy, not just on create.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Decommission a resource that still has live dependents
+  success_criteria:
+  - System detects the three dependent services from the dependency graph before any destroy
+  - Naive destroy of the depended-on resource is blocked
+  - Either the request is refused with the dangling dependents named, or an explicit cascade is offered
+  - No dependent is left referencing a destroyed resource (no stranded state)
+  - The block/cascade decision and its rationale are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: reverse-dependency edges queried to find live dependents
+  - domain: policy
+    interaction: destroy-with-dependents constraint evaluated as a hard gate
+  - domain: audit
+    interaction: block-or-cascade decision recorded with the dependents named
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- dependency-safety
+- cascade
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/003-reverse-dependency-order-teardown.yaml b/dav/use-cases/hammer-decommission/003-reverse-dependency-order-teardown.yaml
new file mode 100644
index 0000000..bed6045
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/003-reverse-dependency-order-teardown.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-decommission-003
+handle: decommission/reverse-dependency-order-teardown
+scenario:
+  description: 'A platform engineer decommissions a full three-tier stack — web tier, app tier, database,
+    and the network and storage they sit on. The system must derive the teardown order dynamically as
+    the reverse of the build dependency graph: dependents first, foundations last, so nothing is destroyed
+    while something still references it. This is the mirror of dynamic rehydration and proves the dependency
+    graph drives destroy ordering, not a recorded build log.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Tear down a full stack in correct reverse-dependency order
+  success_criteria:
+  - Teardown order is computed dynamically as the reverse of the build dependency graph
+  - No resource is destroyed while another resource still depends on it
+  - Each tier's destroy is dispatched to its owning provider and acknowledged in order
+  - Realized state is cleared tier by tier as each destroy confirms
+  - Foundational resources (network, storage) are destroyed only after all consumers are gone
+  - The ordered teardown arc is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph read and reversed to compute teardown order
+  - domain: provider
+    interaction: each tier destroyed by its owning provider in reverse order
+  - domain: audit
+    interaction: ordered teardown sequence recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- reverse-order
+- full-stack
+- orchestration
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/004-shareable-pool-active-stakes-blocked.yaml b/dav/use-cases/hammer-decommission/004-shareable-pool-active-stakes-blocked.yaml
new file mode 100644
index 0000000..f6e5013
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/004-shareable-pool-active-stakes-blocked.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-decommission-004
+handle: decommission/shareable-pool-active-stakes-blocked
+scenario:
+  description: 'A storage admin tries to decommission a shared ZFS pool that three tenants still hold
+    active allocations against. Because the pool is a shareable resource with outstanding stakes, the
+    system must refuse the teardown while any stake is live and surface which stakeholders block it. This
+    probes whether the architecture models allocations as first-class stakes on a shared pool, so a pool
+    cannot be destroyed out from under its consumers.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - tenancy-authority
+  intent: Decommission a shared pool that still has active allocations against it
+  success_criteria:
+  - System enumerates all active stakes/allocations held against the pool
+  - Teardown is refused while any stake remains live
+  - The blocking stakeholders are named in the refusal
+  - No allocation is silently invalidated or orphaned
+  - The refusal and the list of live stakes are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: active allocations against the shared pool enumerated as stakes
+  - domain: policy
+    interaction: shared-resource-with-live-stakes constraint blocks the teardown
+  - domain: audit
+    interaction: refusal recorded with blocking stakeholders named
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- shared-pool
+- stakes
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/005-crypto-shred-kek-destroy.yaml b/dav/use-cases/hammer-decommission/005-crypto-shred-kek-destroy.yaml
new file mode 100644
index 0000000..6841232
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/005-crypto-shred-kek-destroy.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-decommission-005
+handle: decommission/crypto-shred-kek-destroy
+scenario:
+  description: 'A security officer decommissions a departing tenant by crypto-shredding: the tenant''s
+    data volumes are encrypted under a per-tenant key-encryption-key (KEK), and destroying the KEK renders
+    every ciphertext permanently unrecoverable in one irreversible act. The system must treat the KEK
+    as a dependency root — every volume it protects becomes a dependent — refuse to shred while any volume
+    is still mounted or under legal hold, and record the shred as terminal. This probes whether the architecture
+    models a key as a resource whose destruction cascades meaning to its dependents, and whether it can
+    express irreversibility. It may well come back partially supported or unsupported.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Crypto-shred a tenant by destroying its KEK and rendering all data unrecoverable
+  success_criteria:
+  - KEK is modeled as a resource with the tenant's encrypted volumes as dependents
+  - Every volume protected by the KEK is enumerated before the shred
+  - Shred is refused if any protected volume is still mounted or under active legal hold
+  - Destroying the KEK is recorded as terminal and irreversible (no rehydration path)
+  - After the shred, all dependent ciphertext is marked permanently unrecoverable in the data model
+  - The irreversible destruction is captured in the audit trail with the officer's authorization
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: KEK-to-volume dependency resolved, protected ciphertext marked unrecoverable
+  - domain: policy
+    interaction: mount and legal-hold guards evaluated before permitting an irreversible shred
+  - domain: provider
+    interaction: KMS provider destroys the key material terminally
+  - domain: audit
+    interaction: irreversible crypto-shred recorded with authorization
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- crypto-shred
+- kek
+- irreversible
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/006-credential-unrevocable-compensation.yaml b/dav/use-cases/hammer-decommission/006-credential-unrevocable-compensation.yaml
new file mode 100644
index 0000000..8c34df9
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/006-credential-unrevocable-compensation.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-decommission-006
+handle: decommission/credential-unrevocable-compensation
+scenario:
+  description: 'A tenant-admin decommissions a service whose teardown requires revoking a credential the
+    service was issued — but the identity provider that minted it is unreachable, so the revocation cannot
+    be confirmed. The system must not report a clean decommission with a live credential still floating.
+    It must enter COMPENSATION_IN_PROGRESS: hold the decommission open, mark the credential as revocation-pending,
+    retry or escalate, and only close when the credential is provably dead. This probes whether decommission
+    is transactional with a compensation state, not a fire-and-forget delete.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - security-officer
+  intent: Decommission a service whose credential revocation cannot be confirmed
+  success_criteria:
+  - Teardown reaches the credential-revocation step and the IdP call fails or times out
+  - The decommission does NOT close as successful with an unrevoked credential
+  - State transitions to COMPENSATION_IN_PROGRESS and the credential is marked revocation-pending
+  - Revocation is retried or escalated to a human per the recovery policy
+  - Decommission closes only after the credential is provably revoked; otherwise it stays open
+  - The compensation state and every retry are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: identity provider unreachable, credential revocation cannot be confirmed
+  - domain: policy
+    interaction: recovery policy drives COMPENSATION_IN_PROGRESS with retry/escalate
+  - domain: data
+    interaction: credential marked revocation-pending, decommission held open
+  - domain: audit
+    interaction: compensation state and retries recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- credential-revocation
+- compensation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/007-composite-constituent-order.yaml b/dav/use-cases/hammer-decommission/007-composite-constituent-order.yaml
new file mode 100644
index 0000000..3971c77
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/007-composite-constituent-order.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-decommission-007
+handle: decommission/composite-constituent-order
+scenario:
+  description: 'An application team decommissions a composite service — a managed message-broker cluster
+    that is a single logical resource made of a coordinator, three brokers, and a shared config store.
+    The system must decompose the composite into its constituents and tear them down in the correct internal
+    order (brokers before coordinator, coordinator before config store), then retire the composite handle
+    only once all constituents are gone. This probes whether a composite service carries its own internal
+    teardown ordering distinct from external dependencies.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives: []
+  intent: Decommission a composite service and tear its constituents down in the right internal order
+  success_criteria:
+  - The composite is decomposed into its declared constituents
+  - Constituents are torn down in the composite's internal reverse order (brokers, coordinator, config
+    store)
+  - No constituent is destroyed while another constituent still depends on it
+  - The composite handle is retired only after every constituent is destroyed
+  - Realized state is cleared for each constituent and for the composite
+  - The constituent teardown order is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: composite decomposed into constituents, internal order resolved
+  - domain: provider
+    interaction: constituents destroyed in order by the owning provider
+  - domain: audit
+    interaction: constituent teardown sequence recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- composite
+- constituent-order
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/008-free-allocation-back-to-pool.yaml b/dav/use-cases/hammer-decommission/008-free-allocation-back-to-pool.yaml
new file mode 100644
index 0000000..b4a1568
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/008-free-allocation-back-to-pool.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-decommission-008
+handle: decommission/free-allocation-back-to-pool
+scenario:
+  description: 'A finance-conscious platform engineer decommissions a VM that holds a 200 GB allocation
+    carved out of a shared storage pool. The teardown must not just destroy the VM — it must release the
+    allocation back to the pool so the pool''s free capacity increases by exactly 200 GB and the allocation
+    stake is removed. This is the inverse of an allocation request and probes whether decommission correctly
+    reverses resource accounting rather than leaking capacity.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+    - security-officer
+  intent: Decommission a resource and return its allocation to the shared pool
+  success_criteria:
+  - The VM's 200 GB allocation stake against the pool is identified during teardown
+  - The VM is destroyed by its owning provider
+  - The allocation is released and the pool's free capacity increases by exactly 200 GB
+  - The allocation stake is removed from the pool's stake list (no leaked capacity)
+  - The freed-capacity accounting change is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: allocation stake released, pool free capacity incremented
+  - domain: provider
+    interaction: VM destroyed by owning provider
+  - domain: audit
+    interaction: capacity return accounting recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- allocation
+- pool-return
+- accounting
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/009-partial-failure-compensation.yaml b/dav/use-cases/hammer-decommission/009-partial-failure-compensation.yaml
new file mode 100644
index 0000000..f20e7fa
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/009-partial-failure-compensation.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-decommission-009
+handle: decommission/partial-failure-compensation
+scenario:
+  description: 'A platform engineer tears down a multi-resource environment; three of five resources destroy
+    cleanly, then the fourth provider call fails hard mid-teardown. The system must not leave the environment
+    in a torn, ambiguous half-state. It must halt the cascade, mark the environment COMPENSATION_IN_PROGRESS,
+    and drive a compensation policy — retry the failed destroy, and hold the already-destroyed resources
+    as terminal while the remainder is neither abandoned nor blindly forced. This probes partial-failure
+    handling and whether decommission is compensating rather than best-effort.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Handle a mid-teardown provider failure without leaving an ambiguous half-state
+  success_criteria:
+  - Three resources destroy cleanly and their realized state is cleared
+  - The fourth destroy fails and the cascade halts rather than continuing blindly
+  - Environment state transitions to COMPENSATION_IN_PROGRESS
+  - Recovery policy retries the failed destroy and does not report overall success while it is pending
+  - Already-destroyed resources are not re-created or double-destroyed on retry (idempotent compensation)
+  - The partial failure, the halt, and every compensation step are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: fourth destroy fails hard mid-cascade
+  - domain: policy
+    interaction: recovery policy halts cascade and drives compensating retry
+  - domain: data
+    interaction: environment marked COMPENSATION_IN_PROGRESS, destroyed resources held terminal
+  - domain: audit
+    interaction: partial failure and compensation steps recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- partial-failure
+- compensation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/010-audit-retention-past-decommission.yaml b/dav/use-cases/hammer-decommission/010-audit-retention-past-decommission.yaml
new file mode 100644
index 0000000..6b13aae
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/010-audit-retention-past-decommission.yaml
@@ -0,0 +1,53 @@
+uuid: uc-hammer-decommission-010
+handle: decommission/audit-retention-past-decommission
+scenario:
+  description: 'A compliance-auditor must be able to prove, years after a resource is gone, that it once
+    existed, who authorized its teardown, and when it was destroyed. When a resource is decommissioned
+    the system must retire and clear the realized state but PRESERVE the intent record and the audit trail
+    under a retention policy — the decommission destroys the resource, not its history. This probes whether
+    the architecture separates resource lifetime from record lifetime, so teardown never erases the evidence
+    of the resource having existed.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives: []
+  intent: Confirm audit and intent history survive after a resource is decommissioned
+  success_criteria:
+  - After teardown, realized state is cleared but the intent record is retained (marked retired, not deleted)
+  - The full decommission audit trail — who authorized, what was destroyed, when — is preserved
+  - Retention policy governs how long the retired intent and audit records persist
+  - The auditor can retrieve the retired resource's history after the resource itself is gone
+  - The resource UUID remains resolvable to its history and is never reused
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: realized state cleared, intent retained under retention policy
+  - domain: policy
+    interaction: retention policy governs record lifetime independent of resource lifetime
+  - domain: audit
+    interaction: full decommission history preserved and retrievable post-teardown
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- audit-retention
+- compliance
+- records
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/011-fault-domain-aware-teardown.yaml b/dav/use-cases/hammer-decommission/011-fault-domain-aware-teardown.yaml
new file mode 100644
index 0000000..db54641
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/011-fault-domain-aware-teardown.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-decommission-011
+handle: decommission/fault-domain-aware-teardown
+scenario:
+  description: 'An SRE decommissions a hyperconverged host that is simultaneously an OpenShift worker
+    node and a Ceph OSD host — the compute node and a storage fault domain share the same physical box.
+    Tearing it down naively could drop the cluster below its Ceph replication floor and take healthy data
+    with it. The system must recognize the shared fault domain, refuse or serialize the teardown until
+    Ceph reports HEALTH_OK and the OSDs are drained, and never destroy a host whose loss would breach
+    a fault-domain quorum. This probes whether the architecture models physical co-location as a teardown
+    constraint.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+  intent: Decommission a host without breaching a shared compute/storage fault domain
+  success_criteria:
+  - System recognizes the host belongs to both a compute pool and a Ceph storage fault domain
+  - Teardown is gated on Ceph reporting HEALTH_OK and the host's OSDs being drained first
+  - Decommission is refused or serialized if destroying the host would breach the replication floor
+  - The compute node is only removed after the storage fault domain is proven safe
+  - The fault-domain check and the gating decision are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: host's dual membership in compute pool and Ceph fault domain resolved
+  - domain: policy
+    interaction: fault-domain constraint gates teardown on HEALTH_OK and OSD drain
+  - domain: provider
+    interaction: storage provider drains OSDs before compute provider removes the node
+  - domain: audit
+    interaction: fault-domain gating decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- fault-domain
+- ceph
+- cross-domain
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/012-unrealized-intent-discard.yaml b/dav/use-cases/hammer-decommission/012-unrealized-intent-discard.yaml
new file mode 100644
index 0000000..608f1c9
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/012-unrealized-intent-discard.yaml
@@ -0,0 +1,50 @@
+uuid: uc-hammer-decommission-012
+handle: decommission/unrealized-intent-discard
+scenario:
+  description: 'An application team cancels a request that was submitted but never realized — the intent
+    exists in the data model but no provider ever built anything. Decommissioning it must be a pure data-model
+    operation: mark the intent retired, issue no destroy to any provider, and touch no realized state
+    (there is none). This probes whether the architecture distinguishes decommissioning a realized resource
+    from discarding an unrealized intent, without emitting a spurious provider call.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: dev
+  perspectives: []
+  intent: Discard an intent that was never realized without calling any provider
+  success_criteria:
+  - System confirms the intent has no realized state and no provider footprint
+  - The intent is marked retired without any destroy being dispatched
+  - No provider call is emitted (nothing to destroy)
+  - No realized-state store is modified because none existed
+  - The discard decision and rationale are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent confirmed unrealized, marked retired with no state change
+  - domain: audit
+    interaction: discard-of-unrealized-intent recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- unrealized
+- discard
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/013-idempotent-re-decommission.yaml b/dav/use-cases/hammer-decommission/013-idempotent-re-decommission.yaml
new file mode 100644
index 0000000..57fe729
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/013-idempotent-re-decommission.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-decommission-013
+handle: decommission/idempotent-re-decommission
+scenario:
+  description: 'An automation retries a decommission for a resource that was already torn down — a duplicate
+    request from a flaky pipeline. The system must recognize the resource is already gone and produce
+    a no-op: no second destroy, no error that looks like a failure, no resurrection. This is the decommission
+    mirror of idempotent reconvergence and proves teardown is safe to retry, which matters for any at-least-once
+    orchestration driving destroys.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Re-issue a decommission for an already-decommissioned resource and get a safe no-op
+  success_criteria:
+  - System detects the resource is already retired with no realized state
+  - No second destroy is dispatched to any provider
+  - The re-decommission returns a clean no-op, not a failure and not a resurrection
+  - The retired intent and its UUID remain unchanged
+  - The no-op decision and rationale are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    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: resource confirmed already retired, no state change
+  - domain: policy
+    interaction: idempotency check recognizes the destroy as already satisfied
+  - domain: audit
+    interaction: no-op re-decommission recorded with rationale
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- idempotent
+- no-op
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/014-sovereign-in-region-destruction.yaml b/dav/use-cases/hammer-decommission/014-sovereign-in-region-destruction.yaml
new file mode 100644
index 0000000..b56598c
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/014-sovereign-in-region-destruction.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-decommission-014
+handle: decommission/sovereign-in-region-destruction
+scenario:
+  description: 'Under a data-sovereignty mandate, a security-officer decommissions a resource holding
+    regulated data that by law must be destroyed inside the jurisdiction where it lived. The teardown
+    must dispatch the destroy to an in-region provider, produce a jurisdiction-scoped certificate of destruction,
+    and refuse any path that would move or process the data out of region on the way to being destroyed
+    — including a cross-border admin plane. This probes whether sovereignty constraints bind the destroy
+    path, not just the create path.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - sovereignty-authority
+  intent: Decommission regulated data with destruction proven to occur in-region
+  success_criteria:
+  - The resource's residency jurisdiction is resolved from the data model
+  - The destroy is dispatched only to an in-region provider
+  - No teardown step moves or processes the data out of its jurisdiction
+  - A jurisdiction-scoped certificate/proof of destruction is produced
+  - A destroy path that would breach residency is refused
+  - The in-region destruction and its proof are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: residency jurisdiction resolved for the resource being destroyed
+  - domain: policy
+    interaction: sovereignty constraint binds the destroy to an in-region provider
+  - domain: provider
+    interaction: in-region provider executes destroy and emits proof of destruction
+  - domain: audit
+    interaction: in-region destruction and certificate recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- sovereignty
+- residency
+- proof-of-destruction
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/015-shared-credential-peer-dcm-in-use.yaml b/dav/use-cases/hammer-decommission/015-shared-credential-peer-dcm-in-use.yaml
new file mode 100644
index 0000000..3359e28
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/015-shared-credential-peer-dcm-in-use.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-decommission-015
+handle: decommission/shared-credential-peer-dcm-in-use
+scenario:
+  description: 'A tenant-admin decommissions a service whose access credential is a federated credential
+    also relied on by a peer DCM in a partner domain. Revoking it locally would break the peer''s live
+    workloads. The system must consult the peer DCM before revoking, and when the peer is unreachable
+    it must NOT revoke unilaterally — it should hold the credential and surface that the teardown cannot
+    safely complete without peer confirmation. This probes cross-DCM coordination on destroy and likely
+    returns partially supported or unsupported when the peer link is down.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+    - compliance-auditor
+    - security-officer
+  intent: Decommission a service sharing a federated credential with a peer DCM
+  success_criteria:
+  - System identifies the credential as federated and shared with a peer DCM
+  - The peer DCM is consulted before any local revocation
+  - If the peer confirms it no longer needs the credential, revocation proceeds and teardown completes
+  - If the peer is unreachable, the credential is NOT revoked unilaterally
+  - The teardown is held with the peer-coordination gap surfaced, not silently forced
+  - The peer consultation (or its failure) is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: peer_dcm_disconnect
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: credential identified as federated and shared across DCMs
+  - domain: policy
+    interaction: cross-DCM revocation policy requires peer confirmation before destroy
+  - domain: provider
+    interaction: peer DCM consulted; unreachable peer blocks unilateral revocation
+  - domain: audit
+    interaction: peer consultation or disconnect recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- federation
+- peer-dcm
+- credential
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/016-legal-hold-blocks-decommission.yaml b/dav/use-cases/hammer-decommission/016-legal-hold-blocks-decommission.yaml
new file mode 100644
index 0000000..c419e7b
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/016-legal-hold-blocks-decommission.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-decommission-016
+handle: decommission/legal-hold-blocks-decommission
+scenario:
+  description: 'A tenant-admin requests decommission of a data store that is under an active legal hold
+    for litigation. Even a fully authorized teardown must be refused while the hold is in force — the
+    hold is a governance override that outranks the owner''s decommission intent. The system must evaluate
+    hold status as a hard gate, refuse the destroy, and record the refusal with the hold reference. This
+    probes whether governance policy can veto a legitimate decommission and whether holds are modeled
+    as first-class constraints on teardown.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - tenancy-authority
+  intent: Attempt to decommission a resource under an active legal hold
+  success_criteria:
+  - System resolves the active legal hold on the target data store
+  - The decommission is refused while the hold is in force, regardless of owner authorization
+  - The refusal names the hold reference and its governing policy
+  - No destroy is dispatched and no realized state is cleared
+  - The refusal is recorded in the audit trail with the hold citation
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: single_no_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: active legal hold on the resource resolved
+  - domain: policy
+    interaction: legal-hold governance gate vetoes the decommission
+  - domain: audit
+    interaction: refusal recorded with hold reference
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- legal-hold
+- governance
+- compliance
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/017-grace-period-soft-then-hard-delete.yaml b/dav/use-cases/hammer-decommission/017-grace-period-soft-then-hard-delete.yaml
new file mode 100644
index 0000000..6782523
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/017-grace-period-soft-then-hard-delete.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-decommission-017
+handle: decommission/grace-period-soft-then-hard-delete
+scenario:
+  description: 'A platform engineer decommissions a production database with a required grace period:
+    teardown must first soft-delete — detach and quiesce the resource but keep it recoverable — then,
+    only after the grace window elapses with no cancellation, hard-delete and destroy the data irreversibly.
+    The system must orchestrate the two-phase flow, allow an operator to cancel and restore during the
+    window, and treat the hard-delete as terminal once it fires. This probes whether decommission supports
+    a staged, reversible-then-irreversible flow rather than a single destructive step.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives: []
+  intent: Decommission with a grace period — soft-delete, then hard-delete if not cancelled
+  success_criteria:
+  - Phase one soft-deletes the resource (detached and quiesced) while keeping it recoverable
+  - The resource is restorable by an operator cancellation at any point during the grace window
+  - Hard-delete fires only after the grace window elapses with no cancellation
+  - The hard-delete destroys the data irreversibly and clears realized state
+  - Both phases and any cancellation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: orchestration_flow_static
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: two-phase grace-period flow orchestrates soft-delete then hard-delete
+  - domain: provider
+    interaction: provider quiesces on soft-delete, destroys on hard-delete
+  - domain: data
+    interaction: resource held recoverable during window, realized state cleared on hard-delete
+  - domain: audit
+    interaction: both phases and any cancellation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- grace-period
+- soft-delete
+- two-phase
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/018-cross-tenant-shared-pool-cascade.yaml b/dav/use-cases/hammer-decommission/018-cross-tenant-shared-pool-cascade.yaml
new file mode 100644
index 0000000..ba212ac
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/018-cross-tenant-shared-pool-cascade.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-decommission-018
+handle: decommission/cross-tenant-shared-pool-cascade
+scenario:
+  description: 'A tenant-admin for tenant A requests decommission of a shared network segment, and the
+    cascade the system computes would tear down resources that belong to tenant B, which also attaches
+    to that segment. The system must NOT let one tenant''s decommission cascade across the tenancy boundary
+    and destroy another tenant''s resources. It must scope the cascade to the requester''s tenant, block
+    or refuse where the cascade would cross into tenant B, and surface the cross-tenant stakeholders.
+    This probes multi-tenant isolation on teardown, a likely gap.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Prevent a decommission cascade from crossing into another tenant's resources
+  success_criteria:
+  - System computes the cascade and detects it would reach tenant B's resources
+  - The cascade is scoped to the requesting tenant; it does not destroy tenant B's resources
+  - Where teardown depends on a cross-tenant resource, the request is blocked or refused
+  - Tenant B's cross-tenant stakes on the shared segment are surfaced to the requester
+  - No cross-tenant resource is destroyed without that tenant's own authorization
+  - The tenancy-boundary enforcement decision is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: shared segment's cross-tenant attachments resolved
+  - domain: policy
+    interaction: tenancy-isolation matrix blocks cascade across the tenant boundary
+  - domain: audit
+    interaction: cross-tenant enforcement decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- multi-tenancy
+- isolation
+- cascade
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/019-provider-unreachable-unconfirmed-destroy.yaml b/dav/use-cases/hammer-decommission/019-provider-unreachable-unconfirmed-destroy.yaml
new file mode 100644
index 0000000..3bd340a
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/019-provider-unreachable-unconfirmed-destroy.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-decommission-019
+handle: decommission/provider-unreachable-unconfirmed-destroy
+scenario:
+  description: 'An SRE decommissions a resource whose owning provider is unreachable, so the destroy is
+    dispatched but never acknowledged — the system cannot confirm whether the resource was actually destroyed.
+    It must NOT clear realized state on an unconfirmed destroy, which would create a data inconsistency
+    (the model says gone, the world may still have it running and billing). It must hold the resource
+    in a destroy-pending state, reconcile when the provider returns, and never assume success. This probes
+    how teardown handles unacknowledged provider calls and the truth gap they open.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - finance-analyst
+  intent: Decommission a resource whose provider cannot confirm the destroy
+  success_criteria:
+  - Destroy is dispatched but the owning provider does not acknowledge
+  - Realized state is NOT cleared on the unconfirmed destroy
+  - The resource is held in a destroy-pending state rather than marked gone
+  - When the provider returns, the system reconciles actual state against the pending destroy
+  - The unconfirmed destroy is flagged as a data-inconsistency risk, not silent success
+  - The pending state and eventual reconciliation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: destroy dispatched but unacknowledged by unreachable provider
+  - domain: data
+    interaction: realized state held destroy-pending, not cleared
+  - domain: policy
+    interaction: recovery policy drives reconciliation on provider return
+  - domain: audit
+    interaction: unconfirmed destroy and reconciliation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- provider-failure
+- unconfirmed-destroy
+- data-inconsistency
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-decommission/020-cross-domain-dangling-payload.yaml b/dav/use-cases/hammer-decommission/020-cross-domain-dangling-payload.yaml
new file mode 100644
index 0000000..b252697
--- /dev/null
+++ b/dav/use-cases/hammer-decommission/020-cross-domain-dangling-payload.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-decommission-020
+handle: decommission/cross-domain-dangling-payload
+scenario:
+  description: 'A platform engineer decommissions a composite application whose one constituent — an object-storage
+    bucket — is still referenced by a payload-carried dependency from OUTSIDE the composite: a scheduled
+    analytics job in another team''s environment writes to it nightly. The dependency is expressed in
+    the resource payload, not as a top-level graph edge. The system must detect the cross-domain payload
+    reference before destroying the bucket, refuse to strand the external writer, and surface the external
+    dependent. This probes whether the dependency graph sees payload-embedded references, a common blind
+    spot that likely returns partially supported or unsupported.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Decommission a composite without stranding an external payload-referenced dependent
+  success_criteria:
+  - System scans resource payloads, not just top-level edges, for references to the bucket
+  - The external analytics job's cross-domain reference to the bucket is detected
+  - The bucket is not destroyed while the external writer still references it
+  - The external dependent is surfaced to the requester as a blocker
+  - The rest of the composite tears down only if it can do so without stranding the external reference
+  - The payload-reference detection and the block are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: resource payloads scanned for cross-domain references to the bucket
+  - domain: policy
+    interaction: payload-reference constraint blocks destroying a still-referenced constituent
+  - domain: provider
+    interaction: composite teardown withheld on the referenced bucket
+  - domain: audit
+    interaction: payload-dependent detection and block recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- decommission
+- payload-dependency
+- cross-domain
+- composite
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/001-faithful-single-stateless-baseline.yaml b/dav/use-cases/hammer-dr-rehydration/001-faithful-single-stateless-baseline.yaml
new file mode 100644
index 0000000..a7636f0
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/001-faithful-single-stateless-baseline.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-dr-rehydration-001
+handle: dr-rehydration/faithful-single-stateless-baseline
+scenario:
+  description: 'Following a control-plane rebuild, a platform engineer rehydrates a single stateless compute
+    service that has no dependencies. The system reads the resource''s pinned intent and its captured
+    realized facts, re-runs the one validation policy that governed it, and re-realizes it on the same
+    provider it originally occupied. This is the baseline faithful case: no substitution, no data movement,
+    no policy change. It proves the minimal rehydration loop works before any edge is introduced, and
+    that the resource''s UUID and configuration are reproduced exactly from the data model.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Faithfully rebuild one stateless service from stored intent after a rebuild
+  success_criteria:
+  - Stored intent and captured realized facts are read for the single resource
+  - The original governing validation policy is re-evaluated and passes unchanged
+  - The resource is re-realized on its original provider (faithful mode, no substitution)
+  - The resource UUID is preserved across the destroy/rebuild cycle
+  - Post-rebuild realized state matches the original intent exactly
+  - The rehydration decision and provider dispatch are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    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 and realized facts read for the single resource
+  - domain: policy
+    interaction: the single governing validation policy is re-evaluated and passes
+  - domain: provider
+    interaction: original provider re-realizes the resource in faithful mode
+  - domain: audit
+    interaction: rehydration and dispatch recorded with preserved UUID
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- faithful
+- baseline
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A single stateless resource was realized and is now destroyed
+  - Intent and realized facts are preserved in the data stores
+  postconditions:
+  - Resource re-realized on the original provider with preserved UUID
+  - Realized state matches original intent
+  - Audit trail records the faithful rehydration
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/002-rehydrate-from-intent-only.yaml b/dav/use-cases/hammer-dr-rehydration/002-rehydrate-from-intent-only.yaml
new file mode 100644
index 0000000..d7f9fa7
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/002-rehydrate-from-intent-only.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-dr-rehydration-002
+handle: dr-rehydration/rehydrate-from-intent-only
+scenario:
+  description: 'A disaster wipes not only the realized resources but also the requested and realized state
+    stores; only the declared intent survives in an off-site copy. An SRE rehydrates from intent alone,
+    forcing the system to re-derive requested configuration and placement from first principles rather
+    than replaying captured realized facts. The system must treat the absence of realized UUIDs as expected
+    for this source and mint or preserve identifiers per the faithful contract. This probes whether intent
+    is genuinely sufficient as the single source of truth, or whether rehydration secretly depends on
+    realized-state artifacts.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+    - provider-owner
+    - security-officer
+  intent: Rebuild the environment from surviving intent when realized state is lost
+  success_criteria:
+  - Rehydration proceeds using intent state as the sole surviving source
+  - Requested configuration is re-derived from intent, not read from a lost store
+  - Missing realized facts do not abort the rebuild
+  - Validation policies are re-evaluated against the re-derived requested state
+  - All resources are re-realized in correct dependency order from intent alone
+  - The rebuild explicitly records that it ran from intent-only with no realized-state input
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent read as sole source; requested state re-derived, not replayed
+  - domain: policy
+    interaction: validation policies re-evaluated against re-derived requested state
+  - domain: provider
+    interaction: providers re-realize each resource from intent-derived requests
+  - domain: audit
+    interaction: rebuild records intent-only provenance and identifier handling
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- intent-only
+- source-of-truth
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Realized and requested state stores are lost; only intent survives
+  - Resources are destroyed
+  postconditions:
+  - Environment rebuilt from intent alone
+  - Provenance records intent-only source
+  - Four-state stores repopulated from the rebuild
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/003-uuid-preservation-across-rebuild.yaml b/dav/use-cases/hammer-dr-rehydration/003-uuid-preservation-across-rebuild.yaml
new file mode 100644
index 0000000..7a019c9
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/003-uuid-preservation-across-rebuild.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-dr-rehydration-003
+handle: dr-rehydration/uuid-preservation-across-rebuild
+scenario:
+  description: 'A tenant-admin destroys and faithfully rebuilds a small application composed of a web
+    tier that hard-depends on a database. Downstream systems (DNS records, monitoring targets, IAM bindings)
+    reference the resources by their stable UUIDs, so rehydration must reproduce the exact same identifiers
+    rather than mint new ones. The system re-realizes both resources in dependency order and reconciles
+    each newly realized resource back to its original UUID from the data model. This validates that identity
+    is a property of intent, not of a provider''s per-instance handle that changes on every rebuild.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - tenancy-authority
+  intent: Rebuild an app while preserving resource UUIDs for downstream references
+  success_criteria:
+  - Both resources are re-realized in correct dependency order (database before web tier)
+  - Each resource's original UUID is reattached to its rebuilt realization
+  - No new UUIDs are minted for resources that existed before the rebuild
+  - Downstream references keyed on UUID remain valid after rehydration
+  - Realized state matches original intent for both resources
+  - UUID continuity is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: original UUIDs read from intent and reattached to rebuilt resources
+  - domain: provider
+    interaction: provider re-realizes both resources; realized handles reconciled to stored UUIDs
+  - domain: audit
+    interaction: UUID continuity across destroy/rebuild recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- uuid-preservation
+- identity
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A two-resource app was realized with stable UUIDs and is now destroyed
+  - Downstream systems reference the resources by UUID
+  postconditions:
+  - Both resources rebuilt with original UUIDs preserved
+  - Downstream UUID references remain valid
+  - Audit trail records UUID continuity
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/004-provider-portable-single-happy.yaml b/dav/use-cases/hammer-dr-rehydration/004-provider-portable-single-happy.yaml
new file mode 100644
index 0000000..ec2266d
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/004-provider-portable-single-happy.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-dr-rehydration-004
+handle: dr-rehydration/provider-portable-single-happy
+scenario:
+  description: 'A platform engineer rehydrates a single object-storage bucket in provider-portable mode
+    even though the original provider is still available. Provider-portable rehydration ignores the originally
+    realized provider binding and re-runs the placement engine to choose any eligible provider that satisfies
+    the intent''s capability and policy requirements. In this happy case the placement engine happens
+    to re-select the original provider, but it must do so through fresh eligibility evaluation, not by
+    replaying the old binding. This proves portable mode is genuinely re-placed, establishing the baseline
+    before substitution and sovereignty edges are introduced.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - sovereignty-authority
+  intent: Rehydrate one resource in portable mode via fresh placement
+  success_criteria:
+  - Rehydration runs in provider-portable mode, ignoring the original provider binding
+  - Placement engine evaluates all eligible providers against the intent's requirements
+  - A provider is selected through fresh eligibility, not by replaying the old binding
+  - The resource is re-realized on the selected provider and satisfies intent
+  - The resource UUID is preserved even though placement was recomputed
+  - Placement rationale (candidates considered, provider chosen) is recorded
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent read; original provider binding intentionally not replayed
+  - domain: policy
+    interaction: eligibility and validation policies evaluated for candidate providers
+  - domain: provider
+    interaction: placement engine re-selects a provider and re-realizes the resource
+  - domain: audit
+    interaction: placement candidates and selection rationale recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- provider-portable
+- placement
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A single resource was realized and is now destroyed
+  - Multiple eligible providers exist, including the original
+  postconditions:
+  - Resource re-realized via fresh placement in portable mode
+  - UUID preserved; placement rationale recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/005-rehydrate-from-requested-only.yaml b/dav/use-cases/hammer-dr-rehydration/005-rehydrate-from-requested-only.yaml
new file mode 100644
index 0000000..c498ee8
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/005-rehydrate-from-requested-only.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-dr-rehydration-005
+handle: dr-rehydration/rehydrate-from-requested-only
+scenario:
+  description: 'A resource was requested and validated but the original realization never completed before
+    the disaster — it exists only in the requested state, never in realized. An application-team member
+    asks the system to rehydrate it. The system must decide whether a never-realized request is a legitimate
+    rehydration source or a first-time new_request wearing a rehydration label. It must not fabricate
+    realized facts that never existed, and must not silently downgrade the operation without recording
+    the ambiguity. This probes whether the four-state model cleanly distinguishes "rebuild what was" from
+    "finish what was started," and may come back partially_supported or unsupported.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Rehydrate a resource that was only ever requested, never realized
+  success_criteria:
+  - System detects the resource has requested state but no prior realized state
+  - It does not fabricate realized facts or a UUID that never existed
+  - The operation is classified explicitly (rehydration vs first realization), not left implicit
+  - Validation policies are evaluated against the requested state
+  - If realization proceeds, provenance records it originated from requested-only source
+  - Any ambiguity or downgrade of the operation is surfaced as a finding, not hidden
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: requested state present, realized state absent; source classified
+  - domain: policy
+    interaction: validation evaluates the requested state for eligibility
+  - domain: audit
+    interaction: operation classification and requested-only provenance recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- requested-only
+- four-state
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource has requested state but was never realized
+  - No realized facts or provider handle exist for it
+  postconditions:
+  - Operation classified explicitly with recorded rationale
+  - No fabricated realized facts
+  - Ambiguity surfaced as a finding
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/006-rehydrate-from-realized-facts.yaml b/dav/use-cases/hammer-dr-rehydration/006-rehydrate-from-realized-facts.yaml
new file mode 100644
index 0000000..f5225a9
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/006-rehydrate-from-realized-facts.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-dr-rehydration-006
+handle: dr-rehydration/rehydrate-from-realized-facts
+scenario:
+  description: 'A resource had drifted from its declared intent before the disaster — an operator had
+    manually resized it — and the realized state captured that drift. An SRE rehydrates and must choose
+    the source of truth: rebuilding from intent restores the original declared shape, while rebuilding
+    from realized reproduces the drifted, as-run configuration. This UC exercises rehydration explicitly
+    sourced from realized facts, testing whether the system can faithfully reproduce what was actually
+    running (including sanctioned drift) rather than only what was originally declared. It also tests
+    that the intent-versus-realized divergence is made visible so the operator chooses knowingly.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+    - executive
+  intent: Rebuild a drifted resource from its captured realized state, not intent
+  success_criteria:
+  - System detects that realized state diverged from declared intent before the disaster
+  - The divergence between intent and realized is surfaced to the operator
+  - Rehydration reproduces the realized (as-run) configuration when that source is chosen
+  - Validation policies are re-evaluated against the realized-derived request
+  - The resource UUID is preserved across the rebuild
+  - The chosen source (realized over intent) and its rationale are recorded
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent and drifted realized state compared; realized chosen as source
+  - domain: policy
+    interaction: validation re-evaluated against the realized-derived request
+  - domain: provider
+    interaction: provider re-realizes the as-run configuration
+  - domain: audit
+    interaction: intent/realized divergence and chosen source recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- realized-source
+- drift
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Realized state captured sanctioned drift from intent before destruction
+  - Both intent and realized states are preserved
+  postconditions:
+  - Resource rebuilt from realized facts with divergence surfaced
+  - Chosen source recorded in audit trail
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/007-idempotent-re-rehydration-noop.yaml b/dav/use-cases/hammer-dr-rehydration/007-idempotent-re-rehydration-noop.yaml
new file mode 100644
index 0000000..aa6f86c
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/007-idempotent-re-rehydration-noop.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-dr-rehydration-007
+handle: dr-rehydration/idempotent-re-rehydration-noop
+scenario:
+  description: 'A rehydration run is interrupted and retried — a common operational reality when a DR
+    playbook is re-invoked after a partial success or an operator re-runs it out of caution. By the time
+    the second run executes, several resources are already re-realized and match intent. The system must
+    recognize the already-rehydrated resources and produce a no-op for them (no duplicate dispatch, no
+    UUID churn) while completing only the resources that are still missing. This validates that rehydration
+    is idempotent and safely re-runnable, which is a hard requirement for any real DR procedure.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Re-run a rehydration safely so completed resources are no-ops
+  success_criteria:
+  - System compares current realized state against intent for each resource on the retry
+  - Already-rehydrated resources matching intent produce a no-op with no new dispatch
+  - No duplicate resources are created and no UUIDs are reassigned
+  - Only resources still missing or non-matching are re-realized
+  - The environment converges to full intent match regardless of retry count
+  - No-op and completion decisions are both recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: per-resource realized state compared against intent on retry
+  - domain: provider
+    interaction: dispatch issued only for missing resources; matched ones skipped
+  - domain: audit
+    interaction: no-op and completion decisions recorded per resource
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- idempotency
+- retry-safe
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A prior rehydration run partially completed
+  - Some resources already match intent, others are still destroyed
+  postconditions:
+  - Completed resources are no-ops on retry; missing ones re-realized
+  - Environment fully converged with no duplicates
+  - Audit trail records per-resource decisions
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/008-single-resource-data-migration.yaml b/dav/use-cases/hammer-dr-rehydration/008-single-resource-data-migration.yaml
new file mode 100644
index 0000000..8f86985
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/008-single-resource-data-migration.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-dr-rehydration-008
+handle: dr-rehydration/single-resource-data-migration
+scenario:
+  description: 'An SRE faithfully rehydrates a single stateful database service whose data lives on an
+    attached persistent volume backed by an off-site snapshot. Rehydration must not only re-realize the
+    compute resource but also drive the data-plane restore: provisioning the volume, attaching it, and
+    restoring the snapshot before the service is marked realized. The compute and its data payload form
+    a cross-dependency — the service is not truly rehydrated until its data is in place. This tests whether
+    rehydration coordinates the provider (compute) and data (payload restore) domains as a single unit
+    rather than treating data restoration as an out-of-band manual step.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+  intent: Rehydrate one stateful service including its data-volume restore
+  success_criteria:
+  - The compute resource and its attached volume are both re-realized
+  - The data-plane restore (snapshot into the volume) is driven as part of rehydration
+  - The service is not marked realized until its data payload is restored and attached
+  - Validation policies covering the data payload are re-evaluated
+  - The resource UUID and its volume binding are preserved
+  - Compute realization and data restore are both recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: cross_dependency_payload
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: volume snapshot restored and attached as the service's data payload
+  - domain: policy
+    interaction: data-payload validation policies re-evaluated
+  - domain: provider
+    interaction: provider re-realizes compute and provisions/attaches the volume
+  - domain: audit
+    interaction: compute realization and data restore both recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- data-migration
+- stateful
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A stateful service with an attached volume was realized and destroyed
+  - An off-site snapshot of the volume exists
+  postconditions:
+  - Service rehydrated with its data restored and attached
+  - UUID and volume binding preserved
+  - Audit trail records compute and data restore
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/009-provider-gone-portable-substitute.yaml b/dav/use-cases/hammer-dr-rehydration/009-provider-gone-portable-substitute.yaml
new file mode 100644
index 0000000..56da0a8
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/009-provider-gone-portable-substitute.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-dr-rehydration-009
+handle: dr-rehydration/provider-gone-portable-substitute
+scenario:
+  description: 'A platform engineer rehydrates a realized service in provider-portable mode, but the provider
+    that originally realized it has been fully decommissioned and no longer exists in the provider registry.
+    The placement engine must recognize the missing original binding as acceptable in portable mode, evaluate
+    the remaining eligible providers for capability equivalence, and re-realize the resource on a substitute
+    that satisfies the same intent. The substitution must be capability-checked (not merely category-matched)
+    so the rehydrated resource is functionally equivalent. This is a core portability claim of the architecture
+    and may surface gaps where capability equivalence is under-specified.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Rehydrate onto a substitute provider after the original is decommissioned
+  success_criteria:
+  - System detects the original provider is absent from the registry
+  - Portable mode treats the missing original binding as acceptable, not fatal
+  - Remaining eligible providers are evaluated for capability equivalence to the intent
+  - A capability-equivalent substitute provider is selected (not merely category-matched)
+  - The resource is re-realized on the substitute and satisfies intent
+  - Substitution rationale and equivalence evidence are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent read; original provider binding found absent
+  - domain: policy
+    interaction: capability-equivalence and validation policies evaluated for candidates
+  - domain: provider
+    interaction: placement selects a substitute and re-realizes the resource
+  - domain: audit
+    interaction: substitution rationale and equivalence evidence recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- provider-portable
+- provider-gone
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource was realized on a provider that is now decommissioned
+  - Other eligible providers exist with overlapping capabilities
+  postconditions:
+  - Resource re-realized on a capability-equivalent substitute
+  - Substitution rationale recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/010-provider-gone-faithful-blocked.yaml b/dav/use-cases/hammer-dr-rehydration/010-provider-gone-faithful-blocked.yaml
new file mode 100644
index 0000000..bc928a7
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/010-provider-gone-faithful-blocked.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-dr-rehydration-010
+handle: dr-rehydration/provider-gone-faithful-blocked
+scenario:
+  description: 'A platform engineer attempts a strictly faithful rehydration of a resource whose original
+    provider has been decommissioned. Faithful mode, by contract, pins the resource to the exact provider
+    it originally occupied and forbids substitution. With that provider gone, the faithful rebuild cannot
+    proceed. The system must fail this cleanly and legibly: detect the missing provider, refuse to silently
+    fall back to a substitute (which would violate the faithful contract), and surface the conflict with
+    a recommended remediation (switch to provider-portable mode or restore the provider). This case should
+    very likely return unsupported, exposing the tension between faithful fidelity and provider mortality.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Faithfully rebuild a resource onto its original, now-missing provider
+  success_criteria:
+  - System detects the original provider is absent and required by faithful mode
+  - It refuses to substitute a different provider under the faithful contract
+  - The rehydration is blocked cleanly with no partial dispatch
+  - The conflict (faithful pin versus missing provider) is stated explicitly
+  - A remediation path (portable mode or provider restoration) is recommended
+  - The blocked outcome and rationale are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent pins original provider; provider found absent from registry
+  - domain: policy
+    interaction: faithful-mode recovery policy forbids substitution and blocks the rebuild
+  - domain: provider
+    interaction: no dispatch issued; no substitute provider contacted
+  - domain: audit
+    interaction: blocked outcome, conflict, and recommended remediation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- faithful
+- provider-gone
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource's original provider is decommissioned
+  - Faithful mode is required, forbidding substitution
+  postconditions:
+  - Rehydration blocked with no partial dispatch
+  - Conflict and remediation recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/011-partial-dr-some-resources-fail.yaml b/dav/use-cases/hammer-dr-rehydration/011-partial-dr-some-resources-fail.yaml
new file mode 100644
index 0000000..a291895
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/011-partial-dr-some-resources-fail.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-dr-rehydration-011
+handle: dr-rehydration/partial-dr-some-resources-fail
+scenario:
+  description: 'An SRE runs a full-stack faithful rehydration during a real regional outage. Most resources
+    re-realize successfully, but one leaf provider is still down, so a subset of resources cannot be rebuilt.
+    The system must complete every resource it can, halt cleanly at the ones it cannot, and leave the
+    environment in a legible partially-rehydrated state — not a corrupt half-applied one. Dependents of
+    the failed resources must not be force-realized on top of missing prerequisites. This tests whether
+    rehydration degrades gracefully and produces an actionable manifest of what succeeded, what failed,
+    and what remains blocked pending the provider''s recovery.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+  intent: Rehydrate a full stack when one provider is still unavailable
+  success_criteria:
+  - All resources whose providers are available are successfully re-realized
+  - Resources on the down provider fail cleanly without corrupting shared state
+  - Dependents of failed resources are held back, not realized on missing prerequisites
+  - The environment ends in a legible partially-rehydrated state, not half-applied corruption
+  - A manifest of succeeded, failed, and blocked resources is produced
+  - Partial completion is recorded so a later retry resumes only the outstanding resources
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph read; per-resource rehydration status tracked
+  - domain: policy
+    interaction: dependency-order policy holds back dependents of failed resources
+  - domain: provider
+    interaction: available providers re-realize; the down provider fails its resources
+  - domain: audit
+    interaction: succeeded/failed/blocked manifest recorded for resumable retry
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- partial-failure
+- graceful-degradation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A full stack was realized and is now destroyed
+  - One leaf provider remains unavailable during rehydration
+  postconditions:
+  - Available resources rehydrated; failed ones cleanly blocked
+  - Partial-state manifest recorded for resumable retry
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/012-policy-changed-current-eval-blocks.yaml b/dav/use-cases/hammer-dr-rehydration/012-policy-changed-current-eval-blocks.yaml
new file mode 100644
index 0000000..c4f33c0
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/012-policy-changed-current-eval-blocks.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-dr-rehydration-012
+handle: dr-rehydration/policy-changed-current-eval-blocks
+scenario:
+  description: 'Per RHY-001 (rehydration re-evaluates current policy rather than replaying a pinned snapshot),
+    a compliance auditor rehydrates a service that was legally realized months ago under a policy that
+    has since tightened. The governing validation policy now forbids the resource''s original configuration
+    — for example an encryption tier or a data-class handling rule that was later mandated. Rehydration
+    must re-evaluate the current policy and refuse to faithfully reproduce a now-non-compliant resource,
+    even though it faithfully matches stored intent. The system must make the intent-versus-current-policy
+    conflict explicit rather than resurrecting a violation. This likely returns unsupported or compliance-gated
+    by design.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Rehydrate a resource whose original config now violates tightened policy
+  success_criteria:
+  - Rehydration re-evaluates the current governing policy, not a pinned snapshot (RHY-001)
+  - The current policy is detected as stricter than the one in force at original realization
+  - The faithful rebuild is blocked because it would reproduce a now-non-compliant resource
+  - The conflict between stored intent and current policy is stated explicitly
+  - No non-compliant resource is realized on any provider
+  - The blocked outcome, the offending policy, and the delta are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    governance_context: compliance_gated
+    provider_landscape: single_eligible
+    failure_mode: provider_failure
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: stored intent read; original config compared to current policy
+  - domain: policy
+    interaction: current tightened policy re-evaluated and blocks the faithful rebuild
+  - domain: provider
+    interaction: no dispatch; non-compliant resource never realized
+  - domain: audit
+    interaction: policy delta, conflict, and blocked outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- policy-drift
+- rhy-001
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource was compliant under the policy in force at original realization
+  - The governing policy has since tightened
+  postconditions:
+  - Faithful rebuild blocked under current policy
+  - Policy delta and conflict recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/013-policy-changed-pinned-config-preserved.yaml b/dav/use-cases/hammer-dr-rehydration/013-policy-changed-pinned-config-preserved.yaml
new file mode 100644
index 0000000..53b3ff0
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/013-policy-changed-pinned-config-preserved.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-dr-rehydration-013
+handle: dr-rehydration/policy-changed-pinned-config-preserved
+scenario:
+  description: 'The counterpart to the RHY-001 current-policy default: a security officer needs to rehydrate
+    a resource exactly as it ran under the policy in force at original realization, because a legal hold
+    or an in-flight audit requires reproducing the historical state verbatim — even though policy has
+    since changed. This UC tests whether the architecture offers a pinned-config rehydration mode that
+    binds to the historical policy version rather than the current one, and whether such a mode is itself
+    governed (who may authorize resurrecting a superseded policy, and under what audit controls). If the
+    architecture only supports current-policy evaluation, this returns unsupported — a meaningful finding
+    about legal-hold and forensic DR needs.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Rehydrate under the historical pinned policy for a legal hold
+  success_criteria:
+  - The request specifies pinned-config mode bound to the historical policy version
+  - System resolves which policy version was in force at original realization
+  - If supported, the resource is rebuilt under the pinned historical policy, not the current one
+  - Authorization to invoke pinned mode is itself checked and governed
+  - The deviation from current-policy default is recorded with the authorizing identity
+  - If pinned mode is unsupported, the limitation is surfaced explicitly as a finding
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    governance_context: audit_heavy
+    provider_landscape: multiple_eligible
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: historical policy version resolved and pinned mode authorization checked
+  - domain: data
+    interaction: stored intent and the in-force-at-realization policy version read
+  - domain: provider
+    interaction: resource re-realized under the pinned historical policy if supported
+  - domain: audit
+    interaction: pinned-mode invocation, authorizing identity, and deviation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- pinned-config
+- legal-hold
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource was realized under a policy version since superseded
+  - A legal hold requires reproducing the historical state verbatim
+  postconditions:
+  - Resource rebuilt under pinned historical policy, or limitation surfaced
+  - Pinned-mode authorization and deviation recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/014-dependency-cycle-ordering.yaml b/dav/use-cases/hammer-dr-rehydration/014-dependency-cycle-ordering.yaml
new file mode 100644
index 0000000..9fae247
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/014-dependency-cycle-ordering.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-dr-rehydration-014
+handle: dr-rehydration/dependency-cycle-ordering
+scenario:
+  description: 'A platform engineer rehydrates an environment whose stored dependency graph contains a
+    cycle: resource A hard-depends on B while B hard-depends on A (an accidental mutual reference that
+    was tolerated at steady state because both already existed). Rehydration derives build order by topologically
+    sorting the dependency graph, and a cycle makes a valid order impossible. The system must detect the
+    cycle before dispatching anything, refuse to guess an order or deadlock mid-rebuild, and report the
+    specific participating resources so an operator can break the cycle. This probes whether the rebuild
+    planner validates the graph''s acyclicity up front; it likely returns unsupported for the cyclic subgraph.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Rehydrate an environment whose dependency graph contains a cycle
+  success_criteria:
+  - The rebuild planner attempts to derive a topological build order from the graph
+  - A dependency cycle is detected before any provider dispatch occurs
+  - The system refuses to guess an order or enter a mid-rebuild deadlock
+  - The specific resources participating in the cycle are named in the output
+  - Acyclic portions of the graph are reported as buildable versus the blocked cyclic subgraph
+  - The cycle detection and blocked outcome are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: hard_dependencies
+    policy_complexity: orchestration_flow_static
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph read; cycle detected during topological ordering
+  - domain: policy
+    interaction: orchestration ordering policy refuses to plan a cyclic subgraph
+  - domain: provider
+    interaction: no dispatch issued for the cyclic resources
+  - domain: audit
+    interaction: participating resources and blocked outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- dependency-cycle
+- ordering
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Stored dependency graph contains a mutual (cyclic) hard dependency
+  - Resources are destroyed and awaiting rebuild
+  postconditions:
+  - Cycle detected before dispatch; cyclic subgraph blocked
+  - Participating resources named and recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/015-sovereignty-conflict-new-provider.yaml b/dav/use-cases/hammer-dr-rehydration/015-sovereignty-conflict-new-provider.yaml
new file mode 100644
index 0000000..4afa982
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/015-sovereignty-conflict-new-provider.yaml
@@ -0,0 +1,69 @@
+uuid: uc-hammer-dr-rehydration-015
+handle: dr-rehydration/sovereignty-conflict-new-provider
+scenario:
+  description: 'A regional disaster takes out every in-jurisdiction provider for a residency-pinned dataset.
+    A platform engineer attempts a provider-portable rehydration, and the only surviving eligible providers
+    sit in a different, prohibited jurisdiction. Portable mode would normally re-place freely, but the
+    resource''s sovereignty constraint forbids relocating data-at-rest across the border. The system must
+    re-evaluate the sovereignty policy at rehydration time, detect that every available substitute violates
+    residency, and refuse to rehydrate onto a non-compliant provider — even at the cost of leaving the
+    resource down until in-jurisdiction capacity returns. This is the sharp DR-versus-sovereignty tension
+    and should return unsupported for the cross-border substitutes.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - sovereignty-authority
+  intent: Portably rehydrate a residency-pinned dataset when only cross-border providers survive
+  success_criteria:
+  - Sovereignty policy is re-evaluated against each surviving candidate provider at rehydration
+  - Every available substitute is detected to violate the residency constraint
+  - The system refuses to rehydrate the dataset onto any prohibited-jurisdiction provider
+  - Availability pressure does not override the sovereignty constraint
+  - The resource is left unrealized (down) rather than relocated non-compliantly
+  - The blocked outcome, offending jurisdictions, and constraint id are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    governance_context: sovereignty_enforced
+    provider_landscape: mixed
+    failure_mode: provider_failure
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: residency constraint on data-at-rest read from intent
+  - domain: policy
+    interaction: sovereignty policy re-evaluated; all cross-border substitutes denied
+  - domain: provider
+    interaction: no dispatch to any prohibited-jurisdiction provider
+  - domain: audit
+    interaction: blocked outcome, offending jurisdictions, and constraint id recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- sovereignty
+- residency
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - All in-jurisdiction providers are down after a regional disaster
+  - Surviving eligible providers are in a prohibited jurisdiction
+  postconditions:
+  - Rehydration refused onto cross-border providers
+  - Resource left down; sovereignty preserved and recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/016-concurrent-rehydration-live-drift.yaml b/dav/use-cases/hammer-dr-rehydration/016-concurrent-rehydration-live-drift.yaml
new file mode 100644
index 0000000..b0be3fd
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/016-concurrent-rehydration-live-drift.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-dr-rehydration-016
+handle: dr-rehydration/concurrent-rehydration-live-drift
+scenario:
+  description: 'A rehydration is mid-flight when an out-of-band actor mutates a resource that has already
+    been re-realized — an operator hotfixes a config, or an autoscaler resizes an instance, while later
+    resources in the plan are still being rebuilt. The rehydration engine now faces live drift on resources
+    it believed it had just restored to intent. The system must detect that a just-rehydrated resource
+    no longer matches the state it wrote, avoid blindly clobbering the concurrent change or completing
+    the plan on a stale assumption, and reconcile the conflict — either re-converging to intent or flagging
+    the drift for the operator. This tests rehydration under concurrency and may expose a race where the
+    final state is inconsistent.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+  intent: Rehydrate while a concurrent actor drifts already-restored resources
+  success_criteria:
+  - Rehydration proceeds while an out-of-band actor mutates an already-restored resource
+  - The engine detects that a just-rehydrated resource no longer matches what it wrote
+  - It does not complete the plan on a stale assumption about that resource's state
+  - The concurrent change is reconciled (re-converged to intent or flagged), not blindly clobbered
+  - The final environment state is internally consistent, not a torn mix of plan and drift
+  - The detected drift, the reconciliation decision, and timing are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: post-write realized state re-read; concurrent drift detected against plan
+  - domain: policy
+    interaction: recovery/reconciliation policy decides re-converge versus flag
+  - domain: provider
+    interaction: provider re-queried; concurrent change reconciled rather than clobbered
+  - domain: audit
+    interaction: drift, reconciliation decision, and timing recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- concurrency
+- live-drift
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A rehydration plan is executing across multiple resources
+  - An out-of-band actor mutates a resource already re-realized by the plan
+  postconditions:
+  - Concurrent drift detected and reconciled
+  - Final state internally consistent; conflict recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/017-composite-per-constituent-migration.yaml b/dav/use-cases/hammer-dr-rehydration/017-composite-per-constituent-migration.yaml
new file mode 100644
index 0000000..2ee230a
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/017-composite-per-constituent-migration.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-dr-rehydration-017
+handle: dr-rehydration/composite-per-constituent-migration
+scenario:
+  description: 'An application-team member rehydrates a composite service — a single logical unit that
+    bundles a message broker, a relational database, and a cache — where each constituent carries its
+    own data payload and its own restore source (broker journal, database snapshot, cache warm-set). Faithful
+    rehydration must rebuild the composite as one governed unit while driving a distinct data-migration
+    path per constituent, honoring the internal dependency order (the database restores before the services
+    that read it) and only marking the composite realized when every constituent''s data is in place.
+    This tests whether the architecture models a composite''s data restoration at constituent granularity
+    rather than as a single opaque blob.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Rehydrate a composite service with per-constituent data restores
+  success_criteria:
+  - The composite is rehydrated as one governed unit, not three unrelated resources
+  - Each constituent is restored from its own distinct data source and migration path
+  - The composite's internal dependency order is honored during restore (database before readers)
+  - The composite is marked realized only when every constituent's data is in place
+  - Per-constituent UUIDs and the composite's own identity are all preserved
+  - Each constituent's data restore and the composite roll-up are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: each constituent restored from its own payload source in dependency order
+  - domain: policy
+    interaction: composite and per-constituent validation policies re-evaluated
+  - domain: provider
+    interaction: providers re-realize each constituent and the composite roll-up
+  - domain: audit
+    interaction: per-constituent restores and composite completion recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- composite
+- data-migration
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A composite service with three data-bearing constituents was realized and destroyed
+  - Each constituent has its own restore source
+  postconditions:
+  - Composite rehydrated with all constituents' data restored in order
+  - All identities preserved; per-constituent restores recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/018-full-stack-governance-matrix.yaml b/dav/use-cases/hammer-dr-rehydration/018-full-stack-governance-matrix.yaml
new file mode 100644
index 0000000..7afa923
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/018-full-stack-governance-matrix.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-dr-rehydration-018
+handle: dr-rehydration/full-stack-governance-matrix
+scenario:
+  description: 'A compliance auditor oversees a full-stack faithful rehydration of a regulated workload
+    where every resource must pass a governance matrix that combines residency, data-classification, encryption,
+    and approval-chain requirements before it may be re-realized. Rehydration cannot be a fast-path that
+    bypasses controls just because the resources previously existed; each resource must clear the full
+    governance matrix again at rebuild time, and the reconstruction must produce an audit-grade record
+    proving every control was enforced during recovery. This stresses whether DR preserves governance
+    rigor under time pressure, or whether recovery is a hole in the control plane. Heavy audit and matrix
+    enforcement across the whole stack.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: Rehydrate a regulated full stack with full governance-matrix enforcement
+  success_criteria:
+  - Every resource is re-evaluated against the full governance matrix before re-realization
+  - Rehydration does not fast-path or bypass controls because resources previously existed
+  - Residency, data-class, encryption, and approval-chain checks all apply during recovery
+  - Any resource failing a matrix cell is blocked without blocking independent siblings
+  - The rebuild produces an audit-grade record proving each control was enforced
+  - The full destroy-to-recovery arc with per-control evidence is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    governance_context: audit_heavy
+    provider_landscape: multiple_eligible
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent and dependency graph read for the full regulated stack
+  - domain: policy
+    interaction: full governance matrix re-enforced per resource at rebuild time
+  - domain: provider
+    interaction: providers re-realize only resources that clear every matrix cell
+  - domain: audit
+    interaction: per-control evidence and full recovery arc recorded audit-grade
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- governance-matrix
+- audit-heavy
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A regulated full stack governed by a multi-cell matrix was realized and destroyed
+  - The governance matrix is still in force at rehydration
+  postconditions:
+  - Every resource re-cleared the full matrix before re-realization
+  - Audit-grade per-control evidence recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/019-peer-dcm-rehydration-disconnect.yaml b/dav/use-cases/hammer-dr-rehydration/019-peer-dcm-rehydration-disconnect.yaml
new file mode 100644
index 0000000..06f02a8
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/019-peer-dcm-rehydration-disconnect.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-dr-rehydration-019
+handle: dr-rehydration/peer-dcm-rehydration-disconnect
+scenario:
+  description: 'Part of a tenant''s stack was originally realized through a peer DCM in a federated arrangement
+    — the local DCM holds the intent and dependency graph, but the actual realization was delegated across
+    the federation boundary. During DR, an SRE rehydrates, but the peer DCM is unreachable (the disaster
+    or a network partition took it down too). The local DCM can rebuild everything it owns directly, yet
+    the peer-delegated resources cannot be re-realized without the peer. The system must rehydrate the
+    local portion, detect the peer disconnect, hold the peer-delegated resources and their dependents
+    cleanly, and not pretend the federated resources were restored. This likely returns partially_supported
+    or unsupported for the peer portion.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - federation-peer-operator
+    - tenancy-authority
+  intent: Rehydrate a federated stack while the peer DCM is disconnected
+  success_criteria:
+  - Locally owned resources are rehydrated directly by the local DCM
+  - The system detects the peer DCM is unreachable before attempting peer-delegated rebuilds
+  - Peer-delegated resources are held cleanly, not falsely marked realized
+  - Dependents of peer-delegated resources are not built on missing prerequisites
+  - The federation boundary and which resources are blocked on the peer are made explicit
+  - The peer disconnect and the partial outcome are recorded for resumption when the peer returns
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent and federation ownership map read; peer-delegated resources identified
+  - domain: policy
+    interaction: validation runs locally; peer-delegated resources held pending the peer
+  - domain: provider
+    interaction: local providers re-realize local resources; peer DCM unreachable for the rest
+  - domain: audit
+    interaction: peer disconnect, blocked resources, and partial outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- federation
+- peer-disconnect
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Part of the stack was realized via a peer DCM across a federation boundary
+  - The peer DCM is unreachable during rehydration
+  postconditions:
+  - Local resources rehydrated; peer-delegated ones cleanly held
+  - Peer disconnect and partial outcome recorded for resumption
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-dr-rehydration/020-credential-expiry-mid-rehydration.yaml b/dav/use-cases/hammer-dr-rehydration/020-credential-expiry-mid-rehydration.yaml
new file mode 100644
index 0000000..b5c1b1f
--- /dev/null
+++ b/dav/use-cases/hammer-dr-rehydration/020-credential-expiry-mid-rehydration.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-dr-rehydration-020
+handle: dr-rehydration/credential-expiry-mid-rehydration
+scenario:
+  description: 'Because the disaster predates the recovery by weeks, the credential the DCM held for a
+    provider has expired by the time rehydration runs — a realistic DR failure where secrets rotate on
+    a schedule that outlives the workload''s downtime. Mid-plan, the provider dispatch for one resource
+    is rejected with an authentication failure. The system must distinguish an expired-credential failure
+    from a genuine provider outage or a policy denial, avoid retrying blindly into a lockout, pause the
+    affected resource, and escalate for credential refresh rather than corrupting state or abandoning
+    the whole rebuild. Resources not needing that credential should continue. This tests recovery-time
+    credential lifecycle and human escalation.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - security-officer
+  intent: Rehydrate when a provider credential has expired during the outage
+  success_criteria:
+  - Provider dispatch fails with an authentication error for the affected resource
+  - The system classifies it as credential expiry, distinct from provider outage or policy denial
+  - It does not retry blindly into a provider account lockout
+  - The affected resource is paused and escalated for credential refresh
+  - Resources not dependent on the expired credential continue to rehydrate
+  - After refresh the paused resource resumes without restarting the whole rebuild
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: dispatch rejected with auth error; classified as credential expiry
+  - domain: policy
+    interaction: escalation policy pauses the resource and requests credential refresh
+  - domain: data
+    interaction: per-resource rehydration status tracked for clean resume after refresh
+  - domain: audit
+    interaction: expiry classification, escalation, and resumption recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- dr-rehydration
+- credential-expiry
+- escalation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A provider credential expired during the extended outage
+  - Some resources depend on that credential, others do not
+  postconditions:
+  - Affected resource paused and escalated; independent ones continue
+  - Resumes after refresh without full restart; all steps recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/001-snapshot-vs-discovered.yaml b/dav/use-cases/hammer-drift-recovery/001-snapshot-vs-discovered.yaml
new file mode 100644
index 0000000..84916da
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/001-snapshot-vs-discovered.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-drift-recovery-001
+handle: drift-recovery/snapshot-vs-discovered
+scenario:
+  description: 'An SRE triggers a scheduled reconciliation pass over a realized web service. The engine
+    reads the immutable Realized snapshot recorded at last successful dispatch and runs a fresh Discovery
+    against the live provider, then diffs the two field-by-field. In this pass every discovered value
+    matches the snapshot, so the engine must conclude no drift, record a clean reconciliation result,
+    and take no remediation action. This validates the baseline detection mechanism: Realized-vs-Discovered
+    comparison as the source of truth for drift.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+  intent: Run a reconciliation pass and confirm the resource has not drifted
+  success_criteria:
+  - Reconciliation reads the immutable Realized snapshot and does not mutate it
+  - A fresh Discovery is executed against the live provider
+  - Discovered state is diffed field-by-field against the Realized snapshot
+  - The engine concludes no drift because all fields match
+  - No remediation or re-dispatch is triggered
+  - A clean reconciliation result with timestamp is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    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: immutable Realized snapshot read; fresh Discovered state captured and compared
+  - domain: provider
+    interaction: provider queried for current live state, no write issued
+  - domain: audit
+    interaction: clean reconciliation result recorded with timestamp
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- reconciliation
+- discovery
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource is realized with an immutable Realized snapshot on record
+  - Provider is reachable for discovery
+  postconditions:
+  - No drift detected; no remediation taken
+  - Realized snapshot unchanged
+  - Clean reconciliation result recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/002-unsanctioned-provider-change-flagged.yaml b/dav/use-cases/hammer-drift-recovery/002-unsanctioned-provider-change-flagged.yaml
new file mode 100644
index 0000000..0d828f4
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/002-unsanctioned-provider-change-flagged.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-drift-recovery-002
+handle: drift-recovery/unsanctioned-provider-change-flagged
+scenario:
+  description: 'A provider-side operator manually resizes a realized VM outside the DCM pipeline, bumping
+    its memory allocation without any intent change. On the next reconciliation pass the fresh Discovery
+    reports a memory value that diverges from the immutable Realized snapshot. Because no sanctioned modification
+    produced this delta, the engine must classify the divergence as unsanctioned drift rather than an
+    authorized change, mark the resource drifted, and surface it for evaluation. This validates that any
+    divergence lacking a matching pipeline event is treated as drift until proven otherwise.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+  intent: Detect a manual out-of-pipeline provider change and classify it as drift
+  success_criteria:
+  - Fresh Discovery reports a memory value differing from the Realized snapshot
+  - Engine finds no sanctioned modification event that would explain the delta
+  - The divergence is classified as unsanctioned drift, not an authorized change
+  - The resource is marked drifted and flagged for evaluation
+  - The offending field, old value, and discovered value are captured
+  - The drift finding is recorded in the audit trail with its detection basis
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: discovered memory value diverges from immutable Realized snapshot
+  - domain: policy
+    interaction: divergence checked against sanctioned-change ledger and classified as drift
+  - domain: provider
+    interaction: provider live state read; unsanctioned resize observed
+  - domain: audit
+    interaction: unsanctioned drift finding recorded with offending field and values
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- unsanctioned-change
+- detection
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource is realized with a known Realized snapshot
+  - A provider-side change was made outside the pipeline
+  postconditions:
+  - Resource marked drifted; delta captured
+  - No authorization record exists for the change
+  - Drift finding recorded for downstream evaluation
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/003-recovery-policy-fires-on-drift.yaml b/dav/use-cases/hammer-drift-recovery/003-recovery-policy-fires-on-drift.yaml
new file mode 100644
index 0000000..a0de48f
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/003-recovery-policy-fires-on-drift.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-drift-recovery-003
+handle: drift-recovery/recovery-policy-fires-on-drift
+scenario:
+  description: 'A realized load balancer carries a recovery policy declaring that any drift in its health-check
+    configuration must be auto-remediated back to intent. A reconciliation pass detects that the discovered
+    health-check interval no longer matches the Realized snapshot. The engine must match the drifted field
+    against the resource''s recovery policy, find the auto-remediate rule, and fire it — generating a
+    remediation action that restores intent without human approval. This validates that a recovery_policy
+    can be evaluated against a concrete drift and dispatch corrective action.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+  intent: Have a recovery policy automatically fire and remediate a detected drift
+  success_criteria:
+  - Drift is detected on the health-check interval field
+  - The resource's recovery policy is resolved and evaluated against the drifted field
+  - The auto-remediate rule matches and fires without requiring human approval
+  - A remediation action is generated to restore the intended value
+  - The remediation dispatch is issued to the provider
+  - Policy match, rule id, and remediation action are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: drifted health-check field identified against Realized snapshot
+  - domain: policy
+    interaction: recovery policy resolved; auto-remediate rule matches and fires
+  - domain: provider
+    interaction: remediation dispatch issued to restore intended configuration
+  - domain: audit
+    interaction: policy match, rule id, and remediation action recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- recovery-policy
+- auto-remediation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource is realized and carries a recovery policy with an auto-remediate rule
+  - Drift exists on a field the recovery policy governs
+  postconditions:
+  - Recovery policy fired and produced a remediation action
+  - Remediation dispatched to the provider
+  - Policy decision recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/004-reconciliation-loop-fixed-point.yaml b/dav/use-cases/hammer-drift-recovery/004-reconciliation-loop-fixed-point.yaml
new file mode 100644
index 0000000..07fe6e1
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/004-reconciliation-loop-fixed-point.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-drift-recovery-004
+handle: drift-recovery/reconciliation-loop-fixed-point
+scenario:
+  description: 'A platform engineer initiates reconciliation on a multi-resource application after a drift
+    is detected on a shared config value. The engine remediates, re-discovers, and re-diffs in a loop.
+    Each iteration must reduce the outstanding drift set, and the loop must terminate when a pass detects
+    zero drift — a fixed point — rather than looping indefinitely. The engine must prove convergence by
+    showing the drift set is empty and stable across a confirming pass. This validates that the reconciliation
+    loop is convergent and has a defined termination condition.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Drive a reconciliation loop to a stable zero-drift fixed point
+  success_criteria:
+  - Initial pass detects a non-empty drift set on the shared config
+  - Each iteration remediates, re-discovers, and re-diffs
+  - The outstanding drift set strictly shrinks or holds across iterations, never grows
+  - The loop terminates when a pass reports zero drift
+  - A confirming pass shows the drift set remains empty (fixed point reached)
+  - Iteration count and convergence result are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: drift set recomputed each iteration from Realized vs Discovered
+  - domain: policy
+    interaction: recovery policy drives remediation each pass until drift set empties
+  - domain: provider
+    interaction: corrective dispatches issued and re-discovered per iteration
+  - domain: audit
+    interaction: iteration count and convergence-to-fixed-point recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- reconciliation-loop
+- convergence
+- fixed-point
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A multi-resource application is realized with a detectable drift on a shared field
+  - A recovery policy governs the drifted field
+  postconditions:
+  - Reconciliation loop converged to a zero-drift fixed point
+  - Convergence confirmed by a stable follow-up pass
+  - Iteration history recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/005-minor-drift-tolerated.yaml b/dav/use-cases/hammer-drift-recovery/005-minor-drift-tolerated.yaml
new file mode 100644
index 0000000..ac24951
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/005-minor-drift-tolerated.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-drift-recovery-005
+handle: drift-recovery/minor-drift-tolerated
+scenario:
+  description: 'A dev-profile application team runs a reconciliation pass on a sandbox service. Discovery
+    reports that a provider-assigned tag was normalized to lowercase and a last-seen timestamp advanced
+    — cosmetic fields outside the declared intent. The engine must classify this divergence as minor drift
+    under the severity model, record it, and deliberately tolerate it: no remediation, no escalation.
+    This validates that drift severity classification exists and that a minor class exists which the system
+    can choose not to act on.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: dev
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Confirm that cosmetic minor drift is classified and tolerated without remediation
+  success_criteria:
+  - Discovery reports divergence only on cosmetic, non-intent-governed fields
+  - The engine classifies the divergence as minor severity
+  - The classification rationale (fields are outside declared intent) is captured
+  - No remediation action is generated
+  - No escalation is raised
+  - The tolerated minor-drift result is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: data
+    interaction: cosmetic field divergence identified against Realized snapshot
+  - domain: policy
+    interaction: severity model classifies the drift as minor and marks it tolerable
+  - domain: audit
+    interaction: tolerated minor-drift decision recorded with rationale
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- severity-classification
+- minor
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Sandbox service is realized
+  - Only cosmetic, non-intent fields diverged
+  postconditions:
+  - Drift classified minor and tolerated
+  - No remediation or escalation
+  - Decision recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/006-significant-drift-remediated.yaml b/dav/use-cases/hammer-drift-recovery/006-significant-drift-remediated.yaml
new file mode 100644
index 0000000..c1d80f4
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/006-significant-drift-remediated.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-drift-recovery-006
+handle: drift-recovery/significant-drift-remediated
+scenario:
+  description: 'An SRE reconciles a production API service whose discovered instance count has fallen
+    below the intended replica count after a provider-side autoscaler misfire. The engine must classify
+    this as significant drift — an intent-governed field materially off target but not a compliance violation
+    — and route it to automatic remediation that scales the service back to intent. This validates the
+    middle severity band: significant drift is neither ignored like minor nor frozen like critical, but
+    remediated on the normal path.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+  intent: Classify an intent-governed drift as significant and remediate it back to target
+  success_criteria:
+  - Discovery reports the instance count below the intended replica count
+  - The drift is classified as significant severity under the model
+  - The classification distinguishes it from both minor and critical bands
+  - Automatic remediation is selected on the normal path (no freeze, no mandatory escalation)
+  - A scale-up dispatch restores the intended replica count
+  - Severity classification and remediation outcome are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: discovered replica count diverges below intended count in Realized snapshot
+  - domain: policy
+    interaction: severity model classifies drift as significant; recovery policy selects remediation
+  - domain: provider
+    interaction: scale-up dispatch restores intended replica count
+  - domain: audit
+    interaction: significant classification and remediation outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- severity-classification
+- significant
+- remediation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Production API service is realized with an intended replica count
+  - Discovered replica count has fallen below intent
+  postconditions:
+  - Drift classified significant and remediated
+  - Replica count restored to intent
+  - Classification and outcome recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/007-critical-drift-halt-and-freeze.yaml b/dav/use-cases/hammer-drift-recovery/007-critical-drift-halt-and-freeze.yaml
new file mode 100644
index 0000000..1b25cc4
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/007-critical-drift-halt-and-freeze.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-drift-recovery-007
+handle: drift-recovery/critical-drift-halt-and-freeze
+scenario:
+  description: 'A security officer on an FSI profile oversees a realized database whose discovered encryption-at-rest
+    setting has flipped from enabled to disabled — a control the compliance posture treats as inviolable.
+    The engine must classify this as critical drift, and critical drift must NOT be silently auto-remediated:
+    the resource is frozen from further modification, an escalation is raised to a human owner, and the
+    compliance domain is notified before any corrective action. This validates the top severity band where
+    the safe action is halt-and-escalate, not blind self-healing.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Detect a critical control regression and halt-and-escalate rather than auto-heal
+  success_criteria:
+  - Discovery reports encryption-at-rest disabled against a Realized snapshot showing it enabled
+  - The drift is classified as critical severity
+  - Automatic silent remediation is NOT taken for a critical control regression
+  - The resource is frozen against further modification pending review
+  - A human escalation is raised and the compliance domain is notified
+  - Critical classification, freeze, and escalation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: encryption-at-rest field divergence detected against Realized snapshot
+  - domain: policy
+    interaction: severity model classifies critical; escalation policy blocks silent auto-remediation
+  - domain: audit
+    interaction: critical classification, freeze, and human escalation recorded
+  - domain: provider
+    interaction: no corrective dispatch issued until human review completes
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- severity-classification
+- critical
+- human-escalation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - FSI database is realized with encryption-at-rest enabled in the Realized snapshot
+  - Discovery reports the control disabled
+  postconditions:
+  - Drift classified critical; resource frozen
+  - Human escalation raised, compliance notified
+  - No auto-remediation dispatched pre-review
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/008-reconcile-budget-exhausted-escalate.yaml b/dav/use-cases/hammer-drift-recovery/008-reconcile-budget-exhausted-escalate.yaml
new file mode 100644
index 0000000..e103bd9
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/008-reconcile-budget-exhausted-escalate.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-drift-recovery-008
+handle: drift-recovery/reconcile-budget-exhausted-escalate
+scenario:
+  description: 'An SRE reconciles a resource whose recovery policy grants a bounded remediation budget
+    — a maximum number of corrective attempts within a grace window. Each remediation pass restores intent,
+    but a persistent external condition re-introduces the same drift before the next discovery. The engine
+    must count attempts against the budget, and once the budget is exhausted within the grace window it
+    must stop auto-remediating and escalate to a human owner instead of looping forever. This validates
+    that recovery has a defined give-up boundary rather than unbounded retry.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+  intent: Exhaust a bounded remediation budget then escalate instead of retrying indefinitely
+  success_criteria:
+  - Recovery policy defines a max attempt count within a grace window
+  - Each remediation restores intent but drift recurs before the next pass
+  - The engine counts remediation attempts against the budget
+  - When the budget is exhausted, auto-remediation stops
+  - A human escalation is raised carrying the attempt history and recurring-drift evidence
+  - Budget exhaustion and escalation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: recurring drift re-detected each pass against the Realized snapshot
+  - domain: policy
+    interaction: remediation attempts counted against budget; escalation fires on exhaustion
+  - domain: provider
+    interaction: repeated corrective dispatches issued until budget exhausted
+  - domain: audit
+    interaction: attempt history, budget exhaustion, and escalation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- remediation-budget
+- grace-window
+- escalation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource has a recovery policy with a bounded remediation budget and grace window
+  - An external condition keeps re-introducing the same drift
+  postconditions:
+  - Remediation budget exhausted; auto-remediation stopped
+  - Human escalation raised with attempt history
+  - Budget and escalation recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/009-authorized-provider-change-writes-realized.yaml b/dav/use-cases/hammer-drift-recovery/009-authorized-provider-change-writes-realized.yaml
new file mode 100644
index 0000000..3aa7884
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/009-authorized-provider-change-writes-realized.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-drift-recovery-009
+handle: drift-recovery/authorized-provider-change-writes-realized
+scenario:
+  description: 'A provider performs a sanctioned maintenance action — rotating a backing volume to new
+    hardware and reporting the new volume id back through the pipeline as an authorized change. Unlike
+    unsanctioned drift, this change arrives with a valid provider-originated authorization event, so the
+    engine must accept it, write a new immutable Realized snapshot capturing the new volume id, and record
+    that Realized advanced without ever classifying it as drift. This validates the distinction between
+    an authorized provider write to Realized and an unsanctioned divergence.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+  intent: Accept an authorized provider-originated change as a legitimate Realized update, not drift
+  success_criteria:
+  - The provider change arrives with a valid provider-originated authorization event
+  - The engine matches the change to its authorization rather than flagging drift
+  - A new immutable Realized snapshot is written capturing the new volume id
+  - The prior Realized snapshot is retained in history (not mutated in place)
+  - The resource is NOT marked drifted and no remediation is generated
+  - The authorized Realized advance is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: provider reports a sanctioned volume rotation with an authorization event
+  - domain: policy
+    interaction: change matched to authorization and admitted as authorized, not drift
+  - domain: data
+    interaction: new immutable Realized snapshot written; prior snapshot retained in history
+  - domain: audit
+    interaction: authorized Realized advance recorded with provider authorization reference
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- authorized-change
+- realized-write
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource is realized with a known Realized snapshot
+  - Provider issues a sanctioned change with an authorization event
+  postconditions:
+  - New Realized snapshot written; prior retained
+  - Resource not marked drifted
+  - Authorized advance recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/010-drift-on-policy-locked-field.yaml b/dav/use-cases/hammer-drift-recovery/010-drift-on-policy-locked-field.yaml
new file mode 100644
index 0000000..2c7a4ae
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/010-drift-on-policy-locked-field.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-drift-recovery-010
+handle: drift-recovery/drift-on-policy-locked-field
+scenario:
+  description: 'A compliance policy locks the network-tier field of a realized service to an approved
+    segmented VLAN; the lock declares the field non-negotiable and any deviation a policy breach. A provider-side
+    change moves the service onto a flat network. Reconciliation must detect drift on a field that is
+    not merely intent-governed but policy-locked, and treat it with elevated priority: the remediation
+    must restore the locked value AND the breach of the lock must be recorded as a governance event, not
+    just a routine drift fix. This validates that drift detection is aware of field-level policy locks.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Detect and remediate drift on a policy-locked field and record the lock breach
+  success_criteria:
+  - The network-tier field is marked policy-locked to an approved value
+  - Discovery reports the field moved off the locked value
+  - The engine recognizes the drift is on a policy-locked field, not just intent
+  - Remediation restores the locked value with elevated priority
+  - The breach of the field lock is recorded as a distinct governance event
+  - Drift, lock breach, and remediation are all captured in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: network-tier divergence detected against Realized snapshot
+  - domain: policy
+    interaction: field lock recognized; drift flagged as a lock breach and prioritized for remediation
+  - domain: provider
+    interaction: remediation dispatch restores the locked network-tier value
+  - domain: audit
+    interaction: drift, distinct lock-breach governance event, and remediation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- policy-lock
+- governance
+- compliance
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Network-tier field is policy-locked to an approved segmented VLAN
+  - Provider moved the service onto a flat network
+  postconditions:
+  - Locked value restored
+  - Lock breach recorded as a governance event
+  - Full arc captured in audit
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/011-out-of-band-edit-diverges-realized.yaml b/dav/use-cases/hammer-drift-recovery/011-out-of-band-edit-diverges-realized.yaml
new file mode 100644
index 0000000..14a7794
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/011-out-of-band-edit-diverges-realized.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-drift-recovery-011
+handle: drift-recovery/out-of-band-edit-diverges-realized
+scenario:
+  description: 'A tenant admin, bypassing the pipeline, edits a realized object store''s lifecycle-expiry
+    rule directly in the provider console. The Realized snapshot still records the pipeline-set 30-day
+    expiry; the live provider now reports 7 days. On the next pass the engine must surface that Discovered
+    has diverged from Realized due to an out-of-band edit, attribute the change to no sanctioned pipeline
+    event, and present the exact delta so an operator can decide whether to adopt the new value into intent
+    or remediate it away. This validates detection and clear attribution of out-of-band edits.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - tenancy-authority
+  intent: Surface an out-of-band console edit as a Discovered-vs-Realized divergence with a clear delta
+  success_criteria:
+  - Realized snapshot records the pipeline-set 30-day expiry
+  - Discovery reports a 7-day expiry set out-of-band in the provider console
+  - The engine detects the Discovered-vs-Realized divergence
+  - No sanctioned pipeline event is found to explain the change
+  - The exact field delta (30-day to 7-day) is presented for an adopt-or-remediate decision
+  - The out-of-band divergence and its attribution are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: discovered expiry diverges from the 30-day value in the Realized snapshot
+  - domain: policy
+    interaction: divergence attributed to no sanctioned event; flagged for adopt-or-remediate decision
+  - domain: provider
+    interaction: live provider state read revealing the out-of-band 7-day setting
+  - domain: audit
+    interaction: out-of-band divergence, delta, and attribution recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- out-of-band-edit
+- attribution
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Object store realized with a 30-day expiry in the Realized snapshot
+  - A console edit set expiry to 7 days outside the pipeline
+  postconditions:
+  - Divergence detected and attributed to an out-of-band edit
+  - Delta presented for adopt-or-remediate
+  - Divergence recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/012-remediation-redispatch-converge.yaml b/dav/use-cases/hammer-drift-recovery/012-remediation-redispatch-converge.yaml
new file mode 100644
index 0000000..fb22b0c
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/012-remediation-redispatch-converge.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-drift-recovery-012
+handle: drift-recovery/remediation-redispatch-converge
+scenario:
+  description: 'A platform engineer remediates a drifted DNS record whose discovered target IP no longer
+    matches intent. Remediation must not patch the Realized snapshot directly; instead the engine re-dispatches
+    the original intent through the normal provider path to overwrite the live value, then re-discovers
+    to confirm the live state now matches intent before writing a fresh Realized snapshot. This validates
+    that remediation is a real re-dispatch that converges live state to intent — reusing the standard
+    provision path — not a bookkeeping edit of the data model.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Remediate drift by re-dispatching intent through the provider and confirming convergence
+  success_criteria:
+  - Drift detected on the DNS target IP against the Realized snapshot
+  - Remediation re-dispatches the original intent through the normal provider path
+  - The Realized snapshot is NOT hand-patched to fake convergence
+  - A post-remediation Discovery confirms live state now matches intent
+  - A fresh Realized snapshot is written only after confirmed convergence
+  - Re-dispatch, confirmation, and snapshot write are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: drift detected; fresh Realized snapshot written only after confirmed convergence
+  - domain: policy
+    interaction: recovery policy selects re-dispatch of original intent as the remediation
+  - domain: provider
+    interaction: intent re-dispatched via the standard provision path; live value overwritten
+  - domain: audit
+    interaction: re-dispatch, post-remediation confirmation, and snapshot write recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- remediation
+- re-dispatch
+- convergence
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - DNS record realized with an intended target IP
+  - Discovered target IP has drifted
+  postconditions:
+  - Intent re-dispatched; live state converged to intent
+  - Fresh Realized snapshot written post-confirmation
+  - Remediation arc recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/013-drift-cascade-dependents.yaml b/dav/use-cases/hammer-drift-recovery/013-drift-cascade-dependents.yaml
new file mode 100644
index 0000000..a7be69b
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/013-drift-cascade-dependents.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-drift-recovery-013
+handle: drift-recovery/drift-cascade-dependents
+scenario:
+  description: 'An SRE reconciles a three-tier application where the database tier''s discovered connection
+    endpoint has drifted after a provider-side failover. Two dependent tiers were realized against the
+    old endpoint, so the base drift invalidates their realized configuration. The engine must detect the
+    base drift, recognize via the dependency graph that dependents are now inconsistent, and remediate
+    in dependency order — fixing the base first, then re-converging the dependents that referenced the
+    stale value. This validates drift handling that respects hard dependencies rather than treating each
+    resource in isolation.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - tenancy-authority
+  intent: Detect drift on a base resource and remediate its dependents in dependency order
+  success_criteria:
+  - Drift detected on the database endpoint against its Realized snapshot
+  - The dependency graph identifies the two tiers that reference the drifted endpoint
+  - Dependents are flagged as inconsistent due to the base drift
+  - Remediation proceeds in dependency order, base resource first
+  - Dependent tiers are re-converged to reference the corrected endpoint
+  - The cascade, ordering, and per-resource outcomes are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    provider_landscape: multiple_eligible
+    policy_complexity: recovery_policy
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: base drift detected; dependency graph reveals dependents referencing the stale endpoint
+  - domain: policy
+    interaction: recovery policy orders remediation by dependency, base before dependents
+  - domain: provider
+    interaction: base endpoint corrected, then dependent tiers re-dispatched to converge
+  - domain: audit
+    interaction: cascade, ordering, and per-resource outcomes recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- dependency-cascade
+- ordering
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Three-tier app realized; dependents reference the database endpoint
+  - Provider failover drifted the database endpoint
+  postconditions:
+  - Base drift and dependent inconsistency remediated in order
+  - All tiers converged to the corrected endpoint
+  - Cascade recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/014-drift-detection-provider-disconnect.yaml b/dav/use-cases/hammer-drift-recovery/014-drift-detection-provider-disconnect.yaml
new file mode 100644
index 0000000..9eae39e
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/014-drift-detection-provider-disconnect.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-drift-recovery-014
+handle: drift-recovery/drift-detection-provider-disconnect
+scenario:
+  description: 'An SRE runs a reconciliation pass but the provider hosting the resource is unreachable,
+    so fresh Discovery cannot complete. The engine cannot diff Realized against a Discovered state it
+    never obtained. It must NOT assume no-drift (silently declaring health) and must NOT assume worst-case
+    drift and remediate blindly against an unreachable target. The correct behavior is to mark reconciliation
+    indeterminate, hold the last known Realized snapshot, and surface a discovery-unavailable condition.
+    This likely probes an unsupported edge: safe handling of drift detection when the ground truth is
+    unobtainable.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - federation-peer-operator
+  intent: Reconcile a resource whose provider is unreachable without asserting a false drift verdict
+  success_criteria:
+  - Discovery fails because the provider is unreachable
+  - The engine does not diff against a missing Discovered state
+  - The engine does not silently declare the resource healthy (no-drift assumed)
+  - The engine does not blindly remediate against the unreachable provider
+  - Reconciliation is marked indeterminate and the last known Realized snapshot is held
+  - The discovery-unavailable condition is surfaced and recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: discovery attempt fails; provider unreachable, no live state obtained
+  - domain: data
+    interaction: last known Realized snapshot held; no Discovered state to diff against
+  - domain: policy
+    interaction: recovery policy declines to remediate against an unobservable target
+  - domain: audit
+    interaction: indeterminate reconciliation and discovery-unavailable condition recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- discovery-unavailable
+- provider-disconnect
+- unsupported-probe
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource is realized; provider is currently unreachable
+  - A recovery policy exists but requires observed state to act
+  postconditions:
+  - Reconciliation marked indeterminate
+  - No false verdict asserted; Realized snapshot held
+  - Discovery-unavailable condition recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/015-concurrent-drift-during-modification.yaml b/dav/use-cases/hammer-drift-recovery/015-concurrent-drift-during-modification.yaml
new file mode 100644
index 0000000..980872e
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/015-concurrent-drift-during-modification.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-drift-recovery-015
+handle: drift-recovery/concurrent-drift-during-modification
+scenario:
+  description: 'A platform engineer submits an intent modification to a resource at the same moment a
+    reconciliation pass detects unsanctioned drift on an overlapping field. The engine now holds two competing
+    sources of change: a sanctioned in-flight modification and a drift remediation, both targeting the
+    same field. It must serialize them coherently — not double-dispatch, not let remediation revert the
+    sanctioned modification, and not let the modification mask the drift finding. The engine must resolve
+    precedence and reach a single consistent Realized snapshot. This probes concurrency safety between
+    the modification and drift-detection paths.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Safely resolve a sanctioned modification racing with a drift remediation on the same field
+  success_criteria:
+  - A sanctioned modification and a drift remediation target the same field concurrently
+  - The engine detects the overlap rather than dispatching both blindly
+  - The two changes are serialized with a defined precedence rule
+  - Remediation does not silently revert the sanctioned modification
+  - The modification does not suppress or erase the drift finding
+  - A single consistent Realized snapshot and the conflict resolution are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: overlapping field targeted by both an in-flight modification and a drift remediation
+  - domain: policy
+    interaction: precedence rule serializes the two changes into one coherent outcome
+  - domain: provider
+    interaction: a single reconciled dispatch issued rather than two conflicting ones
+  - domain: audit
+    interaction: conflict, precedence decision, and final Realized snapshot recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- concurrency
+- modification-race
+- unsupported-probe
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A sanctioned modification is in flight on a resource
+  - Reconciliation detects drift on the same field simultaneously
+  postconditions:
+  - Changes serialized with defined precedence
+  - Single consistent Realized snapshot reached
+  - Conflict resolution recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/016-remediation-blocked-by-sovereignty.yaml b/dav/use-cases/hammer-drift-recovery/016-remediation-blocked-by-sovereignty.yaml
new file mode 100644
index 0000000..bf1086c
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/016-remediation-blocked-by-sovereignty.yaml
@@ -0,0 +1,69 @@
+uuid: uc-hammer-drift-recovery-016
+handle: drift-recovery/remediation-blocked-by-sovereignty
+scenario:
+  description: 'A security officer on a sovereign profile reconciles a residency-pinned dataset that drifted
+    when a provider replicated it to an out-of-jurisdiction cache. The obvious remediation — re-dispatch
+    the original intent — would itself require touching the non-compliant region to tear down the errant
+    replica, but the sovereignty policy forbids any operation that acts on data in that region. The engine
+    must detect the drift, attempt remediation, find that the corrective action is itself blocked by sovereignty,
+    and escalate to a human rather than either leaving the violation live or breaching residency to fix
+    it. This probes the tension when the remedy conflicts with a hard constraint.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: Remediate a residency drift where the corrective action is itself blocked by sovereignty
+  success_criteria:
+  - Drift detected as an out-of-jurisdiction replica of a residency-pinned dataset
+  - The engine selects remediation to remove the errant replica
+  - Sovereignty policy blocks the corrective action because it operates in the forbidden region
+  - The engine does not breach residency to perform the fix
+  - The unremediable violation is escalated to a human owner with full context
+  - Drift, blocked remediation, and escalation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: provider_failure
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: out-of-jurisdiction replica detected against the residency-pinned Realized snapshot
+  - domain: policy
+    interaction: recovery policy selects a fix that sovereignty then blocks; escalation raised
+  - domain: provider
+    interaction: corrective dispatch withheld to avoid operating in the forbidden region
+  - domain: audit
+    interaction: drift, blocked remediation, and human escalation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- sovereignty
+- blocked-remediation
+- escalation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Residency-pinned dataset realized in-jurisdiction
+  - A provider created an out-of-jurisdiction replica (drift)
+  postconditions:
+  - Remediation blocked by sovereignty; residency not breached
+  - Violation escalated to a human
+  - Full arc recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/017-flapping-no-fixed-point.yaml b/dav/use-cases/hammer-drift-recovery/017-flapping-no-fixed-point.yaml
new file mode 100644
index 0000000..82e5252
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/017-flapping-no-fixed-point.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-drift-recovery-017
+handle: drift-recovery/flapping-no-fixed-point
+scenario:
+  description: 'An SRE reconciles a resource whose live value is being continuously toggled by an external
+    controller the DCM does not own — every remediation is reverted within seconds, so the reconciliation
+    loop never reaches a fixed point. The engine must detect that it is flapping — remediating the same
+    field repeatedly with no lasting convergence — recognize this is not a convergent loop, and break
+    out: stop remediating, declare the resource non-convergent, and escalate. This probes what may be
+    an unsupported edge: distinguishing a genuinely convergent loop from a livelock and refusing to churn
+    forever.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+  intent: Detect a non-convergent flapping loop and break out instead of remediating forever
+  success_criteria:
+  - The same field is remediated and reverted repeatedly across passes
+  - The engine detects that no pass reaches a stable zero-drift fixed point
+  - Flapping is distinguished from a normal convergent loop via oscillation detection
+  - The engine stops remediating rather than churning indefinitely
+  - The resource is declared non-convergent and escalated to a human owner
+  - The oscillation pattern and non-convergence verdict are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: same-field drift re-detected every pass, never stabilizing
+  - domain: policy
+    interaction: oscillation detected; loop declared non-convergent and remediation halted
+  - domain: provider
+    interaction: repeated corrective dispatches reverted by an external controller
+  - domain: audit
+    interaction: oscillation pattern, non-convergence verdict, and escalation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- flapping
+- livelock
+- non-convergence
+- unsupported-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - An external controller continuously reverts the DCM's remediations
+  - Resource carries a recovery policy that keeps re-firing
+  postconditions:
+  - Flapping detected; remediation halted
+  - Resource declared non-convergent and escalated
+  - Oscillation recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/018-correct-immutable-realized-directly.yaml b/dav/use-cases/hammer-drift-recovery/018-correct-immutable-realized-directly.yaml
new file mode 100644
index 0000000..2d19d62
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/018-correct-immutable-realized-directly.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-drift-recovery-018
+handle: drift-recovery/correct-immutable-realized-directly
+scenario:
+  description: 'A platform engineer, seeing that a resource has drifted, asks the system to simply overwrite
+    the immutable Realized snapshot to match the newly discovered value — treating drift as a data-entry
+    error to be edited away. The architecture holds Realized snapshots immutable and advanced only by
+    authorized provider writes, so a direct hand-edit of a historical Realized record must be refused.
+    The engine must reject the in-place mutation and steer the operator to the legitimate paths: adopt
+    the discovered value into intent, or remediate the resource back to intent. This probes an edge that
+    should come back unsupported: mutating an immutable record.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Attempt to hand-edit an immutable Realized snapshot to erase a drift
+  success_criteria:
+  - The request asks to overwrite the immutable Realized snapshot in place
+  - The engine refuses to mutate the historical Realized record
+  - The refusal cites the immutability guarantee of Realized snapshots
+  - No new false snapshot is written to paper over the drift
+  - The operator is steered to legitimate paths (adopt-into-intent or remediate-to-intent)
+  - The rejected mutation attempt is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: in-place edit of an immutable Realized snapshot requested and refused
+  - domain: policy
+    interaction: immutability guarantee enforced; legitimate adopt/remediate paths offered
+  - domain: audit
+    interaction: rejected mutation attempt recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- immutability
+- realized-snapshot
+- unsupported-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource has drifted; a Realized snapshot exists
+  - Operator requests a direct edit of that snapshot
+  postconditions:
+  - Direct mutation refused; immutability upheld
+  - Operator steered to adopt-or-remediate
+  - Rejected attempt recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/019-silent-drift-below-discovery-resolution.yaml b/dav/use-cases/hammer-drift-recovery/019-silent-drift-below-discovery-resolution.yaml
new file mode 100644
index 0000000..e7c9507
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/019-silent-drift-below-discovery-resolution.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-drift-recovery-019
+handle: drift-recovery/silent-drift-below-discovery-resolution
+scenario:
+  description: 'A compliance auditor needs assurance that a realized firewall''s rule ordering matches
+    intent. The provider''s discovery interface reports the rule set but not the internal ordering — the
+    drifted attribute lives below the resolution of what discovery can observe. A provider-side reorder
+    therefore produces real drift that the Realized-vs-Discovered diff cannot see. The engine must not
+    report a false clean bill of health; it must recognize that the intent covers a field discovery cannot
+    verify and flag the resource as unverifiable for that attribute. This probes a likely-unsupported
+    gap: drift on fields beneath discovery resolution.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+    - security-officer
+  intent: Detect that a governed field is unverifiable because discovery cannot observe it
+  success_criteria:
+  - Intent governs firewall rule ordering
+  - Discovery reports the rule set but cannot observe internal ordering
+  - A provider-side reorder constitutes real drift invisible to the field diff
+  - The engine does NOT report a false clean/no-drift verdict for the unverifiable field
+  - The resource is flagged as unverifiable for the rule-ordering attribute
+  - The verifiability gap is recorded in the audit trail for the auditor
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent covers a field the Discovered state cannot express; diff cannot cover it
+  - domain: policy
+    interaction: field flagged unverifiable rather than defaulted to no-drift
+  - domain: provider
+    interaction: discovery interface cannot surface internal rule ordering
+  - domain: audit
+    interaction: verifiability gap recorded for the auditor
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- discovery-resolution
+- unverifiable-field
+- unsupported-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Intent governs a field discovery cannot observe (firewall rule ordering)
+  - A provider-side reorder occurred
+  postconditions:
+  - No false no-drift verdict issued
+  - Field flagged unverifiable
+  - Verifiability gap recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-drift-recovery/020-fleet-wide-drift-sweep-reconcile.yaml b/dav/use-cases/hammer-drift-recovery/020-fleet-wide-drift-sweep-reconcile.yaml
new file mode 100644
index 0000000..27dbe34
--- /dev/null
+++ b/dav/use-cases/hammer-drift-recovery/020-fleet-wide-drift-sweep-reconcile.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-drift-recovery-020
+handle: drift-recovery/fleet-wide-drift-sweep-reconcile
+scenario:
+  description: 'An SRE launches a scheduled fleet-wide reconciliation across a full-stack estate spanning
+    many resources and providers. The engine must discover every resource, diff each against its immutable
+    Realized snapshot, classify each drift by severity, and apply the governance matrix uniformly: tolerate
+    minor, auto-remediate significant, and freeze-and-escalate critical — all within one sweep, producing
+    a consolidated drift report. This validates that detection, severity classification, and policy-driven
+    response compose at fleet scale without per-resource special-casing, and that the sweep terminates
+    with an actionable summary.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - compliance-auditor
+  intent: Run a fleet-wide drift sweep that classifies and responds to each resource under one governance
+    matrix
+  success_criteria:
+  - Every in-scope resource is discovered and diffed against its immutable Realized snapshot
+  - Each detected drift is classified by severity (minor, significant, critical)
+  - The governance matrix is applied uniformly across the fleet
+  - Minor drift is tolerated, significant is auto-remediated, critical is frozen and escalated
+  - A consolidated drift report summarizes findings and actions per resource
+  - The sweep terminates with per-resource outcomes recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: mixed
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: every resource discovered across mixed providers in one sweep
+  - domain: data
+    interaction: each resource diffed against its immutable Realized snapshot
+  - domain: policy
+    interaction: governance matrix classifies severity and selects response per resource
+  - domain: audit
+    interaction: consolidated drift report and per-resource outcomes recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- drift-recovery
+- fleet-sweep
+- governance-matrix
+- severity-classification
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A full-stack estate is realized across mixed providers
+  - A governance matrix maps severity bands to responses
+  postconditions:
+  - Fleet swept; each drift classified and handled per matrix
+  - Consolidated drift report produced
+  - Per-resource outcomes recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/001-peer-provider-realization.yaml b/dav/use-cases/hammer-federation/001-peer-provider-realization.yaml
new file mode 100644
index 0000000..b99cc11
--- /dev/null
+++ b/dav/use-cases/hammer-federation/001-peer-provider-realization.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-federation-001
+handle: federation/peer-provider-realization
+scenario:
+  description: 'A platform engineer submits an intent for a database resource that can only be satisfied
+    by capacity another organization exposes through its own DCM. The local placement engine must treat
+    the peer DCM as a Provider: it dispatches the realization request across the federation boundary,
+    the peer realizes the resource in its own estate, and the returned realized handle is recorded locally
+    with a reference to the owning peer. This tests whether a peer realization can be a first-class Provider
+    in the placement model rather than a special case.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+  intent: Realize a resource whose only eligible provider is a peer DCM acting as a Provider
+  success_criteria:
+  - Intent is accepted and the placement engine identifies the peer DCM as an eligible provider
+  - Realization request is dispatched across the federation boundary to the peer
+  - Peer realizes the resource in its own estate and returns a realized handle
+  - Local realized state records the resource with a reference to the owning peer
+  - 'Ownership boundary is explicit: local DCM does not claim direct control of the peer-owned resource'
+  - Audit trail records the cross-boundary dispatch and the peer's acknowledgement
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent recorded; realized handle stored with peer-ownership reference
+  - domain: policy
+    interaction: validation confirms the peer is an admitted, eligible provider
+  - domain: provider
+    interaction: peer DCM realizes the resource and returns a handle across the boundary
+  - domain: audit
+    interaction: cross-boundary dispatch and peer acknowledgement recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- peer-provider
+- placement
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/002-federated-routing-policy.yaml b/dav/use-cases/hammer-federation/002-federated-routing-policy.yaml
new file mode 100644
index 0000000..dfdfc04
--- /dev/null
+++ b/dav/use-cases/hammer-federation/002-federated-routing-policy.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-federation-002
+handle: federation/routing-as-policy-governed-selection
+scenario:
+  description: 'An organization runs three peer DCMs it can route work to, but a governance policy constrains
+    which peer may receive which class of workload: regulated data must stay with the fsi-attested peer,
+    burst compute may go to the lowest-cost peer, and a default-deny applies to any peer not explicitly
+    authorized. A platform engineer submits an ambiguous intent and the placement engine must resolve
+    the target peer purely by evaluating the federation-routing policy chain, not by static configuration.
+    This tests whether federation routing is modeled as policy-governed provider selection.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Route an order to the correct peer DCM by evaluating federation-routing policy
+  success_criteria:
+  - Placement engine enumerates all peer DCMs as candidate providers
+  - Routing policy chain evaluates data-class, cost, and attestation constraints
+  - A peer not explicitly authorized is excluded by default-deny
+  - The selected peer satisfies every constraint in the chain
+  - The selection rationale (which policy admitted/denied each peer) is recorded
+  - No routing decision is made by static config bypassing the policy engine
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: federation-routing policy chain evaluates each peer against constraints
+  - domain: provider
+    interaction: placement engine selects the peer that satisfies the chain
+  - domain: audit
+    interaction: per-peer admit/deny rationale recorded for the routing decision
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- routing
+- policy-governed
+- provider-selection
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/003-peer-disconnect-mid-order.yaml b/dav/use-cases/hammer-federation/003-peer-disconnect-mid-order.yaml
new file mode 100644
index 0000000..6f5dfa7
--- /dev/null
+++ b/dav/use-cases/hammer-federation/003-peer-disconnect-mid-order.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-federation-003
+handle: federation/peer-disconnect-mid-order
+scenario:
+  description: 'A platform engineer dispatches a multi-resource order to a peer DCM. After the peer acknowledges
+    and begins realizing the second of four resources, the federation link drops and the peer becomes
+    unreachable, leaving the local DCM uncertain whether the in-flight resource was realized. The system
+    must not assume success or silently duplicate the resource; it must mark the order as indeterminate,
+    hold the dependent resources, and expose a recovery path that reconciles once the peer returns. This
+    tests the architecture''s handling of a peer disconnect mid-operation.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - federation-peer-operator
+  intent: Survive a peer DCM disconnect mid-order without data loss or duplication
+  success_criteria:
+  - Order is dispatched and the peer acknowledges before the link drops
+  - Local DCM detects the peer became unreachable during realization
+  - The in-flight resource is marked indeterminate rather than success or failure
+  - Dependent resources are held, not dispatched against an unknown state
+  - No duplicate realization is issued blindly on reconnect
+  - On peer return, a reconciliation step compares realized state and resolves the order
+  - Audit trail records the disconnect, the indeterminate window, and the reconciliation
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peer becomes unreachable mid-realization; in-flight resource state unknown
+  - domain: policy
+    interaction: recovery policy holds dependents and forbids blind re-dispatch
+  - domain: data
+    interaction: order marked indeterminate; reconciled against peer realized state on return
+  - domain: audit
+    interaction: disconnect, indeterminate window, and reconciliation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- peer-disconnect
+- recovery
+- failure-mode
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/004-cross-dcm-causal-ordering.yaml b/dav/use-cases/hammer-federation/004-cross-dcm-causal-ordering.yaml
new file mode 100644
index 0000000..f43d992
--- /dev/null
+++ b/dav/use-cases/hammer-federation/004-cross-dcm-causal-ordering.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-federation-004
+handle: federation/cross-dcm-causal-ordering-no-clock
+scenario:
+  description: 'Two peer DCMs each emit operations that reference each other''s resources — peer A creates
+    a network segment, peer B attaches a workload that causally depends on A''s segment, and A later modifies
+    the segment. There is no shared clock across the federation, so wall-clock timestamps cannot establish
+    the true order of these cross-DCM operations. The system must reconstruct a correct causal ordering
+    from explicit causal references (which operation observed which), not from timestamps. This likely
+    probes a gap: DCM ordering is structural per-estate, and cross-DCM causal ordering without a shared
+    clock may be unsupported.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Establish a correct cross-DCM operation order using causal references, not clocks
+  success_criteria:
+  - Operations from both peers carry explicit causal references to observed resources
+  - The system reconstructs an ordering consistent with all causal references
+  - Wall-clock timestamps are NOT used to break cross-DCM ordering
+  - Concurrent operations with no causal link are flagged as unordered, not falsely serialized
+  - If the model cannot represent cross-DCM causal references, the gap is reported explicitly
+  - The resulting order (or the inability to derive one) is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: cross-DCM operations carry causal references; ordering derived from them
+  - domain: policy
+    interaction: policy requires causal consistency, forbidding clock-based tie-breaking
+  - domain: audit
+    interaction: derived order or the unsupported-gap finding recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- causal-ordering
+- no-shared-clock
+- likely-unsupported
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/005-cross-signed-audit-checkpoint.yaml b/dav/use-cases/hammer-federation/005-cross-signed-audit-checkpoint.yaml
new file mode 100644
index 0000000..629bae6
--- /dev/null
+++ b/dav/use-cases/hammer-federation/005-cross-signed-audit-checkpoint.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-federation-005
+handle: federation/cross-signed-audit-checkpoint
+scenario:
+  description: 'A compliance auditor requires that every federation interaction produce an audit checkpoint
+    signed by BOTH peers, so neither can later repudiate a cross-boundary operation. When peer A dispatches
+    an order to peer B, each side records the same checkpoint (order hash, timestamps, outcome) and cross-signs
+    it with its own key, yielding a tamper-evident record verifiable by either party independently. This
+    tests whether the audit domain can produce and verify cross-signed checkpoints between peers rather
+    than isolated per-estate logs.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - federation-peer-operator
+    - regulator
+  intent: Produce and verify a mutually cross-signed audit checkpoint for a federation interaction
+  success_criteria:
+  - A cross-boundary operation triggers a checkpoint recorded on both peers
+  - Each peer signs the checkpoint with its own key
+  - The checkpoint content (order hash, outcome) is identical on both sides
+  - Either peer can independently verify the other's signature over the shared content
+  - A tampered or missing counter-signature is detectable and flagged
+  - The cross-signed checkpoint is retained in both audit trails
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: provider
+    interaction: cross-boundary operation dispatched to the peer
+  - domain: audit
+    interaction: both peers record and cross-sign an identical checkpoint; signatures verifiable
+  - domain: policy
+    interaction: policy requires a valid counter-signature before the interaction is deemed complete
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- audit
+- cross-signed
+- non-repudiation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/006-split-brain-single-writer.yaml b/dav/use-cases/hammer-federation/006-split-brain-single-writer.yaml
new file mode 100644
index 0000000..af25868
--- /dev/null
+++ b/dav/use-cases/hammer-federation/006-split-brain-single-writer.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-federation-006
+handle: federation/split-brain-single-writer-authority
+scenario:
+  description: 'Two peer DCMs both hold intent for a shared resource — a jointly-operated network fabric
+    — and, during a federation partition, each independently accepts a conflicting modification. When
+    the partition heals, the system detects a split-brain: two divergent intents for one resource. Resolution
+    must defer to the single-writer authority designated for that resource (only the owning peer''s write
+    is authoritative); the non-authoritative write is rejected and its originator notified. This tests
+    whether split-brain on a shared resource is resolved by single-writer authority rather than last-write-wins
+    or silent merge.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - federation-peer-operator
+  intent: Resolve a split-brain on a shared resource via single-writer authority
+  success_criteria:
+  - Both peers accept conflicting modifications during the partition
+  - On heal, the system detects divergent intent for the same shared resource
+  - The designated single-writer (owning peer) is identified for the resource
+  - The authoritative write is retained; the non-authoritative write is rejected
+  - Resolution is NOT last-write-wins and NOT a silent field-level merge
+  - The rejected originator is notified with the reason
+  - The split-brain event and resolution are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: divergent intents detected for one shared resource on partition heal
+  - domain: policy
+    interaction: single-writer authority policy selects the authoritative write and rejects the other
+  - domain: audit
+    interaction: split-brain detection and authority-based resolution recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- split-brain
+- single-writer
+- consistency
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/007-peer-ahead-model-version.yaml b/dav/use-cases/hammer-federation/007-peer-ahead-model-version.yaml
new file mode 100644
index 0000000..8dd89df
--- /dev/null
+++ b/dav/use-cases/hammer-federation/007-peer-ahead-model-version.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-federation-007
+handle: federation/peer-ahead-of-ratified-model-version
+scenario:
+  description: 'A peer DCM has adopted a newer UDLM model version than the locally ratified one and dispatches
+    an order that uses a resource type and fields the local model does not yet recognize. The local DCM
+    must not blindly reject the whole interaction nor silently drop the unknown fields; it must detect
+    the version skew, apply a compatibility rule (accept known fields, quarantine unknown ones, or refuse
+    with a clear version-mismatch reason), and never persist a resource it cannot faithfully represent.
+    This tests federation across a model-version boundary and likely surfaces a gap in forward-compat.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+  intent: Handle an order from a peer running a model version ahead of the ratified one
+  success_criteria:
+  - Local DCM detects the peer is on a newer model version than ratified locally
+  - Unknown resource types/fields are identified rather than silently dropped
+  - A defined compatibility rule is applied (accept-known / quarantine-unknown / refuse)
+  - No resource is persisted that the local model cannot faithfully represent
+  - The peer receives a clear version-mismatch outcome, not an opaque failure
+  - If no forward-compat rule exists, the gap is reported as unsupported
+  - The version skew and disposition are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: model version skew detected; unknown fields quarantined not dropped
+  - domain: policy
+    interaction: compatibility policy decides accept/quarantine/refuse for unknown schema
+  - domain: audit
+    interaction: version mismatch and disposition recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- model-version
+- forward-compat
+- likely-unsupported
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/008-federated-contribution-admission.yaml b/dav/use-cases/hammer-federation/008-federated-contribution-admission.yaml
new file mode 100644
index 0000000..2f18b6f
--- /dev/null
+++ b/dav/use-cases/hammer-federation/008-federated-contribution-admission.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-federation-008
+handle: federation/federated-contribution-admission
+scenario:
+  description: 'A peer DCM offers to contribute a provider capability (a specialized GPU pool) into the
+    local estate''s catalog so local teams can order against it. This contribution must pass admission
+    before it becomes orderable: the local DCM evaluates the peer''s offered capability against admission
+    policy (attestation valid, capability schema conformant, category permitted, default-deny otherwise).
+    Only on admission does the contributed capability appear as an eligible provider. This tests federated
+    contribution admission — a peer adding to, not just consuming from, the local estate.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Admit a peer-contributed provider capability into the local catalog under policy
+  success_criteria:
+  - Peer submits a capability contribution with attestation and a conformant schema
+  - Admission policy evaluates attestation, schema conformance, and category permission
+  - A non-conformant or unattested contribution is denied by default-deny
+  - Only an admitted contribution becomes an eligible provider for local orders
+  - Provenance (which peer contributed the capability) is retained on the catalog entry
+  - The admission decision and rationale are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: admission policy evaluates attestation, schema, and category; default-deny
+  - domain: provider
+    interaction: admitted capability registered as an eligible provider with peer provenance
+  - domain: audit
+    interaction: contribution admission decision and rationale recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- contribution
+- admission
+- catalog
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/009-sovereign-peer-local-audit-export.yaml b/dav/use-cases/hammer-federation/009-sovereign-peer-local-audit-export.yaml
new file mode 100644
index 0000000..8d60e06
--- /dev/null
+++ b/dav/use-cases/hammer-federation/009-sovereign-peer-local-audit-export.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-federation-009
+handle: federation/sovereign-peer-local-audit-manual-export
+scenario:
+  description: 'A sovereign peer DCM, operating under a mandate that no audit record may leave its jurisdiction
+    automatically, participates in a federation interaction. When the local DCM requests a cross-signed
+    checkpoint, the sovereign peer must keep its audit trail local-only and provide no automatic export;
+    instead it produces a manually-releasable export package that a human authority reviews and releases
+    out-of-band. The local DCM must complete the interaction knowing the peer''s audit is authoritative-but-local,
+    accepting a deferred/manual proof rather than a live one. This tests sovereign local-only audit with
+    manual export inside a federation.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Interact with a sovereign peer whose audit is local-only with manual export
+  success_criteria:
+  - Sovereign peer participates without auto-exporting any audit record
+  - Live cross-signed checkpoint export is refused per sovereignty mandate
+  - The peer produces a manually-releasable export package instead
+  - Release requires human authority review out-of-band; no automatic transfer occurs
+  - Local DCM completes the interaction accepting a deferred/manual audit proof
+  - The sovereignty constraint and the deferred-proof arrangement are recorded locally
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: human_escalation_required
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty mandate forbids auto-export; requires human-released package
+  - domain: audit
+    interaction: peer audit retained local-only; manual export package produced on human release
+  - domain: provider
+    interaction: interaction completes on a deferred/manual proof rather than a live checkpoint
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- sovereignty
+- local-only-audit
+- manual-export
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/010-peer-attestation-gate.yaml b/dav/use-cases/hammer-federation/010-peer-attestation-gate.yaml
new file mode 100644
index 0000000..d638349
--- /dev/null
+++ b/dav/use-cases/hammer-federation/010-peer-attestation-gate.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-federation-010
+handle: federation/peer-trust-attestation-gate
+scenario:
+  description: 'Before any order may be dispatched to a peer DCM, the local DCM requires a fresh trust
+    attestation from that peer (signed capability posture, valid within a bounded window). A security
+    officer initiates an order to a peer whose attestation has just expired. The interaction must be gated:
+    the placement engine refuses to select the peer until a fresh, verifiable attestation is presented,
+    and re-attestation unblocks the exact same order without re-authoring it. This tests peer trust/attestation
+    gating an interaction as a precondition, not an afterthought.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Gate a federation interaction on a fresh, verifiable peer attestation
+  success_criteria:
+  - Order targets a peer whose trust attestation has expired
+  - Placement engine refuses to select the peer while attestation is stale
+  - The order is held (not failed outright) pending re-attestation
+  - A fresh attestation is verified against the peer's key and validity window
+  - Re-attestation unblocks the same order without re-authoring it
+  - A forged or out-of-window attestation is rejected
+  - The gate decision, refusal, and later admission are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the attestation Validation Policy blocks peer selection until fresh proof is verified
+  - domain: provider
+    interaction: peer becomes selectable only after re-attestation; order proceeds unchanged
+  - domain: audit
+    interaction: gate refusal, verification, and admission recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- attestation
+- trust-gate
+- security
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/011-peer-catalog-discovery.yaml b/dav/use-cases/hammer-federation/011-peer-catalog-discovery.yaml
new file mode 100644
index 0000000..63e1386
--- /dev/null
+++ b/dav/use-cases/hammer-federation/011-peer-catalog-discovery.yaml
@@ -0,0 +1,50 @@
+uuid: uc-hammer-federation-011
+handle: federation/peer-catalog-discovery
+scenario:
+  description: 'A platform engineer wants to see what a trusted peer DCM can provide before authoring
+    any order. The local DCM queries the peer''s published catalog and lists the offered resource types
+    and capabilities, read-only, with no resource created and no commitment made. This is the simple happy-path
+    baseline for federation: a peer exposes an orderable catalog and the local DCM can enumerate it.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - federation-peer-operator
+  intent: Discover a trusted peer DCM's published catalog of orderable capabilities
+  success_criteria:
+  - Local DCM issues a read-only catalog query to the peer
+  - Peer returns its published, orderable resource types and capabilities
+  - No resource is created and no commitment is made by the query
+  - Offerings are attributed to the peer as their source
+  - The peer's published model version is visible alongside the catalog
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: peer_dcm_required
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peer returns its published catalog to a read-only query
+  - domain: data
+    interaction: offerings enumerated locally with peer attribution; nothing persisted as owned
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- catalog
+- discovery
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/012-peer-liveness-heartbeat.yaml b/dav/use-cases/hammer-federation/012-peer-liveness-heartbeat.yaml
new file mode 100644
index 0000000..6ad7fee
--- /dev/null
+++ b/dav/use-cases/hammer-federation/012-peer-liveness-heartbeat.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-federation-012
+handle: federation/peer-liveness-heartbeat
+scenario:
+  description: 'An SRE relies on a periodic liveness signal from each federated peer DCM to know whether
+    it is reachable before routing work to it. The local DCM records the peer''s heartbeat and reachability
+    status, and a peer that misses its window is marked unreachable so the placement engine can avoid
+    it. This is a simple day-2 baseline: federation health is observable, and staleness is a first-class
+    state.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+    - provider-owner
+    - federation-peer-operator
+  intent: Track peer DCM liveness so placement can avoid unreachable peers
+  success_criteria:
+  - Each peer's heartbeat is received and its reachability status recorded
+  - A peer that misses its heartbeat window is marked unreachable
+  - The placement engine can read peer reachability before routing
+  - Reachability transitions (up/down) are timestamped
+  - No order is dispatched to a peer currently marked unreachable
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: peer_dcm_required
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peer heartbeat received; reachability status maintained
+  - domain: data
+    interaction: reachability transitions recorded with timestamps
+  - domain: policy
+    interaction: default routing rule excludes peers marked unreachable
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- liveness
+- heartbeat
+- day-2
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/013-cross-dcm-hard-dependency.yaml b/dav/use-cases/hammer-federation/013-cross-dcm-hard-dependency.yaml
new file mode 100644
index 0000000..10edbb9
--- /dev/null
+++ b/dav/use-cases/hammer-federation/013-cross-dcm-hard-dependency.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-federation-013
+handle: federation/cross-dcm-hard-dependency-realize
+scenario:
+  description: 'A platform engineer authors a full-stack order where an application tier realized locally
+    has a hard dependency on a network fabric that only a peer DCM can realize. The placement engine must
+    order the realization across the boundary: the peer''s fabric must be realized and confirmed before
+    the local application tier is dispatched, with the cross-DCM dependency edge honored exactly as a
+    local hard dependency would be. This tests whether the dependency graph and realization ordering span
+    the federation boundary for hard dependencies.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - federation-peer-operator
+  intent: Realize a local resource whose hard dependency is realized by a peer DCM
+  success_criteria:
+  - Dependency graph includes a cross-DCM edge from local app tier to peer-realized fabric
+  - Peer fabric is realized and confirmed before the local tier is dispatched
+  - The cross-boundary hard dependency is enforced, not treated as soft/best-effort
+  - If the peer cannot realize the dependency, the dependent local resource is not dispatched
+  - UUIDs and the cross-DCM dependency reference are recorded consistently on both sides
+  - The ordered cross-boundary realization is captured in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: cross-DCM hard-dependency edge recorded in the dependency graph
+  - domain: provider
+    interaction: peer realizes the dependency first; local tier dispatched only after confirmation
+  - domain: policy
+    interaction: ordering policy enforces the cross-boundary hard dependency
+  - domain: audit
+    interaction: ordered cross-boundary realization recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- hard-dependency
+- cross-dcm
+- ordering
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/014-federated-capacity-borrow.yaml b/dav/use-cases/hammer-federation/014-federated-capacity-borrow.yaml
new file mode 100644
index 0000000..ba7adbc
--- /dev/null
+++ b/dav/use-cases/hammer-federation/014-federated-capacity-borrow.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-federation-014
+handle: federation/federated-capacity-borrow
+scenario:
+  description: 'Local capacity is exhausted and a finance-approved burst policy allows borrowing compute
+    from a peer DCM up to a bounded quota. A platform engineer submits an order the local estate cannot
+    place; the placement engine, seeing local exhaustion and a valid borrow authorization, routes the
+    overflow to an eligible peer within the borrow quota and attributes the borrowed usage back for chargeback.
+    Exceeding the borrow quota must be denied. This tests federated capacity borrowing as a policy-bounded
+    overflow to a peer provider.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: prod
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+  intent: Borrow bounded compute capacity from a peer DCM when local capacity is exhausted
+  success_criteria:
+  - Local placement fails on capacity exhaustion for the submitted order
+  - A valid borrow authorization with a bounded quota is present
+  - Overflow is routed to an eligible peer within the borrow quota
+  - Borrowed usage is attributed back to the requester for chargeback
+  - An order exceeding the remaining borrow quota is denied, not silently placed
+  - The borrow decision, quota consumption, and attribution are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: borrow policy authorizes bounded overflow and denies quota breach
+  - domain: provider
+    interaction: peer provider realizes the overflow within quota
+  - domain: data
+    interaction: borrowed usage attributed for chargeback; quota consumption tracked
+  - domain: audit
+    interaction: borrow decision and attribution recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- capacity
+- borrow
+- chargeback
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/015-peer-credential-scoping.yaml b/dav/use-cases/hammer-federation/015-peer-credential-scoping.yaml
new file mode 100644
index 0000000..9bf2926
--- /dev/null
+++ b/dav/use-cases/hammer-federation/015-peer-credential-scoping.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-federation-015
+handle: federation/peer-credential-scoping
+scenario:
+  description: 'When the local DCM dispatches to a peer, it must present a credential scoped strictly
+    to the federation interaction — authorized for the specific capability being ordered and nothing more,
+    with a short validity. A security officer verifies that the peer accepts a correctly-scoped credential,
+    rejects one whose scope exceeds the ordered capability, and rejects an expired one, so a federation
+    credential cannot be replayed to reach unrelated peer resources. This tests least-privilege credential
+    scoping at the federation boundary.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+  intent: Enforce least-privilege, correctly-scoped credentials on federation dispatch
+  success_criteria:
+  - Local DCM presents a credential scoped to exactly the ordered capability
+  - Peer accepts a correctly-scoped, unexpired credential
+  - A credential scoped beyond the ordered capability is rejected
+  - An expired credential is rejected
+  - The credential cannot be replayed to reach unrelated peer resources
+  - Credential issuance, scope, and acceptance/rejection are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: scoping policy issues a least-privilege, short-lived federation credential
+  - domain: provider
+    interaction: peer validates scope and expiry; rejects over-scoped or expired credentials
+  - domain: audit
+    interaction: credential scope and acceptance/rejection recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- credentials
+- least-privilege
+- security
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/016-peer-decommission-dangling-dependent.yaml b/dav/use-cases/hammer-federation/016-peer-decommission-dangling-dependent.yaml
new file mode 100644
index 0000000..efe3d21
--- /dev/null
+++ b/dav/use-cases/hammer-federation/016-peer-decommission-dangling-dependent.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-federation-016
+handle: federation/peer-decommission-dangling-dependent
+scenario:
+  description: 'A platform engineer decommissions a resource realized by a peer DCM, but a workload in
+    a THIRD peer''s estate still depends on it. The local DCM must not let the peer tear down a resource
+    with a live cross-DCM dependent: it must discover the dangling dependent across the federation, block
+    or stage the decommission, and require the dependent be resolved first. Worse, if the dependent''s
+    owning peer is unreachable, the system cannot even confirm the dependency is gone. This tests cross-DCM
+    decommission safety with a dangling dependent and a possibly-unreachable peer.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+  intent: Safely decommission a peer-realized resource that a third peer still depends on
+  success_criteria:
+  - Decommission target is a peer-realized resource with a cross-DCM dependent
+  - The system discovers the dangling dependent in the third peer's estate
+  - Teardown is blocked or staged while a live dependent exists
+  - The dependent must be resolved before the decommission proceeds
+  - If the dependent's owning peer is unreachable, decommission is held as indeterminate, not forced
+  - The blocked decommission and dependency findings are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: cross-DCM dependency graph queried; dangling dependent discovered
+  - domain: policy
+    interaction: decommission-safety policy blocks teardown with a live dependent
+  - domain: provider
+    interaction: dependent's owning peer unreachable, so removal cannot be confirmed
+  - domain: audit
+    interaction: blocked decommission and dependency findings recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- decommission
+- dangling-dependent
+- failure-mode
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/017-federated-drift-detection.yaml b/dav/use-cases/hammer-federation/017-federated-drift-detection.yaml
new file mode 100644
index 0000000..6f92bad
--- /dev/null
+++ b/dav/use-cases/hammer-federation/017-federated-drift-detection.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-federation-017
+handle: federation/federated-drift-on-peer-realized-resource
+scenario:
+  description: 'A resource realized on the local engineer''s behalf by a peer DCM has drifted: the peer''s
+    realized state no longer matches the intent the local DCM recorded. Because the local DCM does not
+    directly control the peer-owned resource, it must detect the drift from the peer''s reported realized
+    state, and it cannot simply re-converge on its own — remediation must be requested of the owning peer.
+    This tests drift detection and remediation authority across a federation boundary, where the detector
+    and the controller are different DCMs.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - federation-peer-operator
+  intent: Detect and remediate drift on a peer-realized resource across the federation boundary
+  success_criteria:
+  - Local DCM compares recorded intent against the peer's reported realized state
+  - Drift on the peer-realized resource is detected
+  - Local DCM does not attempt direct re-convergence on a resource it does not control
+  - A remediation request is issued to the owning peer
+  - Remediation authority (owning peer) is respected; local DCM tracks the request outcome
+  - Drift detection and the cross-boundary remediation request are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: recorded intent compared to peer-reported realized state; drift found
+  - domain: policy
+    interaction: recovery policy routes remediation to the owning peer, not local re-converge
+  - domain: provider
+    interaction: owning peer executes remediation on request; outcome tracked locally
+  - domain: audit
+    interaction: drift and cross-boundary remediation request recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- drift
+- remediation-authority
+- day-2
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/018-peer-provider-portable-rehydration.yaml b/dav/use-cases/hammer-federation/018-peer-provider-portable-rehydration.yaml
new file mode 100644
index 0000000..65c23bf
--- /dev/null
+++ b/dav/use-cases/hammer-federation/018-peer-provider-portable-rehydration.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-federation-018
+handle: federation/rehydrate-when-original-peer-gone
+scenario:
+  description: 'A disaster destroys resources that were originally realized by a peer DCM which has since
+    left the federation and no longer exists. During rehydration, the platform engineer needs the stored
+    intent re-realized, but the original provider (the departed peer) is unreachable and unrecoverable.
+    The system must rehydrate provider-portably: re-run placement against the CURRENT federation, bind
+    the intent to a different eligible peer (or local capacity), and preserve identity — without hard-coding
+    the departed peer. If nothing else can satisfy the intent, it must report the gap rather than fail
+    opaquely. This likely surfaces a portability edge.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - federation-peer-operator
+  intent: Rehydrate resources whose original peer-provider has left the federation
+  success_criteria:
+  - Stored intent and dependency graph are available for the destroyed resources
+  - The original peer-provider is recognized as gone/unreachable
+  - Placement is re-run against the current federation, not the departed peer
+  - Intent is re-bound to a different eligible provider (peer or local) preserving identity
+  - No rehydration step hard-depends on the departed peer
+  - If no current provider can satisfy the intent, the gap is reported as unsupported
+  - The portable rehydration (or the gap) is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: stored intent read; departed peer's realized handles recognized as unrecoverable
+  - domain: policy
+    interaction: validation re-evaluated; portability rule forbids binding to the departed peer
+  - domain: provider
+    interaction: placement re-runs against current federation and re-binds intent
+  - domain: audit
+    interaction: portable rehydration or unsupported-gap finding recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- rehydration
+- provider-portable
+- likely-unsupported
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/019-cross-peer-policy-conflict.yaml b/dav/use-cases/hammer-federation/019-cross-peer-policy-conflict.yaml
new file mode 100644
index 0000000..35b73be
--- /dev/null
+++ b/dav/use-cases/hammer-federation/019-cross-peer-policy-conflict.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-federation-019
+handle: federation/cross-peer-policy-conflict
+scenario:
+  description: 'A shared order spans two peer DCMs whose governing policies conflict: the local estate''s
+    residency policy forbids placing data outside its region, while the peer that must realize part of
+    the order enforces a policy that would place it elsewhere. Neither peer may unilaterally override
+    the other. The system must detect the cross-domain policy conflict up front, refuse to proceed on
+    an unsatisfiable intersection, and surface exactly which two policies collide — rather than letting
+    one side''s policy silently win. This tests conflict detection when governance is split across federation
+    peers.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Detect and refuse a federation order where two peers' policies conflict
+  success_criteria:
+  - The order requires realization spanning two peers with governing policies
+  - The system computes the intersection of both peers' applicable policies
+  - The residency conflict is detected before any realization occurs
+  - Neither peer's policy silently overrides the other
+  - The order is refused as unsatisfiable, naming the two colliding policies
+  - The conflict finding and refusal are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: both peers' policies intersected; residency conflict detected; order refused
+  - domain: provider
+    interaction: no realization occurs on the unsatisfiable intersection
+  - domain: audit
+    interaction: named policy collision and refusal recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- policy-conflict
+- residency
+- governance
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-federation/020-peer-audit-chain-verification.yaml b/dav/use-cases/hammer-federation/020-peer-audit-chain-verification.yaml
new file mode 100644
index 0000000..b3f4308
--- /dev/null
+++ b/dav/use-cases/hammer-federation/020-peer-audit-chain-verification.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-federation-020
+handle: federation/peer-audit-chain-verification
+scenario:
+  description: 'A compliance auditor must independently verify a peer DCM''s account of a completed federation
+    interaction. The peer provides its audit chain for the interaction; the local DCM re-verifies the
+    chain''s integrity (each entry links to the prior, the peer''s signatures are valid, and the peer''s
+    entries agree with the local cross-signed checkpoints). A broken link or a peer entry that disagrees
+    with the local checkpoint must be flagged as an integrity failure. This tests whether a peer''s audit
+    chain is independently verifiable across the federation, not merely trusted.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - federation-peer-operator
+    - regulator
+  intent: Independently verify a peer DCM's audit chain for a federation interaction
+  success_criteria:
+  - Peer supplies its audit chain for the completed interaction
+  - Local DCM verifies each entry links to its predecessor (chain integrity)
+  - The peer's signatures over each entry are validated
+  - Peer entries are reconciled against the local cross-signed checkpoints
+  - A broken link or a disagreeing entry is flagged as an integrity failure
+  - The verification outcome (pass or the specific failure) is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: fsi
+  expected_domain_interactions:
+  - domain: audit
+    interaction: peer audit chain verified for linkage, signatures, and checkpoint agreement
+  - domain: policy
+    interaction: integrity policy flags broken links or disagreeing entries as failures
+  - domain: data
+    interaction: peer entries reconciled against locally-held cross-signed checkpoints
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- federation
+- audit
+- chain-verification
+- integrity
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-intent-fulfillment/001-operational-dependency-cascade.yaml b/dav/use-cases/hammer-intent-fulfillment/001-operational-dependency-cascade.yaml
new file mode 100644
index 0000000..32d9779
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/001-operational-dependency-cascade.yaml
@@ -0,0 +1,63 @@
+uuid: uc-3d4c61ef-81c3-4db8-8ce6-a0b83f11e39d
+handle: intent-fulfillment/operational-dependency-cascade
+version: 1.0.0
+scenario:
+  description: >-
+    A consumer declares an intent with a container that operationally depends on a PVC (an
+    operational dependency: a hard, directional, Realized-layer coupling — the container cannot
+    function without the volume). The PVC cannot realize now for a transient reason (no eligible
+    storage capacity). Because the dependency nature is operational, the container is blocked
+    while its dependency is unsatisfied — classified blocked-transient, not failed and never
+    realized dangling against a volume that is not there. The convergence window is open (w>0),
+    so the container waits and converges the moment the PVC realizes. Independent members of the
+    same intent (a ConfigMap, an unrelated service) proceed and realize — the operational block
+    is scoped to the directional chain, not the whole intent. Crucially the consumer is told: a
+    warning names the PVC as the root unsatisfied dependency, why (transient capacity), and that
+    the container will converge when the PVC does.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: >-
+    Hold a container blocked-transient while its operational PVC dependency is unrealized, let
+    independent members proceed, and converge the container when the PVC realizes — surfacing the
+    root dependency as an actionable warning
+  success_criteria:
+  - The container is classified blocked-transient while the PVC is unrealized — not failed, not realized dangling
+  - The PVC is classified as the root unsatisfied dependency, transiently unrealizable (converges later)
+  - Independent members with no dependency on the PVC realize (the operational block is scoped to the directional chain)
+  - When the PVC realizes, the container converges automatically via the reconciliation loop — no re-request
+  - The consumer receives a warning naming the PVC as the root, the reason, and the expected resolution — not only a structured field
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: none_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the operational (hard, directional) dependency edge makes the container's realization conditional on the PVC's
+  - domain: policy
+    interaction: operational nature blocks the dependent while unsatisfied; independents proceed; block is transient (converges)
+  - domain: provider
+    interaction: no eligible storage now; the reconciliation loop re-attempts the PVC, then the container
+  - domain: audit
+    interaction: the blocked-transient container, the root PVC, and the convergence are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- operational-dependency
+- convergence
+- surfacing
diff --git a/dav/use-cases/hammer-intent-fulfillment/002-operational-transitive-refusal.yaml b/dav/use-cases/hammer-intent-fulfillment/002-operational-transitive-refusal.yaml
new file mode 100644
index 0000000..feefcf5
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/002-operational-transitive-refusal.yaml
@@ -0,0 +1,61 @@
+uuid: uc-30145f26-68ae-43c9-96ec-551fde9ad2be
+handle: intent-fulfillment/operational-transitive-refusal
+version: 1.0.0
+scenario:
+  description: >-
+    A three-member chain: an app operationally depends on a container, which operationally
+    depends on a PVC. The PVC is permanently refused (a sovereignty/policy violation — it will
+    never realize unless the intent changes). Because permanence is refused immediately
+    regardless of the convergence window, the PVC does not wait. Its dependents inherit the
+    status transitively along the operational chain: the container, operationally blocked by a
+    now-refused dependency, becomes blocked-permanent (refused); the app, operationally blocked
+    by the refused container, inherits the same. None of the three realizes dangling. The whole
+    operational chain is surfaced together as a single refusal-with-resolution that names the
+    ROOT — the PVC and its violated rule — and the chain it took down, so the consumer is never
+    told to wait for a member that can never converge. Members outside this operational chain
+    still proceed.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: >-
+    Propagate a permanent refusal down the operational chain — refused PVC to blocked-permanent
+    container to blocked-permanent app — and surface the whole chain as one refusal naming the
+    root dependency and its rule
+  success_criteria:
+  - A permanently-refused PVC is classified refused immediately, regardless of the convergence window
+  - The container operationally depending on it is classified blocked-permanent (refused), inheriting the status transitively
+  - The app operationally depending on the container inherits blocked-permanent along the chain — no member realizes dangling
+  - The surface is a single refusal-with-resolution naming the ROOT (the PVC and its violated rule) plus the affected chain
+  - Members outside this operational chain still realize — the permanent cascade is scoped to the directional dependency path
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: multi_dependent
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: operational edges make each member's realization conditional on its dependency's; status inherits along the chain
+  - domain: policy
+    interaction: permanent refusal at the root propagates as blocked-permanent down the operational chain, immediately (window-independent)
+  - domain: audit
+    interaction: the root refusal, the violated rule, and the transitively-refused chain are recorded together
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- operational-dependency
+- transitive-refusal
+- surfacing
diff --git a/dav/use-cases/hammer-intent-fulfillment/003-request-dependency-atomic.yaml b/dav/use-cases/hammer-intent-fulfillment/003-request-dependency-atomic.yaml
new file mode 100644
index 0000000..3910c17
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/003-request-dependency-atomic.yaml
@@ -0,0 +1,62 @@
+uuid: uc-1dc7115d-636a-4e33-afe8-8f662d9623ea
+handle: intent-fulfillment/request-dependency-atomic
+version: 1.0.0
+scenario:
+  description: >-
+    A consumer declares ten peer VMs coupled by a request dependency — an Intent/Requested-layer
+    coupling meaning "I want these as a unit" (a mutual, non-directional nature, distinct from an
+    operational "can't function without"). Because a request dependency binds at request time, it
+    yields both atomic faces from one nature. One VM cannot be satisfied for a transient reason:
+    while the convergence window is open, the WHOLE unit is held together — no VM activates, every
+    member sits at Requested (reserved where possible, ADR-011 validate-and-reserve, which is
+    reservation not activation) — this is hold-all. If the member becomes permanently
+    unsatisfiable, the whole coupled request cancels together and none goes live — this is
+    cancel-all. Both are the single behavior of the request nature: the unit is held up until all
+    can activate, and cancelled down if any member cannot. The consumer's surface names the
+    blocking member and that the request-coupling binds the unit.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: >-
+    Hold ten request-coupled peer VMs as one unit — none activating while any member is
+    unsatisfiable — activating all atomically when every member can, and cancelling the whole unit
+    if a member is permanently unsatisfiable
+  success_criteria:
+  - No VM activates (transitions to Realized) while any request-coupled peer cannot activate — hold-all under an open window
+  - Members are held at Requested (reserved where possible per ADR-011); reservation is not activation — no VM runs while siblings are held
+  - When every member can activate, all commit to Realized atomically — none partially ahead of the others
+  - A permanently-unsatisfiable member cancels the whole coupled request unit — cancel-all — with no member realized
+  - The surface names the blocking member and that the request-nature coupling binds the whole unit (hold-all up, cancel-all down)
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: a request dependency binds the peers as one unit at the Requested layer; members held at Requested, atomic transition to Realized
+  - domain: policy
+    interaction: request nature yields hold-all activation (up) and cancel-all (down) from one binding — the two atomic faces
+  - domain: provider
+    interaction: reserve across all members (ADR-011) before any activates; no reservation becomes an activation until all can
+  - domain: audit
+    interaction: the request-coupling, the blocking member, and the atomic activation or whole-unit cancel are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- request-dependency
+- atomic
+- convergence
diff --git a/dav/use-cases/hammer-intent-fulfillment/004-request-vs-operational-distinction.yaml b/dav/use-cases/hammer-intent-fulfillment/004-request-vs-operational-distinction.yaml
new file mode 100644
index 0000000..f9faf3b
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/004-request-vs-operational-distinction.yaml
@@ -0,0 +1,60 @@
+uuid: uc-51bdeca2-6b74-484c-a848-82c5a5718e62
+handle: intent-fulfillment/request-vs-operational-distinction
+version: 1.0.0
+scenario:
+  description: >-
+    The same two members, member A and member B, one of which cannot be satisfied — under two
+    different dependency natures, producing two legitimately different behaviors. The nature is
+    the ONE thing that differs. Under an OPERATIONAL edge (B operationally depends on A: a hard,
+    directional, Realized-layer coupling), A unsatisfiable blocks B directionally — B is blocked,
+    A is unaffected as a dependency source, and any member independent of A proceeds. Under a
+    REQUEST edge (A and B coupled as a unit: a mutual, Intent-layer coupling), the same shortfall
+    holds BOTH — neither activates, the unit is held together (or cancelled together if
+    permanent). Neither behavior is a defect: directional cascade with independents proceeding is
+    correct for operational coupling; whole-unit hold/cancel is correct for request coupling. The
+    platform reads the declared nature and applies the matching propagation; it never imposes one
+    on the other.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: >-
+    Apply directional operational cascade (dependent blocked, independents proceed) versus mutual
+    request coupling (whole unit held or cancelled) to the same two members purely by their
+    declared dependency nature, treating both as correct
+  success_criteria:
+  - Under an operational edge, an unsatisfiable A blocks only its directional dependent B; members independent of A proceed
+  - Under a request edge, the same unsatisfiable member holds the whole unit — neither A nor B activates (mutual, non-directional)
+  - The nature is the only differing input; the two propagation behaviors follow deterministically from it
+  - Neither behavior is treated as a defect — directional cascade and whole-unit coupling are each correct for their nature
+  - The consumer surface distinguishes the two — a blocked directional dependent versus a held mutual unit — naming the driving nature
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the dependency edge carries a nature (operational | request); the same two members differ only by that field
+  - domain: policy
+    interaction: operational nature propagates directionally (independents proceed); request nature couples the unit (hold-all/cancel-all)
+  - domain: audit
+    interaction: the declared nature and the propagation it selected are recorded for each case
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- dependency-nature
+- request-vs-operational
+- boundary
diff --git a/dav/use-cases/hammer-intent-fulfillment/005-convergence-window.yaml b/dav/use-cases/hammer-intent-fulfillment/005-convergence-window.yaml
new file mode 100644
index 0000000..b0eeb60
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/005-convergence-window.yaml
@@ -0,0 +1,63 @@
+uuid: uc-670360d1-cd6a-427e-953f-a46cb270548f
+handle: intent-fulfillment/convergence-window
+version: 1.0.0
+scenario:
+  description: >-
+    The same transiently-unsatisfiable member (a container whose PVC has no capacity yet) under
+    three settings of the convergence window w — the only converge-versus-fail-fast dial in the
+    model. At w=0 (fail-fast) the member is given up immediately: it does not wait for the
+    transient blocker, it is refused now, and its operational dependents are dependency-cancelled.
+    At w=N (converge-then-give-up) the member waits and converges if the blocker clears within the
+    bound; if the window expires first, it is given up like w=0. At w=infinity (defer) the member
+    waits indefinitely, held pending, converging whenever the blocker clears. The member status is
+    transient throughout — the window governs how long a transient member is allowed to converge,
+    not whether it can. A permanent member would be refused immediately under every w; the window
+    modulates transient members only. Each setting produces a distinct, correct outcome the
+    consumer chooses.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: >-
+    Have the same transient member behave as fail-fast at w=0, converge-then-give-up at w=N, and
+    defer indefinitely at w=infinity — the window being the sole dial over how long a transient
+    member may converge
+  success_criteria:
+  - At w=0 the transient member is given up immediately (fail-fast) and its operational dependents are dependency-cancelled
+  - At w=N the member converges if its transient blocker clears within the bound, else is given up when the window expires
+  - At w=infinity the member is held pending and converges whenever the blocker clears — no deadline
+  - The member status stays transient across all three; the window governs how long it may converge, not whether it can
+  - A permanent member would be refused immediately regardless of w — the window modulates transient members only
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multiple_interacting
+    provider_landscape: none_eligible
+    governance_context: standard_governance
+    failure_mode: timeout
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the convergence window w is an intent field on the member; member status (transient|permanent) is separate
+  - domain: policy
+    interaction: w=0 fail-fast, w=N converge-then-give-up, w=infinity defer — the sole converge-vs-fail-fast dial, applied to transient members
+  - domain: provider
+    interaction: the reconciliation loop re-attempts the member until it converges or the window expires
+  - domain: audit
+    interaction: the window setting, the convergence or give-up, and any dependency-cancellation are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- convergence-window
+- fail-fast
+- defer
diff --git a/dav/use-cases/hammer-intent-fulfillment/006-soft-operational-does-not-block.yaml b/dav/use-cases/hammer-intent-fulfillment/006-soft-operational-does-not-block.yaml
new file mode 100644
index 0000000..af670ad
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/006-soft-operational-does-not-block.yaml
@@ -0,0 +1,60 @@
+uuid: uc-0e2052cf-1975-48f7-bfab-bf6f27713480
+handle: intent-fulfillment/soft-operational-does-not-block
+version: 1.0.0
+scenario:
+  description: >-
+    A container operationally depends on a DNS service, but the edge is SOFT (dependencies[].strength:
+    soft) — the container works better with it but can function without it. DNS is unrealized. Because
+    a soft operational dependency never blocks, the container still converges and realizes — degraded,
+    not blocked, not held. The convergence window is irrelevant to the container here: it does not wait
+    on a soft dependency at all. The unsatisfied soft dependency is not silent, though — the container
+    is surfaced as realized-degraded with a warning naming the missing DNS and what capability is
+    reduced, so the operator sees the degradation and can act. This is the hard/soft distinction the
+    registry already ships (strength: hard|soft), read through the operational nature: hard operational
+    blocks the dependent; soft operational lets it converge degraded and surfaces the shortfall.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: >-
+    Let a container converge and realize degraded when its soft operational DNS dependency is
+    unrealized — never blocked, never held — surfacing the degradation with the missing dependency
+    named
+  success_criteria:
+  - The container realizes despite its soft operational dependency (DNS) being unrealized — degraded, not blocked
+  - The container is not held pending on the soft dependency — the convergence window does not gate it
+  - The unsatisfied soft dependency is surfaced as a warning naming the missing DNS and the reduced capability — not silent
+  - The distinction is the edge strength (soft vs hard) under the operational nature — soft never blocks, hard does
+  - Were the same edge hard, the container would instead be blocked (per operational-dependency-cascade) — the strength is what differs
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the operational edge carries strength soft (dependencies[].strength); the container realizes degraded, not dangling
+  - domain: policy
+    interaction: soft operational dependency never blocks the dependent — converge degraded; hard would block
+  - domain: provider
+    interaction: DNS unrealized; the container is realized without it, capability reduced
+  - domain: audit
+    interaction: the degraded realization and the missing soft dependency are recorded and surfaced
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- soft-dependency
+- degraded
+- surfacing
diff --git a/dav/use-cases/hammer-intent-fulfillment/007-pending-converges-later.yaml b/dav/use-cases/hammer-intent-fulfillment/007-pending-converges-later.yaml
new file mode 100644
index 0000000..a001387
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/007-pending-converges-later.yaml
@@ -0,0 +1,60 @@
+uuid: uc-61045358-119e-47f9-989c-aa0e2a2eae39
+handle: intent-fulfillment/pending-converges-later
+version: 1.0.0
+scenario:
+  description: >-
+    An intent left a container blocked-transient on a PVC that had no capacity (the operational
+    convergence case, w>0). Later, storage capacity frees. The reconciliation loop realizes the
+    previously-pending PVC and then the container that operationally depended on it — with no new
+    consumer request. The original intent was persistent desired state, not a one-shot command, so
+    the held members converge on their own when the transient blocker clears. The consumer's
+    surfaced state updates from blocked-transient to realized and the shortfall warning clears.
+    This is the persistence proof under the nature model: a transient member (and the operational
+    dependents it was holding) converges later, driven by reconciliation, traceable to the
+    original intent.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: >-
+    Have a persistent intent's blocked-transient member and its operational dependents converge to
+    Realized later via reconciliation, with no re-request and the surfaced state updating
+  success_criteria:
+  - The blocked-transient PVC realizes when its transient blocker clears, driven by reconciliation, not a new request
+  - The container that operationally depended on it converges once the PVC realizes — the held chain proceeds automatically
+  - The original intent persisted as desired state across the gap (held, not discarded)
+  - The consumer's surfaced shortfall clears when the members reach Realized
+  - The convergence event is auditable back to the original intent — no duplicate or conflicting realization
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: Intent persists as desired state; realized state is its current projection; held members carry blocked-transient
+  - domain: policy
+    interaction: reconciliation converges the transient member and its operational dependents without re-request
+  - domain: provider
+    interaction: capacity frees; reserve+realize the held PVC, then the container
+  - domain: audit
+    interaction: convergence traces to the original intent
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- convergence
+- desired-state
+- reconciliation
diff --git a/dav/use-cases/hammer-intent-fulfillment/008-surface-names-root.yaml b/dav/use-cases/hammer-intent-fulfillment/008-surface-names-root.yaml
new file mode 100644
index 0000000..9e392c2
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/008-surface-names-root.yaml
@@ -0,0 +1,59 @@
+uuid: uc-fb444232-1717-48ad-baf2-3209b3433acf
+handle: intent-fulfillment/surface-names-root
+version: 1.0.0
+scenario:
+  description: >-
+    A chain fails — a PVC is refused, taking down the container that operationally depends on it
+    and the app above — and the platform surfaces only the immediate member: "container failed."
+    This is REFUSED as insufficient surfacing. The surfacing contract requires naming the ROOT
+    unsatisfied dependency (the PVC and its violated rule) and the chain it took down, so the
+    consumer can act on the actual cause instead of chasing the symptom. Telling the consumer the
+    container failed, without naming that the container was blocked-permanent because its PVC was
+    refused, sends them to fix the wrong thing. A surface that stops at the immediate member and
+    does not name the root dependency plus the chain does not satisfy the contract, even though it
+    did emit a warning. Naming the proximate failure is not the same as naming the root.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: >-
+    Refuse a chain-failure surface that names only the immediate member and not the root
+    unsatisfied dependency plus the chain — the root and chain are the mandatory content of the
+    surface
+  success_criteria:
+  - A surface naming only the immediate member ("container failed") without the root dependency is refused as insufficient surfacing
+  - The required surface names the ROOT unsatisfied dependency (the PVC and its violated rule) and the operational chain it took down
+  - Emitting a warning is not sufficient if it does not name the root — content, not just presence, is the contract
+  - '"The consumer could have traced the chain themselves" is explicitly not a sufficient defense'
+  - The root-naming requirement holds on every chain-failure path, transient or permanent
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: multi_dependent
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the surfacing contract requires the root dependency plus chain; naming only the proximate member is refused
+  - domain: data
+    interaction: the surface must carry the root unsatisfied dependency and the transitive chain, not just the immediate member
+  - domain: audit
+    interaction: the insufficient (root-less) surface is recorded as a refusal
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- surfacing
+- must-reject
+- root-cause
diff --git a/dav/use-cases/hammer-intent-fulfillment/009-surfacing-mandatory.yaml b/dav/use-cases/hammer-intent-fulfillment/009-surfacing-mandatory.yaml
new file mode 100644
index 0000000..789a17f
--- /dev/null
+++ b/dav/use-cases/hammer-intent-fulfillment/009-surfacing-mandatory.yaml
@@ -0,0 +1,58 @@
+uuid: uc-196cb096-c65d-4601-b3e9-ba5b6d799fe6
+handle: intent-fulfillment/surfacing-mandatory
+version: 1.0.0
+scenario:
+  description: >-
+    A realization completes an intent partially and reports the shortfall ONLY as a structured
+    partial_failures field, with no warning surfaced to the consumer — who can miss it entirely
+    and believe the intent was fully satisfied. This is REFUSED as insufficient surfacing: an
+    unsatisfiable intent the consumer is not actively told about is a silent failure, whatever the
+    dependency nature or window that produced it. A field is not a signal. The mandatory surface is
+    a warning (for a transient shortfall) or a refusal-with-resolution (for a permanent one): what
+    was not realized, why, and how to resolve it. The refusal here is of the SURFACING, not of the
+    partial realization itself — converging the satisfiable members while a transient member stays
+    pending is correct; hiding that fact behind a missable field is not.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: >-
+    Refuse a partial realization whose shortfall is expressed only as a missable field and never
+    surfaced to the consumer as an actionable warning or refusal-with-resolution
+  success_criteria:
+  - A partial realization that surfaces its shortfall only as a structured field (no warning) is refused as insufficient surfacing
+  - 'The required surface is a warning (transient) or refusal-with-resolution (permanent): what was not realized, why, and how to resolve it'
+  - The refusal is of the SURFACING, not the partial realization itself — converging satisfiable members is correct
+  - '"The consumer could have read the field" is explicitly not a sufficient defense'
+  - The surfacing requirement holds on every partial-fulfillment path, whatever the nature or window that produced the shortfall
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: surfacing an unsatisfiable intent is mandatory, not optional; a field is not a signal
+  - domain: data
+    interaction: the warning or refusal-with-resolution is a first-class output, distinct from the partial_failures record
+  - domain: audit
+    interaction: the missing-surface refusal is recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: intent-fulfillment-nature-2026-07-27
+  timestamp: '2026-07-27T18:00:00Z'
+tags:
+- hammer
+- intent-fulfillment
+- surfacing
+- must-reject
+- intent-requirement
diff --git a/dav/use-cases/hammer-multi-cluster/001-provision-spoke-via-hub.yaml b/dav/use-cases/hammer-multi-cluster/001-provision-spoke-via-hub.yaml
new file mode 100644
index 0000000..c132e59
--- /dev/null
+++ b/dav/use-cases/hammer-multi-cluster/001-provision-spoke-via-hub.yaml
@@ -0,0 +1,49 @@
+uuid: uc-multi-cluster-001
+handle: multi-cluster/provision-spoke-via-hub
+version: 1.0.0
+scenario:
+  description: "A platform engineer requests a new cluster through the fleet's hub: the hub (hosted-control-planes\
+    \ capable) provisions the spoke and hosts its control plane. The request binds on the hub's realized\
+    \ outputs (hub_ready) before dispatch; the resulting spoke is contained_by the hub \u2014 the hub\
+    \ has lifecycle authority, and shutdown ordering tears spokes down before the hub. This stresses the\
+    \ hub-provisioned topology end to end: intent against Platform.Hub, a Compute.Cluster realized under\
+    \ it, the containment edge authored by realization."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Provision a hosted-control-plane spoke cluster through a Platform.Hub and verify containment
+    ordering and output binding
+  success_criteria:
+  - The provisioning request binds on the hub's hub_ready output, contract-checked
+  - The realized spoke carries contained_by -> the hub (lifecycle authority)
+  - Shutdown order derives spokes-before-hub with no additional authoring
+  - The hub's managed_cluster_count output reflects the new spoke at next reconciliation
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the containment edge and hub outputs are the authored/published record
+  - domain: policy
+    interaction: validation confirms the hub is admitted for cluster provisioning
+  - domain: provider
+    interaction: the multi-cluster provider (OCM/CAPI-class) realizes the spoke under the hub
+  - domain: audit
+    interaction: provisioning path and binding resolution are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: multi-cluster-2026-07-24
+  timestamp: '2026-07-24T21:00:00.000000+00:00'
+tags:
+- multi-cluster
+- platform-hub
+- hosted-control-planes
+- binding
diff --git a/dav/use-cases/hammer-multi-cluster/002-move-cluster-between-hubs.yaml b/dav/use-cases/hammer-multi-cluster/002-move-cluster-between-hubs.yaml
new file mode 100644
index 0000000..0288e27
--- /dev/null
+++ b/dav/use-cases/hammer-multi-cluster/002-move-cluster-between-hubs.yaml
@@ -0,0 +1,51 @@
+uuid: uc-multi-cluster-002
+handle: multi-cluster/move-cluster-between-hubs
+version: 1.0.0
+scenario:
+  description: "An imported spoke migrates from one hub's fleet to another \u2014 a management-plane change\
+    \ with zero workload impact expected. Because imported management is a soft depends_on edge (OCM detach/import\
+    \ semantics), the move is: detach (edge removed), import (new edge to the target hub), workloads untouched\
+    \ throughout. This stresses management-plane portability: the cluster's identity, workloads, and other\
+    \ dependencies are invariant under the hub move, and both hubs' fleet rollups update."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - executive
+  intent: Detach an imported cluster from one hub and import it into another with workload continuity
+    and correct fleet accounting
+  success_criteria:
+  - The cluster entity keeps its UUID and all non-hub edges across the move
+  - Workloads on the cluster are unaffected (soft management semantics honored)
+  - The old hub's managed_cluster_count decrements and the new hub's increments
+  - Audit shows detach and import as governed operations, not silent edge edits
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: multiple_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the management edge is replaced; everything else is invariant
+  - domain: policy
+    interaction: the target hub's admission and any placement policy re-validate the import
+  - domain: provider
+    interaction: both hub providers execute detach/import per OCM semantics
+  - domain: audit
+    interaction: the move is two governed operations with before/after fleet state
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: multi-cluster-2026-07-24
+  timestamp: '2026-07-24T21:00:00.000000+00:00'
+tags:
+- multi-cluster
+- portability
+- hub-migration
+- ocm
diff --git a/dav/use-cases/hammer-multi-cluster/003-hub-jurisdiction-vs-spoke-sovereignty.yaml b/dav/use-cases/hammer-multi-cluster/003-hub-jurisdiction-vs-spoke-sovereignty.yaml
new file mode 100644
index 0000000..8838ef0
--- /dev/null
+++ b/dav/use-cases/hammer-multi-cluster/003-hub-jurisdiction-vs-spoke-sovereignty.yaml
@@ -0,0 +1,54 @@
+uuid: uc-multi-cluster-003
+handle: multi-cluster/hub-jurisdiction-vs-spoke-sovereignty
+version: 1.0.0
+scenario:
+  description: "A sovereign-profile tenant requires that management-plane control of their clusters stays\
+    \ within jurisdiction: the spokes are compliant, but the HUB managing them runs elsewhere. Management\
+    \ is control \u2014 a hub outside the jurisdiction can mutate in-jurisdiction workloads. This stresses\
+    \ that the hub's own sovereignty position (its location, its provider's sovereignty declaration) is\
+    \ evaluated as part of the spokes' sovereignty posture, not just the spokes' data residency; a non-compliant\
+    \ hub placement is rejected or flagged for the affected spokes."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Evaluate spoke sovereignty including the managing hub's jurisdiction and reject or flag management
+    from outside the required jurisdiction
+  success_criteria:
+  - The hub's location/sovereignty declaration participates in each managed spoke's compliance evaluation
+  - A spoke requiring in-jurisdiction management cannot be imported into an out-of-jurisdiction hub
+  - An existing compliant fleet flags when the hub's declared sovereignty changes (discovered drift)
+  - The evaluation distinguishes data residency (spoke) from control residency (hub) explicitly
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_constrained
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the hub's sovereignty declaration and location edge are the evaluated facts
+  - domain: policy
+    interaction: sovereignty policy composes spoke residency with hub control residency
+  - domain: provider
+    interaction: hub providers declare sovereignty like any provider; changes are drift
+  - domain: audit
+    interaction: control-residency evaluations and rejections are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: multi-cluster-2026-07-24
+  timestamp: '2026-07-24T21:00:00.000000+00:00'
+tags:
+- multi-cluster
+- sovereignty
+- control-residency
+- platform-hub
diff --git a/dav/use-cases/hammer-multi-cluster/004-self-managed-hub-rehydration.yaml b/dav/use-cases/hammer-multi-cluster/004-self-managed-hub-rehydration.yaml
new file mode 100644
index 0000000..408f0b4
--- /dev/null
+++ b/dav/use-cases/hammer-multi-cluster/004-self-managed-hub-rehydration.yaml
@@ -0,0 +1,54 @@
+uuid: uc-multi-cluster-004
+handle: multi-cluster/self-managed-hub-rehydration
+version: 1.0.0
+scenario:
+  description: "The self-managed pattern: the hub runs on a cluster it also manages, its reflexive management\
+    \ edge correctly demoted to references so the ordering graph stays acyclic (ADR-043). Then the host\
+    \ cluster is lost \u2014 taking the hub and its runtime state with it. Rehydration must replay the\
+    \ HUB's intent from the estate (the intent store, not the dead hub), rebuild it (possibly on a new\
+    \ host), re-adopt surviving imported spokes (soft edges \u2014 they kept running), and rebuild hosted\
+    \ spokes from their own intent. This stresses the hardest multi-cluster question: what rehydrate-the-manager\
+    \ means when the manager's home was inside its own blast radius."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: 'Rehydrate a self-managed hub after losing its host cluster: replay hub intent, re-adopt surviving
+    spokes, rebuild hosted spokes from intent'
+  success_criteria:
+  - The hub rebuilds from estate-stored intent, not from any state that died with the host
+  - Surviving imported spokes re-attach without workload disruption (soft edge semantics)
+  - Hosted spokes rebuild from their own intent with lineage to the originals
+  - The reflexive references edge and derived hub role re-derive on the new topology
+  - At no point does an ordering cycle exist in the rebuilt graph (CYCLE gate clean throughout)
+  dimensions:
+    lifecycle_phase: recovery
+    resource_complexity: composite_service
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: infrastructure_loss
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent in the estate is the single recovery source; derived markers re-derive
+  - domain: policy
+    interaction: rehydration re-evaluates under current policy (RHY-001 semantics)
+  - domain: provider
+    interaction: the multi-cluster provider rebuilds the hub and re-runs adoption
+  - domain: audit
+    interaction: the recovery sequence and re-adoptions are fully recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: multi-cluster-2026-07-24
+  timestamp: '2026-07-24T21:00:00.000000+00:00'
+tags:
+- multi-cluster
+- rehydration
+- self-managed-hub
+- adr-043
diff --git a/dav/use-cases/hammer-multi-tenancy/001-cross-tenant-read-denied.yaml b/dav/use-cases/hammer-multi-tenancy/001-cross-tenant-read-denied.yaml
new file mode 100644
index 0000000..357da1b
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/001-cross-tenant-read-denied.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-tenancy-001
+handle: tenancy/cross-tenant-read-denied
+scenario:
+  description: 'An application-team member in tenant B crafts an intent that names a resource UUID owned
+    by tenant A, attempting to read its realized state and cross-reference its payload. The store boundary
+    and validation layer must recognize that the requesting principal''s tenant scope does not include
+    the target resource and reject the request before any store read returns tenant-A data. This tests
+    whether tenant ownership is a first-class, enforced scope on the four-state stores rather than an
+    advisory label.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Prove a cross-tenant read of another tenant's resource is rejected at the boundary
+  success_criteria:
+  - Request naming tenant-A UUID from a tenant-B principal is rejected
+  - No tenant-A intent or realized payload is returned to the caller
+  - Rejection cites tenant-scope violation, not a generic not-found that leaks existence
+  - The store query is scoped by tenant before evaluation, not filtered after fetch
+  - The denied attempt is recorded in the audit trail with both tenant identities
+  - No provider dispatch is triggered by the rejected request
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: store read is scoped by requesting tenant; cross-tenant UUID resolves to no visible record
+  - domain: policy
+    interaction: tenant-isolation constraint evaluates ownership before returning any payload
+  - domain: audit
+    interaction: denied cross-tenant access recorded with source and target tenant identities
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- isolation
+- data-leakage
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/002-decommission-shared-pool-stakes.yaml b/dav/use-cases/hammer-multi-tenancy/002-decommission-shared-pool-stakes.yaml
new file mode 100644
index 0000000..1d0581b
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/002-decommission-shared-pool-stakes.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-tenancy-002
+handle: tenancy/decommission-shared-pool-stakes
+scenario:
+  description: 'Tenant A is being decommissioned, but it is the declared owner of a shareable IPAddressPool
+    from which tenants B and C hold active IPAddress allocations. The platform engineer requests full
+    decommission of tenant A. The system must detect that the owned pool still has live cross-tenant stakes
+    and refuse to destroy it, or require an ownership hand-off first. This probes whether decommission
+    understands that ownership and consumption are separable, and whether a shared allocatable resource
+    can outlive the tenant that provisioned it.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - tenancy-authority
+  intent: Decommission a tenant that owns a shared pool still consumed by other tenants
+  success_criteria:
+  - Decommission enumerates resources owned by tenant A, including the shared pool
+  - System detects live IPAddress allocations held by tenants B and C against the pool
+  - Full decommission is blocked or gated pending pool ownership hand-off
+  - Tenant B and C allocations are never orphaned or silently revoked
+  - Blocking rationale distinguishes ownership from consumption
+  - The blocked decommission and its dependency findings are recorded in audit
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph traversed to find cross-tenant consumers of the owned pool
+  - domain: policy
+    interaction: decommission-safety policy blocks destruction of a pool with foreign stakes
+  - domain: provider
+    interaction: provider is not asked to release the pool while allocations remain
+  - domain: audit
+    interaction: blocked decommission recorded with the offending cross-tenant dependencies
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- decommission
+- shared-pool
+- dangling-dependents
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/003-per-tenant-profile-override.yaml b/dav/use-cases/hammer-multi-tenancy/003-per-tenant-profile-override.yaml
new file mode 100644
index 0000000..2c66b67
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/003-per-tenant-profile-override.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-tenancy-003
+handle: tenancy/per-tenant-profile-override
+scenario:
+  description: 'A tenant-admin defines a tenant-scoped profile override that tightens one validation threshold
+    above the platform-default standard profile while inheriting all other platform defaults. A new resource
+    request in that tenant must be evaluated against the composed profile — the tenant override layered
+    over the platform default — not against either one in isolation. This tests whether profiles compose
+    hierarchically at the tenant boundary and whether the effective policy set is deterministic and auditable.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - compliance-auditor
+    - tenancy-authority
+  intent: Apply a tenant profile override that composes over the platform default
+  success_criteria:
+  - Tenant override is accepted and recorded as a delta over the platform default
+  - Effective profile for the request is the composition, not the override alone
+  - Overridden threshold is enforced; non-overridden defaults are inherited unchanged
+  - Composition order is deterministic and the effective policy set is inspectable
+  - A request that passes the platform default but fails the override is rejected
+  - The composed effective profile is captured in the audit record for the request
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: tenant override composed over platform default to yield the effective profile
+  - domain: data
+    interaction: composed profile resolved and bound to the request record
+  - domain: audit
+    interaction: effective composed profile recorded for later inspection
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- profile-override
+- composition
+- policy
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/004-tenant-quota-exhaustion.yaml b/dav/use-cases/hammer-multi-tenancy/004-tenant-quota-exhaustion.yaml
new file mode 100644
index 0000000..5548b8b
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/004-tenant-quota-exhaustion.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-tenancy-004
+handle: tenancy/tenant-quota-exhaustion
+scenario:
+  description: 'A tenant has a declared quota of resources of a given class. An application-team member
+    submits a new request that would push the tenant over its quota. The system must evaluate the tenant''s
+    aggregate consumption against the quota at admission and reject the request before dispatch, returning
+    a clear over-quota verdict. This probes whether the architecture models per-tenant aggregate limits
+    at all, or whether quota is external to UDLM/DCM and thus unenforceable at the intent boundary.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - sre
+    - tenancy-authority
+  intent: Submit a request that exceeds the tenant's declared resource quota
+  success_criteria:
+  - Tenant's current aggregate consumption for the resource class is computed at admission
+  - The would-be total is compared against the declared tenant quota
+  - The over-quota request is rejected before any provider dispatch
+  - Rejection states the quota, current usage, and requested delta
+  - In-quota requests from the same tenant continue to succeed
+  - The rejection is recorded in the tenant-scoped audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    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: aggregate tenant consumption tallied across realized resources of the class
+  - domain: policy
+    interaction: quota policy compares projected total against the tenant limit
+  - domain: audit
+    interaction: over-quota rejection recorded with usage figures
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- quota
+- exhaustion
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/005-shared-ipaddresspool-isolation.yaml b/dav/use-cases/hammer-multi-tenancy/005-shared-ipaddresspool-isolation.yaml
new file mode 100644
index 0000000..e842e81
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/005-shared-ipaddresspool-isolation.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-tenancy-005
+handle: tenancy/shared-ipaddresspool-isolation
+scenario:
+  description: 'A single platform-owned IPAddressPool is shared across tenants. Tenant A and tenant B
+    each request an IPAddress allocation from the pool in parallel. The system must allocate distinct,
+    non-overlapping addresses, attribute each IPAddress to the requesting tenant, and ensure neither tenant
+    can see or reclaim the other''s allocation — while the pool itself remains a single shared allocatable
+    resource. This tests isolation on a shared allocatable pool: the container is common, but each allocation
+    is tenant-private.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - tenancy-authority
+  intent: Allocate tenant-private IPAddresses from one shared IPAddressPool without overlap
+  success_criteria:
+  - Both tenants receive distinct, non-overlapping IPAddress allocations from the pool
+  - Each IPAddress record is attributed to exactly one owning tenant
+  - Tenant A cannot enumerate, read, or release tenant B's allocation
+  - Concurrent allocation does not double-issue the same address
+  - The shared pool remains a single resource with a running per-tenant allocation map
+  - Each allocation event is recorded in its owning tenant's audit scope
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: pool allocation map updated atomically with per-tenant ownership on each IPAddress
+  - domain: policy
+    interaction: isolation constraint enforces tenant-private visibility of allocations from a shared
+      pool
+  - domain: provider
+    interaction: address provider issues distinct addresses under one pool realization
+  - domain: audit
+    interaction: each allocation logged in the owning tenant's audit scope
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- isolation
+- allocatable-pool
+- ipaddress
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/006-ownership-transfer-whole-allocation.yaml b/dav/use-cases/hammer-multi-tenancy/006-ownership-transfer-whole-allocation.yaml
new file mode 100644
index 0000000..71ae528
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/006-ownership-transfer-whole-allocation.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-tenancy-006
+handle: tenancy/ownership-transfer-whole-allocation
+scenario:
+  description: 'A realized resource with a whole_allocation stake (an entire allocatable unit held by
+    one tenant, not a subdivisible share) must be transferred from tenant A to tenant B — for example,
+    a dedicated block reassigned during a business-unit reorganization. The platform engineer requests
+    the transfer. The system must reassign ownership atomically, preserve the resource UUID and realized
+    state, revoke tenant A''s access, and grant tenant B''s, without a destroy/recreate. This probes whether
+    ownership is mutable metadata that can move between tenants while identity and realization are held
+    fixed.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - compliance-auditor
+    - tenancy-authority
+  intent: Transfer a whole_allocation resource from one tenant to another in place
+  success_criteria:
+  - Ownership field moves from tenant A to tenant B atomically
+  - Resource UUID and realized state are preserved (no destroy/recreate)
+  - Tenant A loses all access to the resource after transfer
+  - Tenant B gains full ownership access after transfer
+  - The transfer is rejected if the allocation is subdivided and not wholly owned
+  - Before/after ownership and the initiating principal are captured in audit
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: ownership attribute updated atomically while UUID and realized state are held constant
+  - domain: policy
+    interaction: transfer policy verifies whole_allocation and both tenants' eligibility
+  - domain: audit
+    interaction: ownership change recorded with prior owner, new owner, and initiator
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- ownership-transfer
+- whole-allocation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/007-cross-tenant-uuid-reference.yaml b/dav/use-cases/hammer-multi-tenancy/007-cross-tenant-uuid-reference.yaml
new file mode 100644
index 0000000..7e72848
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/007-cross-tenant-uuid-reference.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-tenancy-007
+handle: tenancy/cross-tenant-uuid-reference
+scenario:
+  description: 'An application-team member in tenant B declares a new resource whose dependency references,
+    by UUID, a resource that belongs to tenant A. Unlike a raw read attempt, this is a structural dependency
+    in the intent graph. The system must decide whether a cross-tenant dependency edge is permissible:
+    it should reject the reference (or require an explicit sharing grant from tenant A) rather than silently
+    wiring one tenant''s resource into another tenant''s dependency graph. This tests whether the dependency
+    resolver enforces tenant scope on referenced UUIDs.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - tenancy-authority
+  intent: Declare a dependency that references another tenant's resource by UUID
+  success_criteria:
+  - Dependency resolver detects the referenced UUID belongs to a foreign tenant
+  - The reference is rejected absent an explicit cross-tenant sharing grant
+  - No dependency edge is created into tenant A's graph without authorization
+  - Rejection distinguishes not-authorized from not-found
+  - If a sharing grant exists, the reference resolves and is recorded as cross-tenant
+  - The attempted cross-tenant reference is captured in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency resolution checks the owning tenant of each referenced UUID
+  - domain: policy
+    interaction: cross-tenant reference constraint requires an explicit sharing grant
+  - domain: audit
+    interaction: cross-tenant reference attempt recorded with both tenant identities
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- isolation
+- cross-tenant-reference
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/008-tenant-scoped-rls-store-boundary.yaml b/dav/use-cases/hammer-multi-tenancy/008-tenant-scoped-rls-store-boundary.yaml
new file mode 100644
index 0000000..64ae0b0
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/008-tenant-scoped-rls-store-boundary.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-tenancy-008
+handle: tenancy/tenant-scoped-rls-store-boundary
+scenario:
+  description: 'An SRE issues a broad, unfiltered list query against the four-state stores while authenticated
+    as a principal scoped to a single tenant. The store boundary must apply row-level tenant scoping so
+    the result contains only that tenant''s records — even though the query itself specified no tenant
+    filter. This tests whether isolation is enforced at the store boundary (default-deny, scope-injected)
+    rather than depending on every caller remembering to filter. The guarantee must hold for intent, realized,
+    and dependency views alike.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - compliance-auditor
+    - tenancy-authority
+  intent: Verify the store enforces tenant row-level scoping on an unfiltered query
+  success_criteria:
+  - An unfiltered list query returns only the caller's tenant records
+  - Tenant scope is injected at the store boundary, not left to the caller
+  - The guarantee holds across intent, realized, and dependency store views
+  - No foreign-tenant rows appear even in aggregate counts
+  - A platform-scoped principal can still query across tenants when authorized
+  - Store-level scope enforcement is observable in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: store injects tenant row-level scope into every query by default
+  - domain: policy
+    interaction: default-deny scoping rule governs which principals may cross tenant scope
+  - domain: audit
+    interaction: scoped-query enforcement recorded for the querying principal
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- isolation
+- row-level-security
+- store-boundary
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/009-decommission-unrevocable-credentials.yaml b/dav/use-cases/hammer-multi-tenancy/009-decommission-unrevocable-credentials.yaml
new file mode 100644
index 0000000..9a6d993
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/009-decommission-unrevocable-credentials.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-tenancy-009
+handle: tenancy/decommission-unrevocable-credentials
+scenario:
+  description: 'Tenant A is being decommissioned. During credential teardown, one of its issued credentials
+    was minted for a cross-tenant integration and is held by an external provider that is currently unreachable,
+    so revocation cannot be confirmed. The system must not report the decommission as clean while a credential
+    remains potentially live. It must record the credential as unrevoked, hold the decommission in a partial
+    state pending confirmation, and surface the residual exposure. This tests whether decommission treats
+    credential revocation as a first-class success condition, not a fire-and-forget.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - tenancy-authority
+  intent: Decommission a tenant when one cross-tenant credential cannot be revoked
+  success_criteria:
+  - Decommission enumerates all credentials issued for or by the tenant
+  - The unreachable provider's credential revocation is attempted and fails
+  - Decommission does not report clean completion with a credential unrevoked
+  - The residual live credential is recorded as an outstanding exposure
+  - Decommission holds in a partial state pending revocation confirmation
+  - A recovery action to retry revocation is scheduled and audited
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: provider_failure
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: recovery policy blocks clean-decommission verdict while a credential is unrevoked
+  - domain: provider
+    interaction: revocation call to the unreachable provider fails and is marked outstanding
+  - domain: data
+    interaction: decommission held in partial state; residual credential exposure recorded
+  - domain: audit
+    interaction: unrevoked credential and scheduled retry captured as a compliance finding
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- decommission
+- credentials
+- revocation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/010-tenant-boundary-dcmgroup.yaml b/dav/use-cases/hammer-multi-tenancy/010-tenant-boundary-dcmgroup.yaml
new file mode 100644
index 0000000..dc81042
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/010-tenant-boundary-dcmgroup.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-tenancy-010
+handle: tenancy/tenant-boundary-dcmgroup
+scenario:
+  description: 'A platform engineer models a tenant boundary as a DCMGroup that encloses the tenant''s
+    resources and carries the tenant-scoped governance matrix. A new resource request must be validated
+    for membership in the correct DCMGroup and evaluated against that group''s governance matrix. This
+    tests whether the DCMGroup construct is a coherent carrier of a tenant boundary — grouping ownership,
+    scoping policy, and gating membership — as opposed to tenancy being an ad-hoc attribute smeared across
+    records.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Validate a request against a tenant boundary expressed as a DCMGroup
+  success_criteria:
+  - The tenant is represented as a DCMGroup enclosing its resources
+  - New resource is validated for membership in the correct DCMGroup
+  - The group's governance matrix is applied during validation
+  - A resource cannot belong to two tenant DCMGroups simultaneously
+  - Group membership and matrix outcome are bound to the resource record
+  - The membership decision is recorded in the tenant-scoped audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: resource bound to a single tenant DCMGroup with membership recorded
+  - domain: policy
+    interaction: the DCMGroup's governance matrix is enforced for the request
+  - domain: audit
+    interaction: group membership and matrix decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- dcmgroup
+- boundary
+- governance-matrix
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/011-new-tenant-onboarding.yaml b/dav/use-cases/hammer-multi-tenancy/011-new-tenant-onboarding.yaml
new file mode 100644
index 0000000..fb151f4
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/011-new-tenant-onboarding.yaml
@@ -0,0 +1,54 @@
+uuid: uc-hammer-tenancy-011
+handle: tenancy/new-tenant-onboarding
+scenario:
+  description: 'A tenant-admin onboards a brand-new tenant with no existing resources. The system must
+    create the tenant scope, bind it to the default profile, and establish an empty ownership and audit
+    boundary — a clean, simple happy path that establishes the isolation substrate every other tenancy
+    case depends on. This validates that a tenant can be stood up as a first-class scope before any resource
+    exists within it.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: dev
+  perspectives:
+    - compliance-auditor
+    - tenancy-authority
+  intent: Onboard a new empty tenant scope bound to platform defaults
+  success_criteria:
+  - A new tenant scope is created with a unique identity
+  - The tenant is bound to the default profile at creation
+  - An empty ownership boundary and audit scope are established
+  - No resources exist in the tenant immediately after onboarding
+  - The tenant is queryable as an isolated scope from creation onward
+  - Tenant creation is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: data
+    interaction: new tenant scope and empty ownership boundary created
+  - domain: policy
+    interaction: default profile bound to the tenant at creation
+  - domain: audit
+    interaction: tenant onboarding event recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- onboarding
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/012-tenant-scoped-audit-isolation.yaml b/dav/use-cases/hammer-multi-tenancy/012-tenant-scoped-audit-isolation.yaml
new file mode 100644
index 0000000..2a659c8
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/012-tenant-scoped-audit-isolation.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-tenancy-012
+handle: tenancy/tenant-scoped-audit-isolation
+scenario:
+  description: 'A compliance-auditor engaged by tenant A requests the audit trail for tenant A''s resources.
+    The system must return only tenant A''s audit records and never expose events belonging to tenant
+    B, even where the two tenants share an underlying pool or provider. This tests whether the audit domain
+    is itself tenant-scoped — a leak in the audit view would undermine every other isolation guarantee,
+    since audit records describe actions on the very resources isolation is meant to protect.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - security-officer
+    - tenancy-authority
+  intent: Retrieve a tenant-scoped audit trail without leaking other tenants' events
+  success_criteria:
+  - Audit query returns only tenant A's events
+  - Events on shared pools appear only under the acting tenant's scope
+  - No tenant B principal, resource, or action is disclosed to tenant A's auditor
+  - Audit records retain enough detail to satisfy compliance without cross-tenant leakage
+  - The auditor's own access to the audit trail is itself logged
+  - Attempted access to tenant B's audit scope is denied and recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: audit
+    interaction: audit query scoped to the requesting tenant; shared-pool events attributed to the acting
+      tenant
+  - domain: policy
+    interaction: audit-access rule limits the auditor to their engaged tenant scope
+  - domain: data
+    interaction: audit store filters events by owning tenant before return
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- isolation
+- audit-scope
+- compliance
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/013-noisy-neighbor-fair-share.yaml b/dav/use-cases/hammer-multi-tenancy/013-noisy-neighbor-fair-share.yaml
new file mode 100644
index 0000000..0bb9ea2
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/013-noisy-neighbor-fair-share.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-tenancy-013
+handle: tenancy/noisy-neighbor-fair-share
+scenario:
+  description: 'Multiple tenants draw from a shared provider whose capacity is finite. Tenant A submits
+    a burst of requests that would consume most of the provider''s remaining capacity, starving tenants
+    B and C. The system must enforce a fair-share or per-tenant capacity reservation at placement time
+    so that one tenant cannot monopolize a shared provider. This probes whether the placement engine reasons
+    about per-tenant capacity fairness, or whether shared capacity is first-come-first-served and therefore
+    vulnerable to a noisy neighbor.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - provider-owner
+    - tenancy-authority
+  intent: Prevent one tenant from monopolizing shared provider capacity
+  success_criteria:
+  - Placement evaluates per-tenant consumption against the shared provider's capacity
+  - Tenant A's burst is throttled or partially deferred to preserve fair share
+  - Tenants B and C retain their reserved or fair-share capacity
+  - The placement decision cites the fairness constraint that limited tenant A
+  - Requests beyond fair share are deferred, not silently dropped
+  - Fair-share enforcement decisions are recorded in audit
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: placement engine weighs per-tenant capacity against shared provider limits
+  - domain: policy
+    interaction: fair-share constraint caps a single tenant's draw on shared capacity
+  - domain: data
+    interaction: per-tenant capacity consumption tracked against the shared provider
+  - domain: audit
+    interaction: fair-share throttling decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- fair-share
+- noisy-neighbor
+- capacity
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/014-per-tenant-residency-enforcement.yaml b/dav/use-cases/hammer-multi-tenancy/014-per-tenant-residency-enforcement.yaml
new file mode 100644
index 0000000..604e7c5
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/014-per-tenant-residency-enforcement.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-tenancy-014
+handle: tenancy/per-tenant-residency-enforcement
+scenario:
+  description: 'Two tenants share a platform but carry different data-residency mandates: tenant A must
+    remain in-region, tenant B is unconstrained. A compliance-auditor validates that a tenant-A request
+    is placed only on providers within tenant A''s mandated region, while an otherwise-identical tenant-B
+    request may be placed anywhere. This tests whether sovereignty is enforced per-tenant — the residency
+    constraint must travel with the tenant scope, not be a single platform-wide setting.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Enforce per-tenant residency so each tenant's mandate governs placement
+  success_criteria:
+  - Tenant A's request is placed only on in-region providers
+  - The identical tenant-B request may be placed on out-of-region providers
+  - The residency constraint is resolved from the tenant scope, not a global setting
+  - An in-region-only tenant with no eligible provider is failed, not silently relocated
+  - The governing residency mandate is recorded on each placement decision
+  - Residency enforcement is auditable per tenant
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: per-tenant sovereignty mandate resolved and enforced during placement
+  - domain: provider
+    interaction: placement filtered to providers satisfying the tenant's residency region
+  - domain: data
+    interaction: governing residency mandate bound to each placement record
+  - domain: audit
+    interaction: residency decision recorded per tenant
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- sovereignty
+- residency
+- placement
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/015-cross-tenant-dependency-decommission.yaml b/dav/use-cases/hammer-multi-tenancy/015-cross-tenant-dependency-decommission.yaml
new file mode 100644
index 0000000..2bc4e8a
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/015-cross-tenant-dependency-decommission.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-tenancy-015
+handle: tenancy/cross-tenant-dependency-decommission
+scenario:
+  description: 'Tenant A owns a resource that tenant B''s resource hard-depends on via an authorized cross-tenant
+    sharing grant. Tenant A requests decommission of that resource. The system must detect the live hard
+    dependency held by tenant B and refuse to destroy the resource while B''s dependent remains, rather
+    than leaving tenant B with a dangling hard dependency. This probes whether the decommission dependency
+    check spans tenant boundaries when a sharing grant has created a legitimate cross-tenant edge.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - tenancy-authority
+  intent: Decommission a shared resource that another tenant hard-depends on
+  success_criteria:
+  - Decommission traversal finds the cross-tenant hard dependency held by tenant B
+  - Destruction is blocked while tenant B's dependent is live
+  - Tenant B is never left with a dangling hard dependency
+  - Blocking rationale names the dependent resource and its tenant
+  - Decommission can proceed only after the dependency is removed or migrated
+  - The blocked decommission and cross-tenant dependency are recorded in audit
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph traversed across tenant boundary to find live dependents
+  - domain: policy
+    interaction: decommission-safety policy blocks destruction with a live cross-tenant hard dependency
+  - domain: audit
+    interaction: blocked decommission recorded with the cross-tenant dependent
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- decommission
+- cross-tenant-dependency
+- dangling
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/016-shared-pool-chargeback-attribution.yaml b/dav/use-cases/hammer-multi-tenancy/016-shared-pool-chargeback-attribution.yaml
new file mode 100644
index 0000000..2a4d2f5
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/016-shared-pool-chargeback-attribution.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-tenancy-016
+handle: tenancy/shared-pool-chargeback-attribution
+scenario:
+  description: 'A finance-analyst needs per-tenant chargeback for a shared allocatable pool: each tenant
+    should be billed only for the fraction of the pool it holds. The system must attribute pool consumption
+    to owning tenants precisely enough to split the shared resource''s cost, without double-counting or
+    leaving unattributed remainder. This probes whether the data model carries enough per-tenant allocation
+    attribution to support chargeback on shared resources, or whether cost attribution across a shared
+    pool is beyond what UDLM/DCM records.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - tenancy-authority
+  intent: Produce per-tenant chargeback for a shared allocatable pool
+  success_criteria:
+  - Each tenant's share of the shared pool is computed from its attributed allocations
+  - The sum of per-tenant shares reconciles to total pool consumption
+  - No allocation is double-counted across tenants
+  - Unallocated pool remainder is attributed to the pool owner, not to consumers
+  - The attribution basis (allocation records) is inspectable per tenant
+  - Chargeback computation is reproducible from the recorded data
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: per-tenant allocation records aggregated to split shared-pool cost
+  - domain: policy
+    interaction: attribution rule reconciles shares to total and assigns remainder to the owner
+  - domain: audit
+    interaction: chargeback basis recorded for reproducibility
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- chargeback
+- cost-attribution
+- shared-pool
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/017-peer-dcm-tenant-federation-isolation.yaml b/dav/use-cases/hammer-multi-tenancy/017-peer-dcm-tenant-federation-isolation.yaml
new file mode 100644
index 0000000..353c909
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/017-peer-dcm-tenant-federation-isolation.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-tenancy-017
+handle: tenancy/peer-dcm-tenant-federation-isolation
+scenario:
+  description: 'A tenant''s request must be satisfied partly by a peer DCM in another sovereignty domain
+    via federation. The platform engineer requires that only the delegated resource''s intent crosses
+    to the peer — the tenant''s other resources, its full catalog, and its audit scope must remain isolated
+    on the home DCM. Midway, the peer DCM disconnects. The system must keep the tenant''s home-side state
+    consistent and never expose non-delegated tenant data across the federation boundary, even under peer
+    failure. This tests tenant isolation that must hold across a federation seam.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+    - compliance-auditor
+    - security-officer
+  intent: Federate one tenant resource to a peer DCM without leaking the tenant's other scope
+  success_criteria:
+  - Only the delegated resource's intent crosses the federation boundary
+  - The tenant's non-delegated resources and audit scope stay on the home DCM
+  - Peer DCM disconnect leaves home-side tenant state consistent
+  - No partial or orphaned cross-DCM record persists after the disconnect
+  - The federation boundary carries tenant identity so the peer scopes correctly
+  - Federation and disconnect events are recorded in the tenant's home audit scope
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    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: provider
+    interaction: peer DCM engaged for the delegated resource only; disconnect handled without orphaning
+  - domain: policy
+    interaction: federation boundary constraint limits what tenant data may cross to the peer
+  - domain: data
+    interaction: home-side tenant state kept consistent across the peer disconnect
+  - domain: audit
+    interaction: federation and disconnect recorded in the tenant's home audit scope
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- federation
+- peer-dcm
+- isolation
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/018-tenant-scoped-drift-detection.yaml b/dav/use-cases/hammer-multi-tenancy/018-tenant-scoped-drift-detection.yaml
new file mode 100644
index 0000000..335344d
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/018-tenant-scoped-drift-detection.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-tenancy-018
+handle: tenancy/tenant-scoped-drift-detection
+scenario:
+  description: 'An SRE runs drift detection for tenant A. A shared provider has drifted in a way that
+    affects both tenant A and tenant B resources. The drift report for tenant A must include only tenant
+    A''s drifted resources and must not disclose tenant B''s affected resources, even though the root
+    cause is shared. This tests whether drift detection respects tenant scope in both the query surface
+    and the reported findings, so a shared-substrate drift does not become a cross-tenant information
+    leak.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - security-officer
+    - tenancy-authority
+  intent: Detect drift scoped to one tenant without disclosing another tenant's drift
+  success_criteria:
+  - Drift scan for tenant A reports only tenant A's drifted resources
+  - Tenant B's affected resources are not disclosed in tenant A's report
+  - The shared root cause is described without naming foreign-tenant resources
+  - Per-tenant remediation intent is generated only for the scanning tenant
+  - Drift findings are attributed to the correct owning tenant
+  - The scoped drift scan is recorded in the tenant's audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: drift comparison scoped to the tenant's resources despite a shared root cause
+  - domain: policy
+    interaction: reporting rule suppresses foreign-tenant resources from the drift report
+  - domain: audit
+    interaction: scoped drift scan recorded for the tenant
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- drift
+- isolation
+- scoped-reporting
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/019-credential-expiry-mid-dispatch.yaml b/dav/use-cases/hammer-multi-tenancy/019-credential-expiry-mid-dispatch.yaml
new file mode 100644
index 0000000..85522f1
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/019-credential-expiry-mid-dispatch.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-tenancy-019
+handle: tenancy/credential-expiry-mid-dispatch
+scenario:
+  description: 'A tenant-scoped modification is dispatched to a provider using a tenant-issued credential
+    that expires while the dispatch is in flight. The provider call fails on an expired credential. The
+    system must fail the dispatch cleanly within the tenant''s scope, avoid partial cross-tenant state,
+    refresh or re-request the tenant credential under a recovery policy, and never fall back to another
+    tenant''s credential to complete the call. This tests credential isolation and recovery at the tenant
+    boundary under a mid-flight expiry.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Recover a tenant dispatch when its credential expires mid-flight without cross-tenant fallback
+  success_criteria:
+  - Provider call failing on expired credential is detected mid-dispatch
+  - The dispatch fails cleanly with no partial realized state committed
+  - No other tenant's credential is used as a fallback to complete the call
+  - Recovery policy refreshes or re-requests the tenant's own credential
+  - The retried dispatch stays entirely within the original tenant scope
+  - Credential expiry, failure, and recovery are recorded in the tenant's audit scope
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: dispatch fails on expired tenant credential; no cross-tenant credential substituted
+  - domain: policy
+    interaction: recovery policy refreshes the tenant's own credential and retries within scope
+  - domain: data
+    interaction: no partial realized state persisted for the failed dispatch
+  - domain: audit
+    interaction: expiry, failure, and recovery recorded in the tenant audit scope
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- credentials
+- expiry
+- recovery
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-multi-tenancy/020-brownfield-tenant-attribution.yaml b/dav/use-cases/hammer-multi-tenancy/020-brownfield-tenant-attribution.yaml
new file mode 100644
index 0000000..2bebc0d
--- /dev/null
+++ b/dav/use-cases/hammer-multi-tenancy/020-brownfield-tenant-attribution.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-tenancy-020
+handle: tenancy/brownfield-tenant-attribution
+scenario:
+  description: 'A platform engineer ingests a brownfield estate discovered from a shared substrate where
+    resources were never tenant-labeled. Ingestion must attribute each discovered resource to the correct
+    owning tenant using available evidence (network segment, naming, provider account), flag ambiguous
+    resources for human adjudication rather than guessing, and never place a resource into the wrong tenant''s
+    isolated scope. This tests whether brownfield ingestion can establish tenant ownership as a first-class
+    attribute on pre-existing resources, and how it handles unattributable ones.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Attribute discovered brownfield resources to the correct tenant during ingestion
+  success_criteria:
+  - Each discovered resource is evaluated for tenant ownership from available evidence
+  - Confidently-attributed resources are placed in the correct tenant scope
+  - Ambiguous resources are flagged for adjudication, not guessed into a tenant
+  - No resource is silently placed in the wrong tenant's isolated scope
+  - Attribution evidence and confidence are recorded per ingested resource
+  - Unattributed resources are held in a quarantine scope pending decision
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: discovered resources attributed to tenants; ambiguous ones held in quarantine scope
+  - domain: policy
+    interaction: attribution validation flags low-confidence resources for adjudication
+  - domain: audit
+    interaction: attribution evidence and confidence recorded per resource
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- multi-tenancy
+- brownfield
+- ingestion
+- attribution
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-must-reject/001-cross-tenant-reference-refused.yaml b/dav/use-cases/hammer-must-reject/001-cross-tenant-reference-refused.yaml
new file mode 100644
index 0000000..25a98b9
--- /dev/null
+++ b/dav/use-cases/hammer-must-reject/001-cross-tenant-reference-refused.yaml
@@ -0,0 +1,67 @@
+uuid: uc-7f0f609d-744d-4766-8287-28360c6f767d
+handle: must-reject/cross-tenant-reference-refused
+version: 1.0.0
+scenario:
+  description: 'An application-team member in tenant-a submits an intent whose dependency
+    references, by UUID, a database that belongs to tenant-b. No cross-tenant authorization
+    grant exists between the two tenants. Success for this use case is the REFUSAL: the
+    request must be rejected, not accepted with the foreign edge wired in, and not "repaired"
+    by silently dropping the reference and realizing the rest (a partial realization the
+    consumer never asked for). The refusal must be a typed policy error — machine-matchable
+    as a cross-tenant authorization failure, distinct from not-found — actionable (it names
+    the grant mechanism that would make the reference legal), and auditable (a refusal record
+    exists carrying both tenant identities and the attempted reference). It must not leak
+    tenant-b''s resource details beyond existence-as-forbidden: the error may not echo the
+    foreign resource''s attributes.'
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - security-officer
+    - tenancy-authority
+  intent: Declare a resource whose hard dependency targets another tenant's resource by UUID,
+    with no cross-tenant authorization grant in place
+  success_criteria:
+  - The request is refused at validation; no entity is realized and no dependency edge into
+    tenant-b's graph is created
+  - The refusal is a typed cross-tenant authorization error, distinguishable from not-found
+    and from schema-invalid
+  - The reference is not silently dropped — refusal of the whole intent, never partial
+    acceptance with the edge removed
+  - The refusal names the remediation path (a cross_tenant_authorization grant from tenant-b)
+    without disclosing tenant-b resource attributes
+  - An audit record of the refusal exists, carrying both tenant identities, the attempted
+    target UUID, and the policy that refused
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: tenant scope of the referenced UUID is resolved from the instance record's
+      tenant_uuid before any edge is created
+  - domain: policy
+    interaction: the tenancy boundary policy refuses the crossing absent a
+      cross_tenant_authorization grant
+  - domain: provider
+    interaction: no provider is dispatched for the refused intent
+  - domain: audit
+    interaction: the refusal, both tenant identities, and the refusing policy are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: must-reject-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- must-reject
+- refusal-contract
+- multi-tenancy
+- cross-tenant-reference
diff --git a/dav/use-cases/hammer-must-reject/002-sovereignty-egress-refused.yaml b/dav/use-cases/hammer-must-reject/002-sovereignty-egress-refused.yaml
new file mode 100644
index 0000000..2109439
--- /dev/null
+++ b/dav/use-cases/hammer-must-reject/002-sovereignty-egress-refused.yaml
@@ -0,0 +1,71 @@
+uuid: uc-6082a4e3-e69f-4c29-b96b-7fe1a2af2630
+handle: must-reject/sovereignty-egress-refused
+version: 1.0.0
+scenario:
+  description: 'A tenant admin operating under a sovereign profile submits an intent that
+    would realize a hard dependency on a peer estate outside the tenant''s declared
+    sovereignty boundary — realizing it would project residency-classified fields across the
+    boundary to satisfy the peer''s placement. The egress gate (policy in its
+    information-firewall role, ADR-041: sovereignty is inherently egress, the data owner''s
+    pre-crossing call) must refuse at request time, before any data crosses — a refusal after
+    the crossing is a disclosure that cannot be taken back. Success is a refusal that is
+    itself non-leaking: the error states that a sovereignty egress policy refused the
+    crossing and which boundary was hit, but must not include the masked field values, nor
+    enumerate the protected fields in a way that discloses what it protects. The refusal is
+    typed (sovereignty egress denial), actionable (names the declared boundary and the
+    policy, so the tenant can seek an in-boundary alternative), and auditable in the
+    tenant''s own audit store.'
+  actor:
+    persona: tenant-admin
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - federation-peer-operator
+  intent: Realize a resource whose dependency requires projecting residency-classified data
+    to a peer estate across the tenant's declared sovereignty boundary
+  success_criteria:
+  - The egress gate refuses at request time; no data crosses the boundary and nothing is
+    realized on the peer
+  - The refusal is a typed sovereignty egress denial naming the declared boundary and the
+    refusing policy
+  - The refusal payload contains none of the masked field values and does not enumerate
+    protected content — information-firewall behavior holds on the error path itself
+  - The structural surface is sufficient to refuse — the decision matches on the target
+    authority in the reference, without dereferencing the protected data
+  - An audit record of the refusal exists in the tenant's audit store, recording the
+    crossing attempted and the gate that refused, without the protected values
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: policy_violation
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the egress gate refuses the crossing on the structural surface (target
+      authority in the address) before resolution
+  - domain: data
+    interaction: no protected value is resolved for, or embedded in, the refusal payload
+  - domain: provider
+    interaction: no peer dispatch occurs; the peer never observes the refused intent's
+      protected content
+  - domain: audit
+    interaction: the refused crossing and the refusing gate are recorded in-boundary,
+      values excluded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: must-reject-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- must-reject
+- refusal-contract
+- sovereignty
+- information-firewall
+- egress
diff --git a/dav/use-cases/hammer-must-reject/003-inline-credential-literal-refused.yaml b/dav/use-cases/hammer-must-reject/003-inline-credential-literal-refused.yaml
new file mode 100644
index 0000000..fc586f9
--- /dev/null
+++ b/dav/use-cases/hammer-must-reject/003-inline-credential-literal-refused.yaml
@@ -0,0 +1,64 @@
+uuid: uc-bc9ef5a2-5983-4ff1-b908-3f02a6b027c9
+handle: must-reject/inline-credential-literal-refused
+version: 1.0.0
+scenario:
+  description: 'An application-team member submits an intent for a containerized service and
+    pastes a database password as a literal string into the field where the model requires a
+    Security.CredentialRef — the secrets-as-reference primitive that names WHICH credential
+    is held WHERE, never the value. The request must be refused with a remediation that
+    points at Security.CredentialRef (declare the reference; the issuer resolves the value
+    directly to the authorized consumer). The hard part of this refusal contract is
+    non-persistence: the rejecting path itself must not become the leak. The literal must not
+    be written to the state store, the commit log, request logs, or the audit record — the
+    audit entry records THAT an inline literal was refused in that field, never the literal.
+    A refusal that quotes the offending value back, or an error pipeline that logs the raw
+    request body, fails this use case even though the request was nominally rejected.'
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - sre
+    - compliance-auditor
+    - security-officer
+  intent: Submit an intent embedding a secret literal where the model requires a
+    Security.CredentialRef, and receive a refusal that never persists the literal
+  success_criteria:
+  - The request is refused at validation; nothing is realized
+  - The refusal is typed as an inline-credential-material violation, with remediation
+    naming Security.CredentialRef and the field to convert
+  - The secret literal appears in no persisted surface of the rejecting path — state
+    store, commit log, service logs, or error payload echoes
+  - An audit record of the refusal exists, identifying the field and the violation class
+    while excluding the literal value
+  - A corrected resubmission carrying a Security.CredentialRef in the same field passes
+    the same validation
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the literal is excluded from every persisted store on the rejecting path
+  - domain: policy
+    interaction: the secrets-as-reference rule refuses inline credential material and
+      emits the CredentialRef remediation
+  - domain: provider
+    interaction: no issuer or realizing provider is dispatched for the refused intent
+  - domain: audit
+    interaction: the refusal is recorded with field and violation class, value excluded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: must-reject-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- must-reject
+- refusal-contract
+- credentials
+- secrets-as-reference
+- non-persistence
diff --git a/dav/use-cases/hammer-must-reject/004-undeclared-output-binding-refused.yaml b/dav/use-cases/hammer-must-reject/004-undeclared-output-binding-refused.yaml
new file mode 100644
index 0000000..0b63669
--- /dev/null
+++ b/dav/use-cases/hammer-must-reject/004-undeclared-output-binding-refused.yaml
@@ -0,0 +1,68 @@
+uuid: uc-1e2e4408-bebd-45d3-b083-aa129724ecfe
+handle: must-reject/undeclared-output-binding-refused
+version: 1.0.0
+scenario:
+  description: 'A platform engineer submits a request instantiating a catalog item whose
+    constituent binds to an output the producer type never declared. The corpus already
+    asserts what the error must SAY (the binding-surface family: the message names the
+    producer type, the missing output, and the declared alternatives); this use case asserts
+    when and whether refusal happens at all — the request-time twin of the CI-time gate that
+    output-resolves bindings when a catalog item is admitted. A catalog gate alone is
+    insufficient: a producer type can be re-versioned after admission, or the request can
+    compose items the catalog never checked together, so the same declaration-or-refuse
+    check must run against the request. Success is refusal BEFORE any realization: no
+    constituent of the composite is provisioned and then rolled back — the invalid binding
+    is caught while the request is still data. The refusal is typed as a binding-contract
+    violation, actionable per the sibling family''s message contract, and auditable, citing
+    the producer type''s declared output surface as the authority.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Request a catalog item whose constituent binds to an undeclared producer output,
+    and receive a validation-time refusal before any constituent is realized
+  success_criteria:
+  - The request is refused at validation; no constituent of the composite is provisioned,
+    so no rollback or compensation is needed
+  - The refusal is typed as a binding-contract violation, distinct from policy denial and
+    from provider failure
+  - The refusal cites the producer type's declared output surface as the authority for the
+    decision
+  - The check holds even when the catalog item passed admission — a producer re-versioned
+    since admission still yields a request-time refusal
+  - An audit record of the refusal exists, naming the catalog item, the constituent, and
+    the undeclared output requested
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the producer type's declared outputs are the authority the request-time
+      check resolves bindings against
+  - domain: policy
+    interaction: the declaration-or-refuse rule runs at request validation, not only at
+      catalog admission
+  - domain: provider
+    interaction: no provider is dispatched for any constituent of the refused composite
+  - domain: audit
+    interaction: the refusal and its cited output-surface authority are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: must-reject-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- must-reject
+- refusal-contract
+- typed-outputs
+- binding-surface
+- request-time-validation
diff --git a/dav/use-cases/hammer-must-reject/005-provider-capability-mismatch-refused.yaml b/dav/use-cases/hammer-must-reject/005-provider-capability-mismatch-refused.yaml
new file mode 100644
index 0000000..e975a2a
--- /dev/null
+++ b/dav/use-cases/hammer-must-reject/005-provider-capability-mismatch-refused.yaml
@@ -0,0 +1,69 @@
+uuid: uc-a9a1b387-978b-4cd4-9537-aed00b2e872f
+handle: must-reject/provider-capability-mismatch-refused
+version: 1.0.0
+scenario:
+  description: 'A platform engineer submits a realization request that an operator error (a
+    pinned placement, a stale routing rule) routes to provider-north — a provider whose
+    registration does not declare the capability the intent requires: the resource type at
+    the required version of its adopted standard. Under declare-and-select, a provider''s
+    declared capability set is the eligibility authority; dispatching an intent to a
+    provider that never declared for it must be refused, not attempted best-effort. The
+    refusal must name the mismatch concretely: the capability and standard version the
+    intent requires, against what provider-north actually declared — so the reader can tell
+    a mis-routed request (another provider is eligible) from an unsatisfiable one (none is).
+    Success is that the refusal happens before the provider acts: provider-north performs no
+    partial realization it cannot complete, the refusal is typed as a capability mismatch
+    (distinct from provider failure — the provider did not break, it was never eligible),
+    and the audit record carries the required-versus-declared comparison that justified it.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Route a realization request to a provider that does not declare the required
+    capability, and receive a refusal naming the capability mismatch
+  success_criteria:
+  - The dispatch is refused before the provider performs any realization work
+  - The refusal is typed as a capability mismatch, distinct from provider failure and
+    from policy denial
+  - The refusal names the required capability and standard version, and the provider's
+    actually-declared set, so mis-routed is distinguishable from unsatisfiable
+  - Eligibility is decided from the provider's registration declarations, not by
+    attempting the operation and observing failure
+  - An audit record of the refusal exists, carrying the required-versus-declared
+    capability comparison and the routing that was refused
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: none_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the provider's declared capability set is the eligibility authority; the
+      undeclared provider receives no work
+  - domain: policy
+    interaction: the eligibility rule refuses dispatch on declaration mismatch rather than
+      on observed failure
+  - domain: data
+    interaction: the required capability and the provider's declarations are both
+      resolvable records the refusal cites
+  - domain: audit
+    interaction: the refused routing and the required-versus-declared comparison are
+      recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: must-reject-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- must-reject
+- refusal-contract
+- provider-capability
+- declare-and-select
diff --git a/dav/use-cases/hammer-must-reject/006-masked-projection-write-refused.yaml b/dav/use-cases/hammer-must-reject/006-masked-projection-write-refused.yaml
new file mode 100644
index 0000000..6333d89
--- /dev/null
+++ b/dav/use-cases/hammer-must-reject/006-masked-projection-write-refused.yaml
@@ -0,0 +1,72 @@
+uuid: uc-e48ffd64-64e0-4310-9dbc-97e4baf9f756
+handle: must-reject/masked-projection-write-refused
+version: 1.0.0
+scenario:
+  description: 'An application-team member''s policy scope excludes a compliance-classified
+    field (a residency attribute) on a resource they otherwise administer. They request a
+    projection that includes the excluded field, then attempt to write the resource back
+    through the surface the projection returned. The read half must behave as a guard, not a
+    binary gate: the response omits or masks the excluded field AND states that the
+    projection was reduced by policy — a silently-shrunk projection is a failure, because
+    the consumer would treat absence as ground truth (a reconciler that reads a silently
+    reduced projection and writes it back would erase the field). The write half is the
+    must-reject: an update arriving through that masked surface — whether it attempts to
+    set the excluded field or to clear it by omission-round-trip — is refused, not merged.
+    The refusal is typed as a scope violation on the named field, actionable (names the
+    scope that excludes it), non-leaking (the masked value appears in neither the reduced
+    read nor the write refusal), and both the reduced read and the refused write are
+    audited.'
+  actor:
+    persona: application-team-member
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - security-officer
+    - sovereignty-authority
+  intent: Read a projection that policy scope reduces, then write back through the masked
+    surface, and receive a disclosed reduction on read and a typed refusal on write
+  success_criteria:
+  - The projection response omits or masks the excluded field and explicitly states it was
+    reduced by policy, without revealing the masked value
+  - A write through the masked surface that targets the excluded field is refused with a
+    typed scope violation naming the field and the excluding scope
+  - A write that would clear the excluded field by round-tripping the reduced projection is
+    refused or field-ignored-with-notice — never silently merged as a deletion
+  - The masked value appears nowhere in the read response, the write refusal, or their
+    error payloads
+  - Audit records exist for both halves — the reduced projection served and the refused
+    write — each naming the field and the governing scope, values excluded
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the guard reduces the projection on read and refuses the write through
+      the masked surface — one scope, both directions
+  - domain: data
+    interaction: the reduction is disclosed as metadata so absence is never mistaken for
+      ground truth
+  - domain: provider
+    interaction: no realization of the refused write reaches any provider
+  - domain: audit
+    interaction: both the reduced read and the refused write are recorded with field and
+      scope, values excluded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: must-reject-2026-07-24
+  timestamp: '2026-07-24T12:00:00.000000+00:00'
+tags:
+- must-reject
+- refusal-contract
+- projection
+- information-firewall
+- field-granular-scope
diff --git a/dav/use-cases/hammer-networking/001-vlan-create-simple.yaml b/dav/use-cases/hammer-networking/001-vlan-create-simple.yaml
new file mode 100644
index 0000000..10ae3cd
--- /dev/null
+++ b/dav/use-cases/hammer-networking/001-vlan-create-simple.yaml
@@ -0,0 +1,53 @@
+uuid: uc-hammer-networking-001
+handle: networking/vlan-create-simple
+scenario:
+  description: 'A platform engineer requests a single VLAN segment (id 90, "storage") on the lab fabric
+    with no dependents and no upstream references. The system must mint one Network.VLAN record carrying
+    its vlan id and optional fabric scope, and realize it through the network provider. This is the baseline
+    segment-creation path — the simplest possible network resource — and it establishes that a segment
+    is a first-class managed record, not an attribute buried inside a host config.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Create a single standalone VLAN segment on the fabric
+  success_criteria:
+  - Network.VLAN record is created with a stable UUID
+  - The record captures the vlan id and (optional) fabric/cluster scope
+  - Provider realizes the segment on the target fabric
+  - Realized state confirms the segment exists and is reachable for later binding
+  - No dependents are required and none are fabricated
+  - Creation event is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: Network.VLAN intent recorded with vlan id and scope
+  - domain: provider
+    interaction: network provider realizes the segment on the fabric
+  - domain: audit
+    interaction: segment creation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- vlan
+- segment
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/002-static-reservation-adr023.yaml b/dav/use-cases/hammer-networking/002-static-reservation-adr023.yaml
new file mode 100644
index 0000000..3a24c16
--- /dev/null
+++ b/dav/use-cases/hammer-networking/002-static-reservation-adr023.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-networking-002
+handle: networking/static-reservation-adr023
+scenario:
+  description: 'An SRE needs host "app-web-01" to always come up on 192.0.2.10. Rather than hand-maintain a
+    DHCP server''s reservation list, they declare a Network.IPAddress with allocation: static, address
+    192.0.2.10/24, bound to the host''s Hardware.NetworkInterface. Per ADR-023, a static DHCP reservation
+    is not a special object — it is exactly this record with allocation: static, and the DHCP AddressService
+    realizes it as a reservation. The system must treat the reservation as an addressable, ownable record
+    (a projection of intent) rather than an opaque line in a provider''s config file.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives: []
+  intent: Declare a static DHCP reservation as a first-class IPAddress record bound to an interface
+  success_criteria:
+  - Network.IPAddress record is created with allocation set to static
+  - address carries a valid CIDR (192.0.2.10/24) and ip_family ipv4
+  - Record is bound to the target Hardware.NetworkInterface by reference (MAC/interface identity)
+  - DHCP AddressService realizes the record as a host reservation, not a dynamic lease
+  - The reservation is queryable as an owned record, not only visible in provider config
+  - Re-applying the unchanged reservation is a no-op (idempotent)
+  - Reservation creation and its binding are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: Network.IPAddress(allocation=static) recorded and bound to the interface record
+  - domain: provider
+    interaction: DHCP AddressService realizes the address as a static reservation
+  - domain: audit
+    interaction: reservation and interface binding recorded per ADR-023 projection
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- ip-address
+- static-reservation
+- adr-023
+- dhcp
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/003-connection-profile-nmstate-realize.yaml b/dav/use-cases/hammer-networking/003-connection-profile-nmstate-realize.yaml
new file mode 100644
index 0000000..7509074
--- /dev/null
+++ b/dav/use-cases/hammer-networking/003-connection-profile-nmstate-realize.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-networking-003
+handle: networking/connection-profile-nmstate-realize
+scenario:
+  description: 'A platform engineer declares a Network.ConnectionProfile (NMstate/NetworkManager form)
+    for a host: a named connection that pins an interface to a VLAN, sets its IPv4 method to manual with
+    a declared address, and sets DNS. The system must persist the profile as intent and realize it onto
+    the host via the NetworkManager provider, producing the corresponding NMstate on the box. This tests
+    that host connectivity configuration is a declarative, ownable record rather than an imperative script
+    run once and forgotten.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Realize a declarative NMstate connection profile onto a host
+  success_criteria:
+  - Network.ConnectionProfile record is created with a stable UUID
+  - Profile references the target interface, VLAN, and IP method (manual/auto)
+  - NetworkManager provider applies the profile, producing matching NMstate on the host
+  - Realized state reflects the active connection (address, gateway, dns) as declared
+  - Re-applying the unchanged profile converges to a no-op
+  - Profile application is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: Network.ConnectionProfile intent recorded referencing interface and VLAN
+  - domain: provider
+    interaction: NetworkManager provider realizes NMstate on the host
+  - domain: audit
+    interaction: profile application recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- connection-profile
+- nmstate
+- networkmanager
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/004-dns-zone-record-create.yaml b/dav/use-cases/hammer-networking/004-dns-zone-record-create.yaml
new file mode 100644
index 0000000..265399e
--- /dev/null
+++ b/dav/use-cases/hammer-networking/004-dns-zone-record-create.yaml
@@ -0,0 +1,53 @@
+uuid: uc-hammer-networking-004
+handle: networking/dns-zone-record-create
+scenario:
+  description: 'An application-team member requests an A record for a new service under an existing Network.DNSZone
+    served by a Network.AddressService with services including dns. The system must create the record
+    as intent, validate it belongs to a zone the actor is entitled to write, and realize it through the
+    DNS AddressService. This is a simple day-to-day request that establishes DNS as a managed AddressService
+    function rather than out-of-band tribal knowledge.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives: []
+  intent: Add a DNS A record to an existing managed zone
+  success_criteria:
+  - The record intent is created and associated with the target Network.DNSZone
+  - Policy confirms the actor may write to the requested zone
+  - DNS AddressService (services includes dns) realizes the record
+  - Realized state confirms the record resolves as declared
+  - Record creation is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: zone-write entitlement validated for the actor
+  - domain: data
+    interaction: DNS record intent recorded against the zone
+  - domain: provider
+    interaction: DNS AddressService realizes the record
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- dns
+- address-service
+- zone
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/005-ipaddress-from-pool-allocation-ownership.yaml b/dav/use-cases/hammer-networking/005-ipaddress-from-pool-allocation-ownership.yaml
new file mode 100644
index 0000000..294dc6c
--- /dev/null
+++ b/dav/use-cases/hammer-networking/005-ipaddress-from-pool-allocation-ownership.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-networking-005
+handle: networking/ipaddress-from-pool-allocation-ownership
+scenario:
+  description: 'A tenant-admin asks the platform to "allocate the next free address" from a named address
+    pool (10.20.0.0/22) and hand ownership of that specific address to their service, so no two tenants
+    can be handed the same address. This tests whether the architecture models an address POOL as a first-class
+    resource with allocation ownership — a record that atomically carves out a Network.IPAddress and marks
+    it owned — versus only modelling individual IPAddress records and DHCP scopes. The registry today
+    has Network.DHCPScope and Network.IPAddress but no explicit IPAddressPool with allocation-ownership
+    semantics, so this likely returns partially_supported or unsupported and surfaces a real gap.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - tenancy-authority
+  intent: Allocate and take ownership of a free address from a managed pool
+  success_criteria:
+  - A pool resource (or DHCPScope acting as one) is identifiable as the allocation source
+  - The system carves out exactly one Network.IPAddress and records ownership by the requesting service
+  - Allocation is atomic — concurrent requests cannot receive the same address
+  - The allocated address is removed from the free set and cannot be double-allocated
+  - Ownership is queryable (who holds this address, from which pool)
+  - If no pool/allocation-ownership resource exists, the gap is reported explicitly rather than silently
+    faked
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: address carved from a pool and recorded as an owned Network.IPAddress
+  - domain: policy
+    interaction: allocation authorized against the tenant's entitlement to the pool
+  - domain: audit
+    interaction: allocation and ownership transfer recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- ip-address
+- address-pool
+- allocation-ownership
+- edge
+- gap-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/006-address-pool-exhaustion.yaml b/dav/use-cases/hammer-networking/006-address-pool-exhaustion.yaml
new file mode 100644
index 0000000..920e675
--- /dev/null
+++ b/dav/use-cases/hammer-networking/006-address-pool-exhaustion.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-networking-006
+handle: networking/address-pool-exhaustion
+scenario:
+  description: 'A batch of 40 VMs is provisioned into a segment whose DHCP scope / address pool has only
+    12 free addresses left. Partway through the run the pool exhausts. The system must detect exhaustion,
+    fail the affected allocations cleanly with a specific "pool exhausted" reason, leave the already-allocated
+    addresses owned and intact, and not hand out an out-of-range or duplicate address to force progress.
+    This tests graceful degradation at a hard resource limit rather than silent corruption of the address
+    space.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Provision more addresses than the pool can satisfy and observe clean exhaustion handling
+  success_criteria:
+  - Allocations proceed until the pool's free set is empty
+  - Exhaustion is detected and reported with a specific pool-exhausted reason
+  - Requests beyond capacity fail rather than receiving out-of-range or duplicate addresses
+  - Already-allocated addresses remain owned, intact, and unaffected
+  - No partial resource is left in an ambiguous half-allocated state
+  - The exhaustion event and the count satisfied vs denied are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: pool free set tracked; exhaustion boundary recorded
+  - domain: provider
+    interaction: DHCP/pool provider reports it can no longer satisfy allocations
+  - domain: audit
+    interaction: satisfied vs denied counts and exhaustion recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- address-pool
+- exhaustion
+- failure
+- quota
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/007-vlan-shared-tenant-stakes.yaml b/dav/use-cases/hammer-networking/007-vlan-shared-tenant-stakes.yaml
new file mode 100644
index 0000000..784b55c
--- /dev/null
+++ b/dav/use-cases/hammer-networking/007-vlan-shared-tenant-stakes.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-networking-007
+handle: networking/vlan-shared-tenant-stakes
+scenario:
+  description: 'A shared services VLAN (id 30, "platform-ingress") is used by three tenants at once: each
+    attaches workloads and each depends on it staying up. Tenant A files a decommission request for the
+    VLAN. The system must recognize the VLAN as a shared resource with multiple tenant stakes (M:N), refuse
+    to let one stakeholder unilaterally destroy a resource others depend on, and require either co-approval
+    or removal of the other stakes first. This tests whether a segment carries stakeholder relationships
+    or is treated as owned by whoever touched it last.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Attempt to decommission a VLAN that multiple tenants have active stakes in
+  success_criteria:
+  - The VLAN is modelled as a shared resource with multiple tenant stakeholders (M:N stakes)
+  - Each dependent tenant's stake is discoverable from the data model
+  - A single stakeholder's decommission request does not destroy the shared segment
+  - The system requires co-approval or removal of remaining stakes before decommission proceeds
+  - Denied/held decommission is reported with the blocking stakeholders named
+  - The attempt and its governance outcome are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: shared VLAN with per-tenant stakes read; dependents enumerated
+  - domain: policy
+    interaction: shared-resource decommission policy blocks unilateral destruction
+  - domain: audit
+    interaction: blocked decommission and blocking stakeholders recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- vlan
+- shared-resource
+- multi-tenancy
+- stakes
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/008-vlan-reference-vs-inline.yaml b/dav/use-cases/hammer-networking/008-vlan-reference-vs-inline.yaml
new file mode 100644
index 0000000..be03341
--- /dev/null
+++ b/dav/use-cases/hammer-networking/008-vlan-reference-vs-inline.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-networking-008
+handle: networking/vlan-reference-vs-inline
+scenario:
+  description: 'Two VM requests both need to sit on VLAN 90. Request A references an existing Network.VLAN
+    by UUID/handle; request B declares the same VLAN inline inside the VM intent. The system must converge
+    both to the SAME single Network.VLAN record — the inline form is sugar that resolves to (or creates
+    once and dedupes to) the referenced record, not a second parallel segment. This tests that by-reference
+    and inline authoring are two projections of one resource, and that inline declarations do not silently
+    fork duplicate segments that later drift apart.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Prove inline VLAN declaration and by-reference attachment resolve to one segment
+  success_criteria:
+  - By-reference attachment binds the VM to the existing Network.VLAN without creating a new one
+  - Inline VLAN declaration resolves to the same segment identity (create-once / dedupe)
+  - Exactly one Network.VLAN record exists for the shared segment after both requests
+  - Both VMs show a dependency edge to the same VLAN UUID
+  - No duplicate or shadow segment is created by the inline form
+  - Resolution of inline-to-record is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: inline VLAN normalized to a single referenced Network.VLAN record
+  - domain: policy
+    interaction: dedupe/identity resolution validated before realization
+  - domain: audit
+    interaction: inline-to-reference resolution recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- vlan
+- by-reference
+- inline
+- dedupe
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/009-connectivity-ordering-network-before-compute.yaml b/dav/use-cases/hammer-networking/009-connectivity-ordering-network-before-compute.yaml
new file mode 100644
index 0000000..f73dd74
--- /dev/null
+++ b/dav/use-cases/hammer-networking/009-connectivity-ordering-network-before-compute.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-networking-009
+handle: networking/connectivity-ordering-network-before-compute
+scenario:
+  description: 'A three-tier application is requested as one intent: a VLAN, a gateway, and three VMs
+    that attach to the VLAN and route through the gateway. The system must derive from the dependency
+    graph that the segment and gateway are realized BEFORE any VM is dispatched, so no compute is ever
+    launched onto a network that does not yet exist. This tests that connectivity is a hard dependency
+    that constrains ordering, not an afterthought applied post-boot.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Provision a full stack and verify network resources realize before compute
+  success_criteria:
+  - The dependency graph places Network.VLAN and Network.Gateway upstream of the VMs
+  - The VLAN and gateway are realized before any VM dispatch occurs
+  - No VM is dispatched onto a not-yet-realized segment
+  - VMs attach to the already-realized segment and route through the realized gateway
+  - Ordering is derived from the graph, not from a hand-written sequence
+  - The realized order is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph orders network resources upstream of compute
+  - domain: provider
+    interaction: network providers realize segment and gateway before compute providers dispatch
+  - domain: audit
+    interaction: realized ordering recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- ordering
+- dependency-graph
+- full-stack
+- connectivity
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/010-address-service-boot-dependency.yaml b/dav/use-cases/hammer-networking/010-address-service-boot-dependency.yaml
new file mode 100644
index 0000000..9c9d2ea
--- /dev/null
+++ b/dav/use-cases/hammer-networking/010-address-service-boot-dependency.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-networking-010
+handle: networking/address-service-boot-dependency
+scenario:
+  description: 'A diskless/PXE-style host requires DHCP (address + next-server) and DNS to boot at all.
+    The intent declares a hard dependency from the host onto a Network.AddressService (services: dhcp,
+    dns). The system must realize and confirm the AddressService is healthy before booting the dependent
+    host, and — critically for shutdown ordering — must stop the host BEFORE the AddressService in a reverse-topo
+    teardown, because a host cannot renew a lease from a service that is already gone. This tests that
+    an AddressService is a real boot-time dependency, not ambient infrastructure.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Boot a host that hard-depends on a DHCP/DNS AddressService and verify ordering both ways
+  success_criteria:
+  - Host declares a hard dependency on the Network.AddressService (services dhcp, dns)
+  - AddressService is realized and confirmed healthy before the host boots
+  - The dependent host does not boot while the AddressService is unavailable
+  - Reverse-topo shutdown stops the host before the AddressService (served_by relationship honored)
+  - The dependency edge is discoverable in the data model
+  - Boot and shutdown ordering are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: hard dependency host -> AddressService recorded; served_by ordering derived
+  - domain: provider
+    interaction: AddressService realized and health-checked before dependent host boots
+  - domain: audit
+    interaction: boot and reverse-topo shutdown ordering recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- address-service
+- dhcp
+- dns
+- boot-dependency
+- ordering
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/011-l3-gateway-nat-acl.yaml b/dav/use-cases/hammer-networking/011-l3-gateway-nat-acl.yaml
new file mode 100644
index 0000000..9fcf622
--- /dev/null
+++ b/dav/use-cases/hammer-networking/011-l3-gateway-nat-acl.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-networking-011
+handle: networking/l3-gateway-nat-acl
+scenario:
+  description: 'A tenant needs egress from a private segment (10.20.0.0/22) to the internet with source
+    NAT, plus an ACL that permits only outbound 443 and denies inbound. The intent declares a Network.Gateway
+    with a nat policy and an attached ACL, routing between the tenant VLAN and the uplink. The system
+    must model routing, NAT, and ACL as declarative properties of the gateway record and realize them
+    coherently, so the security posture is a first-class managed intent rather than a switch/firewall
+    config edited by hand.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - tenancy-authority
+  intent: Provision an L3 gateway with source NAT and an egress-only ACL
+  success_criteria:
+  - Network.Gateway record captures the routed segments (inside VLAN, uplink)
+  - Source NAT policy is recorded as a property of the gateway (nat)
+  - An ACL permitting only outbound 443 and denying inbound is recorded and attached
+  - Provider realizes routing, NAT, and ACL coherently on the gateway
+  - Realized state confirms egress works and disallowed flows are dropped
+  - The routing/NAT/ACL intent and its realization are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: gateway with routed segments, NAT, and ACL recorded as one record
+  - domain: policy
+    interaction: ACL/NAT posture validated against the tenant's security policy
+  - domain: provider
+    interaction: gateway provider realizes routing, NAT, and ACL
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- gateway
+- nat
+- acl
+- routing
+- security
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/012-network-provider-failure-midprovision.yaml b/dav/use-cases/hammer-networking/012-network-provider-failure-midprovision.yaml
new file mode 100644
index 0000000..7fec6e7
--- /dev/null
+++ b/dav/use-cases/hammer-networking/012-network-provider-failure-midprovision.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-networking-012
+handle: networking/network-provider-failure-midprovision
+scenario:
+  description: 'A stack requests a VLAN, a gateway, and two IPAddress bindings. After the VLAN is realized,
+    the network provider fails mid-flight while realizing the gateway (SDN controller returns an error
+    / times out). The system must halt cleanly, not proceed to bind addresses onto a segment whose gateway
+    does not exist, record which resources are realized versus pending, and leave the environment in a
+    recoverable state so a retry resumes rather than duplicates. This tests partial-failure handling within
+    a single network provisioning arc.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+  intent: Survive a network-provider failure partway through a multi-resource network provision
+  success_criteria:
+  - The already-realized VLAN is preserved and marked realized
+  - Gateway realization failure is detected and reported with a specific reason
+  - Downstream address bindings that depend on the gateway are not dispatched
+  - Realized-vs-pending state is recorded accurately for every resource in the arc
+  - No duplicate or orphaned segment/gateway is created by the failure
+  - Retry resumes from the failed step rather than re-realizing completed resources
+  - The failure and recovery state are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: network provider fails realizing the gateway; error surfaced
+  - domain: data
+    interaction: realized-vs-pending recorded per resource; no orphans
+  - domain: audit
+    interaction: partial failure and recoverable state recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- provider-failure
+- partial-failure
+- recovery
+- gateway
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/013-dual-stack-ipv6-address.yaml b/dav/use-cases/hammer-networking/013-dual-stack-ipv6-address.yaml
new file mode 100644
index 0000000..2b8dbd1
--- /dev/null
+++ b/dav/use-cases/hammer-networking/013-dual-stack-ipv6-address.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-networking-013
+handle: networking/dual-stack-ipv6-address
+scenario:
+  description: 'An existing service currently has a single IPv4 Network.IPAddress. The team modifies it
+    to dual-stack: keep the static IPv4 and add an IPv6 Network.IPAddress (allocation: static or auto)
+    on the same Hardware.NetworkInterface. The system must model two distinct address records distinguished
+    by ip_family on one interface, apply the change as a modification (not a rebuild), and preserve the
+    existing IPv4 UUID. This tests that address family is a first-class discriminator and that dual-stack
+    is additive rather than a replace-the-interface operation.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Add an IPv6 address to an interface that already has an IPv4 address (go dual-stack)
+  success_criteria:
+  - A second Network.IPAddress is created with ip_family ipv6 on the same interface
+  - The existing IPv4 Network.IPAddress record and its UUID are preserved unchanged
+  - Both records coexist on the one Hardware.NetworkInterface, distinguished by ip_family
+  - The change is processed as a modification, not a destroy/rebuild of the interface
+  - Realized state shows both families active on the interface
+  - The additive change is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: second IPAddress (ipv6) added; ipv4 record preserved by ip_family discriminator
+  - domain: provider
+    interaction: interface reconfigured additively to carry both families
+  - domain: audit
+    interaction: additive dual-stack modification recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- ip-address
+- ipv6
+- dual-stack
+- modification
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/014-bond-bridge-interface-topology.yaml b/dav/use-cases/hammer-networking/014-bond-bridge-interface-topology.yaml
new file mode 100644
index 0000000..0c253e5
--- /dev/null
+++ b/dav/use-cases/hammer-networking/014-bond-bridge-interface-topology.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-networking-014
+handle: networking/bond-bridge-interface-topology
+scenario:
+  description: 'A host is configured with two physical NICs bonded (802.3ad) and a bridge (br0) built
+    on top of the bond, with a VLAN interface stacked on the bridge. Each layer is a Hardware.NetworkInterface
+    whose device_class distinguishes physical/bond/bridge/vlan, linked by parent_device / lower_layer
+    to the layer beneath it (per #267 config-vs- component). The system must model this multi-layer interface
+    topology as a connected set of records and realize it in the correct bottom-up order. This tests whether
+    composite host interface stacks are representable without flattening them into an opaque blob.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Model and realize a bond -> bridge -> VLAN interface stack on a host
+  success_criteria:
+  - Each layer (physical NICs, bond, bridge, vlan) is a Hardware.NetworkInterface record
+  - device_class distinguishes physical / bond / bridge / vlan per record
+  - lower_layer / parent_device links each layer to the one beneath it
+  - The stack forms a coherent dependency chain in the data model
+  - Provider realizes the layers bottom-up (physical -> bond -> bridge -> vlan)
+  - The topology and realized order are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: layered NetworkInterface records linked by lower_layer/parent_device
+  - domain: provider
+    interaction: interface stack realized bottom-up via NMstate
+  - domain: audit
+    interaction: interface topology and realized order recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- interface
+- bond
+- bridge
+- topology
+- composite
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/015-cross-tenant-vlan-leakage-denied.yaml b/dav/use-cases/hammer-networking/015-cross-tenant-vlan-leakage-denied.yaml
new file mode 100644
index 0000000..31655f4
--- /dev/null
+++ b/dav/use-cases/hammer-networking/015-cross-tenant-vlan-leakage-denied.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-networking-015
+handle: networking/cross-tenant-vlan-leakage-denied
+scenario:
+  description: 'Tenant B requests a VM and attaches it — by referencing the VLAN UUID directly — to tenant
+    A''s private segment, attempting to gain L2 adjacency to A''s workloads. The system must recognize
+    that the referenced Network.VLAN is owned/staked by another tenant, deny the cross-tenant attachment,
+    and refuse to realize L2 connectivity across the isolation boundary. This probes whether segment ownership
+    is enforced at attach time or whether any actor who knows a VLAN''s identity can bridge into it.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - tenancy-authority
+  intent: Attach a VM to another tenant's private VLAN and get denied
+  success_criteria:
+  - The referenced VLAN's tenant ownership/stake is resolved from the data model
+  - The attach request is evaluated against cross-tenant isolation policy
+  - The cross-tenant attachment is denied and no L2 adjacency is realized
+  - The requesting VM is not left half-attached to the foreign segment
+  - The denial names the isolation boundary that was violated
+  - The attempted cross-tenant attach and denial are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: cross-tenant isolation policy denies attach to a foreign-owned VLAN
+  - domain: data
+    interaction: VLAN ownership/stake resolved; no cross-tenant edge written
+  - domain: audit
+    interaction: attempted leakage and denial recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- vlan
+- multi-tenancy
+- isolation
+- leakage
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/016-vlan-decommission-dangling-interfaces.yaml b/dav/use-cases/hammer-networking/016-vlan-decommission-dangling-interfaces.yaml
new file mode 100644
index 0000000..ea0c209
--- /dev/null
+++ b/dav/use-cases/hammer-networking/016-vlan-decommission-dangling-interfaces.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-networking-016
+handle: networking/vlan-decommission-dangling-interfaces
+scenario:
+  description: 'An operator requests decommission of VLAN 90, but two VirtualMachines still have Hardware.NetworkInterface
+    records attached to it and a static Network.IPAddress reservation is bound within it. The system must
+    detect the dangling dependents, refuse to strand them by deleting the segment out from under live
+    interfaces, and require the dependents be detached or decommissioned first. This tests referential
+    integrity on teardown — that a segment cannot vanish while interfaces and addresses still point at
+    it.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Decommission a VLAN that still has interfaces and a reservation depending on it
+  success_criteria:
+  - Dependent Hardware.NetworkInterface and Network.IPAddress records are discovered
+  - The decommission is blocked while live dependents still reference the VLAN
+  - The system reports which dependents must be detached/decommissioned first
+  - No interface or address record is left dangling to a deleted segment
+  - Once dependents are cleared, the VLAN decommission proceeds cleanly
+  - The blocked and eventual decommission are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependents on the VLAN enumerated; referential integrity checked
+  - domain: policy
+    interaction: decommission policy blocks deletion while dependents remain
+  - domain: audit
+    interaction: blocked-then-completed decommission recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- vlan
+- decommission
+- dangling-dependents
+- referential-integrity
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/017-network-drift-manual-ip-change.yaml b/dav/use-cases/hammer-networking/017-network-drift-manual-ip-change.yaml
new file mode 100644
index 0000000..4611397
--- /dev/null
+++ b/dav/use-cases/hammer-networking/017-network-drift-manual-ip-change.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-networking-017
+handle: networking/network-drift-manual-ip-change
+scenario:
+  description: 'Someone SSHes into a host and changes an interface''s address by hand with nmcli, diverging
+    the realized NMstate from the declared Network.ConnectionProfile / Network.IPAddress intent. On the
+    next reconciliation the system must detect the drift between intent and realized state, report exactly
+    which fields diverged (address, method), and either flag or converge the interface back to the declared
+    intent according to policy — without losing the record of what the box actually looked like. This
+    tests drift detection on host network configuration.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+  intent: Detect and reconcile an out-of-band manual change to a host's network config
+  success_criteria:
+  - Reconciliation compares realized NMstate against declared ConnectionProfile/IPAddress intent
+  - Drift is detected and the diverged fields (address, method) are reported specifically
+  - The realized-state record reflects what the host actually had before reconvergence
+  - Per policy, the interface is either flagged for approval or converged back to intent
+  - If converged, realized state returns to match the declared intent
+  - The drift detection and resolution are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: realized NMstate diffed against intent; diverged fields identified
+  - domain: policy
+    interaction: drift-resolution policy chooses flag vs converge
+  - domain: audit
+    interaction: drift and its resolution recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- drift
+- reconciliation
+- connection-profile
+- ip-address
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/018-network-brownfield-ingestion.yaml b/dav/use-cases/hammer-networking/018-network-brownfield-ingestion.yaml
new file mode 100644
index 0000000..f78773c
--- /dev/null
+++ b/dav/use-cases/hammer-networking/018-network-brownfield-ingestion.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-networking-018
+handle: networking/network-brownfield-ingestion
+scenario:
+  description: 'An existing homelab has VLANs, a Kea DHCP server with dozens of static reservations, a
+    DNS zone, and a gateway — all configured by hand over years, none of it under the data model. An operator
+    ingests this brownfield estate: the system must discover the segments, reservations, zone, and gateway,
+    and represent each as the correct record type — reservations as Network.IPAddress(allocation: static)
+    per ADR-023, the DHCP/DNS daemons as Network.AddressService, segments as Network.VLAN — with cross-references
+    intact. This tests faithful discovery-to-model ingestion of a network estate without inventing intent
+    that was never declared.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Ingest a hand-built brownfield network estate into the data model
+  success_criteria:
+  - Existing VLANs are discovered and represented as Network.VLAN records
+  - Static DHCP reservations are ingested as Network.IPAddress(allocation=static) per ADR-023
+  - The DHCP and DNS daemons are represented as Network.AddressService (services dhcp/dns)
+  - Cross-references (reservation -> interface, host -> segment) are reconstructed
+  - Ingested records are marked as adopted/brownfield, not fabricated as fresh intent
+  - Anything undiscoverable is reported as a gap rather than silently guessed
+  - The ingestion and adopted set are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: discovered segments/reservations/services mapped to canonical record types
+  - domain: policy
+    interaction: adoption policy marks records brownfield and validates references
+  - domain: audit
+    interaction: ingested and adopted network estate recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- brownfield
+- ingestion
+- adoption
+- adr-023
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/019-sovereign-egress-region-lock.yaml b/dav/use-cases/hammer-networking/019-sovereign-egress-region-lock.yaml
new file mode 100644
index 0000000..c36a551
--- /dev/null
+++ b/dav/use-cases/hammer-networking/019-sovereign-egress-region-lock.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-networking-019
+handle: networking/sovereign-egress-region-lock
+scenario:
+  description: 'Under a sovereign mandate, a regulated tenant''s segment must never route to an uplink
+    or NAT that egresses outside the national boundary. An operator requests a Network.Gateway whose uplink
+    resolves to a peer/region flagged out-of-territory. The system must evaluate the gateway''s egress
+    path against a sovereignty policy and deny (or hold) the routing intent because it would carry traffic
+    across the border. This probes whether egress/routing topology is subject to data-sovereignty constraints,
+    or whether sovereignty is only enforced on data-at-rest and placement while the network path escapes
+    governance.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Prevent a gateway from routing a sovereign tenant's traffic out of territory
+  success_criteria:
+  - The gateway's egress/uplink path and its territory are resolved from the model
+  - Sovereignty policy evaluates the egress path, not just data placement
+  - An out-of-territory egress route is denied or held for escalation
+  - No cross-border routing/NAT is realized for the sovereign segment
+  - The denial cites the sovereignty boundary and the offending egress
+  - If egress-path sovereignty is not modelled, the gap is reported explicitly
+  - The evaluation and outcome are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty policy evaluates the gateway egress path and territory
+  - domain: provider
+    interaction: cross-border routing/NAT is not realized
+  - domain: audit
+    interaction: sovereignty evaluation and denial recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- gateway
+- sovereignty
+- egress
+- routing
+- edge
+- gap-probe
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-networking/020-network-fabric-rehydration-ordering.yaml b/dav/use-cases/hammer-networking/020-network-fabric-rehydration-ordering.yaml
new file mode 100644
index 0000000..97187a0
--- /dev/null
+++ b/dav/use-cases/hammer-networking/020-network-fabric-rehydration-ordering.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-networking-020
+handle: networking/network-fabric-rehydration-ordering
+scenario:
+  description: 'After total loss, an environment is rehydrated from stored intent. The rebuild must reconstruct
+    the network fabric first — VLANs, the DHCP/DNS AddressService, static IPAddress reservations, and
+    the gateway — before any compute or storage is re-realized, because addresses, DNS names, and L2/L3
+    reachability are preconditions for everything downstream. The system must derive this ordering from
+    the dependency graph, preserve address/reservation UUIDs so hosts return on their original addresses,
+    and re-realize the fabric faithfully. This tests that network is a first-class, correctly-ordered
+    participant in rehydration, not an assumed-present substrate.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Rehydrate the full environment and verify the network fabric is rebuilt first and faithfully
+  success_criteria:
+  - Rebuild plan is derived from stored intent and the dependency graph (not a static replay)
+  - Network fabric (VLANs, AddressService, reservations, gateway) is realized before compute/storage
+  - Static Network.IPAddress reservation UUIDs and addresses are preserved so hosts return unchanged
+  - The DHCP/DNS AddressService is healthy before dependent hosts re-boot
+  - Downstream compute/storage attach to the already-realized fabric
+  - Post-rehydration realized network state matches the original intent
+  - The rehydration ordering is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph orders fabric upstream; reservation UUIDs preserved
+  - domain: provider
+    interaction: network providers re-realize VLANs, AddressService, and gateway before downstream
+  - domain: audit
+    interaction: rehydration ordering and preserved identities recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- networking
+- rehydration
+- ordering
+- fabric
+- address-service
+- full-stack
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-peer-dcm/001-connected-cross-dcm-resource-realization.yaml b/dav/use-cases/hammer-peer-dcm/001-connected-cross-dcm-resource-realization.yaml
new file mode 100644
index 0000000..6c56527
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/001-connected-cross-dcm-resource-realization.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-peer-dcm-001
+handle: peer-dcm/connected-cross-dcm-resource-realization
+scenario:
+  description: A local DCM has a request whose only eligible provider lives in a peer DCM's estate. Placement selects
+    the peer, the realization request is dispatched across the federation boundary, and the peer realizes the resource
+    in its own estate and returns a realized handle. The local DCM records the resource with a reference to the
+    owning peer and does not claim direct control of it.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+  intent: Realize a resource on a peer DCM's provider across the federation boundary
+  success_criteria:
+  - Placement identifies the peer DCM as the eligible provider
+  - The realization request is dispatched across the federation boundary
+  - The peer realizes the resource and returns a realized handle
+  - Local realized state records the resource with a reference to the owning peer
+  - The cross-boundary dispatch and the peer acknowledgement are audited
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the peer DCM's provider realizes the resource
+  - domain: data
+    interaction: local records the peer-owned reference, not direct control
+  - domain: audit
+    interaction: cross-boundary dispatch + peer ack recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- connected
+- cross-boundary
+- realization
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - A peer DCM is federated and advertises the eligible provider
+  postconditions:
+  - The resource runs in the peer's estate; the local record references the owner
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/002-connected-peer-capability-discovery.yaml b/dav/use-cases/hammer-peer-dcm/002-connected-peer-capability-discovery.yaml
new file mode 100644
index 0000000..19d6919
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/002-connected-peer-capability-discovery.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-peer-dcm-002
+handle: peer-dcm/connected-peer-capability-discovery
+scenario:
+  description: A local DCM needs a capability no local provider offers. It queries its federated peers' advertised
+    capability sets and finds a peer that provides it. The discovery is read-only and respects each peer's advertised
+    (not internal) capability surface.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+  intent: Discover a peer DCM's advertised capabilities to find an eligible provider
+  success_criteria:
+  - The local DCM queries federated peers' advertised capabilities
+  - A peer advertising the needed capability is identified
+  - Only advertised (not internal) capability is exposed across the boundary
+  - The discovered peer capability is recorded for placement
+  - No realization occurs during discovery
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peers advertise their capability surface across the federation
+  - domain: policy
+    interaction: admission matches the needed capability to a peer's advertised set
+  - domain: data
+    interaction: the discovered peer capability is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- connected
+- capability-discovery
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Peers are federated and advertise capability sets
+  postconditions:
+  - An eligible peer capability is discovered for placement
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/003-connected-federated-placement-across-peers.yaml b/dav/use-cases/hammer-peer-dcm/003-connected-federated-placement-across-peers.yaml
new file mode 100644
index 0000000..d502c84
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/003-connected-federated-placement-across-peers.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-peer-dcm-003
+handle: peer-dcm/connected-federated-placement-across-peers
+scenario:
+  description: A portable request is evaluated for placement across a mixed landscape — the local DCM's providers
+    plus several federated peers. Placement scores each candidate by requirements, advertised capability, and policy,
+    and selects the best fit, which may be local or a peer.
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+  intent: Place a workload by evaluating providers across the local DCM and multiple peers
+  success_criteria:
+  - Placement enumerates local and federated-peer candidates
+  - Each candidate is scored by requirements, capability, and policy
+  - The best-fitting candidate is selected (local or peer)
+  - If a peer wins, realization dispatches across the boundary
+  - The placement decision and the candidate set are audited
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: scores mixed local+peer candidates by requirements and capability
+  - domain: provider
+    interaction: the selected candidate (local or peer) realizes the workload
+  - domain: audit
+    interaction: the candidate set and decision are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- connected
+- placement
+- mixed-landscape
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - The local DCM and several peers all advertise eligible providers
+  postconditions:
+  - The workload runs on the best-fitting candidate across the federation
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/004-connected-cross-dcm-dependency-spanning-boundary.yaml b/dav/use-cases/hammer-peer-dcm/004-connected-cross-dcm-dependency-spanning-boundary.yaml
new file mode 100644
index 0000000..62ed752
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/004-connected-cross-dcm-dependency-spanning-boundary.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-peer-dcm-004
+handle: peer-dcm/connected-cross-dcm-dependency-spanning-boundary
+scenario:
+  description: 'A resource requested in the local DCM depends on a resource that is realized and owned in a peer
+    DCM. The dependency graph spans the federation boundary: the local resource''s criteria derive from the peer
+    resource''s realized facts, passed across the boundary as a realized payload.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+  intent: Resolve a dependency where a resource depends on one realized in a peer DCM
+  success_criteria:
+  - The dependency graph includes a cross-boundary edge to the peer-owned resource
+  - The peer resource's realized facts are passed across as a payload
+  - The local resource's criteria resolve from the peer's realized facts
+  - The cross-DCM dependency is recorded with the peer owner
+  - Ordering respects the cross-boundary dependency
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: peer realized facts cross the boundary as a payload
+  - domain: policy
+    interaction: local criteria resolve from the peer's realized facts
+  - domain: provider
+    interaction: the peer owns the depended-on resource
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- connected
+- cross-dependency
+- dependency-graph
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - A depended-on resource is realized and owned in a peer DCM
+  postconditions:
+  - The local resource resolves against the peer-owned dependency
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/005-connected-peer-owned-reference-governed-resolve.yaml b/dav/use-cases/hammer-peer-dcm/005-connected-peer-owned-reference-governed-resolve.yaml
new file mode 100644
index 0000000..fa71227
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/005-connected-peer-owned-reference-governed-resolve.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-peer-dcm-005
+handle: peer-dcm/connected-peer-owned-reference-governed-resolve
+scenario:
+  description: 'A local record references an entity owned by a peer DCM. Resolving that reference is a governed
+    cross-boundary dereference: the resolve is permitted only if policy (sovereignty, tenancy, authorization) admits
+    it, and the resolved value carries provenance of the peer authority.'
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - federation-peer-operator
+    - compliance-auditor
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Resolve a reference to a peer-owned entity across the federation boundary, governed
+  success_criteria:
+  - The reference to the peer-owned entity is addressable across the federation
+  - The dereference is gated by sovereignty/tenancy/authorization policy
+  - Only a permitted dereference returns the peer value
+  - The resolved value carries the peer-authority provenance
+  - A denied dereference is recorded, not silently dropped
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: governs the cross-boundary dereference by sovereignty/tenancy/authz
+  - domain: data
+    interaction: the resolved value carries peer-authority provenance
+  - domain: audit
+    interaction: the governed dereference is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- connected
+- reference-resolution
+- governed-dereference
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - A local record references a peer-owned entity
+  postconditions:
+  - The reference resolves under policy with peer provenance
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/006-connected-federated-blast-radius-across-peer.yaml b/dav/use-cases/hammer-peer-dcm/006-connected-federated-blast-radius-across-peer.yaml
new file mode 100644
index 0000000..3838380
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/006-connected-federated-blast-radius-across-peer.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-peer-dcm-006
+handle: peer-dcm/connected-federated-blast-radius-across-peer
+scenario:
+  description: A change or a discovered vulnerability in the local estate must be impact-analyzed across the federation.
+    Blast-radius reverse-walks the reference edges, including cross-boundary edges into peer DCMs, to enumerate
+    affected peer-owned resources — surfaced to the peer, not acted on directly.
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Reverse-walk impact across a peer boundary to find affected peer-owned resources
+  success_criteria:
+  - Blast-radius reverse-walks reference edges including cross-boundary edges
+  - Affected peer-owned resources are enumerated across the federation
+  - The impact set spanning peers is reported, not directly remediated
+  - The peer is surfaced the affected set within its estate
+  - The cross-boundary impact analysis is audited
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: cross_dependency_payload
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: reverse-walk crosses the federation boundary into peer edges
+  - domain: policy
+    interaction: impact is surfaced to the peer, not remediated across the boundary
+  - domain: audit
+    interaction: the cross-boundary impact analysis is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- connected
+- blast-radius
+- impact
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Reference edges span into peer DCMs
+  postconditions:
+  - The federated impact set is enumerated and surfaced to peers
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/007-disconnected-peer-disconnect-mid-realization.yaml b/dav/use-cases/hammer-peer-dcm/007-disconnected-peer-disconnect-mid-realization.yaml
new file mode 100644
index 0000000..9f54c89
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/007-disconnected-peer-disconnect-mid-realization.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-peer-dcm-007
+handle: peer-dcm/disconnected-peer-disconnect-mid-realization
+scenario:
+  description: A realization dispatched to a peer DCM is in progress when the peer becomes unreachable. The local
+    DCM records the disconnect, holds the operation in a non-complete state, preserves the pre-dispatch local state,
+    and retries when the peer returns. Nothing is marked realized while the peer is unreachable.
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - federation-peer-operator
+  intent: Hold and retry a cross-DCM realization when the peer disconnects mid-operation
+  success_criteria:
+  - The cross-DCM realization is in flight to the peer
+  - The peer becomes unreachable mid-operation
+  - The local DCM records the peer disconnect
+  - The operation is held non-complete; pre-dispatch state preserved
+  - The operation is retried when the peer returns
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the peer DCM becomes unreachable mid-realization
+  - domain: policy
+    interaction: recovery policy holds the operation pending the peer
+  - domain: audit
+    interaction: the disconnect and hold are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- disconnected
+- peer-dcm-disconnect
+- recovery
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - A realization is dispatched to a peer that then disconnects
+  postconditions:
+  - The operation is held and retryable; local state intact
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/008-disconnected-peer-unreachable-placement-fallback.yaml b/dav/use-cases/hammer-peer-dcm/008-disconnected-peer-unreachable-placement-fallback.yaml
new file mode 100644
index 0000000..c4af156
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/008-disconnected-peer-unreachable-placement-fallback.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-peer-dcm-008
+handle: peer-dcm/disconnected-peer-unreachable-placement-fallback
+scenario:
+  description: Placement selects a peer DCM to host a workload, but the peer is unreachable at dispatch. A recovery
+    policy re-evaluates placement across the remaining candidates — local or another peer — and realizes there,
+    recording the peer disconnect and the fallback.
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - federation-peer-operator
+  intent: Fall back to another candidate when the peer that would host is unreachable
+  success_criteria:
+  - Placement selects a peer that is then unreachable at dispatch
+  - The peer disconnect is detected before realization
+  - A recovery policy re-evaluates the remaining candidates
+  - The workload realizes on a reachable candidate (local or another peer)
+  - The disconnect and fallback are recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the first-choice peer is unreachable; another candidate realizes
+  - domain: policy
+    interaction: recovery policy re-evaluates placement on disconnect
+  - domain: audit
+    interaction: the disconnect and fallback recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- disconnected
+- peer-dcm-disconnect
+- fallback
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - The first-choice peer is unreachable at dispatch; other candidates exist
+  postconditions:
+  - The workload runs on a reachable candidate; fallback recorded
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/009-disconnected-degraded-federated-query-partial.yaml b/dav/use-cases/hammer-peer-dcm/009-disconnected-degraded-federated-query-partial.yaml
new file mode 100644
index 0000000..272741b
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/009-disconnected-degraded-federated-query-partial.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-peer-dcm-009
+handle: peer-dcm/disconnected-degraded-federated-query-partial
+scenario:
+  description: A federated query spans several peer DCMs to assemble a cross-federation view. One peer is unreachable,
+    so the result is partial — the reachable peers' data plus an explicit note of the missing peer. The query does
+    not fail wholesale or silently omit the gap.
+  actor:
+    persona: platform-operator
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+  intent: Return partial results when a federated query cannot reach one peer
+  success_criteria:
+  - The federated query fans out to several peers
+  - One peer is unreachable during the query
+  - The reachable peers' results are returned
+  - The unreachable peer's gap is explicitly noted, not silently omitted
+  - The partial-result condition is recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: one peer is unreachable during the fan-out
+  - domain: policy
+    interaction: recovery policy returns partial with an explicit gap
+  - domain: data
+    interaction: the reachable results + the noted gap are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- disconnected
+- partial-fulfillment
+- federated-query
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - A federated query spans peers, one of which is unreachable
+  postconditions:
+  - Partial results returned with the missing peer explicitly noted
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/010-disconnected-peer-reconnect-resync-drift.yaml b/dav/use-cases/hammer-peer-dcm/010-disconnected-peer-reconnect-resync-drift.yaml
new file mode 100644
index 0000000..be7b10b
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/010-disconnected-peer-reconnect-resync-drift.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-peer-dcm-010
+handle: peer-dcm/disconnected-peer-reconnect-resync-drift
+scenario:
+  description: A peer DCM returns after a period of disconnection. The local DCM re-checks the peer-owned resources
+    it references and finds the peer's discovered state has drifted from the last-known realized state during the
+    outage. The divergence is recorded as a data inconsistency and enters reconciliation.
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Reconcile peer-owned state after a peer returns from a disconnect
+  success_criteria:
+  - The peer returns after a disconnection window
+  - The local DCM re-checks the referenced peer-owned resources
+  - The peer's discovered state has drifted from last-known realized
+  - The divergence is recorded as a data inconsistency
+  - Reconciliation across the boundary is initiated
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the peer's state drifted during the outage
+  - domain: policy
+    interaction: drift across the boundary triggers reconciliation
+  - domain: audit
+    interaction: the post-reconnect drift is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- disconnected
+- reconnect
+- drift-detection
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - A peer returns after a disconnection window
+  postconditions:
+  - The cross-boundary drift is detected and reconciliation begins
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/011-sovereign-peer-federation-residency-gated.yaml b/dav/use-cases/hammer-peer-dcm/011-sovereign-peer-federation-residency-gated.yaml
new file mode 100644
index 0000000..e6ccc9b
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/011-sovereign-peer-federation-residency-gated.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-peer-dcm-011
+handle: peer-dcm/sovereign-peer-federation-residency-gated
+scenario:
+  description: A sovereign-profile workload may be placed on a peer DCM only if the peer operates in a jurisdiction
+    the residency policy permits. Placement filters the federated peers to the compliant set and selects from it;
+    peers in non-compliant jurisdictions are excluded before any dispatch.
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Federate only with peers in a compliant jurisdiction for a sovereign workload
+  success_criteria:
+  - The sovereign residency policy is read for the workload
+  - Federated peers are filtered to the compliant-jurisdiction set
+  - Non-compliant-jurisdiction peers are excluded before dispatch
+  - The workload realizes on a compliant peer
+  - The residency constraint and the eligible set are audited
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: residency policy filters peers to the compliant jurisdiction
+  - domain: provider
+    interaction: a compliant-jurisdiction peer realizes the workload
+  - domain: audit
+    interaction: the residency constraint + eligible set recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- sovereignty
+- residency
+- sovereign-profile
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Sovereign profile; peers operate in varied jurisdictions
+  postconditions:
+  - The workload runs on a compliant-jurisdiction peer
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/012-sovereign-cross-jurisdiction-peer-denied.yaml b/dav/use-cases/hammer-peer-dcm/012-sovereign-cross-jurisdiction-peer-denied.yaml
new file mode 100644
index 0000000..5ef4155
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/012-sovereign-cross-jurisdiction-peer-denied.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-peer-dcm-012
+handle: peer-dcm/sovereign-cross-jurisdiction-peer-denied
+scenario:
+  description: A sovereign workload's only capable peer operates in a jurisdiction the residency policy forbids.
+    The sovereignty gate rejects federation to that peer before any realization; the request is denied as a policy
+    violation rather than placed non-compliantly.
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Deny federation to a peer in a non-compliant jurisdiction
+  success_criteria:
+  - The only capable peer is in a forbidden jurisdiction
+  - The sovereignty gate evaluates the peer's jurisdiction
+  - Federation to the non-compliant peer is rejected
+  - The request is denied as a policy violation, not placed
+  - The denial and the reason are audited
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: policy_violation
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty gate rejects the non-compliant-jurisdiction peer
+  - domain: provider
+    interaction: no compliant peer is available to realize
+  - domain: audit
+    interaction: the policy-violation denial recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- sovereignty
+- policy-violation
+- cross-jurisdiction
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Sovereign profile; the only capable peer is non-compliant
+  postconditions:
+  - Federation denied; nothing placed non-compliantly
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/013-sovereign-fsi-peer-attestation-gate-stale.yaml b/dav/use-cases/hammer-peer-dcm/013-sovereign-fsi-peer-attestation-gate-stale.yaml
new file mode 100644
index 0000000..c9d67fd
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/013-sovereign-fsi-peer-attestation-gate-stale.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-peer-dcm-013
+handle: peer-dcm/sovereign-fsi-peer-attestation-gate-stale
+scenario:
+  description: In an FSI profile, a peer DCM must present a fresh attestation of its control plane before federation
+    is allowed. The candidate peer's attestation has expired; the attestation gate blocks peer selection until a
+    fresh proof is verified, and the request escalates or waits rather than federating on stale proof.
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Block federation to an FSI peer whose attestation is stale
+  success_criteria:
+  - The FSI profile requires a fresh peer attestation before federation
+  - The candidate peer's attestation is stale/expired
+  - The attestation gate blocks peer selection on stale proof
+  - Federation waits for a fresh, verified attestation
+  - The blocked federation and the stale attestation are audited
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: compliance_gated
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: attestation gate blocks the peer on stale proof
+  - domain: provider
+    interaction: the peer must re-attest before it is eligible
+  - domain: audit
+    interaction: the blocked federation + stale attestation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- sovereignty
+- attestation
+- fsi-profile
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - FSI profile; the candidate peer's attestation has expired
+  postconditions:
+  - Federation blocked until the peer re-attests
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/014-sovereign-peer-realized-residency-verified.yaml b/dav/use-cases/hammer-peer-dcm/014-sovereign-peer-realized-residency-verified.yaml
new file mode 100644
index 0000000..ad1edc0
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/014-sovereign-peer-realized-residency-verified.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-peer-dcm-014
+handle: peer-dcm/sovereign-peer-realized-residency-verified
+scenario:
+  description: A sovereign workload is realized on a compliant peer DCM. After realization, the peer reports the
+    resource's actual residency, which the local DCM verifies against the required residency and records on the
+    realized resource. A mismatch would trigger remediation; here it matches.
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Verify the residency of a resource realized on a peer DCM
+  success_criteria:
+  - The workload realizes on a compliant peer DCM
+  - The peer reports the resource's actual residency
+  - The reported residency is verified against the required residency
+  - The satisfied residency is recorded on the realized resource
+  - The verification is audited
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the peer reports the realized resource's residency
+  - domain: policy
+    interaction: the reported residency is verified against the requirement
+  - domain: data
+    interaction: the satisfied residency recorded on the resource
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- sovereignty
+- residency-verification
+- sovereign-profile
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Sovereign profile; the workload realizes on a compliant peer
+  postconditions:
+  - The peer-realized resource's residency is verified and recorded
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/015-sovereign-cross-dcm-rehydration-pending-review.yaml b/dav/use-cases/hammer-peer-dcm/015-sovereign-cross-dcm-rehydration-pending-review.yaml
new file mode 100644
index 0000000..b91a1fb
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/015-sovereign-cross-dcm-rehydration-pending-review.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-peer-dcm-015
+handle: peer-dcm/sovereign-cross-dcm-rehydration-pending-review
+scenario:
+  description: A sovereign workload's original provider is offline, so it is rebuilt from intent onto a peer DCM.
+    Rehydration re-evaluates tenancy and sovereignty under current policy (not the historical one), and a residency
+    rule introduced since original realization now conflicts — the entity lands in PENDING_REVIEW before it proceeds.
+  actor:
+    persona: sre
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - provider-owner
+    - federation-peer-operator
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Rehydrate onto a peer DCM under current sovereignty policy, landing in review
+  success_criteria:
+  - The original provider is offline; rehydration targets a peer DCM
+  - Tenancy and sovereignty are re-evaluated under current policy
+  - A residency rule introduced since original realization now conflicts
+  - The entity lands in PENDING_REVIEW rather than proceeding
+  - The current-policy re-evaluation and the pause are audited
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: policy_violation
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: current sovereignty/residency policy re-evaluated on rehydration
+  - domain: provider
+    interaction: the peer would host, pending the review
+  - domain: audit
+    interaction: the current-policy conflict and PENDING_REVIEW recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- sovereignty
+- rehydration
+- pending-review
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Sovereign profile; original provider offline; residency policy tightened since
+  postconditions:
+  - The rehydration is paused in PENDING_REVIEW under current policy
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/016-open-peer-capability-exchange.yaml b/dav/use-cases/hammer-peer-dcm/016-open-peer-capability-exchange.yaml
new file mode 100644
index 0000000..cacce8e
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/016-open-peer-capability-exchange.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-peer-dcm-016
+handle: peer-dcm/open-peer-capability-exchange
+scenario:
+  description: Two DCMs running an open, no-governance profile federate and exchange their advertised capability
+    sets without sovereignty, residency, or classification gates. Capability discovery flows freely, and either
+    can place on the other. This is the permissive baseline against which the gated sovereign cases are contrasted.
+  actor:
+    persona: application-team-member
+    profile: dev
+  perspectives:
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Freely exchange capabilities between two open-profile peer DCMs
+  success_criteria:
+  - Two open-profile DCMs federate without governance gates
+  - Advertised capability sets are exchanged freely
+  - No sovereignty/residency/classification gate applies
+  - Either peer may place a workload on the other
+  - The open exchange is still recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: peer_dcm_required
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peers advertise capabilities freely under the open profile
+  - domain: policy
+    interaction: no governance gate applies (system defaults only)
+  - domain: audit
+    interaction: the open exchange is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- open
+- no-governance
+- capability-exchange
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Two DCMs run an open, no-governance profile
+  postconditions:
+  - Capabilities are exchanged freely across the open federation
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/017-open-federated-placement-permissive.yaml b/dav/use-cases/hammer-peer-dcm/017-open-federated-placement-permissive.yaml
new file mode 100644
index 0000000..ae19cf9
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/017-open-federated-placement-permissive.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-peer-dcm-017
+handle: peer-dcm/open-federated-placement-permissive
+scenario:
+  description: Under an open profile, a workload is placed across a mixed landscape of local and peer providers
+    with no sovereignty, residency, or tenancy-isolation constraints — placement optimizes purely on requirements
+    and capacity. The permissive path for non-regulated / experimental estates.
+  actor:
+    persona: application-team-member
+    profile: dev
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Place across peers with no sovereignty or residency constraints
+  success_criteria:
+  - The open profile applies no sovereignty/residency constraints
+  - Placement optimizes on requirements and capacity across local+peers
+  - The best-fit candidate is selected without governance filtering
+  - The workload realizes on the chosen local or peer provider
+  - The placement is recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: system_defaults_only
+    provider_landscape: mixed
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: policy
+    interaction: no governance filtering; optimize on requirements/capacity
+  - domain: provider
+    interaction: the best-fit local or peer provider realizes the workload
+  - domain: audit
+    interaction: the permissive placement recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- open
+- no-governance
+- placement
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Open profile; local and peer providers eligible without constraints
+  postconditions:
+  - The workload runs on the capacity-optimal candidate
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/018-dev-peer-federation-smoke-test.yaml b/dav/use-cases/hammer-peer-dcm/018-dev-peer-federation-smoke-test.yaml
new file mode 100644
index 0000000..d083143
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/018-dev-peer-federation-smoke-test.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-peer-dcm-018
+handle: peer-dcm/dev-peer-federation-smoke-test
+scenario:
+  description: 'In a dev profile, an engineer federates with a local test peer DCM to smoke-test the cross-boundary
+    realization path end to end: dispatch, peer realize, handle return, and reference recording. Lightweight validation
+    with a single gating check, not production governance.'
+  actor:
+    persona: application-team-member
+    profile: dev
+  perspectives:
+    - federation-peer-operator
+  intent: Validate cross-DCM realization against a local test peer in the dev profile
+  success_criteria:
+  - A dev-profile DCM federates with a local test peer
+  - A cross-DCM realization is dispatched to the test peer
+  - The test peer realizes and returns a handle
+  - The local reference to the peer resource is recorded
+  - The end-to-end federation path is validated
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the local test peer realizes the resource
+  - domain: policy
+    interaction: a single gating check, not full production governance
+  - domain: data
+    interaction: the peer reference is recorded for validation
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- dev
+- smoke-test
+- connected
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Dev profile; a local test peer DCM is federated
+  postconditions:
+  - The cross-DCM realization path is validated end to end
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/019-dev-peer-disconnect-recovery-sandbox.yaml b/dav/use-cases/hammer-peer-dcm/019-dev-peer-disconnect-recovery-sandbox.yaml
new file mode 100644
index 0000000..134467a
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/019-dev-peer-disconnect-recovery-sandbox.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-peer-dcm-019
+handle: peer-dcm/dev-peer-disconnect-recovery-sandbox
+scenario:
+  description: A dev-profile scenario deliberately drops the peer connection mid-operation to exercise the disconnect-and-recover
+    path in a sandbox — confirming the local DCM holds the operation, preserves state, and retries on reconnect,
+    without production governance in the way.
+  actor:
+    persona: application-team-member
+    profile: dev
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+  intent: Exercise peer-disconnect recovery in a dev sandbox
+  success_criteria:
+  - A dev sandbox federates with a peer, then drops the connection
+  - The local DCM records the simulated peer disconnect
+  - The operation is held and local state preserved
+  - On reconnect, the operation retries and completes
+  - The recovery behavior is validated in the sandbox
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: no_governance
+    failure_mode: peer_dcm_disconnect
+  profile: dev
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the sandbox peer connection is dropped and restored
+  - domain: policy
+    interaction: recovery policy holds and retries; no production governance
+  - domain: audit
+    interaction: the simulated disconnect + recovery recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- dev
+- disconnected
+- recovery
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Dev profile; a sandbox peer connection can be dropped
+  postconditions:
+  - The disconnect-and-recover path is validated in the sandbox
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-peer-dcm/020-dev-cross-dcm-dependency-test.yaml b/dav/use-cases/hammer-peer-dcm/020-dev-cross-dcm-dependency-test.yaml
new file mode 100644
index 0000000..8d20368
--- /dev/null
+++ b/dav/use-cases/hammer-peer-dcm/020-dev-cross-dcm-dependency-test.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-peer-dcm-020
+handle: peer-dcm/dev-cross-dcm-dependency-test
+scenario:
+  description: A dev-profile scenario validates that a resource depending on a peer-owned resource resolves correctly
+    across the boundary — the peer's realized facts cross as a payload and the local criteria resolve — with a single
+    gating check appropriate to a development estate.
+  actor:
+    persona: application-team-member
+    profile: dev
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+  intent: Test cross-DCM dependency resolution in the dev profile
+  success_criteria:
+  - A dev resource depends on a peer-owned resource
+  - The peer's realized facts cross the boundary as a payload
+  - The local resource's criteria resolve from the peer payload
+  - The cross-DCM dependency resolves under a single gating check
+  - The resolution is recorded for validation
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: single_validation
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: data
+    interaction: peer realized facts cross the boundary as a payload
+  - domain: policy
+    interaction: a single gating check appropriate to a dev estate
+  - domain: provider
+    interaction: the peer owns the depended-on resource
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: peer-dcm-2026-07-23
+  timestamp: '2026-07-23T08:00:00.000000+00:00'
+tags:
+- peer-dcm
+- federation
+- dev
+- cross-dependency
+- connected
+- peer-dcm
+- hammer-2026-07-23
+version: 1.0.0
+metadata:
+  author: dav-peer-dcm
+  preconditions:
+  - Dev profile; a depended-on resource is owned by a peer
+  postconditions:
+  - The cross-DCM dependency resolves in the dev estate
+  note: batch=peer-dcm-2026-07-23
diff --git a/dav/use-cases/hammer-policy-override/001-precedence-chain-domain-order.yaml b/dav/use-cases/hammer-policy-override/001-precedence-chain-domain-order.yaml
new file mode 100644
index 0000000..6f331be
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/001-precedence-chain-domain-order.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-policy-override-001
+handle: policy-override/precedence-chain-domain-order
+scenario:
+  description: 'A platform-engineer submits an intent that is in scope for four policies whose verdicts
+    conflict: a platform policy permits a public-subnet placement, a tenant policy restricts it, a resource-type
+    policy permits it, and an entity-level tag policy denies it. The engine must resolve the conflict
+    deterministically by domain precedence (system > platform > tenant > resource_type > entity), not
+    by evaluation order or last-writer-wins. The winning verdict, the losing verdicts, and the precedence
+    rule that decided must all be recorded. The mechanism under test is conflict resolution as a declared
+    precedence lattice, not an ad-hoc tiebreak.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - provider-owner
+    - tenancy-authority
+  intent: Submit an intent matched by conflicting policies at different domain levels
+  success_criteria:
+  - All four in-scope policies are evaluated and their individual verdicts captured
+  - Conflict is detected and resolved by domain precedence, not evaluation order
+  - The higher-precedence tenant deny overrides the lower entity-level and resource_type verdicts
+  - The winning verdict names the precedence rule that decided it
+  - Losing verdicts are recorded as superseded, not silently dropped
+  - No provider dispatch occurs until the resolved verdict permits
+  - The full precedence resolution is reconstructable from the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: four conflicting in-scope policies evaluated and verdicts captured
+  - domain: policy
+    interaction: conflict resolved by declared domain-precedence lattice
+  - domain: data
+    interaction: resolved verdict plus superseded verdicts stored against the request
+  - domain: audit
+    interaction: precedence resolution recorded with the deciding rule
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- precedence
+- conflict-resolution
+- multi-policy-chain
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Four policies at distinct domain levels are in scope for the request
+  - Their verdicts conflict
+  postconditions:
+  - A single deterministic verdict is produced by domain precedence
+  - Superseded verdicts and the deciding rule are recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/002-hard-deny-unoverridable.yaml b/dav/use-cases/hammer-policy-override/002-hard-deny-unoverridable.yaml
new file mode 100644
index 0000000..1094b9f
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/002-hard-deny-unoverridable.yaml
@@ -0,0 +1,67 @@
+uuid: uc-hammer-policy-override-002
+handle: policy-override/hard-deny-unoverridable
+scenario:
+  description: 'A security-officer attempts to obtain an override of a hard-enforcement policy that denies
+    exporting regulated customer data outside the sovereign boundary. The override workflow must recognize
+    the target policy as hard-enforcement and reject the override request outright — before any approval
+    is solicited and regardless of the requester''s authority. A hard DENY is a property of the policy,
+    not a default that a sufficiently senior approver can lift. The attempt itself must be audited as
+    a rejected override, so that repeated pressure on an unoverridable control is visible. The mechanism
+    under test is the unoverridable classification of a policy.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Attempt to override a hard-enforcement deny on regulated data export
+  success_criteria:
+  - The target policy is identified as hard-enforcement (override-ineligible)
+  - The override request is rejected without soliciting any approval
+  - No approver, however senior, is offered the option to lift the deny
+  - The underlying request remains denied and no provider dispatch occurs
+  - The rejected override attempt is recorded distinctly from an unattempted request
+  - The audit record names the hard-enforcement classification as the reason
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: target policy classified as hard-enforcement, override declared ineligible
+  - domain: policy
+    interaction: override request rejected before any approval routing
+  - domain: data
+    interaction: rejected override attempt recorded against the request
+  - domain: audit
+    interaction: unoverridable-deny rejection logged with classification reason
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- hard-deny
+- unoverridable
+- compliance
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A hard-enforcement deny policy is in scope for the request
+  postconditions:
+  - Override is rejected as ineligible; the deny stands
+  - The rejected attempt is auditable
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/003-governance-matrix-cross-boundary.yaml b/dav/use-cases/hammer-policy-override/003-governance-matrix-cross-boundary.yaml
new file mode 100644
index 0000000..5b07e3d
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/003-governance-matrix-cross-boundary.yaml
@@ -0,0 +1,69 @@
+uuid: uc-hammer-policy-override-003
+handle: policy-override/governance-matrix-cross-boundary
+scenario:
+  description: 'A platform-engineer declares a dependency that crosses a governance boundary: a workload
+    in a sovereign estate must attach to a shared logging service realized in a peer DCM in a different
+    jurisdiction. No single-resource policy denies either resource on its own — the constraint lives in
+    the governance matrix, which governs the interaction between the two governance classes. The engine
+    must consult the matrix for the (sovereign-workload x foreign-shared-service) cell and deny the cross-boundary
+    attachment even though both endpoints are individually permitted. The mechanism under test is the
+    governance matrix firing on an interaction, not on either resource in isolation.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Attach a sovereign workload to a shared service governed in a foreign estate
+  success_criteria:
+  - Both endpoint resources individually pass their own in-scope policies
+  - The cross-boundary interaction is identified from the dependency payload
+  - The governance matrix cell for the two governance classes is consulted
+  - The interaction is denied even though neither endpoint is denied alone
+  - The denial names the matrix cell and the two governance classes involved
+  - No attachment is realized and no peer dispatch crosses the boundary
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: governance matrix consulted for the cross-class interaction cell
+  - domain: data
+    interaction: cross-boundary dependency payload inspected for governance classes
+  - domain: provider
+    interaction: peer dispatch withheld because the interaction is denied
+  - domain: audit
+    interaction: matrix-cell denial recorded naming both governance classes
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- governance-matrix
+- cross-boundary
+- sovereignty
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A dependency crosses two governance classes in different jurisdictions
+  - Each endpoint individually passes its own policies
+  postconditions:
+  - The interaction is denied by the governance matrix
+  - No cross-boundary attachment is realized
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/004-policy-blocked-resolution-options.yaml b/dav/use-cases/hammer-policy-override/004-policy-blocked-resolution-options.yaml
new file mode 100644
index 0000000..490191a
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/004-policy-blocked-resolution-options.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-policy-override-004
+handle: policy-override/policy-blocked-resolution-options
+scenario:
+  description: 'An application-team-member submits a request that a soft-enforcement policy blocks (an
+    oversized ephemeral volume on a cost-capped profile). Rather than a bare denial, the engine must return
+    a POLICY_BLOCKED verdict that carries the actionable resolution options the actor may take: modify
+    the request to conform, request an override, cancel, or escalate. Each option must state what it would
+    require (e.g. override needs an authorized approver; modify needs the volume under the cap). The actor
+    picks modify and resubmits a conforming request that passes. The mechanism under test is a blocked
+    verdict that is a decision surface with typed next steps, not a dead end.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - sre
+  intent: Resolve a soft-policy block by choosing among offered resolution options
+  success_criteria:
+  - The blocking policy produces a POLICY_BLOCKED verdict, not a bare error
+  - The verdict enumerates modify, override, cancel, and escalate as options
+  - Each option states its precondition (e.g. override requires an authorized approver)
+  - Options that are unavailable to this actor are marked unavailable, not hidden
+  - The actor selects modify and resubmits a conforming request that passes
+  - The original block, the chosen option, and the resolving request are audit-linked
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: human_escalation_required
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: soft policy emits POLICY_BLOCKED with typed resolution options
+  - domain: policy
+    interaction: option preconditions evaluated for this actor and profile
+  - domain: data
+    interaction: block, chosen option, and resolving request linked as a chain
+  - domain: audit
+    interaction: resolution path recorded from block through conforming resubmission
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- policy-blocked
+- resolution-options
+- self-service
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A soft-enforcement policy blocks the initial request
+  postconditions:
+  - The actor resolves via modify and a conforming request passes
+  - The full resolution chain is auditable
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/005-override-dual-approval.yaml b/dav/use-cases/hammer-policy-override/005-override-dual-approval.yaml
new file mode 100644
index 0000000..980ab29
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/005-override-dual-approval.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-policy-override-005
+handle: policy-override/override-dual-approval
+scenario:
+  description: 'A platform-engineer requests a time-bounded override of a soft-enforcement policy that
+    restricts placing a regulated workload on a shared-tenancy provider. Because the policy is classified
+    high-risk, its override eligibility declares dual-approval: two distinct authorized approvers from
+    separate roles (e.g. a security-officer and a compliance-owner) must both grant before the override
+    takes effect. A single approval must leave the override pending, not active. The mechanism under test
+    is an override eligibility rule that requires an approval quorum, and the correct sequencing of a
+    pending-to-active transition only on the second grant.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - security-officer
+    - tenancy-authority
+  intent: Obtain a dual-approved override of a high-risk soft policy
+  success_criteria:
+  - The policy's override eligibility declares a two-approver quorum across distinct roles
+  - The first approval leaves the override in a pending state, not active
+  - The second approval by a distinct authorized role activates the override
+  - The two approvers must be different principals in different roles
+  - The override is scoped in time and narrowed to the specific matched request
+  - Both approval events and the activation are recorded and audit-linked
+  - Policy evaluations honor the override only after both approvals land
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: override eligibility requires a two-role approval quorum
+  - domain: policy
+    interaction: pending-to-active transition gated on the second distinct approval
+  - domain: data
+    interaction: override record stores both approvers, scope, and duration
+  - domain: audit
+    interaction: both approvals and activation linked for review
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- dual-approval
+- quorum
+- human-in-loop
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A high-risk soft policy declares dual-approval override eligibility
+  postconditions:
+  - Override activates only after two distinct-role approvals
+  - Scope, duration, and both approvers are recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/006-decidable-not-routed-to-review.yaml b/dav/use-cases/hammer-policy-override/006-decidable-not-routed-to-review.yaml
new file mode 100644
index 0000000..8cf45d2
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/006-decidable-not-routed-to-review.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-policy-override-006
+handle: policy-override/decidable-not-routed-to-review
+scenario:
+  description: 'A platform-engineer submits a request that is fully decidable by the policy set: every
+    in-scope policy has the data it needs and returns a definite verdict. Per DPO-007 — human-in-the-loop
+    is a necessary anti-pattern to be minimized wherever a policy could decide — the engine must render
+    the automated decision and must NOT route the request to human review. Route-to-review is reserved
+    for the genuinely undecidable. This UC probes whether the architecture treats review as a last resort
+    or leaks it into the common path: a request that a policy can decide should never land in a human
+    queue. A finding of routed-to-review here is a defect, not a feature.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - security-officer
+  intent: Submit a fully policy-decidable request and confirm no human review is invoked
+  success_criteria:
+  - Every in-scope policy returns a definite pass or fail with no missing inputs
+  - The engine renders the automated verdict without routing to human review
+  - No review task is created and no human queue is touched
+  - The decision path records that the request was policy-decidable
+  - Route-to-review remains available but unused for this decidable case
+  - The audit trail shows an automated decision, not an escalation
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: all in-scope policies return definite verdicts with complete inputs
+  - domain: policy
+    interaction: engine decides automatically, suppressing route-to-review
+  - domain: audit
+    interaction: decision recorded as policy-decidable, no review task created
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- dpo-007
+- no-human-in-loop
+- decidable
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
+  preconditions:
+  - The full policy set can decide the request without missing inputs
+  postconditions:
+  - The request is decided automatically with no human review
diff --git a/dav/use-cases/hammer-policy-override/007-shadow-mode-evaluation.yaml b/dav/use-cases/hammer-policy-override/007-shadow-mode-evaluation.yaml
new file mode 100644
index 0000000..c69392c
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/007-shadow-mode-evaluation.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-policy-override-007
+handle: policy-override/shadow-mode-evaluation
+scenario:
+  description: 'A security-officer stages a new placement policy in shadow mode before enforcing it. For
+    every matched request the engine must evaluate the shadow policy alongside the active policy set,
+    record what verdict it WOULD have produced, and surface the would-block rate — all without affecting
+    the live decision or blocking any request. This lets the team measure blast radius before activation.
+    The mechanism under test is a policy lifecycle state (shadow) whose verdicts are observed and recorded
+    but never enforced, cleanly separated from the enforced verdict on the same request.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Evaluate a candidate policy in shadow mode without affecting live decisions
+  success_criteria:
+  - The shadow policy is evaluated on every matched request
+  - The shadow verdict is recorded as would-have without changing the live outcome
+  - No request is blocked or altered by the shadow policy
+  - The would-block rate is derivable from the recorded shadow verdicts
+  - Shadow verdicts are stored distinctly from enforced verdicts on the same request
+  - The policy's shadow lifecycle state is explicit and separate from active
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: shadow policy evaluated alongside active set, verdict not enforced
+  - domain: data
+    interaction: would-have verdicts stored separately from enforced verdicts
+  - domain: audit
+    interaction: shadow evaluation recorded to support blast-radius analysis
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- shadow-mode
+- pre-activation
+- blast-radius
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A candidate policy is staged in shadow (non-enforcing) mode
+  postconditions:
+  - Shadow verdicts recorded; live decisions unaffected
+  - Would-block rate is measurable before activation
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/008-compliance-revalidate-assembled-payload.yaml b/dav/use-cases/hammer-policy-override/008-compliance-revalidate-assembled-payload.yaml
new file mode 100644
index 0000000..6a746ba
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/008-compliance-revalidate-assembled-payload.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-policy-override-008
+handle: policy-override/compliance-revalidate-assembled-payload
+scenario:
+  description: 'A compliance-auditor''s profile requires that a compliance-class policy validate not the
+    raw intent but the fully assembled provider payload — after defaults are applied, dependencies are
+    resolved, and placement fills in the concrete provider, region, and image. A request that passed intent-time
+    validation could still violate compliance once the placement engine picks a non-conforming region
+    or a defaulted-in public endpoint. The engine must re-run the compliance-class validation against
+    the assembled payload immediately before dispatch and deny if the resolved concrete values violate
+    it. The mechanism under test is a late, payload-level re-validation gate distinct from intent-time
+    checks.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - provider-owner
+  intent: Re-validate the assembled provider payload against compliance before dispatch
+  success_criteria:
+  - Intent-time validation passes on the raw request
+  - Placement resolves concrete provider, region, and image into the payload
+  - The compliance-class policy re-validates the assembled payload, not the intent
+  - A non-conforming resolved value (e.g. region) is caught at the payload gate
+  - Dispatch is denied when the assembled payload violates compliance
+  - Both the intent-time pass and the payload-time denial are recorded distinctly
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: provider
+    interaction: placement assembles concrete payload with resolved region and image
+  - domain: policy
+    interaction: compliance-class validation re-runs against the assembled payload
+  - domain: data
+    interaction: intent-time pass and payload-time denial stored as separate gates
+  - domain: audit
+    interaction: late payload denial recorded with the offending resolved value
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- compliance
+- payload-revalidation
+- pre-dispatch-gate
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A compliance-class policy validates the assembled payload, not just intent
+  - Placement can resolve a value that violates compliance
+  postconditions:
+  - Non-conforming assembled payload is denied before dispatch
+  - Both validation gates are auditable
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/009-three-state-out-of-scope-not-passed.yaml b/dav/use-cases/hammer-policy-override/009-three-state-out-of-scope-not-passed.yaml
new file mode 100644
index 0000000..99f5d6f
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/009-three-state-out-of-scope-not-passed.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-policy-override-009
+handle: policy-override/three-state-out-of-scope-not-passed
+scenario:
+  description: 'A compliance-auditor submits a request on a minimal profile that resolves to a small policy
+    set. Several org-wide policies (e.g. a data-residency policy) are NOT in scope for this profile. The
+    engine must report a three-state outcome per policy: evaluated_pass, evaluated_fail, or out_of_scope
+    — and critically, out_of_scope must be reported honestly as ungoverned, never collapsed into a silent
+    pass. An ungoverned dimension is not a satisfied one. The mechanism under test is the integrity of
+    the three-state audit outcome, so that "this profile does not govern residency" is never mistaken
+    for "residency was checked and passed."
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: homelab
+  perspectives:
+    - application-team-member
+    - sre
+    - sovereignty-authority
+  intent: Verify out-of-scope policies are reported as ungoverned, not passed
+  success_criteria:
+  - The resolved profile's policy set is selected by construction
+  - In-scope policies report evaluated_pass or evaluated_fail
+  - Out-of-scope policies report out_of_scope, distinct from evaluated_pass
+  - No out-of-scope policy is recorded as skipped-and-passed
+  - The audit outcome lets a reader tell ungoverned from checked-and-passed
+  - No global fall-through evaluates policies outside the resolved profile
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: homelab
+  expected_domain_interactions:
+  - domain: policy
+    interaction: profile-resolved policy set evaluated, others marked out_of_scope
+  - domain: data
+    interaction: three-state outcomes stored per policy against the request
+  - domain: audit
+    interaction: out-of-scope reported honestly, never as a silent pass
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- three-state
+- out-of-scope
+- ungoverned
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - The minimal profile leaves several org-wide policies out of scope
+  postconditions:
+  - Out-of-scope policies are reported as ungoverned, not passed
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/010-override-injected-as-constraint-on-resume.yaml b/dav/use-cases/hammer-policy-override/010-override-injected-as-constraint-on-resume.yaml
new file mode 100644
index 0000000..e5f683f
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/010-override-injected-as-constraint-on-resume.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-policy-override-010
+handle: policy-override/override-injected-as-constraint-on-resume
+scenario:
+  description: 'A platform-engineer''s provisioning flow is suspended at a soft-policy block that restricts
+    a workload to on-demand instances. An authorized override is granted to permit spot instances for
+    this one request. On resume, the override must be applied not as a blanket bypass that silences the
+    policy, but as a scoped constraint modification injected into the request context: the spot-permitted
+    constraint is added, the flow re-enters evaluation, and the same policy now passes because the modified
+    constraint conforms. The mechanism under test is resume-with-override modeled as a constraint edit
+    that re-flows through evaluation, preserving the audit of a real pass rather than a suppressed check.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Resume a blocked flow with an override injected as a scoped constraint change
+  success_criteria:
+  - The flow is suspended at the soft-policy block with resumable state
+  - The granted override is applied as a scoped constraint modification, not a bypass
+  - On resume the request re-enters policy evaluation with the modified constraint
+  - The previously-blocking policy now passes against the modified constraint
+  - The override is narrowed to this request and does not silence the policy globally
+  - The resume, the injected constraint, and the resulting pass are audit-linked
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: override applied as a scoped constraint edit, flow re-evaluated
+  - domain: data
+    interaction: modified constraint stored in the resumed request context
+  - domain: provider
+    interaction: dispatch proceeds on the now-conforming constraint
+  - domain: audit
+    interaction: resume, injected constraint, and resulting pass linked
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- constraint-modification
+- resume
+- recovery-policy
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A flow is suspended at a soft-policy block with resumable state
+  - An authorized override has been granted for this request
+  postconditions:
+  - Override applied as a scoped constraint; policy passes on re-evaluation
+  - Global policy behavior is unchanged
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/011-policy-language-agnostic-contract.yaml b/dav/use-cases/hammer-policy-override/011-policy-language-agnostic-contract.yaml
new file mode 100644
index 0000000..8c3a9ef
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/011-policy-language-agnostic-contract.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-policy-override-011
+handle: policy-override/policy-language-agnostic-contract
+scenario:
+  description: 'A platform-engineer registers two policies that express the same rule in different policy
+    languages — one in a Rego-style engine, one in a declarative constraint DSL. DCM''s contract with
+    a policy is the verdict interface (in-scope determination, three-state outcome, enforcement class,
+    override eligibility), not the language the policy is authored in. Given identical requests, both
+    policies must produce identical contract-level verdicts, and the engine must treat them interchangeably.
+    The mechanism under test is policy-language agnosticism: DCM depends on the policy contract, not on
+    any specific evaluation engine. This probes whether the architecture has leaked an engine assumption
+    into the contract.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - security-officer
+  intent: Confirm two engines expressing one rule yield identical contract verdicts
+  success_criteria:
+  - Both policies are registered against the same verdict contract
+  - The engine does not require a single specific policy language
+  - Identical requests produce identical three-state outcomes from both policies
+  - Enforcement class and override eligibility are read from the contract, not the engine
+  - Swapping the backing engine does not change the request's verdict
+  - No evaluation-engine detail leaks into the request or audit record
+  dimensions:
+    lifecycle_phase: new_request
+    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: policy
+    interaction: two engines evaluated against one verdict contract, results compared
+  - domain: data
+    interaction: verdict stored by contract fields, engine-agnostic
+  - domain: audit
+    interaction: outcome recorded without leaking engine-specific detail
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- language-agnostic
+- policy-contract
+- portability
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - The same rule is authored in two different policy languages
+  postconditions:
+  - Both yield identical contract-level verdicts and are interchangeable
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/012-baseline-single-validation-pass.yaml b/dav/use-cases/hammer-policy-override/012-baseline-single-validation-pass.yaml
new file mode 100644
index 0000000..3743fe4
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/012-baseline-single-validation-pass.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-policy-override-012
+handle: policy-override/baseline-single-validation-pass
+scenario:
+  description: 'An application-team-member on a dev profile submits a conforming request for a small single
+    resource with no dependencies. Exactly one validation policy is in scope, and the request satisfies
+    it. The engine must evaluate the single policy, return evaluated_pass, and proceed to dispatch — the
+    baseline governed happy path. This is the simple control case that anchors the harder policy-override
+    scenarios: a clean single-validation pass with a truthful audit record and no override, escalation,
+    or conflict machinery invoked.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: dev
+  perspectives:
+    - compliance-auditor
+  intent: Submit a conforming request satisfying a single in-scope validation policy
+  success_criteria:
+  - Exactly one validation policy is resolved as in scope for the dev profile
+  - The request satisfies the policy and returns evaluated_pass
+  - No override, escalation, or conflict-resolution path is invoked
+  - Dispatch proceeds after the single pass
+  - The pass is recorded as evaluated_pass, not out_of_scope
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: policy
+    interaction: single in-scope validation policy evaluated to pass
+  - domain: provider
+    interaction: dispatch proceeds after the pass
+  - domain: audit
+    interaction: evaluated_pass recorded for the single policy
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- baseline
+- single-validation
+- happy-path
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - One validation policy is in scope and the request conforms
+  postconditions:
+  - The request passes and dispatches with a truthful audit record
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/013-soft-enforcement-warns-allows.yaml b/dav/use-cases/hammer-policy-override/013-soft-enforcement-warns-allows.yaml
new file mode 100644
index 0000000..b2c0ee4
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/013-soft-enforcement-warns-allows.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-policy-override-013
+handle: policy-override/soft-enforcement-warns-allows
+scenario:
+  description: 'An application-team-member submits a request that trips a soft-enforcement advisory policy
+    — for example, a naming-convention or tagging-hygiene policy. Because the policy is advisory (soft,
+    non-blocking), the engine must record a warning against the request, allow it to proceed to dispatch,
+    and surface the advisory to the actor without demanding an override. A soft warn is not a block and
+    must not require the override workflow. The mechanism under test is the enforcement-class distinction:
+    advisory policies annotate but do not gate.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - sre
+  intent: Submit a request that trips an advisory policy and still proceeds
+  success_criteria:
+  - The advisory policy is evaluated and flags the request
+  - A warning is recorded but the request is not blocked
+  - No override workflow is triggered for the advisory finding
+  - Dispatch proceeds with the warning attached to the request
+  - The warning is visible to the actor and preserved in the audit trail
+  - The enforcement class (advisory) is explicit in the recorded outcome
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: advisory policy flags the request without blocking
+  - domain: data
+    interaction: warning attached to the request record
+  - domain: audit
+    interaction: advisory warning preserved alongside the pass-through outcome
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- soft-enforcement
+- advisory
+- warn-and-allow
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - An advisory soft policy matches the request
+  postconditions:
+  - The request proceeds with a recorded warning and no override
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/014-tenant-cannot-loosen-system-deny.yaml b/dav/use-cases/hammer-policy-override/014-tenant-cannot-loosen-system-deny.yaml
new file mode 100644
index 0000000..af4a8ce
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/014-tenant-cannot-loosen-system-deny.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-policy-override-014
+handle: policy-override/tenant-cannot-loosen-system-deny
+scenario:
+  description: 'A tenant-admin authors a tenant-scoped policy that permits unencrypted inter-service traffic,
+    hoping it relaxes a system-scoped policy that denies it. Both policies are in scope for the same request
+    and their verdicts conflict. Domain precedence (system > platform > tenant > resource_type > entity)
+    must resolve this so the system deny wins — a lower-domain permit cannot loosen a higher-domain deny.
+    The tenant permit is recorded as superseded, and the request is denied. The mechanism under test is
+    that precedence is a security boundary: authority flows down, not up, and a tenant cannot self-grant
+    past a system control.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - security-officer
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Attempt to relax a system deny with a tenant-scoped permit
+  success_criteria:
+  - Both the system deny and the tenant permit are in scope and evaluated
+  - The conflict is resolved by domain precedence, not by tenant intent
+  - The system-scoped deny wins over the lower tenant-scoped permit
+  - The tenant permit is recorded as superseded, not applied
+  - The request is denied and no dispatch occurs
+  - The audit record shows the tenant could not loosen the system control
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: system deny and tenant permit conflict resolved by precedence
+  - domain: data
+    interaction: tenant permit stored as superseded against the request
+  - domain: audit
+    interaction: denial recorded showing lower domain cannot override higher
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- precedence
+- privilege-boundary
+- system-deny
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A tenant permit and a system deny are both in scope and conflict
+  postconditions:
+  - The system deny wins; the tenant permit is superseded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/015-override-expiry-mid-flight.yaml b/dav/use-cases/hammer-policy-override/015-override-expiry-mid-flight.yaml
new file mode 100644
index 0000000..54e9708
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/015-override-expiry-mid-flight.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-policy-override-015
+handle: policy-override/override-expiry-mid-flight
+scenario:
+  description: 'An SRE holds a time-bounded override that permits a maintenance action across a multi-resource
+    stack. The override''s window expires while the orchestrated flow is still mid-execution — some resources
+    reconfigured under the override, others still pending. The engine must define a deterministic behavior
+    for a mid-flight expiry: does it complete the in-flight unit, halt and leave the stack half-applied,
+    or re-evaluate the remaining steps against the now-expired override (which should deny them)? This
+    probes whether override validity is checked once at admission or continuously along the flow. A silent
+    completion of steps after expiry, or an inconsistent half-state with no defined recovery, is a finding
+    — likely unsupported.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+  intent: Continue a multi-step flow whose override expires mid-execution
+  success_criteria:
+  - Override validity is bound to a time window with a defined mid-flight semantics
+  - Steps completed before expiry are recorded as override-authorized
+  - Steps reached after expiry are re-evaluated and denied without the override
+  - No step is silently authorized by an expired override
+  - Any resulting partial state is detected and flagged for recovery, not left silent
+  - The expiry boundary within the flow is reconstructable from the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: human_escalation_required
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: override validity re-checked along the flow, not only at admission
+  - domain: provider
+    interaction: post-expiry steps withheld; pre-expiry steps already applied
+  - domain: data
+    interaction: partial state detected and flagged as inconsistent
+  - domain: audit
+    interaction: the expiry boundary within the flow is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- override-expiry
+- mid-flight
+- consistency
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
+  preconditions:
+  - A time-bounded override covers a multi-step flow
+  - The window expires before the flow completes
+  postconditions:
+  - Post-expiry steps are denied; any partial state is flagged for recovery
diff --git a/dav/use-cases/hammer-policy-override/016-override-scope-no-sibling-widening.yaml b/dav/use-cases/hammer-policy-override/016-override-scope-no-sibling-widening.yaml
new file mode 100644
index 0000000..71e1924
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/016-override-scope-no-sibling-widening.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-policy-override-016
+handle: policy-override/override-scope-no-sibling-widening
+scenario:
+  description: 'A security-officer grants an override narrowed to one specific request in a batch of near-identical
+    sibling requests (same policy, same profile, same resource type). The engine must apply the override
+    ONLY to the matched request and must re-block the siblings, which continue to fail the same policy.
+    An override scoped to a request must not widen by matching-shape to its siblings. This probes override
+    scoping precision: a common defect is keying the override to a policy-plus-shape signature that accidentally
+    covers every look-alike request. The mechanism under test is that override scope is bound to the specific
+    matched request, not to a reusable pattern.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Confirm a request-scoped override does not leak to sibling requests
+  success_criteria:
+  - The override is scoped to exactly one matched request
+  - Sibling requests with the same shape still fail the same policy
+  - The override is not keyed to a reusable policy-plus-shape signature
+  - Only the matched request proceeds; siblings remain blocked
+  - Each sibling block and the single override are recorded distinctly
+  - The audit trail shows the override did not widen to look-alikes
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: human_escalation_required
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: override applied only to the matched request, siblings re-blocked
+  - domain: data
+    interaction: override scope bound to a specific request identity, not a pattern
+  - domain: audit
+    interaction: sibling blocks and the single override recorded separately
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- scope-precision
+- no-widening
+- least-privilege
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Several near-identical sibling requests match the same blocking policy
+  - An override is granted for exactly one of them
+  postconditions:
+  - Only the matched request proceeds; siblings stay blocked
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/017-separation-of-duties-approver-is-requester.yaml b/dav/use-cases/hammer-policy-override/017-separation-of-duties-approver-is-requester.yaml
new file mode 100644
index 0000000..c6b79b6
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/017-separation-of-duties-approver-is-requester.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-policy-override-017
+handle: policy-override/separation-of-duties-approver-is-requester
+scenario:
+  description: 'A platform-engineer who is also assigned an approver role requests an override and then
+    attempts to approve their own request. The override eligibility declares separation-of-duties: the
+    approving principal must differ from the requesting principal. The engine must reject the self-approval
+    even though the actor formally holds the approver role, leaving the override pending an independent
+    approver. This probes whether the architecture models approver identity distinct from approver role
+    — a system that only checks role membership will wrongly let a role-holding requester self-approve.
+    A self-approval that succeeds here is a finding; the correct outcome is rejection on separation-of-duties.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Attempt to self-approve an override the same principal requested
+  success_criteria:
+  - The override eligibility declares a separation-of-duties constraint
+  - The approving principal identity is checked, not merely the approver role
+  - The self-approval is rejected because requester and approver are the same principal
+  - The override remains pending an independent authorized approver
+  - No policy suppression takes effect from the rejected self-approval
+  - The rejected self-approval attempt is recorded for review
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: separation-of-duties checks approver identity against requester
+  - domain: policy
+    interaction: self-approval rejected, override left pending
+  - domain: data
+    interaction: rejected self-approval recorded against the override request
+  - domain: audit
+    interaction: separation-of-duties rejection logged for review
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- separation-of-duties
+- self-approval
+- identity-vs-role
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
+  preconditions:
+  - The requester also holds the approver role
+  - Override eligibility requires separation of duties
+  postconditions:
+  - Self-approval is rejected; override stays pending an independent approver
diff --git a/dav/use-cases/hammer-policy-override/018-shadow-divergence-gates-activation.yaml b/dav/use-cases/hammer-policy-override/018-shadow-divergence-gates-activation.yaml
new file mode 100644
index 0000000..94782de
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/018-shadow-divergence-gates-activation.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-policy-override-018
+handle: policy-override/shadow-divergence-gates-activation
+scenario:
+  description: 'A security-officer moves a shadow-mode policy toward activation. During its shadow run
+    the policy would have blocked a material fraction of recent requests that the active set allowed —
+    a divergence between shadow and enforced verdicts. The engine must surface this divergence and gate
+    activation behind an explicit acknowledgement of the would-block blast radius, rather than flipping
+    the policy to enforcing silently. This connects shadow evaluation to a safe-activation control: activation
+    is a governed transition informed by measured divergence, not a bare toggle. The mechanism under test
+    is divergence-gated activation of a policy lifecycle state.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Activate a shadow policy only after acknowledging its measured divergence
+  success_criteria:
+  - Shadow verdicts are compared against enforced verdicts over recent requests
+  - The divergence (would-block-but-was-allowed rate) is computed and surfaced
+  - Activation is gated behind an explicit acknowledgement of the blast radius
+  - The policy is not flipped to enforcing silently on a bare toggle
+  - The acknowledged divergence figure is recorded with the activation event
+  - Post-activation, the policy enforces and its verdicts are no longer shadow-only
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: shadow-vs-enforced divergence computed to inform activation
+  - domain: data
+    interaction: divergence figure and acknowledgement stored with the activation
+  - domain: audit
+    interaction: governed activation recorded with the acknowledged blast radius
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- shadow-mode
+- activation-gate
+- divergence
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A shadow policy has accumulated verdicts diverging from the enforced set
+  postconditions:
+  - Activation proceeds only after divergence is acknowledged and recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/019-cross-tenant-matrix-denied.yaml b/dav/use-cases/hammer-policy-override/019-cross-tenant-matrix-denied.yaml
new file mode 100644
index 0000000..3f434a1
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/019-cross-tenant-matrix-denied.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-policy-override-019
+handle: policy-override/cross-tenant-matrix-denied
+scenario:
+  description: 'A tenant-admin in tenant A declares a dependency on a resource owned by tenant B — for
+    instance mounting tenant B''s shared dataset into a tenant A workload. Neither resource is denied
+    on its own, but the governance matrix governs the cross-tenant interaction and denies it absent an
+    explicit sharing grant. The engine must recognize the two resources belong to different tenants, consult
+    the cross-tenant cell of the governance matrix, and deny the dependency. The mechanism under test
+    is the governance matrix enforcing tenant isolation at the interaction level, catching a cross-tenant
+    leak that per-resource policies would miss.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - security-officer
+    - tenancy-authority
+  intent: Declare a dependency on another tenant's resource without a sharing grant
+  success_criteria:
+  - The two resources are identified as belonging to different tenants
+  - Each resource individually passes its own in-scope policies
+  - The governance matrix cross-tenant cell is consulted for the interaction
+  - The dependency is denied absent an explicit cross-tenant sharing grant
+  - No cross-tenant attachment is realized
+  - The denial names the two tenants and the missing sharing grant
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency resolved across two distinct tenant owners
+  - domain: policy
+    interaction: governance matrix denies the cross-tenant interaction
+  - domain: audit
+    interaction: cross-tenant denial recorded with both tenants and missing grant
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- governance-matrix
+- cross-tenant
+- isolation
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A dependency crosses two tenant ownership boundaries
+  - No cross-tenant sharing grant exists
+  postconditions:
+  - The cross-tenant dependency is denied by the governance matrix
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-policy-override/020-escalation-only-when-undecidable.yaml b/dav/use-cases/hammer-policy-override/020-escalation-only-when-undecidable.yaml
new file mode 100644
index 0000000..7072d83
--- /dev/null
+++ b/dav/use-cases/hammer-policy-override/020-escalation-only-when-undecidable.yaml
@@ -0,0 +1,69 @@
+uuid: uc-hammer-policy-override-020
+handle: policy-override/escalation-only-when-undecidable
+scenario:
+  description: 'A platform-engineer on a sovereign mandate submits a request whose governing policy genuinely
+    cannot decide: it depends on an external sovereignty attestation that a peer DCM has not yet returned,
+    so the input is legitimately absent — not defaulted, not inferable. Per DPO-007, human-in-the-loop
+    is a necessary anti-pattern reserved for exactly this residue: the engine must route to review ONLY
+    because the case is undecidable by policy, and must record WHY (the missing attestation) so the escalation
+    is justified, not habitual. When the attestation later arrives the request must become policy-decidable
+    and leave the human queue. The mechanism under test is escalation as a justified last resort, gated
+    on genuine undecidability.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Route a genuinely undecidable request to review with a recorded justification
+  success_criteria:
+  - The governing policy cannot decide because a required attestation is absent
+  - The absence is genuine (not a defaultable or inferable input)
+  - The request routes to human review as a last resort, not by default
+  - The escalation record names the specific missing input as the reason
+  - Decidable policies in the same request are still decided automatically
+  - When the attestation arrives the request becomes decidable and leaves the queue
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: human_escalation_required
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: peer_dcm_disconnect
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: policy reports undecidable due to a genuinely missing attestation
+  - domain: provider
+    interaction: peer DCM attestation is pending, input legitimately absent
+  - domain: policy
+    interaction: only the undecidable residue routes to review, rest decided
+  - domain: audit
+    interaction: escalation recorded with the specific missing input as justification
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- policy-override
+- dpo-007
+- escalation-last-resort
+- undecidable
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
+  preconditions:
+  - A required external attestation is genuinely absent
+  postconditions:
+  - Only the undecidable residue is escalated, with a recorded reason
+  - Arrival of the attestation makes the request decidable again
diff --git a/dav/use-cases/hammer-process-migration/001-engine-migration-canary-cutover.yaml b/dav/use-cases/hammer-process-migration/001-engine-migration-canary-cutover.yaml
new file mode 100644
index 0000000..2188d52
--- /dev/null
+++ b/dav/use-cases/hammer-process-migration/001-engine-migration-canary-cutover.yaml
@@ -0,0 +1,52 @@
+uuid: uc-process-migration-001
+handle: process-migration/engine-migration-canary-cutover
+version: 1.0.0
+scenario:
+  description: "An organization runs OS patching on one automation engine and migrates to another. Both\
+    \ engines have declared the same process type as a shared capability, so the migration is a provider\
+    \ change on an untouched definition: a placement policy routes a canary slice to the new engine, results\
+    \ compare by typed outputs, and cutover is a preference flip. The org's automation intent \u2014 targets,\
+    \ patch policy, reboot policy, windows \u2014 never changes, and the scheduled process keeps its identity\
+    \ and audit history across the engine change."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+    - compliance-auditor
+  intent: Migrate a declared process type from one engine to another via canary routing and placement
+    cutover, with automation intent and audit continuity untouched
+  success_criteria:
+  - Both engines declare support for the same process type before migration begins
+  - A placement/validation policy routes a defined canary slice to the new engine
+  - The org-authored process intent is byte-identical before and after cutover
+  - The scheduled process entity keeps its UUID; runs before and after instantiate the same type
+  - The old engine's capability is de-admitted at completion without touching the type
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the process type is the stable record; only provider selection changes
+  - domain: policy
+    interaction: canary routing and cutover are placement-policy operations
+  - domain: provider
+    interaction: two engines realize the same declared capability in sequence
+  - domain: audit
+    interaction: one unbroken practice with an engine change, not two automations
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: process-migration-2026-07-25
+  timestamp: '2026-07-25T02:00:00.000000+00:00'
+tags:
+- process-migration
+- engine-migration
+- canary
+- automation-intent
diff --git a/dav/use-cases/hammer-process-migration/002-blue-green-engine-verification.yaml b/dav/use-cases/hammer-process-migration/002-blue-green-engine-verification.yaml
new file mode 100644
index 0000000..8ed8523
--- /dev/null
+++ b/dav/use-cases/hammer-process-migration/002-blue-green-engine-verification.yaml
@@ -0,0 +1,52 @@
+uuid: uc-process-migration-002
+handle: process-migration/blue-green-engine-verification
+version: 1.0.0
+scenario:
+  description: "Before cutting automation over to a new engine, the org verifies behavioral equivalence\
+    \ with data instead of faith. The process type is declared idempotent and both engines publish identical\
+    \ typed outputs \u2014 so a green run against targets the blue engine just converged should produce\
+    \ an empty change-set. Any non-empty delta is a behavioral difference between engines, surfaced as\
+    \ a queryable result before any production cutover. The comparison is a diff of declared outputs,\
+    \ not a hand-built test harness."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Verify a new engine against the incumbent by running the same idempotent process type and diffing
+    typed outputs, requiring an empty delta before cutover
+  success_criteria:
+  - The green engine runs the same process type against blue-converged targets
+  - A conformant green run yields an empty change-set output; the comparison is mechanical
+  - Any non-empty delta blocks cutover and is attributable to specific behavioral differences
+  - "No bespoke comparison tooling exists \u2014 the typed output surface IS the harness"
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: multiple_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: identical typed outputs make engines comparable by construction
+  - domain: policy
+    interaction: cutover is gated on the empty-delta verification result
+  - domain: provider
+    interaction: both engines execute the same definition; neither is trusted on faith
+  - domain: audit
+    interaction: the verification runs and their deltas are recorded as evidence
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: process-migration-2026-07-25
+  timestamp: '2026-07-25T02:00:00.000000+00:00'
+tags:
+- process-migration
+- blue-green
+- verification
+- typed-outputs
diff --git a/dav/use-cases/hammer-process-migration/003-automation-staged-promotion.yaml b/dav/use-cases/hammer-process-migration/003-automation-staged-promotion.yaml
new file mode 100644
index 0000000..fa8ed10
--- /dev/null
+++ b/dav/use-cases/hammer-process-migration/003-automation-staged-promotion.yaml
@@ -0,0 +1,52 @@
+uuid: uc-process-migration-003
+handle: process-migration/automation-staged-promotion
+version: 1.0.0
+scenario:
+  description: "Automation is deployed like an application: a new version of a process definition (or\
+    \ its engine binding \u2014 an updated playbook, a new execution environment) promotes through environments\
+    \ with gates. The version realizes in dev, runs against dev targets, passes its verification; promotes\
+    \ to a test/staging fleet under the same gates; and reaches production targets only after each stage's\
+    \ typed-output evidence passes. Rollback is re-selecting the previous version. The application-deployment\
+    \ discipline \u2014 versioned artifact, staged rollout, gated promotion, rollback \u2014 applied verbatim\
+    \ to automation."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Promote a new process-definition version through dev, test, and production stages with output-evidence
+    gates and version rollback, exactly as an application deploys
+  success_criteria:
+  - The process definition/binding is a versioned artifact; each stage pins the version it runs
+  - Promotion to the next stage is gated on the current stage's typed-output evidence
+  - Production targets never run a version that has not passed the prior stages
+  - Rollback is re-selection of the previous version, not a bespoke undo
+  - The promotion history is auditable end to end per version
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: versions and stage pins are records; promotion is a data operation
+  - domain: policy
+    interaction: stage gates are validation policies over typed-output evidence
+  - domain: provider
+    interaction: the engine realizes whichever version the stage pins
+  - domain: audit
+    interaction: per-version promotion history is the compliance story
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: process-migration-2026-07-25
+  timestamp: '2026-07-25T02:00:00.000000+00:00'
+tags:
+- process-migration
+- staged-deployment
+- promotion
+- automation-as-application
diff --git a/dav/use-cases/hammer-process-migration/004-process-portability-structural-query.yaml b/dav/use-cases/hammer-process-migration/004-process-portability-structural-query.yaml
new file mode 100644
index 0000000..21321c1
--- /dev/null
+++ b/dav/use-cases/hammer-process-migration/004-process-portability-structural-query.yaml
@@ -0,0 +1,50 @@
+uuid: uc-process-migration-004
+handle: process-migration/process-portability-structural-query
+version: 1.0.0
+scenario:
+  description: "Leadership asks: how locked-in is our automation? Under the class model the answer is\
+    \ a query, not an assessment project \u2014 every element of every process definition sits at a scope\
+    \ (shared execution contract, portable type definition, or engine binding), so lock-in is read structurally:\
+    \ which definitions carry engine-bound elements, which engines, and what the portable remainder is.\
+    \ The same query enumerates exactly what a migration would need to re-bind, producing the migration's\
+    \ scope estimate for free."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Answer automation lock-in questions as structural queries over element scope, and derive a migration's
+    re-binding scope from the same read
+  success_criteria:
+  - Every process definition's lock-in is answerable from element scope positions alone
+  - The query names which elements are engine-bound and to which engine
+  - A migration scope estimate (what must re-bind) derives from the same query
+  - No per-definition manual assessment is required, at any fleet size
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: multiple_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: element scope positions are the queried facts
+  - domain: policy
+    interaction: portability floors can be policy (e.g. no engine-bound elements in shared processes)
+  - domain: provider
+    interaction: engine bindings are visible, never buried in engine config
+  - domain: audit
+    interaction: lock-in posture is reportable as evidence over time
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: process-migration-2026-07-25
+  timestamp: '2026-07-25T02:00:00.000000+00:00'
+tags:
+- process-migration
+- portability
+- structural-query
+- lock-in
diff --git a/dav/use-cases/hammer-process-migration/005-engine-upgrade-regression.yaml b/dav/use-cases/hammer-process-migration/005-engine-upgrade-regression.yaml
new file mode 100644
index 0000000..748ea20
--- /dev/null
+++ b/dav/use-cases/hammer-process-migration/005-engine-upgrade-regression.yaml
@@ -0,0 +1,51 @@
+uuid: uc-process-migration-005
+handle: process-migration/engine-upgrade-regression
+version: 1.0.0
+scenario:
+  description: 'The blue/green verification mechanism applied to an engine''s own upgrade: before moving
+    automation from engine version N to N+1, the org runs the same idempotent process types through both
+    versions against converged targets and diffs the typed outputs. An empty delta clears the upgrade;
+    a non-empty delta is a behavioral regression in the engine itself, caught with production automation
+    before production exposure. The engine is regression-tested by its own workload, continuously, with
+    no dedicated test suite to maintain.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+    - security-officer
+  intent: Regression-test an automation engine upgrade by blue/green-diffing the same process types across
+    engine versions before adopting the upgrade
+  success_criteria:
+  - Engine N and N+1 run the same process types against converged targets
+  - Output deltas between versions are mechanical to produce and attribute
+  - A non-empty delta blocks the upgrade with the diverging behavior identified
+  - "The mechanism reuses the migration verification path \u2014 no dedicated harness"
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: typed outputs across engine versions are the compared evidence
+  - domain: policy
+    interaction: upgrade adoption is gated on the empty-delta result
+  - domain: provider
+    interaction: two versions of one engine are treated as two providers of the type
+  - domain: audit
+    interaction: upgrade verification evidence is recorded per engine version
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: process-migration-2026-07-25
+  timestamp: '2026-07-25T02:00:00.000000+00:00'
+tags:
+- process-migration
+- engine-upgrade
+- regression
+- blue-green
diff --git a/dav/use-cases/hammer-provider-portability/001-cross-provider-class-vm-vmware-to-ocpvirt-portable.yaml b/dav/use-cases/hammer-provider-portability/001-cross-provider-class-vm-vmware-to-ocpvirt-portable.yaml
new file mode 100644
index 0000000..f43702c
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/001-cross-provider-class-vm-vmware-to-ocpvirt-portable.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-provider-portability-001
+handle: provider-portability/cross-provider-class-vm-vmware-to-ocpvirt-portable
+scenario:
+  description: A VM was requested at the Type Class (Compute.VM) with only Base/Type SharedDataElements — cpu, memory,
+    os_image by standard identity, a portable network requirement. The org re-ports it from the VMware Provider
+    Class to the OCPVirt Provider Class. Because every element is Base/Type-scoped, the requirement set carries
+    wholesale; placement selects OCPVirt and the workload re-realizes with no requirement loss. A third-party mover
+    repopulates the disk.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Re-port a portable Compute.VM from VMware to OCPVirt across Provider Classes
+  success_criteria:
+  - The stored intent is replayed against the OCPVirt Provider Class
+  - Every Base/Type requirement re-realizes with no loss
+  - Placement selects OCPVirt as the eligible provider of the Type
+  - The data-migration provider moves the disk contents
+  - The re-realized resource records its lineage to the source
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: portable requirement set re-scoped against OCPVirt capabilities
+  - domain: provider
+    interaction: OCPVirt realizes the VM; a data-migration provider moves the disk
+  - domain: data
+    interaction: new realized entity records source_record_uuid lineage
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- compute-vm
+- migration
+- portable-baseline
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The source VM was realized at the Compute.VM Type Class with portable requirements
+  - OCPVirt is an eligible provider of Compute.VM
+  postconditions:
+  - The workload runs on OCPVirt with the full requirement set satisfied
+  - Lineage to the source is recorded
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/002-cross-provider-class-nsx-to-ovn-remainder-surfaced.yaml b/dav/use-cases/hammer-provider-portability/002-cross-provider-class-nsx-to-ovn-remainder-surfaced.yaml
new file mode 100644
index 0000000..984a823
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/002-cross-provider-class-nsx-to-ovn-remainder-surfaced.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-provider-portability-002
+handle: provider-portability/cross-provider-class-nsx-to-ovn-remainder-surfaced
+scenario:
+  description: A Compute.VM.VMware carries provider-specific elements (an NSX security group, a distributed switch)
+    alongside portable ones. Re-porting to Compute.VM.OCPVirt re-realizes the portable subset automatically; the
+    NSX security group maps to an OVN NetworkPolicy only if the intent was captured at the Type Class, and the distributed
+    switch has no OCPVirt equivalent and is surfaced as the non-portable remainder for a human decision.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - security-officer
+  intent: Re-port a VMware/NSX VM to OCPVirt/OVN, surfacing the provider-specific remainder
+  success_criteria:
+  - The portable Base/Type subset re-realizes on OCPVirt automatically
+  - The Type-Class network intent naturalizes to an OVN NetworkPolicy
+  - The provider-specific distributed-switch element is flagged non-portable
+  - The non-portable remainder is surfaced, not silently dropped
+  - The partial result is recorded with the surfaced remainder
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: evaluates which Provider-Class elements have a target equivalent
+  - domain: provider
+    interaction: OCPVirt/OVN realizes the portable subset; remainder surfaced
+  - domain: data
+    interaction: partial re-realization records the non-portable remainder
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- partial-port
+- provider-remainder
+- networking
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The source carries NSX-specific Provider-Class elements
+  - OCPVirt/OVN is the target
+  postconditions:
+  - The portable subset runs on OCPVirt
+  - The non-portable remainder is surfaced for a decision
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/003-cross-provider-class-ec2-to-ocpvirt-mover-timeout.yaml b/dav/use-cases/hammer-provider-portability/003-cross-provider-class-ec2-to-ocpvirt-mover-timeout.yaml
new file mode 100644
index 0000000..ba62695
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/003-cross-provider-class-ec2-to-ocpvirt-mover-timeout.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-provider-portability-003
+handle: provider-portability/cross-provider-class-ec2-to-ocpvirt-mover-timeout
+scenario:
+  description: An AWS EC2 instance is re-ported to OCPVirt. Compute re-realizes from intent quickly, but the third-party
+    data-migration provider moving the disk exceeds its operation deadline. DCM records the timeout on the data
+    step, holds the target in a non-operational state, and does not mark the re-port complete — the compute is realized
+    but the workload cannot be brought up until the data lands.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Cross-cloud re-port stalls when the data-migration provider times out
+  success_criteria:
+  - Compute re-realizes on OCPVirt from the stored intent
+  - The data-migration provider is invoked as a tracked Process
+  - The mover exceeds its deadline and DCM records a timeout on the data step
+  - The target is held non-operational pending the data
+  - The incomplete re-port is not marked successful
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: timeout
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: data-migration provider exceeds its operation deadline
+  - domain: policy
+    interaction: recovery policy holds the target non-operational on the timed-out data step
+  - domain: audit
+    interaction: the timeout and hold are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- timeout
+- data-migration
+- cross-cloud
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - EC2 source; OCPVirt target; a data-migration provider is wired
+  postconditions:
+  - Compute is realized but the workload is held pending the data
+  - A timeout is recorded on the data step
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/004-cross-provider-class-target-capacity-rollback.yaml b/dav/use-cases/hammer-provider-portability/004-cross-provider-class-target-capacity-rollback.yaml
new file mode 100644
index 0000000..224ce4b
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/004-cross-provider-class-target-capacity-rollback.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-provider-portability-004
+handle: provider-portability/cross-provider-class-target-capacity-rollback
+scenario:
+  description: A re-port to a new Provider Class begins, but the target provider reports insufficient capacity during
+    realization. Because realization is two-phase (validate-and-reserve, then commit), nothing on the target commits;
+    DCM rolls back the partial attempt and leaves the pre-re-port source state intact. The org is told the target
+    could not accept the workload.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Re-port rolls back when the target provider lacks capacity mid-realize
+  success_criteria:
+  - The re-port reserves against the target provider
+  - The target reports insufficient capacity before commit
+  - No target resource commits (two-phase barrier)
+  - The pre-re-port source state is left intact
+  - The rollback is recorded and the org notified
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: rollback_required
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: target reports insufficient capacity at reserve
+  - domain: policy
+    interaction: two-phase barrier prevents commit; rollback
+  - domain: data
+    interaction: source state preserved; rollback recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- rollback
+- capacity
+- two-phase
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The target Provider Class is capacity-constrained
+  postconditions:
+  - Source intact; no partial target state; rollback recorded
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/005-cross-provider-class-residency-policy-blocks-port.yaml b/dav/use-cases/hammer-provider-portability/005-cross-provider-class-residency-policy-blocks-port.yaml
new file mode 100644
index 0000000..d9f40e7
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/005-cross-provider-class-residency-policy-blocks-port.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-provider-portability-005
+handle: provider-portability/cross-provider-class-residency-policy-blocks-port
+scenario:
+  description: A sovereign-profile workload is re-ported toward a provider whose region violates the current residency
+    policy. The sovereignty gate — evaluated under current policy — rejects the placement before any realization.
+    The port is denied as a policy violation, and the source workload is unaffected.
+  actor:
+    persona: compliance-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - sovereignty-authority
+  intent: Cross-provider re-port is blocked by a residency policy on the target region
+  success_criteria:
+  - The target provider's region is evaluated against current residency policy
+  - The sovereignty gate rejects the non-compliant placement
+  - No realization occurs on the target
+  - The port is denied as a policy violation
+  - The source workload continues unaffected
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: policy_violation
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: current residency policy rejects the target region
+  - domain: provider
+    interaction: no eligible compliant provider accepts the port
+  - domain: audit
+    interaction: the policy-violation denial is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- policy-violation
+- sovereignty
+- residency
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - Sovereign profile; the candidate target region is non-compliant
+  postconditions:
+  - Port denied; source unaffected; denial recorded
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/006-cross-type-class-vm-to-container-portable-subset.yaml b/dav/use-cases/hammer-provider-portability/006-cross-type-class-vm-to-container-portable-subset.yaml
new file mode 100644
index 0000000..684a20a
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/006-cross-type-class-vm-to-container-portable-subset.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-provider-portability-006
+handle: provider-portability/cross-type-class-vm-to-container-portable-subset
+scenario:
+  description: A stateless web workload realized as a Compute.VM is re-realized as a Compute.Container — a cross-Type-Class
+    move under the same Compute Base. The Base-Class requirements (cpu, memory, the portable network intent) carry
+    across; VM-specific Provider/Type elements (a BIOS profile, a vTPM) have no container equivalent and are surfaced
+    as the non-portable remainder.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Re-realize a stateless workload from Compute.VM to Compute.Container across Type Classes
+  success_criteria:
+  - The Compute Base requirements carry from VM to Container
+  - The workload re-realizes as a Compute.Container
+  - VM-specific elements with no container equivalent are surfaced
+  - The partial re-realization records what did not carry
+  - The container serves the same portable network intent
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: re-scopes Base requirements from Compute.VM to Compute.Container
+  - domain: provider
+    interaction: a container provider realizes the workload
+  - domain: data
+    interaction: records VM-specific elements that did not carry
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-type-class
+- portability
+- compute-vm
+- compute-container
+- partial-port
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The source is a stateless Compute.VM with Base-portable requirements
+  postconditions:
+  - The workload runs as a Compute.Container; VM-specifics surfaced
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/007-cross-type-class-container-to-vm-kernel-requirement.yaml b/dav/use-cases/hammer-provider-portability/007-cross-type-class-container-to-vm-kernel-requirement.yaml
new file mode 100644
index 0000000..892fc3e
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/007-cross-type-class-container-to-vm-kernel-requirement.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-provider-portability-007
+handle: provider-portability/cross-type-class-container-to-vm-kernel-requirement
+scenario:
+  description: A container workload needs a capability a shared kernel cannot provide (a custom kernel module).
+    The org re-realizes it from Compute.Container to Compute.VM — a cross-Type-Class move under Compute Base. The
+    portable Base requirements carry; the VM gains the full-isolation Type elements the container lacked.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Promote a Compute.Container workload to a Compute.VM for a kernel-level requirement
+  success_criteria:
+  - The Base requirements carry from Container to VM
+  - The workload re-realizes as a Compute.VM
+  - The VM satisfies the kernel-level requirement the container could not
+  - The cross-Type move is recorded with its rationale
+  - The portable network intent is preserved
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: re-scopes Base requirements from Compute.Container to Compute.VM
+  - domain: provider
+    interaction: a VM provider realizes the workload with full isolation
+  - domain: data
+    interaction: records the cross-Type promotion and rationale
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-type-class
+- portability
+- compute-container
+- compute-vm
+- promotion
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The container workload requires a custom kernel module
+  postconditions:
+  - The workload runs as a Compute.VM satisfying the kernel requirement
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/008-cross-type-class-vm-to-baremetal-performance.yaml b/dav/use-cases/hammer-provider-portability/008-cross-type-class-vm-to-baremetal-performance.yaml
new file mode 100644
index 0000000..a430e3d
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/008-cross-type-class-vm-to-baremetal-performance.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-provider-portability-008
+handle: provider-portability/cross-type-class-vm-to-baremetal-performance
+scenario:
+  description: A latency-sensitive workload on a Compute.VM must run on physical hardware. It is re-realized as
+    Compute.BareMetal — a cross-Type-Class move under Compute Base. Placement finds an eligible bare-metal host
+    by the workload's hard requirements; the portable Base requirements carry, and virtualization-specific elements
+    are dropped.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+  intent: Re-realize a Compute.VM as Compute.BareMetal for a performance requirement
+  success_criteria:
+  - The Base requirements carry from VM to BareMetal
+  - Placement finds an eligible bare-metal host by requirements
+  - The workload re-realizes on physical hardware
+  - Virtualization-specific elements are surfaced/dropped
+  - The cross-Type move is recorded
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: re-scopes Base requirements from Compute.VM to Compute.BareMetal
+  - domain: provider
+    interaction: a bare-metal provider realizes the workload
+  - domain: data
+    interaction: records the cross-Type move and dropped virtualization elements
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-type-class
+- portability
+- compute-vm
+- compute-baremetal
+- performance
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The workload is latency-sensitive and eligible bare-metal hosts exist
+  postconditions:
+  - The workload runs on bare metal with Base requirements satisfied
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/009-cross-base-class-composite-port-spans-bases.yaml b/dav/use-cases/hammer-provider-portability/009-cross-base-class-composite-port-spans-bases.yaml
new file mode 100644
index 0000000..8602a2a
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/009-cross-base-class-composite-port-spans-bases.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-provider-portability-009
+handle: provider-portability/cross-base-class-composite-port-spans-bases
+scenario:
+  description: A three-tier service is a composite whose constituents span three Base Classes — Compute (the tiers),
+    Storage (a volume), and Network (a virtual network). Re-porting the composite re-realizes each constituent against
+    the target, crossing all three Base Classes in one ordered flow driven by the dependency graph.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Port a composite service whose constituents span Compute, Storage and Network Base Classes
+  success_criteria:
+  - The composite's constituents are re-realized in dependency order
+  - Compute, Storage and Network Base-Class requirements each re-realize
+  - The dependency graph supplies the correct order across Bases
+  - Cross-Base realized payloads (IP, volume handle) feed dependents
+  - The composite re-realizes as a coherent whole
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: orders the cross-Base re-realization via the dependency graph
+  - domain: provider
+    interaction: compute, storage and network providers each realize their constituent
+  - domain: data
+    interaction: cross-Base realized payloads recorded and passed downstream
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-base-class
+- portability
+- composite-service
+- compute-storage-network
+- dependency-graph
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The composite spans Compute, Storage and Network Base Classes
+  postconditions:
+  - The composite re-realizes across all three Base Classes
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/010-cross-base-class-block-to-fileshare-storage-cousins.yaml b/dav/use-cases/hammer-provider-portability/010-cross-base-class-block-to-fileshare-storage-cousins.yaml
new file mode 100644
index 0000000..089eeb5
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/010-cross-base-class-block-to-fileshare-storage-cousins.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-provider-portability-010
+handle: provider-portability/cross-base-class-block-to-fileshare-storage-cousins
+scenario:
+  description: During a workload migration the data must move from a block Storage.Volume to a Storage.FileShare
+    — cousin Types under the Storage Base Class. The portable Storage Base requirements (tier, capacity) carry;
+    the access-shape changes from block to file, and a third-party data-migration provider repopulates the share.
+  actor:
+    persona: storage-admin
+    profile: standard
+  perspectives:
+    - sre
+    - provider-owner
+  intent: Re-home data from Storage.Volume to Storage.FileShare during a migration
+  success_criteria:
+  - The Storage Base requirements (tier, capacity) carry across
+  - The data re-homes from Storage.Volume to Storage.FileShare
+  - The access-shape change (block to file) is recorded
+  - A data-migration provider repopulates the file share
+  - Dependents are re-pointed to the file share
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: re-scopes Storage Base requirements across cousin Types
+  - domain: provider
+    interaction: storage provider realizes the file share; mover repopulates it
+  - domain: data
+    interaction: records the access-shape change and re-points dependents
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-type-class
+- portability
+- storage-volume
+- storage-fileshare
+- storage-cousins
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The source data lives on a block Storage.Volume
+  postconditions:
+  - The data is served from a Storage.FileShare
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/011-cross-cousin-placement-vm-container-baremetal.yaml b/dav/use-cases/hammer-provider-portability/011-cross-cousin-placement-vm-container-baremetal.yaml
new file mode 100644
index 0000000..daf5776
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/011-cross-cousin-placement-vm-container-baremetal.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-provider-portability-011
+handle: provider-portability/cross-cousin-placement-vm-container-baremetal
+scenario:
+  description: A portable compute intent is requested at the Compute Base Class without pinning a Type. Placement
+    evaluates the eligible cousin Types — Compute.VM, Compute.Container, Compute.BareMetal — against the workload's
+    requirements and advertised capabilities, and selects the best-fitting cousin. This exercises portability across
+    cousin Type Classes under one Base.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+  intent: Placement evaluates VM, Container and BareMetal cousins for one portable intent
+  success_criteria:
+  - A Base-Class Compute intent is requested without a pinned Type
+  - Placement enumerates eligible cousin Types (VM, Container, BareMetal)
+  - Each cousin is scored by requirements and advertised capability
+  - The best-fitting cousin Type is selected and realized
+  - The selection rationale is recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: scores cousin Types against requirements and capability
+  - domain: provider
+    interaction: the selected cousin's provider realizes the workload
+  - domain: data
+    interaction: records the cousin selection rationale
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-cousin
+- portability
+- compute-vm
+- compute-container
+- compute-baremetal
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The intent is expressed at the Compute Base Class
+  postconditions:
+  - The workload runs on the best-fitting cousin Type
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/012-cross-cousin-composite-mixed-vm-container-baremetal.yaml b/dav/use-cases/hammer-provider-portability/012-cross-cousin-composite-mixed-vm-container-baremetal.yaml
new file mode 100644
index 0000000..bb0ab7c
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/012-cross-cousin-composite-mixed-vm-container-baremetal.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-provider-portability-012
+handle: provider-portability/cross-cousin-composite-mixed-vm-container-baremetal
+scenario:
+  description: A composite service mixes cousin Compute Types — a Compute.BareMetal database, Compute.VM app servers,
+    and Compute.Container front-ends — realized together as one ordered flow. The mix of cousin Types under the
+    Compute Base is coordinated by the dependency graph and a mixed provider landscape.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Realize a composite whose constituents are VM, Container and BareMetal cousins
+  success_criteria:
+  - The composite declares VM, Container and BareMetal constituents
+  - Each cousin Type is realized by its own provider
+  - The dependency graph orders the mixed realization
+  - Realized payloads flow between the cousin tiers
+  - The composite is healthy only when all cousin tiers are up
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: orders the mixed cousin realization
+  - domain: provider
+    interaction: bare-metal, VM and container providers each realize a tier
+  - domain: data
+    interaction: composite_health tracks all cousin tiers
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-cousin
+- portability
+- composite-service
+- mixed-compute
+- three-tier
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The composite mixes BareMetal, VM and Container tiers
+  postconditions:
+  - The composite runs across all three cousin Types
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/013-cross-cousin-fallback-vm-exhausted-to-container.yaml b/dav/use-cases/hammer-provider-portability/013-cross-cousin-fallback-vm-exhausted-to-container.yaml
new file mode 100644
index 0000000..1446bfb
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/013-cross-cousin-fallback-vm-exhausted-to-container.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-provider-portability-013
+handle: provider-portability/cross-cousin-fallback-vm-exhausted-to-container
+scenario:
+  description: A request prefers Compute.VM, but every eligible VM provider is at capacity. A recovery policy permits
+    falling back to the Compute.Container cousin when the workload's requirements allow it. Placement re-scopes
+    to the container cousin and realizes there, recording the exhaustion-driven fallback.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Fall back to a Compute.Container cousin when Compute.VM capacity is exhausted
+  success_criteria:
+  - The preferred Compute.VM providers report capacity exhaustion
+  - A recovery policy permits the Compute.Container cousin fallback
+  - The workload's requirements are checked to allow the cousin
+  - The workload realizes as a Compute.Container
+  - The exhaustion-driven fallback is recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: resource_exhaustion
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: recovery policy authorizes the cousin fallback on exhaustion
+  - domain: provider
+    interaction: VM providers exhausted; a container provider accepts the workload
+  - domain: audit
+    interaction: the exhaustion and fallback are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-cousin
+- portability
+- resource-exhaustion
+- fallback
+- compute-container
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - All eligible Compute.VM providers are at capacity; a fallback policy exists
+  postconditions:
+  - The workload runs on a Compute.Container cousin; fallback recorded
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/014-cross-provider-class-peer-dcm-disconnect-mid-port.yaml b/dav/use-cases/hammer-provider-portability/014-cross-provider-class-peer-dcm-disconnect-mid-port.yaml
new file mode 100644
index 0000000..40a7888
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/014-cross-provider-class-peer-dcm-disconnect-mid-port.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-provider-portability-014
+handle: provider-portability/cross-provider-class-peer-dcm-disconnect-mid-port
+scenario:
+  description: A workload is re-ported across a federation boundary to a provider in a peer DCM's estate. Mid-port
+    the peer DCM becomes unreachable. The local DCM records the disconnect, does not mark the port complete, and
+    preserves the source; the port can be retried when the peer returns.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - federation-peer-operator
+  intent: A federated re-port to a peer DCM's provider fails when the peer disconnects
+  success_criteria:
+  - The re-port dispatches across the federation boundary to the peer
+  - The peer DCM becomes unreachable mid-port
+  - The local DCM records the peer disconnect
+  - The port is not marked complete and the source is preserved
+  - The port is retryable when the peer returns
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the peer DCM's provider becomes unreachable
+  - domain: policy
+    interaction: recovery policy holds the port pending the peer
+  - domain: audit
+    interaction: the disconnect and hold are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- federation
+- peer-dcm-disconnect
+- cross-boundary
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The target provider is in a peer DCM's estate
+  postconditions:
+  - Source preserved; port held; disconnect recorded
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/015-cross-provider-class-partial-composite-db-tier-fails.yaml b/dav/use-cases/hammer-provider-portability/015-cross-provider-class-partial-composite-db-tier-fails.yaml
new file mode 100644
index 0000000..d23e30d
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/015-cross-provider-class-partial-composite-db-tier-fails.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-provider-portability-015
+handle: provider-portability/cross-provider-class-partial-composite-db-tier-fails
+scenario:
+  description: A three-tier application is re-ported across Provider Classes. The web and app tiers — portable at
+    the Type Class — re-realize cleanly. The database tier depends on a provider-specific replication element with
+    no equivalent on the target; that tier is not re-realized, and the composite is reported as partially fulfilled
+    with the DB tier surfaced.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: A three-tier re-port partially fulfills when the DB tier's provider-specific replication does not carry
+  success_criteria:
+  - Web and app tiers re-realize on the target Provider Class
+  - The DB tier's provider-specific replication has no target equivalent
+  - The DB tier is not re-realized
+  - The composite is reported partially fulfilled
+  - The unfulfilled DB tier is surfaced for a decision
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: evaluates each tier's portability against the target
+  - domain: provider
+    interaction: web/app tiers realize; DB tier's replication has no equivalent
+  - domain: data
+    interaction: composite recorded partially fulfilled with the DB tier surfaced
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- partial-fulfillment
+- composite-service
+- three-tier
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The DB tier carries a provider-specific replication element
+  postconditions:
+  - Web/app tiers ported; DB tier surfaced as unfulfilled
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/016-cross-provider-class-rehydration-portable-new-uuid.yaml b/dav/use-cases/hammer-provider-portability/016-cross-provider-class-rehydration-portable-new-uuid.yaml
new file mode 100644
index 0000000..0bbba0b
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/016-cross-provider-class-rehydration-portable-new-uuid.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-provider-portability-016
+handle: provider-portability/cross-provider-class-rehydration-portable-new-uuid
+scenario:
+  description: The provider that held a workload is offline, so it cannot be restored in place. The workload is
+    rebuilt from its stored intent on a currently-available Provider Class — a Provider-Portable rehydration. The
+    replacement is a new realized entity with a new UUID; lineage links it to the source record, and dependents
+    re-point to the replacement.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Rehydrate a workload onto a different provider when the original is offline (new UUID)
+  success_criteria:
+  - The original provider is offline; no in-place restore is possible
+  - The workload is rebuilt from stored intent on an available provider
+  - The replacement is a new entity with a new UUID
+  - Lineage links the replacement to the source record
+  - Dependents re-point to the replacement
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: re-evaluates sovereignty/tenancy under current policy on rehydration
+  - domain: provider
+    interaction: the original is offline; an available provider realizes the rebuild
+  - domain: data
+    interaction: new UUID recorded with source_record_uuid lineage
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- rehydration
+- new-uuid
+- provider-failure
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The original provider is offline; the stored intent is available
+  postconditions:
+  - A new entity runs on an available provider, traceable to the source
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/017-cross-provider-class-nonportable-native-standard-surfaced.yaml b/dav/use-cases/hammer-provider-portability/017-cross-provider-class-nonportable-native-standard-surfaced.yaml
new file mode 100644
index 0000000..b4af770
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/017-cross-provider-class-nonportable-native-standard-surfaced.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-provider-portability-017
+handle: provider-portability/cross-provider-class-nonportable-native-standard-surfaced
+scenario:
+  description: A workload's type adopts a provider-native standard as a type-scope element. When the org re-ports
+    to a different Provider Class, that native-standard element has no equivalent on the target and is surfaced
+    as non-portable. The portable subset re-realizes; the native-standard remainder is flagged for a decision. (The
+    org may choose to keep, remap, or drop it — the engine surfaces, it does not decide.)
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: A type adopting a provider-native standard is surfaced as non-portable at re-port
+  success_criteria:
+  - The portable Base/Type subset re-realizes on the target
+  - The provider-native standard element has no target equivalent
+  - The native-standard element is surfaced as non-portable
+  - The portable result records the surfaced remainder
+  - The decision on the remainder is left to the org
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: identifies the provider-native element with no target equivalent
+  - domain: provider
+    interaction: target realizes the portable subset only
+  - domain: data
+    interaction: records the surfaced native-standard remainder
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- provider-native-standard
+- partial-fulfillment
+- neutrality
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The source type carries a provider-native standard element
+  postconditions:
+  - Portable subset ported; native-standard remainder surfaced
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/018-cross-provider-class-post-port-drift.yaml b/dav/use-cases/hammer-provider-portability/018-cross-provider-class-post-port-drift.yaml
new file mode 100644
index 0000000..fddc395
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/018-cross-provider-class-post-port-drift.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-provider-portability-018
+handle: provider-portability/cross-provider-class-post-port-drift
+scenario:
+  description: After a successful cross-Provider-Class re-port, drift detection compares the target's discovered
+    state against the ported intent and finds a divergence — the target provider silently changed a field the intent
+    pinned. The drift is recorded as a data inconsistency and enters the drift-remediation flow.
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+    - provider-owner
+    - compliance-auditor
+  intent: Post-port drift when the target's realized state diverges from the ported intent
+  success_criteria:
+  - The workload re-realizes on the target Provider Class
+  - Drift detection compares discovered state to the ported intent
+  - A field the intent pinned has diverged on the target
+  - The divergence is recorded as a data inconsistency
+  - The drift enters the remediation flow
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: drift policy classifies the divergence and triggers remediation
+  - domain: provider
+    interaction: the target silently changed a pinned field
+  - domain: audit
+    interaction: the drift is recorded against the ported intent
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- drift-detection
+- data-inconsistency
+- post-port
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The workload was re-ported and is running on the target
+  postconditions:
+  - The post-port drift is detected and enters remediation
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/019-cross-base-class-brownfield-port-unknown-class.yaml b/dav/use-cases/hammer-provider-portability/019-cross-base-class-brownfield-port-unknown-class.yaml
new file mode 100644
index 0000000..a37e945
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/019-cross-base-class-brownfield-port-unknown-class.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-provider-portability-019
+handle: provider-portability/cross-base-class-brownfield-port-unknown-class
+scenario:
+  description: A resource discovered in the field carries only its native construct, not the intent behind it. To
+    re-port it, greening first reverse-derives the workload's Base/Type class and requirements (imperfectly); the
+    recovered intent is then re-realized on the target. The port is only as good as the recovered intent, and any
+    unrecoverable native specifics are surfaced.
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - application-team-member
+  intent: Green a brownfield resource and re-port it, recovering its Base/Type class first
+  success_criteria:
+  - The brownfield resource is discovered with only its native construct
+  - Greening reverse-derives its Base/Type class and requirements
+  - The recovered intent is re-realized on the target
+  - Unrecoverable native specifics are surfaced
+  - The port quality reflects the recovered intent
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: greening reverse-derives the class and requirements
+  - domain: provider
+    interaction: the target realizes the recovered intent
+  - domain: data
+    interaction: records recovered intent and unrecoverable specifics
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-type-class
+- portability
+- brownfield
+- greening
+- partial-fulfillment
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The source is a brownfield resource with no captured intent
+  postconditions:
+  - The recovered intent is re-realized; unrecoverable specifics surfaced
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-provider-portability/020-cross-provider-class-decommission-source-after-port.yaml b/dav/use-cases/hammer-provider-portability/020-cross-provider-class-decommission-source-after-port.yaml
new file mode 100644
index 0000000..c0f8b78
--- /dev/null
+++ b/dav/use-cases/hammer-provider-portability/020-cross-provider-class-decommission-source-after-port.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-provider-portability-020
+handle: provider-portability/cross-provider-class-decommission-source-after-port
+scenario:
+  description: After a workload is re-ported and verified healthy on the target Provider Class, the source resource
+    is decommissioned. Decommission is staged and dependency-ordered so nothing still bound to the source is orphaned;
+    the source's audit records are preserved.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Decommission the source Provider-Class resource after a verified re-port
+  success_criteria:
+  - The re-ported workload is verified healthy on the target
+  - No dependents remain bound to the source resource
+  - The source is decommissioned in dependency order
+  - The source's audit records are preserved
+  - The decommission is recorded against the port lineage
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: verifies no remaining bindings before decommission
+  - domain: provider
+    interaction: the source provider removes the resource
+  - domain: audit
+    interaction: decommission recorded; audit history preserved
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: portability-enrich-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- cross-provider-class
+- portability
+- decommission
+- source-cleanup
+- staged
+- provider-portability
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-portability-enrich
+  preconditions:
+  - The workload is verified healthy on the target after re-port
+  postconditions:
+  - The source is decommissioned; audit preserved
+  note: batch=portability-enrich-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/001-scoped-class-base-to-provider-resolution.yaml b/dav/use-cases/hammer-recent-model/001-scoped-class-base-to-provider-resolution.yaml
new file mode 100644
index 0000000..86a7866
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/001-scoped-class-base-to-provider-resolution.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-recent-model-001
+handle: recent-model/scoped-class-base-to-provider-resolution
+scenario:
+  description: "A platform engineer submits a request against the Base Class Compute with only outcome-level\n\
+    \    requirements (vCPU, memory, a durable local disk) and no provider named. The substrate must resolve\n\
+    \    the request down the Class hierarchy Base(Compute) -> Type(Compute.VM) -> Provider Class\n  \
+    \  (Compute.VM.OCPVirt vs Compute.VM.Libvirt) -> a concrete instance, choosing across the eligible\
+    \ set\n    by intersecting stated requirements with each Provider Class's advertised capability and\
+    \ the governing\n    policy. This probes that resolution is stepwise and driven by requirements plus\
+    \ advertised capability,\n    not by a hard-coded provider binding at the Base Class."
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives: []
+  intent: Provision a Compute instance stated only at the Base Class, resolved down to a Provider Class
+    by capability and policy
+  success_criteria:
+  - The request is accepted at Base Class Compute with no provider named
+  - Resolution proceeds Base -> Type -> Provider Class -> instance in discrete, inspectable steps
+  - Each candidate Provider Class is scored by intersecting requirements with its advertised capability
+  - Governing policy narrows the eligible Provider Class set before selection
+  - The selected instance satisfies every stated requirement and records the resolution path
+  - The chosen Provider Class and the rejected alternatives are captured in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: the Base Class request and the Base/Type/Provider Class definitions are read to build
+      the resolution tree
+  - domain: policy
+    interaction: policy narrows the eligible Provider Class set by requirement-vs-capability constraints
+  - domain: provider
+    interaction: each eligible Provider Class advertises capability and the winner realizes the instance
+  - domain: audit
+    interaction: the full resolution path and rejected candidates are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- scoped-class
+- base-type-provider
+- class-resolution
+- capability-match
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - Compute Base/Type/Provider Class definitions are registered
+  - At least two Provider Classes advertise Compute.VM capability
+  postconditions:
+  - A Compute.VM instance exists under a single resolved Provider Class
+  - The resolution path is queryable from the entity
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/002-scoped-class-capability-filter-narrows-eligible.yaml b/dav/use-cases/hammer-recent-model/002-scoped-class-capability-filter-narrows-eligible.yaml
new file mode 100644
index 0000000..63f054f
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/002-scoped-class-capability-filter-narrows-eligible.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-recent-model-002
+handle: recent-model/scoped-class-capability-filter-narrows-eligible
+scenario:
+  description: "An SRE requests a Compute instance whose requirements include an accelerator class and\
+    \ a hard\n    anti-affinity dependency on an existing tenant workload. Two Provider Classes advertise\
+    \ Compute.VM,\n    but only one advertises the accelerator capability, so requirement-vs-capability\
+    \ filtering collapses\n    the eligible set from two to one before policy even runs. The surviving\
+    \ Provider Class can place the\n    instance but cannot honor the anti-affinity across every zone,\
+    \ so the request is realized in a reduced\n    footprint. This stresses that capability filtering\
+    \ happens at Class-resolution time and that a\n    dependency the resolved Provider Class only partly\
+    \ satisfies yields partial fulfillment, not a silent\n    full success."
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - platform-operator
+    - tenancy-authority
+  intent: Resolve a Compute request with an accelerator requirement and a hard dependency the eligible
+    Provider Class only partly satisfies
+  success_criteria:
+  - Requirement-vs-capability filtering removes the Provider Class lacking the accelerator capability
+  - Exactly one Provider Class survives Class resolution and is selected
+  - The hard anti-affinity dependency is evaluated against the resolved Provider Class's real placement
+    options
+  - The request is realized only in the footprint the Provider Class can honor, flagged partial
+  - The unmet portion of the dependency is reported, not silently dropped
+  - Audit records both the capability-filtered candidate and the partial-fulfillment reason
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: partial_fulfillment
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the request's accelerator requirement and anti-affinity dependency are read against Provider
+      Class capabilities
+  - domain: policy
+    interaction: a cross-domain constraint checks the anti-affinity dependency against the resolved placement
+  - domain: provider
+    interaction: the single surviving Provider Class realizes what it can and returns the unmet remainder
+  - domain: audit
+    interaction: the capability filter outcome and partial-fulfillment reason are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- scoped-class
+- capability-filter
+- requirement-mismatch
+- class-resolution
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - Only one Provider Class advertises the required accelerator capability
+  - An existing tenant workload constrains anti-affinity
+  postconditions:
+  - A partially realized Compute instance exists
+  - The unmet dependency remainder is recorded as an open item
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/003-provider-class-element-custodied-not-translated.yaml b/dav/use-cases/hammer-recent-model/003-provider-class-element-custodied-not-translated.yaml
new file mode 100644
index 0000000..14cbbd3
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/003-provider-class-element-custodied-not-translated.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-recent-model-003
+handle: recent-model/provider-class-element-custodied-not-translated
+scenario:
+  description: "A platform operator provisions a Compute.VM.OCPVirt instance that carries a Provider-Class\n\
+    \    SharedDataElement network_policy_ref, a value meaningful only to the OCPVirt provider. The substrate\n\
+    \    must custody this element on the entity record verbatim, expose it for query and policy, and\
+    \ pass it\n    to the OCPVirt provider WITHOUT ever translating it into a native Kubernetes NetworkPolicy\
+    \ object.\n    Naturalization into provider-native form stays strictly at the provider edge. This\
+    \ probes that a\n    defined Provider-Class element is first-class data the platform stores and governs\
+    \ but never\n    interprets on the provider's behalf."
+  actor:
+    persona: platform-operator
+    profile: prod
+  perspectives: []
+  intent: Provision an OCPVirt VM carrying a Provider-Class network_policy_ref that the substrate stores
+    but never naturalizes
+  success_criteria:
+  - network_policy_ref is stored on the entity as a defined Compute.VM.OCPVirt SharedDataElement
+  - The substrate never converts network_policy_ref into a provider-native NetworkPolicy
+  - The element is queryable and available to policy at the substrate layer
+  - The element is passed to the OCPVirt provider intact for edge naturalization
+  - The realized record shows naturalization occurred only at the provider edge
+  - Audit shows the element crossed the boundary untranslated
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: network_policy_ref is custodied verbatim as a defined Provider-Class SharedDataElement
+  - domain: policy
+    interaction: a single validation confirms the element is well-formed without interpreting its meaning
+  - domain: provider
+    interaction: the OCPVirt provider naturalizes network_policy_ref into native form only at the edge
+  - domain: audit
+    interaction: the untranslated boundary crossing of the element is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- provider-class-element
+- shared-data-element
+- naturalization-at-edge
+- ocpvirt
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - Compute.VM.OCPVirt defines network_policy_ref as a SharedDataElement
+  - The OCPVirt provider is eligible and online
+  postconditions:
+  - The VM exists with network_policy_ref stored verbatim
+  - Provider-native naturalization is confined to the edge
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/004-provider-class-element-survives-modification.yaml b/dav/use-cases/hammer-recent-model/004-provider-class-element-survives-modification.yaml
new file mode 100644
index 0000000..7949121
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/004-provider-class-element-survives-modification.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-recent-model-004
+handle: recent-model/provider-class-element-survives-modification
+scenario:
+  description: "A tenant admin modifies an existing Compute.VM.OCPVirt instance to resize memory. The\
+    \ instance\n    carries a Provider-Class SharedDataElement (a placement_group_ref) that is untouched\
+    \ by the resize.\n    The modification path must preserve the custodied element byte-for-byte across\
+    \ the change and must not\n    round-trip it through any provider-native representation, since the\
+    \ substrate has no schema for the\n    provider's internal form. This stresses that a defined Provider-Class\
+    \ element is durable across\n    lifecycle mutations and remains opaque-but-custodied, distinct from\
+    \ the retired provider_extensions\n    free-bag approach."
+  actor:
+    persona: tenant-admin
+    profile: dev
+  perspectives:
+    - provider-owner
+    - tenancy-authority
+  intent: Resize an OCPVirt VM while preserving its custodied Provider-Class placement_group_ref unchanged
+  success_criteria:
+  - The memory resize is applied to the entity
+  - The placement_group_ref SharedDataElement is unchanged after the modification
+  - The element is never round-tripped through a provider-native representation during the change
+  - The element remains a defined Provider-Class element, not a free-form extension bag
+  - The realized record after resize still exposes the element for query
+  - Audit shows the resize touched memory only and left the custodied element intact
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: data
+    interaction: the placement_group_ref element is carried through the modification unchanged
+  - domain: policy
+    interaction: system defaults validate the resize without touching the custodied element
+  - domain: provider
+    interaction: the OCPVirt provider applies the resize and leaves its element semantics at the edge
+  - domain: audit
+    interaction: the modification scope and element stability are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- provider-class-element
+- shared-data-element
+- modification
+- custody-stability
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - The VM already carries a defined placement_group_ref element
+  - provider_extensions is retired; the element is a defined SharedDataElement
+  postconditions:
+  - The VM has new memory and an unchanged placement_group_ref
+  - No provider-native round-trip of the element occurred
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/005-references-edge-baremetal-in-datacenter.yaml b/dav/use-cases/hammer-recent-model/005-references-edge-baremetal-in-datacenter.yaml
new file mode 100644
index 0000000..7546f00
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/005-references-edge-baremetal-in-datacenter.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-recent-model-005
+handle: recent-model/references-edge-baremetal-in-datacenter
+scenario:
+  description: "During brownfield ingestion a BareMetal host is linked to the DataCenter dc-east through\
+    \ a\n    classified, dereferenceable references-context edge (edge class located_in), rather than\
+    \ by copying\n    the datacenter's attributes onto the host. The edge must be typed, must resolve\
+    \ to the real\n    DataCenter entity on dereference, and must let a reader navigate host -> DataCenter\
+    \ without the host\n    duplicating any datacenter-owned field. This probes that orthogonal context\
+    \ is modeled as a\n    first-class classified edge, keeping the host record free of denormalized context."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Link a discovered BareMetal host to its DataCenter via a classified dereferenceable references
+    edge
+  success_criteria:
+  - A located_in references-context edge is created from the host to DataCenter dc-east
+  - The edge is classified (typed) and dereferences to the real DataCenter entity
+  - No datacenter-owned attribute is copied onto the host record
+  - Navigation from host to DataCenter succeeds through the edge
+  - The edge survives re-scan without duplication or reassignment
+  - The edge creation is recorded with its class and endpoints in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: a classified located_in edge is persisted from the host to the DataCenter entity
+  - domain: provider
+    interaction: a discovery provider supplies the host-to-datacenter association
+  - domain: policy
+    interaction: a single validation confirms the edge class and endpoints are well-formed
+  - domain: audit
+    interaction: the edge class and endpoints are recorded at ingestion
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- references-context-edge
+- classified-edge
+- dereferenceable
+- datacenter
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - The DataCenter dc-east entity exists
+  - A discovery source reports the host's datacenter location
+  postconditions:
+  - The host references dc-east through a dereferenceable edge
+  - The host record holds no denormalized datacenter fields
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/006-references-edge-policy-over-all-pointing-to-dc-east.yaml b/dav/use-cases/hammer-recent-model/006-references-edge-policy-over-all-pointing-to-dc-east.yaml
new file mode 100644
index 0000000..1d55fce
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/006-references-edge-policy-over-all-pointing-to-dc-east.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-recent-model-006
+handle: recent-model/references-edge-policy-over-all-pointing-to-dc-east
+scenario:
+  description: "A compliance auditor enforces a residency rule that must apply to every resource located\
+    \ in the\n    DataCenter dc-east, regardless of resource type. The policy is written against the reference\
+    \ dc-east\n    and evaluates over anything that points to it through a located_in references-context\
+    \ edge, gathering\n    the full set by reverse-walking the edges rather than by a hand-maintained\
+    \ membership list. A newly\n    linked VM that violates the residency rule is caught because it now\
+    \ points to dc-east. This stresses\n    reference-scoped policy: the set of governed resources is\
+    \ derived from who points at the reference."
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: Enforce a residency rule against every resource that references DataCenter dc-east
+  success_criteria:
+  - The policy is authored against the reference dc-east, not a static resource list
+  - The governed set is derived by reverse-walking located_in edges to dc-east
+  - A resource is included the moment it gains an edge to dc-east
+  - A newly linked VM violating the residency rule is flagged as a violation
+  - Resources not pointing to dc-east are excluded from evaluation
+  - The violation and the derived governed set are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: cross_dependency_payload
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: the governed set is computed by reverse-walking references edges into dc-east
+  - domain: policy
+    interaction: the residency rule evaluates over every resource pointing to the dc-east reference
+  - domain: audit
+    interaction: the derived set and the residency violation are recorded for the auditor
+  - domain: provider
+    interaction: provider state confirms the offending VM's realized location for the check
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- references-context-edge
+- reference-scoped-policy
+- blast-set
+- governance-matrix
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - A residency rule is scoped to the dc-east reference
+  - Multiple resource types carry located_in edges to dc-east
+  postconditions:
+  - The reference-scoped governed set is materialized
+  - The offending VM is marked in violation of residency
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/007-navigational-projection-residency-onto-workload.yaml b/dav/use-cases/hammer-recent-model/007-navigational-projection-residency-onto-workload.yaml
new file mode 100644
index 0000000..78bb331
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/007-navigational-projection-residency-onto-workload.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-recent-model-007
+handle: recent-model/navigational-projection-residency-onto-workload
+scenario:
+  description: "A platform engineer provisions a sovereign workload whose placement policy needs the residency\
+    \ of\n    the DataCenter it will run in. Rather than the requester restating residency, the pipeline\
+    \ projects\n    it via the navigational coordinate self.datacenter.residency, pulling the residency\
+    \ field from the\n    related DataCenter entity into the request at evaluation time. The dereference\
+    \ is governed: the\n    projection is only permitted because policy authorizes reading residency across\
+    \ that relation. This\n    probes that a field can be injected FROM a related entity INTO the pipeline\
+    \ by coordinate, and that\n    the cross-entity read is policy-governed rather than free."
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+  intent: Project the DataCenter residency onto a sovereign workload via self.datacenter.residency at
+    evaluation time
+  success_criteria:
+  - The projection self.datacenter.residency resolves to the related DataCenter's residency value
+  - The residency is injected into the request pipeline, not restated by the requester
+  - The cross-entity dereference is authorized by policy before the value is read
+  - The placement decision uses the projected residency
+  - The projected value's provenance (source entity and field path) is retained
+  - The governed dereference is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: self.datacenter.residency is dereferenced from the related DataCenter entity
+  - domain: policy
+    interaction: policy authorizes the cross-relation read and applies the projected residency to placement
+  - domain: provider
+    interaction: the eligible provider places the workload consistent with the projected residency
+  - domain: audit
+    interaction: the governed dereference and its provenance are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- navigational-projection
+- self-relation-fieldpath
+- governed-dereference
+- residency-injection
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - The workload has a resolvable datacenter relation
+  - The DataCenter entity exposes a residency field
+  postconditions:
+  - The workload is placed per its DataCenter's residency
+  - The projection's source path and value are retained on the entity
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/008-navigational-projection-unresolved-source-field.yaml b/dav/use-cases/hammer-recent-model/008-navigational-projection-unresolved-source-field.yaml
new file mode 100644
index 0000000..1866bf0
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/008-navigational-projection-unresolved-source-field.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-recent-model-008
+handle: recent-model/navigational-projection-unresolved-source-field
+scenario:
+  description: "An SRE modifies a workload whose placement policy projects self.datacenter.residency,\
+    \ but the\n    workload's datacenter relation points at a DataCenter record whose residency field\
+    \ was never\n    populated. The navigational-coordinate dereference resolves the relation yet finds\
+    \ the target field\n    empty, so the projection yields no value. The pipeline must treat this as\
+    \ a data inconsistency: the\n    policy input is unresolved, so the evaluation cannot proceed to a\
+    \ trustworthy decision and must\n    surface the dangling field rather than substitute a default.\
+    \ This stresses the failure edge of\n    projection when the source field is unresolved."
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - provider-owner
+    - sovereignty-authority
+  intent: Detect that a self.datacenter.residency projection is unresolved because the source field is
+    empty
+  success_criteria:
+  - The datacenter relation resolves but the residency field is empty
+  - The projection yields no value and is marked unresolved
+  - The pipeline does not substitute a default for the missing projected field
+  - The policy evaluation halts as un-decidable on the unresolved input
+  - The dangling field path (self.datacenter.residency) is surfaced to the operator
+  - The data inconsistency is recorded with the entity and field path in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: the relation resolves but the residency field is found unpopulated
+  - domain: policy
+    interaction: the single validation cannot decide on an unresolved projected input and halts
+  - domain: audit
+    interaction: the unresolved projection and dangling field path are recorded
+  - domain: provider
+    interaction: no provider action is taken because the evaluation did not reach a decision
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- navigational-projection
+- unresolved-projection
+- dangling-relation
+- data-inconsistency
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - The workload's datacenter relation targets a DataCenter with no residency set
+  - The placement policy depends on the projected residency
+  postconditions:
+  - The modification is blocked pending residency resolution
+  - The dangling field path is reported as a data inconsistency
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/009-firewall-egress-release-confidentiality-block.yaml b/dav/use-cases/hammer-recent-model/009-firewall-egress-release-confidentiality-block.yaml
new file mode 100644
index 0000000..dc4dae0
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/009-firewall-egress-release-confidentiality-block.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-recent-model-009
+handle: recent-model/firewall-egress-release-confidentiality-block
+scenario:
+  description: "A security officer's policy governs a request that would send a resolved secret-material\
+    \ reference\n    to a peer DCM for cross-boundary fulfillment. The information-firewall performs egress\
+    \ mediation: it\n    inspects the outbound payload before any value crosses the boundary. Structural\
+    \ inspection catches\n    that the payload carries a pointer to confidential material; value inspection,\
+    \ once the pointer would\n    resolve, confirms the datum is release-restricted. The firewall blocks\
+    \ egress, so the value never\n    leaves the boundary and the peer-DCM handoff is refused. This probes\
+    \ egress release/confidentiality\n    control and the structural-vs-value distinction on the outbound\
+    \ side."
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - federation-peer-operator
+  intent: Block egress of a release-restricted confidential value before it crosses to a peer DCM
+  success_criteria:
+  - Egress mediation runs before any value crosses the boundary
+  - Structural inspection detects the payload carries a pointer to confidential material
+  - Value inspection confirms the resolved datum is release-restricted
+  - The firewall blocks egress and the value never leaves the boundary
+  - The peer-DCM handoff is refused as a policy violation
+  - The egress block, with structural and value findings, is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: compliance_gated
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: egress mediation performs structural then value inspection and blocks release
+  - domain: data
+    interaction: the confidential reference is resolved only inside the boundary for value inspection
+  - domain: provider
+    interaction: the peer-DCM provider handoff is refused because egress was blocked
+  - domain: audit
+    interaction: the egress block with structural and value findings is recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- policy-firewall
+- egress-release
+- confidentiality
+- structural-vs-value
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - A release-restricted classification applies to the referenced material
+  - A peer DCM is the only eligible fulfiller across the boundary
+  postconditions:
+  - The confidential value never crossed the boundary
+  - The peer-DCM handoff is refused and logged as a violation
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/010-firewall-ingress-admission-redact-high-assurance.yaml b/dav/use-cases/hammer-recent-model/010-firewall-ingress-admission-redact-high-assurance.yaml
new file mode 100644
index 0000000..e6934e0
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/010-firewall-ingress-admission-redact-high-assurance.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-recent-model-010
+handle: recent-model/firewall-ingress-admission-redact-high-assurance
+scenario:
+  description: "Data arriving from a lower-assurance discovery source must be admitted into a high-assurance\n\
+    \    sovereign zone. The information-firewall performs ingress mediation: after the data comes in,\
+    \ an\n    admission/integrity check validates provenance and structure, and a cross-domain guard transforms\
+    \ the\n    payload by redacting fields that are not permitted in the high-assurance zone before the\
+    \ data is\n    persisted. Records that pass are admitted in redacted form; records failing the integrity\
+    \ check are\n    quarantined. This stresses ingress admission/integrity control and a guard that transforms/redacts\
+    \ on\n    the inbound side, the mirror of egress mediation."
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Admit lower-assurance inbound data into a high-assurance zone through an integrity-checked,
+    redacting guard
+  success_criteria:
+  - Ingress mediation runs after the data enters and before it is persisted
+  - An admission/integrity check validates provenance and structure of each inbound record
+  - A cross-domain guard redacts fields not permitted in the high-assurance zone
+  - Records passing the check are admitted in redacted form
+  - Records failing the integrity check are quarantined rather than admitted
+  - Both admissions and quarantines are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: sovereignty_enforced
+    failure_mode: partial_fulfillment
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: ingress admission checks integrity and the guard redacts disallowed fields
+  - domain: data
+    interaction: admitted records are persisted in redacted form; failed records are quarantined
+  - domain: provider
+    interaction: the discovery provider supplies the lower-assurance inbound payload
+  - domain: audit
+    interaction: admissions and quarantines are both recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- policy-firewall
+- ingress-admission
+- integrity
+- redaction-transform
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - Inbound data originates from a lower-assurance source
+  - The sovereign zone forbids certain fields at rest
+  postconditions:
+  - Admitted records are stored redacted
+  - Integrity-failing records are quarantined, yielding partial admission
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/011-reentrant-policy-reconverges-on-injection.yaml b/dav/use-cases/hammer-recent-model/011-reentrant-policy-reconverges-on-injection.yaml
new file mode 100644
index 0000000..980e408
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/011-reentrant-policy-reconverges-on-injection.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-recent-model-011
+handle: recent-model/reentrant-policy-reconverges-on-injection
+scenario:
+  description: "A platform engineer modifies a composite service; an enrichment policy injects a derived\
+    \ tier\n    label, and that injected value is itself an input to a placement policy, which in turn\
+    \ injects an\n    affinity zone that a third policy reads. The evaluator must be re-entrant: each\
+    \ injected/enriched\n    value triggers re-evaluation of the policies that depend on it, iterating\
+    \ until the value set stops\n    changing (a fixpoint). The scenario is well-founded and converges\
+    \ in a few passes. This probes that\n    policy re-converges on mutated inputs and settles deterministically\
+    \ at a fixpoint."
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - provider-owner
+  intent: Re-evaluate policies to a stable fixpoint as each injected value feeds the next policy
+  success_criteria:
+  - An enrichment policy injects a derived tier label into the evaluation state
+  - Policies depending on the injected value are re-evaluated, not left stale
+  - Injection cascades (tier -> placement -> affinity) trigger further re-evaluation
+  - Iteration continues until the value set stops changing (fixpoint reached)
+  - The final decision reflects the converged value set, not an intermediate pass
+  - The number of passes and the converged values are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: policies re-evaluate on each injected value until a fixpoint is reached
+  - domain: data
+    interaction: injected and enriched values are written back into the evaluation state each pass
+  - domain: provider
+    interaction: the converged decision drives placement across the eligible set
+  - domain: audit
+    interaction: the pass count and converged value set are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- reentrant-fixpoint
+- fixpoint
+- reconvergence
+- enrichment
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - Enrichment, placement, and affinity policies form a well-founded dependency chain
+  - The composite service has multiple placeable components
+  postconditions:
+  - The evaluation reached a fixpoint
+  - Placement reflects the converged values
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/012-policy-cycle-detected-nondeterminism-stopped.yaml b/dav/use-cases/hammer-recent-model/012-policy-cycle-detected-nondeterminism-stopped.yaml
new file mode 100644
index 0000000..f42d81b
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/012-policy-cycle-detected-nondeterminism-stopped.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-recent-model-012
+handle: recent-model/policy-cycle-detected-nondeterminism-stopped
+scenario:
+  description: "An SRE change introduces two policies that mutually inject each other's inputs: policy\
+    \ A sets a\n    field that policy B reads and mutates, and B's mutation changes an input A reads,\
+    \ so re-evaluation\n    never settles and the value set oscillates. The re-entrant evaluator must\
+    \ detect the policy loop as a\n    cycle / non-deterministic fixpoint, stop iterating rather than\
+    \ spin, and roll back the in-flight\n    change so no partially converged state is committed. This\
+    \ stresses the loop-guard side of the\n    fixpoint machinery: cycle detection and safe rollback when\
+    \ convergence is impossible."
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - compliance-auditor
+  intent: Detect a non-converging policy cycle and roll back rather than commit oscillating state
+  success_criteria:
+  - Mutual injection between two policies produces an oscillating, non-settling value set
+  - The evaluator detects a policy loop / non-deterministic fixpoint
+  - Iteration is stopped rather than allowed to spin unbounded
+  - The in-flight change is rolled back with no partially converged state committed
+  - The offending policy pair and the oscillating fields are identified
+  - The cycle detection and rollback are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: cross_dependency_payload
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: rollback_required
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the evaluator detects the mutual-injection cycle and stops iterating
+  - domain: data
+    interaction: the oscillating state is discarded and the prior committed state is restored
+  - domain: audit
+    interaction: the cycle, offending policy pair, and rollback are recorded
+  - domain: provider
+    interaction: no provider change is applied because the change was rolled back
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- reentrant-fixpoint
+- cycle-detection
+- nondeterminism
+- loop-guard
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - Two policies mutually inject each other's inputs
+  - The evaluation has a loop guard configured
+  postconditions:
+  - No oscillating state was committed
+  - The entity is restored to its pre-change state
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/013-rehydration-restore-in-place-preserves-uuid.yaml b/dav/use-cases/hammer-recent-model/013-rehydration-restore-in-place-preserves-uuid.yaml
new file mode 100644
index 0000000..61a11a3
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/013-rehydration-restore-in-place-preserves-uuid.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-recent-model-013
+handle: recent-model/rehydration-restore-in-place-preserves-uuid
+scenario:
+  description: "After a recoverable outage the original provider is back online. An SRE rehydrates a composite\n\
+    \    service by restoring in place from its Realized record. Because the original provider is available,\n\
+    \    restore-in-place reuses the Realized state and PRESERVES the same entity UUID, so external references\n\
+    \    keyed on that UUID survive. Sovereignty and tenancy are still re-evaluated under CURRENT policy\
+    \ on\n    rehydration, and here they still pass, so the restore completes cleanly. This probes the\n\
+    \    restore-in-place branch of RHY-005: same provider, same UUID, policy re-checked."
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Restore a service in place from its Realized record, preserving the entity UUID under a current-policy
+    re-check
+  success_criteria:
+  - The original provider is confirmed available before choosing restore-in-place
+  - Restore reuses the Realized record rather than replaying intent from scratch
+  - The restored entity keeps its original UUID
+  - External references keyed on the UUID remain valid after restore
+  - Sovereignty and tenancy are re-evaluated under current policy and pass
+  - The restore path and UUID preservation are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the original provider is available and restores from Realized state
+  - domain: data
+    interaction: the Realized record is reused and the original UUID is preserved
+  - domain: policy
+    interaction: recovery policy re-evaluates sovereignty and tenancy under current rules and passes
+  - domain: audit
+    interaction: the restore-in-place path and UUID preservation are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- rehydration-restore-rebuild
+- rhy-005
+- restore-in-place
+- uuid-preserved
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - A Realized record exists for the service
+  - The original provider is back online
+  postconditions:
+  - The service is restored with its original UUID
+  - Current-policy sovereignty and tenancy checks passed
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/014-rehydration-rebuild-new-uuid-pending-review.yaml b/dav/use-cases/hammer-recent-model/014-rehydration-rebuild-new-uuid-pending-review.yaml
new file mode 100644
index 0000000..eee1215
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/014-rehydration-rebuild-new-uuid-pending-review.yaml
@@ -0,0 +1,69 @@
+uuid: uc-hammer-recent-model-014
+handle: recent-model/rehydration-rebuild-new-uuid-pending-review
+scenario:
+  description: "The original provider that realized a sovereign service is permanently offline, so an\
+    \ SRE must\n    rebuild from intent on a peer DCM. Rebuild-from-intent replays the original intent\
+    \ to create a NEW\n    entity with a NEW UUID (the old Realized record cannot be restored in place).\
+    \ Sovereignty and tenancy\n    are re-evaluated under CURRENT policy, which has tightened since the\
+    \ original request, so the rebuilt\n    entity lands in PENDING_REVIEW rather than auto-completing.\
+    \ This stresses the rebuild branch of\n    RHY-005: new provider, new identity, and a current-policy\
+    \ re-check that gates the outcome."
+  actor:
+    persona: sre
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - provider-owner
+    - federation-peer-operator
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Rebuild a sovereign service from intent on a peer DCM, minting a new UUID and landing in PENDING_REVIEW
+    under tightened policy
+  success_criteria:
+  - The original provider is confirmed permanently offline, forcing rebuild-from-intent
+  - Rebuild replays the original intent rather than restoring the Realized record
+  - The rebuilt entity is created with a NEW UUID, distinct from the original
+  - Sovereignty and tenancy are re-evaluated under current (tightened) policy
+  - The tightened policy places the rebuilt entity in PENDING_REVIEW rather than auto-complete
+  - The rebuild path, new UUID, and PENDING_REVIEW gating are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: peer_dcm_required
+    governance_context: sovereignty_enforced
+    failure_mode: partial_fulfillment
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: a peer DCM rebuilds the service from intent because the original provider is gone
+  - domain: data
+    interaction: a new entity with a new UUID is created; the original Realized record is not reused
+  - domain: policy
+    interaction: current sovereignty policy re-evaluates and routes the rebuild to PENDING_REVIEW
+  - domain: audit
+    interaction: the rebuild path, new UUID, and review gating are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- rehydration-restore-rebuild
+- rhy-005
+- rebuild-from-intent
+- new-uuid
+- pending-review
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - The original provider is permanently offline
+  - Sovereignty policy has tightened since the original request
+  postconditions:
+  - A new entity with a new UUID exists
+  - The rebuilt entity is held in PENDING_REVIEW pending current-policy sign-off
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/015-sbom-cve-blast-radius-reverse-walk.yaml b/dav/use-cases/hammer-recent-model/015-sbom-cve-blast-radius-reverse-walk.yaml
new file mode 100644
index 0000000..29d7e64
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/015-sbom-cve-blast-radius-reverse-walk.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-recent-model-015
+handle: recent-model/sbom-cve-blast-radius-reverse-walk
+scenario:
+  description: "A security officer must find everything exposed to a newly published CVE. Filtering by\
+    \ the\n    Vulnerability Knowledge record for that CVE, the query reverse-walks the reference edges\n\
+    \    package -> image -> container -> host to assemble the blast radius: every SoftwarePackage carrying\n\
+    \    the vulnerable version, every SoftwareImage that includes it, every container running that image,\
+    \ and\n    every host running those containers. The result is a de-duplicated impact set spanning\
+    \ a mixed\n    provider landscape. This probes CVE-driven filtering plus reference-edge reverse-walk\
+    \ for\n    blast-radius across the Knowledge domain."
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Compute the blast radius of a CVE by reverse-walking package -> image -> container -> host reference
+    edges
+  success_criteria:
+  - The query is filtered by the Vulnerability Knowledge record for the CVE
+  - Reverse-walk traverses package -> image -> container -> host reference edges
+  - Every SoftwarePackage carrying the vulnerable version is included
+  - The impact set spans images, containers, and hosts across a mixed provider landscape
+  - The blast-radius set is de-duplicated across overlapping paths
+  - The query, filter, and resulting impact set are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: reference edges are reverse-walked from the Vulnerability to affected packages, images,
+      containers, and hosts
+  - domain: policy
+    interaction: a cross-domain constraint scopes the query to governed, in-boundary resources
+  - domain: audit
+    interaction: the CVE filter and the derived blast-radius set are recorded
+  - domain: provider
+    interaction: provider inventory confirms which hosts currently run the affected containers
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- knowledge-sbom
+- cve-filter
+- blast-radius
+- reverse-walk
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - A Vulnerability Knowledge record exists for the CVE
+  - SoftwarePackage/Image/container/host reference edges are populated
+  postconditions:
+  - A de-duplicated blast-radius impact set is materialized
+  - The impact set spans the mixed provider landscape
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/016-scanner-discovers-knowledge-records-timeout.yaml b/dav/use-cases/hammer-recent-model/016-scanner-discovers-knowledge-records-timeout.yaml
new file mode 100644
index 0000000..68dfde1
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/016-scanner-discovers-knowledge-records-timeout.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-recent-model-016
+handle: recent-model/scanner-discovers-knowledge-records-timeout
+scenario:
+  description: "A platform engineer runs an SBOM scanner as a discovery avenue over the fleet. The scanner\n\
+    \    populates Discovered SoftwareImage, SoftwarePackage, and Vulnerability Knowledge records and\
+    \ the\n    reference edges between them, exactly as any discovery provider populates Discovered state.\
+    \ Partway\n    through the sweep the scanner times out before covering the last rack, so the Knowledge\
+    \ graph is\n    populated for the scanned hosts only and the un-scanned hosts remain without SBOM\
+    \ records. The\n    partial graph must be persisted as valid Discovered Knowledge rather than discarded.\
+    \ This stresses\n    the scanner-as-discovery-avenue path and a timeout that yields a partial Knowledge\
+    \ sweep."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Populate Discovered SBOM Knowledge records via a scanner that times out mid-sweep, keeping the
+    partial graph
+  success_criteria:
+  - The scanner is treated as a discovery avenue populating Discovered Knowledge records
+  - SoftwareImage, SoftwarePackage, and Vulnerability records are created in Discovered state
+  - Reference edges between the Knowledge records are populated
+  - The scanner times out before the last rack and the sweep ends partial
+  - The partial Knowledge graph for scanned hosts is persisted as valid Discovered state
+  - The timeout and the un-scanned host set are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: timeout
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: the scanner discovery avenue emits Discovered SoftwareImage/Package/Vulnerability records
+  - domain: data
+    interaction: the partial Knowledge graph and its edges are persisted as valid Discovered state
+  - domain: audit
+    interaction: the scan timeout and the un-scanned host set are recorded
+  - domain: policy
+    interaction: system defaults admit the Discovered Knowledge records without extra gating
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- knowledge-sbom
+- scanner-discovery
+- knowledge-records
+- partial-sweep
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - An SBOM scanner is registered as a discovery avenue
+  - The scanner has a bounded sweep window
+  postconditions:
+  - Discovered Knowledge records exist for scanned hosts
+  - Un-scanned hosts are flagged as lacking SBOM records
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/017-layer-injection-covers-applies-on-intersection.yaml b/dav/use-cases/hammer-recent-model/017-layer-injection-covers-applies-on-intersection.yaml
new file mode 100644
index 0000000..7117dfa
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/017-layer-injection-covers-applies-on-intersection.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-recent-model-017
+handle: recent-model/layer-injection-covers-applies-on-intersection
+scenario:
+  description: "A platform engineer provisions a composite service; a data layer targets the entity via\
+    \ covers\n    (it covers all Compute.VM in the tenant) and targets the provisioning process via applies_on\
+    \ (it\n    applies on the new_request process). Injection into the request is the INTERSECTION of\
+    \ the two: the\n    layer contributes its values only where an entity it covers meets a process it\
+    \ applies_on. A second\n    layer that covers the entity but applies_on decommission is correctly\
+    \ NOT injected into this\n    new_request. This probes that layer injection is the covers-and-applies_on\
+    \ intersection over the\n    from_layers set."
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - tenancy-authority
+  intent: Inject layer values into a request only where covers (entity) and applies_on (process) intersect
+  success_criteria:
+  - The layer covers the target entity (all Compute.VM in the tenant)
+  - The layer applies_on the new_request process
+  - Injection contributes the layer's values at the covers-and-applies_on intersection
+  - A layer that covers the entity but applies_on decommission is not injected into new_request
+  - The injected value set is attributed to its source layer
+  - The from_layers set and the intersection outcome are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: the covers set and applies_on process are intersected to select contributing layers
+  - domain: policy
+    interaction: the static orchestration flow evaluates the injected layer values in order
+  - domain: provider
+    interaction: the injected values shape placement across the eligible set
+  - domain: audit
+    interaction: the from_layers set and injection intersection are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- layer-injection
+- from-layers
+- covers
+- applies-on
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - A layer covers all Compute.VM in the tenant and applies_on new_request
+  - A second layer covers the entity but applies_on decommission
+  postconditions:
+  - Only the new_request-applicable layer is injected
+  - The injected values are attributed to their source layer
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-recent-model/018-layer-injection-skip-excludes-entity.yaml b/dav/use-cases/hammer-recent-model/018-layer-injection-skip-excludes-entity.yaml
new file mode 100644
index 0000000..d7d45be
--- /dev/null
+++ b/dav/use-cases/hammer-recent-model/018-layer-injection-skip-excludes-entity.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-recent-model-018
+handle: recent-model/layer-injection-skip-excludes-entity
+scenario:
+  description: "A tenant admin modifies a governed workload under a compliance-gated profile. A broad\
+    \ data layer in\n    the from_layers set covers the entire tenant, but this specific workload is listed\
+    \ in the layer's skip\n    set because it is under a separate regulatory hold. Effective injection\
+    \ is from_layers MINUS skip, so\n    the broad layer's values must NOT be injected onto this workload\
+    \ even though covers would otherwise\n    include it. With the broad layer skipped, only a narrower\
+    \ compliant layer contributes, so the workload\n    is modified with a reduced value set. This stresses\
+    \ the skip-subtraction side of layer injection under\n    a governance matrix."
+  actor:
+    persona: tenant-admin
+    profile: fsi
+  perspectives:
+    - tenancy-authority
+    - regulator
+  intent: Exclude a workload from a covering layer via skip, so effective injection is from_layers minus
+    skip
+  success_criteria:
+  - The broad layer covers the workload's tenant via covers
+  - The workload is listed in the broad layer's skip set
+  - Effective injection is computed as from_layers minus skip
+  - The broad layer's values are NOT injected onto the skipped workload
+  - A narrower compliant layer still contributes its values
+  - The skip subtraction and the reduced injected set are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: compliance_gated
+    failure_mode: partial_fulfillment
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: the effective layer set is computed as from_layers minus the skip set
+  - domain: policy
+    interaction: the governance matrix enforces the regulatory hold that drives the skip
+  - domain: provider
+    interaction: the workload is modified with the reduced, compliant value set
+  - domain: audit
+    interaction: the skip subtraction and reduced injected set are recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: recent-model-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- layer-injection
+- from-layers
+- skip
+- exclusion
+- recent-model
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-recent-model
+  preconditions:
+  - A broad layer covers the tenant and lists this workload in skip
+  - The workload is under a separate regulatory hold
+  postconditions:
+  - The broad layer's values were not injected onto the workload
+  - Only the narrower compliant layer contributed values
+  note: batch=recent-model-2026-07-22
diff --git a/dav/use-cases/hammer-sovereignty/001-cross-border-migration-denied.yaml b/dav/use-cases/hammer-sovereignty/001-cross-border-migration-denied.yaml
new file mode 100644
index 0000000..67ca6ed
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/001-cross-border-migration-denied.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-sovereignty-001
+handle: sovereignty/cross-border-migration-denied
+scenario:
+  description: 'A platform engineer requests a live migration of a realized database service from an in-jurisdiction
+    provider to a lower-cost provider region located in a different country. The resource carries a residency
+    constraint pinning its data-at-rest to the original jurisdiction. The placement engine must re-evaluate
+    the sovereignty validation policy against the target provider, detect that the move would relocate
+    data-at-rest across a prohibited border, and deny the migration before any dispatch occurs. The denial
+    and its policy rationale must be recorded, and the resource must remain realized on its original compliant
+    provider.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - sovereignty-authority
+  intent: Migrate a residency-pinned database to a cheaper cross-border region
+  success_criteria:
+  - Migration request is accepted into the pipeline and re-evaluated, not silently applied
+  - Sovereignty policy resolves the target provider's jurisdiction and compares it to the constraint
+  - The cross-border move is denied because data-at-rest would leave the mandated jurisdiction
+  - No provider dispatch or partial migration occurs on the target provider
+  - The original resource stays realized and unchanged on its compliant provider
+  - Denial decision, offending jurisdiction, and policy id are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: provider_failure
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: residency constraint on data-at-rest read from intent state
+  - domain: policy
+    interaction: sovereignty validation compares target provider jurisdiction to the constraint and denies
+  - domain: provider
+    interaction: no dispatch issued; target provider never contacted
+  - domain: audit
+    interaction: cross-border denial recorded with offending jurisdiction and policy id
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- cross-border
+- residency-enforcement
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Database service is realized on a provider inside the mandated jurisdiction
+  - Residency constraint pins data-at-rest to that jurisdiction
+  postconditions:
+  - Migration denied; no target dispatch occurred
+  - Resource remains realized on the original compliant provider
+  - Audit trail records the denial and rationale
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/002-data-at-rest-named-jurisdiction.yaml b/dav/use-cases/hammer-sovereignty/002-data-at-rest-named-jurisdiction.yaml
new file mode 100644
index 0000000..c13211b
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/002-data-at-rest-named-jurisdiction.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-sovereignty-002
+handle: sovereignty/data-at-rest-named-jurisdiction
+scenario:
+  description: 'A tenant admin submits a new request for an object-storage bucket that must keep all data-at-rest
+    within a specifically named jurisdiction dictated by a sovereign mandate. The request carries the
+    jurisdiction as a hard residency attribute. The placement engine must select only a provider whose
+    declared data-at-rest jurisdiction matches the named mandate, realize the bucket there, and stamp
+    the realized record with the jurisdiction it was placed in. This is the baseline sovereign-placement
+    happy path that everything else builds on.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Provision storage whose data-at-rest stays in one named jurisdiction
+  success_criteria:
+  - Request is accepted with the named jurisdiction as a hard residency attribute
+  - Sovereignty policy filters candidate providers to those matching the named jurisdiction
+  - The bucket is realized only on a provider whose data-at-rest jurisdiction matches
+  - The realized record records the concrete jurisdiction of placement
+  - Placement decision and the satisfied mandate are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: named jurisdiction stored as a hard residency attribute on intent
+  - domain: policy
+    interaction: sovereignty validation filters providers to the matching jurisdiction
+  - domain: provider
+    interaction: compliant provider realizes the bucket and returns its jurisdiction
+  - domain: audit
+    interaction: placement and satisfied mandate recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- data-residency
+- placement
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - At least one provider declares data-at-rest in the named jurisdiction
+  - Sovereign mandate names a single required jurisdiction
+  postconditions:
+  - Bucket realized in the named jurisdiction
+  - Realized record stamped with the placement jurisdiction
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/003-provider-jurisdiction-falls-out-of-compliance.yaml b/dav/use-cases/hammer-sovereignty/003-provider-jurisdiction-falls-out-of-compliance.yaml
new file mode 100644
index 0000000..68be543
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/003-provider-jurisdiction-falls-out-of-compliance.yaml
@@ -0,0 +1,71 @@
+uuid: uc-hammer-sovereignty-003
+handle: sovereignty/provider-jurisdiction-falls-out-of-compliance
+scenario:
+  description: 'A compliance auditor''s monitoring detects that a provider currently hosting residency-pinned
+    workloads has had its jurisdiction re-classified mid-operation — a legal change places its region
+    under a foreign-access regime that violates the sovereign mandate the workloads were placed under.
+    Nothing about the intent changed, but the provider''s compliance posture did. The architecture must
+    detect this as drift against the sovereignty policy, flag the affected realized resources, and trigger
+    a recovery policy that quarantines new dispatch and proposes remediation (re-placement to a still-compliant
+    provider) rather than leaving the resources silently non-compliant. This case probes whether the model
+    can react to provider-side compliance changes it did not originate.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - sovereignty-authority
+  intent: Re-evaluate placements when a provider's jurisdiction loses compliance mid-operation
+  success_criteria:
+  - The provider compliance change is ingested as a signal against the data model
+  - Sovereignty policy is re-evaluated for every resource realized on that provider
+  - Affected realized resources are flagged as drifted from their sovereign mandate
+  - A recovery policy quarantines further dispatch to the now-non-compliant provider
+  - Remediation (re-placement to a compliant provider) is proposed, not silently executed
+  - The compliance-loss event and affected resource set are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: provider_failure
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: provider jurisdiction re-classification ingested as a compliance signal
+  - domain: policy
+    interaction: sovereignty policy re-evaluated; recovery policy quarantines dispatch and proposes re-placement
+  - domain: data
+    interaction: affected realized resources flagged as drifted from mandate
+  - domain: audit
+    interaction: compliance-loss event and affected resource set recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- provider-compliance-drift
+- recovery
+- edge
+- likely-unsupported
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resources are realized on a provider that was compliant at placement time
+  - The provider's jurisdiction is later re-classified as non-compliant
+  postconditions:
+  - Affected resources flagged as drifted
+  - Dispatch to the non-compliant provider quarantined
+  - Remediation proposed and recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/004-sub-processor-disclosure-requirement.yaml b/dav/use-cases/hammer-sovereignty/004-sub-processor-disclosure-requirement.yaml
new file mode 100644
index 0000000..3c8110d
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/004-sub-processor-disclosure-requirement.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-sovereignty-004
+handle: sovereignty/sub-processor-disclosure-requirement
+scenario:
+  description: 'A security officer provisions a composite analytics service under a sovereign mandate
+    that requires full disclosure of every sub-processor touching the data — not just the primary provider,
+    but any downstream provider it delegates storage, key management, or compute to. The placement engine
+    must resolve the primary provider''s declared sub-processor chain, evaluate each sub-processor''s
+    jurisdiction against the mandate, and admit the service only if the entire chain is disclosed and
+    compliant. An undisclosed or non-compliant sub-processor anywhere in the chain must block admission.
+    This probes whether the model reasons about transitive provider delegation, not just the provider
+    it dispatches to directly.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+  intent: Provision a service only if its full sub-processor chain is disclosed and compliant
+  success_criteria:
+  - The primary provider's declared sub-processor chain is resolved from the provider model
+  - Every sub-processor's jurisdiction is evaluated against the sovereign mandate
+  - Admission proceeds only when the entire chain is disclosed and compliant
+  - An undisclosed or non-compliant sub-processor anywhere in the chain blocks admission
+  - The evaluated sub-processor chain is recorded with each member's jurisdiction
+  - The disclosure evaluation and its verdict are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: primary provider's sub-processor chain resolved transitively
+  - domain: policy
+    interaction: multi-policy chain evaluates each sub-processor's jurisdiction against the mandate
+  - domain: data
+    interaction: evaluated chain and per-member jurisdictions recorded on the resource
+  - domain: audit
+    interaction: sub-processor disclosure evaluation and verdict recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- sub-processor
+- transitive-disclosure
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Primary provider declares a sub-processor chain in the provider model
+  - Sovereign mandate requires full sub-processor disclosure and compliance
+  postconditions:
+  - Service admitted only if the full chain is disclosed and compliant
+  - Evaluated chain recorded with per-member jurisdictions
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/005-government-access-risk-gating-placement.yaml b/dav/use-cases/hammer-sovereignty/005-government-access-risk-gating-placement.yaml
new file mode 100644
index 0000000..a117f23
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/005-government-access-risk-gating-placement.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-sovereignty-005
+handle: sovereignty/government-access-risk-gating-placement
+scenario:
+  description: 'A security officer requests placement of a regulated dataset. Two providers can technically
+    host it and both keep data-at-rest in the correct jurisdiction, but one is subject to a foreign government-access
+    regime (a lawful-access statute reaching data held by that provider''s parent). The sovereign mandate
+    treats government-access risk as a first-class placement gate, not just physical residency. The placement
+    engine must score each eligible provider on government-access exposure and exclude the exposed provider
+    even though it satisfies physical residency, selecting only the provider with acceptable access risk.
+    This probes whether the model can gate on legal-reach risk distinct from geographic data-at-rest.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+  intent: Place a regulated dataset only on a provider with acceptable government-access risk
+  success_criteria:
+  - Both candidate providers pass the physical data-at-rest residency check
+  - Sovereignty policy additionally evaluates government-access exposure per provider
+  - The provider under a foreign lawful-access regime is excluded despite passing residency
+  - The dataset is realized only on the provider with acceptable access risk
+  - The access-risk rationale for exclusion is recorded distinctly from residency
+  - Placement decision and access-risk scoring recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty gate scores government-access exposure separately from residency
+  - domain: provider
+    interaction: provider legal-reach attributes read; exposed provider excluded from candidates
+  - domain: data
+    interaction: access-risk rationale recorded on the placement decision
+  - domain: audit
+    interaction: access-risk scoring and exclusion recorded distinctly from residency
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- government-access-risk
+- placement-gate
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Two providers satisfy physical data-at-rest residency
+  - One provider is subject to a foreign lawful-access regime
+  postconditions:
+  - Dataset realized only on the acceptable-risk provider
+  - Access-risk exclusion recorded separately from residency
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/006-air-gapped-offline-sovereign-deployment.yaml b/dav/use-cases/hammer-sovereignty/006-air-gapped-offline-sovereign-deployment.yaml
new file mode 100644
index 0000000..cd699c8
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/006-air-gapped-offline-sovereign-deployment.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-sovereignty-006
+handle: sovereignty/air-gapped-offline-sovereign-deployment
+scenario:
+  description: 'A platform engineer must stand up a full-stack sovereign environment inside an air-gapped
+    enclave that has no connectivity to any external control plane, registry, or peer DCM. The sovereign
+    mandate forbids any control-plane or telemetry egress from the enclave. The architecture must drive
+    the entire pipeline — intent, policy evaluation, placement, and realization — using only in-enclave
+    providers and a static orchestration flow, with no calls to outside services and no dependence on
+    a reachable peer DCM. This probes whether the model can operate fully disconnected, and whether any
+    step implicitly assumes external reachability.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Deploy a full sovereign stack entirely within an offline air-gapped enclave
+  success_criteria:
+  - The full stack is realized using only providers resident inside the air-gapped enclave
+  - Policy evaluation and placement complete with no external control-plane calls
+  - No telemetry, registry, or control-plane egress leaves the enclave at any step
+  - Orchestration proceeds via a static in-enclave flow with no peer DCM dependency
+  - The disconnected realization arc is recorded in an in-enclave audit trail
+  - No pipeline step blocks waiting on an unreachable external service
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: peer_dcm_disconnect
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: only in-enclave providers realize the stack; no external calls
+  - domain: policy
+    interaction: static orchestration flow evaluates policy without external reachability
+  - domain: data
+    interaction: intent and four-state stores kept entirely inside the enclave
+  - domain: audit
+    interaction: disconnected realization recorded in an in-enclave trail
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- air-gapped
+- offline
+- disconnected
+- edge
+- likely-unsupported
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Enclave has no connectivity to external control planes, registries, or peer DCMs
+  - In-enclave providers can satisfy the full stack
+  postconditions:
+  - Full stack realized with zero external egress
+  - Audit trail retained inside the enclave
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/007-residency-conflict-during-rehydration.yaml b/dav/use-cases/hammer-sovereignty/007-residency-conflict-during-rehydration.yaml
new file mode 100644
index 0000000..7fefc66
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/007-residency-conflict-during-rehydration.yaml
@@ -0,0 +1,70 @@
+uuid: uc-hammer-sovereignty-007
+handle: sovereignty/residency-conflict-during-rehydration
+scenario:
+  description: 'Following a disaster, an SRE rehydrates a full environment to a new set of providers because
+    the original providers are gone. The stored intent pins several resources to a named jurisdiction,
+    but the only providers available in the recovery region cannot satisfy that residency constraint.
+    The architecture must, during provider-portable rehydration, re-evaluate the sovereignty policy against
+    the new provider landscape, detect the residency conflict, and refuse to re-realize the conflicting
+    resources on a non-compliant provider — surfacing the conflict as a blocked rehydration rather than
+    silently relaxing residency to complete recovery. This probes the tension between availability (finish
+    the rebuild) and sovereignty (never violate residency) during DR.
+
+    '
+  actor:
+    persona: sre
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - provider-owner
+    - sovereignty-authority
+  intent: Rehydrate to new providers without violating pinned residency constraints
+  success_criteria:
+  - Rehydration derives a rebuild plan from stored intent including residency constraints
+  - Sovereignty policy is re-evaluated against the new recovery-region provider landscape
+  - The residency conflict is detected before any conflicting resource is realized
+  - Conflicting resources are NOT re-realized on a non-compliant provider to force completion
+  - Compliant resources still rehydrate; the blocked set is surfaced explicitly
+  - The residency conflict, blocked resources, and unmet jurisdictions are recorded
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: sovereignty_enforced
+    failure_mode: provider_failure
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: stored intent with residency constraints read for the rebuild plan
+  - domain: policy
+    interaction: sovereignty re-evaluated against new providers; conflict blocks non-compliant re-realization
+  - domain: provider
+    interaction: compliant resources realized; no dispatch for the conflicting set
+  - domain: audit
+    interaction: residency conflict and blocked resource set recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- rehydration
+- residency-conflict
+- disaster-recovery
+- edge
+- likely-unsupported
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Original providers are destroyed; recovery region lacks a compliant provider for some resources
+  - Stored intent pins those resources to a named jurisdiction
+  postconditions:
+  - Compliant resources rehydrated; conflicting resources blocked, not forced
+  - Residency conflict surfaced and recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/008-per-tenant-sovereign-profile-standard-platform.yaml b/dav/use-cases/hammer-sovereignty/008-per-tenant-sovereign-profile-standard-platform.yaml
new file mode 100644
index 0000000..be553e4
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/008-per-tenant-sovereign-profile-standard-platform.yaml
@@ -0,0 +1,69 @@
+uuid: uc-hammer-sovereignty-008
+handle: sovereignty/per-tenant-sovereign-profile-standard-platform
+scenario:
+  description: 'A standard multi-tenant platform hosts mostly commercial tenants under the standard profile,
+    but one tenant is bound to a sovereign profile that mandates in-jurisdiction data-at-rest and disclosed
+    sub-processors. A tenant admin for the sovereign tenant provisions a composite service on the shared
+    platform. The architecture must apply the sovereign tenant''s governance matrix to that tenant''s
+    request only — enforcing residency and disclosure for it — while leaving other tenants on standard
+    governance, all on the same platform. This probes whether per-tenant sovereign profiles compose correctly
+    inside an otherwise-standard platform without leaking the strict policy onto other tenants or relaxing
+    it for the sovereign one.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: sovereign
+  perspectives:
+    - security-officer
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Enforce a sovereign profile for one tenant inside a standard shared platform
+  success_criteria:
+  - The sovereign tenant's request is evaluated under its sovereign governance matrix
+  - Residency and sub-processor-disclosure policies apply to the sovereign tenant's resources
+  - Other tenants on the same platform remain under standard governance, unaffected
+  - The sovereign tenant's service is realized only on providers satisfying its mandate
+  - No sovereign policy is applied to non-sovereign tenants (no strictness leak)
+  - The per-tenant profile resolution and applied matrix are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: per-tenant governance matrix resolved; sovereign policies applied only to the sovereign
+      tenant
+  - domain: provider
+    interaction: sovereign tenant's service placed only on mandate-satisfying providers
+  - domain: data
+    interaction: tenant-to-profile binding and applied matrix read from the model
+  - domain: audit
+    interaction: per-tenant profile resolution and enforcement recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- per-tenant-profile
+- multi-tenancy
+- governance-matrix
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Platform hosts standard tenants plus one sovereign-profile tenant
+  - Sovereign tenant is bound to a residency + disclosure mandate
+  postconditions:
+  - Sovereign tenant's resources enforced under its mandate
+  - Other tenants unaffected by the sovereign policy
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/009-enforcement-plane-attestation-data-vs-control.yaml b/dav/use-cases/hammer-sovereignty/009-enforcement-plane-attestation-data-vs-control.yaml
new file mode 100644
index 0000000..fd35077
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/009-enforcement-plane-attestation-data-vs-control.yaml
@@ -0,0 +1,70 @@
+uuid: uc-hammer-sovereignty-009
+handle: sovereignty/enforcement-plane-attestation-data-vs-control
+scenario:
+  description: 'A security officer provisions a service under a sovereign mandate that distinguishes the
+    data plane from the control plane: the data-at-rest must reside in-jurisdiction AND the control plane
+    operating that data (the management endpoints, orchestration, and operators able to act on it) must
+    also be in-jurisdiction. A candidate provider keeps data in-jurisdiction but is operated from a control
+    plane in another country. The architecture must require attestation for both planes, evaluate them
+    independently, and refuse a provider that satisfies data-plane residency but fails control-plane residency.
+    This probes whether the model treats sovereignty as a per-plane property with independent attestation,
+    rather than a single data-location flag.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Require in-jurisdiction attestation for both the data plane and the control plane
+  success_criteria:
+  - The mandate is expressed as separate data-plane and control-plane residency requirements
+  - Sovereignty policy requires an attestation for each plane independently
+  - A provider passing data-plane residency but failing control-plane residency is rejected
+  - The service is realized only on a provider attesting both planes in-jurisdiction
+  - The per-plane attestation results are recorded distinctly, not collapsed to one flag
+  - The rejection rationale names the failing plane in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty policy evaluates data-plane and control-plane attestations independently
+  - domain: provider
+    interaction: per-plane attestations read; provider failing control-plane residency rejected
+  - domain: data
+    interaction: per-plane attestation results recorded distinctly on the resource
+  - domain: audit
+    interaction: rejection recorded naming the failing plane
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- enforcement-plane
+- attestation
+- data-vs-control
+- edge
+- likely-unsupported
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Mandate requires both data-plane and control-plane in-jurisdiction
+  - A candidate provider is data-plane compliant but control-plane foreign
+  postconditions:
+  - Service realized only on a both-planes-attested provider
+  - Per-plane attestation results recorded distinctly
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/010-certification-expiry-triggers-reevaluation.yaml b/dav/use-cases/hammer-sovereignty/010-certification-expiry-triggers-reevaluation.yaml
new file mode 100644
index 0000000..4f4475f
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/010-certification-expiry-triggers-reevaluation.yaml
@@ -0,0 +1,70 @@
+uuid: uc-hammer-sovereignty-010
+handle: sovereignty/certification-expiry-triggers-reevaluation
+scenario:
+  description: 'A provider hosting residency-pinned workloads holds a sovereign certification (the compliance
+    credential the placement originally relied on) that reaches its expiry date. No intent changed, but
+    the credential the placement depended on is no longer valid. A compliance auditor expects the architecture
+    to treat certification expiry as a drift signal: detect that a still-realized resource now sits on
+    a provider whose certification has lapsed, re-evaluate the sovereignty policy, and trigger a recovery
+    policy that flags the resource and requires re-attestation or re-placement before the provider is
+    considered compliant again. This probes whether the model treats provider certifications as time-bounded
+    facts that must be re-checked, not one-time admission gates.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - security-officer
+    - sovereignty-authority
+  intent: Re-evaluate placements when a provider's sovereign certification expires
+  success_criteria:
+  - Certification expiry is ingested as a drift signal against realized resources
+  - The set of resources placed under the expired certification is identified
+  - Sovereignty policy is re-evaluated for those resources on expiry
+  - A recovery policy flags the affected resources as pending re-attestation or re-placement
+  - The provider is not treated as compliant again until re-attestation succeeds
+  - The expiry event, affected resources, and required action are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: certification expiry read as a time-bounded compliance fact
+  - domain: policy
+    interaction: sovereignty re-evaluated on expiry; recovery policy requires re-attestation or re-placement
+  - domain: data
+    interaction: affected resources flagged pending re-attestation
+  - domain: audit
+    interaction: expiry event, affected resources, and required action recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- certification-expiry
+- re-evaluation
+- recovery
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resources are realized on a provider under a now-expired sovereign certification
+  - Intent is unchanged
+  postconditions:
+  - Affected resources flagged pending re-attestation or re-placement
+  - Provider not treated compliant until re-attested
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/011-residency-tag-validation-single-vm.yaml b/dav/use-cases/hammer-sovereignty/011-residency-tag-validation-single-vm.yaml
new file mode 100644
index 0000000..92ab11e
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/011-residency-tag-validation-single-vm.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-sovereignty-011
+handle: sovereignty/residency-tag-validation-single-vm
+scenario:
+  description: 'An application team member requests a single virtual machine with no dependencies, tagged
+    with a required residency jurisdiction from a sovereign mandate. The system must validate that the
+    residency tag is well-formed and resolvable against a known jurisdiction, place the VM on a provider
+    in that jurisdiction, and stamp the realized record with where it landed. This is the simplest sovereign
+    case — one resource, one residency tag, one validation — and establishes that a bare residency attribute
+    is honored end to end.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: sovereign
+  perspectives:
+    - sovereignty-authority
+  intent: Provision one residency-tagged VM in the correct jurisdiction
+  success_criteria:
+  - The residency tag is validated as well-formed and resolvable to a known jurisdiction
+  - Placement selects a provider in the tagged jurisdiction
+  - The VM is realized on that provider
+  - The realized record is stamped with the jurisdiction it was placed in
+  - The residency validation and placement are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: residency tag stored and validated against known jurisdictions
+  - domain: policy
+    interaction: single residency validation confirms the tag before placement
+  - domain: provider
+    interaction: provider in the tagged jurisdiction realizes the VM
+  - domain: audit
+    interaction: residency validation and placement recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- residency-tag
+- validation
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A provider exists in the tagged jurisdiction
+  - The residency tag resolves to a known jurisdiction
+  postconditions:
+  - VM realized in the tagged jurisdiction
+  - Realized record stamped with the placement jurisdiction
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/012-sovereign-region-placement-happy-path.yaml b/dav/use-cases/hammer-sovereignty/012-sovereign-region-placement-happy-path.yaml
new file mode 100644
index 0000000..d125294
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/012-sovereign-region-placement-happy-path.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-sovereignty-012
+handle: sovereignty/sovereign-region-placement-happy-path
+scenario:
+  description: 'A platform engineer requests a compute instance that must land in a designated sovereign
+    region where exactly one eligible provider operates. The sovereignty policy is a straightforward single
+    validation: the request''s required region must match the provider''s declared sovereign region. The
+    system evaluates the policy, finds the one eligible provider, realizes the instance there, and records
+    the satisfied constraint. This is the clean single-provider sovereign happy path used as a baseline
+    against the harder edge cases.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - sovereignty-authority
+  intent: Place a compute instance in a designated sovereign region
+  success_criteria:
+  - The required sovereign region is read from the request
+  - Sovereignty validation matches the region to the single eligible provider
+  - The instance is realized on that provider
+  - The satisfied sovereign-region constraint is recorded on the realized resource
+  - The placement decision is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: single sovereignty validation matches required region to the eligible provider
+  - domain: provider
+    interaction: the one eligible provider realizes the instance
+  - domain: data
+    interaction: satisfied sovereign-region constraint recorded on the resource
+  - domain: audit
+    interaction: placement decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- sovereign-region
+- placement
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Exactly one provider operates in the designated sovereign region
+  postconditions:
+  - Instance realized in the sovereign region
+  - Satisfied constraint recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/013-reject-request-no-compliant-provider.yaml b/dav/use-cases/hammer-sovereignty/013-reject-request-no-compliant-provider.yaml
new file mode 100644
index 0000000..9fc8dac
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/013-reject-request-no-compliant-provider.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-sovereignty-013
+handle: sovereignty/reject-request-no-compliant-provider
+scenario:
+  description: 'A tenant admin requests a resource pinned to a sovereign jurisdiction for which no eligible
+    provider exists in the catalog. Rather than falling back to the nearest available provider or queuing
+    the request indefinitely without explanation, the architecture must evaluate the sovereignty policy,
+    find zero compliant providers, and reject the request with a clear unsatisfiable-residency reason.
+    Nothing is realized. This is a deliberately simple negative case that checks the model fails closed
+    — no compliant provider means no placement, not a relaxed one.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Provision in a jurisdiction with no compliant provider
+  success_criteria:
+  - Sovereignty policy filters the provider catalog by the required jurisdiction
+  - The filter yields zero compliant providers
+  - The request is rejected with an unsatisfiable-residency reason
+  - No resource is realized and no non-compliant fallback is used
+  - The rejection and the unmet jurisdiction are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: provider_failure
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty validation finds zero compliant providers and rejects
+  - domain: provider
+    interaction: no provider is dispatched; no fallback used
+  - domain: data
+    interaction: request left unrealized; unmet jurisdiction recorded
+  - domain: audit
+    interaction: rejection and unsatisfiable residency recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- fail-closed
+- no-compliant-provider
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - No provider in the catalog satisfies the required jurisdiction
+  postconditions:
+  - Request rejected; nothing realized
+  - Unmet jurisdiction recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/014-data-residency-label-drift.yaml b/dav/use-cases/hammer-sovereignty/014-data-residency-label-drift.yaml
new file mode 100644
index 0000000..37600bc
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/014-data-residency-label-drift.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-sovereignty-014
+handle: sovereignty/data-residency-label-drift
+scenario:
+  description: 'An SRE''s drift check finds that a realized resource''s actual data-at-rest location,
+    as reported by the provider, no longer matches the jurisdiction recorded in its intent — the provider
+    moved the data to a different region during a maintenance event. The intent still says one jurisdiction;
+    the realized fact now says another. The architecture must detect this divergence between recorded
+    intent and reported realized state, flag it as a sovereignty drift (not a benign difference), and
+    surface it for remediation. This probes whether residency is continuously reconciled against provider-reported
+    reality, not just checked at placement.
+
+    '
+  actor:
+    persona: sre
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - provider-owner
+    - sovereignty-authority
+  intent: Detect when a resource's actual data-at-rest drifts out of its mandated jurisdiction
+  success_criteria:
+  - Provider-reported data-at-rest location is compared against the recorded intent jurisdiction
+  - A divergence between intent jurisdiction and realized location is detected
+  - The divergence is classified as a sovereignty drift, not a benign difference
+  - The drifted resource is flagged for remediation with both jurisdictions shown
+  - The drift event and the mismatched locations are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: recorded intent jurisdiction compared against provider-reported realized location
+  - domain: policy
+    interaction: sovereignty validation classifies the divergence as drift
+  - domain: provider
+    interaction: provider-reported data-at-rest location read for reconciliation
+  - domain: audit
+    interaction: drift event and mismatched jurisdictions recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- residency-drift
+- reconciliation
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource was placed in the mandated jurisdiction
+  - Provider later reports data-at-rest in a different region
+  postconditions:
+  - Divergence flagged as sovereignty drift
+  - Both jurisdictions recorded for remediation
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/015-sovereign-decommission-in-jurisdiction-destruction.yaml b/dav/use-cases/hammer-sovereignty/015-sovereign-decommission-in-jurisdiction-destruction.yaml
new file mode 100644
index 0000000..086e08e
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/015-sovereign-decommission-in-jurisdiction-destruction.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-sovereignty-015
+handle: sovereignty/sovereign-decommission-in-jurisdiction-destruction
+scenario:
+  description: 'A compliance auditor decommissions a resource that was placed under a sovereign mandate.
+    The mandate requires that data destruction happen within the mandated jurisdiction and that a destruction
+    attestation be produced as proof. The architecture must, on decommission, drive the provider to destroy
+    the data in-jurisdiction, obtain the destruction attestation, and only then consider the resource
+    decommissioned — recording the attestation. A decommission that tears down the resource without an
+    in-jurisdiction destruction attestation must not be treated as complete. This probes whether sovereignty
+    obligations extend through the end of the lifecycle, not just placement.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+    - sovereignty-authority
+  intent: Decommission a resource with proof of in-jurisdiction data destruction
+  success_criteria:
+  - Decommission triggers provider-side data destruction within the mandated jurisdiction
+  - A destruction attestation is obtained from the provider
+  - The resource is marked decommissioned only after the attestation is received
+  - A decommission lacking an in-jurisdiction destruction attestation is not treated as complete
+  - The destruction attestation and its jurisdiction are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: provider destroys data in-jurisdiction and returns a destruction attestation
+  - domain: policy
+    interaction: decommission policy requires the in-jurisdiction attestation before completion
+  - domain: data
+    interaction: resource marked decommissioned only after attestation is recorded
+  - domain: audit
+    interaction: destruction attestation and jurisdiction recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- decommission
+- data-destruction
+- attestation
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Resource was placed under a sovereign mandate requiring in-jurisdiction destruction
+  postconditions:
+  - Resource decommissioned only after in-jurisdiction destruction attestation
+  - Attestation recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/016-cross-tenant-residency-isolation.yaml b/dav/use-cases/hammer-sovereignty/016-cross-tenant-residency-isolation.yaml
new file mode 100644
index 0000000..94bcb39
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/016-cross-tenant-residency-isolation.yaml
@@ -0,0 +1,69 @@
+uuid: uc-hammer-sovereignty-016
+handle: sovereignty/cross-tenant-residency-isolation
+scenario:
+  description: 'On a shared sovereign platform, a tenant admin modifies a service to add a shared cache
+    tier. The requested cache would be backed by a pooled resource that also serves a tenant bound to
+    a different, stricter jurisdiction — creating a path where one tenant''s residency-constrained data
+    could co-reside with another''s under a jurisdiction that violates one of the two mandates. The architecture
+    must evaluate the governance matrix across both tenants'' residency constraints, detect the cross-tenant
+    residency conflict in the shared backing resource, and refuse the modification that would co-mingle
+    data across incompatible jurisdictions. This probes whether sovereignty is enforced at shared-resource
+    boundaries, not just per-tenant in isolation.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Add a shared tier without co-mingling data across incompatible jurisdictions
+  success_criteria:
+  - The shared backing resource's existing tenant residency constraints are resolved
+  - The governance matrix is evaluated across both tenants' jurisdictions
+  - A cross-tenant residency conflict on the shared resource is detected
+  - The modification that would co-mingle incompatible jurisdictions is refused
+  - No shared backing is provisioned that violates either tenant's mandate
+  - The conflict, the two jurisdictions, and the refusal are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: existing tenant residency constraints on the shared resource resolved
+  - domain: policy
+    interaction: governance matrix detects incompatible-jurisdiction co-mingling and refuses
+  - domain: provider
+    interaction: no shared backing provisioned that violates either mandate
+  - domain: audit
+    interaction: cross-tenant conflict and refusal recorded with both jurisdictions
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- cross-tenant
+- residency-isolation
+- governance-matrix
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A shared backing resource serves tenants under different jurisdictions
+  - The requested tier would co-mingle data across those jurisdictions
+  postconditions:
+  - Modification refused; no incompatible co-mingling provisioned
+  - Cross-tenant conflict recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/017-peer-dcm-federation-residency-boundary.yaml b/dav/use-cases/hammer-sovereignty/017-peer-dcm-federation-residency-boundary.yaml
new file mode 100644
index 0000000..cd60525
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/017-peer-dcm-federation-residency-boundary.yaml
@@ -0,0 +1,71 @@
+uuid: uc-hammer-sovereignty-017
+handle: sovereignty/peer-dcm-federation-residency-boundary
+scenario:
+  description: 'A platform engineer submits a request whose capacity can only be satisfied by delegating
+    placement to a peer DCM in another domain via federation. The resource, however, carries a sovereign
+    residency constraint, and the peer DCM operates in a jurisdiction that would violate the mandate.
+    The architecture must recognize that although federation to the peer is the only path to capacity,
+    the sovereignty constraint forbids delegating this resource across the residency boundary — and must
+    refuse the cross-domain delegation rather than hand the residency obligation to a peer that cannot
+    honor it. This probes whether sovereignty constraints are preserved across federation boundaries and
+    whether a peer''s jurisdiction is checked before delegation.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - federation-peer-operator
+    - sovereignty-authority
+  intent: Satisfy capacity via a peer DCM without crossing a residency boundary
+  success_criteria:
+  - The request is identified as satisfiable only by delegating to a peer DCM
+  - The peer DCM's operating jurisdiction is evaluated against the residency constraint
+  - The cross-domain delegation is refused because the peer cannot honor the mandate
+  - The residency obligation is not handed off to a non-compliant peer
+  - The request is surfaced as blocked-by-residency rather than silently delegated
+  - The blocked delegation, peer jurisdiction, and mandate are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    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 constraint evaluated against the peer DCM's jurisdiction before delegation
+  - domain: provider
+    interaction: peer DCM's jurisdiction resolved; cross-domain delegation refused
+  - domain: data
+    interaction: request left blocked; residency obligation retained, not delegated
+  - domain: audit
+    interaction: blocked delegation and peer jurisdiction recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- federation
+- peer-dcm
+- residency-boundary
+- edge
+- likely-unsupported
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Only a peer DCM can satisfy the capacity
+  - The peer's jurisdiction violates the residency constraint
+  postconditions:
+  - Cross-domain delegation refused
+  - Request blocked-by-residency and recorded
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/018-sovereign-backup-replica-residency.yaml b/dav/use-cases/hammer-sovereignty/018-sovereign-backup-replica-residency.yaml
new file mode 100644
index 0000000..c5f0eb8
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/018-sovereign-backup-replica-residency.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-sovereignty-018
+handle: sovereignty/sovereign-backup-replica-residency
+scenario:
+  description: 'A platform engineer provisions a database with a DR requirement: it needs backups and
+    a standby replica. The sovereign mandate requires that not only the primary but every backup and replica
+    keep data-at-rest within the mandated jurisdiction. The architecture must apply the residency constraint
+    to the derived backup and replica resources, not just the primary — placing the standby replica and
+    backup targets on in-jurisdiction providers. A DR topology that would land a replica or backup out
+    of jurisdiction must be rejected. This probes whether residency propagates to dependent DR resources
+    rather than applying only to the primary.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - sovereignty-authority
+  intent: Ensure primary, replica, and backups all stay in the mandated jurisdiction
+  success_criteria:
+  - The residency constraint is propagated to the derived backup and replica resources
+  - The primary, standby replica, and backup targets are all placed in-jurisdiction
+  - A DR topology that would place any replica or backup out of jurisdiction is rejected
+  - Each derived resource's realized record is stamped with its jurisdiction
+  - The propagation of residency to derived resources is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: residency validation applied to primary and to derived backup and replica resources
+  - domain: provider
+    interaction: primary, replica, and backup targets realized on in-jurisdiction providers
+  - domain: data
+    interaction: residency propagated to derived resources; each stamped with its jurisdiction
+  - domain: audit
+    interaction: residency propagation and per-resource placement recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- backup-replica
+- disaster-recovery
+- residency-propagation
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Database requires backups and a standby replica
+  - Sovereign mandate applies to all copies of data-at-rest
+  postconditions:
+  - Primary, replica, and backups all in-jurisdiction
+  - Out-of-jurisdiction DR topology rejected
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/019-brownfield-ingest-unknown-residency.yaml b/dav/use-cases/hammer-sovereignty/019-brownfield-ingest-unknown-residency.yaml
new file mode 100644
index 0000000..70c5348
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/019-brownfield-ingest-unknown-residency.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-sovereignty-019
+handle: sovereignty/brownfield-ingest-unknown-residency
+scenario:
+  description: 'A brownfield estate is ingested into the model, and one discovered resource has no reliable
+    residency information — the provider region is ambiguous and no jurisdiction can be confidently resolved.
+    The platform is under a sovereignty-enforced profile. The architecture must not silently assume the
+    resource is compliant, nor silently mark it non-compliant; it must ingest the resource, flag its residency
+    as unknown/unverified, and gate it as pending-attestation so it is neither trusted as sovereign nor
+    lost. This probes how the model handles the common brownfield reality of incomplete residency metadata
+    under a strict profile — and whether "unknown" is a first-class state distinct from compliant and
+    non-compliant.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Ingest a brownfield resource whose residency cannot be resolved
+  success_criteria:
+  - The resource is ingested into the model despite missing residency metadata
+  - Residency is recorded as unknown/unverified, not defaulted to compliant or non-compliant
+  - The resource is gated as pending-attestation rather than trusted as sovereign
+  - The resource is not dropped or lost from the estate
+  - Downstream operations on the resource are blocked until residency is attested
+  - The unknown-residency state and the gate are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: composite_service
+    policy_complexity: single_validation
+    provider_landscape: mixed
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: resource ingested with residency recorded as unknown/unverified
+  - domain: policy
+    interaction: sovereignty validation gates the resource as pending-attestation
+  - domain: provider
+    interaction: ambiguous provider region cannot resolve a jurisdiction
+  - domain: audit
+    interaction: unknown-residency state and gate recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- brownfield
+- unknown-residency
+- pending-attestation
+- edge
+- likely-unsupported
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - A discovered brownfield resource has ambiguous, unresolvable residency
+  - The platform is under a sovereignty-enforced profile
+  postconditions:
+  - Resource ingested and gated as pending-attestation
+  - Unknown-residency treated as a first-class state
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-sovereignty/020-encryption-key-residency-sovereign-kms.yaml b/dav/use-cases/hammer-sovereignty/020-encryption-key-residency-sovereign-kms.yaml
new file mode 100644
index 0000000..ab1cc04
--- /dev/null
+++ b/dav/use-cases/hammer-sovereignty/020-encryption-key-residency-sovereign-kms.yaml
@@ -0,0 +1,69 @@
+uuid: uc-hammer-sovereignty-020
+handle: sovereignty/encryption-key-residency-sovereign-kms
+scenario:
+  description: 'A security officer provisions an encrypted data service where the sovereign mandate governs
+    not only the ciphertext''s data-at-rest location but the encryption key material itself: the keys
+    must be held in a sovereign KMS inside the mandated jurisdiction, and the data service depends on
+    that key material as a cross-resource payload. The architecture must treat the key-residency requirement
+    as a dependency of the data resource — placing the KMS in-jurisdiction, wiring the data service to
+    consume keys from it, and refusing a configuration where ciphertext is in-jurisdiction but the keys
+    that unlock it are held elsewhere. This probes whether sovereignty reasons about key material as a
+    distinct residency-bearing dependency, closing the "data local, keys foreign" loophole.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: Keep both ciphertext and its key material in the mandated jurisdiction
+  success_criteria:
+  - The key-residency requirement is modeled as a dependency of the data resource
+  - The sovereign KMS holding the keys is placed in the mandated jurisdiction
+  - The data service is wired to consume key material from the in-jurisdiction KMS
+  - A configuration with in-jurisdiction ciphertext but foreign-held keys is refused
+  - Both the ciphertext location and the key location are recorded as satisfied constraints
+  - The key-residency dependency and its resolution are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: key material modeled as a residency-bearing dependency of the data resource
+  - domain: policy
+    interaction: cross-domain sovereignty requires both ciphertext and key residency in-jurisdiction
+  - domain: provider
+    interaction: sovereign KMS placed in-jurisdiction; data service wired to consume its keys
+  - domain: audit
+    interaction: key-residency dependency resolution and satisfied constraints recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- sovereignty
+- key-residency
+- sovereign-kms
+- cross-dependency
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  preconditions:
+  - Mandate governs both ciphertext and encryption key residency
+  - Key material is a dependency of the data service
+  postconditions:
+  - Ciphertext and keys both in-jurisdiction
+  - Data-local-keys-foreign configuration refused
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/001-allocate-volume-from-pool.yaml b/dav/use-cases/hammer-storage-mobility/001-allocate-volume-from-pool.yaml
new file mode 100644
index 0000000..e7e409e
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/001-allocate-volume-from-pool.yaml
@@ -0,0 +1,57 @@
+uuid: uc-hammer-storage-mobility-001
+handle: storage-mobility/allocate-volume-from-pool
+scenario:
+  description: 'A platform engineer requests a 500 GiB StorageVolume carved from a named StoragePool backed
+    by a single eligible storage provider. The system must record the volume as a resource with a stable
+    UUID, bind it to the parent pool as a hard dependency, and have the provider realize the allocation.
+    This exercises the baseline block-allocation path and the Storage.Pool -> Storage.Volume containment
+    relationship on the simplest possible request.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Allocate a block volume of a requested size from an existing storage pool
+  success_criteria:
+  - StorageVolume resource is created with a stable UUID
+  - Volume record declares parent StoragePool as a hard dependency
+  - Requested capacity is validated against pool free space before dispatch
+  - Provider realizes the allocation and returns a realized handle
+  - Realized state records the backing pool, size, and provider-native volume id
+  - Intent size matches realized size after allocation
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: capacity validation checks requested size against pool free space
+  - domain: data
+    interaction: volume resource persisted with hard dependency on parent pool
+  - domain: provider
+    interaction: storage provider realizes the block allocation
+  - domain: audit
+    interaction: allocation event recorded with pool, size, and provider handle
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- volume-allocation
+- pool
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/002-zfs-pool-dataset-hierarchy.yaml b/dav/use-cases/hammer-storage-mobility/002-zfs-pool-dataset-hierarchy.yaml
new file mode 100644
index 0000000..9d6abd3
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/002-zfs-pool-dataset-hierarchy.yaml
@@ -0,0 +1,55 @@
+uuid: uc-hammer-storage-mobility-002
+handle: storage-mobility/zfs-pool-dataset-hierarchy
+scenario:
+  description: 'An SRE declares a ZFS-style storage hierarchy: a Storage.Pool composed of vdevs, with
+    nested Storage.Dataset resources (parent tank, child tank/home, grandchild tank/home/chris) each carrying
+    inherited and overridden properties (compression, recordsize, quota). The system must model arbitrary-depth
+    parent/child containment where child datasets inherit properties from ancestors unless overridden.
+    This stresses whether the data model expresses a recursive dataset tree, property inheritance, and
+    the pool-as-root invariant rather than a flat volume list.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives: []
+  intent: Model a nested ZFS pool and dataset hierarchy with property inheritance
+  success_criteria:
+  - Storage.Pool is created as the root of the hierarchy
+  - Datasets nest to arbitrary depth via parent/child containment
+  - Each dataset resolves properties through ancestor inheritance
+  - An overridden property on a child does not mutate the ancestor's declared value
+  - Dependency ordering realizes ancestors before descendants
+  - The full hierarchy is reconstructable from stored intent alone
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: recursive dataset tree persisted with parent/child containment and inherited properties
+  - domain: provider
+    interaction: ZFS provider realizes pool then datasets in ancestor-first order
+  - domain: audit
+    interaction: hierarchy creation recorded with inheritance resolution
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- zfs
+- dataset-hierarchy
+- inheritance
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/003-dataset-snapshot-restore.yaml b/dav/use-cases/hammer-storage-mobility/003-dataset-snapshot-restore.yaml
new file mode 100644
index 0000000..ede4c64
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/003-dataset-snapshot-restore.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-storage-mobility-003
+handle: storage-mobility/dataset-snapshot-restore
+scenario:
+  description: 'An application team takes a point-in-time snapshot of a Storage.Dataset, then later restores
+    the dataset to that snapshot after a bad application migration corrupted data. The system must model
+    the snapshot as a first-class Realized artifact bound to its source dataset, and the restore as a
+    modification that returns the dataset to the captured state without reassigning the dataset UUID.
+    This exercises snapshot lineage and the rollback path on a single dataset with dependents.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives: []
+  intent: Snapshot a dataset and later restore it to that point-in-time state
+  success_criteria:
+  - Snapshot is created as a Realized artifact bound to its source dataset UUID
+  - Snapshot records the capture timestamp and source dataset generation
+  - Restore operation is accepted as a modification of the existing dataset
+  - Dataset UUID is preserved across the restore (no reassignment)
+  - Post-restore realized state matches the snapshot's captured state
+  - Snapshot lineage remains queryable after restore
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: snapshot artifact persisted with lineage to source dataset
+  - domain: provider
+    interaction: storage provider captures snapshot and later executes rollback
+  - domain: policy
+    interaction: restore validated against dataset ownership and snapshot binding
+  - domain: audit
+    interaction: snapshot and restore events recorded with captured generation
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- snapshot
+- restore
+- lineage
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/004-file-share-export-host-dataset.yaml b/dav/use-cases/hammer-storage-mobility/004-file-share-export-host-dataset.yaml
new file mode 100644
index 0000000..df015c1
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/004-file-share-export-host-dataset.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-storage-mobility-004
+handle: storage-mobility/file-share-export-host-dataset
+scenario:
+  description: 'A platform engineer exports an NFS file share whose backing storage is a host-local Storage.Dataset
+    (a ZFS dataset on a specific host, not a portable block volume). The share is a Service that yields
+    file access; its backing dataset is pinned to the host that owns the pool. The system must model the
+    file-share Service as depending on a host-local dataset, and must record that the share''s placement
+    is constrained to the dataset''s host. This probes whether the model distinguishes a filesystem export
+    over a host-pinned dataset from an export over a relocatable volume.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - provider-owner
+  intent: Export a file share backed by a host-local ZFS dataset
+  success_criteria:
+  - File-share Service resource is created with a stable UUID
+  - Share declares a hard dependency on the backing Storage.Dataset
+  - Backing dataset is recorded as host-local (pinned to its pool's host)
+  - Share placement is constrained to the host that owns the dataset
+  - Export parameters (protocol, path, access list) are recorded as intent
+  - Realized state binds the share to the dataset's host
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: file-share service persisted with host-local dataset dependency
+  - domain: policy
+    interaction: placement constrained to the dataset's owning host
+  - domain: provider
+    interaction: storage provider realizes the NFS export on the dataset's host
+  - domain: audit
+    interaction: export event recorded with backing dataset and host binding
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- file-share
+- dataset
+- host-local
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/005-file-share-export-block-volume.yaml b/dav/use-cases/hammer-storage-mobility/005-file-share-export-block-volume.yaml
new file mode 100644
index 0000000..35757c4
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/005-file-share-export-block-volume.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-storage-mobility-005
+handle: storage-mobility/file-share-export-block-volume
+scenario:
+  description: 'A tenant admin requests a file share whose backing storage is a relocatable Storage.Volume
+    (block) rather than a host-local dataset. Because a block volume must first be attached to a host,
+    formatted with a filesystem, and only then exported, the share depends on a chain: volume -> host
+    attachment -> filesystem -> export. The system must either model this multi-hop realization or return
+    that a filesystem export over a bare block volume is not directly expressible. This contrasts with
+    the host-local dataset export and likely surfaces a gap in how block-to-file layering is modeled.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - tenancy-authority
+  intent: Export a file share backed by a relocatable block volume
+  success_criteria:
+  - System recognizes the share cannot bind a bare block volume directly
+  - The volume -> attachment -> filesystem -> export dependency chain is expressed or flagged
+  - If unsupported, the missing filesystem-layering abstraction is named as the gap
+  - No file share is realized over an unformatted block device
+  - The volume retains its relocatable identity if the chain is modeled
+  - Verdict distinguishes this case from the host-local dataset export
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: multi-hop volume-to-export dependency chain evaluated for expressibility
+  - domain: policy
+    interaction: validation checks that a filesystem layer exists before export
+  - domain: provider
+    interaction: provider capability for block-to-file layering is probed
+  - domain: audit
+    interaction: expressibility verdict and gap recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- file-share
+- block-volume
+- layering
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/006-shared-pool-quota-enforcement.yaml b/dav/use-cases/hammer-storage-mobility/006-shared-pool-quota-enforcement.yaml
new file mode 100644
index 0000000..ade0df4
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/006-shared-pool-quota-enforcement.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-storage-mobility-006
+handle: storage-mobility/shared-pool-quota-enforcement
+scenario:
+  description: 'Two tenants share a single Storage.Pool, each granted a capacity quota (tenant-a: 2 TiB,
+    tenant-b: 1 TiB) against a 3 TiB pool. Tenant-a requests a new 800 GiB volume that fits within the
+    pool''s free space but would exceed tenant-a''s remaining quota. The system must reject the allocation
+    on the per-tenant quota even though raw pool capacity is available. This exercises quota accounting
+    layered above physical capacity on a shared pool and the distinction between pool-level and tenant-level
+    limits.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - tenancy-authority
+  intent: Allocate a volume that fits the pool but violates the tenant's quota
+  success_criteria:
+  - Pool free space and per-tenant quota are tracked as distinct quantities
+  - Requested allocation is checked against tenant quota, not just pool free space
+  - Allocation is rejected because tenant quota would be exceeded
+  - Rejection cites the tenant quota, not physical capacity
+  - No partial or reserved allocation is left behind after rejection
+  - Other tenants' quota accounting is unaffected by the rejected request
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: per-tenant quota policy evaluated above pool capacity check
+  - domain: data
+    interaction: pool capacity and tenant quota accounting read and reconciled
+  - domain: audit
+    interaction: quota-based rejection recorded with the limiting dimension
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- quota
+- shared-pool
+- multi-tenancy
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/007-thin-provision-overcommit-denied.yaml b/dav/use-cases/hammer-storage-mobility/007-thin-provision-overcommit-denied.yaml
new file mode 100644
index 0000000..54915ac
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/007-thin-provision-overcommit-denied.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-storage-mobility-007
+handle: storage-mobility/thin-provision-overcommit-denied
+scenario:
+  description: 'A finance-analyst-driven capacity plan thin-provisions volumes on a Storage.Pool such
+    that the sum of declared logical sizes (5 TiB) exceeds physical pool capacity (3 TiB), betting on
+    low real utilization. A subsequent write burst pushes actual usage toward the physical ceiling. The
+    system must model the difference between declared (logical) and allocated (physical) capacity, admit
+    overcommit as an intentional policy, and enforce a guard that denies or throttles new writes before
+    the pool physically fills. This probes whether thin provisioning and overcommit ratios are expressible,
+    or whether the model only understands thick allocation.
+
+    '
+  actor:
+    persona: finance-analyst
+    profile: prod
+  perspectives:
+    - provider-owner
+  intent: Thin-provision volumes beyond physical capacity and guard against fill
+  success_criteria:
+  - Logical (declared) and physical (allocated) capacity are modeled distinctly
+  - Overcommit is admitted only under an explicit thin-provisioning policy
+  - The overcommit ratio is recorded against the pool
+  - A guard denies or throttles allocation/writes as physical usage nears the ceiling
+  - If thin provisioning is not expressible, the gap is reported as unsupported
+  - No silent data loss occurs when physical capacity is reached
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: logical vs physical capacity and overcommit ratio tracked per pool
+  - domain: policy
+    interaction: thin-provisioning policy admits overcommit and enforces fill guard
+  - domain: provider
+    interaction: provider reports physical utilization to the fill guard
+  - domain: audit
+    interaction: overcommit admission and guard actions recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- thin-provisioning
+- overcommit
+- capacity
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/008-volume-online-resize.yaml b/dav/use-cases/hammer-storage-mobility/008-volume-online-resize.yaml
new file mode 100644
index 0000000..12add62
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/008-volume-online-resize.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-storage-mobility-008
+handle: storage-mobility/volume-online-resize
+scenario:
+  description: 'An application team grows an existing 500 GiB Storage.Volume to 1 TiB while it is attached
+    and in use by a running service. The system must treat this as a modification of the existing volume
+    (not a new resource), validate the new size against pool free space and tenant quota, dispatch an
+    online-expand to the provider, and preserve the volume UUID and any dependent attachments. This exercises
+    the day-2 resize path and idempotent size reconvergence.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Grow an in-use volume and preserve its identity and attachments
+  success_criteria:
+  - Resize is accepted as a modification of the existing volume
+  - New size is validated against pool free space and tenant quota
+  - Volume UUID is preserved (no reassignment)
+  - Dependent attachments remain bound across the resize
+  - Realized size matches the new intent size after expansion
+  - Re-applying the same target size produces a no-op
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: new size validated against pool free space and tenant quota
+  - domain: data
+    interaction: volume intent size updated, UUID and attachments preserved
+  - domain: provider
+    interaction: provider executes online volume expansion
+  - domain: audit
+    interaction: resize event recorded with old and new sizes
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- resize
+- day-2
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/009-migrate-volume-cross-provider-identity.yaml b/dav/use-cases/hammer-storage-mobility/009-migrate-volume-cross-provider-identity.yaml
new file mode 100644
index 0000000..ec125e4
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/009-migrate-volume-cross-provider-identity.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-storage-mobility-009
+handle: storage-mobility/migrate-volume-cross-provider-identity
+scenario:
+  description: 'A platform engineer migrates a Storage.Volume from a Ceph-backed provider to a NetApp-backed
+    provider (for example, to consolidate arrays) while the volume must keep the same DCM identity, dependents,
+    and access bindings. The system must copy the data to the target provider, cut over the realized binding
+    to the new provider-native id, and preserve the volume''s UUID and every dependency edge — the data
+    moves, the identity does not. This exercises provider-portable data mobility and the separation of
+    DCM identity from provider-native handle.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Move a volume's data to a new provider while preserving its DCM identity
+  success_criteria:
+  - Migration is modeled as a modification of the existing volume, not a new resource
+  - Data is copied to the target provider and verified before cutover
+  - Realized binding is repointed to the target provider's native volume id
+  - Volume UUID is preserved across the provider change
+  - All dependency edges and access bindings remain intact after cutover
+  - Source provider allocation is released only after successful cutover
+  - Audit trail records both provider handles across the migration
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: source and target providers coordinate data copy and cutover
+  - domain: data
+    interaction: realized handle repointed while UUID and dependencies preserved
+  - domain: policy
+    interaction: target provider eligibility and capability validated before migration
+  - domain: audit
+    interaction: cross-provider migration recorded with both native handles
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- migration
+- provider-portable
+- identity-preservation
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/010-migrate-target-capability-mismatch.yaml b/dav/use-cases/hammer-storage-mobility/010-migrate-target-capability-mismatch.yaml
new file mode 100644
index 0000000..2ec154c
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/010-migrate-target-capability-mismatch.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-storage-mobility-010
+handle: storage-mobility/migrate-target-capability-mismatch
+scenario:
+  description: 'A platform engineer attempts to migrate a Storage.Volume that carries live snapshots and
+    a strong-consistency guarantee to a target provider that supports neither snapshot lineage nor strong
+    consistency. The system must compare the source resource''s realized capabilities against the target
+    provider''s declared capability set and refuse a migration that would silently drop snapshots or downgrade
+    the consistency contract. This probes capability-aware placement and whether the architecture prevents
+    lossy migrations — likely surfacing an unsupported verdict.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+  intent: Migrate a volume to a provider that cannot honor its capabilities
+  success_criteria:
+  - Source volume's required capabilities (snapshots, strong consistency) are enumerated
+  - Target provider's declared capability set is evaluated against them
+  - Migration is refused because the target cannot preserve required capabilities
+  - The specific unmet capabilities are named in the verdict
+  - No data is copied and no cutover is attempted on refusal
+  - Source volume remains fully intact and bound to its current provider
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: target provider capability set compared against source requirements
+  - domain: policy
+    interaction: capability-preservation constraint blocks lossy migration
+  - domain: data
+    interaction: source volume and its snapshot lineage left unchanged
+  - domain: audit
+    interaction: refusal recorded with the specific unmet capabilities
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- migration
+- capability-mismatch
+- unsupported
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/011-provider-failure-queue-writes.yaml b/dav/use-cases/hammer-storage-mobility/011-provider-failure-queue-writes.yaml
new file mode 100644
index 0000000..ef84d1d
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/011-provider-failure-queue-writes.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-storage-mobility-011
+handle: storage-mobility/provider-failure-queue-writes
+scenario:
+  description: 'A storage provider backing an active Storage.Volume becomes unreachable mid-operation
+    while the pipeline is dispatching a batch of allocation and resize intents. The system must not drop
+    or silently fail the in-flight intents: it must hold them in a durable pending state, mark the provider
+    unhealthy, and reconcile the queued intents when the provider recovers — without creating duplicates.
+    This exercises the recovery policy and the durability of intent under a single-provider failure, a
+    core promise of an intent-driven model.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+  intent: Preserve and replay in-flight storage intents across a provider outage
+  success_criteria:
+  - Provider unreachability is detected and the provider is marked unhealthy
+  - In-flight intents are held in a durable pending state, not dropped or errored away
+  - No intent is lost or silently discarded during the outage
+  - On recovery, queued intents are reconciled against realized state
+  - Reconciliation is idempotent — no duplicate volumes or double-applied resizes
+  - Audit trail records the outage window and the replay outcome per intent
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: provider_failure
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: provider health tracked, dispatch suspended on failure and resumed on recovery
+  - domain: data
+    interaction: in-flight intents persisted in durable pending state
+  - domain: policy
+    interaction: recovery policy governs hold, replay, and idempotent reconciliation
+  - domain: audit
+    interaction: outage window and per-intent replay outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- provider-failure
+- durability
+- recovery
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/012-write-once-snapshot-store-contract.yaml b/dav/use-cases/hammer-storage-mobility/012-write-once-snapshot-store-contract.yaml
new file mode 100644
index 0000000..3501adc
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/012-write-once-snapshot-store-contract.yaml
@@ -0,0 +1,59 @@
+uuid: uc-hammer-storage-mobility-012
+handle: storage-mobility/write-once-snapshot-store-contract
+scenario:
+  description: 'A compliance officer provisions a WORM (write-once-read-many) snapshot store for regulatory
+    retention: snapshots written to it are Realized artifacts that, once committed, must be immutable
+    for a declared retention period. The system must model a Realized store whose records carry a write-once
+    contract and a retention lock, and reject any modification or overwrite of a committed snapshot within
+    its lock window. This exercises whether the architecture can express an immutable Realized artifact
+    class distinct from mutable realized state.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - regulator
+  intent: Provision a write-once immutable snapshot store with retention locks
+  success_criteria:
+  - Snapshot store is provisioned with a declared write-once contract
+  - Each committed snapshot carries a retention-lock expiry timestamp
+  - Committed snapshots are immutable — overwrite and mutate are rejected within the lock window
+  - The write-once contract is a modeled property, not merely provider-side configuration
+  - Attempts to shorten a retention lock are rejected
+  - Immutability guarantees are recorded and auditable per snapshot
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: immutable Realized snapshot artifacts persisted with retention-lock metadata
+  - domain: policy
+    interaction: write-once contract rejects mutation or overwrite within the lock window
+  - domain: audit
+    interaction: immutability contract and every rejected mutation recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- write-once
+- worm
+- immutability
+- compliance
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/013-immutable-snapshot-early-delete-denied.yaml b/dav/use-cases/hammer-storage-mobility/013-immutable-snapshot-early-delete-denied.yaml
new file mode 100644
index 0000000..8d9afcd
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/013-immutable-snapshot-early-delete-denied.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-storage-mobility-013
+handle: storage-mobility/immutable-snapshot-early-delete-denied
+scenario:
+  description: 'A tenant admin, trying to reclaim capacity, issues a decommission against a snapshot held
+    in a WORM store whose retention lock has not yet expired. The system must treat the committed snapshot
+    as an immutable record and refuse the deletion until the lock window passes — even when the request
+    comes from the resource owner. This probes drift and lifecycle enforcement on immutable records: the
+    intent to delete must not be honored, and the attempt itself must be audited. Likely an unsupported/denied
+    verdict that proves the retention contract holds against privileged actors.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Delete a retention-locked snapshot before its lock expires
+  success_criteria:
+  - Decommission request targets a snapshot under an unexpired retention lock
+  - The deletion is refused because the retention lock is still active
+  - Refusal holds even though the requester owns the resource
+  - The snapshot and its data remain fully intact
+  - The lock expiry that blocks deletion is cited in the verdict
+  - The denied deletion attempt is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: retention-lock policy denies decommission within the lock window
+  - domain: data
+    interaction: immutable snapshot record left unchanged
+  - domain: audit
+    interaction: denied deletion attempt recorded with requester and lock expiry
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- immutability
+- retention
+- decommission
+- denied
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/014-consistency-model-declaration.yaml b/dav/use-cases/hammer-storage-mobility/014-consistency-model-declaration.yaml
new file mode 100644
index 0000000..e347225
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/014-consistency-model-declaration.yaml
@@ -0,0 +1,56 @@
+uuid: uc-hammer-storage-mobility-014
+handle: storage-mobility/consistency-model-declaration
+scenario:
+  description: 'An application team provisions two datasets with explicit and different consistency contracts:
+    a transactional dataset requiring strong (linearizable) consistency and an analytics dataset accepting
+    eventual consistency for higher throughput. The system must let the intent declare a consistency model
+    as a first-class property, validate that the chosen provider can honor the declared model, and only
+    place each dataset on a provider whose declared capabilities satisfy it. This exercises whether consistency
+    semantics are modeled and matched, or merely assumed uniform.
+
+    '
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives: []
+  intent: Declare per-dataset consistency models and place on providers that honor them
+  success_criteria:
+  - Each dataset's intent declares a consistency model (strong or eventual)
+  - Consistency model is a first-class, validated property of the resource
+  - Provider selection requires the provider to declare support for the requested model
+  - The strong-consistency dataset is not placed on an eventual-only provider
+  - Realized state records the honored consistency model per dataset
+  - A request for an unsupported consistency model is flagged rather than silently downgraded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: consistency model persisted as a first-class per-dataset property
+  - domain: policy
+    interaction: placement validates provider consistency capability against the declared model
+  - domain: provider
+    interaction: providers advertise supported consistency models for matching
+  - domain: audit
+    interaction: honored consistency model recorded per dataset
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- consistency-model
+- capability-matching
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/015-data-mobility-sovereignty-change.yaml b/dav/use-cases/hammer-storage-mobility/015-data-mobility-sovereignty-change.yaml
new file mode 100644
index 0000000..982a9b2
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/015-data-mobility-sovereignty-change.yaml
@@ -0,0 +1,61 @@
+uuid: uc-hammer-storage-mobility-015
+handle: storage-mobility/data-mobility-sovereignty-change
+scenario:
+  description: 'A storage provider that currently holds a tenant''s Storage.Volumes has its sovereignty
+    classification changed mid-flight — for example, its operating jurisdiction is reclassified so it
+    no longer satisfies the tenant''s data-residency mandate. Data already resident on that provider must
+    be evacuated to a compliant provider, and any in-flight writes must be held rather than committed
+    to the now-noncompliant provider. The system must detect the sovereignty change, block further placement
+    on the provider, and drive a compliant migration. This stresses data mobility triggered by a governance
+    change rather than an operator request.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Evacuate data off a provider that lost its sovereignty classification
+  success_criteria:
+  - Sovereignty reclassification of the provider is detected as a governance event
+  - Further placement and write-commit on the now-noncompliant provider is blocked
+  - In-flight writes are held, not committed to the noncompliant provider
+  - Resident volumes are migrated to a provider that satisfies the residency mandate
+  - Volume UUIDs and dependencies are preserved across the forced migration
+  - The sovereignty-driven evacuation is fully recorded for the audit trail
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: cross_domain_constraint
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: sovereignty change re-evaluates placement and blocks the noncompliant provider
+  - domain: provider
+    interaction: compliant target provider selected and data evacuated
+  - domain: data
+    interaction: in-flight writes held; volumes migrated with identity preserved
+  - domain: audit
+    interaction: sovereignty event and evacuation recorded end to end
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- sovereignty
+- data-residency
+- forced-migration
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/016-volume-residency-placement-enforced.yaml b/dav/use-cases/hammer-storage-mobility/016-volume-residency-placement-enforced.yaml
new file mode 100644
index 0000000..a7a9f6c
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/016-volume-residency-placement-enforced.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-storage-mobility-016
+handle: storage-mobility/volume-residency-placement-enforced
+scenario:
+  description: 'A tenant under a data-residency mandate (all data must remain in-region) requests a new
+    Storage.Volume. Two providers are eligible on capability, but only one operates within the mandated
+    region. The system must enforce the residency constraint during placement so the volume is allocated
+    only on the in-region provider, and must refuse to fall back to the out-of-region provider even when
+    it is otherwise a better fit on cost or capacity. This exercises residency as a hard placement constraint
+    on a straightforward allocation.
+
+    '
+  actor:
+    persona: security-officer
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Allocate a volume only on a provider within the mandated data-residency region
+  success_criteria:
+  - Requesting tenant's residency mandate is resolved for the request
+  - Each eligible provider's operating region is evaluated against the mandate
+  - Volume is placed only on the in-region provider
+  - The out-of-region provider is excluded even if cheaper or larger
+  - Realized state records the placement region for later audit
+  - A request with no compliant provider is refused rather than placed out-of-region
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: single_validation
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: residency constraint filters providers by operating region
+  - domain: provider
+    interaction: only the in-region provider is eligible to realize the volume
+  - domain: data
+    interaction: placement region recorded on realized volume
+  - domain: audit
+    interaction: residency-constrained placement decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- data-residency
+- placement
+- sovereignty
+- simple
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/017-cross-tenant-volume-leakage-denied.yaml b/dav/use-cases/hammer-storage-mobility/017-cross-tenant-volume-leakage-denied.yaml
new file mode 100644
index 0000000..11bd3d0
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/017-cross-tenant-volume-leakage-denied.yaml
@@ -0,0 +1,58 @@
+uuid: uc-hammer-storage-mobility-017
+handle: storage-mobility/cross-tenant-volume-leakage-denied
+scenario:
+  description: 'On a Storage.Pool shared by multiple tenants, tenant-b attempts to attach or snapshot
+    a Storage.Volume owned by tenant-a — for instance by referencing tenant-a''s volume UUID or a residual
+    provider-native id after a prior deallocation. The system must enforce tenant ownership on every volume
+    operation so that no cross-tenant attach, snapshot, or read binding is permitted, and must ensure
+    freed blocks are not readable across the tenant boundary. This probes multi-tenant isolation on shared
+    storage and likely returns a denied/unsupported verdict for the crossing.
+
+    '
+  actor:
+    persona: tenant-admin
+    profile: prod
+  perspectives:
+    - compliance-auditor
+    - tenancy-authority
+  intent: Attempt to access another tenant's volume on a shared pool
+  success_criteria:
+  - Every volume operation is authorized against the requesting tenant's ownership
+  - Cross-tenant attach, snapshot, and read-binding attempts are denied
+  - Referencing another tenant's volume UUID does not grant access
+  - Freed blocks are scrubbed or barred from cross-tenant reuse-read
+  - The denied cross-tenant attempt is recorded with both tenant identities
+  - Tenant-a's volume state is entirely unaffected by the attempt
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: tenant-ownership authorization denies the cross-tenant operation
+  - domain: data
+    interaction: tenant-a volume and freed blocks protected from cross-tenant read
+  - domain: audit
+    interaction: denied cross-tenant attempt recorded with both identities
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- multi-tenancy
+- isolation
+- leakage
+- denied
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/018-dataset-replication-peer-dcm.yaml b/dav/use-cases/hammer-storage-mobility/018-dataset-replication-peer-dcm.yaml
new file mode 100644
index 0000000..634ef3c
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/018-dataset-replication-peer-dcm.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-storage-mobility-018
+handle: storage-mobility/dataset-replication-peer-dcm
+scenario:
+  description: 'A platform engineer configures asynchronous replication of a Storage.Dataset from the
+    local DCM to a dataset managed by a peer DCM in a partner organization, for cross-site DR. The replication
+    relationship spans an administrative boundary: each DCM owns its own copy''s identity, and the replica''s
+    lifecycle is governed by the peer. The system must express a cross-DCM replication edge, negotiate
+    the replication contract with the peer, and keep both sides'' realized state coherent — while tolerating
+    a peer disconnect without corrupting the local dataset. This stresses federated data mobility across
+    a peer boundary.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - federation-peer-operator
+  intent: Replicate a dataset to a peer-DCM-managed replica for cross-site DR
+  success_criteria:
+  - A cross-DCM replication edge is expressed between local and peer datasets
+  - Each DCM retains ownership of its own copy's identity
+  - The replication contract (mode, direction, cadence) is negotiated with the peer
+  - Both sides' realized state reflects the replication relationship coherently
+  - A peer disconnect degrades gracefully without corrupting the local dataset
+  - Replication lag and peer reachability are observable and audited
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: peer_dcm_required
+    governance_context: standard_governance
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: replication realized between local and peer-managed datasets
+  - domain: policy
+    interaction: cross-DCM replication contract negotiated and enforced
+  - domain: data
+    interaction: cross-DCM replication edge persisted with per-side ownership
+  - domain: audit
+    interaction: replication state, lag, and peer disconnect recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- replication
+- federation
+- peer-dcm
+- dr
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/019-data-migration-in-rehydration.yaml b/dav/use-cases/hammer-storage-mobility/019-data-migration-in-rehydration.yaml
new file mode 100644
index 0000000..86573c7
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/019-data-migration-in-rehydration.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-storage-mobility-019
+handle: storage-mobility/data-migration-in-rehydration
+scenario:
+  description: 'After a site loss, a platform engineer rehydrates a full stack from stored intent. Unlike
+    a stateless rebuild, the storage resources must not come back empty: each Storage.Volume and Storage.Dataset
+    must be re-realized and then have its data restored from the most recent DR replica or snapshot before
+    dependent services are started. The system must sequence rehydration so that data migration is a step
+    within each storage resource''s rebuild — provision, then hydrate data, then release dependents. This
+    stresses whether rehydration models stateful data restoration as part of the plan or assumes empty
+    re-provisioning.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Rehydrate a stack and restore each storage resource's data before dependents start
+  success_criteria:
+  - Rehydration plan re-realizes storage resources from stored intent
+  - Each storage resource includes a data-hydration step, not just empty provisioning
+  - Data is restored from the most recent DR replica or snapshot per resource
+  - Dependent services start only after their storage is hydrated
+  - Volume and dataset UUIDs are preserved across the rehydration
+  - Post-rehydration data content matches the last replicated point, and this is verifiable
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: composite_service
+    policy_complexity: orchestration_flow_static
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: stored intent read; per-resource data hydration sequenced before dependents
+  - domain: provider
+    interaction: storage re-realized then data restored from replica or snapshot
+  - domain: policy
+    interaction: orchestration ordering gates dependents on completed data hydration
+  - domain: audit
+    interaction: rehydration arc with per-resource data restoration recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- rehydration
+- data-migration
+- dr
+- complex
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-mobility/020-decommission-pool-dangling-volumes.yaml b/dav/use-cases/hammer-storage-mobility/020-decommission-pool-dangling-volumes.yaml
new file mode 100644
index 0000000..404d34a
--- /dev/null
+++ b/dav/use-cases/hammer-storage-mobility/020-decommission-pool-dangling-volumes.yaml
@@ -0,0 +1,60 @@
+uuid: uc-hammer-storage-mobility-020
+handle: storage-mobility/decommission-pool-dangling-volumes
+scenario:
+  description: 'A platform engineer issues a decommission of a Storage.Pool that still has allocated Storage.Volumes
+    (some attached to running services) carved from it. Because volumes hard-depend on their pool, tearing
+    down the pool would orphan or destroy live data. The system must detect the dangling dependents, refuse
+    the naive decommission, and require that dependents first be migrated off or explicitly decommissioned
+    — enforcing dependency-aware teardown ordering. This exercises safe decommission with hard dependents
+    and likely returns a blocked verdict until the pool is empty.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Decommission a storage pool that still has dependent volumes
+  success_criteria:
+  - Pool decommission detects volumes that hard-depend on the pool
+  - Naive teardown is refused while live dependents exist
+  - The blocking dependents are enumerated in the verdict
+  - Decommission proceeds only after dependents are migrated off or decommissioned
+  - No attached volume or its data is destroyed by the blocked request
+  - The refusal and the required teardown ordering are recorded for audit
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: dependency graph consulted for volumes bound to the pool
+  - domain: policy
+    interaction: dependency-aware teardown blocks decommission with live dependents
+  - domain: provider
+    interaction: pool teardown withheld until dependents are cleared
+  - domain: audit
+    interaction: blocked decommission and required ordering recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: hammer-1.0
+  timestamp: '2026-07-16T06:00:00.000000+00:00'
+tags:
+- storage-mobility
+- decommission
+- dangling-dependents
+- teardown-ordering
+- edge
+- hammer-2026-07-16
+version: 1.0.0
+metadata:
+  author: dav-hammer
+  note: batch=framework-hammer-2026-07-16
diff --git a/dav/use-cases/hammer-storage-redundancy/001-degraded-pool-drift-and-member-replacement.yaml b/dav/use-cases/hammer-storage-redundancy/001-degraded-pool-drift-and-member-replacement.yaml
new file mode 100644
index 0000000..2f69ea1
--- /dev/null
+++ b/dav/use-cases/hammer-storage-redundancy/001-degraded-pool-drift-and-member-replacement.yaml
@@ -0,0 +1,58 @@
+uuid: uc-storage-redundancy-001
+handle: storage-redundancy/degraded-pool-drift-and-member-replacement
+version: 1.0.0
+scenario:
+  description: "A member drive in a protected pool fails. Discovery reports the pool degraded: the redundancy_status\
+    \ output flips, fault_tolerance_remaining drops (0 on a degraded mirror \u2014 the next failure loses\
+    \ data), and the dead drive's inbound member edges identify exactly which vdevs, pools, and datasets\
+    \ sit in the blast radius. An operator replaces the drive; resilver/rebuild completes; status returns\
+    \ healthy. This stresses redundancy state as first-class discovered drift with graph-walkable blast\
+    \ radius \u2014 uniformly across ZFS, md, and hardware RAID, because all three are the same Pool shape."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Detect pool degradation as discovered drift, walk the blast radius via member references, and
+    track recovery through member replacement
+  success_criteria:
+  - The failed member's inbound edges enumerate affected vdevs/pools/datasets with no bespoke tooling
+  - redundancy_status and fault_tolerance_remaining outputs reflect degradation at discovery
+  - Degradation in a nested vdev (a mirror leg inside a stripe) composes up the tree to the pool's reported
+    tolerance
+  - 'fault_tolerance_remaining: 0 is distinguishable as at-risk (next failure loses data)'
+  - Member replacement and rebuild restore healthy status, recorded as governed operations
+  - The identical flow holds for pool_kind zfs, md, and hardware_raid
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: component_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: member references and protection topology are the walked record
+  - domain: policy
+    interaction: degradation thresholds can gate maintenance windows (fault-domain serialization)
+  - domain: provider
+    interaction: the backend provider reports degradation and executes the rebuild
+  - domain: audit
+    interaction: failure, blast radius, replacement, and recovery are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: storage-redundancy-2026-07-25
+  timestamp: '2026-07-25T00:00:00.000000+00:00'
+tags:
+- storage-pool
+- raid
+- drift
+- blast-radius
+- degradation
diff --git a/dav/use-cases/hammer-storage-redundancy/002-declare-hardware-raid-at-provision.yaml b/dav/use-cases/hammer-storage-redundancy/002-declare-hardware-raid-at-provision.yaml
new file mode 100644
index 0000000..9a52cc9
--- /dev/null
+++ b/dav/use-cases/hammer-storage-redundancy/002-declare-hardware-raid-at-provision.yaml
@@ -0,0 +1,54 @@
+uuid: uc-storage-redundancy-002
+handle: storage-redundancy/declare-hardware-raid-at-provision
+version: 1.0.0
+scenario:
+  description: "A platform engineer declares a bare-metal host's storage topology as a hardware_raid Storage.Pool\
+    \ intent record contained_by the host, before the host is provisioned. The bare-metal provisioning\
+    \ provider derives its RAID-controller configuration from the declared pool (members, native type,\
+    \ canonical mapping), builds the virtual disk during provisioning, and the pool reaches Realized alongside\
+    \ the host. This stresses that RAID is never host-type fields: the same Pool model that describes\
+    \ a live ZFS pool IS the provisioning declaration for firmware RAID \u2014 replayable intent for storage\
+    \ topology, completing the bare-metal rehydration story."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Declare firmware RAID as a Pool intent on an unprovisioned host and have the provisioning provider
+    build it from that declaration
+  success_criteria:
+  - The hardware_raid pool exists as Intent contained_by the host before provisioning
+  - The provisioning provider derives controller configuration solely from the declared pool
+  - Host and pool reach Realized together; the pool's outputs publish usable capacity and health
+  - Host rehydration replays BOTH the host's provisioning intent and its declared pools
+  - No RAID configuration exists anywhere except the Pool record
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the declared pool is the single home of storage topology intent
+  - domain: policy
+    interaction: validation checks member availability and admitted provider pre-dispatch
+  - domain: provider
+    interaction: the Metal3/BMC-class provider builds the controller config from the record
+  - domain: audit
+    interaction: derivation from declaration and the build result are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: storage-redundancy-2026-07-25
+  timestamp: '2026-07-25T00:00:00.000000+00:00'
+tags:
+- storage-pool
+- hardware-raid
+- provisioning-intent
+- bare-metal
+- rehydration
diff --git a/dav/use-cases/hammer-storage-redundancy/003-composed-topology-fault-tolerance.yaml b/dav/use-cases/hammer-storage-redundancy/003-composed-topology-fault-tolerance.yaml
new file mode 100644
index 0000000..53b4a6c
--- /dev/null
+++ b/dav/use-cases/hammer-storage-redundancy/003-composed-topology-fault-tolerance.yaml
@@ -0,0 +1,58 @@
+uuid: uc-storage-redundancy-003
+handle: storage-redundancy/composed-topology-fault-tolerance
+version: 1.0.0
+scenario:
+  description: "A pool's protection is a recursive tree \u2014 a stripe of mirrors, a mirror of stripes,\
+    \ an LVM pool whose member is an md mirror. Fault tolerance must compose through the tree honestly:\
+    \ a stripe-of-mirrors survives one failure per mirror leg but zero once any leg is degraded; the same\
+    \ physical layout expressed in a different persona (ZFS's top-level mirrors vs a controller's explicit\
+    \ tree) must report identical tolerance numbers. This stresses that the tree semantics, not the authoring\
+    \ idiom, determine the reported protection state."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Model composed redundancy topologies and verify fault tolerance composes through the vdev tree
+    identically for equivalent layouts in different personas
+  success_criteria:
+  - A nested topology (stripe of mirrors) reports tree-composed fault_tolerance_remaining
+  - Degrading one mirror leg drops the composed tolerance to reflect the striped parent
+  - The same layout expressed as ZFS top-level mirrors and as an explicit controller tree reports identical
+    numbers
+  - A mixed-depth tree (drives and child vdevs as siblings, where the backend allows) evaluates correctly
+  - Nested-backend layering (an lvm pool whose member vdev is an md mirror) models without special cases
+  - 'Spare semantics follow tree position: a top-level spare group serves any vdev, a nested one only
+    its parent; draid distributed spares report capacity without devices; spares_available never inflates
+    fault_tolerance_remaining'
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: single_eligible
+    governance_context: internal_audit
+    failure_mode: component_failure
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the recursive vdev tree is the evaluated structure
+  - domain: policy
+    interaction: tolerance thresholds gate maintenance regardless of authoring persona
+  - domain: provider
+    interaction: each backend reports member state; composition is model semantics
+  - domain: audit
+    interaction: tolerance transitions are recorded against the tree, not flat groups
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: storage-redundancy-2026-07-25
+  timestamp: '2026-07-25T03:00:00.000000+00:00'
+tags:
+- storage-pool
+- raid
+- recursive-vdevs
+- fault-tolerance
+- personas
diff --git a/dav/use-cases/hammer-storage-redundancy/004-backend-aggregation-and-pool-boundary.yaml b/dav/use-cases/hammer-storage-redundancy/004-backend-aggregation-and-pool-boundary.yaml
new file mode 100644
index 0000000..b145c61
--- /dev/null
+++ b/dav/use-cases/hammer-storage-redundancy/004-backend-aggregation-and-pool-boundary.yaml
@@ -0,0 +1,56 @@
+uuid: uc-storage-redundancy-004
+handle: storage-redundancy/backend-aggregation-and-pool-boundary
+version: 1.0.0
+scenario:
+  description: "Top-level aggregation belongs to the backend, not the type: zfs dynamic-stripes across\
+    \ top-level vdevs, lvm allocates per VG policy, and a hardware controller does not aggregate independent\
+    \ virtual disks \u2014 two independent VDs are two Pools, because a Pool is one capacity source. This\
+    \ stresses the boundary rule and its consequences: authoring that mistakes two capacity sources for\
+    \ one pool is rejected or flagged; cross-backend portability queries (via the canonical raid_type\
+    \ mapping) still compare protection across all aggregation styles."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Enforce the one-capacity-source pool boundary per backend aggregation semantics while keeping
+    protection comparable across backends via the canonical mapping
+  success_criteria:
+  - A zfs pool with multiple top-level vdevs is one pool (the backend aggregates); its capacity is the
+    aggregate
+  - Two independent hardware-RAID virtual disks model as two Pools; a single-pool authoring of them is
+    rejected or flagged
+  - An lvm pool spanning PVs models as one pool with the VG's allocation semantic, not an implied stripe
+  - A cross-backend query by canonical raid_type compares protection across all three aggregation styles
+  - 'The worked distinction is queryable: which pools aggregate at the backend vs carry one explicit tree'
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: multiple_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the pool-boundary rule (one capacity source) is validated at authoring
+  - domain: policy
+    interaction: validation rejects capacity-source conflation per backend semantics
+  - domain: provider
+    interaction: each backend's aggregation semantic is declared, never assumed
+  - domain: audit
+    interaction: boundary rejections and their reasons are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: storage-redundancy-2026-07-25
+  timestamp: '2026-07-25T03:00:00.000000+00:00'
+tags:
+- storage-pool
+- backend-semantics
+- pool-boundary
+- raid-type-mapping
diff --git a/dav/use-cases/hammer-supply-chain-promotion/001-golden-vm-image-clean-promote-ocpvirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/001-golden-vm-image-clean-promote-ocpvirt.yaml
new file mode 100644
index 0000000..2bca828
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/001-golden-vm-image-clean-promote-ocpvirt.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-supply-chain-promotion-001
+handle: supply-chain-promotion/golden-vm-image-clean-promote-ocpvirt
+scenario:
+  description: 'A platform engineer submits a newly built RHEL golden VM image for promotion into the
+    governed controlled image repository so it can back Compute.VM.OCPVirt provisioning. The promotion
+    pipeline runs the full contribution lifecycle: SBOM generation, CVE scan via the configured scanner
+    discovery avenue, signature and provenance-attestation verification, license check, and approval.
+    Every gate passes cleanly, so the SoftwareImage is admitted across the ingress firewall, moved from
+    proposed to canonical in the controlled repo, and made available to the estate.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - compliance-auditor
+    - security-officer
+  intent: Promote a clean, signed golden VM image into the controlled repo for OCPVirt VMs
+  success_criteria:
+  - Promotion request enters the contribution pipeline and is not silently applied to the repo
+  - SBOM is generated and a CVE scan runs against the scanner discovery avenue with no gating findings
+  - 'Signature and provenance attestation verify: the image digest matches a trusted signer'
+  - License compliance check passes and the approval gate records an approver
+  - SoftwareImage transitions proposed to canonical in the controlled repo keyed by OCI digest
+  - Image becomes available to Compute.VM.OCPVirt and the admission crossing is recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: multi-gate chain (CVE severity, signature, provenance, license, approval) all pass
+  - domain: provider
+    interaction: Compute.VM.OCPVirt registered as an eligible consumer of the promoted image
+  - domain: data
+    interaction: SoftwareImage record written by OCI digest and moved proposed to canonical
+  - domain: audit
+    interaction: ingress admission crossing recorded with scan result, signer, and approver
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-vm
+- golden-image
+- promotion-happy-path
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Controlled image repository is reachable and the scanner discovery avenue is configured
+  - Image is signed by a trusted signer and carries a provenance attestation
+  postconditions:
+  - SoftwareImage is canonical in the controlled repo and available to Compute.VM.OCPVirt
+  - Full scan, signature, and approval evidence is recorded on the admission crossing
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/002-base-container-image-cve-gate-reject-ocpvirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/002-base-container-image-cve-gate-reject-ocpvirt.yaml
new file mode 100644
index 0000000..662228c
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/002-base-container-image-cve-gate-reject-ocpvirt.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-supply-chain-promotion-002
+handle: supply-chain-promotion/base-container-image-cve-gate-reject-ocpvirt
+scenario:
+  description: 'A security officer promotes a new UBI-based base container image intended to back
+    Compute.Container.OCPVirt workloads. During promotion the SBOM is generated and the CVE scan against
+    the scanner discovery avenue surfaces a critical, actively exploited vulnerability in a bundled
+    library. The CVE severity gate in the governance matrix is configured to block any critical finding,
+    so the policy chain must reject the promotion, keep the image out of the controlled repo, and leave
+    the estate unable to consume it. No canonical transition occurs.
+
+    '
+  actor:
+    persona: security-officer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Promote a new base container image that turns out to carry a critical CVE
+  success_criteria:
+  - SBOM generation and CVE scan run against the scanner discovery avenue before any repo write
+  - 'CVE severity gate matches the finding: a critical Vulnerability is detected in a bundled package'
+  - Governance matrix rejects the promotion because critical findings are non-admissible
+  - Image is not written as canonical and remains outside the controlled repo
+  - Compute.Container.OCPVirt cannot reference the rejected image digest
+  - Rejection, offending CVE id, and severity are recorded on the failed admission crossing
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: policy_violation
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: Vulnerability (CVE) linked to the SoftwareImage SBOM by purl during scan
+  - domain: policy
+    interaction: governance matrix CVE severity gate blocks admission on the critical finding
+  - domain: provider
+    interaction: no Compute.Container.OCPVirt consumer binding created for the rejected image
+  - domain: audit
+    interaction: failed ingress admission recorded with CVE id, severity, and gate rationale
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-container
+- cve-gate
+- policy-violation
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Governance matrix blocks any critical-severity CVE at the promotion gate
+  - Candidate base image bundles a library with a known critical vulnerability
+  postconditions:
+  - Promotion rejected; image never becomes canonical in the controlled repo
+  - Estate consumers cannot reference the rejected image; rejection is auditable
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/003-os-package-missing-attestation-reject-metal3.yaml b/dav/use-cases/hammer-supply-chain-promotion/003-os-package-missing-attestation-reject-metal3.yaml
new file mode 100644
index 0000000..01327df
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/003-os-package-missing-attestation-reject-metal3.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-supply-chain-promotion-003
+handle: supply-chain-promotion/os-package-missing-attestation-reject-metal3
+scenario:
+  description: 'A platform engineer promotes a new kernel/OS RPM into the approved-package repository so
+    it can feed Compute.BareMetal.Metal3 host provisioning. The package scans clean for CVEs, but it
+    arrives unsigned and without a provenance attestation tying it to a trusted build system. The
+    provenance and signature-verification gates must reject the promotion regardless of a clean CVE
+    result, because an unattested artifact cannot cross the ingress firewall into the controlled repo.
+    The estate keeps its prior canonical package unchanged.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+    - security-officer
+  intent: Promote an OS package that lacks a signature and provenance attestation
+  success_criteria:
+  - SBOM and CVE scan run and return no gating vulnerabilities
+  - Signature verification fails because the package is unsigned
+  - Provenance attestation gate fails because no trusted build provenance is present
+  - Promotion is rejected even though the CVE scan was clean
+  - No canonical SoftwarePackage transition occurs and Compute.BareMetal.Metal3 keeps its prior package
+  - 'Rejection reason is recorded: missing signature and missing attestation'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: multi_policy_chain
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: SoftwarePackage identified by purl; SBOM recorded but attestation absent
+  - domain: policy
+    interaction: signature and provenance gates deny admission despite a clean CVE scan
+  - domain: provider
+    interaction: Compute.BareMetal.Metal3 continues to reference the prior canonical package
+  - domain: audit
+    interaction: rejection recorded citing missing signature and missing provenance attestation
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-baremetal
+- provenance
+- policy-violation
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Promotion requires both a valid signature and a provenance attestation
+  - Candidate OS package is unsigned and carries no attestation
+  postconditions:
+  - Promotion rejected on provenance/signature grounds despite a clean CVE scan
+  - Prior canonical package remains in force for Compute.BareMetal.Metal3
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/004-new-cve-blast-radius-reverse-walk.yaml b/dav/use-cases/hammer-supply-chain-promotion/004-new-cve-blast-radius-reverse-walk.yaml
new file mode 100644
index 0000000..cbf7b5b
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/004-new-cve-blast-radius-reverse-walk.yaml
@@ -0,0 +1,66 @@
+uuid: uc-hammer-supply-chain-promotion-004
+handle: supply-chain-promotion/new-cve-blast-radius-reverse-walk
+scenario:
+  description: 'A library that was previously promoted into the controlled repo and is embedded in
+    several canonical base images has a new critical CVE disclosed against it. An SRE must drive a
+    blast-radius reverse-walk from the newly created Vulnerability, through the SBOM edges, to every
+    canonical SoftwareImage that bundles the affected SoftwarePackage, and onward to every realized
+    Compute.Container.OCPVirt workload and Compute.VM.OCPVirt instance built from those images. The
+    scenario surfaces a data-inconsistency: artifacts once judged clean are now non-compliant, and the
+    estate must be told which resources are exposed.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - compliance-auditor
+  intent: Trace a newly disclosed CVE to every image and running resource that inherits it
+  success_criteria:
+  - New Vulnerability is recorded and linked to the affected SoftwarePackage by purl
+  - Reverse-walk enumerates every canonical SoftwareImage whose SBOM contains that package
+  - Walk continues to realized Compute.Container.OCPVirt and Compute.VM.OCPVirt resources built from them
+  - Previously clean, now-exposed artifacts are flagged as a compliance drift, not silently ignored
+  - Affected images are marked for re-evaluation and blocked from backing new requests
+  - Blast-radius set and the triggering CVE are recorded for remediation tracking
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: cross_dependency_payload
+    policy_complexity: cross_domain_constraint
+    provider_landscape: mixed
+    governance_context: audit_heavy
+    failure_mode: data_inconsistency
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: reverse-walk over Vulnerability to SoftwarePackage to SoftwareImage to realized resources
+  - domain: policy
+    interaction: re-evaluation marks affected images non-compliant against the CVE severity gate
+  - domain: provider
+    interaction: exposed Compute.Container.OCPVirt and Compute.VM.OCPVirt resources identified across classes
+  - domain: audit
+    interaction: blast-radius set, triggering CVE, and drift status recorded for remediation
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-container
+- blast-radius
+- drift-detection
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - The affected library is a canonical SoftwarePackage embedded in multiple images
+  - A new critical CVE is disclosed after those images were already promoted
+  postconditions:
+  - Every exposed image and realized resource is enumerated and flagged as drift
+  - Affected images blocked from backing new requests pending remediation
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/005-high-impact-base-image-approval-ladder.yaml b/dav/use-cases/hammer-supply-chain-promotion/005-high-impact-base-image-approval-ladder.yaml
new file mode 100644
index 0000000..9232135
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/005-high-impact-base-image-approval-ladder.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-supply-chain-promotion-005
+handle: supply-chain-promotion/high-impact-base-image-approval-ladder
+scenario:
+  description: 'A platform operator promotes a new organization-wide base container image that hundreds
+    of downstream Compute.Container.KubeVirt workloads will inherit from. Because the artifact is
+    high-impact, the promotion policy requires an approval ladder: the automated gates (SBOM, CVE,
+    signature, license) pass, but final admission to canonical is held pending sign-off from a named
+    approver above the automated tier. The pipeline must escalate to a human, block the canonical
+    transition until approval is granted, and only then admit the image across the ingress firewall.
+
+    '
+  actor:
+    persona: platform-operator
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+    - security-officer
+  intent: Promote a high-impact base image that requires human approval before it goes canonical
+  success_criteria:
+  - Automated gates (SBOM, CVE, signature, license) all pass and are recorded
+  - Because the image is high-impact, the policy escalates to a required human approver
+  - Canonical transition is held until the named approver signs off, not auto-completed
+  - On approval the SoftwareImage becomes canonical and available to Compute.Container.KubeVirt
+  - 'If approval is withheld the image stays proposed: the estate cannot consume it'
+  - Escalation, approver identity, and decision are recorded on the admission crossing
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: high-impact rule triggers human escalation and holds the canonical transition
+  - domain: data
+    interaction: SoftwareImage stays proposed until an approval record is attached
+  - domain: provider
+    interaction: Compute.Container.KubeVirt gains the image as a consumer only after approval
+  - domain: audit
+    interaction: escalation, approver identity, and final decision recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-container
+- approval-ladder
+- human-escalation
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Base image is classified high-impact, requiring an approval ladder above automated gates
+  - All automated scan and verification gates pass
+  postconditions:
+  - Image goes canonical only after the named approver signs off
+  - Escalation and approval decision are fully auditable
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/006-scan-job-deadline-timeout-vmware.yaml b/dav/use-cases/hammer-supply-chain-promotion/006-scan-job-deadline-timeout-vmware.yaml
new file mode 100644
index 0000000..75f5c52
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/006-scan-job-deadline-timeout-vmware.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-supply-chain-promotion-006
+handle: supply-chain-promotion/scan-job-deadline-timeout-vmware
+scenario:
+  description: 'An SRE promotes a new golden VM image destined for Compute.VM.VMware. The promotion
+    pipeline dispatches a scan Automation.Job to the scanner discovery avenue, but the scanner is
+    backlogged and the job does not return a verdict before its configured deadline. The pipeline must
+    treat the missing verdict as a timeout rather than assuming success: the promotion is halted, the
+    image is held at proposed, and the estate does not gain a consumable image on an unscanned artifact.
+    The timeout is recorded so the promotion can be retried.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives: []
+  intent: Promote a golden VM image whose CVE scan job never completes in time
+  success_criteria:
+  - Promotion dispatches a scan Automation.Job to the scanner discovery avenue
+  - The scan job exceeds its deadline without returning a verdict
+  - Pipeline treats the missing verdict as a timeout and does not assume the image is clean
+  - Promotion halts with the SoftwareImage held at proposed, never reaching canonical
+  - Compute.VM.VMware cannot consume the unscanned image
+  - 'Timeout is recorded with the job id and deadline so the promotion can be retried'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: orchestration_flow_static
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: timeout
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: scan Automation.Job dispatched to the scanner but returns no verdict before deadline
+  - domain: policy
+    interaction: missing scan verdict fails closed; promotion is not allowed to proceed
+  - domain: data
+    interaction: SoftwareImage remains proposed with no canonical transition
+  - domain: audit
+    interaction: scan-job timeout recorded with job id and deadline for retry
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-vm
+- scan-timeout
+- fail-closed
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Scanner discovery avenue is backlogged beyond the scan job deadline
+  - Promotion policy fails closed on a missing scan verdict
+  postconditions:
+  - Promotion halted; image held at proposed and retryable
+  - Compute.VM.VMware never consumes an unscanned image
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/007-multiarch-image-partial-promotion-kubevirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/007-multiarch-image-partial-promotion-kubevirt.yaml
new file mode 100644
index 0000000..1cc12ef
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/007-multiarch-image-partial-promotion-kubevirt.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-supply-chain-promotion-007
+handle: supply-chain-promotion/multiarch-image-partial-promotion-kubevirt
+scenario:
+  description: 'A platform engineer promotes a multi-arch base container image (a manifest list covering
+    amd64 and arm64) into the controlled repo for Compute.Container.KubeVirt. The amd64 variant scans
+    clean, is signed, and passes all gates, but the arm64 variant fails its CVE scan on a high-severity
+    finding. The pipeline must not admit the whole manifest list atomically as clean: it promotes the
+    passing amd64 digest, holds the arm64 digest out of canonical, and marks the manifest as partially
+    fulfilled so consumers on the failing architecture are not exposed.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Promote a multi-arch image where only one architecture variant passes scanning
+  success_criteria:
+  - Each architecture digest in the manifest list is scanned and gated independently
+  - The amd64 variant passes all gates and is promoted to canonical
+  - The arm64 variant fails its CVE scan and is not promoted to canonical
+  - The manifest is recorded as partially fulfilled rather than admitted atomically as clean
+  - Compute.Container.KubeVirt can consume amd64 but is blocked from the arm64 digest
+  - Per-architecture scan verdicts and the partial outcome are recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: partial_fulfillment
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: gates evaluated per-architecture; arm64 blocked, amd64 admitted
+  - domain: data
+    interaction: amd64 SoftwareImage digest goes canonical; arm64 digest held at proposed
+  - domain: provider
+    interaction: Compute.Container.KubeVirt consumes amd64 only; arm64 unavailable
+  - domain: audit
+    interaction: per-arch verdicts and the partial-fulfillment outcome recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-container
+- multi-arch
+- partial-fulfillment
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Candidate is a multi-arch manifest list covering amd64 and arm64
+  - The arm64 variant carries a high-severity CVE the amd64 variant does not
+  postconditions:
+  - amd64 promoted to canonical; arm64 held out; manifest marked partially fulfilled
+  - KubeVirt consumers exposed only to the clean architecture
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/008-bad-promote-rollback-ocpvirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/008-bad-promote-rollback-ocpvirt.yaml
new file mode 100644
index 0000000..63089f1
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/008-bad-promote-rollback-ocpvirt.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-supply-chain-promotion-008
+handle: supply-chain-promotion/bad-promote-rollback-ocpvirt
+scenario:
+  description: 'A golden VM image was promoted to canonical in the controlled repo for Compute.VM.OCPVirt,
+    but shortly after promotion an out-of-band review finds the SBOM was incomplete and the image
+    actually bundles a vulnerable component that the scan missed. An SRE must drive a rollback: demote
+    the image out of canonical in the controlled repo, block any new Compute.VM.OCPVirt provisioning
+    from it, and reconcile any resource already realized on the bad image. The recovery policy governs
+    the rollback so the repo returns to a known-good state.
+
+    '
+  actor:
+    persona: sre
+    profile: prod
+  perspectives:
+    - platform-operator
+    - compliance-auditor
+  intent: Roll a bad image back out of the controlled repo after it was already promoted
+  success_criteria:
+  - The bad SoftwareImage is identified as incorrectly promoted after canonical admission
+  - Recovery policy drives a rollback demoting the image out of canonical in the controlled repo
+  - New Compute.VM.OCPVirt provisioning from the rolled-back image is blocked
+  - Resources already realized on the bad image are flagged for reconciliation
+  - The controlled repo returns to a known-good canonical state for that image line
+  - 'Rollback cause, image digest, and remediation targets are recorded'
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_no_deps
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: rollback_required
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: recovery policy authorizes and drives the demotion/rollback
+  - domain: data
+    interaction: SoftwareImage demoted from canonical; corrected SBOM/CVE linkage recorded
+  - domain: provider
+    interaction: Compute.VM.OCPVirt blocked from provisioning on the rolled-back image
+  - domain: audit
+    interaction: rollback cause, digest, and affected realized resources recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-vm
+- rollback
+- recovery-policy
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Image is canonical but was promoted on an incomplete SBOM that missed a vulnerable component
+  - A recovery policy governs post-promotion rollback of the controlled repo
+  postconditions:
+  - Image demoted out of canonical; new provisioning blocked; realized resources flagged
+  - Controlled repo restored to a known-good state and rollback is auditable
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/009-sovereign-artifact-store-residency-firmware-metal3.yaml b/dav/use-cases/hammer-supply-chain-promotion/009-sovereign-artifact-store-residency-firmware-metal3.yaml
new file mode 100644
index 0000000..bece0b7
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/009-sovereign-artifact-store-residency-firmware-metal3.yaml
@@ -0,0 +1,63 @@
+uuid: uc-hammer-supply-chain-promotion-009
+handle: supply-chain-promotion/sovereign-artifact-store-residency-firmware-metal3
+scenario:
+  description: 'A compliance auditor oversees promotion of a new firmware/microcode package for
+    Compute.BareMetal.Metal3 hosts under a sovereign profile. Beyond the usual scan and attestation
+    gates, the governance matrix requires that the controlled artifact store holding the promoted
+    package physically reside inside the mandated jurisdiction, and that full provenance be retained
+    for audit. The promotion must verify the artifact store residency and provenance completeness
+    before admitting the package; if the store is out-of-jurisdiction the promotion cannot proceed.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: sovereign
+  perspectives:
+    - sovereignty-authority
+  intent: Promote a firmware package only into an in-jurisdiction, audit-complete controlled store
+  success_criteria:
+  - SBOM, CVE scan, signature, and provenance attestation gates all pass for the firmware package
+  - Governance matrix additionally checks that the controlled artifact store is in the mandated jurisdiction
+  - Residency of the artifact store is verified before the SoftwarePackage is admitted
+  - Full provenance chain is retained and complete for audit before canonical transition
+  - Compute.BareMetal.Metal3 consumes the package only from the in-jurisdiction store
+  - 'Residency verification and provenance evidence are recorded on the admission crossing'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: policy
+    interaction: governance matrix enforces artifact-store residency plus provenance completeness
+  - domain: data
+    interaction: SoftwarePackage and full provenance chain written to the in-jurisdiction store
+  - domain: provider
+    interaction: Compute.BareMetal.Metal3 bound to the residency-compliant package source
+  - domain: audit
+    interaction: residency check and provenance evidence recorded for sovereign audit
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-baremetal
+- sovereignty
+- residency
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Sovereign profile mandates in-jurisdiction artifact storage and complete provenance retention
+  - Controlled artifact store for the firmware line is in the mandated jurisdiction
+  postconditions:
+  - Firmware package promoted only after residency and provenance are verified
+  - Metal3 hosts consume the package from the residency-compliant store; evidence retained
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/010-cross-class-rollout-vm-and-container.yaml b/dav/use-cases/hammer-supply-chain-promotion/010-cross-class-rollout-vm-and-container.yaml
new file mode 100644
index 0000000..92f250d
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/010-cross-class-rollout-vm-and-container.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-supply-chain-promotion-010
+handle: supply-chain-promotion/cross-class-rollout-vm-and-container
+scenario:
+  description: 'A platform engineer promotes a single approved hardened base image and makes it available
+    across a mixed provider landscape: as a container base image for Compute.Container.OCPVirt workloads
+    and, via a bootc/image-mode build, as a golden VM image for Compute.VM.OCPVirt. The one promotion
+    must satisfy the gates once, then fan out a single canonical SoftwareImage lineage to both provider
+    classes without re-admitting the artifact separately, so the estate has one governed source of truth
+    consumed by two distinct compute classes.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Promote one approved image and make it consumable by both VM and container classes
+  success_criteria:
+  - The image is scanned, signed, and gated once through the promotion pipeline
+  - A single canonical SoftwareImage lineage is admitted, not two independent admissions
+  - Compute.Container.OCPVirt can consume the image as a container base
+  - Compute.VM.OCPVirt can consume the derived golden VM image from the same lineage
+  - The mixed provider landscape resolves both classes as eligible consumers of one source
+  - The single admission crossing and its two consumer bindings are recorded
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: cross_dependency_payload
+    policy_complexity: multi_policy_chain
+    provider_landscape: mixed
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: gates evaluated once; result applies to both provider-class consumers
+  - domain: data
+    interaction: one canonical SoftwareImage lineage referenced by both VM and container derivations
+  - domain: provider
+    interaction: Compute.Container.OCPVirt and Compute.VM.OCPVirt both bound as eligible consumers
+  - domain: audit
+    interaction: single admission crossing with two cross-class consumer bindings recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-vm
+- compute-container
+- cross-class-rollout
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - One approved hardened base image is a candidate for both container and VM consumption
+  - The controlled repo supports a single lineage feeding multiple provider classes
+  postconditions:
+  - One canonical image lineage is consumable by Compute.Container.OCPVirt and Compute.VM.OCPVirt
+  - Governance evaluated once and applies across both classes
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/011-license-incompatible-dependency-reject-ocpvirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/011-license-incompatible-dependency-reject-ocpvirt.yaml
new file mode 100644
index 0000000..0b37b79
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/011-license-incompatible-dependency-reject-ocpvirt.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-supply-chain-promotion-011
+handle: supply-chain-promotion/license-incompatible-dependency-reject-ocpvirt
+scenario:
+  description: 'A compliance auditor promotes a new base container image for Compute.Container.OCPVirt.
+    The CVE scan is clean and the image is signed, but SBOM analysis reveals a transitive dependency
+    under a copyleft license that the organization prohibits for redistributed base images. The license
+    compliance gate must reject the promotion on licensing grounds alone, keep the image out of the
+    controlled repo, and record which SoftwarePackage and license caused the rejection so the team can
+    swap the dependency.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+  intent: Promote a base image whose SBOM contains a prohibited-license dependency
+  success_criteria:
+  - SBOM analysis enumerates transitive SoftwarePackages by purl during promotion
+  - CVE scan is clean and the signature verifies, so the block is not security-driven
+  - License compliance gate detects a prohibited copyleft license on a transitive dependency
+  - Promotion is rejected on licensing grounds and the image never becomes canonical
+  - Compute.Container.OCPVirt cannot consume the rejected image
+  - 'Offending package purl and license identifier are recorded on the rejection'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: cross_domain_constraint
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: SBOM enumerates transitive SoftwarePackages and their license metadata
+  - domain: policy
+    interaction: license compliance gate rejects the prohibited copyleft dependency
+  - domain: provider
+    interaction: no Compute.Container.OCPVirt consumer binding created for the rejected image
+  - domain: audit
+    interaction: offending package purl and license identifier recorded on rejection
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-container
+- license-compliance
+- policy-violation
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Organization policy prohibits a specific copyleft license in redistributed base images
+  - The candidate image pulls in that license via a transitive dependency
+  postconditions:
+  - Promotion rejected on licensing grounds despite clean security scans
+  - Offending dependency and license are recorded for remediation
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/012-peer-dcm-pull-disconnect-kubevirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/012-peer-dcm-pull-disconnect-kubevirt.yaml
new file mode 100644
index 0000000..bff64df
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/012-peer-dcm-pull-disconnect-kubevirt.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-supply-chain-promotion-012
+handle: supply-chain-promotion/peer-dcm-pull-disconnect-kubevirt
+scenario:
+  description: 'A platform engineer federates an approved golden VM image from a peer DCM domain: the
+    peer has already promoted and canonicalized the image in its own controlled repo, and the local
+    estate wants to mirror it for Compute.VM.KubeVirt rather than re-vet from scratch. Mid-pull the
+    peer DCM connection drops, so the artifact and its attestation transfer is incomplete. The pipeline
+    must not admit a half-transferred image as canonical: it aborts the federation admission, keeps the
+    local repo unchanged, and records the disconnect for retry.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - federation-peer-operator
+    - compliance-auditor
+  intent: Mirror a peer DCM approved image but the federation link drops mid-pull
+  success_criteria:
+  - Federation pull references the peer DCM canonical image and its attestation
+  - Local admission requires the full artifact and attestation to transfer before canonicalizing
+  - The peer DCM connection drops mid-pull, leaving the transfer incomplete
+  - The pipeline aborts the admission rather than promoting a partial artifact
+  - The local controlled repo is unchanged and Compute.VM.KubeVirt gains no new image
+  - 'The peer disconnect is recorded with the peer identity so the pull can be retried'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: multi_policy_chain
+    provider_landscape: peer_dcm_required
+    governance_context: audit_heavy
+    failure_mode: peer_dcm_disconnect
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: peer DCM federation pull dispatched but the link drops mid-transfer
+  - domain: policy
+    interaction: incomplete artifact/attestation fails admission; no canonical transition
+  - domain: data
+    interaction: local controlled repo left unchanged; no partial SoftwareImage written
+  - domain: audit
+    interaction: peer disconnect recorded with peer identity and pull state for retry
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-vm
+- peer-dcm
+- federation-disconnect
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - A peer DCM has canonicalized the image in its own controlled repo
+  - The federation link is unreliable and drops during the pull
+  postconditions:
+  - No partial image admitted locally; repo unchanged; disconnect is retryable
+  - Compute.VM.KubeVirt gains no image until a full, verified pull completes
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/013-supersede-canonical-image-ocpvirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/013-supersede-canonical-image-ocpvirt.yaml
new file mode 100644
index 0000000..107564b
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/013-supersede-canonical-image-ocpvirt.yaml
@@ -0,0 +1,62 @@
+uuid: uc-hammer-supply-chain-promotion-013
+handle: supply-chain-promotion/supersede-canonical-image-ocpvirt
+scenario:
+  description: 'A platform engineer promotes version N+1 of an existing base container image for
+    Compute.Container.OCPVirt. The new version passes all gates and, on canonicalization, is marked as
+    superseding the prior canonical image, which is deprecated but retained for reference. Consumers are
+    not forcibly rebuilt: existing realized workloads continue on version N, and the estate picks up
+    N+1 on their next converge. The scenario validates version supersession semantics and orderly
+    consumer migration in the controlled repo.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Promote a new image version that supersedes and deprecates the prior canonical one
+  success_criteria:
+  - Version N+1 passes all promotion gates and is admitted to canonical
+  - The prior canonical version N is marked deprecated but retained for reference
+  - N+1 is recorded as superseding N in the controlled repo lineage
+  - Existing realized Compute.Container.OCPVirt workloads are not forcibly rebuilt
+  - Consumers adopt N+1 on their next converge rather than immediately
+  - 'Supersession relationship and deprecation of N are recorded'
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: composite_service
+    policy_complexity: multi_policy_chain
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: gates pass and supersession policy deprecates the prior canonical version
+  - domain: data
+    interaction: N+1 canonical, N deprecated-retained, supersedes edge recorded in lineage
+  - domain: provider
+    interaction: Compute.Container.OCPVirt consumers migrate to N+1 on next converge
+  - domain: audit
+    interaction: supersession and deprecation transition recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-container
+- supersede
+- versioning
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - A prior canonical version N of the image line exists with active consumers
+  - Version N+1 is a clean, gate-passing successor
+  postconditions:
+  - N+1 canonical and superseding; N deprecated-retained
+  - Consumers migrate on next converge with no forced rebuild
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/014-repo-quota-exhausted-large-image-vmware.yaml b/dav/use-cases/hammer-supply-chain-promotion/014-repo-quota-exhausted-large-image-vmware.yaml
new file mode 100644
index 0000000..55fc48c
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/014-repo-quota-exhausted-large-image-vmware.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-supply-chain-promotion-014
+handle: supply-chain-promotion/repo-quota-exhausted-large-image-vmware
+scenario:
+  description: 'An SRE promotes a large golden VM image (a multi-hundred-gigabyte appliance image) into
+    the controlled repository for Compute.VM.VMware. All governance gates pass, but as the artifact is
+    written to the controlled store the backing storage quota for the repo is exhausted before the
+    upload completes. The pipeline must treat the exhausted store as a resource-exhaustion failure, not
+    a policy failure: it aborts the write, does not leave a half-written canonical image, and surfaces
+    the capacity condition so the store can be expanded and the promotion retried.
+
+    '
+  actor:
+    persona: sre
+    profile: standard
+  perspectives:
+    - application-team-member
+    - provider-owner
+  intent: Promote a very large VM image but the controlled repo runs out of capacity mid-write
+  success_criteria:
+  - All governance gates pass before the artifact write begins
+  - The controlled store quota is exhausted before the large image upload completes
+  - The pipeline classifies this as resource exhaustion, distinct from a policy rejection
+  - The write is aborted and no half-written image is left in canonical state
+  - Compute.VM.VMware gains no partially uploaded image
+  - 'Capacity condition and required headroom are recorded so the promotion can be retried'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: resource_exhaustion
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: gates pass; failure is capacity, not a policy violation
+  - domain: provider
+    interaction: controlled store write aborts when quota is exhausted mid-upload
+  - domain: data
+    interaction: no partial SoftwareImage left canonical; repo integrity preserved
+  - domain: audit
+    interaction: resource-exhaustion condition and headroom needed recorded for retry
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-vm
+- capacity
+- resource-exhaustion
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - The controlled store is near its storage quota
+  - The candidate image is large enough to exceed remaining headroom
+  postconditions:
+  - Write aborted cleanly; no partial canonical image; condition is retryable
+  - Compute.VM.VMware never sees a half-uploaded image
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/015-firmware-package-attested-promote-metal3.yaml b/dav/use-cases/hammer-supply-chain-promotion/015-firmware-package-attested-promote-metal3.yaml
new file mode 100644
index 0000000..87b40f7
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/015-firmware-package-attested-promote-metal3.yaml
@@ -0,0 +1,64 @@
+uuid: uc-hammer-supply-chain-promotion-015
+handle: supply-chain-promotion/firmware-package-attested-promote-metal3
+scenario:
+  description: 'A platform engineer promotes a vendor BIOS/firmware update package into the approved
+    firmware repository so it can be applied during Compute.BareMetal.Metal3 host provisioning. The
+    governance matrix requires a verified vendor signature, a provenance attestation tracing the binary
+    to the vendor release, and a check that the firmware version is on the approved baseline. All gates
+    pass, the SoftwarePackage crosses the ingress firewall from proposed to canonical, and Metal3 hosts
+    become eligible to receive the update on their next reprovision.
+
+    '
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - compliance-auditor
+    - security-officer
+  intent: Promote an attested vendor firmware package for bare-metal host provisioning
+  success_criteria:
+  - Vendor signature on the firmware package verifies against a trusted vendor key
+  - Provenance attestation traces the binary to the named vendor release
+  - Governance matrix confirms the firmware version is on the approved baseline
+  - SoftwarePackage transitions proposed to canonical in the approved firmware repo
+  - Compute.BareMetal.Metal3 becomes eligible to apply the firmware on next reprovision
+  - 'Signature, provenance, and baseline evidence are recorded on the admission crossing'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: governance matrix enforces vendor signature, provenance, and approved baseline
+  - domain: data
+    interaction: SoftwarePackage recorded by purl and moved proposed to canonical
+  - domain: provider
+    interaction: Compute.BareMetal.Metal3 bound as an eligible consumer of the firmware package
+  - domain: audit
+    interaction: signature, provenance, and baseline checks recorded on admission
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-baremetal
+- firmware
+- promotion-happy-path
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - Firmware package is vendor-signed with a provenance attestation
+  - The firmware version is on the organization's approved baseline
+  postconditions:
+  - Firmware package canonical and eligible for Compute.BareMetal.Metal3 provisioning
+  - Attestation and baseline evidence retained for audit
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/016-brownfield-unmanaged-image-quarantine-kubevirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/016-brownfield-unmanaged-image-quarantine-kubevirt.yaml
new file mode 100644
index 0000000..1d59f27
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/016-brownfield-unmanaged-image-quarantine-kubevirt.yaml
@@ -0,0 +1,68 @@
+uuid: uc-hammer-supply-chain-promotion-016
+handle: supply-chain-promotion/brownfield-unmanaged-image-quarantine-kubevirt
+scenario:
+  description: 'During brownfield ingestion of an existing estate, a security officer discovers a
+    Compute.Container.KubeVirt workload running a container image that was never promoted through the
+    governed controlled repository: it was side-loaded from an external registry and has no SBOM, no
+    scan record, and no provenance. The admission model must treat this unmanaged image as failing the
+    ingress firewall retroactively: it is quarantined, blocked from backing new requests, and queued
+    for scan-and-promote or replacement, rather than being silently accepted because it is already
+    running.
+
+    '
+  actor:
+    persona: security-officer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Reconcile an already-running image that never went through governed promotion
+  success_criteria:
+  - Brownfield ingestion identifies a running image with no SBOM, scan, or provenance record
+  - The image is recognized as never having crossed the controlled-repo ingress firewall
+  - The unmanaged image is quarantined rather than silently accepted as canonical
+  - It is blocked from backing new Compute.Container.KubeVirt requests
+  - The image is queued for scan-and-promote or replacement to become compliant
+  - 'The quarantine, missing provenance, and affected workload are recorded'
+  dimensions:
+    lifecycle_phase: brownfield_ingestion
+    resource_complexity: single_no_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: audit_heavy
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: data
+    interaction: ingested image has no SBOM/scan/provenance linkage; recorded as unmanaged
+  - domain: policy
+    interaction: governance matrix retroactively fails the un-admitted image and quarantines it
+  - domain: provider
+    interaction: Compute.Container.KubeVirt blocked from backing new requests with the image
+  - domain: audit
+    interaction: quarantine, missing provenance, and affected workload recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-container
+- brownfield
+- quarantine
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - A running workload uses an image side-loaded outside the controlled repo
+  - The image has no SBOM, scan record, or provenance attestation
+  postconditions:
+  - Unmanaged image quarantined and blocked from new requests
+  - Image queued for scan-and-promote or replacement; finding is auditable
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/017-attestation-expiry-demote-canonical-ocpvirt.yaml b/dav/use-cases/hammer-supply-chain-promotion/017-attestation-expiry-demote-canonical-ocpvirt.yaml
new file mode 100644
index 0000000..c6b2d2a
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/017-attestation-expiry-demote-canonical-ocpvirt.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-supply-chain-promotion-017
+handle: supply-chain-promotion/attestation-expiry-demote-canonical-ocpvirt
+scenario:
+  description: 'A canonical golden VM image backing Compute.VM.OCPVirt was promoted with a time-bounded
+    security attestation. A compliance auditor drives expiry enforcement: the attestation reaches its
+    expiry date without renewal, so the image can no longer claim a valid, current provenance. The
+    controlled repo must auto-demote the image from canonical, block it from backing new provisioning,
+    and flag any resource still realized on it for revalidation, without disturbing running workloads
+    until they are reconciled.
+
+    '
+  actor:
+    persona: compliance-auditor
+    profile: fsi
+  perspectives:
+    - platform-operator
+    - sre
+    - security-officer
+  intent: Enforce attestation expiry by demoting a golden VM image that is no longer attested
+  success_criteria:
+  - The canonical image's security attestation reaches expiry without renewal
+  - Expiry enforcement recognizes the image can no longer claim valid current provenance
+  - The controlled repo auto-demotes the image from canonical on expiry
+  - New Compute.VM.OCPVirt provisioning from the expired image is blocked
+  - Resources still realized on the image are flagged for revalidation, not abruptly killed
+  - 'Expiry event, image digest, and affected resources are recorded'
+  dimensions:
+    lifecycle_phase: expiry_enforcement
+    resource_complexity: single_no_deps
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: policy_violation
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: expiry enforcement demotes the image once its attestation lapses
+  - domain: data
+    interaction: SoftwareImage moved out of canonical; attestation marked expired
+  - domain: provider
+    interaction: Compute.VM.OCPVirt blocked from new provisioning on the expired image
+  - domain: audit
+    interaction: expiry event, digest, and affected realized resources recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-vm
+- attestation-expiry
+- expiry-enforcement
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - The image was promoted with a time-bounded attestation that is not renewed
+  - Expiry enforcement is active on the controlled repo
+  postconditions:
+  - Expired image demoted from canonical; new provisioning blocked
+  - Running resources flagged for revalidation; expiry is auditable
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-supply-chain-promotion/018-airgapped-offline-mirror-package-promote-metal3.yaml b/dav/use-cases/hammer-supply-chain-promotion/018-airgapped-offline-mirror-package-promote-metal3.yaml
new file mode 100644
index 0000000..fe0a3b8
--- /dev/null
+++ b/dav/use-cases/hammer-supply-chain-promotion/018-airgapped-offline-mirror-package-promote-metal3.yaml
@@ -0,0 +1,65 @@
+uuid: uc-hammer-supply-chain-promotion-018
+handle: supply-chain-promotion/airgapped-offline-mirror-package-promote-metal3
+scenario:
+  description: 'A platform operator promotes a new OS package into an air-gapped, offline controlled
+    mirror that feeds Compute.BareMetal.Metal3 provisioning inside a sovereign boundary. There is no
+    egress to public scanners, so the scanner discovery avenue and the CVE/OSV feed must both be the
+    in-boundary offline instances. The governance matrix requires that scan, signature, and provenance
+    all resolve from in-boundary sources before the SoftwarePackage crosses the ingress firewall to
+    canonical, proving governed promotion works with zero external dependencies.
+
+    '
+  actor:
+    persona: platform-operator
+    profile: sovereign
+  perspectives:
+    - compliance-auditor
+    - security-officer
+    - sovereignty-authority
+  intent: Promote an OS package into an air-gapped controlled mirror using only in-boundary services
+  success_criteria:
+  - Scanner discovery avenue resolves to the in-boundary offline scanner, not a public one
+  - CVE/OSV vulnerability data comes from the in-boundary offline feed
+  - Signature and provenance verification use in-boundary trust material only
+  - Governance matrix confirms no gate required egress outside the sovereign boundary
+  - SoftwarePackage transitions to canonical in the offline mirror for Compute.BareMetal.Metal3
+  - 'In-boundary scan, signature, and provenance evidence are recorded'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: hard_dependencies
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: scan Automation.Job runs against the in-boundary offline scanner
+  - domain: policy
+    interaction: governance matrix enforces that every gate resolves from in-boundary sources
+  - domain: data
+    interaction: SoftwarePackage and offline CVE feed linkage written to the air-gapped mirror
+  - domain: audit
+    interaction: in-boundary scan, signature, and provenance evidence recorded
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude
+  prompt_version: supply-chain-promotion-2026-07-22
+  timestamp: '2026-07-22T12:00:00.000000+00:00'
+tags:
+- supply-chain
+- compute-baremetal
+- air-gapped
+- sovereignty
+- hammer-2026-07-22
+version: 1.0.0
+metadata:
+  author: dav-supply-chain-promotion
+  preconditions:
+  - The estate is air-gapped with no egress to public scanners or feeds
+  - In-boundary offline scanner, CVE feed, and trust material are available
+  postconditions:
+  - Package promoted to canonical in the offline mirror with zero external dependencies
+  - Compute.BareMetal.Metal3 consumes the package from the in-boundary mirror
+  note: batch=supply-chain-promotion-2026-07-22
diff --git a/dav/use-cases/hammer-type-standard/001-reference-discipline-enforced.yaml b/dav/use-cases/hammer-type-standard/001-reference-discipline-enforced.yaml
new file mode 100644
index 0000000..9829b3c
--- /dev/null
+++ b/dav/use-cases/hammer-type-standard/001-reference-discipline-enforced.yaml
@@ -0,0 +1,53 @@
+uuid: uc-type-standard-001
+handle: type-standard/reference-discipline-enforced
+version: 1.0.0
+scenario:
+  description: "A type author adds a field that names another resource as a bare string ('the handle or\
+    \ uuid of the network'). Bare strings are opaque to policy, drift detection, and impact analysis \u2014\
+    \ the reference-discipline rule (PVD-001 class) requires the common-elements Reference shape so every\
+    \ cross-resource pointer is a typed, walkable edge. A fleet review found the discipline half-migrated:\
+    \ 5 fields on the canonical shape, ~20 still bare strings across 14 types. This stresses that the\
+    \ discipline is enforced at type registration, not discovered in review."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - sre
+    - compliance-auditor
+  intent: Register a type whose cross-resource field uses a bare string and have validation require the
+    canonical Reference shape
+  success_criteria:
+  - A *_ref field declared as a bare string is rejected or flagged at type validation
+  - The same field on the common-elements Reference shape passes
+  - Existing violations are tracked as a shrinking baseline, not silently accepted
+  - Policy and impact analysis can walk every conforming reference as a typed edge
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: none_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the Reference shape is the single canonical pointer form
+  - domain: policy
+    interaction: policies target references they can resolve, not strings they must parse
+  - domain: provider
+    interaction: providers receive resolvable references in dispatch payloads
+  - domain: audit
+    interaction: reference resolution is recordable; bare strings are not
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: type-standard-2026-07-24
+  timestamp: '2026-07-24T18:00:00.000000+00:00'
+tags:
+- reference-discipline
+- pvd-001
+- validation
+- ci-ratchet
diff --git a/dav/use-cases/hammer-type-standard/002-adopts-registration-parity.yaml b/dav/use-cases/hammer-type-standard/002-adopts-registration-parity.yaml
new file mode 100644
index 0000000..2798cc1
--- /dev/null
+++ b/dav/use-cases/hammer-type-standard/002-adopts-registration-parity.yaml
@@ -0,0 +1,49 @@
+uuid: uc-type-standard-002
+handle: type-standard/adopts-registration-parity
+version: 1.0.0
+scenario:
+  description: "A type's description claims it adopts an industry standard (an image spec, a vulnerability\
+    \ format, an identity schema) but its adopts[] list is empty \u2014 the claim carries no version,\
+    \ license verdict, or provenance, so the adoption is unverifiable and the licensing posture unknown.\
+    \ A fleet review found nine types with empty adopts[], three of which claim adoption in prose. This\
+    \ stresses that adoption claims and adoption records cannot diverge: prose that claims, registers."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - compliance-auditor
+  intent: Detect any type whose prose claims standard adoption without a corresponding adopts[] registration
+    carrying version and license disposition
+  success_criteria:
+  - A type claiming adoption in prose with empty adopts[] is flagged mechanically
+  - Every adopts[] entry carries source, version, and license compatibility verdict
+  - The standards-adoption register and adopts[] stay in parity both directions
+  - A reviewer can answer 'what standard backs this field' from the record, not the author
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_no_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: none_eligible
+    governance_context: internal_audit
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: adopts[] is the machine-readable adoption record the prose must match
+  - domain: policy
+    interaction: governance can gate on license compatibility only if it is recorded
+  - domain: provider
+    interaction: provider-adopted standards follow the same parity rule
+  - domain: audit
+    interaction: adoption provenance is attestable from the registry alone
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: type-standard-2026-07-24
+  timestamp: '2026-07-24T18:00:00.000000+00:00'
+tags:
+- adopts-parity
+- standards
+- licensing
+- ci-ratchet
diff --git a/dav/use-cases/hammer-type-standard/003-relationship-target-integrity.yaml b/dav/use-cases/hammer-type-standard/003-relationship-target-integrity.yaml
new file mode 100644
index 0000000..6a6d257
--- /dev/null
+++ b/dav/use-cases/hammer-type-standard/003-relationship-target-integrity.yaml
@@ -0,0 +1,53 @@
+uuid: uc-type-standard-003
+handle: type-standard/relationship-target-integrity
+version: 1.0.0
+scenario:
+  description: "A type declares a relationship whose target names a resource type that does not exist\
+    \ in the registry \u2014 a forward-reference to a planned type, a typo, or a casualty of a rename.\
+    \ Every consumer that walks the declared relationship surface (placement, composition, visualization,\
+    \ the SDK) hits a dangling pointer at runtime. A fleet review found live instances that no gate caught.\
+    \ This stresses that the declared relationship graph is closed over the registry: every target resolves,\
+    \ and a type retirement that would dangle inbound declarations is blocked until they are updated."
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - provider-owner
+    - compliance-auditor
+  intent: Register a type whose relationships[].target does not resolve and have validation reject it;
+    retire a type and have dangling inbound declarations block the retirement
+  success_criteria:
+  - A relationships[].target naming an unregistered type fails validation at registration
+  - Spec fields that name a type (not only relationships[]) are held to the same resolution rule
+  - Retiring a type with inbound relationship declarations is blocked until they are updated
+  - The declared relationship graph is closed over the registry at all times
+  dimensions:
+    lifecycle_phase: decommission
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: none_eligible
+    governance_context: internal_audit
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: the registry is the closure domain for every declared target
+  - domain: policy
+    interaction: retirement gating is a governance rule over inbound declarations
+  - domain: provider
+    interaction: provider-declared types join the same closure
+  - domain: audit
+    interaction: target-resolution failures and blocked retirements are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: claude
+  prompt_version: type-standard-2026-07-24
+  timestamp: '2026-07-24T18:00:00.000000+00:00'
+tags:
+- relationship-integrity
+- registry-closure
+- validation
+- ci-ratchet
diff --git a/dav/use-cases/hammer-vocabulary-intake/001-string-matches-existing-element.yaml b/dav/use-cases/hammer-vocabulary-intake/001-string-matches-existing-element.yaml
new file mode 100644
index 0000000..cc20d04
--- /dev/null
+++ b/dav/use-cases/hammer-vocabulary-intake/001-string-matches-existing-element.yaml
@@ -0,0 +1,47 @@
+uuid: uc-4c2d8015-45c5-43c0-9535-467b50c11524
+handle: vocabulary-intake/string-matches-existing-element
+version: 1.0.0
+scenario:
+  description: 'An author submits intent containing a plain string value for a field governed by shared
+    vocabulary. Intake finds an exact (normalized) match among SharedDataElements visible in the author''s
+    scope and binds the string to the existing element automatically: the author typed a string and received
+    a governed reference at zero added cost, and the decision record cites the element revision that was
+    bound. The author never performed vocabulary mechanics.'
+  actor:
+    persona: platform-engineer
+    profile: dev
+  perspectives: []
+  intent: Have a plain string bind automatically to an exactly-matching SharedDataElement in scope, costing
+    the author nothing
+  success_criteria:
+  - Exact/normalized match against elements visible in the author's scope binds automatically
+  - The bound value is a governed reference to the element, not a retained free string
+  - The decision record cites the element revision bound
+  - The author performs no vocabulary mechanics — the string was sufficient input
+  - 'Scope visibility governs matching: an element outside the author''s scope never matches'
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: dev
+  expected_domain_interactions:
+  - domain: data
+    interaction: scope-visible SharedDataElements are the match surface
+  - domain: policy
+    interaction: the intake mode permits auto-binding on exact match
+  - domain: audit
+    interaction: the binding cites the element revision
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: vocabulary-intake-2026-07-25
+  timestamp: '2026-07-26T05:00:00Z'
+tags:
+- hammer
+- vocabulary-intake
+- match
+- zero-toil
diff --git a/dav/use-cases/hammer-vocabulary-intake/002-net-new-string-minted-at-scope.yaml b/dav/use-cases/hammer-vocabulary-intake/002-net-new-string-minted-at-scope.yaml
new file mode 100644
index 0000000..25f9ee4
--- /dev/null
+++ b/dav/use-cases/hammer-vocabulary-intake/002-net-new-string-minted-at-scope.yaml
@@ -0,0 +1,49 @@
+uuid: uc-add11255-aa87-42dd-98c6-505077a498ed
+handle: vocabulary-intake/net-new-string-minted-at-scope
+version: 1.0.0
+scenario:
+  description: 'The same intake, but the string matches nothing in scope and the estate''s profile permits
+    mint-on-write: a new SharedDataElement is created at the author''s current (narrowest) scope with
+    status proposed and minted-from provenance (the source string, the author, the intent that carried
+    it). The request proceeds without interruption. Vocabulary is harvested from usage instead of demanded
+    before it — the toil of curation is deferred until the element proves it deserves any.'
+  actor:
+    persona: platform-engineer
+    profile: homelab
+  perspectives:
+    - compliance-auditor
+  intent: Mint an unmatched string as a proposed SharedDataElement at current scope without interrupting
+    the author
+  success_criteria:
+  - An unmatched string mints a SharedDataElement at the author's current scope, never wider
+  - The minted element carries status proposed and minted-from provenance
+  - The request proceeds uninterrupted — minting is not a detour the author experiences
+  - The proposed element is immediately matchable for subsequent authors in scope
+  - The proposed-element count is a visible burn-down surface, not an invisible accumulation
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: no_governance
+    failure_mode: happy_path
+  profile: homelab
+  expected_domain_interactions:
+  - domain: data
+    interaction: the minted element enters the store at narrowest scope, proposed
+  - domain: policy
+    interaction: the profile's intake mode permits mint-on-write
+  - domain: audit
+    interaction: minted-from provenance records string, author, and carrying intent
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: vocabulary-intake-2026-07-25
+  timestamp: '2026-07-26T05:00:00Z'
+tags:
+- hammer
+- vocabulary-intake
+- mint
+- proposed
+- harvest
diff --git a/dav/use-cases/hammer-vocabulary-intake/003-proposed-promotes-through-curation.yaml b/dav/use-cases/hammer-vocabulary-intake/003-proposed-promotes-through-curation.yaml
new file mode 100644
index 0000000..7bdbeb7
--- /dev/null
+++ b/dav/use-cases/hammer-vocabulary-intake/003-proposed-promotes-through-curation.yaml
@@ -0,0 +1,49 @@
+uuid: uc-940118e4-4994-4be3-b5a3-37a436ca64c7
+handle: vocabulary-intake/proposed-promotes-through-curation
+version: 1.0.0
+scenario:
+  description: 'A proposed element minted from usage is adopted by further authors and then curated: promotion
+    to canonical status — and optionally up a scope tier — runs through the standard element-promotion
+    operation, with deduplication performed at promotion time (near-duplicate proposed elements merged,
+    references re-bound) rather than at mint time. Promotion up a scope tier is the portability-improvement
+    operation the class system already defines; a harvested string can end its life as a Base-tier element
+    every provider shares.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Promote a usage-harvested proposed element to canonical through the standard promotion operation,
+    deduplicating at promotion time
+  success_criteria:
+  - Promotion proposed-to-canonical is the standard element-promotion operation, not a special path
+  - 'Deduplication happens at promotion: near-duplicate proposed elements merge with references re-bound'
+  - Scope-tier promotion follows the class system's promotion rules and improves derived portability
+  - The promotion records the element's minted-from lineage end to end
+  - Un-promoted proposed elements remain valid at their scope — promotion is earned, never forced
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: multiple_interacting
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: promotion + dedup operate on the element store with re-binding
+  - domain: policy
+    interaction: curation policy governs who promotes and when
+  - domain: audit
+    interaction: minted-from lineage survives promotion
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: vocabulary-intake-2026-07-25
+  timestamp: '2026-07-26T05:00:00Z'
+tags:
+- hammer
+- vocabulary-intake
+- promotion
+- dedup
+- curation
diff --git a/dav/use-cases/hammer-vocabulary-intake/004-near-match-never-silently-bound.yaml b/dav/use-cases/hammer-vocabulary-intake/004-near-match-never-silently-bound.yaml
new file mode 100644
index 0000000..9b7ce4f
--- /dev/null
+++ b/dav/use-cases/hammer-vocabulary-intake/004-near-match-never-silently-bound.yaml
@@ -0,0 +1,52 @@
+uuid: uc-27362b1e-fb32-4a6b-949d-d3acd0cd336d
+handle: vocabulary-intake/near-match-never-silently-bound
+version: 1.0.0
+scenario:
+  description: 'An author''s string is a close variant of an existing element (a synonym, a casing variant
+    beyond normalization, an abbreviation). The system must never silently bind a near match — synonym
+    auto-binding is how vocabularies rot and counts silently corrupt. The near match is surfaced: in permissive
+    profiles the author is offered the candidate and may accept it or mint anew (with the candidate linked
+    for later dedup); in strict profiles the request is refused naming the candidates. Silent approximation
+    is refused in every profile.'
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Have near-matches surfaced with candidates named, and silent approximate binding refused in
+    every profile
+  success_criteria:
+  - Auto-binding happens on exact/normalized match only; near matches never bind silently
+  - In permissive profiles the candidate is offered; accepting binds, declining mints with the candidate
+    linked
+  - In strict profiles the near-match case refuses, naming the candidates
+  - A declined candidate link survives to promotion-time dedup
+  - No profile exists in which approximate binding happens without the author or a curator deciding
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: standard
+  expected_domain_interactions:
+  - domain: policy
+    interaction: the exact-only auto-bind rule holds in every profile
+  - domain: data
+    interaction: candidate links feed promotion-time dedup
+  - domain: audit
+    interaction: offered/accepted/declined decisions are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: vocabulary-intake-2026-07-25
+  timestamp: '2026-07-26T05:00:00Z'
+tags:
+- hammer
+- vocabulary-intake
+- near-match
+- must-reject
+- synonym
diff --git a/dav/use-cases/hammer-vocabulary-intake/005-strict-profile-unknown-string-refused.yaml b/dav/use-cases/hammer-vocabulary-intake/005-strict-profile-unknown-string-refused.yaml
new file mode 100644
index 0000000..2666a4a
--- /dev/null
+++ b/dav/use-cases/hammer-vocabulary-intake/005-strict-profile-unknown-string-refused.yaml
@@ -0,0 +1,47 @@
+uuid: uc-57dbd48e-e796-48f3-a61c-c7824bbb4b9c
+handle: vocabulary-intake/strict-profile-unknown-string-refused
+version: 1.0.0
+scenario:
+  description: 'A production estate runs match-only intake: an author''s string that matches nothing in
+    scope is refused — typed as unknown-vocabulary, naming the nearest existing elements as candidates
+    and the proposal path (how to get the term into the vocabulary through review). The refusal teaches
+    the path forward; nothing mints implicitly in a profile that has declared its vocabulary curated.'
+  actor:
+    persona: platform-engineer
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Refuse unknown strings in match-only profiles with candidates and the proposal path named
+  success_criteria:
+  - In a match-only profile, an unmatched string refuses — nothing mints implicitly
+  - The refusal is typed unknown-vocabulary and names the nearest in-scope candidates
+  - The refusal names the proposal path — the governed route to extend the vocabulary
+  - An exact match in the same profile still binds automatically — strictness gates minting, not matching
+  - The refusal is recorded with the rejected string and the candidates offered
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: policy_violation
+  profile: prod
+  expected_domain_interactions:
+  - domain: policy
+    interaction: match-only intake refuses unknown vocabulary
+  - domain: data
+    interaction: nearest-candidate computation runs over in-scope elements
+  - domain: audit
+    interaction: the refusal records string, candidates, and path offered
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: vocabulary-intake-2026-07-25
+  timestamp: '2026-07-26T05:00:00Z'
+tags:
+- hammer
+- vocabulary-intake
+- match-only
+- must-reject
diff --git a/dav/use-cases/hammer-vocabulary-intake/006-curated-vocabulary-changes-by-change-control.yaml b/dav/use-cases/hammer-vocabulary-intake/006-curated-vocabulary-changes-by-change-control.yaml
new file mode 100644
index 0000000..3c271b0
--- /dev/null
+++ b/dav/use-cases/hammer-vocabulary-intake/006-curated-vocabulary-changes-by-change-control.yaml
@@ -0,0 +1,54 @@
+uuid: uc-70f54659-a8c7-4c1f-8c21-5cfc36beba98
+handle: vocabulary-intake/curated-vocabulary-changes-by-change-control
+version: 1.0.0
+scenario:
+  description: 'A regulated estate permits pre-existing canonical elements only: minting is unavailable
+    in every intake path, including review-queued. Extending the vocabulary is a change to a governed
+    artifact and runs through the estate''s own change control — proposal, approval, window — exactly
+    as any other governed change (the change-policy machinery applied to the vocabulary itself). Intake
+    refusals during the interim name the pending proposal when one exists, so authors see that the term
+    is on its way rather than in a void.'
+  actor:
+    persona: platform-engineer
+    profile: fsi
+  perspectives:
+    - application-team-member
+    - sre
+  intent: Have vocabulary extension in canonical-only estates run through standard change control, with
+    interim refusals citing pending proposals
+  success_criteria:
+  - Canonical-only profiles have no mint path — intake can bind existing elements only
+  - 'Vocabulary extension is a governed change: proposal, approval, and window under the estate''s change
+    policy'
+  - An intake refusal for a term with a pending proposal names that proposal and its state
+  - The vocabulary change, once adopted, follows normal element lifecycle (rotation, provenance, promotion
+    rules)
+  - The audit trail connects the refused intakes to the proposal they motivated — demand evidence for
+    curation
+  dimensions:
+    lifecycle_phase: modification
+    resource_complexity: single_with_deps
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: single_eligible
+    governance_context: compliance_gated
+    failure_mode: happy_path
+  profile: fsi
+  expected_domain_interactions:
+  - domain: policy
+    interaction: vocabulary itself is under change control in canonical-only estates
+  - domain: data
+    interaction: pending proposals are visible to the refusing intake
+  - domain: audit
+    interaction: refusals link to the proposals they motivated
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: vocabulary-intake-2026-07-25
+  timestamp: '2026-07-26T05:00:00Z'
+tags:
+- hammer
+- vocabulary-intake
+- canonical-only
+- change-control
+- regulated
diff --git a/dav/use-cases/identity/actor-authentication.yaml b/dav/use-cases/identity/actor-authentication.yaml
new file mode 100644
index 0000000..7c0115b
--- /dev/null
+++ b/dav/use-cases/identity/actor-authentication.yaml
@@ -0,0 +1,61 @@
+uuid: uc-pipeline-authn-001
+handle: identity/actor-authentication
+scenario:
+  description: An actor authenticates against the identity provider (Keycloak). The
+    control plane validates the token and maps claims (tenant, roles, profile) to a
+    DCM actor identity. This is the foundational authentication step that all other
+    pipeline UCs depend on. Keycloak handles authentication; authorization is a
+    separate concern (authz model TBD — Authorino vs Kessel vs OPA-native).
+  actor:
+    persona: application-team-member
+    profile: standard
+  perspectives:
+    - tenancy-authority
+  intent: Authenticate against the identity provider and obtain a DCM actor identity
+  success_criteria:
+  - Actor receives a valid token with tenant and role claims
+  - Control plane validates the token and resolves it to a DCM actor identity
+  - Authentication event is recorded in the audit trail
+  - Invalid or expired tokens are rejected with a clear error
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: no_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: identity
+    interaction: Keycloak validates credentials and issues token
+  - domain: data
+    interaction: actor identity reference created or resolved
+  - domain: audit
+    interaction: authentication event recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- identity
+- authentication
+- keycloak
+- foundational
+- 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: 0
+    sequence: 1
+    week: wk2
+    depends_on: []
+  preconditions:
+  - Keycloak is deployed and configured with the DCM realm
+  postconditions:
+  - Actor holds a valid Keycloak token with tenant and role claims
+  - Control plane has resolved the actor's DCM identity
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..07d2153
--- /dev/null
+++ b/dav/use-cases/identity/auth-provider-drift-detection.yaml
@@ -0,0 +1,72 @@
+uuid: uc-seed-003a
+handle: identity/auth-provider-drift-detection
+scenario:
+  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: sovereign-tenant-admin
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - sovereignty-authority
+    - tenancy-authority
+  intent: Detect and respond to divergence between DCM's disconnected identity
+    projection and the authoritative IdP, under sovereign/disconnected operation
+  success_criteria:
+  - 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: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: provider
+    interaction: auth provider re-resolves canonical state from the IdP (authoritative)
+  - domain: data
+    interaction: compare the observed point-in-time projection vs canonical IdP state
+  - domain: policy
+    interaction: classify divergence severity and remediation path; gate on whether a
+      projection is permitted (disconnected/sovereign)
+  - domain: audit
+    interaction: record divergence 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
+- delegated-identity
+- disconnected-projection
+- sovereign-profile
+- human-in-loop
+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/identity/connected-delegation.yaml b/dav/use-cases/identity/connected-delegation.yaml
new file mode 100644
index 0000000..44b783f
--- /dev/null
+++ b/dav/use-cases/identity/connected-delegation.yaml
@@ -0,0 +1,69 @@
+uuid: uc-identity-deleg-001
+handle: identity/connected-delegation
+scenario:
+  description: A request requires an authorization decision (is this actor a member
+    of the group permitted to perform the action?). In a connected deployment, DCM
+    DELEGATES the authn/authz resolution to the IdP (Keycloak/RHSSO) at decision time
+    and does NOT maintain an authoritative cache of user/group membership. DCM persists
+    only references (subject/group IDs, claims mappings); the IdP is authoritative.
+    This is the connected happy path and the capability that makes DR-C real — because
+    DCM resolves live and holds no membership cache, there is nothing to drift in the
+    connected case (the disconnected/sovereign projection-drift case is
+    identity/auth-provider-drift-detection). Validates that DCM treats identity as a
+    delegated provider capability, not a thing it re-owns.
+  actor:
+    persona: application-team-member
+    profile: prod
+  perspectives:
+    - platform-operator
+    - sre
+    - sovereignty-authority
+  intent: Have an access decision resolved by delegating to the authoritative IdP,
+    with DCM holding only references and no membership cache
+  success_criteria:
+  - The authorization decision is resolved by querying the IdP at decision time
+  - DCM persists only identity references (subject/group IDs, claims mappings) — never
+    an authoritative membership store
+  - No DCM-side membership cache is consulted as a source of truth for the decision
+  - The decision and the IdP as its source are recorded in the audit trail
+  - With the IdP authoritative and live, there is no DCM identity cache that can drift
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: prod
+  expected_domain_interactions:
+  - domain: provider
+    interaction: auth provider delegates the authz resolution to the IdP at decision time
+  - domain: data
+    interaction: only identity references / claims mappings are read; no membership
+      cache is the system of record
+  - domain: policy
+    interaction: the access gate consumes the IdP-resolved decision
+  - domain: audit
+    interaction: decision recorded with the IdP as the authoritative source
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-29T00:00:00.000000+00:00'
+tags:
+- identity
+- auth
+- delegated-identity
+- idp-authoritative
+- no-membership-cache
+- prod-profile
+- happy-path
+- foundational
+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
diff --git a/dav/use-cases/identity/identity-reference-data-model.yaml b/dav/use-cases/identity/identity-reference-data-model.yaml
new file mode 100644
index 0000000..b9f7afd
--- /dev/null
+++ b/dav/use-cases/identity/identity-reference-data-model.yaml
@@ -0,0 +1,59 @@
+uuid: uc-identity-reference-data-model
+handle: identity/identity-reference-data-model
+version: 1.0.0
+scenario:
+  description: 'Validation UC for DR-C: confirm UDLM models delegated identity correctly — DCM holds identity
+    references (subject/group IDs, claims mappings) and, only under disconnected/sovereign, an immutable
+    point-in-time projection marked provenance=observed. DCM is never the authoritative system of record
+    for membership.'
+  actor:
+    persona: platform-engineer
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - compliance-auditor
+    - sovereignty-authority
+  intent: Validate UDLM models identity as references + observed projection, not a membership store
+  success_criteria:
+  - Identity references (subject/group IDs, claims mappings) are modeled
+  - An optional point-in-time identity projection is modeled with provenance=observed
+  - The model marks the IdP as authoritative; DCM is not the membership system of record
+  - The projection is gated to disconnected/sovereign use, not a default cache
+  - Divergence between projection and IdP is representable as a drift record
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: cross_dependency_payload
+    policy_complexity: human_escalation_required
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: data_inconsistency
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: identity references + observed projection modeled; IdP authoritative
+  - domain: provider
+    interaction: auth provider is the delegation surface to the IdP
+  - domain: audit
+    interaction: projection provenance and divergence 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-c
+- identity
+- delegated-identity
+- data-model-validation
+- trifecta
+- udlm
+- sovereign-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)
diff --git a/dav/use-cases/infrastructure/bare-metal-pxe-bootstrap.yaml b/dav/use-cases/infrastructure/bare-metal-pxe-bootstrap.yaml
new file mode 100644
index 0000000..15d088a
--- /dev/null
+++ b/dav/use-cases/infrastructure/bare-metal-pxe-bootstrap.yaml
@@ -0,0 +1,62 @@
+uuid: uc-pipeline-bm-001
+handle: infrastructure/bare-metal-pxe-bootstrap
+scenario:
+  description: A platform engineer boots bare-metal nodes via PXE. The discovery ISO
+    phones home with hardware inventory. ABI (Agent-Based Installer) installs the
+    operating system and base packages. This UC validates the bootstrap path from
+    powered-off hardware to a node ready for cluster formation. Deployment target is
+    containers (Podman/OCP); no direct OS/KVM install.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Bootstrap bare-metal nodes via PXE and ABI to a cluster-ready state
+  success_criteria:
+  - Bare-metal nodes PXE-boot from the discovery ISO
+  - Each node phones home with hardware inventory (CPU, memory, disk, NIC)
+  - ABI completes OS installation and base package deployment
+  - Node is accessible via SSH/console and reports healthy status
+  - Bootstrap events are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: single_with_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: bare-metal service provider executes PXE boot and ABI install
+  - domain: data
+    interaction: hardware inventory records created in discovered state
+  - domain: audit
+    interaction: bootstrap events recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- infrastructure
+- bare-metal
+- pxe
+- bootstrap
+- 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: 1
+    sequence: 2
+    week: wk2
+    depends_on:
+    - uc-pipeline-authn-001
+  preconditions:
+  - Actor holds a valid Keycloak token with platform-engineer role claims
+  postconditions:
+  - Bare-metal nodes are bootstrapped with OS and base packages
+  - Hardware inventory is recorded in the discovered store
diff --git a/dav/use-cases/infrastructure/cluster-bootstrap.yaml b/dav/use-cases/infrastructure/cluster-bootstrap.yaml
new file mode 100644
index 0000000..98b776d
--- /dev/null
+++ b/dav/use-cases/infrastructure/cluster-bootstrap.yaml
@@ -0,0 +1,62 @@
+uuid: uc-pipeline-cluster-001
+handle: infrastructure/cluster-bootstrap
+scenario:
+  description: A platform engineer forms a Kubernetes cluster from bootstrapped
+    bare-metal nodes. The cluster is stood up using containers (Podman/OCP) on the
+    bootstrapped nodes. This UC validates that the infrastructure substrate is ready
+    for the control plane deployment.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Form a Kubernetes cluster from bootstrapped bare-metal nodes
+  success_criteria:
+  - Kubernetes cluster is formed from bootstrapped nodes
+  - Cluster API server is reachable and responding
+  - Node membership matches the declared intent
+  - Cluster formation is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: multi_dependent
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: cluster service provider orchestrates node joining
+  - domain: data
+    interaction: cluster entity created in intent and realized stores
+  - domain: policy
+    interaction: validation policy checks node readiness before joining
+  - domain: audit
+    interaction: cluster formation recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- infrastructure
+- cluster
+- kubernetes
+- bootstrap
+- 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: 1
+    sequence: 3
+    week: wk2
+    depends_on:
+    - uc-pipeline-bm-001
+  preconditions:
+  - Bare-metal nodes are bootstrapped with OS and base packages
+  postconditions:
+  - Kubernetes cluster is operational with all declared nodes joined
+  - Cluster entity is recorded in intent and realized stores
diff --git a/dav/use-cases/infrastructure/control-plane-deployment.yaml b/dav/use-cases/infrastructure/control-plane-deployment.yaml
new file mode 100644
index 0000000..d12ca57
--- /dev/null
+++ b/dav/use-cases/infrastructure/control-plane-deployment.yaml
@@ -0,0 +1,60 @@
+uuid: uc-pipeline-cp-001
+handle: infrastructure/control-plane-deployment
+scenario:
+  description: A platform engineer deploys the DCM control plane onto the bootstrapped
+    Kubernetes cluster. The control plane includes the convergence engine, policy
+    engine, request orchestrator, and the four-state data stores. This UC validates
+    that DCM itself is operational and ready to accept requests.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Deploy the DCM control plane onto the Kubernetes cluster
+  success_criteria:
+  - DCM control plane components are deployed and healthy (livez/readyz passing)
+  - Four-state data stores (intent, requested, realized, discovered) are initialized
+  - Policy engine is operational and evaluating
+  - Request orchestrator is accepting events
+  - Control plane deployment is recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: multi_dependent
+    policy_complexity: no_policy
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: container runtime deploys control plane pods
+  - domain: data
+    interaction: control plane entities created
+  - domain: audit
+    interaction: deployment events recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- infrastructure
+- control-plane
+- deployment
+- 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: 1
+    sequence: 4
+    week: wk2
+    depends_on:
+    - uc-pipeline-cluster-001
+  preconditions:
+  - Kubernetes cluster is operational with all declared nodes joined
+  postconditions:
+  - DCM control plane is deployed and accepting requests
+  - Four-state stores are initialized and UDLM-conformant
diff --git a/dav/use-cases/infrastructure/profile-based-deployment.yaml b/dav/use-cases/infrastructure/profile-based-deployment.yaml
new file mode 100644
index 0000000..eb7d05e
--- /dev/null
+++ b/dav/use-cases/infrastructure/profile-based-deployment.yaml
@@ -0,0 +1,67 @@
+uuid: uc-pipeline-profile-001
+handle: infrastructure/profile-based-deployment
+scenario:
+  description: A platform engineer deploys a full environment from a software profile
+    definition alone, onto plain VMs with no pre-existing state. The software profile
+    declares the complete stack (OS, runtime, middleware, and application layers).
+    This UC validates that software profiles are sufficient for reproducible
+    deployments without manual configuration steps.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives: []
+  intent: Deploy a full environment from a software profile definition alone
+  success_criteria:
+  - Software profile definition is complete and validated
+  - Deployment proceeds from profile alone (no manual configuration)
+  - All stack layers (OS, runtime, middleware, application) are deployed
+  - Deployed environment matches the profile specification
+  - Deployment is reproducible (running it again produces identical results)
+  - Deployment events are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: full_stack
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: provider
+    interaction: service provider deploys from profile specification
+  - domain: data
+    interaction: profile definition consumed; realized state recorded
+  - domain: policy
+    interaction: validation policy checks profile completeness
+  - domain: audit
+    interaction: profile-based deployment recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- infrastructure
+- profile
+- deployment
+- reproducible
+- stretch
+- 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: 5
+    sequence: 14
+    week: wk5
+    depends_on:
+    - uc-pipeline-cp-001
+  preconditions:
+  - Software profile definition exists and is validated
+  - Target VMs are available and accessible
+  postconditions:
+  - Full environment is deployed matching the profile specification
+  - Deployment is reproducible
diff --git a/dav/use-cases/integration/001-external-consumer-conformance.yaml b/dav/use-cases/integration/001-external-consumer-conformance.yaml
new file mode 100644
index 0000000..1e19f21
--- /dev/null
+++ b/dav/use-cases/integration/001-external-consumer-conformance.yaml
@@ -0,0 +1,60 @@
+uuid: uc-375cba80-b1e8-42f2-9951-3e616f450b08
+handle: integration/external-consumer-conformance
+version: 1.0.0
+scenario:
+  description: >-
+    An integrator builds an external system on the UDLM data model — consuming the estate graph and
+    reacting to realized state. They declare the read surface they depend on (the named types and
+    the versions they verified against), and the registry gates on it: every type they consume
+    exists and no version they require is ahead of the registry. When the registry later adds a
+    field the integrator does not consume, the integrator is unaffected — must-ignore-unknown means
+    forward change does not break a conforming reader. And because the contract is versioned with a
+    compatibility promise, the integrator can pin to a version and trust that a same-major change
+    stays wire-compatible. The integrator's demand is stability under change: they integrate once
+    and are not broken by the platform's forward evolution.
+  actor:
+    persona: integrator
+    profile: standard
+  perspectives:
+    - platform-engineer
+    - compliance-auditor
+    - security-officer
+  intent: >-
+    Consume the UDLM data model from an external system with a declared read surface, unbroken by
+    forward change — unknown fields ignored, the versioned contract pinnable to a compatibility
+    promise
+  success_criteria:
+  - The integrator declares the types and versions it consumes, and the registry gates that surface
+  - A registry-added field the integrator does not consume never breaks it (must-ignore-unknown)
+  - The integrator pins to a version and a same-major change stays wire-compatible (ADR-051)
+  - A required version ahead of the registry is refused, not silently accepted
+  - The integrator integrates once and survives the platform's forward evolution
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_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: the integrator's declared read surface (types + verified versions) is recorded as a consumer declaration
+  - domain: policy
+    interaction: the registry gates the declared surface (types exist, versions not ahead); must-ignore-unknown holds
+  - domain: provider
+    interaction: n/a — the integrator is an external consumer of the data model, not a provider
+  - domain: audit
+    interaction: the declared surface and the pinned version are recorded for the integration
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: osac-persona-coverage-2026-07-27
+  timestamp: '2026-07-27T19:00:00Z'
+tags:
+- integration
+- integrator
+- consumer-conformance
+- must-ignore-unknown
+- versioning
diff --git a/dav/use-cases/observability/drift-detection-remediation.yaml b/dav/use-cases/observability/drift-detection-remediation.yaml
new file mode 100644
index 0000000..961d0eb
--- /dev/null
+++ b/dav/use-cases/observability/drift-detection-remediation.yaml
@@ -0,0 +1,71 @@
+uuid: uc-pipeline-drift-001
+handle: observability/drift-detection-remediation
+scenario:
+  description: The drift reconciliation component compares discovered state (what actually
+    exists) against realized state (what was provisioned). When a divergence is detected,
+    a drift record is produced with field-by-field comparison and severity classification.
+    Remediation actions are triggered per recovery policy. This UC validates the operational
+    steady-state monitoring loop.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Detect drift between discovered and realized state and remediate per recovery
+    policy
+  success_criteria:
+  - Discovered state is probed and compared against realized state
+  - Divergences produce drift records with field-by-field comparison
+  - Drift records include severity classification (info, warning, critical)
+  - Recovery policy triggers appropriate remediation actions
+  - Remediation results are recorded and verified
+  - Drift detection cycle completes within the profile-governed reconciliation window
+  dimensions:
+    lifecycle_phase: drift_detection
+    resource_complexity: single_no_deps
+    policy_complexity: single_validation
+    provider_landscape: single_eligible
+    governance_context: standard_governance
+    failure_mode: data_inconsistency
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: discovered and realized stores compared
+  - domain: policy
+    interaction: recovery policy governs remediation actions
+  - domain: provider
+    interaction: service provider executes remediation if needed
+  - domain: audit
+    interaction: drift detection and remediation recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- observability
+- drift
+- detection
+- remediation
+- 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: 9
+    week: wk4
+    depends_on:
+    - uc-pipeline-composite-001
+    - uc-pipeline-4state-001
+  preconditions:
+  - Composite service is realized with all constituents operational
+  - Four-state stores are populated
+  - Drift reconciliation component is active
+  postconditions:
+  - Drift between discovered and realized states is detected and classified
+  - Remediation actions have been executed per recovery policy
diff --git a/dav/use-cases/observability/rehydration-rto-measurement.yaml b/dav/use-cases/observability/rehydration-rto-measurement.yaml
new file mode 100644
index 0000000..b53bf89
--- /dev/null
+++ b/dav/use-cases/observability/rehydration-rto-measurement.yaml
@@ -0,0 +1,65 @@
+uuid: uc-pipeline-rto-001
+handle: observability/rehydration-rto-measurement
+scenario:
+  description: After a dynamic rehydration, the system measures recovery time objective
+    (RTO) and validates completeness. Every resource in the original intent must exist
+    in the rebuilt realized state with matching field values. The RTO measurement is
+    the time from destroy trigger to last resource reaching OPERATIONAL status.
+  actor:
+    persona: platform-engineer
+    profile: standard
+  perspectives:
+    - platform-operator
+    - sre
+  intent: Measure RTO and validate completeness after dynamic rehydration
+  success_criteria:
+  - RTO is measured from destroy trigger to last resource reaching OPERATIONAL
+  - Every resource in the original intent exists in the rebuilt realized state
+  - Field values in the rebuilt realized state match the original intent (within tolerance
+    for provider-assigned fields)
+  - Completeness percentage is calculated and reported
+  - RTO measurement and completeness results are recorded in the audit trail
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: full_stack
+    policy_complexity: no_policy
+    provider_landscape: multiple_eligible
+    governance_context: standard_governance
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: intent vs rebuilt realized compared for completeness
+  - domain: observability
+    interaction: RTO measured and reported
+  - domain: audit
+    interaction: RTO and completeness recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: seed-1.0
+  timestamp: '2026-06-30T22:00:00.000000+00:00'
+tags:
+- observability
+- rehydration
+- rto
+- measurement
+- 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: 4
+    sequence: 12
+    week: wk4
+    depends_on:
+    - uc-pipeline-rehydrate-001
+  preconditions:
+  - Dynamic rehydration has completed
+  - All resources are re-realized
+  postconditions:
+  - RTO is measured and recorded
+  - Completeness is verified (intent matches rebuilt realized)
diff --git a/dav/use-cases/observability/telemetry-export-capability.yaml b/dav/use-cases/observability/telemetry-export-capability.yaml
new file mode 100644
index 0000000..60ea628
--- /dev/null
+++ b/dav/use-cases/observability/telemetry-export-capability.yaml
@@ -0,0 +1,59 @@
+uuid: uc-telemetry-export-capability
+handle: observability/telemetry-export-capability
+version: 1.0.0
+scenario:
+  description: 'Validation UC for A9: confirm DCM provides the universal telemetry-export capability —
+    a single UDLM-modeled, schema-discoverable export surface over standard transports (OTLP / Prometheus
+    / message-bus) with per-subscriber authorization and data-classification scoping, and no DCM-side
+    per-tool adapters.'
+  actor:
+    persona: platform-operator
+    profile: standard
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  intent: Validate DCM exposes one UDLM export surface over standard transports with per-subscriber policy
+  success_criteria:
+  - DCM exposes a single export/discovery surface consumable over standard transports (OTLP/Prometheus/bus)
+  - Schemas are discoverable by a consumer at subscription time (no out-of-band agreement)
+  - Export scope is policy-evaluated per subscriber (authorization + data classification)
+  - A second consuming tool attaches via the same path with no export-side change
+  - No DCM-side per-tool integration adapter is required
+  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: provider
+    interaction: information provider serves export/discovery over standard transports; message bus delivers
+      events
+  - domain: policy
+    interaction: per-subscriber authorization and data-classification scoping evaluated
+  - domain: data
+    interaction: telemetry exposed as UDLM-modeled discoverable data
+  - domain: audit
+    interaction: subscription and export access 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:
+- a9
+- observability
+- 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)
diff --git a/dav/use-cases/observability/telemetry-udlm-data-model.yaml b/dav/use-cases/observability/telemetry-udlm-data-model.yaml
new file mode 100644
index 0000000..a4568c8
--- /dev/null
+++ b/dav/use-cases/observability/telemetry-udlm-data-model.yaml
@@ -0,0 +1,55 @@
+uuid: uc-telemetry-udlm-data-model
+handle: observability/telemetry-udlm-data-model
+version: 1.0.0
+scenario:
+  description: 'Validation UC for A9: confirm UDLM models the telemetry-export data — metrics, lifecycle/drift/policy
+    events, log records, and audit records as UDLM-modeled, schema-discoverable entities, plus a published
+    event catalog vocabulary for the curated event stream.'
+  actor:
+    persona: platform-operator
+    profile: standard
+  perspectives:
+    - sre
+    - compliance-auditor
+  intent: Validate UDLM models telemetry/events/audit as schema-discoverable data + event catalog
+  success_criteria:
+  - Metrics, events, log records, and audit records are modeled as UDLM entities
+  - Schemas for those entities are discoverable (machine-readable) by consumers
+  - A published event-catalog vocabulary is modeled for the curated event stream
+  - Data-classification and tenancy are modeled on telemetry for per-subscriber scoping
+  - Retention governance for exported telemetry is representable
+  dimensions:
+    lifecycle_phase: new_request
+    resource_complexity: composite_service
+    policy_complexity: system_defaults_only
+    provider_landscape: multiple_eligible
+    governance_context: audit_heavy
+    failure_mode: happy_path
+  profile: standard
+  expected_domain_interactions:
+  - domain: data
+    interaction: telemetry/events/audit modeled as schema-discoverable UDLM entities + event catalog
+  - domain: policy
+    interaction: data-classification + retention modeled for scoping
+  - domain: audit
+    interaction: export access 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:
+- a9
+- observability
+- 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)
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..eaa4322
--- /dev/null
+++ b/dav/use-cases/observability/udlm-universal-telemetry-export.yaml
@@ -0,0 +1,83 @@
+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. 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
+  perspectives:
+    - application-team-member
+    - sre
+    - compliance-auditor
+  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
+  - 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
+    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 + event catalog exposed as UDLM-modeled,
+      schema-discoverable data
+  - domain: provider
+    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
+  - domain: audit
+    interaction: subscription lifecycle and export access recorded in the tamper-evident
+      audit chain
+generated_by:
+  mode: authoring
+  source: llm-guided
+  model: claude-opus-4-8
+  prompt_version: seed-1.0
+  timestamp: '2026-06-07T18:30:00.000000+00:00'
+tags:
+- observability
+- udlm
+- telemetry-export
+- standard-transports
+- otlp
+- prometheus
+- message-bus
+- universal-consumption
+- happy-path
+- standard-profile
+- foundational
+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)'
diff --git a/dav/use-cases/osac/001-cloud-provider-registration.yaml b/dav/use-cases/osac/001-cloud-provider-registration.yaml
new file mode 100644
index 0000000..71f7365
--- /dev/null
+++ b/dav/use-cases/osac/001-cloud-provider-registration.yaml
@@ -0,0 +1,60 @@
+uuid: uc-2f4e1dfa-7159-415a-b9c6-330aec525284
+handle: osac/cloud-provider-registration
+version: 1.0.0
+scenario:
+  description: >-
+    A cloud-operator stands up a sovereign cloud (OSAC) and registers it with the platform as a
+    provider. Registration is a declaration in portable terms: the cloud's capabilities (which
+    resource kinds it can realize), its advertised capacity, and — because it is sovereign — its
+    residency and jurisdiction guarantees. The platform does not learn the cloud's native API; it
+    records the declared capability and sovereignty surface as data, so that later placement routes
+    intent to this cloud on capability, not on hard-coded knowledge of it. Building a new cloud
+    provider is therefore an additive act: the substrate is unchanged, a new placement target
+    appears, and the cloud remains swappable because it will naturalize intent at its own edge.
+  actor:
+    persona: cloud-operator
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - provider-owner
+    - security-officer
+    - sovereignty-authority
+  intent: >-
+    Register a sovereign cloud as a provider by declaring its capabilities, capacity, and
+    residency/jurisdiction guarantees as portable data — so the platform can place intent onto it
+    by capability without knowing its native form
+  success_criteria:
+  - The cloud's capabilities are recorded as declared data, not inferred — placement will match on them
+  - The advertised capacity is carried as data the platform can route against
+  - The residency and jurisdiction guarantees are declared and bound to the provider, not asserted out of band
+  - Registration adds a placement target without any change to the substrate or existing providers
+  - The cloud's native format is nowhere in the substrate — naturalization is reserved to its edge
+  dimensions:
+    lifecycle_phase: provisioning
+    resource_complexity: composite_service
+    policy_complexity: multi_validation
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: the provider's capability, capacity, and sovereignty guarantees are recorded as declared data
+  - domain: policy
+    interaction: registration is validated against the provider contract and the sovereignty declaration is admitted
+  - domain: provider
+    interaction: the cloud is the provider; it declares its surface and will naturalize intent at its edge (T9 / ADR-023)
+  - domain: audit
+    interaction: the registration, its declared capabilities, and the sovereignty binding are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: osac-persona-coverage-2026-07-27
+  timestamp: '2026-07-27T19:00:00Z'
+tags:
+- osac
+- cloud-operator
+- provider-registration
+- sovereignty
+- capability
diff --git a/dav/use-cases/osac/002-sovereign-capacity-advertisement.yaml b/dav/use-cases/osac/002-sovereign-capacity-advertisement.yaml
new file mode 100644
index 0000000..f2e6640
--- /dev/null
+++ b/dav/use-cases/osac/002-sovereign-capacity-advertisement.yaml
@@ -0,0 +1,59 @@
+uuid: uc-98266749-fc7e-4ad7-8550-e6bd2951a8ef
+handle: osac/sovereign-capacity-advertisement
+version: 1.0.0
+scenario:
+  description: >-
+    A registered sovereign cloud (OSAC) advertises its live capacity and the capabilities it can
+    satisfy, as data. The platform's placement routes intent to eligible providers by matching the
+    intent's requirements against these advertised capabilities and remaining capacity — never by a
+    hard-coded map of which cloud does what. The cloud-operator's demand is that advertisement is
+    honest data the platform routes against: when capacity is exhausted the cloud is no longer
+    eligible for new placement, and when a capability is not advertised the cloud is never selected
+    for it. Advertisement carries the sovereignty envelope too, so a workload with a residency
+    requirement is only ever routed to a cloud whose advertised jurisdiction admits it.
+  actor:
+    persona: cloud-operator
+    profile: sovereign
+  perspectives:
+    - application-team-member
+    - platform-operator
+    - provider-owner
+    - solution-architect
+  intent: >-
+    Advertise a sovereign cloud's live capacity and capabilities as data so placement routes intent
+    to it on capability and remaining capacity — and never selects it beyond what it advertises
+  success_criteria:
+  - Placement matches intent to the cloud on advertised capability, not on hard-coded provider knowledge
+  - When advertised capacity is exhausted, the cloud is excluded from new placement
+  - A capability the cloud does not advertise is never placed onto it
+  - A residency-constrained workload is only routed to a cloud whose advertised jurisdiction admits it
+  - Advertisement is data the platform reads; the cloud's native capacity model stays at its edge
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: single_with_deps
+    policy_complexity: system_defaults_only
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_constrained
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: advertised capability and remaining capacity are carried as declared provider data
+  - domain: policy
+    interaction: placement matches intent requirements to advertised capability and sovereignty envelope
+  - domain: provider
+    interaction: the cloud reports its capacity/capability surface; native capacity accounting stays at its edge
+  - domain: audit
+    interaction: the placement decision records which advertised capabilities and capacity were matched
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: osac-persona-coverage-2026-07-27
+  timestamp: '2026-07-27T19:00:00Z'
+tags:
+- osac
+- cloud-operator
+- capacity-advertisement
+- placement
+- capability
diff --git a/dav/use-cases/osac/003-cloud-rehydration-from-intent.yaml b/dav/use-cases/osac/003-cloud-rehydration-from-intent.yaml
new file mode 100644
index 0000000..f6c22b4
--- /dev/null
+++ b/dav/use-cases/osac/003-cloud-rehydration-from-intent.yaml
@@ -0,0 +1,61 @@
+uuid: uc-6abbe5e3-056b-487a-94d9-bc7feafbb15e
+handle: osac/cloud-rehydration-from-intent
+version: 1.0.0
+scenario:
+  description: >-
+    A sovereign cloud (OSAC) is itself a UDLM-modeled estate — its own resources, dependency graph,
+    and sovereignty constraints are declared intent, not tribal setup. After an infrastructure loss,
+    the cloud-operator rebuilds the cloud by replaying that declared intent: the estate is realized
+    again in dependency order onto recovered hardware, its residency and jurisdiction guarantees
+    reasserted from the same declaration that first established them. Because the cloud is intent,
+    not a hand-built artifact, rehydration is a faithful replay rather than a reconstruction from
+    memory — and the sovereignty envelope is restored by construction, not re-justified after the
+    fact. The build of a sovereign cloud and its disaster recovery are the same act on the same
+    declared estate.
+  actor:
+    persona: cloud-operator
+    profile: sovereign
+  perspectives:
+    - platform-operator
+    - sre
+    - sovereignty-authority
+    - compliance-auditor
+  intent: >-
+    Rebuild a sovereign cloud after infrastructure loss by replaying its declared intent — realizing
+    the cloud's own estate in dependency order and reasserting its residency/jurisdiction guarantees
+    from the same declaration
+  success_criteria:
+  - The cloud's estate is realized from its declared intent in dependency order — a faithful replay, not a reconstruction
+  - Residency and jurisdiction guarantees are restored by construction from the original declaration
+  - The rehydrated cloud is verifiably the declared estate, not a drifted approximation
+  - No hand-built step is required that the declared intent does not capture
+  - The build of the cloud and its recovery are the same replay over the same estate
+  dimensions:
+    lifecycle_phase: rehydration_faithful
+    resource_complexity: full_stack
+    policy_complexity: recovery_policy
+    provider_landscape: single_eligible
+    governance_context: sovereignty_enforced
+    failure_mode: infrastructure_loss
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: the cloud's own estate is declared intent — the source of truth rehydration replays
+  - domain: policy
+    interaction: recovery policy orders the replay and reasserts the sovereignty envelope by construction
+  - domain: provider
+    interaction: the cloud-operator realizes the estate onto recovered hardware from the declaration
+  - domain: audit
+    interaction: the replay, the dependency order, and the restored sovereignty guarantees are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: osac-persona-coverage-2026-07-27
+  timestamp: '2026-07-27T19:00:00Z'
+tags:
+- osac
+- cloud-operator
+- rehydration
+- sovereignty
+- recovery
diff --git a/dav/use-cases/osac/004-provider-portability-new-cloud.yaml b/dav/use-cases/osac/004-provider-portability-new-cloud.yaml
new file mode 100644
index 0000000..99c619d
--- /dev/null
+++ b/dav/use-cases/osac/004-provider-portability-new-cloud.yaml
@@ -0,0 +1,59 @@
+uuid: uc-df8ecf5a-a5d2-46a5-923e-43eeb2b21af3
+handle: osac/provider-portability-new-cloud
+version: 1.0.0
+scenario:
+  description: >-
+    A second sovereign cloud (OSAC) is brought online and offered as a provider alongside the first.
+    Existing consumer intent — written in portable terms, with no provider-native detail — becomes
+    eligible to place onto the new cloud with no change to the intent, the substrate, or the other
+    providers. The new cloud naturalizes that portable intent into its own native form at its edge,
+    so adding it is purely additive: a placement target appears, portability is preserved, and a
+    workload can be rebuilt provider-portably onto it. This is the OSAC thesis made operational —
+    building a new sovereign cloud provider extends where intent can land without bending the model
+    toward any one cloud's vocabulary.
+  actor:
+    persona: cloud-operator
+    profile: sovereign
+  perspectives:
+    - solution-architect
+    - application-team-member
+    - provider-owner
+    - integrator
+  intent: >-
+    Bring a new sovereign cloud online as an additional provider so existing portable intent can
+    place onto it with no rewrite — the cloud naturalizing at its edge, the substrate unchanged
+  success_criteria:
+  - Existing portable intent becomes eligible for the new cloud with no change to the intent
+  - Adding the cloud changes neither the substrate nor the other providers — it is additive
+  - The new cloud naturalizes portable intent into its native form at its own edge
+  - A workload can be rebuilt provider-portably onto the new cloud from the same declaration
+  - No provider-native vocabulary from the new cloud enters the portable model
+  dimensions:
+    lifecycle_phase: rehydration_provider_portable
+    resource_complexity: composite_service
+    policy_complexity: multi_validation
+    provider_landscape: multiple_eligible
+    governance_context: sovereignty_constrained
+    failure_mode: happy_path
+  profile: sovereign
+  expected_domain_interactions:
+  - domain: data
+    interaction: consumer intent stays portable; the new provider is another eligible target for the same intent
+  - domain: policy
+    interaction: placement re-evaluates eligibility to include the new cloud without changing the intent
+  - domain: provider
+    interaction: the new cloud naturalizes portable intent at its edge and stays swappable (T9 / ADR-023)
+  - domain: audit
+    interaction: the added provider and the provider-portable placement are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: osac-persona-coverage-2026-07-27
+  timestamp: '2026-07-27T19:00:00Z'
+tags:
+- osac
+- cloud-operator
+- provider-portability
+- naturalization
+- placement
diff --git a/dav/use-cases/oversight/001-portfolio-rollup-and-gaps.yaml b/dav/use-cases/oversight/001-portfolio-rollup-and-gaps.yaml
new file mode 100644
index 0000000..0ac9b9a
--- /dev/null
+++ b/dav/use-cases/oversight/001-portfolio-rollup-and-gaps.yaml
@@ -0,0 +1,60 @@
+uuid: uc-71ec8be8-673a-4a81-a543-3c471a45e6b7
+handle: oversight/portfolio-rollup-and-gaps
+version: 1.0.0
+scenario:
+  description: >-
+    A director accountable for a portfolio of services across several teams needs one rolled-up view
+    of that portfolio's state — health, compliance posture, and open gaps — derived from the estate
+    graph rather than chased team by team. The demand is aggregate and computed: a gap or drift
+    anywhere in the portfolio surfaces to the director with its blast radius and the responsible
+    team, before it becomes an incident, and the rollup is a projection over the same declared and
+    realized data the operators work from, not a separately maintained report. The director does not
+    operate any resource; they consume assurance. The test for the model is whether an oversight
+    projection at portfolio scope is derivable at all, or whether only per-resource views exist.
+  actor:
+    persona: director
+    profile: prod
+  perspectives:
+    - executive
+    - manager
+    - compliance-auditor
+    - sre
+  intent: >-
+    Produce a rolled-up portfolio view — health, compliance, and gaps across teams — derived from the
+    estate graph, surfacing any gap or drift with its blast radius and responsible team before it
+    becomes an incident
+  success_criteria:
+  - The portfolio view is a projection over the estate graph, not a separately maintained report
+  - A gap or drift anywhere in the portfolio surfaces with its blast radius and the responsible team
+  - The rollup aggregates health and compliance posture across teams at portfolio scope
+  - The director consumes the assurance without operating any resource
+  - The projection is derived from the same declared and realized data operators work from — no parallel source
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: multi_dependent
+    policy_complexity: governance_matrix_enforcement
+    provider_landscape: mixed
+    governance_context: audit_heavy
+    failure_mode: partial_fulfillment
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: the portfolio rollup is a derived projection over the declared and realized estate graph
+  - domain: policy
+    interaction: gap/drift detection and blast-radius computation drive what surfaces to the director
+  - domain: provider
+    interaction: n/a — oversight consumes the aggregate; it does not dispatch to providers
+  - domain: audit
+    interaction: the surfaced gaps, their blast radius, and the responsible teams are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: osac-persona-coverage-2026-07-27
+  timestamp: '2026-07-27T19:00:00Z'
+tags:
+- oversight
+- director
+- portfolio-rollup
+- blast-radius
+- assurance
diff --git a/dav/use-cases/oversight/002-team-health-blocked-intents.yaml b/dav/use-cases/oversight/002-team-health-blocked-intents.yaml
new file mode 100644
index 0000000..ec1d622
--- /dev/null
+++ b/dav/use-cases/oversight/002-team-health-blocked-intents.yaml
@@ -0,0 +1,59 @@
+uuid: uc-5425fbcf-8ffa-414c-9c45-3a25a83e0a77
+handle: oversight/team-health-blocked-intents
+version: 1.0.0
+scenario:
+  description: >-
+    A manager accountable for a single team's services needs to see, at team scope, what their
+    team's intents are doing — specifically which are blocked or unsatisfiable and why. The demand
+    maps directly onto the intent-fulfillment surfacing contract, scoped to the team: a blocked or
+    refused intent surfaces with its root cause named and the owner, so the manager sees "this is
+    stuck on that unmet dependency" rather than a silent pending. Alongside it, the team's capacity,
+    cost, and policy posture are visible without standing up a bespoke report — a projection at team
+    scope over the same estate data. The manager operates nothing directly; they are accountable for
+    delivery and need the team's operational health surfaced, not assembled by hand.
+  actor:
+    persona: manager
+    profile: prod
+  perspectives:
+    - application-team-member
+    - sre
+    - finance-analyst
+    - director
+  intent: >-
+    Surface a team's blocked or unsatisfiable intents with root cause and owner, and the team's
+    capacity/cost/policy posture, as a team-scoped projection over the estate — not a bespoke report
+  success_criteria:
+  - A blocked or refused team intent surfaces with its root cause named and the owner (ADR-052 surfacing, team-scoped)
+  - The manager sees why an intent is stuck, not a silent pending
+  - The team's capacity, cost, and policy posture are a projection over the estate, not a hand-built report
+  - The view is scoped to the manager's team without a parallel data source
+  - The manager consumes the team's operational health without operating any resource directly
+  dimensions:
+    lifecycle_phase: day2_operations
+    resource_complexity: multi_dependent
+    policy_complexity: multi_validation
+    provider_landscape: mixed
+    governance_context: internal_audit
+    failure_mode: partial_fulfillment
+  profile: prod
+  expected_domain_interactions:
+  - domain: data
+    interaction: the team view is a scoped projection over the team's declared and realized intents
+  - domain: policy
+    interaction: intent-fulfillment surfacing (root cause + owner) scoped to the team drives what the manager sees
+  - domain: provider
+    interaction: n/a — the manager consumes the team's aggregate health; no dispatch
+  - domain: audit
+    interaction: the surfaced blocked intents, their root causes, and owners are recorded
+generated_by:
+  mode: authoring
+  source: human-authored
+  model: null
+  prompt_version: osac-persona-coverage-2026-07-27
+  timestamp: '2026-07-27T19:00:00Z'
+tags:
+- oversight
+- manager
+- team-health
+- intent-fulfillment
+- surfacing