What the system holds, and why it is there

An employee's record holds personal details, contract terms, an address, a profile picture, and up to five categories of attached documents: personal, managerial, qualification, leave and duty. That covers the actual paperwork a 24/7 workforce runs on, IDs, licences, medical certificates and qualification proofs, not a generic file store.

The most sensitive fields, a fiscal number, an ID or passport number, a home address, a phone number, are held apart from general viewing. They are returned only through a separately gated endpoint that requires write-level access to the employee's primary unit, not the broader read tier that lets a wider set of roles see general employee and roster information. Viewing your own confidential fields through self-service needs only individual-level access, nothing more.

For a growing list of the platform's configuration and staffing aggregates, every change is recorded as a structured, field-level entry: which field changed, its previous value, its new value, who made the change, and a UTC timestamp. Employee identifiers in that history are resolved to readable names, so an audit trail reads as "who changed what" in plain language rather than as a list of internal IDs someone has to look up separately.

Coverage is real and is being extended deliberately, aggregate by aggregate, with an automated test suite behind each rollout that checks every field on that aggregate is actually captured. Treat it as comprehensive across the platform's major configuration and staffing changes, and growing, not as a claim that every possible field change in the system is logged today.

Audit history is retained indefinitely per tenant; nothing is automatically purged. Where it matters most, an administrator investigating why a value is what it is can see that history inline, on the exact screen where the change was made, rather than correlating a separate report against the setting they are looking at.

The Audit & History module covers customer-facing access to the central change log, history on individual records, and search and filters across licensed functionality. It is included in SkyHeavy or available as an add-on to other plans. The written offer confirms record coverage. Internal change recording continues to support platform workflows; this packaging does not change retention, existing contractual entitlements or the published limits of shift-change history.

Because each tenant has its own separate database, and because self-hosting is one of the three deployment shapes, your data can be kept entirely within an infrastructure and a jurisdiction you choose. See the deployment page for what each of the three shapes actually involves.

No public-cloud dependency is architecturally required for the core application, its database, its identity layer, its cache, or its message queue; all of them are self-hostable. A small number of ancillary services, sending transactional email, or where we run backups on your behalf on the managed-cloud shape, have an external dependency by default, and are themselves configurable per environment rather than hard-wired.