Your data.
On your terms.
Your business data stays in the systems that own it: your ERP stays your ERP. Xema keeps who and what each thing is, and who may do what to it. Putting agents to work on real material then raises the questions a policy document cannot enforce: who owns this, who may see it, how sensitive is it, where is it allowed to run, 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.
1Containment is read out of the name
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.
2A person's name does not pass through a company
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.
3The more specific one wins, by a stated order
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.
1An expiry that actually expires
A share with an end date stops granting the moment it lapses — it is checked against the current time 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.
2Owners and the people they shared with are different
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.
3Outside the company is capped per kind
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.
4An administrator cannot help themselves
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.
- 01Public · no restriction
- 02Internal · inside the organisation
- 03Confidential · need to know
- 04Secret · tightly held
- 05Regulated · under an obligation
A run asks to read
The Q3 supplier contract
- resolved: OrganisationInternal · set
- resolved: ProjectConfidential · raised
- resolved: DocumentConfidential · inherited
- refused: Ceilingthis environment allows Internal
- passed: Auditrefusal recorded, with its code
1Saying nothing means inheriting
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.
2The ceiling is what refuses
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. Sensitivity works as a floor: Public < Internal < Confidential < Secret < Regulated. A child Space can never be classified below its parent, and lowering one is a privileged, audited downgrade.
3You see what it will block before it blocks anything
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”.
4The preview is the real thing
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.
5Going down is not an ordinary edit
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. Models follow the same choice: pick the provider per task, including a model on your own servers.
1Your own machines, if that is the requirement
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.
2A promise it cannot keep is refused
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.
3A pool that is not taking work does not get any
A pool being drained or stood down is a hard refusal at dispatch, not a queue that fills up quietly while nobody is listening.
4Every organisation gets its own execution namespace
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.
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.
1How long things are kept is yours to choose
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.
2A legal hold can be placed by you, and lifted by someone else
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.
3Erasure reaches everything, or it fails
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.
4A hold vetoes an erasure — and so does an unreadable one
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.
5A service that could not erase refuses to start
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.
Say what is running.
Show it to anyone who asks.
Regulators, auditors and your own risk team ask the same few things. Xema keeps the answers as part of the platform, so nobody has to assemble them by hand.
1An AI bill of materials
For every agent: the models, tools, skills and data sources it uses, and the version of each. One list, always current.
2EU AI Act risk classes
Tag each agent or process with its risk class. The class sets the controls it needs, such as an approval or a human in the loop.
3Labels travel with the data
A sensitivity label follows the data into every answer built from it. Something made from Confidential material is not quietly Public.
4Spend ceilings
Set a budget per team, project or lane. A run that would cross it is stopped, and the stop is in the audit log.
5Evidence on request
Export what an auditor needs: who held what, who approved, what was refused. It is the same hash-chained audit, in a file.
Governance,
on one screen.
All of the above has one entry point in the product: 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.
At a glance
- one ownership model, everywhere
- promote instead of copying
- shares that expire on time
- sensitivity that only ever rises
- see what a restriction blocks first
- placement declared, never guessed
- roll back by moving a pointer