Deliver the system

The calendar is set by things you do not control: model access in the region their data must stay in, data access, the security review, change approvals. Each sits in someone else's queue, so file them all on day one, with names and dates, and count each one done only when its test passes. The same week, take the baseline from their records: every later claim divides by it, and it cannot be taken once the pilot starts. The MVP begins here, with one question: does the slice the proof chose still hold on real access?

1. File every lead-time request on day one, each with a name and a dateModel access in their region, the security review, data access and the privacy review of the fields you will read, network routes, a change slot for cut-over, the experts' hours. Each gets an owner on their side and a date after which the plan moves. Chase by name, and escalate on the date, not on a feeling.
2. Count access as granted when one call passes, not when someone says yesOne real call per item, as the production identity, through their network, in the right region, run every morning until it passes. Identity, region and network cause most first-week surprises, and the walking skeleton of step 7 is built on whatever passes first.
3. Take the baseline this week, from their recordsCases a day, minutes to a decision, cost per case and cases reopened, from at least four normal weeks before the engagement, counted by a method their ops lead signs. Once the pilot starts the mix changes and people work differently, and the before is gone. OpenAI asks its Deployment Leads to run pre-/post-deployment measurement and report to exec sponsors1: this is the pre.
4. Re-check the proof on real accessThe proof ran on an export. Production brings a slower interface, a rate cap, a field that turns out to be free text. In the words of OpenAI's head of FDE, what the customer describes in scoping doesn't match the data/system reality on the ground2. If real access changes the first slice's economics, re-cut it now, in writing, with the sponsor.
5. Keep one log of risks, assumptions, issues and dependencies with their project managerOne list, read in fifteen minutes a week with whoever can unblock. Two logs, yours and theirs, disagree within a week, always about a date. Tell the sponsor bad news the day you know it: trust is lost to surprise, not to bad news.
6. Agree how you will work with their team, on one pageWhere the code lives and who merges, who pairs with whom, a daily stand-up and a weekly note to the sponsor, how to reach the risk owner, and which data may go into which AI tool, in their policy's words. Pin it in their repository before the first commit, and open your pattern log beside it: one line each time you build something you have built before, for step 10.

Inside your own company access feels like a favour away, so nobody files the requests. File them anyway, with owners and dates: an internal security review can take as long as an external one, and a favour lapses the week its giver is busy. Take the baseline as carefully as for a paying client, because the unit's head will be asked by their own finance team what it saved.

• Day one, to their project managerToday I need three names and three dates: data access, model access in your region, and the security review.
• A request is late, to the person who can approve itData access was due on Tuesday. Every day it waits moves the shadow run by a day. Can you approve it by Friday, or tell me who can?
• The sponsor wants to skip the baselineIf we do not measure the before this week, nobody will ever be able to say what this saved. It takes two days, and it cannot be done once the pilot starts.

Produces

Day-one access list and baseline

Good looks like

One page, read every morning: each lead-time item with an owner, a late-from date and a test that runs, what real access changed about the first slice, and a baseline from records before anything changed, its method signed by their ops lead.

Owner

Forward-deployed engineer, with their project manager

• Counting a yes in an email as access. The first real call, weeks later, finds the identity, the region or the network, and the plan pays for it in days.
• Building in your own sandbox while the requests wait. The code grows around your account's defaults, and moving it into theirs becomes a project of its own.
• Taking the baseline after the pilot starts. The mix has changed and people work differently when watched, so every value claim rests on a guess.

Three documents decide everything after this: the spec, a pass mark for each kind of case, and the authority budget, which says what the system may do alone and the limit on each action. You draft all three, because you can see the system. They sign them, because the risk is theirs. A limit you set because their risk team was slow becomes your limit on the day it is wrong. And a signature is half the step: each limit then lives in the tool that would break it, with a test, or it is a sentence a model can be talked past.

1. Run the requirements as a mob, with their experts in the roomAI-DLC's Mob Elaboration: a model proposes requirements and asks its questions aloud, and their experts answer. Record every answer with its author's name. The names make the decisions theirs, and a credited read-back the next day stops the same question coming back.
2. Write the spec with the five fields a requirements document leaves outWhat the model decides and what code decides; what it may do alone; how right it must be, per kind of case; what happens when it cannot decide; what is logged. If the spec leaves one open, a coding agent fills it by default.
3. Draft the authority budget, one row per actionThe action, its level, its cap, the approver above the cap, and where the cap is enforced. Band each by what one wrong call could damage, never by the size of the change. The architect's step 6 has the method in full.
4. Get each line signed by the person who owns that riskLimits by their risk owner, often compliance or finance; pass marks by their expert lead; the spec by their product owner. A sponsor's signature on a limit they do not own is one that nobody defends in the incident review.
5. Set each pass mark from their costs, so the arithmetic is theirs tooIf a wrong answer costs four times what a right one saves, it must be right four times in five. Use their figures, the complaint and the investigation included, and the bar stops being your opinion. A person approving each refund lowers what a wrong one costs, and moves that bar further than any model can.
6. Put every cap in the tool that would break it, with a testThe refund cap is a typed parameter that raises above it, and the approval is a token the model cannot mint. Two tests, over the cap and without approval, both raise. The sentence in the prompt stays, marked as policy.
7. Build nothing past an unsigned decisionThat is the hard gate. Every other open question runs beside the build behind a placeholder with an owner and a date. If the programme cannot wait, the unsigned action runs in shadow, deciding and acting on nothing, until it is signed.

Inside your own company a nod from a colleague in a corridor feels like enough. Get it written, and signed by whoever owns the risk in the business unit, not by your own manager: when the incident comes, the signature is what keeps it a decision rather than a blame. Your platform's default limits are not their limits either, until someone in the unit has signed them.

• Asked to pick a sensible number for nowI can draft the number, but I cannot own it. If I set the refund limit myself, the first incident review will find that nobody on your side decided it. Who signs refunds today?
• Their compliance team needs three more weeksEverything else can go live on its own evidence. Refunds run in shadow, deciding and paying nothing, until your compliance officer signs the limit. Then it is one line of configuration.
• The risk owner asks how the limit is keptIt is in the refund tool itself, not in the model's instructions. Above the limit the tool refuses unless your approver has confirmed, and a test proves that on every change.

Produces

Signed spec and authority budget

Good looks like

Every action with its level, its cap, its approver and the test that enforces it; every pass mark with the costs that set it; each line signed by the person who owns that risk; and no line that is only written.

Owner

Forward-deployed engineer drafts; their risk owner and expert lead sign

• Choosing a limit yourself because their risk team is slow. It unblocks you this week, and makes the loss yours on the day the limit is wrong.
• A signature from someone who does not own the risk. The sponsor signs happily, and in the incident review the risk owner says nobody asked.
• A cap that lives in the prompt and the design. It reads as a control in every review and stops nothing.
• Treating every open question as hard. The build waits behind eleven meetings when three decisions needed signatures and the other eight needed only a placeholder, an owner and a date.

Build where they will maintain it, with their engineers, and prove it on their cases, not yours. The first slice is the MVP: the thinnest version one group of their users can rely on, held to a signed pass mark. Then every slice in scope meets its own bar, held by a harness in their pipeline that the merge cannot pass, so the proof outlives your stay. Last, it runs beside their staff, deciding and acting on nothing, because the rules that matter most are often written nowhere.

1. Put one context file in their repository, AGENTS.mdTheir stack, the commands that build and test it, what never to touch, and each rule learnt the hard way. Codex reads it, and so does Claude Code when the repository has no CLAUDE.md3: one set of rules for your agents and theirs, and it stays when you go.
2. Build a walking skeleton through their real system firstTheir identity, their data path, one record on a screen, no model. It proves the plumbing on the first day of the build, while a credentials or network problem costs hours.
3. Write the floor, then the model calls, then a checker after the risky onesFares, eligibility and refunds are code with unit tests. The model ranks and drafts on top, and an independent checker follows only the steps where a wrong answer is costly and easy to miss: the engineering lead's steps 3 to 5.
4. Wrap their systems as tools, each with its own least-privilege identityReads open, writes gated, one identity per tool, so a model that has been talked past still reaches only what the job needs. A tool that returns an empty result on error reads to the model as nothing applies: make every tool fail loudly.
5. Build the golden set from their past cases, labelled by their expertsRedacted, from their history, tagged by the slices they care about. First measure how often two of their experts agree: that is the ceiling on any pass mark, and if it sits below the signed bar, go back to step 6 before building. Report every slice with its sample size and lower bound, never one average.
6. Make the harness a check their merge cannot passIn their pipeline, cheapest checks first, failing any slice below its bar however good the average. A comment on a pull request is read in a quiet week and clicked past in a release week, the week it exists for.
7. Run the shadow beside their staff, and read the disagreements with themThe system decides a copy of every live case, off the live path, and acts on none; a model version change restarts the window. Each afternoon, go through the disagreements with the people who made the real decisions: a cluster is usually one rule nobody wrote down.
8. Pair with their engineers on every changeTheir engineer drives as often as you do, and reviews what your coding agent wrote. AWS describes the customer's engineers moving from observers to co-builders to autonomous operators4: these are the co-builder weeks, and by the shadow run they ship a change without you.

Inside your own company you will be tempted to build in your platform's repository, on your pipeline, for now. Build where the business unit will maintain it, under their checks, from the first commit: a move later is a migration nobody budgets for. Hold their bar, not your platform's default, and let their experts label the cases even when your team knows the data better.

• Fourteen shadow disagreements, all on one shiftThese fourteen disagreements are one rule. Who on the evening shift can tell us why?
• The score clears the bar, and the room wants to launchThe score is above the bar and its lower bound is not, so it is probably good enough and not yet proven. We run beside your desk from today, and the evidence decides the launch.
• A senior expert who distrusts itYou know what a right answer looks like better than anyone here. Will you label the cases we test it against, and show us where it is wrong?

Produces

Evidence pack, and the harness in their pipeline

Good looks like

One index page: every artefact with its owner on their side and its date, every slice with its lower bound against its signed pass mark, the shadow's disagreements read and turned into rules, and every control marked enforced or only written.

Owner

Forward-deployed engineer, with their engineering lead

• A golden set you wrote yourself. It holds the cases you can imagine and scores well: at SkyWays twelve invented cases scored 94%, and none of them was codeshare.
• A harness that comments instead of blocking. At SkyWays a red slice was merged past the comment on the Thursday before the pilot.
• Polishing a slice nobody uses. Build means every slice in scope at its bar, not a favourite slice at 99%.

Deploy is thinking at the size of their organisation: owners, operations and the contract, not the code. Widen one action at a time on evidence, never on a date, with money actions gated throughout. Meanwhile make yourself unnecessary: every switch timed, every runbook rehearsed by the person who will use it, every loop owned on their side. The handover is real when that person has signed, your access has ended, and nothing breaks.

1. Widen one action at a time, on evidence, never on a dateShadow, then 5%, then wider, then all, per action, each step naming the evidence that earned it and the risk owner who agreed. Widening raises the share, never the level: a money action keeps its named approver at every share. Each step's length is arithmetic: cases needed ÷ (share × cases a day).
2. Time every switch with a stopwatch before cut-overSomeone on their side, not the author, throws each one while you watch: the kill switch, a flag back to shadow, a prompt rollback, a model rollback. The times go into the runbook with the date. A rollback nobody has timed is a belief.
3. Write runbooks for the five things that will happenA drift alert, a cost spike, a tool outage, a model change, a disputed refund. Each says how to tell, what to switch, whom to call and how to know it is over, and the person who will use it runs it once, end to end.
4. Name an owner on their side for every loopThe operator, the on-call rota, the cost owner, the drift owner, and whoever turns incidents into the next brief. Cost, incidents and drift feed back into design, so nobody downstream chases them unless a named person owns each.
5. Have the handover signed by the person who will run itTheir operator, the person who will be paged, signs that they can run it; their sponsor signs, separately, that it was delivered as the statement of work says. AWS lists what a customer should hold at the end: deployed systems, knowledge graphs, runbooks, architectural documentation, and trained internal champions ready to operate independently4. The checklist is that list, with a name beside every line.
6. End your access on the agreed dateWrite the date into the checklist and keep it. The support period comes from the statement of work, not from goodwill on the day: a fortnight on call to their operator, not to the system, so every question goes through the person who now owns it.

Inside your own company the risk is the opposite: you never leave, because you are a message away and the unit never learns to run it. Put the end date in the charter and keep it. If the unit cannot staff an operator, that is a finding for its head, not a reason to become their team for good without anyone deciding it.

• The sponsor wants to widen on a dateWe widen when the evidence says so. At 5% of 240 cases a day, the 500 cases we need take 42 days. At 20% they take eleven, and one passenger in five meets a system not yet proven. Your risk owner chooses.
• Handing over, to their operatorFrom Friday this is yours to run. For two weeks I am on call to you, not to the system: you call me, and you decide.
• Asked to stay on after the handoverI can stay, but then it is not handed over. Who on your side will run it? If nobody can yet, that is the first decision to take, and it is yours.

Produces

Handover pack

Good looks like

Signed by the person who will run it, after they have thrown every switch and followed every runbook without you: an owner for every loop, the switches with their times, where each action stands and why, the open risks with owners, and the date your access ends.

Owner

Forward-deployed engineer, until the person who will run it signs

• Widening on a date. The calendar says week six, the evidence says not yet, and the share that widens is the one nobody can defend after the first incident.
• Handing over to the sponsor instead of the operator. The sponsor signs and is never paged; the person who is paged meets the system at its first alert.
• Runbooks nobody has run. They read well and fail at the first step their author knew by heart.