Studio Internals.

Everything else in the Studio Ops Kit is about doing the work. This doc is about running the Studio — the processes that keep the business alive between sprints, track what we’ve learned, and make sure we actually get paid. It is the least glamorous doc in the kit and, in year two, probably the most load-bearing.

Five years from now, the Studio’s value will be a function of three compounding assets: the pattern library (§07), the engagement archive (§06), and the post-mortem repository (§08). None of those assets maintain themselves. This doc defines the discipline that keeps them accruing instead of rotting.

Studio Internals is organized around seven surfaces, each backed by one asset we want to compound and one person who owns it. If you can name the surface, you can find the asset and the owner. If you can’t, the surface doesn’t exist yet — go file that gap as a Linear issue on the Studio-internal project.

The Studio does not run a “sales function” in any traditional sense — we run a qualification function. The scarce resource is not leads, it is our own focus. A CRM that tracks which opportunities we’ve declined and why is at least as valuable as one that tracks closes, because the pattern of declines is what tells us where our positioning is drifting.

This section defines the pipeline stages, the tooling, the qualification bar, and the weekly discipline. All of it lives on one Airtable base — one row per opportunity, one view per role.

Parallel to these six, two terminal states: Closed-won (moved through Active and handed off) and Closed-lost (declined by us, declined by them, or timed out). We write a one-paragraph reason into the CRM row for every Closed-lost — that paragraph is what Pattern Search reviews during the quarterly §09 Studio Review.

A Stage-2 call is a pass/fail gate, not a sales conversation. We pass if three things are true: (1) the workflow has a named owner with budget authority; (2) the workflow is real, repeated, and measurable; (3) the client can name the one or two metrics they’d defend in a Gate-1 review. If any of the three are missing, we do not move to Scope — we offer a one-page qualification memo and return to Signal until the gap closes.

The memo is a small gift that earns reply rates on re-engagement three months later. Refusing to scope an unqualified opportunity is Studio hygiene and one of the most-corrected behaviors in our own retrospectives.

Every engagement signs three documents: an MSA (master services agreement, once per client), an SOW (statement of work, one per sprint or phase), and an NDA (mutual, one per client). For enterprise clients, an IP assignment rider is attached to the SOW when scope touches their proprietary data flows.

All four live as versioned Google Docs templates under Umbra Studio / 00-templates / contracts/. Template version is stamped in the footer. Never send a contract from a template older than six months without a review cycle.

The default, signaled in the MSA and reinforced in every SOW: the client owns their workflow artifacts (state sheets, prompts tuned to their data, governance instruments, anything that contains their operational detail). The Studio owns the patterns — the abstract, reusable shapes from which we generate those artifacts — and reserves the right to republish anonymized versions in the pattern library.

This split is the single most important contractual decision the Studio makes. Without it, the pattern library (§07) cannot compound, and each engagement starts from zero. We will walk away from a client who insists on full work-for-hire IP transfer, and have done so twice.

The Studio runs on cash-basis books with a simple three-tool stack: Mercury for banking, Wave for bookkeeping and invoicing, and a shared accountant for tax. The goal is to spend less than 90 minutes per week on finance end-to-end — if we cross that line, the tooling is wrong and we escalate to a quarterly review.

Every SOW names one of three standard schedules. No custom schedules without Studio Lead sign-off — they break the Airtable CRM views and the cashflow forecast.

Every Studio expense lands in Wave with exactly one of five tags: cogs (direct sprint cost — contractor hours, third-party API, client-specific tool), opex (Studio running cost — subscriptions, banking, insurance), capex (hardware purchases that land on the hardware doc — see USO-ST-05), r&d (pattern-library investment, experimentation), or g&a (legal, accounting, compliance). The tag split is what feeds the quarterly review’s margin math.

Last business day of each month. 45-minute block on the Studio Lead’s calendar. Reconcile Mercury against Wave, confirm every expense is tagged, close the books for the month, generate the P&L, and paste the top-line numbers into the finance tab of the Studio’s internal state sheet. Any anomaly > $500 gets a comment; any anomaly > $2,500 blocks close until explained.

Every sprint produces artifacts. Without discipline, those artifacts die in Drive folders no one opens. With discipline, they become the Studio’s most durable asset — a library of case studies, playbooks, and decision records that compound engagement-over-engagement.

The knowledge base has three layers, each with its own place, owner, and review cadence.

Every engagement archive produces a one-page case study, even if it’s private-to-the-Studio. The template has eight fields: client context (1 para), workflow targeted, Lighthouse pattern used, what shipped, governance instruments, metrics before/after, what we’d do differently, what the client got right that surprised us. The last two fields are the most important — they feed Pattern Search.

The pattern library is the Studio’s flywheel. Ten patterns in the library today becomes fourteen next quarter becomes twenty by year-end — and each pattern, as it matures, shaves a measurable number of sprint hours off future engagements. Without a versioning discipline, though, the library degrades into a graveyard of near-duplicates.

This section defines what counts as a pattern, how patterns are promoted through maturity levels, the semver discipline applied to each, and the deprecation path.

A pattern is a reusable workflow shape — abstract enough to be described independent of any single client’s data, concrete enough to ship in a sprint. Examples from the current library: Queue row-locking state machine, Weekly SEO brief + auto-draft, Album-review research + publish, RSS-to-triage inbox. A pattern names a problem, a workflow shape, a governance recipe, and a graduation path.

What is not a pattern: a client-specific prompt, a one-off script, a UI component, a specific MCP server. Those are parts; patterns are assemblies.

Every pattern at P1 or above carries a semver. Major = incompatible shape change (e.g., state layer graduates from Sheets to Supabase). Minor = meaningful addition (new governance instrument, new metric). Patch = clarification or prose fix. A pattern’s semver appears in three places: the Notion page title, the folder name in Git (patterns/<slug>-v<maj.min>/), and every SOW that quotes it.

The CURRENT.md symlink pattern (see USO-ST-02 §06) applies here too: every P1+ pattern has a CURRENT.md that resolves to the latest minor. Major upgrades are published as new folders with a migration note in the old folder’s CURRENT.md.

Promotions are proposed by any Sprint Lead during a post-mortem (§08). They are ratified by the Governance Architect during the monthly pattern review — a 45-minute block on the last Friday of each month. The ratification bar:

Deprecation is the scariest lever in the library, and the one we use least confidently. When a pattern is deprecated, the Governance Architect writes a one-paragraph migration note into the pattern’s CURRENT.md pointing to the successor, and any live engagement still using the deprecated pattern is flagged in the Studio review. Deprecation does not invalidate past SOWs — clients who signed against P1.2 of a now-deprecated pattern are honored at P1.2 until their next sprint.

The Studio’s learning function sits in one Notion database: Studio / post-mortems/. It holds three kinds of records — engagement retrospectives (one per sprint, at handoff), incident reviews (one per Studio-SEV-1 or above, within 7 days), and Studio quarterly retrospectives (one per quarter, at the Studio Review).

All three share the same eight-field template. The discipline is not in the template — it’s in the ratio of lessons-filed to lessons-applied. A lesson that doesn’t change a playbook, a pattern, or a template is not a lesson; it’s a feeling.

The single metric that tells us the post-mortem repository is alive: lessons → artifacts. Every lesson filed must name the artifact it changes. If 80%+ of lessons in a quarter resolve to a committed artifact change, the repository is healthy. If fewer than 50% resolve, we are writing therapy, not post-mortems — and the Studio Lead escalates that as a quarterly theme.

The Studio’s capacity is bounded not by headcount but by attention. A single Sprint Lead can safely run one active sprint and a parallel Discovery phase; that is the atomic unit of capacity. Utilization math rolls up from that unit. This section defines how we plan, how we measure, and what signal triggers the next hire.

One Sprint Lead + one Agent Engineer + shared Governance Architect = one sprint team. One team safely handles one active sprint (stages Build/Handoff) plus one parallel Discovery or Redesign — i.e., 1.5 concurrent workflows. Attempting two concurrent active sprints per team is a known anti-pattern and a top-three cause of engagement retrospective “what failed” bullets.

One spreadsheet. One tab per quarter. Rows = weeks. Columns = roles (Sprint Lead, Agent Engineer, Governance Architect, Studio Lead). Cells = % billable. Anything above 85% sustained for more than two weeks is a burnout risk and a hiring signal. Anything below 50% for a month is a GTM signal — pattern-search the §09 CRM review for blockers.

Everything above collapses into a small number of recurring actions. This checklist is the operating loop of the person running the Studio. If it is filled out honestly each week, every other section of this doc stays alive without further intervention.