How we work
Someone says it is done. What can you actually check?
A pull request says tested. A standup says done. Follow one change through the six moments every change travels here, see what you can open at each, and watch “done” stop being a claim.
The claim
Done is a word. Here is what it usually hides.
What was agreed
A ticket title and the memory of a conversation.
What was tested
A sentence in the pull request.
What is still open
Nobody knows until production asks.
Six moments turn each of those into something you can open. Here they are, in the order every change travels them.
01
Requested
The request is written down first, in your words, and fetched from your tracker, so the work is grounded in what was asked rather than what someone remembered.
What you see
Your request, unchanged, at the top of the record. Every later step points back to it.
02
Agreed
Before any code, the request becomes an agreement: what the change must do, acceptance criteria that each say how they will be proven, and what is out of scope. A person signs it. From then on it is frozen; if the goal changes, the work stops and asks.
What you see
The agreement in your language, who signed it and when.
03
Built
The rules your team agreed, the ones that apply to the files in play, are loaded and recorded before the first edit. Every save passes the same checkpoints, and existing code is reused before anything new is written.
What you see
Not the code, but the fact that it was written under your rules, and that nothing was saved past an open question.
04
Reviewed
Someone who did not write the change reads a digest of everything already proven, then answers it: findings with reasons, a rollback plan, a verdict labelled as a judgement.
What you see
That a review happened, what it found, and how to undo the change if needed.
05
Checked
Your own format, build and test commands run. Their exit codes decide. A separate program then reads the whole record and grades it; what could not be measured is named as such.
What you see
What ran, what passed and, just as clearly, what could not be checked. Nothing is rounded up.
06
Live
After a person approves, the change goes live with its record: a tamper-evident receipt, an inventory of who wrote and who accepted, and every commit linked to the request.
What you see
The delivery and its record on one page. Not a message that says done. A record that shows it.
Six moments, and at three of them the decision is yours.
Your part
Three moments are yours. The rest is checked, recorded and named for you.
Before a Programme team practises this on its backlog, we review its business context and documentation with the team and agree the rules and exceptions the six moments will use.
You write the request
In your words, in your tracker. Nothing is rephrased on the way in.
You sign off what done means
The acceptance criteria are frozen when you say so, and cannot drift without you.
You approve going live
With the record in front of you. You are interrupted when the decision is yours, and never asked to trust the rest.
Here is one change that travelled all six, as the framework recorded it.
One real record
Read one change in full, as the framework recorded it
A change to Paqad, the open-source framework we build with. Six moments, twelve checks passed, three named as not measured. Nothing on the page was written for the page.
Two ways in
Bring this to your team, or let ours deliver inside it.
Your team, our process
The AI Delivery Programme
Five weeks alongside your engineers, in your codebase, until the six moments are enforced rather than hoped for.
Our engineers, same process
Build with us
Extra hands inside your process, or a build you can check before you accept it.
The same six moments for your team and for ours. Counted on one real change.
Key facts
The six moments, counted on one real change
6
moments recorded for one change, six of six, from request to live
Change #557, 12 September 2026
3
commands ran with their exit codes deciding: format, build and test, all three passed
Change #557, 12 September 2026
4
acceptance criteria frozen before any code: three proven by test, one checked by a person
Change #557, 12 September 2026
15
gates graded by an independent program: twelve passed, none failed, three not measured
Change #557, 12 September 2026
Now the process, plainly.
How we work, in short
Every change Eliyce delivers, and every change a Programme team delivers, travels six moments: requested, agreed, built, reviewed, checked and live. At each moment Paqad, the open-source framework we build with, writes a record a person can open. Your team’s rules load before the AI edits, your own build and test commands decide, and what could not be measured is named as not measured rather than rounded up.
Our services
Three ways we make AI work you can check.
Questions
What people ask about the process
Requested, agreed, built, reviewed, checked and live. Every change travels them in that order, whoever or whatever wrote the code, and each moment leaves its own entry in the record.
Your own format, build and test commands, by their exit codes, and then an independent program that reads the whole record and grades it. The AI’s chat is not evidence for that grade: the verifier reads the transcript only to confirm the stages were narrated where the developer could see them. A person approves before anything goes live.
It is recorded as not measured, with the reason, and a change with an unmeasured gate is not sealed Safe to merge. On Paqad’s own change #557 that produced an Inconclusive verdict for exactly that reason.
Yes. Eliyce builds software inside the same six moments it installs in Programme teams, and the record you can read on this site comes from a change to our own framework, Paqad change #557.
Last reviewed 8 October 2026 by Eliyce.
Stop accepting “done” on trust.
Twenty minutes about how a change reaches production in your team today. You leave with an honest view of whether this fits, whether or not you work with us.
We reply within one working day. Or write to hello@eliyce.com.