The Rhizomatic Context Protocol

AI is learning how to do almost everything.

It still does not know, on its own, what it is allowed to do for whom.

A capable agent can research a market, draft an agreement, contact another system, schedule a meeting, deploy code, transfer value, or alter a shared record. Technical capability answers whether the operation can be performed. It does not answer whether the operation should occur, who authorized it, which relationship applies, what information may be revealed, what commitment is active, or who remains accountable for the result.

That gap becomes more important as intelligence becomes cheaper and more systems gain the ability to act.

The next major infrastructure problem is coordination.

Coordination means getting the right people, agents, knowledge, authority, resources, and timing into a sequence that produces a legitimate result. It requires durable state that can survive the message, the application, the model, and the institution where the work began.

The Rhizomatic Context Protocol, or RCP, is being developed for that purpose.

RCP is a proposed open semantic and event protocol for representing, exchanging, and reconstructing governed coordination context across people, organizations, applications, and AI agents.

The plain-English version is simpler:

RCP carries the human and organizational meaning around an action: who is involved, which relationship and Context apply, what may be known, who has authority, what was agreed, what occurred, and what happened next.

Messages are not coordination

Most digital systems preserve fragments.

Email preserves messages. Calendars preserve events. Project tools preserve tasks. CRMs preserve records about contacts. Payment systems preserve transactions. AI assistants preserve some combination of prompts, responses, summaries, and tool calls.

A real outcome can move across all of them.

Someone asks for an introduction in a text message. Another person gives approval during a call. A third person sends the email. An agent prepares the materials. A calendar records the meeting. A payment system records a deposit. The work is delivered in another application. The result appears weeks later.

Each system knows something. None necessarily carries the whole episode.

Communication tells us what was said. Coordination state tells us what is happening, what may happen next, who can authorize it, what remains open, and whether the intended result occurred.

This is why more messages do not automatically produce better coordination. The missing structure usually lives between the messages.

The existing protocols solve adjacent problems

RCP starts from standards that already exist.

The Model Context Protocol gives AI applications a standardized way to access resources, prompts, tools, and other capabilities. The Agent2Agent Protocol gives independent agents a common language for communication and collaboration.

Decentralized Identifiers support identifiers that can be decoupled from one central identity provider. Verifiable Credentials support portable claims with issuers, holders, and verifiers. PROV-O supplies a vocabulary for provenance. ODRL supplies a model for permissions, prohibitions, duties, and constraints.

Each solves an important part of the problem.

RCP addresses the coordination state connecting those capabilities into a durable episode.

An RCP implementation might use HTTP to move a message, a DID to identify an Actor, a Verifiable Credential to carry an attestation, MCP to invoke a tool, A2A to work with another agent, ODRL-compatible policy to express a constraint, PROV-compatible records to preserve derivation, and existing financial rails to settle payment.

RCP supplies the shared meaning around why those events belong together.

The governing rule is narrow:

RCP should standardize only what independent systems must share for coordination to remain legible, authorized, attributable, and portable.

What the protocol carries

A public protocol needs a small semantic core.

It cannot absorb every interface idea, workflow, ranking method, database choice, or product experiment. Those belong above the protocol unless repeated evidence shows that independent systems need to interpret them in the same way.

The current candidate model organizes the core into four groups.

A Node is anything the protocol can identify. An Actor is a Node capable of asserting, authorizing, committing, verifying, or acting. A Context defines the governed boundary. A Relationship connects Nodes in a typed, directional, temporal, and attributable way.

An Objective describes the desired future state. A Signal expresses a need, offer, request, observation, risk, availability, or change. Authority identifies the legitimate basis for access, disclosure, decision, delegation, commitment, verification, or action.

A Route proposes a path. A Commitment records a bounded responsibility. An Action records an attributable attempt to change state.

An Outcome records the observed result. Evidence supports or contradicts an assertion. A Receipt connects the authority, commitment, action, result, and evidence. A Memory Reference points to prior coordination state under explicit access and retention rules. An Event preserves a material transition.

This vocabulary is less opinionated than a Rhiz application. A compatible implementation could use a different interface, database, model provider, ranking method, or domain workflow while preserving the shared meaning of the episode.

The Coordination Episode

The core unit of RCP is the Coordination Episode.

A Coordination Episode is a bounded sequence in which one or more Actors pursue an Objective within a governed Context and authority model, producing attributable state transitions and an observed result.

An episode can be small. One person delegates a bounded task to one agent.

It can also span institutions. A community identifies a need. A funder authorizes resources. Several providers accept commitments. Agents invoke tools. An implementation records the actions. An independent party verifies the result.

The sequence does not require one rigid interface. An episode may begin with a request, an observation, an opportunity, a payment, a dispute, or a correction. Some episodes end in completion. Others end in rejection, expiration, cancellation, failure, or an honest finding that the available evidence is insufficient.

Failure is useful state when it is recorded truthfully. Fabricated closure damages every future decision that depends on it.

Context cannot be global

A person can be a founder in one Context, a parent in another, a volunteer in another, and an anonymous participant somewhere else.

The relevant role, relationship, permission, and memory can change across each of those settings.

A contact is not a relationship. A relationship is not permission.

Knowing that two people are connected does not reveal why they are connected, what they may ask of one another, which information may cross the relationship, or whether the relationship is active in the current Context.

RCP treats Context as a governed boundary with a declared purpose, participants, roles, visibility, policy, authority, time horizon, and lifecycle. Retrieval and disclosure should begin from that boundary. Filtering after sensitive information has already entered a model or projection is too late.

This principle also protects plural identity. A person should not be reduced to one universal profile assembled from every role they have ever occupied.

Capability is not authority

The agent era makes authority inspectable by necessity.

An agent can possess the credentials and technical access required to invoke a tool. That does not prove that the agent has permission to use the tool for the current purpose.

A consequential action should be traceable through its authorization chain. Each delegation can preserve purpose, scope, limits, duration, approval thresholds, revocation, subdelegation rights, and provenance.

A human may authorize an agent to schedule a meeting without authorizing it to accept a contract. An institution may authorize a research agent to inspect protected material without authorizing disclosure. A finance agent may prepare a transaction while final execution still requires a named human approval.

Autonomy becomes a policy decision attached to authority. It is not assumed merely because a system is capable.

Events preserve records. Claims keep their status.

A durable event log is essential for reconstruction and accountability.

The event still needs an explicit truth state.

A message saying that a project was completed proves that the message entered the system. It does not independently prove completion. A model confidence score does not turn an inference into a verified fact. Repeating a claim across summaries does not increase its epistemic standing.

RCP separates observations, claims, inferences, supported assertions, verified assertions, disputes, corrections, withdrawals, expiry, and supersession.

The stronger rule is:

Events are the durable record. Epistemic status remains explicit.

A correction adds a new attributable event. The historical record remains reconstructable, subject to lawful retention, privacy, and deletion requirements.

Trust stays contextual

Trust matters because coordination depends on expectations formed through relationships and prior outcomes.

Trust becomes dangerous when a system turns contextual evidence into one universal score for a person.

Evidence that someone delivered strong design work under one set of conditions may support confidence in a similar project. It does not establish their general financial reliability, morality, employability, civic standing, or human worth.

RCP can carry attestations, credentials, outcome history, relationship history, and provenance. An authorized local policy can use that evidence for a bounded decision. The evidence may travel where permission allows. The judgment remains tied to its purpose and Context.

This is a constitutional principle for the protocol, not a tuning preference.

Coordination has more than one clock

A single timestamp cannot explain a real commitment.

Imagine that an agreement was made on July 8, entered into a system on July 9, due on August 1, and valid through August 15. Each date answers a different question.

Occurrence time records when something happened. Transaction time records when a system learned or recorded it. Deadline time records when an obligation was due. Valid time records the period during which an assertion, role, permission, relationship, or commitment applied.

These distinctions let an implementation ask whether a permission was valid when information was disclosed, what the system knew when a route was approved, whether delivery was late, and which version of an assertion influenced a decision.

Time is part of the coordination state.

Action is not Outcome

Digital systems are good at recording activity.

Activity can create the appearance of progress while the intended change remains distant.

Sending an introduction is an Action. Receiving a reply is an early Outcome. Holding a meeting is another. Accepting a pilot creates a Commitment. Delivering the pilot creates a stronger Outcome. Verifying the result closes more of the episode.

RCP preserves the chain rather than compressing every step into a success flag.

The Receipt answers four practical questions:

1. Who acted?
2. Under which authority and Commitment?
3. What happened, and what Evidence supports it?
4. Who may see, verify, dispute, or reuse the result?

That closure gives future coordination something more useful than a vague memory that work occurred.

Why the protocol is rhizomatic

A rhizome grows through distributed connections rather than one permanent trunk.

It can form new paths around obstruction, preserve local autonomy, reactivate dormant connections, and extend through several centers at once.

RCP applies that pattern through polycentric coordination.

An episode may begin in one application, receive authorization from another institution, invoke a capability in a third system, and obtain verification from a fourth. No participant needs to own the complete network.

Contexts can overlap without collapsing. Routes can change without erasing lineage. Dormant relationships can reactivate when timing and purpose make them relevant again. Completed and failed episodes can return learning to the network under the permissions that govern its use.

The term rhizomatic therefore describes an engineering requirement: many governed paths, several legitimate centers, preserved provenance, and no mandatory permanent hub.

Rhiz Network, RCP, and WeRhiz serve different roles

RCP is the durable protocol layer.

Rhiz Network is the current flagship application and network expression built over it. The product can change its interface, composition, market language, and business model as we learn. Those changes do not automatically redefine the protocol.

WeRhiz, Inc. is the current builder, operator, and steward. It can create commercial products, applications, and future companies over the shared protocol layer.

Repeated application work should compound downward when evidence shows that several systems need the same semantic contract. Product experiments remain above the protocol until that proof exists.

This separation protects both speed and durability. Rhiz Network can adapt to real users. RCP can mature slowly enough to preserve interoperability.

What exists and what still has to be earned

RCP grows from working Rhiz architecture.

The current system contains protocol events, identity infrastructure, permissions and entitlements, relationship models, governed agent tools, and an emerging Coordination Episode model. The complete public protocol remains a candidate.

Three maturity labels keep that distinction honest:

Implemented substrate describes working code with material architecture and operational evidence.

Emerging proof describes code that exists but needs more real use, correction cases, failure cases, Outcomes, Receipts, and portability evidence.

Protocol proposal describes behavior that still requires an implementation-independent specification, security review, public conformance tests, external implementations, federation, and governance work.

The reference implementation can prove that a specification works. It cannot become the specification by accident.

How RCP becomes public infrastructure

A protocol earns legitimacy through use and interoperability.

The present priority is commercial proof inside Rhiz Network. Real people and organizations need to use the system, pay for useful outcomes, coordinate through it, correct it when it is wrong, and produce evidence about which concepts actually survive contact with reality.

That evidence supports semantic hardening. Stable semantics can then separate from the current Neon schema, services, application surfaces, and internal implementation choices. A public specification, reference implementation, test vectors, and conformance suite can follow.

At least two independently controlled implementations should interoperate before a core feature is treated as Standard. Federation should be proven through real episodes that cross humans, institutions, applications, and agents. Neutral or community stewardship becomes credible when an external ecosystem has a reason and the capacity to participate.

The long-term direction is clear:

RCP becomes the commons. WeRhiz becomes one builder on that commons. Rhiz Network becomes one powerful application among several possible expressions.

The test

The internet lowered the cost of moving information.

Artificial intelligence is lowering the cost of producing and applying intelligence.

RCP addresses the state required to coordinate that intelligence across independent actors without assigning one model, application, company, institution, or database permanent control of the whole system.

The protocol succeeds when it helps people, organizations, communities, and agents turn intelligence into legitimate action, action into evidence-backed Outcomes, and Outcomes into greater future capability.

That is the test.

When independent systems can pass it together, coordination can become infrastructure.