PUBLIC DOCS
Start with the lane that matches the work.
The public docs are organized around the same split customers use in production: operator setup, developer integration, key handling, model routing, evidence, and status checks.
Guide map
Where to go first
Use the user guide for product setup, the developer guide for MCP and API connections, and the status page before production workflows.
- User guide: JAWS Flight Deck, Q credits, approvals, and routine operator flow.
- Developer guide: API keys, MCP clients, route checks, and webhook-safe integrations.
- Status: public release evidence, downloads, and read-only availability checks.
Products
How the public pieces connect
JAWS Flight Deck gives teams a native IDE lane. Q provides bounded reasoning. Immaculate governs action, records evidence, and keeps approvals tied to the work.
- JAWS: IDE and cowork lane for developers.
- Q: reasoning gateway used through configured keys and limits.
- LaaS: evidence records for audit, replay, and customer reporting.
Operations
Preflight before launches
Before a public launch, confirm the site, domain, route list, key lane, checkout lane, webhook receiver, and status page all match the product being updated.
- iorch.net updates deploy from the Immaculate dashboard lane.
- aura-genesis.org updates deploy from the Aura guarded site lane.
- qline.site updates deploy only from the current Qline source lane.
Help
When something does not line up
If a page, checkout link, or API key behaves differently across sites, treat that as a route-contract issue. Check the live site profile, then fix the source lane that owns that public surface.
- Do not patch an old source to fix a current product page.
- Do not publish raw local paths, keys, or private run data.
- Record what changed so the next operator can verify the same route.