How verification works

Every public record is keyed by a 24-character HMAC tokenissued by Muranga OS. Tokens carry a purpose tag (lot certificate, healer share, tree, oral history, organisation) and a version. They are not guessable: the HMAC key lives in the tenant's sovereign keystore and signs (subject, version, purpose).

Tokens are revocable. The issuing tenant can take a record off the public surface at any time; the api-core responds 410 Goneand this portal renders the "record not found" page.

Each public payload is bound to an append-only IKS ledger entry of the form
ledger_hash = sha256(prev_ledger_hash ‖ content_hash ‖ payload)

The chain means tampering with any single record breaks every subsequent hash. Auditors can replay the chain offline from the public payloads — no cooperation required from Muranga OS.

Lots additionally publish a Merkle root over their contributor list. You can recompute it from the public contributor table on the lot page and compare.

The portal never receives PII. Contributors are identified by decentralised identifier (DID). Phone numbers, names and exact GPS coordinates stay inside the tenant's isolated database partition (PostgreSQL row-level security). The same applies to oral histories: only the consented transcript and language metadata cross the boundary.

A lot certificate cannot mint until an accredited laboratory records a passing test panel against it. The lab record itself is part of the certificate's payload, which means the "Verified provenance" banner at the top of the lot page is structurally tied to a real test result — not a copy of one.

Healers and contributors view their own royalty accruals at /p/me/[DID], available in English, isiZulu, isiXhosa and Sesotho. Each accrual links back to the underlying lot certificate so the share split is auditable end-to-end.