ACME's order◆ outcome● intervention■ run
The Agent
an eager tenor
an intake agent
The Ensemble
the chorus
every agent, ours and outside ones
The Entity
a proud mezzo · today, an order
ACME Retail's customer order
id e_7f3a
external id ORD-88123
The Outcomes
a bright ensemble ◆
milestones the order reaches
The Intervention
a warm, tired baritone ●
a human who steps in
The Use Case
a crisp soprano scorekeeper
intake · fulfillment · billing
The West Coast Scheduler
a sunny surf-rock agent
west_coast_schedulers
abcd
The Runs
a disposable chorus ■
compute, not sacred objects
workflow: acme-intake-v3
Locked inside, one run at a time
run #812
starts from nothing
ended · gone
run #813
starts from nothing
ended · gone
run #814
starts from nothing
ended · gone
Shipped?Paid?Did a human step in?
The work goes on the order itself: customer_order ORD-88123, shared by every agent.
schema.ts · one per org
entity('customer_order', {
orderNumber, customerName, shippingAddress,
region, totalUsd,
}, { externalId: ['orderNumber'] })
| id | order_number | customer | region | total |
|---|
| e_7f3a | ORD-88123 | ACME Retail | west | $450 |
upsert('customer_order', { orderNumber: 'ORD-88123', … })
→ found or created → { id: 'e_7f3a' }
Every agent, the same row
one key, one row, shared by everyone who writes it
intake agentrun a→ e_7f3a
fulfillment agentrun b, c→ e_7f3a
billing agentrun d→ e_7f3a
an outside agentAPI key→ e_7f3a
Outcomes, interventions and foreign keys point at the id; they never create the order.
customer_order ORD-88123 · Mon → Fri
Mon
Tue
Wed
Thu
Fri
●
discount_approval10%, not edited
●
fulfillment_escalationmissing_suite_number
●
billing_escalationpayment_dispute
Each one is a row with its own occurred_at. Reaching the same outcome twice adds a row; a row written late still counts.
customer_order ORD-88123 · use cases
Mon 09:00 · nothing recorded yet
| use case | success on ◆ | failure on ● | status |
|---|
| intake | accepted, declined | intake_escalation, intake_qa_failed | in_progress |
| fulfillment | delivered | fulfillment_escalation | in_progress |
| billing | paid | billing_escalation | in_progress |
How a use case is scored
1 · any failureOn intervention → failure
2 · otherwise any successOn outcome → success
3 · otherwise → in_progress
Any writer, any order, late or backfilled: it all counts. discount_approval isn't in failureOn, so it changes nothing.
The entity is what we bill against. Use cases define what we bill for.
At the door
customer_order rows
ORD-88123region: west
ORD-88124region: east
ORD-88125region: not set
A row whose filtered column isn't set stays outside, unless the filter lists null.
scope('west_coast_schedulers', {
customer_order: { where: { region: 'west' } },
order_lines: { follows: 'orderId' },
})
What it sees
customer_order: ORD-88123 only
order_lines: ORD-88123:1, following orderId
outcomes & interventions: ORD-88123's. ORD-88124's don't exist, even to query.
✕ upsert { id: 'e_7f3a', region: 'east' }: rejected. A row must be in scope before and after the write.
customer_order ORD-88123Mon ─────────────────── Fri
■ run started · ◆ outcome · ● intervention
intake
■run a
●discount
◆accepted
fulfillment
■run b
●escalation
◆shipped
■run c
◆delivered
billing
■run d
◆invoiced
●escalation
◆paid
+ an outside agent joins, with its own API key and role, on the same order, inside west_coast_schedulers
Tonight only
Break Free
The System of Record, a musical
A short musical about where ACME's work lives, in six numbers.
Sound on, please. ← → change numbers · space pauses