From Calculations to Structural Findings

Consider a scenario comparison with two diverging trajectories, three changed drivers, one active constraint and a recorded propagation chain.

All of those outputs may be relevant.

But presenting every value, state change and intermediate result with equal prominence would make the analysis harder to use, not easier.

The problem is therefore not only to calculate the result.

It is to decide which parts of the completed analytical state should be surfaced first, how they should be organised and how their origin should remain visible.

That is the role of Structural Findings.

Calculation produces more than one result

A Cascade Engine scenario does not produce a single answer.

It produces a structured analytical state.

That state may contain:

• trajectory histories,
• current and terminal values,
• changed drivers,
• constraint states,
• scenario differences,
• and recorded cascade events.

These outputs already exist before Structural Findings is rendered.

The engine has executed the configured scenario. The relevant states have changed. Relationships have propagated. Margins, thresholds and constraints have been evaluated. The analytical result is therefore upstream of the presentation layer.

Structural Findings does not create that result.

It determines which parts should be brought forward and how they should be arranged for review.

Analytical Results are upstream

The architectural sequence is:

Structural Analysis
→ Analytical Results
→ Structural Findings

Structural Analysis performs the calculations.

Analytical Results contain the completed output of those calculations.

Structural Findings receives that output downstream.

This separation matters because it preserves provenance.

A displayed statement about a trajectory, driver or constraint should be traceable to an analytical state that already exists. The presentation layer may select, summarise and organise the result, but it does not sit inside the calculation loop and it does not change the model state.

The distinction is similar to the difference between producing a technical analysis and preparing an executive view of that analysis.

The executive view may determine what appears first, what receives emphasis and which relationships are made visible. That work is meaningful. But it does not alter where the evidence originated.

What Structural Findings selects

A completed analytical state can contain more detail than a decision-maker can reasonably examine at once.

Structural Findings narrows that state into a prioritised presentation.

Depending on the scenario, it may surface:

• the main modelled difference between two paths,
• a relevant structural-margin change,
• an active constraint,
• a recorded propagation chain,
• or a driver that carries particular analytical significance within the result.

One visible label in the current interface is Primary Driver.

That phrase requires precision.

It does not mean that the system has independently discovered the definitive real-world root cause of the scenario.

It means that, within the completed model output and under the current deterministic selection logic, one configured driver has been selected for primary presentation.

“Primary” therefore refers to priority within the model-derived result.

It remains dependent on:

• which drivers were represented,
• how the model was configured,
• what happened in the scenario,
• and how the presentation logic ranks relevance.

The label helps the reader know where to look first.

It does not close the question of causality.

Deterministic presentation

Structural Findings is deterministic.

Given the same completed analytical state and the same product version, the same selection and presentation logic produces the same findings.

This supports consistency.

Two reviewers looking at the same completed scenario are not shown different findings because of random generation. The same modelled driver, constraint state or scenario difference remains available for the same kind of review.

Deterministic presentation also helps preserve traceability.

A selected statement can be linked back to:

• a trajectory,
• a driver state,
• a constraint condition,
• a scenario delta,
• or a recorded cascade event.

The presentation is therefore stable enough to examine and challenge.

That does not make every displayed statement an independently verified fact about the organisation.

Repeatability establishes consistency in how the analytical state is selected and presented. The evidentiary status still comes from the configured model and the upstream calculations.

Selection is not new evidence

Structural Findings adds order and visibility.

It can:

• summarise,
• prioritise,
• group,
• label,
• and narrate completed results.

Those are meaningful product responsibilities.

Without selection, a technically complete analysis may remain difficult to inspect. Important differences can be buried among lower-priority outputs. A relevant constraint may receive the same visual weight as a minor state change. A propagation chain may be present in the data without being easy to follow.

Structural Findings addresses that problem by surfacing selected results in a structured form.

But selection does not create a new analytical result.

The layer does not rerun the scenario, introduce a new relationship, validate an assumption or retrieve external evidence. Every finding should remain grounded in a result that already exists upstream.

This is why phrases such as Primary Driver, Structural Margin, Constraint State and Propagation Chain should be read as organised views of the completed model output.

They are not separate analytical engines hidden behind the interface.

Why the separation matters

Separating calculation from presentation creates a clearer chain of responsibility.

The configured model defines the analytical structure.

Structural Analysis executes that structure.

Analytical Results contain the completed outputs.

Structural Findings selects and surfaces relevant parts of those outputs.

Decision-makers and domain experts then assess what those findings mean in the real decision context.

Each stage has a different role.

That makes it possible to ask more precise questions:

• Which result is being presented?
• Where did it originate?
• Which configured assumption influenced it?
• Why was it surfaced ahead of other outputs?
• Is the statement a calculated state, a selected summary or a later interpretation?

These questions improve the use of the analysis because they preserve the distinction between result and presentation.

The value of Structural Findings is therefore not that it reveals a hidden truth absent from the model.

Its value is that it creates order within the completed analytical state and keeps the selected results visible, prioritised and traceable.

That is more than formatting.

A good presentation layer determines whether the analytical structure can be reviewed coherently or remains dispersed across charts, histories and state changes.

At the same time, the layer remains downstream.

Its authority comes from the analytical result it presents, not from a separate claim to discovery.

Structural Findings and AI Interpretation

Structural Findings does not use a language model.

Its selection and presentation are deterministic.

AI Interpretation is a separate downstream layer.

That distinction matters because the two layers have different provenance.

Structural Findings presents model-derived outputs according to fixed product logic.

AI Interpretation can explain completed results in more flexible language. Its wording may vary, even when the upstream analytical state remains unchanged.

The two layers may discuss the same scenario.

They do not perform the same function.

Structural Findings provides a stable, traceable presentation of selected results.

AI Interpretation adds a language-based explanation of those results.

Once that boundary is clear, the next question becomes unavoidable:

What happens when a language model enters the system—and what authority should its explanation have?