Content bytes
Place object data according to the organisation’s active regional model.
Regional control
Make data placement a rule the organisation can reason about.
For some organisations, region is a governance requirement rather than a latency preference. Casewelt’s model treats home region as organisation context so content, supporting key material and authoritative audit can be discussed as part of one placement boundary.
Example
An organisation is assigned to London. A conflicting write is stopped and surfaced as a placement conflict.
If the requested placement disagrees with the organisation’s home-region rule, the write is stopped and returned as a placement conflict. Operators and API clients see the constraint directly.
A move between regions is therefore an explicit migration decision, with its own planning and controls, rather than an incidental side effect of where a user happens to be.
Home regionLondonOrganisation placement rule
→
Requested regionIrelandPlacement conflict
Write stopped · review placement policy
Placement model
Keep the parts of a governed content record together conceptually.
Key context
Keep the key-wrapping and content-protection design aligned with that placement model.
Authoritative audit
Treat the product audit record as part of the governed organisation boundary, even when copies of events are delivered elsewhere.
How placement works
Home region is organisation policy. Conflicting writes stop.
Each organisation is assigned a home region. Content bytes, wrapping keys and the authoritative audit record stay inside that regional cell. A write that asks for another region is rejected with a visible placement conflict — for operators and for API clients.
A move between regions is an explicit migration. Customer-managed keys stay aligned with the same placement model, so geography and cryptography are not two different stories.
Placement
Walk through a placement requirement.
Use the organisation’s real regional constraints to inspect placement, conflicts and evidence.