Proposed BigQuery Knowledge Publications would turn the OKF graph into replayable context for agents—with explainable access—and a later verified receipt would add evidence that the declared computation ran.
A proposal, with a reference implementation, for an optional runtime layer. Teams keep authoring in the Open Knowledge Format (OKF); each bundle would be published to Knowledge Catalog for discovery and governance, and to BigQuery so an agent’s context can be replayed, its access checked against current policy, and its calculations backed by evidence. OKF itself does not change.
This page is the engineering companion of the 5-minute decision brief: architecture, contracts, protocol, phases and evidence artifacts, with the same decision and the same limits.
5-minute decision brief → The pack says 118%. Retention is 96%. Illustrative scenario, invented company and numbers.
authors portable knowledge and its relations
discovers and governs it
would serve the approved version and linked rules under current access; later, check calculation evidence
observes use; does not grant access or certify results
An agent can cite the right definition and still give the wrong number. This proposal connects the knowledge the agent was given, the access that allowed it, and the calculation that produced the answer. The authored OKF bundle stays the source of truth; Knowledge Catalog (KC) and BigQuery each hold a derived copy with a different job.
Especially strong when the facts an analytical agent needs already live in BigQuery, within budgets the customer has agreed to; none has yet. What the examples show is set out once, with each run’s limits, under recorded examples.
Names. This page calls the proposed feature the BigQuery runtime; the decision brief calls it BigQuery Knowledge Publications (proposed): managed, versioned retrieval, SQL first, with the verified receipt as the follow-on. Neither is committed.
| Proposed guarantee | KC + OKF | + BQ runtime |
|---|---|---|
| 01Replayable context | Catalog finds entries; OKF records linked definitions and rules. The retriever still chooses which linked context to assemble. | Pin a publication and use explicit SQL or bounded relational walks to select the definition, cohort rule and declared computation together under fixed inputs and current authorization. |
| Vector search can be deterministic; the distinction is a pinned, inspectable selection contract, not identical LLM answers. The recorded graph walk retrieves linked rules. | ||
| 02Explainable access | The custom-entry projection uses an EntryGroup access boundary. Discovery alone does not explain each asset decision on the agent’s retrieval path. | Bind the authenticated requester to the execution identity. Enforce current policy across the projected assets and retain a governed record of what was returned and why. |
| Other Catalog and source permissions still apply; metadata visibility does not grant file access. | ||
| 03Verifiable execution | Discovering a computation declaration does not prove the calculation ran. | Validate a separate job ↔ context ↔ result receipt against the declared computation. Substituted SQL or missing evidence cannot substantiate the number. |
| A job ID alone cannot substantiate a number. The recorded receipt example checks query and result and enforces release at a consumer. Attestation concerns process integrity, not data quality. | ||
A graph can be the first workload on Enterprise capacity once its inputs are loaded, a route separate from the stronger case where the facts already live in BigQuery; GQL requires Enterprise or Enterprise Plus, while relational SQL and vector retrieval run on-demand. Catalog points a request to a publication; the proposed BigQuery runtime serves that authorized version or explains why it cannot; BigQuery Agent Analytics (BQAA) observes. Package mechanics: the baseline note in §04.
At 8:55 a.m. the VP of Finance at subscription software company Alder opens the pack for a 9 a.m. board meeting. A $4 million expansion plan leans on her agent’s “verified” 118% retention; an analyst spots that the query counted new customers, and revenue from the starting customers fell 4%. All amounts are annual recurring revenue (ARR) over one quarter:
| Calculation | What it counts | Result |
|---|---|---|
($9.6m + $2.2m) ÷ $10.0m | Closing ARR from the starting customers plus new customers | 118% — wrong for retention |
$9.6m ÷ $10.0m | Closing ARR from the same starting customers only | 96% — retention |
She pulls the slide. The agent found Finance’s definition but missed the accompanying rule; it reused a total-ARR query she cannot trace a policy for; and no execution receipt connects the query, the retention calculation and the reported result.
The proposed runtime answers those three questions separately: retrieve the linked definition and cohort rule with the declared computation; explain current access along that path; validate the actual query and result against the declaration. A good context selection cannot validate a different query. Read the short board-pack story and system diagram →
The source bundle is canonical. The compiler records source observations, resolves the artifact closure and produces immutable snapshots and publications; Catalog exposes governed discovery; BigQuery serves the compiled graph and runtime evidence; policy and telemetry have separate authorities.
| Plane | Primary responsibility | Authority |
|---|---|---|
| Source OKF bundle | Definitions, authored relations, computation declarations and review history | Canonical authored source; no mandatory BigQuery dependency |
| Knowledge Catalog | Discovery, ownership, lifecycle and links to assets | Derived discovery projection; identifies the publication it describes |
| BigQuery runtime projection | Pinned retrieval, current-policy enforcement and computation evidence | Derived relational projection; serving authority for this profile |
| Agent Analytics | Observe tool use, correlation and evaluation | Observer decides neither knowledge truth nor authorization |
Between source and projections sits the compiler / publication plane: observations, artifact manifests, snapshot membership, sync runs. Corrections flow through the source bundle, never as silent runtime mutation.
01 selects context. 02 controls disclosure. 03 validates execution. The requester is authenticated before context is returned, and current access constrains every candidate and traversal hop: policy is checked before each disclosure, not audited after. A retained selection manifest explains the context supplied; only the separate computation path can establish that the declared calculation produced the reported result.
Architecture status. A proposed connected design; the recorded examples exercised separate pieces of it. The attester is a target that still needs a trusted result-evidence path and an enforcing consumer (§06).
Decided for this RFC and stated as positions, not a menu.
Scope — an optional profile, no OKF core change. The profile compiles unchanged OKF v0.2 input and defines only normalized runtime records and enforcement behavior. It adds no authoring syntax and makes neither BigQuery nor Catalog mandatory; the Phase 0 fixture passes a spec-derived §11 inspection unchanged, and every key read is core or a tolerated producer extension (§06).
Placement — toolbox/okf-context/PROFILE.md, plus a one-page Discussion in open-knowledge-format. The normative document lives beside its implementation. The non-normative Discussion introduces the profile and the conventions it tracks and implies no implemented runtime. Not knowledge-catalog/okf/proposals/: that tree is frozen.
Implementation — a separate package, toolbox/okf-context, depending on kcmd as a library. kcmd reconciles catalog metadata pull-then-push; this profile is append-only, push-only and BigQuery-first. Reused: the shipped sample’s staging into Documents Layout and its kcmd push, which creates or patches entries and does not reconcile deletes. The ownership ledger and delete-only-what-you-own reconciliation are this profile’s addition.
Authority — one source, two independent reconcilers. BigQuery’s relational deployment head is the serving authority; Catalog is the governed discovery projection. Both carry the same bundle, observation, snapshot, publication and deployment IDs. A Catalog failure never rolls back a committed publication.
Workflow — source-authoritative, push-only. validate | plan | push | status. No Catalog pull, no source reconstruction, no Catalog-side edits to source-owned fields. A runtime export, if ever built, is labeled lossy; Catalog-native annotations, if allowed later, live in a separately owned aspect and never enter snapshot identity.
Source conventions — consume adopted syntax only, in this order.
supersedes / contested_by (OKF thread #195), the only convention with shipping producers and query-time semantics, which the current retrieval mode depends on.links: carrier (#183) with rel as predicate (#148); confidence maps onto assertion_mode.producer:<rel>.okf-bundle entry type and okf aspect. Runtime pins and ownership stamps live in a profile-owned okf-context-runtime aspect, which a stock kcmd push never stages and so never overwrites; a separate okf-computation aspect carries runtime-derived facts. semantic-* types are not reused in v1, because the semantic-model push deletes orphans under its own prefixes.If accepted, receipt and graph work continue in parallel; receipt enforcement never waits for graph results or benchmark completion.
On the name. Informally still “the OKF Context Graph RFC”; normative text says OKF runtime context projection, because BigQuery Agent Analytics already uses “context graph” for a telemetry-derived graph of agent behavior. The OKF v0.2 spec lives in GoogleCloudPlatform/open-knowledge-format; knowledge-catalog/okf/ is a frozen snapshot the shipped sample still pushes from, so the compiler accepts a bundle root from either repository.
Shipped baseline. Google’s 2026-08-26 post “Scale OKF bundles across an organization with Knowledge Catalog” ships the distribution mechanism: the toolbox/mdcode/demo/okf sample registers an okf-bundle EntryType and a 13-field okf AspectType, and kcmd push publishes every markdown file as an Entry that inherits EntryGroup IAM and is reachable through searchEntries, LookupContext and entries.get. This RFC layers an optional runtime profile on that; it replaces nothing.
What this profile adds. An immutable publication a request can pin, authorized retrieval with a retained selection manifest, and independently validated computation evidence. Pins and ownership stamps belong in the separate okf-context-runtime aspect, never in the shared okf aspect or authored frontmatter. A Catalog-discovered seed carries the publication it describes: the runtime serves that retained, authorized publication or fails stale, never the latest head, and status reports by how many publications the projections disagree.
BigQuery and Catalog have no shared transaction. Immutable rows stage under an uncommitted sync_id; BQ_COMMITTED is the atomic advance of deployment_heads to a new publication_id, when *_current views become visible. Catalog reconciliation follows and never rolls back a committed publication. No recorded run shows this protocol.
KC_RECONCILING is a legal resting state, but lag is a metric with an owner and an SLO per entry count; persistent reconciling is an incident.publication_id and published_snapshot_id on the profile-owned okf-context-runtime aspect. A Catalog-started request reads them through entries.get with view=ALL; the runtime serves that retained publication or fails stale. Agent tools never read Catalog for lifecycle decisions.okf fields that view=ALL reads exposed (metric, computation, full metric entry, full computation entry).deployment_heads answers “what is current now”; deployment_heads_history answers “what was current for deployment D at time t”. Both are Phase 1 deliverables.bundle_key — stable identity of one logical source bundle, independent of revision, deployment and publication attempt.concept_key — bundle_key + "#" + concept_id, the bundle-relative path without .md; changes on a file move. index.md and log.md are bundle content, not concepts, though the Catalog projection still emits them as owned non-concept entries.concept_version_id — canonical structured hash of (concept_key, normalized_frontmatter, normalized_body); one version can appear in many revisions.observation_id — one observation of the source: hash(bundle_key, source_uri, revision).snapshot_id — deterministic identity of the complete compile-input closure under compiler_semantics_version; it identifies inputs, not compiled output.publication_id — one observation compiled to one snapshot and committed to one deployment; deployment_heads points to a publication.deployment_key, sync_id, index_build_id, envelope_id, receipt_id — deployment, operational attempt, index build, delivered context package, execution-evidence record. A receipt’s existence implies no verdict.snapshot_id = SHA256("okf-context:snapshot:v1\0" || canonical_cbor({
bundle_key, source_manifest_hash, canonicalization_manifest_hash,
compiler_semantics_version, semantic_config_hash,
vocabulary_manifest_hash, resolver_manifest_hash }))
publication_id = SHA256("okf-context:publication:v1\0" || canonical_cbor({
deployment_key, observation_id, snapshot_id, profile_contract_version }))Republish semantics. Retrying an identical publication is a no-op; a new observation of an unchanged snapshot creates a new publication row and advances the head with no new semantic rows, a provenance event. All structured identifiers use domain-separated canonical encoding.
Semantics-affecting config belongs to the snapshot; chunking, embedding and index parameters to the index build; project, dataset, IAM mode, retention and region to the deployment; retrieval-selection inputs to the retained envelope manifest, never to snapshot identity.
Membership maps logical identities to exact versions per snapshot, logically complete and immutable; deletion is absence from the next snapshot. This is immutable system-time history, not bitemporality.
computation_version_id = hash(concept_version_id, parameter_schema_hash,
computation_artifact_hash, executor_artifact_hash,
attester_artifact_hash, runtime_contract_version)A computation is reconstructible only when every load-bearing artifact is retained by content hash or immutably content-addressed. The compiler never merges two documents into one concept on similarity alone.
| Class | Keys | Handling |
|---|---|---|
| OKF v0.2 core | type, title, description, tags, status, stale_after, sources, generated, verified, resource; §10 runtime, parameters, computation, executor, attester | Consumed |
| Producer extensions (§4.1) | supersedes, contested_by; links[]; validity | Tolerated; consumed when present, never required |
| Anything else | — | Ignored; preserved opaquely in the okf aspect |
Resolved bundle-internal Markdown links compile to a generic explicit edge under a profile-local predicate (context:untyped_link), since OKF v0.2 links are untyped. The compiler never guesses a stronger predicate or invents a cohort relation from similarity.
logical_relationship_key = hash(source_key, canonical_predicate, direction, target_ref)
relationship_assertion_key = hash(logical_relationship_key, assertion_mode, source_kind,
evidence_locator, producer_assertion_id | source_occurrence_id)
target_ref = "resolved:" + concept_key
| "unresolved:" + normalized_authored_target # namespaced, never null-collapsedEquivalent edges from multiple sources stay distinct assertions; assertion_mode (explicit | imported | deterministic-derived | inferred) is always preserved. Catalog receives only the links it can express.
Edges may target a resource_uri, a real BigQuery table; resolution is external state, so resource nodes get versions and snapshot membership, pinned via resolver_manifest_hash. Unresolved assertions keep the authored target under a namespaced unresolved: key, so two missing targets never collapse into one. The optional Property Graph projection includes resolved edges only.
Append-only version tables, snapshot membership, snapshot_observations, publications, deployments, deployment_heads, deployment_heads_history, sync_runs, execution_receipts and the ownership ledger. Current views resolve through deployment_heads; “current” is always current for a deployment.
Relational is authoritative. Seed lookup, bounded expansion, evidence traversal and path explanation work through relational queries; the baseline and receipt delivery do not depend on Property Graph. Two kinds of determinism: compilation reproduces snapshot_id from the semantic input closure; controlled retrieval reproduces selected context from the publication and selection contract. Index builds, ranking, policy evaluation and packing are separate inputs.
Property Graph is optional. A nodes_current view unions concept and resource nodes. The profile must test its versioned projections, element-key uniqueness, permissions and relational/GQL equivalence in Phase 5; graph names must not collide with kcmd’s semantic-model graphs.
Product boundaries. GQL requires Enterprise or Enterprise Plus; GRAPH_EXPAND is not a general substitute for an OKF link graph; graph-native semantic search is Preview and was not tested. Google’s placement guidance separates analytical work from online neighborhood retrieval, so the broad serving-tier case stays tentative.
Keywords, vector similarity or a model-selected seed find candidates; they do not bind a definition, its linked rules and its computation into one repeatable selection. The controlled path starts from a fixed selection over a pinned publication:
authenticate requester → evaluate current policy
→ seed (explicit selection; lexical / semantic discovery optional)
→ structured filters → bounded relational expansion over the pinned publication
→ dedupe → stable rank + tie-break → token-bounded Context Envelope
→ retain selection manifest → emit context_refWhat must be fixed: publication, seed IDs, query or walk definition and bindings, versioned facts, traversal limits, lifecycle time and mode, ranker and index build, stable ordering, output schema, tokenizer and packing budget. With those fixed and equivalent access, the path selects the same versioned items, paths, ordering and shape; it need not reproduce timestamps, envelope IDs or the LLM’s answer.
Current authorization applies before disclosure and at every hop, evidence fetch, computation and cached envelope; an authorized seed must not traverse an unauthorized intermediate node. A historical publication does not preserve permission to read it, and the runtime never restores historical privileges. Fail closed when access cannot be evaluated.
Policy authority, v1. OKF frontmatter is not an ACL. One security domain per bundle and deployment, with caller-delegated BigQuery authorization as the policy source; mixed-policy bundles fail closed. In the Catalog projection the EntryGroup is the access boundary for published bodies, so a bundle with mixed body visibility is never projected into one broadly readable EntryGroup (Catalog IAM permissions).
Who accessed which asset, under which policy? Bind the authenticated requester to the execution identity at the trusted runtime boundary; retain the policy version and permitted-asset decisions in privileged audit records. Caller-visible explanations expose authorized paths only, with no denied counts. A shared service account cannot identify the agent’s user.
current: exclude status: deprecated and concepts made out-of-force by an
affirmed supersession before ranking; apply application policy to
status: draft; warn/down-rank stale; surface contests
historical: resolve through the requested publication or authored valid time
all: discovery/debug mode with lifecycle state visiblestale_after is a warning and ranking signal, not an exclusion. Concept body text is untrusted content and is never promoted into a privileged instruction channel except through a policy-controlled allowlist.
envelope_id is an opaque, random, tenant-scoped identifier, not a content hash, because a deterministic hash is linkable across users and runs. Cache-reuse equality is a privileged keyed digest in the manifest:
policy_context_commitment = HMAC-SHA256(tenant_scoped_key,
"okf-context:policy-context:v1" || 0x00 || canonical_cbor(effective_policy_context))
envelope_equality_digest = HMAC-SHA256(tenant_scoped_key,
"okf-context:envelope:v1" || 0x00 || canonical_cbor({ publication_id, index_build_id,
policy_context_commitment, ordered_items, rendered_content_digest, packing }))The retained manifest lives in the runtime dataset under source-equivalent IAM and records policy and ranker versions, tokenizer, budget, ordered item IDs, paths and warnings; principal identity never enters it, and possession of an envelope_id grants nothing. It is the proposed “retrieval receipt”: a record of context selection, not proof that the metric ran.
Retrieval identifies the declared computation; execution must separately demonstrate what ran. The Attested Computation path binds context publication and envelope, computation artifact, complete declared parameter bindings, caller-delegated BigQuery job and result path, and ties the reported result to that execution. The agent binds declared parameters only (OKF §10): it cannot edit SQL, swap the computation or bypass the attester. For the story: total-ARR SQL under the retention declaration is rejected, missing evidence is UNVERIFIABLE, and 118% cannot be presented as attested.
Execution is caller-delegated under the caller’s BigQuery identity. The attester runs as an independent, constrained service identity, because a caller-run attester can be subverted. Job metadata cannot bind the reported value to the authoritative result, so the profile also requires a trusted result-evidence path and an enforcing consumer; broad source-row access stays excluded.
Attested SQL executes with named query parameters, so the executed query string is the template and bindings appear in job configuration; the attester compares both literally.
ATTESTED requires authoritative artifact identity, complete parameter binding, authenticated caller, job metadata, result destination, output authorization, authoritative result binding, attester key validity and evidence digest. Anything less is UNVERIFIABLE or REJECTED; unavailable evidence never degrades to success. A consumer releases a result only after validating a matching verdict.
The execution receipt presented to the attester may include executed SQL, bound parameters, result and job metadata; the persisted projection stores commitments, verdict, details digest and an integrity_proof with algorithm and key ID. Verifiers reject a canonicalization version they do not understand.
parameter_binding_commitment = HMAC-SHA256(tenant_scoped_key,
"okf-context:parameter-binding:v1" || 0x00 || canonical_cbor(parameter_value_map))Low-entropy parameters make plain hashes dictionary-attackable; key custody, rotation, revocation and crypto-erasure are Phase 4 gates.
Threat model: attestation protects against an agent substituting an improvised computation, parameters or displayed result. It assumes the executor, BigQuery, the attester runtime and the receipt-integrity mechanism are trusted, and proves nothing against a compromised executor, attester, credential, administrator or data source. It is evidence of process integrity, not of data quality.
Attesters are bundle-authored code, possibly agent-written: sandboxed, restricted identity, reviewed like the computations they attest.
Agent Analytics is observed, not a fifth source of truth. This profile never writes to agent_events; it emits one versioned sub-object, context_ref, on every tool response. BQAA neither grants access nor upgrades an unproven verdict.
context_ref:
profile_contract_version # "okf-context/1"
bundle_key, observation_id, snapshot_id, deployment_key, publication_id
index_build_id # only when an index was used
envelope_id # search / expand / pack results
computation_version_id, receipt_id, bq_job_id, verdict # run_attested_computation only
candidate_bucket # coarse bucket, never an exact denied/filtered count
included_count
warning_codes[] # stale, unresolved, contested, draft — codes onlyPacked items carry a citation token [okf:<envelope_id>#<n>] so a later “was it cited” analysis joins on envelope_id. Never emitted: concept_version_ids, graph paths, authored locators, principal, policy context, raw query, prompt, answer text or bound values; telemetry holds opaque IDs only. BQAA owns the event envelope, tool events, the attributes key, truncation, OTel correlation, principal pseudonyms, retention, evaluation, citation detection and Knowledge Health, decided in the companion RFC in the BQAA SDK repository.
Mapping. One okf-bundle entry per concept with the shipped okf aspect as the sample writes it; the profile-owned okf-context-runtime aspect on every owned entry; an okf-computation aspect on §10 concepts; index and log entries as owned non-concept entries; links to existing BigQuery asset entries. Only relationships with matching Catalog link semantics are materialized; the full ledger stays in BigQuery.
Ownership. Ownership is tracked in a BigQuery ledger keyed by deterministic deployment-scoped IDs, and reconciliation removes only artifacts this deployment owns. Phase 2 tests coexistence against a semantic-model push and a Documents-Layout push of the same bundle in the same EntryGroup; the sample’s repush leaves okf-context-runtime untouched, so pins survive it. catalogEditor can delete across the EntryGroup, so one EntryGroup per team is the boundary.
No mandatory BigQuery/Catalog dependency for OKF; no new OKF authoring syntax or core predicates; no universal ontology or required semantic-web stack; no LLM-guessed typed edges; no universal truth score; no telemetry in the source bundle; no frontmatter-as-access-control; no Catalog→source writeback in v1; no arbitrary agent SQL; no low-latency transactional graph workloads; no telemetry schema in this RFC.
These guarantees hold only while the needed records are retained and the caller is still authorized; the levels are distinctions in the proposed contract, not experimental scores.
If the number is questioned months later, each answer holds only while the record is retained and the auditor is authorized now.
| The question | The record that answers it | Defined in | When the honest answer is “no” |
|---|---|---|---|
| Which version of the definition and cohort rule was in force? | Publication and observation on context_ref | §07 levels 1–2 | Only while membership and versions are retained; system time, not business time. |
| What exactly was the agent given? | Retained envelope manifest, via envelope_id | §07 level 3 | Revocation, quarantine, purge or expired retention; the auditor needs runtime-dataset access now. |
| Was the agent allowed to use the total-ARR asset, and under which policy? | Privileged access record | §06 Replayable retrieval | Missing history means unavailable, not unauthorized. |
| Did the number come from the declared calculation? | Execution receipt, via receipt_id, bq_job_id, verdict | §07 level 5; §06 Attested Computation | UNVERIFIABLE or REJECTED stays so; a verdict does not prove the number was released. |
| Can we get the same 96% again? | Receipt plus retained data-version evidence | §07 level 6 | Mutable facts or an expired time-travel window; the receipt still shows what ran. |
| Would the agent select the same context today? | A controlled rerun over the current head with the same query, bindings and packing | §07 level 4 | A new publication, index build, policy context or packing budget is a different input. |
Accepting this RFC agrees to a design and its gates. It does not mark those gates complete.
UNVERIFIABLE; Attested Computation is the only path carrying this profile’s attestation claim, with an independent attester, a trusted result-evidence path and consumer-enforced release.context_ref and receipts and specifies nothing else about telemetry.Deferred to their phase: body storage location, typed graph labels, the exact attributes key, the retrieval-manifest serialization, policy-resolver grants, benchmark corpus, historical-retrieval defaults, Property Graph compatibility.
Every gate regresses against the Phase 0 fixture, the Germany active-customer-revenue question; Alder adds an illustrative acceptance case per phase. Receipt enforcement proceeds in parallel and never waits for optional Graph support. The connected path is proven only after one chain runs end to end with the negative tests passing; the recorded examples do not yet clear that bar.
| Phase | Outcome | Gate | Explicitly out | Who cares |
|---|---|---|---|---|
| 0 — Contract + fixture | Profile spec, fixture bundle, golden vectors, probes; controlled-retrieval inputs specified before implementation | §11 pass; second hash implementation agrees; BQAA and maintainer sign-off | Receipt crypto, embeddings, Graph, Catalog, telemetry | OKF maintainers, BQAA |
| 1 — Compiler + BQ core | validate|plan|push|status; append-only tables; lexical answer with provenance; relational projection as a first workload | Republish/no-op, head history, unresolved-link and file-move tests; stable ordering preserves linked paths | Catalog, agent tools, attestation | BigQuery runtime |
| 2 — Catalog projection | okf-bundle entries and aspects via kcmd; ownership ledger; lag metric | Idempotent re-push; adversarial coexistence; pin-or-fail-stale through the full-entry read path | semantic-* reuse, writeback, health aspect | Catalog, OKF maintainers |
| 3 — Retrieval + access | Four ADK/MCP tools; opaque envelope_id; retained manifest; requester binding; context_ref | Authorization at every hop; fail-closed mixed policy; controlled retrieval repeats under fixed inputs; denied intermediate and revoked replay disclose nothing, including inside graph queries | Embeddings until lexical passes | BigQuery runtime, BQAA |
| 4 — Execution evidence | run_attested_computation; independent attester; receipts binding job ↔ context ↔ result; consumer-enforced release; BQAA companion RFC | All negative tests fail attestation; missing evidence → UNVERIFIABLE; key lifecycle exercised; telemetry join | Attester data access, non-BQ executors | BQAA, BigQuery runtime |
| 5 — Hardening + pilot | Optional Graph and embeddings; benchmarks; a Finance-owned pilot with drills | Relational ≡ GQL on the fixture if Graph is enabled; stated corpus and concurrency with latency, cost, freshness and upkeep; comparison with KC/SQL, Neo4j and Spanner Graph; customer-accepted budget; drills pass | RDF adapters, writeback, low-latency serving (parked) | Everyone; pilot owner |
Graph walk. The recorded graph walk ran on an Enterprise reservation from a retired Acme definition, followed two links to the declared SQL and returned its status, trust, freshness and provenance, matching a relational cross-check; the SQL was found, not run.
Access and benchmarks. A separate restricted identity was denied where it should be on the relational path over the protected tables (access case records); the same cases have not run inside graph queries. The graph benchmark is unfinished (0 of 9 cells); the ordinary-SQL comparison has measured its four retrieval cells on on-demand capacity, while its request-to-consumer cells have a hermetic-only runner, never run live (their fact data is a selected synthetic fixture, not customer data; the Alder cohort stays unselected), and its cost cells are unmeasured.
Receipt check. The recorded receipt check ran a BigQuery job under the caller and verified it independently of the process that produced the result, releasing the number only once query, inputs and result agreed and withholding it in the wrong-query, wrong-parameter, substituted-display, tampering, replay and missing-evidence cases, under the requester’s own delegation rather than an independent attester.
Connected chains. Catalog-seeded chains began at a live read of a catalog entry, checked the returned pin against already-trusted configuration, retrieved the declared calculation through governed retrieval on plain SQL and handed it to the receipt check; the consumer released the number only after that check passed, and a substituted query and a mismatched declaration were refused (what those cases showed). One run carried both legs under a deliberately restricted identity (how that run worked); one run retrieved through graph queries, for the success case only. The restricted-identity and graph-query runs began from hand-pinned seeds; the restricted run used plain SQL.
What remains to prove. One chain combining a live catalog read, a second identity, graph queries and an independent attester. Code and notes: graph example · receipt example.
PROFILE.md (identity chain, hashing and canonicalization with golden vectors, retrieval modes, envelope schema, attester identity model, BQAA seam), one sample bundle modeling the Germany question with golden identifiers and a receipt specimen, and capability probes of kcmd and of the attester’s result-evidence path.context_ref seam; maintainers agree to placement.validate | plan | push | status; version tables, membership, publications, deployment_heads, deployment_heads_history; lexical search; relational traversal. A publication-scoped lexical query answers the fixture question with provenance.sync_id rows invisible to *_current; unresolved targets never collide; a file move is delete-plus-create; “what was current for deployment D at time t” answerable from history; repeated publication-scoped selection uses explicit stable ordering.okf-bundle entries and okf aspect as the sample writes them, the profile-owned okf-context-runtime aspect, the okf-computation aspect, index and log entries, links to existing BigQuery asset entries, produced through the kcmd library; ownership ledger; status reports lag.BQ_COMMITTED with state KC_RECONCILING; a presented pin serves that publication or fails stale.semantic-* type reuse, writeback, health aspect, Property Graph.search_context, expand_context, get_evidence, explain_context as ADK tools with an MCP wrapper; opaque envelope_id; retained selection manifest; requester bound to the execution identity; privileged access records; context_ref on every result.run_attested_computation; named-parameter execution under caller-delegated identity; one reference attester under its own constrained identity with a trusted result-evidence path; receipts with keyed commitments and integrity proofs; a consumer that releases only on a matching verdict; companion BQAA RFC merged.UNVERIFIABLE); total-ARR SQL under correct context and a substituted display are rejected; key rotation and crypto-erasure exercised; the telemetry join carries no path, principal or query text.nodes_current / edges_current; versioned index builds and optional embeddings; benchmark corpus; CI gates; a limited Finance-owned production pilot with lag, rollback, key-revocation, purge, cost and DR drills and an on-call owner.| Risk | Mitigation | Gate |
|---|---|---|
| Catalog lag: one publication shown, another served | publication_id on every owned entry; pin-or-fail-stale; lag SLO with owner | Phase 2 |
| Two pushers in one EntryGroup | Ownership ledger and deterministic IDs; pins on an aspect a stock repush never stages; one EntryGroup per team | Phase 2 |
| “Pinned” retrieval still uses unstable inputs | Version selection inputs; stable ordering; separate discovery from controlled retrieval | Phases 1 and 3 |
| Historical context restores revoked access | Reevaluate current policy, cached output and intermediate nodes | Phase 3 |
| Envelope manifest as sensitive as content | Runtime-dataset IAM; opaque envelope_id; keyed policy-context commitment | Phase 3 |
| Context citation mistaken for computation evidence | Separate selection record from validated receipt | Phase 4 |
| Attester subverted by the caller | Independent constrained attester; named parameters; complete-evidence verdicts; trusted result-evidence path | Phase 4 |
| Receipt keys expire before the receipts do | Key lifecycle and crypto-erasure as gates | Phase 4 |
| Property Graph quietly becomes the contract | Relational authority; receipts never depend on Graph | Every phase; Phase 5 for Graph |
| Path identity breaks continuity | Delete-plus-create stated plainly; optional alias ledger | Phase 1 |
| Customer budget, Enterprise capacity or a simpler alternative undercuts the case | Stated corpus and concurrency; latency, cost, freshness and upkeep; comparison with KC/SQL, Neo4j and Spanner Graph; customer-accepted budget | 2026-09-19 checkpoint; Phase 5 |
| One example read as product readiness | Promotion only on connected end-to-end evidence; each example credited only for the part it exercised | 2026-09-19 checkpoint; Phases 3–5 |
OKF supplies the authored definition, relations and computation declaration; Catalog makes them discoverable and governed; the proposed BigQuery runtime would select a pinned context, explain current access and check execution evidence; BQAA observes.
Proposed BigQuery Knowledge Publications would turn the OKF graph into replayable context for agents—with explainable access—and a later verified receipt would add evidence that the declared computation ran.
Two asks. 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: sponsor a retention pilot on real cohort data with an agreed operating budget, connecting catalog discovery, pinned retrieval, current access checks, caller-delegated computation and result-bound consumption in one path. Reassess at the 2026-09-19 evidence checkpoint: continue, narrow or stop against thresholds the owner has accepted; the opportunity narrows if budgets or Enterprise cost cannot be met, if simpler retrieval serves the need, or if result evidence cannot be trusted and enforced.
Requested roles, nobody named: BigQuery owner · Knowledge Catalog counterpart · Finance pilot owner · BigQuery Agent Analytics integration counterpart. Staffing, budget and real data: pending.