The AI Delivery Programme
Turn your team’s working agreements into an AI delivery process.
Five weeks alongside your engineers, on one application. We bring together your business knowledge, documentation and engineering conventions, turn the rules that can be tested into automated checks, and help your team deliver real backlog work with records it can review. For CTOs and engineering leaders with teams of roughly 15 to 40 engineers, already shipping with AI coding tools, who want one shared way to document, check and deliver their work.
Want to see the process first? How it works
Fit conversations now. No dates or fees are published.
Your week
Same team, same AI. A different week.
Today
- The review queue grows faster than it shrinks.
- Each developer prompts the AI their own way, so the result depends on who typed.
- “Tested” is a claim in a pull request.
- You find out what was skipped in production.
After the Programme
- Rules your team agreed load before the AI touches a file.
- Nobody improvises in a prompt; everyone follows one workflow.
- Every change carries its own record.
- Review reads what the machine already proved.
- You are asked only when the decision is yours.
The difference is not a tool and not a course. It is what happens between the request and the merge, and whether anything enforces it.
The part the model cannot skip
Rules your team agreed load before the AI edits. The checks your team configured run, and the record shows what they found.
Nothing goes live on the AI’s say-so. The rules are the ones your engineers agreed between themselves, loaded on record before the first edit. We configure and practise the agreed workflow with your team; the record shows which checks ran and their results. Your developers stop improvising and follow one clear workflow; they still decide what to build and whether it is good enough. The process makes sure the checks in between happen, and the record shows that they did. Which checks can block an edit depends on the coding tool: see the question on tools below.
That is what enforced means. Here is how it gets into your team, week by week.
Five weeks
Learn it by delivering your real backlog.
We start with the people who know your software and the documents that explain it, and we end with your leads running the process. At the end of every week your team holds something, not a slide. Participation, access and scope are agreed before we start.
Week 1
Align
Understand the business and agree how to work.
At the end of the week you have
- A reviewed picture of your business context: your existing documentation, user manuals and process notes, including what turned out to be outdated, read with the people who know why the software works as it does.
- Agreed access to the repositories, servers, environments and delivery tools the scoped work needs.
- Your application onboarded to Paqad. Initial project and module documentation is generated from your code for your engineers to review. Starter rules come from the framework and matched stack packs.
- Your team’s conventions and exceptions written down, after we have listened to how your engineers actually work.
- The baseline (how you deliver today), the measures for week five, and the backlog work we will deliver together.
Week 2
Prepare
Turn agreed rules into checks.
At the end of the week you have
- Reviewed documentation and the agreed conventions in your repositories, with outdated assumptions resolved.
- The rules a script can test turned into deterministic checks, each validated against passing and failing examples you agreed before it is switched on.
- The limits written down: what each check establishes, and which rules still need a person’s judgment.
- Example: if your team agrees a file-length limit, a script counts the lines in the changed files and reports a breach. The result comes from the files themselves, not from asking the AI whether it followed the rule.
Weeks 3 and 4
Practise
Deliver real work together.
At the end of the week you have
- Items from your real backlog delivered inside the workflow, with us alongside to answer questions and review friction with your leads.
- A record for each of them: what was checked, the results, the gaps that remain, reviewed with your leads in Spine.
- Documentation kept aligned with the changes you deliver, and rules adjusted where the work showed they needed to change.
Week 5
Hand over
Compare and hand over.
At the end of the week you have
- The comparison with the baseline, in writing: what improved, what did not, and what the evidence cannot establish.
- Operating guidance for your leads: running Paqad, changing rules and checks, maintaining the documentation and creating further documents from your project’s existing context.
- The next ninety days agreed, with your leads running the process and the remaining issues named.
At the end of week five your leads run it. Here is what stays behind when we leave.
What your team keeps
It stays in your repositories, not in ours.
A shared starting point
Reviewed business and technical documentation, connecting what the software does with the business context behind it, and the conventions your engineers agreed.
A repeatable process
Practised on real backlog items, not on examples.
A record you can review
Checks, findings and explicit gaps, for every change.
Your own hands on it
Rules and documentation live with your code; your team controls its delivery records. Your leads know how to change the rules, keep the documentation current and create further documents.
Your rules and documentation stay in your repositories, and your team controls its records. Spine, the shared team view, runs in your environment and is described below. Whether it fits your team is a fair question, so here is the honest answer.
Who it is for
Built for one kind of team. Honest about the rest.
This is for you if
- You lead an engineering team that already ships with AI coding tools.
- You cannot say, every time, what was tested before a change went live.
- Your review queue grows faster than it shrinks.
- You have a real backlog to practise on, and leads who will sit in the sessions.
- You have people who know why the software works as it does, and time to review generated documentation with us.
- You want rules and documentation in your repositories, with delivery records under your control.
This is not for you if
- You want a tool installed and left alone.
- You want a prompting course without your own codebase.
- You want a vendor to take the engineering decisions for you.
- You need software built rather than a process for your own team. That is Build with us.
- You need a result next week. The programme takes five, on your real backlog.
If the first list reads like your week, the next screen is your Monday in week six.
What your leads see on Monday
Illustrative example
Every change, with its record, in one view
Your engineering leads see what went live, what was checked and what still needs a decision. Product owners see their request travel to live.
Same team, same AI, a different week. One honest note before you ask for it.
Where it stands
How it starts
Every programme starts with a fit conversation. We hold a small number of them, and no dates or fees are published.
Open foundations
You can start without us. The Paqad framework is free and public, MIT licensed and published on npm. The programme adds guided adoption, team alignment and engineering support.
Key facts
What enforced looks like, from one real change
27
rules loaded and recorded for the files one change touched, with the rule text fingerprinted
Change #557, 12 September 2026
12
gates passed on that change, none failed, three named as not measured
Change #557, 12 September 2026
6
times the verifier refused to close the change until the review was on record
Change #557, 12 September 2026
1
decision asked of a person, the merge, and zero questions on the way there
Change #557, 12 September 2026
Counted by the framework, not by us. Now the programme, plainly.
The Programme in short
The AI Delivery Programme is a five-week engagement on one application. Eliyce works alongside a team’s engineers to document the business context, agree the working rules, turn the testable rules into automated checks and deliver backlog items through Paqad, with the records collected in Spine. The team keeps the documentation, rules, checks and guidance to maintain them; every change carries a record of what was checked and what remains uncertain.
Our services
Two more ways we make AI work you can check.
Questions
What CTOs ask before a programme conversation
A five-week engagement on one application. Eliyce works alongside your engineers to understand your business context, write down the rules your team agrees, turn the testable ones into automated checks, and deliver your real backlog through the process. Your team keeps the documentation, the rules, the checks and the records; we leave.
It is for CTOs and engineering leaders whose teams of roughly 15 to 40 engineers already ship with AI coding tools and cannot say, every time, what was tested. It is not for teams that want a tool installed and left alone, or a course without their own backlog.
We work on your application with your engineers: reviewing documentation, agreeing conventions, implementing suitable checks and practising delivery on your backlog. Rules your team agreed load before the AI edits, the checks your team configured run and are recorded, and each change leaves a record.
Usually not. We check your stack and coding tools during the fit conversation. Full enforcement runs on Claude Code and Codex CLI, where the checkpoints can block an edit. Gemini CLI records the evidence at the end of a turn without blocking. Other supported coding tools use an advisory instruction contract without executed host hooks: the record depends on the agent following the workflow, and no host hook blocks an edit. Current as of paqad-ai 1.90.0. Your own build and test commands stay the ones that decide.
Fees and dates are not published. We hold a small number of fit conversations first. You leave that conversation with an honest view of whether it fits, whether or not you work with us.
Existing documentation, user manuals, business-process notes and a real backlog. Outdated material is useful context when your team can say what still applies. We agree the repository and environment access the scoped work needs before delivery starts.
We combine your codebase with the material and explanations your team provides. Paqad generates initial project and module documentation from the code; we review it with your team, resolve contradictions and outdated assumptions, and write down the business context behind it.
Yes. The documentation and the workflows that generate it stay with your team, using the free framework. Your leads receive guidance for maintaining it and generating further documents from your project’s context. Generated documents still need review by people who understand the software and the business.
No. We automate the rules a script can test reliably, validate each check against passing and failing examples, and write down which rules still need a person’s judgment. A check establishes its defined condition; it does not establish that the whole application is correct.
The framework is free and you can start without us. The Programme adds the work alongside your team: understanding the business, reviewing the documentation, agreeing conventions and exceptions, implementing the checks, and practising delivery on your own backlog until your leads run it.
Last reviewed 13 October 2026 by Eliyce.
Make “tested” a fact your team can show. Every time.
A 20-minute conversation about your team, your codebase and your AI tools. You leave with an honest view of whether the programme fits, whether or not you work with us.
We reply within one working day. Or write to hello@eliyce.com.