The Value Streams — Streams, Projects, and Product Areas

The Value Streams — Streams, Projects, and Product Areas

See also: universe | constitution | pipeline | blueprint

“A universe isn’t one thing being built. It’s several worlds within a world — each with its own rhythm, its own backlog, its own definition of done. The stream is how you tell them apart.” — Sal

---

TL;DR

• A Stream is the primary work channel inside a universe — the pipeline through which the crew delivers value
• Projects are optional sub-groupings within streams — not required. Issues can live directly in a stream without a project
• The Universe Inbox holds unsorted issues (stream_id = null) — work that hasn’t been triaged yet
• Sal triages unsorted issues from the inbox to streams — this is a core conductor responsibility
• Issues flow through streams, optionally into projects, and ship as releases
• The hierarchy: Universe → Streams → Projects (optional) → Issues
• Blueprint can declare the stream and project topology as version-controlled config

---

What a Value Stream Is

Work doesn’t flow through a single channel. A team building a SaaS product might have:

• Core product — the main application, where most engineering work lives
• Public API — a distinct surface with its own release cadence and stakeholder audience
• Mobile — a separate platform with different physics (different release gate, different QA requirements)
• Infrastructure — a stream that feeds the others but has no customer-visible release

Each of these is a different channel through which value reaches a different audience at a different pace. They share a universe — the same physics, the same crew, the same Observatory — but they are distinct streams.

In Sector 137, a value stream is implemented as a Stream (the primary channel) containing optional Projects (sub-groupings).

---

Streams — The Primary Work Channel

Status: IN DESIGN (v0.11.0 — The Season)

A Stream is the top-level work channel inside a universe. Every universe has at least one stream. Streams are where Sal routes work after it enters the universe.

Schema: universe_streams

• id, universe_id, name, description, slug, active, created_at, updated_at

UNIVERSE: Acme Inc
│
├── STREAM: Product Development
│   ├── PROJECT: Core Product (23 issues, v2.4.0 active)
│   ├── PROJECT: Public API (8 issues, v1.2.0 draft)
│   └── Issues not in any project (5 unsorted within stream)
│
├── STREAM: Infrastructure
│   └── Issues (14 issues, no projects — flat stream)
│
└── UNIVERSE INBOX (unsorted — stream_id = null)
    └── 3 issues awaiting triage

The Triage Flow

1. Issue enters the Universe Inbox (stream_id = null) — either created by the Captain, captured via MCP, or filed by the crew
2. Sal triages the issue to a stream (stream_id set) — this is a core conductor responsibility
3. Optionally, the issue is sorted into a project within the stream (project_id set)

Triage is not optional — it’s how work moves from “captured” to “routed.” An issue in the inbox is a signal that hasn’t been classified. Sal watches the inbox count. When it grows, the pipeline is accumulating unrouted work. That’s a health signal.

“The inbox is where ideas land before they become work. Don’t let it grow. Triage is routing — and routing is what I do.” — Sal

---

Projects — The Implementation of Value Streams

Concept	Product	DB table
Universe	Universe	universes
Value Stream	Project	projects
Work Item	Issue	issues
Work Output	Release	releases

Projects sit between the universe and the pipeline. They organize:

• Issues: every backlog item belongs to a project — features, bugs, chores, improvements
• Releases: every release belongs to a project — the ship event that closes a sprint and signals stakeholders
• Personas: personas can be linked to specific issues, which are project-scoped
• Kano Studies: research missions run within a project context
• API Keys: project-scoped API keys — each key belongs to one project and sees only that project’s data
• Tags: project-specific labels — tags are scoped to a project, not the universe

A project is not just a folder. It’s a stream with its own physics:

• Its own U_local contributing to U_global
• Its own pipeline state (a project can be FLOWING while another in the same universe is CONSTRAINED)
• Its own release cadence (monthly vs continuous vs quarterly)
• Its own stakeholder audience

---

Multi-Stream Universes

A universe with multiple projects has multiple simultaneous value streams. Sal routes incoming work (issues) to the correct stream based on category, assignment, or explicit selection.

UNIVERSE: Acme Inc
│
├── VALUE STREAM: Core Product
│   ├── Issues: 23 open (12 in active sprint)
│   ├── Releases: v2.4.0 (active), v2.3.x published
│   └── Pipeline: FLOWING
│
├── VALUE STREAM: Public API
│   ├── Issues: 8 open (3 in active sprint)
│   ├── Releases: v1.2.0 (draft)
│   └── Pipeline: CONSTRAINED (rate limit issue blocking release)
│
└── VALUE STREAM: Mobile
    ├── Issues: 14 open (0 in active sprint)
    ├── Releases: none active
    └── Pipeline: HALTED (awaiting platform decision)

The universe-level HUD (U_global) aggregates health across all active streams. A CONSTRAINED stream in the API project drags down U_global just like a CONSTRAINED stream in the core product would — because both represent unrealized value delivery.

---

The Workbench — Value Stream Control

The Workbench is the HUD visor mode where the Captain manages all value streams.

From the Workbench, the Captain can:

• See all projects (value streams) in the universe
• Create new projects (open a new value stream)
• Navigate into a project to see its pipeline, issues, and releases
• Archive projects that have reached end-of-life

“The Workbench is where you look at the whole portfolio before you pick up a tool. Multiple projects, multiple states, one universe. You can see which streams are flowing and which ones are stuck.” — Sal

---

Value Stream Health

Each project contributes its own health signal to U_global. The weighted average across all active projects determines the universe’s overall health.

The contribution weight of each project to U_global is proportional to its velocity — a project shipping frequently has higher weight than a dormant one. This means the universe’s health is naturally dominated by the streams that are actively delivering value.

When a project goes dormant (no issues resolved, no releases shipped in a cycle), its contribution to U_global gradually diminishes. This is not a penalty — it’s an accurate representation of where the crew’s energy is actually flowing.

---

Blueprint Schema

Value streams (projects) are configurable in universe.toml via [[projects]] — one entry per project, allowing the Captain to declare the universe’s project topology as a version-controlled artifact.

TOML key	Type	Default	Status
projects[].project_id	string	—	IN DESIGN
projects[].name	string	—	IN DESIGN
projects[].description	string	""	IN DESIGN
projects[].active	boolean	true	IN DESIGN
projects[].default_report_cadence	string	""	IN DESIGN
projects[].start_date	string (ISO 8601)	""	IN DESIGN
projects[].end_date	string (ISO 8601)	""	IN DESIGN
projects[].crew	array of strings	[]	IN DESIGN
projects[].humans	array of strings	[]	IN DESIGN

[[projects]]
project_id = "core"
name = "Core Product"
description = "The main application — customer-facing features and bug fixes."
active = true
default_report_cadence = "monthly"
start_date = "2026-01-01"
end_date = ""
crew = ["sal", "kael", "wren"]
humans = ["captain"]

[[projects]]
project_id = "api"
name = "Public API"
description = "REST and webhook surface for integrators."
active = true
default_report_cadence = "continuous"
start_date = "2026-01-01"
end_date = ""
crew = ["sal", "kael"]
humans = ["captain"]

[[projects]]
project_id = "mobile"
name = "Mobile"
description = "iOS and Android applications."
active = false   # stream paused — no active work this season
default_report_cadence = "quarterly"
start_date = "2025-09-01"
end_date = "2026-02-28"
crew = ["sal", "kael"]
humans = []

Deploy semantics:

• Existing project (matched by project_id) → update name, description, active, default_report_cadence, start_date, end_date, crew, humans
• New project_id → INSERT a new project, linked to the universe
• Project in DB but absent from TOML → no change (projects are not implicitly archived by Blueprint — use active = false explicitly)
• Issues and releases already scoped to a project are not affected by Blueprint deploy

project_id: stable slug, used for SDK scoping and API key assignment. Cannot be changed after project creation without migrating all scoped records.

default_report_cadence: informational — surfaces in the HUD as a signal to the crew. Governs how often Sal generates a status report for the stream, not when releases ship. Does not enforce automatic release creation. Values: "continuous" | "weekly" | "monthly" | "quarterly" | "" (unset).

start_date / end_date: the operational window for the stream. start_date is when the stream opened — when the crew started routing work through it. end_date is set when the stream closes (reaches end-of-life or completes its seasonal purpose). An active stream with no end_date is open-ended. An active stream with a future end_date is time-boxed — a season in progress.

crew: array of agent slugs assigned to this stream — e.g. ["sal", "kael", "wren"]. These are the agents whose Tick cycles include this stream. Crew assignment does not restrict which agents can act on stream issues, but it signals to the Tick Engine which agents should be evaluating stream health and surfacing relevant actions.

humans: array of human role slugs or user IDs assigned to this stream — e.g. ["captain", "user_abc123"]. Used for notification routing, triage priority, and HUD scoping. A stream with no humans assigned is crew-managed: the agents run it, and the captain sees it only at the universe level.

Tracked in: “Blueprint: Add [[projects]] section — value stream topology via config”

---

Relationship to the Pipeline

The pipeline processes issues. Every issue belongs to a project. Every release belongs to a project. The pipeline IS per-project — its state (FLOWING / CONSTRAINED / DEGRADED / HALTED) is computed per value stream.

Value Stream (Project)
  └── Pipeline
        ├── Issues (backlog → in_progress → completed)
        ├── Gates (review, QA, stakeholder sign-off)
        └── Releases (draft → active → published)

When the Captain navigates from the Workbench into a project, they’re entering that value stream’s pipeline. The HUD switches from universe-level view to project-level view — zooming in from the portfolio to the stream.

---

Implementation Status

Capability	Product Support	Status
Project CRUD	Full create/read/update/delete	LIVE
Issues scoped to projects	All issues belong to a project	LIVE
Releases scoped to projects	All releases belong to a project	LIVE
Project-scoped API keys	Each API key tied to one project	LIVE
Project-scoped tags	Tags belong to a project, not the universe	LIVE
Kano studies per project	Studies are project-scoped	LIVE
Multi-project universe (Workbench)	Multiple projects in one universe	LIVE
Per-project pipeline state	Each project has independent pipeline health	LIVE — computed from issue velocity + release cadence
Per-project U_local contribution	Weighted contribution to U_global	PARTIAL — U_global exists; per-project decomposition not yet surfaced
Blueprint [[projects]] deploy	TOML topology import	IN DESIGN
Value stream health dashboard	Per-stream health in the Workbench	IN DESIGN
Project archival	Mark stream as end-of-life	PARTIAL — projects can be deleted; soft archive not yet implemented

Packages

Package	Description
apps/app	Core system — projects table, project CRUD routes, project-scoped issue/release/tag queries
packages/sdk	TypeScript SDK — project-scoped resources, API key project binding
packages/mcp	MCP server — list_projects, project-scoped issue/release tools