Factor IV
Govern the Factory and the Product Separately
The software factory and the running product are different sensitive activities.
Govern the factory (that is, the process by which software artefacts are developed, tested, built, signed and released) separately from the product (what the running system may do).
They are connected, but they are not the same governance object.
Problem
Building software and operating software create different organisational risks:
- A compromised build pipeline may introduce malicious code into every future release.
- A compromised runtime system may expose customer data or execute unauthorised business decisions.
Although these events are related, they require different controls, different evidence and often different owners (see Governance Has Owners).
Regulations increasingly expect organisations to demonstrate both how software was produced and how it behaves once deployed.
Collapsing these into a single governance model obscures where failures occurred, which controls were bypassed and which teams are accountable for remediation.
Characteristics
Separate sensitive activities
The software factory performs activities such as building, signing and releasing software. The running product performs activities such as approving payments, serving customers or invoking AI tools. These activities create different risks and should be governed independently.
Separate twins and evidence
The software factory performs sensitive activities such as building, signing and releasing software. The running product might perform sensitive activities such as approving payments or serving customers.
Build provenance, SBOMs and signing records belong to the factory. Runtime decisions, authorisation events and operational telemetry belong to the product. Mixing evidence reduces clarity and weakens auditability.
Positive examples
Mortgage Platform
The factory twin governs how the mortgage platform is built, reviewed and released. The product twin governs mortgage approvals, customer data access and fund disbursement.
AI Fraud Detection
One governance domain covers model training, evaluation and promotion. The other governs production inference, decision overrides and customer impact.
Trading Platform
The build pipeline governs signed releases and dependency provenance. The runtime governs trade execution, market controls and operational resilience.
Negative examples
One Governance Dashboard
A single "green" status hides the fact that the release pipeline has failed supply-chain validation while production appears healthy.
Shared Policies
The same governance policies are applied to both deployment pipelines and customer-facing applications, leaving neither domain properly governed.
Shared Ownership
The same team is assumed to own software production and runtime governance, making accountability unclear when incidents occur.
Anti-patterns
Pipeline blindness
Runtime looks healthy while the factory that feeds it is ungoverned. Attackers and auditors both notice.
Provenance as a run-time property
Treating “how it was built” as something you can infer from production config. You cannot—record it in the factory domain.
App-level dashboards that hide build risk
A product traffic light that never surfaces signing, SBOM or pipeline failures.
Different Governance for Every Environment
Creating separate governance definitions for Development, UAT and Production instead of promoting a common governance baseline through progressively more representative environments. See Continuous Governance for more.
Diagram
Where does governance apply?
Factory and product are both sensitive activities, with their own governance twins.
Discussion
The software factory and the running product are separate governance domains because they perform different sensitive activities.
The Factory Implementation Twin describes how software is built, tested and released. It is governed by the Factory Governance Twin, which defines the controls, policies and evidence required before a release may leave the factory. This is where governance is developed, reviewed and verified alongside the implementation.
When a release is promoted, the factory delivers more than executable code: it delivers the Product Implementation Twin together with the Product Governance Twin that defines how the deployed software should be governed. The governance created in the factory therefore becomes part of the released product.
References
- SLSA — provenance requirements for how artefacts are produced
- in-toto — verifying authorised factory steps
- CycloneDX — SBOMs for release composition
- Open Policy Agent — runtime and pipeline policy evaluation
- Gatekeeper — Kubernetes admission for the product domain
- Kubernetes — admission control in the path of change