flmnt → the workflow
Don't review the code. Review the agreement.
One pull request, assembled. It starts the way most arrive — a wall of diff and a ticket — and every stage of the harness attaches something to it. Watch it fill in as you read.
How it arrives todayno harness
Correct-looking code, and no way to know if it was the right thing to build.
Twenty-three files, fourteen hundred lines, and a ticket written three weeks ago. Everything a reviewer needs to judge whether this work should exist is somewhere else: in a conversation, in someone's memory, in a decision that may have changed since the ticket was written.
So the reviewer does the only thing available. They read the diff and reconstruct the intent from it — which means the code becomes the specification, after the fact.
- The reviewer's real questionNot "is this code correct" but "is this the thing we decided to do?" Nothing in the request answers it.
- Where the cost landsTrust gets decided here, at the most expensive point in the process — after the work exists.
- Why more reviewers don't fix itReview time is climbing wherever agents write code. Adding a reviewer, human or AI, treats a throughput problem. This is an information problem.
What's missingEvery layer below this line. The rest of the page adds them one at a time.
The substrateflmnt · throughout
First, the decisions this work rests on — and the fact that they're current.
Before any of the other tools make sense, there has to be one answer to "what did we decide?" Not a document someone remembers to update. A record that serves what is true now, keeps what it replaced as history, and carries the reason for both.
A CI worker writes that record onto the pull request as a comment. The reviewer doesn't go looking; the decisions arrive beside the code, where they already are.
- Five decisions, all currentPer-tenant metering; monthly billing on the 1st; overage blocked rather than billed; three days of grace; usage during grace counted but never billed.
- One of them replaced anotherThe retired version stays readable as history. It stops being an answer to any agent that asks.
- Each carries its why"Overage is blocked, not billed — a surprise invoice costs more than a blocked call." The reasoning is the part that stops it being re-litigated.
- This layer alone is enough for most teamsEverything after it is optional. Nothing after it works without it.
AttachedDecision history, posted by CI. Five decisions, all current.
DefineMoment · before code
Then the design those decisions produced, with time in it.
Decisions in prose are still ambiguous. Moment turns them into a domain design that states what exists, what can happen, in what order, and what happens later as a consequence — the part most modeling tools leave to the implementation.
It also asks back. A design surfaces the questions a conversation skipped, and each answer becomes a decision in the record before any code depends on it. On this build that produced the fifth decision: what happens to usage recorded during the grace window.
- billing.moment · v1Attached to the request, so the reviewer can see what the work was shaped by.
- The thingsTenant, UsagePeriod, Invoice — and what can be true of each.
- The events, in orderUsageRecorded → CapReached → PeriodClosed → InvoiceIssued. Named moments, not implied side effects.
- Policies and sagasWhen PeriodClosed, issue the invoice — behavior that spans more than one step.
- Time, made explicitPeriod boundary on the 1st. Grace timer, three days. Written down, not left to whoever implements it.
- What it provesThe model is complete and correctly wired: no dangling event, no unreachable state, no rule the team never actually decided.
Attachedbilling.moment v1 — the domain design, traced to the five decisions.
DefineFacet · before code
Then the evidence that the design actually holds.
A design that reads well can still be incoherent. Facet executes it — no application, no database, no code — and plays scenarios through it to see what it really does.
On this build, two scenarios behaved and one did not: when the period closed during the grace window, the invoice policy fired before the grace timer had expired. That is a five-minute fix in a design and a week in production. It was fixed in the design, and the corrected design was re-run until all three held.
- A normal monthHolds.
- Cap reached mid-monthHolds.
- Period closes during graceContradiction found: invoice issued too early. Fixed, then re-run green.
- What it provesThe design is coherent: events flow in order, contracts hold at every boundary, and sagas and policies behave — including where they overlap.
- Why it's attachedThe verified state lives with the work, so nobody has to remember whether the design was ever checked.
AttachedThree scenarios, verified — including the one that failed first.
BuildFeature · before the build
Then the promise: what will be built, and exactly what it may touch.
A spec in Feature is not a document for humans to read and agents to ignore. It states the promise and the blast radius, and it is machine-checkable in both directions — against the design above it, and against the delivered work below it.
Feature checked these three against billing.moment and found two event names that no longer matched the model. Caught before the build, not after. Then a person flipped them from draft to agreed, which is the only way that transition can happen.
- metering.featRecord usage per tenant per call. May touch /billing/metering and nothing else.
- period-close.featClose the period on the 1st; issue the invoice after grace. One name corrected against the model.
- invoice.featIssue and deliver the invoice, with the pro-rata rules. One name corrected against the model.
- The tests come from the specsNot inferred from the code that was produced. That direction matters.
- Draft → agreed, by a personThe human stays the authority on intent. An agent cannot agree its own spec.
AttachedThree specs, agreed by a person. Promise and blast radius stated.
ProveFeature · after the build
Then the answer: was the promise kept, and was anything else touched?
With a spec that states both the promise and the blast radius, proving the result is mechanical. The report says whether the delivered work does what was agreed, and whether it changed anything it was not allowed to change.
That second half is the one reviewers can't do reliably by reading. A diff shows what changed; only the spec says what was permitted to.
- Promise keptEvery assertion in the three specs, satisfied by the delivered work.
- Nothing unpredictedNo file touched outside the declared blast radius.
- Model conformanceWhat the specs assert still matches what the domain model declares. This is the gate that catches drift after the fact.
- What it provesThe delivered work does what was agreed, and nothing unpredicted. That is the sentence a reviewer actually needs.
AttachedReport — passing, nothing outside the specs.
The reviewera person, deciding
Two confirmations, and the expensive judgment already made.
The request now carries its own case: the decisions it rests on, the design they produced, the evidence that design holds, the promise that was agreed, and the report that says the promise was kept. The reviewer confirms the promise, then confirms it was kept. Style and quality go to linters and other agents.
Nothing here removes review, and nothing here makes an agent trustworthy. What moved is when trust gets decided — from after the build, where changing the answer is expensive, to before it, where changing the answer costs almost nothing.
- Together, these stages catch driftA decision made weeks ago quietly stopping being load-bearing. That takes the whole harness, not the record alone — and no part of it removes a person's judgment about what was intended.
- Adopt in any orderMost teams connect the record and stop there for a while. That's the right order.
CompleteThe agreement is reviewable. The code is checkable by machine.
The tools
Four tools. One is required, and it isn't the workflow.
Each is available today, each has its own home, and each can be adopted without the others.
Throughout
Your team and every agent work from what you decided.
Proves that agents get the current decision, with its reasons, every time — and that the replaced one is history, not a candidate. Connects over MCP to any agent; no SDK required to adopt it.
Personal · team · enterprise licenses
Before code
Model how your business works, including what happens over time, before anyone writes code.
Proves the model is complete and correctly wired. States entities, events, policies, sagas and time explicitly, so the parts that usually live in an implementation live in the design instead.
Open source · free
Before code
Watch your design run before you build it.
Proves the design is coherent: events flow in order, contracts hold, sagas and policies behave. Executes a Moment design with no application and no database, so contradictions surface while they are still cheap.
Harness free to prove Moment designs · not open source
Before and after the build
Write down what the agent will build and exactly what it will change; the tests write themselves.
Proves the delivered work does what was agreed, and nothing unpredicted. Checks specs against the domain model before the build and against the delivered work after it. Specs flip from draft to agreed only when a person agrees them.
Open source · commercial for teams and CI
Case study
A gate compared what the specs claimed against what the model declared. It disagreed 33 times.
Marilou was built this way end to end. Twenty-four of those disagreements were real drift — specs written against a design that had since moved, every one of which would have merged as correct-looking, fully tested code.
Start where it makes sense
The record first. The rest when you're ready.
Most teams connect flmnt and stop there for a while. That's the right order.