Agentic Engineering Governance

powered by Software Dark Factory

Strategic reference

The Operating Model

Software Dark Factory starts with governed AI-assisted software delivery. The longer-term goal is a mission-led, slice-based, evidence-backed operating model for agentic work.

Governance is the wedge, not the ceiling.

Start with a scoped readiness assessment View controlled demo proof

Current proof is controlled and engineering-focused. Future operating-model layers are direction, not production/customer governance claims.

Operating thesis

Trust, review, and governance come first.

The first bottleneck is not whether AI can produce more work. The first bottleneck is whether teams can trust, review, and govern that work.

Governance defines the rules. Assurance proves they held.

Software Dark Factory starts with governed AI-assisted engineering because that is where the risks are most visible: code quality, security, reliability, reviewability, and accountability.

Once the governance layer exists, the factory can support better quality, stronger delivery discipline, clearer cost visibility, and broader organisational leverage.

The long-term aim is a factoryized repo that does not only produce evidence, but also keeps each slice aligned with the product mission, quality bar, constraints, and non-negotiables.

Proven now

Current proof is controlled, engineering-focused, and evidence-backed.

These are not hosted, production, or customer enforcement claims.

Controlled Rails proof

A Rails receiver can adopt the governed front door and complete a real governed work slice with evidence-backed PR anatomy.

Controlled TypeScript proof

A TypeScript receiver can complete a governed work slice while preserving the runtime boundary: the app remains TypeScript/Node, while the current SDF factory tooling runs as Ruby-based local tooling.

Governed PR anatomy

The Rails walkthrough shows the public 01-08 SDF PR anatomy in a production-shaped PR body.

AI usage/economics evidence

Local tool-log token deltas can be captured where available. Cost remains unavailable/not billing-grade and measured savings are not claimed.

Future direction

The expansion path is a ladder, not a promise of dates.

Longer-term direction starts from reviewable governed work and moves toward more repeatable, more aligned agentic delivery.

1

Proven now

Governance / evidence / reviewability

Make AI-assisted work reviewable before asking teams to trust it.

2

Future direction

Playbook-led code quality

Use repeatable engineering playbooks to improve the quality of each slice, not just its audit trail.

3

Future direction

Repo North Star and mission alignment

Give a factoryized repo a durable mission, user focus, business outcome, quality bar, constraints, non-goals, and decision rules that every slice works towards.

4

Future direction

Production governance

Extend governed evidence and review boundaries toward release, operational, and runtime workflows.

5

Future direction

Agentic engineering operating model

Move from individual AI-assisted tasks to a governed team operating model for agentic delivery.

6

Future direction

Wider agentic company operating model

Apply the same mission-led, slice-based, evidence-backed pattern beyond engineering into other departments over time.

Repo North Star

A factoryized repo should know what it is working towards.

Producing evidence is only the starting point. The future SDF model includes a repo-level North Star that keeps governed slices oriented around the product mission, users, business outcome, engineering principles, quality bar, constraints, non-goals, and decision rules.

Each governed slice can then be reviewed not only for whether it passed checks, but whether it moves the repo in the right direction.

This is future direction, not a fully productized current claim.

product mission primary users business outcome engineering principles quality bar security constraints operational constraints non-goals decision rules

SDF vs spec-first approaches

Real software delivery is iterative.

Spec-first approaches are useful when the work is bounded and enough context can be captured upfront.

Priorities shift, constraints emerge, feedback changes the shape of the work, and the team learns as it builds.

Software Dark Factory is designed for that reality: a North Star, small governed slices, playbooks, continuous evidence capture, feedback loops, and reviewable PRs.

Spec-first

  • front-load the plan
  • assume enough context can be captured upfront
  • often encourage larger upfront batches of generated work
  • review after generation

SDF

  • define a North Star
  • work in small governed slices
  • apply playbooks
  • capture evidence continuously
  • review every PR through governed anatomy
  • adapt from feedback

Boundaries

This page describes current controlled proof and future direction.

It does not claim production/customer governance, hosted enforcement, automatic approval, automatic merge, guaranteed correctness, guaranteed safety, billing-grade cost, measured savings, arbitrary receiver coverage, zero-dependency adoption, or native tooling for every language.

To see the current proof layer before the longer-term operating model, start with the controlled demo proof or request a scoped readiness assessment.

automatic_execution_permitted: false

production/customer governance hosted enforcement automatic approval automatic merge automatic enforcement automatic PR creation automatic PR approval guaranteed correctness guaranteed safety security certification formal verification automatic trust judgement automatic repair automatic apply hosted monitoring continuous monitoring billing-grade cost measured savings automatic optimisation automatic model routing optimisation all-stack coverage arbitrary receiver coverage zero-dependency adoption native tooling for every language prompt-injection prevention DLP shadow-AI monitoring
View controlled demo proof Start with a scoped readiness assessment