HOW · Architecture

From SDK call to auditor's inbox.One signed chain all the way through.

This page exists so a regulated buyer — or their auditor, or their counsel — can read the full Plumbline pipeline on one scroll. SDK on the buyer side, signed evaluation runs in our ledger substrate, drift signals on the same chain, and a signed export at the end. Five stages, one chain, no side tables.

Pipeline · one diagram

Five stages. Look here first, read the narrative below.

The diagram is the scannable summary for non-technical reviewers. The four sections below it fill in the “why” for each stage — the SDK placement, the versioned hash, the chain the drift ledger rides, and the signed bundle the auditor receives.

Pipeline · five stages

From SDK call to signed export.

Plumbline pipeline — SDK to signed exportFive nodes in sequence: the Plumbline SDK captures model and agent calls; signed evaluation runs join the Evidence ledger; drift signals join the Drift ledger; both ledgers feed the same signed export handed to auditors and counsel.Plumbline SDKSDK · Inline capturePlumbline SDK — sits inline with model and agent calls on the buyer sideSigned runsSHA-256 · ChainedSigned evaluation runs — versioned records linked by hashEvidence ledgerRecords · tamper-evidentEvidence ledger — chained records for every model decisionDrift ledgerSignals · alerts · provenanceDrift ledger — incidents and alerts detached to the same chainSigned exportAudit log · model cardSigned export — PDF audit log, model card, webhook event stream

The SDK runs on the buyer side, the chain runs in our ledger substrate, and the export lands in your auditor's inbox — three trust boundaries, one signed chain all the way through.

Walkthrough · four sections

What each stage does — and why.

Each section is two paragraphs: the first names the role, the second names the boundary it protects. Read them in order, or jump straight to the section your auditor is asking about.

§1 · SDK sits inline with model + agent calls

Capture happens where the decision happens.The SDK is the only thing that crosses the buyer boundary.

The Plumbline SDK wraps the buyer-side inference and agent call sites. It does not proxy traffic, host models, or sit between the buyer's prompt and the buyer's endpoint — it observes. Each call captures the input, the output, the active model version, the scorer version, and the latency, then writes that record to the chain on a background goroutine so the buyer's request path stays unblocked.

Because the SDK fires right next to the call site, the record is anchored to the moment the decision was made. A later model swap, a prompt edit, or a scorer upgrade cannot retroactively rewrite what happened three weeks ago — the captured record was already in the chain.

§2 · Versioned eval runs land as signed records

Every record is pinned to a model + scorer version.Then signed onto a SHA-256 chain.

A record is only meaningful if the version of the model and the version of the scorer it was judged against travel with it. The signature inputs include the model_id, model_version, scorer_id, scorer_version, input_hash, output_hash, and score — so the record is self-describing and the chain is reproducible months later, even after the model has moved on.

The hash of record n is sha256(record_n || prev_hash_n-1). The chain tip advances by exactly one record per write, and the tip is what the next record signs against. There is no off-chain side table that has to be reconciled with the audit ledger on demand.

§3 · Drift signals detach to a tamper-evident ledger

Alerts ride the same chain as the records they explain.Incidents, resolutions, and provenance all in one.

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 that joins the same chain — not a row in a side table that has to be reconciled with the records it explains. A reviewer resolution is also a record, so the chain shows the full cause → detect → resolve sequence end to end, not just the snapshot.

Because alerts ride the same chain, a six-point accuracy drop walks back to the specific records the SDK already wrote — input, output, score, reviewer, resolution — without a forensic exercise. Provenance is a query against the ledger, not a re-derivation against a backup.

§4 · Signed exports for auditors and counsel

Hand the auditor one signed bundle.PDF audit log, model card, webhook event stream.

When an auditor or counsel asks for evidence, they get a date-range PDF audit log with a signed-hash footer they can re-derive, a printable model card describing intended use, evidence, signers, and drift history, and a webhook event stream showing exactly when each signer signed and each alert resolved. Each export embeds the chain root it was generated against.

Any third party can re-derive the chain from a signed receipt at the public /verify page and confirm the chain tail matches the platform's current tip. Verification is a pure computation over bytes anyone can fetch — no trusted oracle, no insider access, no phone-home. The ledger stays intact while the verifier confirms it from the outside.