MUCC specification
An implementation draft describing identifiers, statuses, records and the separation of verification from commerce.
Draft for ASMRAF review · Version 0.2 · 14 October 2026
Prepared for the South African launch. This document sets out proposed rules; it does not confirm that staff, services or legal arrangements have been put in place.
1. Identifier and scope
Draft version 0.2, dated 14 October 2026. A MUCC identifies one mine registration. The implemented format is MUCC-YYYY-NNNNNN, with a four-digit year and six-digit sequence. Display codes in uppercase and normalise case and surrounding spaces when matching. Existing reserved test identifiers must not be reissued as new registrations. A lot or sale has its own reference linked to the mine code.
2. Allocation and duplicates
Allocate codes on the server in a transaction with uniqueness protection. A retry using the same request identifier and identical payload returns the same result; a changed payload must not silently overwrite the original. A duplicate mine warning needs controlled human review, including possible legitimate differences, rather than granting a second identity automatically.
3. Statuses
Provisional means registered but not verified. Certified records an authorised verification outcome within a defined scope. Suspended means verification cannot currently be relied upon. Withdrawn means the current verification participation has ended. The code remains an historical identifier; changing status does not erase earlier records or prove that a payment occurred. Certificate validity and renewal rules require formal adoption.
4. Private and shared records
The private application holds applicant name, identity number, mine name, address, country, optional contact, consent version and timestamps. The current MinePay mirror is limited to mine identity and status. Identity numbers and contacts must not be added to that mirror. Keep evidence, decision authority and status events under controlled access. Database administrators remain privileged and need separate governance.
5. Decision control and integration
Only specifically authorised ASMRAF verifiers can change status, with an evidence reference, current-record check and audit event. MinePay staff do not inherit that authority. The public label Certified corresponds to the existing registry status value official, which the present MinePay mirror maps to Active; other states remain non-active. This is a limited registry integration, not proof that every custody, messaging or payment service is connected. Consumers must handle stale information and re-check before relying on status.
6. Operational release
Registry allocation and privacy controls have passed isolated tests. Shared test registrations are now stored centrally and recognised by MinePay’s mine lookup, with real payments blocked. The real-registration switch remains off. Before real launch, approve privacy and country rules, resolve verifier access and support recovery, and complete end-to-end device testing. Publishing this draft does not create a standards board, accredited assessor scheme or third-party certification. Record future changes with version, date and migration effects.
Before this document is adopted
Approve the governance authority, operational lifecycle and technical contract. Enforce South Africa as the initial server-side issuance scope before public launch.
Proposed accountable role: ASMRAF standards and technical leads. Named appointments and an adoption date must be recorded before operation.