Proposed · BigQuery Knowledge Publications · nothing committed
An agent can cite the right definition and still report the wrong number. Proposed: BigQuery Knowledge Publications, managed, versioned retrieval so every agent receives the approved definition with its linked rules, SQL first; later, a verified job receipt showing whether the declared calculation produced the reported number.
- Decision requested
- A BigQuery owner and a Knowledge Catalog counterpart to scope Knowledge Publications as a managed Preview; one Finance retention pilot with agreed data and budget.
- Status
- Feasibility on invented data only, each recorded run reaching a different part of the path; nothing committed.
- Checkpoint 2026-09-19
- Continue, narrow or stop against thresholds the owner has accepted.
Illustrative scenario · invented company, people & numbers
The board pack says 118%.
Retention is 96%.
8:55 a.m. At Alder, an invented software company, the VP of Finance opens the board pack for a $4 million plan to expand sales to existing customers; her agent calls 118% retention “verified.”
Wrong · counts new customers
Correct · same customers only
The VP pulls the slide. Three questions go unanswered. The agent found the definition but missed the rule beside it, reused a total-ARR query no policy explains, and holds no receipt tying query, calculation and number.
Proposed integration · four roles
What BigQuery adds to the story.
- Open Knowledge Formatauthors definitions, rules and computation declarations.
- Knowledge Catalogmakes them discoverable and governed.
- BigQuery Knowledge Publications proposedwould serve the approved version and linked rules under current access; later, check calculation evidence.
- BigQuery Agent Analytics observesobserves use, linking context references to agent activity; it does not grant access or certify results.
Especially strong when the facts an agent needs already live in BigQuery, within an agreed customer budget (proposal note).
Which definition and rule did the agent get?
Replayable context
Today
Similarity ranks candidates; it does not pin the linked rule.
Proposed
Pin a publication; with fixed inputs and equivalent current access, the same definition, cohort rule and declared calculation return together; revoked access denies the replay.
Who allowed the agent to use the total-ARR asset?
Explainable access
Today
Custom-entry metadata stops at an EntryGroup boundary; discovery alone does not explain the agent’s retrieval path, and other Catalog and source permissions still apply.
Proposed
Bind the requester to the execution identity; enforce current policy along the path; record who received what.
Did the job match the declared calculation?
Verifiable execution
Today
Finding the computation declaration does not prove the calculation ran.
Proposed · follow-on
A receipt ties job ↔ context ↔ result to the declared calculation; a substituted query leaves the number unproven.
Afterwards, Finance could ask which definition the agent received, which policy permitted access and whether the job matched the number; the records answer only while retained and visible. Replayable context does not promise identical LLM answers.
What works today. Feasibility, not the feature; invented data throughout.
- Recorded feasibility
- Retrieval selected a definition with its linked rules; a receipt withheld a number whose query and result disagreed; connected runs reached an enforcing consumer, once via graph queries. Scope: single identity, hand-pinned seeds, each run a different part; the graph run tried only the expected-success case.
- Measured retrieval
- Ordinary SQL under five seconds one request at a time, over five seconds at five at once (the comparison). Scope: retrieval only; full question-to-number time and cost are not measured.
- Still to validate
- One run combining catalog discovery, a restricted identity and graph queries, access holding inside them; a live read-back of the synthetic fact rows against their digest; a customer cohort. Scope: the restricted identity was denied on plain SQL only; Alder’s cohort has never been selected.
What the decision turns on. Every threshold below is proposed, none accepted.
The task. Retrieve the pinned definition, its linked rules and the declared calculation; release a number only when a receipt bound to that calculation checks out.
The success rule. Release with a checked receipt or refuse with a stated reason; never disclose denied content.
The decision. At the checkpoint, continue, narrow or stop against the thresholds the owner has accepted; demonstrations are not pilot validation.
Proposed thresholdsPlanning defaults · none accepted
The definitions and their versions. Fixed. One pinned bundle of Acme’s definitions, question set fixed in advance, identifying no fact data.
The fact data and its version. Chosen for the comparison, and synthetic. A fourteen-row invented fixture, pinned by a digest of the rows and columns themselves and, separately, of the loading script. Before measuring, a run must read every table back in full and match the rows and columns to their own digest, not the script’s; no live run has done this yet. It is not customer data: Alder’s cohort has never been selected. The digest, load job, expiry and what stays unverified are on record.
Volume and latency. Proposed. Five requests at once, ten thousand a day, and retrieval within five seconds for ninety-five in a hundred: planning defaults nobody has asked for; measured so far only for retrieval (above).
Freshness and retention. Proposed. A republished definition visible within a minute (one publish took 21 seconds); a pinned publication stays pinned; fifteen months of records.
Success. Proposed. Ninety-nine requests in a hundred release a number whose receipt checks out or refuse with a stated reason.
Cost. Proposed. At most five cents per answered question at ten thousand a day, counting failed attempts and reserved capacity; not yet measured.
Technical designProposed integration · early experiments
A cited definition cannot validate a different query; each run’s limits are stated once below.
A proposed integration, not a product. Everything below ran as spike code on invented Acme gross-margin data.
Retrieve a fixed context
Follow the definition’s authored links to the cohort rule and declared computation, under fixed inputs.
Shown
- A walk on vector search plus graph queries reached the sanctioned SQL and matched a relational cross-check (what the walk showed).
Limits
- It found that SQL but never ran it, from a start pinned by hand.
Evaluate current access
Access is checked along the retrieval path, bound to the requester, and recorded.
Shown
- A restricted identity was denied on the protected tables, stayed denied after revocation and never fell back to the owner’s credential (the access cases).
Limits
- Plain SQL only, never inside graph queries.
Validate the calculation
A receipt binds job, query, inputs, pinned context and result to the declared calculation.
Shown
- Checked independently of the process that produced it, the job released its number only when query, inputs and result agreed (what the receipt check showed).
Limits
- Requester’s own delegation, a locally held key, one small fixture; no independent verifier.
The three as one path
A live catalog read pins the publication, governed retrieval supplies the declared calculation, and the receipt check verifies the job before release.
Shown
- Catalog-seeded runs went from live read to enforcing consumer, held their pin while the head moved, and withheld the number when publication or content failed validation (what those cases showed).
- A restricted identity held inside the chain; nothing unauthorized was released (how that run worked and where it stops).
- One run retrieved through graph queries on Enterprise capacity and released only after the declaration and receipt checks passed (what that run did and did not show).
Limits
- All runs carried a single identity, each reached a different part, and the graph-query run tried only the case expected to succeed. The restricted-identity and graph-query runs began from hand-pinned seeds; the restricted run used plain SQL.
What is still open
The bar. One run doing all of it at once: catalog discovery, pinned publication, governed retrieval, caller-delegated computation, result-bound receipt and enforcing consumer, with access and revocation checks holding throughout.
Also unfinished
- Benchmarks: the graph cells are incomplete and the ordinary-SQL comparison has measured retrieval only, not cost or the full path.
The checkpoint. Receipt work should not wait for the graph benchmark. The opportunity narrows if cost, simpler retrieval, authorization or publication guarantees go against it. Boundaries: BigQuery editions, graph placement.
Stop or narrow
Four risks, four gates.
- Catalog lag or a stale pin
- One publication shown, another served. Gate: pin-or-fail-stale and an owned lag target.
- Ordinary SQL is enough
- SQL is the first engine; graph must justify its extra cost.
- Access inside graph queries
- Unproven. Gate: a restricted identity denied inside graph retrieval before promotion.
- A demonstration read as readiness
- Gate: promotion only after one connected end-to-end run; each example credited for its part.
Two asks · four roles
Scope Knowledge Publications. Sponsor one retention pilot.
To BigQuery: an owner and a Knowledge Catalog counterpart to scope Knowledge Publications as a managed Preview, SQL first, receipt as the follow-on; neither committed.
To a Finance owner: pilot Finance’s graph on real cohort data with an agreed budget, one path from pinned retrieval to result-bound consumption; a wrong query or missing evidence withholds the claim.
Requested roles, nobody named: BigQuery owner · Knowledge Catalog counterpart · Finance pilot owner · BigQuery Agent Analytics integration counterpart. Staffing, budget and real data: pending.