Overview

Software Factory turns events in your repositories into work done by agents. A pull request opens, a check fails, a scanner finds a vulnerable package, a label is added, a schedule fires: the factory matches the event to a workflow, starts a run, and walks the run through the workflow’s graph. Some steps are decided by a fast classifier model, some are deterministic checks, some dispatch a crew of agents to a machine, and some wait for a person. The last step writes the result back to GitHub.

Everything the factory does is recorded. Every step lands in the event stream, every change of state in the hash-chained audit ledger, and every outcome in Delivery.

Core objects

Most pages in these docs describe one of these. The console column is the page you see it on, under https://www.vulnetix.com/resolve/.

Object	What it is	Console
Managed org	A GitHub App installation the factory may act on. Nothing outside a managed org is touched.	factory-repos
Workflow	A versioned graph of nodes and edges with limits. Drafts are edited; a published version runs.	factory-workflows
Run	One execution of a published workflow version, made of steps.	factory-runs
Decision	A step where a System One model picks one of the outcomes you listed.	factory-workflows
Crew	Agents dispatched together to one machine for one step.	factory-workforce
Card	A unit of work on the board. A card and its GitHub issue are one record.	factory-board
Checkpoint	Anything waiting on a person: an approval, an agent’s question, a held or blocked card.	factory-checkpoints
Budget	A token, call or USD limit on the month, day, workflow, run, step, repository or org.	factory-budgets
Audit entry	A hash-chained record written in the same transaction as the change it describes.	factory-audit

What happens in a run

1. A trigger fires. A webhook, a cron schedule, a scanner finding, a label, a card moving on the board, or a manual start. Debounce and the hourly run cap are checked first.
2. The engine checks holds. If the factory is paused or stopped, or a maintenance window or schedule blackout is in force, the run waits as held. It is not dropped.
3. Nodes run in graph order. A decision picks an edge, a gate passes or fails without a model, a crew leases a machine and dispatches agents, a human node waits for a person.
4. Anything that needs a person becomes a checkpoint. The run waits as waiting_approval and shows on the Checkpoints page and the cockpit’s Needs you list.
5. Output nodes write to GitHub: a draft pull request, a review, a comment, a VEX statement or a TEA release.

Where the work runs

Crews run on hosts: machines running the Belai agent harness. A host is either a Pix Sandbox, a container Vulnetix runs for you, or a machine of your own connected with belai rc. The factory picks the host for each step from the step’s runOn setting and the placement rules.

Find the page for your task

I want to	Read
Let the factory draft pull requests on one repository only	Autonomy
Run a workflow when a label is added	Labels and commands
Stop everything now	Pause, stop and resume
Find out why a run is held	Holds and blackouts
Cap what one run can spend	Budgets
Choose which machine a crew runs on	Hosts and placement
Fix a publish error like no_trigger	Error codes
Check on the factory from my phone	Calling Pix

Elsewhere

• The Software Factory product page explains what it is for and how it is priced.
• Pix Sandbox describes the machines crews run on.
• Belai is the agent harness inside every session.
• Announcing Software Factory gives the reasoning behind the design.