Skip to content

The work item, walked

A review artefact. The full field list across five different paths, so the set can be checked rather than trusted.

Scenarios

Path Exercises Status
A Routine, drafted and sent The happy path Written
B Flagged, still drafted and sent attention_reason alongside sent_by_us Written
C Cannot determine, acknowledgement only closed_by_human, acknowledgements, no model call at step 2 Written
D The human replied first closed_manual, reconciliation Written
E Nothing needed closed_no_action, shortest path Written
F Draft edited before approval final_payload_hash, the commonest human action Written
G Close confirmed under review close_review: required, a confirm rather than an approve Written
H Job created with gaps filled create_job, the prefilled form Written
I Multi-turn conversation brain_calls climbing, category revision, job re-resolution Not yet
J Multi-category secondary_categories, currently unjustified Not yet
K No draft possible (parse_failure) The human writes from scratch with nothing Not yet
L Reopened after closing first_closed_at, reopen_count, versions restamped Not yet
M Draft regenerated by staleness brain_calls climbing, a superseded approval record Not yet
N mailbox approval surface A different approval surface Not yet
O System failure Item stuck in new, never reaches the client Not yet

All twelve are now writable. Everything they exercise is decided, so the remaining seven are writing rather than design.

M raises a question nothing has answered: when a draft is regenerated, the first approval record is superseded and a new one is pending. Only one is ever pending, so "which is live" is unambiguous, but the walkthrough should show both rows to make that visible.

What to look for:

Question How to spot it
Is a field ever actually used? A row that stays null in every path is redundant
Is a field ambiguous? A row where two paths disagree about what a value means
Is something missing? A path where you cannot tell what happened from the fields alone
Is a field set too early or too late? A value that arrives before the thing it describes is known

A. Routine, drafted and sent

"Hi, we're after a price on upgrading the board at our Preston warehouse. Fairly urgent, our insurer is asking."

Field 1.1 Capture 1.2 Brain 2 Execute 3 Approve 4 Loop
status new assessing awaiting_approval sent_by_us sent_by_us
current_stage captured decided awaiting_human reconciled completed
brain_calls 0 1 2 2 3
model_calls 0 1 2 2 3
config_version null 12 12 12 12
catalogue_version null 3 3 3 3
category null quote_request
secondary_categories null []
priority null high
customer_id null cust_00412
job_id null null
job_link_basis null null
job_link_certain null null
attention_reason null null
attention_detail null null
closed_at null null null null set

priority: high came from a rule (mentions an insurer), not the model. job_id stays null because a quote request has no job yet, which is correct rather than a failure.

B. Flagged, still drafted and sent

"Your invoice on job 4471 is wrong and I've spoken to my solicitor."

Field 1.1 Capture 1.2 Brain 2 Execute 3 Approve 4 Loop
status new assessing awaiting_approval sent_by_us sent_by_us
current_stage captured decided awaiting_human reconciled completed
brain_calls 0 1 2 2 3
model_calls 0 1 2 2 3
config_version null 12 12 12 12
catalogue_version null 3 3 3 3
category null invoice_query
secondary_categories null []
priority null urgent
customer_id null cust_00218
job_id null job_04471
job_link_basis null quoted_reference
job_link_certain null true
attention_reason null legal_risk stays set stays set
attention_detail null "Refers to speaking with their solicitor"
closed_at null null null null set

This is the path that forced attention_reason out of status. The item was flagged and still ended sent_by_us. If the flag lived in status, this row would have to lie about one or the other.

C. Cannot determine, acknowledgement only

"Following up on the thing we discussed."

Field 1.1 Capture 1.2 Brain 2 Execute 3 Approve 4 Loop
status new assessing awaiting_approval closed_by_human closed_by_human
current_stage captured decided awaiting_human reconciled completed
brain_calls 0 1 1 1 2
model_calls 0 1 1 1 2
config_version null 12 12 12 12
catalogue_version null 3 3 3 3
category null unclear
secondary_categories null []
priority null normal
customer_id null cust_00733
job_id null null
job_link_basis null null
job_link_certain null null
attention_reason null unclear_category stays set stays set
attention_detail null "Cannot tell what is being asked"
closed_at null null null null set

An acknowledgement went out, then the human wrote the real answer themselves, so the outcome is closed_by_human rather than sent_by_us.

Neither counter moves at step 2. An acknowledgement is a template render, so there is no second brain call and no model call. Compare with path A, where drafting cost both.

D. The human replied first

A quote request, but someone answered from their phone while it sat waiting.

Field 1.1 Capture 1.2 Brain 2 Execute 3 Approve 4 Loop
status new assessing awaiting_approval closed_manual closed_manual
current_stage captured decided awaiting_human reconciled completed
brain_calls 0 1 2 2 3
model_calls 0 1 2 2 3
config_version null 12 12 12 12
catalogue_version null 3 3 3 3
category null quote_request
secondary_categories null []
priority null normal
customer_id null cust_00901
job_id null null
attention_reason null null
attention_detail null null
closed_at null null null null set

We paid for a draft nobody used. That is what the closed_manual rate measures, and why a high rate means too slow rather than inaccurate.

Worth checking

Nothing on the item records what the human actually sent. The reconcile step found their reply, so we have it. Should there be a pointer, or is the outbound message row enough?

E. Nothing needed

A supplier newsletter.

Field 1.1 Capture 1.2 Brain 2 Execute 3 Approve 4 Loop
status new assessing closed_no_action n/a n/a
current_stage captured decided completed
brain_calls 0 1 1
model_calls 0 1 1
config_version null 12 12
catalogue_version null 3 3
category null marketing
secondary_categories null []
priority null low
customer_id null null
job_id null null
attention_reason null null
attention_detail null null
closed_at null null set

The shortest path. One brain call, one model call, no draft, no human. If close_item is in actions_requiring_approval during onboarding, this path gains a review step and ends closed_no_action after approval instead.

F. Draft edited before approval

Same email as path A, but the approver rewrites two sentences before approving.

Identical to A on the work item. The difference is entirely on the approval row.

approval field Value
action_name draft_reply
payload_hash Hash of what we proposed
final_payload_hash Hash of what the human sent
status approved
decided_by sarah@greenhills.com.au

Both hashes are kept. The first proves what we generated, the second proves what went out. Keeping only one loses either the evidence or the accountability.

The diff between them is the training signal. Consistent rewording in the same direction says the prompt or the voice config is wrong, and it feeds the generation feedback store rather than the triage one.

In reporting this counts toward edit rate, not approval rate. A high approval rate with a high edit rate means people are fixing the output rather than trusting it.

G. Close confirmed under review

A supplier newsletter, but the tenant is on close_review: required during onboarding.

Field 1.1 Capture 1.2 Brain 2 Execute 3 Approve
status new assessing awaiting_approval closed_no_action
current_stage captured decided awaiting_human completed
brain_calls 0 1 1 1
model_calls 0 1 1 1
category null marketing
priority null low
attention_reason null null
closed_at null null null set

Compare with path E, the same email under close_review: none. There it closed at step 2 with no human involved. Here it waits.

No second brain call. Closing needs no generation, so the counters stay at 1 throughout.

If the human corrects it rather than confirming, the item does not close: the category is corrected and it goes back for a draft. That correction is a labelled example for the eval set, which is the real argument for running this mode during onboarding.

H. Job created with gaps filled

"Can you get someone out to look at the switchboard at our Coburg site?"

Field 1.1 Capture 1.2 Brain 2 Execute 3 Approve 4 Loop
status new assessing awaiting_approval sent_by_us sent_by_us
current_stage captured decided awaiting_human reconciled completed
brain_calls 0 1 2 2 3
model_calls 0 1 2 2 3
category null job_request
priority null normal
customer_id null cust_00412
job_id null null set on creation
attention_reason null null

The approval record carries the proposed job, with gaps:

Field Proposed After the human
Customer cust_00412 unchanged
Description From the email unchanged
Site address missing 14 Gaffney St, Coburg
Job type missing Switchboard inspection

final_payload_hash differs from payload_hash, exactly as with an edited draft, because the human changed what we proposed.

job_id is set at creation, not at 1.2.2. Resolve found no existing job, correctly, because this one did not exist until the human approved it.

What the paths show

Field Used in Verdict
status All Earning its place
current_stage All
brain_calls All
model_calls All Diverges from brain_calls only on retries and idempotency hits. Not visible in these eight
config_version, catalogue_version All
category All
secondary_categories None Still unjustified. Needs scenario J
priority All
customer_id A, B, C, D, H Null in E, correctly
job_id B and H only Thin, and correct: most emails have no job
job_link_basis, job_link_certain B only Same
attention_reason B, C
attention_detail B, C
closed_at All
approval.payload_hash A, B, C, F, G, H
approval.final_payload_hash F and H only Only when a human changed something

Questions this raises

secondary_categories is still unused in every written path. Scenario J would justify it. Until then, an empty array on every routine item is a column doing nothing.

job_link_basis and job_link_certain only appear alongside job_id. Three fields that are all null or all set. Worth asking whether that is one nested value rather than three columns.

model_calls never differs from brain_calls in any written path. It diverges only on a parse retry or an idempotency hit, neither of which is a normal path. Still worth having, and worth knowing it is invisible most of the time.

Nothing records what a human sent when they wrote it themselves (C) or replied first (D). The outbound message row has it, so the question is whether the work item needs a pointer.

final_payload_hash appears in two of eight paths, and both are the cases where evidence matters most: a human changed what we proposed. Worth confirming it is nullable rather than always written.