PROJECT ASSUMPTIONS LOG - INSTRUCTIONS AND FICTIONAL CASE

Files: project-assumptions-log-blank.csv, project-assumptions-log-worked.csv,
and this instructions TXT. Exactly three files; the two CSV headers are identical.

These are plain UTF-8 value files. There are no formulas, dropdowns, alerts,
automatic approvals, links to client systems or automatic history. Actual
Office/Excel/Google Sheets opening has not been tested. Import into a copy,
prefer text columns for IDs, timestamps and references, and check all columns,
text and UTC offsets before relying on the result. Retain an unchanged original.

START WITH ONE CHECK
Copy the blank file. Use one row per assumption, not one row per message.
Write a proposition that can be checked, its applicable output/version and why
you are currently relying on it. Name the person who will obtain and assess the
evidence; that person may need an answer from somebody else. Set the check due
before the work commitment that needs the answer. Agree what an adequate answer
would identify, such as the exact wording file/version and any exclusions.

FIELD GUIDE (ORDER MATCHES BOTH CSV FILES)
assumption_id: stable reference, not a row number that changes when sorted.
assumption: the original checkable proposition; do not silently rewrite it.
applies_to: the output, version, purpose and limits to which the check applies.
reason_for_assumption: why it was initially used; not proof of it.
recorded_at: when the assumption was first entered; preserve it.
recorded_by: who entered it; this does not grant approval authority.
verification_owner: who will obtain, evaluate and record the answer.
check_method: the exact comparison or question and what needs identifying.
check_due_at: deadline for obtaining the answer, not a delivery promise.
status: Unverified, Supported, Contradicted or Recheck in this suggested scheme.
checked_at: when the owner actually evaluated evidence; leave blank if not done.
evidence_ref: precise references and versions; no response is not evidence.
finding: what the evidence does and does not establish.
work_response: the dependent work to use, hold or discuss; not proof of approval.
action_owner: who carries out this next step; may differ from verification owner.
next_check_at: next review/follow-up; does not erase an earlier missed deadline.
check_history: append timestamp, recorder, old/new state, sources, reason and
old/new check deadlines before updating the current fields. This is manual.

STATUS LIMITS
Unverified: no adequate check yet; includes no answer or an incomplete answer.
Supported: the evidence backs the proposition only for the stated purpose,
version and conditions. It is not a universal guarantee or finished work.
Contradicted: the evidence conflicts with the proposition in its stated scope.
Recheck: prior support cannot be relied on for the next use without a new check
because a recorded condition or source has changed or is in question.
These labels and columns are editorial suggestions, not a PMI standard.

UPDATE WITHOUT ERASING THE REASON
Keep one current row per ID. Append history first, including the evidence time
and the time/person recording the check when those differ. Then update status,
checked_at, evidence_ref, finding, work_response and next_check_at as needed.
Retain earlier sources in the history and their agreed source location. Do not
replace a previous source merely with 'superseded'. An unchanged statement can
be checked again under the same ID. If the proposition itself is different,
create a new ID and cross-reference the earlier record instead of rewriting it.
If a check is missed, retain its due date, record that it was missed and set a
separate next follow-up. Silence does not confirm or contradict the proposition.
When answers conflict, retain both references and their versions; obtain an
explicit answer for the relevant purpose before marking the proposition supported.
Keep sensitive source material in its authorised location; use precise references
rather than copying private client messages into every log copy.

FICTIONAL WORKED CASE - NOT CUSTOMER DATA OR AN OBSERVED TEST
Merrin Arts Club, Wattle Room Studio, Nina, Ben, all messages, files, dates,
observations and proposed actions are invented. The agreed job is the first
layout of an English two-page workshop programme as a PDF. Ben can identify
wording for that first layout in the fictional brief; final publication approval
and extra deliverables are not established by that permission.
All example times use the project-agreed UTC+11:00 offset. Worked CSV snapshot:
11 November 2026, 16:00. It does not show events after that time as completed.

9 NOVEMBER, 09:00 - BEFORE CHECKING
Nina records AS-01, AS-02 and AS-03 as Unverified. The initial check deadline for
AS-01 and AS-02 is 10 November, 12:00. AS-03 is due 12 November, 15:00.
AS-01: Programme-text-v1 is the wording to use for the first layout.
AS-02: The receiving coordinator can use the agreed PDF without an editable version.
AS-03: The workshop list in the brief is complete.
Q-03 is the fictional request asking Ben to compare the workshop list with the
current programme and identify missing or removed workshops. It has no recorded
reply by the snapshot.

10 NOVEMBER - CHECKS AND EVIDENCE
E-01, Ben, 10:15: identifies Programme-text-v1 for the first layout, not final
publication sign-off. Nina evaluates it at 10:30. AS-01 becomes Supported for
that limited use; it does not validate workshop-list completeness (AS-03).
E-02, Ben, 11:00: says the receiving coordinator needs an editable version for
later updates and cannot use the PDF alone for that intended workflow. Nina
evaluates it at 11:15. AS-02 becomes Contradicted for that handover purpose.
Nina records an additional request for discussion by 12 November, 10:00. No fee,
new date, editable deliverable or work start is approved by this observation.

11 NOVEMBER - A CONDITION CHANGES
E-03, Ben, 15:00: says a room change is being considered and cannot yet confirm
whether v1 wording will need changing. Nina records Recheck for AS-01 at 15:10.
The E-01 support remains in history; E-03 does not approve replacement wording
or prove that E-01 was wrong at the time. Nina holds text-dependent adjustments
and asks which wording remains usable, with a check due 12 November, 12:00.
AS-03 remains Unverified at 16:00. Its check is not yet overdue. No missing
workshop or approved extra session is inferred from the absence of a reply.

NEXT STEPS AT THE SNAPSHOT (PLANNED, NOT COMPLETED)
AS-02: Nina discusses the handover request on 12 November by 10:00.
AS-01: Nina obtains a wording/version answer on 12 November by 12:00.
AS-03: Nina obtains the completeness comparison on 12 November by 15:00.
Dependent work stays distinguishable from unrelated agreed work. Supported does
not approve scope, and Contradicted does not authorise an alternative. Follow
the actual project's decision process before promising an extra file or date.

SOURCE SCOPE
Andy Jordan's public Assumptions Log description on ProjectManagement.com:
https://www.projectmanagement.com/deliverables/283302/Assumptions-Log
Public description checked 4 November 2026. It describes tracking assumptions
and validation work, with description/reason, owner, status and update fields.
Its members-only downloadable file was not accessed. These CSVs and this case
are independently written editorial examples, not a reproduction of that file.