Skip to content
Kiberon LabsAgentic Engineering

Minimal Goals

3 min read

Minimum goals are the smallest durable set of objectives a software dark factory needs in order to direct itself across invocations. They are part of the Minimal Bootstrap, not a later business layer. Without them, the system can execute tasks but cannot determine which work belongs in its queue, whether its operation is improving, or which conditions it must preserve.

These goals define a production identity scoped to software delivery. They do not yet give the factory authority to choose business strategy. Chapter 8 reintroduces goals when that boundary expands.

1. Deliver verified software

Section titled “1. Deliver verified software”

The factory needs a standing production mandate: turn authorised software demand into verified, reviewable, and releasable changes.

This goal gives external signals a meaning. A new issue, failed test, security finding, or release event should create work only when it falls within the factory’s software-delivery mandate and authority.

Useful measures include:

  • accepted changes and completed releases
  • verification and review pass rates
  • cycle time from authorised demand to verified artifact
  • rework, rollback, and regression rates
  • cost per successful software outcome

The exact targets belong to the operating policy. The minimum requirement is that the factory can distinguish a successful software outcome from activity alone.

2. Improve the factory

Section titled “2. Improve the factory”

At least one protected goal must improve the factory’s ability to deliver software. If improvement remains implicit, immediate production work can consume all available attention and compute.

Candidate improvements include better task decomposition, routing, context, recovery, verification, tool interfaces, and movement of repeated work into deterministic automation. Every proposed change must pass the governed evaluation loop from Part VI before promotion.

Useful measures include:

  • task success and recovery rates
  • latency and cost per successful outcome
  • review acceptance and regression rates
  • percentage of eligible work completed without intervention

These measures diagnose the production capability. They are not substitutes for the delivery outcomes in the first goal.

3. Preserve continued operation

Section titled “3. Preserve continued operation”

The factory must preserve the conditions required to keep delivering and improving. A local optimisation that destroys execution, observability, authority boundaries, rollback, or recovery is a system-level failure.

This goal constrains the other two. It requires the factory to protect critical infrastructure, retain human recovery paths, respect resource limits, and route high-risk changes through stronger approval and verification.

Why these goals stop at the factory boundary

Section titled “Why these goals stop at the factory boundary”

These three goals answer:

  1. What software-production outcome must the factory produce?
  2. How should that production capability improve?
  3. What must remain intact so production can continue?

They do not answer which market to enter, which customer problem matters most, how to allocate capital across competing opportunities, or when the organisation should change strategy. Those decisions require the wider identity, authority, and world signals introduced by the Autonomous Business Unit.

The factory goals do not disappear in Chapter 8. They become subordinate capability goals. The autonomous business unit decides which business outcomes to pursue; the factory continues to deliver, improve, and protect the software capability used to pursue them.

Section titled “Related concepts”