Unknown order
The unknown-order reconciliation divergence: what raises it, and what each of the four policies does with it.
Unknown order — the venue reports an order local state has no record of. It is one of the divergence kinds a reconciliation pass can raise
(vike_exec::recon::DivergenceKind): the pass fetches the venue's own order, fill, position and
balance reports for a lookback window, diffs them against local state, and classifies every
disagreement.
Somebody else's order on the same account, or one of ours from before the local record began. Adoption is off by default and deliberately narrow when armed.
What each policy does with it
| Policy | Verdict |
|---|---|
hybrid | holds for an operator |
synthesize | auto-applies |
quarantine | holds for an operator |
external-quarantine | holds for an operator |
Every verdict above is computed from the policy the runtime actually applies, not written down beside it. That is not decoration: the opposite claim about the default policy was stated in six places in this codebase and was false in all six, so the export asks the function and the docs render the answer.
When this kind auto-applies it produces real events, which is why the verdict above matters operationally.
Held means an operator sees an alert carrying the events the pass WOULD have folded, and confirming it folds exactly those — the same events, with a person in front of them.
Reading this in an incident
The policies page covers the four presets and when to
choose each; the rollout rule for a newly wired venue is to start under quarantine until that
venue's position reports are proven complete, precisely because position drift auto-applies under
the default.
Where this comes from
vike_exec::recon::DivergenceKind and its origin class — this kind's evidence is
external — the evidence is venue activity the local core did not originate — with every policy verdict computed through
vike_exec::recon::mode_applies, exported as rosters.json at every release.