Roles & Titles

Capabilities are the contract. Seats are the fulfillment. Titles are internal coverage.

The SOW sells an outcome, priced from the capabilities-at-levels underneath it, never headcount and never a title. A title is internal shorthand for a kind of practitioner: the person who typically owns a coherent bundle of capabilities. It groups coverage; it is not a thing a client buys.

Traditional to AI-Native

14 traditional titles compress into 5. Language and platform distinctions collapse in AI-native delivery; what matters is the capability, not the stack.

Traditional title	AI-Native title
Business Analyst	Product Architect
Product Strategy	Product Architect
Design	Product Architect
.NET Fullstack	Forward Deployed Engineer
Java Fullstack	Forward Deployed Engineer
Mobile	Forward Deployed Engineer
Web	Forward Deployed Engineer
AI & ML	Applied AI Engineer
Cloud Engineering	Applied AI Engineer
Data Engineering	Applied AI Engineer
Quality Engineering	Eval & Quality Engineer
Quality Automation Engineering	Eval & Quality Engineer
Project & Program Management	Engagement Lead

Solution Consultants and Delivery Partners remain as pre-engagement commercial roles, working alongside the Product Architect on the commercial envelope.

* Data Visualization is not yet mapped. Its current project footprint and capability alignment need to be assessed before assigning it to a title.

The 5 titles

Each title is a kind of practitioner, defined by a bundle of capabilities one person can own together. Two people with the same title are not interchangeable. Every capability sits under exactly one title.

Product Architect

Someone has to own the question "are we solving the right problem?" and the interface the answer takes. In AI-native delivery, this is the person who runs Stage 0 and Stage 1, turning fuzzy client intent into tagged assumptions that survive the Evidence Gate, and who owns the product surface users see and touch.

Replaces: Business Analyst, Product Strategy, Design

Typically owns

Framing (whole domain), Product & interface building, Confidence-based estimation, Pricing under uncertainty

Also executes by default

Demonstration & evidence review @ L2
Signal design @ L1
Transparent delivery @ L1
Outcome definition @ L1
Stakeholder alignment @ L1

Forward Deployed Engineer

Language and platform distinctions collapse in AI-native delivery because Claude Code is the primary interface to the codebase. What matters is whether you can build a slice that tests an assumption, instrument it for signal, and ship it to preview.

Replaces: .NET Fullstack, Java Fullstack, Mobile, Web

Typically owns

Core systems engineering, Production hardening, Durable delivery, Slice building, Acceptance proving, Demonstration & evidence review, Transparent delivery

Also executes by default

AI systems engineering @ L1
Product & interface building @ L1
Signal design @ L2
Validation & testing @ L2
Problem framing @ L1

Seat rule: these defaults cover both sides of a segregated pair (Product & interface building and Validation & testing). One person cannot hold both on the same engagement, so the defaults need resolving.

Applied AI Engineer

Someone has to own the infrastructure that makes AI-native delivery possible. This is the person who builds the MCP integrations, the eval harnesses, the deploy hooks, and the agent governance layer.

Replaces: AI & ML, Cloud Engineering, Data Engineering

Typically owns

AI systems engineering, Autonomous-system governance

Also executes by default

Core systems engineering @ L2
Production hardening @ L2
Validation & testing @ L2
Signal design @ L1

Eval & Quality Engineer

Non-deterministic systems need a fundamentally different kind of testing. This person does not write unit tests for deterministic code; they design eval benchmarks for probabilistic behavior, hallucination detection, safety alignment scoring, and the lock-tests.sh hooks that prevent agents from weakening assertions.

Replaces: Quality Engineering, Quality Automation Engineering

Typically owns

Validation & testing, Signal design

Also executes by default

Acceptance proving @ L2
Demonstration & evidence review @ L1
Core systems engineering @ L1

Engagement Lead

Someone has to govern the pipeline itself: stage gates, autonomy tiers at deploy, the change-response doctrine, commercial alignment, and evidence thresholds. This is the person who makes sure speed does not outrun governance. Also owns the handoff: making sure the client org can absorb and run what we build.

Replaces: Project & Program Management

Typically owns

Enablement (whole domain), Client operating-model design, Transition & warranty design, Commercial scoping & envelope shaping

Also executes by default

Stakeholder alignment @ L2
Transparent delivery @ L2

Sensible defaults by stage

Each column is the person holding that title. The matrix shows where they typically lead, contribute, or are informed, derived from which capabilities are primary at each stage. These are sensible defaults, not fixed assignments. On a given engagement, the named L4 owner of a capability that fires in a stage can override the default for that capability.

R: typically drives and produces. A: typically signs off. C: typically contributes context. I: typically informed on output.

Stage	Product Architect	Forward Deployed Engineer	Applied AI Engineer	Eval & Quality Engineer	Engagement Lead
0 · Intent Framing	A	C	C	I	C
1 · Evidence Gate	R	R	C	C	C
2 · Design	R	A	C	I	I
3 · Build	C	A	R	I	C
4 · Test	I	C	C	A	I
5 · Deploy	I	C	R	C	A
6 · Maintain	C	R	R	C	I

What the SOW shows

Three layers, one of them hidden.

1 · Outcome

What's sold and priced. "We'll build the integration hub."

2 · 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.

Invokes: Commercial scoping & envelope shaping, Pricing under uncertainty

3 · Seats

How we assemble the count — three L2s, or one L3 absorbing it. Internal. Never on the SOW.

This three-layer structure is non-negotiable. The SOW sells an outcome, priced from capabilities at levels. Titles, seats, and named people never appear. The level carries the seniority a title used to imply, and carries it precisely. Nothing below the capabilities-at-levels line is visible to the client unless they ask how the number was reached.

"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.

How seats get filled

Seats are read off the contract as capabilities at levels. How many seats of one capability a level needs depends on how big the work is, which is counted in scope units. Build and QA are segregated: one person cannot hold Product & interface building and Validation & testing on the same engagement, whatever the scheduling says.

Scope & Leverage →

Once the SOW is signed, its capabilities-at-levels are the seat list — seats are read off the contract, not designed.

1 · Qualification

Who can fill it. Each capability's L4 certifies who can execute it at each level. The qualified pool is the L4, plus anyone they've certified to that level.

2 · Assignment

Who does. A resourcing function assigns from the qualified pool by availability, continuity, development, and fit.

L4 qualifies; resourcing assigns — kept apart so logistics can't quietly lower a seat's level.

Recorded in two places, neither on the SOW: capability profiles (firm-level — person, capability, certified level) and engagement staffing (per-engagement, internal, changeable).

Key definitions

Level

How deeply, per capability.

L1 guided, L2 solo, L3 sets the standard, L4 owns the capability. Per-capability, not per-person — the same person can be L3 in one capability and L1 in another they're growing into. A capability at a level is what sets the price (e.g. "Framing · L3"). The level is the seniority signal the SOW carries — what a title used to imply, stated precisely.

Not

Seniority. That is the consultant band.
A dial. A level is depth of judgment; a dial is how hot the capability is running right now.
A property of a domain, a skill, a title, or a person.

Used by rules

Scope Units, Required level, Effective capacity, Caliber eligibility

Project seat

What you're doing now.

The role you occupy on a specific squad for a specific slice of work. Seats shift within an engagement as the work changes; the same person may sit Slice Builder one sprint and Governance Lead the next. Because seats are activated by what the work needs, their catalog lives in the operating view, not here.

Not

A second list to maintain alongside capabilities.
A title. A title is durable ownership of a capability bundle; a seat is one capability at one level on one engagement. Both are internal.
A line on a SOW. The contract buys the outcome, priced from capabilities-at-levels. Seats never appear.
A person. One person can staff a seat, or several people together can make up the capability at the level needed.

Used by rules

Seat count, Build and QA segregation, Caliber eligibility

Consultant band

Who you are at the firm.

The whole-person HR identity — Senior Consultant, Principal Consultant. This is where career seniority lives: comp, progression band, the title on an offer letter. It correlates with level (a Principal is typically L3 in their owned capabilities) but never collapses into it — the band is per-person, the level is per-capability. Seniority didn't disappear from the model; it moved here, out of the client-facing layer, so what a client buys and how senior you are can be stated separately.

Not

A level. The band is per person; the level is per capability.
A title. A title groups owned capabilities; neither is what a client buys, and seniority lives here rather than on either.
A capability. Nothing is promised to a client by a band.