Plumbline AI documentationone landing, four entry points.
Plumbline AI is the AI governance and evaluation ledger for regulated teams: capture every model decision as a signed, replayable record your auditor — HIPAA, SOC 2, SOX, NIST AI RMF, EU AI Act — can trace. This page is the single starting point for technical evaluators — pick a direction in the tile grid below, or read the three short concepts that explain the shape of the ledger first.
Concepts · what the docs assume
Read these once, then jump to the tile you need.
The rest of the docs link back to these three ideas. Each section is two short paragraphs — enough context to read the SDK, the webhooks page, or the audit-format reference without meeting the ideas for the first time inside them.
§1 · Signed evaluation runs
Every model decision joins the ledgeras a SHA-256-chained signed record.
The hash binds the input, the output, the score, the model version, and the prior record's hash into a single 64-character digest. Records are append-only and link forward to the next — a chain in the literal cryptographic sense, not a database row that happens to have a hash column.
The SDK or a direct POST /api/eval-records posts the record; the response returns the record's id, hash, created_at, and prev_hash. From that point the record is replayable forward from any later point, and auditable backward from any earlier one.
§2 · Drift ledger
Continuous evaluation,a signed record per incident.
Continuous evaluation surfaces drift in score distribution, calibration, and reviewer overrides as it occurs. Each drift incident and each alert is itself a signed record on the same chain — not a row in a side table that has to be reconciled with the audit ledger on demand.
Because alerts ride the same chain, a six-point accuracy drop walks back to the prior records the SDK already wrote — input, output, score, reviewer, resolution — without a forensic exercise. Provenance is a query, not a re-derivation.
§3 · Tamper-evident verification
Detectable editingwithout asking us to trust it.
Each record's hash incorporates the prior record's hash, so any retroactive edit to a past record changes that record's hash, which invalidates the hash of the next record, and every record after it. Tampering is mathematically detectable — the chain breaks at the edit and stays broken all the way forward to the tip.
The public /verify page lets a third party re-derive the chain from a receipt and confirm the chain root matches the platform's current tail. No trusted oracle, no insider access, no phone-home — verification is a pure computation over bytes anyone can fetch.
Entry points · where to start
Four tiles. One job: get you to the right page.
SDK and Webhooks are public and read-only. Audit export is admin-only — sign in first. Model cards are auth-gated per model — pick one in the dashboard and the card URL is the one to share with your auditor.
SDK quickstart
Register a model, install the SDK, fire your first signed record. Paste-runnable curl + Node + Python.
Webhooks catalog
Event types, HMAC-SHA256 verification, retry / backoff policy. Closed enum, no surprises.
Audit export
Date-range PDF of every evaluation run with a signed-hash footer your auditor can re-derive.
Model cards
One-page printable summary per registered model — intended use, evidence, signers, drift history.