Change Ledger¶
Document — instantiates Layered Record Accumulation
Creates a structured ledger of changes, rationales, approvals, and consequences across time.
A Change Ledger is organized around decisions, not artifacts or events. Each entry records one deliberate change to a controlled thing — a spec, a policy, a configuration, a formula — together with why it was made, who requested, reviewed, and approved it, and which authoritative version it now points to. Its defining idea is that the change and its justification are inseparable: an entry that says a value moved from A to B without the rationale and the approving actors is not a ledger entry but a bare diff. What makes it THIS mechanism is that it answers "why was this changed, who signed off, and what is authoritative now?" — a governance question about accountable decisions, distinct from a moment-by-moment account of a live event or a revision-by-revision history of an artifact.
Example¶
A vaccine fill-finish line proposes switching to a new vial-stopper supplier. Under formal change control, the change ledger opens an entry: the rationale (a second-source supply-risk mitigation), the supporting risk assessment[1], and the named approvals — quality assurance, production, and the regulatory affairs lead — each signed with role and date. On approval, the entry records the effective batch and updates its pointer to the newly approved master batch record that now governs the line.
Setup to outcome: eleven months later a regulatory inspector asks why the stopper specification changed. The ledger answers in one entry: the supply-continuity rationale, the risk assessment that cleared it, the three approving signatures, and the link to the batch record that is currently authoritative. The question that would otherwise trigger a frantic reconstruction across emails and meeting minutes is settled by reading a single accountable record.
How it works¶
- One entry per deliberate change. The unit is a decision to change a controlled thing, opened before the change takes effect.
- Bind the rationale to the change. Each entry carries the reasoning, assumptions, and risk assessment that justified it — the why, not just the what.
- Name every accountable actor. Requester, reviewers, and approvers are recorded by role, so the decision is attributable and non-anonymous.
- Point to the now-authoritative version. The entry links to the specification, procedure, or configuration that its change makes current, so readers can always find what governs today.
Tuning parameters¶
- Approval rigor — single sign-off, multi-party review, or full board adjudication. Heavier rigor deters ill-considered changes but slows every one of them.
- Rationale depth — a one-line justification versus a documented risk assessment. Deeper rationale supports later defensibility but adds friction at change time.
- Change scope threshold — how large a change must be to warrant a ledger entry. A low threshold captures everything but buries significant changes among trivial ones.
- Consequence tracking — whether entries are revisited to record what the change actually caused. Follow-up makes the ledger a learning record but demands ongoing stewardship.
- Authoritative-pointer freshness — how promptly each entry's link to the current version is updated. Lag here is what lets people act on a superseded spec.
When it helps, and when it misleads¶
Its strength is accountability with memory: months or years later, an organization can say not just what changed but why, who stood behind it, and what it made current — which is the difference between a defensible decision and an unexplained one. It is the standard answer wherever regulators, auditors, or successors demand that changes be justified and owned.
Its failure mode is the ledger kept as ceremony: entries created to satisfy a process, with rationales reduced to boilerplate ("per management request") and approvals rubber-stamped, so the record documents that a change occurred without preserving why it was wise. The classic misuse is retrofitting a rationale after the fact to defend a decision already made — a justification written to the conclusion. The discipline that guards against this is to open the entry before the change, require a substantive rationale and genuine review, and periodically revisit entries to record their actual consequences.
How it implements the components¶
change_context— each entry preserves the rationale, assumptions, and risk assessment behind the change, keeping the why attached to the what.authorship_or_actor_marker— the requester, reviewers, and approvers are named by role, making every change attributable.source_of_truth_reference— each entry links to the specification or procedure its change makes authoritative, so the current governing version is always locatable.
It does NOT order a live event by timestamp_or_sequence_marker or grade observations with evidence_confidence_marker — that is Incident Timeline; nor does it link an entity's episodes with cross_layer_index — that is Case History.
Related¶
- Instantiates: Layered Record Accumulation — it preserves the accountable decision-history that makes staged, controlled change interpretable.
- Sibling mechanisms: Incident Timeline · Case History · Version History · Commit History · Archival Layer · Learning Portfolio · Stratigraphic Record · Audit Log
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Creates a structured ledger of changes, rationales, approvals, and consequences across time, making its operative form a durable record, ledger, register, or trace whose value depends on preserving actual state or history.
Independent corroboration: The frozen evidence defines Change Ledger as 'Creates a structured ledger of changes, rationales, approvals, and consequences across time', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Management-of-change and configuration-control practice cohered the reasoned, approved record of modifications to controlled systems.
Related originating lineages:
- Accounting & Auditing — Ledger and audit traditions supply durable attribution, authorization, and reconstruction.
- Organizational & Management Science — Project governance supplies requests, approvals, consequences, and authoritative-version tracking.
Review resolution: Engineering design is the agreed primary lineage because configuration management keeps structured histories of approved changes, rationale, and downstream consequence. Accounting contributes ledger discipline and organizational management contributes ownership, making the record cross-disciplinary but not a novel Encyclopedia synthesis.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A change ledger and an Audit Log are easy to conflate but differ in intent. An audit log passively captures every action on protected data for later investigation; a change ledger deliberately records approved decisions with their rationale and sign-off. One is exhaustive and machine-written; the other is selective, human-reasoned, and forward-authored before the change lands.
References¶
[1] International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use. "Pharmaceutical Quality System". ICH Harmonised Tripartite Guideline Q10 (2008). Requires a formal change-management system in which proposed changes record their rationale and receive quality-risk evaluation and relevant expert review for technical justification. registry ↩