Platform
Portability — leave without a rewrite, and we say how far
Oraclous Portability routes every export through OHM, the open manifest, with an open reference runtime — no vendor lock-in. The docs state exactly what travels and what doesn't.
Portability is the property that OHM — the open Oraclous Harness Manifest — and an open reference runtime let you leave without re-implementing your work. There’s no lock-in. And, because honest scope is a feature, the docs name exactly what portability carries and what it doesn’t.
Read portability docs → Review the trust model →
Can I leave without a rewrite?
Yes — your Harnesses are portable through OHM, the canonical hub every portability operation routes through. Oraclous publishes both the manifest format and a reference runtime, and locks you into neither: every inbound translation produces OHM, every outbound translation starts from OHM, and the reference runtime is open, so the manifest you export is something you can actually run. That’s what “no vendor lock-in” means here — not a marketing promise, but a manifest you own and a runtime you can read.
Citable answer — Can I leave Oraclous without a rewrite? Yes. Oraclous routes every portability operation through OHM, the open Oraclous Harness Manifest, and publishes an open reference runtime — so your Harnesses are exportable and runnable without re-implementation. The docs also state plainly what portability does not carry: knowledge-graph data exports via Neo4j/RDF/JSON-LD, and credentials, the ReBAC graph, and Consciousness records do not travel.
What is OHM? → · What is Portability? →
How does portability work?
OHM is the hub; everything routes through it. Inbound, three adapters translate external formats into OHM: a Claude Code SKILL.md adapter (SKILL.md → OHM skills), an MCP tool adapter (MCP tool definitions → OHM tools), and an OpenAPI 3.x adapter (one OHM tool per operation). Outbound, the same hub model means your work can leave in the formats the wider ecosystem speaks — to Claude Desktop and Claude Code SKILLs, over MCP, and as OpenAPI — because the manifest is the common currency on both sides. Pair this with the open reference runtime and an exported OHM isn’t a dead artefact; it runs.
This is why portability is more than an export button. The unit you take with you — the OHM manifest — is the same governed unit Oraclous ran: a goal statement, an actor roster, an orchestration spec, triggers, and a policy envelope. You leave with the work as it was described, not a lossy snapshot of it.
What does portability not cover?
Naming the boundary is the honest part, and the credible one. Per the architecture’s portability section, four things do not travel with an OHM export:
- Knowledge-graph data — your organisational memory is handled through standard export formats (Neo4j dumps, RDF, JSON-LD), not through OHM. It’s exportable; it just leaves by a different door.
- The member directory and ReBAC graph — platform-internal. Your relationship-based access structure is rebuilt in the destination, not serialised out.
- Credentials — they never leave the Credential Broker in plaintext, by design. Portability does not, and should not, exfiltrate your secrets.
- Per-Actor Consciousness records — substrate-anchored. Exporting a Harness exports its OHM definition, but not the accumulated learning an Actor built up over time.
We state these in writing because a security or compliance leader and an OSS evaluator both reward the disclosure and punish the over-claim. “Total portability, zero lock-in, leave with everything” is the sentence that fails a procurement review. “Here is exactly how far it goes” is the one that passes.
Why does portability matter?
Lock-in is the quiet cost of every closed agent platform: your data, your governance, and your exit belong to someone else’s roadmap, and the day you want to leave you discover the door was never built. Oraclous builds the door first and labels it. For regulated and security teams, portability plus stated limits is an auditable exit story — no surprises at the boundary. For multi-model teams, it’s the platform-level twin of the model freedom that BYOM gives at the model level.
Portability completes the openness triangle. With BYOM the model is yours to swap and MCP & widgets keeps you connected to the broader tool ecosystem both ways, Portability ensures the platform itself is something you can walk away from — manifest in hand.
Frequently asked questions
Q: What is OHM?
A: OHM (Oraclous Harness Manifest) is the serialised, portable form of a Harness — YAML with embedded Markdown, written to .ohm.yaml. It has a structured zone of machine-validated fields and a prose zone of model-interpreted instructions, and it’s the canonical hub every portability operation routes through, so you can leave without re-implementing.
Q: What does portability not cover? A: Four things don’t travel in an OHM export: knowledge-graph data (handled via Neo4j/RDF/JSON-LD exports instead), the member directory and ReBAC graph (platform-internal), credentials (they never leave the broker in plaintext), and per-Actor Consciousness records (substrate-anchored). The docs state this plainly so there are no exit surprises.
Q: How do I export my work? A: Through OHM, the canonical hub. Your Harnesses serialise to OHM manifests, which the open reference runtime can run, and outbound paths reach Claude Desktop, Claude Code SKILLs, MCP, and OpenAPI. Knowledge-graph data exports separately via standard formats (Neo4j dumps, RDF, JSON-LD).
Q: Does “no vendor lock-in” really mean no lock-in? A: It means your Harnesses are portable through the open OHM manifest and runnable on the open reference runtime — you can leave and re-run your work elsewhere. It does not mean every artefact travels: credentials, the ReBAC graph, and Consciousness records stay behind by design, and knowledge-graph data exports through standard formats. The boundary is documented, not hidden.