- Developer preview launch. The hub opens with four surfaces: home with a five-minute quickstart, the execution-chain docs, a six-recipe mission-spec library, and this changelog.
- Execution-chain documentation. The eight stages — contracts → tenant boundary → verified identity → deterministic policy and authorization → governed Action transaction → durable workflow → connector or model execution → evidence and outcome — documented from the platform's actual architecture.
- Mission-spec format v1 draft published. Badged as a draft and explicitly marked evolving; field table plus one illustrative example.
- Recipe library seeded. Six copy-paste mission specs (stale quote follow-up, invoice reconciliation, deployment health check, approval-inbox digest, contract renewal reminder, weekly metrics report), each clearly marked illustrative.
- Honesty guardrails. No public SDK, endpoints, or client libraries are documented because none are public yet. When they ship, they'll appear here first — with version numbers.
Versioned from day one
These docs ship alongside the platform and change only when the platform does. Every entry below describes something that exists in the developer preview — nothing aspirational, nothing vapor.
Where the hub goes next
The roadmap below is the plan for these docs, sequenced against the platform's own milestones. Items move from planned to shipped only when the underlying capability exists and is verified.
Now — developer preview
Docs track the real product. The mission-spec format stays in draft until the platform's first stable spec release. Any field that changes gets a changelog entry here with the version it changed in.
Next
Mission-spec format v1 stable. Once the platform locks the spec, the draft badge comes off, the field table becomes normative, and recipes are re-verified against the stable format.
Planned: recipe verification pass — every recipe re-checked against the stable spec, with a "verified against v1 stable" stamp.
Later
Public SDK and API reference. When a public SDK or API ships, this hub gains a real reference section: verified method names, verified endpoints, verified code samples. Nothing appears here before it exists.
Planned: connector catalog (what each connector can do and which policy rule sets govern it), error and retry semantics for durable workflows, and an evidence-timeline data dictionary.
This hub documents only what verifiably exists. If a page promises a capability, that capability has shipped. If it hasn't shipped, it's on this roadmap — labeled planned, never presented as done.