Which Document Version Did the Approver Accept?

Bind document approval to a readable revision, its attachments and the permitted action. Keep AI summaries, later edits and missing historical evidence distinct.

Approval belongs to a review package, not a filename

A document approval should identify the version reviewed, the material supporting that decision and the action the decision permits. A green badge next to a filename cannot establish those facts. The file may have changed, an attachment may have been replaced, or the badge may describe an earlier stage that did not authorize release.

Consider a hypothetical purchasing workflow. A reviewer opens proposal D12, revision R7, with two supplier attachments. An AI assistant produces a short comparison of the alternatives. The reviewer approves the proposal for internal budget review. Later, an editor changes a delivery condition and replaces one attachment, while the same filename and approval badge remain. A downstream worker is asked to send the current package to the supplier.

The problem is not whether the reviewer clicked Approve. It is whether the system can show what was reviewed and whether that decision applies to the package and action now requested. Internal budget review is not supplier submission. The original decision may remain a valid historical fact while providing no authority for the new action.

This article proposes an engineering contract for that distinction. The example is synthetic, not an Ampity customer story. It does not establish legal signature validity, evidentiary admissibility or a required retention period. The workflow, privacy and legal owners must determine the actual approval purposes, permitted actions and record policy. The engineering acceptance question is whether a changed or unidentifiable package is held rather than silently inheriting an earlier decision.

Bind the readable package before requesting a decision

Define the package as more than the main document's revision number. Include the source document and revision, approved representation, attachments and their versions, relevant structured fields and the intended workflow action. A supplier attachment referenced by a live URL can change independently of the proposal. If it affects the decision, its accepted representation belongs in the package identity.

Record the scope under which the package exists: organization or tenant, document family and workflow stage. Two organizations can use the same filename or revision label. Neither a user-supplied identifier nor a friendly title should select the authority boundary. The backend must resolve the approved package from the workflow record under the current caller's authorized scope.

OWASP's transaction-authorization guidance distinguishes authentication from authorization of a specific operation. It calls for significant data to be identifiable to the user, server-side enforcement, protection against modification and a final authorization check before execution. Applied to this proposed workflow, that means naming both the reviewed package and the action, not treating login or a previous click as general permission.

Show a readable review representation with the significant terms and supporting material accessible. If the approval is limited to selected fields, state that scope directly. Do not label a partial review as approval of the whole document. A digest can detect that bytes differ, but a digest does not prove the reviewer saw or understood the package. Retain the actual representation and its relationship to the decision.

For D12/R7, the request might say that the decision covers a specified internal budget amount and the attached delivery assumptions, for budget review only. That is a proposed scope, not a recommendation for every purchasing process. The responsible owner must decide which values are significant and whether the interface presents them clearly enough for the actual consequence.

Keep the accepted version retrievable

A revision identifier that cannot retrieve its representation is incomplete evidence. Decide where the accepted package is retained, how authorized reviewers retrieve it and how long that purpose permits retention. Preserve the mapping between the source revision and any rendered PDF or review view. If the renderer omits comments, hides tracked changes or recalculates a linked value, record which representation was actually offered for approval.

Google Drive's revision-management documentation describes provider-specific revision retrieval and retention behavior. It notes that some older revisions can be purged and that revision lists can omit older entries for files with large histories. Its blob-file retention controls are not a universal rule for every document type. A workflow must therefore verify its actual retrieval contract rather than assuming that version history is a permanent approval archive.

If your integration uses an external document store, test the exact file type, revision lookup and access path. A current-file download is not proof of a historical revision. Returning the latest file when an old revision is unavailable makes the evidence look complete while changing its meaning. Return a specific evidence-unavailable state and the responsible next owner instead.

Protect retained packages from casual replacement, while supporting authorized correction and disposal. A correction should create an attributable record rather than rewriting the original acceptance evidence. Apply access controls to historical previews, exports and attachments as well as the current document. An old approval package may contain information that should no longer be visible to someone who can still see the main workflow title.

Retention is not a reason to copy every document indefinitely. Record the approved purpose, permitted locations, derivative exports and deletion responsibilities. Where the policy no longer permits keeping content, preserve only what the policy allows and describe the resulting evidence limit. Engineering cannot promise a retrievable original after an authorized deletion or use a checksum to reconstruct missing content.

Explain which changes require another review

Classify a change by its effect on the approved scope, not by whether an editor calls it minor. A punctuation correction, revised quantity, changed recipient and replacement attachment do not necessarily have the same consequence. The workflow owner must specify which changes invalidate an executable approval and which changes require a new representation without changing that authority.

Preserve the earlier decision as history. If D12/R8 changes the delivery condition covered by R7's review, mark the current package as requiring review under the applicable policy. Do not move the old approval to R8 or erase the fact that R7 was accepted. Show both facts: an earlier package was approved, and the current package is not approved for this action.

Where a policy permits a non-significant change, record the classification, rule and attributable basis. Do not let an editor set an unrestricted cosmetic flag that bypasses review. Include changes outside the visible paragraph text: attachments, structured amounts, locale, recipient, external references and the selected execution destination. An unchanged document can still be used for a different action that the earlier decision never permitted.

An AI assistant can help identify differences and organize the review request. Its summary is a derived representation, not proof that the underlying changes are insignificant. Record which source revisions and attachments the comparison used, and disclose incomplete extraction or unsupported file content. A fluent statement that nothing material changed must not automatically carry authority into the new package.

If a summary omits a changed condition, the workflow should still hold a significant revision mismatch under the authoritative rule. Human review may resolve that hold, but it must create a decision for the identified package and action. Asking an approver to accept an unbound summary repeats the original gap in a more convenient interface.

Record who decided, what they decided and what remains permitted

Retain the approver's authenticated identity, role or delegated scope at the decision, package identity, significant representation reference, workflow action, decision and time. Record the policy or rule that interpreted the decision. Separate this record from the user's current profile, which can change later. A display name is not a stable identity, and the application should not reconstruct old authority solely from today's directory membership.

Represent multi-stage approval explicitly. Content acceptance, internal budget review, compliance review and external release can have different owners and packages. Two reviewers saying Approved does not necessarily complete one stage if they reviewed different attachment versions. The stage result must explain which required decisions cover the same intended package and permitted action.

Before using an approval, verify that the package and requested action still match and that the grant remains usable under the current workflow rules. An expired, withdrawn or already consumed grant is not renewed by reopening the document. Current executor permission is also separate from the approver's earlier permission. A historical decision can remain authentic even when a worker must no longer act on it.

Bind the final local transition to the expected package version using the implementation's concurrency contract. A check followed by an unprotected later write leaves a gap for replacement. External execution has its own preconditions and receipt requirements; a locally approved package cannot make an independent supplier system atomic. When the destination result is unknown, preserve the original operation identity and investigate instead of treating fresh approval as permission to send another copy.

This is why the record should distinguish reviewed, permitted for this action, dispatched and confirmed. A successful approval endpoint says nothing by itself about supplier receipt. A delivery receipt says nothing by itself about whether the transmitted representation matched the approved one. Reconcile the actual package sent with its authorization and destination evidence.

Test replacement, missing evidence and incomplete summaries

Use synthetic packages and an inert submission adapter. Specify the expected outcomes before observing the candidate. Start with a correctly scoped package that can complete the intended stage, then replace the main revision, replace one attachment and change only the intended action. Each test should show whether the prior decision remains historical, remains usable or must be held under the declared policy.

Test a stale browser that displays R7 while submitting a reference to current R8. The backend must not infer approval of R8 from that request. Test two users approving different package variants under one filename. The defining failure condition is a usable stage approval for a package that no required approver actually reviewed.

Remove access to the historical representation and separately simulate a revision lookup that returns only the latest file. Missing evidence and wrong-version retrieval are different failures, but neither should be reported as verified historical content. Check that the user sees an understandable hold and an owner, not an apparently approved file with a silent fallback.

Give the AI comparison a missing attachment and a changed significant term that its summary does not mention. The authoritative package comparison should still detect the relevant mismatch; the interface should not claim a complete review from incomplete inputs. Include a deliberately permissive candidate that transfers the approval by filename, so the observer demonstrates that the tests reject the behavior they are meant to prevent.

Finally, inspect the retained decision after restart and export. The exported package should identify its actual version and preserve the limits of the original review. An attractive PDF must not replace the approval evidence with the current document. Record unresolved cases explicitly and classify missing destination evidence as inconclusive, not as proof that nothing was sent.

Use a package-binding worksheet for the next release

For the hypothetical proposal workflow, the following worksheet identifies five distinct evidence families. These fields belong in a structured acceptance record as well as the operator view. The actual policy owner must approve the significance rules and retention purpose. Passing these checks establishes scoped engineering evidence, not legal validity or a universal approval standard.

| Evidence family | What to retain or verify | Reason to hold use of the approval | | --- | --- | --- | | Package identity | Scoped source revision, attachment versions and accepted representation | Current package differs from the reviewed package | | Decision scope | Approver identity, workflow stage, permitted action and policy reference | Earlier decision does not cover the requested action | | Change classification | Significant differences and attributable classification basis | Materiality is guessed or an attachment comparison is incomplete | | Historical retrieval | Authorized readable content matching the accepted version | Missing version or silent current-file substitution | | Execution evidence | Current permission, package precondition, operation identity and receipt | Grant is unusable or destination outcome remains unknown |

Assign one owner to each hold and name the next evidence check. Do not ask the reviewer to approve repeatedly while the application still cannot identify the package. Fix the binding or retrieval gap first. This avoids turning human approval into a ritual that hides an engineering defect.

For a next step, complete this worksheet for one existing approval stage and run the replacement and missing-version fixtures before widening the workflow. Use the approval-lifetime review for expiry and current authority, and the document-intake pilot for incomplete input and review capacity. Bring one scoped acceptance record to a backend systems review or an agentic workflows review. Reading and resource downloads do not require an email address; asking Ampity to contact you remains optional.