Bidda Signed Records, Point-in-Time and Run Ledger
===================================================
JS-free text mirror for AI crawlers. Canonical page: https://bidda.com/attest
Last updated: 2026-07-11

WHAT THIS PAGE OFFERS

Three attestation tools for compliance teams and AI agents. Creating records
requires an API key (any active subscription, including the free trial).
Verifying a record you were handed is public and needs no account, the same
trust model as a TLS certificate.

1. SIGNED DECISION RECORDS

Mint an Ed25519-signed record of a compliance decision: which node was
consulted, what was decided, when. Anyone holding the record ID or the record
itself can verify the signature independently.

  POST /api/v1/attest          create a signed record (API key required)
  GET  /api/v1/attest/{id}     fetch and re-verify a record (public)
  GET  /api/v1/attest/mine     list your records (API key required)
  GET  /api/v1/attest/keys     the full public keyset (current + retired keys)

Every signature carries a key id (kid, an RFC 7638 JWK thumbprint). Signing
keys rotate on a fixed schedule; the public half of every retired key stays
published forever at /api/v1/attest/keys, so old records never stop verifying.

INDEPENDENT OFFLINE VERIFICATION

The signed-view fields and canonicalisation rules are published at
https://bidda.com/.well-known/bidda-attestation-spec.md and are a frozen
public contract. A browser-based verifier that runs entirely on your machine
lives at https://bidda.com/verify-attestation/. You can reproduce
verification byte-for-byte in any language from the spec alone.

2. POINT-IN-TIME RECORDS

A signed statement of which node version was authoritative at a given moment,
anchored to the public per-node version history.

  POST /api/v1/pit             create a point-in-time record (API key required)
  GET  /api/v1/pit/{id}        fetch and re-verify (public)
  GET  /api/v1/pit/mine        list your records (API key required)

History anchors: /api/v1/history/{node_id}.json and /api/v1/history/index.json

3. RUN LEDGER (SIGNED RECEIPT FOR AN ENTIRE AGENT SESSION)

Open a run at the start of an AI agent session, append one hash-chained entry
per step or turn, then seal the run to receive a signed Run Receipt containing
a Merkle root over every entry. Any tampering with any entry breaks the chain.

  POST /api/v1/runs                open a run (API key required)
  POST /api/v1/runs/{id}/entries   append one entry (owner only)
  POST /api/v1/runs/{id}/seal      seal the run, returns the signed Run Receipt
  GET  /api/v1/runs/{id}           fetch a run (owner always; public once sealed)
  GET  /api/v1/runs/mine           list your runs (API key required)
  GET  /api/v1/runs/{id}/audit-pack  auditor-ready evidence pack for a sealed run

Governed runs: the consult_node MCP tool (and SDK Run.consult) fetches a full
node and records a verified, hash-pinned run entry in one call, so the sealed
receipt proves exactly which version of the rule the agent read.

The Run Receipt is signed with the same rotating Ed25519 keyset as decision
records and verifies against /api/v1/attest/keys. Sealed runs are publicly
fetchable by ID, so an auditor can confirm an agent session without a Bidda
account.

AGENT ACCESS

All three tools are also exposed as MCP tools on the Bidda MCP server
(https://bidda.com/mcp): create_attestation, point_in_time, open_run,
record_run_entry, consult_node, seal_run, get_run, get_audit_pack.

Start a free trial at https://bidda.com/pricing. Questions: info@bidda.com