Scenario Playbook

Use this playbook when you understand the basic words and want realistic examples. Each scenario names the goal, the safe order, and the checks that prove the setup is healthy.

The examples are not scripts to copy exactly. Use the structure and choose names that fit your own workspace.

Scenario Index

Try a public hub

A first-time reader creates a narrow connection for a listed hub.

Create a private support hub

A workspace creates one owned hub, one connection, and narrow access rules.

Review team access

A reviewer splits broad access into readable access-rule sets.

Fix a stale client

A support contact traces Dashboard, Clients, Access rules, and Topology.

Change runtime for one hub

A builder creates a separate skill set before changing shared defaults.

Provision a hub from code

A developer creates a runtime group and a hub with an API token instead of the dashboard.

Scenario 1: Try a Public Hub

Goal: explore a public hub without creating an owned hub.

This public hub scenario is the shortest path to a first reply, because no owned hub is involved.

1. Open Public hubs and choose a listing with clear audience guidance.
2. Create one connection named for the app, device, or experiment.
3. Use narrow access rules that match the first task.
4. Use the setup link and keep setup material private.
5. Check Dashboard for the client count and any attention item.

Healthy result: one client exists for one public hub, and the access rule name explains why access exists.

Scenario 2: Create a Private Support Hub

Goal: create a workspace-owned hub for a support front desk.

Item	Example name	Why it helps
Hub	support-frontdesk	Names the destination and purpose.
Client	frontdesk-client	Names what connects.
Access rules	frontdesk-questions-only	Shows narrow access before anyone opens the rule.
Runtime choice	workspace default	Keeps the first setup small.

Check Billing first if the hub, connection, paid Skill Store entry, or address action is locked. Then create the hub, create the connection, add access rules, and verify Dashboard.

Healthy result: Dashboard shows the expected hub and client, and Topology shows the client when live status is available.

Scenario 3: Review Team Access

Goal: make access readable before more connections are added.

Start by finding access-rule sets with vague names like default, full, or temporary. Then split them by purpose.

Instead of	Create
One broad default set	frontdesk-questions-only
One shared service set	skill-status-read
One temporary broad set	temporary-review-window with an end date in the notes

Healthy result: each access-rule set can be reviewed without opening unrelated clients.

Scenario 4: Fix a Stale Client

Goal: understand why frontdesk-client is stale in Topology.

Check order

1. Open Dashboard and note the attention item.
2. Open Clients and confirm the client is active and attached to support-frontdesk.
3. Confirm the setup link or connection file is still private and placed with the connecting app.
4. Open Access rules and confirm the client is linked to the hub.
5. Open Topology and compare stale, missing, warning, and connected states.

Likely cause

1. Missing from Clients usually means the client was not created or was removed.
2. Present but offline usually means setup material or the running app needs attention.
3. Present but blocked usually means Access rules need review.
4. Visible in Dashboard but stale in Topology usually means the latest live update has not arrived.

Healthy result: the symptom points to one owner page instead of a guess.

Scenario 5: Change Runtime for One Hub

Goal: change language or location for one hub without changing every hub that uses the default skills.

1. Create or choose a separate skill set for the affected hub.
2. Assign only the intended hub to that skill set.
3. Open Runtime config for that skill set.
4. Change language, location, speech, or blocked skills only where needed.
5. Check Dashboard and Topology before moving more hubs to the same skill set.

Healthy result: only the intended hub uses the changed runtime defaults.

Scenario 6: Explain a Locked Button

Goal: decide whether a locked action is a plan question or a setup question.

Start with Billing. Read the plan card, current usage, and the message beside the locked action. Common locked actions include creating another hub, adding another connection, using a paid Skill Store entry, setting a hub address, or using a help option that belongs to another plan.

Healthy result: the reader knows whether to change the plan, reduce usage, or return to the original page and continue setup.

Scenario 7: Provision a Hub From Code

Goal: create a runtime group and a hub from a script instead of the dashboard.

1. Mint an API token with the hub write scope on the API Tokens page.
2. Browse the skill catalog first. Reading the catalog works on any plan, so you can decide what the hub should run before upgrading.
3. Create the runtime group, then create the hub attached to it.
4. Install one skill into the runtime group and release both onto a channel.
5. Check Dashboard for the new hub, then connect one client to it.

Healthy result: the hub appears in the dashboard exactly as a hub created by hand, and the script can repeat safely because hub creation accepts an idempotency key.

See Provision Hubs for the calls, the scope and plan rules, and the error table.

Make Your Own Scenario

Use this pattern:

1. Name the goal. Keep it short and specific.
2. Name the hub. The hub name should explain the destination.
3. Name the connection. The connection name should explain what connects.
4. Name access rules by purpose. The name should make review faster.
5. Choose the first health check. Dashboard first, then Topology when live state matters.

Build the first setup