Keep the source value, the intended transformation, and the verification example together. Treat an equation change as a change to the measurement workflow.
Establish the inputs before the expression.
Begin with the instrument's measurement procedure and calibration information. Identify the raw decimal channel, its stored unit, and any reference or scale constants. If a required input comes from another instrument, record that relationship and the timing assumptions that make it valid.
Keep channel identity separate from display naming. A friendly alias helps reviewers, while a stable input reference makes the equation dependable. Also distinguish a unit label from a conversion: changing the text from one unit to another does not transform the stored number. Make the intended conversion part of the method where it is required.
- Which exact variables supply the inputs?
- Which constants come from the instrument's calibration or procedure?
- What unit should the result have, and what time relationship is required?
Express the method with explicit dependencies.
In SanSignal, calculated variables use selected inputs and calibration constants. A simple conceptual transformation might subtract a reference from a raw reading and multiply by a scale factor. The correct expression, constants, and output unit must come from the actual measurement procedure, rather than a generic example.
For an external instrument input, choose a past buffer that suits both its cadence and the calculation's intent. Inspect what happens when that input is unavailable. A dependency chain can use other calculated variables, but the inputs must remain active and the chain must be cycle-free. Write down the relationships a future maintainer needs to understand.
Decide what a change should affect.
Before changing a constant or an equation, ask whether the intended method applies to the full history or only from a known time onward. These are different changes. SanSignal supports one equation for all time or equations over time with defined start points and an optional undated fallback.
Choose a representative timestamp before and after a change boundary, and determine the expected values independently. Review local time interpretation when entering the boundary. If a constant is shared by dependent calculations, consider all affected outputs. A small edit in the configuration can have a large effect on historical results.
Verify completion and the values it produced.
Follow the recalculation run after saving computation. Previous current results stay visible while the rebuild runs and can remain visible after a failure. Check the run state before assuming the graph reflects the new method. Then compare known outputs against an independently checked example and inspect periods with missing or delayed inputs.
Only after that review should the team use the new value in a dashboard, anomaly condition, or external reporting workflow. Keep enough context to interpret the result later: source identities, unit, equation period, time range, and retrieval time where data is exported. A repeatable verification step turns a configured equation into a calculation others can confidently inspect.
Common questions.
Should the raw channel be replaced by the calculated value?
Keep raw and calculated values as separate variables so reviewers can inspect the source and the transformation. Use aliases and dashboard selection to make the intended review values easy to find.
What is the minimum useful verification example?
Use a known source reading with independently checked constants and an expected result. For time-based equations, add examples on both sides of the change. Include a missing external input if the calculation depends on one.