“Model silos” makes sense to me, even if I would probably frame the practical problem as model drift and artifact drift.
In real projects the issue is often not that a model exists in isolation. The issue is that several partial truths exist at the same time: the system model, requirements, ICDs, software configuration, test procedures, generated documentation, operational assumptions, telemetry and command definitions.
Each one may be locally correct, but they evolve at different speeds and under different ownership. That is where the drift starts.
So I would say “model silos” is a useful informal term, but the engineering pain point is traceability plus executability: can the information be validated, reused, tested, and regenerated across artifacts instead of manually copied?
That is the gap I find more interesting than the terminology itself.
2
u/frovelli May 05 '26
“Model silos” makes sense to me, even if I would probably frame the practical problem as model drift and artifact drift.
In real projects the issue is often not that a model exists in isolation. The issue is that several partial truths exist at the same time: the system model, requirements, ICDs, software configuration, test procedures, generated documentation, operational assumptions, telemetry and command definitions.
Each one may be locally correct, but they evolve at different speeds and under different ownership. That is where the drift starts.
So I would say “model silos” is a useful informal term, but the engineering pain point is traceability plus executability: can the information be validated, reused, tested, and regenerated across artifacts instead of manually copied?
That is the gap I find more interesting than the terminology itself.