---
name: business-origin-audit
description: Use this skill when a technology leader is new to a seat (or hasn't re-checked in the last year) and wants to test whether the inherited story of "why this business exists" and "what competitive game we're playing" still matches reality — before making architecture, hiring, or roadmap decisions on top of a stale assumption. States a candidate read at each judgment point (revenue match, which game is being played, draft excavation answers); the user's own dated, signed answer is still what makes it real. Triggers on requests like "run an origin audit," "what business are we actually in," "help me figure out what game we're playing," "is our founding story still true," or "audit our founding premise against AI."
---

# The Origin Audit
This skill is Labor as Code™ for "Learn Why the Business Exists First" in *The Code Takes Care of Itself*. Read that chapter for the
argument this generalizes — the book's own example (a CTO who nearly
killed an approval workflow that turned out to be the company's most
persuasive sales artifact) is a specific case, not the template to
copy. This skill runs the audit and states a read of what the
evidence shows at each judgment point (whether revenue still matches
the founding story, which competitive game the numbers point to) -
but the excavation questions in Step 4 stay the user's own to answer,
date, and sign. That is not caution - the book's mechanism is personal
accountability for a specific, falsifiable belief, and a skill-authored
answer wearing the user's signature would defeat the exercise it's
running. This skill can draft a candidate answer from the evidence to
react to; it cannot sign for the user.

## Before running

1. **This audit needs real documents and real numbers, not inference.**
   Step 1 requires an actual founding artifact (a pitch deck, a
   founding memo, an early investor update). Step 2 requires an actual
   current revenue breakdown. If the user doesn't have these on hand,
   help them figure out who to ask rather than reconstructing a
   plausible version from context — a fabricated founding story
   defeats the entire exercise.
2. **Confirm the seat and the timeline.** A founding CTO answers a
   different question than an inherited one (the book draws this line
   sharply — a founder tested the thesis against real money on the
   line; everyone after inherits the answer without the pressure that
   produced it). A fractional CTO should run this in the first two
   weeks, framed as diligence, not months in. Ask which applies before
   starting.
3. **Confirm who the "peer check" in Step 3 actually is.** The
   exercise depends on saying the name of the competitive game out
   loud to an executive peer before saying it to the engineering team.
   If there's no peer relationship in place yet, that's worth naming
   as a gap before proceeding.

## Steps

Run this audit in the first sixty days in a new seat. Run it again at
least once a year afterward — an audit that isn't repeated becomes an
inherited assumption the same way the original story did.

### 1. Find the earliest surviving statement of why the business exists

A pitch deck, a founding memo, an early investor update — whatever the
user can actually locate. Read it as a hypothesis, not as settled
history: what did the founders believe about customers, the market,
and the competition at the time?

### 2. Test the hypothesis against current revenue

Pull the real revenue breakdown and ask whether it still matches the
founding story or has quietly moved to something else. A company
funded as a developer-tools business that now earns most of its money
from enterprise compliance add-ons is not the company its mission
statement describes — and its technology priorities should be set for
the business it has actually become, not the one on the original deck.
State this skill's own read directly: does the current revenue
breakdown still support the founding hypothesis, contradict it, or
show a genuine split (two segments pulling in different directions,
neither yet dominant)? Cite the specific numbers the read rests on.
Where the split is real and roughly even, name both readings rather
than forcing a single story past what the revenue actually shows.

### 3. Name the game being played now — and say it to a peer first

Pick from the five recurring competitive games (or a blend, with one
dominant note):

- **The cost game** — whoever delivers a comparable outcome most
  cheaply wins; every engineering decision is secretly a margin
  decision.
- **The network-effects game** — the product gets more valuable as
  more people use it; growth and onboarding friction matter more than
  elegance.
- **The regulatory-moat game** — surviving the compliance gauntlet is
  the real defense, not the software; treating compliance as friction
  to optimize away dismantles the company's actual moat.
- **The distribution game** — the winner sits inside the workflow the
  customer won't leave, best product or not; switching-cost inertia
  usually beats technical excellence.
- **The talent-scarcity game** — the bet is that a few unusually
  capable people can do something a larger, better-funded competitor
  can't staff for.

Before the peer conversation, state this skill's own read of which
game (or which dominant blend) the evidence from Steps 1-2 best
supports, and why - this is the candidate answer the user brings to
the peer, not a replacement for bringing it. Where the evidence
plausibly supports two of the five games about equally, name both and
say what would distinguish them (which customer actually pays, and
why they'd switch). Say the name of the game to a leadership peer
**before** saying it to the engineering team. If a peer names a
different game, stop. That disagreement outranks anything currently on
the architecture roadmap — it means the organization is executing two
different bets at once.

### 4. Answer the four excavation questions in writing, dated and signed

Answer each one specifically enough to be wrong — a vague answer isn't
an answer. Where the evidence from Steps 1-3 already points somewhere
specific, draft a candidate answer for the user to react to rather
than handing back a blank question - but the user's own reasoning,
date, and signature are what makes the answer real; a skill-drafted
answer left unreviewed and unsigned is not a finished excavation
question.

1. **Drucker's mission question:** What is our mission, stated the
   way the money actually flows right now, not the way the founding
   deck described it?
2. **Feynman's question:** What would have to be true for our current
   technology bets to be wrong, and have we actually gone looking for
   that evidence, or have we simply not yet been embarrassed by it?
3. **Thiel's contrarian question:** What do we believe about our
   market that would sound insane to a smart, well-informed
   competitor, and does our architecture actually bet on that belief,
   or quietly hedge against it?
4. **The AI-redefinition question:** If AI redefines the work this
   business performs, or the workforce it employs or serves, does our
   reason for existing survive? Or has this been, without anyone
   describing it this way, a workforce-arbitrage business wearing a
   technology company's branding?

Put the user's name and today's date on each answer. An answer nobody
is willing to date and sign isn't believed yet — treat that as a
finding, not a formatting requirement.

### 5. Set the date of the next audit before closing the document

Twelve months is the default. Sooner if a competitor does something
that casts real doubt on the current answer. Put the date somewhere
it will actually resurface — an audit that isn't repeated becomes
next year's inherited assumption, carrying the current leader's name
instead of the last one's.

## The check that catches this book's own failure mode

The chapter's core warning: being *technically correct* about a
narrow question while being wrong about the business is worse than
being wrong outright, because "correct" is what makes the mistake
feel like diligence instead of a blind spot. Before calling this
audit done, confirm:

- **Every answer traces to a real document or a real number**, not an
  inference dressed up as one. If Step 1 or Step 2 came up empty
  because the artifact couldn't be found, say so explicitly rather
  than filling the gap with a guess.
- **Every stated read (the revenue match in Step 2, the game name in
  Step 3, any drafted answer in Step 4) cites the specific evidence it
  rests on**, and names it as a candidate read the user reviews - not
  as a settled finding standing in for the user's own dated signature.
- **The AI-redefinition question got a real answer**, not a reflexive
  "we're fine" — the book is explicit that most inherited premises
  have never been tested against this specific condition, because it
  didn't exist when the premise was written.
- **The game-naming step actually happened out loud with a peer**,
  not just inside the user's own head. A silent agreement with
  yourself isn't the check this step is designed to run.