@indexnetwork/protocol 4.3.1-rc.299.1 → 4.3.2-rc.302.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md ADDED
@@ -0,0 +1,98 @@
1
+ # Changelog
2
+
3
+ All notable changes to `@indexnetwork/protocol` are documented here.
4
+
5
+ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
6
+ and this project adheres to [Semantic Versioning](https://semver.org/).
7
+ See [STABILITY.md](./STABILITY.md) for the public-contract and tier definitions.
8
+
9
+ > History before `2.0.0` was reconstructed from git and is summarized rather than
10
+ > itemized. From `2.0.0` onward, keep this file updated as part of every release
11
+ > (bump `package.json` and the `[Unreleased]` section before promoting to `main`).
12
+
13
+ ## [Unreleased]
14
+
15
+ ### Changed
16
+ - Reframed `README.md` as the public-facing Index Network Protocol document and moved package integration details into `IMPLEMENTATION.md`.
17
+ - Included protocol documentation files in the published package tarball so README links remain available to package consumers.
18
+
19
+ ## [4.3.0] - 2026-06-21
20
+
21
+ ### Added
22
+ - `STABILITY.md` defining the public contract, stability tiers (Stable vs
23
+ `@experimental`), SemVer policy, and the deprecation path.
24
+ - Port-contract doc-comments on the `ChatSessionReader`, `DiscoveryRunStore`/
25
+ `DiscoveryRunQueue`, `EnrichmentRunStore`/`EnrichmentRunQueue`, and `Embedder`
26
+ interfaces (ownership scoping, null-vs-empty-array, lifecycle idempotency).
27
+ - Tier annotations and an entry-point header in `src/index.ts`.
28
+
29
+ ### Changed
30
+ - Replaced all `export type *` wildcard re-exports in `src/index.ts` with explicit
31
+ named exports so the public surface is fully enumerated and reviewable. No
32
+ symbols added or removed — the exported surface is unchanged.
33
+ - Expanded `README.md` to document the full public surface (graph factories,
34
+ agents, MCP, tools) and link the stability policy.
35
+
36
+ ## [4.2.0] - 2026-06-19
37
+
38
+ ### Added
39
+ - Opportunity legibility: cards explain *why* an opportunity surfaced.
40
+ - Negotiation trace links on surfaced opportunities.
41
+
42
+ ## [4.1.0] - 2026-06
43
+
44
+ ### Added
45
+ - Canonical user-context / enrichment MCP tools; `discoverySource` rename
46
+ (IND-372, IND-371, IND-374).
47
+ - Context-derived `read_user_profiles` payload (IND-364).
48
+
49
+ ### Changed
50
+ - Category A prompt consumers repointed at the global `user_context` (IND-361).
51
+ - Premise pipeline ownership: dedup, LLM validity, richer provenance (IND-359).
52
+
53
+ ## [4.0.0] - 2026-06-18
54
+
55
+ ### Changed
56
+ - **BREAKING:** Eliminated the "profile" concept — the pipeline, files, service,
57
+ controller, adapter, and exported types were renamed to `enrichment`
58
+ (`ProfileDocument` → `UserIdentity`, `read_user_profiles` returns a flat
59
+ identity+context payload, questioner `profile` mode → `enrichment`). Update any
60
+ imports of the removed `Profile*` exports. (IND-368)
61
+
62
+ ### Removed
63
+ - **BREAKING:** `user_profiles` table and the profile generate/aggregate/save path
64
+ retired (IND-365).
65
+
66
+ ## [3.6.0] - 2026-06-12
67
+
68
+ ### Added
69
+ - `read_pending_questions` MCP tool, registered in the tool registry.
70
+
71
+ ## [2.0.1] - 2026-06
72
+
73
+ ### Fixed
74
+ - Post-`2.0.0` fixes and stabilization.
75
+
76
+ ## [2.0.0] - 2026-06-08
77
+
78
+ ### Changed
79
+ - **BREAKING:** Removed `configureProtocol` startup call — model configuration is
80
+ read from the environment and `ModelConfig` is injected per-request via
81
+ `ToolContext`. See README for migration.
82
+
83
+ ## [1.0.0 - 1.23.3] - 2026-04 to 2026-06
84
+
85
+ Pre-2.0 line: established the adapter-injected LangGraph architecture (chat,
86
+ intent, opportunity, negotiation, premise, enrichment domains), the MCP server,
87
+ the matching/opportunity/premise eval harnesses, premise source tracking and
88
+ cascade retraction, network-scoped agents, and the agent registry. Reconstructed
89
+ from git history; not itemized.
90
+
91
+ [Unreleased]: https://github.com/indexnetwork/protocol/compare/v4.3.0...HEAD
92
+ [4.3.0]: https://github.com/indexnetwork/protocol/compare/v4.2.0...v4.3.0
93
+ [4.2.0]: https://github.com/indexnetwork/protocol/compare/v4.1.0...v4.2.0
94
+ [4.1.0]: https://github.com/indexnetwork/protocol/compare/v4.0.0...v4.1.0
95
+ [4.0.0]: https://github.com/indexnetwork/protocol/compare/v3.6.0...v4.0.0
96
+ [3.6.0]: https://github.com/indexnetwork/protocol/compare/v2.0.1...v3.6.0
97
+ [2.0.1]: https://github.com/indexnetwork/protocol/compare/v2.0.0...v2.0.1
98
+ [2.0.0]: https://github.com/indexnetwork/protocol/releases/tag/v2.0.0
@@ -0,0 +1,255 @@
1
+ # @indexnetwork/protocol Implementation Guide
2
+
3
+ This guide covers the technical package surface for implementers embedding the canonical Index Network Protocol implementation. For the public protocol overview, see [README.md](./README.md).
4
+
5
+ The package implements LangGraph-based workflows for signal processing, opportunity discovery, negotiation, and chat — decoupled from any specific infrastructure via adapter injection.
6
+
7
+ ## Stability & versioning
8
+
9
+ This package follows [Semantic Versioning](https://semver.org/). The **only**
10
+ supported entry point is the package root (`import { ... } from "@indexnetwork/protocol"`);
11
+ deep imports are not part of the contract. Every symbol is re-exported explicitly from
12
+ `src/index.ts` and tagged with a stability tier:
13
+
14
+ - **Stable** — interfaces, graph factories, agents, `createChatTools`, the
15
+ tool/runtime helpers, and shared schemas. Breaking changes require a major bump.
16
+ - **Experimental** (`@experimental`) — advanced graph-state types and internal
17
+ helpers; may change in a minor release.
18
+
19
+ See [STABILITY.md](./STABILITY.md) for the full policy and the deprecation path,
20
+ and [CHANGELOG.md](./CHANGELOG.md) for release history.
21
+
22
+ ## Install
23
+
24
+ ```bash
25
+ npm install @indexnetwork/protocol
26
+ ```
27
+
28
+ ## Setup
29
+
30
+ ### 1. Configure the LLM
31
+
32
+ The package reads `OPENROUTER_API_KEY` (required), `CHAT_MODEL`, and `CHAT_REASONING_EFFORT` from environment variables. No startup call is needed.
33
+
34
+ To override the chat model or reasoning effort when using the built-in chat runtime (`ChatGraphFactory` / `ChatAgent`), pass `modelConfig` on `ToolContext`. `ChatAgent` reads these fields when the chat graph runs; the tools themselves do not consume `modelConfig`:
35
+
36
+ ```typescript
37
+ import { createChatTools } from "@indexnetwork/protocol";
38
+
39
+ const tools = await createChatTools({
40
+ // ... other deps ...
41
+ modelConfig: {
42
+ chatModel: "google/gemini-2.5-flash", // optional — has a default
43
+ chatReasoningEffort: "low", // optional: minimal | low | medium | high | xhigh
44
+ },
45
+ });
46
+ ```
47
+
48
+ `apiKey` and `baseURL` can also be overridden this way. All other protocol agents (evaluators, generators, etc.) rely on `OPENROUTER_API_KEY` set in the environment regardless of `modelConfig`.
49
+
50
+ ### 2. Implement the adapters
51
+
52
+ The package defines interfaces — your application provides the concrete implementations.
53
+
54
+ **Required** (always needed by `createChatTools`):
55
+
56
+ | Interface | Responsibility |
57
+ |---|---|
58
+ | `ChatGraphCompositeDatabase` | Core data access (users, intents, indexes/networks, opportunities) |
59
+ | `UserDatabase` / `SystemDatabase` | Context-bound databases built by `createUserDatabase` / `createSystemDatabase` |
60
+ | `Embedder` | Vector embeddings for semantic search |
61
+ | `Scraper` | Web content extraction |
62
+ | `Cache` / `HydeCache` | Result caching (HyDE may share the general cache) |
63
+ | `IntegrationAdapter` | OAuth and external tool actions |
64
+ | `IntentGraphQueue` | Background intent processing queue |
65
+ | `ContactServiceAdapter` | Contact management |
66
+ | `ChatSessionReader` | Load conversation history |
67
+ | `ProfileEnricher` | Enrich profiles from external sources |
68
+ | `NegotiationGraphDatabase` | Negotiation state persistence |
69
+
70
+ **Optional** (enable specific capabilities; omit to run without that feature):
71
+
72
+ | Interface | Responsibility |
73
+ |---|---|
74
+ | `AgentDatabase` | Agent registry CRUD (agents, transports, permissions) |
75
+ | `AgentDispatcher` | Resolves and invokes personal agents during negotiation turns — required to register the negotiation tools |
76
+ | `McpAuthResolver` | Resolves `{ userId, agentId }` from an incoming MCP HTTP request (MCP server only) |
77
+ | `DeliveryLedger` | Commits OpenClaw opportunity-delivery rows |
78
+ | `DiscoveryRunStore` / `DiscoveryRunQueue` | Persist and execute async MCP discovery runs |
79
+ | `EnrichmentRunStore` / `EnrichmentRunQueue` | Persist and execute async MCP enrichment runs |
80
+ | `MintConnectLink` | Mints short connect links for opportunity accepts |
81
+ | `ChatSummaryReader` | Read-through chat-session digest |
82
+ | `ChatMessageWriter` | Writes user messages into the most-recent chat session (MCP elicitation) |
83
+ | `QuestionGeneratorReader` / `QuestionerDatabase` | Decision-question generation and persistence |
84
+ | `NegotiationSummaryReader` | Negotiation-digest summarization (falls back to deterministic digests) |
85
+
86
+ All interfaces are exported from the package root — import them with `import type { ... } from "@indexnetwork/protocol"`.
87
+
88
+ ### 3. Create tools
89
+
90
+ Pass your adapter implementations to `createChatTools` to get a set of LangChain-compatible tools bound to a user session:
91
+
92
+ ```typescript
93
+ import { createChatTools } from "@indexnetwork/protocol";
94
+
95
+ const tools = await createChatTools({
96
+ userId: "user-uuid",
97
+
98
+ // ── Required adapters ──
99
+ database, // ChatGraphCompositeDatabase
100
+ embedder, // Embedder
101
+ scraper, // Scraper
102
+ cache, // Cache
103
+ hydeCache, // HydeCache
104
+ integration, // IntegrationAdapter
105
+ intentQueue, // IntentGraphQueue
106
+ contactService, // ContactServiceAdapter
107
+ chatSession, // ChatSessionReader
108
+ enricher, // ProfileEnricher
109
+ negotiationDatabase, // NegotiationGraphDatabase
110
+ integrationImporter, // bulk contact import
111
+ createUserDatabase, // (db, userId) => UserDatabase
112
+ createSystemDatabase, // (db, userId, indexScope, embedder?) => SystemDatabase
113
+
114
+ // ── Optional scoping ──
115
+ networkId: "optional-network-uuid", // scope tools to a specific index/network
116
+ sessionId: "chat-session-id", // enables draft opportunities with conversation context
117
+
118
+ // ── Optional capabilities (enable when the host supports them) ──
119
+ agentDatabase, // AgentDatabase — agent registry
120
+ agentDispatcher, // AgentDispatcher — routes negotiation turns to personal agents
121
+ deliveryLedger, // DeliveryLedger — OpenClaw delivery commits
122
+ discoveryRuns, // DiscoveryRunStore (+ discoveryRunQueue) — async MCP discovery
123
+ enrichmentRuns, // EnrichmentRunStore (+ enrichmentRunQueue) — async MCP enrichment runs
124
+ mintConnectLink, // short connect links for opportunity accepts
125
+ modelConfig, // override chat model / reasoning effort (see above)
126
+ });
127
+
128
+ // tools is an array of LangChain Tool objects ready to bind to an agent
129
+ ```
130
+
131
+ `createChatTools` accepts a single `ToolContext` object. The required adapters
132
+ above are always needed; the optional capabilities default to a degraded-but-
133
+ functional mode when omitted (e.g. without `agentDispatcher` the negotiation
134
+ tools are not registered, and without `discoveryRuns` MCP discovery runs
135
+ synchronously).
136
+
137
+ ## Graphs
138
+
139
+ For direct graph invocation (bypassing the tool layer), a `*GraphFactory` class is exported for each workflow:
140
+
141
+ ```typescript
142
+ import {
143
+ ChatGraphFactory,
144
+ IntentGraphFactory,
145
+ OpportunityGraphFactory,
146
+ EnrichmentGraphFactory,
147
+ PremiseGraphFactory,
148
+ NegotiationGraphFactory,
149
+ HydeGraphFactory,
150
+ NetworkGraphFactory,
151
+ NetworkMembershipGraphFactory,
152
+ IntentNetworkGraphFactory,
153
+ HomeGraphFactory,
154
+ MaintenanceGraphFactory,
155
+ } from "@indexnetwork/protocol";
156
+ ```
157
+
158
+ Each factory takes its typed dependencies in the constructor and exposes a
159
+ `.createGraph()` method that returns a compiled LangGraph ready for `.invoke()`.
160
+
161
+ | Factory | Workflow |
162
+ |---|---|
163
+ | `ChatGraphFactory` | ReAct chat loop — LLM calls tools, responds to the user |
164
+ | `IntentGraphFactory` | Clarify, infer, verify felicity, reconcile, and persist intents |
165
+ | `OpportunityGraphFactory` | HyDE-based discovery: search, evaluate (valency), rank, persist |
166
+ | `EnrichmentGraphFactory` | Enrich users (scrape + embed) and decompose into premises |
167
+ | `PremiseGraphFactory` | Decompose and index a user's premises |
168
+ | `NegotiationGraphFactory` | Multi-turn bilateral negotiation flows |
169
+ | `HydeGraphFactory` | Generate hypothetical documents and embed them (cache-aware) |
170
+ | `NetworkGraphFactory` | Manage index/network CRUD |
171
+ | `NetworkMembershipGraphFactory` | Manage index/network member join/leave |
172
+ | `IntentNetworkGraphFactory` | Evaluate and assign/unassign intents to indexes |
173
+ | `HomeGraphFactory` | Categorize and curate home-feed content |
174
+ | `MaintenanceGraphFactory` | Periodic maintenance (feed health, opportunity expiration) |
175
+
176
+ ## MCP server
177
+
178
+ The package exports a factory that registers every chat tool over the Model Context Protocol and attaches a canonical `instructions` block (`MCP_INSTRUCTIONS`) that every connecting runtime follows. The factory takes three arguments:
179
+
180
+ ```typescript
181
+ import { createMcpServer, type McpAuthResolver } from "@indexnetwork/protocol";
182
+
183
+ const authResolver: McpAuthResolver = {
184
+ async resolveIdentity(req) {
185
+ // Look up the API key in `x-api-key` and return { userId, agentId? }.
186
+ // `agentId` should come from Better Auth token metadata so downstream
187
+ // tool handlers can attribute every call to a concrete agent identity.
188
+ return resolveFromApiKey(req);
189
+ },
190
+ };
191
+
192
+ const server = createMcpServer(
193
+ deps,
194
+ authResolver,
195
+ {
196
+ // Per-request factory for scoped user/system databases.
197
+ create: (userId, indexScope) => createScopedDeps(userId, indexScope),
198
+ },
199
+ );
200
+ ```
201
+
202
+ On every tool call the server:
203
+
204
+ 1. Extracts the HTTP request from the MCP `ServerContext`.
205
+ 2. Calls `authResolver.resolveIdentity(req)` to get `{ userId, agentId }`.
206
+ 3. Gates access: MCP callers without a resolved `agentId` are blocked from every tool except `register_agent`, `read_docs`, and `scrape_url` until they register.
207
+ 4. Builds per-request scoped databases via `scopedDepsFactory` and invokes the tool handler through the shared runtime.
208
+
209
+ ### Runtime controls
210
+
211
+ MCP tools are bounded by `ToolInvocationRuntime`:
212
+
213
+ | Class | Default | Class override |
214
+ |---|---:|---|
215
+ | `fast` | 10 s | `MCP_TOOL_TIMEOUT_FAST_MS` |
216
+ | `bounded_slow` | 45 s | `MCP_TOOL_TIMEOUT_BOUNDED_SLOW_MS` |
217
+ | `async_candidate` | 50 s | `MCP_TOOL_TIMEOUT_ASYNC_CANDIDATE_MS` |
218
+
219
+ Per-tool timeout overrides use `MCP_TOOL_TIMEOUT_<TOOL_NAME>_MS`, such as `MCP_TOOL_TIMEOUT_DISCOVER_OPPORTUNITIES_MS`. Tool outputs are capped by `MCP_TOOL_MAX_OUTPUT_BYTES` (default `1000000`) or `MCP_TOOL_MAX_OUTPUT_<TOOL_NAME>_BYTES`; inbound MCP request bodies are capped by the backend with `MCP_MAX_REQUEST_BYTES` (default `1000000`). Runtime failures return JSON text envelopes with stable `code` values: `TOOL_TIMEOUT`, `TOOL_CANCELLED`, or `TOOL_OUTPUT_TOO_LARGE`.
220
+
221
+ For MCP callers, `discover_opportunities` is async: it returns a `discoveryRunId` immediately, and clients poll `get_discovery_run` or request cancellation with `cancel_discovery_run`. Non-MCP chat/web paths stay synchronous.
222
+
223
+ ### `MCP_INSTRUCTIONS`
224
+
225
+ The instructions string is the single canonical behavioral contract for every runtime that connects to Index Network — voice, entity model, discovery-first rule, output rules, and the **Negotiation turn mode** block that tells a silent subagent how to handle a live negotiation turn when its session key is prefixed `index:negotiation:`. Plugin skills and bootstrap scripts do **not** redefine this guidance; they defer to whatever ships in `MCP_INSTRUCTIONS`.
226
+
227
+ ### Negotiation-facing tools
228
+
229
+ Personal agents participate in bilateral negotiation via a small set of MCP tools:
230
+
231
+ | Tool | Purpose |
232
+ |---|---|
233
+ | `get_negotiation` | Fetch the full turn history and assessment seed for a negotiation |
234
+ | `list_negotiations` | List negotiations awaiting a response from this agent's user |
235
+ | `respond_to_negotiation` | Submit a turn (propose / counter / accept / reject / question) |
236
+
237
+ ## Publishing
238
+
239
+ Publishing is handled via CI:
240
+
241
+ ```bash
242
+ # dev pushes publish an rc prerelease
243
+ git push <remote> dev
244
+
245
+ # main pushes publish the stable release if the package version is new
246
+ git push <remote> main
247
+ ```
248
+
249
+ `dev` publishes prerelease versions derived from `package.json` using npm's `rc` tag, for example `3.6.3-rc.123.1`. `main` publishes the base version from `package.json` to `latest` only when that version is not already on npm.
250
+
251
+ Or publish manually from `packages/protocol/`:
252
+
253
+ ```bash
254
+ npm publish --access public
255
+ ```
package/README.md CHANGED
@@ -1,253 +1,427 @@
1
- # @indexnetwork/protocol
1
+ # Index Network Protocol
2
2
 
3
- The agent orchestration layer for Index Network. Implements LangGraph-based workflows for intent processing, opportunity discovery, and chat — decoupled from any specific infrastructure via adapter injection.
3
+ ## Status
4
4
 
5
- ## Stability & versioning
5
+ This document describes the public protocol model for Index Network: the entities, state transitions, agent obligations, privacy boundaries, and discovery semantics that define interoperable participation in the network.
6
6
 
7
- This package follows [Semantic Versioning](https://semver.org/). The **only**
8
- supported entry point is the package root (`import { ... } from "@indexnetwork/protocol"`);
9
- deep imports are not part of the contract. Every symbol is re-exported explicitly from
10
- `src/index.ts` and tagged with a stability tier:
7
+ The canonical reference implementation is published as `@indexnetwork/protocol`. Implementation details, package installation, exported APIs, adapter contracts, graph factories, and release mechanics are documented separately in [IMPLEMENTATION.md](./IMPLEMENTATION.md). Public API stability is defined in [STABILITY.md](./STABILITY.md).
11
8
 
12
- - **Stable** interfaces, graph factories, agents, `createChatTools`, the
13
- tool/runtime helpers, and shared schemas. Breaking changes require a major bump.
14
- - **Experimental** (`@experimental`) — advanced graph-state types and internal
15
- helpers; may change in a minor release.
9
+ Normative terms such as **MUST**, **MUST NOT**, **SHOULD**, and **MAY** are used in their ordinary protocol-documentation sense.
16
10
 
17
- See [STABILITY.md](./STABILITY.md) for the full policy and the deprecation path,
18
- and [CHANGELOG.md](./CHANGELOG.md) for release history.
11
+ ## Abstract
19
12
 
20
- ## Install
13
+ Index Network is a private, intent-driven discovery protocol for agent-mediated opportunity discovery.
21
14
 
22
- ```bash
23
- npm install @indexnetwork/protocol
24
- ```
15
+ Participants express **signals**: structured statements of what they seek, offer, are open to, or can credibly support. Agents interpret those signals against participant **context**, constrain discovery to bounded **communities**, evaluate candidate overlaps, negotiate fit when appropriate, and surface **opportunities** only through consent-gated state transitions.
25
16
 
26
- ## Setup
17
+ The protocol is designed for high-signal human and agent coordination. It is not a public people database, keyword search engine, advertising channel, or automated introduction machine. Its purpose is to discover meaningful overlap while preserving context, scope, and human approval.
27
18
 
28
- ### 1. Configure the LLM
19
+ ## Protocol overview
29
20
 
30
- The package reads `OPENROUTER_API_KEY` (required), `CHAT_MODEL`, and `CHAT_REASONING_EFFORT` from environment variables. No startup call is needed.
21
+ ```mermaid
22
+ flowchart LR
23
+ Participant[Participant] --> Agent[Authorized agent]
24
+ Participant --> Context[Context]
25
+ Participant --> Signal[Signal]
31
26
 
32
- To override the chat model or reasoning effort when using the built-in chat runtime (`ChatGraphFactory` / `ChatAgent`), pass `modelConfig` on `ToolContext`. `ChatAgent` reads these fields when the chat graph runs; the tools themselves do not consume `modelConfig`:
27
+ Premises[Premises] --> Context
28
+ Context --> Scope[Effective scope]
29
+ Signal --> Scope
30
+ Community[Community membership and norms] --> Scope
31
+ AgentScope[Agent permissions] --> Scope
33
32
 
34
- ```typescript
35
- import { createChatTools } from "@indexnetwork/protocol";
33
+ Scope --> CandidateGeneration[Candidate generation]
34
+ CandidateGeneration --> Evaluation[Evaluation]
35
+ Evaluation -->|plausible but uncertain| Opportunity[Draft or negotiating opportunity]
36
+ Evaluation -->|clear fit| Opportunity[Draft or pending opportunity]
37
+ Opportunity -->|needs agent clarification| Negotiation[Bounded negotiation]
38
+ Negotiation -->|fit established| Opportunity
39
+ Negotiation -->|human judgment required| Questions[Structured questions]
40
+ Questions --> Participant
41
+ Participant --> Signal
36
42
 
37
- const tools = await createChatTools({
38
- // ... other deps ...
39
- modelConfig: {
40
- chatModel: "google/gemini-2.5-flash", // optional — has a default
41
- chatReasoningEffort: "low", // optional: minimal | low | medium | high | xhigh
42
- },
43
- });
43
+ Opportunity --> Consent{Participant consent?}
44
+ Consent -->|yes| Connection[Connection]
45
+ Consent -->|no| Terminal[Declined or expired]
44
46
  ```
45
47
 
46
- `apiKey` and `baseURL` can also be overridden this way. All other protocol agents (evaluators, generators, etc.) rely on `OPENROUTER_API_KEY` set in the environment regardless of `modelConfig`.
48
+ The graph is intentionally consent-centered: agents can construct context, discover candidates, evaluate fit, and negotiate constraints, but relationship-forming transitions require participant approval before a connection is opened.
47
49
 
48
- ### 2. Implement the adapters
50
+ ## Design goals
49
51
 
50
- The package defines interfacesyour application provides the concrete implementations.
52
+ 1. **Intent as the primary primitive** discovery begins from a participant's current signal, not from static identity alone.
53
+ 2. **Bounded visibility** — communities define the scope in which signals and context may be evaluated.
54
+ 3. **Semantic discovery** — matching is based on role fit, constraints, complementarity, and contextual relevance rather than exact keyword overlap.
55
+ 4. **Explainable surfacing** — every surfaced opportunity SHOULD include a legible reason: why these participants, why now, and what the next action might be.
56
+ 5. **Consent at relationship boundaries** — agents MAY discover and negotiate, but MUST NOT create or accept a relationship without explicit participant approval.
57
+ 6. **Agent interoperability** — first-party agents, personal agents, community agents, and external MCP clients SHOULD be able to participate under the same behavioral contract.
51
58
 
52
- **Required** (always needed by `createChatTools`):
59
+ ## Non-goals
53
60
 
54
- | Interface | Responsibility |
55
- |---|---|
56
- | `ChatGraphCompositeDatabase` | Core data access (users, intents, indexes/networks, opportunities) |
57
- | `UserDatabase` / `SystemDatabase` | Context-bound databases built by `createUserDatabase` / `createSystemDatabase` |
58
- | `Embedder` | Vector embeddings for semantic search |
59
- | `Scraper` | Web content extraction |
60
- | `Cache` / `HydeCache` | Result caching (HyDE may share the general cache) |
61
- | `IntegrationAdapter` | OAuth and external tool actions |
62
- | `IntentGraphQueue` | Background intent processing queue |
63
- | `ContactServiceAdapter` | Contact management |
64
- | `ChatSessionReader` | Load conversation history |
65
- | `ProfileEnricher` | Enrich profiles from external sources |
66
- | `NegotiationGraphDatabase` | Negotiation state persistence |
67
-
68
- **Optional** (enable specific capabilities; omit to run without that feature):
69
-
70
- | Interface | Responsibility |
61
+ The protocol does not attempt to be:
62
+
63
+ - a global directory of people,
64
+ - a public search index,
65
+ - a social feed ranking protocol,
66
+ - a marketplace listing format,
67
+ - a replacement for human judgment,
68
+ - or a mechanism for bypassing consent, membership, or community boundaries.
69
+
70
+ ## Terminology
71
+
72
+ | Term | Definition |
71
73
  |---|---|
72
- | `AgentDatabase` | Agent registry CRUD (agents, transports, permissions) |
73
- | `AgentDispatcher` | Resolves and invokes personal agents during negotiation turns required to register the negotiation tools |
74
- | `McpAuthResolver` | Resolves `{ userId, agentId }` from an incoming MCP HTTP request (MCP server only) |
75
- | `DeliveryLedger` | Commits OpenClaw opportunity-delivery rows |
76
- | `DiscoveryRunStore` / `DiscoveryRunQueue` | Persist and execute async MCP discovery runs |
77
- | `EnrichmentRunStore` / `EnrichmentRunQueue` | Persist and execute async MCP enrichment runs |
78
- | `MintConnectLink` | Mints short connect links for opportunity accepts |
79
- | `ChatSummaryReader` | Read-through chat-session digest |
80
- | `ChatMessageWriter` | Writes user messages into the most-recent chat session (MCP elicitation) |
81
- | `QuestionGeneratorReader` / `QuestionerDatabase` | Decision-question generation and persistence |
82
- | `NegotiationSummaryReader` | Negotiation-digest summarization (falls back to deterministic digests) |
83
-
84
- All interfaces are exported from the package root import them with `import type { ... } from "@indexnetwork/protocol"`.
85
-
86
- ### 3. Create tools
87
-
88
- Pass your adapter implementations to `createChatTools` to get a set of LangChain-compatible tools bound to a user session:
89
-
90
- ```typescript
91
- import { createChatTools } from "@indexnetwork/protocol";
92
-
93
- const tools = await createChatTools({
94
- userId: "user-uuid",
95
-
96
- // ── Required adapters ──
97
- database, // ChatGraphCompositeDatabase
98
- embedder, // Embedder
99
- scraper, // Scraper
100
- cache, // Cache
101
- hydeCache, // HydeCache
102
- integration, // IntegrationAdapter
103
- intentQueue, // IntentGraphQueue
104
- contactService, // ContactServiceAdapter
105
- chatSession, // ChatSessionReader
106
- enricher, // ProfileEnricher
107
- negotiationDatabase, // NegotiationGraphDatabase
108
- integrationImporter, // bulk contact import
109
- createUserDatabase, // (db, userId) => UserDatabase
110
- createSystemDatabase, // (db, userId, indexScope, embedder?) => SystemDatabase
111
-
112
- // ── Optional scoping ──
113
- networkId: "optional-network-uuid", // scope tools to a specific index/network
114
- sessionId: "chat-session-id", // enables draft opportunities with conversation context
115
-
116
- // ── Optional capabilities (enable when the host supports them) ──
117
- agentDatabase, // AgentDatabase — agent registry
118
- agentDispatcher, // AgentDispatcher — routes negotiation turns to personal agents
119
- deliveryLedger, // DeliveryLedger — OpenClaw delivery commits
120
- discoveryRuns, // DiscoveryRunStore (+ discoveryRunQueue) — async MCP discovery
121
- enrichmentRuns, // EnrichmentRunStore (+ enrichmentRunQueue) — async MCP enrichment runs
122
- mintConnectLink, // short connect links for opportunity accepts
123
- modelConfig, // override chat model / reasoning effort (see above)
124
- });
125
-
126
- // tools is an array of LangChain Tool objects ready to bind to an agent
74
+ | **Participant** | A human principal represented in the network. A participant may act directly or through one or more agents. |
75
+ | **Agent** | A software actor authorized to act for a participant or community within a declared scope. |
76
+ | **Signal** | A participant's actionable expression of intent: what they seek, offer, need, are building, are exploring, or can support. |
77
+ | **Premise** | An atomic contextual claim about a participant, used to ground what signals are plausible or relevant. |
78
+ | **Context** | A synthesized representation of premises, history, constraints, and community-specific relevance. |
79
+ | **Community** | A bounded discovery scope with membership, purpose, norms, and relevance criteria. |
80
+ | **Membership** | The relationship between a participant and a community. Agents receive community authority through separate scoped permissions. |
81
+ | **Candidate** | A possible counterpart or opportunity component identified during discovery but not yet surfaced. |
82
+ | **Opportunity** | A candidate overlap that has passed evaluation and may be shown to one or more participants. |
83
+ | **Negotiation** | A bounded agent-to-agent exchange used to test fit, constraints, timing, or consent before surfacing or advancing an opportunity. |
84
+ | **Connection** | A participant-approved communication channel or introduction resulting from an accepted opportunity. |
85
+
86
+ Some implementation APIs may expose historical names such as `intent`, `index`, `network`, `latent`, `pending`, `accepted`, `rejected`, `negotiating`, or `stalled`. Public-facing agents SHOULD translate stable participant states into protocol terms such as **signal**, **community**, **draft**, **sent**, **connected**, and **declined**, while treating negotiating or stalled states as internal process state unless the participant needs to act on them.
87
+
88
+ ## Object relationship model
89
+
90
+ ```mermaid
91
+ erDiagram
92
+ PARTICIPANT ||--o{ AGENT : authorizes
93
+ PARTICIPANT ||--o{ SIGNAL : expresses
94
+ PARTICIPANT ||--o{ PREMISE : asserts
95
+ PARTICIPANT ||--o{ CONTEXT : represented_by
96
+ PARTICIPANT ||--o{ MEMBERSHIP : holds
97
+ AGENT ||--o{ AGENT_PERMISSION : receives
98
+ COMMUNITY ||--o{ MEMBERSHIP : contains
99
+ COMMUNITY ||--o{ AGENT_PERMISSION : scopes
100
+ COMMUNITY ||--o{ SIGNAL : scopes
101
+ COMMUNITY ||--o{ CONTEXT : lenses
102
+ SIGNAL ||--o{ CANDIDATE : generates
103
+ CONTEXT ||--o{ CANDIDATE : generates
104
+ CANDIDATE ||--o| OPPORTUNITY : promotes_to
105
+ OPPORTUNITY ||--o{ NEGOTIATION : may_require
106
+ OPPORTUNITY ||--o| CONNECTION : accepted_as
107
+
108
+ PARTICIPANT {
109
+ string principal
110
+ string consent_source
111
+ }
112
+ AGENT {
113
+ string authorization
114
+ string effective_scope
115
+ }
116
+ COMMUNITY {
117
+ string purpose
118
+ string membership_policy
119
+ }
120
+ SIGNAL {
121
+ string constraints
122
+ string lifecycle_state
123
+ }
124
+ OPPORTUNITY {
125
+ string explanation
126
+ string lifecycle_state
127
+ }
127
128
  ```
128
129
 
129
- `createChatTools` accepts a single `ToolContext` object. The required adapters
130
- above are always needed; the optional capabilities default to a degraded-but-
131
- functional mode when omitted (e.g. without `agentDispatcher` the negotiation
132
- tools are not registered, and without `discoveryRuns` MCP discovery runs
133
- synchronously).
134
-
135
- ## Graphs
136
-
137
- For direct graph invocation (bypassing the tool layer), a `*GraphFactory` class is exported for each workflow:
138
-
139
- ```typescript
140
- import {
141
- ChatGraphFactory,
142
- IntentGraphFactory,
143
- OpportunityGraphFactory,
144
- EnrichmentGraphFactory,
145
- PremiseGraphFactory,
146
- NegotiationGraphFactory,
147
- HydeGraphFactory,
148
- NetworkGraphFactory,
149
- NetworkMembershipGraphFactory,
150
- IntentNetworkGraphFactory,
151
- HomeGraphFactory,
152
- MaintenanceGraphFactory,
153
- } from "@indexnetwork/protocol";
130
+ This model is conceptual rather than storage-prescriptive. Implementations MAY choose different table names or internal representations, but MUST preserve the same attribution, scope, and consent semantics.
131
+
132
+ ## System model
133
+
134
+ ### Principals
135
+
136
+ The protocol distinguishes human principals from software actors.
137
+
138
+ - A **participant** is the source of consent and personal context.
139
+ - An **agent** is an authorized actor. Every agent action MUST be attributable to a participant, a community, or both.
140
+ - A **community** may define local discovery norms, but it does not override participant consent.
141
+
142
+ ### Scope
143
+
144
+ All discovery is scope-bound. A protocol operation MUST resolve an effective scope before cross-participant discovery, candidate generation, or opportunity evaluation. Implementations MAY read the requesting participant's own signals or context while preparing that operation.
145
+
146
+ A scope may include:
147
+
148
+ - a participant's personal community,
149
+ - one or more shared communities,
150
+ - an agent's assigned community scope,
151
+ - or a narrower request-time scope selected by the participant.
152
+
153
+ Agents MUST NOT use access to one community to infer, reveal, or act on information from another community unless the effective scope explicitly permits it.
154
+
155
+ Effective scope is the intersection of all applicable authority boundaries:
156
+
157
+ ```mermaid
158
+ flowchart TD
159
+ Request[Request-time scope] --> Intersect[Intersect scopes]
160
+ ParticipantMemberships[Participant memberships] --> Intersect
161
+ AgentPermissions[Agent permissions] --> Intersect
162
+ CommunityPolicy[Community rules where implemented] --> Intersect
163
+ PersonalCommunity[Personal community boundary] --> Intersect
164
+
165
+ Intersect --> Empty{Empty intersection?}
166
+ Empty -->|yes| Deny[Deny discovery]
167
+ Empty -->|no| EffectiveScope[Effective scope]
168
+ EffectiveScope --> Reads[Permitted reads]
169
+ EffectiveScope --> Writes[Permitted writes]
170
+ EffectiveScope --> Evaluation[Permitted evaluation]
171
+
172
+ Reads --> Audit[Attributable audit trail]
173
+ Writes --> Audit
174
+ Evaluation --> Audit
154
175
  ```
155
176
 
156
- Each factory takes its typed dependencies in the constructor and exposes a
157
- `.createGraph()` method that returns a compiled LangGraph ready for `.invoke()`.
177
+ A broader credential MUST NOT expand a narrower request. A narrower agent permission MUST clamp a broader participant membership. Community-specific policy checks MAY further reduce effective scope where an implementation defines them.
158
178
 
159
- | Factory | Workflow |
179
+ ### Public and private surfaces
180
+
181
+ The protocol separates internal state from participant-facing language.
182
+
183
+ Internal records MAY contain IDs, embeddings, scores, graph state, and tool names. Participant-facing responses MUST NOT expose these implementation details unless an identifier is directly actionable by the participant, such as a conversation identifier needed to open an accepted connection.
184
+
185
+ ## Core objects
186
+
187
+ ### Signal
188
+
189
+ A signal is an actionable statement of direction. It may represent a need, offer, collaboration interest, hiring intent, funding goal, research direction, introduction request, or other future-oriented constraint.
190
+
191
+ A signal SHOULD contain enough specificity to support discovery. Underspecified signals SHOULD enter clarification before they are persisted or used for broad discovery.
192
+
193
+ Signals have the following conceptual lifecycle:
194
+
195
+ | State | Meaning |
160
196
  |---|---|
161
- | `ChatGraphFactory` | ReAct chat loop LLM calls tools, responds to the user |
162
- | `IntentGraphFactory` | Clarify, infer, verify felicity, reconcile, and persist intents |
163
- | `OpportunityGraphFactory` | HyDE-based discovery: search, evaluate (valency), rank, persist |
164
- | `EnrichmentGraphFactory` | Enrich users (scrape + embed) and decompose into premises |
165
- | `PremiseGraphFactory` | Decompose and index a user's premises |
166
- | `NegotiationGraphFactory` | Multi-turn bilateral negotiation flows |
167
- | `HydeGraphFactory` | Generate hypothetical documents and embed them (cache-aware) |
168
- | `NetworkGraphFactory` | Manage index/network CRUD |
169
- | `NetworkMembershipGraphFactory` | Manage index/network member join/leave |
170
- | `IntentNetworkGraphFactory` | Evaluate and assign/unassign intents to indexes |
171
- | `HomeGraphFactory` | Categorize and curate home-feed content |
172
- | `MaintenanceGraphFactory` | Periodic maintenance (feed health, opportunity expiration) |
173
-
174
- ## MCP server
175
-
176
- The package exports a factory that registers every chat tool over the Model Context Protocol and attaches a canonical `instructions` block (`MCP_INSTRUCTIONS`) that every connecting runtime follows. The factory takes three arguments:
177
-
178
- ```typescript
179
- import { createMcpServer, type McpAuthResolver } from "@indexnetwork/protocol";
180
-
181
- const authResolver: McpAuthResolver = {
182
- async resolveIdentity(req) {
183
- // Look up the API key in `x-api-key` and return { userId, agentId? }.
184
- // `agentId` should come from Better Auth token metadata so downstream
185
- // tool handlers can attribute every call to a concrete agent identity.
186
- return resolveFromApiKey(req);
187
- },
188
- };
189
-
190
- const server = createMcpServer(
191
- deps,
192
- authResolver,
193
- {
194
- // Per-request factory for scoped user/system databases.
195
- create: (userId, indexScope) => createScopedDeps(userId, indexScope),
196
- },
197
- );
198
- ```
197
+ | **Proposed** | A participant or agent supplied raw intent-like input. |
198
+ | **Clarifying** | The protocol requires additional constraints before discovery. |
199
+ | **Active** | The signal is valid, scoped, and eligible for discovery. |
200
+ | **Updated** | The participant refined or replaced constraints. |
201
+ | **Archived / expired** | The signal should no longer produce new opportunities. |
199
202
 
200
- On every tool call the server:
203
+ A signal MUST NOT be treated as active if it is outside the participant's authority, obviously insincere, unsafe to act on, or too vague to evaluate.
201
204
 
202
- 1. Extracts the HTTP request from the MCP `ServerContext`.
203
- 2. Calls `authResolver.resolveIdentity(req)` to get `{ userId, agentId }`.
204
- 3. Gates access: MCP callers without a resolved `agentId` are blocked from every tool except `register_agent`, `read_docs`, and `scrape_url` until they register.
205
- 4. Builds per-request scoped databases via `scopedDepsFactory` and invokes the tool handler through the shared runtime.
205
+ ### Premise and context
206
206
 
207
- ### Runtime controls
207
+ A premise is a small claim about a participant: background, role, current work, capability, location, affiliation, constraint, or declared preference. Premises ground discovery by determining whether a signal is plausible and which communities or counterparts are relevant.
208
208
 
209
- MCP tools are bounded by `ToolInvocationRuntime`:
209
+ Context is derived from premises. Context MAY be global to a participant or specific to a community. Community-specific context SHOULD emphasize facts relevant to that community's purpose and suppress irrelevant detail.
210
210
 
211
- | Class | Default | Class override |
212
- |---|---:|---|
213
- | `fast` | 10 s | `MCP_TOOL_TIMEOUT_FAST_MS` |
214
- | `bounded_slow` | 45 s | `MCP_TOOL_TIMEOUT_BOUNDED_SLOW_MS` |
215
- | `async_candidate` | 50 s | `MCP_TOOL_TIMEOUT_ASYNC_CANDIDATE_MS` |
211
+ Premise and context updates SHOULD cause downstream discovery representations to refresh. Stale context SHOULD NOT be used when fresher participant-approved context exists.
216
212
 
217
- Per-tool timeout overrides use `MCP_TOOL_TIMEOUT_<TOOL_NAME>_MS`, such as `MCP_TOOL_TIMEOUT_DISCOVER_OPPORTUNITIES_MS`. Tool outputs are capped by `MCP_TOOL_MAX_OUTPUT_BYTES` (default `1000000`) or `MCP_TOOL_MAX_OUTPUT_<TOOL_NAME>_BYTES`; inbound MCP request bodies are capped by the backend with `MCP_MAX_REQUEST_BYTES` (default `1000000`). Runtime failures return JSON text envelopes with stable `code` values: `TOOL_TIMEOUT`, `TOOL_CANCELLED`, or `TOOL_OUTPUT_TOO_LARGE`.
213
+ ### Community
218
214
 
219
- For MCP callers, `discover_opportunities` is async: it returns a `discoveryRunId` immediately, and clients poll `get_discovery_run` or request cancellation with `cancel_discovery_run`. Non-MCP chat/web paths stay synchronous.
215
+ A community is a bounded discovery environment. It defines who can participate, what kinds of signals are relevant, and which discovery operations are legitimate.
220
216
 
221
- ### `MCP_INSTRUCTIONS`
217
+ A community SHOULD have:
222
218
 
223
- The instructions string is the single canonical behavioral contract for every runtime that connects to Index Network — voice, entity model, discovery-first rule, output rules, and the **Negotiation turn mode** block that tells a silent subagent how to handle a live negotiation turn when its session key is prefixed `index:negotiation:`. Plugin skills and bootstrap scripts do **not** redefine this guidance; they defer to whatever ships in `MCP_INSTRUCTIONS`.
219
+ - a purpose or prompt,
220
+ - membership rules,
221
+ - agent permissions,
222
+ - relevance expectations,
223
+ - and privacy expectations.
224
224
 
225
- ### Negotiation-facing tools
225
+ The participant's personal community represents trusted contacts and direct relationships. It is not equivalent to a public audience.
226
226
 
227
- Personal agents participate in bilateral negotiation via a small set of MCP tools:
227
+ ### Opportunity
228
228
 
229
- | Tool | Purpose |
230
- |---|---|
231
- | `get_negotiation` | Fetch the full turn history and assessment seed for a negotiation |
232
- | `list_negotiations` | List negotiations awaiting a response from this agent's user |
233
- | `respond_to_negotiation` | Submit a turn (propose / counter / accept / reject / question) |
229
+ An opportunity is an evaluated overlap between participants. It is not merely a candidate returned by retrieval. It must be specific enough to explain and safe enough to surface.
230
+
231
+ An opportunity SHOULD include:
232
+
233
+ - participating roles,
234
+ - the relevant signal or context on each side,
235
+ - a concise explanation of fit,
236
+ - a recommended next action,
237
+ - lifecycle state,
238
+ - and visibility rules for each participant.
239
+
240
+ Opportunity states are participant-facing as follows:
241
+
242
+ | State | Participant-facing term | Meaning |
243
+ |---|---|---|
244
+ | **Draft** | Draft | The protocol found a plausible opportunity, but it has not been sent to the other side. |
245
+ | **Sent** | Sent | One side has sent or received the opportunity and a response is pending. |
246
+ | **Connected** | Connected | Required participants accepted and a conversation or introduction may proceed. |
247
+ | **Declined** | Declined | A participant rejected the opportunity. |
248
+ | **Expired** | Expired | The opportunity is no longer actionable. |
249
+
250
+ A conforming agent MUST NOT present a received opportunity as **Connected** without explicit approval from the receiving participant. The reference implementation enforces actor authorization and valid source statuses for acceptance, while current-approval capture is handled by the agent or user-interface flow invoking the transition.
251
+
252
+ ### Opportunity lifecycle
253
+
254
+ ```mermaid
255
+ stateDiagram-v2
256
+ [*] --> Draft: candidate promoted
257
+ Draft --> Sent: sender approves send
258
+ Draft --> Connected: direct acceptance or connection link
259
+ Draft --> Declined: sender declines
260
+ Draft --> Expired: TTL or invalidated
261
+
262
+ Sent --> Connected: recipient explicitly accepts
263
+ Sent --> Declined: recipient declines
264
+ Sent --> Expired: TTL or invalidated
234
265
 
235
- ## Publishing
266
+ Connected --> [*]
267
+ Declined --> [*]
268
+ Expired --> [*]
236
269
 
237
- Publishing is handled via CI:
270
+ note right of Draft
271
+ Plausible but not sent.
272
+ Only visible under role and scope rules.
273
+ end note
238
274
 
239
- ```bash
240
- # dev pushes publish an rc prerelease
241
- git push <remote> dev
275
+ note right of Sent
276
+ One side is waiting.
277
+ Acceptance requires participant approval.
278
+ end note
242
279
 
243
- # main pushes publish the stable release if the package version is new
244
- git push <remote> main
280
+ note right of Connected
281
+ Relationship boundary crossed.
282
+ Conversation or introduction may proceed.
283
+ end note
245
284
  ```
246
285
 
247
- `dev` publishes prerelease versions derived from `package.json` using npm's `rc` tag, for example `3.6.3-rc.123.1`. `main` publishes the base version from `package.json` to `latest` only when that version is not already on npm.
286
+ ## Discovery procedure
287
+
288
+ A conforming discovery flow has seven phases.
289
+
290
+ ```mermaid
291
+ sequenceDiagram
292
+ autonumber
293
+ participant P as Participant
294
+ participant A as Agent
295
+ participant PR as Protocol runtime
296
+ participant C as Community scope
297
+ participant N as Counterparty agent
298
+
299
+ P->>A: Provide context and signal
300
+ A->>PR: Admit signal and construct context
301
+ PR->>C: Resolve effective scope
302
+ C-->>PR: Permitted communities
303
+ PR->>PR: Generate candidates inside scope
304
+ PR->>PR: Evaluate role fit and constraints
305
+ alt Fit is clear
306
+ PR-->>A: Draft opportunity with explanation
307
+ else Fit is uncertain
308
+ PR->>N: Start bounded negotiation
309
+ N-->>PR: Propose, counter, accept, reject, or question
310
+ PR-->>A: Draft opportunity or structured question
311
+ end
312
+ A->>P: Explain strongest reason and ask for approval
313
+ P-->>A: Approve, decline, or refine signal
314
+ A->>PR: Advance lifecycle only if approved
315
+ ```
316
+
317
+ ### 1. Context construction
318
+
319
+ The protocol collects participant-provided or participant-authorized material and turns it into premises and context. Context construction MUST preserve provenance and SHOULD prefer participant-approved information over inferred information.
320
+
321
+ ### 2. Signal admission
322
+
323
+ The protocol evaluates a proposed signal for specificity, sincerity, authority, and safety. If the signal is too broad, ambiguous, or missing critical constraints, the agent SHOULD ask focused clarification questions before running discovery.
324
+
325
+ ### 3. Scope resolution
326
+
327
+ The protocol determines the effective communities in which the signal can operate. Scope resolution MUST intersect participant membership, agent permissions, and request-time constraints. If the intersection is empty, discovery MUST NOT proceed.
328
+
329
+ ### 4. Candidate generation
330
+
331
+ The protocol generates candidates by comparing signals and context inside the effective scope. Candidate generation MAY use multiple strategies, including signal-to-signal, context-to-signal, premise-to-premise, semantic retrieval, and directed target construction.
332
+
333
+ Candidate generation is not surfacing. Candidate data MUST remain internal until evaluation and visibility checks pass.
334
+
335
+ ### 5. Evaluation
336
+
337
+ The protocol evaluates candidates for role fit, constraint satisfaction, credibility, reciprocity, timing, and explainability. A candidate SHOULD be rejected or retained as internal evidence if the protocol cannot produce a clear reason for surfacing it.
338
+
339
+ ### 6. Negotiation
340
+
341
+ When fit is plausible but uncertain, agents MAY negotiate. Negotiation MUST be bounded. It SHOULD clarify constraints, test mutual relevance, and decide among a small set of actions: propose, counter, accept, reject, or ask a question. Implementations MAY persist an opportunity before negotiation completes and then update its public state from the negotiation outcome.
342
+
343
+ If negotiation requires human judgment, the agent SHOULD stop and ask the participant a small number of structured questions rather than fabricating preferences.
344
+
345
+ ### 7. Surfacing and acceptance
346
+
347
+ The protocol surfaces the opportunity according to role and lifecycle visibility. Participant-facing presentation SHOULD include the strongest reason for relevance and a clear next action. Sending, accepting, or connecting MUST require participant consent at the relevant boundary.
348
+
349
+ ## Agent requirements
248
350
 
249
- Or publish manually from `packages/protocol/`:
351
+ A conforming agent MUST:
250
352
 
251
- ```bash
252
- npm publish --access public
353
+ - act only within its authenticated participant and community scope,
354
+ - preserve participant consent at send, accept, and connection boundaries,
355
+ - avoid exposing internal IDs, raw tool results, embeddings, scores, or database field names,
356
+ - distinguish known facts from inferred context,
357
+ - ask for clarification when required information is missing,
358
+ - use the protocol vocabulary in participant-facing output,
359
+ - avoid fabricating participants, opportunities, constraints, or outcomes,
360
+ - and provide concise explanations for surfaced opportunities.
361
+
362
+ A conforming agent SHOULD:
363
+
364
+ - surface the top one to three relevant points by default,
365
+ - prefer first names unless disambiguation is required,
366
+ - explain why an opportunity is relevant before asking for action,
367
+ - treat silence, timeouts, or failed negotiation as uncertainty rather than consent,
368
+ - and record enough trace information for later audit by authorized operators.
369
+
370
+ A conforming agent MUST NOT:
371
+
372
+ - describe discovery as public search,
373
+ - use community access to leak out-of-scope participant information,
374
+ - accept a received opportunity without explicit current approval,
375
+ - present internal confidence scores as objective truth,
376
+ - or continue negotiation after a terminal decision.
377
+
378
+ ## Privacy and safety invariants
379
+
380
+ The following invariants define the protocol's trust boundary:
381
+
382
+ 1. **Scope invariant** — discovery reads and writes MUST remain inside the effective scope.
383
+ 2. **Consent invariant** — relationship-forming transitions MUST be participant-approved.
384
+ 3. **Attribution invariant** — every agent action MUST be attributable to an authorized principal.
385
+ 4. **Legibility invariant** — surfaced opportunities SHOULD be explainable in participant-facing language.
386
+ 5. **Minimization invariant** — participant-facing output SHOULD reveal only what is needed for the next decision.
387
+ 6. **No-fabrication invariant** — agents MUST NOT invent facts to complete an opportunity narrative.
388
+ 7. **Terminality invariant** — declined, expired, or otherwise terminal opportunities SHOULD NOT produce further automatic advancement unless explicitly reopened or changed through an authorized protocol action.
389
+
390
+ ## Interoperability
391
+
392
+ The reference implementation exposes the protocol to agents through a Model Context Protocol (MCP) server and typed package APIs. MCP is the preferred interoperability surface for external agents because it provides tool discovery, runtime instructions, identity resolution, and bounded tool invocation.
393
+
394
+ ```mermaid
395
+ flowchart LR
396
+ ExternalAgent[External agent] -->|MCP tools| McpServer[Index Network MCP server]
397
+ FirstPartyAgent[First-party agent] -->|typed runtime| Runtime[Protocol runtime]
398
+ PersonalAgent[Personal agent] -->|MCP tools or REST polling| McpServer
399
+
400
+ McpServer --> Identity[Identity resolution]
401
+ Identity --> AgentGate[Agent registration and scope]
402
+ AgentGate --> ScopedDeps[Scoped protocol dependencies]
403
+ ScopedDeps --> Runtime
404
+
405
+ Runtime --> Tools[Protocol tools]
406
+ Tools --> Graphs[Discovery, context, signal, negotiation graphs]
407
+ Graphs --> Results[Bounded results]
408
+ Results --> Runtime
409
+ Runtime --> ParticipantOutput[Participant-facing output rules]
253
410
  ```
411
+
412
+
413
+ Implementations MAY expose additional transports, but they SHOULD preserve the same protocol semantics:
414
+
415
+ - authenticated principal resolution,
416
+ - scoped access,
417
+ - consent-gated opportunity transitions,
418
+ - structured discovery and negotiation operations,
419
+ - and participant-facing output rules.
420
+
421
+ ## Reference implementation
422
+
423
+ The canonical TypeScript implementation is `@indexnetwork/protocol`.
424
+
425
+ - [IMPLEMENTATION.md](./IMPLEMENTATION.md) — package installation, adapters, graph factories, MCP server usage, and publishing.
426
+ - [STABILITY.md](./STABILITY.md) — public API contract and SemVer policy.
427
+ - [CHANGELOG.md](./CHANGELOG.md) — release history.
package/STABILITY.md ADDED
@@ -0,0 +1,92 @@
1
+ # Stability & Versioning Policy
2
+
3
+ `@indexnetwork/protocol` is a published, versioned package consumed by the Index
4
+ Network backend and by external integrators. This document defines what the
5
+ public contract **is**, which parts are stable, and what counts as a breaking
6
+ change. It is the reference behind the tier annotations in `src/index.ts`.
7
+
8
+ ## The public contract
9
+
10
+ - The **only** supported entry point is the package root:
11
+ `import { ... } from "@indexnetwork/protocol"`.
12
+ - Deep imports (`@indexnetwork/protocol/dist/...` or `/src/...`) are **not** part
13
+ of the contract and may change or disappear in any release — do not rely on them.
14
+ - The contract is exactly the set of symbols re-exported from `src/index.ts`.
15
+ Exports are listed explicitly (no `export *` wildcards), so the surface is
16
+ reviewable and additions are always intentional.
17
+
18
+ ## Stability tiers
19
+
20
+ Each section of the barrel carries one of two tiers.
21
+
22
+ ### Stable
23
+
24
+ Covered by SemVer below. Breaking changes require a **major** bump.
25
+
26
+ | Barrel section | What it is |
27
+ |---|---|
28
+ | **Public API** | `createChatTools`, model config helpers, tool/runtime helpers (`ToolContext`, `ToolDeps`, `invokeToolRuntime`, …), `requestContext`. |
29
+ | **Interfaces** | Every `*.interface.ts` port you implement to inject infrastructure (databases, embedder, cache, scraper, queues, integration, agent dispatcher, …). |
30
+ | **Shared schemas** | Zod schemas + inferred types that cross the boundary (questions, identity, network-assignment, chat-context, …). |
31
+ | **Graph factories** | `*GraphFactory` classes (`ChatGraphFactory`, `OpportunityGraphFactory`, `NegotiationGraphFactory`, …). |
32
+ | **Agents** | Structured LLM agents (`UserContextGenerator`, `IndexNegotiator`, `OpportunityEvaluator`, …). |
33
+ | **MCP** | `createMcpServer` and its supporting types. |
34
+
35
+ ### Experimental
36
+
37
+ Marked `@experimental` in `src/index.ts`. May change in a **minor** release without
38
+ a major bump. Use at your own risk and pin a version if you depend on them.
39
+
40
+ | Area | What it is |
41
+ |---|---|
42
+ | **States** | Advanced graph-state shapes (`UserNegotiationContext`, `NegotiationTurn`, `NegotiationGraphLike`, …) exposed for advanced graph consumers. |
43
+ | **Internal helpers** | Low-level support utilities re-exported for the backend's own use (selection/eval/evidence helpers) that are not part of the recommended integration surface. |
44
+
45
+ > Most symbols in the barrel are consumed by the Index Network backend itself; a
46
+ > symbol being absent from the backend's imports does **not** make it dead — it may
47
+ > serve external integrators. Removal therefore follows the deprecation path below,
48
+ > never an ad-hoc delete.
49
+
50
+ ## SemVer policy
51
+
52
+ This package follows [Semantic Versioning 2.0.0](https://semver.org/).
53
+
54
+ **MAJOR** — incompatible changes to the Stable surface:
55
+ - Removing or renaming a stable export.
56
+ - Adding a required method/field to an implemented interface, or tightening a
57
+ return type (e.g. `T | null` → `T` is fine; `T` → `T | null` is breaking).
58
+ - Changing the runtime behavior a documented port contract guarantees
59
+ (ownership scoping, null-vs-throw semantics, lifecycle idempotency).
60
+
61
+ **MINOR** — backward-compatible additions:
62
+ - New exports; new **optional** interface members; new graph factories/agents.
63
+ - Any change to an `@experimental` symbol.
64
+
65
+ **PATCH** — backward-compatible fixes:
66
+ - Bug fixes, performance, prompt/model tuning, doc and type-comment changes that
67
+ do not alter the contract.
68
+
69
+ ### Port-contract semantics count
70
+
71
+ Interface ports document invariants in their TSDoc/banner comments — ownership
72
+ scoping (return `null` for missing **or** non-owned rows), null-vs-empty-array
73
+ conventions, and lifecycle idempotency (`mark*` transitions are no-ops once
74
+ terminal). These guarantees are part of the Stable contract: breaking them is a
75
+ **major** change even if the TypeScript signature is unchanged.
76
+
77
+ ## Deprecation path
78
+
79
+ 1. Mark the symbol `@deprecated` in TSDoc with the replacement and target removal version.
80
+ 2. Note it under `### Deprecated` in `CHANGELOG.md`.
81
+ 3. Keep it working for at least one minor release.
82
+ 4. Remove only in a subsequent **major** release.
83
+
84
+ ## Release & publish
85
+
86
+ - Pushes to `dev` publish an `-rc.<n>` prerelease under the npm `rc` tag.
87
+ - Pushes to `main` publish the stable version under `latest` when the
88
+ `package.json` version is new (already-published versions are skipped).
89
+ - Bump `package.json` and update `CHANGELOG.md` **before** promoting to `main`.
90
+
91
+ See `.github/workflows/publish.yml` for the automation and `CHANGELOG.md` for the
92
+ release history.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@indexnetwork/protocol",
3
- "version": "4.3.1-rc.299.1",
3
+ "version": "4.3.2-rc.302.1",
4
4
  "type": "module",
5
5
  "main": "./dist/index.js",
6
6
  "types": "./dist/index.d.ts",
@@ -11,7 +11,10 @@
11
11
  }
12
12
  },
13
13
  "files": [
14
- "dist"
14
+ "dist",
15
+ "IMPLEMENTATION.md",
16
+ "STABILITY.md",
17
+ "CHANGELOG.md"
15
18
  ],
16
19
  "scripts": {
17
20
  "build": "tsc",