Factory operating model
How ideas become tickets, tickets choose workflows, runs and approvals move work forward, and shipped work is accepted.
Runyard's factory model has one source of truth for the durable ask and one source of truth for execution:
- a Factory Item is the ticket the company cares about;
- a run is one durable execution attempt against that ticket;
- an approval is a declared human decision with a recorded consequence;
- a board is the operator-facing projection of those facts.
The board is not a second workflow engine. It is a view over tickets, linked runs, and decision records. That keeps product direction, implementation evidence, release gates, and history in one place even when the work is launched from Telegram, the web app, CLI, API, MCP, ACP, schedules, or hooks.
1. Signal becomes a ticket
Incoming signal should become a Factory Item before it becomes execution. A good factory ticket carries enough context for a workflow to act without asking the operator to reconstruct intent:
- title, description, project, type, priority, owner, and requester;
- acceptance criteria and evaluation gates;
- affected surfaces and known risks;
- next action and any blocker;
- an implementation prompt when the next workflow is known.
Research and scout workflows should create proposal tickets in triaged or another pre-Ready lane. They should not enqueue implementation directly when the product decision is still unresolved.
2. Product direction is approved once
When a proposal needs product judgment, the Hub creates or reuses one product-decision approval card keyed to the Factory Item. Replays, delivery retries, and reconciliation runs must converge on the same card instead of creating duplicates.
The decision has durable consequences:
| Resolution | Ticket consequence |
|---|---|
approved | Move to ready; if the Ready lane has an auto trigger, launch the configured workflow. |
changes_requested | Keep the same proposal and revise it in place with the human comment. |
rejected | Do not launch; leave the ticket closed or parked with the reason. |
superseded | Retire stale cards when the ticket has already moved on. |
changes_requested is not a duplicate-proposal loop. The current ticket remains the canonical product ask, and the next proposal text is written back to that same ticket before it can be approved.
3. Ready selects a workflow
Ready means the next workflow or manual action is known. A board lane can suggest, confirm, or automatically launch a workflow:
| Trigger mode | Operator model |
|---|---|
suggest | Show the likely workflow, but let a human launch it. |
confirm | Ask before enqueueing and linking a run. |
auto | Server-owned launch after a successful move into the lane. |
Auto triggers run on the server for every caller surface, not only the web app. They include ticket fields, board/lane metadata, and trigger input in the run request. Duplicate suppression is also server-side: a live linked run prevents a second launch, and each lane-entry event records its launch evidence.
4. Runs move the ticket
Linked runs keep ticket state current while preserving the distinction between product status and execution status:
| Run state | Ticket movement |
|---|---|
queued, assigned, running | running |
waiting_approval, paused, budget_exceeded | waiting |
succeeded | review, or shipped on boards that opt into autonomous shipping |
failed | blocked with an explicit blockedReason |
cancelled | No automatic movement |
A run failure is not a failed ticket. It is evidence that the ticket needs a retry, a revised input, a different workflow, a credential, or a human decision.
5. Exceptions become decision cards
Tickets in blocked or waiting should carry a concrete nextAction or blockedReason. When that state requires product/operator input, reconciliation ensures one implementation-exception approval card exists. The card must say what happened, what evidence was observed, what downside remains, the recommended option, and the exact ask.
If the ticket lacks enough evidence for a meaningful card, reconciliation should record a diagnostic event instead of inventing a generic approval.
6. Review, release, and acceptance
review is the inspection lane. Operators verify the linked run evidence, compare the acceptance criteria, and decide whether to promote. Release work should record:
- implementation commit and release tag;
- local gates and CI/build evidence;
- deployment evidence;
- smoke checks for the affected surfaces;
- any follow-up risk that remains.
shipped means the change is merged, released, and deployed with evidence. accepted means the original ask has been confirmed as satisfied. Keep those distinct so release automation can close its work while product acceptance remains explicit.
7. Recovery loop
When a linked run fails or blocks, the ticket should remain actionable:
- Retry same run when the failure is deterministic and the fix is infrastructure or environment recovery.
- Rerun with edited input when the workflow contract was wrong or incomplete.
- Move back to triage/ready when the product ask changed.
- Ask for a decision only when the next step genuinely needs a human.
The retry/repair controls on the ticket and board card exist for this loop: operators should not have to leave the Work surface to keep an approved card progressing.
Related references
- Factory Items covers the ticket schema, statuses, linked-run rollups, and API/MCP operations.
- Boards covers lanes, triggers, transition policy, portable definitions, and run-status movement.
- Approvals covers approval kinds, resolution semantics, timed approvals, and Telegram delivery.
- Runs covers attempts, recovery, promotion, logs, artifacts, and run drafts.