Pipelines

Pipelines are the execution layer in WyrdOS. If engines explain why work matters, pipelines explain where work lives, when it should happen, and what needs to move next. Operators use pipelines every day. Buyers should read pipelines as the part of WyrdOS that prevents strategy from remaining a slide deck.

The pipeline model is deliberately simple:

Container -> Zone -> Action

A container owns a broad area of work. A zone defines a focused area of activity inside or alongside that container. An action is a concrete item that can move through a work status.

Containers

Containers are broad work areas or responsibilities. A good container has durable ownership and enough surface area to hold multiple zones, pages, documents, and actions.

Use containers for things like:

• Product
• Growth
• Platform
• Customer onboarding
• Enterprise sales
• Internal operations

Do not use containers for single tasks. Fix onboarding button copy is an action or maybe a zone, not a container. Product or Beta onboarding can be a container if it owns repeated work and context.

Containers carry status, priority, type, category, linked pillars, linked value goals, linked goal outcomes, pages, master documents, zones, and actions. They are also one of the most important scoping tools in the product. Many views and APIs can filter by container because containers define an operating boundary.

Zones

Zones are focused work areas. They often represent a phase, initiative, sprint-like focus, dated workstream, or operating area inside a container. A zone should be actionable enough that a team can review progress, but broad enough to hold more than one action.

Examples:

Zones support dates such as do date, due date, and end date where relevant. They also connect to containers, pillars, and goal outcomes. Those relationships are what make a zone more than a calendar entry.

Use a zone when:

• Work needs a time window or review point.
• Several actions belong to the same focused effort.
• You need a visible bridge between strategy and daily action.
• A container is too broad for the current conversation.

Actions

Actions are the concrete work items. They can belong to containers and zones, carry do and due dates, and move through action-specific statuses:

Actions are useful because they give operators a concrete handle on execution. They should not carry the entire strategic explanation. If an action needs a long justification, that explanation probably belongs in the linked zone, container, page, or evidence.

Status And Priority

Containers, zones, value goals, and goal outcomes use broad operating statuses such as Backlog, New, Next up, Active, Future, Completed, Cancelled, and On hold. They also support priority values: No priority, Low, Medium, High, and Urgent.

Status answers where the work is in its lifecycle. Priority answers how much attention it should receive relative to other work. Mixing those two creates confusion. A high-priority item can be on hold. A low-priority item can be active. A completed item should usually no longer compete for attention.

What You Can Do In WyrdOS

The Pipelines area supports index pages, detail pages, and combined layouts.

On index pages you can:

• Search containers, zones, and actions.
• Filter by status, priority, type, category, date, and relationships where available.
• Group by status, priority, category, container, zone, pillar, value goal, or goal outcome depending on the view.
• Switch between list, grid, and kanban-style views where supported.
• Configure visible columns so the view matches the operating question.

On detail pages you can:

• Edit the rich content area for context and decisions.
• Set status, priority, and dates.
• Link related strategy entities.
• Attach pages and documents.
• Review child zones and actions from a container.
• Open calendar or ontology views from container-specific routes.

Pipelines also support side-by-side and top-bottom layouts so operators can compare containers and zones without constantly changing pages.

Example Workflow

For beta onboarding, the operator might set up:

The container links upward to Product clarity and Beta users understand onboarding. The zone inherits the operating context. The actions stay small and executable.

What Good Usage Looks Like

Strong pipeline setup:

• Containers represent durable ownership or operating domains.
• Zones represent focused work with dates or review moments.
• Actions are small enough to complete and review.
• Active zones belong to containers.
• Active containers link to at least one pillar or goal outcome.
• Filters and groupings help the team answer real questions.

Weak pipeline setup:

• Containers are used as a dumping ground for unrelated tasks.
• Zones are created without dates, owners, or relationships.
• Actions carry strategic explanations that should live elsewhere.
• Status becomes a proxy for priority.
• Old active work stays active because nobody reviews the pipeline.

Trust Notes For Buyers

Pipelines build trust by showing whether the operating model is actually used. A buyer can inspect whether strategic goals have active containers, whether containers have current zones, whether zones have concrete actions, and whether work has dates and review points.

The value is not only task tracking. The value is traceable execution: work can be filtered, reviewed, linked to strategy, and exported or automated through stable API and CLI surfaces.

Automate This

Use API and CLI automation when you need repeatable imports, exports, or reporting:

• Containers API
• Zones API
• Actions API
• CLI resource commands
• CLI operational commands