156 — The Writer Never Operates EstatePublisher

Governance chapter: 156. The writer expresses semantic intention; the authoring surface selects an admitted operation, EstatePublisher executes it, and FountainStore proves what happened. The writer never operates EstatePublisher. The writer operates meaning.

The authoring surface is semantic

A writer should not need to understand how a publication operation is implemented in order to use it. “Publish this chapter”, “preview this edition”, “make this revision current”, and “compare this draft with the published version” are intentions, not infrastructure instructions.

The authoring surface therefore must not require command-line arguments, service topology, remote hosts, deployment directories, transport protocols, Store leases, capability identifiers, internal receipts, MIDI2 details, process supervision, DNS mutation, or HTTP implementation details. Those mechanisms remain necessary, but they belong below the semantic boundary.

EstatePublisher is an execution boundary

Chapter 155 made the native capability surface addressable. Chapter 156 makes the consequence writer-facing:

semantic intention → admitted operation → EstatePublisher
→ native capability → execution → durable receipt

EstatePublisher may expose REST, CLI, MIDI2, native Swift, or other projections. Those are implementation surfaces. They must preserve the same semantic identity of the operation; changing the projection must not change its meaning.

The writer does not select mechanisms

When the writer says “Publish this chapter to Governance”, the system resolves the intention against the currently admitted operation surface, constructs the typed request, executes it through EstatePublisher, observes the receipt, and returns a writer-readable result. The writer remains at the first and last stages.

The authoring agent may interpret intention, inspect the live matrix and operation inventory, collect parameters, select among valid operations, submit a typed request, and explain the receipt. It must not invent shell commands, bypass unavailable scenarios, silently substitute another operation, or infer authority from filesystem access.

Natural language does not grant authority

A writer may ask for anything. That does not imply that every requested operation exists, is safe, is admitted, or is currently possible. Understanding an action is not equivalent to possessing authority to perform it.

If no admitted implementation exists, the system must say so. “I understand what you want. The system cannot currently perform it” is a trustworthy result. An unavailable capability is a visible blocker, never an invitation to improvise a workaround.

The matrix describes reality

The scenario matrix is the system’s executable vocabulary, not merely documentation. A row records what the system understands, how it can execute the intention, what inputs it requires, and how it can prove what happened. implemented, admitted, proven, and unavailable remain distinct.

The authoring surface stays simple because the matrix and the native operation inventory remain truthful. It does not become simpler by hiding unresolved state.

The writer’s vocabulary can remain small

A useful writing environment may expose a small vocabulary with deep consequences: write, revise, compare, preview, publish, release, withdraw, restore, place, connect, perform, and listen.

The writer should acquire fluency in the instrument without acquiring fluency in its deployment architecture. The semantic object and its executable environment remain connected until the intention has acquired an observable public consequence.

Semantic operations are not UI buttons

This chapter does not prescribe a graphical interface. The semantic surface may be prose conversation, editor commands, keyboard actions, menus, gestures, MIDI2 instruments, scriptable operations, scenario documents, or local-model interaction.

The important property is semantic stability. Whether the writer speaks, selects, or invokes an operation, the same governed identity must be resolved.

Receipts return as meaning

Infrastructure may produce identifiers, timings, target hosts, revisions, hashes, capability references, and execution evidence. Those records remain available for governance and diagnosis, but they need not become the normal writer-facing response.

The authoring surface translates evidence back into the language of the work while preserving the underlying receipt for inspection. The complete path is therefore:

meaning → typed operation → execution → evidence → meaning

The estate becomes an instrument

An estate governed in this way is not merely a collection of deployed services. Its available actions are explicit. The writer can discover what the instrument can do; the authoring agent can reason over those capabilities; EstatePublisher can execute them; FountainStore can prove what happened; and the public estate can reflect the result.

Governance requirement

Writer-facing Fountain systems shall expose semantic intentions rather than EstatePublisher mechanisms. EstatePublisher projections remain available for implementation, inspection, automation, and administration.

Where a semantic intention cannot be resolved to an admitted operation, the system must preserve that unresolved state. No authoring convenience justifies invented authority. No conversational fluency justifies invented infrastructure.

Governing sentence

The writer never operates EstatePublisher. The writer operates meaning.