The Runtime, in Depth

The payoff: what runs in production is generated from, and stays true to, the knowledge your experts approved, and it scales across your data without a re-architecture.

This page goes under the hood of how verified knowledge runs at scale, the graph engine, the schema language it compiles to, and how it distributes. It is written for technical evaluators, with a short summary above each diagram so the through-line stays clear whether or not you read the diagrams themselves.

Where Verified Knowledge Runs

Once your knowledge is proved, it runs over your live data in an engine whose structure comes straight from that proved knowledge, not a database schema someone maintains by hand. Built on a distributed, battle-tested foundation, it keeps what runs in production from ever quietly drifting away from the knowledge your experts approved.

How the Knowledge Is Represented

Inside the engine, every concept and relationship is a formally typed node, so the graph can only ever represent what your ontology actually allows. It refuses to store what the logic forbids, ruling out whole classes of bad or contradictory data before they can reach the systems that depend on them.

The BFO-Typed Hypergraph

The graph refuses to represent what the standard forbids. Because both the things and the relationships between them are ontologically typed, a contradiction cannot be quietly stored and discovered later. It is rejected as it is written.

Cells, the things

Every entity in the graph is filed under one of four fundamental categories from the standard, so nothing is stored as a loose, untyped record.

Continuant Occurrent Spatial region Temporal region

How it works

The graph root partitions every cell into BFO’s four leaves of Entity. Each cell type carries a BFO IRI and its hyphenated CLIF name, and is read through zero-copy byte-pointer accessors rather than serialized objects, roughly 465 accessors generated from 146 cell definitions.

Relations, the connections

Relationships are first-class entities with their own identity and time, not just pointers between records, so “this was part of that, during that period” is something the graph natively knows.

part of has participant inheres in realizes concretizes occupies region

How it works

Each relation is a hyperedge cell whose endpoints are cell-id lists, stored temporalized as three-place facts indexed by time. Logical properties such as transitivity and antisymmetry are enforced, alongside Allen interval verbs for time and RCC-8 verbs for space. The visible chip “part of” is the plain-English form of the canonical BFO/CLIF relation continuant-part-of.

Asking the graph a question

Queries walk typed relationships instead of joining tables, so a question is expressed the way a domain expert would phrase it: start here, follow this relationship, keep what matches.

StartFrom(cell) .FollowEdge(ContinuantPartOf) .VisitNode(predicate)

How it works

LIKQ fan-out search resolves in-process on a single node, or across nodes through RPC hypergraph-query processors. Zero-copy accessors keep individual cell reads in the sub-microsecond range.

Consistency is proved, never asserted, and here is the honest state of it

Theory-level consistency is discharged by the theorem provers, not claimed by the store. Two layers do two different jobs. The provers settle whether the theory itself is consistent. Generated runtime validators enforce the per-fact constraints as data is written, and they ship in every target language.

How it works

The catalogue runs to around 355 BFO 2020 axioms. Runtime validators are generated into all five SDK languages, covering relation algebra (transitivity, symmetry, antisymmetry, reflexivity, irreflexivity), category disjointness, dependence constraints such as inherence uniqueness and the quality-bearer requirement, mereology, and RCC spatial relations. Theory-level questions still go to the ATP substrate through OntoEnact, because whether a theory admits a model is a different question from whether a fact being written breaks a constraint.

The engine grades its own grounding

You can ask a running engine how well grounded its own ontology is, and it will tell you where it falls short. A substrate report scores seven dimensions: grounding-chain completeness, schema conformance, axiom coverage, relation-property compliance, category conformance, entailment, and ATP consistency. It returns a composite alongside the specific gaps behind each one. How many concepts lack a BFO IRI. How many cell types are ungoverned. Which ancestor chain fails to reach the root universal.

A companion pass proposes repairs for those gaps, and it is deliberately conservative about which it will act on. Deterministic repairs the top-level ontology fully licenses are proposed at confidence 1.0. Anything inferred sits below a threshold and is marked for human review instead of applied. A third class, such as a broken ancestor chain, is reported and never auto-patched, because no amount of confidence makes it safe to guess. Gaps the tool declines are counted and the reasons are retrievable.

This is the same discipline as the prover verdicts. The system is allowed to say it does not know, and a low-confidence suggestion is never quietly promoted into a fact.

A contradiction cannot sit in this graph long enough for anyone to read it.

Powered by OntoMotion™

OGSL — the Ontological Graph Schema Language

The graph's structure is written in a schema language that is itself derived from your verified ontology and proved before use, so when the knowledge changes, the structure regenerates instead of drifting, sparing your teams the expensive re-engineering that keeping software current with changing rules normally demands.

#ontologyspec {
    bfo: {
        category:   Entity;
        iri:        "BFO:0000001";
        clifname:   "entity";
        label:      "Entity";
        definition: "An entity is anything that exists or has existed. The most
                     general BFO 2020 universal, partitioned exhaustively into
                     continuants and occurrents.";
        level:      TLO;
    }
    clif: {
        module:       "universal-declaration";
        axioms:       [nmq-1, mbf-1, uns-1, qaf-1, oap-1, lqn-1, nis-1, bee-1];
        outdiscourse: ["entity", "continuant", "occurrent", "particular",
                       "universal", "instance-of", "exists-at"];
        formulas: [
            "(forall (x) (if (entity x) (or (continuant x) (occurrent x))))"
        ];
    }
    validation: { ontoenact: strict; phase: both; }
    codegen:    { targets: [csharp, cpp, rust, go, java]; }
}

[BFO_IRI: "BFO:0000001",
 BFO_CLIFName: "entity",
 BFO_Label: "Entity",
 BFO_TLO,
 BFO_Universal,
 CLIF_Source: "universal-declaration.cl",
 BFO_AxiomIds: "nmq-1,mbf-1,uns-1,qaf-1,oap-1,lqn-1,nis-1,bee-1",
 GraphNode,
 HyperNode,
 OntoEnact: "strict",
 AxiomValidation: "both",
 GenerateValidator: true,
 Observable,
 CodeGen_Target: "all"]
cell EntityEnhanced {
    // Fixed-width fields first, so the cell packs for zero-copy reads
    [BFO_TemporalParameter]
    DateTime CreatedTimestamp;

    [BFO_TemporalParameter]
    DateTime ModifiedTimestamp;

    bool IsActive;

    // BFO 2020 category, which is what makes type checking possible
    [Index, BFO_Role: "Category"]
    string Category;

    [Index, BFO_Role: "Identifier"]
    string EntityId;
}

How It Distributes

The engine is designed to run across a cluster, spreading your data out while keeping every result consistent, so the platform grows with your data instead of forcing a re-architecture as you scale. Today's published performance figures are single-machine. The distributed design is built in from the start.

Streaming, Full-Duplex Execution

Once verified workflows are running, the engine and your systems hold a symmetric, full-duplex conversation, either side can start work, stream data, or observe decisions as they are made. Long-running processes stay live and auditable rather than fire-and-forget, keeping people and systems in the loop on every decision at the moment it happens, not after the fact.

Want a working session on the architecture? Let’s set one up.