These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Data Entry & Validation
- Features
- Correction evidence
Correction evidence
Keep correction tasks and earlier execution records visible.
OverviewFailed Runs×
Data Entry & Validation · Correction evidence
New
Failed Runs
Operation runs
| Source | Operation key | Source revision | Started at | Status | Failure reason | |
|---|---|---|---|---|---|---|
| IB-84339 | OK-283 | 410 | 12 Oct | Failed | Cut to length | |
| IB-96361 | OK-500 | 790 | 20 Oct | Failed | Weld frame | |
| IB-53921 | OK-911 | 460 | 10 Oct | Failed | Drill and tap | |
| IB-50197 | OK-184 | 520 | 14 Oct | Failed | Deburr | |
| IB-96171 | OK-989 | 830 | 27 Oct | Failed | Assemble |
6 of 6 records
OK-283Operation runs · OR-68823
FailedSourceIB-84339
Source revision410
Started at12 Oct
Failure reasonCut to length
What you can do
Correction evidence in daily work
A correction begins with the existing batch revision and its completed execution record still visible. The correction owner records a follow-up title, assignee, due date and resolution. Evidence documents retain source attachments and verification details. State history records each batch transition, actor and reason so a later reviewer can reconstruct the sequence.
How the work is organized
- Earlier execution. Retain the prior run, completed steps and receipt.
- Successor work. Assign a follow up and prepare a new batch revision for review.
- Verification. Record the corrected output, decision and resolution against the batch.
The Correction Owner takes a follow up from a returned decision or a later target discrepancy. The earlier operation and receipt remain available so the team can see what was already executed. A successor revision receives its own validation results and Independent Reviewer decision. If the target must be corrected, the new operation step records its output identity and receipt. The follow up remains open until the owner records what was verified.
What to agree during setup
For an executed revision, agree how a compensating output will be identified in the target system before creating a successor revision. The execution operator checks the prior step outputs and receipts. The independent reviewer examines the corrected source and records a new decision for its revision. The correction owner closes the follow up only after verification evidence is available.
Agree who can request a correction, who owns its due date and who checks the final target state. The Validation Steward confirms any revised mapping; the Independent Reviewer decides the successor revision. Preserve the earlier source hash, decision and operation evidence. When a compensating target action is needed, identify its output and receipt so the Correction Owner can explain both the original and corrected states.
Check the handoff on an actual case
Suppose a committed row was mapped to the wrong target value. The team retains the earlier receipt and run, creates a successor revision with the corrected mapping and records the compensating target output. A new review decision authorizes the corrected partition. The follow up records who verified the final target state.
Trace the wrongly mapped target value back to the earlier operation step and receipt. Show the revised mapping and new row outcome to the Independent Reviewer. After approval, compare the compensating output with the target and record the evidence in the follow up resolution before marking it completed.
What your team sees
- Open Follow Ups — Find assigned correction and verification tasks with due dates.
- Returned Decisions — Trace the reviewer reason behind a correction request.
Follow the work through
See the related process and the data model to rehearse this handoff with a real submission.
What it keeps track of
Data model- Follow up actions
- Correction and verification tasks raised against validated batches.
- Evidence documents
- Source documents and receipt evidence attached to a batch.
- State history
- Immutable status transition log for every validated batch.
- Import batches
- Staged inbound data submissions validated against a frozen rule set.
- Operation runs
- Workflow-maintained run ledger for parse, commit and correction operations.
- Review decisions
- Independent reviewer sign-off or return against an exact source revision.
Who uses it
Permissions- Correction Owner
- , Independent Reviewer, Execution Operator.
Set up Data Entry & Validation your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.