0% read on this device
Browse the curriculum

Start Here

Vision

First Principles

Operating Model

Domain Model

Agent Factory

Runtime Architecture

AI Engineering

Autonomous Workflows

Verification & Delivery

Factory Platform

Quality Engineering

Security & Governance

Case Studies

Labs

Interview Practice

Research Journal

Reference

Curriculum/Start Here/A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
Start Here3 min readoverview

Start Here

Intent → Plan → Define Agent → Execute through Harness → Apply Skills → Evaluate → Improve → Deliver Software

Status: Review readyRisk: variableLifecycle: intent · plan · execute · verify · deliver · learnContent reviewed 2026-08-30Maturity guide →
Claim boundaryThis chapter references implementation evidence. Inspect its evidence boundary before treating a claim as proven.
study mode

A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.

Intent → Plan → Define Agent → Execute through Harness → Apply Skills → Evaluate → Improve → Deliver Software

This section is the shortest path into AI Software Factory mastery. Read it before the detailed chapters. It establishes the system model, the vocabulary, and the boundary between enduring principles and Mission Control's current implementation.

The idea in one paragraph

An AI Software Factory is a governed engineering operating model. Humans define intent, constraints, priorities, and acceptable risk. Agents plan and execute bounded work. Independent validators produce evidence. Policy controls what may happen next. Humans retain accountability for material decisions. The factory exists to shorten the path from business intent to validated customer value without trading away quality, security, or control.

Mission Control is a concrete attempt to implement this operating model. It is not the definition of the model. The enduring principles should survive a complete rewrite. React, Convex, Hono, particular executors, and current schemas are implementation choices that can change.

The governing flow

The records are deliberately separate. Completing a Task does not accept its WorkOrder. Completing a WorkOrder does not accept its Mission. Passing tests does not authorize a merge or deployment. Each boundary represents a different claim and therefore requires different evidence and authority.

Five ideas to retain

Trust the system, not the model

Models are probabilistic and will fail. Reliable autonomy comes from the surrounding system: bounded authority, isolation, policy, independent validation, immutable history, evidence, recovery, and human accountability.

Intent matters more than activity

Agent sessions, prompts, tokens, and generated code are implementation detail. The primary object is the governed outcome the organization wants to achieve.

Evidence matters more than confidence

An agent's statement that work is complete is not proof. Acceptance depends on fresh, attributable evidence tied to predefined criteria and the exact artifact being reviewed.

Quality enables autonomy

Autonomy should increase only when the factory repeatedly demonstrates that it can operate within policy and produce independently validated outcomes. It must decrease when evidence shows a loss of trust.

Humans own risk

Agents may recommend, implement, validate, and explain. Humans remain accountable for business intent, material exceptions, risk acceptance, promotion of authority, merge, and consequential production decisions.

Choose a reading path

Do not treat the repository as one long checklist. Start at the altitude your current decision requires:

PathBest forOutcome
ExecutiveLeaders evaluating value, risk, and adoptionExplain the operating model in 20 minutes
ArchitectSystem, platform, security, and quality architectsWhiteboard the full system and its authority boundaries
BuilderEngineers implementing agent workflowsBuild and debug one governed delivery path
Deep StudyReaders seeking complete masteryFollow every curriculum area, lab, and teach-back

Use the Topic Index when you already know the concept you need. Use the Canonical Glossary when a term is unclear. Use the complete curriculum map when you want every chapter in sequence. Use the Detailed Architecture Coverage Matrix when you need the accountable owner, specification, evidence boundary, and validation path for a component or control. Use Capability Coverage and Maturity to see what is documented, review ready, validated, or operationally proven. Use the External Reviewer Guide when sharing the curriculum for feedback.

For the shortest foundation pass, read:

  1. AI Software Factory and Mission Control
  2. Software Factory Stack Boundaries
  3. Intent-to-Delivery Lifecycle

Then explain the system without notes. Any boundary you cannot explain clearly is the next study target.

Evidence boundary

This guide uses three labels deliberately:

  • Enduring Principle describes doctrine that should survive technology changes.
  • Current Mission Control Implementation describes behavior supported by a cited commit, source path, test, or observed browser journey.
  • Future Vision describes desired behavior that has not met the current evidence bar.

The distinction prevents a compelling product vision from being mistaken for working software.

Evidence boundary

Curriculum maturity is not implementation proof.

This chapter defines architecture or practice. It does not by itself prove a corresponding production implementation.

CurriculumReview readyImplementation evidenceNot asserted hereInspect evidence map →
External review

Review this chapter.

Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.

  • Claim
  • Boundary
  • Failure
  • Evidence