Roadmap · concept stage
The trust layer we want for every piece of UGC you serve.
C2PA-aligned content credentials on every Idukki asset: creator, timestamp, edits, rights, tamper-evident, verifiable across re-encodes. This is the design target. No manifest generation exists yet, and no customer is running it today.
Roadmap
Tamper-evident manifests
Tamper-evident manifests
SHA-256 hash
Survives re-encoding
Perceptual +
Newsroom-grade
Editorial workflow
- C2PA 1.4Spec we’d align to — not implemented
- 0Assets with a manifest today
- 0Newsroom or platform pilots — none exist
- ConceptStage: design, not build
- 01
Tamper-evident manifests
The plan: every asset published from Idukki carries a signed manifest with creator identity, capture device, edit history and rights state. Not built.
- SHA-256 hash anchored to the rights ledger: planned
- Re-signed after every edit: planned
- C2PA-viewer compatibility: planned
- 02
Survives re-encoding
The goal: manifests survive social-platform re-encodes via a hash-chain anchored fingerprint. No fingerprinting pipeline exists yet.
- Perceptual + cryptographic hash dual-anchor: design goal
- Resilience to crop / re-encode / watermark: untested, nothing built
- Confidence scoring: not built
- 03
Newsroom-grade
The ambition is a provenance trail newsrooms can trust. We have no relationship, pilot or conversation with AP, Reuters, BBC or any other newsroom — an earlier version of this page implied otherwise and that was wrong. Corrected here.
- Editorial workflow fit: unvalidated
- Newsroom CMS plugins: do not exist
- No "Verified by Idukki" badge exists
- 04
Verifiable Credentials
Longer-term idea: export the rights state of any asset as a W3C Verifiable Credential. No export pipeline exists.
- VC export: not built
- Decentralised-identity stack compatibility: unresearched
- No blockchain dependency, by design, once built
- 05
Per-platform fingerprints
The idea: when the same clip appears on IG + TikTok + YouTube, a fingerprint links them so one takedown cascades. Not built.
- Cross-platform same-clip detection: not built
- Cascading revocation: not built
- No fingerprinting service exists today
- 06
Built into the runtime
Eventually: the widget runtime checks the manifest before rendering a revoked clip. Today the runtime has no manifest-checking step at all.
- Manifest check at widget mount: not built
- Verification overhead: nothing to measure yet
- Offline-cache mode: not built
- Research
- Building
- Beta
- Live
Tell us if this is what you need next
No pilot exists to apply for today. If content provenance is the thing your legal or trust & safety team needs before working with us, say so — that shapes where this sits on the roadmap.
- No pilot programme to join yet
- Real conversation with the platform team, not a form-fill
- Tell us your use case and we’ll tell you honestly where this sits on the roadmap
We read every message and reply by email. If it fits, we suggest a call.