The Leverage Audit: Measure Labor vs Leverage Hours with a Local AI

Every operator agrees with the leverage philosophy. Trade hours for systems, build multipliers, protect your thinking. The talks all say it, the books all say it — and then you close the book and answer eleven emails, fix one spreadsheet by hand, and sit in a meeting that could have been a message.

Here is the question the philosophy never answers: what percentage of your week is actually leverage right now? Not what you believe — what's true. Most people guess twenty percent labor and live at sixty. The gap between those numbers is where burnout lives, and nobody measures it because the instrument was missing.

This post is the instrument. A weekly audit that runs on your own machine: your calendar exported, every block classified by a local model as labor, maintenance, leverage, or thinking, and the repeated labor clusters surfaced as a ranked automation backlog. The philosophy told you what to aim for. The audit tells you where you're standing — and both are needed, because you can't close a gap you've never measured.

Why the Ratio Needs an Instrument

The leverage framework is easy to agree with and impossible to act on without numbers, for three reasons:

• Memory lies. You remember the deep-work Tuesday, not the forty small interruptions. Self-reported time diaries drift toward flattery within a week.
• Labor disguises itself. "Managing the pipeline" sounds strategic and is often data entry with better lighting. Labels need to be assigned from evidence, not job titles.
• Progress needs a trend line. Whether last month's automation actually freed hours is answerable only by comparing audits, not by vibes.

A calendar is already a time diary — most people just never read it as data. The audit turns it into one.

Step 1 — Export the Week as Data

Every calendar app exports .ics; from there a few lines of Python turn events into clean JSON the model can read:

python export_week.py --ics calendars/work.ics --out week.json
# -> [{ "day": "Mon", "start": "09:00", "minutes": 90,
#       "title": "Inbox + client follow-ups" }, ...]

Don't curate. The value comes from the audit seeing the week as it actually was — including the ugly blocks you'd rather not report.

Step 2 — Classify Every Block

Feed the whole week to a local model in one pass, with definitions it must commit to:

ollama run qwen2.5:7b """
Here is my week as calendar blocks: {{week.json}}

Classify each block into exactly one category:
- labor: hands-on production; output stops when I stop
- maintenance: email, admin, meetings-about-work, status, chasing
- leverage: building systems, code, content, templates — output repeats without me
- thinking: decisions, design, planning, review
Rules: judge by what the block PRODUCES, not its title. A meeting that
produces a decision is thinking; one that produces status is maintenance.
Return JSON: [{block, minutes, category, one_line_why}]
Then: hours per category, and my labor+leverage ratio.
"""

The "judge by what the block produces" rule is what makes this honest. It is also the step where a local model earning its keep: the same definitions run cold every week, so the numbers are comparable even when they're unflattering — which is the entire point.

Step 3 — Read the Verdict

A typical first audit comes back looking like this:

Sixty-one maintenance blocks averaging nineteen minutes — that is not a discipline problem, that's a queueing problem. And 29% labor is where the automation budget should go, which leads to the audit's second output.

One caution on targets: there is no magic ratio. A solo consultant early in the transition might sit at 40% labor and be perfectly healthy for that stage; an operator three years in should not. What matters is the direction quarter over quarter — leverage and thinking trending up because labor blocks keep graduating into systems. The audit is a compass, not a scoreboard, and the diff against last month is the only number worth arguing with.

Step 4 — Labor Clusters Become the Automation Backlog

Ask the model one follow-up: which labor or maintenance blocks repeat weekly, and what would each look like as an automation?

From this week's classification, list every recurring labor/maintenance block
as an automation candidate. For each: trigger, human part that remains,
first n8n node, risk if it runs wrong. Rank by hours-recovered per month.

The output is your build queue, ranked by payback — "invoice chase (2.5 h/mo)", "weekly client report draft (6 h/mo)", "inbox triage sort (4 h/mo)". This is where the audit connects to everything else in a local stack: each candidate becomes an n8n workflow, each finished workflow should show up in next month's audit as recovered hours. The loop closes.

The Weekly Loop

Manual audits decay after week two, so schedule it — n8n pulls the export, calls the local model, and messages you the trend:

workflow: weekly-leverage-audit
schedule: "0 18 * * 5"
nodes:
  - name: export-week
    type: execute-command
    command: "python /peak/scripts/export_week.py --ics /peak/calendars/work.ics --out /peak/audits/{{date}}.json"
  - name: classify
    type: http-request
    url: "http://localhost:11434/api/generate"
    body: { model: "qwen2.5:7b", stream: false, prompt: "classify-definitions + {{week}}" }
  - name: diff-last-week
    type: code
    rule: "compare category hours vs previous audit; flag any move > 10%"
  - name: report
    type: telegram
    message: "Week {{date}}: labor {{h}}% ({{delta}}) | leverage {{h}}% ({{delta}}) | top recovery: {{candidate}}"
  - name: archive
    type: write-file
    destination: "/peak/audits/{{date}}-result.json"

Friday evening, one message: the ratio, the trend arrows, and the single highest-value automation candidate for next week. That message is the philosophy of leverage, implemented.

The First-Principles Pass

One more prompt earns its keep. For every surviving labor block, ask the model to strip the block to fundamentals:

For each labor block: what does this task fundamentally produce? Which parts
require YOU specifically (judgment, relationship, accountability), and which
only require A someone-or-something? Name the assumption each block hides.

"Invoice chase" hides the assumption that chasing requires a human. "Client onboarding call" hides none — the relationship is the point. The audit's real gift is this sorting: it finds the labor you should automate, and defends the labor you shouldn't.

Why the Audit Must Be Local

Your calendar is the story of your actual life: client names, health appointments, the Tuesday you blocked two hours to think and spent it spiraling. That file is more revealing than your email. Running the audit with a hosted assistant means uploading the raw texture of your week to someone else's servers — the privacy cost isn't hypothetical, it's the whole reason most people never run this analysis at all. A local model reading your real calendar offline is the only version of this instrument many operators will ever honestly use. The sensitivity is the product.

Make It Practical This Week

• Export last week tonight and run one manual audit — the classification prompt above is the entire machinery.
• Read the ratio twice: once for the number, once for which label surprised you.
• Pick the top recurring labor cluster and write its one-line automation sketch.
• Wire the Friday loop before the novelty fades; the trend line is worth more than any single week.

The leverage philosophy promises that your hours can compound. The audit is how you check the promise — privately, weekly, with numbers instead of hope.

Frequently Asked Questions

What if my calendar doesn't reflect my real work? Partial calendars still work — classify what's there, then add a "gap log" prompt: the model lists the untracked stretches and asks what each contained. Most people's calendars underreport exactly the category they're trying to grow. If yours is mostly empty, a week of honest blocking is the prerequisite, and the audit then becomes the reason the habit sticks.

How accurate is a local model at classifying blocks? For calendar titles with your own naming habits, a 7B model with written definitions lands close to human agreement — and crucially, it's consistently wrong in the same direction, which keeps week-over-week comparisons valid. You are reading trends, not audits for a court. Correct mislabels out loud; the fix becomes a definitions tweak that improves every future run.

Isn't this just time tracking with extra steps? Time tracking asks you to log as you go — a tax on every hour, paid forever. The audit reads data you already generate (the calendar) and charges nothing per hour. Different instrument, different cost curve. If you already time-track, feed both sources in; the audit gets sharper.

How long before the ratio actually moves? You'll see the trend bend the month after your first automation ships — one workflow killing a weekly cluster shows up as a clean category-hours drop. The first month is baseline; the second is proof. If three months pass with a flat ratio, the audit has diagnosed something else: you're building automations that don't touch your real calendar, and the backlog ranking — not your instincts — is the thing to trust.