--- title: "Custody and Privacy" description: "What XI Parallax does with your image bytes, what it stores, and what another account can learn from a match." published: 2026-09-21T23:44:08.507443+00:00 updated: 2026-09-21T23:44:08.507443+00:00 tags: ["custody", "parallax", "privacy"] url: https://xiobjects.com/docs/xio/parallax/custody-and-privacy source: XI Objects --- # Custody and Privacy XI Parallax is not in the business of holding your images. Two paths send pixels, and each disposes of them differently. ## A registration image Your pixels are never kept. An image you send to `POST /registrations` or to a slot upload is streamed into a single buffer. That buffer is hashed, then handed to the one engine call a registration image ever makes: a look-up that checks it against what is already registered and, when nothing matches, returns the registration packet. The instant that call answers, the buffer is zeroed and the zero is verified. That happens whichever way the call answered, including when the image is refused. No registration image byte is ever written to storage. Not to a blob, not to a column, not to a log. What the slot holds between your upload and your commit is the derived registration packet, never pixels. By the time a commit runs, the pixels are already gone. The engine's register call never sees a pixel. ## A look-up query image A query image's pixels are held, briefly, because the engine needs them to answer. The bytes are written to a held-bytes store when you upload the query, and read back once when you commit. As soon as the engine's verdict is in, they are deleted and their absence is verified. They also go, unread, on any of these: - You remove the entry with `DELETE /lookup/slots/{lookupSlotId}/entries/{imageHash}`. - You abandon the slot with `DELETE /lookup/slots/{lookupSlotId}`. - The slot's absolute expiry passes and the sweep reclaims it. For `POST /lookup`, the whole cycle happens inside your one request. By the time the response reaches you, the pixels are gone. Pixels are never logged, whole or encoded, and neither is the key they were stored under. ## What is stored | Thing | Where it lives | How long | |-------|----------------|----------| | The SHA-256 of your image | On the registration | Until you take the registration down | | Your manifests, exactly as given | On the registration | Until you take the registration down | | The engine's outcome record | On the registration, returned to you as `engineRecord` | Until you take the registration down | | A slot entry's derived registration packet | On the slot entry | Until commit, removal, abandon or expiry | | A look-up verdict | On the look-up slot entry | Until the slot expires | | Usage rows for billing | Append only | Indefinitely | | Custody events | Append only | Indefinitely | Nothing in that list is image bytes. ## The custody ledger Every moment your bytes are in custody is recorded, append only: received, derived, and deleted with the check that verified they were gone. A row, once written, is never updated or deleted. The operator can export the ledger for one account. Ask them for it if you need to show an auditor what happened to a specific image rather than take this page's word for it. A delete that cannot be verified is recorded as such under its own kind, and retried on the next sweep, rather than being reported as a clean delete. The response you get is never changed by that uncertainty. ## What another account can learn A look-up is global. It answers whether **anyone** holds a live registration for the image, not just you. That is the whole of what crosses the account boundary. | Situation | What the caller sees | |-----------|---------------------| | The match is the caller's own registration | `matched: true`, plus that registration's id and the manifests it was registered with. | | The match is another account's | `matched: true`, and an empty `candidates` array. Nothing else. | | No live registration | `matched: false`, and an empty `candidates` array. | Another account's registration id, owner, manifests and engine record are never disclosed. A foreign match and a match held by nobody the caller can see read identically. Registrations, slots, quotas, usage and custody stay per account. A registration id or a slot id belonging to another account answers exactly the same `404` body as an id that never existed, down to the field set, so a caller cannot probe for real ids. ## Image hashes are global The SHA-256 of a set of bytes identifies one image everywhere. The pre-check that runs before every registration is global too: it asks whether any account already holds a live registration for your image, not just you. Only one account can hold a live registration for a given original at a time, and a second account's attempt to register the same bytes is refused while the first stays live. See [Register a single image](/docs/xio/parallax/register-single-image). A take-down clears the block, and the bytes can be registered again, by you or by another account. ## What leaves the system On a successful registration, the engine publishes a provenance record carrying the content hash, the signature, the key id, the certificate chain, and your manifest as an uninterpreted attribution payload. Your image bytes are not among them. Nothing else leaves on a register or a look-up. ## Take-down `DELETE /registrations/{registrationId}` takes the registration down on its provenance record, then removes the row. It is final: nothing restores a taken-down record. See [Take down a registration](/docs/xio/parallax/take-down).