<aside> 🧠
Doctrine reconciliation — August 3, 2026. The nine-step BackOfHouseOS loop below remains the canonical data/governance workflow. OCHO is a separate founder-candidate lifecycle for how TCO products surround recurring real-world activity. They are complementary, not competing replacements.
</aside>
Ingest → Preserve → Index → Extract → Group → Review → Assign Authority → Surface → Recall
This answers: How does messy source become trusted, usable context?
Identity → Context → Preparation → Live State → Evidence → Completion → Memory → Improvement
This answers: How does a TCO product participate in a real-world activity before, during, and after it happens?
A schedule, filename, workflow label, provider state, model inference, or remote instruction may describe reality. It cannot independently authorize consequential action when a higher human or on-site authority exists.
ChurchOS's first real-service pilot showed that the audit layer could reconstruct exactly how the system failed even when command-authority and completion logic were insufficient. That is not a reason to celebrate failure; it is the evidence needed to harden the correct boundary.
A live activity is not complete because a process stopped. A product loop closes when the human truth, device truth, provider truth, recording truth, product state, exceptions, and final artifact are reconciled exactly once.
Models can write, inspect, test, research, and operate bounded lanes. Phil selects canon, assigns authority, recognizes historical intent, and decides whether the product outcome matches reality.
A signed build, bootable package, preserved USB, Seagate archive, exact commit, receipt, and readable handoff are all ways the product survives a machine, model, account, or founder interruption.