Notifications and Risk Scoring

Notifications model

InboxNotification stores user-facing messages with:

title
body
notification type
optional data payload
read/unread state
timestamp
icon
action label
recipient user

Electrician and client portal routes include notification list, mark-read, and delete actions. The mobile app can also receive Expo push notifications.

Approval and rejection notifications

TimesheetExpenseNotificationService contains notification methods for:

timesheet accepted
timesheet approved
timesheet rejected
expense approved
expense rejected
bulk approvals

The service builds inbox records and sends push payloads through ExpoPushNotificationService. This keeps the portal notification history and mobile push side effects in one workflow.

Risk scoring model

TimesheetRiskScorer reads a timesheet and emits scored signals. TimesheetRiskAssessmentManager persists the result to TimesheetRiskAssessment.

The assessment stores:

risk status: green, amber, or red
score
max score
signal array
summary text
assessed timestamp

Current risk signals

Signal	Trigger	Score impact
`long_shift` red	Gross hours exceed the supervisor-approval threshold and `supervisorOver12HourApproved` is missing.	60
`long_shift` amber	Gross hours exceed 10.0.	20
`allowance_anomaly`	Manual selected allowance does not appear in calculated allowance lines.	25
`allowance_anomaly`	Calculated allowance total exceeds 250.00.	25
`missing_required_context`	Submitted, accepted, or approved timesheet lacks coordinates.	15
`missing_required_context`	Approved timesheet lacks signature data.	15
`device_drift`	Device capture timestamp differs from server update time by more than one hour.	20
`late_edit`	Timesheet was edited more than seven days after week ending.	20
`repeated_rejection`	Timesheet has been rejected more than once.	20

Scores are capped at 100. A score of 60 or more is red. A score of 25 to 59 is amber. Lower scores are green.

Relationship to fraud-prevention requirements

The project manifest includes broader fraud-prevention requirements, including duplicate/overlap prevention, geofencing, exportable version history, and conflict-resolution interfaces. Current code implements pieces of this direction through risk scoring, change logs, location metadata, and route-level review screens. Full geofence blocking and conflict-resolution override workflows should be treated as future or separate implementation work unless code is added for them.