Verify every output independently.
Code, tests, specifications, findings, and evidence are checked against the claim they make.
The Buildfactory approach
AI produces possibilities. Engineering decides what passes.
Buildfactory applies Sarolta's zero-trust approach to AI-assisted software delivery: probabilistic generation inside a controlled process of specification, tests, review, proof, repair, and human acceptance.
Inference, not intelligence
An LLM predicts a plausible answer. It does not prove that answer is right.
Generative AI is a powerful production input. Like every industrial input, its output must be processed into something fit for purpose. In Buildfactory, the processing is engineering: clarify the request, establish proof, build, check, correct, and accept.
Reliable AI-assisted code is therefore a process-engineering problem—not just a model-selection problem.
The axiom
Generated output is not trusted by default.
Confidence, a completion narrative, or a model reviewing its own work are not proof. The delivery process has to establish what is true.
Use deterministic facts where possible.
When a check can be pass/fail, a deterministic gate owns the decision rather than an LLM score.
Check alignment throughout delivery.
Independent challenge catches a specification deviation before it becomes accepted work.
Do not advance on assertion.
Current artifacts, configured checks, and accountable decisions determine whether a stage may continue.
Built from operational work
These controls were not invented as a checklist.
Buildfactory began with infrastructure deployment, upgrades, repair, and configuration automation. As it was used across real projects, each repeated failure, unsafe handoff, or missing proof became another working control in the delivery base.
Used first. Productized later.
Workers, gates, sandboxes, repair paths, and management controls exist because the work required them. See how Buildfactory was built →
Beyond zero trust
AI systems must prove themselves—or they do not ship.
Zero trust is not only a security position. It is the reliability boundary between probabilistic generation and the controls that decide what may advance.
Incorrect but plausible output.
A model can produce code, tests, or a completion report that sounds complete while a requirement or integration remains unproven.
Scope can drift.
Without explicit authority, environment, and stop conditions, an agent can carry work beyond what it was authorized to do.
Trust erodes fast.
A visible failure sets back adoption. The controls and evidence need to exist before it reaches production.
Four pillars
Four controls for four different failure modes.
These work together. The selected Build Profile determines how deeply each is applied for a delivery.
Concept 01Zero-trust agent architecture
Workers have defined roles, repositories, environments, procedures, and handoffs. A model request does not extend its authority.
Concept 02Adversarial review pipeline
Independent review and inquisitor roles assess work against the specification and evidence, not the producing worker's account.
Concept 03Deterministic quality gates
Artifact structure, repository state, tests, coverage, required evidence, and controlled transitions can be verified mechanically.
Concept 04Sandboxed execution environments
Git worktrees, Docker, Proxmox, and bounded environments isolate work and preserve an accountable run history.
What responsible AI requires
Do not ask an LLM to judge itself.
The point is not to slow work down for ceremony. It is to catch the ordinary, plausible failures before they compound.
| Uncontrolled delivery | Buildfactory delivery |
|---|---|
| LLM judges its own output. | Independent review challenges work against its specification and evidence. |
| Tests pass mostly; missing proof is discovered later. | Configured deterministic gates decide whether proof is sufficient to advance. |
| Scope drift emerges during or after release. | Scope is specified, bounded, and checked at major transitions. |
| Failures are reconstructed after the fact. | Artifacts, decisions, evidence, and remediation are retained through the line. |
The methodology
Three disciplines, one delivery standard.
Buildfactory turns established engineering disciplines into operating machinery for AI-assisted work.
Test-Driven Development
Where a profile requires it, failing tests define the expected behaviour before Code builders implement it.
Evidence-Driven Development
Progress and release decisions rely on current, traceable evidence—not confidence or a persuasive summary.
Spec-Driven Development
Machine-readable specifications connect business intent, workers, tests, review, and the accepted outcome.
Flexible controlled phases
A framework for the work, not a fixed eight-step ceremony.
Buildfactory does not assume an incoming request is sufficient. PRD analysis and remediation identify missing constraints, unclear behavior, contradictions, and untestable expectations before downstream work compounds the problem.
Start with a working delivery line. Keep it, or modify it to suit the application you are building.
What runs in each phase depends on the Build Profile and the application. A PoC, an MVP, a SaaS product, and a high-consequence system need different workers, checks, evidence, environments, and human decisions. Some phases can be combined for a bounded product change; others need to be expanded or repeated. The controlled framework keeps the relevant obligations, alignment checks, and remediation paths explicit while allowing the process to fit the product.
Analyze and remediate the requirement.
Required: structured findings, amendments, reanalysisInspect the source request, write actionable deficiencies, apply agreed amendments, and reanalyze before the request is accepted as a build obligation.
Define the obligation.
Required: specification, constraints, evidence contractTranslate the remediated requirement into precise behavior, acceptance criteria, boundaries, and expected proof.
Prove missing behavior.
Required: test artifacts and controlled RED evidenceCreate tests capable of detecting the requested behavior and distinguish real integration proof from mocks or irrelevant happy paths.
Implement the owned change.
Required: implementation, execution evidence, review inputMake the change under the defined specification and test obligation, without silently expanding the scope.
Search beyond the visible pass.
Required: discovery findings and routing decisionLook for missed obligations, hidden integration effects, weak evidence, and assumptions that a normal phase review did not expose.
Judge the integrated result.
Required: implementation review and remediation outcomeReview the resulting behavior against the specification, tests, evidence, and engineering rules, then route any failure to the responsible station.
Validate use and architectural fit.
Required: user and system findingsConfirm that the completed work is usable, fits the surrounding system, and satisfies the human intent behind the requirement.
Make the release decision.
Required: current evidence and unresolved-risk visibilityDecide from the linked requirement, artifacts, reviews, repairs, and outstanding findings—not a worker's declaration of completion.
Pipeline architecture
Probability generates. Controls decide.
The pipeline's intelligence is in its structure as well as its models: no stage advances because an agent sounds confident, and no exception is made because of time pressure.
Every gate is a hard decision point.
Specification, Test, Code, inquisitor, integration, and acceptance controls return work to the phase that can actually resolve the finding.
Review is not inquisition
Verify the contract. Then investigate what the contract may have missed.
Contract verification asks whether defined work, evidence, tests, and engineering rules meet the stated obligation. It is not a free-form hunt for faults. Inquisition is a separate, truth-seeking investigation: it deliberately looks for missing assumptions, weak proof, unintended effects, requirement gaps, and attack paths outside the stated check.
Prove the stated claim.
Does the result satisfy the defined requirements, expected evidence, tests, and established engineering rules? A failure must point to the requirement, proof, or rule it does not meet.
Expose holes and weaknesses.
Search for attack vectors, fake tests, stale evidence, absent integration, wrong scope, or a conclusion that looks stronger than its proof. This work tests the system's assumptions, not just its checklist.
Return the finding to its cause.
A requirement, specification, test, implementation, machine-readable output, or process fault needs a different repair path. The finding is not merely recorded; it is routed for correction and re-verification.
Adversarial work must be focused, evidenced, and bounded.
Applied indiscriminately, an adversarial pass can become speculative finding churn: it starts treating unlikely concerns as defects or turning ambiguity into unsupported claims. Buildfactory uses it where the consequence justifies the search, gives it a defined question or threat focus, and requires a finding to be tied to evidence, impact, and a decision. That keeps the useful part of adversarial work—finding real holes, weaknesses, and attack paths—without substituting noise for assurance.
Beyond code
One controlled pattern for any digital artifact that must be correct.
Software is the primary domain. The same system applies when an AI step needs stated criteria, evidence, independent review, and a responsible acceptance point.
Spec → Tests → Implement → Deploy
Transform PRDs into verified code through worker loops, deterministic gates, and evidence.
Brief → Criteria → Draft → Final
Check completeness, structure, evidence, and approval criteria before release.
Question → Method → Findings → Review
Make sources, method, claims, and conclusions reviewable against a research contract.
Guide → Rules → Write → Publish
Apply factual checks, brand rules, and independent review before publication.
The approach in practice
Plan a technical evaluation →Use AI for generation. Use engineering to decide what is good enough.
Start from a working system, select the proof required for the work, integrate it with your environment, and keep accountable human judgment where it belongs.