The core engines

Where knowledge becomes software

OntoEnact

The compiler

Turn formal knowledge into production software your teams can trust.

OntoEnact compiles your organization's formal knowledge into build-ready software in C#, Java, Go, Rust, C++, and Python, but only after a portfolio of theorem provers proves the knowledge internally consistent. Nothing is generated that was not proved first.

The BFO CLIF Compiler

Four phases turn your ontology into software. The fourth is a gate. That is why a contradiction surfaces as a failed build on a developer’s screen instead of as a defect in production.

The four-phase pipeline

Parse

read the theory

→

Sort

ground it in BFO 2020

→

Emit

hand it to the provers

→

Gate

no proof, no code

One source, four things your teams receive

The canonical theory

your knowledge in its authoritative form

The proof target

what the theorem provers actually check

Proof certificates

replayable evidence, without us in the loop

Native SDKs

build-ready libraries in six languages

How it works

One compiler interface handles parsing, sort inference, translation, and compilation, alongside validation, reasoning, and query. Source is CLIF (ISO/IEC 24707), grounded in BFO 2020 (ISO/IEC 21838-2) and emitted as SMT-LIB 2.7 for the prover portfolio. A module system assembles a theory from a directory and canonicalizes COLORE, OBO, and IOF dialects, so ontologies written in different conventions still arrive as one theory.

Knowledge is organized in four layers — top-level, mid-level, domain-level, and application-level, the arrangement ISO/IEC 21838-2 prescribes, so your domain work sits on standard foundations instead of a private hierarchy.

Nothing reaches your build that a prover did not accept.

OntoTelliect

The runtime

Reason over your live data in the same formal terms your knowledge was defined in.

Where OntoEnact compiles the ontology, OntoTelliect runs it — executing verified knowledge over real-world data at scale, where the graph structure comes straight from the proved ontology and is never maintained by hand.

OntoTelliect Graph Engine IDE: an ontology hierarchy panel expanding the BFO 2020 top-level ontology from entity through continuant to independent continuant, alongside graph layout, prove, verify, refute and receipt controls. — The Graph Engine IDE, the BFO 2020 hierarchy with each universal carrying its axiom label, beside the prove, verify, refute and receipt controls. Interface design. The engine runs today. The Graph Engine IDE is in active development.

The Runtime Graph Engine

Four steps take a proved theory all the way to reasoning over live operational data, with no hand-written stage in between where meaning could be lost.

From proved theory to live data

Proved theory

the verified ontology

→

Schema

derived, not hand-written

→

Typed graph

your ontology is the type system

→

Live reasoning

over real operational data

The graph refuses what the logic forbids

Structure comes from the proved ontology, so a relationship your knowledge rules out cannot be stored, the contradiction is refused as it is written, not discovered in an audit months later.

How it works

Every cell, edge, and traversal is BFO-typed, running on an eleven-year fork of Microsoft Trinity (SIGMOD 2013), the engine Microsoft Research reports running as a server cluster behind the Microsoft Knowledge Graph, also known as Satori. The type system in the running engine is the compiled ontology, never a schema maintained alongside it.

The schema is derived, never hand-maintained

Because the storage schema is generated from verified knowledge, it cannot drift away from it, the usual gap between what a database enforces and what the business actually means never opens.

How it works

The OGSL schema language and its compiler derive the schema from verified CLIF, generate graph operations in five statically typed languages, and route verification back through the compiler. A trust-boundary classifier grades every conversion, so a definition that lost fidelity is labelled, never quietly accepted.

How the two engines connect

The coupling is deliberately one narrow seam: the graph engine reaches the compiler through a single SDK boundary — in-process, over the network, or automatically choosing between them. They are separate stacks, so the runtime can evolve without destabilizing the compiler, and verification behaves identically however it is reached.

A relationship your logic rules out has nowhere in the graph to live.

The authoring experience

How teams work with formal knowledge

OntoLogic Portal

The authoring tool

Give your team a productive way to build and verify formal knowledge, without a logician on staff.

Look inside the authoring environment

The OntoLogic Portal authoring environment: an ontology tree, the editor, and panels for proving, validating and inspecting results. — The full authoring layout, the ontology on the left, the editor in the middle, and proving and validation results where you can see them while you work. Interface design. The engine runs today. The authoring environment is in active development.

The working vocabulary of the toolbar — conjecture, prove, verify, refute, inspect, because these are the actions the work is actually made of.

OntoLogic Portal is the authoring experience over the core engines. It is available as a command-line toolset today, with a visual IDE, live theorem-prover feedback as knowledge is authored, in active development.

OntoLogic Portal interface: a conjecture browser listing BFO 2020 modules with proven and idle states, a CLIF editor, and a receipts panel showing a conjecture proved and four-way verified in 127 milliseconds. — OntoLogic Portal, the conjecture browser, the CLIF editor, and the proof receipts panel. Each receipt records the format, the checker, the producing substrate, and the verdict. Interface design. The command-line toolset ships today. The visual IDE is in development.

The Taxonomy Designer: a hierarchy tree with drag targets, a term detail panel, and BFO grounding controls for each node. — The Taxonomy Designer. A domain expert arranges terms, and each node carries its BFO grounding so the taxonomy stays anchored to the top-level ontology. Interface design. The command-line toolset ships today.

The Ontology Explorer showing the BFO class hierarchy, entity detail, and axiom listings. — The Ontology Explorer, browsing the compiled hierarchy with the axioms that govern each universal. Interface design.

The Authoring Experience

Verification is part of editing, not a step afterwards. Your team finds out that a definition contradicts something the moment they write it, which is what makes formal knowledge practical for people who are not logicians.

Verification is part of editing

Author

write or draw the knowledge

→

Prove

as you edit, not after

→

See why

a counter-example, never an error code

→

Hand off

to the compiler, proved

Four provers, working as peers

Run one, run all, or let the portal choose. When a claim fails, you are shown a concrete counter-example, the specific case that breaks it, instead of a bare rejection you have to diagnose.

How it works

Z3, OntoProver™, CVC5, and Vampire run as peers and not as fallbacks, with counter-models, Craig interpolation, and full prover-disposition traces available beside the source.

Four ways in, for four kinds of author

A logician can write logic directly. A domain expert can import what they already have or work on a visual canvas. The channel differs, the verification does not.

How it works

The four channels are direct authoring, format translators for existing ontologies, a code-level DSL, and a visual canvas that is still in development. All converge on the same verified representation.

Version control that tracks meaning

Changes are tracked at the level of individual statements, so a review shows which piece of knowledge changed, not which line of a file moved.

How it works

Diffs at the axiom level, versioned against the module graph, so a reviewer sees the semantic change and its blast radius instead of a textual patch.

You find out a definition contradicts something while you are still typing it.

Explainability

Reasoning anyone can read

OntoVerba

The explainer

Let anyone read what the system knows, and why a conclusion holds, in plain English.

OntoVerba renders the same statement as plain English and as formal logic from one shared structure, so the two readings cannot drift apart. — **The English and the logic are the same thing.** Both readings are generated from one shared structure, so a plain-language explanation cannot quietly drift away from what was actually proved.

Look closer at how the plain-language reading stays honest

One statement rendered for several audiences, from an informal reading to the formal logic, each provably the same statement. — One statement, read at the level each audience needs — provably the same statement every time.

The no-drift gate: English and formula are both folds over one shared tree, round-tripped to prove no drift. — Both readings are folds over one tree, and the round trip is checked.

An explanation naming the load-bearing axiom behind a result, in English beside the formal statement. — An explanation names the axiom it rests on, not just the conclusion.

A gloss receipt recording which axiom a reading came from and flagging when it has gone stale. — Each reading carries a receipt, and goes stale visibly when the axiom moves.

OntoVerba renders verified axioms and proof results into audience-tuned plain English that is guaranteed to re-parse to the exact formula it describes, so the explanation can never silently drift from the logic. It can also explain why a proof held, or why one failed, in the terms of your domain.

Gloss and Explainer

Three jobs, and each one removes a dependency on the handful of people who understand the model, so a conclusion can be reviewed, challenged, and repaired by the people accountable for it.

Read what the system knows

One definition, rendered for whoever is reading it, an executive, an analyst, an ontologist, or a tooltip in an application. Four audiences, four readings, and they cannot disagree with each other.

How it works

Every register is generated from the same proved statement and carries the same fingerprint, so an executive summary is provably the same claim as the formal logic beneath it, never a paraphrase somebody wrote once and stopped maintaining.

See why a decision held

When a conclusion is challenged, the reasoning is narrated step by step, naming the specific statements the conclusion depended on instead of dumping the whole proof.

How it works

Each step is narrated by the inference rule that justified it, over the load-bearing axioms only. The explanation names which prover decided the question, so every decision has a name against it.

Know what to change when it fails

A failure is not a dead end. Conflicting statements are identified as a set, because no single one of them is at fault, and you are offered ranked ways to resolve it.

How it works

Repairs are proposed as ranked retractions, and the theorem prover confirms whether the chosen edit actually settles the question. The suggestion is never the verdict.

One statement, read four ways

(forall (x t) (if (instance-of x material-entity t) (instance-of x continuant t)))

An executive

Anything physical is a thing that persists, not an event.

An analyst

Every material entity is a continuant at every time it exists.

An ontologist

For all x and all times t, if x is an instance of material-entity at t, then x is an instance of continuant at t.

An application

Tooltip: material entity → continuant

Gloss fingerprintsha256:9f3c…a17didentical for all four readings

The readings above cycle. The fingerprint does not. Each is generated from the same proved statement, so the executive line cannot drift from the logic underneath it. This is a real axiom from the BFO 2020 corpus. Why it cannot drift →

The executive summary and the formal logic are the same sentence, written twice.

Built in, and available on their own

Two capabilities that also stand alone

Sequent and Tessera are part of every TruSpark deployment. Each is also being made available as a standalone offering for organizations that need just that capability. Both are available today inside TruSpark. The standalone packaging is in development.

Look inside Sequent — Core, Algebra and Signal

Sequent Core: the self-proving workflow engine, holding 126 pattern operators and running eleven structural checks. — **Core** holds the pattern library and runs the structural checks — can this process deadlock, can a step be skipped, can it finish.

Sequent Algebra: the behavioural specification layer that composes processes above Core and checks the result. — **Algebra** composes larger processes out of verified smaller ones, and checks that the composition still holds.

Sequent Signal: the orchestration layer running a verified workflow under eight runtime surfaces. — **Signal** runs the verified process and keeps it auditable while it executes.

Both are compiled, not written

Sequent and Tessera are themselves BFO CLIF ontologies, compiled to code through the same proof-gated pipeline TruSpark runs on your knowledge. Neither is a hand-written engine sitting beside the compiler. Their behaviour is generated from formal definitions that a theorem prover accepted first.

Sequent

Five CLIF modules : the pattern core, the composition algebra, the runtime surfaces, and two domain extensions.

Tessera

Twenty-five CLIF modules spanning entitlement, capability, roles, attributes, authentication and renewal.

This is the part worth checking us on. The workflow engine that proves your processes was itself proved. The licensing layer deciding what your organization may run is itself a compiled ontology, never a configuration file. If the method did not hold up, it would have failed on our own products first.

Sequent

The workflow layer

Prove a business process is sound before it ever runs.

The Workflow Automation Ontology treats workflows as formally defined knowledge, so a process can be proved coherent at design time, a required step cannot be skipped, an approval genuinely precedes the action it authorizes. None of that waits for production to reveal it.

The Sequent engine architecture: Sequent Core holding the workflow pattern library, Sequent Algebra composing and checking processes, and Sequent Signal running them under audit. — The three engines behind Sequent: **Core** models a process against the pattern library, **Algebra** proves and composes it, and **Signal** runs it under audit.

The Workflow Automation Ontology Engine

A process is checked for structural faults the way a compiler checks code, so the flaws that normally surface as an incident are caught while the process is still a design.

The self-proving pipeline

Author

describe the process

→

Model

as formal knowledge

→

Verify

before it ever runs

→

Run

under continuous audit

What gets caught at design time

✓ A step cannot be skipped

✓ The process cannot deadlock

✓ Every path can complete

✓ Parallel branches rejoin correctly

How it works

Sequent Core. Eleven structural self-checks cover deadlock, liveness, and synchronization, with an optional theorem-prover gate for full ontological consistency. Underneath is a library of 126 workflow pattern operators drawn from the established control-flow, data, and resource pattern catalogues, so the coverage is measured against published research instead of a list we wrote ourselves.

Processes are composed, then re-checked

Smaller proved processes combine into larger ones, in sequence, in parallel, or as a choice, and the combination is verified again. So a process built from trusted parts is not assumed to be sound. It is shown to be.

How it works

Sequent Algebra. A behavioral specification algebra composes, normalizes, and tests processes for equivalence, with property-checked algebraic laws and temporal carriers for ordering, absence, and repetition. Four structural checks are live today; three more are specified and deferred, and we say so plainly instead of implying they run.

What you get while it is running

Sequent Signal. Eight capabilities are active during execution, so the evidence an auditor asks for is produced while the process runs, never reconstructed afterwards.

Tamper-evident audit

every event hash-chained

Compensation

a failed step unwinds cleanly

Conformance

what ran matches what was approved

Data lineage

where each value came from

Monitoring

against your service levels

Access control

who may run what

Optimization

where the process is costing you

Scientific workflow

reproducible experimental runs

If the process can deadlock, you hear about it at design time.

Inside TruSpark

Grounds and proves the workflows that orchestrate a TruSpark-based application.

As a standalone offering

Brings provable, auditable workflow automation to organizations that are not yet compiling their whole knowledge base with TruSpark.

Tessera

The licensing layer

Protect the software and knowledge you build, and govern exactly what is deployed.

Tessera expresses licensing as formally verified knowledge. It governs which capabilities, SDKs, languages, and deployment targets an organization is entitled to use, and protects the SDKs, ontologies, and applications you produce with machine-bound tokens and a full audit trail.

It is how TruSpark itself is licensed, and how you govern what you build on it, the operational detail lives on Deployment & Integration → Licensing and Entitlements. Pricing, editions, and commercial packaging are handled during the Founding Partner conversation.

Tessera architecture: the capability check against the build, the entitlement check against edition, role, attributes and authentication state, and the signed machine-bound token that carries the result. — Tessera resolves two independent questions before anything runs, and either failure denies. Both answers come from compiled CLIF, never from configuration.

Licensing and Entitlement

Two questions are asked before anything runs, and both must pass. If either is unanswered, a lapsed license, an unreachable check, a fault in the middle, the answer is no. Nothing is permitted by omission.

Both must pass

Question one

Can the software do this at all?

A property of the build, independent of who is asking.

and

Question two

Is this party allowed to?

Their edition, their role, their context, their organization’s policy.

→

PERMIT

otherwise deny, including on failure

Why the two are kept separate

The two questions are formally proved to be disjoint, so a technical capability can never be mistaken for a commercial permission, the failure that lets someone use a feature simply because the software happens to support it. Entitlement itself is decided by a policy point combining edition, role, attributes, and authentication state, where any deny overrides any permit.

How a license is bound

✓ Signed tokens — issued, rotatable, and revocable

✓ Machine binding, a license is tied to the hardware it was issued for

✓ No token, no match — absence is a failure, never a default pass

How it works

Tokens are cryptographically signed and can be rotated or revoked without reissuing software. Machine binding derives a fingerprint from the host’s own hardware and operating system, and every binding is verified on use, so a copied license does not travel to another machine.

License changes are processes, not edits

Issuing, transferring, and revoking run as verified workflows on the same engine as everything else. A transfer that fails partway unwinds cleanly instead of leaving a seat stranded between two owners.

How it works

Lifecycle operations execute as Sequent workflows, with transfer implemented as a compensating transaction. Provisioning state — tokens, grants, and leases, is held in the same BFO-typed graph as the rest of the platform, so entitlement history can be queried instead of dug out of a log.

Both questions have to answer yes. Silence answers no.

Inside TruSpark

Governs entitlements across TruSpark and protects everything you build on the platform.

As a standalone offering

Gives software vendors a verifiable licensing and entitlement layer they can apply to their own products.

Every TruSpark technology is governed through licensing and entitlements, your entitlements determine which capabilities, SDKs, languages, and deployment targets your organization is provisioned to use. Pricing and editions are handled during the Founding Partner conversation; how entitlements are enforced at deployment is covered on Deployment & Integration.

The deliverable

What you build on — and can build a business on

Native SDKs

The deliverable

The verified core, delivered as build-ready software, a development tool and a monetizable asset.

Tessera product editions, cumulative and gated by feature entitlements, built on the OntoEnact SDK and Sequent. — **Tessera** — licensing and entitlement as a product in its own right, built on the same proved foundation as everything else here.

From one verified theory, OntoEnact emits build-ready SDK libraries in C#, Java, Go, Rust, C++, and Python. They are dual-use: your teams build internal software on a verified core, and — governed by Tessera. You can package, license, and embed those SDKs as products you sell to others. So the SDK is both a development tool and an asset you can take to market.

The Verified Deliverable

This is the thing your organization actually ends up owning. It arrives in two parts, in whichever of six languages your teams work in.

Tier 1

The SDK library

A real library in your language — entity classes, queries, and validation — installed through the package manager your team already uses. Not a wrapper around a service, and not a stub.

What is in it

Each language ships with a pinned, public toolchain manifest — NuGet, Cargo, CMake, Go modules, Maven and Python packaging, with no phantom dependencies, plus registries, query providers, and staged native bindings for cross-language calls.

Tier 2

The Knowledge Explorer

An interactive console ships with every SDK, in all six languages. A new engineer can browse the knowledge and watch reasoning actually run before writing a line of code.

What is in it

It browses the entity hierarchy, runs validation, queries the knowledge base, and drives live reasoning. In practice it is the fastest way to bring someone new onto the model, and it costs nothing extra. It is generated alongside the library.

Six languages, one verified source

How each is generated and verified →

Rust

Java

C++

Python

Every target is generated from the same verified source, so the meaning is identical in all six, your teams work in the language they already know, not one we imposed.

It is an asset, never just a build artifact

Most organizations will build internal software on the verified core. But the same SDK can be packaged, licensed, and embedded in products you sell, so formalizing your domain knowledge can earn revenue as well as reduce risk. The knowledge and the SDKs remain yours.

Build on it internally Or license and embed it Entitlements governed by Tessera

What you receive is source in your own language, and it is yours to license onward.

Platform availability

What’s available now — and what’s coming

TruSpark is in Private Beta. We label what is shipping today and what is still in development, plainly and in one place, so you always know what you can rely on now and what is on the way. This list is the reference the rest of the site points to.

Available now shipping in Private Beta In development on the roadmap

Available now Private Beta

OntoEnact compiler + SDKThe .NET compiler and SDK, the proof-gated core.
Reasoning substratesOntoProver with Z3, CVC5 and Vampire — replayable proof certificates and honest three-valued verdicts.
Sequent workflow engine (embedded)Proves workflows before they run.
Polyglot code generationC# is production-grade; Rust, Go, Java, C++ and Python generate verified single-namespace output, with multi-namespace in development.
NativeAOT FFI bridgeA native C-ABI library for in-process embedding.
MCP server + RO-LSPThe agent and editor surfaces. RO-LSP is the Reasoning-Oriented Language Server Protocol: an editor talks to the reasoner the way it already talks to a compiler, so proof verdicts, counter-examples and axiom references arrive as ordinary diagnostics. MCP exposes the same reasoning to AI agents.
FAR 2.0 to ontologyThe US Federal Acquisition Regulation, the government-wide purchasing and procurement standard, lifted from its DITA source into BFO-grounded CLIF. Includes conflict checking across clauses, semantic matching, and metric lowering.
Corpus pipelineLexer, parser, semantics and DITA ingest, so a regulation published as structured documentation becomes knowledge a prover can check instead of prose a person has to interpret.
OntoVerba RecommenderRanked, ontology-grounded suggestions over the verified corpus, with the prover confirming whether a chosen edit settles the question.
Ontology-grounded ReteBFO-typed Rete semantic search served over the RO-LSP wire, with ingest, integration and an SDK surface.
Ontology-grounded NLPNatural-language question to composed BFO theory, so a domain expert can ask a question instead of authoring one.
ontoenactc command-line driverThe whole platform, scriptable from a shell.
OntoLogic Portal command lineThe full authoring and verification loop, shipping today. The visual IDE is listed under In development.
OntoVerba explainabilityPlain English and the formula from one tree, no drift.
Tessera licensing (embedded, single-node)Machine-bound tokens and entitlement, enforced by proof.
Knowledge Explorer ConsoleShips with every generated SDK, in all six languages.

In development on the roadmap

OntoLogic Portal IDE + Graph Engine IDEVisual authoring with live prover feedback — private alpha, Q4 2026.
Full six-language parityMulti-namespace partitioning for the non-C# targets.
Multi-node licensingFleet state and runtime edition-to-feature mapping from CLIF.
VDL visual authoring channelFor domain experts who do not read formal notation.
Neurosymbolic reasoningStatistical models proposing, the prover disposing, on the pattern already used for proof-gated drafting.
Education / academy programA commitment, the tools exist today. A formal curriculum does not yet.
Graph Engine distributed coreThe distributed core is real; current benchmarks are single-machine.
Sequent, standaloneLicensing the workflow engine on its own, outside the TruSpark platform — private alpha, Q4 2026.
Tessera, standaloneLicensing the entitlement engine on its own, for other companies' software — private alpha, Q4 2026.

The TruSpark™ Product Portfolio

One platform, working parts

Where knowledge becomes software

OntoEnact

OntoTelliect

How teams work with formal knowledge

OntoLogic Portal

Reasoning anyone can read

OntoVerba

Two capabilities that also stand alone

Sequent

Tessera

What you build on — and can build a business on

Native SDKs

Which technologies matter to your role

What’s available now — and what’s coming

Where to next

Deployment and Integration

How the platform works

See the portfolio working on your knowledge, not ours.