Pre-release. Factory is in development and is not yet available to customers. Current status and evidence.

Factory

Status

What works today, what is in development and what is planned, with the evidence for each claim. Terms such as Slice and Candidate are explained in The words.

Where Factory stands

As of 29 September 2026. Each line is read again from its source whenever this site is built, and the build stops if the source no longer says it.

  • Factory is accepted local infrastructure in development, on one Mac.

    Source: docs/agents/factory-model.md

  • Nothing has shipped: there is no production service, release or customer yet.

    Source: docs/agents/factory-model.md

  • All 27 customer-value epics are open; none closes without its own independent evidence.

    Source: docs/epics.json

  • No model route is qualified yet, so no model runs inside Factory: both producer receipts say unavailable.

    Source: docs/claude-producer-receipt.json · docs/openai-producer-receipt.json

  • The delivery flow that joins the accepted parts is not built yet: Repository Assurance, the Product gate and the Repository collector are each accepted, and composed into nothing.

    Source: docs/build-review.md

  • Six local products are registered for read-only metadata inspection. Registration grants no right to change, release or spend.

    Source: docs/onboarding-receipt.json

  • Every accepted module was reviewed independently by a different model from a different provider (OpenAI's gpt-6-astra) before acceptance, and failed rounds are recorded: Producers passed on its ninth round, Repository Assurance and the Product gate on their sixth.

    Source: docs/build-review.md

What the labels mean

Working today · verified
It runs on the owner's Mac today, and a different model's independent review accepted it. Its scope is stated beside it: usually the local fixtures or the local dashboard, never a release.
In development
Parts are built and accepted, but they are not yet joined into anything that runs, or cannot run live yet. What is missing is stated beside it.
Planned
Designed or directed by the owner; nothing of it is built. Where the plan is written down is linked beside it.

Working today · verified

These run on the owner's Mac today. Each states its scope.

  • Record every decision once

    Working today · verified

    Each accepted Command is written once, with its result and the Events it caused. Repeating a command returns the recorded answer, so the decision is never made twice; a changed command under the same ID is refused.

    Scope: One local SQLite file on one Mac, crash-tested by killing processes; power loss is not tested. Anything a caller does outside the journal can still happen twice.

    Evidence: Command journal guide · Existing-store receipt (JSON) · Inspection receipt (JSON) · Build review

  • Check a fixture and give an honest Verdict

    Working today · verified

    A built-in test fixture runs as a real, bounded process. What it did is stored as Evidence named by its own contents, and Assurance gives a Verdict: Verified, Failed or Inconclusive. Anything missing, altered or unclear never counts as a pass.

    Scope: The four built-in test fixtures only (pass, fail, hang and noisy), run from the command line as the local development reference shows. Not a product's code.

    Evidence: Evidence and Assurance guide · Fixture worker guide · Baseline receipt (JSON) · Build review

  • Recover from a controller crash within Budget

    Working today · verified

    Each Attempt has exactly one owner and a private workspace. If the controller dies partway, the next run settles that Attempt from its stored report, or proves the old work cannot resume, and starts at most a bounded replacement. A Run's Budget is never extended.

    Scope: The built-in fixtures on one Mac. Recovery happens when someone runs verify or recover, never in the background.

    Evidence: Guarded verification guide · Attempt fence guide · Recovery receipt (JSON) · Build review

  • See each product's sourced progress, with unknown shown as unknown

    Working today · verified

    A local dashboard shows what sources report for each registered product, with the source and the time. A number that is partial or unknown says so, and why; only an exact count ever shows 0.

    Scope: Six local products, registered for read-only metadata inspection. Facts arrive by trusted local import, the dashboard answers only on this Mac, and customer value always shows as unknown.

    Evidence: Portfolio guide · Dashboard guide · Portfolio receipt (JSON) · Dashboard receipt (JSON) · Onboarding receipt (JSON)

  • Keep each product's core values as exact revisions

    Working today · verified

    Up to six values per product, each with the rule it applies when choosing between options. Every save is a new revision, and anything that cites a revision gets exactly that revision back, even after later edits.

    Scope: Edited in the local dashboard. Nothing plans with these values yet, and they grant no permission.

    Evidence: Project guidance guide · Guidance receipt (JSON)

  • One list of what needs attention, from sources only

    Working today · verified

    Open blockers, unavailable repositories and failing sources in one list. Each blocker has a guide: what is blocked, who can act, what was tried and the next step. Missing data never becomes an action.

    Scope: A blocker resolves only when its source reports it; Factory does not re-check the prerequisite itself.

    Evidence: Required actions guide · Guidance receipt (JSON)

In development

Parts of these exist and are accepted. Each says what is still missing.

  • Deliver one useful change, end to end

    In development

    Join the accepted parts into one flow: a Slice admitted under your grant, a Candidate built and sealed, checked in the sandbox, judged, and integrated once, with every step recorded.

    Still missing: Step 1, increments 4 to 8: the joining flow under the Product gate, its command line, an independent review of the whole, then one useful change delivered to a real local product.

    Evidence: Handover: next steps (not published) · Build review

  • Ask a model for a bounded proposal, through your subscription

    In development

    One model, asked once with every tool switched off, proposes small text-file edits for a Slice. Its answer is only data: Repository decides whether it can be sealed.

    Still missing: No model route is qualified, so nothing is proposed yet. Claude Code needs a person to check its built-in agents and plugins, then a fresh qualification under the current rules. A route through the ChatGPT sign-in is not built.

    Evidence: Producers guide · Claude receipt: unavailable (JSON) · OpenAI receipt: unavailable (JSON)

  • Seal a proposed change as an exact Candidate

    In development

    Proposed edits become a Candidate: an exact commit and manifest that cannot change afterwards without being detected, exported byte for byte for checking.

    Still missing: Accepted for fresh repositories that Factory owns, but nothing in Factory calls it yet, and no real product's code has been sealed.

    Evidence: Repository guide · Sealing receipt (JSON)

  • Check a real change in a sandbox, then judge it

    In development

    Each of a Slice's frozen checks runs once in a macOS sandbox with no network and nothing writable. What the host observed becomes Evidence, and Repository Assurance judges it: Verified, Failed or Inconclusive.

    Still missing: The sandbox, the collector and the judge are accepted as parts, but nothing joins them to a delivery yet, and no real Slice has been checked.

    Evidence: Confined executor guide · Executor receipt (JSON) · Repository collector guide · Repository Assurance guide

  • Admit delivery work only within your grants

    In development

    One durable record per product holds your grants, their revocations, a stop switch and the one current owner. It freezes each Slice with its allowance and admits every build, check and branch move only within it.

    Still missing: Accepted as a part; nothing calls it yet, and no Slice has been delivered through it.

    Evidence: Product gate guide · Build review

  • Move a branch at most once, and say unknown when unsure

    In development

    The target branch moves from the Candidate's base to its commit at most once per prepared Action. If Factory cannot confirm the move, it reports unknown and never retries blindly; a last check just before the move can hold it back.

    Still missing: Accepted for fresh local repositories, but not yet joined to the Product gate, and it contacts no remote.

    Evidence: Repository guide · Integration receipt (JSON) · Last-check receipt (JSON)

  • Use a model only where it is needed

    In development

    One registry says which parts may use a model, which one, at what effort and why. Most never do: recording, checking and showing work must give the same answer every time. It refuses rather than substitutes a model.

    Still missing: No model is qualified, so every model task refuses today.

    Evidence: Intelligence guide · Per-module table in the README (not published)

  • Find customer problems in public sources

    In development

    Each product's public sources are read on a schedule: a basic pass daily and a full pass weekly. Code fetches, de-duplicates and keeps an exact quote and hash; a small, fast model sorts new items into Signals.

    Still missing: Two parts are built and each passed independent review, tried only on test data: the schedule, which names each nightly and weekly pass once and holds its weekly token allowance, and the reader, which fetches only the public pages you commission and keeps exact quotes with their hashes. Nothing joins them or runs on a schedule, no real page has been fetched, sorting into Signals is not built, and the detailed design still awaits your decisions (P-C20 in the project intent).

    Evidence: Discovery sources guide · Lifecycle schedule guide · Discovery design · Build review · Project intent (not published)

Planned

Nothing of these is built yet. Each links where it is planned.

  • Admit, park or reject proposals, rules first

    Planned

    Once a week a larger model turns the strongest clusters of Signals into a few proposals. Fixed rules decide first; a second model may challenge a proposal but only ever lower it; anything that widens authority goes to you.

    Plan: Owner direction of 29 September 2026 (P-C20 in the project intent).

    Sources: Project intent (not published)

  • Ask you only what Factory cannot decide

    Planned

    A short, focused list of decisions only you can make, each with its objective, trade-offs, a recommendation and the Evidence one click away. Routine, reversible work never waits for approval.

    Plan: The decision interface design and the project intent (P-C01, P-C16).

    Sources: Decision interface design · Project intent (not published)

  • Plan from each product's saved values

    Planned

    A brief pins the exact revision of a product's values it follows, applies their rules and explains the trade-offs. Values guide choices; they never grant authority or weaken acceptance.

    Plan: Next step 3 in the handover.

    Sources: Handover: next steps (not published)

  • Release only with your approval

    Planned

    Release notes and launch copy are drafted from checked facts only. Every outward action (publishing, releasing, contacting customers, spending) waits for your approval of that exact action, and risky changes reach an alpha channel first.

    Plan: The design's release and marketing rules, and owner direction of 29 September 2026 (P-C20).

    Sources: Design: deliver with evidence · Project intent (not published)

  • Measure whether a change helped

    Planned

    A measurement contract is fixed before release: baseline, target, window and guardrails. When the window closes, an Assessment concludes Supported, Rejected or Inconclusive; only Supported counts as value. A/B tests are used only under genuine uncertainty.

    Plan: The design's measurement rules, and owner direction of 29 September 2026 (P-C20).

    Sources: Design: measurement · Project intent (not published)

  • Keep, renew or retire, and improve in bounded steps

    Planned

    Capabilities are kept while they serve customers and retired deliberately, with migration and notice. Nightly research and weekly simplification enter as ordinary verified Slices, and anything a clean-up breaks is restored.

    Plan: The self-improvement design and next step 4 in the handover. No schedule is active.

    Sources: Self-healing and self-improvement · Handover: next steps (not published)

  • Reuse the lifecycle in a second product

    Planned

    A second product reuses the process and its proven parts while its data, authority and behaviour stay separate.

    Plan: Epic E18 in the implementation guideline.

    Sources: E18 in the implementation guideline

What is not established

Not established yet, in plain words:

  • No release, production service or customer. Nothing has shipped, and no customer benefit has been measured.
  • No qualified model route, so no model runs inside Factory yet.
  • No scheduled automation: nothing runs nightly or weekly.
  • No joined delivery flow: the accepted parts are not yet composed.
  • Power loss, other platforms and more than one machine are not tested.
  • The sandbox is not a general sandbox for arbitrary code: there is no hard memory, disk or CPU-time stop.
  • Records are attributed, not authenticated: anyone who can write the local stores could forge consistent records.

What comes next, in order

  1. Make one useful local delivery work end to end.

    In development

  2. Qualify bounded, proposal-only model routes through your subscriptions.

    In development

  3. Plan from each product's saved values.

    Planned

  4. Add the evidence collectors a real Slice needs, then bounded evolution.

    Planned

  5. Then discovery before building, and release and measurement after it.

    In development

Progress log

Each accepted step, newest first, with the evidence behind it. The docs explain every module and its limits.

  1. The first parts of discovery: a schedule and a page reader

    Lifecycle increments 1 and 2 of the proposed discovery design: a schedule that names each nightly and weekly pass once and holds its token allowance, and a reader that fetches only commissioned public pages, reads robots.txt first and keeps quotes that can be checked again. Each passed independent review, the schedule on the fourth round and the reader on the fifth. Both are tried only on test data, and nothing runs on a schedule.

    Evidence: Lifecycle schedule guide · Discovery sources guide · Build review

  2. The sandbox collector and a last check before a branch move

    Step 1, increments 3 and 3b: the Repository collector runs a Candidate's frozen checks in the sandbox and stores what it saw, and Repository can run a last check just before it moves a branch. Both accepted on their second review round; neither is joined into delivery yet.

    Evidence: Repository collector guide · Repository guide · Build review · Last-check receipt (JSON)

  3. Repository Assurance and the Product gate

    Step 1, increments 1 and 2: a judge for repository Candidates, and one durable record per product for grants, admissions and delivery records. Accepted on the sixth review round, after rounds 1 to 5 each found something to fix. Not yet joined into delivery.

    Evidence: Repository Assurance guide · Product gate guide · Build review

  4. Subscriptions only, and the full lifecycle

    The owner directed that models run only through the owner's own subscriptions, never Platform API keys, and added discovery before building and release, measurement and clean-up after it. Recorded in the project intent; its first parts are now built (see above).

    Evidence: Project intent (not published)

  5. An explicit decision about models, per module

    Every module now declares whether it uses a model, which one and why; most use none. Accepted on review; no model is qualified yet, so every model task refuses.

    Evidence: Intelligence guide

  6. Producers for Claude and OpenAI

    One contract for asking a model, once, for bounded edit proposals, with adapters for the Claude Code command line and OpenAI's Responses API. Accepted on the ninth review round. Both live routes are unavailable.

    Evidence: Producers guide · Claude receipt (JSON)

  7. The local dashboard, Portfolio and project values

    Six local products registered for read-only metadata; a dashboard of sourced progress where unknown is never zero; each product's core values kept as exact revisions; one list of what needs attention. Checked in a real browser at desktop and phone widths.

    Evidence: Dashboard guide · Portfolio guide · Project guidance guide · Dashboard receipt (JSON) · Portfolio receipt (JSON) · Guidance receipt (JSON)

  8. Sealed Candidates, a macOS sandbox and invoke-once integration

    Exact, immutable Candidates in repositories that Factory owns; a sandbox that runs one bounded program and reports only what it saw; a branch move made at most once, reporting unknown when unsure.

    Evidence: Repository guide · Confined executor guide · Sealing receipt (JSON) · Executor receipt (JSON) · Integration receipt (JSON)

  9. Records, runs and recovery

    The command journal, Evidence and Verdicts, Run and Attempt ownership, the fixture worker, per-Attempt fences and crash recovery within Budget: what every later module depends on.

    Evidence: Command journal guide · Guarded verification guide · Baseline receipt (JSON) · Recovery receipt (JSON)

  10. The design, its values and 27 outcome-based epics

    One architecture at three reading depths, one domain language, core values and 27 customer-value epics, each with measurable success criteria. All of them are still open.

    Evidence: Design · Values · Implementation guideline