Guide

Package guide is a step-by-step checklist that gets your business running on AI.

guide

GET /v1/guide/actions

Returns the caller org's Business AI action ledger, most recent first: every "do it for me" tool call, the arguments it ran with, its result and whether it succeeded. It is the audit-visible record of what the agent did on the org's behalf, and the backing state for the "acted" auto-detect signal.

GET /v1/guide/analytics

Analytics returns the caller org's funnel from the analytics lens plus the GTM recommendations derived from it. It is the Business AI's data-grounded read — what the funnel is doing, and the next-best action to move its weakest stage. An unreachable or silent warehouse answers available=false, never a fabricated number.

PATCH /v1/guide/blueprint/{collection}/{id}

Edit — or retire — one item of the brand blueprint

Edits a single item of the brand blueprint by id and saves it as a NEW VERSION, answering the whole blueprint after the edit. collection is one of sections, steps, strategies or templates; anything else is 400, and an id that collection does not hold is 404. This is also the retire lever: {"enabled": false} takes an item out of every org's journey without deleting it or its history.

SuperAdmin ONLY, like the rest of the authoring plane; a per-org admin is 403. The write is audited.

The patch is a SHALLOW merge over the item's own top-level keys — a key you send replaces that key whole, a key you omit is left alone — and id is dropped from the patch before it is applied, so an edit can never rekey an item. That is why the body has no declarable shape: its keys are the patched item's, not this route's.

Fail-closed on the WHOLE document, not just the item: the blueprint is re-validated after the merge, so a patch that would dangle a dependency, break the step DAG or empty the journey is 422 and nothing is saved. An empty patch is 400 and one over 16 MiB is 413.

GET /v1/guide/blueprint/versions

Returns the brand blueprint's version history — every stored version's number and edit time, newest first — which is the point-in-time-recovery and audit trail behind the authoring plane. Metadata only: the documents are not returned. SuperAdmin only, like the rest of this plane. The history is listable even when the current stored document no longer parses, so a schema-drifted row can still be diagnosed.

GET /v1/guide/blueprint

Returns the FULL authored brand blueprint — every principle, section, step, strategy and template WITH its enabled flag made explicit, including the disabled items the org-facing reads never see — plus the active version number, the brand key it is stored under and the item counts. It is the SuperAdmin authoring view of the platform blueprint, so it is refused 403 for anyone else, including a per-org admin: the brand blueprint is shared platform content, not a per-customer surface.

PUT /v1/guide/blueprint

Publish a new version of the brand blueprint

Replaces the deployment's brand blueprint — the shared journey, sections, strategies and templates every org starts from — as a NEW VERSION, and answers the stored document with its key and version number. The previous versions are kept, so /blueprint/versions is a real recovery trail.

SuperAdmin ONLY. A per-org admin is 403: this is platform content, not a per-customer surface — the per-customer surface is /v1/guide/curriculum. The write is audited.

The body is a blueprint document accepted as YAML or JSON, which is the caller-visible reason it takes a raw body. It must parse AND validate — unique ids throughout, an acyclic step graph with no dangling dependencies, every step's section and every strategy's principle resolving to a real one — or it is 422 and never becomes active, leaving the version already serving authoritative. An empty body is 400 and one over 16 MiB is 413.

Edits are live: the next resolve reads the newest version. A stored document that is itself corrupt or schema-drifted does not block this write — the target is resolved without parsing what is there — so a bad version can always be published over.

POST /v1/guide/chat

Chat answers a founder's question about their launch journey as the Business AI coach: it grounds the reply in the org's REAL progress, its ranked available quests and its analytics funnel, and returns those candidate quests alongside so the caller can act on one. READ-ONLY — it advises and never runs a step, so it cannot be talked into performing an action; the only executing path is POST /v1/guide/steps/{id}/do. One AI completion per call, billed to the caller's own payer.

Request body — application/json (required)

GET /v1/guide/curriculum

Returns the journey the caller's org is actually running, and whether it comes from the org's OWN override (custom) or from the platform default — the brand blueprint, else the embedded fixture.

PUT /v1/guide/curriculum

Replace your org's journey with a curriculum you author

Sets the caller org's OWN curriculum — the per-customer override — and answers the journey now in force with custom: true. The body is a curriculum document, and it is accepted as YAML or JSON: that is the caller-visible reason this takes a raw body rather than a declared shape. Whatever the syntax, the CANONICAL parsed form is what is stored, so the document the engine runs never depends on how it was written.

Fail-closed: a body that does not parse, or parses but is not a valid journey (unique step ids, no dangling or cyclic dependencies), is 422 and NEVER becomes active — the org keeps the journey it had. Requires a validated org; 403 without one. An empty body is 400 and one over 256 KiB is 413.

This is tier one only. It overrides nothing but this org's own journey; the shared brand blueprint is a different surface with a different gate. DELETE the same path to drop the override and fall back to it.

DELETE /v1/guide/curriculum

Clears the caller org's curriculum override and returns the journey it falls back to — the brand blueprint, else the embedded fixture. Clearing an org that never set one is a no-op that answers the same default.

GET /v1/guide/profile

Profile returns the caller org's OBSERVED growth profile — the signal set, the classified growth stage, and the org's own key metrics. It is a pure READ, recomputed from the org's CURRENT state each request (real-time by pull): it reuses the reconcile path (snapshotFor runs the detectors) for launch progress and runs the growth probes (observe) for the signals — it never caches, never runs a billable effect, never targets another org. Org-scoped on the validated principal; fail-closed without one. It PRODUCES the profile and classifies the stage; it decides NO recommendation (that is a later surface).

POST /v1/guide/steps/{id}/do

Have the Business AI actually do the step for you

Executes one step of the caller org's journey through that principal's OWN tool plane and answers the action log — {step, events, state} — so the caller sees every tool call the agent made and where the step ended up. This is the ONE executing path in guide: suggest and chat advise, this acts, and the work is charged to the calling principal's ledger.

Ask for it live and the same actions arrive as Server-Sent Events instead, on either of two triggers — Accept: text/event-stream or ?stream=1. The stream opens with a comment, emits one frame per action as it happens, and closes with an end frame carrying ok and the final state. The streamed run is detached and bounded at 120 seconds, so it finishes on its own clock once the response has begun.

An agent that FAILS is not a failed request: the JSON answer still comes back 200 with error beside the events it did manage, and the stream still ends with ok:false. The refusals are the ones before the agent runs — 409 with {error, step, blockedBy} for a step whose dependencies are unfinished, 404 for an id the journey does not contain, 403 without a validated org.

POST /v1/guide/steps/{id}/done

Mark a step of your org's journey finished

Moves one step of the caller org's journey to done and answers the whole refreshed journey, which is what unblocks everything downstream of it.

Dependency-GATED like start: finishing a step whose prerequisites are themselves unfinished is 409 carrying {error, step, blockedBy} naming what is in the way, not a silent success. A step id the org's active journey does not contain is 404. Skipping is the ungated alternative — a founder declaring a step does not apply — and it lives at /skip.

Requires a validated org; 403 without one. The mark is recorded as manual, and /reset returns the step to todo.

POST /v1/guide/steps/{id}/reset

Returns one step of the caller org's journey to todo — clearing a manual mark or a skip — and returns the refreshed journey. Reset is never dependency-gated. Auto-detect runs on the next read, so a step the org has in fact completed elsewhere goes straight back to done.

POST /v1/guide/steps/{id}/skip

Marks one step of the caller org's journey skipped and returns the refreshed journey. Skipping is never dependency-gated — the founder is declaring the step does not apply to them — so a step whose dependencies are unfinished can still be skipped, and a skipped step counts as terminal for everything downstream of it.

POST /v1/guide/steps/{id}/start

Mark a step of your org's journey started

Moves one step of the caller org's journey to in-progress and answers the whole refreshed journey, so a console needs no second read.

The transition is dependency-GATED, and that is why the answer set is wider than a success: a step whose prerequisites are unfinished is 409 carrying {error, step, blockedBy}, where blockedBy names the exact steps in the way — enough to render the blockage rather than merely report it. A step id the org's active journey does not contain is 404.

Requires a validated org; 403 without one, and the journey read and written is that org's alone. The mark is recorded as manual, and the journey is reconciled against the auto-detectors on every read, so a step the org has demonstrably completed elsewhere can still be moved to done underneath it.

GET /v1/guide/strategies

Strategies returns the ENABLED tactics corpus for the caller's org: the tactics library narrowed by the explicit category/workload filters AND by the org's OBSERVED growth stage and capability signals (a tactic's tags are preconditions, so it surfaces only once the org can act on it). Passing stage PREVIEWS the corpus at that stage instead of the observed one. The content is shared platform data — no org's records — and the read is never a billable effect.

GET /v1/guide/suggest

Suggest returns the caller org's next-best quests: the available, non-terminal steps of its journey ranked by how much downstream work each unblocks, each with the grounded reason it is a good next move and whether the Business AI can run it, plus the org's funnel and the GTM recommendations derived from it. A best-effort AI narrative over exactly those quests and numbers is included when an AI plane is wired. READ-ONLY: it advises and never runs a step — the only executing path is POST /v1/guide/steps/{id}/do.

GET /v1/guide

Overview returns the caller org's launch journey: the active curriculum's version and title, every step with its state, whether it is available, what blocks it and whether the Business AI can run it, the done/total/percent progress with the next step to take, and the org's analytics funnel folded in. Auto-detect runs first, so a step the org has already completed elsewhere reads done without anyone marking it.

---

All Hanzo APIs · Interactive reference