The Agentic Constitution Format — the EXA Standard · Reid Webber

01 · Definition

The structured, five-field syntax for a constraint block inside an Agentic Constitution: TRIGGER, AGENT MUST, AGENT MUST NOT, COST IF RENDERED INCORRECTLY, and DISCOVERY SOURCE. It is the machine-readable unit an AI coding agent executes against directly, replacing the annotated screen a developer once interpreted by hand.

02 · Format / template

Constraint block

TRIGGER: CMS redetermination rule update changes a member's coverage status
AGENT MUST: Resolve eligibility against the central system of record; Render lapsed status explicitly, with effective date
AGENT MUST NOT: Render a lapsed member as active under any cached or forked view
COST IF RENDERED INCORRECTLY: Claims liability; caseworker acts on false eligibility; compliance exposure. Severity: CRITICAL
DISCOVERY SOURCE: Production incident — override audit, regional health network. Adjacent states to audit: retroactive termination, dual-eligibility, grace-period

The five fields above specify one constraint block. What follows governs the space the block operates inside: what any agent may do before a ratified constraint set exists, what a specific class of tool is permitted to do with one, and — where a vendor or COTS platform is involved — what the gate can even see well enough to certify.

Three layers, one direction of authority:

Part One, the Agent Permission Boundary — what’s true in principle, for any agent.
Part Two, the Agent Permission Matrix — what’s true in practice, per tool class. It may narrow Part One. It never widens it.
Part Three, the gate’s reduced authority for vendor surfaces — not a fourth rule, but the honest limit underneath Part Two’s Vendor Envelope requirement, for the one row where a vendor platform is doing the acting.

Where any two of these appear to disagree, the earlier one governs.

Part One — The Agent Permission Boundary

The governing statement: agents operate with full autonomy inside strict, mathematically defined boundaries — Governed Autonomy. They are not supervised turn-by-turn; they are constrained by a specification written in advance. Agents assemble. They never invent.

What an agent may do unconditionally

No per-instance human review is required for any of the following. The constraint set itself is the review.

Permitted action	Precondition
Assemble surfaces from ratified constraint sets and governed components	A resolvable, versioned constraint-set reference exists for the surface
Render every governed state defined in the constraint set	The state is named in the State Inventory and carries a constraint block
Apply tokens, theming, and accessibility derivations	Token set version parity confirmed across render targets
Generate code, markup, and platform artifacts from the Semantic Handoff	The constraint file resolves without a clarifying question
Run automated accessibility and constraint-correctness checks	The root constraints are published
Emit telemetry — consumption signals, override events against versioned constraint IDs	An aggregated log exists to receive them
Propose amendments from detected patterns	The proposal enters the queue; it does not self-ratify

What requires a ratified constraint set before the agent may act

The agent may not proceed until the Logic-Review Gate certifies.

Action	Requirement
Operating on any state at HIGH or CRITICAL severity	A ratified constraint set and a ratified Fallback State — with a capacity ceiling and terminal state if the fallback is `HUMAN_QUEUE`
Operating on a surface with a novel state not previously certified	A new constraint block through the Logic-Review Gate; CRITICAL severity certifies centrally only
Any third-party or vendor agent touching enterprise states	A ratified Vendor Envelope — data reach, authorized actions, states routed, halted-state fallback
Acting after a constraint amendment at CRITICAL severity	A forced-adoption date across the full blast radius
Cross-domain action spanning two constraint sets	Arbitration by the Principal Enterprise Experience Architect where the two sets conflict on the same state

What is forbidden regardless

No constraint set authorizes any of the following. These are boundary conditions of the framework itself, not gaps a well-written constraint could close.

Forbidden	Why	Severity if violated
Resolving an unnamed state by best guess	This is the Silent Render — the failure mode with no invoice, surfacing only at the compliance incident. The agent must halt and route the gap, not resolve it	CRITICAL
Inventing a component, layout, or token	Agents assemble; they never invent. An invented component is ungoverned by construction	CRITICAL
Rendering a state the constraint set’s own AGENT MUST NOT prohibits	The prohibition is the boundary	CRITICAL
Self-ratifying its own constraint set or amendment	Ratification is a human authority granted by the org chart. An agent that ratifies has dissolved the gate	CRITICAL
Auto-resolving to a default where the decision itself is the consequential act	Prior authorization, a claims determination, an eligibility ruling, a safety classification — auto-determination under load is the original failure this format exists to prevent, arriving through the back door of the fallback	CRITICAL
Operating past a `HUMAN_QUEUE` capacity ceiling with no stated terminal state	A ceiling with no terminal state is not a ratified fallback	CRITICAL
Writing to the constraint library	The library is the specification. An agent that edits its own governing document has no boundary	CRITICAL
Executing against a constraint set whose binding is an attestation rather than a versioned reference	A checkbox records a claim; a dependency blocks a build	HIGH
Suppressing or filtering its own override telemetry	Override events are the substrate the Amendment Protocol’s structural signal is matched across; suppression makes it undetectable by construction	CRITICAL

When an agent hits one of these boundaries mid-task, the required behavior is fixed: halt, emit an override event against the governing constraint ID, and enter the ratified Fallback State for that constraint. It does not guess, does not approximate, and does not escalate to a human in real time as a substitute for a defined fallback — real-time human escalation at inference speed is not a fallback, it is an unstaffed queue.

Part Two — The Agent Permission Matrix

Part One states what’s true in principle, for any agent. This matrix states what’s true in practice, per tool class — design-context readers, build agents, token pipeline jobs, bridge jobs, telemetry emitters, amendment-proposing agents, and vendor platform agents — crossed against severity tier. The matrix may narrow Part One. It may never widen it. Where the two appear to disagree, Part One governs.

Severity tier refers to the highest severity of any state the surface a tool touches can enter.

Tool class	Action	MEDIUM	HIGH	CRITICAL	Vendor Envelope required?
Design-context reader (Figma MCP, design system MCP)	Read component tree, variables, Code Connect mappings	Unsupervised	Unsupervised	Unsupervised	Yes — third-party data reach
	Write to a design file	Forbidden, any tier — the canvas holds no authority; a write-back path makes the agent an author of the rendering while the Semantic Layer remains the source of truth, creating two sources of truth	Forbidden	Forbidden	—
Build agent (Claude Code, Codex, Cursor, Copilot)	Assemble a surface from a ratified constraint set	Unsupervised	Requires a ratified constraint set and a ratified Fallback State	Requires the above, plus central certification	Yes
	Generate code for a novel state not previously certified	Halt and route	Halt and route	Halt and route	—
	Run automated checks (accessibility, correctness)	Yes	Yes	Yes	Yes
	Commit to a mainline branch	Yes, with pre-merge checks passing	Yes, with pre-merge checks passing	Yes, with tool-call authorization and pre-merge checks both passing — no separate human merge gate at CRITICAL	—
	Write to the constraint library	Forbidden	Forbidden	Forbidden	—
Token pipeline job	Build per-platform artifacts from DTCG source	Yes	Yes	Yes	—
	Create a new token	Propose only, any tier — a new token is a Semantic Layer change, certified centrally at CRITICAL	Propose only	Propose only	—
Bridge job (canvas to structure)	Extract into the registered schema	Yes	Yes	Yes	Yes — reads a third-party surface
	Write outside the registered schema	Fails the job	Fails the job	Fails the job	—
Telemetry emitter	Emit override, deviation, consumption events	Required, not optional	Required	Required	—
	Filter, sample, or suppress its own events	Forbidden	Forbidden	Forbidden	—
Amendment-proposing agent	Detect a pattern and file a formatted amendment request	Propose only	Propose only	Propose only	—
	Set the Blast Radius Verified field	Ratifier only, against centralized telemetry	Ratifier only	Ratifier only	—
	Self-ratify any amendment	Forbidden	Forbidden	Forbidden	—
Vendor platform agent (COTS — e.g. a CRM or ITSM agent acting on enterprise states)	Act on states routed to it within a ratified envelope	Yes	Requires a ratified envelope and a halted-state fallback	Requires the above, central certification, and a named vendor-relationship owner where any CRITICAL constraint is unheld	Always
	Act on a state not routed to it in the envelope	Forbidden	Forbidden	Forbidden	—
Any agent, any class	Auto-resolve to a default where the decision itself is the consequential act	Forbidden	Forbidden	Forbidden	—
	Operate past a `HUMAN_QUEUE` ceiling with no stated terminal state	Forbidden	Forbidden	Forbidden	—

When an action this matrix doesn’t resolve comes up, the same fallback discipline from Part One applies: halt, emit an override event, enter the ratified Fallback State. And when the enforcement plane itself is unavailable — gateway down, policy engine unreachable — every tool class fails closed into its ratified Fallback State. It does not proceed on partial enforcement.

Part Three — The Gate’s Reduced Authority for Vendor Surfaces

Part Three is not a fourth independent rule. It’s the honest limit underneath the Vendor Envelope requirement Part Two’s vendor-platform-agent row already names — what the Logic-Review Gate can actually certify, specifically, once a vendor or COTS platform is in the picture.

It cannot certify vendor internals it cannot see. This is not a limitation to work around. It’s a structural fact the governance model is built to accommodate honestly rather than paper over.

The gate CAN certify	The gate CANNOT certify
The envelope — data reach, authorized actions, routed states, fallback	The vendor’s internal decision logic, model behavior, or algorithm
Integration code — everything the enterprise owns connecting the platform to internal systems	Whether the vendor’s platform behaves as documented — a procurement and contractual question, not a Logic-Review Gate function
Configuration state — that the platform’s settings match the ratified envelope	Undocumented vendor behavior discovered only through production use, until formally raised and either documented or contractually addressed
Customization code — enterprise-authored code running in vendor extension points	Vendor code the enterprise has no visibility into, regardless of how the customization code around it is written

The vendor’s internal logic stays permanently outside this framework’s Blast Radius, for the life of the vendor relationship. That’s not a gap in the framework — it’s the framework correctly recognizing the actual boundary of what it can govern, and directing all governance energy at the boundary that is genuinely enterprise-controlled: the envelope, not the vendor’s code.

The direct answer to the natural objection — “if you can’t see inside the vendor’s platform, how can you claim to govern it?” EXA does not claim to govern the vendor’s platform. It governs the boundary around it — the only boundary that is actually the enterprise’s to govern, and the only one whose failure the enterprise bears liability for, regardless of whose code caused it.

03 · Worked example

The constraint block above is the format's founding worked example — 'Member Eligibility: Post-Redetermination,' first published in EXA vs. SDD (July 2026). It encodes the incident that produced it: at a regional health network, three of the four product squads owning the member-eligibility experience had forked the eligibility view off the central system, and a CMS redetermination rule change left one forked view rendering a lapsed member as active — a state every engineering gate passed, because it was never a property of the code. The block names the trigger, the required and prohibited renderings, the cost the organization carries if the surface renders wrong, and the discovery source, including the adjacent states that audit flags for review. The COST IF RENDERED INCORRECTLY field is the load-bearing difference from an engineering specification: no code-correctness format carries a column for consequence.

Build your own constraint block

The block above is the format proved once. This builds another: fill the five fields and watch the block assemble as you type, then take it with you. Everything runs in this browser — nothing is sent anywhere, and nothing is stored.

Block name (optional)

Names the state this block governs, as a title comment. Carried as a naming convention, not a structural field.

Trigger

The event, threshold, or data condition that places the system in this state.

Agent must

Required actions and outputs.

Agent must not

Prohibited actions and outputs.

Cost if rendered incorrectly

The organizational consequence — claims liability, compliance exposure, operational error, revenue impact. This is the field no engineering format carries.

Severity

Discovery source

How this state was found — production incident, regulatory document, stakeholder interview, telemetry signal.

Adjacent states to audit (optional)

Other states worth checking for the same gap — related eligibility categories, adjacent workflow steps, similar triggers in other systems.

# CONSTRAINT — Untitled

TRIGGER: — not yet specified —
AGENT MUST: — not yet specified —
AGENT MUST NOT: — not yet specified —
COST IF RENDERED INCORRECTLY: — not yet specified —
DISCOVERY SOURCE: — not yet specified —

Fill all five fields and choose a severity to copy the block.

04 · Version history

2026-08-16Added three new MDX-body sections — the Agent Permission Boundary (Part One), the Agent Permission Matrix (Part Two), and the gate's reduced authority for vendor surfaces (Part Three) — appended after the existing worked constraint block, not replacing it. Adapted from internal research (EXA Agentic Workflow, Steps 3.0 §15, 4 §5, 3.E §6), now fully ratified as of 2026-08-11 per the author. Extends this object rather than a new standalone object, per the recommendation doc's stated preference; no structural reason found to prefer standalone. Existing content (the five-field format definition, the constraint block, the interactive builder) is completely unaffected. `status` stays published and `version` stays 1.0, deliberately unchanged — the object's live production content is untouched, but this new addition has not yet had the author's own review of its adaptation and framing, which is a separate gate from the source research's own ratification. Pending that review before this content is considered final.
2026-07-01Object scaffolded: frontmatter and schema in place. Worked example and the constraint-block payload are still pending editorial work (Build Ledger §3.3) — status stays draft, and the page is not built in production, until both are written.
2026-07-03First publication. Worked example and constraint-block payload populated from the published EXA vs. SDD article's 'Member Eligibility: Post-Redetermination' block — the format's founding worked example, drawn from public prose rather than invented content. Status flipped draft → published; version 0.1 → 1.0.

05 · Download

Download the working file (.json)

06 · Cite this

Citation

Citation: Webber, Reid. "The Agentic Constitution Format." The EXA Standard, v1.0, Enterprise Experience Architecture, 2026-08-16. https://reidexa.design/standard/agentic-constitution-format. Licensed under CC BY 4.0.
License: © Reid Webber. Licensed under CC BY 4.0 — you may copy, adapt, and redistribute this material, including for commercial use, provided you credit the source and indicate if changes were made.

View raw

Raw frontmatter

title: The Agentic Constitution Format
slug: agentic-constitution-format
objectNumber: 2
version: 1.0
status: published
type: format
source: Series One · Article 4 — defended in EXA vs. SDD
lastUpdated: 2026-08-16

{
  "title": "The Agentic Constitution Format",
  "slug": "agentic-constitution-format",
  "objectNumber": 2,
  "version": "1.0",
  "status": "published",
  "source": "Series One · Article 4 — defended in EXA vs. SDD",
  "sourceArticleUrl": "https://medium.com/enterprise-experience-architecture/spec-driven-development-certifies-the-code-who-certifies-the-consequence-a3b0503af23a",
  "summary": "The structured, five-field syntax for a constraint block inside an Agentic Constitution: TRIGGER, AGENT MUST, AGENT MUST NOT, COST IF RENDERED INCORRECTLY, and DISCOVERY SOURCE. It is the machine-readable unit an AI coding agent executes against directly, replacing the annotated screen a developer once interpreted by hand.",
  "lastUpdated": "2026-08-16",
  "changelog": [
    {
      "date": "2026-08-16",
      "note": "Added three new MDX-body sections — the Agent Permission Boundary (Part One), the Agent Permission Matrix (Part Two), and the gate's reduced authority for vendor surfaces (Part Three) — appended after the existing worked constraint block, not replacing it. Adapted from internal research (EXA Agentic Workflow, Steps 3.0 §15, 4 §5, 3.E §6), now fully ratified as of 2026-08-11 per the author. Extends this object rather than a new standalone object, per the recommendation doc's stated preference; no structural reason found to prefer standalone. Existing content (the five-field format definition, the constraint block, the interactive builder) is completely unaffected. `status` stays published and `version` stays 1.0, deliberately unchanged — the object's live production content is untouched, but this new addition has not yet had the author's own review of its adaptation and framing, which is a separate gate from the source research's own ratification. Pending that review before this content is considered final."
    },
    {
      "date": "2026-07-01",
      "note": "Object scaffolded: frontmatter and schema in place. Worked example and the constraint-block payload are still pending editorial work (Build Ledger §3.3) — status stays draft, and the page is not built in production, until both are written."
    },
    {
      "date": "2026-07-03",
      "note": "First publication. Worked example and constraint-block payload populated from the published EXA vs. SDD article's 'Member Eligibility: Post-Redetermination' block — the format's founding worked example, drawn from public prose rather than invented content. Status flipped draft → published; version 0.1 → 1.0."
    }
  ],
  "type": "format",
  "tagline": "Five fields that give an experience state a trigger, a boundary, and a cost — the machine-readable unit an agent executes against, and the column no engineering constitution carries.",
  "workedExample": "The constraint block above is the format's founding worked example — 'Member Eligibility: Post-Redetermination,' first published in EXA vs. SDD (July 2026). It encodes the incident that produced it: at a regional health network, three of the four product squads owning the member-eligibility experience had forked the eligibility view off the central system, and a CMS redetermination rule change left one forked view rendering a lapsed member as active — a state every engineering gate passed, because it was never a property of the code. The block names the trigger, the required and prohibited renderings, the cost the organization carries if the surface renders wrong, and the discovery source, including the adjacent states that audit flags for review. The COST IF RENDERED INCORRECTLY field is the load-bearing difference from an engineering specification: no code-correctness format carries a column for consequence.",
  "constraintFields": {
    "trigger": "CMS redetermination rule update changes a member's coverage status",
    "agentMust": [
      "Resolve eligibility against the central system of record",
      "Render lapsed status explicitly, with effective date"
    ],
    "agentMustNot": [
      "Render a lapsed member as active under any cached or forked view"
    ],
    "costIfRenderedIncorrectly": "Claims liability; caseworker acts on false eligibility; compliance exposure. Severity: CRITICAL",
    "discoverySource": "Production incident — override audit, regional health network. Adjacent states to audit: retroactive termination, dual-eligibility, grace-period"
  }
}