A stable vocabulary with reviewed domain extensions

Start with a distinction the work actually needs

TACITUS uses eight analytical concepts as a starting vocabulary: Actor, Claim, Interest, Constraint, Leverage, Commitment, Event, and Narrative. They help name recurring questions in policy and conflict analysis. They do not settle the meaning of every undertaking, allegation, or legal obligation in every institution.

For example, a public statement may express conditional support for a proposal without creating a binding obligation. A domain extension might describe a ConditionalUndertaking with an actor, terms, an explicit condition, and a supporting passage. Whether the undertaking is legally binding remains a separate interpretation, with its own authority and evidence. The ontology should make that distinction easier to inspect.

A definition is more than a new label

An extension proposal should state its parent concept, intended use, required fields, examples, counterexamples, and migration implications. “CeasefireCommitment” is not useful merely because a model coined the name. A reviewer needs to know which records qualify, which do not, and how the term differs from an existing definition.

OWL provides formal semantics for classes, properties, and entailment. Its open-world approach does not treat an unstated fact as false. SHACL validates a supplied data graph against declared shapes. These tools address related but different problems: a missing required source can fail an application’s shape without proving that the real-world undertaking never occurred. [1][2]

@prefix ex: <https://example.org/policy/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:ConditionalUndertakingShape a sh:NodeShape ;
  sh:targetClass ex:ConditionalUndertaking ;
  sh:property [ sh:path ex:actor ; sh:minCount 1 ] ;
  sh:property [ sh:path ex:terms ; sh:minCount 1 ] ;
  sh:property [ sh:path ex:condition ; sh:minCount 1 ] ;
  sh:property [ sh:path ex:sourcePassage ; sh:minCount 1 ] .

Separate four kinds of review

RDF gives identifiers and relationships a common representation, but an identifier’s spelling does not create shared meaning. Two teams can use the same label differently, or different labels for overlapping concepts. Mapping them should retain qualifications and uncertainty rather than silently equating them. [3]

The review result should record who proposed the extension, which examples were checked, and why it was accepted or rejected. PROV-O offers terms for that derivation and attribution history. A model can help draft definitions and find candidate examples; it should not grant its own proposal institutional authority. [4]

A vocabulary change is a data migration

Suppose version 1 permits a commitment without an explicit condition field, while version 2 requires that field for conditional undertakings. Existing records cannot be upgraded honestly by filling every missing value with “none.” Some require re-reading the source; some remain unknown; some may belong to another type. Retain the original interpretation and the mapping decision.

Pin the vocabulary and validation-rule versions used for a capsule. A consumer should reject an unsupported migration or show its limitations. Derived summaries and query templates may also need rebuilding: a filter written for an earlier definition can become incomplete even if the underlying source documents have not changed.

Keep simpler alternatives in the comparison

A controlled list of document tags may be sufficient for discovery. A relational schema can enforce a stable operational process. A domain ontology is useful when explicit distinctions and relationships support questions those approaches handle poorly. There is no basis for dismissing established medical or financial ontologies because their goals and scale differ from ours.

Extensions also consume context and maintenance effort. Sending a large vocabulary with every prompt may cost more than retrieving a few relevant definitions and examples. Measure definition-selection errors, prompt size, preprocessing, migration work, and review time together. A smaller prompt that omits the condition defining the case is a regression.

Evaluate on cases that resist the definition

Test with positive examples, near misses, ambiguous language, and cases from a second domain. Ask independent reviewers to apply the definition, record disagreements, and identify which fields would change an answer. Compare extraction and analytical usefulness before and after adding the extension; also track schema churn and the cost of maintaining mappings.

The TACITUS direction is reviewed extension proposals through DIALECTICA, inspected in PRAXIS and packaged with capsule context. Conversational ontology authoring and reliable enforcement across agents remain under development. A useful extension should earn its place by clarifying work that matters, not by increasing the number of types in the system.

Review a definition change before migrating the records

Consider a proposed extension from one “start date” field to procedure_state, legal_effect and obligation_state, keyed to a named instrument and provision. A reviewer checks the definitions against a proposal, adopted text and application exception. Version the extension and preserve the old definition; do not mechanically convert historical January proposals into effective obligations. Imported records need an explicit mapping or a failed compatibility receipt. This website extension is explanatory; it does not migrate the PRAXIS production schema. [5]