Privacy Policy

# F-002 — Privacy Policy (First-Pass Draft) **Status:** Published v1 (2026-05-14, A11-PRIVACY Phase B) — counsel review pending WS-COMP close per master index §10. **Source alignment:** Drafted against the Office of the Australian Information Commissioner (OAIC) *APP Guidelines Chapter 1 — APP 1: Open and transparent management of personal information*. Structural content expectations are treated as the APP 1.3 "clearly expressed and up-to-date APP privacy policy" test, with the content list under APP 1.4(a)–(g) mapped to §§1–10 below. Availability under APP 1.5 / APP 1.6 is covered by §9 + the downstream deployment note. **Target of rewrite:** `src/app/(marketing)/privacy/page.tsx` — currently a 40-line stub with a stale last-updated stamp (`February 27, 2026`). Both the structural-completeness problem (F-002) and the last-updated-drift problem (F-012) are addressed here in one document. **Deployment:** This draft is NOT for deployment. It is a pre-counsel artefact assembled at workstream **WS-EXT-C4** as input to the counsel spot-check at **WS-EXT-C5**. After counsel markup, workstream **WS-EXT-C6** rewrites `privacy/page.tsx` with the counsel-selected content and lands a public footer link from `(public)/layout.tsx` (F-011 remediation bundled per master plan §6 dependencies). **Context constraints observed:** - Controller identity (Q4) — v1 carries pre-incorporation framing (preserved literal prose) per Decision 7. Resolves at v2-republish when WS-EXT-C3 closes (T1 trigger). - Overseas-disclosure — resolved at v1 (Sydney sole-production text inlined in §5). - Controller-vs-processor framing — resolved at v1 (Alternative A selected per Decision 5). Alternative B preserved in Phase C acceptance doc for counsel-batch consumption. - Record-keeping integrity claims are deliberately conservative per F-015 counsel-framing constraint. No "tamper-proof", "immutable", "cryptographically verified", or similar positive-integrity language. §6 uses "reasonable steps" phrasing aligned with APP 11.1 and post-WS-EXT-A2 Layer-2a (append-only trigger) + Layer-3 (PII minimisation) posture. Hash-chain is explicitly absent. - Retention periods (§8) are stated declaratively with per-category values resolved (2026-04-24 retention research); F-005 remains the companion internal runbook (WS-EXT-C8), not named in §8 body after the retention update. Enforcement is runbook-based with progressive code-enforcement rollout; §8 also carries a legal-hold pause clause. Q3 open question to counsel on wording still stands. --- ## 2. APP 1.3 structural-elements checklist The OAIC's APP Guidelines Chapter 1 lists the content expected of an "APP privacy policy" under APP 1.4(a)–(g). F-002's suggested-fix-approach (session-f-compliance-operational-findings.md lines 248–258) expands this to ten working elements Duck uses as the self-check rubric for this draft. The table maps each element to the section in this document that discharges it and flags placeholder dependencies. | # | Element | OAIC Chapter 1 reference | Present? | Section in draft | |---|---------|--------------------------|----------|------------------| | 1 | Controller identity (legal entity, ABN, registered address, contact email) | APP 1.3 clarity + APP 1.4 by implication (who the "we" is); OAIC guidance that policies must identify the entity | RESOLVED — pre-incorporation framing in v1 per Decision 7 | §1 | | 2 | APP entity status (controller or processor) | APP 1.3 "clearly expressed"; OAIC "open and transparent management" test | RESOLVED — Alternative A (controller) selected per Decision 5 | §1 + Appendix A | | 3 | Categories of personal information collected and held | APP 1.4(a) "the kinds of personal information that the entity collects and holds" | YES — enumerated | §2 | | 4 | Primary and secondary purposes of collection, holding, use, disclosure | APP 1.4(c) "the purposes for which the entity collects, holds, uses and discloses personal information" | YES | §3 | | 5 | How personal information is collected and held | APP 1.4(b) "how the entity collects and holds personal information" | YES | §2 + §5 | | 6 | Disclosures (recipients + purpose) | APP 1.4(c) disclosure limb; OAIC guidance that "purposes" includes who information is disclosed to and why | YES | §4 | | 7 | Security measures — reasonable steps (APP 11) | APP 11.1 reasonable-steps obligation; APP 1.3 clarity | YES — conservative framing per F-015 constraint; cross-references WS-EXT-A2 closure of F-015/F-016/F-017 where landed | §6 | | 8 | Access (APP 12) and correction (APP 13) mechanism | APP 1.4(d) "how an individual may access the personal information about the individual that is held by the entity and seek the correction of such information" | PARTIAL — manual runbook at EXT per WS-EXT-C8; structural code path arrives post-MVP | §7 | | 9 | Retention and destruction periods per data category | APP 11.2 destruction or de-identification; APP 1.4(b) "holds" limb; OAIC practical guidance | PARTIAL pending Q3 counsel resolution — per-category values resolved (2026-04-24 retention research); F-005 remains companion internal runbook; runbook-based enforcement with progressive code-enforcement rollout; legal-hold pause clause included | §8 | | 10 | Overseas disclosure — whether it occurs and the countries if practicable | APP 1.4(f) + APP 1.4(g) | RESOLVED — post-WS-EXT-C1 Sydney sole-production text inlined in §5 | §5 | | — | Complaints mechanism | APP 1.4(e) "how the individual may complain about a breach of the Australian Privacy Principles, or a registered APP code (if any) that binds the entity, and how the entity will deal with such a complaint" | YES | §9 | | — | Up-to-date + clearly expressed | APP 1.3 | YES — last-updated convention + changelog discipline embedded | §10 + Appendix C | | — | Availability free of charge + in appropriate form | APP 1.5 | YES — published at `/privacy`, linked from both `(marketing)/layout.tsx` (current) and `(public)/layout.tsx` (added at WS-EXT-C6 per F-011) | §10 + Downstream deployment note | | — | Availability in requested form on request | APP 1.6 | YES — fall-back mechanism noted | §9 + §10 | **Checklist self-verification.** All ten numbered rows above map to at least one headed section of §3. Rows flagged PARTIAL carry explicit placeholder tokens; see §4 tokens table. **Per-row self-verification notes (for counsel review at WS-EXT-C5):** - Row 1 (Controller identity) — RESOLVED at A11-PRIVACY Phase B publication. §1 carries pre-incorporation framing as preserved literal prose per Decision 7. Resolves at v2-republish when WS-EXT-C3 closes (T1 trigger). - Row 2 (APP entity status) — RESOLVED at A11-PRIVACY Phase B publication. Alternative A (Duck-as-controller) selected per Decision 5. Alternative B preserved in Phase C acceptance doc for counsel-batch consumption. - Row 3 (Categories) — YES. §2 table enumerates nine categories covering the Session A / Session F appendix of PII in the baseline schema. Medical (sensitive) is flagged inline with APP handling uplift. - Row 4 (Purposes) — YES. §3 distinguishes primary and secondary per APP 6 framing. - Row 5 (How collected and held) — YES. §2 intro describes collection channels (worker, administrator, device); §5 describes hold location. - Row 6 (Disclosures) — YES. §4 recipient table lists every tenant-external recipient with purpose; RLS cross-reference to §6 confirms tenant boundary for the "customer" row. - Row 7 (Security — reasonable steps) — YES with F-015 conservative framing. §6 explicitly declines positive integrity-proof claims; Q2 re-opens this if counsel has a tighter preferred wording. - Row 8 (Access and correction mechanism) — PARTIAL. §7 describes the manual runbook posture; roadmap for structural tooling is referenced but not committed by date. - Row 9 (Retention) — PARTIAL pending Q3 counsel resolution. §8 uses APP 11.2 primary framing with per-category retention posture (bulleted list, values resolved per 2026-04-24 retention research: induction + sign-on/off = 7 years; credentials = 3 months with active-induction-linkage carve-out; accounts = 90 days + 7 years billing per Corporations Act s 286 / ITAA s 262A; marketing = 12 months + indefinite opt-out per Spam Act 2003). Includes legal-hold pause clause; enforcement is runbook-based with progressive code-enforcement rollout. Counsel may reframe to softer language per Q3. - Row 10 (Overseas disclosure) — RESOLVED at A11-PRIVACY Phase B publication. §5 carries the post-WS-EXT-C1 Sydney sole-production text inlined. - Row 11 (Complaints) — YES. §9 includes complaint-to-Duck mechanism + OAIC referral per APP 1.4(e). - Row 12 (Up-to-date + clearly expressed) — YES. §10 + Appendix C embed changelog discipline; "last updated" set at PR merge time. - Row 13 (Availability free of charge) — YES. §10 + downstream deployment note confirm `/privacy` publication and dual-footer placement (marketing + public). - Row 14 (Availability in requested form) — YES. §9 closing paragraph covers APP 1.6 alternative-format fallback. --- ## 3. Policy body draft > **Intended rendering context:** plain-English, worker-readable prose suitable for a construction-site audience. Technical terms (RLS, JSONB, IP address, etc.) are explained inline where they appear. Target body word count 1200–2000 words across §§1–10. Current draft is within target. ### 1. Who we are > Duck Inductions (operated by [pre-incorporation; entity to be confirmed at WS-EXT-C3]; ABN: pending issuance; registered office: pending issuance) (referred to in this policy as "Duck Inductions", "we", "us", or "our") operates the Duck Inductions platform. > > When you use our platform — whether you are a worker completing an induction or signing on to a site, a site administrator managing inductions, or a subcontracting company associated with a worker — we are the APP entity responsible under the *Privacy Act 1988* (Cth) for the personal information we collect through the platform. > > We act on the basis of our own purposes as described in §3 as well as to fulfil the agreements we have with our customers (the site operators). > > Our customers may have their own privacy notices that apply to their own handling of your information outside our platform; this policy describes our handling. > > Questions about what information is held about you, or how to access or correct it, can be directed to us at `[PRIVACY_CONTACT_EMAIL_PLACEHOLDER]`, or to the site administrator who invited you, who we will cooperate with in responding. We are an APP entity under the *Privacy Act 1988* (Cth) and are bound by the Australian Privacy Principles (APPs). This policy explains how we manage personal information under APP 1. ### 2. What personal information we collect We collect personal information directly from workers (via induction, sign-on, sign-off), from site administrators (our customers who invite workers), and automatically from devices accessing the platform. | Category | What it includes | |---|---| | Identity | Full name; preferred name; in some cases date of birth. | | Contact | Mobile number; email address. | | Emergency contact | Name, mobile, relationship (e.g. "spouse") of the worker's nominated contact. Third-party PII — see Appendix B. | | Employment & credentials | Employer/subcontractor for a given site; WHS credentials (number, issue date, expiry date, issuing body); uploaded credential images. | | Signature | Captured signature image for induction and SWMS acknowledgement. | | Sensitive — medical | Allergies or medical info if an operator's custom form requests and the worker provides it. Sensitive information under the *Privacy Act 1988*; stricter handling (§6). | | Sign-on / sign-off | Date, time, site; device geolocation where the flow requests it. | | Induction responses | Answers (including free text) to the site's induction form. | | Technical | IP address; truncated user-agent; QR and pass tokens (not independently identifying). | Where an operator's custom form collects categories beyond those listed, the operator's own privacy notices apply to that collection; we act in relation to that information as described in §1 (see Appendix A). ### 3. Why we collect it **Primary purposes:** - Operate the induction, sign-on, sign-off flows — e.g. verify a worker has completed the required induction before signing on. - Maintain a WHS record of who was on site, when, holding which credentials, under which induction. - Provide site administrators with dashboards, reports, and exports to meet their WHS obligations. - Contact workers with induction-completion confirmations, credential-expiry reminders, and operational messages. - Contact site administrators about their account, subscription, and platform usage. **Secondary purposes** (permitted under APP 6): - Platform improvement — aggregated usage-pattern analysis; de-identified or aggregated data preferred where practicable. - Legal, regulatory, contractual obligations — lawful requests from a WHS regulator, a court, or a Duck customer whose contract specifies audit support. - Security-incident and suspected-misuse investigation. We do **not** use personal information for marketing to workers. Marketing (if any) goes only to site administrators or operator contacts who have opted in. ### 4. Who we share it with We share your information with: - **Site operators and administrators** — the people running induction, sign-on, and site safety at the sites you are inducted for. - **Subcontracting companies** — the company you are working under on site, if you are engaged by a subcontractor. - **Australian WHS regulators** — when required by law (for example, SafeWork NSW under the WHS Act 2011). - **Sub-processors** — the third-party service providers we use to operate the platform. The current sub-processor list (function, jurisdiction, contract basis) follows: | Sub-processor | Function | Jurisdiction | |---|---|---| | Apple Inc. | Wallet pass distribution | US | | Resend Inc. | Transactional email | US | | Stripe Inc. | Subscription billing + payment processing | US (control plane); global processing per Stripe data-residency posture | | Supabase Inc. | Database + auth | Sydney, Australia (ap-southeast-2) | | Twilio Inc. (au1 edge) | SMS OTP + notifications | Sydney edge (au1); control plane US | | Vercel Inc. | Hosting + CDN edges | Global CDN; control plane US | We do not sell your information and we do not use it for marketing. ### 5. How we store it and where Your personal information is stored on Supabase infrastructure in Sydney, Australia (AWS ap-southeast-2). We do not disclose your personal information to overseas recipients for the purpose of running the platform itself. Certain secondary recipients listed in §4 (Stripe, Resend, Apple, Vercel, Twilio) are global services whose handling of the limited information we share with them may involve infrastructure outside Australia; we disclose them explicitly so you can make an informed decision. Observability sub-processors (Sentry, PostHog) are not active at pilot. If they are re-introduced post-launch, this section and §4 will be updated before that deployment ships (per the CLAUDE.md Compliance Drift Guard rule 4). Access inside Supabase is controlled by our Row-Level Security (RLS) model (§6). ### 6. How we keep it secure We take reasonable steps (APP 11.1) to protect personal information from misuse, interference, loss, and unauthorised access, modification, or disclosure. | Control | What we do | |---|---| | Row-Level Security (RLS) | Database enforces access at the row level. A worker's record is visible only to authorised administrators of the sites they inducted at. Cross-tenant access is blocked at the database, not just the application. | | Authentication | Supabase Auth password authentication with a strength floor on signup and reset. Sessions managed via secure HTTP-only cookies. | | Rate limiting | Public endpoints (induction, sign-on, sign-off, pass) rate-limited by token + IP address. | | Transport encryption | HTTPS (TLS) on all traffic. | | At-rest encryption | Database and object storage encrypted at rest by the underlying provider. | | Audit logging | Activity affecting personal information recorded in an append-only audit log. RLS permits INSERT by the application role; UPDATE and DELETE blocked under normal operation. | | PII minimisation in logs | Log metadata does not duplicate identifier fields (worker name, mobile). IP and user-agent values hashed and truncated respectively. | | Administrative access | Production access limited to authorised personnel under least privilege. Administrative actions logged. | **What we do not claim.** We do not claim our records are cryptographically tamper-proof or that we can provide a mathematical proof of record integrity. "Append-only" means the database rejects UPDATE and DELETE against the log table under normal operation. Positive cryptographic integrity proofs (hash-chain or similar) are on our roadmap, not in place today. Customers whose use case requires such a proof should contact us for current posture detail. ### 7. How you can access or correct your information Under the APPs you can request access (APP 12) and correction (APP 13) of the personal information we hold about you. **To make a request:** email `[PRIVACY_CONTACT_EMAIL_PLACEHOLDER]` or write to the address in §1. **How we respond.** Within a reasonable time (typically 30 days), we acknowledge, verify your identity proportionately to the sensitivity of the information, and then either (1) provide the information, (2) make the correction, or (3) explain in writing why we cannot and how to complain about that decision. **Who can ask.** Workers, via the site administrator who invited them or directly to Duck. Emergency contacts (see Appendix B). **Operational posture.** At launch, requests go via a manual operational runbook. The runbook is internal-facing; access requests follow `docs/source/runbook-dsar-manual.md` (APP 12) and correction requests follow `docs/source/runbook-correction-manual.md` (APP 13). A structured admin-initiated data-subject-export flow and a worker-facing correction flow are on our roadmap (planned at WS-PUB-05); we will update this section when they ship. ### 8. How long we keep your information We retain personal information only for as long as we need it for the purposes in §3, or as required by Australian law. APP 11.2 requires us to take reasonable steps to destroy or de-identify personal information once it is no longer needed. Current retention posture per category: - Induction records (completion evidence, SWMS acknowledgement, signature): retained while the worker has active induction status at any site operator using Duck, plus 7 years after last active status — basis: supports customer WHS compliance obligations (F-002 §3 primary purpose), aligns with Fair Work s 535 floor for worker-employees, matches industry convergence (Safety Champion publishes 7 years; sector norm). - Sign-on/sign-off records: retained while the site is active on Duck, plus 7 years after site closure — basis: evidentiary pair with induction records (see above). - Credential records (licences, tickets, qualifications): retained while worker has active induction; credentials supporting expired status are deleted within 3 months unless linked to an induction record still within its retention window. - Account records (builder administrators, subcontractor administrators): retained while account is active, plus 90 days after account closure (for standard account data); billing and contractual records retained for 7 years per Corporations Act s 286 / ITAA s 262A. - Technical logs and audit_log records: retained per the integrity policy in §6 — append-only under normal operation. - Marketing or communication records: retained while the communication relationship is active, plus 12 months after last contact (for contact records); opt-out markers retained indefinitely to comply with Spam Act 2003. If a regulatory investigation or litigation is known to affect specific records, retention for those records pauses until the matter is resolved. Retention enforcement is currently handled through operational runbooks. We are progressively adding code-enforced retention and will update this section as those controls ship. We take reasonable steps to destroy or de-identify personal information once no longer needed, consistent with APP 11.2. Full retention detail is available on request. ### 9. How to complain If you believe we have breached the APPs or any registered APP code binding us, you can complain. **How.** Email `[PRIVACY_CONTACT_EMAIL_PLACEHOLDER]` or write to the address in §1. Please describe what happened, when, what personal information was involved, and the outcome you are seeking. **How we handle your complaint.** We acknowledge receipt within 7 days, investigate, and provide a written response within 30 days — or explain any delay with an updated timeframe. **If you are not satisfied with our response**, you may refer the complaint to the Office of the Australian Information Commissioner (OAIC): | Channel | Detail | |---|---| | Website | `https://www.oaic.gov.au` | | Phone (within Australia) | `1300 363 992` | | Post | Office of the Australian Information Commissioner, GPO Box 5288, Sydney NSW 2001 | **Alternative formats.** You can request this privacy policy in an alternative form (printable PDF, screen-reader-friendly version, etc.) by contacting us at the address above. This discharges APP 1.6. ### 10. Updates to this policy We update this policy when there is (a) a material change to how we collect, hold, use, or disclose personal information, (b) a change to our regulatory posture, or (c) an underlying platform architecture change that affects §§1–9. On every update we change the "last updated" date at the top of the published policy and — where the change is material — add a row to the changelog in Appendix C. **"Last updated" convention (F-012 remediation).** The "last updated" date is set automatically to the date the change is deployed. The content source-of-truth lives in this repository; a change to that source in a pull request becomes "last updated" on merge. The previous policy carried a manually-maintained stamp that had drifted across releases — this convention prevents that drift. **Availability (APP 1.5 / APP 1.6).** The policy is available free of charge at `/privacy`, linked from the marketing footer and — after WS-EXT-C6 — from the worker-facing public footer (F-011). Alternative formats are available on request (see §9). --- ## 4. Placeholder tokens | Token | Where it appears | Resolution source | Workstream | Slip risk | |---|---|---|---|---| | `ENTITY_PLACEHOLDER (preserved literal in v1)` | §1 — legal entity name, ABN, registered address | Pre-incorporation framing applied in v1 (`[pre-incorporation; entity to be confirmed at WS-EXT-C3]; ABN: pending issuance; registered office: pending issuance`); resolves at v2-republish post-entity formation | WS-EXT-C3 — T1 trigger | **v1 carries pre-incorporation framing.** | | `OVERSEAS_DISCLOSURE_PLACEHOLDER (RESOLVED)` | §5 — overseas-storage statement | **RESOLVED at A11-PRIVACY Phase B publication** — post-WS-EXT-C1 Sydney sole-production text inlined. | **WS-EXT-C1 closed 2026-04-29** | Done. | | `CONTROLLER_PROCESSOR_FRAMING (RESOLVED)` | §1 primary paragraph | **RESOLVED at A11-PRIVACY Phase B publication** — Alternative A (Duck-as-controller) selected per Decision 5; Alternative B preserved in Phase C acceptance doc for counsel-batch consumption. | A11-PRIVACY Decision 5 | Done. | | `ABN_PLACEHOLDER, ADDRESS_PLACEHOLDER (preserved literal in v1)` | §1 only (no longer in §7/§9) | Pre-incorporation framing applied in v1; resolve together with ENTITY at v2-republish | WS-EXT-C3 — T1 trigger | **v1 carries pre-incorporation framing.** | | `PRIVACY_CONTACT_EMAIL_PLACEHOLDER (preserved literal in v1)` | §1, §7, §9 | **Preserved literal token in v1** per amended Decision 7 (2026-05-14 operator decision reverted the Phase 0 default `privacy@duckinductions.com.au`); resolves at v2-republish trigger | **T2 trigger — brand-domain finalization** | Operator decision at brand-domain batch close. | **Token-resolution procedure (WS-EXT-C6 deployment):** 1. Grep the file for each token in the left column of the table above. 2. Replace each with the resolved value produced by the workstream listed in the "Workstream" column. 3. Verify no unresolved tokens remain before publishing. 4. Run the CI deploy gate: `grep -n "_PLACEHOLDER" src/app/(marketing)/privacy/page.tsx` must return no matches. **v1 publication status per token:** - `ENTITY_PLACEHOLDER` / `ABN_PLACEHOLDER` / `ADDRESS_PLACEHOLDER` — v1 carries pre-incorporation framing as preserved literal prose. Resolves at v2-republish when WS-EXT-C3 closes (T1 trigger). - `OVERSEAS_DISCLOSURE_PLACEHOLDER` — resolved at v1 (Sydney sole-production text inlined in §5). - `CONTROLLER_PROCESSOR_FRAMING` — resolved at v1 (Alternative A selected per Decision 5). - `PRIVACY_CONTACT_EMAIL_PLACEHOLDER` — preserved literal token in v1 per Decision 7 amendment (2026-05-14). Resolves at v2-republish when brand-domain is finalized (T2 trigger). **Suggested `grep` check for WS-EXT-C6:** add a lint-level test `test/privacy-policy-placeholders-resolved.test.mjs` that reads the deployed page source and fails if any of the tokens above are present in the rendered output. This becomes a required CI check for merges that touch `src/app/(marketing)/privacy/page.tsx`. --- ## 5. Open questions flagged to counsel (WS-EXT-C5 briefing packet) The following three open questions are included verbatim in the WS-EXT-C5 briefing packet per master plan §8.2. They are copy-paste-ready. **Summary table — decisions required:** | # | Topic | Decision type | Source | Affects | |---|---|---|---|---| | Q1 | Controller vs processor framing | Select Alternative A or Alternative B from Appendix A | Session F compliance handoff open question; shared with F-001 | §1 + §4 + §7 + Appendix A | | Q2 | F-015 defensible-claim boundary on record-keeping integrity | Approve / revise §6 "what we do not claim" wording | Master plan §8.2 item 5 (verbatim) | §6 + marketing copy audit WS-EXT-C2 | | Q3 | APP 11.2 retention — declarative periods with manual enforcement | Approve declarative periods or require softer wording | F-005 retention policy draft (WS-EXT-C8) | §8 | --- ### Q1 — Controller vs processor framing **Context for counsel.** Duck Inductions is a multi-tenant SaaS platform for Australian construction-site operators and subcontractors. Customers (site operators) invite workers to complete inductions and sign on/off at their sites. Workers typically do not have a direct contractual relationship with Duck. Two alternative §1 paragraphs are drafted in Appendix A of this document. **The question:** > For the purpose of the *Privacy Act 1988* and the APPs, is Duck the APP entity that is responsible for the personal information collected through the induction, sign-on/off, and SWMS-acknowledgement flows — acting as a controller in substance — or is Duck a processor operating on behalf of each customer as the APP entity? > > We have drafted two alternative §1 paragraphs (Appendix A of the F-002 draft) — one per framing. Which should we publish? If the answer depends on facts (e.g., which party determines the form content, whether the customer has a written contract in place, the type of customer), please describe the facts we should document per customer relationship so we can apply the rule consistently. > > This question is shared with F-001 (collection notice) — the resolution applies to both documents. **Why this matters for Duck's operating model.** - APP 12/13 rights run against the named APP entity. If Duck is the APP entity, worker requests come to Duck and Duck must respond; if the customer is the APP entity, Duck supports the customer who responds. - APP 1.4(e) complaints mechanism likewise. - Some customers may request a formal framing in their pilot agreements — counsel's answer shapes the WS-EXT-C7 agreement template. **What we have drafted in anticipation of either answer.** Both paragraphs are in Appendix A below. The F-001 collection notice mirrors the selected framing. --- ### Q2 — F-015 defensible-claim boundary on record-keeping integrity **Context for counsel.** C2 remediation ships two of three defensive layers at EXT (append-only trigger + PII minimisation in audit log metadata). The third layer (hash-chain positive integrity proof) is roadmap-only; we have deliberately not drafted marketing copy that relies on it. §6 of this policy uses "reasonable steps" language only and explicitly declines cryptographic-proof claims. **The question (verbatim from master plan §8.2 item 5):** > We have shipped append-only audit-log trigger + PII minimisation; hash-chain positive integrity proof is on roadmap. What can we defensibly claim in marketing today about record-keeping integrity? **Why this matters.** The F-015 marketing copy audit (WS-EXT-C2) needs the same defensible boundary. Any wording counsel approves here will propagate to the marketing site copy. Overclaiming record-keeping integrity in a privacy policy is a textbook finding a WHS-regulator or OAIC investigator picks up first. **How §6 handles it today.** §6 describes the append-only trigger mechanically ("database rejects UPDATE and DELETE under normal operation") without claiming tamper-proof-ness. It says roadmap for hash-chain verbatim. Counsel may mark up §6 tightly — we have drafted the base to be comfortable under markup. --- ### Q3 — APP 11.2 retention — declarative periods with manual enforcement **Context for counsel.** F-005 retention policy draft (WS-EXT-C8) is the companion artefact listing retention periods per data category. Periods are declarative: 7 years for WHS-evidentiary records (induction, attendance, credentials), shorter for operational categories (email outbox, technical telemetry). For the first 3 post-launch months, enforcement is manual — operator reviews records against the schedule, effects destruction or de-identification by hand. Structural tooling (schema-level `retention_until` columns + scheduled cleanup job) ships in a follow-up workstream. **The question:** > Does counsel approve Duck stating declarative retention periods in the published privacy policy (F-002 §8) when enforcement is manual-only during the pilot window? > > If not, should §8 be redrafted in softer language (e.g., "we retain for no longer than required" with no explicit periods) until the structural mechanism is in place? **Why this matters.** Declarative periods are stronger customer signal and align with APP 1.3 "clearly expressed" — but we cannot enforce them atomically yet. Soft language is weaker signal but removes a defensible-claim gap if enforcement drifts in the launch window. Either answer is engineerable; counsel picks. --- ## 6. Appendix A — §1 controller framing (selected at A11-PRIVACY Phase B) The Alternative A (Duck-as-controller) paragraph is now inlined as the §1 §1 opening of this policy (above). Alternative B (Duck-as-processor) is preserved verbatim in the Phase C acceptance doc (`docs/specs/ws-comp/acceptance/A11-PRIVACY-acceptance-<date>.md`) for counsel-batch consumption at WS-COMP close. --- ## 7. Appendix B — Emergency-contact notice (F-010) **Background.** F-010 identified that the induction form captures the name, phone number, and relationship of a worker's emergency contact — a third party who has not interacted with Duck and who is not directly informed of the collection. **APP posture.** APP 3.2 permits solicited collection from the worker about a third party where reasonably necessary for the entity's functions. On-site emergency-contact collection is an accepted legitimate-safety purpose in Australian WHS practice. The gap F-010 flagged is narrow and tied to APP 12 / APP 13 rights for the third party once they become aware of the collection. **Notice text** — suggested placement inline after §2's emergency-contact row, or as an expandable sub-section of §2: > When you complete an induction you may be asked to provide the name, phone number, and relationship of an emergency contact — for example, a spouse, a parent, or a trusted friend. > > This is personal information about a third party that you are giving us, and we use it only for the purpose of reaching that person in an emergency during your attendance at a site. > > We do not contact this person for any other purpose. > > If your emergency contact becomes aware that we hold their information and wishes to access or correct it, or to have their information removed from your record, they can contact us using the details in §9 / §1. > > We will verify their identity proportionately and take reasonable steps to respond. > > Please consider letting the person you nominate know that you have provided their details, so they can make an informed decision about the nomination. **Post-launch supporting work** (for reference, not policy content): - Once F-003/F-004 tooling ships, a partial index on `emergency_contact_phone` will support reverse lookup when an emergency contact submits an APP 12 request. - Until then the reverse lookup is manual — operator runs SQL against the `workers` table, keyed on the phone number provided by the requester. - The DSAR manual runbook (WS-EXT-C8) includes the reverse-lookup SQL query as a canonical step. **Interaction with F-001 collection notice.** The F-001 collection notice explicitly mentions the emergency-contact field and points workers at this policy. Together F-001 + this appendix discharge Duck's structural obligation to workers re: the third-party implications. The third party themselves remain un-notified at collection time — the APP 3.2 framing is what permits this; F-010 body accepts the gap as narrow. --- ## 8. Appendix C — Changelog The changelog records every material change to this policy. v1 is empty because v1 is the pre-counsel draft and has not been published. WS-EXT-C6 populates the first row when the counsel-reviewed version goes live at `/privacy`. | Version | Date | Change | PR | |---|---|---|---| | v1 | [DRAFT · pre-counsel] | Initial draft against OAIC APP 1.3 + APP 1.4 (APP 1.4(a)–(g) content list mapped to §§1–10; APP 1.5 / APP 1.6 availability covered by §9 + deployment note). Pre-counsel artefact for WS-EXT-C5 briefing packet. | — | | v2 | [pending] | First published version (post-counsel markup; ENTITY_PLACEHOLDER resolved; controller-vs-processor framing selected; overseas-disclosure paragraph set to either pre- or post-WS-EXT-C1 variant; F-011 footer link from `(public)/layout.tsx` added in same PR). | [WS-EXT-C6 PR reference] | **Changelog discipline rule.** Every PR that modifies `src/app/(marketing)/privacy/page.tsx` must also modify this changelog (or the equivalent section in the deployed page) with a new row. The "last updated" date in the deployed page is the PR merge date. CI can enforce the `privacy/page.tsx` ↔ changelog pairing with a simple "both files or neither" check if operator wants the guardrail. **What counts as a "material change" triggering a changelog row:** - Addition or removal of a data category in §2. - Change to the purposes in §3 (primary or secondary). - Addition or removal of a recipient in §4. - Change to storage location (§5) — e.g. migrating cloud regions, adding a new overseas processor. - Substantive change to security posture described in §6 — e.g. shipping hash-chain integrity proof would materially strengthen the §6 claim and warrant a changelog row. - Change to the access/correction mechanism (§7) — e.g. shipping the structured DSAR export. - Change to retention periods (§8) or the enforcement mechanism. - Change to the complaints mechanism (§9) — e.g. changing the privacy contact email. **What does NOT count as a material change (typo fixes, link re-styling):** - Pure typography or formatting fixes. - Non-substantive rewording (e.g. splitting a sentence). - Link updates where the destination is equivalent. - These can ship without a changelog row, but the "last updated" date still advances because the underlying file changed. --- ## 9. Downstream deployment note Workstream **WS-EXT-C6** is the deployment-side counterpart to WS-EXT-C4 (this draft) and WS-EXT-C5 (counsel spot-check). **WS-EXT-C6 tasks:** 1. **Rewrite `src/app/(marketing)/privacy/page.tsx`.** - Replace the stub (lines 1–40) with the counsel-reviewed content of §§1–10 of this draft. - Resolve all tokens per §4 (ENTITY_PLACEHOLDER, OVERSEAS_DISCLOSURE_PLACEHOLDER, CONTROLLER_PROCESSOR_FRAMING, ABN_PLACEHOLDER, ADDRESS_PLACEHOLDER, PRIVACY_CONTACT_EMAIL_PLACEHOLDER). - Alternative A controller framing is now the §1 opening (locked at A11-PRIVACY Phase B publication). - Select pre- or post-migration overseas-disclosure paragraph for §5. - Insert Appendix B content inline in §2 per emergency-contact-notice placement. 2. **Remove the manually-maintained "Last updated" literal.** - Replace with a build-time value — either the merge-commit date injected at build, or a small CI workflow that updates the page prior to commit. - This prevents the date from drifting from reality. - F-012 closure depends on this. 3. **Add the `/privacy` and `/terms` links to `src/app/(public)/layout.tsx` footer.** - F-011 closure. - Master plan §6 dependencies bundle F-011 with F-002 deployment. 4. **Verify.** - T2 verification: `npm run lint && npm run typecheck && npm test`. - T3 verification: dev server up, navigate to `/privacy`; verify only the 4 canonical preserved tokens (ENTITY/ABN/ADDRESS/PRIVACY_CONTACT_EMAIL) appear as literal text, and the §4 sub-processor table is rendered from the live registry snapshot. - Navigate to `/induct/<token>`, verify the footer link to `/privacy` is visible. - Follow the link and land on the rewritten policy page. - Playwright smoke: one test that visits `/privacy` and asserts §1 entity-name text, §9 OAIC referral text, and presence of `/privacy` link in `(public)/layout.tsx` footer. 5. **Record decisions.** - Capture in a brief deployment note (commit message or linked doc): - which controller-vs-processor paragraph was selected; - the resolved entity + ABN + registered address; - the pre- or post-WS-EXT-C1 overseas-disclosure paragraph selected; - any counsel-approved wording that differs from this draft. - Add the first populated row to Appendix C changelog. **Pipeline summary:** | Stage | Workstream | Produces | |---|---|---| | Draft against OAIC APP Guidelines | WS-INT-03 Task D (this draft) | `docs/source/compliance/f-002-privacy-policy-draft.md` — pre-counsel artefact | | Sydney migration | WS-EXT-C1 | Resolves OVERSEAS_DISCLOSURE_PLACEHOLDER selection | | Entity + ABN resolution | WS-EXT-C3 | Resolves ENTITY_PLACEHOLDER, ABN_PLACEHOLDER, ADDRESS_PLACEHOLDER, PRIVACY_CONTACT_EMAIL_PLACEHOLDER | | Counsel spot-check | WS-EXT-C5 | Selects Alternative A/B, marks up §6 per Q2, approves/revises §8 per Q3, general line-edits | | Deployment | WS-EXT-C6 | Rewrites `privacy/page.tsx`, adds `(public)/layout.tsx` footer link, first changelog row, Playwright smoke | The pre-counsel draft in this document is the input; the deployed policy at `/privacy` is the output. Between the two are WS-EXT-C3 (entity), WS-EXT-C1 (Sydney migration), WS-EXT-C5 (counsel markups), and WS-EXT-C6 (the deployment itself). None of those workstreams are executed here — WS-INT-03 produces the draft only. --- ## 10. Cross-reference map — F-002 to other audit findings This draft intentionally interlocks with several other Session F findings and several Session A / Session C cross-references. The table below captures these for counsel's benefit so they can see the remediation surface area during the WS-EXT-C5 spot-check. | Other finding | Relationship to this draft | Where handled | |---|---|---| | F-001 — Collection notice absent from induction form | Shared Q1 (controller-vs-processor framing) | F-001 draft (sibling artefact); §1 + Appendix A of this draft | | F-010 — Emergency contact third-party PII | F-002 §2 flags the third-party PII; Appendix B contains detail notice | §2 + Appendix B | | F-011 — Worker-facing pages lack privacy-policy link | Bundled with WS-EXT-C6 deployment | Downstream deployment note (§9 above — item 3) | | F-012 — Last-updated stamp stale | "Last updated" convention change bundled with F-002 deployment | §10 body + Appendix C | | F-013 — E-023 counsel-review gate not captured | Overseas-disclosure paragraph (§5) is the customer-facing expression of E-023 closure | §5 + Token table | | F-014 — Overseas-disclosure transparency gap | Pre-WS-EXT-C1 variant of §5 discloses Tokyo storage explicitly | §5 pre-migration variant | | F-015 — Marketing overclaim re: record-keeping integrity | §6 conservative posture; Q2 to counsel | §6 + Q2 | | F-005 — Retention policy absent | §8 is the public retention expression with per-category values (2026-04-24 retention research); operator-facing retention policy at `docs/source/retention-policy.md` (shipped WS-EXT-C8); F-005 is also the label for the internal monthly-cadence runbook (not committed to repo per `adr-retention-framework.md` §6.3); Q3 to counsel | §8 + Q3 | | F-003 — DSAR tooling absent | §7 describes manual runbook posture; manual workflow at `docs/source/runbook-dsar-manual.md` (shipped WS-EXT-C8); structural tooling at WS-PUB-05 | §7 | | F-004 — Correction tooling absent | §7 describes manual runbook posture; manual workflow at `docs/source/runbook-correction-manual.md` (shipped WS-EXT-C8); structural tooling at WS-PUB-05 | §7 | | F-008 — Sensitive-information (medical) handling | §2 flags medical as sensitive; §6 flags stricter handling | §2 + §6 | | C2 closure (audit log three-layer) | §6 "append-only" and "PII minimisation in logs" rows describe Layer-2a + Layer-3 posture; does not claim Layer-2b (hash-chain) | §6 + Q2 | --- ## 11. Verification checklist for counsel spot-check (WS-EXT-C5 reviewer prompts) These prompts are for counsel's use during the 60-minute WS-EXT-C5 call. They map back to the §2 APP 1.3 structural-elements checklist and the §5 open questions. **APP 1.3 clarity + up-to-date test:** - Does the language in §§1–10 satisfy "clearly expressed" for a worker-audience reader? - Is there any section that relies on internal jargon (RLS, JSONB, `retention_until`) in a way that would confuse a non-technical reader? Flag for plain-English rewrite. **APP 1.4(a)–(g) content coverage:** - APP 1.4(a) — categories: does §2 list all kinds we actually collect? Flag any missing from the baseline schema appendix (Session A of the audit). - APP 1.4(b) — how we collect and hold: is §2 intro + §5 storage description complete? - APP 1.4(c) — purposes: does §3 capture primary and secondary? - APP 1.4(c) disclosure limb — does §4 table cover every recipient? - APP 1.4(d) — access/correction: is §7 enough given Q3's retention enforcement framing? - APP 1.4(e) — complaints: does §9 give a worker what they need to complain to us and to the OAIC? - APP 1.4(f) — overseas disclosure occurring: does §5 make the pre/post-WS-EXT-C1 dichotomy clear to the reader of whichever variant ships? - APP 1.4(g) — countries of overseas recipients: does each recipient in §4 that handles data overseas identify the country? **APP 1.5 + APP 1.6 availability:** - Is the "free of charge at `/privacy`" commitment in §10 correct? - Is the "alternative format on request" commitment in §9 achievable operationally? **APP 11 — reasonable steps:** - Is §6 "reasonable steps" language appropriately conservative given Duck's current posture? - Q2 detail — any change to the language describing the audit-log append-only mechanism? **APP 11.2 — retention:** - Q3 detail — approve declarative periods in §8 or redraft softer? **APP 12/13 — access and correction:** - Is the manual-runbook posture in §7 acceptable for the pilot launch window? - Any changes to the 30-day response commitment? **APP 8 — overseas disclosure:** - Either variant of §5 — is the drafted paragraph sufficient? - For the post-WS-EXT-C1 variant, does the "global service" disclosure of Stripe / Resend need per-country detail? (Observability — Sentry, PostHog — is not active at pilot; if re-introduced post-launch, the §4 table and §5 paragraph must be updated before that deployment ships.) --- ## 12. File provenance **File:** `docs/source/compliance/f-002-privacy-policy-draft.md` **Workstream:** WS-INT-03 Task D (parallel batch subagent D) **Status:** Published v1 (2026-05-14, A11-PRIVACY Phase B) — counsel review pending WS-COMP close per master index §10. **Author:** subagent D (Claude Opus 4.7 1M context), 2026-04-23 **Source alignment:** OAIC APP Guidelines Chapter 1, accessed 2026-04-23 via WebFetch against https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-1-app-1-open-and-transparent-management-of-personal-information. Fetch succeeded; APP 1.4(a)–(g) content list and APP 1.5 / APP 1.6 availability requirements extracted. **Related authoritative sources consulted:** - `docs/audits/2026-04-17-full-codebase-audit/session-f-compliance-operational-findings.md` lines 231–268 (F-002), 422–440 (F-010), 459–471 (F-012) - `docs/source/references/duck-inductions-compliance-handoff.md` (F-002 references, counsel-engagement approach) - `docs/source/references/remediation-master-plan.md` §6 (sequencing), §8.2 (counsel briefing packet — Q2 verbatim), §11 R1 (slip risk), §10 (C2 layer 2b deferral framing) - `docs/source/references/remediation-scope-decisions.md` Q4 (entity/ABN) - `src/app/(marketing)/privacy/page.tsx` (40-line stub being replaced) **Next action:** bundle this draft into the WS-EXT-C5 counsel briefing packet per master plan §8.2 item 3, alongside the F-001 collection-notice draft (Task C sibling artefact), the entity-and-ABN pack (Task F / WS-EXT-C3 output when ready), the Sydney migration status (Task S / WS-EXT-C1 output when ready), and the C2 audit-log ADR (Task B). Send to counsel 48 hours before the call. --- ## 13. Appendix D — Construction-industry context (reviewer orientation) This appendix gives counsel unfamiliar with Duck's product a short orientation so they can read the policy with the right worker-population in mind. **Who the policy is written for.** - **Workers** — construction-industry workers at Australian building sites. Often employed by a subcontractor rather than the head site operator. Typically access Duck via their phone on a tablet at the site gate. Induction is often the first time they see any of the site's compliance content. Audience comprehension floor is mixed literacy; plain English matters. - **Site administrators** — the head site operator's safety-and-compliance team. Typically one or two people per site. Read the policy during customer-evaluation or privacy-due-diligence phases. Audience comprehension floor is higher — familiar with WHS and Australian Privacy Principles terminology. - **Subcontracting company administrators** — the employer of the worker. Read the policy when managing their crew's credentials and inductions. Audience comprehension floor similar to site administrators. - **OAIC investigators or WHS regulators** — the "worst-case" audience. Read the policy if a complaint or incident lands. Audience is APP-fluent and looks first for the elements in §2 of this draft. **Key flows the policy describes.** - **Induction flow** — a worker scans a QR code at a site, fills in identity and credentials, signs an acknowledgement, and completes site-specific safety questions. This is the largest PII collection event for a given worker. - **Sign-on / sign-off flow** — a worker scans a QR code at arrival and departure; the platform records time and (optionally) geolocation. - **SWMS acknowledgement** — high-risk work requires Safe Work Method Statement acknowledgement; the worker signs and the signature is stored alongside the induction record. - **Pass display** — the worker can display a compliance pass showing their current site eligibility. **What Duck does not do.** - Duck is not a worker-authenticated platform — workers typically do not have a login. Site administrators do. - Duck does not directly market to workers. - Duck is not a payroll or payment system — no salary information passes through the platform. **Regulatory environment that shapes the policy.** - Australian *Privacy Act 1988* (Cth) and the thirteen Australian Privacy Principles. - State/territory WHS legislation (e.g., *Work Health and Safety Act 2011* in most jurisdictions) imposing record-keeping obligations on site operators — Duck's platform exists to help discharge those. - The Notifiable Data Breaches (NDB) scheme within the Privacy Act. --- ## 14. Appendix E — Diff summary against the 40-line stub For counsel orientation: this appendix summarises what changes between the current stub policy and the post-counsel deployed version. **Current stub** (`src/app/(marketing)/privacy/page.tsx`): - 40 lines total. - Four short sections (What we collect / How we use data / Data access and retention / Contact). - Each section 2–4 sentences. - Does not identify: legal entity, ABN, APP entity status, specific PII categories, specific purposes, specific recipients, overseas storage, specific access/correction mechanism, retention periods, complaints mechanism. - "Last updated" stamp: `February 27, 2026` — predates 2026-04-21 baseline cutover. Stale (F-012). **Post-counsel deployed version** (after WS-EXT-C6): - Full OAIC APP 1.3 / APP 1.4 structural coverage. - Ten headed sections (§§1–10) plus an inline third-party emergency-contact notice. - Identifies legal entity and ABN (from WS-EXT-C3). - Identifies APP entity status (from WS-EXT-C5 counsel selection). - Enumerates PII categories (from §2 of this draft). - Distinguishes primary and secondary purposes (APP 6). - Lists recipients with purpose per recipient. - Discloses overseas recipients and countries (APP 1.4(f), (g)) — variant selected post-WS-EXT-C1. - Describes access/correction mechanism (APP 12/13) — manual runbook during pilot. - States retention periods per data category (APP 11.2). - Describes complaints mechanism (APP 1.4(e)) — including OAIC referral. - "Last updated" stamp auto-set at PR merge time. Changelog embedded. **Line-count delta.** Stub is 40 lines of TSX, mostly JSX boilerplate. The rewrite is ~200 lines of content-dense TSX with prose pulled from this draft. The rendered page is several orders of magnitude longer — acceptable for a privacy policy where length reflects structural completeness. --- ## 15. Appendix F — Delivery checklist Final delivery checklist for the pre-counsel draft (what should be true before sending to counsel at WS-EXT-C5): - [ ] Draft file exists at `docs/source/compliance/f-002-privacy-policy-draft.md`. - [ ] §1 opens with a neutral `[§1 opening — ...]` placeholder referencing Appendix A selection (Alternative A or B at WS-EXT-C5 or counsel re-evaluation trigger); entity table and the "We are an APP entity" framing-neutral closing sentence follow. - [ ] §2 table enumerates all nine PII categories (identity, contact, emergency-contact, employment-and-credentials, signature, sensitive-medical, sign-on/off, induction responses, technical). - [ ] §3 distinguishes primary and secondary purposes. - [ ] §4 table lists every external recipient with purpose. - [ ] §5 contains both pre-WS-EXT-C1 and post-WS-EXT-C1 variants. - [ ] §6 describes security controls without claiming tamper-proof-ness. - [ ] §7 names APP 12 / APP 13. - [ ] §8 enumerates per-category retention periods as a bulleted list with specific values (2026-04-24 retention research) and APP 11.2 primary framing; includes legal-hold pause clause and progressive-enforcement framing. - [ ] §9 names OAIC referral (website, phone, post) and APP 1.4(e) complaints mechanism. - [ ] §10 describes the "last updated" auto-stamp convention and links to Appendix C changelog. - [ ] §4 (placeholder tokens table) enumerates all four placeholder tokens. - [ ] §5 (open questions) contains Q1, Q2, Q3 with Q2 verbatim from master plan §8.2 item 5. - [ ] Appendix A contains both Alternative A and Alternative B paragraphs. - [ ] Appendix B contains emergency-contact notice per F-010. - [ ] Appendix C contains changelog skeleton with v1 row and pending v2 row. - [ ] Downstream deployment note (§9) names WS-EXT-C6. - [ ] Cross-reference map (§10) links to F-001, F-003, F-004, F-005, F-010, F-011, F-012, F-013, F-014, F-015, F-008, C2. - [ ] No commits made by the drafting subagent. **If any row above is unchecked, the draft is not ready for WS-EXT-C5.** --- ## 16. Appendix G — Edge-case rendering considerations (for WS-EXT-C6 developer) These are notes for the WS-EXT-C6 developer rewriting `src/app/(marketing)/privacy/page.tsx`. They do not affect counsel review of the content. **Rendering approach options:** - **Option 1 (inline TSX content).** Copy §§1–10 of this draft directly into the page component as JSX. Fastest to ship. Slight friction for future updates because the content is co-located with JSX markup. - **Option 2 (MDX content).** Move content to a `src/content/privacy/v2.mdx` file; the page component imports and renders it. Better for future updates. Requires a small MDX pipeline. - **Option 3 (versioned MDX).** Same as Option 2 but preserves `v1.mdx`, `v2.mdx`, etc. for users who agreed to older versions. This is what the session-f finding body describes as post-MVP. **Out of MVP scope** — use Option 1 or Option 2. **Recommended for WS-EXT-C6:** Option 1 (inline TSX). Post-launch, revisit Option 2 if update cadence warrants it. **Accessibility considerations.** - Use semantic headings (`<h1>` once, `<h2>` for section-level, `<h3>` for sub-section). - Tables (§2, §4, §6, §8, §9) must use proper `<thead>`, `<tbody>`, and `<th scope="col">`. - Contact-email and phone number should be `<a href="mailto:...">` and `<a href="tel:...">` respectively for screen-reader and mobile-device affordance. - Policy should be readable at a base font size of 16px and remain legible at 200% browser zoom. **Content delivery.** - Page is statically generated at build time. Content is immutable between deployments. - "Last updated" date is injected at build from the Git commit timestamp of the content source file. - Changelog in Appendix C renders as a table at the bottom of the page, or as a collapsible "Version history" disclosure (UX decision for WS-EXT-C6). **SEO and metadata.** - `<title>` = "Privacy Policy | Duck Inductions". - Meta description = one-sentence summary of Duck's PII handling. - Structured data (`schema.org/PrivacyPolicy`) optional but recommended. **Public-footer link (F-011 remediation).** - Add to `src/app/(public)/layout.tsx` footer component. - Link text: "Privacy". - Target: `/privacy`. - Placement: bottom of `(public)` layout, visible on all public pages (`/induct/[qr_token]`, `/sign-on/[qr_token]`, `/sign-off/[qr_token]`, `/pass/[pass_token]`). - Also add `/terms` link alongside, matching the marketing footer structure. --- ## 17. Appendix H — Anti-pattern guard (WS-INT-03 plan §6) This draft deliberately observes the anti-patterns listed in the WS-INT-03 Task D brief. They are restated here so future editors (including the author of the next draft revision) can verify that the guard continues to hold. **Anti-patterns observed:** - The controller-vs-processor framing is NOT resolved in this draft. Two alternative §1 paragraphs sit in Appendix A; counsel selects one at WS-EXT-C5. - The controller identity is NOT resolved in this draft. ENTITY_PLACEHOLDER threads through §1 and is flagged in the Q4 decision path at WS-EXT-C3. - Record-keeping integrity claims are NOT overstated. §6 explicitly declines cryptographic-proof language and flags the roadmap-only status of hash-chain via Q2. - The draft has NOT been polished against counsel markup. Counsel has not seen this yet — WS-EXT-C5 is the first contact. - This draft is NOT being committed to the repository by the drafting subagent. Delivery is WS-EXT-C4 → WS-EXT-C5 → WS-EXT-C6; commit happens at WS-EXT-C6 with the deployed page. - The drafting subagent has NOT edited `src/app/(marketing)/privacy/page.tsx`. That is WS-EXT-C6's work. - The drafting subagent has NOT coordinated with the other four parallel subagents. Cross-document consistency is the parent-session reviewer's job (WS-INT-03 Task 6). **What happens if any of these anti-patterns is violated during future edits:** - Flag to the operator immediately. - Do not proceed to WS-EXT-C5 until the draft is re-harmonised with the pre-counsel constraints. - In particular: resolving Q1, Q2, or Q3 inside this document short-circuits counsel's review and is the failure mode the anti-pattern guard exists to prevent. **Self-verification log (subagent D, 2026-04-23):** - OAIC Chapter 1 fetch via WebFetch — SUCCEEDED. Primary source extracted APP 1.4(a)–(g) content list and APP 1.5 / APP 1.6 availability. The source naming convention in OAIC places the structural content list under APP 1.4; the session-f audit finding refers to the list as "APP 1.3 elements" because APP 1.3 is the umbrella obligation to have such a policy. Both framings are captured in §2 of this document so neither reader is misled. - Session-f finding body (lines 231–268) — READ. Ten structural elements enumerated; all ten mapped to §§1–10 in §2 checklist. - Session-f F-010 (lines 422–440) — READ. Emergency-contact notice drafted in Appendix B; third-party APP 3.2 framing preserved. - Session-f F-012 (lines 459–471) — READ. Last-updated convention drafted in §10 + Appendix C. - Compliance handoff F-002 references — READ (grep lines 18, 63, 68, 87, 129, 135). "Approach 2 self-draft" posture adopted. - Master plan WS-EXT-C sequencing — READ (lines 116–120, 245, 260, 513, 519, 541, 563, 584, 608, 638, 688). C4 drafts, C5 counsel, C6 deploys; dependencies captured in §9. - Master plan §8.2 item 5 (Q2 verbatim) — READ (line 1413). Q2 text in §5 is a verbatim copy. - Master plan §11 R1 (slip risk on entity) — READ (line 1512). Captured in §4 tokens table and §1 entity row. - Scope-decisions Q4 (entity/ABN) — READ (lines 77, 188, 212, 301, 339, 477). Captured in §1 placeholder + §4 tokens table + Appendix H anti-pattern guard. - Stub file `src/app/(marketing)/privacy/page.tsx` — READ. All 40 lines. Diff summary in Appendix E. **Zero-commits confirmation.** No git commits have been made by this subagent. The file at `docs/source/compliance/f-002-privacy-policy-draft.md` is unstaged and untracked until the parent session or a later workstream decides to commit. WS-INT-03 Task D delivers the draft only. **Cross-session-f consistency note.** The ten APP 1.3 structural elements listed in session-f F-002 body (lines 248–258) are deliberately mirrored in the §2 checklist of this document so that a reviewer cross-reading the two artefacts sees the same list in the same order. Divergence between the two lists would be a drafting error and should be flagged at WS-EXT-C5 reviewer handoff. **Next subagent handoff.** The parent-session reviewer (WS-INT-03 task 6) should run the following cross-document consistency check between this draft and the F-001 collection-notice draft (subagent C sibling artefact): - Both documents use the same legal entity placeholder convention (ENTITY_PLACEHOLDER). - Both documents reference the same Q1 controller-vs-processor question text. - Both documents point to the same `/privacy` URL and privacy-contact email placeholder. - Neither document pre-commits a resolution to Q1, Q2, or Q3. --- *End of F-002 first-pass draft · v1 · pre-counsel · not for deployment.*