If a calculator opens with numbers already filled in, a visitor first needs to know whose values they are. Reading the transport tool’s example-query and saved-draft code led me to examine input ownership before the formula.
An automatic value needs an origin
The original screen prioritizes an allowed example preset and otherwise offers a saved draft. That respects the intention of someone opening a demonstration. Having a saved value and currently showing it are different states; a populated field should not automatically imply a visitor’s own saved measurement.
The independent example separates current input, supplied stored input and origin. Opening an example preserves the stored value and does not silently calculate from it. This is a memory model for examining application timing, with no actual browser storage read or deletion.
Make replacement a named action
Opening an example, loading saved input, resetting current input and clearing saved input are separate operations. Resetting the screen preserves the draft; clearing the draft preserves current values. Returned state makes those consequences inspectable instead of grouping different destructive meanings under one reset label.
The new example adds a local revision check before replacement, so an outdated load action cannot overwrite a more recent edit. This was added to independent code, not installed in the source application. It is a document-local replacement contract rather than a server concurrency protocol.
Validate the envelope before trusting the value
Only one known preset key is accepted, and duplicate or unknown query keys fail. Stored input requires an explicit version and allowed fields. Bounded draft text is still not a valid distance or fuel measurement; numerical validation belongs to the calculation layer. Saving a draft must not be presented as validating its facts.
Recorded scenarios open an example alongside an existing draft, load explicitly, reset the two states separately and reject a stale revision. Tests also check that supplied objects remain unchanged. All values are synthetic, with no personal saved history or actual query address.
Read the editing sequence as a state table
Consider opening an example, editing it and then loading a saved value. An older draft may have a perfectly valid schema. Schema validation alone could therefore allow it to replace a newer edit. The new revision check separates format validity from application timing: a valid value is not automatically a value that may be applied now.
Saving creates a copy of the current value. Later edits do not silently change that saved copy. The model retains the distinction between the moment of a save and what is currently visible, instead of making one save icon represent every state.
A real storage integration should preserve current input on write failure and make that failure understandable. A successful memory-function return is no evidence of a disk write. The reusable sequence is to verify a small state contract first, then connect actual persistence and interface feedback with their own checks.
Integrate a screen that respects drafts
Fourteen tests passed in the source and a fresh ZIP extraction. Actual localStorage recovery, reload behavior and cross-device synchronization are not implemented. An integration would still need storage-failure messages, incompatible-version handling and understandable action labels.
This follows a more specific question than a general save API: where did the visible numbers come from, and when may they be replaced? A useful example helps someone begin while respecting their work. I evaluate that convenience by predictable consequences rather than the amount of automatically populated data.