The building blocks, grouped by the problem each one solves
Software Factory is a set of parts that run as one line. Each block below says what it does and names the problem it removes.
Decide what is worth doing
GitHub cockpit
Lists the repositories in the GitHub organisations you choose to manage, through a standard GitHub App installation, with their scan state and the runs in flight.
The problem: The factory touches the organisations you chose and no others.
Event-driven triggers
Starts a run from a webhook event, a schedule, an issue label, a scanner finding or a board change.
The problem: A critical exploited finding should not wait for the next sprint.
Vulnetix scanners
Runs SCA, SAST, secrets, IaC, container, malware, licence and end-of-life scans as part of a run.
The problem: Work starts from evidence about what is broken.
Code scanner · SCA · SAST
System One decision nodes
Pick one outcome from a list you define, report a confidence, and take your chosen path below the confidence threshold or on an abstain.
The problem: An unsure answer from a model should reach a person before it reaches production.
Do the work
Agent crews and the agent builder
Five crews (security, feature, bug, delivery and UI) take the cards that suit them, and the builder defines your own agents with handoff rules.
The problem: Specialists pick up the work, and a team can add its own.
Quick-start templates
Eleven ready workflows cover patching, bug fixes, features, dependency upkeep, malware and secret response, release provenance, triage and delivery sweeps.
The problem: A new team starts from a working workflow on one repository.
Outputs
Hand back a draft pull request, an issue comment, a VEX statement, a TEA release publish or a notification.
The problem: The result lands where the team already works.
Pix Sandbox or any belai rc machine
Runs every agent step, scan and test on a managed Pix Sandbox with controlled egress, or on any other machine running belai rc.
The problem: Agents work on code without access to a laptop or an open network.
Prove it
Quality gates and the release jail
Plain rules with no model in the loop decide whether a change passes, returns to the crew or stops.
The problem: A confident model cannot talk its way past a rule.
Trust and provenance
Reports a SLSA level for each repository, publishes to your TEA catalogue and keeps the Package Firewall and AI Firewall on.
The problem: The factory's own work meets the standard it enforces on yours.
Run traces
Keep each run's decisions with their rationale, the handoffs between agents and the evidence files.
The problem: A reviewer sees why a change was made before approving it.
Tamper-evident audit ledger
Chains every entry to the one before it, so the whole record can be verified.
The problem: An auditor can verify what ran.
Stay in control
Human approval
Pauses a run at a plan, a merge review or a publish review until a person you chose answers, and records who said what.
The problem: A change that matters waits for a person you chose.
Token budgets
Cap spend per run, step, workflow, day, month and repository, with an action at the limit: pause, downgrade, switch, ask a person, stop or alert.
The problem: Spend has a ceiling.
Autonomy limits and the kill switch
Set how far the factory goes on its own, from observe to auto-merge of low risk changes, cap concurrent runs, stop after repeated failures, or stop everything with one switch.
The problem: You decide how far the factory goes without a person, and you can stop it at once.
One line from trigger to evidence
Every run follows the same line. Something happens, the run gathers context, scans, decides, works, passes the gates, waits for a person where you require one, hands back its output and writes down what it did. The three diamonds are the places where a run can branch, stop or wait.
- Trigger: Something happens. A run starts from an event, not from a person watching a dashboard. The trigger decides which repository and which workflow. Cron, Webhook, Issue label, Scanner finding, Kanban change.
- Context: The run gathers what it needs. Before it decides, the run collects the repository posture, the open issues and pull requests, and the findings so far. Repository posture, Open issues, Pull requests, Scan findings.
- Scan: Run the Vulnetix scanners. A scan node runs the same scanners as the CLI inside the sandbox and writes findings, an SBOM and SARIF. SCA, SAST, Secrets, IaC, Containers, Licences, Malware, End of life.
- Decide (switch): A System One model picks an outcome. A decision node returns one outcome from an enum you define, with a confidence. Below your threshold, or on abstain, it takes the action you chose. Classify, Gate (yes or no), Route to a crew, Score.
- Work: A crew does the job. An agent or crew edits code, writes tests and answers questions in the sandbox. Handoff rules pass work between agents. belai:security, belai:feature, belai:bug, belai:delivery, belai:ui.
- Gate (switch): Deterministic checks decide pass or stop. Gates are plain rules with no model in the loop. A failing gate returns the work to the crew, ends the run or asks a person. Quality gate, Release jail, Tests, Budget check.
- Approve (switch): A person says yes. Human approval pauses the run until an approver answers. The approver and the answer go into the trace. Plan approval, Merge review, Publish review.
- Output: The work leaves the machine. Outputs are what a run hands back to GitHub and to people, and each one is listed in the run. Draft PR, Issue comment, TEA publish, Notify, VEX.
- Evidence: The run is written down. The trace, the decision rationale, the handoffs and the evidence files are kept, and the ledger entry is chained to the one before it. Run trace, Rationale, Handoffs, Ledger entry.
System One decisions with a threshold you set
A decision node asks a System One model to pick one outcome from a list you define and to report its confidence. An exploited library in a live service becomes a patch today, and a finding in a function nobody calls joins the weekly batch. Below your minimum confidence, or when the model abstains, the run does what you chose: ask a person, try a fallback model, take the safest outcome or stop.
The minimum confidence starts at 80%. Below it, a node can: escalate to a person, try a fallback model, take the safest outcome, end the run. When the model abstains or errors, a node can: escalate to a person, retry once, then escalate, end the run. The outcomes are an enum you define, for example patch_now, batch_weekly, suppress_candidate, escalate.
A decision never replaces a gate. The quality gate and the release jail are plain rules, so a confident model cannot talk its way past them.
Workflows built from triggers, gates and outputs
A workflow is a graph. It begins at a trigger (a schedule, a webhook event, an issue label, a scanner finding or a board change), runs through Vulnetix scanners, System One decisions, crews, quality gates and human approval, and finishes in outputs. Eleven quick-start templates cover the common jobs, so a team starts from a working workflow on one repository.
Security patch train
Works the findings that are worth patching today, tests the fix and opens a draft pull request for review.
Starts: Scanner finding. Flow: Scanner finding, then Repository posture, then Patch now, batch or suppress, then Patch in the sandbox, then Tests and quality gate, then Draft PR.
Nightly blackbox regression
Exercises the running application from outside on a schedule and reports what regressed.
Starts: Cron. Flow: Cron, then Run the blackbox suite, then Real regression or flake, then Tests, then Issue comment.
Feature from issue
Turns a labelled issue into a plan, waits for approval, then builds and tests it.
Starts: Issue label. Flow: Issue label, then Is the issue ready to build, then Plan the change, then Plan approval, then Build and test, then Draft PR.
Bug repro to fix
Reproduces a reported bug first, and only writes a fix when the failure is confirmed.
Starts: Issue label. Flow: Issue label, then Reproduce the bug, then Reproduced or not, then Fix and add a test, then Tests, then Draft PR.
Dependency hygiene
Keeps dependencies and licences current on a schedule, grouping safe upgrades into one pull request.
Starts: Cron. Flow: Cron, then SCA and licence scan, then Upgrade now, group or skip, then Bump in the sandbox, then Tests and quality gate, then Draft PR.
Malware response
Confirms a malware verdict, checks the release jail, asks a person and records a VEX statement.
Starts: Scanner finding. Flow: Malware finding, then Malicious or benign, then Release jail, then Human approval, then Notify and VEX.
Secret leak response
Separates live credentials from test values, removes the secret from code and notifies the owner.
Starts: Scanner finding. Flow: Secret finding, then Live credential or test value, then Remove it from the code, then Human approval, then Notify and draft PR.
Release provenance
When a release publishes, scans it, checks the release jail and publishes the SBOM and VEX to your TEA catalogue.
Starts: Release published. Flow: Release published, then SBOM and scan, then Release jail, then Publish review, then TEA publish and VEX.
Kanban triage autopilot
Reads a card that landed in triage, picks the crew that should take it and leaves the reason on the issue.
Starts: Kanban change. Flow: Kanban change, then Board state, then Which crew takes it, then Issue comment.
UI polish pass
Applies interface fixes from a labelled issue and checks them before a draft pull request opens.
Starts: Issue label. Flow: Issue label, then Adjust the interface, then Tests, then Design review, then Draft PR.
Delivery sweep
Walks open pull requests on a schedule, finds the stuck and conflicted ones and unblocks or reports them.
Starts: Cron. Flow: Cron, then Pull request state, then Stuck, conflicted or ready, then Unblock the pull request, then Issue comment and notify.
The 11 templates that change code end in a draft pull request for a person to review. Scan nodes run the same scanners as the Vulnetix code scanner, and the outputs include SBOMs in CycloneDX and statements in OpenVEX.
Crews that work a board
The board is a kanban worked by agents. Cards sit in review, backlog, done, triage and conflicts, and issues mirror to and from GitHub, so the board and GitHub show the same work. Five crews pick up the cards that suit them, and the agent builder defines your own agents with handoff rules between them.
- belai:security: Works findings: patches, suppression candidates, secret and malware response.
- belai:feature: Builds a feature from an issue. A person approves the plan before code is written.
- belai:bug: Reproduces a reported bug, writes the fix and the test that covers it.
- belai:delivery: Moves work to done: stuck pull requests, conflicts and release checks.
- belai:ui: Interface fixes and polish passes, checked before a draft pull request opens.
Issue mirroring
A card and its GitHub issue are one record, so the board and GitHub show the same work.
Agent builder
Each agent has its own model tier and the handoff rules that pass its work to the next agent.
Plan approval
When you require it, a person approves the plan before belai:feature writes any code.
Agents and crews are kept in your Library. The Pix registry lists the agents, crews, skills and prompts that other organisations publish, and a workflow can follow one by reference.
The factory passes the controls it applies to your code
An auditor, a customer or your own security team can check what ran, on what, and under which controls. The factory sits inside the Vulnetix security platform, so its own work goes through the same scanners, firewalls and gates.
SLSA levels per repository
The trust page reports each repository's SLSA level from 0 to 3 and says why it sits there.
TEA catalogue publish
A workflow output can publish to your Transparency Exchange catalogue.
Scanner matrix
One grid shows which Vulnetix scanners cover which repositories, with findings and clean results told apart.
Package Firewall
Workflow defaults keep the Package Firewall on, so a dependency your policy blocks does not install in the sandbox.
AI Firewall
Workflow defaults keep the AI Firewall on, so model traffic passes provider and model policy, guardrails and PII redaction.
Sandbox egress control
The Pix Sandbox controls its own egress, so an agent reaches only the destinations the sandbox permits.
Release jail
A workflow can use the release jail as a gate, so a repository with stale or missing evidence does not ship.
Signed commits
Commits made in a sandbox are signed by a key that never enters the container, so GitHub shows them as Verified.
Provenance is measured against the SLSA specification. Publishing is covered in Transparency Exchange.
Token budgets and autonomy limits you set
Budgets nest. A month holds days, a day holds workflows, a workflow holds runs, a run holds steps, and a per-repository budget cuts across all of them. Each budget names what happens when it is reached, so spend stops where you decided. Separate limits set how far the factory may go without a person.
- Month: The widest window. Everything the factory spends in a month counts toward it.
- Day: A daily window inside the month, so one bad day cannot use a month.
- Workflow: A limit on one workflow across its runs.
- Run: A limit on a single run from trigger to evidence.
- Step: A limit on one step inside a run, such as a crew step.
- Repository: A limit on one repository, whichever workflow spends on it.
When a budget is reached it can: pause the run, downgrade to a fast model, switch to the pix allocation, escalate to a person, hard stop, alert only.
- Pix allowance: The allowance that comes with your plan. It is the default source for System One decisions.
- Provider keys: Keys you store in the Secrets Vault, for models you bring yourself. A key's value is write-only: only its last four characters are ever shown.
Autonomy limits and the kill switch
You set how far the factory may go on its own. Limiting what an agent may do without a person is the control the OWASP Top 10 for LLM applications asks for under excessive agency.
- Observe. Reads, decides and writes the trace. Changes nothing on GitHub.
- Suggest. Proposes the change on the card or the issue.
- Draft PR. Opens a draft pull request for a person to review.
- Auto-merge low risk. Merges a change that the workflow graded low risk.
- Concurrency: A cap on how many runs go at once.
- Stop the line: A workflow stops after the number of failed attempts you choose.
- Kill switch: One switch stops the factory.
Everything is on record
Events, decisions, handoffs and approvals are recorded and readable by the people who own the repositories. A reviewer can see why a change was made, and an auditor can verify what ran.
Event stream and run traces
GitHub events, run steps and handoffs arrive on one live stream that filters by run, card, agent, crew, repository or workflow. Each run keeps its decisions with the rationale, the handoffs between agents and the evidence files it wrote.
Tamper-evident audit ledger
Each entry is chained to the one before it, so the whole record can be verified. Editing an entry changes its hash, and hiding that means rewriting every entry after it.
Runs on a Pix Sandbox or any machine running belai rc
Crews work on a machine, not on a laptop. A Pix Sandbox is the managed machine: Vulnetix runs it around the clock with egress control, and every agent step, scan and test executes there. A team that needs the work to stay on its own infrastructure runs crews on any other machine where belai rc is running, such as a build server or a workstation. A sandbox also runs single agent sessions with no workflow, and Software Factory adds the triggers, decisions, gates, budgets and the record.
The Pix Sandbox · Announcing the Pix Sandbox · Announcing Pix · Package Firewall · AI Firewall
Questions teams ask before they turn it on
What is the difference between Software Factory and the Pix Sandbox?
The Pix Sandbox is the isolated machine that every agent step, scan and test can run on. Software Factory is the feature set you run on it: the cockpit, event stream, board, workforce, workflows, budgets, trust pages and audit ledger. A sandbox can also run a single agent session with no workflow.
Where does the code run, and can we host it ourselves?
Crews run in an isolated environment with controlled egress. That can be a Pix Sandbox, the managed machine Vulnetix operates around the clock, or a machine you host yourself when the work has to stay on your own infrastructure.
Which repositories can a workflow touch?
Only repositories in a GitHub organisation you chose to manage. Inside one, the cockpit lists every repository you have scanned or attached, and a workflow names the repositories it may use. The API refuses a repository outside your managed organisations.
Who approves a change?
People you choose. A workflow can pause for human approval at a plan, a merge review or a publish review, and the approver and the answer go into the run trace. A System One decision never replaces a gate, and the quality gate and release jail are plain rules.
Will it merge code without me?
Only if you allow it. Maximum autonomy is a setting with four levels: observe, suggest, draft PR and auto-merge low risk. The quick-start templates that change code end in a draft pull request, so a person merges.
What happens when a System One model is unsure?
You decide in advance. A decision node has a minimum confidence. Below it the node can escalate to a person, try a fallback model, take the outcome you marked safest or end the run. A separate setting covers an abstain or an error.
How is spend capped?
Token budgets apply per run, step, workflow, day, month and repository. Each budget names an action at its limit: pause the run, downgrade to a fast model, switch to the Pix allocation, ask a person, stop hard or alert only. A System One decision uses the default model from your Pix allocation, and crews can use the Pix tiers or models you bring through provider keys.
How do I stop it?
There are four ways. Lower the maximum autonomy, set a budget whose action at the limit is a hard stop, cap concurrent runs, or throw the kill switch.
What does an auditor see?
Each run keeps its decisions with the rationale, the handoffs between agents, the approvals and the evidence files it wrote. Ledger entries are chained to each other, so the whole record can be verified, and a SLSA level is reported for each repository.
How do we start?
Choose a GitHub organisation to manage and start from one of the eleven quick-start templates on a single repository. Leave autonomy at draft PR and read the first run trace before you add more.
See the line run on one of your repositories
A demo starts one quick-start template on a single repository with autonomy at draft pull request. You read the first run trace, with every decision and its rationale, before anything widens.