Attested Computation

An Attested Computation is a new concept type introduced in OKF v0.2 that pairs a sanctioned computation definition with a runtime verification mechanism. It answers the fifth trust-signal question: was this number produced the way we said it must be? [

Core Idea

When an agent reports a computed value (e.g., a revenue figure), the consumer needs to know whether the agent used the sanctioned computation or improvised its own SQL. An Attested Computation declares:

1. What the value means — the semantic definition (e.g., “Revenue for a fiscal year”)
2. How it must be computed — a runtime, parameters, and executor resource
3. How to verify the computation ran correctly — an attester resource that inspects the execution receipt

The agent may only fill the declared parameters; it must never author or edit the computation definition [

How It Works

A consumer runs the computation through the executor, which returns a receipt containing the execution evidence (e.g., a BigQuery job_id, the SQL that was actually executed, and the result). Then a deterministic, no-LLM attester inspects that receipt and returns a verdict: did the query that ran equal the sanctioned computation bound with the claimed parameters, and does the displayed value match the receipt’s authoritative source? [

Because the comparison is mechanical, a rewritten query, a swapped computation file, or a mutated dependency all fail the check. The consumer refuses to display the value when the verdict comes back false [

Example

In the acme_retail example bundle, the attester at attesters/sql_equality.py canonicalizes both SQLs (strips comments, collapses whitespace, uppercases known keywords) and refuses to return ok if the canonical forms differ. A swapped table name, an added filter, or a dropped JOIN all fail attestation [

Relationship to Verification

Attestation is distinct from verification:

• verified confirms the definition still matches policy (slow, doc-level, stored in the bundle)
• Attestation confirms a single run produced the value correctly (per-call, runtime, never stored in the bundle)

A stale definition can still attest cleanly; a freshly-verified definition still needs attestation on every run. That is why both exist [

Flexibility

While the OKF v0.2 blog post uses BigQuery and SQL as the example, the abstraction is deliberately flexible. Attested computations can correspond to invoking semantic models (in Looker, AtScale, or other systems), querying structured knowledge graphs, or even making arbitrary API calls [

A Minimal Implementation in the Wild

Everything above describes attestation as OKF v0.2 specifies it — a bundle, an executor, a receipt, a deterministic attester. local-knowledge-graph arrives at the same underlying distinction with none of that machinery, which is useful for seeing what the idea reduces to.

It draws a graph of a local model’s reasoning steps and colours the edges by how they were established: blue for embedding similarity — mere association — and green for what an exact evaluator settled, sums and unit conversions computed in fractions via a companion arithmetic library. A reader sees at a glance which links are plausible and which were checked.

There is no receipt, no attester resource, and no verdict that can be re-run by a consumer — so this is not attestation in the OKF sense, and a consumer cannot independently confirm anything. What survives the reduction is the part that carries the epistemic weight: verified and unverified claims are rendered as visibly different kinds of thing rather than flattened together. OKF spends its machinery on making that distinction re-checkable by a third party; the graph spends a colour on making it legible at a glance.

Implications: The two occupy different points on the same axis, and the cheap end is available immediately. This vault already tracks confidence: and contested: per page but renders every wikilink identically — an inferred connection and a source-supported one look the same in the graph export. Adopting the full attestation pattern would require executors and receipts the vault has no use for; adopting the distinction only requires that edge provenance survive into wiki/graph/. The cheap version is the one this vault could actually use.

Implications

Attested Computation makes runtime verification a first-class concept in the OKF ecosystem. For the Synaptic Lattice vault, this means that any concept page carrying a computation (e.g., a metric definition) could adopt the attestation pattern to ensure that automated agents cannot silently substitute a different computation. The pattern also aligns with the vault’s forward-only linking rule: a computation definition is a stable artifact, and attestation checks that the runtime behavior matches that artifact.

Open Questions

• Should the vault adopt the Attested Computation type for any of its own computed concepts (e.g., derived metrics in queries)?
• How should the attester resource be stored — as a vault-internal script, an external reference, or both?
• Does the receipt model work for non-deterministic computations (e.g., LLM-generated summaries)?

Related

• open-knowledge-format — the OKF spec that defines this concept type
• llm-wiki — the artifact-first pattern that makes attestation meaningful
• ingest — the operation that produces computations in a bundle
• query — the operation that consumes attested computations
• local-knowledge-graph — a minimal, machinery-free expression of the verified-versus-associative distinction

External Links

• https://github.com/punnerud/Local_Knowledge_Graph

Sources

^[raw/articles/okf-v0-2-trust-signals.md]