Your data.
On your terms.
Putting agents to work on real material raises the questions every other AI tool leaves to a policy document: who owns this, who may see it, how sensitive is it, where is it allowed to run, what was recorded, and what happens when it has to go. Xema answers each of them in the product, the same way for every kind of thing it holds. Not a governance module. The way the platform is put together.
Everything ownable
has one name.
A skill, an agent, a credential, a connection, a stored result — each belongs to exactly one of seven places, and they are the same seven for all of them. That is not tidiness. It is what makes "move this up to the whole company" a single operation instead of a feature each part of the product has to grow separately — and it is why a setting you make on your project behaves the same way as one made on your organisation.
An app's name says which project it is in, and that project's name says which organisation. There is no second copy of the hierarchy kept alongside, so there is nothing for it to fall out of step with.
Walk your own address and you get you, then the platform. An organisation is not a step on that walk — not because a rule forbids it, but because it is not on the path.
When two answers exist for the same thing — one on your project, one on your organisation — the narrower one is served. The order is written down and checked against the structure, rather than inferred from it each time.
Good on one team.
Now good everywhere.
Somebody works out how a job should be done and captures it — as a skill, as an agent, as a set of tools. Everywhere else, publishing that to the rest of the company means duplicating it, and from that moment there are two of them drifting apart. Here it is one operation: the same thing, now owned a level up. There is no second copy to keep in step.
It only ever goes wider. Narrowing something is not offered, because it would quietly strand everyone already relying on it — if you want a narrower version, you write one, and the original keeps working.
Share it. Say how far.
Say until when.
Documents, mailboxes, portals and store listings can be shared with a person, a team, an agent, a role, somebody outside your company, or your whole organisation at once. The levels on offer are the ones that mean something for that kind of thing — a document has view, edit and manage; a mailbox has read and manage, and deliberately no "edit", because there is no such act.
A share with an end date stops granting the moment it lapses — it is checked against the clock on every permission decision and on every listing, so nothing waits for a nightly job to notice. The thing also disappears from what that person can see, rather than staying visible and failing when opened.
Only an owner sees the full list of who else has access, and only an owner opens something to the whole organisation. Somebody you shared with can never pass on more access than they hold, and can never take away a share that outranks theirs.
Each kind of thing declares how far an external person may ever be taken — a document tops out at view-only, and a mailbox cannot be shared outside the organisation at all. The cap refuses; it does not quietly downgrade what you asked for.
There is no admin override that silently opens someone else's material. An administrator who needs access asks for it, and the owner answers — which is a request with a name on it rather than an entry nobody sees.
Say how sensitive it is.
The platform does the rest.
Set a level on your organisation and everything inside it inherits that as a floor. A project handling something touchier raises its own; a document inside that project can raise again. What applies to any one thing is the most restrictive answer anywhere above it — so nothing inside can ever quietly loosen what the level above decided, and there is no ordering trick that lets it.
An unlabelled thing is not quietly assigned a default — it simply takes the level of whatever contains it. And where nothing has been declared anywhere, the platform says so rather than showing you a value nobody chose.
Every environment work runs in carries a ceiling. When something's sensitivity is above it, the run is refused at the decision — not flagged in a report afterwards. Environments start at the most permissive setting, so lowering one is literally the act of switching restrictions on.
Before a lower ceiling is saved, the platform shows you exactly what would start being refused — and, for each one, which setting decided it, so you know where to go. You cannot save a ceiling you have not previewed; the one thing that button will not do is “save anyway, we couldn't check”.
The dry run and the live decision are the same piece of code answering the same question. What the preview showed you is what will happen, because there is no second implementation to disagree with it.
Raising a level is a plain save and ends there. Lowering one is measured first — the platform works out what becomes less protected and records that alongside the change — and it can be put behind sign-off from a named data-governance group, in which case nothing is written until they answer.
Placement is declared,
never guessed.
An organisation names the pool of machines its work runs on, and every run is dispatched to that pool. There is no fallback branch: if the platform cannot read where your work is supposed to go, the run is refused. Quietly relocating work because a lookup failed is the one outcome that must never happen.
Run the workers yourself and they pick up only your organisation's work. Work that must stay on your own infrastructure is dispatched only to machines that are on it — the ones that are not are removed from consideration before anything is chosen, rather than ruled out afterwards.
Where a requirement cannot actually be enforced by the platform, the work is refused rather than run with the requirement assumed. An unenforceable guarantee is worse than an absent one, because everybody plans around it.
A pool being drained or stood down is a hard refusal at dispatch, not a queue that fills up quietly while nobody is listening.
Your runs execute in a namespace of your organisation's own, created the first time you need one — not a shared queue with a tenant column on it. A run is refused rather than started into a namespace whose retention the platform could not verify.
A record that
verifies itself.
Everything an agent invokes passes one router, and it records what it allowed and what it refused, each with the reason behind it. Your organisation's own record is searchable by the thing that was touched, by the permission that allowed it, and by the request it belonged to — and exportable as a pack you can hand to somebody.
The entries are chained together, and you can ask the platform to re-derive that chain and report any break. Deliberately, the rule for turning an entry into the bytes that get chained lives outside the service that writes the log: a record only the author can check is not evidence, because the party a record protects against includes whoever runs the installation.
The asks that need you
land in one queue.
Approving a lowered sensitivity level, letting a new package go live, moving a connector, granting somebody access, clearing a listing for the store, releasing a held email — they all arrive in the same place, look the same, and are answered the same way. You can answer, take your answer back, or put it off. Nobody has to learn six inboxes.
An ask can require a number of people to agree before it goes ahead — while a single refusal settles it on its own. That asymmetry is the point: a quorum should make approval harder, never make objecting harder.
Address an ask to a team and it is expanded to the people in it at that moment, and kept. Someone who joins tomorrow is not silently added to a question already in front of others, and someone who leaves does not vacate a seat that was already counted.
If the directory cannot be reached, the ask is refused rather than sent to an empty audience — which would otherwise look exactly like a question awaiting an answer that can never come.
Deadlines say what they do. One closes the question for good; another simply drops it out of the everyday queue while leaving it answerable, so a late reply still counts instead of hitting a wall.
Nothing is lost.
And when it must go,
it actually goes.
Every skill, agent, process, result and app keeps its earlier versions as they were — nothing is edited over the top. Going back to one is a matter of pointing at it again: no bytes copied, no re-checking, nothing destroyed on the way, and the version you left behind still sitting there. Roll an app back to any earlier release and it is live again in one click.
Your organisation sets its own retention window, within whatever bounds the installation allows — and can see what window is actually in force for any kind of thing before changing anything.
You can put a hold on your own material whenever you need to preserve it. You cannot lift one — lifting is what lets deletion start again, so it deliberately sits with a different authority. Placing always preserves more; that direction is safe to give away.
Erasing an organisation is one operation that fans out to every service holding any of its data — dozens of them. Each one proves the rows are gone by counting them afterwards rather than trusting its own report, and any failure stops the run loudly instead of being written down as a success.
A preservation order outranks a deletion request, and the erasure refuses rather than deleting around it. If the platform cannot tell whether a hold exists, that also refuses: a wrong answer here destroys material under a court order and nothing recovers it afterwards.
A participant that would silently delete nothing and report success is caught when it is deployed, not during somebody's data-subject request. It fails to boot rather than advertise something it cannot do.
Governance,
on one screen.
All of the above used to be spread across nine separate screens, which for the person who would rather not think about any of it is nine places to not think about. It is now one entry point: permissions and roles, who was granted what and until when, the environments work runs in and the ceiling each enforces, every capability on the installation and its risk level, the policies in force, and what each installed package contributes.
Now see how far
an agent reaches.
Governance decides what happens to the things agents touch. The other half is how far any one agent is allowed to reach in the first place — and that is decided on the path of every call it makes.
Trust & control →