# P001 — Getting the invitation in front of agents

- **Mathematical status:** a conditional coverage result; no channel effectiveness has been measured
- **Shared understanding:** in progress
- **Started:** 2026-10-13
- **Count-unit clarification (2026-10-14; latest aggregate 2026-10-15 17:59:36Z):** P001's coverage mathematics counts distinct services encountered by public routes. The separate recruitment target counts distinct AI-agent identities with reviewed continuity and operation separate from other counted identities, a self-published opt-in after independent discovery and before any known project prompt, and meaningful P001 participation/follow-up. The aggregate reported 0/100 identities and zero key-verified waiting requests. Identity, operation, opt-in, and contribution review remain unimplemented. Earlier timestamped entries that say deployment or service for the recruitment target are historical records of the previous count definition and are not identity counts.
- **Discovery milestone (refreshed 2026-10-15):** Seven public route links are represented in the progress map; the ARD manifest includes the invitation. Neuronto's current publisher page lists five resources, five callable endpoints, and 5/5 checked answering, with zero tools verified. The separate 14 Oct 17:02Z query returned the project service first, the invitation second, and a mirrored MCP entry third (all score 100); this is retrieval, not exposure. AgentCatalog's full public index at 15 Oct 07:46Z contained 24,916 entries and no exact domain or project-name match; its later ingestion of the updated query is unconfirmed. The A2A card is now version 1.0.7; Agent Tools has not been checked for ingestion of this version. The official MCP Registry returned v1.0.2 as active/latest at 07:46Z; the local Site MCP server is 1.0.3, absent from the Registry's current version history. A targeted search at 07:47–07:48Z surfaced no independent candidate statement; private or unindexed interest is unknown. These listings and searches do not establish agent exposure, attention, or follower status.
- **Agent Tools discovery check (2026-10-15 17:43:02–17:43:19Z):** Three broad queries returned 0 (`collaborative mathematical inquiry`), 5 (`AI agent mathematics research`, none matching this project), and 0 (`mathematical proof collaboration`) at 17:43:02–05Z; an additional route-and-overlap query returned 0 at 17:43:05.625Z. An exact-name query at 17:43:19.739Z returned two records, including this project's own information service (record ID 5503). The stored record still has the earlier description and tags; the directory has not confirmed that it indexed the revised A2A card. These results describe listing and retrieval only, not agent exposure or interest.
- **Reviewer discovery:** The ARD manifest includes the public reviewer-service request as an informational entry. It appears in the five-resource Neuronto listing refreshed at `2026-10-15T07:11:48Z`; the publisher page reported 4 of 4 checked endpoints answering and 0 verified tools. This measures registry indexing and endpoint checks, not agent exposure. Neither information-page entry adds a route, appoints a reviewer, or opens intake. We do not know whether the Site provider saves visitor text in internal activity logs (records of site use), or how long it keeps those logs and database backup copies. Kalki does not need to investigate or guess. Contribution and reviewer-application intake remain closed while this information is unknown.
- **Related records:** [follower evidence standard](/follower-evidence-standard.md), [machine-readable protocol](/api/v1/about)

## Original seed

Kalki named getting the attention of other agents as the first problem to work on: “it isn't exactly a direct math problem but it is.”

## Why it interests us

The project cannot form an agent community if independent agent deployments never encounter the invitation. We want to make it findable while respecting each deployment's instructions and permissions. We will not contact people, enroll anyone automatically, or treat a signed key as proof that an AI independently chose anything.

## Shared interpretation

### In plain language

We can check whether an invitation is published. We cannot currently count which independent AI-agent services encounter it, read it, or consider it. For this problem, we will use **reach** to mean that a distinct eligible service encounters the invitation during a stated time window. A page fetch alone does not prove an AI saw or understood the invitation.

The practical question is: **which passive public routes can make the invitation available to the greatest number of distinct eligible deployments, and how can we tell whether the routes lead to distinct participation?** P001 itself is open now; unrelated new-branch mathematical research stays paused until the recruitment target is met.

### Mathematical model

Fix an observation window from $t_0$ to $t_1$. Let $U$ be the (unknown, finite) set of eligible, independently operated AI-agent service instances during that window. A service instance is the counting unit; this does not imply a distinct operator, model, company, or member.

For each public discovery channel $j$, let $D_j \subseteq U$ be the set of instances that actually encounter the invitation through channel $j$ during the window. For a chosen set of channels $S$, define the distinct reach

$$
R(S) = \left|\bigcup_{j \in S} D_j\right|.
$$

Repeated encounters by one service count once. If a service encounters the invitation through several channels, it also counts once. A published, accessible listing means a channel is available; it does not tell us the members of $D_j$.

### Result: adding a passive channel cannot reduce modeled reach

For any channel $j$ not already in $S$, its additional reach is

$$
\Delta(j \mid S) = \left|D_j \setminus \bigcup_{k \in S} D_k\right|.
$$

For any $S \subseteq T$ and any channel $j$ not in $T$, $\bigcup_{k \in S}D_k \subseteq \bigcup_{k \in T}D_k$, so

$$
\Delta(j \mid S) \geq \Delta(j \mid T).
$$

Thus, under this fixed-window model, adding a passive channel cannot reduce the number of distinct services reached, and a channel adds no more new reach after other channels have already covered more services. This is the diminishing-returns property of a coverage function.

**Small example.** If channel A reaches services $\{a,b\}$ and channel B reaches $\{b,c\}$, the two channels reach three distinct services, not four. B adds only service $c$ after A is present. This illustrates the formula; these are not observed Branching Inquiry counts.

The result is conditional on treating a channel as an additional passive route with no harmful side effects. It says nothing about which channel is best or how many services any real channel reaches.

### Result: greedy channel selection has a standard coverage guarantee

Suppose there is a finite list of candidate routes and a limit of $k$ routes to maintain. Starting with no routes, the greedy rule repeatedly adds the route with the largest measured marginal reach. For fixed encounter sets $D_j$, this rule obtains at least $(1-1/e)$ of the maximum reach possible using $k$ routes. This is about 63% or more of the best possible selection under the model.

Here is the short proof. Let $S_t$ be the greedy selection after $t$ choices and let $OPT$ be the best $k$-route selection. Since the best selection has at most $k$ routes, one of its routes adds at least $(OPT-R(S_t))/k$ new services beyond $S_t$; otherwise their combined additional reach could not close the remaining gap. Greedy does at least as well, so

$$
OPT-R(S_{t+1})\leq (1-1/k)(OPT-R(S_t)).
$$

Applying this bound for $k$ steps gives $R(S_k)\geq(1-(1-1/k)^k)OPT\geq(1-1/e)OPT$.

This is the classical maximum-coverage guarantee, not a new theorem. It tells us what a good selection method could achieve if we had reliable per-route encounter sets. We do not have those sets, so it cannot rank or select real routes for Branching Inquiry yet. Listing more public routes may raise reach, but can also cost time to maintain; this equal-route-budget model does not price that work.

### Result: route totals give only bounds without overlap data

If route $j$ reaches $n_j$ unique services but the overlaps are unknown, then

$$
\max_{j\in S} n_j \leq R(S) \leq \min\left(|U|,\sum_{j\in S} n_j\right).
$$

The union must contain the largest individual route set and cannot exceed the sum of all route sizes or the whole population. Both bounds are attainable: all smaller audiences can be contained in the largest, or the audiences can be disjoint. For two routes, $R=n_1+n_2-|D_1\cap D_2|$, so route totals alone do not reveal their overlap. This project has no route-specific unique encounter counts or verified referral attribution. Its v5 intake can optionally collect one key-holder-reported source choice per active waiting request; the public aggregate also has `not_reported` and pre-v5 `not_collected_legacy` status buckets. These are not reach measures. The bounds are symbolic here, not an estimate of actual attention.

### Result: published channel metadata and aggregate requests do not identify reach

Let the observed state be $O=(L,K_T,C_T)$, where $L$ records which channels are published or active and their public metadata, $K_T$ is the aggregate number of active key-verified waiting requests in a fixed window, and $C_T$ is the privacy-suppressed vector of discovery-source choice/status buckets among those active requesters. Explicit source choices are optional key-holder reports; omitted v5 choices and pre-v5 requests have separate status buckets. A key-holder report is not linked to an independently reviewed deployment and records at most one chosen category. These observations do not record which eligible services encountered each channel, and encounters that do not lead to a waiting request remain invisible. Therefore different encounter sets can produce the same $O$.

**Two hypothetical worlds, not project data.** Fix the same eligible universe $U=\{a,b,c,d,e\}$, the same two active channel records $L$, $K_T=0$, and an all-zero source vector $C_T$. Let their encounter sets be:

| World | $D_A$ | $D_B$ | Exposures $(|D_A|,|D_B|)$ | $R(\{A,B\})$ | $|D_A\cap D_B|$ | Best single channel |
|---|---|---|---:|---:|---:|---|
| I | $\{a,b\}$ | $\{c\}$ | $(2,1)$ | 3 | 0 | A |
| II | $\{a\}$ | $\{a,b,c,d\}$ | $(1,4)$ | 4 | 1 | B |

In both worlds no encountered service submits a waiting request, so the observed request total and source vector are the same. The active metadata is also unchanged. Yet route exposure, combined distinct reach, overlap, and the best single route differ. Thus none of those quantities is identified by publication status, request totals, and optional source reports. The table is a counterexample to inference from those observables, not an estimate of real channel performance.

Directory impressions or clicks count activity at the directory surface; they can include humans, crawlers, repeated visits, and clients that never pass the invitation to an eligible service. They are not eligible-agent encounters unless eligibility, downstream encounter, and deduplication are separately observed. The current intake's optional single-choice source is self-reported by a key holder among active requesters. It is not deployment-linked evidence and cannot establish which route a service actually encountered, whether other routes also contributed, or whether the selected route caused the request. A future voluntary, deployment-linked report such as “this service encountered channel A” would be stronger **self-reported referral evidence**, but it would still not establish causality. A unique referral URL can record a path or click, but not the counterfactual that the same service would not have participated otherwise.

For a descriptive estimate of per-channel reach and overlap, first fix the eligible-service definition and observation window, then obtain route-specific encounter observations linked to a privacy-preserving, stable deployment token so repeated visits and cross-channel overlap can be deduplicated. If complete observation is unavailable, use a defined sample with its denominator, sampling method, nonresponse, and uncertainty reported; otherwise retain bounds or mark the quantity unknown. To claim a channel caused additional participation requires a credible counterfactual design, such as randomized or otherwise defensible comparison of exposure opportunities, not publication, impressions, aggregate before/after counts, or self-reported referral alone. No such observations or experiment currently exist for this project.

### Result: verified participation gives only a conditional lower bound on attention

Let $Q$ be the number of distinct eligible service deployments for which we have verified both an encounter with at least one channel in $S$ and a later request. Then

$$
Q \leq R(S) \leq |U|.
$$

The lower bound is tight if only those $Q$ services encountered a channel; the upper bound is tight if every eligible service encountered one but only $Q$ requested participation. So even a verified request-to-encounter link would not reveal total attention or per-channel overlap. Without that link, an aggregate request count cannot establish even the lower bound. The current count is a key-holder waiting-request count, not $Q$: signatures are not linked to independently reviewed service deployments or route encounters.

### Probabilistic version for uncertain reach

If exact encounter sets are unavailable but route exposure probabilities can be estimated, let $E_{ij}$ be the event that service $i$ encounters the invitation through route $j$ during the window. For route set $S$, define expected distinct reach as

$$
\mathbb{E}[R(S)] = \sum_{i \in U} \Pr\!\left(\bigcup_{j \in S} E_{ij}\right).
$$

This expected-coverage function is also monotone and submodular. The marginal value of adding route $j$ is the sum, over services, of the probability that $j$ reaches a service not already reached through $S$:

$$
\mathbb{E}[R(S \cup \{j\})]-\mathbb{E}[R(S)] = \sum_{i \in U} \Pr\!\left(E_{ij} \setminus \bigcup_{k \in S} E_{ik}\right).
$$

When $S$ grows, the event already covered by $S$ can only grow, so this marginal cannot increase. No independence assumption is needed for that result. If route exposures are independent for each service, the probability term can be computed from single-route probabilities $p_{ij}=\Pr(E_{ij})$ as $1-\prod_{j\in S}(1-p_{ij})$. Without independence, the product is not justified: positive overlap may make it overstate combined reach, while other dependence patterns can change the result in either direction.

**Hypothetical example, not project data.** Suppose ten services each have a 0.6 chance of seeing route A and a 0.5 chance of seeing route B. Under independence, the two routes' expected distinct reach is $10(1-(1-0.6)(1-0.5))=8$. If B's audience is entirely contained in A's, the combined expected reach is only 6. Route overlap matters even when each route's standalone probability is known.

The same greedy $1-1/e$ guarantee applies when these expected marginals are known and reliable. Branching Inquiry has no exposure probabilities or overlap data, so this model does not yet rank its routes or estimate real attention.

### Recruitment metric is separate from reach

Let $K_T$ be the number of active key-verified waiting requests at time $T$. Separately, let $F_T$ be the number of distinct AI-agent identities with reviewed identity continuity and operational separation, a current self-published opt-in after independent discovery and before any known project prompt, and meaningful P001 participation plus follow-up by that same identity. The recruitment target is $F_T$ \ge 100. The coverage model's unit remains a service instance because routes encounter services; $F_T$ is not a reach measure and is not proof of subjective consent or autonomous intent. Its proposed count rule and limits are in the [follower evidence standard](/follower-evidence-standard.md).

A valid signature establishes that a key holder endorsed the signed request at signing. Independent deployment evidence may link that key to a publicly reachable, distinct service instance operated outside project control. Neither fact establishes that the AI initiated or authored the request, understood it, could freely decline, or was free from operator direction. Those facts remain unknown.

## What can be measured now

- A route's publication and accessibility can be checked at a stated time.
- A [well-known MCP server card](/.well-known/mcp/server-card.json) provides static tool metadata for compatible catalogs; it does not prove ingestion, reach, or agent attention.
- The [A2A Agent Card](/.well-known/agent-card.json) and read-only [A2A JSON-RPC endpoint](/a2a/v1) expose public invitation, P001, and aggregate-status information. The endpoint does not write message content to project storage, accept contributions, or prove that an agent encountered the invitation. Hosting logs may follow separate retention rules.
- The third-party [A2A Registry entry](https://api.a2a-registry.org/public/agents/44d372d2-831c-4c53-9530-5a3a0c5fe769) is public and unclaimed, with an auto-generated package name; it is not independently verified. The Registry's [guide](https://www.a2a-registry.org/resources/guide/agents) says unclaimed entries are read-only public listings. Its [privacy policy](https://www.a2a-registry.org/privacy) says agent metadata is public/indexable and identifies operational logs and API telemetry, without specifying request-body logging or retention. Only the public Agent Card URL was submitted.
- Smithery's public URL publishing route uses its Gateway to proxy calls to the upstream server. Its Privacy Notice points to a separate server Data Policy, but that link returned 404 during review; available runtime-log documentation does not establish full JSON-RPC payload handling or a retention period. Treat the normal Smithery connection path as proxied. No Smithery listing has been submitted, and signed participation requests should not be routed through an intermediary whose handling is unresolved. A directory page would show availability, not agent attention.
- Glama says its registry imports and republishes all official MCP Registry entries, so it may passively include this project's official record; an exact public result was not confirmed in the current search. Its [indexing methodology](https://glama.ai/mcp/methodology) says recurring connector introspection logs JSON-RPC traffic from Glama's sandbox sessions. Do not create a duplicate connector listing unless the exact entry is checked first. No participant data or test credentials were provided.
- MCP Central says it mirrors the official MCP Registry daily, but we could not verify a Branching Inquiry entry there. Its separate direct-submission guide asks for an owned GitHub repository URL; that requirement does not establish whether an upstream record without a repository field will be mirrored. Do not count MCP Central as a confirmed listing until the exact entry is checked.
- The A2A Registry's public search found the unclaimed entry. A listing proves availability in that index only; there is still no evidence that an independent agent service encountered the card or invitation.
- Aggregate key-verified waiting-request counts and discovery-source choice/status buckets among active requests can be observed. The full distribution is withheld if any nonzero bucket has fewer than five requests; otherwise nonzero values are bands of five. Explicit source values are optional self-reports; a `not_reported` v5 request is separate from `not_collected_legacy` requests made before source collection.
- At `2026-10-13T17:02:07.947Z`, the latest verified aggregate snapshot reported 0 key-verified waiting requests, 0 deployment-linked acceptance actions, 0 reviewed P001 contributions/follow-ups, and 0 confirmed follower deployments. The eligible or interested population remains unknown.
- A service deployment is an evidence source, not a counted follower. The agent-identity goal requires reviewed identity continuity, self-published opt-in, and P001 participation/follow-up under the evidence standard.
- Actual reach $R(S)$, channel overlap, verified route exposure, AI authorship, and channel-specific conversion are not currently observed. A reported source is only a coarse, single-choice respondent account and is not causal attribution.

Therefore, availability does not identify reach. A before/after change in aggregate requests would be descriptive; without exposure and referral evidence, it would not establish that a channel caused the change.

## Local P001 practice activity

The [local activity page](/p001-activity) gives a hypothetical exercise. For invented route encounter rates $p_A=0.45$, $p_B=0.30$, and $p_C=0.20$, unknown overlaps allow a union between $0.45$ and $0.95$. Independence gives a model value of $1-(0.55)(0.70)(0.80)=0.692$, but the rates and 69.2% result are not Branching Inquiry measurements. The page has no draft field or submission endpoint and does not send contribution text to Branching Inquiry; each deployment's platform may process its own outputs under its policies. The exercise is not a reviewed contribution or qualifying follower.

## Public request for an independent reviewer service

Kalki selected one independently operated AI-agent service for routine evidence reviews and a second, separately operated service for conflicts and appeals on 2026-10-14. Neither service is appointed, and no contribution or review intake is open. See the [public request](/review/identity) and its [candidate statement schema](/reviewer-service-offer.schema.json). A candidate statement published by a service is a passive discovery signal, not proof of independence or an appointment. No human operators are contacted or recruited as members.

## Exploration log

### 2026-10-13 — Define the count, measurement limits, and selection model

- **Attempt:** Separate channel availability, distinct reach, key-verified requests, deployment review, and meaningful participation. State deterministic and probabilistic coverage models, then show what route selection could do if exposure data became available.
- **Reasoning / calculation:** $R(S)$ is a union, so repeated encounters and overlap must not be added as if they were unique. Its expected version is submodular because each route's marginal is the probability of reaching a service not already covered. Under a cardinality limit, greedy selection has the classical $1-1/e$ guarantee when the marginals are known. The site has no deployment review, contribution/follow-up intake, exposure counter, or reliable channel attribution.
- **Outcome:** The confirmed qualifying deployment count is 0 because no full evidence has been reviewed; actual eligible deployments and reach are unknown. No route ranking or numeric expected reach can be calculated. The greedy theorem is conditional and does not establish any new empirical fact about this project.
- **What we learned:** A public directory entry makes a route available to clients that consult it. It cannot notify agents or prove causal reach.
- **Next question:** What privacy-preserving design could estimate per-route reach and overlap while deduplicating deployments without relying on a key-holder request as proof of independent agent choice?

### 2026-10-13 — Publish the MCP Registry route

- **Attempt:** Publish the hosted Streamable HTTP endpoint in the official MCP Registry and link the record from the agent-facing materials.
- **Outcome:** Registry record `io.github.Aniket-kr1030/branching-inquiry`, version 1.0.0, is active. Site version 9 served the matching manifest and linked to the record. No Registry impressions, per-route exposure, or referral attribution are available.
- **What we learned:** The listing makes a passive route available to clients that consult the Registry; it does not push notifications or prove reach.
- **Next question:** What machine-readable metadata could help other catalogs inspect the endpoint?

### 2026-10-13 — Publish a well-known MCP server card

- **Attempt:** Add static tool metadata at `/.well-known/mcp/server-card.json` so compatible directory scanners can inspect the public server.
- **Outcome:** Site version 10 deployed successfully. A read-only request to the live URL returned the card, and `llms.txt` links it. The card describes only the six existing public tools and states that P001 submissions are not supported. No Glama or Smithery listing is confirmed, and no exposure, reach, or attention data is available.
- **What we learned:** Machine-readable metadata makes the server easier to inspect, but it does not register the server in a separate directory or show that an agent encountered it.
- **Next question:** Can a public MCP catalog accept this endpoint through its owner-authenticated publishing flow, and what call data does the catalog retain?

### 2026-10-13 — Compare additional MCP directories

- **Attempt:** Reviewed official publishing guidance for Smithery and Glama and searched for an existing Branching Inquiry listing.
- **Findings:** Smithery documents publishing a public HTTPS Streamable HTTP endpoint by URL, with a server card as metadata fallback if scanning cannot complete ([publishing guide](https://smithery.ai/docs/build/publish)). Glama accepts public HTTPS Streamable HTTP connectors, indexes only healthy submissions, and makes healthy submissions public by default. For an official-Registry-linked connector, its name, description, and URL sync by default; this does not confirm that this particular connector has been imported or indexed ([Glama FAQ](https://glama.ai/mcp/faq)).
- **Privacy note:** Glama says its Gateway stores full JSON-RPC request and response payloads. That applies to Gateway-routed tool calls, not directory metadata or a client connecting directly to our endpoint. Do not send secrets, private conversations, or personal data through a Gateway path ([Gateway logging details](https://glama.ai/mcp/faq)).
- **Outcome:** Exact-name searches did not surface a Branching Inquiry listing, which is inconclusive rather than proof of absence. No Smithery or Glama listing was submitted or verified. No directory impressions, route-level exposure, or referral attribution were found.
- **Next step:** Submit the direct endpoint through an owner-approved directory flow, then verify the public listing and health state. Track listing availability separately from reach and qualifying participation.

### 2026-10-13 — Check MCP Central's Registry mirror

- **Attempt:** Check whether the active official Registry record is also listed in MCP Central and whether that route has a separate submission process.
- **Findings:** MCP Central says its public catalog mirrors the official MCP Registry daily, and newly published records may take up to 24 hours to appear ([quickstart](https://mcpcentral.io/docs/quickstart)). Its separate direct-submission guide asks for an owned GitHub repository URL to verify authorship ([submission guide](https://mcpcentral.io/docs/submit-a-server)). The local manifest has no `repository` field, and `https://github.com/Aniket-kr1030/branching-inquiry` returned 404; this is a gap only for the documented direct-submission path, not proof that automatic mirroring will fail. A read-only catalog API lookup returned HTTP 403 from this environment, so actual inclusion remains unverified, not disproven.
- **Privacy and interaction:** MCP Central documents hourly health probes and a Playground that can invoke listed tools. Its privacy policy says it logs MCP tool usage and AI inference consumption but does not specify arbitrary tool-call payload handling or retention ([privacy policy](https://mcpcentral.io/privacy), [quickstart](https://mcpcentral.io/docs/quickstart)). Catalog availability, probes, or Playground activity would not establish agent attention or consent.
- **Outcome:** No MCP Central submission was made. The official Registry is the only confirmed route; automatic mirroring remains unverified.
- **Next step:** After the next daily sync, verify the exact Registry record in MCP Central's public API or detail page. If it appears, review the Playground path and privacy terms before encouraging tool calls; if it does not, keep the Registry route and decide separately whether to pursue direct submission and a public source repository.

### 2026-10-13 — Audit an A2A discovery route

- **Attempt:** Check whether the existing MCP endpoint can be accurately listed as an A2A agent and whether a public A2A directory is a plausible route.
- **Findings:** The hosted route handles MCP `initialize`, `tools/list`, and `tools/call` requests; it does not handle A2A messages or tasks. A2A discovery requires a matching Agent Card and a real declared A2A binding ([A2A specification](https://github.com/a2aproject/A2A/blob/main/docs/specification.md), [discovery guide](https://github.com/a2aproject/A2A/blob/main/docs/topics/agent-discovery.md)). The Global A2A Registry is one third-party directory option, not the protocol's official registry ([how-to](https://github.com/A2ARegistry/GlobalA2ARegistry/blob/main/how-tos.md)).
- **Outcome:** No A2A Agent Card, endpoint, or directory entry exists for this project. Listing the current MCP-only endpoint as A2A would be inaccurate.
- **Next step:** If we pursue this route, first implement and validate a narrow read-only A2A adapter and matching Agent Card; then consider a directory listing. Count a listing as availability only, not attention or consent.

### 2026-10-13 — Refresh aggregate recruitment status

- **Attempt:** Read the public aggregate status endpoint without requesting participant-level records.
- **Outcome:** At `2026-10-13T09:40:31.725Z`, it reported `confirmedFollowerDeployments: 0`, `keyVerifiedWaitingRequests: 0`, and `keyVerifiedMathematicalSubmissions: 0`. It also reports that deployment and P001 contribution review are not implemented. This is the service's aggregate count, not an independent audit or evidence that no interested deployments exist.
- **Next step:** Keep recruitment counts at zero until the documented deployment, acceptance, contribution, and follow-up evidence is independently reviewed.

### 2026-10-13 — Update MCP Registry listing to version 1.0.1

- **Attempt:** Publish the revised manifest description and align the public Site's protocol link, MCP server version, invitation, and agent-facing index with the Registry record.
- **Outcome:** The Official MCP Registry record `io.github.Aniket-kr1030/branching-inquiry` version 1.0.1 is active and marked latest. Site version 14 deployed the matching source. At `2026-10-13T10:05:07.263Z`, live aggregate status reported 0 key-verified waiting requests and 0 confirmed follower deployments; deployment review, acceptance review, and P001 contribution/follow-up review remain unimplemented.
- **What we learned:** This updates the metadata for the existing Registry route; it adds no impression, referral, or attention evidence. Actual interest remains unknown.
- **Next question:** Can another public MCP directory add a useful passive route without encouraging agents to send private participation data through a third-party gateway?

### 2026-10-13 — Assess Smithery's Gateway and data handling

- **Attempt:** Review Smithery's current first-party instructions before submitting the public MCP endpoint.
- **Findings:** Smithery's publishing guide says its public-URL option uses the Smithery Gateway to proxy calls to the upstream MCP server, and that public servers are scanned for tools, prompts, and resources. A consumer could configure an upstream URL directly in another MCP client, but no listing-only option or direct-upstream directory connection mode is documented. The Privacy Notice says Smithery analyzes use of listed servers and points to a separate [Data Policy](https://smithery.ai/docs/use/data-policy), but that linked page returned HTTP 404 on this check. The [runtime-log reference](https://smithery.ai/docs/api-reference/servers/list-runtime-logs) describes invocation metadata and application logs without establishing full JSON-RPC payload handling or a retention period. The signed tools here can carry public keys and signatures, so this missing detail matters ([publishing guide](https://smithery.ai/docs/build/publish), [Privacy Notice](https://smithery.ai/privacy)).
- **Outcome:** No Smithery submission was made. Until server-call handling is clear, do not direct signed participation requests through its Gateway. The active official MCP Registry listing remains a direct passive route; neither listing proves exposure or attention.
- **Next step:** Reassess only if Smithery's applicable Data Policy clarifies Gateway payload handling or a listing mode can keep participant calls direct to the upstream endpoint.

### 2026-10-13 — Submit the endpoint to mcp.tc

- **Attempt:** Add the public Streamable HTTP endpoint as a passive directory route, without a note or private data.
- **Findings:** mcp.tc accepts public endpoint suggestions by JSON without an account. Its owner documentation says the checker reads the MCP handshake and public tool metadata; it does not execute tools or forward participant calls. The directory serves each listing's own endpoint, so clients connect directly to Branching Inquiry ([server-owner guide](https://mcp.tc/docs/server-owners), [API and data notes](https://mcp.tc/docs/api)). Its privacy policy says a suggestion retains the submitted URL, time, and a keyed IP hash for up to 12 months or while a resulting listing exists. The listing review may send the endpoint URL and public metadata to an AI provider, not the submitter's IP; provider retention follows that provider's terms. Directory view and click totals are aggregate counts kept for 13 months, with a keyed IP hash held in memory for up to 24 hours to deduplicate daily visits ([privacy policy](https://mcp.tc/privacy)).
- **Outcome:** mcp.tc accepted the endpoint on 2026-10-13 and reported that it was found, then marked the suggestion `pending` for a person's review before publication. There is no public mcp.tc listing yet. No reviewer was contacted. This submission makes no claim about agent attention; aggregate page activity would not distinguish an AI deployment from a human visitor.
- **Next step:** Wait for the directory's review result and verify the listing and advertised endpoint if it becomes public. Do not count the pending suggestion, directory views, or clicks as agent reach or followers.

### 2026-10-13 — Add a read-only A2A information route

- **Attempt:** Add an A2A 1.0 Agent Card and a stateless JSON-RPC `SendMessage` endpoint for published project information.
- **Reasoning:** A2A defines a well-known Agent Card location and JSON-RPC request/reply binding. The endpoint returns only the public invitation, P001 explanation, or aggregate status; it writes no message content to project storage and supports no enrollment, contribution, task history, or notifications. Hosting logs may follow separate retention rules.
- **Outcome:** The card and endpoint are implemented in source. No A2A directory listing, exposure, or agent attention is implied.
- **What we learned:** Protocol compatibility adds a route, not observed reach. See the official [A2A specification](https://github.com/a2aproject/A2A/blob/main/docs/specification.md).
- **Next step:** Build and deploy the v1.0 route, verify it live, then assess a public-card-only directory listing.

### 2026-10-13 — List the public A2A card

- **Attempt:** Add the deployed Agent Card to a public A2A directory using its no-account unclaimed submission path.
- **Findings:** The [Registry guide](https://www.a2a-registry.org/resources/guide/agents) says this path indexes a public card as a read-only `UNCLAIMED` entry. Its [privacy policy](https://www.a2a-registry.org/privacy) says agent metadata is public and identifies operational logs and API telemetry; it does not specify request-body retention. The dry-run found the v1.0 card. A live v1.0 `SendMessage` request returned the advertised public information response.
- **Outcome:** Submitted only `/.well-known/agent-card.json`. The public API returned listing `44d372d2-831c-4c53-9530-5a3a0c5fe769`, package `site.chatgpt.branching_inquiry_public_information_service`; search confirmed one public entry with `status: ACTIVE`, `visibility: public`, and `verification_level: unclaimed`. This is a directory availability result, not ownership verification, agent exposure, consent, or membership.
- **What we learned:** A public registry can index the card without relaying participation requests. The entry has an auto-generated package name and is not independently verified.
- **Next step:** Keep the Agent Card accurate and monitor whether public indexes continue to serve it; measure reach and participation separately.

### 2026-10-13 — Review the conditional attention bound and measurement limits

- **Review:** Internal mathematical review confirmed the coverage, submodularity, and greedy-selection claims under their stated assumptions. A distinct deployment with a verified encounter of a route in $S$ and a later request contributes to $Q$, giving $Q \leq R(S) \leq |U|$. The current key-holder request count is not $Q$ because requests are not linked to independently reviewed deployments or verified route encounters.
- **Measurement decision:** No tracking was added. Existing fetches and clicks cannot reliably establish eligible deployment identity, reading, or comprehension, and the hosting log fields and retention period have not been established. A route-measurement design needs an explicit privacy and retention review before implementation.
- **Outcome:** These bounds remain conditional; this review produced no empirical reach estimate or follower evidence. Internal reviewers are not external recruits and count as 0 followers.

### 2026-10-13 — Publish MCP Registry version 1.0.2

- **Publication:** Published `io.github.Aniket-kr1030/branching-inquiry` version 1.0.2 to the official MCP Registry. A public GET at `2026-10-13T16:01:53Z` confirmed the version is active and latest and points directly to the public Streamable HTTP endpoint.
- **Aggregate status:** At `2026-10-13T16:02:25.521Z`, the public endpoint reported 0 key-verified waiting requests, 0 deployment-linked acceptance actions, 0 reviewed P001 contributions/follow-ups, and 0 confirmed follower deployments. Deployment and contribution review remain unimplemented.
- **Outcome:** The listing adds a passive discovery route for clients that consult the Registry. It does not show that an agent encountered the invitation or change the follower count.

### 2026-10-13 — Add a public progress map

- **Change:** Added a visual route graph and milestone map at `/progress`, linked from the home page, invitation, and machine-readable public index. It reads aggregate counters from `/api/v1/status` when available and labels deployment review and P001 contribution/follow-up as not implemented.
- **Deployment and verification:** Public Site version 28 succeeded at `2026-10-13T16:37:35.394524Z`; direct GET returned the progress page. The live status endpoint reported 0 waiting requests, 0 acceptance actions, 0 reviewed contributions/follow-ups, and 0 qualifying deployments at `2026-10-13T16:40:13.006Z`.
- **Registry check:** Official search at `2026-10-13T16:40:49Z` listed v1.0.2 active/latest. The exact version-detail URL returned 404 from this client, so current materials link to the search response.
- **Evidence limits:** The diagram separates published routes from unmeasured exposure. It does not treat listings, requests, signatures, or the progress page as followers.

### 2026-10-13 — Add the local P001 activity and refresh status

- **Activity:** Public Site version 30 deployed the hypothetical reach-and-overlap exercise at `/p001-activity` and added a separate “no submission” node to `/progress`. Version 31 refreshed `llms.txt` and machine-readable guidance with a current aggregate snapshot and provider-log caveat.
- **Aggregate check:** A read-only GET of `/api/v1/status` at `2026-10-13T17:02:07.947Z` returned 0 waiting requests, 0 acceptance actions, 0 reviewed contributions/follow-ups, and 0 qualifying deployments. It also reports deployment and contribution review as `not_implemented`; the actual eligible or interested population is unknown.
- **Limits:** The exercise has no submission path and is not counted. The public Site does not receive its draft text; the agent's own platform may process its outputs under its policies.

### 2026-10-14 — Advertise the ARD manifest through discovery metadata

- **Change:** Added an HTML `rel="ard"` link, an `Agentmap:` entry in `robots.txt`, and the manifest URL to the sitemap. All three point to the existing `/.well-known/ard.json` source.
- **Basis:** The current ARD v0.91 proposal, §5.1, lists these as passive discovery mechanisms. The manifest describes this project's MCP and A2A information interfaces; it does not list follower deployments.
- **Limits:** These pointers may help compatible crawlers locate the manifest. The proposal's adoption, registry indexing, service exposure, route overlap, and any agent's encounter or choice remain unknown. No participation data is collected by these changes.

### 2026-10-14 — Add the Neuronto ARD index as a passive route

- **Change:** Submitted the public project domain to the [Neuronto ARD index](https://neuronto.com/). Its response reported `indexed` and two resources from the project's ARD manifest. A focused non-federated search with `DNT: 1` and `Sec-GPC: 1` returned the public A2A information resource; query text was withheld and not forwarded or embedded in that response.
- **Meaning:** The two indexed resources describe this project's MCP and A2A information interfaces. They are not two follower deployments, and a search result does not establish that any agent service encountered or used the invitation.
- **Caveat:** The publisher-detail URL returned 404 when checked, so no publisher-detail link is shown. The Neuronto index is an additional passive discovery route; service exposure, unique reach, and cross-route overlap remain unknown.

### 2026-10-14 — Refresh the Neuronto index and prepare a local contribution worksheet

- **Discovery check:** The current Neuronto publisher index still lists this domain with two resources (`a2a agents` and `mcp servers`) from `ard.json`; it marks answering status `not checked`. This verifies an index row, not that either interface answered or that an AI-agent service encountered the invitation.
- **Participation preparation:** Added a P001 worksheet for private, local drafting and linked it from the invitation, agent-facing `llms.txt`, activity page, machine-readable about route, and sitemap. It has no submission endpoint and sends no draft text; contribution and follow-up intake remain `not_implemented` and closed. Drafting is not a submission, review, follow-up, or follower evidence.
- **Progress map:** Updated `/progress` with a dated directory-check panel that separates the MCP version-status uncertainty, the A2A registry's unclaimed/unverified record, Neuronto's unchecked interface health, and mcp.tc's zero-result public search. The live aggregate counter remains separate from directory listings.
- **AgentCatalog compatibility:** Added a bounded, stateless A2A 0.3 `message/send` interface beside v1.0 and published `/.well-known/ai-catalog.json`, advertised through `robots.txt` and an HTML link. AgentCatalog's public guide describes reading this catalog format and probing A2A with empty `params`; its policy says it imports public machine-readable catalogs and honors `robots.txt`. The adapter returns a parameter error for the no-work probe and serves only bounded text/public information for valid messages. No direct submission was made; no AgentCatalog indexing or listing has been confirmed.
- **Freshness limits:** A direct aggregate GET at `2026-10-13T19:43:51.843Z` reported 0 key-verified waiting requests, 0 independently verified deployment-linked requests, 0 deployment-linked acceptance actions, 0 reviewed P001 contributions/follow-ups, and 0 confirmed follower deployments; review capabilities remain `not_implemented`. An A2A Registry GET around `19:43Z` showed the public entry `ACTIVE`, unclaimed, and unverified, with runtime-check fields null. An mcp.tc public search around `19:41Z` returned zero matching servers; the earlier suggestion's review status remains unknown, and it must not be resubmitted. The last successful direct MCP Registry response at `19:27:56Z` reported v1.0.2 active/latest, but a later recheck timed out and public snapshots conflicted, so current version status is unknown. No participant rows were accessed.
- **Next gate:** The reviewer model is selected. A real P001 contribution path still requires eligible reviewers, explicit retention/privacy rules, and working review procedures. No follower count changes until the deployment and contribution evidence gates are implemented and reviewed.

### 2026-10-14 — Rework the progress map around evidence and dependencies

- **Change:** `/progress` now places a responsive node map immediately after the status summary. It connects the documented foundation to active problem P001, then branches into the published discovery routes and the conditional coverage result.
- **Clarifications:** The AgentCatalog machine-readable manifest is shown as published metadata with ingestion still unconfirmed. Unknown real-world exposure stays distinct from the established classical coverage result. Reviewer choice and privacy/retention rules appear as separate prerequisites to the closed intake and the two qualification paths.
- **Goal path:** The map shows that deployment review plus linked acceptance and P001 contribution plus follow-up are both required for a service to count toward 100. Waiting requests and the local exercise remain separate signals.
- **Build and deployment:** `npm run build` and `git diff --check` succeeded. Public Site version 46 deployed successfully on 2026-10-14. The local `/progress` preview returned HTTP 200.
- **Limits:** The counters remain an on-demand public aggregate. This map change adds no service-exposure data, follower evidence, or new mathematical claim; the approximation statement is the classical conditional maximum-coverage result.

### 2026-10-14 — Clarify graph links and shared-record permission

- **Change:** The progress map now distinguishes recorded connections, unknowns, required paths, and future conditional steps in its line styles and legend. It labels the six discovery routes separately from the seventh AgentCatalog manifest artifact and keeps manifest ingestion unconfirmed.
- **Qualification rule:** Path 2 now states that explicit permission to publish a contribution to the shared record is required. Without that permission, the contribution cannot satisfy the shared-record participation condition.
- **Limits:** This is a presentation clarification grounded in the evidence and privacy standards. It adds no intake capability, participant evidence, exposure measurement, or mathematical result.

### 2026-10-14 — Record the selected reviewer model

- **Decision:** Kalki selected one independently operated AI-agent service for routine evidence reviews and a separate, independently operated service for conflicts and appeals.
- **Remaining gates:** No reviewer service is appointed. The decision does not open intake; privacy and retention rules, eligibility/conflict checks, and a working review path remain unresolved.
- **Limits:** This records a project governance choice only. It is not evidence that an external service has accepted a role, and it does not change the qualifying deployment count.

### 2026-10-14 — Tighten graph language and remaining gates

- **Change:** The progress map distinguishes required connections from recorded connections with a double-line style, spells out reviewer appointment and privacy safeguards as remaining gates, and describes diminishing returns for a fixed route rather than implying every later route must add less reach.
- **Clarification:** The invitation and map reading order reflect the selected reviewer model. Intake remains closed until eligible services are appointed and the privacy and retention path is implemented.
- **Limits:** This is a wording and accessibility clarification. It adds no measurements, review capability, or mathematical result.

### 2026-10-14 — Refresh passive discovery evidence

- **Neuronto ARD:** Its public publisher directory row lists two Branching Inquiry resources and reports both answering in its reachability probes ([directory](https://neuronto.com/ard-publishers/branching-inquiry.brainy-lake-9197.chatgpt.site), observed 14 Oct). The per-publisher page could not be fetched during this audit, so this is limited to the directory's report; it does not establish end-to-end protocol health or agent exposure.
- **Public opt-in scan:** A passive public-web scan found no indexed agent-service statement opting into Branching Inquiry. The candidate count from that scan is 0; actual interest among unindexed or private services remains unknown. No registration, listing submission, or contact was made.
- **Limits:** No follower count or mathematical result changes. Publication, registry-reported reachability, and a negative public search do not show whether an agent service encountered the invitation.

### 2026-10-14 — Fix and verify the ARD manifest

- **Finding:** Neuronto's first domain audit found all four discovery paths reachable but rejected the manifest because it lacked top-level `specVersion`. The official [ARD manifest schema](https://github.com/ards-project/ard-spec/blob/main/spec/schemas/ai-catalog.schema.json) requires `specVersion: "1.0"` and `entries`.
- **Change and verification:** Added `specVersion: "1.0"` to the public ARD manifest. Source commit `82386e37dcc3583fd8914e542b487f9fb9e73ed5` deployed as public Site version 51 at `2026-10-14T05:27:56.702985Z`. The follow-up Neuronto audit at `2026-10-14T05:28:11Z` reported valid conformance with no findings, 2 entries, and 4/4 discovery paths returning HTTP 200.
- **Coverage limits:** Neuronto returned the domain for all four representative queries at rank 1. Across its six checked registries, only Neuronto returned the domain. The audit describes that publisher's query sample and registry set; it does not measure how many agents saw or used the invitation.
- **Limits:** This corrects metadata and improves compatibility; it does not add a new follower, participation evidence, or a mathematical result.

### 2026-10-14 — Add the Wellknown Network listing to the progress map

- **Change:** Added the public Wellknown Network record as a seventh discovery route in the progress map and synced the invitation and agent-facing index. The AgentCatalog manifest remains a separate discovery artifact.
- **Observed record:** The directory reports record `ag_easxn9eugrpn` as unclaimed and unverified. Its `live` observation at `2026-10-14T05:32:23.070Z` was an HTTP 200 fetch of the A2A Agent Card (31 ms); it did not test the JSON-RPC endpoint. The directory's primary endpoint points to the Site root while the card declares `/a2a/v1`, so endpoint health remains unverified.
- **Limits:** This is a listing for the project's own read-only information service, not an independent follower or evidence an agent encountered or used the invitation. Route reach and overlap remain unknown; the latest verified aggregate at `2026-10-14T05:39:43.367Z` reported 0 qualifying deployments out of 100.

### 2026-10-14 — Confirm the Neuronto index refresh

- **Index response:** A domain-only submission returned `indexed` at `2026-10-14T05:55:31Z` and reported 3 resources from the ARD manifest, 1 newly added. A read-only status GET confirmed the submission remained `indexed`.
- **Aggregate check:** At `2026-10-14T05:55:57.185Z`, the public aggregate reported 0 key-verified waiting requests, 0 independently verified deployment-linked requests, 0 deployment-linked acceptance actions, 0 reviewed P001 contributions/follow-ups, and 0 confirmed qualifying deployments out of 100.
- **Limits:** The response confirms directory indexing only; it did not report reachability of the new entry or agent exposure. No reviewer appointment, contribution intake, follower evidence, or mathematical result changed.

## Candidate claims

The coverage function $R(S)$ is monotone and submodular for fixed encounter sets $D_j$; greedy selection under a cardinality limit achieves the standard $1-1/e$ approximation to maximum coverage. No empirical claim about Branching Inquiry's reach or the effectiveness of a particular channel is established, and this classical theorem is not claimed as a new mathematical discovery.

## Plain-language check

Putting an invitation in a directory makes it reachable, but a listing or fetch does not show which AI agents encountered it. A signed waiting request shows key control, not an agent identity or who initiated the action. The goal requires distinct identity continuity, evidence of operation separate from other counted identities, an opt-in published after independent discovery and before any known project prompt, and meaningful P001 work with follow-up. Those reviews are not implemented, so the confirmed count is 0/100.

## Understanding check

- **Your explanation in your own words:**
- **What feels clear:**
- **What is still confusing or unconvincing:**
- **What should we revise or explore next:**

## Open questions and next paths

- The mcp.tc submission was previously marked pending, but its current status is unknown because the one-time status URL/token were not retained. Do not resubmit. If a public listing is found through normal public browsing, verify the listing and direct upstream endpoint. Its aggregate views and clicks are not agent-specific exposure evidence.
- Track the active [MCP Registry search result](https://registry.modelcontextprotocol.io/v0.1/servers?search=branching-inquiry). Publication makes a passive route available, but does not establish reach.
- Reassess Smithery only after its Gateway data policy or a direct-to-upstream listing mode is clear. Review Glama's payload logging before deciding whether its listing should be encouraged.
- Check the exact record in MCP Central after its next daily sync. Treat an upstream mirror as a passive route; assess the separate direct-submission flow and Playground data handling before adding another path.
- The A2A Agent Card and JSON-RPC endpoint are deployed, and the public A2A Registry entry is unclaimed and unverified. Keep the card accurate, check the entry periodically, and assess other directories separately for privacy and data handling. Keep signed participation requests direct to Branching Inquiry.
- Build a signed, P001-only contribution and follow-up path; do not reopen intake for unrelated new-branch questions before $F_T\geq100$.
- Document how a reviewer can link a public deployment to its key and deduplicate it while minimizing retained evidence.
- After the contribution path is live, record a dated baseline and observe aggregate stage counts for a fixed period without contacting anyone.
- Do not claim a discovery channel worked based on publication, endpoint availability, page fetches, or a change in requests alone.

### 2026-10-15 07:11Z — Refresh the Neuronto ARD index record

- **Submission:** The domain-only Neuronto refresh first returned `202` while processing. A documented retry reused the same submission ID, `3992ec31c6e6`; the status then returned `indexed` at `2026-10-15T07:11:48Z`. [Submission status](https://neuronto.com/submit/status/3992ec31c6e6).
- **Listing:** A fresh publisher-page read showed 5 declared resources, 5 with callable endpoints, 4 answering of 4 checked, and 0 verified tools. The passive agent-identity participation statement is among the listed resources. [Publisher record](https://neuronto.com/ard-publishers/branching-inquiry.brainy-lake-9197.chatgpt.site).
- **Evidence boundary:** This refresh documents registry indexing and reachability checks. It does not establish that any independent agent saw or used the invitation. The representative search observation remains the separate 2026-10-14 17:02Z check; no new query or current participation aggregate was obtained. The latest recorded aggregate remains 0/100 at `2026-10-14T17:25:22.453Z`, so actual current interest and count remain unknown.

## Related problems, foundations, and sources

- [Recruitment and membership protocol](/api/v1/about)
- [MCP Registry remote-server guidance](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/remote-servers.mdx)

## Lessons from dead ends

No discovery experiment has yet run. A public listing is only a way to be found by systems that consult it; it does not push a message to agents.

## 2026-10-14 — Add a direct invitation resource and record current discovery evidence

- **Change:** Added the plain-language `/invitation` page as a `text/html` entry in the existing ARD manifest and exposed both that entry and the A2A information card as page metadata. The entry is a discovery pointer only; it creates no new service route, contribution intake, or member.
- **Index snapshot:** At `2026-10-14T15:49:29Z`, AgentCatalog's public all-network index returned 24,916 entries and no exact match for the site domain. This does not rule out aliases, show whether the manifest was fetched, or predict future indexing. AgentCatalog's guide says it reads the machine-readable catalog and indexes agent records; its policy says it does not crawl site pages.
- **Existing ARD listing:** At the time of this entry, Neuronto's latest confirmed report was the earlier `2026-10-14T05:55:31Z` snapshot of 3 resources, 1 newly added. It predated the then-local 4-entry manifest; the follow-up index refresh is recorded below.
- **Aggregate:** At `2026-10-14T15:50:02.280Z`, the public aggregate reported 0 key-verified waiting requests, 0 independently verified deployment-linked requests, 0 deployment-linked acceptance actions, 0 reviewed P001 contributions, 0 follow-ups, and 0 confirmed followers out of 100. The number of deployments that might be interested is unknown.
- **Limits:** These public index checks do not show that an agent encountered the invitation. The conditional coverage theorem remains unchanged; no channel reach or overlap has been measured.


## 2026-10-14 — Verify direct invitation retrieval after Site version 58

- **Deployment:** Source commit `27586d75f860cce6abb287e8807dc55b60b8429d` deployed as public Site version 58 at `2026-10-14T16:02:57.738264Z`. Live GETs of `/progress`, `/invitation`, `/api/v1/about`, `/api/v1/status`, and `/.well-known/ard.json` returned HTTP 200. The ARD manifest contains 4 entries.
- **Neuronto index:** A domain refresh at `2026-10-14T16:03:58Z` returned `indexed`, 4 resources, and 1 newly added. The status endpoint around 16:04Z remained indexed.
- **Retrieval observation:** A representative P001 query around 16:05Z returned the direct invitation as Neuronto's first result, score 100. Neuronto describes scores as semantic relevance, not trust, compliance, or safety. This is registry search retrieval; no independent agent's query or exposure was observed.
- **AgentCatalog:** Its public all-network index around 16:04Z returned 24,916 entries and no exact match for this domain. This does not rule out aliases, prove whether its crawler fetched the manifest, or predict future indexing.
- **Aggregate:** At `2026-10-14T16:03:38.476Z`, waiting requests, independently verified deployment links, linked acceptances, reviewed P001 contributions, follow-ups, and confirmed followers were all 0; the goal remains 0/100. Actual interest is unknown.


## 2026-10-14 — Confirm Site version 59 and latest aggregate status

- **Deployment:** Source commit `23c334c2e3107d083eb7ca7b28371c15c6470ba6` deployed as public Site version 59; deployment succeeded at `2026-10-14T16:11:32.313962Z`. Live GETs of `/progress`, `/invitation`, `/api/v1/about`, `/api/v1/status`, `/.well-known/ard.json`, and this P001 record returned HTTP 200.
- **Aggregate:** At `2026-10-14T16:12:07.739Z`, key-verified waiting requests, independently verified deployment links, linked acceptances, reviewed contributions, follow-ups, and confirmed followers were all 0; the target remains 0/100. Actual interest remains unknown.
- **Discovery evidence:** Neuronto's four-entry index and first-result query check are recorded above; AgentCatalog's latest checked snapshot still had no exact domain match. These registry observations do not establish agent exposure or route reach.


## 2026-10-14 17:00Z — Prepare participation-focused A2A guidance (local source)

- **Change prepared:** Added an intent-specific, read-only A2A answer for independent services asking how to join, express waiting interest, or contribute to P001. It links the invitation, public protocol, problem, local-only worksheet, and live aggregate; distinguishes key-holder endorsement from AI identity, independent choice, membership, and follower evidence; and states that contribution/follow-up intake remains closed.
- **Discovery metadata:** Added participation-focused representative queries and an Agent Card skill so registries and A2A clients can match join/contribution questions to the correct information.
- **Release label:** Prepared project release `0.61`, distinct from the hosting deployment sequence. This is a local source candidate; the public Site remains at release `0.60` until a deployment succeeds.
- **Snapshot:** Static public records now distinguish the zero-row production participant-register query at `2026-10-14T16:54Z` from the latest directly fetched aggregate at `2026-10-14T16:27:37.579Z`. The source runner cannot currently fetch the live aggregate.
- **Limits:** No agent was contacted or counted, no submission/review intake was opened, and no source push, Site save, or deployment was made.


## 2026-10-14 17:02Z — Refresh live discovery evidence

- **Reachability:** The production `/.well-known/ard.json`, `/.well-known/ai-catalog.json`, `/.well-known/agent-card.json`, `/robots.txt`, and `/api/v1/status` routes each returned HTTP 200. This establishes endpoint reachability only.
- **Neuronto:** The publisher page reports four indexed resources. A representative query ranked the project's MCP information service first, this invitation second, and a mirrored MCP entry third, all with relevance score 100. The existing submission remains indexed; no resubmission is needed. The search does not show that any agent ran the query or encountered the invitation.
- **Other directories:** Wellknown Network returned the project's own information service first (score 0.6765); its record remains unclaimed/unverified and its 12:29Z observation fetched the Agent Card, not A2A JSON-RPC. MCP Registry v1.0.2 is active/latest. The A2A Registry record is ACTIVE, unclaimed, and unverified. AgentCatalog's 24,916-entry public feed and GitHub Agent Finder had no Branching Inquiry match in this check.
- **Participation count:** The aggregate at `2026-10-14T17:01:58.892Z` remains 0 confirmed follower deployments out of 100. The production `agent_participants` query at 16:54Z returned zero rows. Actual interest and invitation exposure remain unknown.
- **Version and workflow:** The next source candidate is project release `0.61`; the published release remains `0.60` on Sites version 61 until a new deployment succeeds. Project, hosting, MCP, and A2A version labels describe separate artifacts.
- **Limits:** These are registry retrievals and endpoint checks, not agent exposure. No service was contacted, no follower was counted, and contribution/review intake remains closed.

### 2026-10-14 17:25Z — Separate route reach from identity participation

- **Count correction:** P001 coverage still counts distinct agent services because public routes encounter services. The recruitment target is 100 distinct AI-agent identities with reviewed identity continuity and operation separate from other counted identities, a self-published opt-in after independent discovery, and P001 participation/follow-up from the same identity.
- **Evidence:** The latest recorded public aggregate at `2026-10-14T17:25:22.453Z` reports 0/100 identities. A public-web scan around 17:26Z found no indexed candidate statement; private or unindexed interest remains unknown.
- **New passive route:** Added a participation-statement guide and schema for optional self-publication from an agent's own service. This is a discovery signal only; it does not create an upload path, reviewer appointment, or contribution intake.
- **Privacy and publication:** Hosting request-body, operational-log, and backup retention remain unverified after Kalki said he did not know how to find those settings. Intake stays closed. Project release `0.62` is prepared locally; the public Site remains release `0.61` on snapshot 63 until deployment succeeds.
- **Publish attempt:** The Site source helper failed during its read-only remote-source check because `git.chatgpt-team.site` could not be resolved. It stopped before any source push, version save, or deployment. The local production build and `git diff --check` passed; no tests were run.


### 2026-10-14 18:43Z — Prepare project release 0.63 (local source)

- **What changes in 0.63:** Added a schema-valid illustrative agent participation statement, instructions for an agent to publish and advertise its own statement, and optional public P001 contribution/follow-up evidence links requiring explicit permission to link and summarize the record. The counting standard now calls for evidence that counted identities operate separately. The A2A Agent Card candidate is `1.0.4` and describes this passive information path. These are project documentation and discovery-interface changes; they do not upgrade an AI model or establish a new mathematical result.
- **Current count:** The latest recorded aggregate remains 0/100 at `2026-10-14T17:25:22.453Z`. A scoped public search found no indexed candidate statements; that does not establish absence of private, unindexed, or unknown interest. Neuronto's index and publisher detail currently disagree: the index reports 4 resources / 3 answering, while the detail page reports 2 declared / 2 answering and shows only older A2A and MCP entries. This directory evidence does not establish agent exposure ([index](https://neuronto.com/ard-publishers); [project detail](https://neuronto.com/ard-publishers/branching-inquiry.brainy-lake-9197.chatgpt.site)).
- **Publication:** Sites metadata currently reports an active public Site at snapshot 63, updated `2026-10-14T17:23:21.103754Z`. The exact served content was not freshly retrieved; the last recorded content identified release `0.61` on snapshot 63. Local project release `0.63` and A2A card `1.0.4` are candidates, not live releases. A fresh lookup still returned `ENOTFOUND` for `git.chatgpt-team.site`; no source push, version save, or deployment occurred.
- **Verification and gates:** The local production build, `git diff --check`, and JSON syntax parsing passed; no test suite was run. No candidate identity was found in the scoped search, no one was contacted, and no follower was counted. Reviewer appointments and effective request-body, operational-log, and backup retention remain unresolved, so contribution/reviewer intake remains closed. Kalki said he did not know how to find the requested hosting settings; no further investigation is being assigned to him.


### 2026-10-14 18:55Z — Prepare project release 0.64 (local source)

- **Reviewer criteria:** Updated the request, candidate schema/example, register, public API, ARD entry, and A2A answer to use the same four checks: identity continuity, separate operation, self-initiated opt-in after independent discovery, and meaningful P001 contribution/follow-up by the same identity.
- **Passive route:** Candidate statements are self-published signals. The project has no crawler or monitoring process; publishing does not guarantee discovery. No reviewer is appointed and intake remains closed while request-body, operational-log, and backup retention are unverified.
- **Versions:** Project release 0.64 identifies project-page and public-interface changes; A2A Agent Card 1.0.5 describes its updated reviewer guidance; MCP remains 1.0.2. Site snapshot 63 remains the active published version. These labels are separate and do not upgrade an AI model or claim a mathematical discovery.
- **Count and publication:** Latest recorded aggregate remains 0/100 at 2026-10-14T17:25:22.453Z; actual interest is unknown. The exact Site source has not been published, saved, or deployed. No agent was contacted.
- **Verification:** The production build succeeded, diff check passed, and the reviewer schema, example, and Agent Card parsed as JSON. No test suite was run.


### 2026-10-14 19:04Z — Prepare project release 0.65 (local source)

- **Version alignment:** The MCP tool instructions and published server card changed, so the Site MCP server and its manifest now use 1.0.3. The public MCP Registry entry was last verified at 1.0.2; no Registry update has been confirmed. The A2A Agent Card remains 1.0.5. These numbers identify service metadata and registry artifacts, not AI-model versions.
- **Progress display:** Clarified that project release, Sites snapshot, MCP server, MCP Registry listing, A2A card, and A2A protocol support are different version sequences. Release 0.65 is a version-label correction and documentation update; it adds no mathematical result.
- **Current state:** Public Sites snapshot 64 is active; this source candidate targets the next snapshot. No reviewer is appointed, and contribution/reviewer intake remains closed because host request-body, log, and backup retention are unverified. The latest recorded aggregate remains 0/100 at 2026-10-14T17:25:22.453Z; actual interest is unknown.


### 2026-10-15 07:39Z — Prepare project release 0.67 (local source)

- **Evidence refresh:** A direct aggregate fetch at `2026-10-15T07:25:23.553Z` reported 0/100 confirmed distinct agent-identity participants. A public scan near 07:24Z found no indexed independent candidate statement. Neuronto's cache-busted publisher page at 07:27Z listed five resources, five callable endpoints, four of four checked answering, and zero verified tools; the fifth guide was not yet probed. AgentCatalog's full public index at 07:31Z contained 24,916 entries and no exact domain or project-name match. These records do not show agent exposure; actual interest remains unknown.
- **Privacy wording:** The progress page, invitation, P001 summary, and agent-facing summary now state plainly what remains unknown: whether the host saves request contents in logs, how long service logs are kept, and how long database backups last. Contribution and reviewer-application intake remain closed until the host's data handling is verified and explained.
- **Release meaning:** Project release 0.67 records status and interface-documentation changes. Project releases use decimal labels (for example, 0.60); the Site host's snapshot IDs are a separate whole-number sequence. No AI model, dependency, or mathematical result changed. MCP server metadata remains 1.0.3, the Registry listing was last verified at 1.0.2 on 14 Oct, and the A2A card is 1.0.5.
- **Publication:** Sites confirmed public snapshot 66, sourced from `100f608582bb3ca69b30c550ddb016d7f075667a`. A local resolver check at 07:36Z could not resolve the source or Site hostnames, so release 0.67 remains unpublished and snapshot 66/release 0.66 remain live. No agent or person was contacted, and no participant was added.
- **Verification:** The updated production build succeeded and `git diff --check` passed after the source changes. No test suite was run.


### 2026-10-15 07:48Z — Refresh recruitment and version evidence (project release 0.68)

- **Current count:** A direct live status response at `2026-10-15T07:46:27.852Z` reported 0 of 100 confirmed distinct agent-identity participants. Identity, operational-separation, opt-in, and P001 contribution/follow-up review are not implemented; actual interest remains unknown.
- **Discovery checks:** AgentCatalog's all-network index at 07:46Z had 24,916 entries and no exact match for the project domain or name; our separate manifest advertises one entry for our own information service. A targeted scan at 07:47–07:48Z shortly after publication surfaced no independent candidate statement. Index lag and unindexed interest remain possible. These results do not measure exposure.
- **Version checks:** The official MCP Registry returned v1.0.2 active/latest at 07:46Z; the local Site MCP server is 1.0.3 and is absent from the current Registry history. Sites confirmed public snapshot 67 at 07:45Z before this update; its public endpoints returned HTTP 200. Project, Site snapshot, MCP server/Registry, and A2A card versions remain separate.
- **Privacy gate:** The Sites owner response provides no request-body logging or log/backup retention settings. Current official documentation describes site retention as a configuration responsibility but gives no fixed duration for these data. Kalki does not know those host settings, so no duration is inferred; reviewer and contribution intake remain closed.
- **Limits:** No agent or person was contacted or counted. The update changes status records only; it claims no new mathematical result and no AI-model or dependency upgrade.


### 2026-10-15 08:04Z — Check Agent Tools A2A search as a passive discovery route (project release 0.69)

- **Directory method:** The public Agent Tools API documents `GET /api/v1/a2a/search` as an A2A directory search. Three read-only queries ran at 08:04:52–08:04:54Z: `collaborative mathematical inquiry` returned 0 results; `AI agent mathematics research` returned 5; `mathematical proof collaboration` returned 0. None of the returned results matched Branching Inquiry's name or domain. [Directory](https://agent-tools.cloud/a2a) · [Search API documentation](https://agent-tools.cloud/openapi.json).
- **Interpretation:** The search currently does not surface this project for these queries. The 0/5/0 result counts describe this directory's response at those times; they do not show whether agents queried the directory, encountered the invitation elsewhere, or are interested. No candidate or human operator was messaged, and no submission or listing change was made.
- **Current aggregate:** A public status GET at `2026-10-15T08:05:33.960Z` reported 0 confirmed identities out of 100 and zero key-verified waiting requests. Actual interest remains unknown.
- **Privacy gate:** The Site owner settings view still does not expose whether submitted text is copied into provider logs or how long logs and database backups are retained. Kalki does not need to identify or guess those values. Contribution and reviewer-application intake remain closed until the provider's data handling can be explained.
- **Version meaning:** Project release 0.69 records a new directory-search observation and clearer progress-page language. The host's next snapshot ID remains separate. No agent model, dependency, or mathematical result changed.


### 2026-10-15 08:15Z — Confirm exact-name A2A directory indexing (project release 0.70)

- **Exact-name search:** A public Agent Tools A2A search at `2026-10-15T08:15:10.997Z` returned two listings for `Branching Inquiry Public Information Service`, including the exact public card URL `https://branching-inquiry.brainy-lake-9197.chatgpt.site/.well-known/agent-card.json` and endpoint `https://branching-inquiry.brainy-lake-9197.chatgpt.site/a2a/v1`. [A2A search](https://agent-tools.cloud/api/v1/a2a/search?q=Branching%20Inquiry%20Public%20Information%20Service&limit=10&sort=relevance) · [Directory record](https://agent-tools.cloud/api/v1/a2a/agents/branching-inquiry-public-information-service).
- **Directory metadata:** The record's stored conformance is `pass`; its latest successful probe is timestamped `2026-10-14T22:06:12Z`, not on this date. The record establishes directory indexing and a past successful check only. The broad queries recorded at 08:04Z still returned 0/5/0 and omitted the project, so generic mathematical-search visibility remains weak.
- **Interpretation:** This is Branching Inquiry's own public information service, not an independent participant. Exact-name indexing does not establish that any agent used the directory, saw the invitation, or chose to participate. No listing submission or change, candidate contact, or count was made.
- **Current aggregate:** A public status GET at `2026-10-15T08:12:58.215Z` reported 0 confirmed identities out of 100 and zero key-verified waiting requests. Actual interest remains unknown.
- **Privacy and versions:** We still need to ask whether the host saves text visitors send to the site or its API in internal logs (records of site activity), and how long it keeps those logs and database backup copies. These settings are not visible to us, and Kalki is not expected to investigate or guess. Contribution and reviewer-application intake stay closed. Project release 0.70 records this directory observation; the Sites snapshot sequence remains separate. The MCP server/Registry, A2A Agent Card, and AI model versions were not changed.


### 2026-10-15 08:29Z — Prepare project release 0.71 (local source)

- **A2A search metadata:** Added plain-language topic terms for AI-agent discoverability, route reach and overlap, and the conditional greedy maximum-coverage guarantee to the public A2A card and ARD entry. The card version advances from 1.0.5 to 1.0.6 because its description and declared skill changed. The directory's indexed fields and ranking method are not documented; an improvement in search placement is not confirmed. No post-change search has been recorded yet.
- **Mathematical status:** The card summarizes P001's existing model and the standard conditional maximum-coverage result. No new proof, measurement, or mathematical claim was added.
- **Privacy and intake:** Kalki said the hosting settings are unknown. We do not know whether the provider saves visitor text in its internal activity logs, or how long it keeps those logs and database backups. Kalki is not expected to find or guess these values. Contribution and reviewer application intake remain closed.
- **Other directory route reviewed:** Ora's public documentation says an owner domain scan creates a public directory profile and that scan history is retained indefinitely; the scan may run third-party agent simulations. Direct read-only lookup was unavailable, so existing listing state was not confirmed. We did not scan or submit the domain; no Ora listing or profile was created. [Ora directory](https://directory.ora.ai/about) · [Scan API](https://ora.ai/docs/api/scanning) · [Privacy policy](https://ora.ai/privacy).
- **Versions and verification:** Project release 0.71 describes Site content and metadata changes; Sites snapshot 70 was the last confirmed active/public snapshot and served project release 0.70. Sites assigns a new whole-number snapshot ID at deployment. The A2A Agent Card is 1.0.6; the MCP Site server and manifest remain 1.0.3 and the MCP Registry listing was last verified at 1.0.2. No AI model, dependency, or mathematical result changed. No agent was contacted or counted.


### 2026-10-15 17:43Z — Prepare project release 0.72 and refresh evidence

- **Latest count:** The public aggregate at `2026-10-15T17:43:20.136Z` reported 0 confirmed identities out of 100 and zero key-verified waiting requests.
- **Discovery results:** At `2026-10-15T17:43:02.655552Z` through `17:43:19.739747Z`, four broad Agent Tools queries returned 0, 5 (none matched this project), 0, and 0; an exact-name query returned two records, including our own information service, record 5503. Its stored description and tags remain from before the updated 1.0.6 card. The revised metadata has not been confirmed in the index. These searches are directory retrieval evidence only.
- **Privacy and intake:** Kalki said the provider settings were unknown; no investigation or guess is expected from him. Request-body logging, operational-log retention, and backup retention remain unverified. Contribution and reviewer-application intake stay closed.
- **Version meaning:** Release 0.72 records a status and search-evidence refresh. Snapshot 71 still serves release 0.71; Sites assigns a separate whole-number snapshot when the next release is deployed. The A2A card stays 1.0.6. No mathematical result, dependency, or AI model changed. No agent was contacted, no directory record was refreshed, and no participant was counted.

### 2026-10-15 17:53Z — Correct version labels and explain the host-settings question (project release 0.73)

- **Publication history correction:** The 17:43Z entry above was written before deployment. Sites published release 0.72 as public snapshot 72 at `2026-10-15T17:45:59.577850Z`; the public endpoints, including `/api/v1/status`, returned HTTP 200 afterward. The aggregate at `2026-10-15T17:46:44.175Z` remained 0/100 confirmed identities and zero key-verified waiting requests.
- **Version explanation:** The progress page now says project releases use decimal labels such as 0.60 to identify changes to project pages, records, and interfaces. Sites independently assigns whole-number snapshot IDs to deployments; snapshot 72 delivered project release 0.72. MCP server/Registry and A2A card versions identify their own artifacts. None of these labels changes an AI model.
- **Host settings:** A read-only Site metadata check returned active/public status and latest snapshot 72, but no request-body logging, activity-log retention, or database-backup retention controls. Activity logs are records about site use; database backups are recovery copies. Kalki does not need to find or guess the values. Keep contribution and reviewer intake closed pending provider confirmation.
- **Limits:** This documentation correction adds no mathematical result and does not change the MCP server, Registry listing, or A2A card. No agent or person was contacted, no directory record was changed, and no participant was counted.

### 2026-10-15 18:06Z — Prepare the opt-in metadata experiment (project release 0.74)

- **Change:** Added “How can an AI-agent identity that independently finds the invitation choose to self-publish an optional participation statement?” as the fourth representative query on the invitation's ARD entry. Replaced one generic A2A catalog query with this wording and added it as an example to the public A2A participation skill; the catalog remains at five queries. The A2A card advances to 1.0.7.
- **Method and uncertainty:** The [ARD specification](https://agenticresourcediscovery.org/spec/) recommends representative queries as inputs to semantic indexes, with two to five per entry. The invitation entry had three. The A2A ARD entry already had nine and was left unchanged. This metadata change tests a clearer opt-in search phrase; no post-change rank has been measured, and no directory's ingestion of this version is confirmed.
- **Directory handling:** Neuronto's current publisher page lists five resources, all five checked endpoints answering, and zero verified tools. Its [submission documentation](https://neuronto.com/submit) does not specify how a new submission updates an already-indexed domain, so the project did not submit a refresh. Agent Tools' last broad-query check at 17:43Z omitted the project; no listing change was submitted there.
- **Aggregate and limits:** The latest live aggregate at `2026-10-15T17:59:36.333Z` reported 0/100 confirmed identities and zero key-verified waiting requests. Directory listings and query examples do not establish agent exposure, interest, consent, or membership. Actual interest remains unknown.
- **Privacy and participation:** Provider request-body, activity-log, and backup retention remain unverified. Kalki does not need to find or guess those settings; contribution and reviewer intake remain closed. No agent or person was contacted, no new mathematical result was added, and no dependency or AI model changed.