How to correct a condition record without erasing its history
Learn when to edit a draft, void a submitted condition record, or replace it while keeping the earlier observation and correction reason available.
By AuditIt Editorial Team · Fact checked
What to know
- Edit an in-progress draft; after submission, use a reasoned void or replace action.
- Void when no successor is needed; replace when a corrected observation should follow the earlier item.
- Review the earlier item, status, correction reason, and successor together before making a separate operational decision.
A hire record says a telehandler left the yard at 1240 hours. Later, someone checks the meter photograph and spots the transposed digits: it read 1420. The tempting fix is to type over the first number. The tidy screen comes at a cost, though. Nobody reviewing the record can see what was first submitted, why it changed, or which value replaced it.
That is the point of a useful condition record correction history. If the observation is still a draft, correct the draft. If it has already been submitted, use a reasoned void or replace action and keep the earlier item in view.
The distinction works for an hour-meter entry, a checkout note, or a photograph attached to the wrong field. It is a recordkeeping method for an authorized reviewer—not a shortcut to a conclusion about damage, safety, or fault.
First ask whether the record is still a draft
Before choosing a correction action, check the stage status.
While an AuditIt stage is in_progress, a draft field can be updated. Current draft-mutation endpoints stop working after that stage is submitted. At this point, fixing a typo is simply draft work; there is no earlier submitted observation to preserve.
Once the stage is locked, the job changes. Silently rewriting a submitted value would hide the path from the first observation to the corrected one. Current AuditIt flows instead expose deliberate void and replace actions on locked, non-voided stages. Each action needs a reason.
The practical rule is short: edit an open draft; explain a correction to a submitted record.
Void and replace answer different questions
Use void when the submitted item should no longer be treated as active and there is no successor to put in its place. A duplicate entry is a straightforward example. The row receives a voided status and keeps the recorded reason.
Use replace when a new observation should take the earlier item's place. AuditIt's current entry-replacement response identifies both the voided entry and its replacement. The implementation test describes this as append-only evidence history rather than an in-place edit.
A useful correction reason says what was wrong with the record, not what a later investigation ought to conclude. “Transposed digits on checkout” or “photo attached to the wrong field” gives a reviewer context. “Operator caused the damage” tries to turn the correction field into a verdict it cannot support.
What remains available for review
In current AuditIt list and comparison contexts, voided or replaced entries may still be returned so the corrected evidence stays visible. The same status model applies to media: a photo can be active, voided, or replaced, and a list may return the earlier file with a warning state.
On the mobile workflow, original rows remain visible with their void or replacement reason and successor identity. That gives the next reviewer a much better question than “Which number should I trust?” They can see 1240 as the earlier entry, 1420 as its successor, and the reason connecting them.
Those rows form part of the audit ledger—the durable history of stages, entries, events, manifests, signatures, hashes, and verification state. The ledger is the reviewable record; it should not be described as a backup file or as proof that the corrected observation is true.
Work through the meter-reading correction
Return to the fictional telehandler. The first entry says 1240, while the photograph shows 1420.
- Check the stage. If checkout is still in progress, correct the draft to 1420. No void or replacement is needed.
- If checkout has already been submitted, replace 1240 with 1420 and record a plain reason such as “transposed digits on checkout.”
- Leave the meter photograph attached if it is the right photograph. If the photograph itself is wrong, correct the media item rather than deleting context from the field entry.
- Review the earlier entry, successor, photograph, reason, and timestamps together. Let an authorized person make any separate operational decision.
There is no benefit in making the history dramatic. A concise reason and a visible predecessor usually tell the story better than a long defence written after the fact.
Do not let one word—void—hide three statuses
AuditIt uses similar language for three separate objects, so name the object whenever you discuss a void:
- A voided entry or media item remains part of that item's correction history, with its reason and any successor relationship.
- A voided audit is read-only for review.
- A voided report is one report-file status, alongside generating, ready, and failed. It does not mean every observation in the audit disappeared.
Keeping those nouns attached prevents a common handoff problem: “the report was voided” should not be paraphrased as “the evidence was deleted.”
Where AuditIt fits
AuditIt supports reasoned entry and media corrections in condition-record workflows, including checkout/return and one-visit templates. A reviewer can follow the earlier item, its status, the reason, and its successor instead of receiving only the last value on screen.
AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability. For the related integrity boundary, read tamper-evident vs tamper-proof and what AuditIt public report verification actually checks.
To start a structured condition record, create an AuditIt account.
Direct answers
Frequently asked questions
Can I edit a submitted condition record?
Not through the draft-edit path. Draft updates belong to an in-progress stage. After submission, current AuditIt flows use a reasoned void or replace action so the earlier item can remain available for review.
When should I void an item instead of replacing it?
Void it when the submitted item should no longer be active and no successor is needed. Replace it when a corrected value, note, or file should become the successor. In both cases, write a reason that describes the record correction rather than assigning blame.
Does replacing an entry delete the first value?
The current replacement flow voids the earlier entry and creates a successor with a separate identity. List contexts may still return the earlier row and its status. This describes the product's correction flow; it is not a promise that data can never be lost outside that flow.
What should a correction reason include?
Keep it specific and observable: “transposed digits,” “duplicate entry,” or “photo attached to the wrong field.” Avoid conclusions about cause, safety, compliance, or liability unless an authorized process has established them separately.
What happens when a submitted photograph is corrected?
Media rows can be active, voided, or replaced. Current list contexts may include the earlier voided or replaced file with a warning state, while a replacement can link to its predecessor. Review the media status and reason with the rest of the record.
If software summarizes the record, should it use only the newest value?
No. A useful summary should keep the earlier item's status, the correction reason, and the successor relationship together. Showing only 1420 would hide why 1240 appears in the history. A person still needs to review that context before making an operational or liability decision.
Sources
- correction history
- void
- replace
- condition records
- audit ledger
