We keep drawing the easy diagram
Component diagrams answer how the machinery connects. They do not establish which information governs, which instruction outranks another, or whether a technically possible action is authorized.
Architecture has two planes
The technology plane supplies capability.
The intent plane supplies direction, legitimacy, and constraint.
The planes must be separate enough to review independently and connected enough that every material capability has an objective, authority source, action boundary, validation gate, and reversal path.
Meaning is not cleanup
The semantic layer cannot be postponed until after the platform is built.
The architecture must define what the organization means by terms such as approved, current, canonical, validated, managed, complete, and authorized.
Those words are operating controls. Treating them as loose prose and asking retrieval to sort it out later is not sophisticated. It is deferred architecture.
The semantic layer is part of the operating architecture.
| Do not confuse | With | Why it matters |
|---|---|---|
| Relevant | Authoritative | Similarity nominates material; authority determines whether it governs. |
| Recent | Approved | Freshness does not create approval. |
| Working copy | Governed record | Convenience does not create canonicality. |
| Recommendation | Decision | Generation does not establish accountability. |
| Tool access | Mutation authority | Capability is not a mandate. |
| Candidate context | Trusted context | Promotion requires review, evidence, and explicit authority. |
Authority must be explicit
The system needs contracts for:
- source authority
- instruction precedence
- decision authority
- mutation authority
- exception authority
- context-promotion authority
The fact that an agent can change a repository, database, workflow, or infrastructure component does not mean it has the mandate to do so.
Capability is not authority.
Contradiction and ambiguity are normal
Real operating environments contain stale records, scoped policies, overlapping definitions, incomplete evidence, exceptions, and sources that disagree.
The architecture must define whether the system resolves, escalates, quarantines, asks, or stops.
Take the most recent result is not a universal conflict-resolution strategy. Recent can still be wrong, unapproved, out of scope, or nonauthoritative.
The knowledge corpus is production
In a context-as-code environment, policies, decisions, instructions, evidence, relationships, and exceptions can directly shape future agent behavior.
When an agent can rewrite its own operating context, you are no longer managing documentation. You are managing the future behavior of the system.
Candidate context and trusted context must remain separate. Generated material does not become organizational memory because the model wrote it confidently and the file saved successfully.
When an agent can rewrite its operating context, it can rewrite future behavior.
Review consequence, not only access
The security question is not only:
What can this system access?
What can this system cause?
The architecture must bound maximum scope, target eligibility, reversibility, approval, validation, observability, rollback, retained evidence, and stop conditions.
A read-only research worker and a production mutation worker may use the same model. They do not have the same risk.
Human judgment belongs at authority transitions
Human review belongs where authority changes, ambiguity remains material, evidence is incomplete, consequences become difficult to reverse, an exception is requested, or the system proposes modifying its own governing context.
Models can perform increasingly sophisticated work. They do not establish their own organizational mandate or accept accountability for the outcome.
A decorative human-in-the-loop box does not establish accountability.
Require two architecture views
Every consequential AI architecture submission should include:
- the technology architecture
- the architecture of intent
- an alignment matrix binding each capability to objective, authority, permitted action, evidence, scope, approver, validation, rollback, and stop condition
The first view proves the system can work.
The second helps prove it can be trusted to work in the intended way.
Technology architecture
Components, data paths, identity, security boundaries, deployment, observability, resilience, recovery, and failure modes.
Architecture of intent
Objective, semantics, truth hierarchy, conflict rules, decision and mutation authority, blast radius, evidence, rollback, and stop conditions.
Alignment matrix
| Capability | Intended outcome | Governing authority | Action class | Maximum scope | Stop condition |
|---|---|---|---|---|---|
| Retrieval | Provide relevant context | Source and permission contract | Read / retrieve | Eligible corpus only | Evidence gap or conflict |
| Code generation | Prepare a candidate change | Repository and issue authority | Prepare | Isolated branch or worktree | Validation failure |
| Database update | Change approved records | Application owner and policy | Mutate | Explicit rows / objects | Scope or integrity uncertainty |
| Infrastructure action | Apply an authorized change | Change authority | Mutate | Named target set | Blast radius exceeds limit |
| Knowledge promotion | Add trusted operating context | Content owner and promotion contract | Promote | Exact approved artifact | Unresolved contradiction |