Infrastructure should explain its recovery model

What we build

Orch8 explores a straightforward model for durable workflow execution: accepted progress is stored at explicit boundaries, workers use ordinary HTTP contracts, and recovery decisions remain visible to operators. The project is designed for teams that need to coordinate background work, retries, timers, approvals, or external workers without hiding the state that makes recovery possible.

Durability is not a promise that every external API executes exactly once. Payments, email providers, AI tools, and other remote systems keep their own truth. Orch8 documentation therefore separates internal state guarantees from idempotency, reconciliation, and compensation at the provider boundary.

What we publish

The product documentation describes current behavior, configuration, APIs, failure modes, and operational controls. Field guides explain broader reliability problems and place concise answers next to their supporting sources. Comparison pages state their criteria and direct readers to each product's own documentation where possible.

Technical articles are maintained as part of the website repository. They identify publication and modification dates, link to relevant Orch8 documentation, distinguish practical guidance from product guarantees, and include source links for claims that readers should verify independently. Community discussions may reveal recurring problems, but they are treated as problem signals rather than proof of a technical fact.

How we verify changes

Website and documentation changes pass automated builds, internal-link checks, documentation checks, and structured content checks before publication. Product behavior should also be tested at failure boundaries: worker termination, lease expiry, duplicate delivery, ambiguous external responses, state-version changes, and restore from backup. Examples are educational starting points, not a substitute for testing with each team's infrastructure and providers.

When a claim changes, the page should update its modification date and supporting references. Corrections are preferred over preserving outdated marketing language. Security-sensitive reports are routed through the security contact published in the site metadata; general documentation corrections can be sent to hello@orch8.io.

How to verify us

• Inspect the public repositories, commit history, and releases on GitHub.
• Run the documented quick start in an isolated environment.
• Compare an article's claims with its linked primary documentation.
• Test worker death, lease loss, retries, restore, and upgrades before trusting production state.
• Report inaccurate claims to hello@orch8.io so the page can be corrected.

Authorship and limitations

Pages credited to “Orch8 Engineering” are organizational work maintained through the project repository. We do not invent personal bylines or reviewer credentials. Named contributors will appear only with their consent and a verifiable role.

Orch8 is evolving software. Documentation can contain mistakes, examples may omit production concerns, and compatibility can change between releases. Verify the version you deploy, preserve rollback and restore paths, and make business-specific safety decisions with the people who own the affected systems.