The following scene is an illustration, not a customer case, and its timing is not a measurement. A sales director asks an AI assistant to draft a renewal proposal for an enterprise customer. The draft arrives in seconds. It reads well and makes three commitments: keep the 15% discount, carry over last year’s support credit, and offer 60-day payment terms.
Before it goes out, the deal desk lead has to approve it. She opens the contract repository to find where the 15% came from and finds it in an amendment signed two years ago. The amendment keeps the discount valid only through this quarter, under a three-year commitment, so applying it to the renewal needs her separate approval. She searches email for the support credit and finds the approval: it was granted once, for an outage. Then she checks the finance policy, which allows 60-day terms only above a set contract value. When she can approve the proposal, with the credit removed and the discount approved as a new renewal term, it is late afternoon.
AI writing a draft fast is not the same as a person approving it fast. Finding the wrong credit took one search. Checking whether the other two terms could apply took the rest of the afternoon, because the draft did not say where each claim came from, which conditions limit it, or which exceptions apply. To see whether AI saves time, measure the work from request to approval, not the draft alone.
Key takeaways
- A fast AI draft can still take a long review when the reviewer has to find sources, conditions, and exceptions by hand.
- Fixing errors and checking evidence can overlap, but they are worth measuring separately. Workslop speaks to the first; the second remains even when the draft has few errors.
- For evidence to reach the reviewer, three links have to hold: the data keeps it, retrieval passes it to the model, and the output shows it next to each claim.
- Measure AI productivity across the whole approval workflow and by step, and do not report savings you have not measured.
Why reviewing an AI draft can take longer than generating it
Reviewing an AI draft can take longer than generating it because the draft gives the conclusion and leaves the evidence behind. A model can turn a contract, a policy, and an email thread into one clean paragraph. The paragraph does not say which clause supports each number, whether that clause still applies, or which parts were one-time decisions. The reviewer is accountable for those answers, so she goes back to the sources.
- 01Draft
A renewal proposal written in seconds
- 02Find the source
Contract repository: which amendment set the 15% discount?
- 03Check conditions
The discount depends on a commitment that ends this quarter
- 04Check exceptions
Email: the support credit was a one-time decision
- 05Approve
Finance policy on payment terms, then sign-off late in the afternoon
Is it AI workslop? Partly, but that is not what took the afternoon
Researchers from BetterUp Labs and the Stanford Social Media Lab described a related problem in Harvard Business Review: workslop, AI-generated work that looks finished but lacks the substance to move the task forward, so the person who receives it has to redo or clarify it.
The renewal draft had one error, the one-time support credit, and fixing it was quick once it was found. The slow part was different. To approve the draft, the reviewer had to check whether the other two terms could apply, and she could not do that without rebuilding the evidence. The two costs can overlap, since checking evidence is often how errors get found. They are still worth measuring separately, because they need different fixes.
| Workslop | A draft without evidence | |
|---|---|---|
| What the reviewer receives | Polished text with little substance | Text that may be mostly right, with no visible sources, conditions, or exceptions |
| Where review time goes | Finding and fixing what is wrong, or asking what it means | Checking whether each term applies by rebuilding the evidence the draft did not carry |
| What reduces it | Better requests and clearer norms for AI use | Data that keeps sources, conditions, and exceptions, plus retrieval and output design that show them |
Prompts and output design help with both. They can ask the model to cite a source for each claim and to flag terms with an end date. But a prompt can only cite what retrieval hands the model, and retrieval can only hand over what the data kept. If the contract clause, the end date, or the approval record was dropped when the data was prepared, no instruction brings it back.
Four checks a human-in-the-loop reviewer repeats
A human-in-the-loop reviewer repeats four checks before approving an AI draft: source, conditions, exceptions, and approval. Each answers a question the reviewer is accountable for.
| Check | What the reviewer asks | Where the reviewer checked (illustration) | What the draft should carry | How to test it |
|---|---|---|---|---|
| Source | Where did this number or term come from? | The contract repository, to find the amendment behind the 15% discount | source_ and document version for each claim | Pick any claim; the reviewer should reach its source in one step |
| Conditions | Does it still apply, here and now? | The amendment terms: the discount depends on a commitment that ends this quarter | scope, start_, end_, and dependencies as fields | Run a request after the end date; the draft should flag the term |
| Exceptions | Was this a one-off or a standing term? | An email thread approving the support credit once, for an outage | An exception flag, the rule it overrides, and the approving record | Request a renewal the exception never covered; the draft should leave it out |
| Approval | Who can sign off, and on what basis? | The finance policy on payment terms above a contract value | The approver role and the data version the draft used | The approval record should point to the data version and source records |
The last column matters most. If you cannot test a check, you cannot tell whether a change to the data made the reviewer’s job easier or only moved the work somewhere else.
These are the same details that make data provenance useful, and they overlap with what an audit trail for AI decisions has to keep. Exceptions are the hardest of the four, because they often live in tickets and email threads rather than in the main record. We showed one failing in an expired exception that an AI summary kept alive.
Measuring AI productivity across the whole approval workflow
To measure AI productivity in a workflow like this one, count the time from request to approved output and split it by step: drafting, finding sources, checking conditions, checking exceptions, and approval. Drafting time alone measures only the step that AI changed most.
A split by step shows where the time went. If drafting shrank and source checks grew, the time moved to another step without going away. If one check dominates, that check is where the data needs work. Until you have measured both before and after, report what you observed and leave out savings estimates.
Count the second pass as well. A reviewer who finds one wrong commitment, like the one-time credit, usually rechecks the rest of the draft more slowly. That cost does not appear in the draft timing at all.
How to make AI drafts reviewable
A reviewable draft puts the evidence next to each claim. In the renewal scene, two lines of it could look like this (illustration):
- Keep the 15% discount. Source: contract amendment signed two years ago. Condition: valid through this quarter under the three-year commitment; applying it to the renewal needs separate approval. Status: needs deal desk approval.
- Support credit: not carried over. Exception: granted once for an outage, approved by email. Not a standing term.
Getting there takes three links. The data has to keep the evidence, retrieval has to pass it to the model, and the prompt and output format have to show it beside each claim. The steps below start with the data, because the other two links can only use what the data kept:
- Attach a source to every claim. Keep
source_record_idand the document version with each number, term, and commitment the draft can use. - Carry conditions as fields. Store
scope,start_date,end_date, and any dependency, such as a minimum commitment, so the draft can flag a term whose condition has ended. - Mark exceptions as exceptions. Record one-time decisions with an exception flag, the rule they override, and the record that approved them, so they do not read as standing terms.
- Show what the draft could not find. When a source or condition is missing, the draft should say so instead of filling the gap with a plausible sentence.
- Tie the approval to the data version. Record which data version and source records the approved draft used, so a later change shows which approvals to check again.
- Test with fixed evaluation conditions. Use the same model or agent, prompt, and retrieval settings, run the same set of requests before and after the data change, and check two things: whether the evidence fields appear in the draft, and how often the reviewer had to leave the draft to check something.
Each of these steps is simple to describe and hard to keep running. Someone has to attach source records to every field a draft can use, keep conditions and exceptions current as contracts and policies change, and rerun the tests whenever a source changes. If no one owns that work, it can stop when the person who built the first prototype moves on. Keeping the data preparation and validation running is the part CUBIG builds into Syntitan, so the team does not have to maintain it by hand.
Start with one recurring document, such as a renewal proposal or a policy answer, and follow a single draft from request to approval. The checks the reviewer repeats are the fields the data is missing. The same records help the next team too, as we covered in what a second AI deployment should inherit.
Where reviewable data fits in AI data preparation
Keeping sources, conditions, and exceptions attached is part of preparing data for a specific use case, alongside field meanings, business terms, and relationships between records. In Syntitan, CUBIG’s AI-Ready Data Platform, teams prepare data for a defined use case. They validate whether the data meets the criteria for that task, using the model or agent they selected under fixed evaluation conditions. Each release leaves a data version with before-and-after evidence for its preparation steps, the evaluation conditions, and a validation result of qualified, not qualified, or inconclusive. When the source data changes, the team can see what changed against the previous version and which results to check again. Syntitan does not replace the drafting assistant or its review screen. The retrieval and output design that put evidence beside each claim stay with the team building the assistant, and the reviewer checks the evidence there. Syntitan covers the data side: the fields are prepared, versioned, and tested before the assistant uses them. Whether data is AI-ready depends on the task it serves, and for a drafting task that includes whether a reviewer can check the result.
Where to start
Pick one draft your team approved last week and list every place the reviewer had to look before signing off. For each item, ask which link broke: the data never kept it, retrieval did not pass it, or the draft did not show it. That list is your first requirement.
If your team prepares enterprise data for AI tasks and wants drafts a reviewer can check, explore Syntitan.
