Repository Receipt di C2PA 2.4: Mengapa Riwayat Ingestion Mulai Dicatat

Ada fase dalam content provenance yang jarang dibahas.

Bukan creation.

Bukan editing.

Bukan signing.

Ingestion.

Asset atau manifest masuk ke repository.

Repository menerima.

Menyimpan.

Mendaftarkan.

Lalu bagaimana kita membuktikan bahwa manifest tersebut memang pernah berada di repository tertentu pada waktu atau workflow tertentu?

C2PA 2.4 menambahkan primitive baru untuk kebutuhan ini:

Repository Receipt Assertion.

Label-nya:

`c2pa.repository-receipt`.

Tujuannya bukan membuat repository menjadi “sumber kebenaran”.

Tujuannya memberi bukti bahwa sebuah C2PA Manifest Store telah di-ingest oleh C2PA Manifest Repository tertentu, lengkap dengan repository-specific proof.

Ini mungkin terdengar seperti fitur backend yang hanya menarik untuk developer.

Sebenarnya implication-nya cukup besar.

Karena begitu provenance mulai menjadi infrastructure, bukan sekadar metadata file, kita membutuhkan evidence tentang lifecycle manifest di luar asset.

Repository Menjadi Bagian dari Provenance Infrastructure

Durable Content Credentials dapat mengandalkan manifest repository.

Asset mungkin kehilangan embedded manifest.

Soft binding seperti watermark atau fingerprint dapat membantu menemukan manifest di repository.

Kalau repository punya peran sebesar itu, pertanyaan trust muncul:

Apakah manifest ini benar-benar terdaftar?

Kapan?

Di repository mana?

Apa identifier canonical-nya?

Bagaimana pihak lain memverifikasi bahwa ingestion terjadi?

Repository Receipt mulai menjawab problem tersebut.

Assertion ini dapat digunakan untuk:

non-repudiation of ingestion,
menetapkan bahwa manifest pernah hadir di repository,
atau mendukung service eksternal yang memberi attestation registration.

Ini bukan glamorous.

Tetapi infrastructure trust sering dibangun dari detail seperti ini.

Receipt Hanya Boleh Berada di Update Manifest

Ini detail penting.

Repository receipt assertion hanya boleh muncul di update manifest.

Kenapa?

Karena receipt terjadi setelah manifest di-ingest.

Kita tidak ingin mengedit editorial content asset hanya untuk menambahkan evidence bahwa repository sudah menerima manifest.

Update manifest dirancang untuk menambahkan assertion tertentu tanpa editorial modification asset.

Jadi chain-nya kira-kira:

asset punya manifest.

repository ingest.

repository mengeluarkan receipt/proof.

update manifest menambahkan repository receipt.

Sekarang provenance chain mendapat state baru tanpa menyatakan asset content berubah.

Ini elegant.

Riwayat infrastructure bisa bertambah tanpa mengacaukan riwayat editorial.

Strukturnya JSON-LD

Repository receipt body memakai JSON-LD.

Ada beberapa bagian wajib.

`repository`

mengidentifikasi repository yang meng-ingest manifest.

Di dalamnya ada:

`uri`

base URI repository.

dan:

`manifestId`

identifier manifest yang canonical untuk repository tersebut.

Lalu ada:

`anchor`

yang menjelaskan proof repository-specific dan tempat verification atau retrieval.

Anchor punya:

`uri`

tempat proof dapat diperiksa.

`proof`

object JSON yang didefinisikan repository.

Ada optional:

`parameters`

untuk key/value tambahan saat mengakses anchor.

Format proof sengaja repository-specific.

Standard memberi envelope.

Repository menentukan mekanisme proof.

Kenapa Proof Tidak Distandardisasi Satu Bentuk?

Karena repository infrastructure bisa berbeda.

Satu repository mungkin memakai signature.

Satu memakai transparency log.

Satu memakai database attestation.

Satu memakai blockchain anchor.

Satu memakai service khusus.

Kalau C2PA memaksa satu proof scheme, innovation dan adoption lebih sulit.

Dengan repository-specific proof, ecosystem bisa berkembang.

Trade-off-nya:

consumer harus memahami mekanisme proof.

Jadi interoperability tidak otomatis sempurna.

Repository receipt mengatakan:

“Ini tempat proof dan object proof-nya.”

Consumer masih perlu validator atau logic yang memahami scheme.

Ini pattern umum open standard.

Common envelope, extensible mechanism.

Apa Bedanya dengan Timestamp?

Receipt bisa membantu membuktikan manifest present di repository pada particular time sebagai use case.

Tetapi jangan menyamakan dengan trusted timestamp authority universal.

Proof semantics ditentukan repository.

Kalau legal requirement membutuhkan trusted timestamp dengan standard tertentu, gunakan mechanism yang sesuai.

Repository receipt adalah evidence of ingestion.

Time bisa menjadi bagian dari proof/service.

Tetapi legal timestamp assurance adalah layer lain.

Ini distinction seperti provenance vs truth.

Jangan meminta satu assertion melakukan pekerjaan yang bukan scope-nya.

Kenapa Ingestion Perlu Non-Repudiation?

Bayangkan dispute.

Publisher berkata:

“Kami sudah mendaftarkan manifest ini ke repository pada hari publikasi.”

Repository berkata:

“Tidak pernah.”

Tanpa receipt, sulit.

Dengan repository-specific proof, publisher dapat menunjukkan evidence bahwa ingestion terjadi.

Atau sebaliknya.

Repository punya receipt yang mengikat manifest identifier.

Ini berguna untuk:

archive,
compliance,
evidence preservation,
distribution,
AI-generated content transparency,
rights workflow.

Manifest existence tidak hanya bergantung pada file asset.

Ada record eksternal.

Ini semakin penting untuk durable provenance.

Repository Receipt dan Soft Binding

Soft binding punya problem discovery.

Watermark atau fingerprint mengarahkan consumer ke manifest repository.

Repository receipt menambah evidence bahwa manifest memang di-ingest.

Kombinasi ini menarik.

Asset kehilangan embedded manifest.

Consumer mendeteksi watermark.

Query repository.

Manifest ditemukan.

Repository receipt memberi additional lifecycle evidence.

Again, tidak otomatis membuktikan content true.

Tetapi provenance chain lebih robust.

Internet adalah tempat metadata sering hilang.

Repository infrastructure memberi fallback.

Receipt membantu membuat fallback itu lebih auditable.

Receipt juga membuka peluang reconciliation otomatis.

Repository dapat memiliki daftar manifest yang sudah di-ingest. Publisher memiliki daftar manifest yang seharusnya terdaftar. Sistem membandingkan keduanya.

Kalau asset sudah publish tetapi receipt belum ada, workflow bisa memberi alert.

Kalau repository mengembalikan manifestId yang tidak cocok dengan record internal, investigation dimulai.

Kalau proof URI tidak lagi dapat diverifikasi, asset masuk maintenance queue.

Ini mengubah provenance dari proses sekali jalan menjadi operasi yang bisa dimonitor.

Pada skala kecil, spreadsheet mungkin cukup. Pada skala besar, machine-readable receipt membuat kontrol seperti ini jauh lebih realistis karena status tidak bergantung pada operator mengingat apakah upload kemarin benar-benar sukses.

Apa Artinya untuk Publisher?

Publisher besar mungkin memiliki manifest repository sendiri atau menggunakan service pihak ketiga.

Mereka ingin memastikan:

manifest high-value asset tidak hanya embed,
tetapi juga registered.

Repository receipt bisa menjadi acceptance proof.

Workflow:

publish asset,
upload manifest,
receive proof,
add update manifest,
archive receipt.

Sekarang asset management system bisa track state:

signed,
repository ingested,
receipt recorded,
distribution active.

Ini mirip supply chain.

Content punya logistics.

Provenance punya logistics juga.

Repository ID Harus Stabil

`manifestId` canonical pada repository.

Ini penting.

Jika repository mengganti identifier sembarangan, receipt history sulit.

URI juga perlu stable.

Publisher yang membangun repository harus berpikir jangka panjang:

domain ownership,
path policy,
redirect,
retention,
migration.

Provenance bisa dibutuhkan bertahun-tahun.

Infrastructure tidak boleh bergantung pada temporary URL.

Ini operational burden yang nyata.

Standar bukan hanya schema.

Standar menuntut lifecycle discipline.

Apa yang Terjadi kalau Repository Mati?

Receipt mungkin tetap ada.

Tetapi anchor URI tidak bisa diakses.

Proof mungkin tidak bisa diverifikasi melalui service.

Ini reason redundancy dan retention penting.

Repository architecture bisa mempertimbangkan:

backup,
mirror,
export,
portable proof,
transparency log.

C2PA tidak magically menjamin endpoint selalu hidup.

Operational reliability tetap responsibility implementer.

Provenance infrastructure hanya sekuat availability supporting services.

Ini lesson untuk organisasi yang terlalu cepat bergantung pada SaaS vendor.

Tanyakan exit plan.

Apakah manifest dan receipt dapat diekspor?

Privacy dan Repository

Repository bisa menyimpan provenance yang sensitif.

Creator identity.
Workflow.
AI model.
Internal asset detail.

Jangan otomatis membuat semuanya public.

Repository design harus mempertimbangkan:

public vs private,
authentication,
access control,
data minimization,
retention.

Receipt hanya membutuhkan repository information dan proof structure tertentu.

Tidak berarti seluruh manifest harus public jika use case tidak membutuhkan.

C2PA core punya privacy principles.

Infrastructure harus mengikutinya.

Repository Receipt untuk Evidence Ledger

Ini use case menarik untuk GEO.or.id.

Bayangkan GEO.or.id membuat public AI visibility evidence asset.

Screenshot.
Report.
Manifest.

Manifest disimpan di repository.

Receipt mencatat ingestion.

Sekarang evidence package punya:

raw asset,
provenance,
repository registration proof.

Ini menambah chain of custody.

Apakah perlu untuk semua article?

Tidak.

Untuk high-value evidence, bisa.

Misalnya:

public AI visibility observation,
research report,
official benchmark asset.

Repository receipt membuat timestamp-ish registration history lebih tangible, tergantung proof system.

Tetapi methodology tetap dibutuhkan.

Receipt tidak membuktikan observation benar.

Ia membuktikan repository ingestion dalam scope proof.

Machine Workflow Bisa Memakai Receipt sebagai State

Asset pipeline dapat membuat rule:

Jika credential belum punya repository receipt, jangan distribute ke long-term archive.

Atau:

High-value publication harus punya repository confirmation.

Atau:

Jika ingestion gagal, retry sebelum publish.

Receipt menjadi machine-readable state.

Ini mungkin value terbesar.

Humans tidak perlu melihat JSON-LD.

Backend bisa membaca.

Dashboard menampilkan:

Repository: registered.

Proof: available.

Manifest ID: X.

Sekarang provenance operations punya observability.

Repository Receipt Bukan CDN Delivery Receipt

Jangan salah paham.

Assertion membuktikan Manifest Store di-ingest oleh C2PA Manifest Repository.

Bukan berarti:

asset image sudah tersebar ke semua CDN.

Bukan berarti:

user sudah melihat.

Bukan berarti:

search engine sudah crawl.

Bukan berarti:

AI system sudah membaca.

Ini ingestion pada repository tertentu.

Scope harus dijaga.

Marketing team mungkin tergoda mengubah:

“Manifest registered”

menjadi:

“Provenance verified everywhere.”

Jangan.

Satu receipt satu event.

Kekuatan evidence datang dari precision.

Update Manifest Membuat Provenance Bisa Bertumbuh

Concept yang lebih besar ada di sini.

Digital asset history tidak berhenti saat publish.

Setelah publish bisa ada:

timestamp,
repository receipt,
certificate status,
additional assertion tertentu.

Update manifest memungkinkan provenance mendapat layer baru tanpa menyatakan content diedit.

Ini penting untuk long-lived asset.

Provenance bukan static metadata.

Ia bisa menjadi lifecycle log.

Repository receipt adalah salah satu contoh yang paling infrastructure-oriented.

Kita mulai mencatat bukan hanya:

“asset dibuat bagaimana”

tetapi juga:

“asset provenance dikelola bagaimana setelah dibuat.”

Itu maturity shift.

Mengapa Riwayat Ingestion Mulai Penting?

Karena Content Credentials bergerak dari file feature menuju ecosystem.

Begitu ada:

repository,
soft binding,
validation service,
publisher CMS,
archive,
platform,
AI pipeline,

kita membutuhkan evidence antar node.

Repository receipt memberi primitive untuk satu transition:

manifest diterima repository.

Kecil.

Spesifik.

Tetapi sangat useful.

Standar infrastructure sering tumbuh seperti ini.

Bukan dengan satu fitur besar yang menyelesaikan semuanya.

Dengan primitive yang memungkinkan system lain membangun trust chain lebih lengkap.

Untuk organisasi yang baru mengenal C2PA, repository receipt mungkin belum prioritas.

Mulai dari signing dan validation.

Untuk organisasi yang sudah mengelola provenance pada skala besar, receipt mulai masuk akal.

Karena pada skala itu pertanyaan berubah.

Bukan lagi:

“Apakah file punya credential?”

Tetapi:

“Apakah credential tersimpan, terdaftar, dapat ditemukan kembali, dan punya proof lifecycle yang bisa diaudit?”

C2PA 2.4 mulai memberi jawaban untuk pertanyaan level infrastructure tersebut.