Evidence-driven delivery for BUILD and enforceable runtime governance for live AI systems.
A live system view of INTENT v0.5: Proof Tier (P0-P4), BUILD Autonomy Tier (A0-A4), and the runtime governance boundary that controls live agent behavior.
Live phase
FRAME to EXPLORE
Define outcomes, constraints, and proof expectations through an Intent Contract. This phase creates clarity before execution begins.
A small, versioned set of non-negotiable principles that every Intent Contract, every agent action, and every phase must satisfy. The constitution is the project's supreme constraint layer - it does not change per feature, only through a formal amendment process.
The constitution defines what is always true. Intent Contracts define what should be true for a specific change. An Intent Contract cannot contradict the constitution. If it needs to, the constitution must be amended first.
Basic automated checks; coverage is inconsistent.
Spec continuum
AI implements; humans review + run proof.
Active handoff
FRAME to EXPLORE
P1 (Repeatable) x A2 (Implement): execution is faster, but delivery still depends on manual coordination and review. Raise proof strength first, then expand autonomy safely.
2-4 people split core capabilities and use shared policies for proof and autonomy.
Define what must be true in outcomes before discussing how work will be done.
Move work continuously through proof gates instead of waiting for calendar rituals.
Human leverage comes from cross-domain judgment while agents execute implementation tasks.
Policy, risk handling, and quality checks are built into the system from the start.
Teams should know what was agent-generated, human-authored, and human-reviewed.
Regularly test assumptions from pre-agent workflows and re-evaluate what is now feasible.
Use runtime governance when an AI system is live, customer-facing, or safety-critical. Build-time governance defines what should be true. Runtime governance defines how to enforce it in production behavior.
Defines the positive boundary of what the live agent is authorized to say or do.
Core structure
Governance authority
Binding runtime policy referenced by the Constitution and versioned with the Intent Contract.
Defines every path from agent-handled interaction to human involvement, including failure handling.
Core structure
Governance authority
Binding operational safety contract referenced by the Intent Contract and validated during runtime testing.
Defines valid interaction states, transition triggers, and per-state permissions.
Core structure
Governance authority
Behavioral runtime architecture that must exist before prompt/runtime implementation.
Constitution defines non-negotiables. Runtime artifacts define the live-operating boundary and fail-safe behavior.
| Artifact | Required update |
|---|---|
| Constitution | Add Runtime Governance Requirements that make Trust Envelope, Escalation Contract, and Interaction State Model mandatory for live, customer-facing, or safety-critical agents. |
| Intent Contract | Add version references for the three runtime artifacts plus a Runtime Governance validation section in the proof plan. |
| Scenario Bank | Make scenarios state-aware with state paths, escalation classes, and trust-envelope category mapping. |
| Proof Report | Track runtime metrics: unsafe-answer rate, false/missed escalation rate, state violation rate, and escalation success rate. |
| Autonomy Policy | Separate BUILD autonomy tiers from RUNTIME output authority; runtime authority is bounded by the Trust Envelope. |
BUILD autonomy is budgeted by risk and earned by proof. RUNTIME authority is bounded by the Trust Envelope and Escalation Contract.
BUILD: humans lead and agents assist. RUNTIME: trust envelope is narrow and escalation is fast.
BUILD: agents implement while humans review. RUNTIME: bounded categories with explicit escalation classes.
BUILD: agents can operate under exception review. RUNTIME: autonomy expands only inside a validated trust envelope.
Drift is when behavior diverges from declared governance: Constitution and Intent Contract in BUILD, plus Trust Envelope, Escalation Contract, and Interaction State Model in RUNTIME. INTENT treats drift as a named, instrumented failure mode at three levels.
Scenario Bank is the intent-level memory of correctness. It captures expected outcomes, failure modes, runtime signals, and state paths so validation stays aligned with real behavior.
Spec validators run in CI. If generated code violates Constitution constraints or Intent Contract commitments, the build fails. This includes schema validation, contract tests, and architectural conformance checks.
Production behavior is continuously checked against Trust Envelope categories, escalation paths, and state-transition rules. When behavior diverges beyond tolerance, alerts fire and the relevant Intent Contract is flagged for review.
The Intent Contract itself can drift from reality when telemetry reveals incorrect assumptions or when contracts are not updated to match shipped behavior. Detection compares stated outcomes against production metrics.
| Dimension | Agile Scrum | INTENT |
|---|---|---|
| Fundamental unit | User story | Intent Contract |
| Cadence | Time-boxed sprints | Continuous flow through proof gates |
| Team structure | Fixed role Scrum team | Capabilities + agents + policy |
| Planning | Sprint planning | Continuous contract definition |
| Status updates | Daily standup | Evidence and exception dashboards |
| QA | Embedded QA | Scenario Bank + Proof Tiers |
| Execution | Humans write | Agents execute under gates |
| Validation | Test suites as primary | Scenario outcomes + supporting tests |
| Bottleneck | Coordination overhead | Intent clarity + evidence quality |
| Governance | Process compliance | Policy as code |
| Invariants | Implicit team norms | Constitution (versioned, enforced) |
| Drift handling | Manual code review | Automated build-time, runtime, and spec drift detection |
INTENT is an operating model, not an engineering methodology. It composes with - rather than competes against - the emerging SDD tooling ecosystem.
INTENT (Operating Model)
Team structure, roles, ceremonies, governance posture, rollout cadence, and the organizational contract between humans and agents.
SDD (Engineering Methodology)
Spec-first workflows and pipelines such as constitution, specify, plan, tasks, implement, validate, and drift detection.
Agent Tooling (Execution Runtime)
Agents that write code, run tests, deploy, and monitor in IDE and CI runtime contexts.
INTENT layer (this framework): Defines team structure, roles, ceremonies, governance posture, rollout cadence, and the organizational contract between humans and agents. Answers who decides, who reviews, what evidence is needed, and how autonomy scales.
SDD layer (engineering methodology): Defines spec-first workflows where structured specifications drive generation, validation, and drift detection. GitHub Spec Kit, AWS Kiro, and Tessl formalize this into repeatable pipelines. INTENT BUILD and VALIDATE phases execute through these workflows.
Agent tooling layer (execution runtime): Claude Code, Cursor, GitHub Copilot, Microsoft Amplifier, and OpenAI Codex. INTENT and SDD remain tool-agnostic: they define constraints and workflows while tools execute.
Teams adopting INTENT should select SDD tooling that fits their stack and configure it to enforce their Constitution and Intent Contracts. The framework does not prescribe specific tools because the ecosystem is evolving rapidly.
INTENT gives teams a governance layer for who decides, what proof is required, and how autonomy scales in BUILD plus enforceable runtime boundaries for live systems. GitHub Spec Kit gives teams a spec-driven implementation pipeline. The integration page combines both into a single operating model and includes ready-to-use templates.
Use INTENT to improve delivery by tightening intent quality, increasing proof strength, and scaling autonomy only when evidence supports it - with runtime governance artifacts for live agent behavior.
Contact for implementation help