Frequently Asked Questions

An ontology is a formal, structured representation of what an organization knows, its concepts, the relationships between them, and the rules that govern them, expressed in a way that software can reason with directly. Not a database schema. Not a taxonomy. A precise, machine-readable definition of what things mean and how they relate.

It matters for AI in regulated industries because it is the difference between AI that pattern-matches on data and AI that reasons from knowledge. When an AI system's understanding of "adverse event" or "material nonconformance" or "beneficial owner" is formally defined, grounded in a recognized standard, and provably consistent, rather than inferred from training data, the outputs it produces are traceable, auditable, and defensible in a way that probabilistic outputs are not.

Formal reasoning derives conclusions from explicitly defined rules using mathematical logic. The conclusions it produces follow necessarily from the rules it starts with, and every step can be inspected and verified by an independent party.

The difference from probabilistic AI is where the conclusion comes from: a probabilistic model produces the output most consistent with patterns in its training data, while formal reasoning derives the output that necessarily follows from the defined rules, and can show the derivation. That distinction becomes decisive when you need to show your work, when the output must be auditable by an external party, and when the cost of being wrong is not recoverable. A drug interaction flag that cannot be traced to a specific rule is not defensible in a regulatory submission. A compliance determination that came from a model's statistical tendencies is not auditable. Formal reasoning is not always the right tool, but in regulated and mission-critical environments, it is often the only one that meets the bar.

It means that before TruSpark generates any software, it submits the formal knowledge the software will be built from to a portfolio of automated theorem provers — mathematical reasoning engines that check whether the knowledge is internally consistent and whether the conclusions it draws actually follow from the rules that define it. If they do, a proof certificate is issued. Software is only generated after that certificate exists.

For an auditor, this means the chain of evidence is explicit: the formal knowledge was defined, it was proved, the proof was certified, and the software was compiled from the certificate. Every output can be traced back through that chain to the specific rule that produced it. This is not a confidence score. It is a proof.

TruSpark's place is unusual: instead of competing with any single category, it brings together capabilities that are normally spread across many of them, formal reasoning, graph execution, schema generation, workflow verification, and knowledge integration, on one foundation whose results can be independently proved. That combination, unified and verifiable in a single system, is rare.

And it is additive, never disruptive. TruSpark raises the efficacy of the systems you already run rather than replacing them: it gives your AI and LLM workflows a verified foundation to reason over, keeps your graph, schema, and workflow systems aligned to knowledge that has been proved consistent, and sits alongside your existing stack as the layer that makes its outputs trustworthy.

Large language models generate outputs by predicting what comes next based on patterns in training data. They are powerful and genuinely useful for many tasks. But they are probabilistic by design, the same input can produce different outputs, and no output comes with a guarantee that it follows from a defined body of knowledge. That is not a flaw that better prompting or more training data resolves. It is structural.

TruSpark reasons from formally defined knowledge using mathematical proof. Its outputs are deterministic, traceable, and independently verifiable. In environments where an auditor, a regulator, or a patient safety review needs to know not just what the system concluded but why, and whether that conclusion was provably correct, formal reasoning is not an alternative to LLMs. It is the foundation that makes LLM-assisted workflows trustworthy.

Fine-tuning adjusts the statistical weights of a model so that its outputs more closely reflect a particular domain or style. It improves relevance, but it does not change what a language model fundamentally does: generate probable outputs based on patterns. A fine-tuned model produces more domain-relevant outputs. It does not produce outputs that can be traced to a defined rule, proved correct, or audited by a regulator.

If your organization's requirements include explainability, auditability, or the ability to demonstrate that an output follows from a specific policy or standard, fine-tuning does not satisfy those requirements. TruSpark satisfies them at the architectural level.

Every non-trivial conclusion is decided by an automated theorem prover, not inferred from data, not generated by a language model. Verdicts are three-valued: proved, disproved, or indeterminate. A timeout is reported as indeterminate, never as a disproof. A prover abstains and not guesses on inputs outside its scope. A theory that contains a logical contradiction is rejected outright — TruSpark refuses to build on knowledge that cannot be proved consistent.

Yes. Every proof comes with a certificate, a machine-readable record of exactly how the conclusion was reached — emitted in three independently verifiable formats. A certificate can be archived, transported, and replayed in an independent checker at any point, including during a regulatory audit, without Reasonics' involvement. The verification claim is not something you take on faith from Reasonics. It is something you can audit yourself.

Only if your role is authoring new formal knowledge from scratch. A subject-matter expert reads a compiled theory in plain English and never sees the underlying logic. A consultant or integrator brings in existing knowledge in common formats with a single command. An engineer consumes a generated software library and works entirely in their native programming language. TruSpark does the formal work and explains itself at each step.

No. TruSpark is built on .NET 9 / 10 and is cross-platform by construction. The OntoLogic Portal™ IDE targets Windows, macOS, and Linux. Current Private Beta binaries are validated on Windows x64. Contact us about a specific target platform.