Operator guideEN

Reporting / Control Verification

Monitoring workspace for integrity verification runs, compliance scoring, baseline control, and component-by-component failure review.

How to use this guide

Start with the main guide

Follow the explanation and examples first. Extra definitions and formulas are available below when you need them.

What this page shows

Control Verification is the operator-facing monitoring page for system integrity checks. It combines:

  • historical verification runs
  • compliance-style summary cards
  • manual verification trigger
  • baseline management in the detail dialog
  • component-level comparison against the previous successful verification

When to use it

  • confirm that automatic verification is still running within the expected daily cadence
  • review recent failures or partial verification runs
  • inspect which components failed and whether any critical areas were affected
  • trigger a manual verification before or after sensitive infrastructure changes
  • mark one successful run as the current trusted baseline

How to read it

The visible summary cards are stored verification aggregates:

  • Total Verifications counts runs from the last 90 days
  • Avg Execution Time is the rounded average runtime of non-null executions from the last 30 days
  • Critical Failures counts recent runs where the critical-components array is not empty
  • Recent Failures counts failure and partial runs from the last 24 hours

These cards come from a separate statistics endpoint and do not follow the table filters below. The current subtitle under Recent Failures says Last 7 days, but the traced formula uses a 24-hour window.

The page also uses stored statistics to show operational alerts:

  • Automatic Verification Not Running appears when no automatic run exists in the last 24 hours
  • Compliance Alert repeats the same 24-hour automatic-verification failure below the cards
  • Critical Components Failed appears when the 30-day critical-failure count is greater than zero
  • successRate, lastVerification, and complianceScore are returned by the statistics endpoint but are not rendered as cards on this page

The main table is the audit log for individual runs. Each row shows:

  • when the run happened
  • whether it was automatic, manual, on-demand, or installation
  • whether the run ended in success, failure, or partial
  • how many components were valid
  • who initiated the run
  • whether critical impact was recorded

View Details opens the comparison dialog. That dialog is where operators:

  • inspect component results by service area
  • compare against the previous successful verification
  • set the current successful run as the verified baseline
  • remove the verified baseline
  • run a local manual file-verification checklist before setting a baseline
  • export the selected detail view as browser-generated PDF, JSON, or CSV

Filters that change the result

  • Start Date, default empty, maximum current date
  • End Date, default empty, maximum current date and minimum equal to selected Start Date
  • Verification Type, default All Types, options Automatic (24h), Manual, On-Demand, Installation
  • Status, default All Status, options Success, Failure, Partial
  • Search, placeholder Search by component, hash, or user...
  • Show Critical Failures Only, default off
  • table page, default 0
  • rows per page, default 25, options 10, 25, 50, 100
  • sort field, default created_at
  • sort order, default desc

Action and filter behavior

  • The filter accordion uses mostly live-bound controls. Changing dates, type, status, or Show critical only immediately updates the logs query.
  • Search schedules the logs query after 500ms, but the current handler does not cancel prior timers, so rapid typing can still send several delayed searches.
  • Refresh re-fetches the current logs query and the separate summary-statistics endpoint. It does not commit a second hidden filter state.
  • Clear Filters resets dates, type, status, search, critical-only toggle, page, page size, and default sorting.
  • Export Report is a CSV-only page action. The button enables when at least one filter is active, but the current export call passes only Start Date and End Date into the export request.
  • Trigger Manual Verification posts the fixed reason Manual trigger from dashboard, then refreshes the table/statistics immediately and again through the hook's delayed mutation.
  • The logs and statistics already poll every 30 seconds; the page also has its own 30-second refresh interval.

Detail dialog behavior

The detail dialog has three tabs:

  • Components (N): grouped component list with category expansion, current hash, optional previous hash, optional verified baseline hash, and Changed status chips
  • Failed (N): failed-component list with expected hash, actual hash, and impact chip
  • Actions & Metadata: persisted action text, gaming-stopped alert, verification id, algorithm, IP address, expiry date, and raw metadata JSON

The dialog comparison model is:

  • previous successful verification is loaded from /logs/:verificationId?includePrevious=true
  • verified baseline is loaded separately from /baseline
  • when a verified baseline exists, the dialog recalculates visible pass/fail counts by comparing current component hashes with the baseline component hashes
  • new components without a baseline hash are treated as passing when the current component itself is valid
  • hash display is truncated by default and can be expanded with Show Full Hashes

Manual file verification is a local operator checklist inside the dialog. It lets the operator check individual files or categories before opening Confirm Verification Baseline; it does not persist per-file checklist state. The saved baseline action only receives the selected verificationId and verifiedBy.

Why this page can differ from other monitoring screens

This page is not a generic uptime dashboard. It is built from stored verification logs, while the actual verification chain also includes local system-core hash collection, casino verification, and Core verification. The page therefore reflects the persisted audit result of the verification workflow, not a live polling view of each service.

Known caveats

  • Search matches verification id, master hash, initiator, and serialized invalid-component text. It is broader than the placeholder wording suggests.
  • Recent Failures has a visible Last 7 days subtitle, but the traced formula is last 24 hours.
  • Export Report on the page only threads the date range into the export request. Type, status, search, critical-only, pagination, and sort state are not reflected in the current export call.
  • The visible summary cards are global statistics from /statistics; they do not recalculate when the table filters are narrowed.
  • Set baseline is only valid for successful runs. Failed or partial runs cannot become the trusted baseline.
  • Detail comparisons use the stored verified baseline when one exists and also show the previous successful verification as historical context.
  • Detail PDF/JSON/CSV exports are generated from loaded dialog data in the browser, not by the page-level export route.
More details

Definitions and formulas

Open only the section you need. The relevant section opens automatically when you request help for a specific item on screen.

Calculations21 topicsOpen details

Total Verifications

This is a global 90-day statistics card and is not narrowed by table filters.

Transform
The statistics query counts `control_verification_logs` rows where `created_at` is at least `now - 90 days`.

Avg Execution Time

This is a recent average runtime, not the runtime of the selected row. The page appends `ms` and shows `Target: <5000ms`.

Transform
The statistics query averages non-null `execution_time_ms` values from the last 30 days and rounds the result to an integer millisecond value.

Recent Failures

The visible subtitle currently says `Last 7 days`, but the traced formula is last 24 hours.

Transform
The statistics query counts rows where `verification_status` is `failure` or `partial` and `created_at` is at least `now - 24 hours`.

Critical Failures

Any value greater than zero turns the card into the error-colored critical state and triggers the page warning alert.

Transform
The statistics query counts rows from the last 30 days where `jsonb_array_length(critical_components_affected) > 0`.

Automatic verification health

A missing automatic run drives both the header chip and the compliance alert.

Transform
The statistics query checks whether any row exists with `verification_type = automatic` and `created_at >= now - 24 hours`.

Compliance Score

Returned by the statistics feed, but the traced page does not currently render this metric.

Transform
The compliance-score calculation starts at 100, subtracts 10 when successRate is below 95, subtracts another 10 when below 90, subtracts another 20 when below 80, subtracts 25 when automatic verification is not healthy, subtracts up to 30 points at 5 points per critical failure, adds 5 points when totalVerifications is over 100 and successRate is over 95, then clamps the result to 0..100.

Statistics versus logs split

Narrowing the table does not recalculate the four summary cards.

Transform
The page loads summary cards from the statistics feed and the table from the logs feed. Table filters change only the logs table. The statistics cards stay global and refresh independently.

Logs query parameters

Empty/default filter values are intentionally omitted from the logs request.

Transform
The table request always includes paging and sorting. It includes date filters only when present, type/status only when not set to all, search only when text is non-empty, and critical-only only when that switch is enabled.

Filter apply behavior

Most filters are live-bound; search is delayed but is not a strict cancelled debounce in the current implementation.

Transform
Date, type, status, and critical-only changes call `onFiltersChange` immediately. Search changes schedule an update after 500ms, but previous timers are not cancelled. `Refresh` simply re-sends the current local filter object.

Active filter count

This count controls the `N active` chip, `Clear Filters` disabled state, and part of the `Export Report` enabled state.

Transform
The filter chip counts start date, end date, non-`all` type, non-`all` status, non-empty search text, and critical-only true.

Export Report filter scope

Type, status, search, critical-only, pagination, and sort state can enable the export button but are not included in the current export request.

Transform
The page-level export is CSV-only; it only includes start and end dates when present. The export defaults to the last 90 days when no dates are supplied.

Polling and refresh cadence

Operators can see data refresh without pressing refresh; recent manual runs can trigger an extra near-term refresh.

Transform
The logs and statistics requests refresh every 30 seconds. The page also creates another 30-second refresh interval. Manual trigger refreshes immediately and then schedules another logs/statistics refresh after 2 seconds.

Compliance

This is a per-row ratio, not the global compliance score returned with the statistics cards.

Transform
The table calculates `Math.round((valid_components / total_components) * 100)`. The chip is success at 95% or higher, warning at 80% to 94%, and error below 80%.

Execution Time

The row value is one verification's runtime, while `Avg Execution Time` is a 30-day aggregate.

Transform
Null or zero-ish values render as `-`; values below 1000 render as milliseconds; values 1000 or higher render as seconds with two decimals.

Verification run component counts

The table is showing persisted audit counts, not live component probes.

Transform
When a run is triggered, the verification controller saves `total_components`, `valid_components`, and `invalid_components` as the sum of casino backend, NX workspace, local admin system-core, and casino-services verification results.

Master hash

The displayed master hash is a combined verification fingerprint for the successful service portions of the run.

Transform
The verification controller concatenates successful service master hashes in the order casino backend, NX workspace, admin system-core, and casino services, then hashes the concatenated string with SHA-256. If no service succeeds, the combined hash is `error`.

Critical Impact

A critical row means the stored audit record says gaming functions were stopped or may be affected.

Transform
The verification controller intersects invalid component keys with a fixed critical-components list. If any critical component is affected, verification status becomes `failure`, `gaming_functions_stopped` is saved as true, and action text becomes `CRITICAL: Gaming functions stopped due to critical component failure`.

Detail comparison baseline

Operators should not expect comparison against failed or partial intermediate runs.

Transform
The detail dialog first compares against the stored verified baseline when one exists and also provides previous successful verification data for historical comparison.

Detail baseline recalculation

The dialog can show a failed/differing state even when the stored row status itself was originally `success`.

Transform
When a verified baseline exists, the dialog recalculates visible passing and differing counts by matching current component hashes to baseline hashes across `nxWorkspace`, `casinoBackend`, `systemCore`, and `casinoServices`. Components with no baseline hash are counted as passing when their current component result is valid.

Manual File Verify

This is a human checklist before baseline selection, not persisted per-file verification evidence.

Transform
Manual file verification is local page checklist state. The operator can check files or whole categories, and the baseline confirmation button is gated until all files are checked in manual mode. The baseline action still receives only `verificationId` and `verifiedBy`.

90-day retention period

Normal verification logs are retention-bound; baseline retention depends on which cleanup path is used.

Transform
New logs are saved with `expires_at = now + 90 days`; the database migration also defines an insert trigger for 90-day expiry. The model cleanup helper preserves verified baselines, but the controller cleanup route currently deletes expired rows without an `is_verified` guard.
Columns9 topicsOpen details

Date/Time

Render
Browser-formatted timestamp.

Type

Render
Icon plus mapped label `Automatic`, `Manual`, `On-Demand`, or `Installation`.

Status

Render
Uppercase status chip for `SUCCESS`, `FAILURE`, or `PARTIAL`.

Components

Render
Shows `valid_components/total_components`; adds an `N failed` chip when `invalid_components > 0`.

Compliance

Render
Rounded percentage chip with success/warning/error threshold colors.

Execution Time

Render
Empty values show `-`; values below 1000 show milliseconds; values at least 1000 show seconds with two decimals.

Initiated By

Render
Initiator text from backend authentication/header/body/cron resolution.

Critical Impact

Critical-impact chip area. Rows with critical components are tinted and show a blocked-state marker.

Render
Shows `None` or an error icon with `N critical`; tooltip text is `Gaming functions stopped`.

Actions

Render
Contains `View Details`.
Filters10 topicsOpen details

Start Date

Type
date
Behavior
Immediate apply; serialized to ISO string when present.
Constraints
The picker maxDate is the current browser date.

End Date

Type
date
Behavior
Immediate apply; serialized to ISO string when present.
Constraints
The picker maxDate is the current browser date., The picker minDate is the selected `Start Date`.

Verification Type

Type
select
Default
all
Options
0: Value: all | Label: All Types | 1: Value: automatic | Label: Automatic (24h) | 2: Value: manual | Label: Manual | 3: Value: on-demand | Label: On-Demand | 4: Value: installation | Label: Installation
Behavior
Immediate apply; omitted from the backend query while value is `all`.

Status

Type
select
Default
all
Options
0: Value: all | Label: All Status | 1: Value: success | Label: Success | 2: Value: failure | Label: Failure | 3: Value: partial | Label: Partial
Behavior
Immediate apply; omitted from the backend query while value is `all`.

Search

Type
text
Placeholder
Search by component, hash, or user...
Behavior
The page schedules apply after 500ms, but the current handler does not cancel earlier timers.
Backend Matching
verification_id ILIKE search, master_hash ILIKE search, initiated_by ILIKE search, invalid_component_list::text ILIKE search

Show Critical Failures Only

Type
boolean
Default
false
Behavior
Immediate apply; sends `criticalOnly=true` and filters rows with non-empty `critical_components_affected`.

Page

Type
pagination-state
Default
0
Behavior
Reset to `0` whenever filters or page size change.

Rows per page

Type
pagination-state
Default
25
Options
10, 25, 50, 100

Sort by

Type
sort-state
Default
created_at

Sort order

Type
sort-state
Default
desc
Summary cards4 topicsOpen details

Total Verifications

Global 90-day count from the dedicated `/statistics` endpoint, not from the filtered logs table.

Avg Execution Time

Rounded 30-day average execution time in milliseconds. The card subtitle shows target `<5000ms`.

Recent Failures

Stored count of `failure` and `partial` runs in the last 24 hours. Current card subtitle says `Last 7 days`, which does not match the traced formula.

Critical Failures

Stored count of 30-day rows where `critical_components_affected` is not empty. Card turns error-colored when greater than zero.

Page sections8 topicsOpen details

Filters

Expanded by default. Shows an `N active` chip based on date/type/status/search/critical-only controls.

Clear Filters

Resets dates, type, status, search, critical-only, page, page size, sort field, and sort order to defaults. Disabled while no filter is active.

Refresh data

Re-sends the local filter object to the page and refetches logs/statistics through the hook.

Export Report

CSV page export. Enables when at least one filter is active, but the export request only includes start/end dates.

Verification log table

Audit log table backed by the filtered `/logs` endpoint.

Verification details dialog

Dialog with baseline comparison, component drill-down, and baseline management controls.

Table pagination

Pagination controls for the logs table only.

Showing X - Y of Z verification logs (90-day retention period)

Summary text shown below non-empty table results.

Metrics9 topicsOpen details

Total Verifications

Number of verification logs created in the last 90 days.

Aliases
control verification total verifications, verification run count
Formula
count(logs where created_at >= now - 90 days)

Avg Execution Time

Rounded average runtime of recent verification runs, displayed in milliseconds with the visible target note `<5000ms`.

Aliases
control verification average execution time, average runtime
Formula
round(avg(execution_time_ms where created_at >= now - 30 days and execution_time_ms is not null))

Recent Failures

Count of `failure` and `partial` runs from the last 24 hours. Important caveat: the current page subtitle says `Last 7 days`, but the report formula is 24 hours.

Aliases
control verification recent failures, verification failures last day
Formula
count(logs where status in ['failure','partial'] and created_at >= now - 24h)

Critical Failures

Count of recent runs where the critical-components list is not empty.

Aliases
control verification critical failures, verification critical failures
Formula
count(logs in last 30 days where jsonb_array_length(critical_components_affected) > 0)

Automatic Verification Not Running

Drives the header chip and compliance alert. False means no automatic verification run was found in the last 24 hours.

Aliases
automatic verification healthy, compliance alert automatic verification
Formula
Boolean(find one log where verification_type = 'automatic' and created_at >= now - 24h)

Components

Per-row valid component count over total component count; shows an extra failure chip when invalid components are present.

Aliases
valid components over total components, control verification components column
Formula
valid_components / total_components, where each side is the sum of casino backend, nx workspace, admin system-core, and casino-services component counts saved on the log.

Compliance

Per-row percentage of valid components. Green means 95% or higher, warning means 80% to 94%, and error means below 80%.

Aliases
compliance ratio, control verification row compliance
Formula
round((valid_components / total_components) * 100) in the table, using persisted component counts.

Compliance Score

Aliases
backend compliance score, control verification compliance score
Formula
Start at 100; subtract 10 if successRate < 95, another 10 if < 90, another 20 if < 80; subtract 25 if automatic verification is not healthy; subtract min(criticalFailures * 5, 30); add 5 when totalVerifications > 100 and successRate > 95; clamp to 0..100.

Success Rate

Aliases
verification success rate, backend successRate
Formula
round(((count(success rows in last 30 days) / count(all rows in last 30 days)) * 100) * 10) / 10; returns 0 when there are no rows.
More help

Related pages

Reporting

Canonical entrypoint for standalone reporting pages outside the main Dashboard widgets.

Reporting / Affiliate Events Report

Audit log of the events and saved amounts the platform sent to the affiliate system, with per-currency successful totals, CSV export, suspicious-traffic visibility, and a guarded force-send override.

Reporting / Bonus Performance

Grouped bonus performance report for activations, amounts, deposits, withdrawals, GGR, and NGR by bonus item.

Reporting / Card Approval Rates

Snapshot report of card deposit approval rates for NetworxPay, Paydex, and Carouseller, split by Trusted and NonTrusted players, with today versus the previous 30 days and today top decline reasons.

Reporting / Change Notification Detail

Detail page for one audit entry, including actor metadata, description, and before/after comparison views.

Reporting / Change Notifications

Audit list for recorded configuration, administrator, and system change entries with filters for actor, entity, and change type.