What Is an ARC?

An Architecture Reference Contract (ARC) is the central governance document in the DLC. Unlike traditional architecture documents that describe design decisions, the ARC defines enforceable constraints — rules that can be verified after construction.

ARC vs Traditional Architecture Docs

Aspect	Traditional Architecture Doc	ARC
Purpose	Communicate design decisions	Govern construction
Tone	Descriptive (“We will use…”)	Prescriptive (“MUST use…”)
Enforcement	Honor system	Machine-checkable via adherence reports
AI governance	Not addressed	Built-in section
Traceability	Optional	Required — every constraint traces to intent

Anatomy of an ARC

1. Context and Technology Stack

The system’s technology choices: runtime, frameworks, databases, deployment model. This sets the foundation for constraints.

2. Constraints

The heart of the ARC. Constraints use RFC 2119 keywords:

MUST — Non-negotiable. Failure to comply is a defect.
MUST NOT — Explicit prohibition. Violation is a defect.
SHOULD — Strong recommendation. Deviation requires justification.
MAY — Permitted but not required. Documents optionality.

Each constraint has:

A unique ID (e.g., MUST-001)
A clear, specific statement
Traceability to a business need in the Intent Brief

3. AI Governance

Every ARC includes rules for AI-assisted development:

Which code paths can be AI-generated
Review requirements for AI-generated code
Testing requirements specific to AI-produced artifacts
Boundaries between AI-assisted and human-only work

4. Testing Requirements

Testing strategy that traces to constraints:

Which constraint categories require unit tests
Integration testing requirements
Security testing for relevant constraints
Performance testing thresholds

How the ARC Is Used

The ARC governs the entire Construction and Validation phases:

ARC Created
  ↓
Bolt Writer reads ARC → Maps constraints to bolts
  ↓
Bolt Execution reads ARC → Enforces constraints during coding
  ↓
Code Review reads ARC → Verifies compliance
  ↓
ARC Adherence Check reads ARC → Final compliance matrix

Quick ARC vs Full ARC

Aspect	Quick ARC	Full ARC
Scope	What’s changing only	Full system
When	Small brownfield changes	Greenfield or major features
Constraints	Delta from existing architecture	Comprehensive
Effort	10–20 minutes	30–60 minutes

Constraint Quality

Good constraints are the difference between a useful ARC and a rubber stamp.

Bad: “MUST handle errors properly”

Too vague. What’s “properly”? How do you check?

Good: “MUST return structured error responses using the ErrorResponse schema with appropriate HTTP status codes (4xx for client errors, 5xx for server errors)”

Specific. Testable. Verifiable during adherence check.

See Also: Build an ARC · Architecture Phase · AI Governance