DECISION LOG — INSTRUCTIONS, COMPLETE HISTORY AND CONFIRMATION

CURRENT THREE-FILE DELIVERY
1. decision-log-template-blank.csv: the blank, 23-column CSV for a new project.
2. decision-log-example-after-fictional.csv: the completed fictional 30 October 2026 CSV; inspect separately, never merge its teaching data into a live log.
3. This UTF-8 TXT: the full original field guide and work notes, complete before/pending CSV history, and fictional unsent confirmation request/reply.

The before and pending snapshots are verification history, not separate downloads. Read the existing work notes first. For a spreadsheet comparison, copy only the complete data between each BEGIN CSV and END CSV marker into a separate plain UTF-8 .csv file. Include the 23-column header, commas and all double quotes; exclude the marker lines. Open with comma separation and double-quote quoting, then check a save/reopen. Do not append the snapshots to a current log. Actual Office/Excel/Google Sheets opening and display remain untested.

The next section preserves the original instructions unchanged. Its before/pending CSV filenames are archival source names: their complete data is included in sections B/C below. Its confirmation TXT filename identifies the unchanged content in section D below. Only the blank and completed after CSVs are separate downloads in this delivery.

SECTION A — ORIGINAL INSTRUCTIONS, FIELD GUIDE AND WORK NOTES
BEGIN TEXT: decision-log-instructions.txt
DECISION LOG — MANUAL CSV INSTRUCTIONS

Blank template and fictional teaching examples

The studio, client, people, project, IDs, sources, dates, decisions, messages and work states in the example files are entirely fictional. They are not real client records, measured results, legal approval rules or a TASKUL demonstration. All October and November 2026 dates are historical teaching values, not live deadlines for the reader.

FILES AND OPENING
1. Make a copy of decision-log-template-blank.csv for your project. It contains only the 23-column header.
2. Inspect decision-log-example-after-fictional.csv separately for the completed 30 October 2026 record.
3. Compare decision-log-example-before-fictional.csv (27 October) and decision-log-example-pending-fictional.csv (28 October). They are separate snapshots, not rows to merge into a live log.
4. Read decision-log-confirmation-example.txt for the exact fictional, unsent request and bounded reply. No message has been sent.
5. Open/import each CSV using UTF-8 encoding, comma separation and a double quote as the quote character. The first row is the header; all rows use the same ordered 23 fields. Keep the complete header when saving.
6. Preserve stable IDs, source references and ISO dates (YYYY-MM-DD). A spreadsheet may change date display or values during opening/saving; check the saved copy before sharing.

These are ordinary value files. They do not supply automatic approval, status transitions, replacement links, notifications, formulas, evidence storage or access controls. Actual Excel/Google Sheets/Office opening and display have not been tested. TASKUL import compatibility and public download delivery have not been tested. Local data checks do not establish these behaviours.

READ THE CURRENT CHOICE AND THE WORK SEPARATELY
Keep the full unfiltered history. A current view is for the relevant project and subject, with actual approval and applicable effect: exclude proposed/rejected/superseded entries, then check effective dates and unresolved conditions. A recorded approval does not make disputed work safe to execute or mean the action is completed.
In this project Elise is already the agreed decision-maker for route and format; Priya maintains the log and owns the design action. Rory contributes information. The template cannot assign authority for your client.
Before (27 October): current approved IDs DEC-001 and DEC-002.
Pending (28 October): current approved IDs remain DEC-001 and DEC-002; DEC-003 is proposed. ACT-001 map work is held while the independent ACT-002 copy work can continue.
After (30 October): current approved IDs DEC-002 and DEC-003. DEC-001 is retained and superseded by DEC-003; DEC-002 is unchanged.

FIELD GUIDE — EXACT COLUMN ORDER
1. decision_id: Stable, project-wide unique DEC-NNN reference for one meaningful choice. Never recycle or renumber after sorting; a spreadsheet row number is not an ID.
2. project_ref: Stable project reference. PJT-GUIDE identifies the fictional guide project.
3. subject_key: Stable key for the same choice being revised; different subjects may have several current approved decisions. Here walking-route groups DEC-001 and DEC-003; output-format keeps DEC-002 independent.
4. decision: The exact direction under consideration or approved. Retain original wording on a superseded row.
5. item_version: The precise item/version considered, such as route-map-v1. Preserve the version each comment or approval refers to.
6. status: Decision state only: proposed, approved, rejected or superseded. Do not put held, ready, answered or completed here; work progress belongs in its action record.
7. recorded_on: Date this row was first created; retain when a proposal is later approved.
8. approved_on: Date of the actual approval supported by approval_ref, not the date the maintainer typed it.
9. effective_from: When the approved choice starts applying. In this example it equals approved_on. For future/conditional choices retain the old basis until activation; add a condition note and check.
10. approver: Person whose answer the agreed process requires; distinct from action_owner and log_maintainer. A name in this field does not itself establish approval or grant authority.
11. rationale: Reason recorded for the choice. Retain the original rationale on superseded rows. If missing, use Not recorded — confirm with [person]; do not invent a reason.
12. source_ref: Precise discussion/proposal reference, including title/date/item or passage. Preserve this when adding a later approval.
13. approval_ref: Precise original confirmation reference, including limits; retain the old approval on superseded rows.
14. impact: Consequences for the work, constraints, holds and any unresolved condition. A superseded row retains its historic impact; current work comes from the successor and action records.
15. proposed_replacement_for: A candidate target only. Populated while pending; does not say the old row has been superseded.
16. replaces: Actual earlier decision replaced after approval takes effect.
17. superseded_by: Actual successor ID on the old row; reciprocal with successor.replaces.
18. next_action_ref: Reference to work; progress stays in its own action record. Approved is not completed.
19. next_action: Concrete follow-up work or question tied to next_action_ref. Retain historic action text on superseded rows without treating it as current instruction.
20. action_owner: Person responsible for the next action, distinct from the approver. Priya owns the design work; Elise authorises the route in this fictional project.
21. action_due: Date the action is due, not the approval or ledger-maintenance date.
22. follow_up_on: Date to seek an answer/check an unresolved entry, separate from approval and work due dates.
23. last_updated_on: Date of ledger maintenance; not a substitute for approved_on.

STATUS, DATES AND REPLACEMENT RULES
Use proposed, approved, rejected or superseded for decision status. Keep work states in the separate action record and the snapshot work notes below.
For an unapproved proposal, approved_on, effective_from and approval_ref remain empty. A required approver can be named without approval. If the approver is unknown, use To confirm and leave the choice unapproved. Silence or a contributor comment is not approval evidence.
While DEC-003 is proposed, proposed_replacement_for is DEC-001. Both actual-link fields replaces and superseded_by stay empty, and DEC-001 has no successor.
When the authorised replacement actually takes effect, set old.superseded_by to the new ID and new.replaces to the old ID, clear the candidate field, and retain the original wording, version, rationale, approval date and source on the old row. For the after example these reciprocal links are DEC-001.superseded_by=DEC-003 and DEC-003.replaces=DEC-001.
If rejected, mark the proposal rejected, clear its candidate target and leave DEC-001 approved without a successor. Do not create a replacement just to close the discussion.
For future-effective or conditional approval, record the actual approval and its effective date/condition but keep the old row unsuperseded and actual replacement links inactive until the date arrives or the condition is verified. Put the activation check in impact and follow_up_on. Verify activation manually before changing the links/statuses. The supplied example demonstrates immediate effect only, not this later activation.
A further substantive decision after approval gets a new stable ID. While a proposal changes, preserve the precise version each comment refers to. Do not renumber IDs after sorting.
DEC-001: approved/effective 26 October, first recorded 27 October; the after snapshot was maintained on 30 October. DEC-003: first recorded 28 October, approved/effective 29 October, maintained 30 October. Maintenance never moves the original approval date.
Preserve DEC-003 source_ref (Rory's 28 October call-note item) when adding approval_ref (Elise's 29 October email, 10:20 AEDT, paragraph 1). Where same-day order matters, retain the actual source timestamp and timezone; row order cannot establish chronology.
The old DEC-001 impact and ACT-001 description remain as history. They do not instruct someone to keep making route-map-v1 after replacement. ACT-004 prepares a proof for review, due 2 November. It is not delivered or approved in the example, and no final guide/publication approval is recorded. ACT-002 has no later completion record.

PER-SNAPSHOT WORK NOTES — KEPT OUTSIDE DECISION STATUS

BEFORE — as of 2026-10-27
ACT-001 | ready | Prepare the map under DEC-001 for review; not approved for publication.
ACT-002 | ready | Independent non-route copy proofread.

PENDING — as of 2026-10-28
ACT-001 | held | A contributor raised a conflicting route; request the authorised answer. DEC-001 remains the recorded approved position; this does not make disputed work safe to execute.
ACT-002 | ready | Independent copy check continues.
ACT-003 | awaiting_client | Confirmation requested; no approval inferred from Rory's comment or silence.

AFTER — as of 2026-10-30
ACT-001 | stopped_after_replacement | Retained as old map work; not marked completed.
ACT-003 | answered | Elise's exact reply is referenced; approval happened 29 Oct and was entered on 30 Oct.
ACT-004 | ready | Prepare the new proof by 2 Nov. Delivery/approval of that proof has not occurred in the example.

PRIVACY AND EDITING
Use precise private references accessible to the relevant colleagues when evidence is confidential. Do not copy a whole client conversation into a broadly shared sheet merely to fill source_ref or approval_ref.
Do not invent an unknown rationale, approver, approval, outcome or work completion. Empty approval fields in a proposal are meaningful; do not replace them with zero dates.
New text can be interpreted as a formula by spreadsheet applications if it begins with =, +, - or @, or with control characters. Treat such input as text using your spreadsheet's import settings and inspect the saved copy. The supplied fictional cells contain no such leading formula characters; that local scan does not cover future edits.

SAVE AND HANDOVER CHECK
Use the old DEC-001 ID to reach DEC-003, inspect the exact approval reference, return to DEC-001, and locate ACT-004 with Priya and 2026-11-02. Keep DEC-002 independent. Compare the proposal's empty approval fields with the after record.
Check commas, double quotes, Unicode text, IDs and dates after saving and reopening. The supplied files have a local UTF-8/CSV parse-and-write consistency check; actual spreadsheet UI, Office display, rendered article links, PC/SP and public delivery remain untested.
Local CSV validation is not legal approval, client sign-off, a completed task or product import verification.
END TEXT: decision-log-instructions.txt

SECTION B — BEFORE SNAPSHOT, 27 OCTOBER 2026
BEGIN CSV: decision-log-example-before-fictional.csv
decision_id,project_ref,subject_key,decision,item_version,status,recorded_on,approved_on,effective_from,approver,rationale,source_ref,approval_ref,impact,proposed_replacement_for,replaces,superseded_by,next_action_ref,next_action,action_owner,action_due,follow_up_on,last_updated_on
DEC-001,PJT-GUIDE,walking-route,Use the north entrance and two-stop route in the visitor guide.,route-map-v1,approved,2026-10-27,2026-10-26,2026-10-26,Elise (client project owner; fictional),The client confirmed the north entrance for this edition.,"Fictional kick-off record, 26 Oct 2026, decision 1","Fictional email: Guide route and format confirmed, Elise, 26 Oct 2026, paragraph 1","Priya can lay out route-map-v1; this is a layout direction, not approval of the final guide.",,,,ACT-001,Lay out route-map-v1 for client review.,Priya (designer; fictional),2026-10-28,,2026-10-27
DEC-002,PJT-GUIDE,output-format,Keep the visitor guide to one double-sided A4 sheet.,guide-format-v1,approved,2026-10-27,2026-10-26,2026-10-26,Elise (client project owner; fictional),The agreed distribution point uses the A4 leaflet holder.,"Fictional kick-off record, 26 Oct 2026, decision 2","Fictional email: Guide route and format confirmed, Elise, 26 Oct 2026, paragraph 2",The output format stays fixed while map content can be reviewed separately.,,,,ACT-002,Proofread the supplied non-route copy within the agreed A4 layout.,Noah (copy editor; fictional),2026-10-30,,2026-10-27
END CSV: decision-log-example-before-fictional.csv

SECTION C — PENDING SNAPSHOT, 28 OCTOBER 2026
BEGIN CSV: decision-log-example-pending-fictional.csv
decision_id,project_ref,subject_key,decision,item_version,status,recorded_on,approved_on,effective_from,approver,rationale,source_ref,approval_ref,impact,proposed_replacement_for,replaces,superseded_by,next_action_ref,next_action,action_owner,action_due,follow_up_on,last_updated_on
DEC-001,PJT-GUIDE,walking-route,Use the north entrance and two-stop route in the visitor guide.,route-map-v1,approved,2026-10-27,2026-10-26,2026-10-26,Elise (client project owner; fictional),The client confirmed the north entrance for this edition.,"Fictional kick-off record, 26 Oct 2026, decision 1","Fictional email: Guide route and format confirmed, Elise, 26 Oct 2026, paragraph 1","Priya can lay out route-map-v1; this is a layout direction, not approval of the final guide.",,,,ACT-001,Lay out route-map-v1 for client review.,Priya (designer; fictional),2026-10-28,,2026-10-27
DEC-002,PJT-GUIDE,output-format,Keep the visitor guide to one double-sided A4 sheet.,guide-format-v1,approved,2026-10-27,2026-10-26,2026-10-26,Elise (client project owner; fictional),The agreed distribution point uses the A4 leaflet holder.,"Fictional kick-off record, 26 Oct 2026, decision 2","Fictional email: Guide route and format confirmed, Elise, 26 Oct 2026, paragraph 2",The output format stays fixed while map content can be reviewed separately.,,,,ACT-002,Proofread the supplied non-route copy within the agreed A4 layout.,Noah (copy editor; fictional),2026-10-30,,2026-10-27
DEC-003,PJT-GUIDE,walking-route,Use the east entrance and three-stop route in the visitor guide.,route-map-v2,proposed,2026-10-28,,,Elise (client project owner; fictional),An operations contributor reports that visitors should enter from the east; approval is still needed.,"Fictional review call notes, 28 Oct 2026, item 3, comment by Rory (operations contributor)",,Hold ACT-001's affected map work pending Elise's answer; ACT-002's independent copy proofread may continue.,DEC-001,,,ACT-003,Ask Elise to confirm route-map-v2 as the replacement for DEC-001.,Priya (designer; fictional),2026-10-29,2026-10-29,2026-10-28
END CSV: decision-log-example-pending-fictional.csv

SECTION D — FICTIONAL UNSENT CONFIRMATION REQUEST AND REPLY
BEGIN TEXT: decision-log-confirmation-example.txt
DECISION LOG — FICTIONAL UNSENT CONFIRMATION EXAMPLE

Fictional teaching copy, not sent.
All people, project, messages and dates are invented teaching data. No request or reply has been sent. These October/November 2026 dates are historical example values, not live deadlines.

Subject: PJT-GUIDE: confirm whether DEC-003 replaces DEC-001

Elise, DEC-001 currently records the north entrance and two-stop route in route-map-v1. Rory has proposed the east entrance and three-stop route. Please confirm whether route-map-v2 should replace that route now. If approved, Priya will prepare the updated proof for review by 2 November; DEC-002's double-sided A4 format stays the same. This request is for the map direction and next proof only, not final publication approval. We will hold the affected map work until your answer; the independent copy check can continue.

Fictional reply from Elise on 29 October 2026 at 10:20 AEDT: Yes, replace DEC-001 with the east entrance and three-stop route in route-map-v2, effective today. Keep the double-sided A4 format. Send the updated proof for review by 2 November. This does not approve the final guide for publication.
END TEXT: decision-log-confirmation-example.txt