Functional Specs

These are the natural-language functional specifications for Spectral’s operator and customer surfaces. They are authored as plain-language scenarios, generated into executable Playwright tests, and run deterministically against a locally-booted stack with recorded LLM responses replayed at the model transport — so the suite proves real end-to-end behavior without a live model. The spec text here is the source of truth; the executable tests are generated from it.

Operations cockpit

• Action Authoring — A world’s action set is the list of routing keys the customer’s agent names on POST /decide and discovers via GET /actions (ADR-089/104).
• Action Inputs — An action’s inputs are the canonical values the customer’s agent sends on POST /decide for that routing key — its ontology.
• Auth Gating — The operator cockpit is gated to Spectral staff with the operations organization role.
• Authoring Loop — The conversational authoring loop is the primary alpha flow: the operator chats with the Assistant on its dedicated page, shares source material via the sing…
• Candidate Review — The review queue is where the operator dispositions proposed rules outside the chat.
• Feedback Evolution — The Feedback & evolution surface is the fifth workspace tab inside a ruleset.
• Llm Config — The operator configures the platform-default World-Agent LLM from the cockpit’s LLM config surface: a global, non-ruleset setting that selects the provid…
• Navigation IA — The cockpit’s information architecture is a persistent navigation shell: a left rail on every operator surface (brand, command-palette button, global nav wit…
• Publish Deploy — Once rules are approved, the operator publishes a new ruleset version.
• States — Every operator surface should communicate its loading, empty, and error states rather than rendering a blank or broken page.
• Verify Remediation — When the operator runs verify-at-review on a proposed rule (“Generate & run checks”), the rule’s deterministic logic is generated and its checks run.
• World Model Card — The Ruleset Card is the version-addressed, read-only artifact that presents a published version’s content for inspection/audit.
• Worlds Crud — Rulesets are the top-level container an operator authors against (the UI says “ruleset”; the route + wire stay /worlds / world_id).

Customer dashboard

• Auth Gating — The customer dashboard is gated to authenticated customer-org members.
• Coldstart Empty — The onboarding flow’s two cold-start empty states render cleanly, never as errors:
• Dashboard Reads — The customer dashboard presents the deployed world model and its decisions.
• Decide Round Trip — POST /decide is the customer decision surface — the executable payoff of the whole loop.
• Domain Create — On the onboarding first-workspace step, the customer names a workspace and chooses a published world from the picker, then creates the workspace (`POST /orgs…
• Org Llm Config — An org admin configures their organization’s bring-your-own World-Agent LLM from the dashboard’s Organization model surface: an org-level (not domain…
• Portfolio — The All-workspaces portfolio is the customer’s landing at / when no domain is selected (gate semantics: memberships-without-a-selection land here, never fo…
• Signup — A brand-new customer (an authenticated GoTrue user with no organization yet) reaches the signup/onboarding surface at /auth/onboard — NOT the forbidden scr…
• States — Each customer dashboard read should communicate its loading, empty, and error states rather than rendering blank or broken.
• World Model Card — The Ruleset Card (design 03 surface F) is the version-scoped methodology disclosure of the ruleset governing a domain — the per-version, immutable record o…