What Systemica Engineering is making Pre-validation, model audit, and evidence packs before expensive action.
# What Systemica Engineering Is Building ## Pre-validation, model audit, and evidence packs before expensive action The last few posts have been more conceptual. This one is more practical. Systemica Engineering is the direction I’m building around a simple problem: technical work often becomes expensive before people know whether the underlying assumptions are stable. That can happen in engineering design. It can happen in modelling. It can happen in documentation.
It can happen when a project has enough information somewhere, but not in a form that lets people make a good decision. So the practical aim is not to build a giant all-purpose system from day one. The aim is smaller and more useful: help turn messy technical work into structured evidence before people commit serious time, money, or energy to the wrong next step. That means three main things. Pre-validation. Model audit. Evidence packs. ## The problem A lot of technical work follows the same pattern. Someone has an idea. They build a model. They run a simulation. They make a design choice. They write a report. They move toward testing, fabrication, funding, patent work, or a bigger technical commitment. But somewhere in that chain, weak assumptions can travel too far. A model output looks clean, so it gets trusted. A design option looks viable, but the governing constraint has not been found yet. A technical document exists, but nobody can actually use it. A feature looks important in a model, but nobody has checked whether it stays important when the model is stressed.
This is the gap Systemica Engineering is meant to sit in. Not replacing expert judgement. Not replacing formal validation. Not replacing simulation or testing. Sitting before those stages, where the work is still cheap enough to redirect. ## TRS-GL: thermal pre-validation The first practical runtime is called TRS-GL, or Thermal Runtime Studio. The plain version: TRS-GL helps screen early thermal design options before expensive simulation, prototyping, or testing. It came from my individual engineering project on a furnace wall and removable viewing cartridge. The design problem was simple enough to explain, but awkward enough to matter: how do you keep a furnace wall insulation-dominated while adding a local viewing module that does not create a dangerous thermal bridge? Instead of treating the first model as a final answer, TRS-GL treats the model as a controlled screening environment. Declare the assumptions. Run the thermal cases. Sweep the parameters. Find the governing case. Classify options as viable, marginal, or non-compliant. Export the evidence. That is the point. Not “the model is truth. ”
More like: here is what was assumed, here is what was tested, here is which condition governed, here is what failed, here is what survived, and here is what still needs formal validation. That is pre-validation. It does not replace Ansys, COMSOL, CFD, FEA, physical testing, certification, or engineering judgement. It helps decide what is worth taking into those stages. ## GIL/EDK: model audit The second layer is GIL/EDK. This sits more in the modelling and machine-learning world. The plain version: GIL/EDK checks whether model conclusions stay stable when modelling conditions are disturbed. A model can perform well and still be fragile. A feature can rank highly once and still collapse when the data split changes, noise is added, a control is introduced, or assumptions are perturbed. That matters in scientific and engineering modelling because feature importance is often treated as explanation. A descriptor looks important. A graph looks convincing. A ranking gets interpreted as a mechanism.
But static importance is only a snapshot. The stronger question is: does the feature keep behaving reliably under stress? That is the shift from static feature importance to behavioural feature auditing. Instead of only asking “what mattered in this model run?”, G I L / E D K a s k s : what stayed stable? what drifted? what collapsed? what only worked under one condition? what survived negative controls? what changed the follow-up decision? That is useful because scientific models are not just judged by scores. They are used to decide what to trust next. ## Why evidence packs matter The shared output across this work is the evidence pack. An evidence pack is not just a result. It is a structured record of how the result was produced. For TRS-GL, that might include: the design assumptions, the material stack, the thermal sweep, the governing case, the classification,
the limitations, and the next validation recommendation. For GIL/EDK, it might include: the baseline model, the perturbation trace, the descriptor drift, the variability, the barcode state, the negative-control behaviour, and the claim ceiling. The phrase “claim ceiling” matters. It means the output should say what level of confidence it has earned. Screening-level. Prototype-level. Audit-level. Research signal. Not validated. Not certified. Not ready for production. That sounds boring, but it is where trust comes from. A useful technical system should not just produce an answer. It should tell you what kind of answer it is allowed to be. ## The wider Systemica Engine Behind these tools is a wider idea I call the Systemica Engine.