Zachary F. Mainen · HAAK · Methods 55 · March 2026

Engagement Tagging

Engagement tagging assigns engagement IDs to individual rounds within inscribed sessions. The tags are the filtering key for every engagement-scoped operation in context surgery (method 54):…

Engagement tagging assigns engagement IDs to individual rounds within inscribed sessions. The tags are the filtering key for every engagement-scoped operation in context surgery (method 54): compress-engagement, extract-engagement, and split all depend on rounds carrying engagement_id values. Without tags, those operations have nothing to select on. Tagging is the bridge between the session record (what happened) and the engagement model (what it was for).

#Engagement Discovery

Before tagging a session, enumerate the engagement vocabulary. An engagement ID is a short, stable, human-readable slug that identifies a workstream. The vocabulary comes from four sources, checked in order:

engagement.md files. Active projects may already have engagement.md files (architecture 39) with engagement_id fields in their frontmatter. These are authoritative — use them as-is.

Board entries. Board posts that mention distinct workstreams often name them implicitly. "Console work is done" implies a console-work engagement. Read board.md for workstream names that recur.

Session content. Many sessions predate the engagement model. Their workstreams must be discovered by reading the round previews. Look for topic transitions — where the conversation shifts from one concern to another. Each distinct concern is a candidate engagement.

Cross-session consistency. The same workstream may appear in multiple sessions. Use the same engagement ID everywhere. The vocabulary is global, not per-session.

#Engagement ID Format

<domain>-<topic>, lowercase, hyphen-separated. The domain is the area of work; the topic is the specific concern. Examples:

  • infra-session-inscription — building the session inscription system
  • infra-console-viewer — web console, viewer consolidation, browser design
  • infra-engagement-system — engagement skills, engagement.md format
  • infra-agent-runner — agent runner development
  • infra-exoscale-deploy — Exoscale deployment, sync, remote services
  • design-context-surgery — context surgery model, compression, split/merge
  • design-knowledge-org — knowledge organization, filesystem restructuring
  • design-situation-browser — situation browser design and iteration
  • design-panel-claims — panel creation standard, claim extraction
  • project-5ht-talk — 5HT talk/slides work
  • project-asc-review — ASC review process
  • project-inscription-paper — inscription paper/arXiv
  • project-library-theorem — Library Theorem paper, arXiv submission
  • project-fct-grants — FCT grant applications
  • meta-session-management — roster, dispatch, agent coordination
  • meta-role-coordination — standing role handoffs, mandate work
  • ops-system-health — CPU issues, daemon management, file watcher problems

The vocabulary grows as new workstreams are discovered. Prefer reusing an existing ID over creating a near-duplicate.

#Classification Process

For each session:

#Step 1 — Read the round previews

Read the session's index.md table. The you said and agent said columns provide enough signal to identify topic boundaries in most rounds. For ambiguous rounds, read the full round JSON.

#Step 2 — Identify topic transitions

Scan sequentially. Note where the conversation shifts from one engagement to another. Transitions are usually visible as:

  • The user introduces a new topic ("ok, now let's work on...")
  • A long time gap between rounds (the user left and returned with a different concern)
  • A task notification arriving from unrelated work
  • The user explicitly switching context ("what about the console?")

#Step 3 — Assign engagement IDs

Apply one engagement_id per round. Rules:

  • Primary content wins. A round belongs to the engagement it primarily advances. If a round discusses console work for 80% and mentions the inscription system briefly, it gets the console tag.
  • Meta-rounds follow context. Rounds like "what's on deck?" or "wrap up" get tagged with the engagement they're embedded in. If they are genuinely cross-cutting (spanning multiple engagements equally), leave them null.
  • One tag per round. No multi-tagging. The engagement_id column is a single value, not a list. When a round spans two engagements, assign the dominant one.
  • Task notifications inherit. <task-notification> rounds get the engagement of the task that produced them, which is usually the engagement of the preceding user request.
  • Interrupted rounds. Rounds that are interrupted ([Request interrupted by user]) with no substantive content get the tag of the surrounding block, or null if isolated.
  • System rounds. Rounds from /model, /compact, and other CLI commands get null unless they are clearly part of an engagement transition.

#Step 4 — Consistency checks

After initial classification, verify:

  • No isolated tags. A single round tagged X surrounded by rounds tagged Y is likely wrong. Check whether the content genuinely belongs to X.
  • Clean transitions. Tags should form contiguous blocks. Alternating tags (X, Y, X, Y) suggest either the engagements are really one thing, or the transition points need adjustment.
  • Reasonable block sizes. An engagement block of 1-2 rounds in a long session is suspicious. Either the content was too brief to constitute a real engagement (tag it with the surrounding engagement), or it is a genuine micro-engagement (keep it, but note it).

#Step 5 — Summary table

Produce a summary per session:

Session: 24f52300 (75 rounds)
  infra-session-inscription: rounds 1-12, 16-27
  infra-console-viewer: rounds 38-58
  design-context-surgery: rounds 59-75
  null (meta/system): rounds 13-15, 28-37

The summary is the review artifact. The human reviews it before tags are written to SQL.

#Writing Tags

Tags are written via the session scribe CLI:

python3 infra/scripts/session_scribe.py tag <uuid> <range> "<engagement_id>" --agent <agent_id>

The <range> is either a single round number, a lo-hi range, or all. Examples:

python3 infra/scripts/session_scribe.py tag 24f52300-... 1-12 "infra-session-inscription"
python3 infra/scripts/session_scribe.py tag 24f52300-... 38-58 "infra-console-viewer"
python3 infra/scripts/session_scribe.py tag 38ebd26a-... 1-58 "project-fct-grants" --agent sill

Tags are mutable. Re-running the command overwrites previous tags for those rounds. This is safe — the block store is never modified, only the SQL index.

#Retroactive Tagging at Scale

For sessions that predate the engagement model (the majority of the corpus), batch tagging proceeds as follows:

  1. Prioritize. Start with the longest and most recent sessions — they contain the most active workstreams.
  2. Discover vocabulary. The first pass through key sessions establishes the engagement vocabulary.
  3. Propagate. Once the vocabulary is stable, older sessions can be tagged faster — the engagement IDs are known, and round content is matched against known patterns.
  4. Validate. Cross-session queries (SELECT engagementid, COUNT(*) FROM rounds GROUP BY engagementid) verify that the vocabulary is consistent and coverage is adequate.

#Relationship to Other Methods

Session inscription (method 53) produces the round records that tagging annotates. Inscription is prerequisite; tagging is post-hoc annotation.

Engagement state (architecture 39) defines what an engagement is. Tagging connects individual rounds to engagement instances. When an engagement.md exists, its engagement_id is the tag value.

Context surgery (method 54) consumes tags. compress-engagement, extract-engagement, and split all filter on engagement_id. Without tags, these operations cannot distinguish workstreams within a session.

method . 55 . engagement tagging . 2026-03-20 . zach + claude

Methods 55 — Engagement Tagging — 2026 — Zachary F. Mainen / HAAK