How document results reach reporting¶
A recorded document review, processing result, prepared signature or release can supply evidence to reporting. Zerohive keeps a saved copy of that evidence so background recovery can send the same information again. This helps investigate missing results without asking someone to repeat the original business action.
This page explains the implemented background mechanism. It does not add a reporting-repair screen or establish that every result is already visible in a deployed report. Read document-work outcomes for the meaning and limits of each result, and signed files for the difference between preparing a signature and completing its source task.
Distinguish the stages¶
| Stage | What it means | What still needs confirmation |
|---|---|---|
| Business action recorded | The relevant source has recorded its result | Whether the surrounding workflow or delivery is complete |
| Reporting evidence saved | The document service has retained a specific version of the evidence | Whether it has been delivered and accepted downstream |
| Evidence sent | A background publication has been attempted | Whether the receiving service processed the intended version |
| Daily inventory prepared | A source inventory identifies the expected document evidence for a UTC day | Whether all expected entries arrived and reconciliation completed |
| Evidence sent again | Recovery resends the original saved evidence | Whether the receiving report has caught up and presents it correctly |
A successful file upload or view does not by itself create one of these completed-work outcomes. A reporting delay also does not by itself show that the document action failed. Check the business item and the report separately.
Preserve the original meaning¶
Saved evidence identifies the original event, its revision and the exact content that was recorded. A correction can add a later revision while preserving history. Recovery resends the stored content and its original trace references; it does not rebuild a more favorable result from the document's current state.
For example, if a recorded review is corrected, both its identity and revision matter. Repeated delivery of the same revision is not a second review. A newer revision is not automatically a second piece of work either. The receiving reporting rules must interpret corrections and duplicates correctly; the sending mechanism alone does not establish a final score or a performance judgment.
The checks protect consistency between saved evidence and the requested recovery. They do not independently verify the underlying business decision, resolve an employee's responsibility or prove that a recipient read a released document. Those questions remain with the source workflow and its evidence.
Why a daily inventory matters¶
The document service groups reporting evidence by organization, activity type and UTC day. The inventory records which saved event revisions belong to that group. A day with no events still has an explicit empty inventory, so an empty day can be distinguished from missing information.
Once the first inventory for that group is saved, an exact repeat reuses its original details. A later attempt with different contents is rejected for investigation. This avoids silently replacing the agreed list during recovery; it does not promise that every late result has already been reconciled.
UTC day boundaries may differ from a reader's local calendar day. An inventory count describes reporting-evidence entries, including revisions. It is not a count of unique documents, hours worked, successful deliveries or people whose performance has been accepted.
When a result is missing or appears twice¶
Start with the original business item. Confirm its current result, document version and any correction history available through the supported source journey. Keep the item reference, organization, approximate time and the report in which the discrepancy appears. Share those details through your organization's normal support process, together with the visible error or reference if one was supplied.
Avoid repeating a completed review, release or signing action solely to make a report update. That can create new business work rather than repair the original reporting record. Support needs to determine whether the source result, saved evidence, delivery, reconciliation or report presentation is the incomplete stage.
Recovery can resend only an exact matching saved revision with intact content. A changed inventory, missing revision or failed integrity check requires investigation. It is not automatically fixed by refreshing the page, uploading the file again or selecting a different outcome.
What managers and executives can rely on¶
Use the business record to understand what happened and the reporting context to understand how that result was counted. Preserve the distinctions between a rejected review, a late result, an unresolved cause and a confirmed responsibility. The outcome explanation describes the information that is and is not supplied.
The implementation supports traceable recovery, but this draft does not establish achieved delivery latency, complete report coverage or an organization-wide assurance claim. Operators and engineers have the private protocol reference in GitHub. Full delivery, concurrent recovery, downstream interpretation and reader acceptance remain to be verified.
Reporting journals also have a data lifecycle. They are included in this service's bounded organization export and deletion behavior; they are not a promise of indefinite retention. See expiry and document-session data.