Sarolta engineering case study / BuildFactory
Building BuildFactory. AI-native delivery governed for production.
Sarolta productized its internal delivery system into BuildFactory: durable task orchestration, typed AI workers, deterministic gates, and traceable proof from requirement to release.
How it started
Operational automation became a durable delivery system.
Make infrastructure and software changes repeatable, inspectable, recoverable, and safe to hand between people and systems.
BuildFactory began with Sarolta’s internal Ansible automation for isolated LXC and Proxmox environments. Those runs made deployment work repeatable, captured its state, and produced early proof in a target-like environment.
As delivery added requirements, testing, model calls, review, recovery, and release evidence, reusable phase managers and engineering utilities grew into a productized delivery runtime.
Automate environments
Run repeatable infrastructure changes in isolated, observable jobs.
Preserve delivery state
Give work clear ownership, execution history, evidence, and recovery paths.
Apply AI under control
Use models for judgment and generation inside explicit engineering boundaries.
Productize the runtime
Turn proven delivery controls into BuildFactory for production software work.
The engineering approach
A model can propose the work. Evidence decides whether it progresses.
BuildFactory uses AI for interpretation, generation, review, and remediation. Deterministic controls decide admission, scope, legal transitions, and the definition of done.
Progress requires a named task, an approved contract, independent challenge, and evidence that remains current for the target runtime.
01 / Declare intent
Every task begins with its contract.
Scope, ownership, acceptance criteria, runtime bounds, and required proof are set before execution begins.
02 / Assign capability
Workers receive narrow, typed responsibilities.
Canonical roles, prompts, tools, output schemas, and worktree boundaries keep model activity attributable.
03 / Admit evidence
Independent proof controls progression.
Reviews, tests, provenance, and runtime receipts must agree before work can move to the next legal stage.
Assurance and capability profiles
The build profile defines the engineering standard. The model profile selects an approved capability.
A build profile determines required stages, evidence independence, runtime boundaries, and completion gates. A model profile selects allowed providers and tools for a role without changing those rules.
This separation keeps the delivery standard stable while model capability and routing evolve.
Build profiles
Define the proof required for the class of work.
Assurance gates specify depth of review, tests, environment proof, and release criteria.
Bounded execution attaches scope, retries, concurrency, and terminal evidence to the task.
Explicit recovery reuses approved task state rather than silently starting over.
Model profiles
Route capability to a role - never policy to a model.
Anthropic, OpenAI/Codex, Gemini, Cursor, OpenCode, OpenRouter, and local models can be selected by role, effort, cost, and approved fallback policy.
Independent challenge
Use a different model or provider to reduce correlated failure.
Adversarial review can challenge an earlier artifact under a separate role contract.
Stable contracts
Required output, evidence, and pass conditions stay fixed.
Provider routing cannot lower the evidence bar.
Deterministic systems first
Model judgment starts only after mechanical engineering facts are established.
Admission, identity, artifact integrity, and recovery are deterministic. Models are used only where interpretation or generation adds value inside an approved boundary.
Admission and identity
Verify the task before dispatch.
Task identity, profile, dependency state, authorised worktree, agent contract, prompt version, schema, file plan, and predecessor evidence are checked before a worker runs.
Artifact integrity
Prove that the evidence is current and connected.
Manifests, reports, test suites, commits, binaries, and receipts are checked for structure, freshness, source linkage, scope, and runtime identity.
Bounded recovery
Never repeat an unchanged failure.
Retries are finite, idempotent, and require changed facts, parameters, or graph generation. Cancellation, cleanup, concurrency, and resource limits are policy-bound.
Platform architecture
A durable control plane around autonomous engineering work.
Task ownership, execution, and assurance are deliberately separated. Durable workflow state survives restarts; registered execution owns external jobs; and deterministic policy decides which evidence can advance a task.
Every state and legal next action stays visible.
Operators can inspect task dependencies, active stations, policy reasons, current evidence, health signals, and recovery actions without reconstructing a run from logs.
Durable control plane
Task graph, policy, timers, and provenance.
Dependencies, idempotency, recovery, profile decisions, Git-backed lineage, and operator controls define the legal delivery path.
Governed execution plane
Typed workers in bounded environments.
Canonical roles run in isolated worktrees, Docker, virtualized environments, and registered external jobs with cancellation and cleanup.
Deterministic assurance plane
Checks that make evidence admissible.
Admission, schemas, provenance, scope, ownership, independent review, and runtime receipts determine whether a result can progress.
Zero-trust engineering discipline
No actor certifies its own work.
No worker, response, artifact, callback, or destination is assumed safe. Policy admission, typed contracts, scope controls, and fresh evidence make each transition deliberate and attributable.
Policy admission
Workers run only under a registered contract.
Task identity, profile, worktree, prompt, tool policy, schema, runtime, and predecessor evidence are checked before dispatch.
Separation of duties
Builders never approve their own output.
Reviewers and independent challengers evaluate artifacts through separate role contracts and evidence expectations.
Fail-closed evidence
Missing, stale, or mismatched proof blocks advancement.
Unauthorized diffs, malformed receipts, unsafe execution, and incomplete coverage route to remediation or escalation.
The delivery graph
A durable graph - not a fixed sequence.
A selected build profile compiles the task graph for the work at hand. It can require requirements analysis, behavior specifications, RED tests, implementation, review, runtime proof, or other composite work – only where the contract calls for it.
Every admissible transition is evidence-gated. Gaps return through a declared remediation route instead of retrying unchanged work.
Profile-defined work
The graph matches the assurance required.
A proof-of-concept and a pipeline-critical release can use the same platform while requiring different stages, review depth, and terminal proof.
Evidence-gated progression
Artifacts advance only when the proof agrees.
Specifications, tests, source changes, reviews, receipts, and environment results are checked for freshness, lineage, scope, and compatibility.
Legal remediation
Failures return to the smallest correct action.
A specification gap, test defect, implementation fault, or environment problem follows its owned recovery path with changed facts and new evidence.
Typed workforce and independent challenge
Roles are narrow by design. No generic agent swarm governs itself.
Workers have declared inputs, output schemas, tool permissions, runtime boundaries, and evidence responsibilities. Independent roles challenge earlier artifacts rather than repeating the same assumption.
Controlled generation
Generate multiple candidates when the decision deserves it.
Role contracts constrain inputs and outputs. Candidate generation can be diversified, then checked by an independent reviewer before selection or remediation.
Test-first evidence
A passing test is evidence only when the required behaviour is proven.
Specifications define expected behavior; RED tests demonstrate the gap; implementation is reviewed against the contract and runtime evidence.
What BuildFactory makes visible
From product intent to release, the delivery record stays intact.
Every stage leaves connected evidence that explains what changed, why it was allowed, which conditions were checked, and what recovery remains legal.
Intent and contract
Keep the work attached to its reason.
Requirements, constraints, ownership, acceptance criteria, and approved profiles remain linked to task state.
Evidence and lineage
Make proof inspectable.
Specifications, tests, commits, review reports, environment receipts, and release decisions remain connected and attributable.
Operations and recovery
Keep the next action visible.
Task health, dependencies, policy reasons, terminal outcomes, and recovery routes remain available to operators.
Durable operations and release proof
The delivery record survives workers, sessions, and environments.
Execution continues as a durable, inspectable graph rather than transient worker memory. Release evidence is collected in the target-like environment required by the contract.
Git-backed operational memory
Keep the engineering record with the source.
Task dossiers, specifications, manifests, tests, review reports, decisions, lessons, handoffs, commits, and release lineage remain versioned and attributable.
Environment contracts
Prove the behaviour in the required runtime.
Docker, virtualized, and target-like environments verify setup, readiness, execution, evidence capture, teardown, and preserve-on-failure behavior across unit, integration, UI, API, infrastructure, and system tests.
Explainable recovery
Diagnose across signals, then route the smallest legal correction.
Run state, logs, processes, Git activity, artifacts, dependencies, review evidence, and environment receipts are reconciled before a worker is replaced, retried, or escalated.
Complex delivery needs engineering
Bring us the workflow that cannot be reduced to a prompt.
Sarolta builds dependable systems around the constraints real software teams have to operate within.