Prompt and scope
Several agents continuously generate metric definitions, runbooks, and table schemas. Design an OKF v0.2 knowledge catalog that records sources, generators, verifiers, expiry, and computation evidence while remaining readable by v0.1 consumers.
Google Cloud introduced OKF v0.2 in July 2026. Open Knowledge Format uses Markdown files and YAML frontmatter for knowledge maintained by people and agents. Version 0.2 makes provenance, trust, lifecycle, and attestation queryable while remaining additive and backward-compatible. It is a data format and governance convention, not a centralized runtime or access-control system.
What the interviewer evaluates
The interviewer wants a clear separation between who generated and who verified content, per-claim attribution through stable source IDs, executable freshness and lifecycle filtering, and an understanding that trust tiers are consumer-derived advisory signals rather than authorization. Also cover v0.1 fallback, idempotent writes, migration, hostile content, and the verification boundary of computation attestations.
Clarifying questions before answering
- Which producers write the bundle, and who owns final human review?
- Must consumers filter unverified, stale, deprecated, or only selected trust tiers?
- Should
sourcessupport external URLs, bundle-relative paths, and scope descriptors? - What execution environment, input version, and recomputation resources back an attested computation?
- Can v0.1 consumers only read old fields, or must they receive migration warnings?
A 30-second answer framework
“I would treat OKF files as versioned knowledge facts and separate production, verification, indexing, and consumption. Each concept records sources, generator and time, independent verification records, status, and expiry; claims use stable sources[].id attribution. Consumers filter frontmatter by status, trust tier, and freshness before reading the body. All v0.2 additions are optional, readers preserve unknown keys, and they fall back from timestamp to generated.at and from old citation conventions to sources. Trust tiers are derived by consumers, not used as authorization; computation evidence binds inputs, code, and reproducible proof.”
Step-by-step deep dive
1. Design the smallest concept file
Keep one maintainable concept per file with base fields such as type, title, description, resource, and tags. Put indexable and filterable metadata in frontmatter and explanations, schemas, and example queries in the body. A directory in Git gives change review and rollback without requiring a central registry at runtime.
2. Establish sources and per-claim attribution
sources records external documents, bundle-relative paths, or scope descriptors that a concept derives from, with objective signals such as author, usage count, and last-modified time. Body claims use footnotes keyed by stable source IDs rather than positional sources[0]; reordering cannot silently misattribute a claim, and consumers can compute credibility locally.
3. Separate generated from verified
generated says who produced the current content and when; verified says who confirmed it against sources or a resource and when. Missing verified means unverified; machine-only confirmation can yield machine-confirmed; a human verifier can yield human-reviewed. These tiers are advisory signals derived by the consumer, not direct authorization or compliance decisions.
4. Manage freshness and lifecycle
Use status for stable, draft, or deprecated lifecycle states and stale_after or an equivalent time for review deadlines. An indexer combines current time, source updates, and business policy to compute freshness. Stale does not mean false: the consumer decides whether to hide, down-rank, or re-verify and records the reason.
source -> generated -> verified -> trust tier
-> status/stale_after -> consumer filter -> body read5. Handle attested computations
For metrics and computed claims, record the definition, input-resource version, executor, execution time, and verification result. An attestation proves that a value was produced by the declared method; it does not prove that inputs or business interpretation are correct. OKF does not prescribe an executor or packaging, so governance must pin the environment, dependencies, and replay evidence.
6. Preserve v0.1 compatibility
Version 0.2 is an additive, backward-compatible minor version; a v0.1 bundle that adopts no new fields remains valid. Readers preserve custom and unknown keys, prefer generated.at, fall back to old timestamp, and can read the old # Citations convention when sources is absent while emitting a migration warning. Writers should provide versioned migration rather than silently rewrite history.
7. Build a trustworthy consumption pipeline
Producers commit files, validators check frontmatter, source IDs, and timestamps, verifiers write independent confirmations, indexers materialize filter fields, and consumers filter before loading bodies. Use concept IDs and content hashes for idempotence and a review queue for repeated generation. Escape and allow-list remote links, Markdown, footnotes, and agent-generated content, with audit trails.
High-quality sample answer
I would treat an OKF bundle as reviewable knowledge facts in Git. Each file contains one concept, with filterable metadata in frontmatter and explanations in the body. sources has stable IDs and body footnotes attribute individual claims. generated and verified separately record the producer and confirmer; consumers derive unverified, machine-confirmed, or human-reviewed tiers without treating them as authorization. status and stale_after drive lifecycle and freshness filtering, while stale concepts can be down-ranked or sent to review. Computed claims carry input versions, execution environment, method, and evidence, with the explicit limit that attestation does not prove input correctness. A v0.2 reader preserves unknown keys, supports fallback from generated.at to timestamp and from sources to old citation conventions, and emits migration warnings for v0.1 compatibility. Idempotent commits, hashes, review queues, and safe rendering then separate production, verification, indexing, and consumption.
Common mistakes
- Combining generator and verifier → independent confirmation disappears → record
generatedandverifiedseparately. - Using a trust tier as permission → an advisory signal becomes a security control → keep authorization in identity, policy, and resource systems.
- Using
sources[0]for attribution → list reordering misattributes claims → use stable source IDs and footnote keys. - Treating stale as false → consumer policy becomes too coarse → let consumers hide, down-rank, or re-verify.
- Claiming attestation proves truth → inputs and semantics are ignored → bind input versions, method, and verification scope.
- Silently deleting old fields during migration → v0.1 consumers break → use fallback, warnings, and versioned writes.
Follow-up questions and responses
Why not define one universal trust score in the format?
Scores depend on domain, consumer, and time; storing one makes them stale and non-portable. The format records verifiable signals, and each consumer derives a local policy from authorship, freshness, verification, and usage.
What if two independent verifiers confirm one concept?
Keep multiple verified records with subject and time. A consumer can combine human, machine, domain, or recency policies without overwriting earlier evidence.
How do you prevent arbitrary extension of stale_after?
Restrict who can change it, require source or business-owner approval, and audit old value, new value, reason, and verification evidence. Refreshing a deadline is not a content review.
What if a v0.1 consumer does not understand new fields?
It should ignore unknown fields and continue reading the base fields. Provide compatibility writes, old-field fallback, and migration warnings; do not make v0.2 extensions mandatory in every old bundle.
How does an agent-generated metric reach a high-trust tier?
Record its generation source and computation evidence, then independently verify inputs, method, and result. Only after the human review or business process succeeds should a consumer derive a higher trust tier.