Architecture / 03
A system built around accountability.
The orchestrator connects models, context, evidence, and tools. Each has a distinct responsibility; the result is judged against the work performed.
On this page
The architecture at a glance
A request enters a controlled workflow. Planning establishes scope and dependencies. Analysis investigates when the task calls for it. Authoring or execution produces authorized work. Final analysis reconciles the answer with evidence and outcomes.
The drawing is conceptual: not every request visits every stage, and the hardware symbols are representative. In particular, authorized artifact authoring can proceed from planning into execution without turning the request into a defect investigation.
SpecKit 008 · AC-008-002-14 · SpecKit 018 · AC-018-005-01 · AC-018-005-03
The control layer
The orchestrator manages the lifecycle: what is ready to run, what depends on another result, which limits apply, and when the work must stop or return an incomplete outcome. The model contributes proposals within that process.
Separating these responsibilities makes the system easier to evaluate. A fluent model response cannot substitute for a completed dependency, a valid operation, or evidence that a check passed.
SpecKit 009 · AC-009-005-01 · AC-009-008-01 · SpecKit 001 · AC-FR003-01
The evidence and context layer
Working material is organized outside any one response. Evidence records preserve attribution; context assembly selects relevant material for the current step. Search helps discover where to look, while authoritative reads support claims about the source.
This separation matters when work is long or distributed. A useful summary is navigation and context. Its convenience does not make it a replacement for the evidence behind a conclusion.
SpecKit 007 · AC-007-003-07 · AC-007-005-01 · SpecKit 005 · AC-005-001-01
The action layer
Tools connect reasoning to the workspace. Their structured requests and results give the runtime something concrete to validate. Changes pass through the staged mutation lifecycle and its required checks; completion must reflect actual outcomes.
The purpose is to contain the distance between intention and effect. A proposal, an attempted write, a committed change, and a verified result should remain distinguishable throughout the run.
SpecKit 003 · AC-003-002-01 · AC-003-003-01 · SpecKit 004 · AC-004-004-01 · AC-004-004-02
The model layer
Model selection is part of the configured deployment. Different stages can have different needs, and the runtime accounts for limits and usage. The models supply reasoning capacity; they do not replace the process’s authority over actions and final claims.
Merlin can run on infrastructure you control. Cloud escalation exists, is configuration-gated, and can be switched off. Evaluating data residency requires reviewing the actual deployment and connected tools, not inferring a boundary from a diagram.
SpecKit 009 · AC-009-008-01 · AC-009-008-02 · Deployment boundary