AI turned thousands of people who are not engineers into builders. The architecture, security and delivery discipline that makes software safe to ship did not grow with them. You cannot hire that discipline as fast as the building now happens, and you cannot stop the building without losing the speed. FORGE is how you govern it.
It is our product, an engineering platform, and the method it runs. Your architects, security engineers and platform teams set their standards once. FORGE builds those standards into the path to production for every project. A builder who is not an architect still ships to the standard.
Five disciplines do the work: Factory, Observability, Review, Governance and Trust, and Expert Intelligence. Each is an engineering property of the path, running as the work happens, and each build leaves with the evidence that it ran under them. The path starts with requirements, written new or recovered from a system you already run. It runs through a verified build, a generated pipeline and an infrastructure-as-code deployment on the cloud you choose. It ends in operation, with an operator built from the system's own design, and the evidence is continuous across all of it. BtSavvy's forward-deployed engineers build on FORGE with your team, inside your repositories and your cloud accounts. They teach the product and the discipline as they go.
The five disciplines
F — Factory
The build path itself, with your standards and security controls built in. Your architecture, security, operations and compliance teams define their standards once in FORGE. From a project's requirements and those standards, FORGE produces a complete engineering environment for that one project. It holds the design the software must satisfy and the tooling to build, deploy and operate it, with every rule already inside. The environment runs inside your own repositories and cloud accounts. What it builds can see the internal systems it has to work with, so what ships fits the enterprise it runs in. Work is built in units, each accepted before the next begins, and the tests are planned from the requirements before the code is written. The depth of checking is worked out from the risk a change carries. It can be raised, and it cannot be talked down. Where a system already exists, FORGE recovers what it does from the code, the documents and the running product. The rebuild is measured against the old system's recorded behaviour before cut-over. Deployment is infrastructure-as-code on AWS, Azure, Google Cloud (GCP) or Oracle Cloud (OCI), whichever the workload needs. The modules come from the provider where they fit and from our labs where they do not.
Project-by-project delivery starts again on every project. A factory compounds. Kieran Klaassen at Every named this shift compound engineering: each piece of engineering work should make the next one easier (Klaassen, Every, 2025). FORGE is built on that principle. A standard hardened or a mistake designed out on one build is inherited by the next. The second application starts further along than the first, and the tenth further still. The standards, the patterns and the reference builds live in your repository as plain, versioned files. They are yours after the engagement and portable out of it.
O — Observability
Built to run, with its own operator. Alarms come from the availability the design promised, so they mean something on the first day. The system is built to withstand the failure of what it depends on, and to be returned to a known good state. Operations documentation is generated from the system itself, so it describes what was built. Across the portfolio, FORGE shows which projects are behind your standards, and what a change to a standard would affect before you make it. Every cloud application FORGE builds comes with its own operator, built from the application's own design and deployed beside it in your account. The operator watches the application, investigates when something goes wrong, and fixes the problems it has been proven to handle. Everything else reaches a person with the evidence already assembled. Its authority is earned by rehearsal, bounded by the application it belongs to, and lapses if it is not renewed. Releasing code stays with people, and anyone on call can stop it at once. A healthy dashboard is not a correct answer, so FORGE also watches whether the application is keeping the promises it made to its users.
An agent that looks healthy on an uptime graph can be producing output nobody should act on. How far people rely on an automated system, and whether that reliance matches how reliable it is, has been studied for decades. The foundational paper is Lee and See, Trust in Automation: Designing for Appropriate Reliance (Human Factors, 2004). FORGE treats that reliance as an operating property of the running system, watched beside latency and error rate. The absence of alerts is not the presence of safety.
R — Review
Every decision on the record, with the person who made it. The decisions that matter carry an accountable owner from your team, ours, or both. The depth of review is worked out from the change itself, so routine work moves fast and risky change gets the scrutiny it deserves. An AI agent does not approve its own work or move its own pass mark. Those decisions stay with a person, and setting a check aside is itself recorded as a decision someone made. The design is reviewed before any code is written. The record of who decided what is produced as the work happens, so an audit is a lookup, not a reconstruction. The path cannot produce code without producing that record beside it.
The regulation is moving the same way. The EU AI Act requires high-risk AI systems to be designed so that people can oversee them effectively (Regulation (EU) 2024/1689, Article 14). The organisations that deploy them must assign that oversight to people with the competence, training and authority to exercise it (Article 26(2)). Anonymous AI review is not auditable AI review. Who owns each decision is a term of the engagement: you hold it, we hold it, or both names appear together.
G — Governance and Trust
Governance generated into the pipeline. Your platform and security teams set policy once. Every project's pipeline is generated from it, so the team a pipeline constrains does not write it. The checks and the evidence are part of the path itself. Full DevSecOps deployment across AWS, Azure, Google Cloud (GCP) and Oracle Cloud (OCI), with the pipeline tooling you already run, hosted or on premises. Secrets stay outside the AI tool chain, and each deployment identity is scoped to the work it does. Nothing in your cloud account changes at deployment until a person on your side has agreed to the change. A standard is set once and inherited by every project. A project that has fallen behind is found at the moment of work, not at the audit. For AI products in regulated markets, the record a regulator asks for is an output of the build. It states what the system is for, its risk classification, the oversight in place and where its data came from.
ISO/IEC 42001 sets out AI management as a system that has to keep running, not a one-off assessment (ISO/IEC 42001:2023). FORGE is built to that posture. A compliance record produced separately from the delivery record can be contradicted by the delivery it describes. In FORGE the policy enforcement, the data lineage and the name of the person who decided are artefacts of the path that built the system. They are not reports written afterwards for an audit.
E — Expert Intelligence
Your experts' judgment, applied further than they could reach by hand. The standards they set reach every project without them reviewing each one. The models that do the work are governed the same way. Your organisation decides which models may be used, on what terms and in which regions. Work is written against the role a model plays, so the model behind a role can change without rebuilding the system. A model withdrawn by its provider is an orderly change your governance already covers. The same discipline takes a general-purpose model to an expert in your domain. The context an application is given, the data it may retrieve and the evaluation it must pass are engineered as part of the build. Where the application has AI in it, it carries its own evaluation: accuracy against known-good answers and resistance to prompt injection. The pass mark stays with a named person, never with the agent that did the work.
As Philipp Schmid puts it, most agent failures are now failures of context, not of the model. He made that line the centre of context engineering (Schmid, The New Skill in AI is Not Prompting, It's Context Engineering, 2025). FORGE treats the context an agent works from as the main engineering surface of agentic work. What the model is given decides what it can do, and that is engineered, reviewed and versioned like everything else on the path.
Compound Evolution
Compound Evolution is the sixth discipline, and it runs through the other five. What one application learns in production goes back into the patterns FORGE builds from. The next application ships with that failure already prevented or already rehearsed. The learning is deliberate. A person decides what is promoted into the patterns every project starts from. A running project takes a changed standard on when its owners accept it. Nothing learned elsewhere acts on your system until it has been proven on your system. Project-by-project delivery starts its learning again on every statement of work. A compounding platform does not, and over several years that is the gap between an asset and a recurring cost.
Why FORGE
The name
We call it FORGE because forging is how the parts that must not fail are made. Metal shaped under controlled heat and pressure comes out with its grain following the shape of the part. That is why a forged part is stronger than the same metal cast or cut. Your standards and controls are the die. Every build passes through the same one, so the discipline runs through the grain of what ships instead of being applied to the surface afterwards. The letters name the five disciplines: Factory, Observability, Review, Governance and Trust, and Expert Intelligence.
What FORGE answers
The question every technology and security leader now lives with is how to let everyone build with AI without losing control of what ships. FORGE answers it by making your standards properties of the path to production rather than reviews added after it. When an auditor asks how an AI-built application was designed, reviewed and approved, FORGE is the reason you can answer. FORGE is not another AI coding tool. It sits on top of the AI tools your teams already use and changes what they produce. Your teams keep their tools and their pace, and the standards your experts set travel with them.
It also answers a question about ownership. A capability you would otherwise rent as SaaS can be built with your team on FORGE. It is built to the standard a SaaS provider holds itself to: reliability, operations and evidence. FORGE supplies the design, the tooling and the operator. Your team builds the part that is specific to your business, without building a full application from scratch, and owns all of it. What gets built lives where your work already lives, so changing a supplier does not mean changing the system.
Each discipline answers one of the questions a leader arrives with.
- Can I trust what it ships? Review, and Governance and Trust.
- Is it production-ready, or only demo-ready? Factory and Observability.
- Can we support it when it breaks? Observability, and the operator that arrives with every application.
- What is my compliance exposure? Governance and Trust.
- Where is the business case? Expert Intelligence, and the compounding across all five. Your experts' judgment reaches every project, each build starts where the last one finished, and you own what is built.
FORGE, in full.
The Engineering Brief is the long-form treatment of the method. Each discipline in depth, and the engineering traditions FORGE draws on. Written for engineering leaders, security architects and evaluators who want the whole argument behind safe to ship.
To evaluate it against a real workload, start with the FORGE Diagnostic. It takes one workload you select and builds a working slice of it to your standards, inside your controls, in 2 to 4 weeks.