Project: Smart Operator Assistant for CAT Machinery Team: H1B Visa

1. Protect operator personal data and machine telemetry from unauthorized access.
2. Ensure only authorized roles can view/modify safety-critical configuration (rule thresholds) and incident records.
3. Preserve an accurate, tamper-resistant audit trail for safety alerts and incidents.
4. Be explicit about the system's boundaries so it is never mistaken for a certified safety system.

Access control should be enforced server-side on every endpoint (role check on the API, not just hiding UI elements), since a hidden button is not a security boundary.

• Hackathon scope: simple email/username + password with a JWT carrying the user's role claim; token expiry on a reasonable session window.
• Production path: integrate with an organization identity provider (SSO/OAuth) and add multi-factor authentication for Safety Manager and System Admin roles, given their ability to change safety-critical configuration.

• All API traffic should run over HTTPS/TLS, including in the demo environment where feasible.
• No secrets (API keys, JWT signing keys) should be committed to the repository; use environment variables/secret management.

CATALYST is a decision-support interface only. It explicitly does not:

• Control machine movement, hydraulics, or any physical actuator.
• Perform autonomous driving or excavation.
• Replace certified machine safety systems (e.g., factory-installed seatbelt interlocks, proximity-detection hardware).
• Provide medical monitoring or diagnosis of the operator.
• Guarantee the accuracy of task-duration predictions, particularly when historical data is limited (as with the 4-telemetry/5-task sample set used in this prototype).

This boundary should be stated in-product (e.g., a footer note or onboarding message) as well as in project documentation, so operators and supervisors do not over-rely on the system in place of certified equipment and procedures.

• Every safety alert: timestamp, machine, operator, rule that fired, severity, acknowledgment time, resolving user.
• Every incident: creation time, creator, category, severity, all status changes with timestamp and actor.
• Every safety-rule configuration change: old value, new value, actor, timestamp.
• Logs should be append-only where feasible (no silent edits/deletes of historical safety records), supporting later incident investigation.

Because safety rules are stored as configurable data (see ARCHITECTURE.md §7), the system must guard against:

• Unauthorized edits: only Safety Manager/Admin roles may write to safety_rules.
• Malformed/malicious conditions: rule conditions should be validated against a strict schema (allowed fields, operators, and value ranges) rather than evaluated as arbitrary code, to prevent injection through the rule-config surface.
• Silent threshold weakening: consider requiring a second approver or at least a logged justification when a threshold is loosened (e.g., raising the idling limit), since this directly affects safety sensitivity.

• Incident records function similarly to workplace safety logs; production deployments should align retention and access policies with applicable occupational safety regulations (e.g., OSHA-equivalent record-keeping in the relevant jurisdiction).
• If deployed across regions, data residency and privacy regulations (e.g., GDPR-equivalent) should govern where operator PII and telemetry are stored.

This prototype, built for a hackathon timeframe, intentionally simplifies several production security concerns: