Source: https://www.orchestro.org/docs/factory/lifecycle Updated: 2026-09-20 # From a signal to a verified cure. Updated September 20, 2026[Read as Markdown ↗](https://www.orchestro.org/docs/factory/lifecycle.md) Signals become evidence. Evidence establishes a cause. A bounded repair becomes a cure only when the required verification proves it. [Start with the visual Factory tour](https://www.orchestro.org/factory), then use this page to connect the public language to the actual implementation. Agent Factory is the current product name on Orchestro. 1. 1Send 2. 2Classify 3. 3One problem 4. 4Investigate & fix 5. 5Verify 6. 6Cure or park ## A report in the backlog is not a promised PR Intake classifies the signal and attaches it to a canonical identity — a new one, or an existing one. That is correct disposition. It is not a promise of investigation or a PR. The selector later chooses what may change. A report may remain in the queue, wait for evidence, attach to a problem already shipped, describe expected behavior, or, rarely, be a true duplicate. [Follow an 11-report weekend through intake](https://www.orchestro.org/factory#from-a-report), then F-17 from investigation onward — not back through the reports. **Implementation snapshot: 20 September 2026.** The core is implemented in the private framework. Sources, tests and release procedures require project configuration. Examples below are fictional. Built-in autonomous web/mobile journey execution and full Backlog Zero certification remain roadmap; they are not shipped product settings. ## A signal is not automatically a bug Users, support, production logs, monitoring, product analytics, automated tests, agents and human-created issues can all provide evidence. Each source must be connected through the project’s configured inputs; this is not a list of turnkey integrations. A report may reveal a real bug, capability gap, wrong result, false action claim or service availability issue. It may also describe expected behavior or lack enough evidence. These are explanatory categories, not a new implementation enum. The agent proposes a classification; validated intake and durable authority decide what may happen next. ## Public language → implementation ### Signal An observation from a person, system or test. It may describe expected behavior or incomplete evidence. **In the implementation:** Configured truth sources; signalIdentity; structured intake ### Canonical identity The durable address of one problem, with linked reports and repair history. Source-provided occurrences can grow without creating new problems; distinct-user totals require source data. **In the implementation:** signalIdentity; same\_cause relations; family grouping ### Classification An agent proposes what the evidence means; deterministic validation controls what is recorded. Public examples include bugs, capability gaps, wrong results, false action claims, availability, expected behavior and uncertainty. **In the implementation:** Intake: verify / fix / feature / experiment / decision. Investigation: product / measurement / both / ops / unknown ### Selector Chooses executable work under priority, current authority, dependencies, evidence and human decisions. A high-ranked item that cannot run should not occupy the mutating seat. **In the implementation:** factory.ts; checkpoint; current / evidence\_acquisition / backlog\_campaign; measurement dependencies ### Root cause boundary The specific causal mechanism the investigation proves. Similar symptoms do not grant authority to merge unrelated causes. **In the implementation:** causal\_confirmation; ROOT\_CAUSE\_CONFIRMED ### Remediation One bounded change and persistent PR for one cause. Review and regression evidence belong to that identity. **In the implementation:** remediation receipt; IN\_REMEDIATION ### Merge Code joined the main branch. This does not prove release or repair for users. **In the implementation:** merge receipt; mergedSha; release queue (not a separate MERGED lifecycle enum) ### Release The relevant version reached the declared delivery surface. A web release is not proof of native app distribution. **In the implementation:** deploy receipt; deployedSha; releaseChannels ### Verification A separate actor checks the declared evidence against the released version. Outcomes are passed, failed or inconclusive. **In the implementation:** WAITING\_VERIFICATION; verification receipt; verifier.command ### Recurrence A verified cause returns. Reuse its identity and history rather than making an unrelated ticket. **In the implementation:** RECURRENT; cure lineage; current observations ### Evidence plan A bounded next probe: what is missing, how to obtain it, and an evaluable return condition. **In the implementation:** evidence\_plan; missingEvidence; nextProbe; dueAt or targetSampleCount + planBaselineOccurrences ### Park / re-entry Keep the problem open and visible while unrelated work proceeds. When its supported condition becomes due, the probe becomes eligible for selection. **In the implementation:** EVIDENCE\_PENDING; EVIDENCE\_PLAN\_WAITING; WAITING\_VERIFICATION\_DEFERRED; verificationNotBefore ### Cured Required verification has passed. Where production reconfirmation is configured, it must also pass before cure. **In the implementation:** IN\_PRODUCTION\_UNCONFIRMED → cure\_reconfirmation → CURED (when configured) ### Backlog Zero Zero actionable deterministic debt in the declared scope. Evidence waits, external waits, observation, owner decisions and explicit deferrals remain visible. **In the implementation:** NO\_ACTIONABLE\_WORK / EVIDENCE\_WAIT\_ONLY + remainingGates. Full zero-proof certification remains roadmap ## Understand, group into one problem, then select Ten matching reports should strengthen one problem rather than produce ten unrelated tickets. Intake reuses an exact or high-confidence backlog match. Proposed relations and family grouping do not prove a common cause. Keep distinct causes separate, and retain the original evidence when a family needs to be split. The selector reconciles current signals, due evidence probes and the canonical backlog. Existing mutation authority, measurement dependencies, priority, human decisions and release/verification state constrain execution. Only one mutating causal boundary is allowed at a time. A parked item stays visible without holding that seat; re-entry makes it eligible, not automatically selected ahead of other authority. ## Worked example: a saved change that stays invisible This generic application example uses one identity, F-17, throughout. The observed symptom is “I saved a change, but the app still shows the old version.” 1. **Signals.** “I still see the old version.” “Saved. Nothing changed on screen.” Same person, same weekend. That is evidence, not yet a proven bug. 2. **Classify.** Compare the saved result with what people actually see. Is this a bug, a missing capability, expected behavior, or simply not enough evidence? Classification is not a PR. 3. **One problem.** Link the matching reports to F-17. Keep their evidence and history together. A similar-looking error with a different cause stays separate. 4. **Select.** F-17 is classified and attached. The Factory now chooses the next work that is allowed: priority, evidence and human decisions. Other identities stay in the queue or wait for samples. Only one cause is rewritten at a time. 5. **Investigate.** The saved record is correct. A reproducible check shows that the app keeps an old cached version after save. The problem is the refresh path. 6. **Fix.** The agent repairs the refresh path and adds a regression check. Review, merge and release evidence stay attached to F-17. A merged PR is only one step. 7. **Verify.** An independent check exercises the released save-and-refresh flow. Tests, release identity and the declared production evidence determine the verdict. 8. **Cure or park.** Pass the required checks and observation window: cured. Missing evidence: wait with a plan. A confirmed failure: reopen the same problem. Then select again. **Passing ending:** the regression check succeeds, the reviewed PR is merged, and the relevant release is recorded. An independent verifier checks the released save-and-refresh flow. If the project requires production reconfirmation, the item remains `IN_PRODUCTION_UNCONFIRMED` until that check also passes. Only then is F-17 `CURED`. **If it returns:** evidence tying a later failure to the same cause makes F-17 `RECURRENT`. The previous repair remains attached. A different cause gets its own boundary. A cured defect is not, by itself, proof that a business metric improved. ## Coded → merged → deployed → verified → cured These are separate claims. A PR, a merge receipt, a deployment receipt and an independent verification receipt answer different questions. A mobile fix requiring a new binary also needs the relevant client distribution; a web deployment is not a substitute. “Merged, awaiting release” is useful public language for the release queue. It is not a new lifecycle enum in this framework. Likewise “park” is an explanation of eligibility and gates, not a `PARKED` state. Use the actual receipt kinds and lifecycle vocabulary above. ## Worked example: no production sample yet The F-17 change is deployed and its regression test passed. The required production observation has not happened. The honest verdict is **INCONCLUSIVE**: neither a pass nor proof of recurrence. 1. **Declare the missing evidence:** a production save-and-refresh observation for the deployed version. 2. **Bound the next check:** a deployment-linked `verificationNotBefore` timestamp records when the observation window can first be evaluated. 3. **Park this wait:** the gate projects as `WAITING_VERIFICATION_DEFERRED` while the window is not executable. F-17 is still open. 4. **Reselect:** unrelated executable B, C and D may proceed. A has not been closed or declared fixed. 5. **Re-evaluate when due:** expiry makes verification executable again. Read fresh evidence. Missing samples remain inconclusive; elapsed time is never a cure. ### When the investigation itself lacks evidence An `EVIDENCE_PENDING` investigation uses an `evidence_plan` receipt. It must name `probeType`, `missingEvidence`, `nextProbe` and a machine-evaluable condition: an absolute `dueAt` timestamp or a positive `targetSampleCount` with a frozen `planBaselineOccurrences`. **Example: 5 new occurrences, not 5 total.** At baseline 12, a target of 5 becomes due at 17 source-reported occurrences, or at the declared due time if that arrives first. Unknown counts do not satisfy the target. The next packet runs the recorded probe; it does not authorize an invented pass or unrestricted code changes. The latest active plan applies. Re-entry only promotes an identity still in the plan’s eligible lifecycle. A prose instruction such as “when traffic returns” is insufficient on its own. General external-event wakeups and automatic backoff for unchanged probes remain roadmap. These limits matter: structured waiting is not an excuse to silently forget an item or promise a wakeup the engine cannot evaluate. ## Autonomous web/mobile testing is part of the cycle The intended system includes autonomous journeys in the same loop: **test the product → collect signals → investigate and fix → verify the relevant release → feed new evidence back**. Web and native mobile are surfaces of that system, not a separate add-on backlog. **Implemented:** project contracts configure truth commands, periodic checks and an independent `verifier.command`. A project can supply its own browser or mobile test tooling through those commands. That is an integration mechanism, not evidence of a built-in runner for every platform. **Roadmap / demo:** a built-in autonomous web/mobile journey runner and the simple on/off switches in the visual tour. They illustrate control of test generation inside the Factory; they do not change an actual project’s configuration. Disabling autonomous test generation does not remove required verification. An unexecuted test is not a pass. Synthetic checks and natural production observations answer different questions; the project must specify which evidence its verification requires. ## Backlog Zero means zero actionable deterministic debt It does not mean deleting every row. Within a declared scope, all executable work has been handled. Some identities may lawfully remain awaiting evidence, external events, cure observation, human decisions or explicit deferral. Their reasons and return conditions must stay visible. The tour’s **0 actionable / 4 waiting / 7 observing** is a fictional explanation of that definition. Current checkpoints distinguish `NO_ACTIONABLE_WORK` and `EVIDENCE_WAIT_ONLY` and expose `remainingGates`. Complete zero-proof reconciliation is still roadmap. An empty source response, missing visibility or a green aggregate counter cannot certify every product problem cured. ## Why receipts outlive the conversation An agent session can end, lose context or be replaced. Its recollection cannot authorize a mutation, establish which version is live or prove a cure. The Factory persists identity-linked receipts, decisions and state so the next session can reconstruct what happened from authoritative records. The append-only lifecycle records the cause, remediation, PR, merge, deployment, verification actor and evidence, outcome and any evidence plan. A new agent reads current repository and release truth alongside that history. A confident message in chat is never a replacement for those records. [Explore the detailed signal register and evidence-plan examples](https://www.orchestro.org/docs/work-lifecycle), [read the real CLI reference](https://www.orchestro.org/docs/tools), or [return to the visual tour](https://www.orchestro.org/factory).