Plural Embodiment, Singular Authority

Plural Embodiment, Singular Authority is the discipline of allowing a system to appear through many optimized surfaces while requiring every durable governed mutation to resolve to exactly one accountable authority locus.

Its central rule is:

Many embodiments may present, inspect, or assist.
One declared authority locus must own each governed mutation.

The pattern applies when a system has multiple valid ways of being present:

• Windows CLI and WSL CLI;
• local clone and cloud worker;
• operator console and agent terminal;
• daemon, web UI, script, and chat interface;
• cache, projection, replica, and source substrate.

Plural embodiment is not a defect. It is often necessary for ergonomic operation. The defect appears when plurality becomes implicit authority: whichever surface happens to receive the command mutates durable state.

1. Positioning

This concept emerged from a Narada operation in which Windows-optimized and WSL-optimized invocation paths could both plausibly operate on Narada proper, while different repo clones had different freshness and command surfaces.

The local problem was:

Windows caller
WSL caller
D:\code\narada clone
/home/andrey/src/narada clone
canonical inbox state

The higher-level problem was not path selection. It was authority routing.

The system should support many front doors, but state mutation should not depend on the door through which the operator entered.

Related concepts:

• Constructively Invariant Progressive De-Arbitrarization: chooses the next structure while preserving future transformation potential.
• Authority-Revealing Inversion: reveals when a clone, CLI, UI, or folder is only an embodiment of a deeper authority structure.
• Governed Crossing: describes the authority-mediated crossing that must happen when an intent enters through one embodiment but belongs to another mutation locus.
• Inhabited Evolution: supplies the operational pressure that earns the distinction.
• Intelligence-Authority Separation: separates fallible judgment from governed consequence.
• Constructive Universalization by Re-instantiation: requires the originating case to run through the lifted form.

Plural Embodiment, Singular Authority specializes structural differentiation to the case where several system embodiments can act near the same state.

2. Core Type

Given a governed system S, a set of embodiments E, a set of durable mutation targets M, and an authority-routing policy R, the pattern has the shape:

PESA : (S, E, M, R) -> (S', A, T) | B

Where:

The key invariant is:

for each governed mutation m:
  count(authority_locus(R, m)) = 1

Multiple embodiments may request or carry the operation. Only one authority locus admits the mutation.

3. Embodiment Versus Authority

An embodiment is a way the system becomes operationally present.

Examples:

• a Windows shell command;
• a WSL shell command;
• a Codex session;
• a Kimi session;
• a browser console;
• a daemon worker;
• a checked-out repo clone;
• a generated projection;
• a local cache.

An authority locus is the place where a state transition is admitted as durable.

Examples:

• the canonical task lifecycle database;
• the canonical inbox database and envelope export directory;
• the declared state-bearing repo clone;
• the governed Site registry;
• the authoritative event log;
• a configured effect worker queue.

The same physical component may host both embodiment and authority, but the functions must remain distinct. A clone can be an ergonomic working copy without being mutation authority. A web UI can request a change without owning durable truth. An agent can formulate a command without becoming the authority locus for its effect.

4. Routing Rule

A mutating command should pass through the following sequence:

caller embodiment
-> classify command authority class
-> resolve configured authority locus
-> check current embodiment against authority locus
-> forward, refuse, or execute locally
-> read back durable result
-> emit audit evidence

The command is admissible only if the authority locus is explicit before the mutation occurs.

If the current embodiment is not the authority locus, it may:

1. forward the command to the authority locus;
2. refuse with a precise routing explanation;
3. run in dry-run or inspection mode only.

It must not silently mutate local state merely because local execution is technically possible.

5. Read, Write, And Projection

Plural embodiment is easiest to make safe when command surfaces distinguish at least three modes.

Read plurality is not write plurality. A stale clone may still be useful for reading docs. It is unsafe for task allocation if task state authority lives elsewhere.

6. Configuration Shape

A system practicing this discipline should have a configuration object that names the authority topology.

Example shape:

narada_proper:
  authority_clone: wsl
  clones:
    wsl:
      path: /home/andrey/src/narada
      runtime: linux-node
      shell: wsl
    windows:
      path: D:\code\narada
      runtime: windows-node
      shell: powershell

This is not merely convenience configuration. It is an authority map.

The map should be outside accidental caller context. If the operator happens to be inside a non-authority clone, the system should still know where mutation authority lives.

7. Relation To Narada

Narada naturally creates plural embodiments:

• Sites on different machines;
• user and PC loci;
• Windows and WSL shells;
• source clones and generated templates;
• operator console, task CLI, inbox CLI, and agents;
• local evidence, exported envelopes, SQLite state, and Git state.

This plurality is a strength only if mutation authority remains explicit.

For Narada, the discipline implies:

• narada doctor should report current embodiment, authority locus, runtime origin, freshness, and mutation safety.
• narada inbox submit should disclose the target inbox authority before accepting payload.
• Task allocation should refuse when invoked from a non-authority clone unless forwarding is configured.
• Read-only commands may run from replicas, but their output should identify the replica and freshness posture.
• Cross-environment wrappers should route to the configured state-bearing clone rather than duplicating state.

The practical slogan is:

Many front doors. One mutation locus.

8. Relation To CIPDA

CIPDA asks which next move increases coherence without reducing future transformation potential.

In plural embodiment situations, a weak move is to pick the currently convenient clone or shell and proceed. That may work locally, but it hides policy as accident.

A stronger CIPDA move is to name the authority-routing invariant:

caller plurality is allowed
mutation authority is singular
authority can migrate only through explicit policy

This increases coherence while preserving future freedom. New embodiments can be added freely because they do not automatically become authority loci. Authority can also move later, but only as a named migration.

9. Relation To Inhabited Evolution

Inhabited Evolution earns structure through operational pressure.

Plural Embodiment, Singular Authority is earned when inhabited work repeatedly crosses embodiments:

• an operator speaks in chat;
• an architect runs commands from Windows;
• the state-bearing repo is in WSL;
• another clone has newer tooling but older doctrine;
• an inbox or task mutation must be submitted without split-brain state.

The concept prevents local tooling friction from becoming hidden architecture. The operation may remain convenient, but convenience is routed through authority rather than replacing it.

10. Failure Modes

Split-Brain Mutation

Two embodiments both mutate state as if they were authoritative. Later reconciliation discovers duplicate, divergent, or missing transitions.

Convenience Capture

The easiest command path becomes the de facto authority locus without being declared.

Stale Embodiment Authority

A clone or tool with outdated command semantics performs a valid-looking mutation against the wrong substrate.

Forwarding Without Disclosure

A command silently forwards to another locus without telling the operator where authority was exercised. This avoids split-brain but weakens audit and operator understanding.

Read-Write Smearing

A replica that is acceptable for inspection is treated as acceptable for mutation.

Tool Identity Confusion

The operator believes they are invoking “Narada”, but the actual binary, runtime, package build, or repository is not the one that owns the relevant authority.

11. Tests

A system satisfies Plural Embodiment, Singular Authority for a mutation class when it can answer:

1. What embodiments can present this command?
2. Which locus is authoritative for this mutation?
3. Where is that routing policy stored?
4. What happens if the command is invoked from a non-authority embodiment?
5. How is freshness checked?
6. How is forwarding disclosed?
7. What read-back confirms the mutation?
8. What audit record identifies caller, authority locus, and result?
9. How can authority migrate later without split-brain state?
10. Which embodiments are read-only projections rather than authority-bearing substrates?

If these questions cannot be answered, embodiment plurality is likely to become authority ambiguity.

12. Summary

Plural Embodiment, Singular Authority names a structural invariant for systems that must be present in many places without becoming many conflicting systems.

It permits ergonomic plurality:

many shells
many agents
many clones
many UIs
many projections

while preserving governed consequence:

one declared authority locus per mutation
explicit routing
read-back confirmation
auditable result

The system may have many bodies. Its governed mutations need one accountable place to become true.