Least-privilege access
ShiftMark should access only the worker, shift and rule context required for the approved workflow. Roles and tenant boundaries are defined for each deployment.
Trust and control
Know what the agent can do—and when a person takes over.
Security and privacy details must match the deployed system, not a marketing promise. This page describes the controls ShiftMark is designed around; pilot-specific architecture, storage, retention and subprocessors are documented during diligence.
Explicit authority
Contact, assignment, disclosure and write-back permissions are bounded. Anything outside authority is blocked or escalated.
Reviewable action trail
Operational actions and outcomes remain visible to authorised people. Transcript availability follows the recording and retention configuration.
Human takeover
Workers can reach a person through the configured escalation path. Coordinators can intervene with the incident context intact.
Defined data lifecycle
Call recordings, transcripts and logs require explicit retention, deletion and access rules. The applicable design is confirmed before go-live.
Safe failure behaviour
When a dependency is unavailable or confidence is insufficient, ShiftMark should stop autonomous action, notify the right person and preserve context.
Diligence checklist
Questions we expect serious agencies to ask.
Where is our data stored?
The answer depends on the production architecture selected for your deployment. Storage region, encryption, backups and subprocessors are documented during security review; this site does not make an unverified residency claim.
Are calls recorded?
Recording is a configurable workflow choice, not an assumption. Where enabled, disclosure, consent, access, retention and deletion rules must be defined before use.
Do you train models on worker information?
Model and data-processing terms are documented for the production system and reviewed with the agency. ShiftMark does not make a blanket claim here until those controls and contracts are verified for the deployment.
Can we delete data?
Deletion requirements are part of the data-lifecycle design. The exact process, scope and backup implications are documented during diligence.
What if ShiftMark goes down?
The operating plan identifies safe failure behaviour, notification paths and the human fallback. Autonomous actions should not continue when required context or dependencies are unavailable.
Bring security into the first conversation.
We will separate verified controls, pilot requirements and future work.