Status Current

Path standing-notes/loomworks-standing-note-companion-as-operator-system-interface-v0_1.html

Standing note — Companion as Operator-system-interface — v0.1

Version 0.1
Date 2026-06-09
Status Standing note. Elevates a principle named in the architecture specification §08 to a first-class, durably-recorded commitment: the Companion is the primary surface for all Operator-system interaction — preferences, configuration, policy — not only the conversational work of an engagement. The manifest flagged this as a candidate standing note, not yet written; this is it. Operator-facing. HTML primary, Markdown source alongside.
Author posture Discovery — the principle, its first proof instance, its extension pattern, and its boundary are recorded; where the boundary corrects a tempting over-reading (that the Companion replaces every control), the correction is named.
Relates to The Phase 60 implementation notes v0.1 (the first instance, tune_setting); architecture specification §08 (where the principle is named and where it "shapes Phase 61+"); the Companion functional specification v0.1 (the optional-access-layer framing that bounds this principle).

Plain-language summary

There are two ways to think about what the Companion is for. The narrow way: the Companion helps you do the work inside an engagement — contribute, organize, produce. The broader way, and the one this note commits to: the Companion is how you interact with the system itself — not just the work, but the settings, the preferences, the configuration, the policies. The conversation is the interface.

Phase 60 proved this with a small first instance: you can change three settings by asking the Companion ("make the wait time shorter," "show oldest first") instead of hunting through a settings screen. The principle is bigger than three settings — it says that, over time, the things that historically lived in settings UIs become things you can simply ask for. The Companion is the front door to the system, not just to the work.

There is a boundary, and it matters: the Companion being the primary interface does not make it the only one, and it never lets the Companion do anything the system itself wouldn't allow. A setting you can change by asking is also a setting you can change by a direct control, and both are recorded the same way. The Companion makes the system pleasant to operate; it does not become the system.

1. The principle

The Companion is the primary surface for all Operator-system interaction — not only conversational work within an engagement. This includes preferences, configuration, policy adjustments, and other Operator-system concerns that have historically lived in settings screens. Where an Operator would once have navigated to a control, the principle says they can instead ask the Companion, and the Companion makes the change, confirms it, and the surface reflects it.

This generalizes the Companion's role. The narrow framing — the Companion as the assistant inside the work — undersells it. The Companion is the Operator's interface to Loomworks as a whole: the work, and the system the work runs on.

2. The first instance — `tune_setting` (Phase 60)

The principle was first shipped, not merely asserted. Phase 60's tune_setting lets the Operator adjust three settings by conversation — the voice-listening blur, the voice-listening wait time, and the conversation message order — instead of through a settings UI. The Operator says what they want in plain terms ("shorter wait," "oldest first"), the Companion resolves it, writes it, and names the new value back so the change is trustworthy. The implementation notes v0.1 record the full build.

Three settings is deliberately small. Phase 60 proved the pattern — that a setting can move from a screen to a sentence — rather than moving everything at once. The value of the first instance is that it establishes the path; the principle is what says the path generalizes.

3. The extension pattern — why this generalizes cheaply

The principle is credible because instantiating it is cheap. Adding a new setting to the conversational surface is a single, well-defined change: the labels that name it in conversation, its definition (type, default, bounds), and how the surface reflects it. There is no per-setting feature to build — there is one branch to add. That is what makes "the Companion is the primary surface for system interaction" a buildable commitment rather than an aspiration: each new piece of system-interaction-by-conversation costs about one branch, so the surface grows as the work warrants.

4. The boundary — primary, not sole; pleasant, not sovereign

Two limits keep this principle from over-reaching, and both follow from the Companion's nature as an optional access layer (Companion functional specification v0.1):

Primary, not sole. The Companion being the primary interface does not make it the only one. A setting changeable by conversation (tune_setting) is also changeable by a direct control (the direct settings affordance), and both paths are audited identically — the record of what changed and when is complete regardless of which path made the change. The Operator who prefers a control still has one. The principle is that conversation is available and primary as a way to operate the system, not that other ways are removed.

Pleasant, not sovereign. The Companion never does anything through this interface that the raw Engine API would not permit any caller to do. Tuning a setting goes through the same validated, clamped, bounded write the direct path uses; the Companion adds the conversational route, not new authority. This is the founding axiom holding at the system-interface surface: the Companion makes the system pleasant to operate; it does not become the system or gain reach the API withholds.

These two limits are why the principle is safe to generalize. It does not centralize control in the Companion (other paths remain); it does not grant the Companion power (it rides the same API any caller does).

5. What it commits future work to

The architecture specification §08 says this principle "shapes Phase 61+." Concretely, the commitment is:

New Operator-system-interaction surfaces should consider conversation as a first-class path, not default to a settings screen. The question for a new preference or policy control becomes "what does the Operator say to change this?" alongside "what does the control look like?"
Where a setting moves into conversation, it follows the established pattern (one branch), preserves the dual path (conversation and a direct control), audits both, and names the value back on change.
The principle does not require every control to be conversational — it requires conversation to be a considered, available path, growing as the work warrants. Judgment about which controls benefit from conversational access stays with the Operator and the build.

6. Disposition

The principle is committed, not merely named: the Companion is the primary surface for Operator-system interaction, proven by Phase 60's tune_setting, generalizing by the single-branch extension pattern, bounded by primary-not-sole and pleasant-not-sovereign.
The first instance is recorded in the Phase 60 implementation notes v0.1 (including the one interim shape — the non-conversation-intent gate — which does not affect the principle).
Future work inherits it per §5, as the architecture specification §08 already signals.