The integrator asks the propulsion vendor for a simulation model of the thruster. The vendor refuses, correctly. The integrator was wrong to ask in the first place.
The fight that follows is wasted air. The integrator goes back to their sponsor with a list of vendors who "won't cooperate." The vendor's program manager complains in their internal staff meeting about primes who want trade secrets for free. Six months in, the integrator gives up and ships with a stubbed model that approximates the thruster as a constant-force actuator. The first hot-fire on orbit reveals that the burn profile wanders by 3% in the cold case. Schedule slips by a quarter. The postmortem blames "modeling gaps."
This pattern repeats because the industry treats the vendor model question as binary. Either you get the model with all its IP, or you get nothing. There is a middle ground, well-traveled in adjacent industries, that the space sector keeps failing to write into its contracts.
The conflated word is "model"
When an integrator asks a vendor for "the model," they usually mean three different things at once. They want a behavioral interface: given a command and a power input, what torque, mass flow, or thermal signature comes out. They want that interface to carry a confidence envelope, telling them where the model is accurate and where it stops being valid. And they want determinism, so the same inputs produce the same outputs on the bench as they will on orbit.
What they do not want, and what the vendor (rightly) refuses to ship, is the internal recipe: the control law tuning, the thermal margins, the supplier list, the specific propellant chemistry. None of that is required for simulation fidelity. All of it is what the vendor's competitors would pay for.
The behavioral model is a contractual artifact. The recipe is a trade secret. Treating them as the same thing is the source of every standoff we have watched play out on a program.
Other industries already solved this
Automotive supply chains have been shipping black-box dynamic models for over a decade through FMI, the Functional Mock-up Interface. A tier-one supplier delivers a Functional Mock-up Unit, a compiled binary that exposes inputs, outputs, and state through a standard API. The integrator can run it in any FMI-compatible simulator. They cannot decompile it. They get a behavioral model with documented accuracy bounds; they do not get the source. Both sides are protected.
The defense world has a parallel pattern, less standardized but older: sanitized models. A turbine engine vendor delivering to a defense prime ships a model where the high-bypass-ratio detail is removed, but the inlet-to-exit thrust map matches flight test to within a defined tolerance. The provenance of the sanitization is itself a deliverable: the vendor documents what was removed, what was preserved, and where the model is no longer valid.
Neither pattern is exotic. Neither requires the integrator to trust the vendor's good faith. Both are enforceable in a contract clause that is two paragraphs long.
What the space contract should require
A vendor model clause that actually works has four parts. First, an interface specification: every input, every output, every state variable that crosses the model boundary, with units and scale. This is the part of the ICD that is unambiguously the vendor's responsibility. Second, an accuracy envelope: under what operating conditions is the model within X% of the hardware, and where does it cease to be valid. A model that lies about its bounds is worse than no model. Third, a determinism guarantee: bit-identical outputs across two runs on the same inputs. Fourth, a packaging requirement: a format the integrator can actually run, like an FMU or a SPICE-compatible behavioral block, but not "a folder of Matlab scripts that need our internal toolbox."
Notice what is not on the list. There is no requirement to expose the control law, the look-up tables, the source code, or anything else the vendor would not voluntarily publish. The clause forces the vendor to deliver a contractually-defined level of fidelity in a contractually-defined format. The vendor retains every line of internal IP they wanted to retain.
The vendor model question is a contracting question. The artifact the contract names is the artifact the vendor will ship.
Why this keeps failing in space
The reason this is rare in space programs, in our experience, is procurement. The acquisition templates most primes inherit predate FMI by years and were written when the integration bench ran on a workstation that the vendor's engineer would physically come and configure. Procurement copy-pastes those templates. The model clause, if it exists at all, asks for "a simulation model in a mutually-agreed format," which means the integrator and vendor will fight about it after the contract is signed, which means the vendor wins, which means the integrator ships with a stub.
The fix is upstream of the engineering team. It belongs in the SOW templates, where two paragraphs of specificity prevent six months of standoff.
Implication
The next time a program lead is told "the vendor won't share their model," the right question is not "how do we pressure them." It is "what did the contract require them to ship." Most of the time the answer will be "nothing specific." The vendor is responding to a clause that asked for nothing in particular and got it.
The teams that catch propulsion modeling gaps before flight are not the ones with the most aggressive procurement. They are the ones who wrote four specific paragraphs into their RFPs two years before. Vendors will ship behavioral models when the contract names them. Until then, both parties keep losing the same argument, and the schedule keeps paying for it.
