This document addresses a structural gap in the ontology: what happens when situations persist long enough to become the contexts within which other situations occur? The answer resolves the confusion between projects and domains, establishes situation scale as a continuous property rather than a type distinction, and shows how the directory hierarchy maps to the ontology as materialization rather than identity.
The running examples from [[01-objects]] continue: (a) a student sitting an examination, (b) a doctor diagnosing a patient, (c) a lawyer arguing a case in court, (d) a chef preparing a meal. Two new examples ground the argument in HAAK's own operation: (e) a research project producing a paper, (f) a Claude Code session within that project.
#The Problem
Definition 11 of [[01-objects]] defines a situation as "a particular, ongoing coming-together of actors, methods, and domains around materials." The examples given are short-lived: this Tuesday's exam, this morning's ward round, this week's trial. These situations occur within domains that exist independently — the examination hall, the hospital, the courtroom.
But some situations persist. A research project runs for months. A trial may last years. A medical treatment extends over a patient's lifetime. These long-lived situations accumulate resources, attract participants, develop internal structure, and become the contexts within which shorter-lived situations occur. A review round happens "within" the inscription project. A witness examination happens "within" a trial. A chemotherapy session happens "within" a cancer treatment.
The ontology as stated does not address this. It defines domains as contexts that "exist independently of any particular action occurring within them" (Definition 4). But projects do not exist independently of their work — a project is the work. Without writing, reviewing, and experimenting, there is no inscription project. The project came into being when someone decided to write a paper and will cease when the paper is published or abandoned. This is the temporal profile of a situation, not a domain.
Yet the project behaves like a domain. It carries resources (manuscripts, datasets, figures). It has inhabitants (Zach, Claude, reviewers). Sub-work happens "within" it. Policies accumulate in it (style conventions, submission deadlines, co-author agreements). These are all domain properties from Definition 4.
The question is not whether to classify projects as situations or domains. The question is how situations acquire domain-like properties, and what this acquisition means for the ontology.
#Situation Scale
Definition S1 (Scale). The scale of a situation is the extent of its temporal, participatory, and structural reach. Scale is continuous, not categorical. It is a property of the situation, not a type distinction.
All situations are the same kind of object — descriptive token-compounds (Definition 11). What varies is how long they last, how many actors participate, how much internal structure they develop, and how many sub-situations they contain. Four regions of the scale are named here for orientation, not as ontological kinds:
| Region | Duration | Internal structure | Examples |
|---|---|---|---|
| Act | seconds–minutes | None (atomic) | Sending an email. Adding salt to a sauce. Sustaining an objection. Writing a name on an exam paper. |
| Episode | hours–days | Sequence of acts | A review round. A ward round. A day of trial proceedings. Preparing a multi-course meal. A Claude Code session. |
| Project | weeks–months | Episodes, accumulated materials, local policies | Writing the inscription paper. Treating a patient's illness. A trial from filing to verdict. Developing a restaurant's seasonal menu. |
| Program | months–years | Projects, institutional identity | The five-paper arc. A medical residency. A law firm's caseload. A chef's career at a restaurant. |
The boundaries are not sharp. A long episode becomes a short project. A long project becomes a program. The names are conventional, not definitional. What matters is the structural consequence: as scale increases, situations begin to exhibit domain-like properties.
#Domain Acquisition
Definition S2 (Domain acquisition). A situation acquires domain-like properties when it becomes the context within which other situations occur. This acquisition is gradual, not instantaneous. It begins when the first sub-situation references the parent situation as its context.
The mechanism is the quality framework from [[02-relations]]. When a sub-situation S₂ occurs "within" a parent situation S₁, the parent belongs to the sub-situation with quality "domain":
situation:inscription belongs-to situation:review-round-3 quality: "domain"This is the same structural move that Definition R4 makes for institutions. Champalimaud belongs to the situations it governs as "domain" and to the situations it acts upon as "actor." Similarly, the inscription project belongs to its review rounds as "domain" (providing context) and belongs to the five-paper arc as a constituent situation.
The claim is not that long-lived situations become domains — they remain situations. The claim is that they play the domain role for their sub-situations. The domain role is a quality of a belonging, not a property of the entity (R4). Nothing changes its ontological kind. What changes is the set of belongings it participates in.
Running examples:
- (a) The examination (episode) occurs within the academic term (project-scale situation). The term plays the domain role for the exam. The term itself occurs within the university (institution, a persistent domain). At the act level: the student writing their name belongs to the exam situation as "actor"; the exam belongs to the term as "domain."
- (b) A chemotherapy session (episode) occurs within the cancer treatment (project-scale situation). The treatment plays the domain role for the session. The treatment occurs within the hospital (persistent domain). The patient's test results from session 4 are materials that belong to session 5 — the project-situation accumulates state across episodes.
- (e) A review round (episode) occurs within the inscription project (project-scale situation). The project plays the domain role. The project occurs within "AI ontology research" (topical domain) and "Champalimaud" (institutional domain). The project carries resources: manuscripts, datasets, reviewer assignments. These resources belong to the project with quality "material." Sub-situations inherit access to them — a reviewer in round 3 can reference the manuscript from round 2 because both rounds share the project as domain.
- (f) A Claude Code session (episode) occurs within the inscription project (domain). The session has actors (Zach, Claude opus-4-6), methods (writing, reviewing, building), materials (files read and changed), and temporal bounds (session start, session end). The project provides context — when the session begins, its actors inherit the project's accumulated state (the board, the index, the manuscript draft, the review history).
#The Subsumption Question
Domains form a rooted forest via subsumption (Definition 4): a child domain falls within its parent. Does the same hold for situations that play the domain role?
Yes, but with a qualification. Domain subsumption is spatial-institutional: the paediatrics ward is inside the hospital. Situation nesting is temporal-participatory: the review round is inside the project. Both are directed containment, but they are distinguished by their quality:
ward:paediatrics belongs-to hospital:lisbon-central quality: "subsumed-by"
situation:review-3 belongs-to situation:inscription quality: "episode-of""Subsumed-by" and "episode-of" are both instances of the composition quality family (R2). They differ in what they compose: spatial extent vs. temporal extent. A ward inherits all policies of its hospital. An episode inherits all policies of its parent situation — but only for the episode's duration. When the project ends, its policies lapse. When the hospital closes, its policies lapse. The mechanism is the same; the temporal profile differs.
Definition S3 (Situation subsumption). Situation S₂ is nested within situation S₁ when S₂'s temporal bounds fall within S₁'s, S₂'s participants are a subset of (or drawn from) S₁'s participant pool, and S₁ plays the domain role for S₂. Nesting is transitive: if S₃ is nested within S₂ and S₂ is nested within S₁, then S₃ is nested within S₁. This transitivity follows from the transitivity of "episode-of" (meta-quality R5.4).
What nesting is not. Not all temporal containment is nesting. If a doctor diagnoses a patient (situation) and simultaneously a plumber fixes a pipe in the same hospital (situation), the two situations are temporally concurrent within the same domain but neither is nested within the other. Nesting requires the parent to play the domain role — to provide context that the child situation depends on.
#Materialization
Definition S4 (Materialization of a situation). The materialization of a situation is any material entity that records, evidences, or externalizes the situation. The materialization belongs to the situation with quality "materialization" (from the provenance family, R6).
A trial transcript materializes the trial. A patient's medical record materializes the treatment. A project directory materializes the project. An email materializes the communication event. These are all provenance-quality belongings:
directory:projects/inscription belongs-to situation:inscription quality: "materialization"
transcript:session-2026-03-15 belongs-to situation:session-abc quality: "materialization"
document:efta-12345 belongs-to situation:email-001 quality: "materialization"This is the critical distinction that resolves the project-as-domain confusion. The directory is not the project. The directory materializes the project. The project is a situation — a temporal, goal-directed coming-together of actors, methods, and domains around materials. The directory is a material artifact that records the situation's state. The project can change (new participants, new methods, new goals) without the directory structure changing, and vice versa.
HAAK's current implementation treats the directory as the project — navigating to projects/inscription/ is treated as engaging with the project itself. The ontology says this is a convenient shorthand for: navigate to the materialization of the situation, and from the materialization reconstruct the situation's current state (actors, methods, phase, accumulated materials, active policies).
The convenience is real. The shorthand is practical. But the ontological distinction matters when you ask: "what is this project?" The answer is not "this directory." The answer is "an ongoing situation, materialized in this directory, with these participants, at this phase, under these policies." The directory is evidence. The situation is the thing.
#Sessions as Situations
A Claude Code session is a situation at the episode scale. It has:
- Actors: the human (Zach), the agent (Claude opus-4-6 or another model), any subagents spawned
- Methods: writing, reviewing, building, searching — the skills invoked during the session
- Domain: the project-situation that provides context (often identifiable from the board, lifeline, or explicit
#projectinvocation) - Materials: files read, files changed, tools invoked, outputs produced
- Temporal bounds: session start (first message), session end (last message or
/bye) - Goals: the engagement view (Definition 13) — what the session set out to accomplish
Currently, sessions are not entities. They leave traces — board entries, git commits, transcript files — but these traces are not linked to a situation entity. The traces are orphaned materializations: evidence of a situation that was never registered.
The registration is straightforward:
entity: situation:session-2026-03-16-abc
type: situation
zach belongs-to situation:session-abc quality: "actor"
agent:claude-opus-4-6 belongs-to situation:session-abc quality: "actor"
method:review belongs-to situation:session-abc quality: "method"
method:writing belongs-to situation:session-abc quality: "method"
situation:inscription belongs-to situation:session-abc quality: "domain"
transcript:session-abc belongs-to situation:session-abc quality: "materialization"
commit:e3938c7f belongs-to situation:session-abc quality: "materialization"
board-entry:2026-03-16 belongs-to situation:session-abc quality: "materialization"The session-situation is nested within the project-situation. The project plays the domain role. The session's actors are a subset of the project's participant pool. The session's temporal bounds fall within the project's. All the conditions of Definition S3 are met.
Once sessions are registered as situation entities, the query "show me everything related to the inscription project" becomes a graph traversal: find all situations nested within situation:inscription, collect their materializations, return the trails. No grep. No filename heuristics. The structure carries the answer.
#The Domain/Situation Distinction Revisited
With situation nesting in hand, the distinction between domains and situations becomes precise:
Domains are contexts that exist independently of the situations that occur within them. Champalimaud exists whether or not any project is active. "Neuroscience" exists whether or not anyone is doing neuroscience today. The examination hall exists whether or not an exam is being held. Domains have no temporal bounds in the strong sense — they persist until deliberately dissolved. They form a rooted forest via subsumption.
Situations are contexts that exist because of the action occurring within them. The inscription project exists because people are writing a paper. The trial exists because a case was filed. The treatment exists because a patient is sick. Situations have temporal bounds — they begin, continue, and end. They form a directed graph via nesting (which is transitive but not necessarily a tree — a situation can be nested within multiple parent situations if it draws context from more than one).
The overlap is that long-lived situations play the domain role for their sub-situations. This does not make them domains. It means they participate in belongings where the quality is "domain." The distinction is preserved: domains persist independently; situations depend on their constitutive action. A project that loses all its participants and all its work is not a dormant domain — it is a terminated situation.
The HAAK directory hierarchy maps as follows:
| Directory | Ontological status | Reason |
|---|---|---|
ontology/ | Domain (topical) | Exists independently of any specific ontology work |
foundations/ | Domain (topical) | The intellectual foundations persist whether or not anyone is reading them |
patterns/ | Domain (methodological) | Methods, architecture, policies exist as standing resources |
personas/ | Domain (organizational) | Actor profiles persist independently of engagement |
data/ | Domain (infrastructural) | Data stores exist whether or not they are queried |
projects/inscription/ | Materialization of situation | The directory materializes the ongoing inscription project-situation |
projects/face-decoding/ | Materialization of situation | Same: a long-lived situation, not a permanent domain |
strategy/ | Mixed | Some files are domain-level (standing policies); others are situation materializations (plans for specific projects) |
#The Index Identity
The index.md at projects/inscription/ serves two functions simultaneously: it is a document index (routing an agent to the right file in O(log N) time) and a situation index (declaring the inscription situation's current configuration — its phase, its participants, its active policies, its nested episodes). These two functions are the same function.
The Library Theorem ([[02-library-theorem]]) proves that organized retrieval over external memory is O(log N) vs. Ω(N) for flat scan. The theorem is stated for documents, but its subject is more general: any bounded reasoner retrieving from an organized store. A situation hierarchy is such a store. Acts are nested in episodes, episodes in projects, projects in programs. Finding a specific act within a program is a retrieval problem. When each level of nesting has an index — a compressed representation of its contents — retrieval is logarithmic. When it does not, retrieval degrades to scanning transcripts, board entries, and git logs linearly.
The index hierarchy is the materialization of the situation-nesting structure. The Library Theorem's O(log N) bound is a theorem about this materialization.
An index.md is not a file listing. It is a compressed representation of a situation's current configuration, structured for efficient retrieval. The one-liners in the Contents section are the compression; the Details section is the decompression on demand. When the index is current — when the materialization tracks the situation — retrieval is fast. When the index is stale — when the materialization has drifted from the situation — retrieval degrades. This is Foundation 01's "stale index is forgetting," given its ontological explanation: the materialization no longer represents the situation it claims to represent.
The identity between document-index and situation-index is not a coincidence that will break when situations need richer state. It is the deep result. If the inscription project acquires a new policy (reviewer anonymity), a new participant (an external reviewer), or enters a new phase (revision), these belong in the index because they are part of the situation's configuration. An index that cannot carry situation state is too narrow. The fix is always: enrich the index. Never: build a parallel situation-state system.
This connects situation nesting to the core formal result. The Library Theorem quantifies the advantage of organized external memory. Situation nesting is how that organization manifests: situations contain sub-situations, each level indexed. The index hierarchy is not a filing system that happens to be convenient. It is the structure that makes the Library Theorem's bound achievable for the system's own operation.
#Policy Inheritance
Policies accumulate downward through situation nesting, as they do through domain subsumption (Definition 12 of [[01-objects]]). An episode inherits all policies of its parent project-situation. A project inherits all policies of its parent program. The constitution sits at the top — maximal scope, applying everywhere.
But situations, unlike domains, generate a resolution rule for conflicts. When an inner situation's policy conflicts with an outer situation's policy, the inner wins. The formal reason: the inner context has strictly more information than the outer. The project knows things the domain doesn't — its specific goals, its participants, its current phase. The session knows things the project doesn't — what the user just said, what was tried and failed this hour. More local knowledge takes precedence. This is lexical scoping applied to normative compounds.
constitution → "all work must be externalized" (universal)
domain:champalimaud → "use institutional email for correspondence" (domain)
situation:inscription → "reviewer anonymity in this review round" (project)
situation:session-abc → "skip formal tone, user wants directness" (episode)The session-level policy ("skip formal tone") overrides nothing structural — it cannot relax externalization or anonymity. But within its scope, it governs how the agent communicates. The override is local and temporary: it lasts for the session's duration and does not propagate to sibling sessions.
Definition S5 (Policy resolution). When policies at different nesting levels conflict, the innermost applicable policy prevails, provided it does not contradict a policy at a higher scope marked as non-overridable. The constitution is always non-overridable. Domain policies are overridable by default unless marked otherwise. Situation-level policies govern only within their temporal and participatory bounds.
This is the normative counterpart to situation nesting. Definition S3 describes how situations nest descriptively (what is happening). S5 describes how they nest normatively (what should happen when prescriptions conflict). Together they complete the picture: situations inherit context from their parents and can locally specialize it.
#Foundations Cross-Reference
Situation nesting is not a standalone ontological claim. It is the same mechanism the foundations describe, appearing at the ontological level.
| Foundation | Connection to situation nesting | Mapping |
|---|---|---|
| 01 Core Thesis | "One argument, three scales" | Situation scale (S1) IS the three scales: act = individual, episode/project = scientific, program = institutional |
| 02 Library Theorem | O(log N) retrieval over organized memory | The index hierarchy materializes the situation-nesting structure; the theorem's bound holds when the materialization is current |
| 03 Institutional Intelligence | Alignment is governance, not calibration | Policy inheritance through nested situations (S5) is governance — structuring the situations within which agents operate |
| 05 Externalization | Every step visible, every decision traceable | Materialization (S4) IS externalization, given ontological precision: situations are externalized as material entities with provenance-quality belongings |
| 07 Coordination Topology | Context switching without losing state | Context transport is movement between situations; checkpoint-trace-engage is: materialize current situation → record navigation → enter new situation |
| 08 Agent Mortality | Identity is context; writing is survival | Sessions are episode-scale situations; agent death is situation termination; externalizations are materializations; siblings are co-participants in a parent situation |
#Ordered Composition
A secondary gap exposed by this analysis: the quality framework lacks a mechanism for ordered composition. Author 2 on a paper, track 3 on an album, slide 5 in a deck, episode 4 of a project — these are belongings that carry ordinal position. The belonging relation as defined (entityid, target, quality, startdate, end_date, source) has no place for rank.
Two approaches:
Approach A: Position as a quality. The quality "second-author" is an instance of "author" with an implicit ordinal. This proliferates qualities — "first-author," "second-author," "third-author," etc. — and does not generalize.
Approach B: Position as a property of the belonging. Add a rank field to the belonging:
belongings (
entity_id TEXT
target TEXT
quality TEXT
rank INTEGER -- ordinal position within a quality-group
start_date TEXT
end_date TEXT
source TEXT
)This is the pragmatic choice. Rank is not a quality (it does not specify the nature of the dependence — "author" does that). Rank is a property of the belonging itself: among all belongings of this target with this quality, where does this one fall? It is metadata about the belonging, not about the relationship.
Approach B preserves the quality framework's parsimony. Qualities carry semantics. Rank carries ordering. They are orthogonal. A belonging can have both: "person X belongs to paper Y with quality 'author' at rank 2."
The same mechanism handles episode ordering within a project-situation. Episode 3 of the inscription project is a belonging with quality "episode-of" at rank 3. The rank establishes sequence without requiring a separate temporal ordering scheme (though temporal ordering provides independent confirmation).
#Implementation Consequences
This document establishes five things that the current implementation lacks:
- Situation as entity type.
entities.dbneeds entities of typesituation. Projects, sessions, review rounds, communication events — all become queryable nodes in the graph.
- The "episode-of" quality. A new quality in the composition family, distinct from "part-of" (spatial) and "member-of" (organizational). "Episode-of" is temporal composition with ordering.
- The
rankfield on belongings. A nullable integer that handles ordered composition universally: author position, track number, episode sequence, slide order.
- Session registration. Each session becomes a situation entity with standard belongings (actors, methods, domain, materializations). Board entries, transcripts, and commits link to the session-situation via materialization quality.
- Project reclassification. Projects are situations, not domains. The directory that carries their files is a materialization. The project itself is an entity of type
situationwith temporal bounds, participants, and nested sub-situations.
None of these changes require restructuring the domain databases. Papers.db keeps its paperauthors table. Health.db keeps its records table. The change is in entities.db and in the conceptual mapping — how domain schemas are understood relative to the ontology. The declarative schema mapper (when built) will express the mapping: paperauthors.position maps to rank on a belonging with quality "author."
#Scope and Continuation
This document addresses the structural gap between situations and domains. It does not address:
- Engagement nesting — the normative counterpart. If situations nest, engagements nest too: the goal of the session-engagement is subordinate to the goal of the project-engagement. This is stated in Definition 13 ("sub-engagements") but not formalized.
- Situation termination — when and how a situation ends. Temporal bounds record the fact; the conditions that trigger termination (completion, abandonment, supersession) are policy questions, not ontological ones.
- Situation discovery — how situations are identified in source data. This is the mapping engine pattern from [[09-situation-graph]], which remains applicable without modification.
ontology · 12 · situation nesting · 2026-03-16 · zach + claude
Ontology 12 — Situation Nesting — 2026 — Zachary F. Mainen / HAAK