In this note
You have an engineer who can build the prototype. You still need someone who knows why the process works that way, someone who can check the source, and someone who can reject a wrong result. Their names may be missing from the project plan.
I’d staff those contributions before committing a pilot date. A business analyst may trace the work, an architect may resolve an integration boundary, and a data engineer may check whether the extract is complete. One person can cover several jobs. They need the skill, time, access, and decision rights to do them.
Consider two hypothetical finance jobs: drafting commentary without changing any records, then adding the ability to save an approved correction in the finance system. The example assignments and hours below show how to plan coverage. They aren't a recommended headcount or evidence of a delivered project.
Start with the read-only draft
The first job calculates differences between approved actuals and plan in code. It collects explanations from the people responsible, then lets a model draft the commentary. Finance checks the figures and explanations before accepting it for internal use. The service can't change a balance or invent a reason for overspending.
Finance owner Mira decides which accounts and period to cover, what a usable draft looks like, and what to do with missing explanations. Engineer Lin builds it. Source specialist Tess checks the data and access. Reviewer Jo checks the output independently against the approved figures and explanations. The draft also needs a service owner to arrange support and deal with a missing source next month. Changing a prompt doesn't give the engineer permission to expand the job.
A read-only draft can still leak information. The extract might include accounts the requester cannot see, or the explanation might reveal a sensitive reason in the text or logs. Have a security reviewer check the selected fields, model destination, retention, and handling of the output before using real sources.
Check contributions rather than collecting titles
| Contribution | Work and inspectable result |
|---|---|
| Workflow analysis and domain judgment | Sit with finance through an ordinary report and one exception; establish which explanations the reviewer needs and who can accept the draft |
| Product and experience | Ask an operator to check a draft, correct an amount, reject it, and find the person who handles missing evidence |
| Architecture and integration | Show where figures come from, how the service checks the reader's access, where drafts are saved, and what happens when a source fails |
| Data engineering or source expertise | Check that the extract covers the permitted accounts and period, uses the approved calculation and source revision, and reconciles to finance's report |
| Software and AI engineering | Build the calculation and drafting path; test it, record failures, and provide a way to stop or replace a bad version |
| Evaluation and independent checking | Prepare cases with finance, have a separate qualified person check the expected answers against their sources, and verify that wrong drafts fail |
| Security, privacy, and risk | Check which records may be used, what the model receives, how long copies remain, and which actions or approvals are outside the draft's scope |
| Adoption and operation | Try a review and a support failure with the receiving team; reserve support time and decide who handles changes, recovery, and eventual shutdown |
You don't need eight full-time hires. The engineer might also design the integration, while the finance owner and an operator work out the review screen. The source specialist may join only for the data work, and an existing platform may provide login and monitoring. Add specialist skills when the design needs them. A commentary draft doesn't automatically need a data scientist.
Reserve time and name the backup
For this example, reserve eight engineering hours a week for Lin and two source-review hours for Tess. Reviewer Jo has a protected two-hour weekly session, with Lee as the approved independent backup. Security reviewer Rae has 90 minutes before the pilot and a separate release-review slot. Confirm these estimates against the actual cases before committing the date.
At eight minutes a case, ten reviews use 80 of the reviewer's 120 minutes. That leaves 40 for corrections and discussion. Twenty cases need 160 minutes before corrections. Limit the first group to ten cases, add qualified cover, or delay intake. A working prototype doesn't make the review work disappear.
The backup needs the skill, access, and permission to decide. If the review requires independence, the person who built the work can't be its independent backup. When neither reviewer is available, hold acceptance and keep the manual process available.
Give source and security questions deadlines too. If the source review isn't finished, the engineer can work with teaching records but can't say the real data is ready. Don't send real records to the model while waiting for the security review.
A controlled write changes the coverage needed
Now the request changes: save a specific correction in the finance application after approval. Bring in the finance-system owner. They must agree what can change, who can request it, how approval is checked, how to detect an outdated record, and how to confirm the save. The team's permission to prepare drafts doesn't cover these actions.
Plan the write with the system and integration owner before coding it. The engineer needs to handle duplicate requests and timeouts. The source specialist helps check record versions and what was saved; security checks the allowed action. Test denied requests, expired approvals, duplicates, outdated records, and unconfirmed saves as well as success.
The service owner now needs someone who can recover an uncertain write, as well as support the draft. A request might time out after the correction was saved. Check what happened before trying again. If the team can't exercise that recovery, or the application can't support a safe write, keep the service at a reviewed draft or staging step. The launch date can't fill that gap.
Keep acceptance, approval, and operation distinct
Separate the decisions even if they happen in one meeting. Finance decides what the workflow is for. An independent reviewer checks a prepared result. The finance-system owner allows the specific write. The release owner approves the tested software, and the security reviewer handles the applicable risk decision. Approval of a draft doesn't approve the software or a change to a financial record.
The service owner is responsible for support, reliability, changes, incidents, and eventual retirement. The person providing day-to-day support covers the tasks that owner has delegated during agreed hours. Answering an alert doesn't let support change finance policy or approve a release. One person can hold both service and support roles if the duties and time are explicit; the worksheet shows one possible assignment.
Exercise the cover before calling the team ready
Try a missing source, a rejected result, and a support alert with the people assigned to handle them. Ask the backup to find the current evidence and explain what they can decide. Time a burst of reviews and rehearse stopping intake while supporting existing cases. If the original engineer handles everything, the receiving team isn't ready yet.
Before promising the pilot, add a person, a qualified backup, and confirmed time to each required contribution. Mark decisions that need an independent reviewer. For each uncovered job, agree whether to reduce scope, find cover, or postpone it.