The Origin Audit

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…

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.