Operator guideENreportingauditverificationcompliance

Reporting / Control Verification

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

Reader view

Clean portal guidance

This page keeps the operator explanation, field and action descriptions, and screenshots visible without exposing repo paths, raw sidecars, or editorial-only implementation details.

Narrative content

Page body

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 backend-owned 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 UI subtitle under Recent Failures says Last 7 days, but the traced backend query is a 24-hour query.

The page also uses backend 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 FE call passes only startDate and endDate 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 SWR hooks already poll every 30 seconds; the page also has its own 30-second interval calling refetch().

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 to the backend. The backend 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 in gs-admin-backend, while the actual verification chain also includes the local admin system-core hash collection, a casino-services verification hop that reaches gs-casino-backend, and the nx-workspace/services/core verification endpoint. The page therefore reflects the persisted audit result of the verification workflow, not a live polling view of each service.

Known caveats

  • Search is backend-owned and 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 backend 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 backend export route.

Verification status

  • status: verified_backend_and_core
  • FE route, filters, summary cards, table, and detail dialog are mapped
  • gs-admin-backend owns the audit log, statistics, baseline actions, and export flow
  • gs-casino-backend participates in the manual verification fan-out
  • nx-workspace/services/core is part of the verification chain and appears in component comparison data
Calculation notes

Calculations

calculation

Total Verifications

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

Source Fields
created_at
Transform
The backend counts `control_verification_logs` rows where `created_at` is at least `now - 90 days`.
calculation

Avg Execution Time

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

Source Fields
execution_time_ms, created_at
Transform
The backend averages non-null `execution_time_ms` values from the last 30 days and rounds the result to an integer millisecond value.
calculation

Recent Failures

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

Source Fields
verification_status, created_at
Transform
The backend counts rows where `verification_status` is `failure` or `partial` and `created_at` is at least `now - 24 hours`.
calculation

Critical Failures

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

Source Fields
critical_components_affected, created_at
Transform
The backend counts rows from the last 30 days where `jsonb_array_length(critical_components_affected) > 0`.
calculation

Automatic verification health

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

Source Fields
verification_type, created_at
Transform
The backend checks whether any row exists with `verification_type = automatic` and `created_at >= now - 24 hours`.
calculation

Compliance Score

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

Source Fields
successRate, automaticVerificationHealthy, criticalFailures, totalVerifications
Transform
The backend 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.
calculation

Statistics versus logs split

Narrowing the table does not recalculate the four summary cards.

Source Fields
/api/admin/control-verification/logs, /api/admin/control-verification/statistics
Transform
The FE loads summary cards from `/statistics` and the table from `/logs`. Table filters change only the logs query. The statistics cards stay global and refresh independently.
calculation

Logs query parameters

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

Source Fields
page, limit, sortBy, sortOrder, startDate, endDate, verificationType, verificationStatus, searchText, showCriticalOnly
Transform
The hook always sends page, limit, sortBy, and sortOrder. It sends ISO start/end dates only when present, type/status only when not `all`, `search` only when search text is non-empty, and `criticalOnly=true` only when the critical-only switch is on.
calculation

Filter apply behavior

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

Source Fields
localFilters, onFiltersChange, searchText
Transform
Date, type, status, and critical-only changes call `onFiltersChange` immediately. Search changes schedule `onFiltersChange` after 500ms, but the function returned by the handler is not used as a React cleanup, so previous timers are not cleared. `Refresh` simply re-sends the current local filter object.
calculation

Active filter count

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

Source Fields
startDate, endDate, verificationType, verificationStatus, searchText, showCriticalOnly
Transform
The filter chip counts start date, end date, non-`all` type, non-`all` status, non-empty search text, and critical-only true.
calculation

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.

Source Fields
startDate, endDate, verificationType, verificationStatus, searchText, showCriticalOnly
Transform
The FE page-level export always calls `/export` with `format=csv`; it only adds `startDate` and `endDate` when present. The backend defaults to the last 90 days when no dates are supplied.
calculation

Polling and refresh cadence

Operators can see data refresh without pressing refresh; developers should know there are overlapping refresh paths.

Source Fields
useSWR.refreshInterval, page setInterval, triggerManualVerification
Transform
The logs and statistics hooks each use SWR `refreshInterval: 30000`. The page also creates a 30-second interval that calls `refetch()`. Manual trigger calls `refetch()` immediately and the hook schedules another logs/statistics mutate after 2 seconds.
calculation

Compliance

This is a per-row ratio, not the backend `/statistics` `complianceScore`.

Source Fields
valid_components, total_components
Transform
The FE 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%.
calculation

Execution Time

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

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

Verification run component counts

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

Source Fields
casinoHashResult.summary, nxHashResult.summary, systemCoreData.statistics, casinoServicesResult.summary
Transform
When a run is triggered, the backend 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.
calculation

Master hash

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

Source Fields
casinoHashResult.masterHash, nxHashResult.masterHash, systemCoreData.masterHash, casinoServicesResult.masterHash
Transform
The backend 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`.
calculation

Critical Impact

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

Source Fields
invalid_component_list, critical_components_affected, gaming_functions_stopped, action_taken
Transform
The backend 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`.
calculation

Detail comparison baseline

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

Source Fields
component_results, verifiedBaseline, previousVerification
Transform
The detail dialog first compares against the stored verified baseline when one exists and also provides previous successful verification data for historical comparison.
calculation

Detail baseline recalculation

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

Source Fields
component_results, verifiedBaseline.component_results
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.
calculation

Manual File Verify

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

Source Fields
manualVerificationMode, fileVerificationStatus, component_results
Transform
Manual file verification is local UI 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 backend baseline request still receives only `verificationId` and `verifiedBy`.
calculation

90-day retention period

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

Source Fields
created_at, expires_at, is_verified
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.
Grid columns

Columns

field

Date/Time

Render
Browser-formatted timestamp.
field

Type

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

Status

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

Components

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

Compliance

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

Execution Time

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

Initiated By

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

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`.
field

Actions

Render
Contains `View Details`.
Filter dictionary

Filters

field

Start Date

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

End Date

Type
date
Backend Query Param
endDate
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`.
field

Verification Type

Type
select
Default
all
Backend Query Param
verificationType
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`.
field

Status

Type
select
Default
all
Backend Query Param
verificationStatus
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`.
field

Search

Type
text
Placeholder
Search by component, hash, or user...
Backend Query Param
search
Behavior
The FE 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
field

Show Critical Failures Only

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

Page

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

Rows per page

Type
pagination-state
Default
25
Backend Query Param
limit
Options
10, 25, 50, 100
field

Sort by

Type
sort-state
Default
created_at
Backend Query Param
sortBy
field

Sort order

Type
sort-state
Default
desc
Backend Query Param
sortOrder
Summary cards

Summary cards

field

Total Verifications

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

field

Avg Execution Time

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

field

Recent Failures

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

field

Critical Failures

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

Widget map

Widgets

item

Filters

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

item

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.

item

Refresh data

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

item

Export Report

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

item

Verification log table

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

item

Verification details dialog

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

item

Table pagination

Pagination controls for the logs table only.

item

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

FE summary text shown below non-empty table results.

Metric dictionary

Metrics

metric

Total Verifications

Number of verification logs created in the last 90 days.

Aliases
control verification total verifications, verification run count
Backend Formula
count(logs where created_at >= now - 90 days)
Verification Status
verified_backend
Last Verified At
2026-05-05
metric

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
Backend Formula
round(avg(execution_time_ms where created_at >= now - 30 days and execution_time_ms is not null))
Verification Status
verified_backend
Last Verified At
2026-05-05
metric

Recent Failures

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

Aliases
control verification recent failures, verification failures last day
Backend Formula
count(logs where status in ['failure','partial'] and created_at >= now - 24h)
Verification Status
verified_backend
Last Verified At
2026-05-05
metric

Critical Failures

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

Aliases
control verification critical failures, verification critical failures
Backend Formula
count(logs in last 30 days where jsonb_array_length(critical_components_affected) > 0)
Verification Status
verified_backend
Last Verified At
2026-05-05
metric

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
Backend Formula
Boolean(find one log where verification_type = 'automatic' and created_at >= now - 24h)
Verification Status
verified_backend
Last Verified At
2026-05-05
metric

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
Backend 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.
Verification Status
verified_backend_and_core
Last Verified At
2026-05-05
metric

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
Backend Formula
round((valid_components / total_components) * 100) in the FE table, using backend-persisted component counts.
Verification Status
verified_backend
Last Verified At
2026-05-05
metric

Compliance Score

Backend returns this value from `/statistics`, but the traced page does not currently render it as a visible card.

Aliases
backend compliance score, control verification compliance score
Backend 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.
Verification Status
verified_backend
Last Verified At
2026-05-05
metric

Success Rate

Backend returns this value from `/statistics`, but the traced page does not currently render it as a visible card.

Aliases
verification success rate, backend successRate
Backend 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.
Verification Status
verified_backend
Last Verified At
2026-05-05
Operational notes

Notes

item

Statistics are controller-owned aggregates over the stored `control_verification_logs` table, not FE-derived cards.

item

The visible statistics cards are `Total Verifications`, `Avg Execution Time`, `Critical Failures`, and `Recent Failures`; backend also returns `successRate`, `lastVerification`, `automaticVerificationHealthy`, and `complianceScore`.

item

Recent Failures is a backend 24-hour count even though the visible subtitle currently says `Last 7 days`.

item

Manual verification is initiated from `gs-admin-backend`, then fans out through the local admin system-core collector, a casino-services verification hop that reaches `gs-casino-backend`, and the `nx-workspace/services/core` verification endpoint.

item

Triggered runs combine casino backend, NX workspace, admin system-core, and casino-services counts into one persisted log row and combine successful service master hashes into one SHA-256 master hash.

item

The detail dialog compares the selected run with the previous successful run and can also compare against or update the separately loaded verified baseline.

item

Manual file verification inside the detail dialog is local FE checklist state; the backend baseline mutation receives only `verificationId` and `verifiedBy`.

item

Detail PDF/JSON/CSV exports are browser-generated from loaded dialog data and are separate from the backend `/export` route.

item

Search matches verification id, master hash, initiator, and serialized invalid-component content.

item

Table filters are sent only to `/api/admin/control-verification/logs`; summary cards come from `/api/admin/control-verification/statistics`.

item

Logs and statistics both use 30-second SWR polling, and the page has an additional 30-second interval calling `refetch()`.

item

The filter search handler schedules a 500ms delayed update but does not cancel prior timers, so rapid typing can still send multiple delayed searches.

item

The FE page export action only offers CSV and currently forwards `startDate` and `endDate` into `/api/admin/control-verification/export`.

item

The model cleanup helper preserves verified baselines, but the controller cleanup route deletes expired rows without an `is_verified` guard.

Related references

Related pages

pageReporting

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

pageReporting / Affiliate Events Report

Audit log of the events and saved amounts the platform sent to the affiliate system, with per-currency successful totals and a CSV export.

pageReporting / Bonus Performance

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

pageReporting / 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.

pageReporting / Change Notification Detail

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

pageReporting / Change Notifications

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