CLIENT OFFBOARDING RECORD - USE NOTES AND FICTIONAL REFERENCES Files 1. client-offboarding-blank.csv: the same 18 headers as the worked file, with one empty row. Make your own copy and add a row for each file/access/retention decision that needs a separate check. 2. client-offboarding-worked-example.csv: 18 teaching rows: six stable record IDs at three snapshots. This is a completed illustration of a partial close-out, not a fully closed real project. 3. This TXT: use instructions, field meanings and invented reference details. ALL PEOPLE, BUSINESSES, ITEMS, AGREEMENTS, EVIDENCE, DATES AND RESULTS BELOW ARE FICTIONAL. No account, permission, link, ownership transfer, deletion or client communication was actually performed. There are no real evidence URLs in these files. Reference labels describe what the invented record would contain; they do not link to missing deliverables or actual logs. Case Ivo at Harbour Paper Studio has delivered Larkspur Gallery's approved poster PDF and editable layout package v4. In this invented agreement those are the defined final items. Nia is the client's contact and operational owner; Elliot is its authorised administrator for the named final location, support notes and board. Rowan later turns out to manage the old review workspace. These are operational roles, not a statement about copyright or contractual title. Snapshots (all example times carry the fixed offset +11:00) S0: 10 November 2026, 10:00. Final pack sent; six checks pending. S1: 11 November 2026, 14:00. Four checks Confirmed; OF-05 and OF-06 Hold. S2: 12 November 2026, 12:00. Five checks Confirmed; OF-06 still Hold. The example preserves all six IDs at each snapshot. Filter snapshot=S2 to see the latest picture. Do not count all 18 rows as 18 separate assets. The unique key here is snapshot plus record_id. A verified_at value may be unchanged in a later snapshot because no new check occurred. Use sequence Identify the item and the exact location/link/account scope using references the intended readers are authorised to see. Name the recipient, operational owner and authorised admin separately. Leave an unknown role Unknown rather than using the person who last emailed you. Record the required access and proposed handling in current_access/agreed_handling; before agreement identify it as proposed. Add the agreement reference and the person authorised to act. Record the check, its scope, evidence, checker and time only after that check occurs. Keep a failure or missing prerequisite as Hold, with a next_owner and next_check. A request sent is not a successful check. Preserve dated versions or use your organisation's approved change history; the CSV does not create an audit trail automatically. Fields snapshot: group of rows describing one point in the example; use your own unambiguous version/date in a real record. record_id: stable identifier for one check. Keep it when that check changes. item_reference: exact pack/location/permission/link/archive being considered. recipient: person who needs the work or response. operational_owner: person responsible for the item after the handoff; not IP ownership. authorised_admin: person confirmed able and authorised to administer this specific scope; not automatically the recipient. current_access: what is currently known; say Unverified/Unknown when it has not been checked. agreed_handling: retain/end/await decision, including any narrow support scope. Mark a proposal as proposed until agreed. agreement_ref: where the relevant authorisation or arrangement is recorded. Blank means no agreement reference is supplied, not implied consent. action_owner: person responsible for the current action or inquiry. status: Pending = required checks not yet supplied; Hold = a specific prerequisite/decision is unresolved; Confirmed = evidence supports this row's agreed outcome. Confirmed does not mean access ended: it may confirm retained access or receipt. verification_result: what the check established, including its limits. evidence_ref: location/identifier of the actual check or hold record; example labels below are invented. verified_by / verified_at: who recorded that check and when, with a timezone/offset. For a hold these describe the check which found the gap, not a successful change. next_owner / next_check: who follows up and the agreed checkpoint; neither sends an automatic notification. Blank means this example has no additional checkpoint on that row, not an exemption from later obligations. notes: relevant scope limits and unresolved questions. Do not use it to hide a required action. Invented agreement references AG-01: 11 November, Nia confirms receipt of the two v4 items and responsibility for LARK-FINAL-01; Elliot confirms authorised administration. No transfer operation is proposed or reported. AG-02: 11 November, Nia and Ivo agree the separately specified correction needs Ivo's read/comment access to SUP-01 only; Elliot checks that scope. Review on 19 November 2026 at 10:00+11:00. This is not an expiry command or a new support promise. AG-03: 11 November, Nia authorises Elliot to end Ivo's editor access to BOARD-01 only. It does not authorise removing support access. AG-04: 12 November, Nia identifies Rowan as original review-workspace administrator; Rowan confirms the role and the authorised request to end REV-OLD-01 only. Invented check references EV-01: Nia's 11 November 11:00 confirmation: both named v4 items located/opened with her own approved access. EV-02: Nia and Elliot's 11 November 11:15 responsibility/administration confirmations for LARK-FINAL-01. EV-03: Elliot's 11 November 13:00 comparison of the named SUP-01 permission with AG-02. Does not certify every access route elsewhere. EV-04: Elliot's 11 November 13:30 authorised change/check for Ivo's specified BOARD-01 editor access. Does not claim deletion of the board or its contents. HOLD-01: Elliot's 11 November 13:45 inquiry cannot establish who administers REV-OLD-01. He is to resolve that with Nia by 12 November 10:00+11:00. No link-ending action is recorded at S1. HOLD-02: Nia's 11 November 13:50 record that the applicable instruction for ARC-01 is unresolved. She will obtain the relevant agreement/requirements and reply to Ivo by 12 November 16:00+11:00. No deletion is authorised. S2 occurs before that checkpoint; the hold remains, and its earlier check time is preserved. EV-05: Rowan's invented 12 November 11:30 ending record for REV-OLD-01, and Elliot's separate 11:45 check recording that named link unavailable. This is a teaching result, not a tested product function. It does not prove all access routes or copies disappeared. Handling the files These are UTF-8 CSV/TXT files, not an import package for a cloud service. If using a spreadsheet, preserve IDs, references, timestamps and free text as text and check them against this file after import. The generated files were checked locally as CSV/text; Office/Excel application opening, saving and shared editing have not been tested. No macros or formulas are intended. When adding text, use your tool's approved plain-text handling for values beginning with =, +, -, @ or control characters; do not trust a renamed extension to neutralise spreadsheet formulas. Never enter passwords, recovery codes, secret tokens or a broad confidential client archive. A reference must only expose material its readers may see. Closing the record At S2 only the specified old link and board access have confirmed endings. The final files, client administration and narrow support arrangement remain. ARC-01 is still Hold with Nia and the next checkpoint, so the overall offboarding record stays open. The 19 November support review also remains scheduled in the record; it has not happened and does not remove access automatically. Apply the actual agreement, service controls and applicable requirements before authorising an action. This template sets no retention period, contract effect, bulk ownership transfer, deletion method or assurance that every backup/copy is erased.