Skip to harness content
Open technical reference map

Assurance source reference

Enterprise Control Model v2

Complete canonical source reference from docs/ENTERPRISE_CONTROL_MODEL_V2.md.

Canonical pathdocs/ENTERPRISE_CONTROL_MODEL_V2.mdRevision69bab1cInspect source

Enterprise Control Model v2

Valdris v0.8 retains the v0.7 control-level typed-assurance model and adds provenance, neutrality, privacy, schema compatibility, portable proof, independent review, typed RCA, and coherent run-packet enforcement. The thirteen production layers remain the full-stack map, but each required layer expands into named controls whose evidence is machine-resolved before the run can finish.

Decision model

  1. Select the requested evidence/maturity profile: prototype, production, enterprise, or regulated.
  2. Detect composable workload profiles such as SaaS, mobile, payments, realtime, regulated/high-impact, and AI/agentic; the strongest applicable floor determines the effective assurance tier.
  3. Classify every canonical assurance domain as required or not-applicable.
  4. Apply hard dependencies from controls/production-layers.v2.json; treat conditionalDependencies as applicability questions rather than automatic expansion.
  5. Prove every required control. A whole domain cannot pass on one generic sentence.
  6. Record residual risk and obtain a human approval where the Red Zone or policy requires it.
  7. Re-run the gate against the exact commit and environment being handed off.

The catalog currently contains 39 controls across:

frontend -> backend -> data -> auth -> deployment -> cloud -> CI/CD -> security -> rate limits -> cache/CDN -> scaling -> observability -> recovery

The arrows describe an assurance map, not a fixed build order. dependencies form the enforced acyclic prerequisite graph; conditionalDependencies document common relationships that classification or human review must resolve without over-projecting unrelated systems.

Typed evidence

Passing controls use one or more of these evidence types:

TypeWhat the gate proves
artifactReal non-symlink path exists inside the repo; enterprise/regulated evidence matches SHA-256, run, commit, and environment.
commandNamed command exited zero and its captured output file matches the recorded SHA-256 digest.
metricObserved numeric value satisfies a declared operator and target over a named window/source.
approvalA named human granted a scoped approval; an agent cannot self-approve.
provider-reportHTTPS provider result passed at a recorded time and is digest-bound.

Evidence is subject-bound by control ID, run ID, profile, commit, environment, producer/version, trust tier, and a profile-specific freshness window. The aggregate gate binds the packet to current wall-clock time and Git HEAD when the target is a Git worktree. A URL, filename, command string, or exitCode: 0 alone is not enterprise proof.

Waivers and skips

  • A required layer and required control cannot be skipped.
  • A layer may be not-applicable only with a workload-specific reason.
  • failed, pending, blocked, required, and needs_approval are blocking states.
  • A human approval proves authorization, not technical correctness. It cannot convert a failing metric or missing artifact into a pass.
  • Every run carries waivers/waivers.json, even when the ledger is empty. Active waivers require a control ID, human risk owner and approver, compensating controls, HTTPS remediation issue, expiry, and a token-gated bridge approval event. Valdris does not silently turn waivers into technical passes.

Commands

npm run production:gate
npm run enterprise-ai:gate

The v2 validator retains read compatibility for historical uash.production-readiness.v1 files. Newly commissioned packs generate v2 controls and validators.

Standards posture

The implementation is designed as an evidence orchestration layer, not a claim of certification. The detailed primary-source baseline, crosswalk, contradictions in the supplied PDFs, and missing-control analysis are in research/enterprise-ai-2026/enterprise-controls.md. The control model should be reviewed whenever its source standards or a workload's regulatory obligations change.