RecordWeb Concept (RWC)

1. Summary

Public administrations have managed information for decades in systems built for filing, not for traceability. The result is well known: incomplete dossiers, lost version histories, system boundaries that fragment information, and an institutional memory that promises more than it delivers.

RecordWeb postulates a paradigm shift. Not a better filing principle, not a smarter dossier structure, but a different foundational decision about what information is: an autonomous, permanently identifiable, versioned, and cryptographically secured object. The Record is the smallest meaningful unit of information. It knows its origin. It proves its state. It exists independently of the systems in which it is stored.

RecordWeb takes up the networking idea of the World Wide Web (not for documents, but for Records) and combines it with the conceptual openness of the Records Continuum, the cryptographic integrity of modern versioning systems, and the institutional accountability of classical Records Management. The result is an architecture in which information no longer migrates through system changes but traverses states. In which completeness is not trusted but proven. In which accountability is not a claim but a structural property.

This concept paper lays out the conceptual foundations of RecordWeb, distinguishes it from related approaches, and describes the path from idea to specification. It is addressed to professionals in Records Management, archival science, and public administration, as well as to anyone interested in the question of how institutional information can exist in a digital world in a way that allows it not merely to be stored but permanently proven. For the normative technical specification, see [RWP].

2. From Berners-Lee to RecordWeb: The Unfinished Revolution

2.1. The World Wide Web as an Information Architecture

When Tim Berners-Lee sketched out his idea for a distributed hypertext system at CERN in 1989 [BERNERS-LEE-1989], he was pursuing a precise goal: information should be linked together, regardless of which system it was stored on. His proposal, "a large hypertext database with typed links", was no technical gimmick but an epistemological thesis: knowledge emerges through connection, not through filing.

The Web that grew from it fulfilled this thesis, but only halfway. It networked documents: Web pages, PDFs, images, videos. The networked unit remained the document, not the information.

2.2. Linked Data: The Second Attempt

Berners-Lee recognised the incompleteness early. With his concept of the Semantic Web and later the Linked Data principles [LINKED-DATA], he tried to go a step further: networking not documents but data. The four principles are well known:

1. Use URIs as names for things.

2. Use HTTP URIs so that names can be resolved.

3. Provide useful information when someone looks up a URI.

4. Link to other URIs to enable discovery.

Linked Data has achieved significant successes: Wikidata, DBpedia, and Google’s Knowledge Graph are children of this idea. But the core problem remained: the networked unit is a data point in a graph, not an autonomous information object with history, provenance, and accountability.

What is missing is the institutional dimension. An RDF triple does not know who created it. It does not know when it was valid. It has no version. It has no responsible party. It is not auditable.

2.3. The Overlooked Question

Berners-Lee’s approaches answer the question how do I connect information?, but not the question what is information that can be connected? This question arises everywhere that information must not merely be transmitted but proven.

Note: [ISO15489] defines a Record as "information created, received, and maintained as evidence and as an asset by an organization or person, in pursuit of legal obligations or in the transaction of business" (Section 3.14). This definition emphasises the evidentiary character (information as an object of proof) and forms the normative foundation for the Record concept in RecordWeb.

This question is not technical. It is ontological: what is the smallest meaningful unit of information; autonomous, identifiable, traceable, and permanent?

The answer RecordWeb postulates is: **the Record**.

2.4. RecordWeb: The Consistent Extension

RecordWeb takes up Berners-Lee’s core idea and radicalises it. Not documents are networked, not data points, but **Records**: autonomous, versioned, schema-based information objects with unambiguous identity, traceable provenance, and explicit accountability.

The Web made documents findable. Linked Data made facts linkable. RecordWeb makes information provable.

2.5. A Paradigm Shift, Not a Replacement

RecordWeb does not replace the World Wide Web and does not compete with Linked Data. It is a complementary architecture that answers a different question: how can information (as an atomic, autonomous unit) exist in such a way that it can be reliably identified, linked, and proven across system boundaries, organisational boundaries, and time boundaries?

This question arises everywhere that information must not merely be transmitted but proven: in healthcare, in finance, and especially in public administration, which owes accountability to the sovereign, to parliaments, and to courts.

3. The Records Continuum and Its Unresolved Tension

3.1. The Australian Revolution

In the second half of the twentieth century, archival science was dominated by linear thinking: Records are created, used, transferred to the archive, and end there. This lifecycle (creation, maintenance, disposal) was intuitive, easy to convey, and closely tied to the physical reality of paper documents.

Frank Upward and his colleagues at Monash University fundamentally challenged this model in the 1990s [UPWARD-1996] [UPWARD-1997]. Their Records Continuum Model replaced the linear sequence with a multidimensional, continuous spatial model. A Record does not pass through phases, it exists simultaneously across multiple dimensions: create, capture, organise, pluralise. The underlying idea is radical: a Record is not an object that travels from A to B. It is an entity that lives in a continuous space of meaning, context, and use.

This idea is conceptually far more advanced than the classical lifecycle. It anticipates what RecordWeb thinks through to its logical conclusion: a Record never ceases to exist. It changes its context, its use, its meaning. But it itself endures.

3.2. The Unresolved Tension: Continuity Versus Provability

The Records Continuum Model has a blind spot that is often underestimated in scholarly discussion. The model’s strength (its openness, its multidimensionality, its rejection of rigid phase boundaries) is simultaneously its weakness in the institutional context.

Public administrations owe accountability. They must be able to prove:

• When was which information available in which version?

• Who had knowledge of which matter at which point in time?

• How was a decision prepared — which information was present, which was not?

The Records Continuum provides no structural answer to these questions. It describes how Records are meaningful, but not how they are provable. This is not a flaw in the model; it was not designed for this purpose. But it is the gap that RecordWeb must close.

3.3. The Classical Lifecycle: Structure Without Flexibility

On the other side stands the classical lifecycle, as anchored in [ISO15489] and other national standards (e.g. Switzerland [ECH-0164]): processing — retention — archiving or disposal.

This framework has great merits. It creates clarity about responsibilities, enables legally compliant retention periods, and structures the transition between operational use and historical preservation. But the model carries a structural cost: it thinks in system boundaries. A Record "lives" in one system and is "moved" to another. Every transition is a migration, a transformation, a potential loss of information.

3.4. RecordWeb as Synthesis

RecordWeb postulates that the tension between continuity and provability cannot be resolved through a better lifecycle model, but through a different approach.

The thesis: a Record does not need a system that carries it through phases. It needs an identity that outlasts it. It needs a version history that documents its change. And it needs cryptographic integrity that proves its state at any point in time.

What is today understood as "archiving" (the physical or digital transfer to a retention system) becomes in RecordWeb a state transition. The Record stays where it is. It receives a new state. Its location can change; its DID remains. Its version is frozen; new versions can emerge without overwriting the old one.

3.5. What RecordWeb Inherits from Both

RecordWeb is not a refutation of the Records Continuum, it is its technical implementation. The idea that a Record does not die but lives on is the core thought of both approaches. What RecordWeb adds is the mechanism: the immutable, cryptographically secured snapshot as the basis for every statement about the state of information at a specific point in time.

From the classical lifecycle, RecordWeb inherits the insight that Records exist in an institutional context, with responsible parties, with retention periods, with governance. This institutional dimension is absent from the Records Continuum just as it is from Linked Data. It is constitutive for RecordWeb.

The result is a model that combines the conceptual openness of the Continuum with the institutional binding force of the classical lifecycle (and places both on a cryptographic foundation that was not yet available in the 1990s).

4. Why SoW, SoR, and SoA Have No Future

4.1. An Honest Appreciation

The distinction between System of Work (SoW), System of Record (SoR), and System of Archive (SoA) is not wrong. It is precise, legally grounded, and reflects a real institutional logic: information is created in the work process, secured in the record repository, and preserved in the archive. RecordWeb does not challenge this approach. It asks one level deeper.

4.2. The Diagnosis: The Problem Is the System Boundary Itself

The lifecycle model does not fail in practice due to poor technology. It fails because of people, but not because people lack discipline. It fails because the model assigns people a task that is structurally incompatible with their work.

Staff in a public authority want two things: to get their work done, and to have access to all relevant information at any time. What they do not want (and what they have consistently refused to do over decades, not out of ill will but out of rational time management) is the manual transfer of information from one system to another.

4.3. The Thesis: System Boundaries Are an Artefact of the Twentieth Century

The tripartite SoW/SoR/SoA structure is historically motivated. Paper could not simultaneously be in circulation and in the archive. Electronic systems were expensive, specialised, and poorly networked. The transition between phases was a physical or organisational necessity.

This necessity no longer exists technically.

RecordWeb does precisely this: there is no longer any transition between SoW and SoR, because every Record from the outset satisfies both requirements: it is editable (in the draft state) and it is archivable (every finalised version is immutable, cryptographically secured, and permanently addressable). There is no longer any transition between SoR and SoA, because the archive is no longer a place, it is a state.

4.4. What Remains — and What Disappears

What disappears:

• The organisational obligation to manually transfer information between systems

• The institutional distinction between "working area" and "record repository" as a system boundary

• Migration as a regular, risk-laden transition in the information lifecycle

• The archive as a separate system with its own staff, its own interfaces, its own logic

What remains:

• The substantive distinction between active and concluded information: mapped as states

• Legal retention periods: mapped as metadata in the Record

• The archive’s responsibility for long-term stability and accessibility: mapped as governance rules

• The human decision about finalisation: as an explicit, documented act

4.5. The Consequence for Staff

For staff, RecordWeb means a radical simplification: they work in a single conceptual space. They create Records, edit them, finalise them. They link Records to Cases. They never again have to decide whether information is "ready for filing". They never again have to switch between systems. They never again have to classify before they are allowed to work.

5. The Record: The Smallest Meaningful Unit of Information

5.1. What a Record Is — and What It Is Not

The term "Record" is established in archival science and Records Management, but it is imprecise. RecordWeb uses the term more precisely: a Record is the smallest semantically autonomous unit of information that can meaningfully exist without additional context.

Note: This definition sharpens the normative Record concept from [ISO15489] (Section 3.14) in two dimensions: first, RecordWeb emphasises semantic autonomy: a Record must be understandable without an external container. Second, RecordWeb adds technical identifiability: a Record must be globally and uniquely addressable without a foreign register.

A single database field is not a Record. An email attachment is not a Record. A folder is not a Record (it is a container).

A Record, by contrast, is: a decision of a public authority; an application submitted by a citizen; minutes of a meeting; an expert opinion; a contract. Each of these objects carries its meaning within itself.

5.2. Conceptual Taxonomy of Records {#section-record-taxonomy}

For the purposes of the RecordWeb conceptual model, Records can be distinguished by their primary purpose:

Record = InformationRecord | RelationRecord | SystemRecord

An InformationRecord primarily carries semantically autonomous institutional or domain information. Examples include an application, a decision, a contract, minutes, an expert opinion, or a captured representation of an object from a source system. InformationRecord is a conceptual category, not a mandatory technical Record type. Concrete InformationRecord types are defined by their respective SchemaRecords.

A RelationRecord primarily establishes, preserves, and makes meaningful relationships between Records. For example a case provides a persisted, governed view of linked Records without becoming a container for them or containing their payload. For example CaseRecord and AssertionRecord.

A SystemRecord primarily defines, documents, or provides evidence of a RecordWeb system rule, operation, or capability. For example, the schemas and protocol evidence through which RecordWeb governs Records belong to this conceptual category. For example: SchemaRecord, MergeRecord, DeletionRecord, MigrationRecord, and ConformanceRecord (see the RecordWeb Protocol).

This taxonomy describes conceptual purposes. It is not a mandatory implementation inheritance hierarchy, a required JSON type hierarchy, or a replacement for concrete Record types and their schemas. The normative protocol definitions and conformance consequences are defined by the RecordWeb Protocol.

5.3. The Three Components of a Record

Every Record in RecordWeb consists of three inseparable components: its identity, its payload, and its metadata.

**Identity** is what makes the Record unambiguous. Globally, permanently, and without a foreign register. Every Record carries a unique identifier that identifies it across system boundaries, organisational boundaries, and time boundaries. This identifier is entirely independent of the Record’s physical storage location.

**The payload** is the actual content, the information that the Record carries. A payload always follows a schema defined for its Record type. The schema is the contract between the Record and the system. A Record can carry multiple payload representations of the same information: a working format in draft state and a long-term format in finalized state.

**Metadata** are the dimensions along which a Record can be found, linked, and classified. They describe the Record from the outside without needing to know its content. The minimum set is deliberately kept small: type, timestamp, responsible parties, state, provenance references, classification, and a free tag field.

5.4. Type and Schema: The Record’s Contract

Every Record has a type. And every type has a schema. A Record’s type is not merely a label, it is a statement about which rules apply to this Record. In RecordWeb, a schema is itself a Record: a SchemaRecord with its own type, its own version graph, and its own history. This guarantees backward compatibility structurally: every version of a Record remains permanently linked to the schema version that was valid at the time of its creation.

5.5. States: The Liveliness of the Record

A Record in RecordWeb is not static. It has a state that describes the condition it is in. The minimum set is:

draft

Being worked on. Content can still change. It MUST NOT be the target of a hard link.

finalized

Complete. Content is immutable and cryptographically secured. A Record MAY be the target of a hard link only when it is in this state.

Additional states do not make a Record eligible as the target of a hard link. Only the finalized state has that effect. Working references may point to Records in any state.

Record types MAY define additional states. A contract may have the state signed. An expert opinion may have the state under review. These extensions must be defined in the SchemaRecord.

What does not exist is a state archived as a system transition. In RecordWeb, there is no "moving into the archive". There are finalised versions that can no longer be changed. That is archiving, without migration, without a system boundary.

5.6. Lifecycle

RecordWeb does not prescribe a mandatory lifecycle for Records. A Record remains a Record regardless of the system in which its content is physically stored, processed, preserved, or made available. Its identity, provenance, and evidential context are maintained through its persistent identifier and DID Document rather than through membership in a particular repository or lifecycle phase.

Nevertheless, organisations may apply an established records lifecycle where this supports their operational, governance, archival, or legal requirements. In particular, a progression from a System of Work (SoW) to a System of Record (SoR) and subsequently to a System of Archive (SoA) remains possible within the RecordWeb approach.

The transition between lifecycle stages does not require creating a new Record or discarding information about its previous context. Instead, the organisation transfers the Records digital representation to the appropriate target system and updates the Records DID Document accordingly.

A lifecycle transition therefore consists principally of two coordinated activities:

1. The Record, including the relevant content and associated representations, is physically transferred and made available in the target system.

2. The DID Document is updated to reflect the current location, service endpoint, access method, or other technical information required to retrieve or interact with the Record in its new environment.

The DID Document may retain references to previous locations, services, or lifecycle events where this is required for traceability, auditability, or preservation purposes. This allows an organisation to document that a Record was previously managed in a SoW or SoR while making its authoritative representation available from a SoR or SoA. This is not currently part of RWP; the DID document can be supplemented according the organisations requirements.

Consequently, lifecycle management in RecordWeb is an organisational capability rather than a protocol-imposed state machine. RecordWeb enables organisations to express lifecycle transitions without changing the identity of the Record and without losing its accumulated provenance, relationships, or evidential value. The Record remains continuously identifiable throughout its lifecycle; only its physical custody, technical accessibility, and relevant DID Document entries change.

5.7. Identifying Agents Alongside Records

RecordWeb uses the same identifier scheme, did:rwp, both for Records and for the parties that bear responsibility for them — an owning organisational unit, a controller, someone asserting or attesting a fact, a source adapter capturing data, or a party approving a deletion.

To keep this distinction explicit rather than implicit, RWP defines a separate category, the AgentRecord, aligned with the general notion of an agent from the PROV provenance model [PROVO]: something that bears responsibility for an entity, an activity, or another agent’s actions, without itself being the thing being tracked (see also Record Identity).

This split matters conceptually because it draws a clean line between what RecordWeb manages (traceable institutional information) and what it merely needs to reference (the identity of a responsible party). RecordWeb does not attempt to be an identity or organisation-management system: it defines only enough structure to say "this DID identifies an agent, not a record," leaving how that agent is described, verified, or authenticated to other systems or specifications.

Also relevant to: the local vs. globally resolvable distinction described in Record Identity, which applies identically to Records and AgentRecords. An AgentRecord DID may be globally resolvable or scoped to a local resolution context under the same rules.

5.8. An Example from Administrative Practice

A citizen submits an application for a building permit.

In today’s system: the application arrives by email or as a PDF. It is printed out or filed in a RecordManagement System. Perhaps it is classified, perhaps not. Later someone looks for it and finds three versions on two drives and in one email.

In RecordWeb: the application is captured as a Record of the type building-permit-application. Its schema specifies which fields must be present: parcel number, applicant, description of the construction project, date. The Record immediately receives a unique identity. Once fully captured, it is finalised. From that moment on, it is immutable, but accessible, linkable, and discoverable for all involved.

6. RecordWeb Reference Architecture

6.1. Purpose

RecordWeb provides an architectural and interoperability framework for treating institutional information as persistent, identifiable, contextualised, and verifiable Records across systems, organisations, and time.

RecordWeb is not a replacement for Internet, network, transport, or Web protocols. It is not itself a records-management application, repository, archival system, or certification authority.

The Internet makes communication interoperable. RecordWeb makes institutional information interoperable, continuous, and verifiable.

The RecordWeb Reference Architecture explains how RecordWeb concerns relate to technical infrastructure, information representations, Records, contextual relations, records governance, and institutional use.

It is intended to provide a common explanatory model for records-management professionals, archivists, institutional adopters, architects, developers, and implementers.

6.2. Architecture and stack

The RecordWeb Reference Architecture is represented through the RecordWeb Reference Stack.

The stack has six conceptual layers. The layers identify abstraction boundaries and primary concerns. They do not require that every layer be implemented by a separate system, service, database, organisation, or protocol.

┌──────────────────────────────────────────────────────────────┐
│ 6. Use and Institutional Effect                              │
│    Decisions, accountability, public access, reuse           │
├──────────────────────────────────────────────────────────────┤
│ 5. Governance and Records Continuum                          │
│    Responsibility, access, retention, appraisal, disposal    │
├──────────────────────────────────────────────────────────────┤
│ 4. Context, Relations and Case Views                         │
│    Functions, agents, activities, relations, generated cases │
├──────────────────────────────────────────────────────────────┤
│ 3. Record and Evidence                                       │
│    Identity, state, version, provenance, integrity, proof    │
├──────────────────────────────────────────────────────────────┤
│ 2. Information Package and Representation                    │
│    Content, metadata, schemas, serialisations, files         │
├──────────────────────────────────────────────────────────────┤
│ 1. Carrier and Infrastructure                                │
│    Storage, repositories, Web, resolvers, network, hardware  │
└──────────────────────────────────────────────────────────────┘

The principal RecordWeb boundary is between the Record and Evidence layer and the layers that describe information representations and technical carriers.

Institutional use and effect
────────────────────────────

Governance and records continuum
────────────────────────────

Context, relations and case views
────────────────────────────

Record: identity, state, version and evidence
════════════════════════════════════════════

Information package and representations
────────────────────────────

Carrier, storage, resolver and network infrastructure

This boundary expresses a central RecordWeb principle:

A Record is not identical to a file, database row, URL, repository location, application, or technical carrier.

A Record may have several representations, locations, copies, custodial arrangements, and technical service endpoints over time. Its persistent identity, contextual meaning, state, version history, provenance, and integrity evidence can remain independently verifiable despite those changes.

6.3. Layers

6.3.1. Carrier and Infrastructure

The Carrier and Infrastructure layer contains the technical means through which information is stored, transmitted, replicated, resolved, and preserved.

A carrier may be a file, database object, object-storage object, message, repository resource, export package, storage medium, or network-accessible service representation.

This layer includes service discovery and technical resolution mechanisms. Such mechanisms can identify a current service endpoint or storage location, but they do not by themselves define the identity, status, evidentiary value, or institutional meaning of a Record.

A DID Resolver and a namespace-resolution mechanism are therefore infrastructure functions. They support the resolution of persistent Record identity to current technical information without making the Record identical to a resolver, repository, URL, or endpoint.

6.3.2. Information Package and Representation

The Information Package and Representation layer concerns the content and representations through which a Record can be rendered, interpreted, exchanged, or preserved.

A Record may include, reference, or be represented through structured data, metadata, documents, binary objects, files, serialisations, schemas, and semantic vocabularies.

Several representations may express the same Record at different times or for different uses. For example, a Record may be represented as JSON for exchange, JSON-LD or RDF for linked-data processing, PDF for human rendering, and a preservation package for archival transfer.

A representation is not, solely by being technically complete or cryptographically protected, the Record itself. Its relationship to a Record depends on the applicable identity, version, provenance, integrity, and contextual evidence.

6.3.3. Record and Evidence

The Record and Evidence layer is the principal focus of RWP.

This layer concerns the persistent identity, type, state, version history, provenance, integrity, finalisation, and verifiability of a Record.

RWP specifies mechanisms through which an implementation can create, manage, retrieve, validate, and verify Records. These mechanisms allow a Record to remain identifiable and inspectable when its content representation, storage location, custodian, resolver endpoint, or surrounding application changes.

A Record may be associated with one or more representations and technical carriers. The persistent Record identity is not reduced to any particular representation or carrier.

Record-level evidence may include, as applicable:

• a persistent identifier;

• schema association;

• metadata and contextual references;

• version and derivation relations;

• lifecycle state and finalisation information;

• integrity hashes;

• signatures and attributable agents;

• provenance statements;

• references to validated linked Records; and

• an inspectable conformance or validation assertion.

The Record and Evidence layer does not itself decide whether a Record is useful, admissible, accessible, retained, transferred, appraised, or disposed of in a particular institutional setting. Those decisions require the upper layers of context, governance, and use.

6.3.4. Context, Relations and Case Views

The Context, Relations and Case Views layer places Records in the relationships that make them understandable and accountable.

Relevant context can include functions, activities, transactions, agents, mandates, legal bases, subjects, events, classifications, retention contexts, archival descriptions, and relations to other Records.

PROV-O is relevant to the description of creation, derivation, revision, attribution, and related provenance events. RiC-O and other permitted contextual vocabularies can express archival, institutional, functional, legal, subject-matter, and descriptive context.

An AssertionRecord can preserve an attributable and durable assertion about one concrete relation. It provides a bridge between Record-level evidence and the contextual graph in which Records are interpreted.

A case or dossier is not necessarily a primary, permanent technical container. It can be generated as a meaningful view over a set of Records and their relations for a defined purpose, scope, time, or institutional context.

6.3.5. Governance and Records Continuum

The Governance and Records Continuum layer concerns the institutional responsibilities and rules that apply throughout the life of Records.

It includes, as applicable:

• mandates and legal bases;

• responsibility and authority;

• access conditions and protection requirements;

• retention and disposition rules;

• appraisal and archival selection;

• transfer between custodians or institutions;

• migration and preservation planning;

• compliance, audit, and accountability requirements.

This layer distinguishes the technical lifecycle of a particular carrier, repository, or service from the continuing institutional responsibility for the Record.

A Record can remain subject to governance obligations when it is copied, migrated, transferred, redacted, transformed, preserved, or made accessible through a different technical environment.

6.3.6. Use and Institutional Effect

The Use and Institutional Effect layer concerns the purposes for which Records are created, relied upon, communicated, disclosed, reused, or preserved.

Relevant purposes can include administrative decisions, accountability, legal evidence, service delivery, public access, research, archival use, historical interpretation, and democratic scrutiny.

A Record supports institutional effect not only because information is available, but because its identity, context, authority, state, provenance, and integrity can be understood and evaluated in relation to the relevant institutional setting.

RecordWeb supports this layer by making Record-level evidence interoperable. It does not decide the legal effect, evidentiary weight, or institutional authority of a Record in a specific jurisdiction or procedure.

6.4. Cross-cutting dimensions

The stack should not be interpreted as a strictly one-directional processing sequence. Two dimensions cross all layers: time and continuity, and trust, assurance, and conformance.

6.4.1. Time and continuity

Time and continuity cross the complete RecordWeb Reference Architecture.

Relevant events and processes include:

• creation, capture, and registration;

• revision, derivation, and versioning;

• finalisation and authoritative use;

• copying, replication, and transfer;

• migration and transformation;

• retention, appraisal, and disposal;

• archival preservation and continuing access.

This dimension distinguishes the lifecycle of a technical carrier or representation from the Records continuum of the persistent Record and its institutional context.

A particular file, storage object, URL, resolver endpoint, application, or repository may be replaced. The Record can nevertheless remain identifiable and its history inspectable when continuity is supported by appropriate identity, provenance, integrity, and contextual evidence.

6.4.2. Trust, assurance, and conformance

Trust, assurance, and conformance cross all layers of the architecture.

Relevant mechanisms include:

• identification and attribution of agents;

• authority and responsibility;

• governance and access conditions;

• integrity hashes and signatures;

• provenance and derivation chains;

• schema, profile, and Record validation;

• implementation assessment;

• conformance attestations;

• completeness and scope evidence for cases, exports, transfers, and aggregations.

These mechanisms answer different questions and should not be conflated.

A Record validation result concerns whether a specific Record or snapshot satisfies applicable requirements. An implementation assessment concerns whether an identified implementation version fulfils the requirements of claimed RWP profiles and roles. An attestation is a signed statement by an identifiable attester about such an assessment. Certification is an institutional process that remains outside the RWP base protocol.

A ConformanceRecord is a RecordWeb SystemRecord that can preserve a durable, machine-readable conformance attestation. Its presence does not by itself establish that a claim is true, independently assessed, or certified. A verifier evaluates the identity of the attester, the claimed scope, the assessment method, the evidence, and the applicable trust policy.

6.4.3. Publication of conformance attestations

An organisation may publish a ConformanceRecord, or a verifiable reference to one, through a publication mechanism appropriate to its disclosure, governance, and trust requirements.

Possible publication mechanisms include:

• an organisational website or service endpoint;

• a procurement or audit evidence repository;

• an institutional registry;

• a DID-related service endpoint;

• a signed Nanopublication; or

• direct provision to an auditor, procuring organisation, or other verifier.

A publication mechanism can make an attestation easier to discover, cite, replicate, or inspect. It does not itself establish that the underlying claim is true, authoritative, independently assessed, or certified.

The choice of publication mechanism is outside the RWP conformance requirements. RecordWeb does not require a central conformance registry, a particular distributed ledger, Nanopublications, or any other specific publication infrastructure for ConformanceRecords.

6.5. Position of RWC and RWP

RWC explains the overall conceptual architecture and the relationships between Records, information packages, technical carriers, context, governance, and institutional use.

RWP primarily specifies the Record and Evidence layer. It also defines selected interfaces to adjacent layers, particularly where persistent identity must be resolved through technical infrastructure or where Record context and representations must be referenced and verified.

7. The Version Graph: How Information Changes Without Disappearing

7.1. The Problem with Versions Today

Anyone who today looks for the "current version" of a document in a public authority enters uncertain terrain. In most cases, the history of a document (who changed it, when, and how) cannot be reconstructed. This is not a marginal problem. It is the normal condition. And it has real consequences: decisions are made on the basis of information whose period of validity is unclear.

7.2. The Core Idea: Change as Linkage

In RecordWeb, information is never overwritten. When a Record changes, a new version arises, a new, autonomous snapshot. This snapshot is linked to its predecessor: it knows where it came from. The entirety of all versions of a Record and their linkages forms the version graph.

A graph is the right metaphor because the history of information is rarely a straight line. Sometimes it branches: two staff members work simultaneously on different aspects of the same Record. Sometimes strands come together again: different revisions are merged into one authoritative version.

7.3. Branches: Parallel Work as the Normal Case

A branch arises when from one finalised version, two or more simultaneously existing drafts emerge. Both are visible. Both are in the draft state. Anyone looking at the Record sees immediately that parallel work is underway. Nothing is hidden, nothing is lost.

7.4. Finalisation: The Moment of Binding Force

The heart of the version graph is finalisation. It is the moment in which a draft becomes binding information. Only upon finalisation may a Record become the target of a hard link; it is then usable as the basis for further actions.

Finalisation is not a technical automatism. It is a human decision, documented and attributable. Whoever finalises assumes responsibility for the content. A finalised version is immutable: it cannot be withdrawn, corrected, or overwritten. Corrections arise as new versions, with explicit reference to the version they replace.

This immutability is not a technical limitation. It is a statement about the nature of accountability: whoever declares something to be true and binding at a particular point in time must be able to stand by it.

7.5. Corrections, Replacements, and Validity

When a finalised Record is incorrect, it remains what it was — a finalised, provable version at a particular point in time. A new version arises that corrects or replaces it. What changes is not the past, but the state of knowledge about the past.

This distinction is central. An incorrect version remains visible as a historical fact. The corrected version becomes visible as its successor. This does not weaken trust, it strengthens it. Trust does not arise from the fiction that institutions never make mistakes, but from the ability to prove how they dealt with mistakes.

7.6. Why a DAG Is More Than a Technical Detail

Technically, the version graph is implemented as a Directed Acyclic Graph (DAG). This means: every version has one or more predecessors, but no cycles. A Record can refer back to earlier versions, but it cannot become its own ancestor.

Acyclicity means that history has a direction. One can reinterpret the past, correct it, recontextualise it, but one cannot make it unhappen. The graph therefore expresses, in technical form, an institutional principle: accountability needs chronology.

The version graph is not an optional implementation feature of RecordWeb. It is part of its ontology.

8. The Case: Cases as a View onto the RecordWeb

8.1. Why the Dossier Is Not Enough

In public administration, the dossier has long been the central organisational principle. But it has a weakness that becomes visible in the digital context: the dossier is a container. It holds together what belongs together. But it does not explain why it belongs together, and it does not create any identity of its own for the individual parts.

RecordWeb therefore proposes a different perspective: not the dossier as the primary unit, but the Case as a view onto linked Records.

8.2. What a Case Is

A Case in RecordWeb is not a container into which Records are placed. It is a RelationRecord: a semantic and procedural relationship structure that links Records to one another and makes them visible as belonging together.

A Case answers questions such as:

• Which Records belong to the same matter?

• Which Records were causally relevant to a decision?

• Which Records together constitute the context of a process?

This has a fundamental consequence: a Record can belong to multiple Cases without being duplicated.

8.3. Case as View, Not as Container

In the classical system, the dossier is primary and the document secondary. In RecordWeb, the Record is primary and the Case secondary. The Record exists in its own right. The Case emerges through the explicit linking of Records. Context is not produced by storage, but by relation.

A Case can be polycontextual: it can connect Records across organisational units, across processes, across time periods. It can represent causal links where the dossier can only represent storage location.

8.4. Example: A Building Permit as a Case

A citizen submits an application for a building permit. This application is a Record. Later a site plan is added, then an expert opinion from the heritage authority, then the hearing of neighbours, then the authority’s decision.

In a classical system, all of this would be placed in a dossier. In RecordWeb, all these are autonomous Records linked through a Case: "Building Permit Muller, Parcel 4711".

The Case makes visible that the Records belong together. But none of them loses its autonomy. The heritage expert opinion can later appear in another Case if a legal dispute arises. The authority’s decision can be linked to a political oversight Case. The application remains the same application.

**The context changes. The Record remains.**

8.5. Cases and Governance

Because Cases create context, they are institutionally relevant. They also need governance: who may open a Case? Who may add or remove Records? Under what conditions may a Case be split, merged, or closed?

RecordWeb’s answer is clear: Cases must be defined semantically and governed institutionally, but without reducing them again to containers.

9. Source Integration: From Domain Content to a Record

A Source Application remains responsible for the domain object that it creates, manages, or interprets. A conversation in a collaboration platform, a case in a specialist application, or a document in a business system remains a source object in that application’s domain. RecordWeb does not require such a system to adopt RWP’s identity, versioning, or storage model.

A source-adapter can expose content and provenance from such a source object to an RWP producer. The source-adapter does not thereby need to implement the RWP DID method, snapshot graph, storage model, or Case model. The form of the exchange is a matter for the participating implementations: it may be an API, an event, a file transfer, a queue, or another agreed mechanism. This exchange mechanism is deliberately outside the scope of [RWP] and is not expected to be standardised by a future protocol version without a dedicated specification effort.

The boundary of RWP responsibility is the producer that creates the RWP representation. From that point, the information becomes a Record only when it has received an RWP identity, has been associated with an applicable schema, and has been created and, where applicable, finalised according to the RWP rules. The producer, and not the source application merely providing content, is accountable for the resulting RWP Record.

A source-adapter may itself also act as an RWP producer. In that case, it does not merely provide source content: it creates an RWP Record and is subject to the full RWP requirements for that role. Another RWP implementation may then retrieve, validate, or retain that Record according to the ordinary producer, consumer, and custodian responsibilities.

9.1. Provenance without content

A source-adapter may deliberately provide only source-provenance information, without transferring the underlying source content, when that content is subject to confidentiality or secrecy classification and must not leave the source system. This is not a degraded or incomplete case of Source Integration; it is a deliberate deployment choice with its own trust basis.

In this pattern, trust in the resulting reference does not rest on the producer having received and validated the source payload. It rests instead on independent evidence that the source system itself is properly governed and operated. For example, an implementation assessment of the source-adapter, expressed as an attestation under [RWP]. A relying party evaluates such evidence according to its own trust policy, in the same way it would evaluate any other conformance claim.

This separation preserves implementation freedom while keeping the evidential boundary clear: a source system may remain specialised in its domain, and may keep sensitive content within its own perimeter, while an RWP producer ensures the identity, versioning, integrity, and long-term provability of whatever is actually represented as a Record.

9.2. Illustration (non-normative)

The following flow illustrates the pattern from a proof-of-concept implementation. It is not a prescribed Source Integration protocol.

RWP-compliant system
  │ opens or requests Record context
  ▼
SoX
  │ producer + custodian
  │ creates permanent Record DID
  │ may retain an empty draft while source content is unavailable
  ▼
ChatAdapter
  │ source-adapter
  │ exposes content and source provenance for a thread
  ▼
SoX
  │ applies its own applicable RWP production and finalization process
  │ creates and retains the resulting RWP snapshots
  ▼
RWP-compliant system
  │ resolves the Record DID
  │ verifies a finalized snapshot and snapshotHash
  ▼
CaseRecord hard link

The systems in this illustration share no common database, storage model, or orchestration layer. The architectural insight (a clear responsibility boundary between source-adapter and producer) is independent of the transport used between them.

10. Accountability and Trust: Proving Rather Than Claiming

10.1. The Question Authorities Dread

"Can you prove that this information existed at the time the decision was made?"

No court asks this question lightly. But it is asked in legal remedy proceedings, in parliamentary inquiries, in audits, in criminal investigations. And in most administrations, the honest answer is the same: no, not with certainty.

RecordWeb is built for provability. That is not a side benefit, it is a design principle.

10.2. Three Levels of Traceability

RecordWeb anchors traceability at three levels that together produce a complete picture.

10.2.1. Level 1: The Individual Record

Every finalised version of a Record is cryptographically secured. The content, the schema, the metadata, and the provenance references are condensed into a single hash value. This value is unambiguous: two Records with the same hash value are guaranteed to be identical (bit for bit, without exception). If even a single character in the content changes, the hash value changes. Subsequent manipulation is not only prohibited, it is detectable (see § 10.3 Validating RecordWeb Objects).

10.2.2. Level 2: The Version Graph

The history of a Record is not separately documented, it is structurally anchored. Every version knows its predecessors. Every branch is visible. The question "which information was available at the time of the decision?" is answered by examining the version graph at the relevant point in time (not by questioning those involved, not by searching through email archives).

10.2.3. Level 3: The Case Merkle Root

A finalised Case has a fingerprint: the Merkle root, calculated from the hash values of all linked Records. This value represents the entire state of the Case at a specific point in time: completely, immutably, and machine-verifiably.

The question "was this Case complete at the time of the decision?" is answered by comparing the Merkle root from that time with the one from today. If they are identical, nothing has changed. If they differ, the system knows exactly which Record has changed.

10.3. Validating RecordWeb Objects

RecordWeb enables a Consumer to validate different objects independently. A Consumer may validate a Record, one specific Version of a Record, or the inline content of one Representation.

Validation is repeatable. A Consumer may perform it when receiving an object, before using it in a business process, during a transfer or migration, or at a later time. RecordWeb does not prescribe when an organisation must validate an object or what consequence it must attach to the result.

A successful integrity validation establishes only that the obtained object matches the applicable RecordWeb hash. It does not by itself establish that the content is true, that an organisation or person is authoritative, that an external or physical object is available, or that the object has legal effect.

10.3.1. Example: Separate Validation Objects

A Consumer may receive a Record with several historical Versions and multiple Representations per Version.

If the Consumer needs only one currently presented PDF representation, it may validate the Content object for that representation. This establishes whether the inline content matches its contentHash.

That result does not establish the integrity of the containing Version or the entire Record. If the Consumer also needs to validate the Version or the Record, it performs separate validations of the corresponding Version and Record identifiers.

This avoids treating a validation of one object as an assertion about all historical Versions, all Representations, or the complete Record.

10.3.2. Example: Content and References

A Representation can contain inline content or a reference.

Where inline content is present, RecordWeb can provide a contentHash for verifying that content. Where a Representation contains only a ref, such as an external repository identifier or the statement "Physically held in filing location x.y.z", the reference documents where content may be found. It does not by itself provide a RecordWeb integrity assertion about the referenced digital or physical content.

10.3.3. Retained Validation Results

A Consumer may retain the result of a validation in its own system or in an appropriate Record. A retained result is a statement by that Consumer, at the recorded time, about the identified object and the validation that it performed.

A retained validation result is not a new state of the validated Record and does not prevent another Consumer from validating the same object independently at another time.

10.4. Federation Needs an Anchor Without an Owner

A federated namespace, however, still needs one thing a purely peer-to-peer network cannot provide on its own: a starting point that every participant can agree to trust before they have ever spoken to each other.

This is the role of the operating organisation for the global Global Namespace Registry (GNR). It is not a central authority in the sense the Web was built to avoid. It does not own the namespaces it helps route between, it does not operate every resolver in the federation, and it does not see the Records or DID Documents that lie behind a resolved namespace. Its function is narrower and, for that reason, more durable: it coordinates the infrastructure that keeps the shared namespace directory consistent, available, and trustworthy across organisations that may never fully trust one another individually.

This distinction (coordination without ownership) has precedent outside RecordWeb. The European Commission’s role in EBSI, the European Blockchain Services Infrastructure, is structurally similar: it facilitates a shared ledger operated jointly by member states without holding a private copy of the data itself. The US Federal Public Key Infrastructure Policy Authority plays a comparable part for cross-certified certificate authorities: it sets accreditation criteria without itself issuing end-user certificates. RecordWeb’s operating organisation is proposed in this lineage, not as a novel kind of institution.

Why does this role need to be named explicitly, rather than left to emerge informally? Because the alternative to a named coordinator is not "no coordination", it is unaccountable coordination: whoever happens to run the most infrastructure at a given moment. For a registry that public administrations depend on to resolve identifiers tied to legal records, that default is not acceptable. A named operating organisation, bound to a published governance framework, is what makes the difference between infrastructure that happens to work today and infrastructure that institutions can commit to for decades.

The governance framework itself is deliberately not specified here. Its required minimum content (who may join, how namespaces are registered and retired, how incidents and upgrades are handled, how history remains auditable) is a conformance question for implementers and is defined in the RecordWeb Protocol [RWP]. What matters at the concept level is only the shape of the role: a coordinating body, accountable and named, sitting beside the namespace owners and resolver operators it serves rather than above them.

That is RecordWeb Trust Association.

10.5. The Optional Ledger: Hyperledger as External Anchor

For situations in which an authority needs external proof, RecordWeb offers an optional extension: anchoring the Case Merkle root on a distributed infrastructure (for example Hyperledger Fabric [HYPERLEDGER], a permissioned distributed ledger that operates without a public blockchain).

The principle is simple: when a Case is finalised, its Merkle root (and only this value, no content) is written to the ledger. This creates a timestamped, publicly provable entry: "this Case had this state at this point in time", without privacy or official secrecy being violated.

The Hyperledger anchor is an option, not an obligation.

10.6. The Optional Pod: Solid as Citizen-Controlled Storage

For situations in which a Record or Case belongs not to an authority but to a citizen (as the subject, recipient, or rights-holder) RecordWeb offers a second optional extension: delivery and storage of Records in a Solid Pod [SOLID].

Solid is a W3C-based protocol that enables individuals to store their own data in a personal online data store (a Pod), fully under their own control. Applications and institutions may read from or write to a Pod only with explicit, revocable consent. The citizen is not the recipient of a copy, the citizen is the owner of the original.

The principle for RecordWeb is straightforward: when an authority finalises a Record that concerns a specific citizen, it may (with the citizen’s consent) deliver that Record directly into the citizen’s Pod. The Record retains its DID, its version graph, and its cryptographic integrity. What changes is the storage location: the authority’s system and the citizen’s Pod both hold a reference to the same immutable, permanently addressable object.

Typical use cases for citizen-held Records include:

• A driving licence issued by the road traffic authority

• A medical image (X-ray, MRI) delivered by a hospital

• A residence registration confirmation issued by the municipality

• A building permit delivered to the applicant

• A diploma or professional certification

In each case, the citizen can present the Record to any third party (an employer, an insurer, a foreign authority) who can independently verify its authenticity via the DID and the cryptographic hash, without querying the issuing authority. The authority’s system remains authoritative; the citizen’s Pod holds a provable, portable copy.

Note: The Solid Pod option complements, not replaces, the authority’s own record keeping. The issuing authority retains the Record in its own RecordWeb system. The Pod delivery is an additional output, a citizen-facing endpoint for Records whose primary subject is the individual.

The Solid Pod anchor is an option, not an obligation. It requires the citizen to have a Pod and to have granted the relevant authority write access. The RecordWeb specification provides a delivery-target field in the optional metadata extension block for this purpose.

10.7. Trust Through Transparent Governance and Publication

Trust in public institutions arises not from promises but from provability. An authority that can say: "here is the decision, here is its history, here is the proof that it has not changed", this authority deserves trust. Not because it was well-intentioned, but because it can prove it.

RecordWeb is not an instrument of control against authorities. It is an instrument of credibility for authorities.

RecordWeb does not treat trust as an unconditional technical property of a Record. Trust is supported by transparent governance, accountable actors, and independently inspectable evidence.

A globally registered RecordWeb namespace provides a limited but meaningful trust basis. Its registration identifies a responsible Registrar within the RecordWeb Global Namespace Registry (GNR). The Registrar’s participation, namespace responsibility, and applicable obligations are governed through the RecordWeb Trust Association and its published rules.

This does not establish that every Record in the namespace is factually true, legally effective, or suitable for every purpose. It establishes that the namespace is publicly attributable to an identified and accountable Registrar under a transparent governance arrangement.

RecordWeb supports publication of Records and verification-relevant information wherever this is compatible with confidentiality, privacy, security, and legal obligations. Publicly accessible registry entries, governance rules, attestations, and other verification evidence enable independent inspection and can strengthen trust through transparency and accountability.

Open Government Data principles provide a useful model for this approach: information should be made open by default where appropriate, timely and comprehensive, accessible and usable, and comparable and interoperable. RecordWeb does not require every Record to be public. It supports the publication of the information necessary for independent verification while respecting legitimate access restrictions.

Nanopublications or comparable citable publication mechanisms MAY be used to publish atomic assertions, provenance information, and publication information. They are optional publication mechanisms and are not required by the RWP core.

10.8. Trust Assumptions

Every verification rests on trust assumptions. Integrity validation shows that an obtained object matches its RecordWeb hash. It does not show who controls an identifier, how that identifier was obtained, or under which rules a schema was published. RecordWeb distinguishes four trust assumptions:

1. Resolution: the DID Document was obtained from an authoritative resolution path.

2. Namespace and controller: the owner DID is controlled by the entity it is claimed to represent, and its namespace registration is authoritative. For global namespaces, the GNR and its governance provide the fixed basis of trust defined by RecordWeb.

3. Key custody: the owner’s private keys are adequately protected and were valid at the relevant time.

4. Schema governance: the schema version used was the one in force at the time.

A Consumer decides which of these assumptions it accepts, and which evidence it requires for each.

11. Conformance and Accountable Implementation Claims

In RecordWeb, conformance is understood as an accountable claim made by an identifiable implementation. It is not a general property of an organisation, a product family, a deployment environment, or an individual Record. The normative meaning, prerequisites, scope, and representation of such a claim are defined exclusively by the RecordWeb Protocol ([RWP]).

Conceptually, the relevant trust boundary is the software component that creates, manages, validates, or makes an RWP representation available and that accepts responsibility for the RWP guarantees it claims. Depending on the deployment, this can be a source system, connector, capture service, Case system, Record repository, resolver, or another software component. The precise conformance boundary and the applicable roles are defined by [RWP].

A source system does not, merely because another implementation creates an RWP representation from information obtained from it, thereby become the subject of that implementation’s conformance claim. This holds independently of whether the source system also transfers its underlying content, or provides only provenance information about it while the content itself remains outside RWP’s reach, for instance where the content is confidential and must not leave the source system. The allocation of conformance responsibility is defined by [RWP].

11.1. Validation, Assessment, Attestation, and Certification

The following distinctions explain how conformance claims can be understood; they do not introduce additional protocol requirements.

Record validation concerns a particular Record, snapshot, or other RWP representation: it examines whether that artefact satisfies the applicable RWP requirements.

Implementation assessment concerns an implementation and the scope of its claimed RWP conformance, such as its declared RWP version, profiles, roles, and capabilities.

An attestation is an inspectable statement by an identified attester about such an implementation assessment. It may be self-issued or independently issued.

Certification is an attestation issued under an external certification regime. RecordWeb itself neither operates nor presupposes a certification authority, accreditation scheme, or legal certification regime. Whether and how an external regime uses RWP conformance claims is outside the scope of this concept document and of the RWP protocol.

12. Related Concepts and Demarcation

12.1. Linked Data and the Semantic Web

Tim Berners-Lee’s Linked Data principles [LINKED-DATA] are the conceptually closest relative of RecordWeb. RecordWeb takes up the networking idea from Linked Data and adds the institutional dimension that is missing there: accountability, versioning, auditability, states.

12.2. Records Continuum

RecordWeb is the technical implementation of the Records Continuum idea [UPWARD-1996] [UPWARD-1997]. The notion that a Record does not die but lives on is structurally anchored in RecordWeb, through immutable versions, through the version graph, through the absence of an "archiving" system transition.

12.3. Records Management (RM)

RM [ISO15489] defines international principles of Records Management: authenticity, reliability, integrity, usability. These four properties are RecordWeb’s requirements specification. RecordWeb fulfils all four structurally:

• Authenticity: DID and cryptographic hash guarantee that a Record is what it claims to be

• Reliability: Finalisation and immutable versions guarantee that a Record is complete and correct at the time of finalisation

• Integrity: Merkle hashes guarantee that a Record cannot change unnoticed after finalisation

• Usability: The DID document and metadata guarantee that a Record remains findable and accessible, regardless of system migrations

12.4. Open archival information system (OAIS)

OAIS [ISO14721] is the international standard for digital long-term preservation. RecordWeb and OAIS are complementary: RecordWeb covers the operational phase; OAIS covers long-term preservation. RecordWeb Records can be migrated to long-term archives according to OAIS principles; the DID is retained in this process.

12.5. PROV-O

[PROVO] is a W3C standard for describing the provenance and history of data. RecordWeb and PROV-O overlap in intention. The difference: PROV-O is a description standard, it can be layered onto existing systems. RecordWeb is an architecture standard, provenance is structurally anchored in the version graph. PROV-O would be a possible serialisation format for RecordWeb lineage documentation.

13. Roadmap and Open Questions: An Invitation

13.1. What RecordWeb Is Today

In this document, RecordWeb is a concept with an initial specification. It is not a product, not software. It is an architectural idea. Precise enough to discuss, open enough to be developed further together. The normative technical specification (the RecordWeb Protocol [RWP]) defines the JSON schemas, the DID structure, the version graph algorithms, and the Merkle calculations.

13.2. The Next Steps

Step 1: Concept Validation

The present concept must be discussed with professionals from Records Management, archival science, computer science, and public administration. Do the basic assumptions hold? Are there use cases that the model does not cover?

Step 2: Pilot Use Case

A concrete pilot use case is needed: a real Case from a public authority, modelled as a RecordWeb structure. What Record types arise? What does the version graph look like? Where do the concepts reach their limits?

Step 3: Standardisation Process

RecordWeb has the potential to contribute to international standardisation processes. This path is long. It begins with the concept, proceeds through the specification, and is validated through implementations.

13.3. Open Questions

The following questions are explicitly offered for community contribution:

Access control: RecordWeb deliberately defines no authorisation model. Data security and information protection are delegated to the implementing systems. The specification provides an optional accessPolicy block in the minimum metadata set.

Federation: RecordWeb offers a directional answer inspired by DNS architecture. DID resolvers function like DNS servers: federated, replicated, without a single point of failure. The Nanopublication network [NANOPUB] offers a working reference model: a decentralised peer-to-peer server network in which each node holds cryptographically signed, immutable micro-assertions identified by Trusty URIs. RecordWeb Records in their finalised state share the same structural properties (immutable, hash-identified, independently verifiable) and could be published and queried across a Nanopub-inspired federation layer. The complete federation architecture is the subject of [RWP].

Deletion obligations: The tension between RecordWeb’s immutability and the data protection right to erasure (GDPR, Swiss DSG) is resolved through payload deletion while retaining structure. On a legal requirement, the payload is deleted; the DID, the metadata, and the graph structure are retained. The Record continues to exist as a provable "empty shell", its former existence is documented, its content is gone.

Depending on the specific legal basis, the deletion regime admits three distinct modes:

Payload deletion (default)

The payload is deleted; DID, metadata, and version graph are retained. The Record remains as a structural shell. Applies where provenance continuity is legally required despite erasure (e.g. audit trails, public registers).

Full deletion (opt-out)

The entire Record (including DID, metadata, and graph edges) is deleted. Applies where no retention obligation exists and the right to erasure is absolute (e.g. erroneously captured personal data with no public interest basis).

Deletion exemption (opt-out)

No deletion occurs, not even of the payload. Applies where a statutory retention obligation overrides the erasure claim (e.g. tax records, notarial acts, public register entries). The legal basis must be documented as metadata on the Record at the time of creation.

The applicable mode is declared in the deletionRegime field of the Record’s metadata. Implementations MUST respect this field and MAY enforce it at the infrastructure level.

Performance and scaling: A global network of linked Records with cryptographic hash values places demands on infrastructure that are not yet fully foreseeable.

Platform adoption: The actual adoption task lies not with the end user, but with the platform providers: Microsoft, Google, SAP, and others must integrate RWP as a native layer into their products.

13.4. An Invitation

RecordWeb is a thesis, not a doctrine. It is an invitation to think together about the foundations of institutional information architecture, and in doing so, to question old assumptions.

Whoever wishes to accept this invitation (as a critic, as a fellow thinker, as an implementer) is welcome. Feedback is invited via GitHub Issues.

14. Annex A: Glossary

Branch

A parallel development line within the version graph of a Record. From one finalised version, two or more simultaneously existing drafts arise. Branches are transparently visible; their consolidation is effected through an explicit merge act.

Case

A specialised Record type that represents a persisted, governed view of linked Records. A Case makes Records belonging to a business transaction visible according to a defined schema, without becoming a container for those Records. It follows the same rules as any other Record: DID, states, version graph, finalisation.

Conformance claim

A statement by an identifiable implementation about the scope in which it claims conformance with the RecordWeb Protocol. The normative content, scope, and conditions of a conformance claim are defined by [RWP].

Conformance attestation

An inspectable statement by an identified attester about an assessment of a conformance claim. An attestation may be self-issued or independently issued. Whether an attestation forms part of an external certification regime depends on that regime.

Content hash

A cryptographic fingerprint calculated from the content of a dataset. Two datasets with identical content hashes are guaranteed to be identical. If even a single bit in the content changes, the hash changes.

DID (Decentralized Identifier)

A globally unique identifier that requires no central register. A DID permanently identifies a Record — regardless of where it is physically stored. Defined in [DID-CORE].

Directed Acyclic Graph (DAG)

A graph with directed edges and no cycles. Every node has one or more predecessors; no node can be its own ancestor. The version graph of every Record in RecordWeb is a DAG.

Finalisation

The explicit act by which a Record draft is converted into a binding, immutable version. Only finalised versions MAY be the target of a hard link. Finalisation is a human decision, documented with record owner and timestamp.

Merkle root

A cryptographic value calculated from the hash values of a set of Records that uniquely represents the aggregate state of that set. The Case Merkle root represents the state of a complete Case at a specific point in time.

Metadata

The dimensions along which a Record can be found, linked, and classified. The minimum set: type, timestamp, responsible parties, state, provenance references, classification, and a free tag field.

Owner

The person or organisational unit responsible for a Record at a specific point in time. Identified by a DID. The record owner is the one who finalises the Record and thereby assumes accountability for its content.

Payload

The actual content of a Record — the information it carries. A payload always follows the schema of its Record type.

Record

The smallest semantically autonomous unit of information in RecordWeb. A Record consists of identity (DID), payload, and metadata. It has a type that determines its schema, and a state that controls its linkability. It exists within a version graph and is permanently identifiable regardless of system boundaries.

State transition

A change of the state of a Record, for example from draft to finalized. In RecordWeb, "archiving" is a state transition, not a system migration.

Version graph

The entirety of all versions of a Record and their linkages. Every node is an immutable snapshot; every edge describes a provenance relationship. The version graph is a Directed Acyclic Graph (DAG): directed (from old to new), acyclic (no cycles). It contains branches and merges.

15. Annex B: Relationship to Existing Standards