# AEG Worked Example: Governed Production Change

Version 1.0 · August 28, 2026  
Source: https://jacobpallattu.com/architecture/aeg/kit  
License: CC BY 4.0 — adapt with attribution to Jacob George and the AEG Architecture Model.

> Fictional scenario: Lumen Notes, its people, identifiers, architecture, and events are invented solely to explain the public AEG model.

## Scenario

An operator asks an AI-assisted release coordinator to deploy version 2.4.0 of the fictional Lumen Notes API to production using a 10% canary. The release includes a schema backfill. The assistant may generate and refine a proposal, but it cannot authorize production execution.

## 1. Request

“Deploy Lumen Notes API 2.4.0 to production. Start with 10%. Roll back if the error rate exceeds 2% for five minutes.”

The request is input—not authority.

## 2. Structured intent

```json
{
  "intentId": "int_lumen_240_001",
  "type": "release.deploy",
  "target": {
    "service": "lumen-notes-api",
    "environment": "production",
    "version": "2.4.0"
  },
  "constraints": {
    "canaryPercent": 10,
    "includesSchemaBackfill": true,
    "rollbackWhen": "errorRate > 2% for 5m"
  },
  "requestedBy": "operator_17",
  "expiresAt": "2026-09-01T18:00:00Z"
}
```

The schema is illustrative. The invariant is that meaning, scope, constraints, provenance, and expiry become independently inspectable.

## 3. Policy decision

The governance component evaluates the intent independently from the component that generated it.

- Target is explicit: pass.
- Requester may propose production changes: pass.
- Production execution requires review: approval required.
- Schema backfill must remain within the declared canary and rollback constraint: approval required.
- Intent expires: pass.

Decision: `approval_required`.

## 4. Bounded authority

An independent reviewer approves this exact intent. The grant is bound to:

- `lumen-notes-api` version `2.4.0`;
- the production environment;
- a 10% canary;
- the declared rollback condition; and
- the intent expiry.

Changing any of these creates a new intent and requires a new decision.

## 5. Controlled execution

The execution adapter validates the approval, intent digest, expiry, and current target state. It begins the 10% canary. The adapter cannot derive broader permissions from the original conversation.

## 6. Observable evidence

All events use `int_lumen_240_001` as their correlation identifier:

1. `intent.proposed`
2. `policy.evaluated` with `approval_required`
3. `authority.granted`
4. `execution.started`
5. `execution.verified`

Denied, expired, failed, and rolled-back paths should emit equally inspectable outcomes.

## What this demonstrates

AEG does not prevent intelligence from proposing consequential actions. It prevents proposal generation from silently becoming execution authority. Intelligence, policy, authority, execution, and evidence remain distinguishable and independently inspectable.