Intent Mediation Platform

IMP FORGE

Tell it what you want. In ordinary words.

Start a conversationHow the work goes

Start a conversation

You do not have to say it properly. Type it the way you would say it out loud. Spelling mistakes are fine. What comes back is a plan, in plain sentences, that you read and argue with before anything gets built.

Everything shown below is the real thing running. So is this page — a program in the same workshop made it.

What this is

A box you type into, and a gatekeeper behind it

You write what you want the way you would say it. Underneath, the words are checked, the job is written out, and a machine is asked only the part that needs asking.

The IMP panel inside the console. A typed sentence asking for a program to find municipalities within three hours of Cincinnati is returned as a user story in AS A / I WANT / SO THAT form, followed by numbered GIVEN/WHEN/THEN acceptance criteria. A model selector above shows hosted and local models, with local and private modes available.
Type it the way you would say it, typos and all. What comes back is a user story and acceptance criteria you can argue with. The models on offer include ones that run on your own machine, and the sentence you actually wrote is kept beside the rewritten one.
The console's Datasources page listing every connection the framework is told about — the source-code corpus, the identity spine, the inventory, the wiki, the secrets vault, the fleet control API — each with what it holds. A left-hand menu lists Board, Stories, Sprints, Tasks, Runs, Bugs, Postmortems, Git, IMP, Boxes, Shards, Lexicon, Ontology, Architecture, Manual, Datasources, Corpuses and Capability. The IMP panel is open on the right with a model selector and a live session.
Every connection the system has been told about, and what lives on each one. The page states its own rule at the top: a datasource is a row, so routing is a query rather than a setting somebody remembers.
A list of sprints, each titled as a full sentence rather than a code — 'imp is the harness and the terminal reads typed signals not prose', 'the box refuses before the model spends and the estimate is history', 'the shard inspector proves what a model saw and the board links to it' — with story state, acceptance-criteria counts and item counts beside each.
Work is named in sentences, not ticket numbers. Each row carries how many acceptance criteria it has and whether the story is draft or ready, so the state of the work is readable at a glance.
A shard inspector showing the selection policy as JSON and a panel headed 'Payload — what was sent', with buttons to reveal the sent shard and preview its mediated form. A banner states that this one was a preview, never sent and never recorded, and gives the hash it would have had.
Exactly what a model was shown, kept and inspectable afterwards, with the rule that selected it. When something was only previewed, the page says so rather than implying it ran.

How it works

From a sentence to work somebody can check

Three steps. Nothing is built until you have read the plan and said yes.

1
It asks, in plain words, until the shape is complete. Each answer adds one strand to the canvas, and the last question is always the one about why — a chain that produces a file but cannot say what it is for does not get to close.
A canvas showing a chain of labelled boxes — Tom opens Spreadsheet, reads Customer rows, merged into a Letter, prepared and held pending Gmail authorization, producing an Emailed letter. Beside it a transcript shows IMP asking the customer short clarifying questions and adding a noun or a piece of data after each answer.
2
The conversation becomes a sprint with criteria that are rows, not prose. Each one starts UNSATISFIED and has to be satisfied by something nameable. Nothing is approved until a person clicks approve.
A sprint page titled 'Tom mails or emails every citizen who commented during the initiative their own submitted comments, thanking them for participating', marked DRAFT with an approve button. Below it the user story in AS A / I WANT / SO THAT form and five acceptance criteria rows, each GIVEN/WHEN/THEN, each marked UNSATISFIED and awaiting judgment.
3
The drawings are rendered from the requirement rows, so they cannot drift from what was agreed. The page names its own open questions rather than smoothing them over — what is still undecided is written down as undecided.
A page of generated diagrams for the same sprint. One row of boxes shows Tom opens Spreadsheet, reads Customer rows, merge into Letter, print and CEO sign, Mailed letter. A second shows the email path: Letter, prepare, Prepared email, hold, Held pending Gmail authorization, operator authorizes connection, Ready to send, Sent via Gmail UI.

Why it is different

There is a gatekeeper in the middle of all this. It is called imp. It sits between you and the machine. The machine can suggest. The imp decides what gets through. The machine never writes anything down on its own.

Every important word means one thing. Most teams use the same word for two different things and nobody notices until something breaks. Here each one has an agreed meaning, written down — 252 of them so far. Use one wrongly and the tools stop you. A wrong name is worse than no name, because the machine believes it.

Your private work stays on your machine. Papers are broken into shapes on your own computer first. If something is private, only a machine on your own desk may look at it. We keep a record of exactly what was sent, every time, so did anything private leave this building is a question with a real answer.

It gets cheaper the longer you use it. Most tools charge more the more you use them, so they are glad when you use more. This one works the other way round. Anything that happens twice becomes a small program, and programs are free to run. The machine is only asked about something genuinely new.

Built out of parts that already work

A machine told to write software from nothing writes something that looks right. Give it parts that already work, with honest names and clear edges, and it builds something that runs.

The library is 445 of those parts, all in Rust, built and tested over years. One part knows about money. One knows about people and companies. One knows about places, one about calendars, one about keeping an unalterable record of what happened. They are stacked in layers, and a part may only lean on the layers beneath it, never sideways and never up.

445parts in the library
865,878lines of Rust
12,866tests
252agreed words

Every number was counted on 2026-09-18, and the command that counted it is written down beside it. See what they count.

Why it is all written in Rust

Rust is a fussy language. It refuses to build your program if certain kinds of mistake are in it — not a warning you can ignore, a refusal. Most languages would let those through and you would find out later, when a customer did.

That fussiness matters far more when a machine is doing the typing. A machine writes plausible code very fast. The compiler reads every line of it before any human does, and throws out a whole class of mistake for free — no test run, no review, nothing to pay for. It is the cheapest checker in the building and it never gets tired.

It can hold rules that are not about programming at all. In one of these products, a supplier's licence says their sales figures may never be shown to an AI. Rather than write that down and hope, the pricing function is built so those figures cannot be handed to it — the wrong sort of thing simply will not fit. A promise to a lawyer, kept by a compiler.

Technical stack

A fleet control page listing ten hosts, each with its node id, hostname, operating system — mostly FreeBSD, some Linux — agent version, certificate validity, issue and expiry dates, and per-host actions for a terminal, a token and a download. All ten show Online.
The machines, and what is true of each right now. Most of them run FreeBSD. Every one carries its own certificate with an issue and an expiry date, so trust between them is something with a date on it rather than a password somebody shared.
A page of deployable modules, each a card with a name, a version, a size and a content hash: antivirus, backup, bash-setup, cbsd, control-panel, data-recovery, desktop-apps, disk-cleanup, disk-usage, dotfiles, fail2ban, firewall, health-check, jail-testing, log-stats, manpage, media-apps, network-scan.
The jobs the fleet knows how to do, each one a sealed bundle with a hash. A machine is not told to run a script somebody pasted; it is handed a named thing whose contents can be checked against what was published.

One machine, divided into jails. Each has one job and its own address, so a mutation run that goes berserk cannot reach the database that holds the record, and the box facing the internet holds no working copy of anything.

                    one FreeBSD machine
┌──────────────────────────────────────────────────────────┐
│                                                          │
│   ┌───────────┐   ┌───────────┐   ┌──────────────────┐   │
│   │  pg01     │   │  imp      │   │  rfw             │   │
│   │  the      │   │  console  │   │  the checkout    │   │
│   │  record   │◄──┤  chat     │──►│  and the         │   │
│   │           │   │  dispatch │   │  toolchain       │   │
│   └───────────┘   └───────────┘   └──────────────────┘   │
│         ▲                                                │
│         │ read only              ┌──────────────────┐    │
│         └────────────────────────┤  mutants         │    │
│                                  │  breaks things   │    │
│   ┌───────────┐                  │  on purpose      │    │
│   │ mutants_pg│◄─────────────────┤                  │    │
│   │ throwaway │   writes here    └──────────────────┘    │
│   │ in memory │   and nowhere else                       │
│   └───────────┘                                          │
└──────────────────────────────────────────────────────────┘

What happens when you ask for something

The same shape, written out. Note where the line is: a model is handed a bounded thing and hands back a suggestion. It never reaches past the imp.

   you, in ordinary words
│
▼
┌─────────────────────────────────────────┐
│  imp                                    │
│   · keeps exactly what you wrote        │
│   · rewrites it in agreed words         │
│   · works out what is actually needed   │
└─────────────────────────────────────────┘
│
├──────────────► already a program?      ──► done, costs nothing
│
├──────────────► private material?       ──► a model on your own desk
│
└──────────────► genuinely new?          ──► a hosted model
│
▼
┌─────────────────────────────────────────┐
│  imp again, on the way back             │
│   · is this the shape we asked for?     │
│   · does it use the agreed words?       │
│   · record what was sent and returned   │
└─────────────────────────────────────────┘
│
▼
a person approves        then it is written down

Why an imp

The little devil on the corner of an old Unix manual page has been there for forty years, reminding everyone that the thing doing the work in the background is small, horned, and not very sorry. An imp does what it is told, inside a line somebody drew. That is the whole idea — and it is why the drawing came before the sales pitch.

How to start

Write in plain words about what is broken, or what you want to exist. No specification needed — working one out is the first piece of work, and it is the part you buy first. Start a conversation.