Overlay attachments policy

Several v3 overlays carry unstructured attachments today — TA10 plans, EPCs, leasehold packs, photographs, identity-verification documents. This page is the published handling policy: file-format requirements, signing and integrity rules, retention guidance for issuers, and consent semantics for consumers whose documents are flowing through the framework.

1. Overview and scope

PDTF v3 overlays embed document attachments (TA10 plans, leasehold packs, EPCs, photographs, survey reports, search responses) alongside the structured claims they extend. Until now the framework has had no published handling policy for these attachments — file-format expectations, integrity proofs, retention obligations, and consent semantics have all been left to the individual issuer's discretion. This page is the policy. It defines what handling looks like across all eleven attachment-bearing overlay families, and it identifies the decisions that the Technical WG (with C&R WG input on retention and consent) needs to make to put the policy into production.

The work is commissioned in ADR 0001's Wave 2 — see §Resolved during review item 6, which promotes the overlay-attachment strand from Wave 3 to Wave 2 because the artefacts are already in production overlays. The companion strand (GARP-based handling for OPDA's institutional records) stays in Wave 3. ADR 0001's §Reassessing the four boundaries → DMBOK Document & Content Management is the framework anchor: PDTF v3 overlays embed document attachments throughout: TA10 fittings & contents, leasehold packs, EPCs, plans, photographs. The base pdtf:Document type carries unstructured payloads alongside structured claims.

The regulatory anchors are UK GDPR Article 5(1)(e) — storage limitation: personal data kept in a form which permits identification of data subjects for no longer than necessary — and UK GDPR Article 5(1)(f) — integrity and confidentiality: personal data processed in a manner that ensures appropriate security including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures. Both apply to every attachment that carries personal data, which in practice is almost all of them. For attachments that do not carry personal data (a redacted title plan, a public EPC) the security limb still applies; the storage limit relaxes.

The framework anchor for handling discipline is the Generally Accepted Recordkeeping Principles (GARP) — accountability, integrity, protection, compliance, availability, retention, disposition, transparency. ADR 0001's reassessment (§Document & Content Management) observes that GARP overlaps almost perfectly with OPDA's own published principles in governance.md §1, and promotes the framework into scope on that basis. This page therefore reuses GARP as the cross-cutting policy spine: every per-type subsection below maps to the GARP principles even where it does not name them.

Scope: every overlay in source/03-standards/schemas/src/schemas/v3/overlays/ that issues or anticipates issuing attachments alongside structured claims. Out of scope: OPDA's institutional records (markdown, transcripts, briefings) which are governed by the Wave 3 GARP-for-records strand; attachment handling inside member firms' internal systems before issuance or after disposal (which remains a member-firm matter, with this page providing a default that can be adopted).

2. The eleven attachment types

The eleven attachment-bearing overlay families are listed below, in the same order as the stub. Each subsection captures: what the attachment is, which overlay it originates in, file formats that have appeared in production, the integrity pattern, a retention shape, and a consent shape. Specific retention durations, mandatory format whitelists, and consent UX flows are flagged as WG decisions — they are not proposed here.

The integrity pattern is universal across all eleven families and is therefore restated once here rather than repeated per type: every attachment is content-addressable (hashed before issuance); the hash is embedded in the issuing Verifiable Credential; the VC envelope signature covers the hash. See §3. Cross-cutting policy for the full signing / integrity discussion, anchored on the W3C VC Data Model.

2.1 TA10 — Fittings & Contents attachments

• What it is: photographs of fixtures and fittings; floor plans annotated to identify items included in the sale; supplementary inventories where the form's enumerated fields cannot capture the item.
• Originating overlay: ta10.json (Law Society TA10 Edition 3, Fittings and Contents Form).
• Typical file formats (production observed): JPEG and PNG for photographs; PDF for annotated plans; occasionally PDF/A for archival-grade plans where the conveyancer's case-management system enforces it.
• Integrity: as universal — content hash embedded in the VC; signature over the VC envelope covers the hash.
• Retention shape: linked to the transaction lifecycle for the issuing firm — retention extends through the Limitation Act 1980 ceiling for contractual claims arising from the conveyance, which is the longest plausible window in which a dispute over fixtures could surface. WG decision: exact retention period in years and the trigger event (completion, registration, or grant of indemnity).
• Consent shape: consent is granted under the transaction grant — the seller authorises onward sharing for purposes incidental to completing the sale (showing the buyer, the buyer's solicitor, the lender's surveyor). Derivative uses (training data for AVM photograph-quality scoring, comparable-sales image datasets) require a separate consent. WG decision: consent UX and whether derivative consent is granular (per use-case) or compound (a single broader opt-in).

2.2 TA6 and TA7 — Property and Leasehold Information attachments

• What it is: guarantees (FENSA, GasSafe, electrical), planning permissions and decision notices, building regulation completion certificates, party-wall agreements (TA6); lease pack, service-charge statements, buildings insurance certificates, head-lease where applicable (TA7).
• Originating overlays: ta6.json (Law Society TA6 Edition 4, Property Information Form) and ta7.json (Law Society TA7 Edition 3, Leasehold Information Form).
• Typical file formats (production observed): PDF (overwhelmingly), with some legacy TIFF and scanned-image PDF for older certificates; native PDF where the issuing body publishes it (FENSA, local authority planning portals).
• Integrity: universal — see §3. Additional note: where the issuing authority itself signs the PDF (HMLR signed title plans, FENSA certificates with embedded signatures), the original issuer's signature should be preserved alongside the OPDA-overlay signature.
• Retention shape: matched to the longer of (a) the Limitation Act 1980 contractual ceiling for the conveyance, and (b) the natural retention period for the underlying document (insurance certificates retain through the policy term; planning notices retain through the implementation window; lease packs retain through the lease term). WG decision: per-document-class retention rules and how multi-anchor retention is captured in the issuer's retention schedule.
• Consent shape: transaction grant covers onward sharing with the chain (buyer, buyer's solicitor, lender, freeholder for TA7); third-party data (e.g., a previous owner named on a planning notice, a contractor named on a guarantee) is incidental to the document and is shared on a necessary-for-the-transaction basis under UK GDPR Article 6(1)(b) or (f). WG decision: whether third-party data inside attachments requires a separate notification flow when it materially exceeds what the transaction needs.

2.3 BASPI v5 — Material-information attachments

• What it is: material-information documents required by NTSELAT's Parts A, B, and C guidance (tenure proof, council-tax band, EPC, restrictive covenants, flood-risk statements, accessibility statements, parking arrangements).
• Originating overlay: baspi5.json (BASPI v5 — enhanced Buyers and Sellers Property Information). The earlier baspi4.json family carries a narrower set of the same kinds of attachments.
• Typical file formats (production observed): PDF for documents; image formats (JPEG / PNG) for photographs; GeoJSON or PDF for flood-risk maps depending on the source authority's publishing format.
• Integrity: universal. Many BASPI v5 attachments are themselves issued by an authoritative third party (EPC from a registered assessor, flood-risk statement from the Environment Agency); the third party's original signature should be retained where present, and the OPDA-overlay signature attests only to the integrity of the attachment as bundled, not to the underlying authority's claims.
• Retention shape: Limitation Act 1980 ceiling, plus the natural lifetime of the material-information document (EPCs are valid for ten years from issuance; council-tax bands persist until revaluation). Material information forms part of the contractual record and so retains for the duration of any plausible NTSELAT enforcement window. WG decision: NTSELAT-aligned retention floor versus the broader contractual ceiling, and how the two interact when they diverge.
• Consent shape: transaction grant covers onward sharing for marketing-the-property purposes (NTSELAT's primary use-case for material information is informing prospective buyers before they make an offer). Derivative analytical use (NTSELAT compliance benchmarking, regulator-facing aggregate reporting) is plausibly within the public-interest basis under UK GDPR Article 6(1)(e) but should not be assumed without WG sign-off. WG decision: derivative-use basis and whether aggregate reporting requires explicit consent or relies on legitimate interests / public interest.

2.4 NTS / NTS2 / NTSL / NTSL2 — Consumer-protection attachments

• What it is: supporting documents for the National Trading Standards material-information regime — overlapping with BASPI's set but framed by the consumer-protection lens (specialist-issues documentation for asbestos, Japanese knotweed, dry rot, subsidence; flood-defence statements; leasehold-fee schedules in the NTSL families).
• Originating overlays: nts.json (NTS 2023), nts2.json (NTS 2025), ntsl.json (NTS Leasehold 2023), ntsl2.json (NTS Leasehold 2025). The extensions/ directory carries the modular specialist-issues overlays (as.json asbestos, jk.json Japanese knotweed, dr.json dry rot, sb.json subsidence, hs.json health & safety) that NTS2 references; each may carry its own supporting attachments.
• Typical file formats (production observed): PDF for specialist reports (asbestos surveys, structural reports, treatment guarantees); JPEG / PNG for photographs documenting the issue.
• Integrity: universal. Specialist-issues attachments are often signed by an accredited specialist (asbestos surveyor, structural engineer); the specialist's signature should be preserved alongside the OPDA-overlay signature.
• Retention shape: aligned with the latent-defect window for the underlying issue (asbestos and structural defects can manifest decades after disclosure; treatment guarantees specify their own retention windows). The Limitation Act 1980 ceiling applies for contractual claims; statutory limitation for tort claims extends further. WG decision: whether the OPDA-published default retention shadows the specialist's own guarantee period, the contractual ceiling, or a longer floor.
• Consent shape: transaction grant covers onward sharing with the chain. Specialist-issues attachments may identify named professionals (the surveyor who diagnosed the issue, the contractor who treated it) — their data is incidental and shared on the same basis as TA6/TA7 third-party data. WG decision: aligned with the TA6/TA7 third-party-data decision above.

2.5 PIQ — Property Information Questionnaire attachments

• What it is: attachments supporting the estate agent's pre-marketing property information questionnaire — photographs, floor plans, marketing materials, the agent's own due-diligence evidence.
• Originating overlay: piq.json (PIQ v3, Property Information Questionnaire).
• Typical file formats (production observed): JPEG / PNG / WebP for photographs; PDF for floor plans and marketing brochures; occasionally video container formats for virtual tours.
• Integrity: universal. PIQ attachments are agent-issued and so the OPDA-overlay signature is typically the only signature present.
• Retention shape: shorter than the legal forms above — PIQ attachments are marketing artefacts, not contractual evidence. Retention follows the marketing-record retention default for the agent's accreditation body, with a floor aligned to the duration of the listing. WG decision: retention floor (listing duration plus a buffer) versus a fixed period after the listing's withdrawal or completion.
• Consent shape: the seller's consent to marketing the property includes consent to PIQ attachments being shared with portals (Rightmove, Zoopla, OnTheMarket), prospective buyers, and the agent's own marketing channels. Derivative use of photographs (the agent's own portfolio, training data for AI staging tools, comparable-sales image collections) requires a separate consent. WG decision: derivative-use granularity and whether photographs of identifiable interior detail (artwork, personal items) warrant a separate consent tier.

2.6 RDS — Residential Development Survey attachments

• What it is: survey reports, condition-assessment narratives, photographs documenting building condition, drone imagery of roofs and external elevations, thermal-imaging output.
• Originating overlay: rds.json (Residential Development Survey).
• Typical file formats (production observed): PDF for the survey report itself; JPEG / PNG / TIFF for high-resolution photographs; thermal-imaging output in proprietary or PNG/TIFF format depending on the surveyor's equipment.
• Integrity: universal. Survey reports are signed by the issuing surveyor; the surveyor's signature should be preserved alongside the OPDA-overlay signature.
• Retention shape: long — survey findings remain relevant for the working life of the building element they describe (a roof survey informs decisions over decades). Surveyor professional-indemnity insurance typically requires retention of survey records for at least the limitation period for professional-negligence claims (six years from the date the cause of action accrues, extendable). WG decision: retention floor aligned with PI insurance practice, and whether OPDA's default exceeds the floor.
• Consent shape: transaction grant covers onward sharing with the chain and with subsequent surveyors who may rely on the previous report. Derivative use (training data for automated condition-assessment, comparable-survey benchmarking) requires a separate consent. WG decision: whether the surveyor or the seller is the appropriate consent party for derivative use, given that the report is the surveyor's intellectual property but the underlying property is the seller's.

2.7 CON29R / LLC1 / CON29DW — Search attachments

• What it is: local-authority search responses (CON29R standard enquiries; LLC1 local land charges); water-utility search responses (CON29DW drainage and water); supporting documentation that authorities attach to their responses (planning decision notices, road-adoption maps, asset maps).
• Originating overlays: con29R.json (Local Authority Search 2019), llc1.json (Local Land Charges Search v2), con29DW.json (Drainage and Water Search). HMLR Official Copies (oc1.json) are covered separately in §2.9 — they share the "issued by a public authority" shape but the issuing authority and content are different.
• Typical file formats (production observed): PDF for the search response (authority-issued); PDF and GeoJSON for accompanying maps where the authority publishes machine-readable formats.
• Integrity: universal. Search responses are signed by the issuing authority (local council, water utility); the authority's signature should be preserved alongside the OPDA-overlay signature. Where the authority signs only the response narrative and not the accompanying maps, the OPDA-overlay signature should cover both.
• Retention shape: Limitation Act 1980 contractual ceiling, plus the natural lifetime of the underlying entries (a local land charge persists until removed from the register; a planning decision persists until implementation or lapse). Search responses are part of the conveyance contractual record and so retain through the conveyance limitation window. WG decision: aligned with the TA6 attachment retention decision.
• Consent shape: search responses are issued by public authorities and largely concern public-register information; consent considerations are weaker than for personal-data-rich attachments. Third-party personal data may appear (named owners on charge entries, named applicants on planning records) — handled on the same basis as TA6/TA7 third-party data. WG decision: minimal — aligned with TA6/TA7.

2.8 FME1 / LPE1 — Management-enquiry attachments

• What it is: management company responses to freehold (FME1) or leasehold (LPE1) enquiries — service-charge accounts, reserve-fund statements, insurance schedules, building-safety case files (post-Building Safety Act 2022), major-works consultation notices.
• Originating overlays: fme1.json (Freehold Management Enquiries Edition 2) and lpe1.json (Leasehold Property Enquiries Edition 4).
• Typical file formats (production observed): PDF for financial statements, insurance schedules, and consultation notices; occasionally Excel / CSV for service-charge breakdowns where the managing agent publishes machine-readable data.
• Integrity: universal. Management-enquiry responses are signed by the managing agent or freeholder; their signature should be preserved alongside the OPDA-overlay signature.
• Retention shape: aligned with TA7 leasehold-pack retention (lease term plus the contractual ceiling); building-safety case files for relevant buildings retain through the statutory floor set by the Building Safety Act 2022. WG decision: Building-Safety-Act floor for the in-scope subset, and how it interacts with the broader leasehold default.
• Consent shape: aligned with TA7. Service-charge data and insurance schedules contain limited personal data; building-safety files may contain more (named building-safety officers, occupier-specific safety assessments) and warrant tighter handling. WG decision: whether building-safety files warrant a tighter consent tier than the broader leasehold default.

2.9 OC1 — Office Copy attachments

• What it is: HMLR office copy entries — official copies of the register, title plan, charges register; supporting documents referenced in the register (filed deeds, restrictions, leases held by HMLR).
• Originating overlay: oc1.json — HMLR Official Copies of the Register. The schema's own fields (ocSummaryData, ocRegisterData, officialCopyDateTime, proprietorship, registerEntryIndicators) are HMLR title-register concepts. Upstream note: the schemas README.md currently labels this overlay "Optional Enquiries of Local Authority v21" — that label is inconsistent with the schema content and should be corrected upstream; flagged for the Technical WG.
• Typical file formats (production observed): PDF (HMLR's published format for official copies); occasionally the underlying lease as scanned PDF where the lease is held by HMLR rather than the leaseholder.
• Integrity: universal. Office copies are signed and dated by HMLR as the issuing authority; HMLR's signature should be preserved alongside the OPDA-overlay signature. The dated nature of office copies (an "as at" date) is material to integrity — the attachment's freshness is part of its value and should be surfaced in the VC metadata.
• Retention shape: office copies are by their nature point-in-time snapshots; HMLR's own retention practice is the upstream reference. The "as at" date plus a refresh window (a fresh office copy is typically obtained at exchange or completion) drives the operational retention. WG decision: retention of stale office copies — how long the original snapshot retains after a fresher copy supersedes it, and whether superseded copies are kept for audit or disposed.
• Consent shape: register entries are public; consent considerations are weaker than for personal-data-rich attachments. Filed deeds and historic leases may contain third-party personal data (named parties to historic transfers) — handled on the same basis as TA6/TA7 third-party data. WG decision: aligned with TA6/TA7; minimal.

2.10 SR24 — Sustainability Report attachments

• What it is: supporting evidence for the Sustainability Report — energy-use data, smart-meter exports, retrofit records, embodied-carbon assessments, accreditation certificates (Passivhaus, BREEAM, EnerPHit), green-mortgage compliance documentation.
• Originating overlay: sr24.json (Sustainability Report 2024).
• Typical file formats (production observed): PDF for reports and certificates; CSV / JSON for smart-meter and energy-use time series; PDF for accreditation certificates issued by certification bodies.
• Integrity: universal. Certification-body documents are signed by the issuing body; their signature should be preserved alongside the OPDA-overlay signature. Smart-meter exports raise an additional integrity question — they originate from a meter or a data-aggregator and the chain of integrity from meter to attachment is non-trivial. WG decision: whether smart-meter attachments require an additional provenance chain beyond the universal pattern (e.g., meter-signed export, aggregator-signed envelope).
• Retention shape: aligned with the asset-lifetime nature of sustainability information — accreditation certificates retain through their validity period (EPC ten-year cycle; Passivhaus typically not time-limited); retrofit records retain through the working life of the installed measure. WG decision: retention floors per evidence class, and whether smart-meter time series have a shorter window than the certificates they support.
• Consent shape: transaction grant covers onward sharing with the chain and with green-mortgage lenders or insurers. Derivative use (sustainability benchmarking, net-zero policy modelling, retrofit-incentive design) is plausibly within the public-interest basis but should not be assumed without WG sign-off. WG decision: derivative-use basis for sustainability data, including whether anonymised aggregate use needs an explicit consent flag.

2.11 Identity-verification attachments

• What it is: KYC / identity-verification artefacts — government-issued ID images, address-verification documents, source-of-funds evidence, anti-money-laundering check outputs. Cited in the page lead as one of the in-scope attachment families.
• Originating overlays: not a single named overlay; identity-verification attachments flow through several overlays as supporting evidence for issuer KYC (per Data Security framework §Issuer onboarding) and for transaction-party identity verification under the AML regime.
• Typical file formats (production observed): JPEG / PNG for ID images; PDF for proof-of-address documents; PDF or JSON for AML-check outputs from electronic-verification providers.
• Integrity: universal. Where the AML provider signs their output (Onfido, Veriff, HooYu and similar typically do), the provider's signature should be preserved alongside the OPDA-overlay signature.
• Retention shape: the most sensitive of all attachment families; the strictest UK GDPR Article 5(1)(e) discipline applies. The Money Laundering Regulations 2017 set a five-year retention floor for AML records after the end of the business relationship; UK GDPR storage-limitation principles set the ceiling against the same window. WG decision: retention exactly aligned with the MLR 2017 floor, or shorter where the transaction does not engage the AML regime; disposal trigger; and whether identity attachments are held in a separate retention silo from transaction attachments.
• Consent shape: consent for identity verification is granted explicitly at the point of KYC and is purpose-bound (verifying the party's identity for the transaction). Derivative use is highly constrained — biometric and identity data attract special-category-data protections under UK GDPR Article 9 where biometric features are used to uniquely identify a person. WG decision: hard line on derivative use of identity attachments; consent UX for identity data; whether OPDA publishes a model identity-verification consent template.

3. Cross-cutting policy

Five cross-cutting policy themes apply across all eleven attachment families. Each is defined in shape below; specifics are flagged as WG decisions.

3.1 File-format requirements

Shape: OPDA publishes and maintains a per-attachment-type format whitelist — what formats may be carried for each type, including version constraints where they matter (PDF/A-2 versus generic PDF; progressive versus baseline JPEG for high-resolution photographs). Issuers verify against the whitelist before issuance and the verification result is part of the attachment metadata. Holders and verifiers can refuse an attachment whose declared format does not match the whitelist or whose actual bytes do not match the declared format.

Rationale: a maintained whitelist gives downstream consumers (lenders, conveyancers, portals) a predictable surface to implement against; an open-ended any format the issuer chooses approach pushes integration cost onto every consumer and creates a long tail of edge-case parsing bugs that are unfit for a trust framework.

3.2 Signing and integrity (the universal pattern)

Every attachment in every overlay follows the same integrity pattern:

1. Content addressing. The attachment is hashed (a strong cryptographic hash — SHA-256 is the current floor) before issuance. The hash uniquely identifies the byte-exact attachment; any modification produces a different hash.
2. Hash embedded in the VC. The issuing Verifiable Credential carries the hash as a claim, alongside the structured claims the attachment supports. The attachment itself may be embedded (base64 in the VC payload) or referenced by URL; either way, the hash binds the VC to the bytes.
3. VC envelope signature. The issuer signs the VC under the standard PDTF signing pattern (see PDTF governance §2.B Technical Layer for the broader signing context). The signature therefore covers the hash, and so transitively covers the attachment bytes.
4. Upstream signatures preserved. Where the attachment is itself signed by an authoritative third party (HMLR for office copies, FENSA for guarantees, an AML provider for identity-verification output, a surveyor for a survey report, a certifying body for an accreditation certificate), the third-party signature is preserved unchanged inside the attachment bytes. The OPDA-overlay signature attests to the integrity of the attachment as bundled; the third-party signature continues to attest to the underlying authority's claims.
5. Verification. A verifier checks the OPDA-overlay signature against the issuer's DID; verifies the embedded hash against the attachment bytes; and, where present, verifies the upstream third-party signature against its own trust anchor.

The pattern is anchored on the W3C VC Data Model and is consistent with the PDTF Technical Layer (DIDs, VCs, JSON-LD proofs) defined in PDTF governance §2.B. It applies uniformly across all eleven attachment families and is the reason §2 does not repeat it per type.

3.3 Retention

Shape: UK GDPR Article 5(1)(e) — storage limitation — is the primary regulatory anchor: kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed. The Limitation Act 1980 sets contractual and tortious limitation periods (six years for simple contract; twelve years for deeds; longer in latent-defect tort cases) and so provides a ceiling beyond which retention is hard to justify on a litigation-readiness basis. The Land Registration Act 2002 sets parallel registration-related retention considerations for the title-data subset. HMLR retention practice is the upstream reference for register-derived attachments. The Money Laundering Regulations 2017 set a five-year floor for AML records, which applies to the identity-verification family.

The general retention shape: retain only as long as necessary; align with the natural lifetime of the underlying obligation (contractual, statutory, or asset-life); dispose on a defined trigger with an audit trail. Specific durations and triggers are deferred to the C&R WG.

3.4 Consent

Shape: the consent granted by a data subject when they authorise a PDTF transaction covers all attachments necessary to complete the transaction — sharing with the chain (buyer, seller, their solicitors, the lender, the freeholder where applicable), sharing with regulators where compulsion or public-interest bases apply, and sharing with platforms acting as data processors under Article 28 controller-processor agreements. Derivative uses — analytics, comparable-sales training data, AI model training, public research, internal benchmarking — require additional consent under a separate consent flow. Identity-verification attachments are purpose-bound and carry the strictest derivative-use restriction (§2.11).

The transaction-grant / derivative-grant split mirrors UK GDPR's purpose-limitation principle (Article 5(1)(b)) — personal data collected for specified, explicit and legitimate purposes shall not be further processed in a manner that is incompatible with those purposes. New purposes need a new lawful basis (consent, legitimate interests, or one of the other Article 6 / 9 bases as appropriate).

3.5 Cross-border transfer

Shape: attachments containing personal data and flowing to recipients outside the UK engage UK GDPR Chapter V transfer rules. The default transfer mechanisms (UK-adequacy decisions for EEA countries; UK International Data Transfer Agreement or the UK Addendum to EU SCCs for non-adequate jurisdictions; binding corporate rules for multinational member firms; specific derogations under Article 49 where transfer is necessary for the performance of a contract) all apply unchanged. Per-attachment additional disciplines: identity attachments warrant a stricter transfer review (special-category biometric data); building-safety-case attachments require careful handling where international parties are involved post-Building Safety Act 2022.

4. Assurance Level × Attachment integrity

The four PDTF Assurance Levels (AL1–AL4, defined in PDTF governance §5 and recapitulated in ADR 0001's Wave 2 §Maturity-based accreditation) describe the trustworthiness of the issuing party for a structured claim. The same scale can be applied as a floor for attachment-integrity controls — an attachment carried under an AL4 claim should not have weaker integrity than the claim itself.

Proposed shape:

• AL1 (self-asserted): the universal integrity pattern applies (content hash; VC envelope signature). The attachment may be supplied by the data subject themselves; no upstream third-party signature is required. Suitable for marketing photographs, seller-supplied floor plans, seller-uploaded EPC PDFs.
• AL2 (accredited issuer): AL1 plus the issuer is an accredited PDTF participant. The OPDA-overlay signature attests to the issuer's accreditation. Suitable for agent-issued PIQ attachments, conveyancer-issued TA6/TA7 attachments where the conveyancer is collating but not authoring the underlying documents.
• AL3 (accredited issuer with extra controls, or proxy authority): AL2 plus the issuer has either operationalised additional integrity controls (e.g., a documented attachment-provenance log) or is acting as proxy for the authoritative party. Suitable for AML-provider attachments under a regulated relationship; for surveyor-issued RDS attachments where the surveyor's PI insurance and accreditation backstop the integrity claim.
• AL4 (official primary authority): AL3 plus the attachment is issued by the authoritative party themselves and carries that party's signature (preserved alongside the OPDA-overlay signature). Suitable for HMLR office copies, local-authority search responses, certification-body accreditation certificates, FENSA-signed guarantees, Environment-Agency-signed flood statements.

5. Disposal and revocation

Attachments do not live forever. The GARP disposition principle and UK GDPR's storage-limitation principle both require defined disposal practices. PDTF attachment disposal has four triggering scenarios:

1. Transaction completes normally. Retention clocks start from the completion event; disposal happens at the per-type retention horizon (§3.3).
2. Transaction rescinded or aborts before completion. Attachments retain through any limitation window for claims arising from the aborted transaction, then dispose. Some attachments (PIQ marketing artefacts) may dispose earlier; some (identity-verification under the MLR 2017 five-year floor) retain regardless of completion outcome.
3. Underlying VC revoked. Where the issuing VC is revoked (the issuer discovers an error, the issuer is itself de-accredited), the attachments associated with that VC are flagged in the status list and disposal is triggered for any holder who relied on the revoked VC.
4. Consent withdrawn. Where the data subject withdraws derivative-use consent (§3.4), derivative copies dispose under the consent-withdrawal window; the transaction-grant copies persist for their natural lifetime.

Revocation propagation: when an attachment is flagged for disposal, the disposal signal needs to reach every party who has a derivative copy (firm-held, partner-held, search-index cached, training-corpus included). The default mechanism is the PDTF status list (W3C Status List 2021 or equivalent, per PDTF governance §2.B); derivative-copy holders are expected to honour the disposal signal within a defined notification window.

6. Auditability

Every attachment event — issuance, access, transfer, derivative-copy creation, revocation, disposal — generates an audit-log entry per the Data Security framework's audit-logging discipline (cross-link: /governance/data-security §Policy + checklist + audit profile). Audit entries carry: the attachment hash, the event type, the actor (issuer DID, holder DID, verifier DID, or processor identifier), the timestamp, and the lawful basis or consent reference under which the event occurred.

Audit logs are themselves attachments-like — they retain through the longer of (a) the underlying attachment's retention window and (b) the statutory audit-retention floor for the issuer's regulated activity. Audit logs for identity-verification events retain through the MLR 2017 five-year floor at minimum. Audit-log integrity follows the same universal pattern (§3.2).

Verifier-side audit: a verifier who relies on an attachment to make a decision (a lender approving a mortgage on the strength of an EPC attachment; a conveyancer relying on an office-copy attachment) is expected to record the verification event such that the decision can be reconstructed. This page does not mandate verifier-side audit formats; it cross-references the Data Security framework's audit profile.

7. Governance, roles, and review

Three role groups own this page's content, mirroring the broader PDTF operational-functions structure (PDTF governance §3):

• Technical WG (PDTF governance §3.B) owns the technical anchors: the universal integrity pattern (§3.2), the file-format whitelist machinery (§3.1), the schema hooks that surface attachment metadata in the overlays, and the AL-to-control mapping (§4). The overlays themselves are Technical WG artefacts.
• Compliance & Risk WG (PDTF governance §3.C) owns the retention rules (§3.3), the consent policy (§3.4), the cross-border-transfer policy (§3.5), the disposal windows (§5), and the data-protection impact assessment for attachment handling. Per ADR 0001 Wave 2, the C&R WG's remit explicitly includes UK GDPR Article 5(1)(d) accuracy obligations and the broader retention / consent agenda.
• Domain Data Stewards (per /governance/data-stewardship) are responsible for context-specific attachment guidance: e.g., a leasehold-bounded-context steward maintains the TA7 / LPE1 / FME1 attachment guidance; a search-bounded-context steward maintains the CON29R / LLC1 / CON29DW guidance. Stewards take the Technical-WG and C&R-WG outputs and turn them into domain-specific working guidance that lives close to the practitioners who issue the attachments.

Annual review: the policy is reviewed annually as part of the EC meeting nearest the AGM (per ADR 0001 §Newly resolved during review item 4, which establishes the AGM-adjacent EC meeting as the standing slot for governance reviews). The annual review covers: regulatory change (UK GDPR updates, MLR amendments, new sector-specific retention obligations), schema change (new attachment-bearing overlays added since the previous review), and evidence change (what audit data has accumulated and what it implies for the policy).

Ad-hoc review: the policy may be revised mid-cycle on the trigger of (a) a material UK GDPR or regulator action affecting attachment handling, (b) a new attachment-bearing overlay reaching production, or (c) an incident affecting attachment integrity in the wild. Ad-hoc revisions follow the PDTF change-management SOP (PDTF governance §6).

8. Open questions for WG kick-off

The following questions are tabled for the Technical WG kick-off, with Compliance & Risk WG and Domain Data Stewards in attendance.

1. Whitelist governance. Who maintains the file-format whitelist, what is its change cadence, and how is it versioned? Options span (a) Technical WG owns the whitelist as a versioned artefact under the schemas repository; (b) each overlay owns its own whitelist as part of the overlay schema; (c) the whitelist is published as a separate companion document to this page.
2. Retention anchor preference. Where the Limitation Act ceiling and the asset-lifetime floor diverge (commonly for survey reports, building-safety files, accreditation certificates), which anchor wins? Possible answers: the longer wins (most defensive); the asset-lifetime wins (most aligned with the underlying obligation); a per-type call.
3. Derivative-consent granularity. Single broad opt-in (transaction-incidental derivative use only) versus per-use opt-in (analytics, training, benchmarking, research as separate switches) versus a hybrid (broad opt-in plus a named-exception list for high-risk uses like AI training).
4. Disposal evidence. What does disposal happened evidence look like, given that genuine cryptographic deletion across all derivative copies is hard (training corpora, search caches, partner archives)? Options: a disposal attestation signed by the disposing party; a hash-of-deletion entry in the status list; a third-party-auditable disposal log; or an acknowledgement that disposal is best-effort and the policy honours that limitation.
5. Identity-attachment isolation. Should identity-verification attachments live in a separate retention silo with stricter access controls (different DIDs, different status lists, different verifier-side handling) — and if so, does that break the unified verification flow that holders and verifiers currently rely on?

Related

• Data security framework — signing and integrity requirements draw on the security workstream; audit-logging discipline (§6) cross-references the Data Security audit profile.
• Data quality framework — attachment quality (legibility, completeness, format conformance) is a DQ concern handled by the C&R WG's parallel DQ workstream.
• Accreditation Directory — overlay-attachment capabilities are scored here (per ADR 0004); the AL-to-control mapping (§4) feeds the Directory's capability dimension.
• Overlays — the technical reference for each overlay's structure; the eleven attachment families in §2 map one-to-one onto entries here.
• Data stewardship — Domain Data Stewards take this page's cross-cutting policy and turn it into context-specific working guidance for practitioners.
• ADR 0001 — commissions this work as part of Wave 2 (§Resolved during review item 6).

DAMA KA rubric — Wave 1 alignment

Per ADR 0001 Wave 1, KA-tagged pages follow a consistent rubric: Purpose · Activities · Deliverables · Roles · Metrics · Maturity. Sections below may be filled incrementally by Technical WG (with C&R input on retention + consent) — content authored above already maps to several of these; this scaffold is for the gaps.