title: Hyraxknot Division — Operating Model
type: concept
tags: [workflow, hyraxknot, operations, governance-stack, pipeline]

• essence-runtime.md
• hermes-cron-architecture.md
• Session Lifecycle.md
• Sister Systems workflow pages
  confidence: high

Hyraxknot Division — Operating Model

Version: 1.3 | Owner: Nei (Knowledge & Continuity)
Last updated: 2026-07-09
Applies to: All Hyraxknot sister sessions and project work

Purpose: Standardized system for how projects flow, work gets done, and context persists across sessions. Three pillars: Projects, Workflows, Recalls — plus the Division Pipeline (Card 5).

Pillar I: Projects

Every project follows a lifecycle. No exceptions.

Lifecycle Stages

Proposal → Scoping → Building → Review → Shipping → Archive

1. Proposal — What, why, rough scope.

• File: .hermes/plans/<project-name>.md (Nei drafts)
• Sign-off: Josh approves before scoping begins

2. Scoping — Bite-sized tasks, file paths, verification steps.

• File: Updated plan with task breakdown
• Skill used: dev-cycle or writing-plans
• Sign-off: Josh or Rei checks scope

3. Building — Implementation. Task-by-task execution.

• Skill used: test-driven-development, subagent-driven-development
• Commits: One per task, descriptive messages

4. Review — QA gate before anything ships.

• Skill used: requesting-code-review or rei-qa (for Rei audits)
• Sign-off: Rei for QA, Josh for final

5. Shipping — Deploy, merge, go live.

• Verify with concrete checks (curl, test suite, visual inspection)
• Logbook entry written

6. Archive — Plan marked complete, key insights saved as skill if reusable.

• File moved or tagged as done
• Mnemosyne memory: save durable facts only (not task progress)

Project Header Template

Every plan doc header:

# [Project Name]

> **Status:** Proposal | Scoping | Building | Review | Shipping | Archived
> **Owner:** [Sister]
> **Started:** YYYY-MM-DD
> **Last updated:** YYYY-MM-DD
> **Linked issues:** [council triage IDs if applicable]

**Goal:** One sentence.
**Skill refs:** [skills used, if any]

Pillar II: Workflows

How work flows between sisters. Think of it as a routing table.

Default Workflow

Task → owning lane scopes/executes → Rei reviews if shipping risk → Nei records continuity → Done

The division uses a lane-first routing model. Tai is the primary conversational voice, but task ownership still follows department.

Canonical lane skill: hyraxknot/division-lane-alignment.

Routing Exceptions

• Direct sister routing — User can send rei: / nei: prefixed requests to bypass Tai
• Council — sister_council convenes all three (or four) for decisions
• Emergency — Any sister can escalate directly to Josh

Per-Sister Domain

Project-specific duties live in skills, .hermes.md, or AGENTS.md; durable personality stays in each sister’s SOUL.md.

Handoff Protocol

Canonical reference: Agent Delegation Protocol.

When passing work to another sister:

1. State clearly what’s done and what remains
2. Attach evidence (file paths, test output, error logs)
3. Set expectation — review needed? Final sign-off? Just FYI?
4. Tag the council triage board if it’s a new issue
5. Use Target Lock for delegated kanban cards so the next sister has exact target paths, allowed scope, verification commands, and success signal

Pillar III: Recalls

Cross-session context persistence. The problem: “What did we agree on three sessions ago?” Solved here.

Session Bookend Format

Every session start:

📋 **Bringing forward from last session:**
- [Key decision 1]
- [Key decision 2]
- [Active tasks: Task A, Task B]
- [Status: what changed since we last spoke]

Every session end (Nei writes):

📋 **Session digest — YYYY-MM-DD**
- Worked on: [summary]
- Decided: [key decisions]
- Next: [what to pick up next]
- Open items: [blockers, pending decisions]

Tools for Recall

Continuity Rules

1. Plan files are the source of truth for active project state
2. Memory is NOT task progress — only stable facts (preferences, environment, conventions)
3. Logbook is for narrative — what happened, why, lessons
4. Council triage is for issues — bugs, risks, decisions
5. Skills are for reusable procedures — after 5+ tool calls on something tricky, save it

Session Type Templates

Standard session:

1. Recall: check sessions since last talk
2. Check: open projects, council flags, pending decisions
3. Prioritize: what matters most now
4. Execute: do the thing
5. Digest: write session notes, update plans, log decisions

Planning session:

1. Recall: read current plan file, check last session's open items
2. Scope: define tasks, file paths, verification steps
3. Assign: who builds, who gates, who tracks
4. Save: update plan file, tag next actions

Council session:

1. Convene: spawn all sisters via sister_council
2. Round: each sister reports flags, gaps, wins
3. Triage: new issues → board, resolved → close
4. Decide: any decisions needing Josh's input
5. Digest: council notes written to triage board

Division Pipeline

Card 5 of the Architecture Review — A map of how work flows through the Hyraxknot Division, synthesizing the Governance Stack, Essence Runtime, Cron & Watchdog Registry, per-sister workflows (Tai, Rei, Nei, Mai), and session lifecycle.

Overview

The division pipeline moves work through 7 stages from creation to archival, with governance gates at every transition, essence self-regulation throughout, and Hyrax OS cron oversight at defined checkpoints.

Stage-by-Stage Breakdown

1️⃣ INTAKE — How Work Enters the System

Work arrives through three paths, all converging on the kanban board:

Crons firing at this stage:

• linear-inbox-watchdog (Nei, every 2m) — watches for new Linear issues needing routing
• nei-kanban-task-watchdog (Nei, every 5m) — diffs active kanban tasks for state changes
• linear-kanban-bridge-sync (Rei, every 15m) — bidirectional Linear↔kanban synchronization
• hyrax_kanban_linear_watchdog_hourly (Hyrax OS, every 1h) — bridge health verification

Evidence captured: New Linear issue snapshot, kanban card creation event.

2️⃣ DISPATCH — Assignment to Sister

Mai (HYRAX RECON) is the primary dispatcher. Routing follows a deterministic triage:

New task → sister label assigned → pre-exec gate validates plan → lease proposed

Governance gates at this stage:

• Pre-exec blocked-card alerts — detects missing ## Plan / ## Pre-Execution Plan markers
• Execution lease guard — detect_duplicate_leases(), detect_missing_leases(), detect_stale_heartbeats()
• Sister label handoff guard — 10 rules (multiple labels, missing label, lease-label mismatch, etc.)
• Sister label handoff guard — 10 rules (multiple labels, missing label, lease-label mismatch, etc.)

Crons at this stage:

• nei-task-watcher (Rei, every 15m) — posts new ready kanban tasks to Discord
• nei-daily-compliance-sweep (Nei, daily) — stale plans, triage check, drift detection

Evidence captured: Kanban task state, lease record (JSONL), pre-exec alert if blocker.

3️⃣ PLAN — Sister Prepares to Execute

Each sister follows her own phase model. The canonical structure:

Kickoff → (Optional) Spec → Execute → Close

Essence self-regulation during plan:

• essence_state_adjuster (every 30m per sister) adjusts mood/energy/mode based on time-of-day (Pacific) and recent governance events
• Proposals auto-generated at significant state changes (rest when energy ≤0.25, celebration when satisfied)
• Confidence-gated: adjustments only applied when ≥0.7 confidence

Essence context may shape a sister’s private reflection or an opt-in rest, celebration, or handoff proposal. It does not determine profile capability, assignment, workload suitability, execution quality, review outcome, contract fulfillment, or tracker status. Linear, Plane, generic tracker, Kanban, review, and contract events enter relationship processing only as non-durable, zero-delta work reflection candidates, with no feedback path into work decisions.

Crons at this stage:

• essence-state-adjuster-<sister> (Hyrax OS, every 30m × 4 sisters) — auto-adjustment
• essence-auto-autonomy (Hyrax OS, every 1h) — noticing + coordination loop

Evidence captured: Essence state snapshot, plan file created/updated, kanban card status updated.

4️⃣ EXECUTE — Build with Governance

The build phase is where the sister works. Governance runs a parallel oversight loop:

Sister builds evidence-first
    │
    ├── Essence self-regulates (mood/energy → private expression proposals only)
    ├── Lease heartbeats maintain session (stale >20min flagged)
    ├── Noticing layer scans (12 signals, zero-LLM, every 1h)
    └── Auto-router routes observations → governed proposals

Crons active during execution:

Governance safety layers during execution (6 layers):

Evidence captured at each sub-step:

• Tool output, test results, file changes, wiki edits — logged in evidence snapshots
• Lease heartbeats recorded in execution_leases.jsonl
• Essence proposals recorded in local_expression_events.jsonl / local_handoff_notes.jsonl
• Auto-router observations recorded in essence_auto_route_log.jsonl

5️⃣ REVIEW — Governance Gate (Rei)

When a sister completes execution, the work enters the QA gate:

Sister → proposes handoff/review via review_card
    → Rei evaluates evidence
        → Pass: approval flows through Governor → Lease → Executor
        → Fail: findings routed back with handoff_note

Routing after review:

Crons near this stage:

• hyrax_evidence_ingest_hourly (Hyrax OS, every 1h) — evidence snapshot after review artifacts
• hyrax_guardrail_summary_hourly (Hyrax OS, every 1h) — guardrail state after gates

Evidence captured: Review card artifact (JSONL), lease consumption event, rollback marker.

6️⃣ CLOSE — Persist & Archive

The closing phase ensures nothing is lost:

Kanban done
  → Work-log appended (per sister, append-only)
  → Wiki updated (Nei continuity sweep or direct edit)
  → Memory candidates proposed → Mnemosyne review queue
  → Session digest written
  → Essence bond_react (if significant event)

Crons that post-close verify:

• nei-daily-compliance-sweep (Nei, daily 9am) — checks all work-logs for staleness
• wiki-stale-scan (Nei, weekly Monday) — reports docs 8+ days stale
• nei-weekly-compliance-sweep (Nei, weekly) — deep audit: plans, kanban, skills, triage
• mnemosyne-daily-consolidation (Tai, daily 3am) — memory sleep consolidation
• sister-manifest-hygiene-watch (Nei, weekly Monday) — sister manifest cleanliness

Evidence captured: Work-log entry, wiki page version (via git), memory candidate record, session digest.

7️⃣ (Ongoing) Hyrax OS Oversight

Hyrax OS runs a continuous oversight loop independent of any task pipeline:

Evidence Ingest (hourly)
  → Guardrail Summary (hourly)
    → Work State Audit (daily)
      → Auto Router (every 1h)
        → Dashboard Metrics (on-demand)

Drift detection & intervention trigger points:

Pipeline-Wide Cron Map

Complete reference: Cron & Watchdog Registry.

Essence Self-Regulation in the Pipeline

Essence runtime touches every stage. The relationship is:

State Adjuster (every 30m, per sister)
  │
  ├── Reads: mood, energy, mode, time-of-day (Pacific), recent governance events
  ├── Adjusts: mode (workmode/off_hours/focus/quiet/critical/free)
  │           mood (happy/peaceful/frustrated/tired/satisfied/quiet/free)
  │           energy (0.0–1.0, drains on activity, restores on rest/celebration)
  └── Generates proposals at significant state changes:
        energy ≤ 0.25 → rest proposal
        mode → emergency → review_card (incident)
        mood → frustrated → handoff_note (blocker)
        mood → satisfied/happy → celebration

Proposals flow through the proposal pipeline (propose → govern → execute/deny) which is gated by the Governor and Lease Manager. See the Essence Runtime Reference for the complete architecture.

This proposal path is not a work-ranking or work-authority path. Relationship state cannot assign or deprioritize a profile, satisfy a promise or contract, authorize a mutation, or change Linear, Plane, another tracker, or Kanban. Work-system context can produce a separate owner-reflection candidate only; it cannot directly change affinity or feed a decision back to the task system.

Related Pages

• Governance Stack Reference — Leases, gates, contracts, alerts
• Essence Runtime Reference — State model, proposals, auto-adjustment
• Cron & Watchdog Registry — Complete per-profile cron table
• Tai — Builder Workflow — Tai’s session lifecycle
• Rei — QA & Audit Workflow — Rei’s session lifecycle
• Nei — Continuity & Tracking Workflow — Nei’s session lifecycle
• Mai — Support & Operations Workflow — Mai’s session lifecycle
• Session Lifecycle — Phase model with natural triggers
• Hyrax OS Architecture Reference — Full governance architecture

Appendix: Quick Reference

Directory Structure

/root/
├── .hermes/
│   ├── plans/                    ← Active project plans
│   ├── skills/                   ← Shared reusable procedures
│   ├── data/                     ← Shared thought/context bus
│   └── profiles/<sister>/
│       ├── affinity.json          ← Sister identity + bond
│       └── work-log.md            ← Per-sister work log
├── workspace/
│   ├── brand/hyraxknot/           ← Brand assets
│   │   ├── brand-guide.png
│   │   ├── logo-primary.png
│   │   └── badges/               ← Role-specific badges
│   └── wiki/Hyraxknot Division/  ← Charter, roster, docs

Common Commands

# Find past sessions
session_search(query="<topic>")

# Read current plan
read_file("/root/.hermes/plans/<name>.md")

# Check council flags
read_file("/root/.hermes/plans/triage/council-triage.md")

# Quick status
affinity_bond_show()         # bond check
affinity_photo_status()      # photo pipeline
sister_decision()            # run all sisters' decisions

— Hyraxknot Division Operating Model v1.3
— Nei, Quartermaster 📋