A current quantity of seven does not explain why six was changed. A useful history needs enough context for another person to understand the decision.
The earlier article preserved documents as sent. Here the new SQLite lab records document changes and events together, while making the limits of that history explicit.
Current state and history answer different questions
Current values support the next task. History explains how those values came to exist. Treating them as one row can let an edit overwrite the explanation of an earlier decision. I separated documents from events and recorded the synthetic state before and after every successful transition.
An event includes document identity, company scope, actor, action and reason. Its snapshots retain both write version and content revision, distinguishing submission from a quantity edit. A local database sequence orders events instead of asking a formatted time string to establish order. That sequence does not claim to order every event across unrelated systems.
A field difference does not explain its reason
A comparison from six to seven shows which value changed, but cannot tell whether it was a customer request or an input correction. Commands therefore require a short nonempty reason. The tests use fixed synthetic reasons rather than real business material. The model still makes the distinction between a changed value and the reasoning behind it inspectable.
A company screen should not expose every internal field as a raw diff. Apply understandable labels and units, then project only fields the reader may access. Reasons also need an input policy that does not invite unrestricted sensitive text. Those policies depend on purpose and audience; the shared package contains no client change reasons.
Separate a successful change from a failed attempt
A version-conflict response did not change the document, so it does not become a successful business event. Replaying an earlier request result also does not append another event. Without that rule, repeated clicks could look like repeated changes. Business history and operational request-attempt logs need different definitions.
This does not mean failures should never be logged. A service can retain error and request tracing under an appropriate policy, without counting those entries as completed sales or approvals. In this lab, events represent successful transitions, while tests compare rejection results and unchanged records. It is not an implementation of a complete operational logging service.
Prevent a changed document without its event
Saving a document and adding its history in a later function leaves a gap if the second operation fails. Appending history first has the inverse risk. The new code updates the document and inserts its event in one SQLite transaction, alongside the follow-up queue and completed request result.
An injected error leaves the initial document version unchanged and no event, result or queue row behind. That is evidence of atomicity in this local synthetic database. It does not extend the same guarantee to every external provider, nor make records tamper-proof against database administrators. An append-through-API history and independently protected audit evidence have different trust levels.
Leave enough context for the next reader
Staff see history only for their assigned records; coordinators and owners stay within their company. A separate test verifies that another company’s events are absent. Real adoption requires a server-verified principal and permissions, not an Actor copied from a request. Hiding a history tab alone cannot enforce that boundary.
The package viewer exposes actual local submission and approval event snapshots, without client ledgers. Production decisions still include retention, sensitive fields, reason policy and the people entitled to audit. I focus the article on which change was recorded with which context, rather than the mere existence of a history indicator.