This directory contains the capability registry pages for the [&] Protocol.
These pages are intended to serve two purposes at the same time:
human-readable documentation
stable, structured content for indexing, generation, and publishing
Each page describes one concrete protocol capability such as:
memory.graph
memory.episodic
reason.argument
reason.deliberate
reason.attend
time.forecast
space.fleet
The canonical protocol identifiers for these are:
&memory.graph
&memory.episodic
&reason.argument
&reason.deliberate
&reason.attend
&time.forecast
&space.fleet
A capability page is the protocol-level explanation of a single capability subtype.
It should help a reader answer questions like:
What does this capability mean?
Why does it exist?
When should an agent use it?
What operations does it usually support?
What inputs and outputs does it work with?
What other capabilities does it compose well with?
Which providers can satisfy it?
What governance and provenance concerns apply?
What MCP or A2A implications does it have?
In other words, these pages are the bridge between:
the formal schema and contract artifacts
the broader protocol specification
concrete implementation and integration decisions
These pages complement several other protocol artifacts.
SPEC.md
protocol.html
These define the formal model, grammar, and architecture of the protocol.
protocol/schema/v0.1.0/ampersand.schema.json
protocol/schema/v0.1.0/capability-contract.schema.json
protocol/schema/v0.1.0/registry.schema.json
These make the protocol machine-readable.
contracts/v0.1.0/
These define typed capability behavior such as operations, accepts_from, feeds_into, and a2a_skills.
protocol/registry/v0.1.0/capabilities.registry.json
This publishes discoverable provider and subtype metadata.
docs/capabilities/memory.md
docs/capabilities/reason.md
docs/capabilities/time.md
docs/capabilities/space.md
docs/capabilities/body.md (planned)
docs/capabilities/govern.md
These explain the primitive domains. The files in this directory explain specific capability pages inside those domains. For &body.* subtypes (body.browser, body.os, etc.), see the individual registry pages and the OS-011 Embodiment Protocol specification for behavioral semantics.
Files in this directory use the capability subtype name as the filename.
Examples:
memory.graph.md
memory.episodic.md
reason.argument.md
reason.deliberate.md
reason.attend.md
time.forecast.md
space.fleet.md
This mirrors the public route shape envisioned in the protocol roadmap:
/capabilities/memory.graph
/capabilities/memory.episodic
/capabilities/reason.argument
/capabilities/reason.deliberate
/capabilities/reason.attend
/capabilities/time.forecast
/capabilities/space.fleet
Each capability page should be substantial enough to stand on its own.
Recommended sections:
Definition
A concise explanation of the capability.
Why it exists
The architectural reason the capability is a first-class subtype.
Position in the primitive family
How it fits under &memory, &reason, &time, &space, or &govern.
Capability contract summary
A representative contract or contract excerpt.
Operations
Typical operations and what they do.
Architecture patterns
How the capability composes with other capabilities.
Example declaration
A realistic ampersand.json fragment.
Example API or payload shape
A representative implementation-facing example.
Compatible providers
Providers that may satisfy the capability contract.
Governance implications
Hard constraints, soft constraints, and escalation considerations.
Provenance implications
What should be preserved in the provenance chain.
A2A and MCP implications
How this capability may compile into downstream protocol artifacts.
Research grounding
Theoretical or systems background that motivates the capability.
Anti-patterns
Common mistakes in modeling or implementing the capability.
Summary
A short closing explanation of why the capability matters.
These are not meant to be thin SEO pages.
A good capability page should be:
technically useful
accurate
specific
provider-agnostic at the protocol level
grounded in the actual schema and contract model
helpful to both implementers and readers discovering the protocol
A weak capability page usually does one or more of the following:
repeats the subtype name without explaining it
talks only in marketing language
confuses provider names with capability identifiers
has no contract or architecture context
has no realistic examples
is too short to help an engineer use the capability
At the moment, this directory includes:
memory.graph.md
memory.episodic.md
reason.argument.md
reason.deliberate.md
reason.attend.md
time.forecast.md
space.fleet.md
These pages are the first set of high-quality registry entries and can act as templates for future pages.
As the protocol expands, useful additions include:
memory.vector.md
reason.vote.md
reason.plan.md
time.anomaly.md
time.pattern.md
space.route.md
space.geofence.md
These should be added only when they can be documented with enough quality and grounded protocol detail.
When writing a new capability page:
start from the protocol capability identifier, not the provider name
keep the capability/provider distinction explicit
use realistic examples
align terminology with SPEC.md
align contracts with contracts/v0.1.0/
align registry metadata with protocol/registry/v0.1.0/capabilities.registry.json
mention governance and provenance when they materially matter
prefer clarity over hype
A simple rule of thumb:
Write each page so that an engineer could understand what the capability is, how it composes, and how to implement or consume it without reading the whole repository first.
This directory is the protocol’s capability-level documentation surface.
The top-level spec explains the model. The schemas validate the artifacts. The contracts define typed behavior. The registry publishes discovery metadata.
These pages explain what each capability actually means.