Zachary F. Mainen · HAAK · Architecture 44 · March 2026

Engagement Threading

Engagements are currently isolated records. Each captures a single topic within a single session, but nothing connects them across sessions. Three concrete gaps:

#1. The problem

Engagements are currently isolated records. Each captures a single topic within a single session, but nothing connects them across sessions. Three concrete gaps:

Threads. Work often spans many sessions and many engagements. A home reorganization might touch personal files, music, contacts, lab data, and papers across a dozen sessions over two weeks. There is no way to query "show me everything related to the home reorganization" without full-text search and manual assembly.

Dependencies. Some engagements cannot start until others finish. A lab database build depends on a contacts cleanup. A paper submission depends on a review round completing. These dependencies exist in the user's head but not in the data.

Handoffs. When an engagement is handed off (phase: handed-off) or spawns successor work, there is no structural link between predecessor and successor. The successor agent reconstructs the relationship by reading boards and guessing.

Monitoring. Some completed engagements need periodic re-checking: a data migration should be verified after a week, a deployed daemon should be confirmed stable, an outcome (approval email, delivery) should be watched for. The current phase vocabulary has no state between "completed" and "abandoned" that captures this ongoing low-intensity attention.

#2. Schema additions

Three new optional fields on the engagement object within engagements.jsonl, plus one new phase value.

{
  // existing fields unchanged: topic, project, method, phase, key_decisions, outcome, turn_range

  // NEW: stable identifier for cross-referencing
  "id": "reorg-contacts-2026-03",

  // NEW: thread membership (string, thread slug)
  "thread": "home-reorg-2026",

  // NEW: dependency and handoff links (arrays of engagement IDs)
  "depends_on": ["reorg-personal-files-2026-03"],
  "continues": "reorg-contacts-2026-03-initial"
}

#Field definitions

FieldTypeRequiredDescription
idstringNo (backward-compatible)Stable engagement identifier. Format: <topic-slug>-<YYYY-MM>. Must be unique across the JSONL file. When absent, the engagement is unreferenceable.
threadstringNoThread slug grouping related engagements. Any engagement with the same thread value belongs to the same thread. Threads are implicit -- they exist when two or more engagements share a value.
depends_onstring[]NoIDs of engagements that must reach a terminal phase (completed, abandoned) before this one can meaningfully start. Informational, not enforced.
continuesstringNoID of the predecessor engagement this one continues. Used for handoffs: when engagement A ends with phase handed-off and engagement B picks up the work, B's continues points to A's id.

#New phase: monitoring

Added to the phase vocabulary alongside existing values. Semantics: the primary work is done, but the engagement requires periodic verification. Distinct from completed (done, no further attention) and in-progress (actively being worked). An engagement in monitoring may transition to completed (verified OK) or back to in-progress (problem found, work resumes).

#3. How threads work

A thread is a shared tag, not a container. There is no thread object, no thread metadata file, no thread lifecycle. Threads emerge from the data.

Creation. When an agent writes an engagement and recognizes it belongs to a broader effort, it sets "thread": "slug". The first engagement to use a thread slug creates the thread implicitly.

Membership. Any engagement sharing the same thread value belongs. Thread membership is many-to-many with sessions: one session may contain engagements in different threads, and one thread spans many sessions.

Querying. engagement_search.py --thread home-reorg-2026 returns all engagements in that thread, sorted chronologically. Thread overview: all unique thread slugs with counts and date ranges.

No nesting. Threads are flat. If a sub-grouping is needed, use a more specific thread slug (home-reorg-2026-music vs home-reorg-2026-contacts). Hierarchical threads would violate principle 4 (no unnecessary structure).

#4. How dependencies work

Dependencies are informational annotations, not enforcement mechanisms. They answer: "what should have been done before this engagement started?"

Semantics. "depends_on": ["X"] means: engagement X reaching a terminal phase is a precondition for this engagement to proceed meaningfully. An agent reading this can check X's phase and warn if the dependency is unmet.

Handoff chain. "continues": "X" means: this engagement is the direct successor of X. The chain is a linked list -- follow continues pointers to reconstruct the full history of a piece of work across session boundaries. Unlike depends_on (which is a prerequisite gate), continues is a provenance link (this work came from that work).

Cycles. Dependencies must be acyclic. continues chains must be acyclic. No enforcement -- agents are expected to set sensible values. Circular dependencies are a data quality bug, not a system failure.

#5. Ontological grounding

All four additions map to existing ontological primitives from 02-relations.md.

AdditionOntological mapping
idEntity identity -- the engagement becomes a referenceable entity in the situation graph
threadBelongs-to with quality "member-of" -- the engagement belongs to the thread-situation as a participant
depends_onBelongs-to with quality "prerequisite" (temporal quality family) -- the dependency belongs to the dependent engagement as an enabling condition
continuesBelongs-to with quality "successor" (temporal quality family, inverse of "predecessor") -- provenance chain
monitoring phaseQuality of the engagement-situation -- a phase-quality like any other, positioned between completion and active work in the phase graph

Threads are situations in the ontological sense (Definition 11 of 01-objects): compounds of belongings where multiple engagements participate as members. They are lightweight situations -- no actors, no obligations, no phase graph. Just a grouping context.

Dependencies are enabling conditions (Definition 4 of 39-engagement-state): the completion of a dependency is a condition that enables a transition in the dependent engagement's phase graph. The depends_on field externalizes this condition so any agent can evaluate it.

#6. Extensions to engagement_search.py

Four new capabilities:

--thread SLUG         Filter by thread membership
--threads             List all threads with engagement counts and date ranges
--chain ID            Follow continues chain for an engagement, showing full history
--deps ID             Show dependency tree for an engagement (what it depends on, what depends on it)

The --threads subcommand aggregates: for each unique thread value, show the count of engagements, earliest and latest dates, and phase distribution (how many completed, in-progress, blocked, monitoring).

The existing --active flag should also match monitoring phase (engagements needing attention).

#7. Migration path

Backward-compatible. All four fields are optional. Existing engagements without them continue to work. No rewrite of the JSONL file is required.

Incremental annotation. When session_scribe.py processes new sessions, it should attempt to:

  1. Generate id values for each engagement (from topic slug + date).
  2. Detect thread membership when the session summary or board context mentions an ongoing effort.
  3. Detect continues links when an engagement's topic closely matches a recent handed-off or in-progress engagement.

Retrofit batch. A one-time script can scan existing engagements and propose thread and continues annotations based on topic similarity and temporal proximity. Human review before committing -- automated linking will have false positives.

ID uniqueness. On first retrofit, if two engagements would generate the same ID, append a disambiguator (-2, -3). The scribe should check for collisions on write.

#8. Example: filesystem reorganization thread

From the existing data, sessions deep-crafting-owl, humble-pondering-met, and vast-petting-pnueli all contain filesystem reorganization engagements. With threading:

// Session: humble-pondering-met (2026-03-19)
{
  "topic": "Filesystem reorganization and cleanup",
  "id": "reorg-filesystem-2026-03-a",
  "thread": "filesystem-reorg-2026",
  "phase": "blocked",
  "method": "reorg",
  "depends_on": []
}

// Session: deep-crafting-owl (2026-03-19)
{
  "topic": "Complete filesystem reorganization blockers and cleanup",
  "id": "reorg-filesystem-2026-03-b",
  "thread": "filesystem-reorg-2026",
  "phase": "completed",
  "method": "reorg",
  "continues": "reorg-filesystem-2026-03-a"
}

// Session: vast-petting-pnueli (2026-03-20)
{
  "topic": "Evaluate and execute merge of filesystem reorganization branch to main",
  "id": "reorg-merge-2026-03",
  "thread": "filesystem-reorg-2026",
  "phase": "completed",
  "method": "reorg",
  "depends_on": ["reorg-filesystem-2026-03-b"],
  "continues": "reorg-filesystem-2026-03-b"
}

Query: engagement_search.py --thread filesystem-reorg-2026 returns all three, showing the progression from blocked to completed to merged.

Query: engagement_search.py --chain reorg-merge-2026-03 follows continues pointers backward: merge <- completion <- initial block.

architecture . 44 . engagement threading . 2026-03-22 . zach + claude

Architecture 44 — Engagement Threading — 2026 — Zachary F. Mainen / HAAK