Skip to main content

Delivery Foundry: Autonomous Software Delivery Loop

Project overview of Delivery Foundry — a dual-track foundry for personal venture autonomy and organization 10x engineering, built on a shared governed kernel.

5 min read·Intermediate·Concept·Aug 25, 2026
projectai systemsautonomous systems

Delivery Foundry: Autonomous Software Delivery Loop

What Was Built​

Delivery Foundry packages the V12 architecture for loop-engineered software delivery: give it a PLAN.md, a mockup, or a mission statement, and the system loops through build → verify → deploy → observe → improve until the work is honestly complete or provably blocked.

The public repository (created 2026-07-20) contains:

  • Normative architecture — docs/foundry/delivery_foundry.md master index plus modular contracts under docs/foundry/docs/ (architecture, workflows, autonomy, security, operations)
  • Implementation roadmap — 83 sequentially numbered tasks in docs/PLAN.md with constitution articles C1–C22
  • Tasks 1–22 complete (2026-07-25) — via PR #1: agent harness, autonomous plan runner, Temporal kernel workflow, CLI/daemon, fitness suite, migrations, profiles, and policy compiler v1
  • Tasks 156–161 complete (2026-08-08) — via PR #14: Postgres-backed operator config store (operatorcfg.Store), versioned policy/quotas/model tables, packaging catalog DB load path, and -pg-dsn on foundry catalog commands
  • Tasks 162–164 partial (2026-08-10, updated 2026-08-11) — via PR #15 and commit cdc80eb: unattended input loop with AutonomyPolicy, transport inputrouter, kernel InputRouteWorkflow, mission brief API, and protected loop-proof CI; CLI executor layer PARTIAL PASS (live Path A/B receipts captured 2026-08-11); full Temporal+PG loop with SCM/billing/deploy receipts still pending per source evidence gate
  • Shared Kernel Proof (M0 exit) — end-to-end demo proving admit → worktree → verify → evidence → checkpoint restart

Tasks 23–155 and 165–83 (OPA integration, full provenance chain, venture and 10x tracks) remain open; this page tracks project evolution as documented in source.

The Problem​

Engineering teams want AI agents to deliver software autonomously — from a mockup sketch to a deployed product, or from an approved plan to verified commits on a shared branch. Two contexts need different governance:

  • Solo builders want bounded autonomy: discover, build, deploy, observe revenue, and self-improve inside an explicit envelope with minimal touchpoints.
  • Organizations want stricter control: provenance-verified plans, multi-repository execution, and handoff to existing 10x branch workflows without implicit trust in agents.

Both need the same durable kernel — state, evidence, recovery, policy — not two separate orchestration stacks.

Architecture Summary​

Track A accepts missions (example documented: reach verified net monthly recurring revenue), runs a venture loop with synthetic verification and bounded self-adaptation, and uses admission tiers A0/A1/A2/H plus a Mission Setup Ceremony before unattended operation.

Track B accepts human-approved PLAN.md files, executes across one or many repositories, and may stop at TEN_X_BRANCH_HANDOFF_READY — verified atomic groups on a shared 10x branch with no PR, merge, or deployment in that workflow.

Evolution and Milestones​

MilestoneWhat it proves / ships
V12 documentation setModular normative contracts; V11 content preserved via migration map
Task 1 (✅ 2026-07-20)Docker dev toolchain, CI, Go package scaffolds, fitness v0
Tasks 2–22 (✅ 2026-07-25, PR #1)Agent harness (.ai/), plan runner, Temporal kernel, CLI/daemon, SKP e2e, migrations + policy compiler
Tasks 156–161 (✅ 2026-08-08, PR #14)Operator-hot config Postgres SoT: operatorcfg.Store, versioned policy/quotas/catalogs, DB-backed foundry catalog
Tasks 162–164 (⚠️ partial 2026-08-10, CLI receipts 2026-08-11, PR #15 + cdc80eb)M9 unattended input loop: AutonomyPolicy, InputRouteWorkflow, loop-proof CI; CLI executor receipts captured; full Temporal e2e still pending
M0 — Shared Kernel Proof (✅)Admit one plan → worktree → verify → evidence → resume after restart
M1 — Foundation (partial)Tasks 20–22 done; OPA PDP, full provenance chain, ledger (Tasks 23–26) pending
Venture MLS (Track A)Mission → deployable product → billing observation → one bounded improvement cycle
10x MLS (Track B)Approved plan → provenance → atomic group → direct 10x branch push
Mission-capable ventureAutonomous improvement within drift governance envelope
Org-production 10xMulti-repo orchestration with organization integrations

Roadmap estimates and builder assumptions are documented honestly in docs/architecture/overview.md — ranges with confidence levels, not false precision.

Key Decisions​

DecisionRationale
Two tracks, one kernelAvoid serializing venture autonomy behind org milestones
Mockup as first-class entrydocs/workflows/mockup-to-delivery.md with Observed/Inferred/Assumed labels
PEC rename from "Forge"Avoid collision with Atigravity Forge; kernel retains authority
Docker-only host requirementsDocker + GNU make; no local Go/Node/Playwright install
Constitution-gated tasksEvery plan task checked against C1–C22; make fitness at milestone exits
Autonomous plan runner (Task 3)Risk-tiered AUTO/GATED orchestrator; bootstrap tool retires once kernel admits backlog
Multi-provider agent harness (Task 2)ARES .ai/ canonical source composed to Claude/Codex; eleven skills mapped to six roles
Constitution fitness (Task 18)fitlint enforces C1 enum rules, import boundaries, and doc links in CI
Four container image lineagesAnti-sprawl rule: dev, postgres/temporal, executor sandbox, release binary
Postgres operator config SoT (Tasks 156–161)Policy, quotas, model rates, and packaging catalogs share one versioned store; disk YAML seeds once at daemon boot
Unattended input loop (Tasks 162–164)All IDEA/MOCKUP/brief transports route through persistent input router + kernel workflow under explicit AutonomyPolicy; CLI executor receipts PARTIAL PASS (2026-08-11); full Temporal+deploy proof still pending

Entry Types and Workflows​

All entries converge on deterministic admission, then the standard delivery loop:

Entry typeTypical workflow document
Approved PLAN.mddocs/workflows/direct-plan.md
Mockup or sketchdocs/workflows/mockup-to-delivery.md
Mission statementdocs/workflows/venture-loop.md
Multi-repo org plandocs/workflows/multi-repository.md
10x shared branchdocs/workflows/ten-x-branch.md

Recovery, retry, and honest completion semantics live in docs/workflows/recovery.md.

Repository Layout (current)​

docs/foundry/delivery_foundry.md   master architecture index
docs/PLAN.md                       83-task implementation plan (Tasks 1–22 ✅)
docs/architecture.md               one-page constitution + link map
.ai/                               canonical agent harness (ARES format)
AGENTS.md / CLAUDE.md              composed provider views (do not hand-edit)
cmd/foundry/                       operator CLI
cmd/foundryd/                      Temporal kernel worker
cmd/fitlint/                       constitution linter
tools/planrunner/                  bootstrap autonomous task orchestrator
deploy/                            Docker dev toolchain + postgres/temporal compose
internal/                          Go packages (kernel, state, admission, evidence, operatorcfg, inputrouter, autonomypolicy, …)
scripts/fitness.sh                 constitution check suite
scripts/loop_proof.sh              protected unattended-loop proof gate
scripts/loop_proof_cli.sh          host-only CLI executor receipt proof (subscription Claude CLI)
Makefile                           docker-wrapped targets

Lessons Learned​

  1. Document authority before code — V12 relocates V11 prose into modular contracts so implementation agents receive only relevant normative sections.
  2. Honest roadmap sizing — Dual-track scope increases total effort; the architecture states this explicitly rather than hiding it behind a single-track estimate.
  3. Bootstrap then kernel — Tasks 1–3 required manual or runner trigger; PR #1 delivered the runner and the first kernel workflow so later tasks can dogfood Foundry itself.
  4. Fitness functions earn the design score — The spec targets 10/10-quality design but declares the score is earned only when fault-injection, security, and SLO tests pass.
  5. Legacy quarantine — docs/legacy/ is banner-marked superseded history and must never be fed to implementation agents.

Sources​