Framework
The engineering model
A practical way to connect intent, architecture, implementation, and operational evidence.
Working engineering model — an evolving proposal, not a certification standard.
The six lenses
Each lens has a purpose, a few practical questions, and an output you can point at. They are connected lenses, not a rigid waterfall — security, privacy, governance, and operational ownership apply throughout. Learning does not imply automatic retraining or expanded permissions.
- 01
Define intent
Clarify users, desired outcomes, constraints, and ownership.
- Who is this workflow for, and what outcome counts as useful?
- Which constraints are non-negotiable?
- Who owns the result when it goes wrong?
Output — An intent brief and acceptance criteria.
- 02
Architect relationships
Map actors, boundaries, context, decisions, and dependencies.
- Which actors participate, human and automated?
- Where are the trust and data boundaries?
- Which decisions depend on which inputs?
Output — A system map and interface contracts.
- 03
Integrate capabilities
Connect models, agents, data, and tools with explicit responsibilities.
- What is each component responsible for, and what is it not?
- What does a tool accept, return, and refuse?
- Where does context come from, and how fresh is it?
Output — A component map and integration contracts.
- 04
Govern action
Establish decision rights, permissions, approval requirements, and escalation.
- Which actions require a person to decide?
- Which permissions apply regardless of what a model proposes?
- How does an unresolved case escalate?
Output — An authority matrix and control rules.
- 05
Verify outcomes
Test behavior, failures, evidence quality, and recovery limits.
- How do we confirm the action actually happened?
- What evidence is retained, and for how long?
- Which failures cannot be undone?
Output — Test scenarios and an evidence record.
- 06
Operate and evolve
Monitor outcomes, investigate incidents, and introduce reviewed improvements.
- What signals indicate the system is drifting?
- Who investigates an incident, and with what access?
- How is a change reviewed before it reaches production?
Output — An operating runbook and change process.
Engineering principles
Guidance produced for this project. It describes how the Engineering work intends to behave, not a claim about any external standard.
Understandable behavior
A person should be able to explain what the system did and why, without reading a trace they cannot interpret.
Meaningful human direction
Direction means a real decision at a real moment, not an acknowledgement dialog after the fact.
Explicit boundaries
Permissions, data access, and tool scope are stated in the architecture, not inferred from prompt text.
Traceable evidence
Claims about what happened are backed by records that can be inspected independently of the system that produced them.
Proportionate controls
Control weight follows consequence. Low-risk steps should not carry the ceremony of irreversible ones.
Honest recovery limits
Some external actions cannot be reversed. The design should say so rather than imply universal undo.
Architecture explorer
Five layers and two cross-cutting concerns. Untrusted inputs are not authority, and a model proposal does not bypass application permissions.
A conceptual reference architecture — not an installed runtime and not a live system monitor. Select a layer to read its purpose and controls.
Cross-cutting
Authorization and policy
Spans every layer. Decision rights, permissions, and approval requirements are defined in the system, independent of what any model proposes.
Cross-cutting
Observation and evidence
Spans every layer. Records of inputs, decisions, actions, and outcomes that can be reviewed after the fact.
Layer 1
Human intent and interaction
- Purpose
- Where people state goals, review proposals, and make consequential decisions.
- Main question
- What does the person actually want, and what may they decide here?
- Example artifact
- Intent brief with acceptance criteria and review points.
- Control consideration
- A request expressed in natural language is input, not authority. Interface affordances must reflect real permissions.
Text equivalent of the full architecture
Layer 1 — Human intent and interaction. Where people state goals, review proposals, and make consequential decisions. Main question: What does the person actually want, and what may they decide here? Example artifact: Intent brief with acceptance criteria and review points. Control consideration: A request expressed in natural language is input, not authority. Interface affordances must reflect real permissions.
Layer 2 — Context, knowledge, and memory. The material the system draws on: documents, records, prior interactions, and state. Main question: Where does this context come from, and how current is it? Example artifact: Source register with freshness and sensitivity annotations. Control consideration: Retrieved content is untrusted input. Text inside a document never grants access or changes policy.
Layer 3 — Reasoning and orchestration. Planning, decomposition, and routing between models, agents, and deterministic steps. Main question: Which steps are proposed, in what order, and under which assumptions? Example artifact: Plan record with assumptions and a concise rationale. Control consideration: A plan is a proposal. It becomes action only after the governing layer permits it.
Layer 4 — Tools and execution. The point where the system changes something outside itself: writes, sends, schedules, pays. Main question: What is the real-world consequence of this call, and is it reversible? Example artifact: Tool contract with scope, inputs, failure modes, and idempotency notes. Control consideration: Permissions are enforced by the application and the tool, not by the model deciding to behave.
Layer 5 — Outcomes and feedback. Confirming what happened, retaining evidence, and feeding findings back into intent. Main question: How do we know the outcome, and what do we keep as proof? Example artifact: Verification record with outcome, evidence, and open questions. Control consideration: Completion of a step is not confirmation of an outcome. Unverified means unverified.
Authorization and policy. Spans every layer. Decision rights, permissions, and approval requirements are defined in the system, independent of what any model proposes.
Observation and evidence. Spans every layer. Records of inputs, decisions, actions, and outcomes that can be reviewed after the fact.
Untrusted inputs are not authority, and a model proposal does not bypass application permissions.