Compliance Controls
The DLC defines 10 compliance controls that together ensure every initiative has a traceable, auditable path from intent to implementation. The Compliance Report (cat-compliance-report) evaluates all 10.
The 10 Controls
Section titled “The 10 Controls”Control 1: Intent Capture
Section titled “Control 1: Intent Capture”What: An Intent Statement or Intent Brief exists with required fields (who, what, why, outcome, metrics).
Why: Without documented intent, there’s no way to verify that what was built matches what was needed.
Evidence: _cat/artifacts/intent/intent-statement-*.md or quick-intent-*.md
Control 2: Scope Definition
Section titled “Control 2: Scope Definition”What: In/out scope clearly defined with measurable boundaries.
Why: Unbounded scope leads to scope creep, missed deadlines, and delivered features that nobody asked for.
Evidence: Scope section in Intent Brief with explicit “In Scope” and “Out of Scope” lists.
Control 3: Architecture Contract
Section titled “Control 3: Architecture Contract”What: An ARC exists with enforceable MUST/MUST NOT constraints.
Why: Without constraints, architecture is advisory. The ARC makes it contractual.
Evidence: _cat/artifacts/architecture/arc.md or quick-arc.md
Control 4: AI Governance
Section titled “Control 4: AI Governance”What: AI governance section present in the ARC, defining boundaries, review requirements, and testing expectations.
Why: AI-assisted development without governance creates blind spots in review, testing, and accountability.
Evidence: AI Governance section in the ARC.
Control 5: Constraint Traceability
Section titled “Control 5: Constraint Traceability”What: ARC constraints trace to business needs in the Intent Brief.
Why: Constraints without business justification become dogma. Every rule should exist for a reason.
Evidence: Traceability notes in ARC constraints.
Control 6: Bolt Decomposition
Section titled “Control 6: Bolt Decomposition”What: Features decomposed into bolts with ARC constraint mapping.
Why: Without bolt-level decomposition, it’s impossible to verify which constraints apply where.
Evidence: _cat/artifacts/construction/bolt-spec-*.md with ARC constraint references.
Control 7: Construction Compliance
Section titled “Control 7: Construction Compliance”What: Bolt execution artifacts reference and satisfy mapped ARC constraints.
Why: Executing code without constraint awareness defeats the purpose of the ARC.
Evidence: _cat/artifacts/construction/bolt-execution-*.md with compliance status.
Control 8: Code Review
Section titled “Control 8: Code Review”What: Code reviews completed against ARC constraints and AI governance rules.
Why: Traditional code review focuses on code quality. DLC code review also verifies constraint compliance.
Evidence: _cat/artifacts/construction/code-review-*.md
Control 9: Adherence Verification
Section titled “Control 9: Adherence Verification”What: Post-construction ARC adherence check completed with constraint-by-constraint results.
Why: Self-reported compliance during construction needs independent verification.
Evidence: _cat/artifacts/validation/arc-adherence-report.md
Control 10: Acceptance
Section titled “Control 10: Acceptance”What: Work acceptance validates completed work against Intent Brief success criteria.
Why: Technical compliance (Controls 1–9) doesn’t guarantee business value delivery.
Evidence: _cat/artifacts/validation/work-acceptance-*.md
Compliance Levels
Section titled “Compliance Levels”Not every project needs all 10 controls at full depth:
| Project Type | Minimum Controls | Recommended Controls |
|---|---|---|
| Bug fix | 1, 2 | 1, 2, 3, 8 |
| Small enhancement | 1, 2, 3 | 1–4, 8, 10 |
| New feature | 1–6 | All 10 |
| New system | All 10 | All 10 |
Running the Compliance Report
Section titled “Running the Compliance Report”cat-compliance-reportVera scans all artifacts and produces the 10-control matrix. See How to Run a Compliance Report.
See Also: Run Compliance Report · AI Governance · Validation Phase