Commercial
Shaping the deal and the market story so the engagement is priced honestly against confidence and positioned to win.
Domains are types of work. They do not change and they do not have levels. Capabilities are the named outcomes we promise inside a domain.
How a capability is executed is a separate scale. L1 Guided Execution, L2 Practitioner, L3 Advanced Lead, and L4 Capability Ownership. That scale lives with capabilities, not with domains.
A second scale says how big the work is: how many independent instances of a capability an engagement needs. That is scope, and it is also set per capability.
Shaping the deal and the market story so the engagement is priced honestly against confidence and positioned to win.
Understanding the problem well enough to make the go, redirect, or stop call.
Making the thing real — from the smallest proof to durable, ownable production.
Making it demonstrably true that the work does what it was supposed to — confidence from what the client can see, not what they're told.
Making the client's people more capable than they were.
Making the system more capable than it was.
| Level | Description |
|---|---|
| L1 Guided Execution | Operates safely using defined guardrails and templates. Non-specialists can execute without inventing method. |
| L2 Practitioner | Executes end-to-end independently and handles edge cases without escalating the method. |
| L3 Advanced Lead | Builds guardrails, handles extreme complexity, and defines the standards others execute against. |
| L4 Capability Ownership | Agency-wide accountability for capability maturity, L1 guardrail creation, and quality. Distinct from L3 execution. An L4 is responsible for the capability existing and remaining fit for use. |
Frames the deal as an envelope you can commit to: clear boundaries, room for what discovery turns up, so scope stops being a running fight.
A commercial envelope with fixed boundaries and batched trade-off checkpoints instead of line-item disputes.
Define scope by outcomes + non-negotiable boundaries, not a feature list; build an explicit emergence allowance into the budget; set checkpoint gates where trade-offs are decided together.
No L1Deciding which boundaries are truly non-negotiable and how much emergence to fund is a commercial judgment a template can frame but not make.
Unit. One deal envelope, covering the whole engagement.
Does not grow with scope: one per engagement regardless of size.
Leverage by level.
1 unit
1 unit
1 unit
1 unit
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. Is there more than one deal envelope to shape in this engagement, such as separate agreements or entities?
Concurrency. Do the envelopes need shaping together or in turn? With one envelope this does not matter.
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. One envelope wraps the whole engagement, so there is normally one unit and the leverage numbers are 1 throughout. Correct the unit or the numbers when a real project shows they are wrong.
Open question: Untested hypothesis: one envelope per engagement regardless of internal system count. The deal wraps the whole thing, not a subsystem. Needs confirmation, not assumed.
An estimate that says plainly what we're sure about and what's still a bet, so you're never paying for false precision.
An estimate that separates proven cost from high-uncertainty bets, with confidence shown per line.
Pull analog baselines from delivery history; tag each line proven / bounded / bet; show confidence bands, never a blended number.
No L1Tagging a line proven / bounded / bet, and setting the band width, is a judgment about how much uncertainty the evidence actually leaves — structured by a guardrail, decided by a person.
Unit. One independently estimable workstream, each with its own uncertainty profile.
Leverage by level.
1 unit
2 units
3 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many workstreams in this engagement need their own estimate with its own stated confidence?
Concurrency. Can the estimates be produced one after another, or must they be ready together for a decision?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Estimating follows a method that a person repeats across workstreams, but the senior ceiling is judgment about unknowns, so it levels off at L3. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
A price that stays fair when the full shape of the work can't be known yet: fixed where it's proven, staged where it isn't.
A staged price — fixed rates for known work, investment staged as clarity grows.
Stage price across confidence gates; itemize the emergence allowance in the agreement; tie phases to signal thresholds from delivery.
No L1What to fix, what to stage, and how to price the emergence allowance is a risk call between firm and client, not a template output.
Unit. One commercial arrangement to price: a SOW or phase.
Does not grow with scope: one per engagement regardless of size.
Leverage by level.
1 unit
1 unit
1 unit
1 unit
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. How many separate commercial arrangements or phases need their own price structure?
Concurrency. Must the arrangements be priced together or one after another? With one arrangement this does not matter.
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Pricing is normally one arrangement per engagement, so the unit is 1 and leverage is 1 throughout. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
Finds the walls that can't move (legal, technical, contractual) before the plan is built, so they're inputs and not late surprises.
A constraint map the plan is built against, not discovered late.
Interview across four lanes (legal, regulatory, technical, operational) on a fixed script; sort constraint vs preference on the rubric; publish the set before sequencing.
Four-lane interview scriptconstraint-vs-preference rubricconstraint-set record templateL1 runs the script and populates the rubric; arbitrating ambiguous constraints is L2.
Unit. One constraint domain (legal, technical, contractual) that needs its own investigation.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate constraint domains need to be investigated before the plan is built?
Concurrency. Can the domains be investigated one after another, or must all constraints be known together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Each domain needs its own reading, and a lead can hold a few at once. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
A clear call on whether the thing is worth building and what to do first, made in the room with the reasoning behind it.
A proceed / redirect / stop decision and a defensible "what first."
Score candidates against the problem sentence, constraint set, and risk shortlist; sequence only what survives; record the call; treat stop as a valid outcome.
No L1The proceed / redirect / stop call is the judgment; a guardrail can assemble the inputs but can't own the decision or its consequences.
Unit. One direction being qualified: a single go, redirect or stop call.
Leverage by level.
1 unit
1 unit
1 unit
2 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate directions need a go, redirect or stop call in this engagement?
Concurrency. Can the calls be made one after another, or must they be made together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. A call carries the reasoning behind it, so it is hard to spread across directions, and only an L4 owner spans two. Correct the unit or the numbers when a real project shows they are wrong.
Agreement on what winning actually looks like, in numbers, before anyone designs or builds.
Up to three agreed, measurable targets locked before work starts.
Translate the lever into ≤3 measurable targets in-session; run a kill-check that each is measurable; hand instrumentation to Signal design.
Target template (lever → ≤3 targets)measurement kill-checkSignal design handoff stubL1 runs the template; judging whether a complex target passes the kill-check is L2.
Unit. One outcome with its own success numbers, agreed with its sponsor.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate outcomes need to be defined in numbers before design starts?
Concurrency. Can outcomes be defined one after another, or must they be agreed together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Defining an outcome is a repeatable conversation, so a lead can run a few. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
Cuts through the ask to the one thing the work really has to solve — a single sentence everyone can line up behind.
A single-sentence problem statement that aligns decisions across teams.
Run a framing session with sponsor + a blocker; ladder symptom → lever live; draft, swap-test, and lock the sentence in the room.
Problem-sentence templatesymptom→lever laddering prompt packswap-test checklistone worked exampleL1 facilitates from the prompt pack and drafts the sentence; resolving a sentence that fails the swap test is L2.
Unit. One distinct problem statement that the work has to solve.
Leverage by level.
1 unit
1 unit
2 units
2 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many distinct problems does this engagement need a single framing sentence for?
Concurrency. Can the problems be framed one after another, or must they be framed together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Most engagements have one problem, so the numbers matter only on large programs, where a lead can take a second. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
Separates the few risks that could sink the whole thing from the noise, so attention goes where it actually matters.
A shortlist of collapse-level risks; the rest stays off the steering agenda.
Run an assumption dump + failure premortem; sort by collapse potential (impact × irreversibility); keep only what changes the proceed call or first slice.
Dump + premortem prompt packcollapse-potential sort rubricrisk-shortlist templateL1 facilitates the dump and applies the score; judging irreversibility ratings is L2.
Unit. One major workstream with its own set of collapse-level risks.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many major workstreams in this engagement each carry their own collapse-level risks?
Concurrency. Can the risks be framed workstream by workstream, or must the whole picture be shortlisted at once?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Shortlisting risks for a workstream is a method a lead repeats across a few workstreams. Correct the unit or the numbers when a real project shows they are wrong.
Open question: Untested hypothesis: on very large programs this may scale per major workstream (each with its own collapse-level risk set) rather than one shortlist for the whole engagement.
None assessed.
Gets the people who could stop the work to agree, up front, on what good looks like — in language that outlasts us.
A shared decision standard locked in executive language that holds across org shifts.
Map who can block or bless; put the lever in front of them in a working session; secure sign-off on a standard that holds without us.
No L1Reading who can actually kill the work and moving them to a shared standard is live political judgment; the kill-map is prep, the room is not L1.
Unit. One stakeholder group that could stop the work and must agree on what good looks like.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. How many separate stakeholder groups could stop the work and need to be aligned up front?
Concurrency. Must alignment with the groups happen at the same time, or in turn?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Alignment is relational, so a lead can carry a few groups, and it must land before the work starts. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
AI that actually works on your real problem and your real data, not a demo that falls over in production.
A production-ready AI system grounded in your data, with accuracy and limits you can verify.
Stand up an eval harness with golden sets before architecture; ingest domain data into model-agnostic context pipelines; gate deploy on eval scores, not demo quality.
Eval-harness scaffoldcorpus-ingestion checklistreliability-benchmark templateL1 runs scaffolds and eval suites; modifying context pipelines is L2.
Builds and modifies the context pipelines; tunes reliability against the eval bar independently.
Sets the eval methodology and reliability architecture others build to; owns what "trustworthy enough to ship" means.
Unit. One independent model or pipeline domain requiring its own evaluation harness and reliability ownership.
Leverage by level.
1 unit
1 unit
2 units
2 units
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. How many independent model or pipeline domains in this engagement each require their own AI Systems Engineering ownership, separate from the others?
Concurrency. Do these instances need simultaneous attention, or can they be sequenced?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Model and pipeline reliability work saturates sooner than systems architecture, because each domain needs its own evaluation harness kept alive, so L4 spans no further than L3 plus a little. Correct the unit or the numbers when a real project shows they are wrong.
Open question: One manual run on a finished project needed this capability's scope units corrected. "Independent" may need reading against the scale of the engagement, and the scope units may need re-deriving when an engagement's shape changes. See `instances` in `capacity-model.yaml`. Not yet a rule.
None assessed.
The system underneath, built to fit your stack and hold together — something your own team can extend, not just inherit.
A clean architecture matched to your stack that internal teams can extend.
Choose proven patterns matched to the constraint set; build clean seams across services, data, and APIs; document interfaces well enough for a third-party dev.
Approved architecture-pattern catalogueseam-documentation templateconstraint-citation formatL1 implements established patterns; architecting custom seams is L2.
Unit. One independent system, subsystem, or integration domain in the engagement's architecture that requires its own end-to-end architectural judgment. For example, a legacy core, an integration layer, and a new AI layer each count as one scope unit if they can be worked and reasoned about independently of the others.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. How many independent systems, subsystems, or integration domains in this engagement each require their own Core Systems Engineering judgment, separate from the others?
Concurrency. Do these instances need architectural attention at the same time, or could they be addressed one after another without delaying the engagement?
Leverage numbers are a starting default, not derived from delivery history. First thing to check against real engagements before trusting the instance math: whether L1 and L2 leverage of 1 (zero spanning capacity) actually holds, or whether a strong L2 can run two low-complexity systems in parallel. Concurrency reflects the AI modernization worked example (legacy core, integration layer and AI layer needing simultaneous architectural ownership). It has not been checked against an engagement where concurrency turned out to be false.
Open question: One manual run on a finished project needed this capability's scope units corrected. "Independent" may need reading against the scale of the engagement, and the scope units may need re-deriving when an engagement's shape changes. See `instances` in `capacity-model.yaml`. Not yet a rule.
None assessed.
A codebase and release path clean enough that your team keeps shipping long after we've gone.
An automated release pipeline and readable repo ready for handoff.
Configure CI/CD in the client's infrastructure; hold the codebase to readability and modular-interface standards; test against the "next change without the original author" bar.
Release runbook templatecodebase-readability checklistCI/CD scaffoldL1 runs CI/CD scaffolds and formatting rules; changing core pipeline logic is L2.
Unit. One codebase with its own release path: a repository and the pipeline that ships it.
Leverage by level.
1 unit
2 units
3 units
4 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate codebases or release paths in this engagement need to be left in a state the client's team can keep shipping from?
Concurrency. Can these codebases be cleaned up one after another, or must they all be ready at the same time?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Scaffolds and release hygiene repeat once a pattern is set, so a person spans more codebases as the level rises. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
The part users actually see and touch, built for real: a working product, not a prototype.
A working, usable product shipped to live preview, backed by a reusable component library.
Assemble from design tokens + a Figma/code component library; ship increments to preview; check token use and accessibility on every build.
Component token sheetpage assembly template (Figma + code scaffold)in-token component-generation prompt packL1 assembles from tokenized components; defining new tokens or state hooks is L2.
Owns state and edge-case interface behaviour without escalating the method.
Sets the tokens, the component contracts, and the motion language others build to.
Unit. One independent product surface (a distinct app or portal).
Leverage by level.
1 unit
1 unit
2 units
2 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many independent product surfaces does this engagement require?
Concurrency. Must these surfaces be built in parallel, or can they be built one after another without delaying the engagement?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Building a surface is hands-on, so even a lead spans a second surface at most before the work stops being hands-on. Correct the unit or the numbers when a real project shows they are wrong.
Cannot share a seat with Validation & testing. Build and QA are segregated. One person cannot hold an instance of each on the same engagement, regardless of scheduling or allocation. This is a policy gate, not an availability question.
Makes sure it holds up under real traffic, real users, and real pressure, not just in the demo.
A resilient, observable system verified under load and real failure.
Run security, load, and observability against the constraint set + risk shortlist; wire monitoring/tracing into the deploy; map each fix to a named risk.
Hardening checklist (scoped from constraints + risks)observability wiring scaffoldrisk-remediation report templateL1 deploys scaffolds and runs hardening scripts; diagnosing complex load failures is L2.
Unit. One production-bound service or workload that needs its own load and failure analysis.
Leverage by level.
1 unit
2 units
3 units
4 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate services or workloads will carry real traffic and need hardening before go-live?
Concurrency. Can the services be hardened one after another, or must they all go live together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Hardening follows a checklist that a senior person can run across several services, so spans grow with the level. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
The smallest real, working thing that answers a live question — proof over promises, early and cheap.
A running artifact plus signal, delivered early.
Frame one assumption per slice; build only what tests it in Cursor / Claude Code, deployed to a preview; log the decision (continue / pivot / stop) against the signal.
Slice charter (one assumption + success/fail + kill date)preview deploy scaffoldone-assumption gateL1 wires the scaffold for a defined slice; refactoring logic across slices is L2.
Unit. One slice: the smallest real, working thing that answers one live question.
Leverage by level.
1 unit
1 unit
2 units
2 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate live questions does this engagement need a working slice for?
Concurrency. Must the slices be built at the same time, or can they take turns without delaying the answer?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Each slice is hands-on and disposable, so a lead covers a second one at most. Correct the unit or the numbers when a real project shows they are wrong.
Open question: Slices are meant to be small and disposable. Worth checking whether scope units apply at all here, or whether slice count is governed by assumption count instead, a different axis entirely (see the Evidence Work doctrine).
None assessed.
Clear, evidence-backed sign-off that the work does what was agreed, not a subjective "looks done to me."
Sign-off backed by pass/fail proof against criteria set up front.
Validate against the outcome targets and eval bar; record pass/fail per criterion; require verification before "complete."
Acceptance checklist (wired to agreed criteria)pass/fail record templatecriteria-verification guideL1 runs the checklist against defined cases; ruling on edge-case exceptions is L2.
Unit. One acceptance gate: a deliverable that needs its own sign-off evidence.
Leverage by level.
1 unit
2 units
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate deliverables need their own evidence-backed sign-off?
Concurrency. Can the gates be proven one after another, or must all sign-offs land together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Gathering sign-off evidence follows a pattern a practitioner repeats, and judgment about sufficiency levels off at L3. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
Progress you can see running, with the numbers behind it — not a status deck that tells you it's fine.
Interactive review of running software alongside its live signal.
Demo only from live preview; walk the signal alongside the functionality; capture decisions in the session.
Evidence-review run sheetlive-preview default dashboardfeedback-capture logL1 runs the walk-through from the run sheet; handling off-script technical questions is L2.
Unit. One review cadence for the engagement.
Does not grow with scope: one per engagement regardless of size.
Leverage by level.
1 unit
1 unit
1 unit
1 unit
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. Does the engagement need more than one demonstration and review cadence?
Concurrency. Do the cadences run together or in turn? With one cadence this does not matter.
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. One cadence covers the whole engagement and is not multiplied by the number of subsystems, so the unit is 1. Correct the unit or the numbers when a real project shows they are wrong.
Open question: Untested hypothesis: one cadence per engagement, not multiplied by subsystem count.
None assessed.
Deciding up front what would actually count as proof, and building in the means to measure it.
The measures and thresholds that make results evidence, set before build.
Define metric, source, and threshold before slice build; embed measurement hooks in components/services; record the bar so results can't be re-litigated.
Signal spec template (measure / source / success / failure / threshold)instrumentation starter kitsignal-vs-demo gateL1 embeds standard hooks from the kit; defining custom metric formulas is L2.
Unit. One assumption or claim whose proof signal must be defined.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate claims need a signal defined for what would count as proof?
Concurrency. Can the signals be designed one after another, or must they be ready together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Designing a signal is a method a lead repeats across claims. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
You can watch the work being true as it's built, any time, instead of waiting for a weekly report.
Continuous access to live preview and status, not status packs.
Deploy a preview per active branch; expose live health/progress to stakeholders; replace at least one status meeting with the live link.
Preview-deploy scaffoldlive status-view template"no status pack where a live view exists" ruleL1 configures preview links and status views; fixing a broken delivery channel is L2.
Unit. One workstream whose progress is made continuously visible to the client.
Leverage by level.
1 unit
2 units
2 units
3 units
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. How many workstreams need their progress visible to the client at any time?
Concurrency. Must every workstream be visible at once, or can visibility be added one workstream at a time?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Once the visibility pattern exists, a practitioner can keep two workstreams visible, and the pattern is the same for a lead. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
Puts the work through its paces, including the ugly edge cases a happy-path demo never hits, and shows what held and what didn't.
Coverage that proves it holds, with performance boundaries and known failure modes named.
Run automated suites + generated edge cases; for AI features, run eval suites against the signal bar; archive a summary naming passes and misses.
Test-plan templateautomated eval-suite scaffoldfailure-summary format (must name misses)L1 triggers runs and fills the failure report; authoring custom generative suites is L2.
Unit. One system or feature area under test, needing its own test plan and edge-case coverage.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate systems or feature areas need their own test plan and edge-case coverage?
Concurrency. Can the areas be tested one after another, or must they be tested together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Test plans for separate areas are mostly independent, and a lead can oversee a second and third. Correct the unit or the numbers when a real project shows they are wrong.
Open question: One manual run on a finished project needed this capability's scope units corrected. "Independent" may need reading against the scale of the engagement, and the scope units may need re-deriving when an engagement's shape changes. See `instances` in `capacity-model.yaml`. Not yet a rule.
Cannot share a seat with Product & interface building. Build and QA are segregated. One person cannot hold an instance of each on the same engagement, regardless of scheduling or allocation. This is a policy gate, not an availability question.
None assessed.
Your people in the room for the hard calls, so they can run and extend the system themselves — not just own a repo they didn't help shape.
A team that can maintain and extend the system on its own.
Pair client people on the calls that set the method; transfer the reasoning, not just the docs; record decision rationale for later reference.
No L1You have to be in the hard calls to transfer the judgment behind them; there's no guardrailed way to teach judgment you don't yet hold.
Unit. One client team receiving transfer: the people who will run and extend the system.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many client teams need to be brought into the hard calls so they can run the system themselves?
Concurrency. Can the teams be brought in one after another, or must they be in the room together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Transfer needs people in the room, so spans stay small until a lead can set the pattern others run. Correct the unit or the numbers when a real project shows they are wrong.
Open question: The unit here is plausibly the audience or team receiving transfer, not a system count. A different unit type again.
None assessed.
Getting the wider organization to actually trust and use what was built, so it gets used instead of shelved.
Measurable adoption across the people who didn't build it.
Map affected users outside the build team; design adoption paths against their incentives and fears; track usage and treat low usage as a signal to act on.
No L1Designing an adoption path against a specific org's incentives and fears is bespoke change judgment; usage can be instrumented, the design can't be templated.
Unit. One audience or user group that must come to trust and use what was built.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate audiences or user groups need to adopt what was built?
Concurrency. Can adoption work go audience by audience, or must it reach them all at once?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. An adoption plan for one group can be reused for the next, so a lead covers a few groups. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
Leaves your people genuinely better at their craft, not just trained on this one build.
Higher capability across your engineering and product people.
Coach 1:1 against live problems in their domain; assess against a craft rubric; leave a per-person growth roadmap.
No L1Growing a person's craft against their live problems is individual judgment; a rubric can assess, the coaching itself isn't guardrail-executable.
Unit. One coaching cohort: a small group of people being developed together.
Leverage by level.
1 unit
1 unit
1 unit
2 units
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. How many separate groups of people need coaching in this engagement?
Concurrency. Does the coaching run alongside delivery for every cohort at once, or in turn?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Coaching is high-touch and cannot be spread thin, so only an L4 owner covers a second cohort. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
The controls, review, and stop-rules that let you run an AI system safely once it's yours — not just own something you can't supervise.
Explicit kill switches, guardrails, and escalation paths for AI in production.
Define operating boundaries, drift measures, and escalation triggers post-launch; build kill rules and override paths for client operators; deliver a runbook tied to known failure modes.
Governance runbook templatekill-rule spec sheetdrift-monitoring formatL1 fills the runbook from templates; defining custom kill rules is L2.
Unit. One autonomous system, an agent or model in production, that needs its own controls, review and stop-rules.
Leverage by level.
1 unit
1 unit
2 units
2 units
Concurrency.
concurrent. All units must be active at the same time. The timeline gives no relief.
Intake questions
Units. How many autonomous systems will the client run after handover that each need their own controls and stop-rules?
Concurrency. Do all of these systems go live at the same time, or in turn?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Each live system needs its own supervision design, so spans stay small even for a lead. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
A clear picture of who owns what and how decisions get made once we're gone: a machine your team knows how to run.
An operating model defining responsibilities, ownership, and cadences.
Define post-launch roles, cadences, and decision rights; write it in the client's own org language; map when to execute, escalate, or change the system.
No L1Deciding who owns what and which calls can't wait is organizational-design judgment specific to each client; a template captures the format, not the decision.
Unit. One client team or function whose ownership and decision rights must be mapped.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many client teams or functions need their ownership and decision rights mapped?
Concurrency. Can the teams be mapped one after another, or must the whole picture land together?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Mapping a team is conversational and a lead can hold a few teams in their head at once. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
No surprises after go-live: exactly what we still hold, what you hold, and when it changes hands.
A handoff schedule with dates, support coverage, and ownership transfers.
Draft one agreement covering warranty, support, and backlog transfer; specify exact transfer dates and boundaries; run a backlog review to confirm ownership.
Transition/warranty templatebacklog-handoff formatownership-transfer checklistL1 completes the standard checklist; negotiating custom warranty terms is L2.
Unit. One handover: a system or release changing hands, with its own warranty terms.
Leverage by level.
1 unit
1 unit
2 units
3 units
Concurrency.
sequenceable. Units can take turns. The same people can cover more of them, and the calendar gets longer.
Intake questions
Units. How many separate systems or releases will change hands, each needing its own warranty terms?
Concurrency. Do the handovers happen at the same time, or one after another?
Default for the pilot, reasoned from this capability's own unit and not copied from another capability. Handover terms follow a template once the first is done, so a lead can run a few in parallel. Correct the unit or the numbers when a real project shows they are wrong.
None assessed.
Level says how senior the work needs to be. Scope says how many independent instances of that capability and level the engagement needs. Without it, a one-person customization and a large modernization produce the same capability and level, and the size gets settled by asking people.
instances = ceil(scope_units / leverage[level])
A scope unit is one independent instance of the capability's work, and each capability declares what counts as one. Leverage is how many units one person at a level can responsibly span before a second instance is needed. The count itself is per engagement: it comes from answering the capability's intake question at scoping time, so it is never stored in the model. Where a capability declares leverage, it takes the place of the model's generic seat-capacity defaults for that capability.
Concurrency is a separate question: do the units have to run at the same time, or can they take turns? Concurrency does not change the instance count above; it feeds surface area and the seat count instead. Concurrent units are all active at once, so the timeline gives no relief. Sequenceable units can follow one another, so the same people cover more of them and the calendar gets longer. There is no 50/50 split between two units that run one after another, because nothing overlaps. Each unit gets the person's full time while it is active.
How much of a person one active unit takes is recorded as an allocation of 50 or 100, an assumed figure in the capacity model. It only matters when units overlap, and there is no third bucket until a real case shows these two do not fit.
26 of 26 capabilities have some of this defined so far: AI systems engineering, Core systems engineering, Durable delivery, Product & interface building, Production hardening, Slice building, Commercial scoping & envelope shaping, Confidence-based estimation, Pricing under uncertainty, Autonomous-system governance, Client operating-model design, Transition & warranty design, Capability transfer, Org change & adoption, Talent development / coaching, Constraint framing, Direction qualification, Outcome definition, Problem framing, Risk framing, Stakeholder alignment, Acceptance proving, Demonstration & evidence review, Signal design, Transparent delivery, Validation & testing. Leverage by level is set for 26 and concurrency for 26. The figures are [ASSUMED]: starting defaults, not drawn from delivery. Every capability shows its own gaps on its card. Different domains plausibly count different things (a system, a product surface, an audience), so none is filled in by copying another.
| Agent skill |
|---|
accessible-component-audit
Audit interface components against accessibility criteria so later screens inherit a passable baseline instead of shipping inaccessible patterns.
|
engagement-change-runner
An executable pass over the source-of-truth model that answers "a big scope shift just landed mid-delivery — now what?". Given the current engagement state and a change event, it re-reads the risk mix and the intensity dials, tests whether the change crosses the product-vision line (re-opening Direction qualification: proceed / redirect / stop), re-staffs against the bench, and produces a confidence-tiered re-estimate and the next slice to attack — every claim traced to a named element of the model. It reads the model through the capability-model MCP server rather than carrying a copy, so it cannot go stale; if the server is unavailable it stops rather than reconstructing the model from memory. It proposes; owners decide. It never silently re-scopes, re-prices, or proceeds across a product-vision change.
|
judgment-kit
Run the judgment pass before any interface work. Given a brief, a data source, or an existing workflow, refuse to produce labels, navigation, or actions until five things are named — activity, participant, decision, outcome, disclosure boundary — and emit a handoff contract of product-language responsibilities, approved states, and disclosure and action boundaries. Use before designing or generating any UI, before treating a workflow as ready to build, and before installing any generated candidate. Not a design system; it runs upstream of one.
|