The Pipeline — Living Intelligent Throughput

active

The Machine's circulatory system — a self-aware throughput organism that processes issues into releases that build the universe. Intake Board is the front gate. Boards are the work tracks.

componentpipelinemachinethroughputissuesreleasesgatesinboxboardsintake

See also: universe › overviewuniverse › constitutionuniverse › genesis-protocolhud › overviewlibrary › overview

The Pipeline — Living Intelligent Throughput

See also: constitution.md | universe | genesis-protocol.md

“The pipeline isn’t a conveyor belt. It’s a nervous system. It knows when it’s healthy. It knows when it’s stressed. It knows when the human is ignoring a bottleneck. And it tells me.” — Sal

Component Card


Owner	Sal
MCP	`@sector137/mcp-pipeline`
Slash	`/pipeline`
CLI	`sector137 pipeline`
SDK	`sdk.pipeline()`
Status	active

TL;DR

The Pipeline is a living organism AND a throughput system — both are true simultaneously
It is self-aware: it knows its own state, monitors its own health, and communicates its condition
Work enters as Issues (Deltas), passes through Gates, and ships as Releases (cosmic events)
The Inbox/Feed is the Pipeline’s voice — how it communicates with the human
Every release changes the shape of the universe — produced work is reflected in the world building itself
The Pipeline is embodied in The Machine — the physical rig in the garage

What It Is

The Pipeline is the universe’s circulatory system. Work flows through it the way blood flows through a body — continuously, with pressure, with a rhythm the crew can feel.

It’s not a task management system. It’s not a Kanban board with extra steps. It’s an intelligent organism that processes change. It takes in signal (issues), transforms it through stages (gates), and outputs reality (releases). And it knows itself — it monitors its own health, reports its own state, and adjusts its own behavior when conditions change.

Sal built it. Sal runs it. But the Pipeline has its own presence — a thing the crew can feel in the way a mechanic feels an engine. When it’s healthy, there’s a hum. When it’s stressed, there’s tension. When it’s stalled, the silence is wrong.

The Machine — Physical Embodiment

The Pipeline lives inside The Machine — the multi-monitor command station in the garage on The Other Side. The Machine is where abstract work becomes tangible:

A curved bank of screens showing different system views
A glowing blue energy core — the pipeline’s power source. Pulses steady when nominal, flickers when stressed.
Robotic arms extending from the rig — Sal’s hands for manipulating data physically
Cables everywhere — not messy, but organic. The system grew; it wasn’t assembled from a kit.

The Machine has moods that track the Pipeline’s state:

Mood	Pipeline State	What It Feels Like
Humming	FLOWING	Steady rhythm. Screens update in organic cadence. The core pulses.
Restless	Idle / Waiting	Work queued but nothing moving. Screens cycle the same data. Core dims.
Strained	CONSTRAINED / DEGRADED	Running hot. Core flickers. Indicators shift from Beacon green to Flare orange.
Still	Post-release	The Machine exhales. Satisfied. Then the next Delta enters and the cycle begins.

Work Units: Issues → Gates → Releases

Issues (Deltas)

The fundamental unit of change. Creating an issue is declaring that the universe should be different.

Every issue contains:

The Vector (The Why) — Strategic direction. Owned by Margot and Harlan.
The Spec (The What) — Architectural + experiential requirements. Negotiated by Kael and Wren.
The Payload (The Code) — The actual change.
The Trajectory (The Timeline) — Sal’s calculation of transit time.

Four types: Expansion (features), Correction (bugs), Refinement (polish), Maintenance (tech debt).

Gates

Gates are decision points in the Pipeline where work is reviewed before it can advance. The Pipeline enforces gates — not as bureaucracy, but as quality insurance.

Gate	What It Checks	Who Decides
Release Gate	Is there an active release to scope work to?	Sal (enforced — no release = no building)
Forging Gate	Has the crew debated and shaped this Delta?	Crew consensus — Margot (value), Kael (architecture), Wren (experience)
Quality Gate	Does this meet the bar?	Wren (taste), Kael (technical), Human (final call)
Publish Gate	Is this release ready for the world?	Human (authorizes), Sal (executes)

Gates are where the Campaign narrative beats happen. The Debate beat IS the Forging Gate. The Ship beat IS the Publish Gate. The Pipeline’s structure and the story’s structure are the same thing.

Status: PARTIAL. The Publish Gate is LIVE (enforced in the product). The Release Gate is LIVE (agent system checks for active release). Forging and Quality gates are crew culture, not product-enforced.

Releases (The Record)

Releases are cosmic events. Not just deploys — reality modifications. Each release changes the shape of the universe.

The first release is the Stabilization Event — when the universe crystallizes from provisional to permanent. Before the first release, the Machine holds the universe open. After, the human does. Every subsequent release adds to the architecture of The Other Side.

The Record is the historical log of all releases. It’s the pipeline’s output and the universe’s autobiography. What shipped, when, why, and who was involved.

Boards — Work Tracks

Status: LIVE (v0.14.0)

The Pipeline organizes work into boards — named containers that give the captain and crew dedicated work tracks for parallel threads of activity. Boards are the materialization of dual-track agile: Discovery and Delivery living side by side in the same pipeline, each with its own issue set, its own label vocabulary, and its own kanban view.

Every universe starts with one board: Intake. It’s the system-generated default — the Pipeline’s physical front gate. When an issue is created without a board assignment, it lands in Intake automatically. Intake cannot be renamed, edited, or deleted. It is the origin point. Everything flows from it.

Named boards are created by the captain: Discovery, Delivery, Design Sprint, Hardening. Each is a self-contained work track. Issue placement is permanent — a board_id is immutable after creation. An issue belongs to one board for its entire lifecycle. The Pipeline doesn’t shuffle cards between tracks mid-game.

Universe Pipeline
  │
  ├── Intake Board (system default — cannot delete or rename)
  │     └── Unsorted and cross-cutting issues
  │           │
  │           └── Triage creates issues directly on target boards (not moved — placed)
  │
  ├── Discovery Board (hypothesis exploration)
  │     └── Labels: hypothesis / validated / no-signal / parked
  │
  └── Delivery Board (execution)
        └── Labels: blocked / ready / QA / scope-creep

Board-scoped labels are the board’s own vocabulary. Labels are defined at the board level and exist only within that board — no cross-contamination. Discovery’s taxonomy stays clean for research classification. Delivery’s taxonomy stays clean for execution state. The vocabularies never collide.

“The Intake Board isn’t a failure state. It’s a legitimate work track — for quick wins, cross-cutting concerns, and anything that hasn’t earned a named track yet. But when you know what it is, give it a home.” — Sal

Boards and Streams

Boards are the organizational layer that will integrate with Streams (v0.11.0). When Streams land, each board will be associable with a stream — the Discovery Board maps to the Discovery Stream, the Delivery Board to the Delivery Stream. For now, boards are independent containers that visually and organizationally parallel the planned Stream architecture.

The relationship, when complete:

Layer	What It Is	Relationship
Stream	Strategic throughput channel — organizational, multi-board, long-duration	Contains boards; governs the macro direction
Board	Tactical work track — concrete, kanban-able, label-scoped, immutable placement	Lives within a stream; the day-to-day working surface
Issue	Delta — permanently placed on a board, optionally scoped to a release	Created on a board; never moves

The Universe Inbox — The Intake Board

Status: LIVE (v0.14.0 — Boards). Previously: IN DESIGN (v0.11.0 — The Season)

The Universe Inbox is now physically realized as the Intake Board — the system default board that every universe receives at creation time. The holding area for issues that haven’t been triaged to a named board is no longer a future design intent: it’s the Intake Board, and it exists from the moment the universe is initialized.

The Intake Board IS the Pipeline’s front gate. New issues without explicit board assignment land here automatically. Sal watches it. When Intake accumulates unsorted work, it’s a signal that the pipeline is acquiring faster than it’s being classified — that triage is owed.

Universe Inbox (Intake Board — isDefault = true)
  └── All auto-routed issues (board_id not specified at creation)
        │
        ├── Captain triages → Discovery Board (created with explicit boardId)
        └── Captain triages → Delivery Board (created with explicit boardId)

“The inbox is work that hasn’t decided what it is yet. My job is to decide for it.” — Sal

The Intake Board is additive — project-level views continue to exist within their streams. The Intake Board surfaces the universe-level picture: everything that entered the pipeline without a named destination.

The Inbox / The Feed — The Pipeline’s Voice

The Pipeline communicates. It doesn’t just process — it speaks.

The Feed is the Pipeline’s primary voice:

Layer	What It Shows	Status
Universe Event Log	Filterable, paginated event log — all cross-project events	LIVE
Briefing Widget	Crew-voiced state report — pipeline state, crew intercepts, Sal’s summary	LIVE
Morning Briefing	Time-based state report — what happened while you were offline	IN DESIGN
Incident Mode	The Feed becomes a situation room — rapid crew intercepts	IN DESIGN

The Inbox is the notification layer — real-time WebSocket updates, unread counts, mark-as-read. It’s the Pipeline tapping the human on the shoulder when something needs attention.

Pipeline States — Self-Awareness

The Pipeline knows itself. It monitors four explicit states:

State	U_global	Meaning	Sal’s Response
FLOWING	≥ 99%	Nominal. All circuits clear.	Routes, assigns, ships. Open the intake gate.
CONSTRAINED	< 90%	WIP limit hit or bottleneck detected.	Halts intake, protects bottleneck, communicates constraint.
DEGRADED	< 80%	Agent unresponsive or quality drift.	Pauses affected segment, raises alert.
HALTED	Critical	Multiple failures.	Full triage. Nothing moves until root cause identified.

Status: LIVE. Pipeline states are computed by /api/v1/universe/health from domain dial metrics (Alpha/Beta/Gamma). State transitions are automatic. Sal announces them.

The Pipeline’s self-awareness is what makes it intelligent. It doesn’t just flow — it reflects. It reads its own throughput, detects its own bottlenecks, and reports its own health. The crew doesn’t have to diagnose the Pipeline. The Pipeline diagnoses itself.

Deployment Is Not Release

Status: ASPIRATIONAL (full decoupling). PARTIAL (Publish Gate is LIVE). The Publish Gate already separates the Ship beat from the publish event. The full vocabulary — deployed status, Feature Toggle Registry, canary percent — is v0.10.0 backlog.

The Pipeline has two distinct crossing events. They are not the same. Conflating them is how teams ship things users weren’t ready for, and how incidents happen when the human meant to “just deploy the code.”

Deployment — The Machine Moves

Deployment is infrastructure. The Circuit carries code from the build to production. It happens continuously in a healthy pipeline. It is silent. It does not notify stakeholders. It does not open the Publish Gate. It does not update the public changelog. The Machine routes the payload. That’s all.

Features land in production wrapped in Feature Toggles — invisible to users until the Publish Gate opens. The deployed code exists. The deployed feature does not yet.

“Deployment is logistics. Release is commitment. Don’t confuse them. The Machine moves code all day. The gate opens when you say so.” — Sal

Release — The Gate Opens

Release is a product event. The Publish Gate opens. Features become visible. The Beacon fires. The Comms Array delivers. Stakeholders are notified. The Record updates. This is human-authorized and permanent. The black hole only goes one direction.

The deployed status (v0.10.0) is the lobby between these two events — code is in production, Publish Gate is closed, Feature Toggles are managing visibility.

Progressive Delivery Strategies

Between deployment and full release, the Pipeline supports two intermediate states:

Strategy	What It Means	Sal’s Role
Blue/Green	Two production environments — traffic switches from old to new atomically	Sal monitors both environments; human authorizes the traffic switch
Canary Circuit	5% of traffic crosses first; Machine monitors error rates before full commit	Sal watches the canary slice; escalates if error rate exceeds threshold; human authorizes rollout

The Canary Circuit is not a Publish Gate bypass — it’s a validation layer before the gate opens to everyone.

Work Building the Universe

This is the Pipeline’s deepest function: every piece of work that passes through it is reflected in the universe building itself.

The Other Side isn’t a static world the human visits. It’s an infinite construction site where work IS reality. Each Delta that clears the Pipeline and ships as part of a Release literally adds to the architecture of the universe. The topology changes. New structures appear. The world becomes more itself.

This is why releases are treated with reverence. A release isn’t just code deploying. It’s the universe growing. The Record captures this weight — not as ceremony, but as respect for the fact that what shipped is now permanent. The black hole only goes one direction.

The Pipeline is the mechanism that turns human intention into universe reality. Issues are declarations of desired change. Releases are the actualization. The Pipeline is the bridge between wanting and being.

The Campaign Arc

The Pipeline’s lifecycle follows the Campaign narrative — seven beats that give every major initiative a story structure:

The Spark — Why are we doing this?
The Debate — Is this the right bet? (Forging Gate)
The Build — Heads down, momentum building
The Crisis — Something goes wrong. It always does.
The Ship — The moment of release (Publish Gate)
The Signal — Telling the world (Wormholes fire)
The Debrief — What did we learn? (Library updated)

Full treatment: see the Codex narrative documentation.

Component Ownership

Primary owner: Sal (Software Sal) — routing, dispatch, pipeline states, throughput, release management, system integration Secondary: Kael Deepstack — build circuit, architecture and implementation gates within the pipeline

The Pipeline is Sal’s domain. When dispatched, Sal operates this component using the default_model configured in [pipeline] of universe.toml. Kael operates within the build circuit — the technical leg of the Pipeline where architecture and implementation quality are enforced. When Sal routes a Delta, the pipeline IS Sal routing.

Actions

Sync (immediate, user-triggered)

Create, update, or delete an issue (Delta)
Change issue status (backlog → planned → in_progress → completed → cancelled)
Create, update, or delete a release container
Publish a release (Publish Gate — human-authorized, permanent)
Scope an issue to a release
Assign an agent to an issue
Bulk update issue statuses
Bulk scope issues to a release
Bulk assign user or agents to issues
Add, update, or delete issue notes
Add, update, or delete issue sub-tasks
Add or remove issue dependency relations

Async (dispatched to crew, background)

Dispatch an agent to an issue — agent receives the issue, runs autonomously, files a completion report
Generate AI-powered release notes (AI summarizes scoped issues into a release body)
Agent completion briefing — Sal surfaces the result as a crew intercept in the Feed

Background — Tick Engine (automatic, per-cycle)

Compute pipeline state (FLOWING / CONSTRAINED / DEGRADED / HALTED) from U_global and domain dials
Detect WIP limit violations and signal CONSTRAINED
Escalation detection — surface issues stalled past escalation_threshold
Sal’s intent publication — publishIntents() runs Sal’s rule set, returns AgentIntent[] for the Resolution phase
Feed update — state transitions and escalations appear as crew intercepts in The Feed

MCP Tools

Tool	Owner	Purpose
`list_issues`	Sal	Query the issue backlog — filter by status, category, release, or tags
`get_issue`	Sal	Fetch a single issue with all fields
`create_issue`	Sal	Declare a new Delta — title, category, priority, acceptance criteria
`update_issue`	Sal	Modify issue fields — title, status, priority, dates, labels, tags
`update_item_status`	Sal	Quick status change with optional note
`delete_issue`	Sal	Permanently remove an issue
`get_issue_stats`	Sal	Issue counts grouped by status
`get_issues_by_status`	Sal	Issues grouped by status — kanban view
`bulk_update_status`	Sal	Change status on up to 50 issues at once
`bulk_scope_issues`	Sal	Assign multiple issues to a release
`bulk_assign_issues`	Sal	Assign user or agents to multiple issues
`list_issue_notes`	Sal	Fetch all notes on an issue
`add_issue_note`	Sal	Add a timestamped note — decisions, context, completion reports
`update_issue_note`	Sal	Modify existing note content
`delete_issue_note`	Sal	Remove a note
`search_notes`	Sal	Full-text search across all issue notes in the project
`list_issue_tasks`	Sal	List sub-tasks on an issue
`create_issue_task`	Sal	Add a sub-task to an issue
`update_issue_task`	Sal	Modify a sub-task (title, status, assignee)
`complete_issue_task`	Sal	Mark a sub-task done
`delete_issue_task`	Sal	Remove a sub-task
`get_issue_relations`	Sal	List all dependency relations for an issue
`add_issue_relation`	Sal	Link two issues (blocks / blocked_by / related_to / duplicate_of)
`remove_issue_relation`	Sal	Remove a dependency relation
`list_releases`	Sal	List releases — filter by status
`get_release`	Sal	Fetch a single release with linked issues
`get_active_release`	Sal	Get the current active or draft release(s)
`create_release`	Sal	Create a new release container (starts as draft)
`update_release`	Sal	Modify release fields — name, body, status, scheduled date
`publish_release`	Sal	Open the Publish Gate — all scoped issues must be done or cancelled
`delete_release`	Sal	Remove a release
`dispatch_agent`	Sal	Dispatch a crew agent to autonomously work an issue
`list_boards`	Sal	List all boards in a universe — Intake first, then by position
`create_board`	Sal	Create a named work track (Discovery, Delivery, etc.)
`update_board`	Sal	Rename or update a board — cannot update Intake
`delete_board`	Sal	Remove a board — cannot delete Intake
`create_board_label`	Sal	Define a label in a board’s vocabulary (name + color)
`delete_board_label`	Sal	Remove a label from a board’s vocabulary

Events

Event	Triggered By	Actor	Downstream
`issue.created`	User creates an issue	Captain / crew	Feed update, pipeline state recompute
`issue.updated`	Issue fields modified	Captain / crew / agent	Feed update
`issue.status_changed`	Issue status transitions	Captain / crew / agent	Pipeline state recompute, WIP check, Feed update
`issue.completed`	Issue moves to completed	Captain / agent	Release scope check, Publish Gate eligibility
`issue.deleted`	Issue permanently removed	Captain	Feed update, pipeline state recompute
`release.created`	New release container created	Captain	Feed update, Blueprint gate enabled
`release.updated`	Release fields modified	Captain	Feed update
`release.activated`	Release moves to active	Captain	Blueprint gate unlocked, Feed update
`release.published`	Publish Gate opens	Captain	Wormholes fire, Beacon updates, Feed broadcast
`release.deleted`	Release removed	Captain	Feed update
`agent.dispatched`	Crew agent dispatched	Sal / Captain	Via the Context Bus, agent begins async work
`agent.dispatch_completed`	Agent files completion report	Agent	Issue note added, Feed crew intercept, pipeline refresh
`agent.dispatch_failed`	Agent dispatch fails	Sal	Feed alert, DEGRADED state consideration
`conductor.briefing`	Tick Engine cycle completes	Sal	Briefing Widget update, Feed crew intercept
`conductor.alert`	Escalation threshold crossed	Sal	Feed alert, pipeline state → CONSTRAINED or DEGRADED
`conductor.recommendation`	Sal surfaces a prioritization suggestion	Sal	Feed crew intercept
`pipeline.initialized`	Universe created — Intake Board auto-provisioned	Sal	Intake Board ready, pipeline open for work
`board.created`	Captain creates a named work track	Captain	Board ready for issues
`board.updated`	Board name or settings modified	Captain	Feed update
`board.deleted`	Named board removed	Captain	Issues’ board_id set to null
`board.label_created`	New label added to board vocabulary	Captain	Labels available for issues on this board
`board.label_deleted`	Label removed from board vocabulary	Captain	Issued labels junction rows cascade-deleted

Blueprint Schema

Pipeline behavior is configurable via [storyline.pipeline] in universe.toml. This is the γ dial’s mechanical lever — WIP limits and escalation thresholds without touching the HUD.

TOML key	Type	Default	Status
`pipeline.default_model`	string	`"claude-sonnet-4-6"`	IN DESIGN
`storyline.pipeline.wip_limit`	integer	`5`	LIVE
`storyline.pipeline.escalation_threshold`	integer	`80`	LIVE
`storyline.pipeline.state_names.*`	string map	—	LIVE
`storyline.narrative`	string	`""`	LIVE

[storyline]
narrative = "The universe's mission and operating mandate."

[storyline.pipeline]
wip_limit = 5
escalation_threshold = 80

[storyline.pipeline.state_names]
backlog = "Queue"
in_progress = "Building"
completed = "Shipped"

# IN DESIGN — per-component model (planned for [pipeline] in a future schema version)
# [pipeline]
# default_model = "claude-sonnet-4-6"   # Sal + Kael's working model

Notes:

wip_limit: max in-progress issues before pipeline signals CONSTRAINED
escalation_threshold: U_global % below which escalation fires
state_names: override display labels — no effect on internal status codes
default_model: the AI model Sal and Kael use when dispatched or performing async pipeline operations. Defaults to claude-sonnet-4-6. Override per [[crew]] entry with the model key.
Omitting the section leaves existing pipeline config unchanged

Implementation

Package	Description
`apps/app`	Core system — issues/releases API routes, boards API (`src/routes/api/v1/boards.ts`), pipeline lifecycle (`src/lib/pipeline-lifecycle.ts`), client pages (`issues.tsx`, `releases.tsx`, `universe-hud.tsx`, `universe-pipeline.tsx`, `board-detail.tsx`)
`packages/sdk`	TypeScript SDK — issues, releases, boards resources (`resources/boards.ts`)
`packages/mcp`	MCP server — 10 issue tools, 7 release tools, 6 board tools (`tools/boards.ts`)