Platform · Architecture and Standards

The Architecture of Trust

Trustworthy software isn't the product of a single feature. It is built up in layers, each one depending on the one beneath it. This page follows that chain of trust from end to end: from the meaning your organization defines, to the verified software TruSpark™ delivers. Each layer compounds the assurance established by the layer before it.

Trust, Built by Stratification

Select any layer to open its technical detail.

1
Formal Ontologies
Establish an unambiguous, shared foundation of meaning.
2
Common Logic
Express that meaning precisely enough for a machine to reason over.
3
Automated Theorem Proving
Prove the knowledge is internally consistent — before anything is built.
4
Compiler Architecture
Generate executable software directly from the proved theory.
5
Proof Certificates
Emit portable, independently replayable evidence of what was proved.
6
Polyglot SDKs & Outputs
Deliver the verified core into your technology environment.
1

Formal Ontologies

Everything starts with meaning made explicit. A formal ontology defines the concepts, relationships, and rules of your domain precisely, and grounds them in a shared upper-level standard (BFO 2020) so that a term means the same thing across every domain, department, and system that uses it. That shared foundation is what lets knowledge from different parts of the organization work together instead of quietly conflicting, the misalignments that are expensive to discover late and harder still to unwind.

Isn't a taxonomy enough?

A taxonomy is an excellent starting point, organizing and classifying concepts into a clear hierarchy is genuinely valuable, and it is often where formal ontology work begins. A formal ontology extends beyond classification: alongside organizing concepts, it represents their meaning, the relationships between them, the constraints that govern them, and their logical behavior, in a form that can be reasoned over and formally verified. Put simply, a taxonomy tells you how concepts are categorized. A formal ontology also lets a machine reason about what those concepts mean and check that the result is consistent.

Why use a top-level ontology (BFO) instead of only domain ontologies?

Domain ontologies model knowledge within a specific field exceptionally well. A top-level ontology like BFO adds something a domain ontology cannot provide on its own: a common semantic foundation that keeps meaning consistent across many domains, departments, and enterprise systems. When every domain ontology is grounded in the same upper ontology, a concept defined in one place carries the same meaning everywhere it is used, so knowledge from different areas can be combined without the terms quietly drifting apart. Both layers have a role, the domain ontology captures the specifics of the field, and the top-level ontology preserves shared meaning across all of them.

TLO
Top-Level Ontology
BFO 2020 · ISO/IEC 21838-2

The shared foundation. When every layer of meaning traces back to one internationally agreed foundation, a term cannot quietly mean two different things in two different systems. That shared grounding is what lets knowledge from across your organization combine without drift, the precondition for AI whose conclusions can be explained and trusted.

MLO
Mid-Level Ontology
Concepts shared across domains

Captures concepts that recur across many domains but are not universal, so proven structure can be reused instead of rebuilt for every field — including, for example, a workflow ontology we provide for defining and checking business processes. The benefit is consistency: shared structure that has already been proved sound.

DLO
Domain-Level Ontology
Domain-specific concepts

Captures the specifics of a single field. TruSpark is industry-agnostic, the same architecture applies whether the domain is clinical research, financial services, or manufacturing; in each, your field's concepts, rules, and standards are expressed formally the same way, so its particular meaning is captured without loss.

ALO
Application-Level Ontology
Organization-specific rules

Captures the rules, protocols, and requirements specific to a single organization or application. This is where your own policies become formally expressed and provable, so the software reflects exactly how you operate, and every rule it applies can be traced and defended.

2

Common Logic

For software to reason about what your organization knows, that knowledge has to be written down in a language precise enough to leave no room for interpretation. Everyday modeling tools keep things simple so they stay fast, but simplifying is exactly what you cannot afford when a single definition carries regulatory or safety weight.

That is why TruSpark writes meaning in Common Logic (CLIF), a mathematical language that captures the full nuance of a regulated domain instead of a stripped-down approximation of it. The relationships, constraints, and rules that make your field what it is come through intact, ready to be proved and not merely stored.

CLIF is itself an international standard — ISO/IEC 24707:2018, so the language your meaning is written in is governed and auditable, not something Reasonics invented and asks you to take on faith.

Bring your existing knowledge

If your organization already has knowledge in OWL, OBO, or SKOS, TruSpark lifts it in and grounds it in CLIF automatically. You don’t rebuild what you already have.

Ingest — Existing Knowledge Lifted In, Not Rebuilt

Your ontology investment survives the move. Each format family gets a complete translation stack, never a thin shim that handles the easy cases and quietly loses the rest.

Every family is a full stack
Lexer
Parser
Translation
BFO-grounded CLIF
Proved, then generated
OWL / RDF / TTL

The largest translator. Class axioms, restrictions, and property characteristics all become logical statements, expressed in full first-order logic, so nothing has to be dropped to fit a simplified fragment.

owl-to-clif
How it works

Five projects make up the family — core, lexer, parser, translation, and workflow, roughly 21,600 lines in total. Because the target is full first-order logic instead of a decidable subset, constructs that an OWL reasoner must approximate survive the lift intact.

OBO

The biomedical corpus format. BFO 2020 is already the upper ontology for much of OBO, so for these ontologies the lift is less a conversion than a homecoming.

obo-to-clif
How it works

The same five-project shape as OWL, at roughly 6,400 lines. Annotations and provenance carry through, so Gene Ontology, Cell Ontology, and their peers arrive with their curation history intact.

SKOS & SKOS-XL

The taxonomy and thesaurus world — where most enterprise vocabularies actually live. Broader and narrower relations become real parthood and subsumption, which is the step that turns a term list into something that can reason.

skos-translate
How it works

A translation project plus an RDF/XML reader, roughly 2,400 lines. Once anchored to BFO, a controlled vocabulary stops being a naming convention and becomes knowledge the provers can check.

The translation is itself a proved workflow

Bringing your ontology in is not an unchecked import. The lift runs as a verified workflow, proved before it executes, audited while it runs, on the same engine we ask you to trust for your own knowledge.

How it works

Each family ships a workflow project executed by Sequent: verified by Sequent Algebra before execution, audited by Sequent Signal during it, with HTML reports produced as a record. We run our own platform to ingest your ontology rather than demonstrating it on something easier.

A lifted ontology can always be traced back

Every generated artifact carries a provenance record of what produced it, from which source file, under which proof, so months later, no one has to reconstruct where a definition came from.

How it works

Provenance is written using W3C PROV-O on the emit side and not treated as an input format, through a provenance sink and an annotation overlay applied to generated artifacts.

Your existing ontology comes across intact. You do not write it a second time.

Powered by OntoMotion™
Why Common Logic?

Many knowledge representations are designed for classification and fast lookup, which means they intentionally limit how much can be expressed so that reasoning stays quick and predictable. Common Logic takes a different approach: it can express the full richness of a domain's meaning — relationships, constraints, and rules, and it supports formal reasoning over all of it, not just classification. TruSpark uses Common Logic because preserving meaning across an enterprise requires representing that meaning completely, and then being able to prove things about it.

What standards does TruSpark conform to, precisely?

Standards are what let someone outside Reasonics check our claims. When a system conforms to a published, independently governed standard, its behavior can be audited, reproduced, and relied on by regulators, partners, and your own engineers, without anyone having to take our word for it. TruSpark is built on recognized standards at every layer:

  • ISO/IEC 21838-2:2021 (BFO 2020), the ISO top-level ontology standard. It specifies 35 universals, 60 relations, and 354 axioms across 13 CLIF modules.
  • ISO/IEC 21838-1:2021 (Top-Level Ontologies), the requirements standard BFO 2020 satisfies as a conformant top-level ontology. It is what makes “BFO is ISO-standardized&rdquo. A checkable claim instead of a label.
  • ISO/IEC 24707:2018 (Common Logic / CLIF), the ISO standard for the logic language TruSpark reasons over.
  • OBO 1.4 and OWL 2 — widely adopted community standards, accepted directly as input formats.
  • SMT-LIB 2.6/2.7, TPTP TSTP, and Alethe, open proof-certificate formats, independently replayable without TruSpark in the loop.
  • W3C PROV-O, the W3C standard for data provenance, embedded in every compiled artifact.
  • Three of these, BFO 2020, the top-level-ontology requirements it answers to, and CLIF, are ISO international standards. The rest are community or W3C standards.
3

Automated Theorem Proving

Before any software is generated, the knowledge is submitted to automated theorem provers that check it is internally consistent and that its conclusions genuinely follow. This is proof, not testing, and a result that cannot be proved is reported honestly as indeterminate, never guessed.

The OntoProver decision ladder: the cheapest tier that can answer a query answers it, escalating to heavier reasoning only when the cheap tiers cannot decide.
The cheapest tier that can answer, answers. Most questions are settled by direct structural checks; only what genuinely needs a full proof search escalates to one.

TruSpark does not rely on a single prover. It runs a portfolio of automated theorem provers under one interface, because different provers are suited to different kinds of problems, and a result that several independent provers agree on is far more trustworthy than one from any single tool.

Why does TruSpark have its own theorem prover alongside Z3, CVC5, and Vampire?

Different provers are good at different things. TruSpark routes each problem to the prover best suited to its shape. For high-assurance work you can go further and require cross-verification: two engines run the same question concurrently, and the verdict is only promoted when both agree. A one-sided proof the second engine cannot confirm is reported as indeterminate rather than accepted, and outright disagreement is surfaced as its own verdict instead of being resolved silently. That is what makes a proof defensible and not merely asserted, and disagreement between reasoners is treated as information, never something to hide. OntoProver™ is Reasonics’ own prover in the portfolio, purpose-built for BFO 2020 reasoning and emitting independently replayable certificates in TSTP and Alethe; Z3, CVC5, and Vampire are industry-standard provers used by verification teams worldwide. No single external prover combines BFO-native optimization with that independent certification.

See it decide

Pick a formal statement and watch the prover portfolio reach a verdict — proved, or honestly reported as indeterminate.

Pick a statement

Axiom submitted to the portfolio specific-dependency.cl . [iyu-1]
(forall (s c)
  (if (specifically-depends-on s c)
    (and (exists (t) (and (exists-at s t) (exists-at c t)))
         (forall (t) (if (exists-at s t) (exists-at c t))))))

If s specifically depends on c, they coexist at some time, and c exists at every time s does.

OntoProver proved 41 ms
Z3 confirms
⊢ Proved Decided by OntoProver

A dependent entity cannot outlive its bearer.

TSTP . replayable without Reasonics in the loop

OntoProver is Reasonics’ own automated theorem prover, built specifically for BFO 2020 ontological reasoning, with its own tableau, resolution and superposition engines, and a native SMT solver: a DPLL(T) core driving five theory solvers. Three of those are BFO-native — mereology, category disjointness and temporal reasoning — alongside the BFO sort lattice and linear arithmetic. It reads and writes SMT-LIB 2.7 across QF_UF, UF, AUFLIA and AUFLIRA. That is the part an off-the-shelf SMT solver cannot supply: a decision procedure that already knows what parthood and disjointness mean. Z3, CVC5, and Vampire are industry-standard provers used by research institutions and verification teams worldwide, each bringing different strengths to the portfolio.

An inconsistent theory is rejected outright. A theory that contains a logical contradiction can prove anything vacuously, so TruSpark refuses to build on one.

For the business, this is the difference between a system whose answers you hope are right and one whose answers you can defend. Because every conclusion is proved before anything is built on it, the software your teams ship carries meaning that has already been checked, so a decision can be explained to a regulator, reproduced by an auditor, and relied on by the people downstream, without anyone having to trust that the logic simply happened to be correct. Correctness stops being a matter of confidence and becomes a matter of record.

⊢ verified
(assume h1 (forall ((x Entity)) (=> (continuant x) (exists-at x))))
(step t1 (cl (not (and (continuant a) (not (exists-at a)))))
      :rule resolution :premises (h1))
(step t2 (cl) :rule contradiction :premises (t1))   ; ⊢ consistent
substrate: OntoProver + Z3agreement: 2 / 2artifact: independently replayable

Beyond first-order logic

The core runs on first-order logic in CLIF, but real questions also ask about time, obligation, actions, and exceptions. TruSpark ships logic extensions for those, while holding the same line on genuine proof. Pick a family below to see its members. The tag on each says whether the platform proves it directly today, handles part of it, or hands it to a specialist tool.

Must this always hold, eventually happen, or hold until something else does? The logic of time and ordering.

Categorical composition C9
Prove that combining two verified ontology modules stays consistent.
NATIVE
Markov logic (hard rules) C6
Logic-plus-weight; hard constraints proved, soft weights deferred to probabilistic engines.
NATIVE
Game & independence-friendly C11 · C12
Semantic evaluation games and quantifier-independence reasoning.
NATIVE
Dependent type theory C2
Expressed and handed to Lean; no native proof claimed, so the platform reports indeterminate.
DEFER
Inside the reasoning substrate

The platform answers instantly when it recognizes a known pattern and escalates to the full prover only when it needs to, and when it genuinely cannot decide, it says so honestly instead of guessing.

OntoProver — Answer Fast, or Escalate Honestly

Verification only helps if it is fast enough to live inside a working day. Because the knowledge is anchored to BFO 2020, a great many questions have known answers, so the cheapest tier that can answer, answers, and anything the shortcuts do not genuinely recognize goes to the full prover rather than being waved through.

Tier 1 · Known shapes 1–10 nanoseconds

Questions matching a known BFO pattern are answered from precomputed results, no solver is called at all.

answers are precomputed
How it works

This is the BITS layer — bit-level BFO reasoning. BFO’s fixed relationships are encoded as bit patterns and not as statements to be solved: disjointness matrices, sub-universal lattices, Allen interval tables, clause arenas, and relation counters, shipped pre-saturated as a binary resource. Answering becomes a bitwise lookup instead of a solver call. Roughly 5,500 lines across 19 files.

no match
Tier 2 · Known theory Microseconds

If every axiom in a module is a recognized BFO 2020 theorem, the module is certified consistent without ever invoking the prover.

structural identity, not heuristics
How it works

A fast-path matcher checks axioms against a catalogue of top-level ontology theorems by structural identity, not by similarity scoring, so a near-match is a miss instead of a guess. One shared adapter means the layer fires identically on every route into the prover.

no match
Tier 3 · The full prover Full saturation

Anything unrecognized is declared out of scope and handed to the full theorem provers. Nothing is approximated to look fast.

a timeout is never reported as a disproof
How it works

Unrecognized conjectures are dispatched to the saturation engine — OntoProver alongside Z3, CVC5, and Vampire. Verdicts stay three-valued: proved, disproved, or indeterminate, so a timeout is reported as unknown rather than quietly counted as a refutation.

Verdict badges showing verified, disagreed, inconclusive, pending and error states, plus a composite four-way verified badge naming the substrates that agreed.
The verdict states the interface actually renders. Disagreement and inconclusive are first-class results, never error conditions.
What counts as a recognized shape
Sub-universal — anything that is an instance of the narrower kind is also an instance of the broader one
Inverse relation , both plain and time-indexed forms of a relation and its converse
Disjointness , two kinds that cannot share an instance
Counter-model goal , a claim that something belongs to two disjoint kinds at once — refutable by construction
How it works

Matching is structural. A refutation requires a shared witness variable and temporal index — distinct witnesses are satisfiable and fall through to the next tier instead of being reported as a contradiction. The shapes follow the BFO 2020 corpus anti-conjecture form, expressed in CLIF as (forall (t x) (if (instance-of x SUB t) (instance-of x SUPER t))) and its relatives.

Where the same discipline reaches

The same escalate-honestly rule governs transaction logic, dependent type theory through Lean 4, and the native bindings your developers call from Rust, Go, C++, and Java.

speed figures are internal benchmarks, not published results

Most questions never reach the prover. The ones that do are not hurried.

Powered by OntoMotion™
4

Compiler Architecture

Once a theory is proved, TruSpark compiles it into executable software. Compilation is gated on verification: a build that succeeds but contains anything that does not match its proved source is treated as a defect, not a release.

Cross-checker matrix showing each conjecture against each prover, with per-cell verdicts and timings.
Two engines, same question. A verdict counts as corroborated only when independent engines agree on the same theory.
Counter-model viewer inspecting a refuted anti-conjecture, showing the attempted finite model and its empty domains.
A refutation is evidence too. When a claim fails, the counter-model shows exactly which case breaks it.

Reasonics calls this principle verification-first emission. Every artifact emitted, in every language, across every deployment target — carries the same machine-checked semantics and an independently replayable proof certificate. It is the difference between trusting software because you read its documentation and trusting it because a machine proved its claims.

Knowledge-to-Code Pipeline
OWL ontologyTaxonomy / lexiconCLIFISO/IEC 24707auto-translateontology devOntoEnact™ compilerOntoProverZ3 / CVC5Vampireverified before emitC#JavaGoRustC++PythonW3C PROV-O provenance embedded in every artifactEvery output traces back to an accepted axiom
5

Proof Certificates

Every proof produces a certificate, a portable, machine-checkable record of exactly how a conclusion was reached. You do not have to take Reasonics’ word for it: a certificate can be replayed in an independent checker, with TruSpark nowhere in the loop.

Proof artifact card in three variants, showing the produced proof file, its format, size and timestamp.
Every proof leaves a file. Format, size and timestamp, kept with the run that produced it.
Proof graph projection linking a conjecture to the prover that discharged it and the SMT2 and Alethe artifacts it emitted.
Conjecture to artifact, traced. Which prover answered, and what it left behind.

Certificates are emitted in three independently verifiable formats — TSTP, Alethe, and SMT-LIB 2.7.

A receipts row showing one conjecture verified four ways, listing each substrate and its verdict.
One conjecture, verified four ways. Each row names the substrate that checked it and the verdict it returned.
For organizations subject to regulatory review, this is what makes the chain of evidence real: it exists, it is portable, and it is not proprietary.

By the numbers

Each figure carries its own evidence. Click a stat to see exactly what it measures — and, just as important, what it doesn’t.

⊢ verified

TruSpark's compiler works with 40 formal categories (universals), the standard 35 BFO categories plus five meta-ontological terms used internally by the sorted reasoning pipeline. The axiom count is identical. The encoding differs.

⊢ verified

304 formal statements are catalogued in TruSpark's BFO conjecture registry. A smaller set runs under proof-gated verification. These two counts measure different things, a platform that conflates them is imprecise.

⊢ verified

More than 150 generated SDK trees, with 147 named entries in the ontology manifest, have been compiled through the identical pipeline, including the platform's own internal systems. TruSpark uses the SDKs it generates in its own production infrastructure.

⊢ verified

TruSpark's CLIF parser has been tested against COLORE, a large public benchmark repository of Common Logic ontologies contributed by multiple independent research groups — achieving a 99.87% successful parse rate across 3,118 files — 3,114 parsed, with four documented defects. This measures the parser's robustness across real-world inputs from sources outside Reasonics. It is a parse-pass rate, not a proof-verification rate: successfully reading a file and formally proving it correct are different claims, and TruSpark does not conflate them.

6

Polyglot SDKs & Generated Outputs

Finally, the verified core is delivered into your environment as build-ready software your teams can use directly, in the languages they already work in, with the evidence from the layers above traveling alongside it. The assurance built up across the previous five layers arrives as something your teams can ship, never a report someone still has to act on.

Native SDKs

In six languages — C#, Rust, Go, C++, Java, and Python, each with entity classes, query providers, axiom registries, and validation logic. These are build-ready libraries, not wrappers or stubs.

Knowledge Explorer Consoles

Interactive applications in each language that let engineers and domain experts explore the compiled ontology directly, without formal logic expertise. Twenty modules covering entities, relations, temporal reasoning, validation, live theorem proving, and more.

Proof certificates

In TSTP, Alethe, and SMT-LIB 2.7, independently replayable without TruSpark in the loop.

Provenance records

Through W3C PROV-O (the W3C international standard for data provenance), embedded in every compiled artifact, a formal record of the knowledge that produced each output and the verification it passed through.

Graph schemas

Derived directly from the verified ontology and consumed by TruSpark's runtime graph engine to execute over your instance data, the graph structure comes straight from the proved knowledge, not maintained separately.

Where to next

Go deeper

Architecture in depth

The engineering detail behind the runtime, the graph engine, the schema language it compiles to, and how it distributes.

Architecture in depth
Next in the tour

Products

A verified core becomes valuable when it ships. The next page covers what TruSpark generates, the SDKs, engines, and capabilities your organization builds and licenses.

Products

Have your architects put the standards and the proof trail under scrutiny.

Request a Technical Review