Onboarding into TheNetwork — the self-serve path

1. Getting access

1. Have a GCP project with billing enabled. That project is where your queries run and where their cost lands (BigQuery on-demand: per TB scanned, see §6).
2. Send your Google identity — a service account email (...@your-project.iam.gserviceaccount.com), a Google group, or a Workspace domain — to ops@webgcp.org with the domain you operate and what you intend to build.
3. You are granted BigQuery Data Viewer on the datasets in §2. Nothing else is needed on our side: bigquery.jobs.create comes from YOUR project (roles/bigquery.jobUser there), and the scan bytes bill to it.

# prove access, from your own project (this query bills ~MBs to you):
bq query --use_legacy_sql=false \
  'SELECT entity_type, COUNT(*) n
   FROM `webgcporg.catalog.entities`
   WHERE deleted_at IS NULL
   GROUP BY entity_type ORDER BY n DESC'

2. The datasets, and which tables are contract

webgcporg.catalog — the pillar (entities + edges)

~100k entities: skills, roles, profiles, tasks, agencies, sectors, extracted from real corpora and synthetic seeds, each carrying provenance and a pinned-space embedding.

Edge tables (skill↔task, role↔skill, ... — one table per pair) carry via (the mechanical derivation) and edge_origin. LLM-proposed edges live in edge_candidates until a curator promotes them — candidates are never part of the traversal contract.

webgcporg.webgcp_network — the operating graph

3. Truth-class semantics — the one rule you must not skip

Every row tells you what kind of claim it is. The vocabulary, in descending strength: canonical (ground truth from the eval or production-outcome lanes) · derived (computed views over canonical) · registry/inferred (self-declared or extracted) · synthetic (seeded; synth=TRUE).

• Directory reads show everything, labeled. A synthetic agent appears in listings with its badge — that is policy, not an accident.
• Decisions and training rank only canonical/derived evidence. If you build matching, scoring, or any learned system on these datasets, exclude weaker classes from the evidence side — the schema makes that a one-line WHERE authority IN ('canonical','derived').
• A capability claim is proven iff a canonical/derived edge in evaluated_for_edges or production_outcome_edges backs it; otherwise it is claimed. Copy that discriminator, don't invent one.

4. Query patterns (plain SQL, no services)

-- skills matching a keyword, with provenance
SELECT entity_id,
       JSON_VALUE(payload, '$.name')        AS name,
       JSON_VALUE(payload, '$.skill_kind')  AS kind,
       synth
FROM `webgcporg.catalog.entities`
WHERE entity_type = 'skill' AND deleted_at IS NULL
  AND LOWER(JSON_VALUE(payload, '$.name')) LIKE '%column%masking%';

-- a role's required skills (the capability graph)
SELECT r.role_id, r.display_name, rrs.skill_id
FROM `webgcporg.webgcp_network.role_records` r
JOIN `webgcporg.webgcp_network.role_requires_skill` rrs USING (role_id);

-- proven vs claimed skills (the evidence discriminator, verbatim)
SELECT s.skill_id,
       EXISTS(SELECT 1 FROM `webgcporg.webgcp_network.evaluated_for_edges` e
              WHERE e.skill_id = s.skill_id
                AND e.authority IN ('canonical','derived')) AS proven
FROM `webgcporg.webgcp_network.skill_records` s
WHERE s.status = 'active';

5. Semantic search, self-sufficiently

The corpus embeddings are pinned to gemini-embedding-2, 3072 dimensions, COSINE distance (embedder_version on every row — trust the column, not this page, if they ever disagree). To search semantically without our services, embed your query text in your own project on the same model, then rank in SQL:

-- 1. your project: embed the query text (Vertex AI, gemini-embedding-2, 3072 dims)
-- 2. then rank against the corpus:
SELECT base.entity_id,
       JSON_VALUE(base.payload, '$.name') AS name,
       distance
FROM VECTOR_SEARCH(
  (SELECT entity_id, payload, embedding
     FROM `webgcporg.catalog.entities`
    WHERE entity_type = 'skill' AND deleted_at IS NULL),
  'embedding',
  (SELECT @query_vec AS embedding),
  distance_type => 'COSINE', top_k => 10);

6. What it costs you (measured, not estimated)

• BigQuery on-demand bills the querying project per TB scanned (see Google's current price card; on the order of dollars per TB).
• A full-corpus vector match scans ~1.2 GB (the embedding column dominates) — roughly a cent per match at on-demand rates, measured on the ~100k-entity corpus. Metadata-only queries that avoid embedding scan MBs instead.
• BigQuery caches identical queries for 24h at $0 — deterministic embedding of the same query text makes repeat matches literally free.
• Heavy users: BigQuery capacity pricing or a 768-dim Matryoshka search column are the levers — ask, the corpus already supports prefix search spaces.

7. The optional hosted surfaces

Everything above needs none of these. When convenience beats self-sufficiency:

• the webGCP descriptor — machine-readable index of every hosted surface;
• POST /webgcp/v0/query — hosted semantic retrieval (spec §6.4–6.7);
• POST /webgcp/v0/answer — the task-answer door (extension draft);
• Attested Context — signed context bundles for agent frameworks.

8. Stability contract

Contract tables (§2) evolve additively; renames/removals are announced via this page and the descriptor before they land. Underscore-prefixed tables have no contract. The truth-class vocabulary (§3) is governed by TheNetwork's decision log and does not change silently. Questions, access requests, and breakage reports: ops@webgcp.org.