How the Tier-Max Rule Protects Autonomous Software Factories

If you're running an autonomous software factory, a 'dark factory' where AI agents write, test, and deploy code with minimal human oversight, you've probably thought about governance tiers. Maybe you've mapped T0 paths where the system runs lights-out and T3 paths where a human must sign off before anything ships. So here's the question nobody asks until it bites them: what happens when a single change touches both?

The Averaging Loophole

Without a composition rule, a change that spans a T0 path and a T3 path can theoretically be evaluated at the average tier. A quick config tweak on a T0 route gets bundled with a core database migration on a T3 path. On balance, the change is "mostly safe", so it sails through lights-out.

That's not how governance works. A T3 path exists for a reason. Regulatory compliance, data integrity, customer safety. These aren't negotiable constraints you can dilute across a change boundary. Allowing a change to average its way past a T3 requirement defeats the purpose of having tiers at all.

This isn't a theoretical edge case. In any factory where AI agents plan and batch changes, the bundling problem is inevitable. An agent looks at the work queue, sees a T0 task and a T3 task touching related files, and merges them into one change-set to save time. Without a guardrail, that merged change inherits neither tier, falling into a gap where no tier's rules fully apply.

How the Tier-Max Rule Works

The fix is straightforward: when a change spans paths in more than one governance tier, the change inherits the maximum (strictest) tier across every path it touches. A T3 + T0 change is treated as T3, full stop. Nothing lets it average out.

In practice, this is enforced as deterministic policy in the gate engine: no LLM decides, no prompt can override it. The gate checks the set of paths a change touches, looks up each path's configured tier, and returns the maximum. If any path is T3, the whole change is T3. The rule is simple enough that its guarantees are testable as fast unit tests: a T3 change always routes to a human.

The composition rule also handles inherited paths. If a module inherits its tier from a parent directory and one sub-path carries a stricter tier, the whole change lifts to that stricter tier. There's no way to restructure your way around it. The rule follows the paths, not the packaging.

The Regulated Core, Autonomous Shell

The strategic corollary is worth stating explicitly: the tier-max rule incentivises good architecture. If every change touching a T3 path gets bumped to full human review, you're motivated to keep the T3 surface small.

This maps to a pattern you see in well-designed platforms: a regulated core surrounded by an autonomous shell. Push the compliance-sensitive logic (data mutations, financial calculations, access control changes) into a small, well-defined core. Keep routine operations (formatting, refactoring, dependency updates) in the autonomous shell where they can run lights-out.

Report T3 surface area as a platform KPI. If it's growing quarter over quarter, that's a signal that either your architecture is leaking regulated concerns into too many places, or your tier definitions need recalibration. The goal isn't to eliminate T3 paths. Some things need human oversight. It's to keep them small enough that the tier-max rule doesn't become a drag on the whole factory.

Why This Matters for Dark Factories

Dark factories aim for full autonomy. But autonomy without governance is an accident waiting to happen. The seven blockers of autonomous software factories include regulatory hard limits and the accountability gap. The tier-max rule directly addresses both.

Regulatory hard limits: if a regulator mandates human sign-off on changes to certain systems, that's not optional. The tier-max rule encodes that mandate at the infrastructure level, not as a manual checklist someone can miss or override. The gate engine enforces it deterministically, and the provenance trail records the decision.

Accountability: the tier-max rule surfaces who owns what. Each path has a named Spec Owner, Platform Owner, and Operations Owner. When a change spanning tiers triggers a T3 gate, those owners are the ones who certify it. The rule turns a policy concern into a testable, auditable guarantee, and that's exactly what you need when the regulator asks how you're governing your AI-driven delivery pipeline.