Protocol

Core operations

The initial protocol vocabulary remains intentionally small:

identify   inspect    retrieve   encounter
preserve   relate     assert     correct
request    grant      revoke     act
approve    verify     sync       succeed

Each interface may present these differently, but the underlying operation retains participant, identity, target, context, authority, provenance, idempotency, evidence, event, receipt, and objective semantics.

The machine-readable contract registry is available at registry/protocol.json.

Step 1A — addresses and envelopes

Pre addresses use one bounded storage-neutral grammar:

<kind>:<segment>[:<segment>...]

Address segments provide namespacing and readability only. They do not imply ownership, hierarchy, membership, inheritance, or permission.

pre.action.v1 represents a participant request. It carries a request: address, participant, acting identity, source interface, context-grant references, intended action, target, caller-supplied authority references, bounded JSON input, caller risk label, idempotency key, evidence expectations, and issue time.

pre.result.v1 represents the trusted boundary's disposition. It keeps three questions separate:

admission   accepted | denied
execution   not-started | pending | running | succeeded | failed
objective   unverified | verified | not-met | not-applicable

A successful process therefore cannot silently claim that the objective was achieved.

Step 1B — authority and capabilities

A trusted authority store admits immutable records:

identity binding
membership
context grant
capability
revocation

The resolver never treats a schema-valid record supplied by a client as admitted authority. claimedAuthority and contextGrants are explicit references and lookup hints. The trusted store resolves them.

Identity bindings establish that a participant may act through an identity for a bounded period and assurance level. Memberships are addressable relationships that may receive explicit grants; a role name grants nothing by itself.

Capabilities and context grants bind exact subjects, actions, targets, fields, risk ceilings, time windows, and delegation lineage. Each delegated child must attenuate every parent dimension.

Revocation is a separate immutable record. Revoking an ancestor invalidates the chain without rewriting historical grants.

The boundary independently classifies risk. Caller labels cannot downgrade a consequential action into a read.

Step 1C — events, receipts, and idempotency

An accepted request first creates an immutable request claim binding participant, idempotency key, and canonical action digest.

Events are immutable and ordered within an explicit stream:

stream
sequence
previous event
request
actor
event type
time
payload

Pre does not require one global event order. A task, request, conversation, or relation can be reconstructed from its own ordered stream.

Retry behavior is explicit:

• identical finalized retry → return the original result and receipt;
• same idempotency scope with different input → deny as conflict;
• admitted request without a final receipt → return pending/recovery state;
• never silently execute an incomplete request twice.

A final immutable receipt binds the request and result digests to the accepted event history.

Step 1D — evidence and objective outcomes

Evidence records describe what was observed or produced. They retain source request, kind, subject, producer, artifact reference, digest, claims, and time.

Evidence is not a verdict.

Only an explicit trusted evaluator may issue an objective verdict. Verdicts retain evaluator identity and authority, evidence references, status, rationale, issue time, and explicit supersession.

Conflicting active verdicts remain addressable and project as disagreement rather than synthetic certainty.

Step 1E — external bindings and succession

An external binding maps a canonical Pre object to one provider object. It grants adapter behavior per field:

canonical field
external field
direction
external write: none | propose | apply
conflict policy

An adapter that may update one field does not own the object. Unlisted and canonical-only fields remain denied. External deletion marks a projection missing; canonical history survives.

A succession record connects predecessor and successor while preserving selected history, context, attribution, or obligations. It never transfers authority implicitly. Identity, membership, context, and capability require new records.

Step 1F — reference protocol loop

The in-memory reference kernel proves the complete storage-neutral loop:

validate request
  -> claim idempotency
  -> resolve authority
  -> execute one bounded operation
  -> record ordered events and evidence
  -> optionally evaluate the objective
  -> emit result and immutable receipt
  -> terminate
  -> reconstruct or replay from durable protocol state

The bounded-read reference executor returns only fields present in resolved authority. A replacement kernel sharing the journal reconstructs or replays the same request without relying on the original executor process.

This is a conformance reference, not a production runtime or database decision.

Interface collapse

API, CLI, DOM, GUI, email, Stow, agent tools, and later neural or spatial interfaces do not invent parallel action models.

Preserving a webpage as evidence, approving a task, replying to a message, or updating a field should retain the same canonical meaning regardless of which surface initiated it.

Safety invariants

• Posting text cannot execute code.
• Encountering content cannot grant it authority.
• An address does not confer authority through syntax.
• Schema validity establishes shape, not trust.
• Caller claims never become resolved authority automatically.
• Delegation can attenuate but cannot escalate.
• Risk is classified by a trusted boundary.
• Field scope is part of authority.
• Duplicate requests do not duplicate effects.
• Incomplete requests are recovered explicitly.
• State transitions are attributable and ordered.
• Evidence does not evaluate itself.
• Process completion does not prove objective completion.
• External projections may disappear without deleting canonical state.
• Succession preserves continuity without implicit authority inheritance.

Content and surface projections

PageDocument remains the first concrete surface projection. The same storage-neutral rule now applies to actions and durable protocol records: a database may persist them, but the database does not define their meaning.