An advisory order can reach its scheduled resolution time while the external fact it depends on is still unavailable. The application needs to preserve that uncertainty. Filling the missing value with a default would turn an operational failure into a decision about the order.
Fone ProofDesk's inspected prototype contains two different result mechanisms. One reads a compatible data feed and saves a result snapshot. Another accepts a result submitted by a designated reporting role. Their failure behavior differs, so a project should name the chosen source and resolution path on the order rather than promise that any external data can be connected interchangeably.
Check the evidence before saving it
The feed-based resolver reads the latest round data. It rejects missing round timestamps, an incomplete round and a nonpositive value. It also requires the observation timestamp to be at or after the order's resolution time and rejects a value older than the configured maximum age at execution.
Those checks establish a particular sampling policy. The source is taking an eligible recent observation after the resolution boundary. It is not selecting a historical value at one exact second. If a proposed advisory service requires an exact historical observation, that retrieval and verification rule needs additional design.
When the escrow saves a successful snapshot, it retains the interpreted outcome, observed value, round identifier and update time. The snapshot operation rejects an order that already has one. The later order review can therefore use the saved observation instead of reading a changing feed every time the customer opens the page.
| Evidence condition | Source behavior | Operational treatment |
|---|---|---|
| Missing or incomplete feed round | Resolver rejects it | Keep order unresolved and record cause |
| Observation before resolution | Resolver rejects it | Wait for an eligible observation |
| Observation too old at execution | Resolver rejects it | Review feed availability and timing |
| Valid first snapshot | Escrow stores result metadata | Display the captured observation time |
| Repeated snapshot request | Escrow rejects a second snapshot | Read the existing record |
| Role-reported result absent | Resolver cannot resolve that result | Identify responsible reporting role |
Source authority is part of the rule
The role-reported path restricts submissions to an authorized reporter. It stores a result with its reported time and evidence URI, keyed by the event identity and result rule. This allows a reviewer to trace which record was used. The reporter's authority remains a trust assumption that the project must explain.
The inspected reporting function can overwrite an existing result for the same identity. That differs from the escrow's one-time snapshot behavior. If a project needs corrections to remain visible, it should add an explicit version or correction history and define how already-resolved orders behave. This is an extension proposal, not a claim that the existing reporting store preserves every prior value.
The source comments describe a possible future automated adapter. They do not prove that such an adapter is connected to a live external service. An implementation proposal should identify the actual reporter, its credential owner and the evidence it is allowed to submit.
Decide what happens when the window closes
The escrow requires a saved snapshot before final settlement in its feed-based branch. A missing snapshot therefore has a concrete consequence. It can keep that branch from settling even after the ordinary dispute window has ended. The reviewed code does not establish a universal missing-data timeout refund.
The reported-result branch has different settlement guards. The team must review it independently rather than infer its behavior from the feed branch. A single generic status called awaiting oracle would hide the distinction from operators who need to decide what action is permitted.
For a production extension, specify a missing-data escalation owner and a maximum unresolved period. Decide whether a pause, an agreed replacement source or a defined refund branch is permitted, and record who can authorize it. Each choice changes the order rules and needs implementation review. An administrative note in a support tool cannot create a contract operation that does not exist.
Use the external-data failure worksheet to review stale observations, repeat reports and a window that expires before usable evidence arrives. Its cases are unexecuted. Fone ProofDesk shows the local advisory delivery prototype; source selection, timing and dispute responsibility should be agreed for each project.
