What policy means in Fundamentum
Policy in Fundamentum defines which roles can perform which actions on which device categories in which lifecycle states under which conditions. Policies are versioned, auditable, and testable — they can be reviewed by a compliance officer, approved in a change management workflow, and validated against a test fleet before deployment to production.
- Rules live in code — broken when a developer forgets the check
- No version history — "what was the rule last Tuesday?" is unanswerable
- Not testable in isolation — requires a full application deployment
- A new team member can bypass a rule they don't know exists
- Regulatory auditors have nothing to inspect except application logs
- Rules enforced by the governance layer — bypass requires a change to governance config, which is itself logged
- Full version history — every policy change is a governed, auditable event
- Testable against a staging fleet before production deployment
- New team members inherit the policy — they don't need to know the rule exists to comply with it
- Compliance auditors inspect the policy store — not code reviews
Role-based access control (RBAC)
Fundamentum's RBAC model defines roles along three dimensions: what action class, on what device category, in what lifecycle state. The intersection of these three dimensions determines what is permitted — not a flat permission list that grows ungovernable at scale.
| Role example | Action class | Device category | State restriction |
|---|---|---|---|
| Fleet Operator | Read telemetry, send non-destructive commands | All activated devices | Activated only |
| Firmware Engineer | Initiate OTA update | Assigned device class | Activated + Maintenance |
| Security Admin | Revoke credentials, force maintenance mode | All devices | Any state |
| Decommission Authority | Decommission devices | All devices | Must be in Maintenance |
| Read-Only Auditor | Read audit trail, read telemetry | All devices | Any state, read-only |
Regulatory policy encoding
Fundamentum policies can encode regulatory requirements as infrastructure-layer enforcement — not as compliance documentation that developers are expected to read and implement.
- GDPR / PIPEDA: Data access policies that enforce right-to-erasure workflows at the governance layer. Deletion requests trigger a governed decommission workflow, not a manual database operation.
- CCPA: Data minimization policies enforced at telemetry ingestion. Devices that attempt to transmit fields outside their declared data schema are refused.
- IEC 62443 (Industrial): Zone and conduit models encoded as device category restrictions. Cross-zone commands require elevated authorization.
- Healthcare (FDA, Health Canada): Audit trail requirements for all device interactions are natively satisfied by Fundamentum's tamper-evident log. No additional logging layer required.
- Defence (ITAR/EAR, CPCSC): Geographic access restrictions, elevated authorization requirements for sensitive command classes. Available for Stratys deployments.