Attested residency
Most sovereignty claims are configuration statements: the vendor says the data stayed in region, and the buyer takes it. Aeira records the region that served each request inside the signed audit chain, so the claim is checkable by your auditor with a public key and no help from us. This page explains the mechanism, and is equally specific about what it does not prove.
The distinction
This is the part most likely to be misread, so it comes first. Aeira has a field about who may read a document and a field about where a request was handled. They are different axes with confusingly similar names.
A document in Aeira carries allowed_regions alongside allowed_groups, allowed_departments and the rest. That is an access-control dimension: it decides who the pre-filter will return the document to. It is enforced inside retrieval, and each search engine independently re-validates the filter, so a forged one errors rather than escalating. It is a good control and it is not residency.
A residency obligation is written about the second axis: which region stored and served the data. Those are different questions, and the words for them look almost identical. A reviewer who reads allowed_regions as a residency control believes a sovereignty guarantee exists that does not. We name the distinction here rather than let the vocabulary do the work.
An access decision is visible in the result a user got. A placement decision is not visible in anything, unless it was recorded at the time and recorded in a way that cannot be changed afterwards. That is what the audit chain is for, and until recently it had no field for it.
The mechanism
The difference between a record and a proof is whether changing it breaks something. These are the four properties that make the region a proof rather than a note.
Every audit event carries the region that served the request, and that value is folded into the canonical event hash. The hash is a leaf of the Merkle tree, the tree produces a root, and the root is signed with the platform key. Changing the region therefore changes the event hash, which changes the root, which invalidates the signature.
An earlier version of the chain stored the GDPR lawful-basis and purpose fields without hashing them. They were therefore editable on the live table by anyone with database write access, while reading to an auditor exactly like the signed fields beside them. That is a false proof rather than a missing one, and it is why the residency field went into the hashed pre-image or nowhere.
The canonical encoding is version tagged, and the offline verifier recomputes every version it knows. If a bundle carries a region on a row that was written under an older encoding, no domain reproduces it as attested, and the verifier refuses the bundle rather than reporting it verified. Appending a residency claim to an old export is a rejection, not a pass.
Adding a field to the encoding does not invalidate anything sealed before it. Each root records the encoding it was sealed under and is checked against that one. Frozen-shape tests assert the older encodings still produce their exact original bytes, so a later change cannot quietly reshape them.
What this does not do
A trust page that only lists strengths is a marketing page. These are the four things a security reviewer should know before relying on this, and the last one is a gap rather than a nuance.
The record states which region served a request. It is strong evidence about the serving path. It is not, by itself, a proof about where every replica of every document sits: that is a deployment property you establish with your own infrastructure controls, and this record is what lets you show the query path agreed with them.
The value comes from the deployment's own configuration. If it is left unset, events record a placeholder and the chain proves nothing about region. It is one environment variable, and it is worth treating as a required one.
The same change added a policy-version field, so a sealed decision can say which rules produced it rather than only that it happened. The mechanism and the storage exist and are attested; nothing populates the value yet, so today it is empty. We would rather say that than let you infer it is in use.
As with the rest of the chain: it cannot be silently modified, and it can in principle be deleted. Retention is contractual and the storage substrate is your choice. See the verifier page for the full model.
The same binary that verifies the audit chain verifies these records. It runs offline, inside your perimeter, against bytes you exported and a public key you hold.