The platform, installed
in your building.
Oria runs on your side of the wall, on your ontology, on your GPUs.
ARPIA Edge is the runtime you install in your own datacenter. Your people keep using Oria exactly as they would on our cloud: they ask, it reasons over the ontology and the institutional memory, it builds what they need. Only now the data, the keys, the inference and the audit trail never leave your infrastructure. We publish the applications from our side; the execution, and everything it touches, is on yours.
The data cannot leave, and the transfer cannot be justified.
If you hold patient records, client files, case work or anything covered by professional secrecy, the question you are asked is not which model you use. It is who else could read the file, and under whose law. A cross border transfer has to be justified, and a hosting region does not answer it: the operator of that region still has the keys and the access path.
- Your obligation is not to keep the data in a country. It is to keep it out of reach.
- An assistant that reads your files holds your context, wherever the servers are.
- A policy commitment is auditable only as a document. An architecture is auditable as a system.
The Factory builds. The Edge executes.
One line splits the platform in two, and everything else follows from it. Executing a governed use case goes down to you. Generating one stays up with us.
Factory, in our cloud
Where a use case is authored: the ontology, the reasoning, the code generation, the governed flow. This is our engineering, and it works against test data. It never holds your production data, because it never needs it.
Edge, inside your walls
Where it runs: on your production data, your keys, your cluster. It executes what the Factory produced and it cannot author anything new, which is exactly why you can let it near the data.
The asymmetry is deliberate on both sides. You get an executor you can inspect, and inspecting it tells you how a use case runs, not how we build them. We keep the part that is hard to build, and we keep it away from your data. Neither of us has to trust the other with what they cannot afford to lose.
One runtime, four things running on your cluster.
Edge is not a copy of the platform. It is the part that executes, packaged to be installed and operated by your team on your own Kubernetes.
Oria, locally
The same surface your people already use, answering from your local ontology and institutional memory. Sessions, artifacts and live apps stay inside.
The ontology, resident
Your model of your business, held locally so the runtime resolves and runs with no call out to us. The applications read it in place.
Execution and inference
Governed code runs in ephemeral containers on your cluster, and the models can run on your own GPUs, so no prompt and no record reaches a provider.
The update centre
Where your administrator sees what we published, reads what changed, applies it, refuses it or rolls back. It is also the local admin surface.
What you do not install is the part that builds. That stays with us, and it is the reason we can hand you the rest.
We publish from our cloud. It lands as a version you approve.
An application built on ARPIA is not code you have to redeploy by hand. It is packaged as one versioned release, carried down to your Edge and applied in a single transaction: the applications, the ontology they need, the governed actions and the executable code, all in the same package.
Your team keeps building too. What a Builder makes on the platform ships down the same path, so the local runtime and the work your people do stay in step without anyone copying files between environments.
- One release, one point in time, applied whole or not at all.
- Applying it twice changes nothing the second time.
- Rolling back is installing the previous release, not a recovery procedure.
- Every application lands in your own release log, with what came and from where.
Every piece, and who can read it.
The useful version of this conversation is not a diagram, it is a list of what sits where. This is the design, line by line, including the line that says what we keep.
| What | Where it lives | Who can read it |
|---|---|---|
| Production dataplaintext and keys | Your environment, on storage you control, encrypted with keys you hold. | You only |
| Model inferencethe reasoning itself | Your own GPUs, locally, so no prompt and no record is sent to a model provider. Pseudonymisation only matters if you deliberately call an external model. | You only |
| Logs and audit trailwho ran what, on what | Local tables on your side, deliberately outside the delivery path, so they cannot travel even by accident. | You only |
| Ontology and use case configyour model of your business | Authored in the Factory, delivered down to you, held locally so the runtime works with no dependency on us. | Both |
| The authoring enginehow use cases get built | Our cloud. It is our engineering and it stays with us, which is the other half of the bargain. | Us only |
Nothing updates itself.
Sovereignty that ends at the data boundary is half an answer. The other half is who decides when the thing running on your data changes, and whether you can prove afterwards what changed and when.
- No release installs itself. Your administrator applies it, or does not.
- Applying one is a governance event on your side: which release, by whom, when.
- The reviewer who approves what the AI may do is your person, in your building.
- Refusing an update is a supported state, not a failure. You can stay where you are.
The reviewer who approves what the AI is allowed to do also stays on your side. Nothing about that step travels to us, which is what makes the human in the loop worth having: the approval and the record of it live in the same place as the data.
The result is a system whose changes you can reconstruct without asking us for anything.
The cargo is real. It has moved between datacenters.
The mechanism this model depends on is not a diagram. A complete use case, built in one of our datacenters, has been packaged, carried to another and applied there, by hand, end to end. What that package carries and guarantees:
- The executable code travels inside the release, not a reference to something it would fetch later.
- The ontology travels with it, so what arrives is what runs.
- It is a snapshot of a published state, never a live copy of whatever the source was doing at that second.
- It tells you what already exists before it writes anything, and names the conflicts.
- Identities and system connections are rewritten for the destination, so the arriving copy points at your systems and not at ours.
- Both sides keep a record: what came, from where, with which warnings.
That is the part a technical evaluation can push on, so it is the part we lead with.
In your jurisdiction, by an operator inside it.
For regulated work the cleanest structure is not a contract with a foreign vendor. We license the platform to an operator established where you are, who runs it on infrastructure in your country and holds the relationship with you. We are the technology licensor: no custody of your data, no independent access path to it.
Continuity is part of the licence rather than an assurance: if support ever stops, the right to keep operating the runtime does not.
- Your counterparty is local, and so is the infrastructure.
- We hold no copy of your data and no key to it.
- The runtime keeps running if the commercial relationship does not.
Bring your constraint.
Tell us what your data is not allowed to do and which authority says so. Thirty minutes is enough to tell you whether this architecture answers it, and where it does not yet.