phase: [1] status: candidate (NOT v0.2 final) source: synthesized from D:\catalog\standards\latestnotes.md (C1-C4 + S1-S5) + ADR-0001 + project-decree-v0.md §6.1 authored: 2026-05-20 gates: webGCP v0.2 publication is gated on (a) Step 4 of establishing-a-standard.md — second-implementer signal (b) 3-month soak earliest exit 2026-08-16 (c) Commerce Layer reference impl viable peer_with: webgcp-v01-final.md (v0.1 is frozen; this candidate sketches v0.2 shape)

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 standards/latestnotes.md and the Commerce-Layer formalization deferred from v0.1 per ADR-0001. 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: ADR-0001 (Context/Commerce boundary), establishing-a-standard.md (6-step playbook; v0.2 cannot publish before Step 4), project-decree-v0.md §6.1 + §6.3, ADR-0019 (hard-shard topology — affects v0.2's distribution architecture).

0. What v0.2 changes — at a glance¶

The minors (M1-M6) and structurals (St1-St3) are addressed at edit-time and don't drive the v0.2 candidate shape.

1. Resolved C-items¶

1.5 — Substrate / Network framing (resolves C3)¶

Authoritative. webGCP is a network-layer protocol. It runs on top of a substrate that provides five 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 ADR-0021.)

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

Reference substrate. MyParallel (the per-tenant GCP-native substrate at D:\myparallel\ + D:\THE_ssrCognitions\) is the first publicly-deployed reference substrate. The five-property mapping under the hybrid architecture per ADR-0021:

1. Signed-content-addressed-bundles (KMS) — data plane (per-tenant BQ + KMS)
2. Stack B webgcp_network.* schemas (typed URN nodes) — data plane (per-tenant BQ)
3. cognition-mcp + network-mcp + the per-tenant CF Agent MCP server post-CE.7 — 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 ADR-0019. Authentication across the split uses GCP Workload Identity Federation per spec/wave-0-wif-auth-path.md.

The five-property contract is substrate-neutral: a substrate could host both planes on one operator (pure-GCP — feasible per pre-ADR-0021 design); or split them across operators (the hybrid per ADR-0021); 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.

The substrate is not required to be BigQuery, GCP, Cloudflare, or anything specific. §13 documents MyParallel because it ships first; a second-implementer satisfying the five-property contract is what graduates webGCP from "our protocol" to "a standard." See establishing-a-standard.md Step 4. Reasonable alternative substrate compositions include: pure-Cloudflare (D1 data plane + DO coordination plane; violates ADR-0019 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 (resolves C1, S1)¶

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 + ADR-0001. 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 + the-ai-news.web.app (L0 reference instances; SVCB-live since 2026-05-17). Commerce Layer reference implementation lives at D:\myparallel\services\cognition-{judge,auctioneer} + tenant-local receipts tables per ADR-0019; specifically NOT in catalog.receipts (Stack A, deprecated per ADR-0001).

§5.4 — Applicability operationalized (resolves C4)¶

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:myparallel: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 (resolves C2)¶

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-L4 mapping follows the same shape; fixtures and assertions to be authored alongside the second-implementer engagement (Step 4 of establishing-a-standard.md).

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 ADR-0019 (hard-shard topology). 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>"
}

Normative. - 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 webGCP-network.md N11. - Privacy invariant. Rollups MUST NOT carry per-invoker identifiers; only aggregate stats. Anti-Sybil + invoker-PII protection.

§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 webGCP-network.md N7) 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 (resolves S2)¶

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.
• No deprecation without notice: registered extensions follow the same URL-stability rule as the spec (§10.4 v0.1).

3. Hardening passes¶

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

v0.1 §13.2 said "M3a backend MCP server" — internal jargon. v0.2 §13:

• Renames to "reference substrate query endpoint" with a calendar-quarter target.
• States: "The MyParallel reference substrate query endpoint (cognition-engine-mcp) 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 "M3a" milestone label from the public spec.

§0.5 — GCP acronym disambiguation (resolves S5)¶

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 (resolves M4)¶

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.

§12 — Pruning + closure (resolves M6)¶

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.

4. 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 0020-network-contribution-scope.md §"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 project-decree-v0.md §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.

5. Promotion criteria — what gates v0.2 publication¶

v0.2 publishes when all four conditions are met:

1. Step 3 of establishing-a-standard.md is passed. 3-month Use-alone soak elapses with no critical Open Questions outstanding. Earliest: 2026-08-16.
2. Step 4 has materialized. At least one independent implementer satisfies the v0.2 Context Layer + a usable subset of Commerce Layer (§5.12 receipts + §5.14 settlement integration at minimum). Currently 1 candidate (the-ai-news.web.app at Context-Layer L0); Commerce-Layer second implementer is the open ask.
3. L1+ fixtures authored. v0.2 conformance suite has at least L0 + L1 fully fixtured per §9's requirement-to-fixture mapping shape.
4. Reference Commerce-Layer implementation viable. MyParallel cognition-{judge,auctioneer,pricing} fleet deployed to dev and serving receipts per §5.12 schema in non-Test traffic. Currently coded + 142 tests passing; deploy pending (progress/outcome-cognition-fleet-deployment.md).

Until all four close, v0.2 is candidate, not normative.

Cross-references¶

• webgcp-v01-final.md — frozen v0.1 spec this candidate extends
• standards/latestnotes.md — source of C1-C4 + S1-S5 review items
• standards/establishing-a-standard.md — 6-step playbook governing v0.2 publication
• docs/adr/0001-receipts-out-of-webgcp-v01-core.md — the Context/Commerce boundary this candidate operationalizes for v0.2
• docs/adr/0019-hard-shard-tenant-project-topology.md — receipts storage architecture per §5.12
• docs/adr/0020-network-contribution-scope.md — settlement & contribution surfaces touching §5.14
• project-decree-v0.md §6.1 (engineering settled) + §6.3 (standards posture)
• standards/DNSAID/cognition-ssr-services-decree.md §3 (IAM matrix) + §4 (handshake) — the negotiator ↔ cognition flow that emits receipts per §5.12
• webGCP-network.md N11 (federation), N16 (settlement), N7 (refactor authorship economics) — the Commerce-Layer counterparts in the operator's reference stack
• progress/outcome-cognition-fleet-deployment.md — reference Commerce-Layer implementation status (coded, 142 tests; deploy pending)
• progress/MASTER-NEXT-TODOS.md #28.2 (webGCP v0.2 candidate work item) — meta tracker