A schema checks the record. An ontology explains the terms.

A field can be valid and still be misunderstood

Consider a record with an actor, a deadline, and a status of “accepted.” A JSON validator can check that the actor is a string, the date has the expected form, and the status belongs to an allowed set. It cannot infer from those checks whether “accepted” means a model extracted the text successfully, an analyst endorsed its interpretation, or a party accepted a legal obligation.

JSON Schema defines vocabularies for describing and validating JSON instances. That is more than a storage format: constraints can encode meaningful application rules. But their meaning still needs documentation. An ontology supplies explicit concepts and relationships for a domain, potentially with formal semantics that support inference. Neither is inherently superior, and neither alone establishes factual accuracy. [1][2]

Separate four questions in the implementation

SHACL validates an RDF data graph against a shapes graph. OWL serves a different purpose: its semantics support entailment, and its open-world assumption does not treat an unrecorded fact as false. Using an OWL reasoner as though it were a closed database validator can therefore produce surprises. Choose the mechanism for the question rather than expecting one language to perform every check. [2][3]

Make ambiguity visible before adding a graph

In a policy file, “endorsed,” “signed,” and “entered into force” are different events. Adding an enum for them is helpful only if reviewers agree on what counts as evidence for each value. The example preserves a reported endorsement while leaving legal effect unresolved. A later revision should record both the changed interpretation and the source or review activity that justified it. PROV-O offers useful terms for that lineage. [4]

{
  "id": "assertion-17",
  "recordType": "ReportedEndorsement",
  "actorRef": "ministry-a",
  "instrumentRef": "draft-agreement-3",
  "sourceSpanRef": "document-12:paragraph-6",
  "legalEffect": "not_assessed",
  "reviewState": "needs_review",
  "schemaVersion": "example-1"
}

Migration is an evidence problem, not an impossibility theorem

Suppose an old system called every statement a claim. If it retained source documents, a reviewer may recover distinctions between intentions, proposals, and accepted commitments. If it retained only a summary, some distinctions may be irrecoverable. Migration should identify that uncertainty rather than assigning precise new types to evidence that no longer exists.

A practical migration has a versioned mapping, examples of difficult cases, and a queue for unresolved records. A change from “deadline” to separate proposed and agreed dates is not merely a renamed field: queries and user expectations may change. Conversely, adding a document checksum need not alter the domain’s conceptual model. The boundary is useful without being absolute.

The context budget is part of the design

For recurring questions, typed records can avoid sending the same long document into every prompt. A query might retrieve only commitments involving one actor, their conditions, and the passages supporting them. This is a hypothesis about useful compression, not a guarantee of fewer total tokens: extraction, validation, indexing, and rebuilding also cost time and computation.

Compare a document baseline, structured tables, and a graph on the same tasks. Measure field and relationship errors, evidence retained in retrieved context, answer support, total tokens, latency, and maintenance effort. Include cases where a missing qualification changes the answer. In TACITUS, DIALECTICA is the knowledge-engine boundary and PRAXIS the review workspace; the broader ontology and portability contract remains under development.

Use the same valid record to expose the semantic error

A JSON record can have a valid date field and still misrepresent “January 2027 proposed” as an adopted effective date. The record must carry modality, named authority, conditions, date precision and an unresolved adoption state. Likewise, the structurally valid Group Q exercise cannot merge an unverified alias or infer that unchecked Fictional B has no designation. Structure, semantic consistency, access, byte integrity, local review and factual accuracy are different checks. [5]