You have mapped the operation, found the constraint, contracted the automation, and placed the human boundary. Now: how do you know, week to week, whether any of it is working? Without a dashboard, you find out from customers. With the wrong dashboard — vanity volume charts — you find out late and misunderstand why.

This lesson builds the smallest dashboard that still tells the truth.

Leading, lagging, and the rest of the vocabulary

• An operational metric is a number you review on cadence and act on.
• A leading signal moves before outcomes do: queue age rising, exception rate climbing, inputs arriving incomplete. It buys time.
• A lagging signal confirms after the fact: revenue, churn, published corrections. It keeps you honest but arrives too late to prevent.
• Queue age is how long the oldest waiting item has waited. It is the single best early warning in any operation with a review gate.
• Error rate is failed or reworked jobs over total jobs. Track it separately from volume: volume can rise while quality quietly collapses.
• A service target is a promise with a number: review within 24 hours, resolve within 2 days. Without targets, queues grow until someone screams.
• Cost per completed job is total operation cost divided by good outputs. The word "good" matters — cheap jobs that need rework are expensive jobs.

A healthy dashboard pairs leading with lagging. Leading without lagging optimizes activity; lagging without leading delivers postmortems.

Six lenses, five metrics

Look at the operation through six lenses: volume (how much entered and left), completion time (lead time and queue age), quality/rework (error and correction rates), customer outcome (was the recipient better off?), cost (per good job), and exceptions (what escaped the happy path and where it went).

Five metrics is the discipline: enough to cover the lenses, few enough to review weekly in thirty minutes. Combine volume with completion, and fold raw exception counts into queue age plus error rate — exceptions deserve attention through those two numbers, not their own vanity chart. A minimal set:

1. Jobs completed per week (volume). 2. Median lead time + oldest queue age (completion time). 3. Error/rework rate (quality). 4. One customer-outcome signal: resolution satisfaction, useful-question rate, repeat/referral (outcome). 5. Cost per good completed job (cost).

Notice what is missing: AI usage counts, messages sent, drafts generated. Activity metrics flatter automation while saying nothing about the operation. Every metric on your scorecard must be able to change a decision, or it leaves the page.

Set targets the honest way: from your own baseline, not from aspiration. Run the operation for two to four weeks, record the actual numbers, then set each target slightly better than baseline — close enough to be reachable, strict enough to notice drift. A target with no baseline is a wish; a target met for three straight reviews gets tightened or replaced. And keep the review ritual fixed: same thirty minutes weekly, same owner walking through the five questions, decisions written into the log. The scorecard's power is not the numbers but the cadence — a system examined weekly cannot rot quietly the way an unmeasured one does.

Exercise: write your OPS-SCORECARD.md

Create OPS-SCORECARD.md with five metrics, each carrying a target and a weekly question:

# OPS-SCORECARD — [operation name]

1. Completed jobs/week — target: [n] — weekly Q: [e.g. did throughput rise without quality falling?]
2. Median lead time / oldest queue age — target: [n days / n hours] — weekly Q: [where is work waiting, and is the constraint moving?]
3. Error/rework rate — target: [<%] — weekly Q: [which step produced the rework, and what input or standard fixes it?]
4. Customer outcome: [chosen signal] — target: […] — weekly Q: [are recipients better off, or just served faster?]
5. Cost per good job — target: [$] — weekly Q: [is each good output getting cheaper without quality loss?]

Finish line: a dashboard that changes a decision. Each weekly question must have an owner and a review slot. A metric nobody asks about is decoration.

Verify: run last week's numbers through the five questions and confirm at least one suggests an action — even "no change needed, because…". If no question can ever produce action, rewrite it. As a concrete test, imagine queue age doubling next week: your scorecard should tell you which stage is clogged, who owns it, and what the service target requires — all without opening a single thread or log.

Common failure mode: measuring the automation instead of the operation — runs executed, tokens consumed, steps automated. Those belong in a vendor invoice, not a scorecard. The scorecard measures jobs, time, quality, outcome, cost.

Check your understanding

1. Why does queue age work as a leading signal while corrections are lagging? 2. What goes wrong when cost-per-job counts all outputs instead of good outputs? 3. Which of your five metrics would move first if your bottleneck shifted?

Class 84 is complete: you can map a system, find its constraint, contract its automation, bound its autonomy, and watch it weekly. Class 85 applies all of it to the operation most readers scale first — content: turning an editorial mission into a pipeline that publishes reliably without losing its point of view.