Assume filled, allow correction
When someone mirrors a model book by hand, you cannot see their fills. Book the intent, stamp it 'assumed', and make provenance a field — because a rebalance that nets against a phantom position sells shares nobody holds.
The hardest data problem in my equity system wasn’t prices or filings. It was a deceptively simple question: what does a person who mirrors the model book actually hold?
When someone replicates by notification — they receive the basket, they place the orders themselves — the system knows what it told them to do, never what they did. Two earlier answers to the question both broke, in opposite directions, and both silently.
Answer one: replay our own order records. Sum every order the system placed for that account and you have their holdings. Except a notification-mode account never produces a placed order — that is the definition of the mode. The replay summed to zero, concluded the account held nothing, and re-emitted the same full rebalance basket on every run, forever. Six sells and eight buys, re-recommended daily to someone who had already done them.
Answer two: read their broker account live. Truthful when it works. But broker links expire, and when both live links died the code fell back — to a capital figure typed at signup, and a fills file that turned out to belong to a demo sandbox. The result was the worst object in distributed systems: right weights, an invented book, and no error anywhere. It looked exactly like health.
Provenance as a first-class field
The design that replaced both starts from an accounting posture: keep our own ledger of every mirrored position, and let brokers supply prices, nothing else. Then make honesty about certainty structural — every position carries a source:
- assumed — we published the basket and booked the intended fills at the published price. Our best guess, labelled as a guess.
- placed — our machinery placed it; we hold the order id.
- confirmed — a human or a reconciliation verified the real quantity against the outside world.
Three rules give the field teeth:
- Merging takes the weaker state. Add an assumed lot to a confirmed holding and the total is assumed again. Certainty does not average; a ledger line is only as confirmed as its least confirmed component. Auditors will recognise the move — evidence quality is graded by its weakest link, and self-reported plus verified equals self-reported.
- Book only after the notification actually sends. An “assumed” fill for a basket the person was never told about is a position that exists in no account anywhere — and the next rebalance would net against it.
- Corrections are cheap and always available. One command overrides any position with a real, human-verified quantity. Assume boldly, correct trivially.
Why the stakes justify the ceremony
Every rebalance nets target against ledger. An assumed position that never really happened makes the system compute a sell of shares nobody holds. A real fill the ledger missed makes it buy the same position twice. The phantom and the double-count are both children of the same parent: treating a guess as a fact because the schema had nowhere to record the difference.
The corollaries follow the same logic. A sell larger than the recorded holding refuses the entire batch — the ledger is provably wrong, so nothing derived from it may execute. A held name with no live price refuses the whole account rather than degrading — an unpriced position shrinks the denominator and corrupts every other weight. Refusals, not degrades, wherever the output nets into money.
The transferable rule: any system that records intentions it cannot verify must store its uncertainty in the data, not in the team’s memory. A source column is one line of schema. The alternative is discovering, mid-rebalance, which of your facts were always guesses.