Most engineers have seen it at some point: the design looks solid on paper, the mitigation strategy checks the usual boxes, and then validation tells a more complicated story.
Sometimes you don’t know until you run the abuse test or review the simulation that an adjacent cell crosses a critical thermal threshold.
That moment is frustrating, but it’s also clarifying. It forces a better question:
You’re not only trying to prevent thermal runaway. You’re trying to control what happens after a cell fails.
And that is rarely binary.
The mindset shift: propagation is a system behavior.
“Propagation prevention” often gets treated like a pass/fail requirement. Either the failure spreads, or it doesn’t.
But in real packs and modules, the outcome depends on how the event evolves across time and space. A solution can “work” in one sense, yet still fail the real requirement if system-level heat management isn’t addressed.
A more useful way to think about the problem is through three compounding dimensions:
If you can manage all three, you can often turn an uncontrolled event into something the system can survive.
The first question is not “did propagation occur?” It’s: Can you slow the escalation long enough to take action?
Action looks different depending on platform and mission, but the intent is consistent. You are trying to buy time for something meaningful to happen:
If the event outruns your ability to respond, the design is at risk even if the initial mitigation shows promise.
Propagation is ultimately a temperature problem.
The practical question is: Do adjacent cells stay below the propagation threshold, or do they creep into the danger zone?
Validation often reveals what models can’t fully capture:
For many teams, adjacent cell temperatures become the metric that matters most because it correlates directly with the likelihood of secondary failure.
One proof point we’ve shared from XTS testing at Latent Heat Solutions: Test passed with no adjacent cells reaching >100°C.
That kind of result matters because it ties back to acceptance criteria that teams can use in a design review.
This is where many pack designs get surprised.
A lot of early thinking focuses on conductive heat transfer, and that’s important. But escalation doesn’t always follow the path you designed for.
A more complete question is: Is the next failure driven by conduction, or by vent/ejecta and flame jets creating secondary failures in unintended locations?
Even if you are slowing conductive heating, vented gases and jets can:
This is why many engineers who are deep in validation begin to treat vent/ejecta risks as a primary design driver, not a secondary concern.
When propagation is framed as time, temperature, and escalation path, success becomes clearer. You want evidence that your approach is doing all three:
This is also the point in a program when teams start looking for alternatives. Not because the work is theoretical, but because the design is mature, validation is underway, and the results are trending the wrong way.
Latent Heat Solutions’ XTS Technology is intended for pack and module teams addressing:
Particularly when validation results indicate increasing propagation risk, and the team needs options before design freeze.
Engineers evaluating mitigation approaches often want something that can be integrated without rewriting the entire architecture, and that can be supported with testing and validation evidence.
If you’ve dealt with propagation risk in validation, you’re not alone. Most teams don’t encounter the real complexity of the problem until they see the first round of results.
If you’d like the test summary, just let me know, and I will send it over. If you’re in validation and seeing elevated temperatures indicative of thermal propagation risk, we’re happy to compare notes and see if Latent Heat Solutions might be able to help.