Technical

Architecture

A protocol with many fields risks looking like bureaucratic classification rather than useful infrastructure. The test is not how many categories exist; it is whether each one answers a question a real user needs answered. This page separates what PRA requires now from what is optional, and states plainly where a future ledger fits and where it does not.

Minimum viable record

A conforming PRA record requires only these core fields. Everything else is an extension module, adopted where useful, not a universal precondition:

• PRA-ID
• Work and edition
• Covered components
• Excluded components
• Territory
• Mark or basis (PRA-A, PRA-B, PD-V, or a stated combination)
• Evidence source
• Review status
• Authority status
• Current record state
• Responsible recording node
• Resolver URL
• Challenge route
• Status history

Optional modules, adopted only where a node or a national implementation actually needs them: payment routing and royalty administration; WIPO ST.96 mapping; ledger or blockchain anchoring; automated availability checking; machine-readable licence negotiation; cross-node conflict resolution; and privacy-preserving identity credentials. A node that implements only the core fields is still PRA-conformant.

Why each field earns its place

Each core field answers a specific question someone actually needs answered. A field that doesn't survive this test doesn't belong in the core record.

A four-layer architecture

The protocol is deliberately layered so that no single technology choice, including a ledger, becomes load-bearing for the whole system. Only Layers 1 to 3 are required for a conforming implementation.

Verifiable credentials before blockchain

PRA's record model is designed to fit the W3C Verifiable Credentials pattern before it fits any blockchain: an issuer (a rights holder, institution, or authority) signs a credential naming the subject work or edition, covered components, territories, legal basis, evidence references, review status, expiry, current state, and revocation status. A holder (the publisher or reprint house) presents it. A verifier (a library, bookseller, printer, regulator, or reader) checks it. A resolver or registry, and optionally a ledger for integrity and event history, sit alongside this rather than replacing it.

This is why the bright-line rule on every other page of this site (a PRA mark is information, not certification) holds regardless of which storage or integrity technology a node chooses.

If a node adopts a ledger

• Use a permissioned or consortium model, open to libraries, publishers, universities, national offices, rights organisations, standards bodies, and approved independent nodes, rather than an unrestricted public chain. The ledger should preserve signed claims from multiple independent actors; it must not become a new exclusive authority that decides rights questions by majority vote.
• Keep personal addresses, contact details, unredacted agreements, payment and bank details, private search correspondence, sensitive rights-holder information, and full copyrighted documents off-chain. Only a hash, identifier, issuer signature, timestamp, status event, public document pointer, or access policy belongs on a public ledger.
• Ledgers handle deletion and correction poorly. PRA's existing append-only status-event model does the actual work of correction; a ledger, where used, only anchors that history. "Immutable" should never be represented as meaning "permanently true."
• PRA should not be tokenised. It must not become a non-fungible token, a tradeable licence token, a speculative asset, or a token that purports to represent or transfer copyright ownership. The mark remains a rights-information and provenance credential; a transfer of rights occurs only through the underlying deed, licence, contract, statute, or authority, never through the transfer of a ledger token.

Recommended sequence

Stabilise the vocabulary and this record model. Publish the minimum-record schema. Build an ordinary web resolver. Test it with real books and real users. Add signed records and verifiable credentials where a node needs them. Anchor hashes and events to a ledger only where a demonstrated trust problem calls for it. Consider a consortium chain only once multiple institutions need shared governance.

Human-readable mark, then interoperable record, then signed credential, then optional distributed event history, in that order. This gives the protocol a path beyond any one website or company without making a ledger a precondition for using it today.

A relevant caution: the Automated Content Access Protocol (ACAP), proposed in 2006 by a consortium of publishing bodies, was a well-specified, industry-backed, machine-readable rights protocol that never achieved adoption, because the platforms it needed to reach (principally the major search engines) had no reason to honour it and declined to. A voluntary protocol only works once the parties who need to check it, here libraries, printers, and booksellers, have a concrete reason to. That is why the pilot design tests procurement interest and publisher willingness to create records directly, rather than assuming a well-designed schema will be adopted on its merits.

What would make this essential, not just interesting

The classification on this site is justified only to the extent a pilot shows it changes real decisions. Outcomes worth measuring: whether a librarian, publisher, printer, or reader can interpret a record faster and with fewer errors; whether a search file gets reused instead of repeated; whether components are correctly identified; how many challenges occur and how fast they resolve; how many records go stale or turn out wrong; whether trust in a documented edition actually goes up; whether libraries would put the record into procurement requirements; and whether publishers would bear the cost of creating one. Where a field doesn't move one of these outcomes, it should be cut, not kept for completeness.

See the framework paper's Part V for the full technical text, and the canonical evidence fields this architecture is built on.