Five Metrics, One Privacy Rule

Lesson 3 got you a Week 1 baseline. This lesson is about what you actually do with it. Five numbers get computed off that baseline every week, and one design rule sits underneath all five: none of them can ever hold a real dollar figure, because the schema they're written into has no field that accepts one.

You don't need to memorize the formulas below. You need to know what each metric is actually answering, because that's what tells you what to do differently once you can read it. The formulas themselves come straight from billion_tracker.py, an earlier open-source tracker I built and ran before this course existed. Nothing here is invented for the lesson; it's the same code, credited to the same repo.

The five metrics, and the question each one answers

Automation Index asks: how much of this week's work did the machine do instead of you? It's computed as (automated_hours / total_hours) * 100, a plain percentage of the week's hours that went to automated work rather than hands-on-keyboard work. If it's flat for three straight weeks, you've stopped automating and started just running what you already built. That's not a failure. It's worth noticing, because your next win has to come from somewhere other than automation coverage.

Time Liberation Score asks: how many hours did I get back this week, compared to where I started? The formula is baseline_hours - total_hours, where baseline_hours is fixed at Week 1's total_hours forever. Notice what it's not comparing against: last week. It's always measured against the same fixed point, for the same reason Lesson 1 fixed that point in the first place. A number that drifts against a moving comparison isn't a measurement.

Revenue Efficiency Multiple asks the question that matters more than raw hours saved: am I making more per hour, or just working the same or fewer hours for the same money? The formula is (revenue_ratio / total_hours) / (baseline_revenue_ratio / baseline_hours), this week's revenue-per-hour divided by Week 1's revenue-per-hour. A 1.4 means you're generating 40% more revenue per hour worked than you were at baseline. A 0.9 means each hour is worth less than it used to be, even if total revenue looks fine. This is the metric that catches the trap of "busier, not better."

Client Capacity Score asks how many clients you could actually take on at your current pace, not how many you happen to have. It's (active_clients / total_hours) / (baseline_clients / baseline_hours), clients served per hour worked, as a multiple of your Week 1 rate. If Revenue Efficiency Multiple is flat but Client Capacity Score is climbing, you're absorbing more clients per hour without charging more per hour for it. Worth knowing which one moved before you decide the automation is "working."

Recurring-revenue percentage is the odd one out on purpose: it's not a ratio to anything, just the share of revenue (0-100) that's recurring or subscription work rather than one-off projects, entered directly as you report it. Lesson 10 covers the graduation gate this number feeds into; for now, just know it's tracked toward a 50% target and it's the one metric in the set that isn't derived from a baseline comparison.

The privacy rule: not a policy, a missing field

Here's the part worth sitting with. transformation-log.jsonl (the actual file this system writes, one line per week) is safe to post publicly, paste into a Slack channel, or pull up on a client call. Not because you're careful about what you type into it. Because the schema doesn't have anywhere to put an absolute number even if you tried.

Every week after Week 1, the log asks for a revenue ratio to your own Week 1 baseline, not a dollar amount. The field is named revenue_ratio, a float, not revenue_dollars or anything that could hold an absolute value. Type in 1.15 and you've recorded "15% more revenue than my own Week 1," whatever that real number actually was. Week 1 itself is always 1.0 by definition. It's the point everything else is measured against, never a number in its own right.

Walk that back through Revenue Efficiency Multiple's formula: (revenue_ratio / total_hours) / (baseline_revenue_ratio / baseline_hours). Every term on both sides is either a ratio or an hours figure. There is no dollar anywhere in that expression, at any point in the computation, because there was never a dollar anywhere in the inputs. You couldn't leak a real revenue number through this metric even by accident, because the arithmetic never touches one.

That's the actual guarantee, and it's a structural one, not a promise about your own discipline. A policy says "please don't type in your real revenue." A missing field means you can't, not even by mistake, not even under deadline pressure at 11pm on a Friday when you've stopped thinking carefully about what you're typing. The second kind of guarantee survives a bad week. The first kind only survives as long as you remember it exists.

What the log actually looks like on disk

Here's the real schema, filled in with a worked example rather than any operator's actual numbers, so you can see the field names and read the arithmetic yourself. This is the shape every row takes: Week 1, then a later week.

{"week_number": 1, "total_hours": 52.0, "automated_hours": 6.0, "manual_hours": 46.0, "active_clients": 4, "revenue_ratio": 1.0, "recurring_revenue_pct": 18.0, "automation_index": 11.54, "time_saved_vs_baseline": 0.0, "revenue_efficiency_multiple": 1.0, "client_capacity_score": 1.0}

{"week_number": 6, "total_hours": 41.0, "automated_hours": 19.0, "manual_hours": 22.0, "active_clients": 5, "revenue_ratio": 1.15, "recurring_revenue_pct": 27.0, "automation_index": 46.34, "time_saved_vs_baseline": 11.0, "revenue_efficiency_multiple": 1.4585, "client_capacity_score": 1.5854}

That's every field the real script actually writes, minus submission_date, logged_at_utc, automated_this_week, and biggest_bottleneck, trimmed here so the metric fields aren't buried in bookkeeping. Notice the five computed fields are stored, not left for a reader to derive: automation_index, time_saved_vs_baseline, revenue_efficiency_multiple, and client_capacity_score sit right there in the row log_week.py wrote, already calculated. Notice too what neither line could ever tell you, no matter whose real week it was: what the operator actually charges, what their revenue was in dollars, or what their business is worth. You can compute all five metrics from a row shaped like this and you still won't know. That's not an omission. It's the schema doing exactly what it was built to do.

How to read a week's row without doing the arithmetic by hand

Why this matters before Module 2 starts

Starting in the next lesson, you're logging one of these rows every week for real. If you only remember the formulas, you'll type in numbers without knowing what they're telling you. If you remember what each metric answers, a report that looks fine on the surface will start showing you the thing underneath it: hours saved with revenue-per-hour flat, or client capacity climbing while the recurring-revenue share stalls. Those disagreements are the actual content of Lesson 6. This lesson's job was just to make sure you can read the five numbers before you're staring at four real weeks of them.