A change is proposed
An operator asks to deploy Lumen Notes 2.4.0 to production using a 10% canary.
AEG canonical model01 · Request 02 · Intent 03 · Policy 04 · Authority 05 · Execution 06 · Evidence
AEG Practical Model Kit · v1.0
From a production request to bounded execution authority
A worked, inspectable application of the Agentic–Event–Governed Architecture Model using one entirely fictional system.
Fictional scenario. Lumen Notes, its people, identifiers, architecture, and events are invented solely to explain the public AEG model.
Worked example
A governed change, end to end
An operator asks an AI-assisted release coordinator to deploy version 2.4.0 of the fictional Lumen Notes API. The release includes a schema backfill, so proposing the change and authorizing it must remain separate acts.
Meaning becomes inspectable
The request is normalized into a typed, immutable intent before any executor receives it.
Risk is evaluated independently
Production scope and a schema backfill trigger a rule requiring human approval.
Approval grants bounded authority
The approval is bound to this release, environment, canary size, expiry, and rollback condition.
An adapter performs the change
The executor can act only from the authorized intent—not from the original natural-language request.
Events preserve the decision trail
Outcome events make the request, policy decision, approval, execution, and verification reconstructable.
Structured intent
Execution receives a contract, not a conversation
The exact schema is illustrative. The invariant is that meaning, scope, constraints, provenance, and expiry become independently inspectable before authority is considered.
{
"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"
}Policy evaluation
The generator does not grade its own request
An independent governance component evaluates the normalized intent and returns a decision—not an execution command.
Target is explicitly identifiedPassService, version, and production environment are present.
Intent is within requester scopePassThe requester may propose—but not authorize—production changes.
Production change requires reviewApprovalHuman approval is mandatory for production execution.
Schema mutation is boundedApprovalThe backfill must use the declared canary and rollback constraint.
Intent has an expiryPassAuthority cannot be reused after the declared window.
Governance decisionApproval required
The system may prepare the change, but no execution authority exists until an independent reviewer approves this exact intent.
Event evidence
A decision trail that can be reconstructed
Each transition emits evidence under the same intent identifier. Model-generated explanations may provide context, but they are not the authoritative audit record.
- intent.proposedNormalized intent recorded
- policy.evaluatedDecision: approval_required
- authority.grantedReviewer grants bounded authority
- execution.started10% canary begins
- execution.verifiedGuardrails healthy; rollout completes
Evaluation checklist
Does the architecture preserve the AEG boundary?
This is a design-review aid, not a certification score. A checked item should point to inspectable architecture evidence.
Architecture signalAuthority boundary is incomplete0 of 12 checks confirmed
0%
Reusable artifacts
Take the model into a design review
The downloadable artifacts are intentionally vendor-neutral and may be adapted with attribution under CC BY 4.0.
Assumptions and limitations
What this kit does not claim
Not an authorization product
AEG defines separation of responsibilities and decision boundaries. It does not prescribe an identity provider, policy engine, event broker, or deployment platform.
Not a guarantee of safe policy
A structurally independent policy can still be incomplete or wrong. Policy quality, testing, ownership, and change control remain separate obligations.
Not required for every automation
Low-impact, reversible automation may not justify the operational cost of the full pattern. Apply controls in proportion to consequence.
Not a substitute for domain controls
Privacy, security, legal, safety, and domain-specific requirements must still be designed and verified independently.
Version history
Model kit changelog
v1.0August 28, 2026
Initial practitioner release: fictional production-change example, structured intent, policy decision, event trail, interactive checklist, reusable artifacts, and explicit limitations.
Challenge the model
Found an ambiguity or a broken assumption?
Useful feedback identifies the exact boundary, rule, or failure mode that needs clarification. Public implementation examples must contain only material you are authorized to share.