How it all relates

Domains, capabilities, levels, roles, titles, seats. That looks like six lists. It is one list. Everything else is a way of pointing at it.

The convolution comes from treating those six words as six things to keep. Domains and capabilities are the list. Levels are how a capability is executed. Roles, titles, and seats are people pointing at it — not parallel inventories.

The count we now attach to a seat is not a seventh list. It's a quantity on one entry, not a new inventory to keep.

One list, not several lists

The spine

Domain contains capability. A capability is the named outcome we promise. It can be executed at L1, L2, L3, or L4 — same promise, different depth of judgment and accountability.

The capability is the whole piece. The level is which piece you slot in to assemble it. Same promise either way. Domains and capabilities are fixed; capabilities carry levels. Nothing else below is its own list.

Capability assembled at a level

Capability Model →

Two questions, not one

A seat is set by two questions that do different jobs. How much rides on this sets the level. How much of it there is sets the count. Neither answers the other.

Level is depth of judgment, fixed by collapse risk. Count is volume, fixed by how much of the work there is. A bigger project does not raise the level — it raises the count at whatever level the risk already fixed. This is the answer to whether scale changes the level: it doesn't. Scale is a count question; level is a risk question. They're orthogonal.

L3×1, L1×5, and L2×3 are all coherent seats — one deep expert on the thing that can't fail, many hands on routine surface, or moderate stakes with more of it than one seat can carry.

Surface area

Count comes from surface area — how much of a capability-at-level the work demands, divided by how much one seat can hold.

Surface area is the number of independently attention-demanding units at a capability×level — units that can't share one operator's attention without one of them degrading. It's a concurrency measure, set by the timeline: two things on separate critical paths are two units; the same work done serially is fewer.

What one seat holds depends on the level and on who's in it. Nominal capacity falls as the level rises — higher stakes tax attention per unit [UNTESTED; to be calibrated from a real engagement]. And an overqualified operator covers more, up to a hard ceiling, because the work is easy for them.

One flag stays open: surface area counts cleanly in engineering (services, streams), but whether the same unit survives in the judgment-heavy domains — Framing, Proof, Commercial, Enablement, Continuity — is [UNTESTED]. Named and unresolved, not assumed closed.

Three verbs

Title, ownership, and seat are not three more lists. They are three verbs on the same capability: grouped under, keeps fit, executes.

Title is grouped under — a bundle of owned capabilities, internal shorthand for coverage. L4 Capability Ownership is keeps fit — the capability you author guardrails for, internal and permanent. Seat is executes — one capability at one level, this squad, internal and dynamic. All three are internal; none of them is what the client buys.

Roles & Titles →

A seat is runtime

A seat is a capability at a level, with a count, filled by a person or people, on this engagement. That's a runtime instance — and the count isn't a new list, it's how many times we instantiate one entry.

The count is confidence-gated, same as everything else. Before the work can prove the load, the count is assumed — a demanded ceiling estimated at intake, the least-validated moment we have, when we don't yet know what we don't know. As surface area validates during the work, a committed floor emerges.

We stand behind the floor and watch the ceiling; a surface-area update re-derives the count mid-engagement. One person can hold the seat, or several people who each clear the bar can make up the count together. Seat names churn. The capability underneath does not.

One capability, staffed one or several ways

Operating View →

What the SOW shows

Three layers, one of them hidden.

  • Outcome. What's sold and priced. "We'll build the integration hub."
  • Capabilities at levels, with counts. The price justification, surfaced if the client asks how the number was reached — "core systems engineering at L2, ×3." The count lives here because load drives price. But it's the demanded shape, a capability at a level with a quantity, not named bodies.
  • Seats. How we assemble the count — three L2s, or one L3 absorbing it. Internal. Never on the SOW.

The title never appears on the SOW. The level carries the seniority a title used to imply — and carries it precisely.

"Capabilities at levels, with counts" is the same person-agnostic shape we can put in front of a client; the moment it resolves to named people, it drops below the line.

Rule of thumb: the client buys an outcome, the firm fulfils it with people in seats, and the shorthand we use between the two stays on our side of the table.

Roles & Titles →