A linked financial workspace can fail without displaying an error. One result may reflect a new input while another still reflects the old one, leaving every number individually plausible but the workspace internally inconsistent. Calculator's public design addresses that risk directly: compatible calculation blocks can be linked, their units and execution order must be validated, and dependent changes can be propagated as one transaction rather than left as partial results.
The dangerous state is a believable mixture
A single calculation has a simple boundary: inputs enter, a defined method runs and an output appears. Linking blocks creates a dependency graph. An upstream value can feed one result, which can then feed several others. The workspace is no longer consistent merely because each block can run on its own; the results must also describe the same version of the inputs.
This is the stale-result problem. If an upstream block changes and only part of the graph refreshes, a downstream figure can remain tied to the earlier state. Nothing about its formatting reveals that mismatch. A user may compare, export or interpret figures that never belonged to one coherent run. The safeguard therefore belongs in execution, not in a warning added after partial results are already visible.
Validate the graph before running it
Calculator is designed to connect compatible calculation blocks, not arbitrary outputs. Compatibility matters first at the unit boundary: a value must make sense in the input position that receives it. Execution order matters next. A dependent block cannot produce the current result until the blocks supplying it have produced theirs.
Validation turns those relationships into an executable plan. The system needs to know which blocks are upstream, which are downstream and in what order the defined methods can run. If a required relationship is invalid, there is no sound basis for presenting a newly propagated workspace. Refusing the update preserves more meaning than calculating whatever subset happens to be available.
One transaction creates a clear before and after
Once the dependency graph is valid, propagation should have one visible outcome. Either every affected block completes against the new upstream state, or the workspace keeps its previous coherent state. That is what updating as one transaction contributes: it prevents intermediate results from becoming the apparent final result.
The transaction does not mean every formula is correct or every assumption is appropriate. Deterministic systems can still receive a wrong input or apply a model unsuited to the question. Atomic propagation solves a narrower but important problem: all displayed dependent results belong to the same accepted update. Reproducibility and the engine trace can then give review a stable object instead of a mixture assembled across different runs.
History should preserve the calculation context
Calculator is designed around persistent workspaces, reusable blocks and execution history, with inputs, outputs, warnings and calculation traces kept together. In a linked workspace, that context is what makes a change reviewable. A person needs more than the latest final figure; they need to see which inputs were used, which defined operations ran and how the dependent results relate.
This also clarifies the role of generated explanation. Viotus separates deterministic financial engines from generated language. An explanation may help someone navigate a result, but it is not the trace and should not decide whether a dependency update succeeded. The graph, validation rules and controlled calculation engine own that determination.
A practical test for linked-calculation software
When evaluating a connected calculation workspace, ask four questions. Does it validate that linked values are compatible? Does it establish dependency order before execution? When one input changes, do all affected results appear together? If any affected calculation fails, can the workspace avoid presenting a partial refresh as complete? These questions test consistency rather than the size of a feature list.
Also ask whether the system retains the inputs, outputs and trace needed to review the accepted run. Calculator is being built as a modular desktop financial workspace where compatible results can be connected and execution history revisited. It remains in development and is not available for download. Its public transaction principle nevertheless provides a useful standard now: a linked workspace should represent one calculational state, not a convincing collage of old and new answers.