9b. Agent onboarding — org rules served at connect time#

Give every connecting agent your organization's rules and security practices before it does anything — deterministically, not hoping it searches for them:

1. Tag a concept onboarding (an ordinary tag on an ordinary concept — no new place to maintain content).
2. Promote it — a human promotion to authoritative is what makes it eligible (§4a). This is the whole trust gate: only human-verified, authoritative concepts are ever served.

Qualifying concepts are compiled into a compact digest that reaches agents three ways:

• Automatically at MCP connect: the digest rides in the instructions field of the MCP initialize response — your agent has the org rules from its very first exchange.
• get_onboarding (MCP tool): re-fetches the same digest, for clients that don't surface initialize instructions.
• GET /v1/onboarding (REST twin): the same digest over plain HTTP with any workspace token.

The digest is fenced to what the calling token can see (like every other retrieval surface), and budget-capped to stay context-window-polite — long bodies are truncated with a pointer to read_concept, and overflow concepts land in a pointer list rather than being silently dropped. A concept past its re-verification date (§4b) is never injected — it drops to the pointer list marked "(needs re-verification)".

Why human-verified only: rules served as gospel at connect time must have been vouched for by a person. Even a trusted-author write (§9's author_concept) lands authoritative without a human verification record — so it never reaches the digest until a human re-promotes it. Machine verification records don't count either. Generated is never the same thing as verified.