You author the architecture. ArchRails steers the agent onto it, gates the write and the pull request, and keeps the record. Same engine in the session and at merge — no model in the decision path.
Built on FINOS CALM v1. Evidence an auditor verifies offline, without logging into us. One product, sold as an engagement.
The architecture lives in your repo, owned by humans. The thing being gated cannot legalize its own change.
Before it writes, the agent is given the journey and the code that already exists in that service.
A non-compliant file is never written. Bypass the session and the pull request still gets the identical verdict.
Findings name the control you attached. The evidence does not depend on logging into us.
ArchRails
OrderService calls PaymentService directly — must route via service-api-gatewayOrderDatabase accessed via HTTP — node declares JDBC:5432 onlyInventoryService changes scoped to service-inventory — no leakageInstead of architecture living in Confluence, Visio, wikis, and slides that drift from what shipped, you describe it as a schema-validated JSON file that lives next to the code.
CALM (Common Architecture Language Model) is the open standard for that file, maintained by FINOS. Nodes, relationships, and the rules that bind them — a model agents and the PR gate can actually check.
ArchRails runs in the agent's session. It steers while the agent codes, then gates the write. The pull request is the same engine.
Before the agent writes, it is given the journey, the owning node, and the symbols that already exist in that service. Guidance is the product. The refusal is the backstop.
Agents can't edit your CALM files to make non-compliant code legal. Architecture changes go through your normal human-reviewed PR process. The gate can't be rewritten by the thing it's gating.
If the session is bypassed — a manual edit, a raw push, a different agent — the pull request still gets this verdict. Two surfaces, one source of truth.
Ask ArchRails the same question twice and you get the same verdict twice. No model sits in the decision path, so there is nothing to re-roll and no answer that drifts between Tuesday and Thursday. That is what makes a verdict something you can put in front of an auditor rather than something you have to defend.
And it is judged against an architecture that is current. The graph moves with your merges, so what gets enforced today reflects what shipped yesterday — not a diagram someone exported last quarter and forgot.
Most tooling reviews what an agent already wrote. By then the change exists, the branch is open, and someone is arguing about it in a comment thread. ArchRails applies your architecture at the point the agent is deciding what to do — so a change that would violate it doesn't get written, and the agent works out another way to solve the problem instead.
Crucially, the rules do not soften because the author was a machine. An agent gets the same verdict a human would get for the same change, and every refusal is recorded. When your risk function asks what your agents have been prevented from doing, that is a question with an answer — which is not the same as being able to say you allow agents but supervise them carefully.
The same holds for infrastructure. You author the control on the architecture. Anyone changing Terraform in that repo is judged against it. Application source is not proof that a store is encrypted. A control you apply to the whole architecture applies to every node in it.
Architecture governance has lived at PR review forever. ArchRails keeps it there — and puts the same engine in the agent's session so a forbidden write never starts. One product. Two surfaces. Read the product.
Signed in? Academy lesson: Infrastructure controls.
Cursor attempts a forbidden DB call during a 3 AM hotfix. ArchRails blocks it in the session; the agent rewrites against the permitted path. Production stays in PCI scope.
ArchRails doesn't invent standards. It enforces what your team defines in a CALM document, and cites every node it used.
If a node, relationship, or interface constraint isn't in your calm.json, ArchRails won't enforce it. Full stop.
Feedback cites the exact CALM node ID, relationship ID, or interface that triggered it — so teams align faster and argue less.
Reviews resolve only the CALM nodes touched by the PR diff. Less noise, fewer false positives, no cross-service contamination.
Every governed merge produces a signed attestation — what the architecture was, that the change was evaluated against it, and who promoted it. You download it and check it yourself. You never have to take our word.
What an attestation is, and is not. It proves what your architecture was at a merge, that the change was evaluated against it, and by which build. It does not contain your code. Your SCM already holds the pull request. The attestation binds to that record rather than duplicating it.
Paste your calm.json to instantly check for interface violations, missing controls, and structural issues — then render your architecture graph interactively. No account required.
archrails arch generate in your repo and it reads your code and writes a first-draft architecture document, plus the configuration ArchRails needs to enforce it. It uses a coding agent you already have installed — Claude Code, Codex, Gemini CLI or Cursor Agent — so ArchRails calls no model service of its own and no AI API key is involved. Budget 20–40 minutes on a large repo; it is a one-time cost. You review the draft like any other PR, merge it, and enforcement starts on the next one. If you'd rather author by hand, the free CALM Visualizer is available with no account required. Declaring the architecture once is the fundamental that lets AI amplification go in a useful direction; without it, more agents just means more entropy.calm.json. Every comment is traceable to a node ID you authored. It's deterministic, not probabilistic, and the same gate runs at PR time and inside the coding agent — so the agent can't reach an API your architecture forbids. As Adam Bender put it at SE@TP 2026: “all of your APIs just became public” the moment you let agents loose. ArchRails is the contract that says which ones they're allowed to call.calm.json at the repo root describes your full system graph, and ArchRails only evaluates the slice of the graph a given PR actually touches — a payment-service change won't trigger inventory-service checks. This is deliberate: dependency graphs scale quadratically with codebase size, so at the 10× AI-driven velocity everyone is preparing for, evaluating everything on every PR is how you burn your test budget into the ground.Start with one repo and one CALM document. ArchRails will enforce it on every pull request.