webGCP v0.2 candidate — Context Layer hardening + Commerce Layer surface¶

Status. Candidate — NOT yet v0.2 final. This document sketches the v0.2 shape against the four critical (C) and five significant (S) review items raised in internal review notes and the Commerce-Layer formalization deferred from v0.1 per the reference architecture. v0.2 publication itself is gated on three conditions (frontmatter).

v0.1 stays frozen. webgcp-v01-final.md is the published Context-Layer specification; nothing in this candidate modifies it. v0.2 will publish at a new permanent URL (webgcp.org/spec/v0.2/) per webgcp-v01-final.md §10.4's URL-stability rule.

Authority hierarchy. This candidate defers to: the Context/Commerce boundary ruling, the standards-track playbook (6-step playbook; v0.2 cannot publish before Step 4), the project governance decree §6.1 + §6.3, a reference-architecture ruling (hard-shard topology — affects v0.2's distribution architecture).

1. Resolved C-items¶

1.5 — Substrate / Network framing¶

Authoritative. webGCP is a network-layer protocol. It runs on top of a substrate that provides six properties:

1. Content-addressed artifacts — every bundle response is identifiable by hash; identical inputs produce identical outputs.
2. Typed URN nodes — every queryable entity has a stable typed identifier (the URN form is substrate-defined; urn:webgcp:<substrate>:<type>:<id> is the canonical convention).
3. MCP-callable surfaces — every node exposes a callable contract per MCP / WebMCP (the L1/L2/L3 federation layers).
4. Payable invocation contracts — every invocation has a settlement primitive (in v0.2: x402 V2 payment URI embedding in the receipt — see §5.14).

5. Explicit coordination/data plane separation. A compliant substrate names where coordination lives (scheduling, queues, HITL approval, MCP server hosting, sub-agent orchestration, observability emission, per-tenant runtime) separately from where data lives (manifest stores, receipt ledgers, reputation rollups, bundle artifact storage). The two planes MAY run on the same operator/cloud or different operators/clouds; the substrate MUST name which surfaces are which. (Property added in v0.2 per the reference architecture.)

6. Declared space identity. A substrate MUST declare the space identity (model, dim, distance) of every embedding space it serves and MUST NOT compare vectors across spaces; where multiple spaces exist they are isolated lanes, and exactly one canonical space feeds any trained matcher. Neutral to which model; strict about space identity. A cross-space comparison does not error — it returns confidently ranked noise, which is why the guard must be declarative, not empirical. (Property promoted in v0.2 on 2026-07-30 from the §7 sync-item-3 resolution shape.)

Any substrate satisfying these six properties is webGCP-substrate-compliant.

Reference substrate. The reference substrate — per-tenant, GCP-native — is the first publicly-deployed one. The six-property mapping under the hybrid architecture per the reference architecture:

1. Signed-content-addressed-bundles (KMS) — data plane (per-tenant BQ + KMS)
2. The webgcp_network.* schemas (typed URN nodes) — data plane (per-tenant BQ)
3. The substrate's MCP-callable surfaces (backend MCP + network MCP + the per-tenant agent MCP server) — coordination plane (Cloudflare Durable Object) + data-plane handshake to BQ
4. x402 V2 settlement URIs in receipts (payable invocations) — data plane (per-tenant BQ receipt ledger) + coordination-plane orchestrator (CF Agent runFiber("settle:..."))

5. Explicit coordination/data split — coordination on Cloudflare Agents (Durable Objects + embedded SQLite + scheduling + queues + fibers + HITL + observability), data on per-tenant GCP BigQuery per the reference architecture. Authentication across the split uses GCP Workload Identity Federation per the reference WIF auth path.

6. Declared space identity — the canonical space pin gemini-embedding-2 / 3072 / COSINE, tiered lanes isolated per space — data plane (per-tenant BQ embedding columns). The one known deployed divergence and its convergence path are disclosed in §7 item 6.

The six-property contract is substrate-neutral: a substrate could host both planes on one operator (pure-GCP — feasible per an earlier reference design); or split them across operators (the hybrid per the reference architecture); or split further (e.g., separate identity provider for the bilateral handshake). Property 5 makes the split-or-not choice an explicit substrate property, addressable by buyers in conformance / procurement / governance review.

Property 5 — Corollary (coordination-plane behavioral invariants). A substrate whose coordination plane performs selective forwarding of work between participants MUST honor two invariants:

• No-forward of data-plane-private state. The coordination plane MUST NOT read, cache, or forward any participant's private negotiation state (budget caps, negotiation rules, private strategy). It forwards public artifacts (envelopes, bids, candidate sets, rollups) only; private state is composed at the participant's edge. This is the coordination-plane expression of the data-plane tenant isolation: a coordination plane that ingested every tenant's private strategy to compute a shared view would be a confused deputy.
• No-mix (provenance preservation). When the coordination plane selects among forwarded artifacts (e.g., picking a winning bid), it MUST forward the selected artifact by reference and retain non-selected artifacts in the audit substrate. It MUST NOT emit an artifact whose content is a function of more than one received artifact. Composition is expressed as a chain (§5.12 chain.upstream_receipt_ref) or a decomposition (§5.17 Table A blocked_by), never as a blended single artifact.

The substrate is not required to be BigQuery, GCP, Cloudflare, or anything specific. §13 documents the reference substrate because it ships first; a second-implementer satisfying the six-property contract is what graduates webGCP from "our protocol" to "a standard." See the standards-track playbook Step 4. Reasonable alternative substrate compositions include: pure-Cloudflare (D1 data plane + DO coordination plane; violates a reference-architecture ruling sovereignty for The Network reference instance but acceptable for hypothetical implementers); pure-AWS (Aurora data plane + Step Functions/EventBridge coordination); pure-Azure (Cosmos data plane + Durable Functions coordination); split-operator hybrids with explicit auth federation.

§1.5 — Context vs Commerce Layer¶

Context Layer. Knowledge retrieval, provenance, applicability gating, bundle contracts. All §5.1-§5.11 normative requirements are Context-Layer. v0.1 specified this layer in full.

Commerce Layer. Settlement (x402 V2), receipts, reputation rollup, marketplace routing. v0.1 explicitly excluded these per §0.7 + a reference-architecture ruling. v0.2 formalizes the Commerce Layer surface in §5.12-§5.15. Commerce is optional at L0/L1, MUST at L2-Governed and above (where audit + reputation are buyer-required).

Where Commerce is specified. Within this same webGCP document — not in "neighbor standards" (that v0.1 framing was misleading and is dropped). Commerce composes with x402 V2 (settlement wire format), AP2 (mandate registry), and MCP (callable surfaces), but the receipt schema, reputation rollup, and right-to-delete fanout are webGCP's own normative surfaces in v0.2.

Reference implementation status. Context Layer is live on webgcp.org + news.energypager.com (the non-author second implementer, re-identified per the reference architecture) + catalog.myparallel.dev (L0 instances; SVCB-live since 2026-05-17). The Commerce-Layer reference implementation runs as the reference substrate's judge + auctioneer services writing tenant-local receipt ledgers (per-tenant isolation per the reference architecture), never a single shared receipts table.

§5.4 — Applicability operationalized¶

Expression language. webGCP v0.2 MUST use Common Expression Language (CEL) for in_scope_when and out_of_scope_when predicates.

Rationale: well-defined; widely implemented (Kubernetes admission, GCP IAM, Envoy); language-neutral; bounded evaluation time; safe to evaluate untrusted predicates.

Composition rules. - Within a list (in_scope_when: [P1, P2, P3]): implicit AND. A KB is in-scope when ALL predicates evaluate true. - For explicit OR: callers compose a single CEL expression with || operator. Lists are not OR. - Across in_scope_when and out_of_scope_when: out_of_scope_when overrides in_scope_when. A KB is in-scope IFF in_scope_when evaluates true AND out_of_scope_when evaluates false (or is absent).

Worked example.

kb_id: urn:webgcp:example:skill:refund-triage-v3
in_scope_when:
  - 'request.purchase_channel == "retail"'
  - 'request.amount_usd <= 5000'
  - 'request.policy_version >= "2024-q3"'
out_of_scope_when:
  - 'request.region == "EU"'  # EU has separate policy; route to refund-triage-EU
  - 'request.disputed == true'

Semantics: this KB applies to retail refunds ≤$5k under policy 2024-q3+, except when the request is in the EU (different KB) or disputed (different KB).

Failure modes. - CEL evaluation error → the predicate is treated as false (KB not in-scope). Server logs the evaluation failure; ACL-equivalent error envelope returned only if no other KB matched. - Missing referenced field (e.g., request.policy_version absent) → evaluation is strict: missing required field = false (out of scope).

§9 — L0/L1 conformance fixture mapping¶

v0.2 conformance suite structure.

For each conformance level (L0 / L1 / L2 / L3 / L4), the v0.2 spec publishes: 1. The set of normative requirements satisfied at that level (e.g., L0 = §5.1-§5.11 from v0.1). 2. The set of fixture files (WGCP-LN-NNN.yaml). 3. A requirement-to-fixture map showing which fixtures cover which requirements.

L0 fixture map (v0.2; explicit).

Total: 13 fixture-level assertions across 3 fixtures, mapping 11 normative requirements (§5.1-§5.5, §5.7-§5.9, §5.11) + the 4 mitigation assertions. §5.6 (HTTP wire format), §5.10 (forbidden practices) verified by inspection rather than fixture; documented in v0.2 §9.

v0.1 was honest but unmapped. This explicit table closes the credibility-test gap.

L1 fixture map (authored 2026-07-31 — publication gate 3). Four fixtures, one per L1 pillar (§4: + multiple KBs, multiple primitives, versioned artifacts, refresh SLAs), 18 positive + 5 negative assertions, staged at /conformance/v0.2-candidate/:

Honesty flag, load-bearing: the fixtures are authored, not runnable — no L1-or-above instance is deployed anywhere, no party has ever passed them, and each fixture's own $status stamp says so (the same posture WGCP-L0-001 shipped with before the query endpoint existed). An L1 claim before a passing run is a conformance failure. Runner extension follows the first L1 deployment, per the phase-2 gate discipline.

L2-L4 mapping remains to be authored alongside the second-implementer engagement (Step 4 of the standards-track playbook) — normative prose without a fixture is not a conformance level.

§9a — Entity-generic conformance + declared degraded posture (graduated from §0a E-1/E-2, 2026-07-08)¶

Both changes are evidence-earned, not theoretical: they come from graph-wiki, a complete self-contained v0.1 implementation over SQLite whose entities are wiki_page, not skills — the standard's first non-skill registry. What it hit is what any non-skill catalog will hit.

(a) Conformance is entity-generic; skills are the worked example, not the requirement. v0.1's payload and edge conformance were phrased in skill vocabulary. A conformant catalog of a different entity type satisfies the substance without matching that vocabulary, so v0.2 re-phrases the two skill-centric checks against entity_type while keeping skills as the normative worked example:

graph-wiki's mapping (documented in the reference graph-wiki implementation §4/§7) is the first worked non-skill instance: wiki_page rows carry the type's payload (WGCP-1), and links_to / parent_of / documents are the three typed edge labels (WGCP-6). WGCP-2/3/4 were already entity-neutral and unchanged. The frozen v0.1 fixture corpus is untouched; v0.2 adds an entity_type-parameterized fixture alongside the skill fixtures.

(b) A conformant server MAY serve a query in a declared degraded posture. WGCP-4 (vector-ranked local_search + graph expansion) is all-or-nothing in v0.1 — but real deployments lose the embedding provider (outage, absence, cost gate). graph-wiki, without an embedding provider, falls back to lexical full-text ranking: functional and honest, but v0.1 gave it no way to say so, forcing a self-declared non-conformance.

v0.2 defines the honest middle: a server MAY answer local_search in a labeled degraded mode, and the label rides the typed response envelope rather than the quality loss going silent.

• The response _meta carries retrieval_mode: "vector" | "lexical" (extensible; vector = full WGCP-4 semantics, lexical = degraded).
• WGCP-4 passes only in vector mode. A lexical response is conformant as a declared-degraded response — it is never silently counted as full WGCP-4.
• The degraded label is machine-readable, so a consumer can down-weight or re-route rather than trusting a lexically-ranked result as if it were semantic. Honesty-over-silent-quality-loss is the same principle as v0.1 §5.9 (denied fields are absent, never fabricated-as-masked).

This preserves the guarantee (a vector claim means true vector search) while admitting the operational reality the frozen core couldn't express. Reference behavior: graph-wiki reports mode: fts today; v0.2 standardizes the envelope field name.

2. Commerce Layer surface (new in v0.2)¶

§5.12 — Receipts Protocol (MUST at L2+)¶

A receipt is a signed, content-addressed record of one invocation. Receipts are the audit substrate for the Commerce Layer.

Wire shape.

{
  "receipt_id": "urn:webgcp:receipt:<sha256>",
  "schema_version": "1",
  "issuer": "urn:webgcp:server:<server-id>",
  "issuer_sig": "<EdDSA signature>",
  "issued_at": "2026-05-20T14:23:00Z",
  "request": {
    "kb_id": "urn:webgcp:<substrate>:<type>:<id>",
    "kb_version": "v3.2.1",
    "idempotency_key": "<opaque>",
    "manifest_hash": "<sha256>",
    "invoker": {
      "principal_id": "<urn>",
      "mandate_ref": "urn:ap2:mandate:<id>",
      "ap2_signature": "<EdDSA>"
    }
  },
  "response": {
    "bundle_hash": "<sha256>",
    "outcome": "ok | error | denied",
    "freshness": "..."
  },
  "settlement": {
    "x402_uri": "x402:base:usdc:0x<addr>?amount=<nano>",
    "amount_nano_usdc": 100,
    "facilitator": "circle | self-hosted"
  },
  "chain": {
    "upstream_receipt_ref": "urn:webgcp:receipt:<sha256> | null",
    "depth": 1
  }
}

Normative. - L0 — MAY emit receipts (informational). - L1 — SHOULD emit receipts for any invocation with a non-zero settlement.amount_nano_usdc. - L2 Governed — MUST emit receipts for every invocation; receipts MUST be hash-chained where the bundle is composed from upstream bundles (upstream bundle_hash is the upstream receipt.response.bundle_hash); receipts MUST be retained per the substrate's data-retention contract (≥1 year is RECOMMENDED). - L3+ — receipts MUST be cross-server-verifiable: a receipt from server A invoked from server B carries B's chain.upstream_receipt_ref, and either party can independently verify the chain.

Storage. Receipts are tenant-local per the hard-shard topology ruling. Cross-tenant access is via signed content-addressed artifacts or Analytics Hub linked datasets, never via direct read of another tenant's receipt table.

§5.13 — Reputation Rollup (MUST at L2+)¶

Per-skill (per-kb_id) reputation is derived from receipts. The rollup is deterministic: given a set of receipts + a fixed rollup function, anyone can recompute reputation independently (anti-collusion).

Wire shape.

{
  "rollup_id": "urn:webgcp:rollup:<sha256>",
  "kb_id": "urn:webgcp:<substrate>:<type>:<id>",
  "version": "v3.2.1",
  "window": {
    "start": "2026-05-13T00:00:00Z",
    "end": "2026-05-20T00:00:00Z"
  },
  "stats": {
    "invocation_count": 1247,
    "success_rate": 0.94,
    "p95_latency_ms": 320,
    "quality_tier": "T2"
  },
  "feedback": {
    "aggregate_id": "urn:webgcp:feedback-aggregate:<sha256>",
    "feedback_count": 42,
    "weighted_score": 0.82
  },
  "last_invoked_at": "2026-05-19T22:01:33Z",
  "rollup_signature": "<EdDSA>"
}

Fidelity tiers (read-side simulcast). A reputation consumer MAY request a rollup at one of three fidelities; the server MUST serve at most the requested fidelity:

Lower tiers are projections of the full rollup, not independently recomputed; each tier carries the full rollup's rollup_id + rollup_signature so a consumer MAY fetch-and-verify full when the projection is insufficient. The privacy invariant (no per-invoker identifiers) holds at every tier.

Normative. - Determinism precondition (no-mix). Reputation is recomputable from receipts (the §5.13 anti-collusion guarantee) only if each receipt attributes its outcome to exactly one kb_id. An implementation MUST NOT emit a receipt whose request.kb_id is a composite of multiple invoked KBs, and a coordination plane that selects among competing bids MUST NOT blend them (Property 5 corollary, no-mix). Multi-KB composition is expressed via chain.upstream_receipt_ref (§5.12); a blended single receipt is non-conformant because it makes the rollup non-recomputable. - L2 Governed — MUST publish rollups at a stable URI per kb_id; rollup signature MUST be verifiable against the publisher's known key; window size MUST be ≥7 days. - L3 Federated — rollups MAY be federated; cross-server reputation requires HMAC-signed attestations per the reference network spec. - Privacy invariant. Rollups MUST NOT carry per-invoker identifiers; only aggregate stats. Anti-Sybil + invoker-PII protection.

Reference-implementation status (sync 2026-07-01). The recomputable reputation function is live in the reference substrate as the agents_current derived view: deterministic over truth-class-clean (canonical/derived) outcome edges, absent-means-no-proof, advisory-never-gating in discovery. Two deliberate deltas from the §5.13 wire shape: (a) the reference function exposes raw score + n and does not emit stats.quality_tier — tier bucketing is a tuned-threshold choice deferred until demand data exists; treat quality_tier as OPTIONAL in the v0.2 wire shape. (b) today it recomputes from eval-record edges, not receipts — the receipts-based recompute is the L2+ Commerce shape and stays gated with the rest of §5.12/§5.14.

Field-normalization input rules (graduated from §0a E-6, 2026-07-08 — AtCoder Heuristic Contest evaluation infrastructure). The rollup's stats are absolute per-kb_id. When a consumer compares KBs on the same task_class, the rollup that derives a field-relative view MUST obey two contest-hardened rules — the same discipline that has kept a gaming-motivated leaderboard un-Goodharted for ~15 years:

1. Degenerate-run exclusion from best-known. A degenerate outcome (crash / timeout / illegal output — receipt.response.outcome == "error") counts as a zero for its own kb_id's success_rate, but MUST be excluded from the best-known-performance baseline used to normalize the field. One broken invocation must never distort every other KB's relative standing. (AtCoder's "excluded from the MIN calculation" rule.)
2. Relative rank is derived, never stored. Where ≥2 KBs carry rollups on the same (task_class, prompt_set_hash), a relative_rank MAY be derived by normalizing a KB's metric against the best-known on that pair (AtCoder's MIN/YOUR per case), recomputed whenever a new rollup lands. It MUST NOT be written onto the rollup record — the record stays absolute and content-addressed; relativity is a query-time projection over the current field, consistent with the determinism precondition above (the field changes; the recompute is deterministic given the field).

These are rollup input constraints, not a new wire field; they bind at L2+ alongside the determinism precondition. Origin: the reference eval profile §3.4 (the eval-lane statement of the same rules) + the reference eval study.

§5.14 — Settlement Integration (SHOULD at L1+; MUST at L2+)¶

webGCP servers integrate x402 V2 settlement; webGCP does not re-specify x402.

• The settlement.x402_uri field in §5.12 carries a v2 payment URI per x402 V2.
• Settlement is out of band: the server records the URI in the receipt; the payer satisfies it via their wallet; the facilitator confirms.
• Compile-once / serve-many cost economics (resolves §12 #7 from v0.1): when a KB version is published once but served N times, the receipt records settlement.amount_nano_usdc per invocation. Authorship economics (e.g., refactor-author royalty per the reference network spec) is a roll-up at receipt batch level, not per-receipt; specified at Commerce Layer §5.13.

§5.15 — Right-to-Delete Fanout (MUST at L2+)¶

When a principal exercises right-to-delete (GDPR Art. 17, CCPA, similar), the deletion request fans out across all federated servers that hold receipts referencing the principal.

Normative. - A right-to-delete request is itself a signed receipt of type "deletion-request", addressed to the principal's federated server set. - Receiving servers MUST honor the request within 30 days; MUST emit a "deletion-completed" receipt back to the requester; MUST hash-chain to the original deletion request. - Deletion is destructive for the principal's PII fields; the receipt's structural metadata (hash chain, version, kb_id) is retained (audit substrate). - L3 Federated servers MUST relay deletion requests to upstream-chained receipts (closes the federation loop).

§5.16 — Vocabulary Registry & Extension Mechanism¶

Custom retrieval primitives + bundle field types declared via URI scheme.

• Primitive extension URI: urn:webgcp:primitive:<authority>:<name>:<version> (e.g., urn:webgcp:primitive:webgcp.org:semantic-layer:v1).
• Bundle field type extension URI: urn:webgcp:field-type:<authority>:<name>:<version>.
• Registration: webgcp.org publishes a public registry at webgcp.org/registry/v0.2/. Authorities MAY self-host their own registries under their own URN authority; webgcp.org is the canonical aggregator.
• Conflict resolution: different authorities can declare same-name primitives; the URN scopes them. Implementers cite by full URN.
• Coordination URNs (registered for §5.17 DESIGN-TARGET surfaces):
• urn:webgcp:coord:subscription:v1 — the §5.17 Table D subscription declaration
• urn:webgcp:coord:fidelity:v1 — the {score_only, summary, full} simulcast vocabulary (shared across §5.13, §5.7, Table D)
• urn:webgcp:coord:forward:v1 — the forwarding-provenance record (§3.1)
• No deprecation without notice: registered extensions follow the same URL-stability rule as the spec (§10.4 v0.1).

3. Coordination Layer surface (proposed for §5.17; PROMOTION DEFERRED per 2026-05-26)¶

Status flag: DESIGN-TARGET — the proposed §5.17 normative text below is drafted but explicitly NOT promoted to v0.2-candidate-normative status until reference-impl maturity gates (3) below close. This is the protocol-side companion to substrate property #5 in §1.5 (the named coordination/data plane separation per the reference architecture).

Why this section exists. webGCP v0.1 §0.5 + §1.3 named "coordination" as a substrate concern but left the wire-format / table-shape unstandardized. The 2026-05-26 standards-consolidation brainstorm + the 2026-05-27 team-graph-as-dogfood brainstorm surfaced that (a) the Coordination Layer machinery is already designed in the reference architecture; (b) a local team-graph dogfood is the first reference instance at small N (12 nodes; 13 edges); (c) the reference implementation's distributed coordinator services (routing, auction, and proposed scope-promotion) are the implementation layer. Pulling the proposed §5.17 text forward into this v0.2 candidate makes the layer's eventual shape explicit for external readers and second implementers, without promoting it normatively.

3.1 — Proposed §5.17 normative tables (DESIGN-TARGET; not yet binding)¶

The §5.17 amendment would standardize three tables + one extension to §5.7's retrieval-primitives table. Full schema authority lives at the reference Coordination architecture [read-only archive] §4; reproduced here in proposed-normative form:

Table A — task_coordination (claim + heartbeat + scope per the reference Coordination architecture §4.1): - task_id STRING NOT NULL - tenant_id STRING NOT NULL (per the reference architecture hard-shard scope) - claim_owner STRING (which agent / role / team owns this work; NULL = open) - status STRING (open | claimed | in_progress | done | blocked | cancelled) - heartbeat_at TIMESTAMP (last observable activity) - k_hop_scope STRING (the retrieval-scope this work touches — graph_traversal anchor) - created_at, updated_at

Table B — edge_attention (GAT-style attention coefficients per the reference Coordination architecture §4.2): - src STRING, dst STRING (the edge endpoints — typed URN nodes) - kind STRING (existing enum: depends_on | reviews | delegates | supersedes | invokes; proposed v0.2 additions for local-team coordination: paired_with | parent_of | co_steward_with per the reference team-graph dogfood §4.1) - tenant_scope STRING (* for global Graph; specific tenant_id for tenant-scoped attention) - weight FLOAT64 (0..1 attention coefficient; updates via the GAT-style rule below) - n_observations INT64 - last_outcome_at TIMESTAMP - recompute_at TIMESTAMP - PRIMARY KEY (src, dst, kind, tenant_scope)

Edge attention update rule (proposed normative; from the reference graph-retrieval architecture §3.3):

weight_new = (1 - α)·weight_old + α·outcome_score
   where α = 0.5  if n_observations < 10   (warm-up)
         α = 0.1  otherwise                (steady-state)

outcome_score is conventionally 1.0 for clean handoff completion / 0.5 for partial / 0.0 for failure. Implementers MAY refine the outcome enumeration; the GAT-style structure is normative.

Table C — promotion_queue (scope-promotion state machine per the reference Coordination architecture §4.3 + the reference stewardship overlay §4.3): - promotion_id STRING NOT NULL - tenant_id STRING NOT NULL - promotion_kind STRING (version | scope | tier) - from_state STRING, to_state STRING, from_scope STRING, to_scope STRING - state STRING (the 7-state machine: Built → Submitted → Canary → AwaitingSignoff → Confirmed → Finalized OR RolledBack) - steward_approvals ARRAY<STRUCT<role STRING, principal_id STRING, approved_at TIMESTAMP>> - created_at, updated_at

Table D — coordination_subscription (who-receives-which-forward; the SFU subscription declaration): - subscriber_id STRING NOT NULL (agent / role / team / scout URN) - tenant_id STRING NOT NULL - scope_selector STRING NOT NULL (glob/URN over what the subscriber receives — task-class, skill-class, ticket-class) - edge_kinds ARRAY<STRING> (which coordination edges to receive: depends_on|reviews|delegates|invokes|paired_with|parent_of|co_steward_with) - fidelity STRING (score_only|summary|full — the simulcast tier requested; see §5.13 fidelity tiers + §5.7) - min_weight FLOAT64 DEFAULT 0.0 (relevance floor; forwards below this edge_attention.weight are deferred/batched, never dropped) - created_at, updated_at - PRIMARY KEY (subscriber_id, scope_selector, tenant_id)

A subscriber MAY subscribe only to scopes its tenant/role is authorized for; publish authority is governed separately (a participant publishes only artifacts it owns, per the task-state-ownership map). The coordination plane forwards a published artifact to subscribers whose scope_selector matches and whose edge_kinds intersect, ranked by edge_attention.weight, at each subscriber's declared fidelity.

§5.7 extension — graph_traversal primitive (proposed normative addition to the v0.1 retrieval-primitives table): - Bounded k-hop traversal: k_hop_radius (default 1; max 3); top_k_per_hop (default 20) - Sampling weight = edge_attention.weight (importance-weighted top-K by default; implementer MAY add ε stochastic exploration) - Tier-aware retrieval architecture per the reference graph-retrieval architecture §3.4 — free=Graph Transformer global attention / small-paying=tenant-masked GT / dedicated=GraphSAGE+GAT/GIN - Fidelity (simulcast). A traversal/forward MAY carry a fidelity ∈ {score_only, summary, full}; the server returns candidate nodes at the requested fidelity (consistent with the §5.13 rollup tiers for credibility nodes). Default summary. This bounds per-consumer payload independently of top_k_per_hop. - Returns candidate set [(node_id, composite_score, score_breakdown), …] with full provenance

Forwarding provenance. A coordination plane that forwards artifacts SHOULD record each forward (from, to, fidelity_sent, weight_at_send) for audit. At L3 Federated, cross-server forwards MUST be provenance-verifiable: a forwarded artifact retains its origin envelope's signature so the receiving server can verify it without trusting the forwarder. Within a single server, forwarding provenance is an internal concern.

3.2 — Where the coordinator concept lives in this proposed surface¶

The §5.17 amendment makes explicit that no single "coordinator" service exists in webGCP-compliant implementations. Coordination is distributed across:

Anti-pattern (explicit): an implementation that consolidates routing + auction + promotion + scheduling + HITL into a single "coordinator" service violates the distributed-coordination intent. This is the MCU failure in coordination terms: a single consolidating coordinator mixes every participant's work into one synthesized view, which is lossy (provenance lost), a single point of failure, and — for negotiation — destroys the outcome→bidder attribution §5.13 depends on. The distributed router/auctioneer/promoter fleet is the SFU: each forwards selectively and composes nothing centrally. The protocol distributes coordination by design for the same reason an SFU beats an MCU at scale — selective forwarding without central mixing.

3.3 — Conformance to proposed §5.17 (when promoted)¶

When the §5.17 amendment promotes from DEFERRED → NORMATIVE, conformance would require:

1. Substrate provides the three tables (or schema-equivalent surfaces) and the graph_traversal primitive
2. edge_attention.weight update rule is observable (an implementation MAY use a different algorithm; the GAT-style behavior must be reproducible per the rule above)
3. promotion_queue state machine transitions are observable + idempotent
4. graph_traversal primitive returns candidate sets with the declared composite_score breakdown
5. Tier-aware architecture declaration — implementation declares which tier(s) it supports + which retrieval architecture maps to each (per the reference graph-retrieval architecture §3.4)
6. Select-don't-mix is observable. For a selection event (e.g., bid award), the resulting receipt references exactly one selected artifact by hash, and non-selected artifacts are retained in agent_control.audit_chain. No receipt carries a request.kb_id composed of multiple invoked KBs. (Tests Property 5 corollary + §5.13 determinism precondition.)
7. Fidelity tiers are honored. A request at score_only returns the score_only projection (not full); a request at summary returns summary; each projection carries the full artifact's id + signature. (Tests §5.13 fidelity tiers + §5.7 fidelity param.)

Three reference instances would close Step 4 of the standards-track playbook for this proposed surface: - webgcp.org (existing L0 self-conformant) - news.energypager.com (the non-author L0 second implementer; re-identified from the-ai-news.web.app per the reference architecture) - the reference substrate's team_records + edge_attention team-graph dogfood (proposed; pending Option E deploy per the reference team-graph dogfood §10)

3.4 — Promotion gates from DEFERRED → NORMATIVE (when this section becomes part of v0.2-final)¶

Anti-pattern lock applies. Per project-decree-v0 v0.4 §7 decision principle #9, this proposed surface stays at DESIGN-TARGET status until ≥3/4 (probably ≥G-CL.1, G-CL.2, G-CL.3, G-CL.5) gates close. Promotion to NORMATIVE = a separate revision of v0.2-candidate; doesn't trigger automatically when gates close.

SFU coverage note. The SFU surfaces (subscription Table D, fidelity tiers, select-don't-mix, no-forward) are exercised under the existing gates — Table D + fidelity under G-CL.2 (fixtures) and G-CL.4 (promotion_queue/selection end-to-end); no-mix + no-forward under G-CL.1 (reference impl observable). They add no new promotion gate. The gate count stays 5; the SFU edits sharpen what those gates test.

3.5 — Reference impl pointers¶

• Catalog-side dogfood: the reference team-graph dogfood [read-only archive] (Option E from the 2026-05-27 brainstorm)
• Coordination state authority: the reference Coordination architecture [read-only archive] §4 + §7 + §8
• Tier × architecture mapping: the reference graph-retrieval architecture [read-only archive] §3.4 + §3.6 (Step-1 placeholder; 0/4 gates; anti_pattern_lock applies separately for THIS standard)
• Stewardship overlay: the reference stewardship overlay [read-only archive] (the 4-role steward seed for promotion_queue signoff)
• Distributed coordinator service taxonomy: an internal reference [read-only archive] (the reference implementation's routing, auction, and scope-promotion services as the reference distributed-coordinator layer)

3.6 — Open questions for §5.17 (separate from the v0.2 candidate's other open items)¶

1. Sample rate per tier for decision-events — at production scale, every routing decision could emit an event. Free tier 10% / small-paying 50% / dedicated 100% sample rates proposed; not yet validated.
2. Cross-tenant aggregation privacy model — how do tenant T1's edge_attention weights relate to public-Graph attention weights? (Per the reference graph-retrieval architecture §3.4 small-paying tier discussion.)
3. promotion_queue mid-flight cancellation — what happens to in-flight promotions when a tenant cancels or a steward revokes signoff?
4. graph_traversal cost budget — should the primitive include a cost_budget_ms cap per query? (Affects free-tier protection.)
5. Reconciliation between task_coordination.k_hop_scope and graph_traversal retrieval anchor — same field? Different fields? Implementation choice?
6. Low-fidelity verifiability. score_only/summary projections are not independently signed (§5.13 fidelity tiers). Per-tier signing (Merkle proof over the full rollup) vs fetch-full-to-verify — deferred until a consumer needs verifiable low-fidelity.
7. Subscription cold-start. No edge_attention history at launch; warm-up from the static ownership/skill-class map (weight 0.5, α=0.5 for first 10 observations per §8) until forwarding observations accrue.

These 7 open questions DO NOT block the §5.17 amendment from publishing as proposed-but-deferred text. They DO need resolution before promotion to NORMATIVE.

4. Hardening passes¶

§13 — Reference substrate (rename / honesty surgery, resolves S3)¶

v0.1 §13.2 used internal milestone jargon for the backend MCP server. v0.2 §13:

• Renames to "reference substrate query endpoint" with a calendar-quarter target.
• States: "The the reference substrate reference substrate query endpoint is live in production since 2026-05-17. Second-implementer engagement targeted Q3 2026; webGCP Step 3 promotion (Use-alone → Invite-second) earliest exit 2026-08-16 per 3-month soak."
• Removes the internal milestone label from the public spec.

Substrate notes (graduated from §0a E-5/E-7, 2026-07-08). Two reference-substrate facts join §13 — both are honest description of the reference substrate, neither is protocol-normative (the core stays substrate-agnostic):

• BigQuery Graph reached GA (2026-07-07). GQL traversal (GRAPH_TABLE, CREATE PROPERTY GRAPH) over the reference substrate's network_graph ran on-demand with no reservation error — first evidence the Enterprise-reservation gate is lifted at GA (the reference architecture's revisit trigger; pricing review pending). The graph_traversal contract wrapper stays — it is architecture (the frozen core takes no dependency on the substrate's query language, a reference-architecture ruling), not a maturity quarantine that GA would dissolve. One residual Preview edge: label OPTIONS(descriptions, synonyms) (the natural-language graph metadata surface) is not yet accepted by the GA DDL grammar — the reference substrate keeps that metadata as DDL comments until it ships.
• Reading non-conformant surfaces. v0.1 specifies discovery for conformant surfaces; it says nothing about how the network reads surfaces that expose no manifest. The reference substrate's crawler lane (a read_surface fallback reader) runs a discovery-first ladder — /.well-known/webmcp.json → /.well-known/mcp.json → /.well-known/mcp/server-card.json — and only when none exists does it DOM-dehydrate the page (static parse, indexed interactive-element text map, no JS execution). Surface data not derived from a manifest is truth_class: inferred — it never trains a matcher and never feeds a reputation rollup (the model-collapse guard, a reference-architecture ruling; graph-retrieval §3.1). This is reference-substrate behavior today; a normative cross-implementer crawl contract is a candidate for a future Coordination profile, not core.

§0.5 — GCP acronym disambiguation¶

v0.1's "at least one prior usage in adjacent literature" sounds evasive. v0.2:

"GCP previously appeared in adjacent literature as Graph Commerce Protocol. This v0.1+ specification formally narrows the acronym to Graph Context Protocol to disambiguate from Google Cloud Platform and to scope v0.1 to the Context Layer. Commerce concerns are formalized in v0.2 §5.12-§5.15 but the protocol acronym remains 'Graph Context Protocol' regardless of layer."

§10.4 — v0.1 URL stability¶

v0.1 said /spec/v0.1/ is immutable, then described v0.1 as a working draft. v0.2 reconciles:

• /spec/v0.1/ URL → permanent freeze at the v0.1.0 release content.
• /spec/v0.2/ → permanent freeze at v0.2 publication (post-Step-4 gate).
• Working drafts use suffixed URLs: /spec/v0.2-candidate/ (this document).
• Iteration on a published spec MUST be a new major-minor version with a new URL.

§3.3 discovery — citation refresh (graduated from §0a E-3/E-4, 2026-07-08)¶

v0.1 §3.3's discovery MUSTs (/.well-known/mcp.json per SEP-1649, /.well-known/webmcp.json) stay valid and frozen — but the upstream standards they cite moved between v0.1's authoring and now. v0.2 refreshes the citations and the prose that surrounds them (a hardening pass, not a normative change to what must be served). Full delta table + reference implementation in the reference WebMCP manifest pattern §0a.

(a) MCP Server Card: SEP-1649 ratified (2025-11-25), superseded by SEP-2127. v0.1-era prose implied the card carries tool listings at a single path. The ratified reality:

• The card is a subset of the registry server.json: required name, version, description; optional title, icons, repository, websiteUrl, remotes[] (transport endpoints), _meta (namespaced extensions). $schema points at https://static.modelcontextprotocol.io/schemas/v1/<name>.schema.json.
• The card deliberately OMITS tool/resource/prompt listings — a client connects and calls tools/list; the card is pre-connect metadata only. (v0.2 discovery text must not describe the card as a tool catalog.)
• Served at three locations for client-vintage coverage: /.well-known/mcp.json (ratified SEP-1649 path), /.well-known/mcp/server-card.json (SEP-2127 consensus), and <streamable-http-url>/server-card (2127-recommended). Claude Desktop + Cursor shipped Server Card support Apr 2026.
• Reference impls: the graph-wiki server-card builder + the reference backend MCP service. The ad-hoc schemaVersion: "sep-1649/0.1" shape used by early impls is retired.

(b) WebMCP 2026-06-24 draft. v0.1-era prose says navigator.modelContext; the entry point moved to document.modelContext (partial interface Document, secure-context). registerTool(tool, {signal, exposedTo}) — signal unregisters via AbortSignal (no separate unregisterTool), exposedTo scopes visibility by origin. ToolDescriptor gained title + annotations {readOnlyHint, untrustedContentHint}; a toolchange event fires on register/unregister; Chrome 149 is in public origin trial. Still no W3C pre-visit discovery manifest, so /.well-known/webmcp.json remains an MP convention (bumped mp/webmcp/1.1 for the annotations vocabulary; 1.2 candidates maskedFields + usageRules parked). This refreshes the substrate-property #3 citation (§1.5: "MCP-callable surfaces per MCP / WebMCP") and Q10's "browser-side surfaces are WebMCP's domain" (§4 open-question closure) — both remain correct, now with current API names.

Neither (a) nor (b) changes what a v0.1 server must serve; both correct how v0.2 describes the upstream surfaces it composes with, keeping the "great citizen of adjacent standards" posture honest against ratified reality.

§12 — Pruning + closure¶

Of v0.1's 10 open questions: - Q4 (graph as first-class) — CLOSED by §0.5's Context/Commerce split; graphs are one primitive in §5.7 / §5.16. - Q7 (receipt protocol) — RESOLVED in §5.12. - Q8 / Q9 (vocabulary / conformance governance) — RESOLVED in §5.16 + §9. - Q10 (browser-side webGCP) — CLOSED: Context Layer is server-side; Commerce Layer is server-side. Browser-side surfaces are WebMCP's domain. - Q1/Q2/Q3/Q5/Q6 — carried forward to v0.2 §12; pruned for staleness.

5. Out of scope for v0.2¶

Items the v0.2 candidate does not cover; defer to v0.3+:

• Cross-protocol reputation portability. Reputation rollups in v0.2 are per-webGCP-server. Cross-protocol reputation (e.g., a webGCP skill's reputation transferable to an MCP-only context) requires a federated identity layer that doesn't exist yet.
• Trusted-execution proofs. Confidential Computing / TEE proofs for off-platform inference are credible long-term but excluded from v0.2 per the reference architecture (network contribution mechanism; the v1-verification scope originally in a superseded legacy ADR, preserved in the ADR archive §"What's not in v1 verification").
• Tokenized reputation. Reputation as a transferable token is excluded; v0.2 reputation is per-kb_id and non-transferable. Tokenization is not on the v0.2 roadmap.
• AgentOS surfaces. Client-side / Phase 2 surfaces are deferred per the project governance decree §1.
• Marketplace lifecycle MUSTs. Phase 5 marketplace (Roles/Skills/Tasks/Tickets) is substantively spec'd across other docs but its publication is Phase 2-era; v0.2 references it without normative integration.