Pillar 01 — Verifiable Origin

Verifiable Origin.

Pass the origin of the data AI reads as a tamper-proof proof.

Turn the "where it came from" of business documents, API responses, and IoT measurements into a cryptographic proof that travels with the data into AI inputs and business systems. One of the four axes that make up the Lemma trust infrastructure.

Answering the challenges most in demand today

AI inputs of unknown origin can't be used in production

RAG and knowledge bases without tamper detection can't be trusted

Audits and regulators demand proof of origin

01 · What Verifiable Origin is

Pass the origin of data in a form anyone can verify.

Attach the issuer's cryptographic signature and a tamper-proof hash to documents and data, then deliver it. AI and recipients can independently verify the origin without accessing the original.

Issuing system

Original data

Data the issuer can verify, such as business documents, API responses, and IoT measurements.

The original stays with the issuer

Lemma

Hash + issuer signature

1Hash the original

2Issuer signs cryptographically

3Record on the provenance chain

Never touches the original's contents

AI / business system

Data arrives with provenance

sourceHash0x9c4f...

issuerkyc.jp

issuedAt2026-06-05

lineageChain✓

Tampering is detectable

Think of it like a notarized deed.

When you record an important contract or will, a notary creates a notarized deed certifying that "this document was created by this person, on this date" — have you ever gone through this? Lemma's Verifiable Origin works the same way. It cryptographically fixes "who issued the data, and when" so a third party can independently verify it later.

What is disclosed

The provenance facts + proof

✓sourceHash (the data's fingerprint)
✓issuer (the issuer's cryptographic signature)
✓issuedAt (issuance time)
✓Provenance chain (traceability of the chain)

What this makes possible

✓The origin of the data AI reads arrives as a cryptographic proof

✓The original data stays with the issuer and is never shared

✓Tampering is mathematically detectable

✓A third party can independently verify provenance without seeing the original

Chain the trust of data structurally.

→The origin of AI inputs is always in place as a precondition of the work

→Trust across multi-tier supply chains is linked by hashes

→Tamper detection is built into the business workflow

02 · How it differs from existing approaches

How is it different from hashing, digital signatures, and backups?

The individual techniques exist, but Lemma is what brings "origin," "tamper-proof," and "independent verification" together in a single structure.

Approach

Proves origin

Original stays in hand

Independently verifiable

Cryptographic proof

Plain hashing

✗

✓

△

Digital signature only

△

✓

✗

△

Backup / redundancy

✗

✓

✗

Lemma Verifiable Origin

✓

03 · Position in the trust infrastructure

P1 is one of the four axes that make up the Lemma trust infrastructure.

P1 Origin P2 AI P3 Authority P4 Attributes

See the full trust infrastructure →

04 · In production

Business scenarios that use this axis.

P1 · RAG

RAG content provenance

P1 · Component

Supply chain component provenance

P1 · Bridge

DeFi bridge verification

P1 · Contract

Long-term contract record

P1 · Control

Internal control approval proof

P1 · Credential

Credential presentation

See all use cases →

05 · Technical reference

Prove the origin alone, with purpose-built cryptography.

Issuer signature

Cryptographically fixes the data's issuer (a vendor, a government body, an internal team). Who issued it can be independently verified later.

Hash commitment

Keeps the original's contents hidden while publishing only the unique fingerprint. Tampering is mathematically detectable.

Provenance chain

Records multi-tier issuance and handoffs as a chain. Guarantees continuity of origin across multi-tier supply chains and RAG indexes.

// your.provenance.v1 — Lemma canonical schema
{
  "$schema": "your.provenance.v1",
  "sourceHash": "0x9c4f...e7d2",
  "issuer": "kyc-provider.jp",
  "issuedAt": "2026-06-05T10:00Z",
  "lineageChain": [
    { "node": "supplier-a", "hash": "0x71..." },
    { "node": "manufacturer-b", "hash": "0x9c..." }
  ],
  "attestation": "0xa8...4f3e"
}

Developer guides for implementing P1