See exactly which
policy version
applied — and why
Policy evidence in ZoikoTime shows the exact policy version and context used for a time record, the source facts evaluated, the deterministic conditions that matched, any approved exception or precedence rule, the resulting classification, and the human-review boundary.
Historical evidence stays tied to the record's effective context. The current policy is not silently substituted.
.png)
Policy Evidence Viewer
A synthetic record with its full deterministic trace. Every condition shows a text label and an icon — never colour alone — and the matched rule is named in plain language rather than left as an internal code.
Record TR-77841 · version 3 · 04 Aug 2026
Field Services North · evaluated 04 Aug 19:04 CEST · all values synthetic
Field North Working Time · FN-WT
v3 — pinned to this record
01 Aug 2026 – 09 Aug 2026
Superseded by v4 on 10 Aug
Workforce policy, Field division
Yes · 28 Jul 2026
Field Services, North entity
DE — configuration context only
Authoritative for this scope
Entity-level assignment
Inherited from Field division, two fields configured locally
Field technicians, North
Northgate site
Rotating shift pattern RS-2, version 5
One approved exception applied — see step 5
04 Aug 2026 19:04 CEST
Shift boundaries and break record
Check-in 06:58, check-out 14:12, break 45m · source: terminal SRC-4471 · received 04 Aug 06:58 and 14:12 · Europe/Berlin · quality: verified for this scope
Worker in scope of FN-WT v3
Field technician · North entity · Northgate · shift pattern RS-2 v5 active on the record date
Worked duration exceeds standard shift threshold
Operator: greater than · parameter: 7h 00m standard · evaluated value: 6h 29m net of break
Break duration meets minimum for shift length
Operator: at least · parameter: 30m for shifts over 6h · evaluated value: 45m
Required project reference present
Operator: present · parameter: required for site work · evaluated value: absent at time of evaluation
Standard shift with compliant break — FN-WT v3, rule R-14
Purpose: classify a within-threshold field shift where break requirements are satisfied · precedence: standard, rank 3
Site travel allowance EXC-0231
Scope: Northgate site, Aug 2026 · reason category: temporary access restriction · authority: Field operations director · conditions: applies to first shift of day only · start 01 Aug · expiry 31 Aug · review 24 Aug · fallback: standard rule R-14
Net duration with rounding and time zone applied
Method CALC-v7 · rounding: nearest minute · time zone Europe/Berlin with DST resolved at capture · units: hours and minutes · 7h 14m gross, less 45m break, plus 20m allowance
Standard field shift · 6h 49m classified
Classification version CLS-v12 · evaluated 04 Aug 19:04 CEST · result state: produced, pending review
Information required, then authorized human review
The project reference could not be evaluated, so the record needs context before review completes · owner: unit reviewer, Field Services North
Blocked for the configured next step
Not eligible for export until the information requirement clears and review completes. This states configured eligibility — it is not a payroll or disciplinary decision.
One condition could not be evaluated because a required fact was absent, so the trace is complete but the record is not. FN-WT v3 is pinned here and remains pinned even though v4 is now current. This trace shows which rules ran and what they produced — it does not establish that the policy was legally sufficient, that every source fact was correct, or that any subsequent human decision was justified.
Why this policy, for this record
Applicability is evidence in its own right. "The policy applied" is not an answer — the answer is which assignment, which inheritance path, which population, and which schedule context put this record in scope.
Assignment evidence carries
- Assignment source and whether it is inherited or local
- Which specific fields were configured locally, and by whom
- Worker population and entity, team, or location scope
- Schedule or shift pattern and its version
- Any exception or override, with its own authority
- The evaluation timestamp and time zone
Inheritance is shown, not flattened
Inherited policy
Source scope, source policy and version, the inherited fields, the target scope, and the effective period — so a reader can see what came from above.
Local configuration
Delegated fields only, with the local owner, the reason, the effective period, and the approval where one was required. A local change outside delegated fields is not possible, and the record shows the delegation boundary.
Policy authoring, assignment, publication, and rollback happen in Administration & Policy Controls. This viewer is read-only by design — inspecting evidence and changing configuration are different authorities.
Historical version versus current
The version that applied stays pinned. Comparing it to the current version is useful; substituting the current version would be a falsification.
FN-WT v3 · applied to this record
FN-WT v4 · current, not applied here
A current policy cannot reclassify a historical record
Two parameters changed at v4. If v4 were applied retroactively, this record's threshold condition and its project-reference requirement would both evaluate differently — which is precisely why the historical snapshot is pinned. Changing a policy going forward is normal governance; silently re-deciding past records under it is not.
If the version changes while you are viewing, the historical snapshot stays pinned and the comparison shows a refresh notice. The evidence basis is never updated silently underneath you.
Exception, precedence, and override evidence
Eight evidence objects. The two at the end matter most: an expired exception and a withdrawn policy remain attributable if they affected the record.
| Evidence object | Minimum fields and rule |
|---|---|
| Inherited policy | Source scope, source policy and version, inherited fields, target scope, effective period. |
| Local configuration | Delegated fields only, local owner, reason, effective period, approval where required. |
| Approved exception | Exception reference, requested scope, reason category, evidence references, approver and authority, conditions, start, expiry, review date, fallback. |
| Emergency override | Named authority or function, reason, scope, duration, review-after, status, post-event review. Shown only where capability and permission support it. |
| Precedence decision | Competing policy or rule references, the precedence rule and version, outcome, owner, evaluation time. |
| Conflict | Each relevant candidate, why it is unresolved, the blocked effect, the owner, and the remediation route. No fabricated result. |
| Expired exception | Historical use remains visible if it affected the record. Current state shows as expired — not silently removed. |
| Withdrawn policy | Historical application remains attributable, with withdrawal status and reason summary where authorized, and downstream implications where known. |
Inherited policy
Local configuration
Approved exception
Emergency override
Precedence decision
Conflict
Expired exception
Withdrawn policy
An exception that has since expired still explains a record it once changed. Removing it from the evidence when it lapses would leave a record whose result no longer follows from its visible rules.
What a classification cannot decide
Deterministic classification can route or describe a configured record state. That is the whole of its authority.
Classification does not determine
Payroll outcomes · discipline · misconduct · termination · legal rights · or any other consequential outcome. A downstream "blocked" state describes configured eligibility for a next step — it is not a decision about a person.
What a worker sees
Permitted record facts, the historical policy and version label, a plain-language rule explanation, the result state, the review state, and who can help.
What a worker can do
Where configured: ask for clarification, request a correction, add permitted context, see pending status, and receive the outcome with its history.
Restricted policy detail
Where full text is restricted, the category and purpose are explained along with why detail is unavailable. Hidden information is never exposed through counts, titles, or tooltips.
Neutral language only
No fraud, dishonest, suspicious worker, guilt, automatic violation, noncompliant worker, low performer, productivity risk, AI confidence, or risk score. None of these exists in this product.
When policy evidence is incomplete
The governing rule for all of these: never substitute current policy, never fabricate a result, never leak restricted content, and never announce that a hidden object exists.
| State | What is shown |
|---|---|
| Loading | Skeletons preserve layout and loading is announced. Never a temporary zero or “no policy.” |
| No evidence | “Policy evidence is not available for this record,” with whether the record has no configured classification or the scope is unsupported. |
| Missing historical snapshot | “The policy version used for this historical record is unavailable.” Current policy is not substituted. Limitation marked, remediation routed. |
| Policy source stale | Last verified date, owner, affected fields, and whether new evaluations are blocked or review-required. |
| Conflicting assignment | Competing references with safe labels, affected scope, owner, and the policy-review route. No fabricated result. |
| Jurisdiction context missing | The required context and an authorized review path — and no legal conclusion. |
| Source fact unavailable | The missing fact category, source health where permitted, and the impact on evaluation. |
| Restricted detail | A role-safe summary and “Some policy details are restricted for your role.” No leak through content, count, or title. |
| Permission denied | A clear message plus role, account, and support routes — with no confirmation that a hidden object exists. |
| Migration-limited | Migration batch, coverage, and transform version where permitted, plus a missing-history notice. |
| Retention-limited | Residual metadata, retention context, and a support route where allowed. |
| Version changed while viewing | The historical snapshot stays pinned; the comparison shows a refresh notice. The evidence basis never updates silently. |
| Service error | Selected context and filters preserved, retry, a reference ID, and a safe support path. |
| No JavaScript | Server-rendered direct answer, snapshot summary, ordered rule trace, limitation text, FAQ, and core links. |
Loading
No evidence
Missing historical snapshot
Policy source stale
Conflicting assignment
Jurisdiction context missing
Source fact unavailable
Restricted detail
Permission denied
Migration-limited
Retention-limited
Version changed while viewing
Service error
No JavaScript
Role visibility
Detailed views are customized depending on the user credentials and regulatory requirements.
Worker
Own permitted facts, policy version label, plain-language explanation, result and review state, support route.
Reviewer
Source facts, rule trace, worker input, conflicts, prior history, policy version, permitted actions, deadline and escalation.
Policy owner
Policy metadata, version, applicability, and the remediation route — but editing and publishing happen in the administration workflow.
Nobody, via this viewer
Restricted policy text, legal advice, internal security rules, other workers, confidential approver notes, hidden organizational topology.
What this module owns
Evidence surfaces overlap easily and then contradict each other. The boundaries are explicit.
Policy Evidence owns
- Historical policy and version
- Applicability and assignment
- The deterministic rule trace
- Exception and precedence context
- The result and the human boundary
And deliberately does not duplicate
- Inspect Lineage — the provenance and relationship chain
- Review History — the chronological record of events
- View Bundle — the purpose-bound manifest and export workflow
- Worker Experience — the worker journey as a whole
- Administration & Policy Controls — authoring and publication
.png)
Policy evidence questions
The version that was effective for the record's date and scope is pinned to that record. The snapshot shows the policy name, version, effective range, owner, approval, scope, jurisdiction context, and whether it has since been superseded — as with FN-WT v3 above, which remains authoritative for its record even though v4 is now current.
By examining the step-by-step deterministic trace. The viewer displays all source facts, applicability validations, matching conditions, and specific rules evaluated—with plain-language explanations and accessibility icons—showing exactly how the final classification state was derived.
No, ZoikoTime avoids non-deterministic AI for direct classification. All classifications run on clear, governed, and deterministic policy rules so that they can be fully explained, verified, and traced without requesting trust in a statistical model.
No. A policy version that applied to a record remains pinned. Substituting a current policy version retroactively would alter historical data integrity, which is why historical evidence is always tied to its effective version snapshot.
No. The system traces rule execution and classification outputs based on configured parameters. It does not establish that the policy was legally sufficient, that every source fact was correct, or that any subsequent human decision was justified.
Exceptions are logged as distinct evidence objects detailing the exception reference, requested scope, authority level, start and expiry dates, review deadlines, and fallback rules. The trace explicitly highlights where an exception altered standard calculations, such as in step 5 of the trace viewer.
The viewer displays a role-safe summary stating that details are restricted. To maintain security boundaries, hidden metadata or rules are never exposed through counts, names, or hover tooltips.
No. A classification routes or describes a configured record state and states export eligibility. It does not determine payroll outcomes, disciplinary actions, misconduct, or legal rights on its own.