Foundry is a governance kernel for AI agents that write code. Its current manual lane records tickets, submissions and reviews without launching agents. Same-login records are useful for following a workflow, but are not tamper-resistant against agents with that login or proof of an independent reviewer. Agents do the work; Foundry's protected acceptance boundary is a later, separately gated option.
Status (2026-09-25): early and not in production. Foundry runs today as the manual lane. It records work but launches nothing: a human or LLM operator hands each work packet to an agent by hand. Foundry is being built by using it on itself (dogfood log).
Coding agents are now capable enough to do real work unattended. The hard part has moved from getting an agent to act to trusting what it did:
- An agent reports "tests pass". Did they pass, on which commit?
- Did the reviewer see the same code the developer submitted, and were they independent, or the same model checking its own work?
- A session crashed halfway through. What finished, what is still uncertain, and what is safe to retry?
- Did the run stay within its budget, or quietly fall back to a paid API?
Most agent tooling improves the agent: better prompts, more tools, bigger task graphs. Foundry works on the other side of that line. It is the part that does not trust the agent.
Foundry's manual lane helps capable models follow work with these recorded rules. They are not host-security guarantees while every participant shares one login:
| Guarantee | What it means in practice |
|---|---|
| Admitted intent | Work starts as an admitted ticket with a base commit, a file scope and acceptance criteria. Agents cannot widen it. |
| Bounded authority and budget | Every agent run spends a pre-granted allocation. There are no paid fallbacks, and no eligible budget means the work waits with a reason. |
| Exact evidence | A submission is a specific commit in a clean checkout, descended from the admitted base. Reviews bind to that exact commit. |
| Independent acceptance | Core refuses a reviewer whose recorded principal did the developer work. An agent's own claim never counts as acceptance. Until isolation lands (FR-15aB), principals are recorded, not authenticated. |
| Durable, replayable state | Every acknowledged decision is a committed event in one SQLite store. A restart replays it. An uncertain outcome is never retried: it is settled as unknown until FR-10 supplies reconciliation. |
| Observation is not authority | Logs, process exits and transcripts can explain work. They cannot admit, accept or integrate anything. |
The short version is a phrase from the strategy: a working process is not progress; progress is not completion; completion is not acceptance.
operator Foundry (manual lane) agents
──────── ───────────────────── ──────
lane admit ──► ticket: base, scope, acceptance
lane packet ──► developer packet (spends one allocation) ──► developer works in its own worktree
◄── lane submit --candidate <sha> --checkout <dir>
lane packet ──► reviewer packet (different principal) ──► fresh reviewer, different model
◄── lane review --verdict approved|correction|rejected
ready_to_integrate
git (manual) ──► lane integrated: is base..candidate in main?
Each arrow into Foundry is a command. The kernel checks it against the current state and
refuses it with a stable reason if it does not fit, for example wrong_source_phase or
candidate_mismatch. Otherwise it is committed as an event. How Foundry works
explains each mechanism (the store, the kernel, packets, principals, reviewer independence,
refusals, recovery) and defines the vocabulary.
- Not a coding agent or harness. It does not write code or prompt models. Claude, Codex, Pi or any other agent does the work. Foundry records and governs it.
- Not an orchestrator or DAG engine. Planning, decomposition and sequencing belong to replaceable controllers, which can be model-driven. Foundry owns the rules that judge their results, and keeps them where the planner cannot change them (orchestrator boundary).
- Not a sandbox, yet. Nothing in the tree launches an agent, so nothing needs sandboxing today. Isolated execution is a prerequisite for automatic launch (FR-15a), not something Foundry has now.
- Not a model gateway or billing system. It never grants entitlement. A model name or an available credential is not permission to spend.
- Not production software. It is not limited to one operator or machine, but so far it has only run that way, on its own repository. There is no release, no multi-tenant story, and no stability promise on any interface.
The repair plan is the sole backlog. The first product goal is a useful local workflow assistant for Pi, Codex and, when available, Claude Code: work in a branch, run checks, get model review and publish a PR through the normal repository rules. The installed MCP preview currently offers only read-only manual-lane status; the wider experience is not built yet. Compare it on real Foundry tickets against the operator's existing workflow prompt and a minimal shared checklist before deciding it is worth maintaining. Try Pramāṇa as a separately authorized second project only after this internal dogfood.
Protected identities, service ownership, automatic acceptance and autonomous
launch remain separate, gated options,
not claims of the local product. LaunchEligibility has no callers; Foundry does
not launch agents today.
You need the Elixir/Erlang toolchain pinned in mise.toml, plus git and python3.
mix deps.get
TMPDIR=/private/tmp MIX_ENV=test mix test # model-free suite
bin/foundry-lane build && bin/foundry-lane start # the lane daemon
bin/foundry lane statusTo run a real ticket through the lane, follow the lane runbook.
The full gate is TMPDIR=/private/tmp elixir ci/run.exs --output <dir outside the repo>
(CI).
| If you want to… | Read |
|---|---|
| Understand the mechanisms and vocabulary | How Foundry works |
| Find any document, by task or by layer | Documentation index |
| Run the lane | Lane runbook |
| See what is next | Repair plan, then the dogfood log handoff |
| Change code | AGENTS.md, then the boundary rules |
| Understand why | Strategy working summary |
lib/foundry/
manual_lane/ the lane: CLI, backend, server, log, replay
workflow/ the pure workflow kernel: decides transitions, never writes
durable_store/ Core: the SQLite authority store and its gateway
observations/ bounded read queries over the store
repair/ FR-08A attestation modules
cli/rpc.ex inert command transport; dispatches lane commands only
launch_eligibility.ex, quota/, effects/ policy and process leaves kept for FR-09/FR-10
test/ model-free ExUnit suite, including the architecture gate
bin/ foundry (RPC wrapper), foundry-lane, evidence tools, doc checker
ci/run.exs the gate
spec/ Quint models of the ledger, the Core boundary and FR-10 effects
docs/ everything above; start at docs/README.md
Git holds source, tests, specs and the lockfile. It does not hold live state, logs,
releases or provider credentials. The operator runtime root defaults to the ignored
local/ directory in the main checkout (FOUNDRY_OPERATOR_RUNTIME_ROOT overrides it).
It must never come from a task worktree.
Foundry was split from the Pramāṇa project on 2026-09-23, with its full history. It is
now fully independent: it depends on no Pramāṇa code, service, document or process. Commit SHAs recorded
before the split name Pramāṇa commits. The legacy daemon stack was deleted rather than
migrated (plan amendment C1). The edge cases its
tests encoded are kept in moved knowledge.
Audits and other dated records are at tag
records/2026-09-24.