The Machine-Readable Intent Document (MRID) Lifecycle

The Machine-Readable Intent Document (MRID) Lifecycle

How Agentic Change Is Contained Before It Becomes Damage

Why a Lifecycle Matters

Most organizations treat agent output as work.

That is the mistake.

Agent output must be treated as a proposal that moves through a controlled lifecycle.

The MRID is not documentation after the fact — it is the gatekeeper before anything happens.

Without a lifecycle, intent dissolves the moment code is generated.

The MRID Lifecycle (End-to-End)

Below is the only safe flow for agentic change in a real enterprise.

1. Intent Declaration (Human-Owned)

Input: Human-authored MRID (JSON)

Output: Versioned intent artifact

What happens here:

• A human defines why the change exists

• Scope and authority are explicitly constrained

• Invariants are declared up front

Key rule:

Agents do not write MRIDs. Humans do.

If intent is unclear at this stage, automation is forbidden downstream.

2. Policy Validation (Automated, Non-Negotiable)

Input: MRID

Output: Pass / Fail

Automated checks validate:

• Schema correctness

• Authority scope

• Blast radius limits

• Required rollback strategy

Key rule:

If policy fails, the workflow stops. No overrides.

This is where most unsafe systems should die.

3. Agent Proposal Generation (Constrained Execution)

Input: Approved MRID

Output: Code, configs, or plans — tagged with MRID ID

What agents are allowed to do:

• Generate implementation within declared boundaries

• Produce diffs, not deployments

• Reference MRID invariants in output

What they are not allowed to do:

• Expand scope

• Change contracts

• Perform irreversible actions

4. Independent Verification (Not Written by the Agent)

Input: Agent output + MRID

Output: Verified / Rejected

Verification includes:

• Contract compatibility checks

• Test coverage enforcement

• Invariant validation

• Complexity budget scoring

Key rule:

An agent may not verify its own work. Ever.

If verification fails, the proposal is discarded — not “fixed later.”

5. Human Authorization (Named Accountability)

Input: Verified proposal

Output: Explicit approval or rejection

This is where accountability becomes real:

• A human name is attached

• Approval is deliberate

• Responsibility is explicit

If leadership wants “fully autonomous execution,”

they are also explicitly accepting liability.

6. Controlled Execution (Guardrails Active)

Input: Approved proposal

Output: Deployed change

Execution must include:

• Feature flags

• Circuit breakers

• Observability hooks

• Time-bound rollback guarantees

No silent deploys.

No background mutations.

7. Post-Deployment Observation & Drift Detection

Input: Runtime signals

Output: Continue / Rollback / Incident

The MRID becomes the baseline for drift detection:

• Did the system behave as declared?

• Were invariants violated?

• Did blast radius exceed expectations?

Failures here are not “bugs.”

They are intent violations.

Why This Diagram Changes Behavior

This lifecycle does something subtle but powerful:

• Engineers stop arguing about prompts

• Managers stop pushing “speed” blindly

• Agents stop being treated as decision-makers

Because everyone can see:

Intent precedes automation — not the other way around.

The Architectural Payoff

When this lifecycle exists:

• Failures are explainable

• Rollbacks are fast

• Scope creep is visible

• Accountability is survivable

Most importantly:

No agent can surprise the system.

And surprises are what destroy trust.

Optional Next Additions (If You Want to Extend This)

You could later add:

• A swimlane version (Human vs Agent vs CI)

• A “What Happens When MRID Is Missing” failure path

• A mapping from MRID stages to GitHub/GitLab checks

But this diagram alone is enough to reset expectations.

Just tell me how far you want to take it.