An exchange needs enforceable agreements about authority and disclosure as well as a shared schema. An organization must know who supplied a fact, who can correct it, who may receive it, and how a dispute is resolved. Federation alone does not answer those questions.
Implemented prototype access
The local API associates a configured API key with one organization. A sender must match the message's issuing organization. Retrieval and listing are restricted to that issuer and the message's named recipients. An unrelated organization receives a not-found response when it requests a message by identifier.
Only a named recipient can record its own receipt. A receipt records acceptance or rejection of a message for that organization. It does not prove that goods arrived, that a regulator approved a shipment, or that a payment settled.
This is organization-level access to the entire message. Field-level disclosure, individual roles, broker delegation, legal-purpose checks, identity verification, key rotation, and a production trust registry are not implemented. The prototype is for synthetic data on a local development machine.
Authority and provenance
The operational network should assign an authoritative source to each type of fact. A carrier may report movement, a warehouse may report receipt, and a competent agency may issue a regulatory decision. One participant's acknowledgement cannot be promoted into another participant's authority.
When reports conflict, preserve their sources and evidence. Agree which source governs the operational view and how a correction is authorized. A timestamp or a valid signature is insufficient by itself to establish that a reported fact is true.
Corrections and disclosure
Corrections should create a new message linked to the earlier record and retain both. The prototype restricts correction links to an earlier message from the same issuer for the same journey and shipment, and requires exactly the original recipient set. See the core profile for the exact implemented rule.
Revoking future retrieval cannot remove copies already received. Production agreements must address onward sharing, corrections sent to prior recipients, lawful retention, and access termination. The prototype has no general access-revocation or data-deletion workflow.
Governance to establish
The proposed national network needs a sponsor and steering mechanism with authority to resolve cross-agency and industry issues. A resourced programme office should coordinate delivery. A network operator needs clear accountability for service, security, membership, costs, incident handling, and exit arrangements.
An international advisory committee can review process analysis, standards, architecture, and results. It cannot supply domestic decision-making authority merely by providing advice. These institutional roles are recommendations; no such mandate is established by the software or these documents.
Conditions before live use
Agree data-sharing purposes and permissions for each participant and record type. Confirm document acceptance, electronic-original requirements, applicable jurisdictions, supported government interfaces, and required testing. A structured message or scanned document does not by itself replace an original or establish transferable title.
Production operation also needs protected transport, secure credentials, auditing that does not expose message contents, retention policy, recovery testing, operational support, and independent security review. These are defined gaps for the roadmap, not implemented capabilities of the local prototype.
Copyright © 2026 Stephen Makonin.