CSV change approval guide
Keep a CSV Change Reason and Approval Record
After reviewing a delta, keep what changed, why it is accepted, and who approved it in one handoff record. This page uses synthetic data only and sends nothing.
1. Separate the delta from the decision
Record facts about the delta separately from the reason for adopting it. Keep an unapproved row as pending; do not mix it with approved output.
| Change ID | Delta fact | Reason | Status |
|---|---|---|---|
| chg-001 | Add the region column | Required by the new delivery contract | approved |
| chg-002 | Correct row 002 to west | Do not adopt until source-confirmation is checked | pending |
pending means unapproved. Do not infer an empty value or call it delivered before the approver and reason are recorded.
2. Fields for one handoff record
| Field | Record |
|---|---|
| Target | Input, old revision, new revision, and change ID |
| Reason | Contract change, source evidence, or hold reason |
| Approval | Approver, approval time, and approved / pending |
| Reproduction | Delta manifest or source-confirmation filename |
| Output boundary | Keep the original CSV and approved output as separate files |
3. Use a safe order
- Review the old/new delta locally in CSV cleanup.
- Record the reason and unresolved evidence in the handoff record.
- Enter approver and time; only approved changes become delivery candidates.
- Save the CSV, delta manifest, and record under the same change ID.
This fixed case demonstrates the handoff decision after comparison, rather than rebuilding the comparison engine.
Where not to auto-approve
If the approver, reason, source evidence, or manifest reference is missing, stop at pending. External storage, authentication, and server-side approval ledgers are outside this guide.