How it works

Factory reads each product's public sources on a schedule: issue trackers, forums, reviews and changelogs. Plain code fetches, de-duplicates and keeps an exact quote and hash of each item; a small, fast model sorts new items into Signals, such as a customer problem, a request or a competitor move.

Gate

Every source reports its coverage, and every new item is sorted or marked unsorted. Research is never treated as a customer interview.

Evidence it leaves

Cited quotes with their hashes, and a coverage record for each source.

• Find customer problems in public sources

  In development

  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).

Once a week a larger model turns the strongest clusters of Signals into a few proposals. Rules decide first, at no model cost: is the evidence real, recent and from customers, can the outcome be measured, is there capacity, and does it stay within your authority? A second model may challenge a proposal, but it can only lower it, never approve it.

Gate

Each proposal gets one recorded decision (admitted, parked or rejected) naming the rule or answer behind it. Anything that would widen authority goes to you.

Evidence it leaves

The decision, the rule behind it and the Signals it cites.

• Admit, park or reject proposals, rules first

  Planned

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

• Ask you only what Factory cannot decide

  Planned

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

Planning freezes the smallest useful change as a Slice: the need, what is in and out of scope, the acceptance checks, the allowance of runs and time, and how the outcome will be measured. All of it is fixed before any code is written.

Gate

The Product gate records the frozen Slice under a live grant from you. Nothing later can widen its scope or lower its acceptance.

Evidence it leaves

A frozen Slice record, written once, with the digests of its inputs.

• Admit delivery work only within your grants

  In development

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

• Plan from each product's saved values

  Planned

  Plan: Next step 3 in the handover.

A producer asks one model, once, for small text-file edits within the Slice's scope, with every tool switched off. The answer is only a proposal: Repository seals it as a Candidate, an exact commit and manifest that cannot change afterwards without being detected.

Gate

The proposal must parse within fixed limits, or nothing is sealed. A Candidate that changes anything outside the Slice's frozen paths can never be integrated.

Evidence it leaves

The sealed Candidate: its manifest and its exact bytes.

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

  In development

  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.

• Seal a proposed change as an exact Candidate

  In development

  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.

The Slice's frozen checks run against the unchanged code and the Candidate, each once, in a macOS sandbox with no network and nothing writable. What the host observed is stored as Evidence, and Assurance judges it and gives a Verdict: Verified, Failed or Inconclusive. The builder's own claims carry no authority.

Gate

Only Verified moves on. A timeout, a missing record or anything unclear never counts as a pass: the Verdict is Failed if any required check failed, and otherwise Inconclusive.

Evidence it leaves

One Evidence record per check run, and the Verdict with its pins.

• Check a fixture and give an honest Verdict

  Working today · verified

  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.

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

  In development

  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.

The Product gate works the Verdict out again, inside its decision, and confirms the Candidate stays within the Slice. Then the target branch moves from the Candidate's base to its commit, at most once. If Factory cannot tell whether the move happened, it says unknown and blocks every later move until that is settled.

Gate

A Verified Verdict re-derived at the moment of the move, a live grant, and no unknown move outstanding for the product.

Evidence it leaves

A Receipt for the confirmed move.

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

  In development

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

• Deliver one useful change, end to end

  In development

  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.

Factory drafts release notes and launch copy, rendering every claim from a checked fact. Anything outward-facing (publishing, releasing, contacting customers, spending or changing live traffic) waits for your approval of that exact action. Potentially unsafe changes reach an alpha channel before everyone.

Gate

Your approval of the exact draft and action. Availability is claimed only after the channel's Receipt and a check from the customer's side.

Evidence it leaves

The approved draft's digest, the channel's Receipt and the availability check.

• Release only with your approval

  Planned

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

The measurement was fixed before release: baseline, target, window and guardrails. When the window closes, an Assessment compares what happened with the intended outcome and concludes Supported, Rejected or Inconclusive. Only Supported counts as value; a rejected change closes as learning, never as a win.

Gate

Assurance independently checks the instrumentation and how the decision rule was applied.

Evidence it leaves

The Assessment, with the frozen contract and the observations it rests on.

• Measure whether a change helped

  Planned

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

The improvement becomes a Capability with an owner and executable checks. Factory keeps it while it serves customers, renews it when Evidence shows friction, and retires it deliberately, with migration and notice, when its benefit no longer justifies its cost. If a later clean-up breaks it, Factory restores it.

Gate

Retirement needs evidence beyond low usage, and your decision whenever customers would notice.

Evidence it leaves

Capability records: required, retiring or retired, and healthy, degraded or unknown.

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

  Planned

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

• Reuse the lifecycle in a second product

  Planned

  Plan: Epic E18 in the implementation guideline.