Capstone — The whole loop

The three-part tutorial built one AI feature — a support-ticket classifier — and proved it works. This capstone runs the same kind of problem through the entire suite, starting earlier and ending later: from the first rough sketch of the idea to the settled lesson about whether shipping it was the right call.

The scenario. Your support inbox is drowning. A handful of senior agents know exactly how to route tickets — billing here, account issues there, the genuinely urgent ones to the front — but that judgment lives in their heads, and on a bad week the urgent tickets get buried. Someone says "couldn't AI sort these?" in a meeting. That sentence is where we start.

The path: sketch the idea in Napkin with zv1 looking over your shoulder → map the workflow in Compass → build the classifier in Workbench → prove it in Caliper → record the ship decision in Ledger with a checkable expectation → settle it against the evidence a week later.

Sketch it — Napkin

Start on a napkin. The idea isn't ready for a spec yet.

1. 1
   Rough out the shape

   Open napkin.zerowidth.ai and click New sketch — you land on a blank canvas with the pen ready. Draw the pipeline as you imagine it: a rectangle (R) for the inbox, one labeled "AI sorts it", and four boxes for the queues — billing, technical, account, urgent. Connect them with arrows (A), label with text (T), and park the open questions on sticky notes (S): "who checks its work?", "how do we know it's not getting worse?" Ugly is the point — the sketch is for thinking.

2. 2
   Pull a teammate onto the board

   Click Share, create a Can draw link, and drop it in your team chat. Whoever opens it is drawing within seconds — no account needed; they show up as a named guest with their own cursor, and you watch their strokes land live. Your support lead adds a sticky you hadn't thought of: "half our tickets are three problems in one email."

3. 3
   Ask zv1 what's missing

   Open the docked assistant and ask: "Look at this triage sketch — what's missing?" zv1 finds the board and actually reads it — the boxes, the arrows, the stickies. What you should see: a critique of what's drawn, not a generic checklist. The one that matters here: every arrow out of the sorter lands in a queue — there's no path for a ticket the AI can't confidently place. That gap becomes a design decision: add an unsure route that goes to a human. Draw the fifth box now.

The sketch just did its job: the idea has a shape, the shape has a hole, and the hole got fixed before anything was built.

Map it — Compass

A sketch is thinking; a Compass page is memory. Before building, put the workflow on the map so everything that follows — the flow, the eval, the ship decision — has a place to attach to.

1. 1
   Have zv1 draft the page from the sketch

   In the same conversation, ask: "Turn this sketch into a Compass workflow page for ticket triage." zv1 drafts the page from what's drawn — the stages, the five routes, the open questions — and shows you an approval card before anything is written: exactly what page it's about to create. Nothing lands without your yes. Approve it, and the Ticket triage workflow page exists in Compass.

2. 2
   Attach the opportunity — and the sketch

   Open the page in Compass and attach an opportunity to the workflow: "auto-classify inbound tickets into five queues, routing low-confidence ones to a human." Specific, anchored to the real work — not "use AI in support." Then paste the sketch's URL into the page body: it renders as a live card with a thumbnail, so the diagram that explains the workflow travels with it. Later, connect the surroundings — the person who owns triage, the helpdesk system, the urgent-tickets-buried pain point — and the map starts carrying the context a builder needs.

Build it — Workbench

The opportunity is concrete enough to build. You can do it by hand (Part 1 walks every click) — or have zv1 do the scaffolding while you do the judging.

1. 1
   Have zv1 scaffold the classifier

   Ask: "Wire up a classifier flow that sorts a support ticket into billing, technical, account, urgent, or unsure." zv1 proposes the flow — and again, it's an approval card: you see the flow it's about to create before it exists. Approve, and the flow is in Workbench waiting for you.

2. 2
   Sharpen the category descriptions

   Open the flow. The category descriptions are where accuracy lives, so write them like you're briefing a new hire: billing — payments, refunds, invoices, chargebacks; urgent — anything time-critical or high-severity, regardless of topic; unsure — genuinely ambiguous or multi-issue tickets that a person should read. That last one is the sketch critique, now encoded as behavior.

3. 3
   Test it, then publish

   In the test pane, paste real tickets. "Card declined twice but I was still charged" → billing. "Whole team locked out and a launch is in an hour" → urgent. "Invoice is wrong and also the export is broken and also how do I add a user" → unsure — the three-problems-in-one-email sticky, handled. When it behaves, publish a version (1.0.0): a frozen snapshot production can pin to while you keep editing the draft. (Wiring it into your ticketing system is one API call — Part 2 covers it.)

Prove it — Caliper

"It looked right in the test pane" is a demo. Before this touches real tickets, get a number.

1. 1
   Build the answer key

   In Caliper, create a dataset of tickets with the queue each should land in. Shortcut: Caliper can generate a starter set from your flow — then you correct it, which is faster than authoring from scratch and forces you to disagree with a few labels (that's the labels earning their keep). Make sure the hard cases are in there: the multi-issue emails, the polite-but-urgent ones. Then write a rubric — for a classifier it's one criterion, "Correct queue": did the output match the expected label?

2. 2
   Run the eval

   Create an eval: the dataset, the rubric, and the target set to your Workbench flow — Caliper runs the classifier on every item itself, no code needed. Kick off a run. What you should see: an overall score plus a per-item heatmap. Say it comes back 0.79, and the red rows cluster where the senior agents said it would be hardest — urgent-flavored tickets landing in account.

3. 3
   Fix the reds, run it again

   Each red cell carries the judge's reasoning — read it, sharpen the urgent description in Workbench ("time-critical regardless of topic"), republish, re-run. 0.90, and the cells that were red are green. That's a measured fix. Keep this eval — it's about to become evidence.

Record the call — Ledger

You're about to ship. This is a decision, and decisions evaporate — six months from now nobody will remember what you expected to happen, only what did. So put the expectation on the record before the results exist.

1. 1
   Record the ship decision with its expectation

   Open ledger.zerowidth.ai, click New entry → Record a decision, and fill the three fields that exist at decision time:

   • What we did — "Shipped the triage classifier (v1.0.0) on live inbound tickets, with the unsure queue routing to a human."
   • Why — "Eval hit 0.90 on the labeled set; urgent tickets were getting buried under manual routing."
   • What we expect — the one that matters. Pick Measurable, source Caliper eval, and write the claim reality can check: >= 85 % accuracy, deadline one week out. In plain words: the eval still clears 85% at the end of week one, on real launch-week tickets — not just on the set we tuned against.

   Under Where, link the Ticket triage Compass page, so the decision and the workflow can find each other. Click Record entry.

2. 2
   Notice what you can't do

   Back on Entries, the decision sits under the Open filter with a days-open counter — an expectation on the record, waiting for reality. Open it: What we now believe reads "Written at settlement — not before." While the entry is open you can still edit it — it's a draft of history, not history yet. But watch what happens after settlement: the claim locks, and the only way to change the record is a new entry that visibly supersedes this one. That's the entire trick: a settled expectation reads exactly as it was written before the numbers came in, so the record can't be tidied up later.

Settle it — the week-one verdict

A week passes. The classifier has been routing real tickets. Time to find out if you called it.

1. 1
   Get the week-one number

   Add a sample of real launch-week tickets to the dataset — labeled with where they should have gone, including the ones the team noticed landing wrong — and re-run the eval. What you should see: the run lands at, say, 86.4%. Cleared the bar — but barely, and the item heatmap shows why: the unsure queue caught about a fifth of real traffic, far more than the tuning set suggested it would.

2. 2
   Attach the evidence and settle

   Open the Ledger entry, click Add evidence, and reference the eval run: "Week-one run scored 86.4% on the launch-week sample; unsure absorbed ~20% of volume." Then click Settle and write the lesson in What we now believe:

   "The unsure queue is why accuracy held. A fifth of real tickets have no clean home, and routing them to a person beats forcing a guess. Don't widen the classifier's reach until that volume drops."

   Settlement happens exactly once: the entry locks, the expectation closes, and the lesson enters the workspace's record. If the eval had come back at 81% instead, you'd settle it just the same — an expectation that missed, with an honest lesson about why, is worth more than a hit. The value is knowing which.

3. 3
   Read it back in Beliefs

   Switch to the Beliefs tab. The lesson is there, citing the entry that earned it — which carries the expectation, the evidence, and the link to the Ticket triage workflow. And it's now part of what zv1 knows: months from now, when someone asks the assistant to "just widen the classifier's categories," it can check the record first and answer with receipts — this workflow has a settled entry; here's what we learned last time.

What you built

One problem, wall to wall: an idea sketched and stress-tested before it was built, a workflow mapped so the context outlives the chat scroll, a behavior built and versioned, proven with a number instead of a demo, and a ship decision recorded and settled — so the next decision starts from what this one taught you.

That last edge is the one most teams never close. Anyone can ship a feature; the compounding comes from knowing, with receipts, whether you were right about it. Run this loop a few times and the Beliefs page becomes the answer to "what do we actually know here?" — for the whole team, new hires included.

Go deeper