Deterministic architectural guardrails for AI agents

Your architecture, enforced — not just reviewed.

Boundry compiles the architecture diagram you draw into a dependency linter that rejects any change crossing your boundaries — in the agent's loop and in CI. No model calls. No judgment. Just the architecture you drew, enforced.

View on GitHub Quickstart

ci · boundry check

$ npx boundry check --arch arch src

✓ boundry.lock — 7 layers, 12 allowed edges
✓ scanning 1,284 modules …

✖ boundary violation  src/ui/CheckoutForm.tsx → src/db/OrdersRepo.ts
    crosses: ui ─╳→ db   (allowed: ui → application → db)
    the accepted architecture permits no edge from ui to db

1 boundary crossed. build failed.
$ echo $?
1

Same input, same verdict, every run. The check is your accepted architecture rendered to rules — it exits non-zero the moment code crosses a line you didn't draw.

The problem

AI agents write more of your codebase every week — and architectural intent erodes faster than review can catch it.

Agents don't respect module boundaries, layering, or dependency direction. The usual fixes don't scale:

More human reviewYou can't out-review an agent. Review already can't keep up with the output it produces.
LLM-judge supervisorsProbabilistic, flaky, and unauditable — you can't trust or reproduce the verdict.
After-the-fact refactorsBy the time you catch the drift, the damage is already merged into trunk.

How it works

Draw it. Compile it. Prove every change.

Step 1

Draw the architecture

A LikeC4 diagram: the allowed layers, modules, and the dependency edges between them. Vibe it with an LLM if you want — a human signs off, and that accepted architecture becomes the contract Boundry enforces.

Step 2

Boundry compiles it

Your diagram is rendered deterministically into a dependency-cruiser linter. Same model in, same rules out. No heuristics, no model calls.

Step 3

Every change is proven

The linter runs in the agent's loop and as a CI gate, exiting non-zero on any boundary the code physically cannot cross.

Why deterministic

The opposite of a probabilistic supervisor.

The check is just your architecture, rendered to rules. Fast, repeatable, auditable — the same input always gives the same verdict.

LLM-judge supervisors

Probabilistic, flaky, and unauditable. You ask a model whether a change is okay and hope for a consistent answer — with no way to reproduce or explain the verdict when it matters.

Boundry

Your diagram compiled to rules. No model in the loop, so the same code and the same architecture always produce the same result — a verdict you can read, reproduce, and put in front of an auditor.

Pluggable by design

One tool, swappable ends.

TypeScript-firstEnforced via dependency-cruiser — but the enforcer is an injectable adapter, so other languages plug in without a rewrite.
LikeC4-firstYou author the architecture in LikeC4 — but the architecture source is an adapter too, so your model can come from elsewhere.
StandaloneA tool in its own right. Other platforms (e.g. Blueprint) can ingest Boundry; Boundry is unaware of them and depends on none.

Quickstart

Run it on your repo in minutes.

Record your architecture once, then check the tree against it. Add the same check as a CI gate; it exits non-zero on the first crossed boundary.

terminal

$ npx boundry approve --arch arch     # records the accepted architecture (boundry.lock)
$ npx boundry check --arch arch src   # enforce it — in CI and the agent's loop

Wire the check into CI — it fails the build on the first crossed boundary, so no violation ever reaches trunk.

Open source

MIT-licensed on GitHub.

Star it, open an issue, send a PR. The README carries the full pitch, the quickstart, and the pluggable design — everything you need to run it today.

View on GitHub

License · MIT Deterministic · no model calls TypeScript-first · pluggable