The value of a forward-deployed engineer is not a property of the engineer. It is a before-and-after inside one operation, under that operation's constraints, observed for long enough to mean something. That is why the question of what an FDE is worth cannot be separated from the question of which field they work in. General capability makes the work possible. Specialization is where the result becomes measurable.
This note describes what a value claim has to contain to be inspectable, how five fields change what "good" means, and how an engineer should specialize so that the record they build is the record a buyer can read. It follows the earlier note on domain expertise as part of the stack and narrows it to value.
A value claim is a comparison, not an adjective
The benchmark's outcome-linkage study protocol already sets the standard: an outcome needs a defined baseline, an intervention with a known boundary, an observation window, and an attribution caveat that names what else changed. Vendor-reported results are useful signals and are treated as such. Cognizant's reported deployment outcomes in contract intelligence and underwriting research, for example, show where value is expressed, which is inside a specific workflow, but they are not independent impact studies and this note does not read them as one.
The practical test for any forward-deployed value claim is four questions. What was the number before. What exactly was deployed, and where did its authority stop. Over what period was the new number observed. What else moved in that period. A claim that cannot answer all four is an anecdote, however sincere.
Five fields, five definitions of good
The reviewed records already specialize the role by field, and each field changes the constraints that define competent work.
| Field | What the record shows | What changes the definition of good | What the FDE's evidence must carry |
|---|---|---|---|
| Healthcare, payer and provider | OpenAI's healthcare FDE specification names EHR integration, HL7 and FHIR, protected-data safeguards, auditability, and human review | A determination or a clinical action carries a regulatory clock and a reconstruction obligation years later | An evaluation set from real cases, a control boundary a compliance officer signed, and a record that can be replayed |
| Legal | OpenAI's legal FDE specification | Provenance and privilege: the source of a clause matters as much as its summary, and the wrong disclosure is unrecoverable | Citation-carrying outputs, matter-scoped access, and a review path that shows which human accepted what |
| Financial services and insurance | Cognizant's insurance underwriting work; Wipro's mortgage sector work in its Applied AI Center of Excellence | Model risk management and decision explainability: a recommendation has to be defensible to a second line and a regulator | Decision rationale in a fixed schema, drift monitoring, and separation of duties when an agent participated |
| Manufacturing and semiconductor | OpenAI's semiconductor deployment roles noted in the field intelligence brief; Wipro's manufacturing and airline sector work | Physical consequence and safety: a wrong instruction reaches a line, a plant, or an aircraft | Simulation or shadow evidence before any live actuation, and an explicit human gate at the point of physical effect |
| Public sector | Palantir's originating government work, described by The Pragmatic Engineer | Accountability to a statute and to the public record, with procurement and data-sovereignty limits on what may run where | Deployment inside the agency boundary, data residency evidence, and decisions that survive a records request |
The pattern across the table is the same. The field does not add a vocabulary quiz. It adds a constraint that changes the architecture, the evaluation, the release gate, and the definition of a safe outcome. An engineer who has done the work in one field carries evidence that looks different from an engineer who has done it in another, and the benchmark's separately governed domain packs exist to keep that difference visible instead of averaging it away.
How an engineer should specialize
Donner's explainer makes a practical recommendation that the record supports: learn a business area, maybe two, before the job, to demonstrate that you can apply AI to a domain. The Salesforce onboarding account shows the other route, in which people arrive with the domain from professional services or customer success and acquire the engineering.
Either way, the sequence that produces a readable record is the same.
- Build the general core first. Software engineering and AI engineering are field-independent and are the floor for every variant.
- Go deep in one field, not broad in four. Learn its unit of work, its clocks, its records, and the person who signs. The healthcare specification is a good model of what depth means: it names systems, standards, safeguards, and acceptance thresholds, not enthusiasm.
- Build the field's evidence, not generic evidence. An evaluation set drawn from that field's cases, including the ones the system must refuse. The control boundary that field's regulator expects. An adoption path through that field's actual roles.
- Add a second field by adjacency. Payer operations to provider operations; insurance to banking; manufacturing to logistics. Adjacent fields share records and constraints, so the second pack is cheaper than the first and the evidence compounds.
- Carry the field forward. Domain knowledge, once demonstrated in production, is portable across employers and variants. It is the layer that keeps appreciating.
LockedIn Benchmark implication
Value is an outcome claim and is treated as one. It is linked to a production artifact, recorded with its baseline, window, and attribution caveat, and published with its uncertainty. It lives inside a domain pack, never in a cross-field composite, because a result in claims operations and a result on a manufacturing line are not on the same scale. And it is separate from capability: a practitioner can be production proven on the evidence ladder without any outcome yet being attributable, and the record should say so rather than imply otherwise.
The benchmark's answer to "what is a forward-deployed engineer really worth" is therefore not a number. It is a record structured so that the number, when one exists, can be read with its context attached.
Where the family speaks in unison
The firm's field guide tells an engineer to learn a business area before the seat and to build the thing that annoys them like it has to survive a security review. The training platform rehearses that discipline against a live-shaped operation and a published field standard. This benchmark records what the field then proves. Three properties, one company, one definition of value: a before-and-after inside a real operation, with its evidence attached.
Limitations
This note reads a purposive set of first-party role specifications, sector announcements, one vendor-reported onboarding account, and one practitioner explainer. Sector examples are vendor-reported and are not independent impact studies. No prevalence, workforce-size, compensation, or predictive-validity claim is supported or asserted. The five fields are illustrative, not exhaustive; domain packs and their weights are proposals to be tested through the registered research program, not validated instruments.