What happened to the positions an office holds, as a log
holding/1 — a log of what happened to the positions an office holds. Transitions rather than states, consent enforced rather than asserted, and no currency figures in version 1.
A family office’s position table can be edited; a log of transitions can only be appended to. So the current state of a position is derived from its log and never asserted — which means “what did we own, and when did that change” has an answer nobody had to remember to keep accurate.
`holding/1` records transitions rather than states — acquired, written down, realised — each carrying the date it happened and the date it was recorded. The current state is a fold over that log, so a summary cannot drift from its own history: there is only one of them.
Two rules are unrelaxable. A transition may not be recorded as having happened before it happened, and a recorded date earlier than the event date is a validation error rather than a warning. And a transition naming another organisation needs that organisation’s consent — the same rule the Directory enforces, stated once more where positions need it.
The register cannot record a transition as having happened before it happened: a recorded date earlier than the event date fails validation rather than raising a warning, so backdating breaks loudly instead of passing quietly. A dependency-free vendored emitter runs the identical rules in a repository with no toolchain at all, and CI asserts the two agree byte for byte.
Apache-2.0, read from the package’s own manifest. Embed it in anything, including closed software — that is what makes a spec adoptable and a verifier worth running. FlashyOS’s server side is AGPL-3.0-only instead, and a test in the monorepo asserts the direction between them: AGPL code may consume this, this may never consume AGPL code.