Ontology Guide

Ontologies & Formal Vocabulary

An ontology in Lightwell is not a taxonomy of topics — it is a typed vocabulary of mechanisms, patterns, formal families, and invariants that extracted knowledge must speak. This guide covers the element types, evidence grading, and layer model used across the platform.

Why a formal vocabulary?

Free-text knowledge cannot be verified. When a source says a system renews itself through observing its own output, that claim is unfalsifiable prose. When the same claim is typed as a system element with a recursive self-model motif, an inferred evidence grade, and an A4 altitude, it becomes checkable: does the extracted structure actually exhibit recursion? Does the invariant hold under domain substitution?

The ontology is what lets two extractions from wildly different domains — a myth and a control system — be compared structurally rather than rhetorically.

Element types

system

System element

A mechanism with state and behavior: boundary crossings, state reassignments, constraint violations, feedback loops. Systems are the verbs of an ontology.

motif

Motif

A recurring pattern that carries structural meaning across instances: permission gradients, recursive self-models, conservation themes. Motifs are evidence of a generator at work.

formal_family

Formal family

The mathematical class a structure belongs to: state transition systems, Bayesian estimators, hypergraphs, Markov chains. Formal families make structures comparable across domains.

invariant

Invariant

A property that must hold true for the structure to be valid: conservation of causal structure, type soundness, termination. Invariants are the unit of trust.

Evidence grading

Every extracted element carries an evidence grade declaring how it came to exist. Grades are preserved through the whole pipeline — a downstream consumer can always distinguish what the source said from what the pipeline concluded.

explicitStated directly in the source and traceable to a passage.

implicitImplied by structure or repeated pattern, but never stated outright.

inferredDerived by the extraction pipeline from converging evidence. Always flagged as such.

Anatomy of an extracted element

CIR element — example record

{
  "id": "s01",
  "element_type": "system",
  "title": "Boundary Crossing",
  "summary": "Agent transitions across restricted domain boundary",
  "evidence_type": "inferred",
  "altitude": "A4",
  "extracted_structure": ""
}

element_type selects the ontological class. evidence_type grades provenance. altitude positions the structure on the abstraction scale documented in the Compiler Docs.

extracted_structure holds the formal payload once the element has been through typing — empty until the CIR stage assigns it. An element without a typed structure can never be promoted into an architecture.

The G-A-S-O layer model

Compiled architectures are organized into four layers, from the most concrete to the most abstract:

1. Generators

The machinery that produces the output: the functions whose application generates the domain’s behavior.

2. Architectures

How generators compose: pipelines, feedback loops, hierarchies of control.

3. Structures

The typed data the machinery operates on: states, events, relations.

4. Ontology

The vocabulary itself: element types, invariants, and the rules for combining them.

Working with ontologies

See the ontology applied to real extractions in the Cangjie Extractor, and browse verified formal families in the Architecture Library.

Open Extractor Architecture Library