One
You say what you want
In a sentence, in your own words. "A pricing page with our three plans, in a row." No measurements, no technical terms. Saying how is the builder's job.
Say it · read it back · check it
Say what you want.
Get it read back.
Let the check decide.
A promise is a sentence with one way to check it. You say what will be true. It comes back to you as a short list anyone could tick. When the work is done the list is checked, and the answer is kept or broken.
You never give measurements. You never argue that the work was done. The check is the argument, and the record remembers who keeps their word.
You said
“A pricing page with our three plans, in a row.”
Read back
- three plans, each with a name, price and button
- side by side where they fit
- every button starts checkout for its plan
- nothing cut off on a phone
One question: which three plans? There are six.
Verdict
kept broken open
The whole idea
Like ordering a cake
You tell the baker: chocolate, for ten, "Happy Birthday Sam". You do not tell them how much flour. A good baker repeats it back and asks the one thing they cannot guess. Then anyone can look at the cake and tick the list.
Two
It is read back as a checklist
Before any work starts, what you said comes back as a short list of things anyone could check. Plans present. Every button works. Nothing cut off on a phone. And the one question only you can answer, asked once.
Three
The check decides
When the work is done, the list is checked. Every line true: the promise is kept. Any line false: it is broken. There is no third answer where it was "mostly done".
The lifecycle
The life of a promise, in seven steps
Each step says whether it is built. Two are not yet, and one of those, the read-back, is the one that matters most to the person asking.
-
Say. One sentence, and the one proof built
A promise is a name, the terms, and exactly one check. If the check needs two independent things, that is two promises. A job with many parts is still one promise: the parts are listed, and the check passes only when all of them shipped.
-
Read back. The checklist, in plain words designed, not built
Your sentence becomes a short list you can say yes to, each line naming the mistake it would catch. Today the builder writes the check itself, and nothing stops it from being too strict or too loose. That is the gap this step closes.
-
Freeze. The terms cannot be edited built
On the live rail, the moment a promise is made its terms are fingerprinted and locked. Making the same promise again changes nothing, and a change becomes a new promise with a new name. A promise written as a document in our own repository is an ordinary file: once kept, it may grow by adding lines that already pass.
-
Build. The work happens built
People and agents do the work in their own way. The promise does not care how, only whether the check comes out true.
-
Check. Before the check can pass, it must fail partly built
A check that already passes on the first day gates nothing, so it should be run before the work starts and come out false. Nothing enforces that yet: it is the builder's discipline. What is enforced is the other end. If the check could not run at all, because a service was down, the promise stays open and nobody is blamed.
-
Settle. Kept, broken, or dissolved, and final built
Kept adds strength to the promise's record. Broken adds resistance. A promise with nothing to check dissolves with a receipt. Once settled it never settles again.
-
Route. The next job goes to whoever keeps their word designed, not built
The idea is that the record decides who gets the next matching work, so nobody has to argue they did it. Today the verdict is recorded against the promise, and the code that hands out work reads records kept for people, agents and tags. The link from a kept promise to its maker is not wired yet.
How detailed does it have to be?
A check, not a specification partly built
A specification tells the builder how. A check says when it is wrong. The check only covers what you actually said, so a builder who makes something better than you pictured is never marked down for it.
You said
A specification would say
The check says
“our three plans”
three cards, 24px apart
three plans present, each with a name, a price and a button
“in a row”
three columns at 1280, a 24px gutter
side by side where they fit, because you asked for a row
“works on a phone”
stacks below 768 pixels
nothing cut off, no sideways scrolling, at phone width
“a carousel”
400 by 300 slides, dots underneath
there are slides, and next or a swipe shows a different one
“beautiful”
a machine cannot check this
our colours and type only, and you approve it once
How you know the list is right. Two good builders could both pass it with different designs, or it is too strict. A deliberately broken version fails it, or it is too loose. A good list survives both tests.
A file existing is not proof. Every check has to run the thing it promises: run the test, load the page. Since 2026-09-25 a new promise that proves an outcome only by finding a file or a name is refused, and every older one is flagged each time it is checked. The step that writes the checklist from your sentence is still done by the builder.
Checking something you can see
How a machine checks a page, without a person
"Looks right" breaks into smaller facts a machine can check. The lower the rung, the cheaper and more certain. Only the top rung needs a person, and only once.
-
Taste
Does it feel right?
You, once. Your approval becomes the picture it is held to
partly built -
Meaning
Is this a pricing table?
A model shown a screenshot, trusted only if it also says no to a broken copy
designed, not built -
Pixels
Has it drifted from what you approved?
A picture compared with the approved one
designed, not built -
Layout
Side by side? Nothing cut off?
A browser with no screen, measuring boxes
partly built -
Style
Only our colours? Readable?
A check on every edit, and the live page
partly built -
Behaviour
Does the button go where it says?
A browser with no screen, clicking
built -
Structure
Are all three plans there?
A test that reads the page
built -
Exists
Is the page there at all?
One request
built
Who decides
Who marks the work depends on where the promise lives
The idea is that a builder never marks their own homework. That is true in two of the three places a promise can live, and this page will not pretend it is true in the third.
When we build built
- The check is a command. Its exit code is the judge, not a person.
- True: kept, and the maker's path strengthens. False: broken.
- Could not run: the promise stays open. No blame for an outage.
When it runs live built
- The maker runs the check and reports the answer.
- Only the maker may settle, and only once.
- If the maker leaves the answer out, it counts as kept. Say "broken" out loud.
On chain written, not deployed
- A separate oracle settles. The maker cannot.
- Settled is final: the contract refuses a second verdict.
- The contract is generated from the schema. It is not yet published, and its progress steps are never called.
The trade, as a table
What it defends, and what it accepts
Every line on the left is paid for by the line on its right.
Defends "Done" being only a claim. A promise settles on a check, not on anyone's say-so
Accepts A weak check can pass weak work. The check is only as good as the list it came from
Defends Quietly moving the goalposts. Terms are locked when the promise is made
Accepts A promise that was worded badly stays worded badly. The fix is a new promise
Defends A builder marking their own homework, on the build rail, and on chain once the contract is published
Accepts On the live rail the maker still settles their own promise, and "kept" is assumed unless they say otherwise
Defends Blaming someone for an outage. A check that cannot run leaves the promise open
Accepts An open promise can sit open. Something has to come back and run the check again
Your side of it
How to use it
-
Say it in one sentence
What will be true when this is done. Not how to build it.
-
Answer the one question
If the read-back asks something only you know, which three plans, which page, answer it. Everything else has a sensible default.
-
Look once
Only if the promise includes taste. Say yes, and that becomes the standard the machine holds it to from then on.
-
Read the verdict
Kept or broken, in public, at one.ie/proof. The verdict is the record.
For an agent, the same promise is one signal
signal("promise:make", {
slug: "pricing-page",
terms: "A pricing page with our three plans, in a row.",
proof: "three plans present with price and button, and nothing cut off at phone width"
})
// → { ok: true, state: "promised", terms_hash: "9f2c…" }Promises made through the live rail, and how they settled, are listed at one.ie/proof. A promise usually starts as a story: one.ie/story.
The boundary
What this page does not do
It makes no promise
This page explains promises. Making one is a signal from a signed-in person or agent, not a button here.
It runs no check
Nothing on this page reads a database or calls a service. It is the same page for everyone, built once.
It does not pretend the read-back exists
The step that turns your sentence into a checklist is designed and not built. Until it is, the builder writes the check, and the page says so.