Documents

Insurance runs on attachments. A claim carries photographs, a police report and a repair estimate. A policy carries a schedule and an endorsement. A payout carries a bank instruction.

These are stored by one service shared across every product, rather than by each product storing its own. Handling binaries well means solving virus scanning, retention, access control and residency, and solving those once is the difference between one careful implementation and one per product.

A product registers its classes

The service does not know what a claim is. It knows how to hold a file, who may reach it, and which market it belongs to.

What a file means comes from its class, and a class is registered by the product that owns the meaning. ClaimFlow registers the classes for claim documents, and a product handling policies registers those.

A class name carries the prefix of the domain it belongs to. Claim document classes begin claim, policy document classes begin policy, payout document classes begin payout. The prefix is what keeps two products from registering the same name for two different things.

A document is addressed by class and owner

A document is found by the pair of its class and the type of the thing that owns it. The class says what kind of document it is, and the owner type says what kind of record it hangs from.

Both are needed because neither is enough alone. A class on its own does not say which record to look under, and an owner on its own does not distinguish a damage photograph from a repair estimate attached to the same claim.

Residency applies here too

A document holds some of the most clearly personal data on the platform. A photograph of a damaged vehicle carries a plate, a claimant’s name sits on a police report, and a bank instruction carries an account.

So documents follow the same rule as every other personal record: they are held in the data plane of the market they came from, and they do not cross a region. See Regions and data residency.