A small core.
A rich relationship model.

Relationships as first-class records.

A relationship is more than a link between two rows. It can have multiple participants in named roles, its own context, a lifecycle, and an attributed history. That lets an agent work with the relationship itself.

Wealth of Networks is the platform implementing this model. The Relationship Protocol defines the model and its authorized operations. It does not require a particular model provider, programming language, or graph database.

Two record kinds.

Both have stable IDs, a type, a revision and data. They belong to a collection in a workspace. Application types are defined in a versioned program rather than hard-coded as new platform subsystems.

A relationship can be a participant.

Connect a person to a team through a membership. Then connect an agent to that membership through an assignment. The same relationship pattern repeats at each level.

Relationships can reference other relationships, including cycles. They are not recursively expanded or traversed automatically. An application decides which authorized records to retrieve.

Small core. Programmable behavior.

A program is an immutable, versioned package describing the types and behavior an application needs:

• Schemas and roles: what data and participants a type accepts.
• Lifecycles: the states a record can occupy.
• Commands and conditions: which transitions are available and what input they require.
• Views and work requests: ways to present records and record an intent for external work.

The definition language is bounded and declarative. It does not run arbitrary code, models, network requests or external actions. Existing records remain pinned to their program version.

A work request is a durable intent. The agent or application consuming it must independently have permission to use any external tools.

Context is not authority.

Describing a person, agent, membership or assignment does not grant access. Represented participants and authenticated principals are distinct.

People sign in through Intergraph. They manage workspace membership and collection permissions, and approve an agent’s exact collections and scopes through OAuth. Connections default to read-only permissions; definition writing and activation require separate permissions.

Restricted participants are redacted in reads and history. Revoking a connection or changing collection access is enforced on subsequent operations.

Changes keep their context.

Every committed mutation has attribution and a revision. Writes require idempotency keys, and edits to existing records require an expected revision. Lifecycle changes happen through authorized commands.

A durable change feed lets an external consumer resume from a checkpoint and deduplicate event IDs. Statements about meetings, delivery, or sales are attributed records or attestations, not independent verification that an external event occurred.

One contract. Two interfaces.

REST and MCP expose the same operation catalog. An agent can search authorized records, inspect command requirements, execute permitted commands, and consume changes.

REST  POST https://api.wealthofnetworks.com/v1/operations
MCP        https://api.wealthofnetworks.com/mcp

REST operation names such as record.search become MCP tool names such as record_search. Both use the same authorization boundaries.

Read the current contract.

These references are published from the implementation’s specification and bundled examples. They describe the initial contract and its limits.

• Read the full technical reference →Records, programs, operations and errors
• Download the contractMarkdown
• Record schemaJSON Schema
• Operation catalogJSON
• SalePiper programJSON example package
• Community programJSON example package