EXA-STD-005·THE EXA STANDARD·THE AMENDMENT PROTOCOL & VETO CHARTER
Edition1.1.1StatusPUBLISHED

charterThe Reviewer's Interface, Article 3Read the article

The Amendment Protocol & Veto Charter

Enforcement for everything already deployed.

Ratified
2026-08-07
License
CC BY 4.0
Cite as
Webber, 2026

A safe process for amending a live constraint set, and a standing authority to halt a surface running against an uncertified one.

A gate governs entry. This charter governs enforcement — what happens to a constraint set that is already live, and what happens when a squad has a legitimate reason to change it. Adoptable as written. No new system, no new committee, no tooling purchase: the gate’s own log is the intake record, and the veto’s authority comes from the org chart, not from software.

Two mechanisms. One instrument each.

  • The Amendment Protocol — the safe, filtered route for changing a ratified constraint when a squad has a legitimate reason to override it.
  • The Cultural Veto — the standing authority to halt a live surface running against an uncertified or failed constraint set.

Neither works without the other. A veto with no amendment route becomes pure refusal. An amendment route with no veto has nothing backing its deadlines.


Part One — The Amendment Protocol

The signal-to-noise standard

An override proposal enters the amendment queue only with a structural logic case: a named state the constitution does not govern, a documented conflict between the constraint and an external requirement, or evidence of the same override in three or more squads. Everything else is a preference request, returned at intake with a pointer to the governing constraint and no review cycle spent. Publish this rule before the queue opens. A filter announced after the first rejection reads as a rejection.

The three triggers, in order

Regulatory change — an external rule changed the correct behavior. Priority one. The clock is external; the amendment is not optional and the queue position is not negotiable.

Structural signal — three squads, same override, independently. Priority two. Treat the third instance as the specification’s own bug report.

Production incident — a governed surface caused an operational consequence. Priority three by sequence, first by urgency. Every incident-triggered amendment carries a second finding: which of the two earlier triggers was missed.

What counts as a production incident

Settle this before the first one, because the default answer is wrong. In most enterprises an incident means the system stopped: downtime, a breach, a failed deploy, a page. The failures this charter governs do not look like that — the servers are up, latency is nominal, error rates are flat, and the agent is confidently resolving an unnamed state wrong at production volume.

Under this charter, a governed surface producing confidently wrong output against an uncertified constraint set is a P1 or P2 incident, on the same severity ladder as an outage, classified on the consequence of the output rather than the health of the system producing it.

Register that definition in the operations organization’s existing incident taxonomy, in its own severity language, before the charter goes live. An incident model that requires something to be down will reject every failure this charter exists to catch — correctly, by its own definitions — and the third trigger never fires.

Amendment adoption timing

Ratifying an amendment raises the immediate question of who pays to adopt it. The answer follows severity, not filing order.

CRITICAL — a regulatory clock, a safety consequence, a contractual exposure. Carries a forced-adoption date across the full blast radius, funded per the Priority One resourcing rule below.

Below CRITICAL — inherited. Downstream surfaces bind to the amended version at their next scheduled release, and the prior version stays certified until they do.

The squads that filed the overrides are not penalized with an immediate refactor for having surfaced the gap. Charge the refactor to the squads who reported the problem and the third squad stops filing, which removes the signal the structural trigger depends on.

Amendment request format

# AMENDMENT REQUEST — [Constraint ID / State Name]

TRIGGER:
  [REGULATORY | STRUCTURAL_SIGNAL | PRODUCTION_INCIDENT]

CURRENT CONSTRAINT:
  [The governed behavior as ratified today]

PROPOSED CONSTRAINT:
  [The governed behavior as amended]

STRUCTURAL CASE:
  [The unnamed state, external conflict, or the three overrides.
   Absent this section, the request is returned at intake.]

BLAST RADIUS:
  [Surfaces, squads, and tenants governed by this constraint]

BLAST RADIUS VERIFIED:
  [Confirmed by the Ratifier against centralized override telemetry
   before the priority tier is accepted. A submitted radius that
   understates what the telemetry shows does not clear at the
   submitted tier — it escalates to the tier the telemetry supports.]

FALLBACK STATE:
  [Required at HIGH / CRITICAL. Behavior on halt:
   HUMAN_QUEUE | REVERT_LAST_CERTIFIED | DEGRADE_READ_ONLY]

FALLBACK CAPACITY:
  [Required if FALLBACK STATE is HUMAN_QUEUE. Maximum volume
   per hour the receiving queue can absorb, and the terminal
   state above that ceiling: HARD_BLOCK | SHED_TO_SCHEDULED |
   DEGRADE_READ_ONLY | AUTO_RESOLVE_TO_DEFAULT.
   AUTO_RESOLVE_TO_DEFAULT is prohibited where the decision
   itself is the consequential act. A queue with no stated
   ceiling, or a ceiling with no stated terminal state, is not
   a ratified fallback.]

VENDOR ENVELOPE:
  [Required if the surface is a third-party or vendor agent.
   State what is ratified: data reach, authorized actions,
   states routed to the agent, and halted-state fallback.
   If a CRITICAL constraint cannot be held by the envelope,
   name the vendor-relationship owner and the dated
   commitment. An exception with no owner and no date is
   not a ratified envelope.]

COST IF LEFT UNAMENDED:
  [Organizational consequence and severity: CRITICAL / HIGH / MEDIUM]

RATIFICATION:
  [Named function. Not a committee.]

The squad submits blast radius. The squad does not get to have it accepted on submission. A request that understates its own reach is the fastest way to move a structural amendment through as a preference, for the same reason a squad has every incentive to under-scope the surfaces it names — a narrower radius reads as lower priority and clears faster. The Ratifier checks the submitted radius against the centralized override telemetry before accepting the priority tier, not after. If the telemetry shows the constraint governing surfaces the request didn’t name, the amendment moves to the tier the telemetry supports, not the tier the squad asked for.

The same eleven fields, ready to fill — copy the block above.

Required telemetry

Centralized telemetry is not a feature of this mechanism. It is the engine of it. The structural-signal trigger works only if override events across every squad resolve to one place: a shared, versioned constraint ID, landing in one aggregated log the ratifying function reads. The gate already generates the events — no new system is required, only the aggregation. Fragment that log across disconnected regional instances and the mechanism does not degrade. It is dead on arrival: the three-squad signal is undetectable by construction, and the amendment protocol collapses into an incident-triggered process wearing a preventive name.

Priority One resourcing

A queue priority is not a delivery guarantee. Naming Regulatory Change as Priority One establishes sequence; it does not, by itself, get the amendment built. Before the first regulatory clock starts running, name the funding source Priority One work draws from — a standing capacity reserve held outside squad allocation, or a defined authority for the Ratifier to interrupt an active sprint — and name it once, in this charter, not squad by squad in the moment. A charter that can jump the queue but cannot pull capacity has ordered the work and left it unfunded.

What this charter is not

It is not a change-advisory board, and it is not an approval workflow with a new name. A committee that votes on amendments reintroduces the diffusion the mechanism exists to prevent. One named function ratifies. Others are consulted — security and legal by default, on day one — and consultation is encoded into the constraint library rather than convened into a standing meeting.


Part Two — The Cultural Veto

Veto activation conditions

The Cultural Veto activates on a live surface executing against an uncertified constraint set with a consequence severity of HIGH or CRITICAL. It is exercised by a named function, not a body, and it halts the surface — not the squad, not the release train, not the roadmap. The halt holds until the constraint set is certified or amended. It does not lapse because the sponsor is unavailable.

The veto is not the emergency stop. When a CRITICAL surface is actively misbehaving at 3 a.m. on a Saturday, the technical halt is SRE’s or Ops’s call, made on incident-response authority, on incident-response timelines — that authority exists already and this charter does not touch it. The Cultural Veto is what governs the surface after the bleeding stops: the standing decision that the surface stays down, or comes back only in its ratified fallback state, until the constraint set that failed is certified or amended. SRE stops the incident. The ratifier decides when the surface is allowed back. Collapsing those into one role either hands 3 a.m. life-safety judgment to someone without an operational pager, or hands the standing authority over whether a surface may resume to whoever happened to be on call. Keep both, and keep them distinct, or the charter reads as a turf claim against Ops instead of a boundary with it.

The required fallback state

No constraint set at HIGH or CRITICAL severity is certified without a ratified fallback: the specific, pre-agreed behavior the surface exhibits when the veto is exercised. Three standard forms cover most cases — route the decision to a human queue, revert to the last certified constraint version, or degrade the surface to read-only so it reports and stops acting. Specify which one, per constraint, at certification time. A veto with no defined landing does not halt a surface; it breaks everything downstream of it, and the organization correctly learns not to let it happen twice. The fallback is what makes the mechanism repeatable.

The human-queue form is not exempt from that discipline — it is the form most likely to fail quietly. A surface running production volume that halts straight into a support or operations queue with no stated capacity does not degrade; it moves the outage downstream and detonates against headcount instead of the agent. Every HUMAN_QUEUE fallback specifies the volume the receiving queue can absorb per hour and the behavior above that ceiling. A fallback to “a human” with no ceiling is an unratified fallback wearing a ratified one’s paperwork.

The behavior above the ceiling is itself a ratified constraint, not a note in a runbook. “Fail gracefully” and “drop the request” are not terminal states; they are gaps with reassuring names. Four terminal states are permitted, and the request stops in exactly one of them:

HARD_BLOCK — the request is refused, with a user-facing statement that the system cannot process it now and what the requester should do instead.

SHED_TO_SCHEDULED — the request is accepted into a stated later window, with acknowledgment and a committed time. Only where delay is materially different from denial.

DEGRADE_READ_ONLY — the surface reports and stops acting. The request is neither resolved nor refused; a human retrieves it.

AUTO_RESOLVE_TO_DEFAULT — the request resolves to a stated, ratified default, available only under the restriction below.

Where the decision itself is the consequential act, no terminal state may resolve it. A queue overflow in a prior-authorization path, a claims determination, an eligibility decision, a safety classification — in any of these, AUTO_RESOLVE_TO_DEFAULT is prohibited regardless of which direction the default points, because auto-determination under load is the original failure this charter exists to prevent, arriving through the back door of the fallback. Where resolving is safe and refusing is the harm, the reverse applies. Decide which case a surface is in at certification time, in writing, and record it beside the ceiling.

Third-party and vendor agents

The charter governs bought agents as well as built ones, with one substitution: the object of ratification is the envelope, not the internals.

What gets ratified. The data the agent may reach, the actions it is authorized to take in your environment, the states you route to it at all, and the fallback it lands in when halted. That envelope is yours regardless of who wrote the model behind it.

What the veto reaches. Deployment, not vendor code. You cannot amend a vendor’s constitution; you decide whether it is allowed to execute against your states. That authority is unaffected by the contract.

When the envelope cannot hold a CRITICAL constraint. The amendment converts from an engineering item to a procurement one. Record it with the same fields as any other amendment, plus two: a named owner on the vendor relationship, and a dated commitment. The surface runs in its ratified fallback state until the vendor ships, and the dated commitment is what keeps that from becoming permanent by default.

What is not permitted. Accepting a vendor’s assurance in place of a constraint, ratifying an envelope the vendor’s documentation does not support, or logging the gap as an exception with no owner and no date. A vendor agent operating outside a ratified envelope is a Provisional Surface with an invoice attached, and it carries the organization’s liability rather than the vendor’s.

The escalation path

Publish it before you need it, and terminate it above the squad’s delivery leadership. An escalation that resolves inside the accountability it is escaping is not a path. Name the executive sponsor, name the tier at which a contested halt is resolved, and state the standing rule that a halt survives the quarter boundary. Then run the reverse test: if the veto holder halted a flagship surface this Friday, who could reverse it, how fast, and on what authority? If the answer is anyone with a deadline, the charter is not yet in force.


Adopting this charter

This charter is adoptable as written by any organization running agentic surfaces in production, independent of the Agentic Constitution or the Logic-Review Gate. It assumes only two things: a versioned constraint set exists somewhere for each governed surface, and someone in the organization can be named as the ratifying function with standing above the squads whose work it gates.

Full argument, worked example, and the org-design reasoning behind each requirement: Your Kill Switch Works. Nobody Has the Standing to Pull It.The Reviewer’s Interface, Article 3.

Worked example — pending. Reworded detail from a published engagement is queued editorial work (Build Ledger §3.3), independent of this template.

  1. v1.1.12026-08-06Sync fix, no new rules. VENDOR ENVELOPE was added to the template at 1.1.0 but omitted from the request-format block in this object and in the source article; all three now carry the same eleven fields in the same order. The requirement itself was already normative under 'Third-party and vendor agents' at 1.1.0 — this makes it operational at the point of filing.
  2. v1.1.02026-08-06Minor-version bump: two new normative requirements, not clarifications. (1) The behavior above a HUMAN_QUEUE ceiling is now itself a ratified terminal state, enumerated as HARD_BLOCK, SHED_TO_SCHEDULED, DEGRADE_READ_ONLY, or AUTO_RESOLVE_TO_DEFAULT, with AUTO_RESOLVE_TO_DEFAULT prohibited wherever the decision itself is the consequential act. (2) New section governing third-party and vendor agents: the object of ratification is the envelope rather than the vendor internals, the veto reaches deployment rather than vendor code, and an unholdable CRITICAL constraint converts the amendment into a procurement item requiring a named vendor owner and a dated commitment. Downloadable template updated with both, including a new VENDOR ENVELOPE field. Adopters on 1.0.x should re-verify existing HUMAN_QUEUE fallbacks and any vendor surfaces against these requirements.
  3. v1.0.42026-08-01Structural only, no rule changes. Adoption-timing and production-incident definitions moved out of the trigger entries into dedicated sections ('Amendment adoption timing', 'What counts as a production incident') so the three triggers read as a clean ordered sequence. Priority One resourcing detail de-duplicated from the Regulatory Change entry; it remains in full under its own heading.
  4. v1.0.32026-08-01Specified amendment adoption timing (CRITICAL amendments carry a forced-adoption date; all others inherit at next scheduled release, with the filing squads exempt from immediate refactor) and defined 'production incident' in experience-state terms — confidently wrong output against an uncertified constraint set is a P1/P2 incident classified on output consequence, not system health. Both close deployment-blocking ambiguities raised in enterprise review.
  5. v1.0.22026-08-01Added Priority One resourcing requirement (a named funding source for regulatory-trigger amendments, distinct from queue sequencing) and BLAST RADIUS VERIFIED as a required field in the amendment request format, closing a self-reported-scope gap analogous to the severity down-ranking risk in the Logic-Review Gate Charter. Downloadable template updated to match.
  6. v1.0.12026-08-01Tightened the Required Telemetry section from a soft dependency to an explicit architectural requirement — centralized aggregation is the mechanism, not a recommended practice. No change to the underlying rule.
  7. v1.0.02026-08-01Founding release. Extracted from The Reviewer's Interface, Article 3 — 'Your Kill Switch Works. Nobody Has the Standing to Pull It.' No content changes from the article's shipped Charter section; formatting only, for standalone citation.
Citation
Citation
Webber, Reid. "The Amendment Protocol & Veto Charter." The EXA Standard, v1.1.1, Enterprise Experience Architecture, 2026-08-07. https://reidexa.design/standard/amendment-protocol-veto-charter. 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.
Raw frontmatter
title
The Amendment Protocol & Veto Charter
slug
amendment-protocol-veto-charter
objectNumber
5
version
1.1.1
status
published
type
charter
source
The Reviewer's Interface, Article 3
lastUpdated
2026-08-07
{
  "title": "The Amendment Protocol & Veto Charter",
  "slug": "amendment-protocol-veto-charter",
  "objectNumber": 5,
  "version": "1.1.1",
  "status": "published",
  "source": "The Reviewer's Interface, Article 3",
  "sourceArticleUrl": "https://medium.com/enterprise-experience-architecture/your-kill-switch-works-nobody-has-the-standing-to-pull-it-4337453b48be",
  "summary": "A safe process for amending a live constraint set, and a standing authority to halt a surface running against an uncertified one.",
  "lastUpdated": "2026-08-07",
  "changelog": [
    {
      "date": "2026-08-06",
      "version": "1.1.1",
      "note": "Sync fix, no new rules. VENDOR ENVELOPE was added to the template at 1.1.0 but omitted from the request-format block in this object and in the source article; all three now carry the same eleven fields in the same order. The requirement itself was already normative under 'Third-party and vendor agents' at 1.1.0 — this makes it operational at the point of filing."
    },
    {
      "date": "2026-08-06",
      "version": "1.1.0",
      "note": "Minor-version bump: two new normative requirements, not clarifications. (1) The behavior above a HUMAN_QUEUE ceiling is now itself a ratified terminal state, enumerated as HARD_BLOCK, SHED_TO_SCHEDULED, DEGRADE_READ_ONLY, or AUTO_RESOLVE_TO_DEFAULT, with AUTO_RESOLVE_TO_DEFAULT prohibited wherever the decision itself is the consequential act. (2) New section governing third-party and vendor agents: the object of ratification is the envelope rather than the vendor internals, the veto reaches deployment rather than vendor code, and an unholdable CRITICAL constraint converts the amendment into a procurement item requiring a named vendor owner and a dated commitment. Downloadable template updated with both, including a new VENDOR ENVELOPE field. Adopters on 1.0.x should re-verify existing HUMAN_QUEUE fallbacks and any vendor surfaces against these requirements."
    },
    {
      "date": "2026-08-01",
      "version": "1.0.4",
      "note": "Structural only, no rule changes. Adoption-timing and production-incident definitions moved out of the trigger entries into dedicated sections ('Amendment adoption timing', 'What counts as a production incident') so the three triggers read as a clean ordered sequence. Priority One resourcing detail de-duplicated from the Regulatory Change entry; it remains in full under its own heading."
    },
    {
      "date": "2026-08-01",
      "version": "1.0.3",
      "note": "Specified amendment adoption timing (CRITICAL amendments carry a forced-adoption date; all others inherit at next scheduled release, with the filing squads exempt from immediate refactor) and defined 'production incident' in experience-state terms — confidently wrong output against an uncertified constraint set is a P1/P2 incident classified on output consequence, not system health. Both close deployment-blocking ambiguities raised in enterprise review."
    },
    {
      "date": "2026-08-01",
      "version": "1.0.2",
      "note": "Added Priority One resourcing requirement (a named funding source for regulatory-trigger amendments, distinct from queue sequencing) and BLAST RADIUS VERIFIED as a required field in the amendment request format, closing a self-reported-scope gap analogous to the severity down-ranking risk in the Logic-Review Gate Charter. Downloadable template updated to match."
    },
    {
      "date": "2026-08-01",
      "version": "1.0.1",
      "note": "Tightened the Required Telemetry section from a soft dependency to an explicit architectural requirement — centralized aggregation is the mechanism, not a recommended practice. No change to the underlying rule."
    },
    {
      "date": "2026-08-01",
      "version": "1.0.0",
      "note": "Founding release. Extracted from The Reviewer's Interface, Article 3 — 'Your Kill Switch Works. Nobody Has the Standing to Pull It.' No content changes from the article's shipped Charter section; formatting only, for standalone citation."
    }
  ],
  "type": "charter",
  "tagline": "Enforcement for everything already deployed.",
  "download": {
    "label": "Amendment Request Format (.txt)",
    "filename": "amendment-request-format.txt",
    "assetPath": "/standard/assets/amendment-protocol-veto-charter/amendment-request-format.txt"
  }
}