Chapter 5

Chapter 5: Exchange Protocol and Audit Trails

How biosafety records leave one institution and arrive at another without losing their meaning, their provenance, or their history.

Chapters 2 and 3 described records as they live inside a single institution: a facility registration, a training record, an incident report moving through its states. Chapter 4 put a service interface in front of those records. This chapter deals with the moment a record crosses a boundary. A training credential issued by one university is presented at a partner hospital. A national authority asks for quarterly incident statistics. An inspector needs to read, but never change, a facility's certification history. A registered material moves from one registered facility to another, and both sides must be able to show later who handed it over, who received it, and under which approval.

Each of these crossings raises the same three questions. Can the receiver trust that the record really came from the sender and was not altered on the way? Can the receiver process the same message twice, or a stale one, without corrupting its own state? And can anyone, months or years later, reconstruct exactly what happened, in what order, and who did it? The first question is answered by a message envelope, the second by idempotency and replay rules, and the third by an append-only audit trail. This chapter treats all three as data structures, because in an audit that is what they become.

5.1 Inter-Institution Exchange Scenarios

Before designing an envelope it helps to list who actually exchanges biosafety records and why. In practice four scenarios cover almost every request an institution receives. They differ in direction, in how much data is needed, and in whether the receiver may keep what it receives.

5.1.1 Joint-research facility sharing

Two institutions run a joint project, and researchers from institution A will work in a registered facility operated by institution B. Institution A's institutional biosafety committee (IBC) needs evidence that the host facility is registered, that its certification is current, and that its authorized level matches the level recorded on the approved project. It does not need B's floor plan, room-level engineering checklist, or staff list. The minimum payload is a projection of the BiosaftyFacility record from Chapter 2: facilityId, name, bslLevel, the certification block (certified, certificationDate, expirationDate, certifyingAuthority, nextInspectionDate) and the host's reference to the IBC approval that covers the project. The building and room fields stay at home. As Chapter 6 explains, precise facility-location data is itself sensitive.

5.1.2 Training-credential portability

A researcher moves between institutions, or holds appointments at two at once. Without an exchange, the receiving institution either repeats the training or accepts a scanned certificate it cannot verify. With an exchange, the receiving institution asks the issuing institution to confirm a specific TrainingRecord: its trainingType, trainingDate, expirationDate, whether the competencyAssessment was passed, and the certificateNumber. Whether the receiving institution then accepts that training, or requires its own site-specific induction, is a policy decision for its biosafety officer. The exchange supplies verified facts and leaves the decision to the institution. This scenario is the subject of the sequence diagram in Section 5.2.4.

5.1.3 Aggregated incident statistics to a national authority

Some authorities and networks ask institutions for periodic summaries: how many incidents and near misses were reported, of what type and severity, and how many corrective actions closed on time. The unit of exchange here is not an IncidentReport but an aggregate computed from many of them. Personnel identifiers, free-text descriptions and root-cause narratives never leave the institution. Only counts do, and only at a granularity the recipient specifies. When a count is small enough that it could point to an identifiable event or person, the sender should suppress or coarsen that cell. The suppression threshold is set by the recipient's reporting guidance and is not defined by this standard. Individual reportable incidents follow the separate notification hand-off described in Chapter 3 (the NotificationRecord), not this statistical channel.

5.1.4 Inspector read-only access

During an inspection or an accreditation visit, an external inspector needs to browse records in their original form: certification history, training status of authorized personnel, open corrective actions. The right pattern is a time-bounded, scope-limited, read-only grant, not an export. The inspector's reads themselves become audit events, so the institution can later show exactly what was viewed. That is useful both for the institution's own accountability and for resolving disputes about what was or was not disclosed.

Scenario	Direction	Record type exchanged	Minimum content	Receiver may retain?
Joint-research facility sharing	Host → partner IBC	Facility projection + approval reference	ID, name, level label, certification block, approval ID	Yes, for the life of the joint project
Training-credential portability	Issuer → verifier (on request)	Training-record attestation	Type, dates, pass/fail, certificate number	Yes, as evidence of the acceptance decision
Aggregated incident statistics	Institution → authority/network	Statistical summary	Counts by period, type, severity; CAPA closure counts	Yes (aggregate only)
Inspector read-only access	Inspector ← institution (pull)	Original records, view only	As scoped by the grant	No copy; reads are logged

The last column matters more than it first appears. A receiver that keeps data becomes a second custodian of it, with its own retention, access-control and breach obligations. Designing each scenario with the smallest possible payload is therefore not only a privacy measure but also a way to keep the number of places that must be secured and audited small.

5.2 The Message Envelope

Every record that crosses an institutional boundary travels inside an envelope. The envelope does not change the record. It adds the metadata a receiver needs to decide whether to accept it. Keeping the envelope separate from the payload has a practical benefit: the payload schema can evolve under the additive-only rules of Chapter 2 while the envelope stays stable, and the receiver can reject an unacceptable message before parsing its body at all.

5.2.1 Envelope fields

Field	Type	Purpose
envelopeId	string (UUID)	Unique identifier of this transmission. A time-ordered UUID (version 7, RFC 9562) sorts naturally in logs.
senderInstitutionId	string	Registered identifier of the sending institution in the federation directory.
recipientInstitutionId	string	Intended receiver. A message addressed to someone else is rejected, which prevents a captured message from being redirected.
schemaVersion	string (SemVer)	Version of the payload schema, so the receiver can pick the right validator.
recordType	enum	For example facility-projection, training-attestation, incident-statistics, custody-transfer, custody-receipt.
createdAt	ISO 8601 UTC	Sender's clock at creation; used for freshness checks (Section 5.5).
sequence	integer	Monotonic counter per sender–recipient channel.
idempotencyKey	string	Stable key for the business operation, reused on retry.
inReplyTo	string, optional	The envelopeId of the request this message answers.
payloadHash	string	SHA-256 digest of the canonicalized payload, with algorithm prefix.
signature	object	Detached signature over the canonicalized envelope (all fields except signature), with key identifier and algorithm.

Two design choices deserve explanation. First, the hash is computed over a canonical serialization of the payload. JSON allows the same data to be written in many byte-level forms (key order, whitespace, number formatting), and a hash over raw bytes would break whenever an intermediary reformats the document. The JSON Canonicalization Scheme (RFC 8785) defines one deterministic form and is a reasonable default. Second, the signature covers the envelope, and the envelope contains the payload hash, so one signature binds sender, recipient, sequence, time and content together. An attacker cannot swap the payload, replay the message to a different recipient, or change its sequence number without invalidating the signature.

The signature format is a deployment choice. JSON Web Signature (RFC 7515) is widely supported in web stacks. The DSSE envelope used by Sigstore, which Chapter 7 uses for conformance evidence, is another option. What matters for interoperability is that the federation profile names exactly one format and one set of permitted algorithms, and that keys are published in the federation directory with validity periods, so a verifier can tell whether a key was valid when a message was signed.

5.2.2 Example envelope

The example below carries a training attestation. All identifiers, names and values are fictitious. The hash and signature values are shortened placeholders.

{
  "envelope": {
    "envelopeId": "0192f3a4-7c1e-7b20-9d3a-5e8f1c2b4a61",
    "senderInstitutionId": "INST-EXAMPLE-UNIV-A",
    "recipientInstitutionId": "INST-EXAMPLE-HOSP-B",
    "schemaVersion": "1.2.0",
    "recordType": "training-attestation",
    "createdAt": "2026-03-10T01:15:42Z",
    "sequence": 4187,
    "idempotencyKey": "verify-TRN-2025-000731-req-88c1",
    "inReplyTo": "0192f3a1-02aa-7f10-8b44-1d9e0c7a3b12",
    "payloadHash": "sha256:9f2c…e41a",
    "signature": {
      "format": "jws-detached",
      "alg": "ES256",
      "kid": "INST-EXAMPLE-UNIV-A#key-2026-01",
      "value": "eyJhbGciOiJFUzI1NiIs…"
    }
  },
  "payload": {
    "subjectRef": "PSN-A-7f3c21",
    "trainingRecordId": "TRN-2025-000731",
    "trainingType": "refresher",
    "trainingDate": "2025-11-04T00:00:00Z",
    "expirationDate": "2026-11-04T00:00:00Z",
    "competencyAssessmentPassed": true,
    "certificateNumber": "CERT-A-2025-1142",
    "attestedBy": "BSO-A-001",
    "attestationStatus": "valid"
  }
}

Note what the payload leaves out. It does not include the assessor's score or the free-text notes that may sit in the source record. The subject is identified by a pseudonymous reference (subjectRef) agreed between the two institutions for this person, not by a national identifier. The expirationDate shown reflects the issuing institution's own policy. As Chapter 2 noted, refresher cadence is an institutional decision, and the one-year gap in the example is illustrative only.

5.2.3 Idempotency and replay protection

Networks retry. A sender that times out waiting for an acknowledgement will send again, and a receiver that processed the first copy must not create a second custody receipt or count an incident twice. Replay attacks take advantage of the same weakness on purpose. Three mechanisms, used together, close the gap.

1. Idempotency key. The sender derives one key per business operation (for example, "confirm receipt of transfer TRF-…") and reuses it on every retry. The receiver stores each processed key with the result it returned. When a key arrives again with an identical payload hash, the receiver returns the stored result without reprocessing. When the key arrives with a different payload hash, that is a conflict, and the receiver rejects it with an error rather than guessing which version is correct.
2. Sequence numbers. Each sender–recipient channel carries a monotonic sequence. The receiver tracks the highest sequence accepted and a small window of recent values. Anything already seen is a duplicate. Anything far below the window is stale and rejected. A gap signals that messages were lost and triggers a resynchronization request instead of silent acceptance.
3. Freshness window. The receiver compares createdAt with its own clock and rejects messages outside an acceptance window agreed in the federation profile. A window of a few minutes is a common starting point for online exchange (illustrative). Air-gapped batch exchange (Section 5.6) needs a much wider window, and relies more heavily on sequence numbers and signatures.

The idempotency store is itself a record with a retention period. It must keep keys at least as long as the sender might retry, and in practice it is simplest to keep it as long as the envelope log. Idempotency data is small, and losing it early reopens the duplicate problem at exactly the moment a slow partner system recovers and flushes its queue.

5.2.4 Walk-through: verifying a training credential

The sequence below shows scenario 5.1.2 end to end. The researcher's consent is collected by the receiving institution before the request is sent, because the issuing institution will disclose personal data about the researcher to a third party.

Researcher        Hospital B (verifier)        Directory          University A (issuer)
    |                     |                         |                         |
    |-- presents CERT --->|                         |                         |
    |<-- consent form ----|                         |                         |
    |--- consents ------->|  AuditEvent: consent.recorded                    |
    |                     |-- lookup INST-A key --->|                         |
    |                     |<-- endpoint + keys -----|                         |
    |                     |-- signed request (seq 912, idemKey K1) ---------->|
    |                     |                         |   verify sig, recipient,|
    |                     |                         |   freshness, seq        |
    |                     |                         |   AuditEvent: read       |
    |                     |<-- signed attestation (inReplyTo, seq 4187) -----|
    |                     |  verify sig + payloadHash                         |
    |                     |  AuditEvent: attestation.received                 |
    |                     |  BSO decision: accept / require induction         |
    |                     |  AuditEvent: training.accepted                    |
    |<-- result ----------|                         |                         |

Four audit events are written, split across the two institutions: consent and receipt at the verifier, the read at the issuer, and the acceptance decision at the verifier. Neither institution holds the whole story alone, yet together their trails reconstruct it completely, with each event pointing at the same envelope identifiers. If the issuer later revokes the training record, for example because a competency assessment is found to have been recorded in error, it can send a signed revocation that references the original attestation's envelopeId. The verifier then writes a further audit event and reopens its decision.

5.3 The Audit Trail

An audit trail is the institution's memory of who did what to which record, and when. In biosafety administration it answers the questions that come up in every inspection and every incident review. When was this facility's certification entered, and by whom? Was the training record edited after the incident? Who closed this corrective action, and was the closure reviewed? PHASE-3 requires "comprehensive audit logging" but does not specify its shape. The AuditEvent below is the book's proposal.

5.3.1 The AuditEvent record

Field	Content
eventId	Unique identifier (AUD- prefix, following the ID convention of Chapter 2).
streamId	The chain this event belongs to, typically one per institution or per tenant.
seq	Position in the stream, strictly increasing without gaps.
timestamp	ISO 8601 UTC time at which the action was committed.
actor	Pseudonymous user or service ID, the role under which it acted, and the authentication context (e.g. MFA used).
action	Controlled vocabulary: create, update, transition, read, export, grant, revoke, sign, and similar.
recordRef	Record type, record ID and record version affected.
beforeHash / afterHash	Digests of the canonical record before and after the action (null for create or read as appropriate).
reason	Short coded reason, plus optional reference (approval ID, ticket, envelope ID).
prevEventHash	The eventHash of the previous event in the stream.
eventHash	Digest of this event's canonical form, excluding eventHash itself.

The event stores hashes of the record before and after, not the record contents. That keeps the audit trail small and, more importantly, keeps sensitive content out of a store that is designed never to be edited. The record versions themselves live in the record store, which keeps prior versions. The audit event proves which version existed at each point, and the record store supplies the content when an authorized reviewer asks for it. If a version must later be erased for a lawful reason, the record store can remove the content while the audit trail keeps showing that a version with a given hash existed and was erased, by whom, and why.

5.3.2 Example

{
  "eventId": "AUD-2026-0004821",
  "streamId": "INST-EXAMPLE-UNIV-A/main",
  "seq": 4821,
  "timestamp": "2026-03-12T06:40:03.214Z",
  "actor": {
    "id": "USR-A-5d02e9",
    "role": "biosafety-officer",
    "authContext": "mfa"
  },
  "action": "transition",
  "recordRef": {
    "type": "IncidentReport",
    "id": "INC-2026-000118",
    "version": 5
  },
  "beforeHash": "sha256:1b7e…90c3",
  "afterHash": "sha256:c44a…0f7d",
  "reason": {
    "code": "status-change",
    "detail": "under-investigation -> resolved",
    "ref": "CAPA-2026-000061"
  },
  "prevEventHash": "sha256:77d0…a912",
  "eventHash": "sha256:e3f8…5b26"
}

The event records a state transition of the kind defined in Chapter 3. The reason.ref points at the corrective-action record whose completion justified the transition. An auditor can therefore follow a single thread from "incident marked resolved" to "which CAPA made that acceptable" to "who approved the CAPA", without reading any incident narrative.

5.3.3 Hash chaining

Each event includes the hash of the one before it. Changing, deleting or inserting any event in the middle of the stream changes that event's hash, which no longer matches the prevEventHash stored in its successor, and so on to the end of the stream. To hide an edit, an attacker would have to rewrite every later event, and that becomes detectable the moment any later event hash has been shared outside the database. The verification logic is short:

import { createHash } from "node:crypto";

// canonicalJson: an RFC 8785 (JCS) implementation supplied by the deployment
declare function canonicalJson(value: unknown): string;

interface AuditEvent {
  eventId: string;
  streamId: string;
  seq: number;
  prevEventHash: string | null;
  eventHash: string;
  [field: string]: unknown;
}

function digest(e: AuditEvent): string {
  const { eventHash, ...body } = e;          // hash everything except eventHash
  const h = createHash("sha256").update(canonicalJson(body), "utf8");
  return "sha256:" + h.digest("hex");
}

export function verifyStream(events: AuditEvent[]): { ok: boolean; brokenAt?: number } {
  let prev: string | null = null;
  for (let i = 0; i < events.length; i++) {
    const e = events[i];
    if (i > 0 && e.seq !== events[i - 1].seq + 1) return { ok: false, brokenAt: e.seq };
    if (e.prevEventHash !== prev) return { ok: false, brokenAt: e.seq };
    if (digest(e) !== e.eventHash) return { ok: false, brokenAt: e.seq };
    prev = e.eventHash;
  }
  return { ok: true };
}

A chain proves internal consistency, not absolute truth. A database administrator who controls the whole stream could rebuild it from scratch with altered content, and it would verify. Hash chaining becomes a strong control when the latest hash, the "head", is regularly committed somewhere the administrator does not control. There are three common options. The first is to include the current head in each outbound envelope's metadata or in periodic signed statements sent to partners. The second is to obtain a trusted timestamp over the head from an independent time-stamping authority (the Time-Stamp Protocol, RFC 3161). The third is to anchor the head in an external ledger, which is what the README's reference to WIA-BLOCKCHAIN describes.

5.3.4 Anchoring with WIA-BLOCKCHAIN: benefits and trade-offs

The README lists WIA-BLOCKCHAIN integration for "immutable audit trails for compliance". Read carefully, the useful form of this is narrow: periodically write a single digest (the stream head, or the root of a Merkle tree over a batch of events) to the ledger, never the events themselves. Anchoring on that basis offers real benefits and real costs.

Aspect	Anchoring digests only	Writing records or events on-chain
Tamper evidence	Strong: any rewrite after the anchor time is detectable	Strong, but no stronger than anchoring
Confidentiality	Digest reveals nothing useful about content	Exposes metadata (who, when, which facility) to every ledger participant
Erasure obligations	Content erased off-chain; digest remains meaningless	Conflicts with lawful erasure and correction rights
Operational dependency	Low: anchoring can lag or be retried without blocking work	High: record writes depend on ledger availability
Cost and complexity	One transaction per anchoring interval	Per-event cost and key management for all writers

The conclusion is that anchoring is an optional hardening step, not a requirement, and that an RFC 3161 timestamp or cross-signing with partner institutions can deliver comparable tamper evidence with fewer moving parts. An institution that chooses anchoring should state the anchoring interval in its profile manifest (Chapter 7), because the interval bounds how much history could be silently rewritten before the next anchor.

5.3.5 Retention

How long audit events, envelopes, idempotency records and record versions must be kept is decided by the law of each jurisdiction and by the rules of the authorities and funders involved, not by this standard. The PHASE-1 and PHASE-3 implementation notes mention a seven-year retention window. The book treats that figure as a floor for the software: an implementation should be able to keep data at least that long and should make the period configurable per record type. It is not a statement that seven years is legally sufficient anywhere. The PHASE note links that period to a certification-body standard (ISO/IEC 17065), and the book does not rely on that link. An institution should obtain its retention schedule from its legal and records-management function and set the configuration to match. The schedule should cover the audit trail as well, which must be kept at least as long as the records it describes.

Retention also has a lower edge. When a retention period ends, deletion is itself an audited action. The event records what was deleted (by hash), under which schedule, and by which process, so that the absence of a record can later be explained.

5.4 Chain of Custody at Record Level

Research institutions move registered materials between registered facilities, within the institution and across institutions. The management question is simple and strict. At every moment, which registered facility and which accountable person is responsible, and does the paperwork on both ends agree? The SDK has no custody types. The book proposes two records, a transfer record created by the sender and a receipt record created by the receiver, linked by a shared transfer ID.

5.4.1 Transfer and receipt records

Record	Field	Meaning
Transfer	transferId	Identifier shared by both records (TRF- prefix).
	materialRef	Institution-internal registry ID of the material. No descriptive or characteristic data (see Chapter 2, data minimization).
	riskGroup	The RiskGroup classification label (1–4) as recorded in the registry, the same field as in materialRefs (Chapter 2). No other classification data.
	fromFacilityId / toFacilityId	Registered facility IDs at both ends.
	releasedBy	Pseudonymous ID of the accountable person releasing custody.
	approvalRefs[]	IBC approval ID and any permit or approval reference issued by the competent authority, where one is required.
	transportLabel	Optional regulatory label for the consignment, as text (see 5.4.2).
	dispatchedAt	UTC time custody was released.
Receipt	receivedBy	Pseudonymous ID of the accountable person accepting custody.
	receivedAt	UTC time custody was accepted.
	outcome	accepted, accepted-with-discrepancy, or refused.
	discrepancyRef	If not simply accepted, the ID of the incident or near-miss record opened under Chapter 3.

The pair forms a small state machine: initiated → dispatched → received or refused, with overdue raised automatically when no receipt arrives within the window the two institutions have agreed. Custody is never "nobody's". Until the receipt is recorded, the sending facility remains accountable, and an overdue transfer shows up on the sending biosafety officer's dashboard, not only the receiver's. A discrepancy is not fixed by editing the transfer record. It is handled as a new record: the receiver records what it observed at the administrative level, and the resulting incident or near-miss enters the workflow of Chapter 3.

{
  "transfer": {
    "transferId": "TRF-2026-000044",
    "materialRef": "MAT-A-REG-01872",
    "riskGroup": 2,
    "fromFacilityId": "FAC-A-0103",
    "toFacilityId": "FAC-B-0210",
    "releasedBy": "PSN-A-19b0aa",
    "approvalRefs": ["IBC-A-2025-117", "IBC-B-2026-009"],
    "transportLabel": "UN 3373",
    "dispatchedAt": "2026-04-02T00:30:00Z",
    "status": "dispatched"
  },
  "receipt": {
    "transferId": "TRF-2026-000044",
    "receivedBy": "PSN-B-4c7e10",
    "receivedAt": "2026-04-02T05:12:00Z",
    "outcome": "accepted",
    "discrepancyRef": null
  }
}

The example uses fictitious facility, approval and registry IDs. The riskGroup and transportLabel values are placeholders that show the field format. They are not guidance on how any material should be classified or shipped. That determination belongs to the qualified personnel and the rules cited below.

5.4.2 Transport regulations as labels only

Consignments of biological material are subject to transport rules such as the IATA Dangerous Goods Regulations and the UN numbering system (for example UN 2814 and UN 3373), which the main WIA-BIO-017 specification mentions in its section on international organizations. A management record may store which label was applied, as text, so that the custody trail can be matched to shipping documents. The record does not store packaging, labelling or content details. Deciding which rule applies and preparing a compliant shipment is the job of trained and, where required, certified shipping personnel working from the current official regulations. This book does not reproduce those regulations.

5.4.3 Cross-institution custody

When the two facilities belong to different institutions, the transfer and the receipt each travel in a signed envelope. The receipt's envelope uses inReplyTo to reference the transfer's envelope. Each institution records an audit event when it sends and when it receives. The shared transferId and the envelope IDs let either side, or an inspector with read access to both, line up the two trails. An idempotency key on the receipt ("receipt of TRF-2026-000044") ensures that a retried receipt never turns into two receipts.

5.5 Time and Ordering

An audit trail is only as good as its clock. The questions it answers ("was the certification valid on the day of the transfer?", "was the training recorded before or after the incident?") are questions about order. Order across machines is harder than it looks.

5.5.1 Synchronized clocks

All timestamps are recorded in UTC in ISO 8601 format. Local time is a display concern, never a storage concern. The PHASE implementation notes recommend NTPv4 (RFC 5905) against stratum-2 servers as sufficient for most deadlines, with the Precision Time Protocol (IEEE 1588) where tighter synchronization is needed. For biosafety records, whose deadlines are measured in hours and days, the notification targets of Chapter 3 among them, NTP is ample. The discipline that matters more is monitoring. A server whose clock has drifted should raise an alert, and events written while its offset exceeded tolerance should be flagged so reviewers know their timestamps are less reliable.

5.5.2 Sequence beats wall-clock time

Within one stream, order is defined by seq, not by timestamp. Two events committed in the same millisecond, or on two application servers with slightly different clocks, still have an unambiguous order because the database assigns sequence numbers in a single transaction. Timestamps remain important as evidence of when something happened, but they are never used to decide which of two events came first in the same stream.

Across institutions there is no shared sequence. Each side orders its own events, and envelopes provide the causal links. A receipt that says inReplyTo a transfer happened after that transfer, whatever the clocks say. When a receiver sees a message whose createdAt is later than its own current time, beyond the tolerance, it should not "correct" the timestamp. It should accept or reject the message according to the profile and record both times: the sender's createdAt and its own receivedAt. Reviewers can then see the skew instead of having it silently erased.

5.5.3 Validity checks against time

Many exchange decisions compare a timestamp with a validity period: was the facility certification current at dispatchedAt, and was the training unexpired at the date of an access grant? These checks should always use the event's own recorded time and the record version that was in force at that time, which the audit trail can reconstruct. Checking against "now" produces false results when an old event is reviewed. The certification may have been renewed since, or may since have lapsed.

5.6 Federation Topologies

The PHASE annexes describe four reference deployment shapes, used by the working group to validate the test vectors. They are non-normative, but they are a helpful vocabulary for matching exchange architecture to the kind of institution involved. Each deployment declares its topology in its profile manifest (Chapter 7), and a change of topology requires a newly signed manifest.

Topology (PHASE Annex J)	Shape	Typical fit for biosafety records	Audit-trail implications
Single-tenant edge	One runtime per organization, no shared state; manifest signed by the organization itself	A single university, hospital or company running its own biosafety management system	One stream per institution; external anchoring or partner cross-signing is the main defence against insider rewrite
Multi-tenant gateway	One shared runtime serving several tenants with header-based isolation and a shared identity provider	A vendor-hosted service or a consortium hosting smaller institutions	One stream per tenant; the operator must show that no tenant can read or write another's stream, and operator actions are logged in each affected tenant's stream
Federated mesh	Independent runtimes peering with each other and publishing to a directory service	Research consortia and joint projects across several institutions	Each peer keeps its own stream; envelopes and shared IDs link them; the directory signs the index of members and keys
Air-gapped batch	No live network link; signed evidence packages carried out of band	Environments where policy forbids live connectivity, and recipients that accept only batch submissions	Each batch carries the stream head and signatures; wider freshness windows; the sequence number is the primary integrity check

Real institutions often combine shapes. A university may run a single-tenant edge system internally, join a federated mesh for a multi-institution consortium, and send its annual statistics to an authority as an air-gapped batch. The envelope and audit-event structures in this chapter are deliberately the same in every topology. Only transport, key distribution and freshness tolerances change. That is what makes it possible to move between shapes without rewriting records or breaking the audit chain.

5.6.1 Choosing a topology

Three questions settle most decisions. First, who operates the runtime, and does the institution's policy permit that operator to hold its records? If not, a multi-tenant gateway is ruled out. Second, how many partners exchange records routinely? With one or two partners, point-to-point exchange between single-tenant systems is simpler than a mesh. With many, a directory service pays for itself. Third, does any recipient or environment forbid live connectivity? If so, batch export must be supported regardless of what else is chosen.

Whichever shape is chosen, key management is the part most often underestimated. Each institution needs a documented process for rotating its signing keys, publishing new keys to the directory before use, and keeping retired public keys available for as long as signed messages and evidence packages must be verifiable. That is at least as long as the retention period of Section 5.3.5.

Chapter Summary

• Four exchange scenarios cover most needs: facility sharing, training-credential portability, aggregated incident statistics and inspector read-only access. Each should carry the smallest payload that supports the receiver's decision.
• A signed envelope binds sender, recipient, schema version, sequence, time and a canonical payload hash. Idempotency keys, sequence numbers and freshness windows together prevent duplicates and replays.
• An append-only, hash-chained AuditEvent stream records actions by reference and hash, not by content. External anchoring (a trusted timestamp, partner cross-signing, or WIA-BLOCKCHAIN digests) is optional hardening.
• Retention is set by jurisdiction. The PHASE seven-year figure is a software floor, not a legal conclusion.
• Custody is tracked through paired transfer and receipt records between registered facilities. Transport regulations appear only as labels.
• Order within a stream comes from sequence numbers, and order across institutions comes from envelope links. Clocks are synchronized and monitored but never silently corrected.
• The four PHASE reference topologies share one record and envelope model and differ only in transport, keys and tolerances.

Chapter 6 turns to the controls that protect these records and exchanges: the threat model, role-based access, personal-data rules and integration with the systems institutions already run.