A reliable process around AI.

Why we built Merlin #

Useful intelligence needs a dependable way to work. A persuasive explanation is not enough when someone must review a system, make a change, or act on a finding. They need to know what was inspected, which conclusions survived scrutiny, what actually changed, and what remains unresolved.

Merlin began with that engineering problem. The early design explored a bounded recursive process: keep working material outside a single model response, examine it in manageable parts, and let the runtime own the limits and stopping conditions. The vision developed into an evidence-governed AI runtime. Models contribute reasoning; the surrounding system governs how that reasoning becomes work.

We built Merlin to make that distinction useful in practice. Responsibility should not disappear into a confident paragraph. A system should be able to account for a partial result just as clearly as a successful one.

SpecKit 009 · AC-009-008-01

What we mean by deterministic #

The ambition is a dependable process, not a promise that a language model will produce the same words every time. Model judgments remain probabilistic. Different evidence, models, configurations, or environments can lead to different outcomes.

Some controls can be exact: whether a requested operation has a valid structure, whether a cited line exists in material that was read, whether a verification receipt supports the assertion being made, or whether unresolved blockers contradict a claim of completion. Other questions—such as whether an interpretation is sound—still require judgment.

Merlin combines these forms of checking while keeping their authority distinct. The goal is to narrow uncertainty, expose what remains, and make consequential steps answerable to evidence. Recursion alone does not create determinism; disciplined control of the process is the work.

SpecKit 005 · AC-005-004-02 · SpecKit 004 · AC-004-004-02 · AC-004-004-03

The principles behind the system #

Evidence before assertion. A finding should point back to the material and work that support it.

Authority before action. A model’s suggestion is not permission to change a workspace.

Verification before completion. A generated artifact and a verified outcome are different things.

Honest limits. A blocked, uncertain, or incomplete result carries information that a success-shaped summary would erase.

These principles are expressed as acceptance criteria, not just advice to a model. The following pages explain the concepts and the SpecKits that define their behavior.

SpecKit 018 · AC-018-001-02 · SpecKit 004 · AC-004-004-01 · AC-004-004-03

Built for work with consequences #

Software is a useful proving ground: files can be inspected, proposed changes can be reviewed, and tests can be run. The underlying need is broader. Document review, technical research, incident investigation, and specification authoring also require a connection between a request, the evidence gathered, and the result delivered.

The benefit we are pursuing is less uncertainty at handoff. An evaluator should be able to distinguish an observation from an inference, a proposal from a completed action, and a passed check from an untested claim. That is a practical foundation for trust, even when the system cannot finish everything.

SpecKit 014 · AC-014-002-01 · SpecKit 018 · AC-018-003-01 · AC-018-004-04

Start with the architecture #

Read Recursive language models for the foundation, then the architecture overview and core concepts. Follow the orchestrator through each stage to see how the parts work together.

These are public explanations of intent and observable behavior. SpecKit references identify the governing requirements; they are not a claim that every internal design document is published or that a specification, by itself, proves a deployed system correct.