Evidence Package: Exports for Auditors
An auditor asks about the audit trail in four questions: who changed what, when, with which old and new value, and why? LiteLog answers these questions with eight exports. Each can be generated in the portal, opened as CSV or Excel and checked against the others. This page explains which export documents which requirement, what every column means and how the files fit together.
:::info Requirement The exports require the permission Export round evaluation; some additionally View settings or View reports. Every run appears under Export & Dispatch, where it can be downloaded again or scheduled as a recurring delivery. At most 50,000 rows per file; above that, narrow the period or the area. :::
Which export documents which requirement
| Requirement | Evidence | Export |
|---|---|---|
| Automatic, complete, not editable | Audit tables are locked in the database against change and deletion. A change without an audit row is rejected. There is no edit function for audit entries. Tasks are archived instead of deleted. Signed completions cannot be changed after the signature. | all |
| Sign-in and sign-out events | Access log: sign-in, sign-out, failed attempt with reason, session refresh, property switch, password, signature PIN check, each with username and time local/UTC | Activity log |
| Audit trail during the process | Completion, submitted form and electronic signature as three mutually verifiable traces, plus the PDF evidence | Signature log, Task completions, Reports, Form PDF |
| Who (user name) | Full name, username and role in every row; personnel number for completions and signatures | all |
| When (timestamp) | Local time with seconds and UTC in every row; for signatures device and server time | all |
| Old value / new value | One row per changed field for settings, master data, templates and accounts | Settings audit trail, Activity log |
| Name of the action | Column Event (created, changed, deactivated, archived, correction requested, sign-in, …) | all |
| Change reason | Column Reason in the format [Code] free text; with the mandatory reason switched on, the reason is enforced on save | Settings audit trail, Activity log, Change requests |
The eight exports
| Export | Where in the portal | Content |
|---|---|---|
| Settings audit trail | Activity log › view Settings › Export | Configuration, checkpoints, templates, roles and task rhythms per field with old/new/reason |
| Activity log | Activity log › view Activity › Export | Access log, account changes per field and settings audit in one chronology (at most 31 days per file) |
| Signature log | Activity log › view Signatures › Export | All electronic signatures with checksum |
| Task completions | Tasks › filter row type Completions › Export | Every completion with person, form, approval, signature and cancellation |
| Reports | Reports › Export | Submitted forms and incidents with status, approval and signature |
| Form PDF | Reports › open form › PDF | The single signed record as presented to the auditor |
| Template definitions and Change requests | Settings › Templates › Export and Settings › Change approvals › Export | Every check item of every template today, plus every change request with its decision |
| User list | Employees › Export | All accounts with role, status, sign-in methods and last sign-in |
All CSV files use the separator ; and UTF-8. Row 1 is the header row. Excel files deliver the same columns with real date and number cells.
Time and actors in all exports
Time
- Time (local): event time in the time zone of the property or account, format
DD.MM.YYYY hh:mm:ss. - Time (UTC): the same event time in UTC, ISO 8601 with milliseconds. The UTC column is the reference for ordering and reconciliation; the local column is for reading.
- The time comes from the server clock. It is NTP-synchronised and cannot be changed by users. Where an action took place on the device (signature), device and server time stand side by side. For completions the device time only counts if it is at most one hour behind the server time and at most five minutes ahead of it; otherwise the server time counts.
Actors
- User / Person / Signer: full name of the account that performed the action.
- Username: sign-in name of that account (may be an email address).
- Role: role of that account at the time of the action. Vendor interventions (support access) appear as Platform admin.
- Personnel number: the personnel identifier assigned by the account.
- Empty actor columns mark system actions without a signed-in account, for example the creation of the default roles when the account was set up, or the acceptance of an invitation.
Immutability
The underlying audit tables are locked at database level against change and deletion. There is no function in the portal, in the app or via the API to edit or remove audit rows. A functional change whose audit row cannot be written is rejected and not saved.
Settings audit trail
Covers: audit trail of the configuration: checkpoints, templates, roles, task rhythms, property and company settings. Who, when, old value, new value, change reason.
What a row is: a row is one field of a record. If one save changes several fields, several rows are created with identical time (UTC), user and reference. A new entry creates one row created per set field with an empty old value and the reason Initial creation. Deactivations and correction requests carry no field; they describe the whole record.
| Column | Meaning |
|---|---|
| Time (local) | Event time in local time, with seconds |
| Time (UTC) | Event time UTC, ISO 8601, milliseconds |
| User | Full name of the account that saved the change |
| Username | Sign-in name of that account |
| Role | Role of that account at the time of the change; empty for system actions without a signed-in account |
| Area | Kind of the changed record (catalogue below) |
| Event | Kind of action (catalogue below) |
| Reference | Affected record, readable: Property › Checkpoint, Property › Task (for rhythms), template name, role name, rule name; Tenant = company settings of the account |
| Field | Name of the changed field in plain text, e.g. "Repetition", "Chip ID", "Permissions". Nested settings as a path with "›", e.g. "GxP change control › Mandatory reason". For templates the individual check item |
| Old value | Value before the change. Empty for created. Switches as "Yes" / "No", rhythms in words ("daily", "Mon, Tue"), permissions as a list of permission codes |
| New value | Value after the change |
| Reason | Change reason in the format [Code] free text (codes: Correction, New requirement, Customer request, Bug fix, Periodic review, Other). Initial creation for new entries. For correction requests the request text without code |
Catalogue "Area"
| Area | What is logged there |
|---|---|
| Task rhythm | Repetition, weekdays, start, time window and tolerance of a task; reference = Property › Task |
| Task | Creation and change of a task (name, checkpoints, assignees, form) |
| Checkpoint | Name, chip ID, area, notes, status of a checkpoint |
| Area (checkpoints) | Grouping of the checkpoints |
| Form template | Name, status, scope, signature requirement and every single check item |
| Role | Name, hierarchy, permissions |
| Master data | Name and address of the property |
| Company settings | Account-wide rules: change control, approvals, retention |
| Feature switches | Switching features on and off per property (documents, chat, status, bookings) |
| Automation rule | Rules for notifications and follow-up tasks |
| API key | Creation and change of API keys |
Further areas (status definition, category, working time settings, completion) appear as soon as changes happen there.
Catalogue "Event"
| Event | Meaning |
|---|---|
| created | Record newly created (new value only) |
| changed | Field changed (old and new) |
| deactivated | Record taken out of service, retained with its history (e.g. automation rules) |
| archived / restored | Record moved to the archive or reactivated (tasks are archived, not deleted) |
| correction requested | Change submitted under change approval; takes effect only after approval by a second administrator and then creates the row changed |
Reading notes
- Every template change creates one row per check item. A version step additionally carries the row
Version: v4 → v5. - Rows without a user are system actions during account setup (default roles).
- The row that switched on the mandatory reason carries no reason itself: the requirement applies from the moment this setting is saved.
- The setup of the account (checkpoints, templates, tasks) is logged as Initial creation. The subsequent fine-tuning shows as a sequence of changes to templates and rhythms, each with a reason.
Activity log (activity, sign-ins, account changes)
Covers: sign-in and sign-out events (access log), changes to user accounts with old/new and, for the overall chronology, the settings audit trail once more. Which sources are in the file is decided by the sources in the left menu of the activity log.
| Source | Content |
|---|---|
| Sign-in | Access log: sign-in and sign-out, failed attempts, property switch, password, signature PIN checks |
| Account change | Creation and change of user accounts per field with old/new and reason |
| Settings audit | the same data as the settings audit trail, limited here to the period |
The activity export covers at most 31 days. The setup of the account is fully contained in the settings audit trail.
| Column | Meaning |
|---|---|
| Time (local) / (UTC) | Event time, see above |
| Source | Sign-in, Account change, Settings audit and the other sources of the activity log |
| Event | Kind of action (catalogues below) |
| Person | Full name of the acting account. For account changes the person acting, not the affected account |
| Username | Sign-in name of the acting account |
| Role | Role of the acting account at the time; empty for system actions |
| Property | Property in whose context the action took place (for sign-ins the active property) |
| Reference | Affected record: for account changes the affected account, for settings the record, Tenant = company settings |
| Field / Old value / New value | as in the settings audit trail, one row per field, field names in plain text |
| Reason | [Code] free text, e.g. [Correction] Allow sign-in via QR code |
| Detail | For sign-ins: surface, method and failure reason (e.g. LiteLog app · via QR code, Portal · via password, via signature PIN · Wrong signature PIN). For settings the area |
| Latitude / Longitude | Device location, only if the app has location permission |
Catalogue "Event", source Sign-in
| Event | Meaning |
|---|---|
| Sign-in | successful login; Detail names the surface (portal, LiteLog app) and the method (password, QR code, NFC chip) |
| Sign-in failed | rejected login with the failure reason in Detail (wrong password, account locked, account deactivated, licence expired) |
| Sign-out | logout by the user, by inactivity or by session end after a password change |
| Session refreshed | running portal session automatically extended (token renewal), no new login |
| Property switch | user switches the active property in the app |
| Password changed | password changed by the user |
| Electronic signature | check of the signature PIN when signing (second factor). Without suffix: successful. With suffix: Wrong signature PIN or Signature PIN temporarily locked (too many failed attempts) |
| Signature PIN changed | signature PIN of the account newly set |
| Offline verification key issued | The device received a verification key with which the signature PIN is checked without a network connection (offline signature); the signature itself is transmitted at the next sync |
Catalogue "Event", source Account change
| Event | Meaning |
|---|---|
| Account created | New account, one row per set field (name, username, personnel number, status, assignment, role) |
| Master data changed | One row per field: name, username, personnel number, status (active/deactivated), assignment (employee/customer), assigned properties, contact details, allowed sign-in methods |
| Role changed | Role of the affected account old/new (the column Role is the role of the person acting) |
| Invitation accepted | Account activated via invitation link (without person: the invitee themselves) |
| Password reset | Reset by an administrator (Person = administrator) |
Signature log
Covers: every electronic signature with signer, time, meaning, method and checksum (audit trail during the process).
| Column | Meaning |
|---|---|
| Signed at (local) | Time of the signature on the device, local time |
| Signed at (UTC) | the same time in UTC |
| Received at (UTC) | Server time of arrival. If it is clearly after "signed", the signature was made offline and transmitted later |
| Signer | Full name, frozen |
| Username | Sign-in name, frozen |
| Personnel number | Personnel identifier of the signer at the time of the signature |
| Role | Role of the signer at the time of the signature |
| Object type | What was signed: form response (submitted form), task completion (completion by scan without form), incident, tour, approval request |
| Reference | Title of the signed record (template, task or incident) |
| Property | Property |
| Object UUID | Unique ID of the signed record; corresponds to Form ID or Completion ID in the task completions export and UUID in the reports export |
| Meaning | Signature meaning per 21 CFR Part 11 §11.50: "Performed and confirmed" (performer), "Reviewed and approved" (reviewer on approval), "Change approved" (decision on a request) |
| Method | PIN = personal signature PIN, entered in addition to the sign-in; in the portal also password, in the app also NFC chip or QR code |
| Status | Signed (check successful), Rejected (PIN wrong or locked), Failed |
| Failure reason | for Rejected/Failed the reason |
| Checksum (SHA-256) | Hash over the signed content (record, template and version, signer). The same hash is in the task completions export and as a prefix in the PDF evidence |
| Device | Device identifier of the signing device; empty for signatures in the portal |
| IP | only filled for signatures in the portal |
| Manifest ID | Unique ID of the signature event |
Reading notes
- Signatures are inseparably linked to the record: the table is immutable, and a signed form is not changed any more. A correction creates a new version with a new signature; the original remains visible with its signature as Superseded.
- When signing, a checksum over the stored record is saved. With it, every later change to the signed record can be proven. The column Status shows the result of this check: Signed (record unchanged), Modified after signature, Cancelled, Superseded. Signatures with the suffix "(v1, not recomputable)" carry an older checksum version without recomputation (see Signature status).
- Rejected PIN entries appear in this file with status Rejected and failure reason and additionally in the access log (event "Electronic signature" with failure reason).
Task completions
Covers: who completed which task at which checkpoint and when, with form, approval, signature and cancellation (process data).
| Column | Meaning |
|---|---|
| Type | Completed, or Not feasible (with reason) |
| Task | Task title |
| Property | Property |
| Checkpoint | Area · room where the chip or QR code was scanned; empty for a task without checkpoint |
| Occurrence | Planned day of the series occurrence the completion is assigned to |
| Completed at (local) / (UTC) | Time of the completion |
| Person / Username / Personnel number | Performing person, frozen |
| Source | Form = completion via the filled form template; App scan = completion by scan at the checkpoint without form |
| Form status | Submitted, Draft; empty for app scan |
| Approval | Approval pending, Approved, Rejected; empty if no approval is configured |
| Checklist | Ticked items of a task checklist (not the form check items) |
| Photos | Number of photos attached to the completion |
| Delay reason | Reason when completed after the time window |
| Reason (not feasible) | Reason for type "Not feasible" |
| Note | Free text of the performing person |
| Signature status | Signed / Not signed / Rejected |
| Signed by | Full name (username) of the signer |
| Signer role | Role of the signer at the time of the signature |
| Signed at | Signature time, local |
| Checksum (SHA-256) | Hash of the signature, identical to the signature log |
| Completion ID | Unique ID of the completion |
| Form ID | ID of the associated form; identical to Object UUID in the signature log and UUID in the reports export |
| Cancelled at / Cancelled by / Cancellation reason | For cancelled completions time, account and reason [Code] text; empty for active rows |
Reading notes
- Occurrence is the calendar day the completion counts for; Completed at is the time of the completion (device time if it is at most one hour behind the server time and at most five minutes ahead of it, otherwise server time). Cancelled completions remain in the file with time, account and reason.
- The form check items themselves (OK/defect per surface) are in the reports export (column Content) and completely in the form PDF.
- The system rejects every subsequent addition to a signed completion (note, checklist, photos). The signature stays linked to the signed content.
Reports (submitted forms and incidents)
Covers: every submitted form with template, status, approval, signature and short content, plus the incidents.
File structure: row 1 is the header row. After the last data row, separated by an empty line, follows a KPI block. When opening in Excel: table from row 1, KPIs at the end read separately.
| Column | Meaning |
|---|---|
| Time | Submission, local time, with seconds |
| Time (UTC) | Submission in UTC |
| Type | Form (filled template) or Incident |
| Title | For forms the name of the form template the form was filled in with; for incidents the text excerpt |
| Property | Property |
| Person | Full name of the submitting person |
| No. | Personnel number of that person |
| Status | Submitted, Draft, Superseded (replaced by a corrected version), Cancelled; empty for incidents |
| Approval | Approval pending, Approved, Rejected; empty for incidents |
| Approved by / Approved at | Decider and time of the reviewer approval |
| Signature | Signed / Not signed |
| Signed by | Full name of the signer |
| Signed at | Signature time, local |
| Category | Category of the template or incident; "No category" if none assigned |
| Content | Short version of the filled check items; defects and photos completely in the form PDF |
| UUID | Unique ID of the record; only in CSV and Excel, not in the PDF of the list |
Reading notes
- A submitted form is not changed any more. A correction creates a new version; the old one gets the status Superseded and keeps its signature.
- Which version of the template applied at the time of filling is documented by the settings audit trail: area Form template, row
Version: v4 → v5with time and reason.
Form PDF
Covers: the single signed record as presented to the auditor.
| Section | Content |
|---|---|
| Header | Template, checkpoint and property, time of recording, performing person |
| Notice banner | "Defects recorded" if at least one check item was closed with a defect |
| Check items | Per surface or procedure the result: OK, or defect with defect type and note |
| Approval | Status of the reviewer approval: Pending, Approved, Rejected (only for templates with reviewer approval) |
| Digital signature (Part 11) | Status, full name, username and role of the signer, method (PIN), meaning ("Performed and confirmed"), signature time with seconds and time zone, hash prefix. "Sign-in: offline (device)" means: the PIN was checked on the device and confirmed by the server on transmission |
Reading notes
- The full SHA-256 hash for every record is in the signature log and in the task completions export; the PDF shows the first 16 characters.
- After a reviewer approval the PDF receives a second signature block with the meaning "Reviewed and approved".
- The PDF is a rendering of the record. The record with its signature in the database is authoritative. Both remain retrievable together.
Template definitions and change requests
Covers: which check items every form template has today, in which version, and which changes have been requested, decided or are not yet effective. The template definitions answer the question "Which check items does form X have today?", the settings audit trail the question "since when and why?".
Template definitions: one field per row; the template header repeats in every row.
| Column | Meaning |
|---|---|
| Template | Name of the form template |
| Description | Description text of the template |
| Version | Running version number; every content change increases it by 1 |
| Status | Active (usable in the app), Draft, Archived |
| Kind | Form or Incident (system template) |
| Reviewer approval | Yes: submitted forms of this template wait for an approval by a reviewer |
| Signature requirement | Rule for the electronic signature. "E-signature: as property" = the requirement is set on the property or the task. "Signature (drawn)" = the template additionally contains a field for a drawn signature |
| Property assignment | "All properties" = template applies to all properties of the account; after the colon the properties it is explicitly assigned to |
| Last changed (local / UTC) | Time of the last version change |
| Template ID | Unique ID, identical to the template ID in form and signature exports |
| Step | Heading of the section the field belongs to (empty if the template has no sections) |
| Check item | Text of the check item or field |
| Field type | OK/defect = check item with result OK or defect; Yes/No; Heading; Photo; Long text; Short text; Date; Time; Number; Choice; Multiple choice; Signature; Property selection; Checkpoint; Repeatable block |
| Required | Must be answered before submitting (empty for headings) |
| Conditional | Field appears or becomes required only under a condition |
| n/a allowed | May be skipped with "not applicable" (OK/defect fields only) |
| Defect types | Choice on "defect"; the app automatically appends "Other" with a mandatory text |
| Note required on defect / Photo required on defect | Whether a note or a photo is enforced on "defect" |
| Options | Options for OK/defect, Yes/No and choice fields, separated by a vertical bar; options marked with * count as a defect |
| Field ID | Technical identifier of the field |
Change requests: all requests of the change approval. Every requested content appears with requester, reason and content (old → new). Requested content that has not been decided is not effective.
| Column | Meaning |
|---|---|
| Requested at (local / UTC) | Time of the request |
| Requested by / Username | Requester, frozen at request time. Suffix "(current)": the request dates from before names were frozen; the name comes from today's account |
| Type | Configuration change or record archiving |
| Area | Form template, Role, Task rhythm, … |
| Subject | Affected record with name, for status changes with the target status |
| Property | Property, if the record belongs to a property |
| Reason | Reason given by the requester |
| Change | Content of the request as Field: old → new, several fields separated by a vertical bar; added check items with type and required flag |
| Status | Open, Approved, Rejected |
| Decided by / Username (approver) / Decided at (local / UTC) | Approver and time of the decision (empty for open requests) |
| Decision note | Note of the approver, or the system reason for an automatic rejection, starting with Automatically rejected |
| Signature status / Signature meaning / Checksum (SHA-256) / Manifest ID | Electronic signature of the decision; No signature for open requests or requests that did not require a signature |
| Request ID / Batch ID | Unique identifier of the request and of the batch it was submitted in |
Approval happens in the portal under Settings → Change approvals by a second administrator with signature. The decision (who, when, note, signature) then appears in this file and in the settings audit trail.
User list
Covers: all user accounts of the account with role, status, allowed sign-in methods and last sign-in (access control).
| Column | Meaning |
|---|---|
| Name | Full name of the account |
| Username | Sign-in name (unique, personal; no shared accounts) |
| Personnel number | Personnel identifier of the account |
| Role | Role of the account |
| Status | Active, Deactivated, Invitation open, Archived |
| Access | All properties or selected properties only |
| Properties | Assigned properties if access is restricted |
| Login methods | Allowed sign-in methods (password, NFC chip, QR code, Microsoft, passkey) |
| Microsoft linked | Account linked to Microsoft sign-in |
| Two-factor | Second factor for sign-in active |
| Last login (local / UTC) | Time of the last successful sign-in |
| Created (local / UTC) | Time of account creation |
| Belongs to | Parent account (e.g. subcontractor), otherwise empty |
| Language | Language of the user interface |
| Account ID | Unique ID of the account |
Reading notes
- Customer logins (read-only access) are not included.
- The signature PIN is personal per account and never appears in plain text. Its checks are in the access log.
- Every creation and change of an account is traceable with old/new in the activity log (source Account change).
Cross-checking across the files
- Form ID (task completions) = Object UUID (signature log) = UUID (reports).
- Checksum in the signature log = Checksum in the task completions = hash prefix in the form PDF.
- Every signature in the signature log has a PIN check ("Electronic signature") in the access log (activity log) at the same time.
- Every change in the settings audit trail appears in the activity log under source "Settings audit" at the same UTC time (within the 31 days).
- Title and Category in the reports export refer to the template definitions; the version history in the settings audit trail documents who created the version, when and why.
- Role and Personnel number per account (user list) match the entries in task completions and signatures.
Machine cross-check
The same change history is available via the REST API v1 (scope audit:read):
| Method & path | Purpose |
|---|---|
GET /api/v1/config-changes?include=values | Settings audit trail with old and new values, reason and username |
GET /api/v1/change-requests | Change requests with status and decision |
GET /api/v1/form-templates/{id} | Template with check items and version (scope form_templates:read) |