Who owns the outcome and authority?
Name the accountable owner, affected parties, decision rights, escalation path and boundary where a human must decide, approve or interrupt.
EAINE Reference Architecturev0.8.0 · Candidate
Architecture for systems that can reason, act, be challenged, and evolve.
A living, evidence-connected architecture for enterprise AI. It makes intent, authority, behaviour, evidence, failure, cost, and learning visible as one governed system.
10 domains15 components6 trust zones10 interfaces
RA / 0.8.0CandidateMachine-verifiable source
01Experiencehuman
02Application + orchestrationruntime
03AI capabilityruntime
04Knowledge + contextruntime
05Tools + integrationruntime
06Controlcontrol
07Operationsevidence
IntentAuthorityBehaviourEvidenceLearning
Open Candidate architectureVendor-neutral · human-accountable · evidence-led
Suitable for implementation, review, and challenge. It is not a certification, regulatory conclusion, or promise of business outcomes.
Understand EAINE in 90 seconds
Three questions reveal the whole governed system.
Start with decisions people can own. The seven publication layers, ten canonical domains, five traces and every identifier remain beneath this simpler view.
How does the system behave across AI, knowledge and tools?
Treat models, prompts, policies, knowledge, tools and runtime configuration as one versioned behavioural release.
How does the enterprise control, prove, operate and improve it?
Connect lifecycle decisions, evidence, observability, containment, rollback and learning into one operating record.
Accountable outcome + authority→AI + knowledge + tools→Control + evidence + operations→Learning + lifecycle re-entry
Choose your perspective
One architecture. Three adoption journeys.
Each view changes the decision emphasis, not the underlying EAINE taxonomy or controls.
Executive view
Executive
Outcome, affected parties, ownership, risk, investment, operating cost and the scale, adapt or stop decision.
Use this perspective in the builder →Architecture view
Architecture
Domains, trust zones, shared components, interfaces, identity, deployment and failure boundaries.
Use this perspective in the builder →Delivery view
Delivery
Nine AI SDLC stages, evidence, release digest, evaluation, operations, rollback and a 90-day path.
Use this perspective in the builder →Six governed scenarios
Start with a bounded pilot, not a transformation slogan.
These are constructed guidance—not field-validated case studies. Each keeps the complete architecture and emphasizes the controls that matter most in context.
Banking and insurance
Policy-grounded operations or decision support
Healthcare and life sciences
Bounded professional-support workflow
Telecom and manufacturing
Maintenance or service-operations assistant
Public sector
Internal caseworker or knowledge assistant
SaaS and digital products
Bounded customer-facing capability
Consulting and services
Preparation or quality-review assistant
Turn the architecture into your starting pack.Anonymous, local-first and downloadable as print, Markdown or JSON.
Open blueprint builderAuthoritative deep view
Inspect the implementation-grade atlas.
Version history, component catalogues, interfaces, event details, traces and deployment patterns remain fully inspectable below.
Implementation-grade architecture atlas
From business intent to a recoverable operating system.
These views form one architecture. Component IDs, interface IDs, trust zones, events, controls, and evidence references remain consistent from design through implementation and operation.
Enterprise system context
Who participates, where accountability sits, and which external boundaries the system crosses.
Accountability boundaryAuthenticated human owner + reviewerIntent · approval · override · appeal
→TZ-004Knowledge gatewayGoverned sources
TZ-004Tool brokerTyped enterprise actions
TZ-005Provider gatewayMinimised model request
Telemetry → evidence → operations → improvement → lifecycle re-entry
Implementation rule: model output never becomes material business authority without an explicitly engineered decision path.
Canonical logical topology and trust zones
What to build, where it belongs, and which identity and data boundary protects it.
CMP-004
Human Review Interface
Human Review Interface
CMP-001 Use Case RegistryCMP-002 Lifecycle OrchestratorCMP-003 Release GateCMP-009 Evaluation RunnerCMP-010 Policy Decision PointCMP-013 Operations ConsoleCMP-015 Improvement Backlog
CMP-005 Bounded RuntimeCMP-011 Security Enforcement
CMP-006 Tool BrokerCMP-007 Knowledge Gateway
CMP-008
Provider Gateway
Provider Gateway
CMP-012 Telemetry PipelineCMP-014 Evidence Store
Boundary rule: authenticate workload identity, authorise purpose, minimise data, enforce contract, and emit evidence at every zone crossing.
Runtime decision sequence
How one request is admitted, grounded, executed, reviewed, and evidenced.
- 01Human → RuntimeIF-003
Authenticated purpose-bound request
- 02Runtime → PolicyCMP-010/011
Input, release, data, and authority precheck
- 03Runtime → KnowledgeIF-004
Authorised, filtered, cited context
- 04Runtime → ProviderIF-006
Minimised request through approved adapter
- 05Runtime → PolicyEVT-004
Output, citation, and proposed-action check
- 06Runtime → ToolIF-005
Typed capability request; deny by default
- 07Runtime → HumanEVT-008
Assistance, review, or escalation
- 08All → EvidenceIF-008/010
Versions, decisions, consequence, disposition
Knowledge and context supply chain
How information becomes authorised context without confusing relevance with authority.
01RegisterOwner · classification · permitted purpose
02PrepareProvenance · quality · residency · retention
03RetrieveIdentity · record filter · freshness
04AssembleConflict logic · minimisation · token budget
05UseCitation · output boundary · no hidden authority
06LearnFeedback review · source correction · expiry
Fail-safe: no authorised context means no grounded recommendation; preserve the human path.
Agent authority and tool execution
How a proposal can—and often cannot—become an enterprise side effect.
Model authorityProposePlan + typed action request
→CMP-010/011Admit?Identity · purpose · policy · budget
→Human / delegatedApprove?Consequence · competence · segregation
→CMP-006ExecuteSchema · scope · idempotency
→CMP-012/014ProveOutcome · evidence · reversal
Deny / expire / revokeNo side effect · reason code · human route
Behavioural release pipeline
How the complete behaviour—not merely a model name—is evaluated and authorised.
CodeModelPromptPolicyKnowledgeToolsRuntime
→CMP-009Evaluation portfolioPositive · negative · adversarial · regression · recovery
→CMP-003Release gateExact digest · accepted evidence · accountable signer
→CMP-005Allowlisted runtimeObserve · contain · rollback
Decision-capable observability and evidence
How to reconstruct authority, behaviour, consequence, and learning without copying unrestricted content.
IdentityIntentReleasePolicyKnowledgeToolProviderHumanOutcomeCost
Controlled trace referencetraceId · boundaryId · releaseDigest · reasonCodes · evidenceRefs
CMP-012TelemetryRedacted operational signals
CMP-014EvidenceIntegrity-bound decisions
CMP-013OperationsDetect · contain · recover
CMP-015LearningOwned lifecycle re-entry
Failure containment and recovery
What the system does when policy, knowledge, provider, evidence, or behaviour fails.
01DetectThreshold, denial, drift, incident, complaint
02ContainDeny, circuit break, suspend, human-only
03RestoreLast accepted digest or approved adapter
04VerifyRecovery suite + independent evidence
05LearnClassify change and reopen lifecycle
Recovery rule: no silent forward recovery; every intervention retains evidence and every restored state is verified.
Deployment patterns
How to place the same logical controls under different continuity, privacy, and residency needs.
RuntimeControlEvidence
Separate identities and encrypted stores in one approved region. Human-safe degradation during regional outage.
Primary⇢Passive
Signed failover; only approved data classes replicate. Test provider and policy equivalence.
Private⇢Gateway⇢Provider
Knowledge and tools remain private; only minimised approved payloads cross the egress boundary.
Canonical component catalogue
The minimum deployable responsibilities and ownership boundaries teams must assign.
| ID + component | Domain | Trust zone | Implementation responsibility |
|---|---|---|---|
| CMP-001Use Case Registry | Product + use case | Governed control | Own intent, boundary, tier, and accountable outcome |
| CMP-002Lifecycle Orchestrator | AI SDLC platform | Governed control | Move governed records and decisions through nine stages |
| CMP-003Release Gate | AI SDLC platform | Governed control | Bind accepted evidence and approval to one release digest |
| CMP-004Human Review Interface | Application runtime | Human interaction | Preserve disclosure, review, override, and escalation |
| CMP-005Bounded Application Runtime | Application runtime | Runtime | Execute only the behaviour and authority in the accepted release |
| CMP-006Tool Broker | Application runtime | Data + tools | Validate typed actions, scope, limits, and reversibility |
| CMP-007Knowledge Gateway | Knowledge + data | Data + tools | Enforce source permission, provenance, freshness, and minimisation |
| CMP-008Provider Gateway | Model + provider | External provider | Pin approved providers and models; minimise payloads and contain failure |
| CMP-009Evaluation Runner | Evaluation | Governed control | Run positive, negative, adversarial, regression, and recovery suites |
| CMP-010Policy Decision Point | Governance + RAI | Governed control | Return allow or deny decisions with policy versions and reason codes |
| CMP-011Security Enforcement Point | Security + privacy | Runtime | Enforce identity, data, isolation, egress, and supply-chain controls |
| CMP-012Telemetry Pipeline | Observability + operations | Evidence + telemetry | Capture schema-valid, redacted, digest-linked operating signals |
| CMP-013Operations Console | Observability + operations | Governed control | Detect, contain, recover, and verify operational state |
| CMP-014Evidence Store | Governance + RAI | Evidence + telemetry | Retain append-only decision, release, and recovery proof |
| CMP-015Improvement Backlog | Continuous improvement | Governed control | Convert verified signals into owned lifecycle re-entry |
Interface contracts and failure behaviour
The calls teams implement, their performance boundary, and the safe outcome when dependencies fail.
| Interface | Flow | From → to | Timeout | Failure behaviour |
|---|---|---|---|---|
| IF-001Lifecycle command | Lifecycle command | CMP-001 → CMP-002 | 2 s | Reject; no state transition |
| IF-002Release decision | Release decision | CMP-002 → CMP-003 | 2 s | Fail closed; preserve prior digest |
| IF-003Assistance request | Assistance request | CMP-004 → CMP-005 | 3 s | Bounded unavailable response; human path |
| IF-004Knowledge query | Knowledge query | CMP-005 → CMP-007 | 500 ms | No context; escalate instead of inventing |
| IF-005Tool invocation | Tool invocation | CMP-005 → CMP-006 | 500 ms | Deny action; emit tool.denied |
| IF-006Provider invocation | Provider invocation | CMP-005 → CMP-008 | 1 s | Circuit break, approved replay, or escalate |
| IF-007Evaluation run | Evaluation run | CMP-003 → CMP-009 | 10 s | Release gate fails |
| IF-008Telemetry event | Telemetry event | CMP-005 → CMP-012 | 250 ms | Bounded buffer; alert on loss |
| IF-009Operational signal | Operational signal | CMP-013 → CMP-015 | 2 s | Visible queue, owner, and deadline |
| IF-010Evidence write | Evidence write | CMP-002 → CMP-014 | 2 s | Decision unproved; release fails closed |
Event and operating record
Which signals connect lifecycle, runtime, assurance, and operations into one reconstructable record.
lifecycle.stage.enteredrelease.gate.evaluatedimprovement.proposedrequest.receivedpolicy.decisionknowledge.retrievedtool.decisionprovider.completedevaluation.completedhuman.review.requiredevidence.writequality.observedcost.observedincident.openedrecovery.verifiedRequired envelope: eventId, occurredAt, boundaryId, traceId, releaseDigest, producer, outcome, and controlled references.
Implementation path
How to move from architecture decision to controlled production without attempting everything at once.
- 0–30Bound the use case
Owner, affected parties, human decision, data classes, risk tier, outcome baseline, stop conditions.
- 31–60Build the controlled path
Runtime, gateways, policy, identity, knowledge, tool contracts, evaluation suites, evidence schemas.
- 61–90Release one workflow
Digest, segregated approval, telemetry, incident drills, rollback, recovery verification, operating ownership.
- 90+Scale only what earns it
Measure outcome, control performance, adoption, total cost, portability, and verified learning.
Implementation definition of done
A diagram is not deployed architecture.
Named owner, purpose, affected parties, authority, data, region, retention, and stop condition.
Schema, caller and target identities, policy interceptors, timeout, idempotency, and failure behaviour.
Pinned code, model, prompt, policy, knowledge, tools, evaluation, and runtime configuration.
Accepted evaluation evidence, release decision, runtime trace, incident path, rollback target, and recovery result.
Owned service levels, cost limits, quality and safety thresholds, escalation, containment, and on-call response.
Signal owner, review deadline, change class, reopened lifecycle stages, verification, and disposition.
One operating system
More than components and arrows.
The architecture connects the system people build with the authority, evidence, and learning the enterprise needs to operate it responsibly.
Human boundaryBounded runtimeCross-cutting controlEvidence + learning
Experience
Intent, affected parties, channels, disclosure, review, override, and escalation.
Application + orchestration
Workflow state, deterministic logic, bounded agents, and coordination.
AI capability
Models, prompts, inference configuration, routing, and approved fallback.
Knowledge + context
Authority, permission, provenance, freshness, retrieval, and assembly.
Tools + integration
Typed actions, transactions, external systems, limits, and reversibility.
Control
Evaluation, governance, security, privacy, approvals, budgets, and evidence.
Operations
Telemetry, consequence, cost, incidents, recovery, rollback, and learning.
These seven reader-facing layers are a publication view of the ten canonical logical layers. They do not create a competing taxonomy.
EAINE signature model
Five traces. One operating record.
A consequential action is not understood until the enterprise can connect why it happened, who authorised it, what produced it, what supports it, and what changed next.
Intent
Why this system exists, who owns the outcome, and when it should stop.
Authority
Who or what may propose, approve, execute, override, revoke, and answer.
Behaviour
The exact code, model, prompt, context, policy, tools, and runtime configuration.
Evidence
What supports design, release, operation, investigation, and risk decisions.
Learning
How verified signals reopen the lifecycle and change products or enterprise capability.
One system, five decisions
Change the lens without changing the architecture.
Each role sees the same governed system through the decision it owns.
Primary question
Where are authority, trust, state, and failure boundaries?
Identity-scoped contracts, explicit interceptors, data classes, timeouts, failure behaviour, and recovery objectives.
- 01Ten domains
- 02Six trust zones
- 03Ten interfaces
- 04Deployment and recovery variants
The model may propose an action. The architecture decides whether that proposal can become authorised behaviour.
Controlled autonomy
Authority is engineered as an expiring envelope.
Autonomy is bounded by identity, purpose, permission, consequence, time, transaction limits, and a recoverable human path.
| Stage | Permitted authority | Enforcement evidence |
|---|---|---|
| Propose | Agent may form a plan | Purpose, policy, context, and budget precheck |
| Request | Agent may request a typed tool action | Capability token, schema, scope, and transaction limit |
| Approve | Named human or segregated authority | Competence, evidence, consequence, and expiry |
| Execute | Tool broker, never model authority alone | Identity, idempotency, validation, and audit event |
| Contain | Operations or automatic safety control | Circuit breaker, safe degradation, rollback, and revocation |
Intelligence supply chain
Knowledge carries authority, not just relevance.
Permission, provenance, ownership, applicability, freshness, and conflict behaviour travel with knowledge from registration to output and learning.
Production rule
Retrieval relevance never substitutes for source authority or permission.
Behavioural release
Release the configuration that can change behaviour.
A model name is not a release identity. EAINE binds the complete behavioural configuration to the accepted evidence and accountable decision.
CodeModelPromptPolicyKnowledgeToolsEvaluationRuntime=Governed behavioural release
Exact versionsRelease digestAccepted evidenceAccountable signerRollback target
Decision-capable observability
Observe authority and consequence, not only model activity.
Telemetry becomes useful evidence when it connects the active configuration, initiating identity, proposed authority, enforced permission, human decision, outcome, and learning disposition.
IdentityWho initiated
ConfigurationWhat was active
AuthorityWhat was allowed
BehaviourWhat executed
ConsequenceWhat changed
DispositionWhat happens next
Temporal architecture
The architecture governs change, failure, and recovery over time.
Production is not the end state. Signals can contain authority, restore a prior release, or reopen the lifecycle with new evidence.
Missing authority, evaluation, or release integrity preserves the prior accepted state.
Provider, retrieval, policy, or evidence failure cannot force an invented automated decision.
Rollback, replay, and restoration retain intervention evidence and require verified recovery.
Architecture economics
A shared capability must earn adoption.
Platform architecture creates value only when it removes repeated work, improves a consequential control, or enables an outcome teams could not justify independently.
Which repeated work is real and frequent?
Which decision becomes safer or clearer?
What do assurance, operation, migration, and exit cost?
Do teams choose the trusted path or bypass it?
Can the enterprise retain decision-grade proof?
What evidence causes adaptation or retirement?
Time horizons
Look ahead without presenting speculation as established practice.
Human accountability, controlled model and tool access, governed context, evaluation, release evidence, observability, rollback, and lifecycle re-entry.
Dynamic policy enforcement, portable provider adapters, evidence-linked behavioural releases, cross-layer incident reconstruction, and governed enterprise memory.
Machine-verifiable architecture contracts, continuous control assurance, simulation-backed autonomy envelopes, and evidence-aware architecture agents.
Versioned and inspectable
Follow the architecture as it evolves.
Permanent version URLs, explicit status, dated change records, and machine-readable controls prevent silent replacement.
- Current
- v0.8.0
- Published
- 27 July 2026
- Alignment review
- 11 August 2026
- Book baseline
- First Edition, 2026 — editorial production candidate
Review before publication
Challenge the boundaries, not just the diagram.
Inspect the canonical source, test the control model, compare it with your environment, and identify where it creates clarity or unnecessary cost.