F-35 Lightning IIF-35 JPO Digital Engineering
Unclassified · 2026-08-15
F-35 Lightning II
Collaboration model → Next Generation JPO

Where each artefact lives, and who is allowed to write it

The industrial structure of the F-35 enterprise, drawn as a target-state data architecture rather than an org chart: one government-held record, one governed boundary, and every partner writing into it from their own tooling.

Siemens proposed view Not JPO direction Unclassified throughout

1The premise, stated plainly

Today the authoritative engineering record of a programme like this effectively lives with the prime, and the government receives deliverables from it. That arrangement is what produces three of the JPO's four stated findings: a stove-piped process, limited visibility into assembled hardware, and dependence on industry that Title 10 pressure now works against.

The target state inverts the direction of custody without pretending the government will do the engineering. The JPO holds the record. Every partner keeps their own authoring tools, their own intellectual property and their own internal process, and writes into the government record across a boundary that is governed rather than negotiated per deliverable.

The test of an authoritative source of truth. Not whether the government can read it. Whether the government holds it, controls who writes to it, and can answer a configuration question without asking a contractor. Everything in the diagrams below is in service of that one sentence.

2Where things live

Next Generation JPO collaboration model The F-35 Joint Program Office holds the authoritative source of truth in Teamcenter. Requirements, interface control documents and configuration baselines flow down through a governed exchange boundary to the industrial partners. Verification evidence, as-built configuration and readiness flow back up through the same boundary. AFRL and the sustainment enterprise write across the same boundary rather than through a separate channel. F-35 Joint Program Office Authoritative source of truth, government held TEAMCENTER requirements · ICD registry · configuration baselines · verification record · computed readiness requirements, ICDs, configuration baselines verification evidence, as-built config, readiness GOVERNED EXCHANGE BOUNDARY ReqIF · STEP and JT · FMI and FMU · OSLC · signed ICD packages · access, export and IP control Lockheed Martin Air system integration, forward fuselage, final assembly AIR SYSTEM BASELINE INTEGRATION EVIDENCE Northrop Grumman Centre fuselage, AESA radar, distributed apertures SENSOR ICDs RF AND THERMAL EVIDENCE BAE Systems Aft fuselage, electronic warfare, fuel and inceptors EW INTERFACE MODEL STRUCTURAL EVIDENCE L3Harris Mission systems components, communications PROCESSOR ICDs FUNCTIONAL EVIDENCE Pratt & Whitney F135 propulsion, power and thermal offtake POWER AND COOLING ICD PERFORMANCE EVIDENCE GKN Fokker Wiring systems, flaperons, landing gear doors HARNESS AND PIN MAP CONTINUITY EVIDENCE AFRL and S&T Technology insertion, prototype pull-through, maturity assessment against the same record Sustainment enterprise Depots, supply chain, fielded data return against the requirement that predicted it Every party writes across the same boundary. Nothing here is a point-to-point integration negotiated between two companies.
Target state, Siemens proposed. The partners keep their own tools and their own intellectual property; what changes is who holds the record they write into, and that the interface is one governed boundary rather than a deliverable schedule per pairing.

3Who writes what, and who may change it

The diagram is only meaningful if write authority is explicit. The table is the same picture stated as permissions, which is the form a configuration control board can actually argue with.

ArtefactLives inWritten byGoverned how
System and subsystem requirementsJPO recordJPO, proposed by partnersBaseline under government configuration control; partner proposals arrive as change requests, not edits
Interface control definitionsJPO recordJointly, one owner per interfaceEvery ICD has exactly one accountable owner and both sides subscribe to change
Design and analysis modelsPartner environmentThe owning partnerStays with the partner. Only the interface view and the evidence cross the boundary
Verification evidenceJPO recordWhoever ran the verificationMust cite a re-fetchable managed artefact, or it is rejected rather than filed
As-built configurationJPO recordManufacturing and depotTraced to the as-designed baseline it was built against
Readiness and coverageJPO recordNobody. It is computedDerived from evidence. Not editable by any party, which is the point
The row that matters most is the last one. If readiness can be typed in by a human, it is a status report. If it can only be computed from evidence that cites re-fetchable artefacts, it is a measurement, and no party can improve their own score except by doing verification work.

4How the solution is architected

Next Generation JPO layered solution architecture Five layers. At the top the government authoritative source of truth in Teamcenter. Below it the governed exchange and interface control layer. Below that the partner engineering environments, each with their own PLM and EDA tooling. Below that the verification and evidence services that produce results. At the bottom the measurement and assessment layer that computes readiness. Requirements flow down the left side, evidence flows up the right side. SIEMENS PROPOSED SOLUTION ARCHITECTURE 1. Government authoritative source of truth TEAMCENTER, JPO HELD Requirements and traceability ICD registry one owner each Configuration baselines Verification record Programme plan and gates 2. Governed exchange and interface control OPEN STANDARDS ReqIF · STEP and JT · FMI and FMU · OSLC · signed ICD packages · identity, access, export control and IP redaction 3. Partner engineering environments PARTNER HELD, MIXED VENDOR Lockheed own PLM, CAD, integration lab Northrop own EDA, RF and antenna tooling BAE own EW and structures tooling L3Harris own mission systems tooling Pratt & Whitney own propulsion models GKN Fokker own harness tooling 4. Verification and evidence services FIVE INDEPENDENT TECHNIQUES Dynamic Questa, UVM Static formal, CDC, lint HW/SW co-analysis Innexis, Questa TLM Multi-mode Flotherm, HyperLynx Independent safety, security Physical test Testlab, SCADAS 5. Measurement and assessment 15288 6.3.7 AND 6.3.2 Computed readiness · coverage achieved · single-technique ceiling · gate status · abstention when the evidence is too thin to support a figure requirements and baselines flow down evidence and readiness flow up
Five layers, Siemens proposed. Layer 3 is deliberately mixed-vendor: the architecture has to work when a partner does not run Siemens tooling, or it is not an enterprise architecture.

5What each layer is actually for

Layer 1: the record

Requirements, the ICD registry, configuration baselines, the verification record and the programme plan, held by the government. This is the layer that answers a configuration question without a phone call to a contractor. Teamcenter is the product answer, deployable on premises and capable of running disconnected.

Layer 2: the boundary

The only layer everyone has to agree on, and therefore the one worth standardising hardest. Open interchange formats, an identity and access model, export control and a redaction posture so a partner can supply an interface view without surrendering the model behind it. Get this layer right and layer 3 can be as heterogeneous as the industrial base actually is.

Layer 3: partner environments

Deliberately mixed vendor. Each partner keeps their PLM, their CAD, their EDA and their internal process. The demonstration proves this case rather than assuming it: the system model is authored in a competitor's tool and the thread carries it anyway.

Layer 4: verification services

Five independent techniques, because the JPO's own analysis says one technique reaches 10 to 20 percent coverage. Multi-mode is highlighted because it is the technique that finds the failure in this demonstration and the one where a pure-EDA competitor has no comparable answer.

Layer 5: measurement

Not a dashboard. A computation over the evidence in layer 1, with a stated abstention rule. This is the layer the JPO asked for when it wrote "objective implementation readiness analysis with continuous metrics", and it only works because layers 1 and 2 made the evidence citable in the first place.

6The hard parts, named

An architecture diagram that shows only the parts that work is a sales aid. These are the places this model is genuinely difficult, and they are worth raising before the customer raises them:

  • Intellectual property across the boundary. A partner will not put its design models in a government record, and should not be asked to. The model only works if the interface view and the evidence are separable from the design that produced them, and that separation is real engineering work per interface.
  • Who owns an interface. Every ICD needs exactly one accountable owner. That is a contractual question before it is a technical one, and it is where this architecture will succeed or fail.
  • Evidence provenance across organisations. "Cite a re-fetchable artefact" is easy inside one company and hard across six, because the artefact has to remain fetchable after the programme moves on and possibly after the supplier changes.
  • Classification boundaries. Everything on this page is unclassified. A real deployment sits across multiple classification levels, and the exchange layer has to be designed for that from the start rather than retrofitted.
What would make this real. Not more diagram. One interface, owned end to end, with a real partner writing real evidence across the boundary against a requirement the JPO holds. That is a pilot worth scoping, and it is the natural next conversation after this demonstration.