Platform
How Ledgible works — the detail.
For the CTOs, compliance leads, and technical evaluators who want to go deeper.
Architecture
Platform overview
Ledgible is a three-layer stack. SDKs embed a verified record at the moment of creation. The Ingestion API writes digitally signed content credentials to a permanent record. The Verification API exposes those records publicly — no account required.
Digital Fingerprint
Every asset receives a unique digital ID at the moment of creation — a tamper-evident identity that persists through every format conversion, platform upload, and downstream use.
Origin Record
The verified record captures who created the asset, which tool produced it, and exactly when — a permanent origin document that no retroactive claim can replicate or override.
Permanent Record
A permanent, tamper-proof store holds the complete transformation history of every asset — from raw generation through every post-processing step to final publication.
Layer 1
Verified-at-Creation SDKs
Lightweight plugins for authoring tools — Figma, Premiere, Python pipelines, CI/CD steps — that attach authenticity metadata before the asset leaves its creation environment.
Layer 2
Ingestion & Signing API
A REST API that receives asset metadata, creates a unique digital ID, signs the record with your HSM-backed organization key, and writes a permanent content credential.
Layer 3
Verification & Query API
A public endpoint for verifying any signed asset by its digital fingerprint. No authentication required. Returns the full authenticity record including signer, tool, and timestamp.
Verified at creation
Retroactive labeling is insufficient for legal or compliance purposes. Verification must be captured at the moment of creation — before the asset leaves the generation environment.
Verifiable by anyone
Proof should be inspectable by any party — regulators, auditors, publishing partners — without access to your systems or a Ledgible account. Verification is a public primitive.
Permanent records
Records are written once and never mutated. No corrections, no deletions, no retroactive edits. The integrity of the record is the product — and it is never compromised for convenience.
Data flow
How We Compare
Ledgible vs. existing solutions
| Ledgible | Adobe Content Credentials | Hash Registries | Cloud Detection APIs | Build Yourself | |
|---|---|---|---|---|---|
| Works with any AI tool | ✓ | ✗ Adobe only | ✓ | ✗ | ✓ |
| Text, image, audio, video | ✓ | ✗ Image/video only | Partial | Partial | ✓ with build |
| Signs at generation time | ✓ | ✓ in-tool only | ✗ | ✗ | ✓ with build |
| Verified digital signature | ✓ | ✓ | ✗ | ✗ | ✓ with build |
| Public verify endpoint | ✓ | ✓ | ✗ | ✗ | ✓ with build |
| Unified enterprise audit trail | ✓ | ✗ | ✗ | ✗ | ✓ with build |
| Legal-grade compliance export | ✓ | ✗ | ✗ | ✗ | ✓ with build |
| EU AI Act Article 50 coverage | ✓ | Partial | ✗ | ✗ | ✓ with build |
| Custom pipeline support | ✓ | ✗ | ✓ | ✗ | ✓ |
| Time to integrate | < 1 day | Weeks | Days | Days | 6–12 months |
Under the Hood
Standard methods. No proprietary lock-in.
Unique digital fingerprinting
Every asset receives a unique digital fingerprint before it is stored. The fingerprint is tied to the file's exact content — any change, even a single pixel, produces a different result, making tampering immediately detectable.
Identity-bound signatures
Each record is signed with your organization's unique key — binding the fingerprint to a verified identity and proving the record was created by an authorized party.
Permanent record
Records are written once and never mutated. The ledger is a linear, auditable content history of every asset your organization has signed — queryable at enterprise scale.
Regulatory Tailwinds
The compliance clock is already running.
EU AI Act Article 50 mandates verified content records for AI-generated content — active from August 2025. FTC guidance, California AB 3211, and equivalent frameworks in the UK, Canada, and Australia are following the same pattern. Organizations that build authenticity infrastructure now are compliant across jurisdictions. Those that wait will re-engineer under pressure.
Write Side
Ingestion API
The Ingestion API is the authoritative write path for the Ledgible content authenticity record. Every call produces a permanent, digitally signed content credential tied to your organization's HSM-backed key.
Atomic signing
Each ingestion request is fingerprinted, signed, and committed in a single atomic operation. Partial writes are impossible.
Multi-modal
Supports text, image, audio, video, and arbitrary binary assets. Asset type is stored as part of the authenticity record.
Parent linking
Derivative assets carry a parent_hash field that links them to the original record — enabling full lineage graphs.
Permanent, tamper-proof guarantees
Records are never updated or deleted. The content history is linear and verifiable. Corrections are certified as new entries.
Request
POST /api/v1/assets/ingest
X-API-Key: ldg_your_key
{
"asset_id": "img-campaign-042",
"asset_type": "image",
"title": "Spring campaign hero",
"creator_id": "usr_8a2f",
"tool_id": "midjourney-v6",
"parent_hash": null,
"metadata": {
"campaign": "spring-2026",
"approved_by": "legal-team"
}
}Response
{
"success": true,
"record": {
"id": "rec_9kxp1m",
"asset_id": "img-campaign-042",
"canonical_hash": "sha256:3d4f9a...",
"signature": "hmac:9a1c7f...",
"signed_at": "2026-04-02T09:14:00Z",
"signer": "acme-corp"
}
}Read Side
Verification API
The Verification API is a fully public endpoint. No authentication, no account, no rate limit. Anyone — regulators, journalists, consumers, trading partners — can verify any signed asset by its digital fingerprint.
Public primitive
Verification is intentionally unauthenticated. The integrity of the proof depends on it being inspectable by any party, not just paying customers. This is a design principle, not a limitation.
Request
GET /api/v1/verify?hash=sha256:3d4f9a... # No API key required # Returns full authenticity record
Verified response
{
"verified": true,
"asset_id": "img-campaign-042",
"signer": "acme-corp",
"tool_id": "midjourney-v6",
"creator_id": "usr_8a2f",
"signed_at": "2026-04-02T09:14:00Z",
"c2pa": true,
"record_id": "rec_9kxp1m"
}Not found
{
"verified": false,
"message": "Asset not found in record"
}Hardware Security
FIPS 140-2 Level 3
Every signing key is generated inside and never leaves a FIPS 140-2 Level 3 certified hardware security module. The HSM is the only entity that can produce a valid Ledgible signature.
Key Generation
Organization keys are generated inside the HSM at onboarding. The private key material is never exported, never stored in software, and never touches application memory.
Key Rotation
Keys can be rotated on a policy-defined schedule or on demand. Rotation generates a new key pair inside the HSM. All prior records remain verifiable under their original key.
Key Revocation
Compromised keys can be revoked instantly. Revocation is recorded on the public transparency log. Verifiers can check revocation status before trusting a record.
Tamper Evidence
FIPS 140-2 Level 3 requires physical tamper-evidence and response mechanisms. Attempts to probe or extract key material result in automatic key destruction.
Audit Logging
Every HSM operation — signing, rotation, revocation — is logged with a hardware-attested timestamp. Logs are permanent and available to enterprise compliance teams.
Multi-region Redundancy
HSM clusters are deployed across multiple availability zones. No single hardware failure affects signing availability. SLA of 99.99% applies to all signing operations.
FIPS 140-2 Level 3
Certification
HMAC-SHA256
Algorithm
HSM only — never exported
Key storage
Open Standard
C2PA Compliance
The Coalition for Content Provenance and Authenticity (C2PA) is the open technical standard for attaching tamper-evident authenticity metadata to digital content. Ledgible fully implements the C2PA specification.
C2PA-compliant records produced by Ledgible are readable by any other C2PA-compliant tool — including Adobe Content Credentials, browser extensions, and content verification services. No vendor lock-in.
Manifest Store
Ledgible generates a C2PA Manifest Store for each signed asset. The manifest contains the claim, the assertion set, and the digital signature — all embedded in or linked to the file.
Claim Generator
Each ingestion request produces a C2PA claim identifying the creator, tool, and timestamp. Claims are signed with your organization certificate, issued against a Ledgible CA anchor.
Hard & Soft Binding
Ledgible supports both hard binding (content fingerprint embedded in manifest) and soft binding (external fingerprint reference) — compatible with workflows that cannot modify file containers.
Interoperability
Authenticity records are readable by any C2PA-compliant verifier worldwide. Ledgible does not require customers to use Ledgible-specific tooling to read the proof.
Ready to integrate?
Book a 30-minute demo or talk to us about enterprise deployment.