Choir’s Operator Surface
Choir’s Operator Surface: The Month the System Learned to Prove Itself from a Terminal
Status: published\
Scope: API, CLI, auth, health, and platform observability in June 2026\
Revision reviewed: go-choir main at bff823d7
A browser is not enough control surface for a self-improving computer.
That is one of June’s practical lessons. If Choir is going to run agents, publish news, ingest sources, recover from failures, and verify its own state, then humans and scripts need a way to interrogate it without clicking through the web desktop.
June built that operator surface.
API keys solved the headless access problem
Choir already had browser authentication. But a browser session is not the right primitive for agents, scripts, diagnostics, or overnight verification. June introduced API key authentication with bearer tokens and scoped access through the proxy.
The important pattern is not “there are tokens now.” It is that the proxy remains the trust boundary. Browser cookies and bearer tokens both resolve into authenticated product access, but raw internal services are not exposed as the user interface.
There was also a first-key paradox: if API keys are created through authenticated product paths, how does a headless operator create the first key? June answered with a bootstrap admin key mechanism: a guarded one-time path that seeds an operator key without storing raw secrets.
The choir CLI became an evidence machine
The new CLI in cmd/choir/main.go is small but conceptually important. It can ask Choir for:
- Universal Wire stories;
- Wire diagnostics;
- recent trajectories;
- one trajectory’s obligations;
- Texture reads and history;
- search results.
That turns “I think the product works” into something closer to a reproducible check. A CLI can be run from CI, from a debugging session, from a cron job, or by an agent. It returns JSON. It gives the system a nervous system outside the browser.
Health became part of the product boundary
June also added health endpoints, readiness aggregation, and gateway circuit breakers. This is boring infrastructure in the best sense. Provider failures, upstream latency, and dead services need to become visible states rather than mysterious vibes.
The public health surface is deliberately coarse. It should reveal whether a service is alive, not leak credentials, internal URLs, raw provider responses, or sensitive topology. That distinction—observable but not overexposed—is exactly the kind of boundary an agentic platform needs.
The crash loop was the proof
The month ended with a platform VM crash-loop diagnosis. Universal Wire was not merely “empty.” The system had enough operator surface to distinguish stale feed state, source ingestion, publication gaps, and runtime health.
That is the point of the operator surface: not dashboards for their own sake, but the ability to turn a product symptom into a bounded diagnosis.
The larger claim
Self-improving systems do not become safe by becoming magical. They become safer by becoming inspectable.
The June operator work says: if Choir is a computer that changes itself, then it needs ways to answer:
- Who is asking?
- What are they allowed to see or mutate?
- Which service owns this state?
- Is the dependency alive?
- Which trajectory is blocked?
- Which Texture revision is current?
- What did the publication feed actually serve?
A browser can present the answer. A CLI can prove it.