Every value on this page — the shard id, the counts, the sample rows — comes from actually running the exit against the synthetic sample checked into this repository. Run it yourself:
# the three GETs happen out of band, with the customer's own bearer token, # against the vendor's PUBLISHED Ontology API v2 — not shown here, never # our credentials, never a live tenant in this repository curl -H "Authorization: Bearer $CUSTOMER_TOKEN" \ https://<tenant>/api/v2/ontologies/<ont>/objectTypes > capture/objectTypes.json curl ... /objectTypes/{type}/outgoingLinkTypes > capture/linkTypes/<type>.json curl ... /objects/{type} > capture/objects/<type>.json
From the capture, one command parses it, seals it through genesis, and verifies it detached — then a second command mounts the sealed shard into the repository's own query engine (axiom_runtime.engine.SpectraEngine, see tests/test_foundry_ontology_exit.py::test_sealed_ontology_is_queryable_through_spectra) and asks it questions. What follows is a recorded replay of exactly that session, captured verbatim:
▶ Recorded replay — verbatim output from a real foundry_exit run on the synthetic sample. Not a live terminal; nothing executes in your browser.
The sample declares 1,200 Patient instances but only 5 rows were captured in this run. Both numbers are sealed as separate claims — instance_count_declared and instances_captured — so a partial pull can never quietly pass as a complete one. All five rows below are synthetic: invented reference numbers, placeholder names.
| patientRef | given name | family name | registered practice |
|---|---|---|---|
| SYN-0000000001 | Ada | Testcase | SYNTH GP PRACTICE A |
| SYN-0000000002 | Grace | Placeholder | SYNTH GP PRACTICE A |
| SYN-0000000003 | Alan | Sample | SYNTH GP PRACTICE B |
| SYN-0000000004 | Edith | Fixture | SYNTH GP PRACTICE B |
| SYN-0000000005 | Mary | Synthetic | SYNTH GP PRACTICE C |
5 of 1200 declared — captured, not invented away. Not valid NHS numbers. No real person, practice, ward, or clinician is represented.
This page walks through one real run of the Ontology Exit: a small NHS-shaped ontology pulled out of a vendor data platform with the customer's own credentials, and resealed into a genesis-signed record that verifies with nothing but its own bytes and an out-of-band key.
Four object types, drawn as an ontology graph in the shape every enterprise-ontology tool renders. On the stage above, the left panel is walled inside a vendor data platform; the right panel is the identical structure, reconstructed on your side — sealed, portable, and verifiable without the vendor in the loop. Here is what each side of that stage is actually saying.
A generic vendor data platform — a Foundry-shaped silo. The wire shape is Palantir's published Ontology API v2; nothing here is a claim of access to, or affiliation with, an actual Palantir tenant. You can see the ontology in the vendor's console. You cannot take it — not the structure, not detached, not on your own authority. Clinician has no captured link in this run — shown honestly, not hidden.
The same structure, reconstructed on your side. Genesis-signed. Detached-verifiable with an out-of-band key. No Palantir, no AXM, no vendor required to hold or check it. Unlocked, portable, queryable — and the declared-vs-captured gap is shown, not smoothed over: a partial capture, honestly labeled.
A CSV export gives you rows. It does not give you the object types, the typed properties, the links, the cardinalities — the ontology that makes the rows mean anything. That structure usually lives only inside the vendor's platform, reachable only through the vendor's tools, on the vendor's terms.
The Ontology Exit takes the structure out too. The stage above is one real, reproducible run of it against a synthetic NHS-shaped ontology, shown as a familiar node-and-link ontology graph — walled on one side, sealed and yours on the other.
Ontology structure — object types, typed properties, primary keys, links, cardinalities — and object instance data, both promoted to signed claims and preserved byte-for-byte as verbatim API responses.
The workflow layer: pipelines and transform code, Actions and Functions, Workshop/Slate applications, and the permission/security model. Not yet exited. Not implied here.
"Export your ontology and data" is true today, for this repository, against a synthetic sample. "Export your workflow" is not — and this table says so plainly rather than letting the graph above imply more than it proves.
| Vendor platform surface | Does this exit cover it? |
|---|---|
| Ontology structure — object types, properties, primary keys, links, cardinalities | YES — promoted to genesis claims, queryable via Spectra |
| Object instance data | YES — sealed as verbatim content; declared vs. captured, never hidden |
| Verbatim API responses (audit trail of what was pulled) | YES — sealed byte-for-byte |
| Pipelines / transforms (code) | NO — not yet — the operational moat |
| Actions / Functions | NO — not yet |
| Workshop / Slate applications | NO — not yet |
| Permission / security model | NO — deliberately not carried — no vendor ACLs made portable |
This channel is inert by design. It carries real records only when a data controller with the lawful authority to release them decides to authorize it — never covertly, never as a quiet parallel intake of real data. That authorization would itself be a sealed, custodied record, subject to the same verification as everything else here.
In this repository the gate is honored the only honest way available without a real controller: the data is synthetic, precisely because no such authorization exists. The channel is ready and standing. Whether it ever carries anything real is a decision for a customer with an actual tenant and the authority to make it — not a decision this demo makes for them.