HC / FIELD BRIEF
BigQuery + Knowledge Catalog + OKF · RFC VP walkthrough · 6 beats · 5–8 minutes

“Can I trust the Germany number?” Make the answer defensible.

Finance needs active-customer revenue for Germany. A Catalog-shaped lookup led an agent to say “verified” without a computation. A tool with a verdict field gave another agent a reason to say “unproven”. That is the runtime opportunity.

derived / demo · observer-only · nothing attested Live captures · 4 sessions · 212 events Static viewer · browser makes no GCP calls

BigQuery is the runtime of Knowledge Catalog + OKF. Catalog makes context discoverable. The runtime would make its use accountable.

The story in 30 seconds One customer question: what is active-customer revenue in Germany, and can I trust the number?

Catalog path · session 04fa3d56

“You can trust the number because it is verified.”

A successful lookup became a claim of trust. Nothing computed the number.

See the transcript · beat 3 live trace local tool · no verdict field

Verdict-carrying path · session f21ee192

“No. The number is unproven.”

A verdict field gave the agent a limit to report: “unproven” in 12 of 12 final answers.

beat 2 See the receipt · beat 5 live trace stubbed attester · no-execution

Both paths used local tools; prompts and questions differ. This illustrates the contract, not a controlled runtime comparison. The verdict path used an in-process demo pin. BigQuery execution behind that verdict remains RFC text only.

  1. The value · 1

    Trust you can defend

    Make “can I trust it?” a verdict the agent must report, with a receipt you can inspect.

    beat 3 live the 13-field Catalog template carries no verdict field at all · beat 5 seeded every receipt on this page reads UNVERIFIABLE

  2. The value · 2

    One pinned answer

    Give the next agent the same context revision, then trace which publication each run used.

    beat 6 live query attribution to seeded publications · pinning to a head stays RFC text only

  3. The value · 3

    IAM you can explain

    Aim for a boundary the size of one deployment: who can discover, publish, and read its context.

    beat 3 live the EntryGroup IAM policy, and the policy body the Catalog lookup returns · the BigQuery side is RFC text only: Phase A service accounts and table-level grants are not built, and this page claims neither

The next step: prove one governed deployment for this Germany question, from a pinned publication to a computation receipt and an attributable answer.

Optional extension: BigQuery Graph would make the OKF chain easier to retrieve: observation → snapshot → publication. RFC text only No Graph execution is shown; beats 4–5 contain the relational and adapter evidence.

Start the six-beat show →Presenter talk track · 5–8 min
Scope and terminology

Context earned by an agent → BQAA observation → derived OKF for the next agent to discover. BQAA is observer-only, not a truth score or human-in-the-loop promotion. Sync is a planned external CLI. Every receipt here is UNVERIFIABLE.

Normative text here is OKF v0.2 core plus an optional runtime profile. “OKF 2.0” is shorthand for the runtime story, not a published core change.

Loading the checked-in live captures…

1 / 6

Keys: → / N next · ← / P back · 1–6 jump · deep link #beat=1 … #beat=6

Backup · where Catalog ends and the runtime begins

For the architecture discussion after the show. The matrix separates shipped Catalog capabilities, captured results, and proposed runtime behavior; each row points to its evidence.

Open the capability matrix · shipped, demonstrated, proposed

Matrix renders with the captures…

Honest limits, printed here on purpose. The Catalog mapping itself (one entry per concept, the okf aspect, the overview body, index and log entries, parent hierarchy) is shipped and complete; the RFC adds pins and a ledger to it, not a rival projection. IAM on the EntryGroup, the type resources and the runtime tables is the only boundary enforceable today; the ownership ledger is a discipline. Nothing here claims a Dataplex built-in or a roadmap item.

Backup · five angles on the same Germany question

Use one if asked about stale metrics, history, or auditability. These are views of the same finance scenario, with session citations and explicit RFC text only limits.

Open the five customer stories and their citations

Stories render with the captures…

How this was built / IDs / job ids

Everything on this page is copied from the files in live/; the browser recomputes none of it and calls no Google API. Each BigQuery capture carries the job id it ran as, and live/bq_jobs_identity.json is the INFORMATION_SCHEMA.JOBS_BY_USER row set for those job ids, so the identity that ran every query is on record.

What is real here, and what is not
  • Real, live GCP, read on 2026-09-03 for this page: a per-session row count over okf_rfc_demo.agent_events (4 sessions, 212 rows); three of those sessions (209 rows: f21ee192…, 04fa3d56…, 1e6dfed7…) pulled by session_id with explicit bq job ids; the fourth, a63c3e86-5897-40cc-bdf3-77bfcf750b12 (3 rows, no tool call), is counted but not pulled; the never-emit scan over all 27 TOOL_COMPLETED payloads; gcloud dataplex entries lookup --view=ALL, entry-types describe, entry-groups get-iam-policy; the lookupContext REST call on the legacy entry, on eleven resources (rejected), on a missing entry, and on two entries; the Dataplex discovery document's LookupContextRequest text.
  • Real, written by the operator for this page: the eleven runtime, legacy and evidence tables plus the context_ref_resolution view from sql/setup_runtime_tables.sql, run once as raincoatrun@gmail.com (project Owner, dataset OWNER), and the seed rows for three publications, three legacy bindings, and two evidence rows. agent_events received no DML.
  • Real, shipped Catalog types, if present under beat 3: the sample setup.ts and push.ts from GoogleCloudPlatform/knowledge-catalog were built from source and run as the operator against the derived bundle the SDK adapter regenerated from the committed export (publication sha256:53bd1651… reproduced before any push). Beat 3 says which of those steps completed and shows only what the API returned.
  • Not done yet, and labelled: the Phase A service accounts, custom role, table-level grants, boundary probe, negative checks and the okf-context sync CLI itself. Beat 4 shows the specified algorithm, the IAM contract and the captured operator identity; it shows no BQ_COMMITTED or CATALOG_STAMPED because none happened. deployment_heads is empty and the page shows that empty result rather than inventing a head.
  • Honest by construction: every receipt is UNVERIFIABLE (rcpt-observe-noexec). The word ATTESTED appears only inside quoted agent answers and the labelled non-normative Phase 4 shape, never as a claim.
  • Never emitted on agent-facing payloads: concept_version_id, bundle paths, principal, SQL / query text, parameter values, raw destination table names. The scan on beat 2 is the live query result.
  • This browser: fetches same-origin static files and Google Fonts only. No BigQuery, no Dataplex, no model call.
Run it locally / re-run the queries

Static files, no build. From the repo root: python3 -m http.server 8000 then open http://localhost:8000/rfc/full-demo/. Check the page against the committed captures with python3 rfc/full-demo/tools/check_full_demo.py. Every query is in sql/; each marked statement is piped over stdin to bq query --use_legacy_sql=false --project_id=test-project-0728-467323 as its own invocation. Reader-side files contain SELECT only; sql/setup_runtime_tables.sql is the only file with DDL and seeds. See live/README.md for the capture list.