Use case
Public sector
Sovereignty and auditability are not negotiable line items.
Procurement is long, the systems are old, and the accountability is real. An agency cannot adopt a tool whose data path it cannot describe, and cannot defend a decision it cannot reconstruct.
That rules out most of the current AI tooling market on structural grounds, before anyone evaluates whether it works.
01 — Where it stalls
What actually slows this down
Data residency is a hard constraint
Where the compute physically runs is a matter of policy, sometimes of statute, and is not resolved by a vendor's assurances.
Decisions must be reconstructable
Months later, someone will ask what changed, who approved it, and on what basis. That answer has to exist.
Skills are hard to retain
The engineer who understood the integration moves on, and the knowledge leaves with them unless it was written into the system.
02 — What Orfyn takes on
The work that stops being manual
- 01
Run entirely on infrastructure inside your own jurisdiction and control
- 02
Keep the full change history as diffs and branches rather than as chat logs
- 03
Standardise recurring integration work so it survives staff turnover
- 04
Select model providers — including self-hosted ones — to match policy rather than convenience
- 05
Give oversight staff read access to what agents did without giving them the ability to run it
03 — The deciding constraint
You choose the jurisdiction, because you choose the hardware
There is no hosted service to locate. The daemon runs on the machine you put it on, in the facility you chose, using provider keys you issued — which makes residency an infrastructure decision rather than a contract negotiation.
Walk us through your version of this.
Bring one workflow you are trying to ship. We will go through what it touches, where it stalls today, and what running it on Orfyn would look like.