How the infrastructure fits together.
From raw information to living, usable and verifiable knowledge. Simple to understand from the outside — rigorous underneath.
Two products, one architecture.
Each product is sold on its own. Technically, each hands its output to the next — that is what makes the layer verifiable end to end.
Parser
Understand reality — documents and media into high-fidelity structured evidence.
available in pilot →Verifiable Knowledge
Prove it — one governed knowledge base with origin, versions, evidence and lineage, served to any AI.
available in pilot →Living Knowledge
Stay correct — sources watched, change governed, history preserved. A recurring solution on the two products.
the solution →Architectural invariant
The knowledge base is never edited directly. Every change re-enters through Parser and is adjudicated and versioned — with contradictions and history preserved.
Structure. Prove. Stay correct.
The transformation ends in an asset you own. The fork is architectural, not marketing: your knowledge asset feeds any model directly — or is served by Orves as knowledge objects. Continuous monitoring keeps it current either way.
embeddings · retrieval · fine-tuning · training data · agents
Every hop produces a certified artifact.
Nothing is passed along as an opaque blob. Each product consumes a certified artifact and emits the next one — addressable, versioned, verifiable.
| Product | Consumes | Produces | Certified |
|---|---|---|---|
| Parser | documents · sources | canonical text · structure atoms · spans | always |
| Verifiable Knowledge | certified parses | knowledge objects · versions · projections · grounded answers · abstentions | always |
| Continuous monitoring | declared sources | admission decisions · governed updates | rolling out |
Products are what you buy. Engines are how they work.
Internally, the platform runs specialized engines — you never buy them, and you never have to understand them. The distinction is deliberate: product ≠ implementation.
Inside Verifiable Knowledge
canonicalization · dedup · claims · resolution · memory · retrieval · knowledge graph · policies
The Knowledge Engine governs claims, evidence and versions — the core the product is built on. You buy the outcome; the engines are how it works.
Across everything
certification · provenance · lineage · versioning · governance · IDs · hashes · resolution states
Trust capabilities are transversal — properties of every artifact, not features of one product. How trust works →
Properties, not promises.
These are architectural invariants — enforced by construction and verifiable by mechanism, not slideware.
Canonical first
One canonical representation per document. Everything downstream — chunks, datasets, indexes — is a projection that can be re-derived and proven equivalent.
Determinism
Same input, same version, same output. Replay is a feature of the architecture, which is what makes audits possible at all.
Evidence is primary
Knowledge is derived. No claim exists without an evidence chain reaching back to a source span and a file hash.
UNKNOWN ≠ PASS
Uncertainty is a first-class state that propagates. Nothing turns green by default, and abstention is measured like any other outcome.
No lock-in
The canonical substrate is model-ready by design. Your knowledge works with any AI — Orves has to win on merit, not on capture.
Immutable ledger
Every artifact, every version, every transformation recorded append-only. Corrections are new entries with lineage — never rewrites.
45 seconds, no narration.
Sources drawn into the core, structure preserved, knowledge certified — and an honest ABSTAINED when evidence is insufficient.
API-only, by design.
The platform is delivered exclusively through the API. Nothing is installed on your side, and price logic lives only on the server. Thin SDKs exist for convenience — they are disposable; the platform is not.
Integrate in minutes.
Everything is delivered through the API. Nothing to install, nothing to host.