For teams that build with AI agents: an app in your browser to model the business with stories, rules that run and scenarios that test them, all kept in git. When the model leaves no doubt, the code comes out exact, and if not, FDN tells you.
In someone's head, in the code, in a manual or in the agent's chat.
What nobody decided gets decided in an if.
Event storming doesn't run, and nobody checks it.
Business, engineering and operations work together, each with their preferred agent.
agentNothing says who the trip's manager is: anyone could authorize it. I left you a proposal.
require status = sent
require actor = trip manager
Apply
youMakes sense. I approve it.
FDN checks the model on every change and flags what doesn't fit; your agent reads it and proposes changes through MCP, the protocol AI agents use to work with tools. You review them and decide which ones get applied.
Event storming: the business's stories as a timeline of post-its.
DDD: the rules of each part of the business. An engine runs them, so Given, When, Then scenarios pass or fail without a line of code.
The exact shape of what goes in and out, technology-agnostic.
fdn trace checks that nothing in the model is missing from the code, and that nothing is extra.fdn verify runs the same scenarios against your code, through a lightweight adapter your agent also writes. If your code says something other than the model, it fails.Node 22.18 or later.
npm install -g @fdn-dev/cli
In the folder that holds your repositories. It opens in your browser, and each repository keeps its model in .foundation/, readable and diffed in every PR.
fdn --open
Any MCP client, at http://127.0.0.1:4848/mcp. With Claude Code:
claude mcp add --transport http fdn http://127.0.0.1:4848/mcp
With a team server, business and operations join from the browser, with nothing to install.
No. Engineering installs FDN once on a team server; business and operations join from the browser with their company account, and their agent connects to the same place. What they approve reaches git as commits, and engineering reviews it in a PR.
It helps, but it isn't required. Your agent models with you, and FDN checks the model on every change: it tells you, in the business's language, what is missing or doesn't fit.
Yes. The model lives apart, in .foundation/ of the same repository, and doesn't touch your code. FDN doesn't infer the model from the code you already have: it's modeled from the business's stories.
Any MCP client: over HTTP at http://127.0.0.1:4848/mcp, or over stdio with fdn mcp if your client doesn't connect over HTTP. FDN brings no AI of its own and doesn't charge for using it.
No. FDN runs on your machine or on your team's server, never on ours; the model lives in your git and FDN sends no telemetry. Your agent only proposes: a person decides what gets applied.
Your model: one readable JSON file per context inside .foundation/, with its history in git. It's yours, and it reads without FDN.
Your agent reads a Markdown spec once, and nobody checks that the code follows it. Gherkin runs its scenarios against the code, so the code has to exist first. In FDN the scenarios run on the model and pass or fail before the code exists; FDN warns on every change about what stops fitting, and then fdn verify runs the same scenarios against your code.
They're good ways to give your agent a spec before writing code. FDN goes one step earlier: the business model runs, gets checked on every change and checks the code with fdn verify. They can be used together.
No. Model-driven tools generated the code from the model, and you had to maintain the generator and live with what it produced. In FDN your agent writes the code, in your language and your style; the model doesn't generate it, it checks it, with fdn trace and fdn verify.