See what changed, who reviewed it, and what became effective
Review corrections, reviewer actions, approvals, notices, reopenings, and superseding record versions as an attributable history. Every material event keeps its actor or service identity, reason, time, evidence context, and relationship to the record version it affected.
Chronology is not proof. A history supports transparent review and accountable administration. It does not establish legal correctness, misconduct, or a payroll outcome.
Review History Viewer
One synthetic record, twelve material events in chronological order. Each keeps its actor, authority, reason, effect, and relationship — and one arrives late without rewriting the chronology above it.
Version 3 is current for review and approved. Version 1 was released externally on 08 Aug and the target still holds it. So this record is simultaneously “approved at v3” and “externally released at v1” — those are different statements about the same record, and neither cancels the other.
Source received
04 Aug · 06:58- Actor
- Terminal connector SRC-4471 · service identity, not a decision-maker
- Object
- Record TR-77841 · version 1 created
- Reason
- Scheduled capture
Recorded · not a human decisionValidation flagged missing context
04 Aug · 19:04- Actor
- System process · validation
- Object
- Version 1 · field: project reference
- Reason
- Required field absent for site work
- Result
- State: needs input
Processing is not approval or judgmentAssigned for review
05 Aug · 08:00- Actor
- Routing policy v4 · assigned to unit reviewer, Field Services North
- Authority
- Assignment only — not decision authority
Review is not approvalNotice sent to worker
05 Aug · 08:02- Notice
- Information required on your record
- Generated
- 05 Aug 08:01
- Sent
- 05 Aug 08:02
- Delivered
- 05 Aug 08:02
- Acknowledged
- Not acknowledged
Delivered · acknowledgement not receivedDelivery is not acknowledgement, and acknowledgement would not be agreement. These are three separate states and only two are known here.Correction requested by worker
06 Aug · 08:14- Actor
- Worker · requester role — not reviewer or approver
- Object
- Version 1 · field: project reference
- Reason
- Category: missing at capture · “Reference was not available on site that morning.”
- Result
- No change to the governing record — request recorded only
Request is not a correctionReviewer recused, reassigned
06 Aug · 11:20- Prior owner
- Unit reviewer A
- New owner
- Unit reviewer B
- Reason
- Category: separation of duties — prior owner was the record’s shift supervisor
- Continuity
- Prior activity remains attributable to reviewer A
Recusal recorded · no invisible delegationCorrection accepted · version 2 created
06 Aug · 15:42- Actor
- Unit reviewer B · scope: Field Services North
- Before
- Project reference: not provided
- After
- Project reference: PRJ-Northgate-02
- Reason
- Category: accepted worker context · evidence: worker statement
- Result
- Version 2 created and linked
Applied · version 1 preservedSupersedes version 1 · caused by correction request 06 Aug 08:14
Approved with condition · version 3 effective
07 Aug · 09:30- Actor
- Unit reviewer B · authority scope: Field Services North, period records
- Decision
- Conditionally approved
- Reason
- Category: context accepted · condition: project reference to be confirmed against the site register at period close
- Decision time
- 07 Aug 09:30
- Effective time
- 07 Aug 09:30 for review purposes
- Separation of duties
- Satisfied — approver was not the requester
Authorized human decisionSupersedes version 2 · condition open
Released for external use
08 Aug · 02:10- Actor
- Export service · scheduled run
- Object
- Version 1 — the package was prepared before the correction landed
- Result
- Sent to configured payroll target
Sent · acceptance separateDecision is not execution. Approval at version 3 did not retroactively change what had already been prepared and sent at version 1.Receipt returned
08 Aug · 02:14- Actor
- Target system · acknowledgement reference ACK-5510-1
- Returned
- Accepted · version 1
Acceptance is not semantic correctnessSite register confirmation · late-arriving event
Event 07 Aug · 16:05 · received 09 Aug 10:22- Actor
- Site register connector · delayed feed
- Object
- Condition on the 07 Aug decision
- Result
- Condition satisfied — project reference confirmed
Late arrival · original event time preservedInserted at its original event time with a late-arrival marker. The chronology you saw before this arrived is not silently rewritten, and source clock precision for this feed is limited to the minute.Reopened for downstream reconciliation
09 Aug · 10:30- Actor
- Payroll operations · reconciliation owner
- Trigger
- Failed verification — target holds version 1, current version is 3
- Result
- New linked review state · corrective event required
Reopened · reconciliation openReopened from the 07 Aug decision · related release 08 Aug
Reversal is not available for a sent external package, so this proceeds as a corrective event rather than pretending a rollback occurred.
Four separations the timeline never collapses
Every one of these was visible in the record above. Collapsing any of them would make a history that reads cleanly and describes something that did not happen.
Review ≠ approval
Assignment, comments, information requests, and escalation are review activity. None of them is a decision.
In the record: assigned 05 Aug, decided 07 Aug.
Request ≠ correction
A submitted request has no effect on the governing record until an authorized workflow changes it.
In the record: requested 06 Aug 08:14, applied 15:42.
Decision ≠ execution
An approval may change record state or authorize a downstream action. External execution and acceptance stay separate.
In the record: approved at v3, released at v1.
Delivery ≠ agreement
Generated, sent, delivered, and acknowledged are four states. Acknowledgement is still not consent or agreement.
In the record: delivered, never acknowledged.
Material corrections create a linked new version or an explicitly governed corrective event. Where reversal is not supported — as with an external package already sent — the history shows a compensating corrective event rather than implying a rollback took place. Prior versions and decisions remain historical with a successor link and a reason.
Change proof
Before and after, shown only where material and permitted — with units, time zone, and rounding included wherever they affect meaning.
- Project ref
- Not provided
- Duration
- 6h 49m
- State
- Needs input
- Externally
- Released 08 Aug, target holds this
- Project ref
- PRJ-Northgate-02
- Duration
- 6h 49m
- State
- Conditionally approved
- Externally
- Not yet reconciled
Duration did not change — only the missing reference was added. A correction that supplies context is a different event from one that changes hours, and the comparison makes that visible rather than asking for trust.
Notice proof
Communication state is tracked separately from the decision it describes, because a decision remains valid whether or not its notice was delivered.
Chronology, time zone & effective time
CurrentObjective: keep five different times distinct instead of flattening them into one column.
- Event time
- When the action occurred, per the authoritative source
- Receipt time
- When ZoikoTime recorded it, where materially different
- Decision time
- When the authorized decision was recorded
- Effective time
- When it became applicable for the configured purpose
- Notice times
- Generated, sent, delivered, acknowledged — all separate
- Late arrival
- Shown at original event time with a marker; prior chronology is not silently rewritten
Limitations: where source time precision or clock synchronization is limited, the limitation is shown rather than fabricating exactness. Default order is event time with a deterministic tie-breaker.
Actors, service identity & authority
CurrentObjective: never let a system look like a decision-maker, or a delegation stay invisible.
- Worker / requester
- Role and permitted identity — never represented as reviewer or approver
- Reviewer / manager
- Role, scope, assignment, effective authority, decision eligibility
- Service identity
- Connector or service name and version — never shown as a human decision-maker
- System process
- Validation, state transition, retry, notice orchestration — processing is not approval
- Delegated authority
- Delegator, delegate, scope, effective and expiry, decision linkage. No invisible delegation.
- Recusal
- Old and new owner, reason category, time. Prior activity stays attributable.
Limitations: a reviewer cannot exceed current permission or self-approve where separation policy blocks it. Where authority later changes, the historical decision stays as recorded — there is no retroactive relabelling.
Worker-facing review history
The worker in the record sees their own chronology — with no guilt labels and no pressure to admit fault.
Own changes
Chronological own-record events, version summary, current state, and material changes — own records and permitted organizational context only.
Track a correction
Submitted → assigned → information requested → under review → decision → resulting version → notice. No guilt labels at any stage.
See the decision
Authorized role, decision, reason, conditions, effective version, and next action. Confidential reviewer notes stay protected.
Rights preserved
Using the correction flow waives no privacy, grievance, appeal, legal, or contractual right. Help routes involve no lead capture or sales routing.
When history is incomplete
Fifteen states. None of them fabricates a chronology, reconstructs disposed content, or leaks a restricted event through an error message.
| State | Required behaviour |
|---|---|
| Loading | Skeleton for timeline and detail; context heading preserved; completion announced. |
| No material history | “No material review-history events are available for this record in your permitted scope.” |
| Restricted | A safe explanation, with no hidden titles, counts, or content. |
| Partial history | Available period and coverage, plus the missing, retention, or migration limitation. |
| Late event | Inserted with a late-arrival marker and an explanation that preserves prior chronology. |
| Missing linkage | The event exists but its linked version or evidence is unavailable — owner and recovery path shown. |
| Authority changed | The decision stays historical; current authority is shown separately. No retroactive relabelling. |
| Superseded | Successor and current link with reason; the prior event remains accessible where permitted. |
| Notice failed | The decision and history remain recorded; the notification failure is explicit and owned. |
| Permission changed while viewing | Access revalidated, newly restricted content hidden, safe context maintained — and no leak through the error. |
| Retention-limited | Allowed residual metadata and the period limitation. Disposed content is not reconstructed. |
| Migration-limited | Import batch, coverage, and transform reference, plus the missing prior-history limitation. |
| Service error | Selected record and filter context preserved, retry, a reference ID, and a route to the Help Center. |
| No JavaScript | Server-rendered direct answer, event list, limitations, and links remain usable. |
| Reversal unsupported | A compensating corrective event is shown rather than implying a rollback occurred. |
Loading
Skeleton for timeline and detail; context heading preserved; completion announced.
No material history
“No material review-history events are available for this record in your permitted scope.”
Restricted
A safe explanation, with no hidden titles, counts, or content.
Partial history
Available period and coverage, plus the missing, retention, or migration limitation.
Late event
Inserted with a late-arrival marker and an explanation that preserves prior chronology.
Missing linkage
The event exists but its linked version or evidence is unavailable — owner and recovery path shown.
Authority changed
The decision stays historical; current authority is shown separately. No retroactive relabelling.
Superseded
Successor and current link with reason; the prior event remains accessible where permitted.
Notice failed
The decision and history remain recorded; the notification failure is explicit and owned.
Permission changed while viewing
Access revalidated, newly restricted content hidden, safe context maintained — and no leak through the error.
Retention-limited
Allowed residual metadata and the period limitation. Disposed content is not reconstructed.
Migration-limited
Import batch, coverage, and transform reference, plus the missing prior-history limitation.
Service error
Selected record and filter context preserved, retry, a reference ID, and a route to the Help Center.
No JavaScript
Server-rendered direct answer, event list, limitations, and links remain usable.
Reversal unsupported
A compensating corrective event is shown rather than implying a rollback occurred.
What this module owns
Review History owns
- Chronological corrections and reviewer actions
- Approvals, decisions, conditions, and recusals
- Notice generation and delivery state
- Reopenings, supersession, and reversal handling
- Record-version changes and release impact
And does not duplicate
- See Policy Evidence — the policy version and deterministic rule trace
- Inspect Lineage — relationship topology and provenance traversal
- View Bundle — manifest, redaction, generation, delivery, expiry
- Worker Experience — the worker journey as a whole
What a history cannot establish
A complete-looking timeline does not establish that a decision was legally correct, fair in every jurisdiction, or sufficient for payroll, tax, employment, collective-agreement, or evidentiary requirements. It does not establish motive, misconduct, or worker performance — and it is not an immutability or admissibility claim.
No customer evidence
No customer names, logos, volumes, or outcome metrics appear here. None has been verified for this module.
A history that still explains itself years later
See how corrections, decisions, notices, releases, late events, and reopenings stay attributable — with the four separations intact and no silent overwrite.
Request Enterprise Demo
Review history questions
What changed, who or what initiated the event, which authorized person reviewed or decided it, why the change occurred, which record version became effective, what notice was sent, and whether a later correction or supersession changed the outcome. ZoikoTime preserves those relationships without treating the timeline as proof of legal compliance or worker misconduct.