7. Audit Trail & Compliance Package

Preamble This Audit Trail & Compliance Package ("Package") constitutes the technical and legal validation framework underpinning the Waiver2.0 Platform's evidentiary record. It documents the forensic architecture, evidentiary standards, and compliance mappings that govern every digital event recorded by the Platform. This Package is available to legal counsel, insurance underwriters, regulatory authorities, and courts upon verified request. 1. Purpose & Scope 1.1 The purpose of this Package is to provide a jurisdiction-neutral audit framework describing how e-signatures, payment events and forensic records are generated, sealed and kept by the Platform, for review against the rules of evidence of each jurisdiction. Whether a record is admissible, and its weight, is for the competent court or tribunal. 1.2 This Package serves as the primary technical validation of the Waiver2.0 record-keeping process (the i-witness protocol is not offered at present), documenting the chain of custody for every signed document from the moment of generation through signing, storage, and any subsequent access event. 1.3 Jurisdiction-Specific Legal Enforceability Basis: 🇦🇺 Australia: Electronic Transactions Act 1999 (Cth) and state/territory equivalents; Evidence Act 1995 (Cth); Privacy Act 1988 (Cth). 🇨🇦 Canada: Personal Information Protection and Electronic Documents Act (PIPEDA); Canada Evidence Act (ss. 31.1–31.8); applicable provincial electronic commerce and evidence legislation. 🇺🇸 United States: ESIGN Act (15 U.S.C. § 7001); UETA; Federal Rules of Evidence Rules 803(6) and 901; applicable state electronic transactions and evidence law. 2. Audit Trail Specification 2.1 Tamper-Evident Event Logging: Each waiver sealed after payment has a tamper-evident, hashed record in the forensic audit trail; document generation and data access events are not entries of the hash chain. Media captured through the i-witness protocol (not offered at present) is kept in the record of the incident, not in this audit trail. 2.2 The record of a signing event contains the following forensic data points; the IP address and the server timestamp are recorded with the sealed record; the server timestamp is not an input to the hash chain, and for waivers submitted from 16 October 2026 neither is the IP address (Section 4): Data PointDescriptionSHA-256 Document HashUnique cryptographic fingerprint of the final PDF at the moment of generationServer TimestampRecorded by the Platform's own server clock at the moment the event is received, independent of local device timeIP AddressNetwork address from which the submission was receivedLegal CorpusVersion and SHA-256 hash of the legal corpus (the templates and the files of text the Platform prints in the waiver contract and the health annex) of the server that accepted the submission, recorded with the submission and covered by its hash for waivers submitted from 25 October 2026; it does not identify the documents of the Legal Compliance Suite (Section 8.2)Contract_IDUnique identifier linking the forensic record to the Athlete's account and payment eventPayment RecordThe payment provider's transaction identifier, where one was recorded, and the start of the database transaction in which the Platform wrote the sealed record after confirming the payment (not the provider's own payment time), stored with the sealed record of the Contract_ID; it is not an input of the record's forensic hash (Section 6) 2.3 All log entries are stored in a forensic database in which an alteration of the hashed content of a sealed record is detectable by hash verification (Section 4.5). The Platform's application can add log entries but has no database permission to delete them or to change their hashed content; the owner of the database table and a database superuser can change or delete them, and personal data is to be deleted at the end of its retention period (Section 9.1; Privacy Policy, Section 5). 2.4 A sealed record is written to the hash chain after the payment provider reports a waiver's payment as captured or paid, one for each waiver sealed. A paid submission that has not been sealed has no entry in the chain. Events before the seal, including the first interaction with the Platform and a submission that is not paid, and the deletion of personal data at the end of its retention period are not entries of the chain. 3. Technical Architecture 3.1 Architecture: Waiver2.0 generates, hashes and stores each record on infrastructure it operates on Railway, a hosting provider acting as its processor. The components involved, the external processor used for transactional email and, once the archive copy of the Privacy Policy, Section 6.6, is kept, the external processor that holds it, are listed in the table below. ComponentTechnologyHostBackend Forensic EngineNode.js / TypeScript API ServiceRailway (EU West, Amsterdam)PDF Generation EngineCustom Puppeteer-based renderingRailway (EU West, Amsterdam)Primary DatabasePostgreSQL with forensic integrity constraintsRailway (EU West, Amsterdam)Transactional EmailResend (including single-use sign-in links, medical alerts to the Gym, the sealed PDF delivered to the Athlete and the link to it sent to the Gym)Sending infrastructure in Ireland; Resend Inc. is a US companyArchive CopyScaleway SAS (Paris, France), once the archive copy of the Privacy Policy, Section 6.6, is kept (a copy of the sealed PDF files and of the daily root values of the hash chain, and a daily backup copy of the database kept for at least 35 days, each file and each backup encrypted by Waiver2.0 before it is sent)A Scaleway region in the EU; Scaleway SAS is a company established in France 3.2 Architectural Principle: The Platform's forensic integrity depends on the following components: The Athlete's browser sends each submission, including health information, directly to the Node.js API Service over an encrypted connection (HTTPS); it does not pass through a workflow-automation tool. Node.js API Service = The Platform's business logic, including, in configuration (a) described below, the production of the PDF files and the email that delivers them. The SHA-256 hashing of each submission, chain-link generation and the sealing of the forensic record are performed within this service, and the daily check of the hash chain runs in it. The sealed contract and Health Annex PDF files are produced by the same codebase in one of two configurations, chosen by Waiver2.0: (a) inside this service, which renders them, computes their SHA-256 hashes, records those hashes and the file names in the forensic record, sends the email that delivers them and stores the files on its own storage volume; or (b) in a separate PDF worker service that Waiver2.0 runs with the same hosting provider, which renders them, computes their SHA-256 hashes, records those hashes and the file names in the forensic record, sends the email that delivers them and stores the files on its own storage volume, from which this service reads them over the hosting provider's private network; the checks of the stored PDF files against their recorded hashes are then run in that worker service. During a change between the two configurations each document is still produced by one of the two services. In either configuration the PDF files and their hashes are not inputs to the hash chain (Section 4.3). PostgreSQL = Forensic record storage. The primary repository for forensic records and hash chains. 3.3 Security Benefit: The components in the table in Section 3.1 other than transactional email and the archive copy run on infrastructure Waiver2.0 operates on Railway (EU West, Amsterdam), and each submission is received there by the Node.js API Service directly from the Athlete's browser. Transactional email is sent through Resend, a third-party processor, as set out in that table. 4. SHA-256 Hash Chain — Technical Specification 4.1 Document Hashing: For a record sealed since 7 October 2026, the service that renders the final PDF document (Section 3.2) computes, after the record has been sealed, a SHA-256 hash from its raw binary; before that date the document was usually rendered before the seal. This hash constitutes the document's unique digital fingerprint. 4.2 Payload Hashing: A payload hash is computed from the structured data record submitted at signing, together with the legal corpus stamp the server adds for waivers submitted from 25 October 2026 (Section 2.2). The server timestamp and document hash are recorded alongside it and are not part of that hash. 4.3 Chain Hashing: Each record's payload hash is combined with the chain_hash of the preceding record in its chain to produce that record's chain_hash (SHA-256), and the chain_hash is combined with the payload hash to produce the record_hash. The document hash and the server timestamp are stored with the record; they are not inputs to the chain_hash. Altering a sealed payload, or removing or reordering a record that is followed by later records in the chain, produces a mismatch that the chain verification detects. 4.4 MCD Media Hashing: Where a Premium Plan Athlete uses the MCD module (it is not offered at present), the SHA-256 hash of each media file is designed to be computed by the server at the time of receipt, over the file after the server removes the metadata in which a device may save its location (Media Capture Protocol, Section 4.1), and entered in a hash chain kept for the incident and linked to the waiver and its sealed record; the media is not entered into the waiver's own hash chain (Media Capture Protocol, Section 4). 4.5 Tamper Detection: A modification to a sealed payload after hashing produces a hash mismatch that the chain verification detects. Admissibility and weight remain for the competent court or tribunal. 5. Server Timestamping — Technical Specification 5.1 All signing events and payment confirmations are timestamped using the Platform's own server clock at the moment each event is received by the API. 5.2 Timestamps are recorded in UTC and are independent of the local device time of the signing user, so that adjusting the device clock does not change them. 5.3 The server timestamp is stored with each record and printed on the sealed document; it is not an input to the chain_hash. 6. Payment Record 6.1 Payment metadata is stored with the sealed record of the Contract_ID when the Platform writes that record after confirming the payment; it is not an input of the record's forensic hash. 6.2 The payment event is treated as a component of the record, as evidence that the Athlete not only signed the document but also fulfilled the financial consideration of the contract. 6.3 This payment-to-signature link may be relevant in insurance and litigation contexts, as a record of both the signing and the payment of the contract; the weight it carries is for the competent court or tribunal to decide. 6.4 Payment processing is conducted by Our payment provider, named at checkout, as an independent data controller. Waiver2.0 retains transaction metadata with the sealed record (Section 6.1), including the provider and its transaction and order identifiers, the amount, currency, plan, payment status, failure count and times, and the Contract_ID reference. 7. Admissibility Framework — Jurisdiction-Specific 7.1 🇦🇺 Australia The forensic records generated by the Platform are designed with the following requirements of the Evidence Act 1995 (Cth) and equivalent state and territory evidence legislation in mind; whether a record meets them in a given case is for the court: The business records exception to the hearsay rule (Evidence Act 1995, s. 69), addressed by the Platform's systematic, automated, and contemporaneous record-keeping process. The requirements for admissibility of electronic communications (Evidence Act 1995, s. 182). The Electronic Transactions Act 1999 (Cth) requirements for reliability of electronic signatures, addressed by the server timestamp, IP capture, and SHA-256 hash chain. 7.2 🇨🇦 Canada The forensic records are designed with the following requirements of the Canada Evidence Act (ss. 31.1–31.8) in mind; whether a record meets them in a given case is for the court: The integrity of the electronic records system, supported by the SHA-256 hash chain and tamper-evident audit log (Canada Evidence Act, s. 31.2). The business records exception (Canada Evidence Act, s. 30), addressed by the Platform's systematic and automated record-keeping. The electronic signature provisions of PIPEDA Part 2 (the Platform does not create a secure electronic signature as defined in PIPEDA). 7.3 🇺🇸 United States The forensic records are designed with the following requirements of the Federal Rules of Evidence and the ESIGN Act in mind; whether a record meets them in a given case is for the court: Business records exception (Federal Rules of Evidence, Rule 803(6)), addressed by the Platform's systematic, automated, and contemporaneous record-keeping. Authentication requirements (Federal Rules of Evidence, Rule 901), addressed by the SHA-256 hash chain and server timestamp. ESIGN Act requirements for electronic record retention (15 U.S.C. § 7001(d)), addressed by the Platform's tamper-evident storage and export capability. The Uniform Electronic Transactions Act, in the states that have adopted it. 8. Compliance Package Contents 8.1 The following documents constitute the complete Waiver2.0 Legal Compliance Suite, each published at athlete.waiver2.com/legal and showing the date it was last updated: #DocumentStatus1Terms of Use (Universal / Multi-Jurisdiction)✅ FINAL2Privacy Policy (Universal / Multi-Jurisdiction)✅ FINAL3Refund & Cancellation Policy (Universal / Multi-Jurisdiction)✅ FINAL4Electronic Signature & Forensic Disclosure (Universal / Multi-Jurisdiction)✅ FINAL5Standard Operating Procedure (SOP) (Universal / Multi-Jurisdiction)✅ FINAL6Data Processing Agreement (DPA) (Universal / Multi-Jurisdiction)✅ FINAL7Audit Trail & Compliance Package (Universal / Multi-Jurisdiction)✅ FINAL8Cookie & Tracking Policy (Universal / Multi-Jurisdiction)✅ FINAL9Media Capture Protocol (Universal / Multi-Jurisdiction)✅ FINAL10Gym Onboarding Agreement✅ FINAL11Accessibility Statement✅ FINAL12Plain English Rights Card✅ FINAL 8.2 The version of the documents listed in Section 8.1 is not recorded with a signing event. For waivers submitted from 25 October 2026, the record holds the version and SHA-256 hash of the legal corpus of the server that accepted the submission (Section 2.2); the contract and the health annex print that value and mark it when it differs from the corpus that rendered them. 8.3 The complete Compliance Suite is designated: Waiver2.0 Legal Compliance Suite — Universal / Multi-Jurisdiction. Each document shows the date it was last updated. 9. Forensic Record Retention & Judicial Verification 9.1 The personal data underlying each signing event — identity, contact details, health declarations, signature image, and stored payload — is retained until the limitation period applicable to the Gym's jurisdiction expires, counted from the expiry of the waiver, longer where the Waiver2.0 operator places a hold while an incident report is still open (holds are placed and lifted by the Waiver2.0 operator, not automatically; see Privacy Policy, Section 5: 12 years Australia, 6 years United States, 15 years Canada). The Gym's access to the health-information copy used for the Gym-facing medical alert ends when the Athlete's subscription ends, ahead of that date; the copy inside the sealed record is preserved until the limitation period expires. The cryptographic record — hash values, timestamps, and chain position — is retained permanently, by design, and continues to show that the record existed and where it sits in the hash chain after the personal data is deleted. 9.2 Read-Only Judicial Access: Upon receipt of a valid court order, regulatory request, or verified legal counsel request, Waiver2.0 will provide read-only access to the relevant forensic records within 5 business days. 9.3 Record Export: A forensic record may be exported as an evidence package, which holds, among other files, the contract PDF, a manifest of the record's identifiers and of its chain and document hashes, a README that explains how to check each hash with standard tools, and a SHA256SUMS file, and which may be offered as evidence; admissibility and weight remain for the competent court or tribunal. 10. Versioning & Amendments 10.1 This Package is versioned and stored on the Platform. Its version is not recorded with a signing event (Section 8.2). 10.2 We will notify the relevant user or Gym Compliance Officer of material amendments and, where required by law, seek consent again. 10.3 Last updated: 10 November 2026.