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 ties the discount to a three-year commitment that ends this quarter, so she checks whether it carries into a renewal. 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, it is late afternoon.
AI made the draft fast. It did not make the draft checkable. The draft does not say where each claim came from, which conditions limit it, or which exceptions apply, so the reviewer rebuilds that evidence by hand. The time saved in writing comes back in review. 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.
- This differs from workslop: the draft can be correct and still hard to check, because the evidence stayed behind in contracts, policies, and email.
- A human-in-the-loop reviewer repeats four checks: source, conditions, exceptions, and approval. Each one can travel with the draft as data.
- 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
Each step in the scene was a search through a different system. None of it was writing. A faster or better-written draft would not have shortened any of these searches, because the draft text was never the slow part.
Is it AI workslop? Not if the draft is accurate
Researchers from BetterUp Labs and the Stanford Social Media Lab named one version of this 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 was not workslop. Two of its three commitments were correct. The reviewer still could not tell which two without rebuilding the evidence, and that is what took the afternoon. The two problems need different fixes.
| Workslop | A correct draft without evidence | |
|---|---|---|
| What the reviewer receives | Polished text with little substance | Accurate text with no visible sources, conditions, or exceptions |
| Where review time goes | Redoing the work or asking what it means | Rebuilding the evidence the draft did not carry |
| What reduces it | Better requests and clearer norms for AI use | Data that carries sources, conditions, and exceptions into the draft |
Better prompts and clearer norms for AI use can reduce workslop. They do not attach a contract clause, an end date, or an approval record to the draft. That depends on whether the data the AI drew from kept those details.
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 check answers a question the reviewer is accountable for, and each one can travel with the draft as data instead of being rebuilt by hand.
| 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 AI draft carries its evidence with it. Build that into the data before the model writes:
- 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 count 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. In most teams that work falls to whoever built the first prototype, and it stops when that person moves on. Keeping that 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. 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.
Five questions before the next AI draft reaches a reviewer
- Can the reviewer reach the source of every number in one step?
- Does the draft show which conditions limit each commitment, and when they end?
- Are one-time decisions marked as exceptions in the data the AI reads?
- Do we measure time from request to approval, by step, or only drafting time?
- When the source data changes, do we know which approved drafts to check again?
If the answer to the first question is no, start there. Pick one draft your team approved last week and list every place the reviewer had to look. That list is your first data requirement.
If your team prepares enterprise data for AI tasks and wants drafts a reviewer can check, explore Syntitan.
