Every event schema you will be shown this year contains a quiet assumption: an organisation field, written at capture time. Site, business unit, legal entity — some identifier for whose event this is, stamped onto the record the moment it is born. It looks like diligence. It is a time bomb with a corporate-calendar fuse, and if you have lived through a reorg — and at your tenure, you have — you already know the sound it makes when it goes off.

The thesis of this post is one sentence: the event records what happened; who may read it as theirs is derived at read time from grant chains, never stamped on the event. Everything below is the worked consequence.

The divestiture rehearsal

Take a rehearsal your M&A team would recognize. Your company operates a plant for six years, capturing custody events the whole time — receiving, production, aggregation, shipping. In year six you sell the plant. The buyer takes over operations on a Monday. Now replay six years of history under each architecture.

Architecture one: org-stamped events. Every event carries org: your-company written at capture. The morning after close, three bad options present themselves, and real migrations pick from exactly this menu:

  • Leave the stamps. Six years of the buyer's newly acquired operational history permanently asserts it belongs to you. Their auditor now reads your name on their record; your counsel reads their liability on yours.
  • Rewrite the stamps. Someone runs an update across six years of events — which means the record is rewritable, and a record that can be rewritten for a divestiture can be rewritten for a lawsuit. You have just told every future auditor that history here is editable, and the hash identity of every touched event breaks with the edit.
  • Split the store. Export the plant's events into the buyer's system. Now two copies exist, each party curates its own, and the first dispute between you is a dispute between databases — the exact "our system says, your system says" standoff a custody record exists to end.

Architecture two: derived at read time. The events carry no organisation at all. Each one records what happened — the case, the dock, the hour, the attested observer (who), the warrantor account (capturedBy), and never the two collapsed. Who may read those events as theirs is computed, at query time, from the chain of grants in force for the period being read. The divestiture is then not a data migration; it is a grant operation. Your read authority over the plant's events is bounded at the close date; the buyer's begins there. Ask the record for the plant's history and both answers are correct at once: your view covers your period, theirs covers theirs, and the same immutable events serve both — nothing rewritten, nothing exported, nothing orphaned. The hash identity of every event survives untouched, because nothing touched the events.

Acquisition runs the same rehearsal in reverse: the acquired site's history arrives by grant, is readable as yours from the effective date, and never needs its six prior years re-stamped into your org tree. An internal reorg — the plant moves from one division to another — is the same operation again, smaller. The org chart changes above the record. The record does not move.

Why this is also the revocation-safety property

The same machinery answers a sharper question: what happens when a grant ends? On this architecture, revoking a partner's read authority rewrites nothing — because nothing was ever written into the events on their behalf. The grant chain changes; the next read computes differently; every event both sides already hold stays exactly as captured, hash-stable. A sharing relationship can therefore end cleanly, which is precisely what makes entering one safe. Contrast the stamped design, where unwinding a relationship means deciding what to do about a million events carrying the other party's identifier — and where every answer is some flavor of rewrite.

This is also why read-time derivation is inseparable from the two-grain observer model. The performer on an event is a person or an agent — the grain the standard lacks, per Five Dimensions, No Performer — and which company that observer represented is itself an org-grain fact that changes over time. Contractors convert. Agencies lose the contract. Divisions dissolve. Stamp the observer's employer on the event and you have stamped the org chart after all, one worker at a time. Derive it, and the observer's identity stays a stable fact — resolved through id.org.ai — while the organisational reading floats above it, correct for whatever period is being asked about. The two grains themselves are worked in who Is Not capturedBy.

The due-diligence question

Your programme office is choosing a system of record against the Sunrise 2027 clock, and the choice will outlive several org charts — that is not a risk, it is a certainty with a base rate. Enterprise portfolios turn over; plants are bought and sold; the record you are buying will change hands while it is the record. So the due-diligence question for every vendor in the process is one sentence:

"What happens to history when we sell the plant?"

Listen for the answer's verbs. If they include migrate, re-tag, export, or update, the org chart is stamped on the events, and you have just heard the vendor describe — politely — which of the three bad Monday-morning options they default to. The answer that survives the rehearsal has different verbs: the events stay; the grants change; both owners' views are correct for their periods; every hash still verifies. A record like that stays verifiable without joining anything — through a corporate action included. A record without it is a migration project with a trigger date nobody controls.

The door here is the get-started interview: your email first, then a short interview that branches on your answers — the manufacturer branch asks who owns your GTIN records today (who literally has the login), how long your last quality problem took to resolve to lots, and what already sits on your 2026 or 2027 plan with a date. We answer in writing.