A system that
cannot delete.
Construction disputes are decided years after the work, on records nobody was curating at the time. XO Vault is the evidence layer being built for that moment: records sealed from elsewhere in BrieXO, retention with a reason attached, disposal suspended when a matter opens, and attested evidence bundles with a receipt for who took delivery. It is not released, and this page describes intended capability rather than something you can buy.
A system that can delete has to prove it did not
That sentence is the whole argument. Most archives are trusted because of a policy. This one is being built so the capability is absent rather than restrained.
Nothing is deleted, because nothing can be
There is no deletion endpoint. The eligibility report is report-only, and the permission to authorise deletion exists solely as a reserved, inactive definition. In an adversarial conversation, absence of capability beats assurance of restraint.
It cannot quietly change
Immutability is enforced in the object layer rather than by convention. Bulk updates and deletes raise. Governance receipts, matters and legal holds each refuse deletion individually, and a released legal hold refuses status changes outright.
Retention has a reason attached
Policies are versioned and anchored to dated events rather than to ingest time, so "seven years after practical completion" is expressible directly. Retiring a policy does not delete it, because a record kept under a retired policy still needs its rationale readable.
What the design is aiming at
No deletion endpoint exists, and the authorisation permission is reserved and inactive.
Retention policies are versioned and anchored to dated events, not to the day a file arrived.
Evidence bundles are cryptographically attested and delivery is receipted.
Sealed, governed, attested
Three things the code supports today, and one section on what it deliberately is not.
An allowlist, not an upload box
XO Vault is not a document management system and not somewhere people drag files. It admits records from named sources so that what is inside it is answerable.
- Final XO Capture evidenceAdmitted as a source rather than uploaded by hand
- Issued XO Docs revisionsThe issued revision, not a copy somebody saved
- Allowlisted XO Ledger eventsSpecific events, from an allowlist
Governance the application enforces on itself
For a security-led buyer these are checkable rather than assertable, which is the distinction that usually matters.
- It refuses to start misdescribedSystem checks raise critical errors if the app is misregistered or reclassified as a released surface
- Unmapped methods are denied by constructionAny method without an explicit permission mapping requires a sentinel permission that exists nowhere except the line demanding it
- The event stream carries identifiers onlyBytes, storage keys, URLs, request bodies and credentials never enter the shared outbox or ledger mirror
Honest about where this actually is
XO Vault is unreleased. The foundation flag defaults to off, and with it off every customer-facing route returns unavailable. Two views exist solely to declare routes that are not live.
- Not available, released or purchasableNone of the three. The design is documented; the service is not running for customers
- No restore has been rehearsed in angerAn evidence system that has never restored anything has not proven anything, which is why rehearsal is modelled as a first-class job
- Design quality is not operational evidenceNothing here has been proven under load, against a real adversary, or in a real dispute
Where XO Vault will sit
The evidence layer beneath the apps that produce authoritative records. In design.
XO Capture
Final evidence is admitted from Capture as an allowlisted source rather than uploaded.
XO Docs
Issued revisions are sealed as issued, not as a copy somebody kept.
XO Ledger
The Ledger records that events happened. Vault seals the allowlisted ones and governs how long they are kept.
Frequently asked questions
Is XO Vault available today?
No. It is unreleased, and not available or purchasable. The foundation flag defaults to off and every customer-facing route returns unavailable while it is. This page describes intended capability.
Can records be deleted?
There is no deletion endpoint. The eligibility report is report-only and the permission to authorise deletion exists as a reserved, inactive definition. That is the point: a system that can delete has to prove it did not.
Is this write-once storage?
We claim immutability at the object layer and cryptographic attestation of exports. We do not claim write-once guarantees at the storage layer, and the distinction matters enough to state it.
How does retention work?
Policies are versioned and anchored to dated events rather than to when a record arrived, so a rule like "seven years after practical completion" is expressible directly. Retiring a policy does not delete it.
Does it use AI?
No. There is no model, no adapter and no seam for one.
What still has to happen before you would sell this?
A real tenant with records sealed from all three sources, a rehearsed and recorded restore, an evidence bundle exported and receipted end to end, and a review by someone who would have to defend that bundle in a dispute.
Follow XO Vault as it is built
See the design, and the list of things that have to be true before we claim any of it publicly.