Leonard — AI provenance & attestation

Positioning

An ingredient brand, by design.

Leonard embeds inside your MLOps, model registry, GRC, or agent platform. We measure success by partners shipping attestation under the hood—not by owning the end-user experience. Collaboration over ego. Optional “attested with Leonard” mark when you want it; never required theater.

In your AI process

Where business teams invoke Leonard.

Familiar moments in applying AI. At each one, Leonard records a durable claim you can verify before the next gate.

Why now: the board and risk teams need a fixed answer to “what data was this model allowed to see?”
Why now: controls only matter if they are bound to the same release as the model—not a slide in a deck.
Why now: deployment must match the approved artifact—weights, hyperparameters, and configuration included.
Why now: bytes alone do not prove the job ran as declared. Attest the computation, not only the files.
Why now: silent change in production is a governance failure. Time-stamped attestations make drift reviewable.
Why now: multi-actor systems need accountable handoffs—tools used, prompts exchanged, outcomes sealed.

Connect

One key. Your pipeline.

Partners authenticate with an API key or OAuth client. Every call is attributed, scoped, and rate-limited. You never integrate raw prover endpoints—only Leonard’s platform verbs.

Authorization: Bearer <leonard_key>

POST /v1/seal_dataset
POST /v1/seal_model
POST /v1/attest_compute
POST /v1/verify

Scopes map to business actions—not infrastructure.

Meter

Pay for the work that matters.

Usage is metered as a product: requests, data processed, and compute class. Sealing artifacts and attesting computation are priced differently so cost tracks risk and effort—not a surprise cloud invoice.

Seal class — datasets, models, policies
Attest class — training runs, evaluations, agent steps
Verify class — cheap checks at deploy gates

Verification

Prove once. Verify without re-running.

For compute claims, Leonard’s platform runs a prover and exposes a verifier. Partners call attest and verify through one platform surface.

1. Claim

You declare what happened: inputs, program or pipeline identity, and outputs that matter to the business.

2. Prove

Leonard produces a cryptographic proof that the claim holds. Heavy work happens here—so you do it once per attested step.

3. Verify

A verifier checks the proof against public inputs. Deploy gates, auditors, and partners confirm integrity without replaying training or inference.

For architects: what the verifier actually does

The verifier does not re-execute your training job. It checks that a proof is well-formed and consistent with the stated claim and public digests (for example, hashes of inputs and outputs, and the identity of the attested procedure). If verification succeeds, the claim is accepted as attested; if anything was altered, verification fails.

Leonard packages this as platform APIs—submit attestation, store the proof artifact, and verify at a gate. Partners integrate Leonard only; proving machinery stays inside the platform.

Interactive

Exercise the platform verbs.

A business-level walkthrough of Leonard’s capabilities. Responses are platform-shaped; compute attestation is shown as the end-game surface partners will call.

Seal dataset

Lock the training cohort so every downstream approval points at the same data.

Business moment: Cohort freeze before training
Why invoke: Tamper-evident provenance of training data

Select a verb and run it.

Built to live inside your AI stack.

Leonard is the provenance and attestation layer—from cohort to compute—for teams applying AI with accountability.

Discuss a pilot

Provenance for every step of AI.