[DCM-08] DAV validation corpus

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.

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.