Daml's MCP safety layer: Daml Reason

Daml Reason gives your AI assistant traceable, compiler-validated patterns or an honest "not covered." Never confidently wrong Daml.

Daml is a safe-by-construction smart-contract language. The authorization model is explicit. Every choice, signatory, and observer is declared in the code.

The AI coding assistants people use to write Daml are the opposite. An LLM completes patterns, but doesn't verify what they mean for the business. Feed it enough Daml, and it will produce code that looks right: plausible choices, familiar structure, an authorization model that compiles cleanly and encodes the wrong economic or legal relationship. The gap isn't syntax. The question isn't whether a model can write Daml. It's whether the agent should proceed, and on what authority.

We've spent the last year on a two-part answer to this. The first part shipped in March: Daml Autopilot, the first MCP server for the Canton Network, grounding AI suggestions in compiler-validated patterns. The second part is what we're announcing today: an upgrade to Daml Reason, the MCP tool that Daml Autopilot exposes. It's one tool with two phases, one before any code exists and one after, and it isn't a code generator. It's the condition that tells an agent when to continue, when to fix, and when to hand the work back.

The server retrieves. It doesn't generate.

The old model pulled patterns from documentation and GitHub repositories, which worked until the SDK moved, the docs aged, and the assistant confidently suggested patterns from a version of Daml that no longer exists.

We removed generation from the server. Before any code exists, describe your business intent, and Daml Reason searches a promoted bundle: a curated, compiler-validated corpus of canonical Daml patterns. What comes back is a short, diversified set of template matches with pinned source references, plus a deterministic explanation that ties the terms in your intent to the templates it matched. If your search text was rewritten to improve recall, the tool will disclose that, too.

For a financial institution, that means the assistant cites institutional memory with provenance, not whatever looked plausible in training data or a stale blog post. The first draft is grounded in named, versioned patterns your team can trace.

Abstention is the safety feature.

Most AI tools optimize for always having an answer. Daml Reason optimizes for answering only when recall is confident.

Our corpus is curated, which means it has edges. Trust gates check both how strongly the top pattern matches and how clearly it stands apart from the runners-up, and they reject ambiguous clusters. When your intent is too vague, recall is weak, or the corpus simply doesn't cover what you're asking, Daml Reason returns delegate: a first-class outcome, not an error, that sends you back to sharpen the intent. No list of weak matches comes attached. The agent can't dress up uncertainty as guidance.

In regulated work, "I don't know, sharpen your intent" beats confident, wrong pattern completion. Audit teams prefer structured abstention to fluent hallucination. An assistant that knows what it doesn't know is the rarest kind of AI feature, and the most important one for safety-critical code.

A versioned corpus, with drift detected loudly.

Patterns come from a promoted, versioned bundle, not live scraping of docs and GitHub. We won't claim patterns never age. We'll claim that as Daml and Canton evolve, drift is detected loudly rather than silently ignored.

A verdict loop, with compile proof required to pass.

Once code exists, Daml Reason takes your business intent and your draft together and returns a structured verdict on whether to continue, compile, fix, or hand off. You can go around as many times as you need (that's the point). Under the tool contract, a pass requires compile proof.

The server doesn't compile. You run the Daml compiler on your own machine and forward the result as a hard signal. Your code compiles on your machine; the server never needs your proprietary Daml source to run the compiler. For financial institutions and enterprises adopting AI-assisted development, that's table stakes.

We'll be plain about where this stands: checking alignment between intent and code is still maturing, and Daml Reason doesn't prove your business logic correct. What it gives you today is a structured verdict loop, with compile proof required for a pass.

One contract for your IDE and your CI.

Same tool, same outcomes, same bar for what counts as a match, whether the caller is an agent in Cursor or a merge gate in your pipeline. Governance teams get one verification contract to enforce, instead of IDE magic on one side and CI rules on the other.

Why we built it this way.

Our design posture is deliberate. Daml Reason is a single-purpose MCP tool that does one job: the safety layer between LLM drafts and ledger code. Generation stays client-side in the developer's IDE; the server retrieves, gates, and renders verdicts. The intended loop is simple: orient on corpus patterns (or get told to sharpen your intent), draft locally, then run the verdict loop and compile when you're ready.

We're not optimizing for an autonomous code factory. We're building for how banks actually work: human accountability with AI acceleration, not replacement. And we don't think a company's entire codebase should be dependent on any single large-scale AI application.