Anatomy of a config

A config fits in one YAML file. This guide walks through it in the order of the target version; what does not exist yet today says so, and points to the target.

station:                   # STATION — who it is
  id: teranga
  name: Teranga Kitchen
  identity: {...}           # AUTH — the providers that prove data (a code)
global: {...}               #   its language, its currency
domain: {...}

apis:      [...]            # SOURCES — what the tenant exposes
catalog:   {...}            #   where catalogue search comes from

                            # CONTEXT — rooms and sessions: the platform holds them

submit_guard: {...}         # POLICIES — the guards; the station's submit guard

skills:    [...]            # CAPABILITIES — what the agent sees: what can be offered, chosen, executed
playbooks: [...]            #   the journeys

agent:                      # AGENT — its voice, its model
  portals:
    web: {...}              #   the tenant's site: the widget, its theme, its copy
mcp: {...}

Behaviour is set mostly in sources, policies and capabilities. If a station misbehaves, look there first; then in agent, which changes what the model reads.

The plan of the guide

	page	what you set there today
1	Anatomy	the shape of the file
2	Station	station.id, station.name, domain, the language, the currency
3	Sources	apis, catalog
4	Context	what the platform holds: rooms, sessions, selection, conversation thread
5	Auth	identifies: true: typed data identifies the room; station.identity.providers: a code proves it
6	Policies	the select guards (form, require, check, update) and their conditions, the submit guard, where values come from, how long everything is kept
7	Capabilities	skills, playbooks, the submit
8	Agent & portals	agent, agent.portals.web, mcp
9	Verify and publish	what Core says at load time, the tests

Two rules that apply to the whole file

• Every key is read. A key Core does not know is refused at load time, with its path (agent.portals.web.widget.theme.primary_colour): it would suggest it has an effect. A typo is therefore caught, in a file as through the provisioner's API.
• Every reference is checked at load time. A submit call that names an operation missing from apis, a task that names an unknown skill, a condition that reads an undeclared field: the station refuses to start, with a message that says where and what to fix. See Verify and publish.

The writing order

Each layer only cites the one below it. So you write from the bottom up:

1. apis — what the tenant exposes;
2. skills — on those operations;
3. playbooks — on those skills;
4. submit_guard — what is required before executing.