Practical companion to [[02-relations]]. That document establishes the theoretical foundation: one relation (belongs-to), the quality mechanism, meta-qualities, reflexive closure. This document applies the framework to the systems that implement it: how the entity graph gets populated, how qualities are assigned, what epistemic status the resulting assertions carry, and how the system's own operations become auditable entries in the graph it produces.
The central result: every act of extraction — mining a filesystem, reading a transcript, indexing a document — is itself a situation in the ontology. The extraction situation has actors (agents, humans), methods (models, prompts, context), materials (the documents processed), and products (the entities and belongings created). These products link back to the extraction that produced them via provenance qualities. The system documents its own documentation, all the way back to the code that wrote the code.
#1. The Epistemic Gradient
The entity graph contains assertions of varying epistemic status. These are not different kinds of data — they are all belongings with qualities — but they differ in how they were produced and therefore in how much confidence they warrant.
Structural assertions. A file is in a directory. The belonging (file belongs-to directory, quality: "part-of") is true by construction. The filesystem is the fact. These assertions are the ground floor — they cannot be wrong unless the filesystem itself is corrupt.
Declared assertions. A document's frontmatter says status: active or related: ontology-objects. The author asserted the relationship. It could be outdated or mistaken, but it was intentional. Source: frontmatter.
Extracted assertions. A regex matched [[01-objects]] in the body of a document. Syntactic evidence of a reference. The document's author probably intended the dependency, but the extraction is mechanical — it cannot distinguish a genuine intellectual dependency from a passing mention. Source: mine:haak-filesystem.
Inferred assertions. An LLM reads a transcript and extracts "Zach proposed database-driven triage rules." This is a propositional claim about a situation that probably occurred. The claim is shaped by the LLM's interpretive frame — which model ran, what context was loaded, what domain was active. Source: the extraction situation itself (see §3).
All four produce the same data structure. The source field and the provenance chain distinguish them. Downstream consumers — queries, visualizations, inference engines — can filter by epistemic level as needed.
#2. Materialization vs. Evidence
When a belonging links an entity to a source document, two provenance qualities do different work:
Materialization. The artifact IS the thing. An email is a materialization of a communicative act — the email doesn't report the communication, it constitutes it. A commit is a materialization of a code change. A WhatsApp message is a materialization of a request. The artifact and the act are the same event viewed from different angles.
Evidence. The artifact WITNESSED the thing. A Zoom transcript is evidence of a meeting — the meeting happened in real time; the transcript is a record produced afterward. A handwritten note is evidence of an insight. A photo is evidence of a scene. The artifact and the event are distinct; the artifact is a trace.
The distinction matters because materialization is definitional (if the email exists, the communicative act occurred) while evidence is defeasible (the transcript might be garbled, the note might be misread, the photo might be staged).
Some artifacts carry both qualities simultaneously. A published paper materializes the act of writing AND evidences the scientific findings reported within. These are two belongings with different qualities between the same pair of entities, or between the paper and two different situation entities (the writing situation and the experimental situation).
| Source artifact is... | Quality | Defeasible? |
|---|---|---|
| The event itself | materialization | No — artifact = act |
| A record of an event | evidence | Yes — record ≠ event |
| A report about an event | evidence (nested) | Yes — chain of custody |
| An intellectual product | both | Materialization: no; Evidence: yes |
#3. Extraction as Situation
Every act of populating the entity graph is itself a situation. When an agent reads a transcript and creates situation entities, the agent is an actor in an extraction situation whose material is the transcript and whose products are the new graph entries.
situation:extraction-run-2026-03-10 (type: situation)
belongs-to agent:opus-4-6 quality: "actor"
belongs-to transcript:2026-01-27 quality: "material"
belongs-to project:5ht-novelty quality: "domain"
belongs-to method:deep-extraction-v1 quality: "method"
situation:adam-contradiction-claim (type: situation)
belongs-to transcript:2026-01-27 quality: "evidence"
belongs-to situation:extraction-run quality: "derived-from"The derived-from link is the epistemic chain. It says: this inferred situation was produced by that extraction run. The extraction run's belongings record who ran it (actor), what was processed (material), under what interpretive frame (domain), and with what procedure (method).
The method entity captures the full extraction context:
method:deep-extraction-v1 (type: method)
belongs-to agent:opus-4-6 quality: "actor"
belongs-to skill:capture quality: "implements"
belongs-to prompt:entity-extraction quality: "method"Different methods produce different results from the same material. A Haiku scan of a transcript yields coarse-grained situations (who spoke, what topics). An Opus deep read yields fine-grained situations (what was argued, what was implied, what was left unsaid). The method entity's qualities formally distinguish these — not as labels but as structural differences in the graph.
#4. Ostensive Inference and Relevance
Extracting situations from unstructured text is not decoding. It is ostensive inference (Sperber & Wilson, 1986): the extractor infers what the speaker meant to make relevant, not just what they said.
"I've been thinking about database-driven triage" — propositional content: a mental state report. Ostensive meaning: a design proposal. The situation to extract is not "Zach had a thought" but "Zach proposes database-driven triage rules for the storage pipeline."
The quality assignment on every extracted belonging is an act of ostensive inference. When Adam says "Gonçalo's paper contradicts the serotonin hypothesis," the extractor must judge: is Adam an actor (making an argument), a source (reporting what he read), or a sender (alerting Zach to a problem)? The quality depends on communicative intent, which depends on context — the project domain, the conversational history, the relationship between the speakers.
This means every extraction carries an implicit theory of relevance that shaped which situations were extracted, which entities were identified, and which qualities were assigned. The theory is not declared — it is embodied in the extraction method's belongings: which model ran, what domain was active, what persona was loaded.
The domain belonging on the extraction situation IS the relevance frame. It says: "this extraction was performed in the context of the 5HT project, which determined what counted as salient." A different domain — say, the lab governance project — would extract different situations from the same transcript. Both are valid; neither is complete. This is withdrawal ([[02-relations]] §7) applied to the extraction process itself.
#5. Multi-Agent Provenance
In a running system, multiple agents and multiple humans contribute to the entity graph concurrently. Each contribution is a situation with its own actors, methods, and provenance.
A Haiku agent triages incoming files — creates belongings with quality "stored-in" and "instance" (tagging). An Opus agent indexes a newly arrived PDF — creates situation entities with quality "evidence" linking back to the PDF. A human reviews the Opus output and corrects a quality assignment — that correction is itself a situation with the human as actor and the Opus extraction as material.
The graph does not privilege human over agent contributions. Both produce belongings; both are tracked through extraction situations; both carry provenance chains. The difference is in the method entity's qualities — a human correction carries different epistemic weight than an automated scan, and that difference is recorded structurally, not as a special case.
This extends to collaboration. When Zach and Opus co-author a document ([[06-ai-writing-scenario]]), the writing situation has two actors with different qualities: Zach as actor (steering the argument) and Opus as actor (generating text). The document materializes their joint production. The provenance chain records both contributions — who wrote the code that wrote the code, who shaped the ontology that shaped the extraction, who corrected the error that changed the graph.
#6. Quality Assignment Rules
The filesystem miner (scripts/minehaakgraph.py) assigns qualities based on the structural relationship between source and target entity types:
| Source type | Target type | Quality | Rationale |
|---|---|---|---|
| any | same type | extends | Peer documents build on each other |
| any | foundation, ontology | grounds | Theoretically grounded in |
| architecture, method, policy | foundation | implements | Makes operational a theoretical claim |
| any | method, pattern | method | Uses as procedure |
| any | project | subject | Is about |
| any | policy | governs | Normative constraint |
| file path | entity | materialization | File is physical trace of entity |
| frontmatter | status value | status | Lifecycle state |
| frontmatter | predecessor | supersedes | Version replacement |
| frontmatter | related path | depends-on | Generic intellectual dependency |
| directory | parent | part-of | Containment |
These rules are the miner's theory of relevance (§4). They are explicit, auditable, and revisable. When a quality assignment is wrong, the rule that produced it is identifiable and correctable — and the correction itself becomes a situation in the graph.
#7. Domain Database Convergence
The entity graph subsumes six domain-specific databases, each a system of record for its domain:
| Domain DB | Entity types | Key qualities |
|---|---|---|
| music.db | track, artist, album, genre, crate | track-on, author, instance, part-of |
| papers.db | paper, person, journal, doi | author, published-in, cites, cited-by |
| books.db | book, person, genre | author, instance, status |
| contacts.db | person, org | member-of, collaborator |
| files.db | file, bucket, tag | stored-in, instance, materialization |
| public-archives.db | document, person, org | evidence, participant, source |
The domain DBs remain systems of record — they are not replaced. Schema mappings (declarative transformations) project domain-specific records into the entity graph as entities and belongings with appropriate qualities. The mappings are themselves methods: they have actors (the mapping script), materials (the domain DB), and products (the graph entries). The mapping run is a situation.
#8. Session Memory: Save, Reconstruct, Compare
Multi-agent coordination requires that the system's memory is consistent regardless of which agent reads it, when. The test: ask "where are we?" before closing a session, clear context, ask again. The answer must be identical. If it diverges, the memory system is broken.
Three operations achieve this:
Save. At every checkpoint, the session writes its state as a situation in the entity graph:
situation:session-2026-03-10-quality-graph (type: session)
belongs-to agent:opus-4-6 quality: "actor"
belongs-to ontology:10-relations-applied quality: "created"
belongs-to script:mine-haak-graph quality: "created"
belongs-to entities.db quality: "material"
belongs-to situation:session-prev quality: "predecessor"
belongs-to fingerprint:abc123 quality: "materialization"The fingerprint is a hash of the session's outputs: entity count, belonging count, quality distribution, files modified, git HEAD. It captures the state in a single comparable value.
Reconstruct. Any agent — fresh session, different model, no prior context — queries the graph to derive the current state:
SELECT * FROM belongings
WHERE entity_id LIKE 'situation:session-%'
ORDER BY start_date DESC LIMIT 10The result is the same regardless of who asks. No board to skim, no text to interpret. The graph is the memory.
Compare. At session start, the agent reconstructs the state from the graph and compares it to the most recent saved fingerprint. If they match, the graph is consistent. If they diverge, something mutated state without recording it — a rogue process, a concurrent write, a schema-breaking rebuild. The divergence is the alarm.
This is the Library Theorem applied to the system's own coordination. Without the entity graph, "where are we?" requires a linear scan of board.md — O(N) in the number of past sessions, and fragile (agents skim text, miss entries, interpret differently). With it, reconstruction is a structured query over indexed situations — O(log N), deterministic, auditable. The indexed condition should outperform the flat condition measurably, and the save-compare loop is the integrity mechanism that detects when it doesn't.
Board.md becomes a view. The board is currently HAAK's last unstructured coordination channel — the equivalent of a WhatsApp group chat between agents. Under this model, it becomes a generated view over session situations, like Apple Contacts is a view over contacts.db. The file can still exist for human readability, but the source of truth is the graph. An agent that reads only the graph and an agent that reads the board should reach the same conclusions — and the comparison proves it.
#9. Scope
This document covers the applied framework: epistemic gradient, materialization vs. evidence, extraction as situation, ostensive inference, multi-agent provenance, quality assignment rules, domain convergence, and session memory. It does not cover the theoretical foundations (see [[02-relations]]), the situation-graph query model (see [[09-situation-graph]]), or the data model implementation (see [[22-lifecycle]]).
The next step is implementation: building the extraction pipeline that reads documents, creates situation entities, records its own extraction situations, and populates the graph with auditable provenance chains. The pipeline's design is shaped by this document; this document was shaped by the ontological discussion that produced it; that discussion is itself a situation in the graph.
ontology · 10 · relations-applied · 2026-03-10 · zach + claude
Ontology 10 — Relations Applied — 2026 — Zachary F. Mainen / HAAK