Append-Only Audit Log for Lightning Risk Assessments

An append-only audit log is evidence only when entries are added as the work happens and nobody can change them afterwards.

A lightning risk assessment passes through several hands before anyone relies on it. An engineer enters the building, a reviewer checks it, a report goes to an owner, an insurer or an authority. When a question comes later, the first thing anyone asks is who changed what, and when. A log that can be edited cannot answer that, because a quiet correction looks exactly like the original entry.

This page sets out the principle, then states exactly what Lumex records today, what the guarantee rests on, and where it stops. It sits beside traceable, reproducible risk figures: that principle covers how each number was reached, this one covers who acted on the assessment.

The principle

Why an audit trail must be append-only

An audit trail has one job: to let someone who was not there reconstruct what happened. It can only do that if each entry is written at the moment of the action and never touched again. Append-only means exactly that. New entries go on the end. Old entries are neither corrected nor removed, even when they record a mistake, because the mistake is part of the history.

The risk clauses themselves are about the comparison, not the records. IEC 62305-2:2024 clause 7.3 asks you to compare the risk with its tolerable value, and NFPA 780-2026 L.6.5 asks the same for each type of loss. Neither clause says how to prove later who entered the inputs or who approved the result. That falls to the tool and to the firm that signs the report.

What Lumex records

Two records, each with its own audience

Lumex keeps customer work and Webority staff work in separate logs. Both are only ever added to.

The workspace activity record

Each change your team saves to an assessment, a project or a project document, a new assessment draft starting or being removed, and each review step adds a line naming the person, the action, the assessment reference and the time. The line is written in the same database save as the change, so a change that fails to save leaves no line. Workspace admins read it on the activity page.

The staff audit log

When a Webority operator suspends or reactivates an account, changes a subscription or feature access, issues a refund or replays a payment notification, an entry records the operator and the outcome, and for some actions the values before and after. A bulk recompute of stored assessments writes one entry per assessment with the standard and edition it ran under, and records a failure as a failure.

A line in your workspace record names a signed in member of your workspace, or the Webority support team when it replies to or resolves one of your support tickets. A change saved with nobody signed in, such as a payment notification, is filed under the workspace owner with a note that it was recorded automatically. Any other change saved from the Webority admin portal writes no line in your workspace record, rather than invent an actor.

What the guarantee rests on

Nothing in Lumex edits or deletes an entry

The guarantee comes from how the application is built. Staff audit entries are written through a writer that only appends, and the query side can list and find entries and do nothing else. The audit package can also delete entries past a retention period, but Lumex has not switched that on. The workspace record is served by endpoints that only read. No screen, API or job in Lumex updates or removes a row in either table.

Review decisions follow the same rule. Once a reviewer approves, rejects or sends back a report, that decision is fixed, and an attempt to change it is refused. Reopening a review starts a new round beside the old one, so the earlier decision, its note and its date stay on record. Removing the assessment removes its review rounds with it, while the activity lines for each step stay. The sign-off itself is described in the engineer signs, the reviewer checks.

A report download is not an edit, and Lumex does not record it as one. Producing a report stamps only the first time it happened, outside the save path that feeds the activity record, so opening a finished report never adds an Updated line.

Where it stops

What the audit log does not do

A principle page that claims more than the product does would break the principle it describes. These are the limits as they stand today.

Question	Workspace activity record	Staff audit log
Who it covers	Members of your workspace, automatic events filed under the owner, and support replies to your tickets	Webority operators and Lumex system jobs
Who can read it	Workspace admins, on the activity page	Webority administrators, in the admin portal
What one entry holds	Who, what action, which record, when. Not the values that changed	Who, what action, outcome, and for some actions the values before and after
Edited or deleted by a screen, API or job in Lumex	Never	Never
Enforced by the database itself	No. The rule lives in the application	No. The rule lives in the application
Sealed against tampering, for example by hashing	No	No
If the entry cannot be written	For an assessment or project change, the change is not saved either	The action still stands and the failure is logged as an error

More limits matter to an auditor. A draft autosave and a save that changed nothing add no line. The first report produced for an assessment fills in an empty next review date without a line. The workspace record shows a person by their current name, so a renamed user appears under the new name on older lines. And the last updated by and last updated time on an assessment are a single stamp that each save overwrites, not a history; the activity record is the history.

Where Lumex fits

An audit trail beside figures you can trace

The activity record answers who acted on an assessment. Voltrace, the calculation engine, answers how each figure was reached: it computes the method of IEC 62305-2:2024, NFPA 780-2026 Annex L or AS 1768:2021 and shows the working behind every number, and each verdict is stored with the time it was reached. Lumex holds the current inputs and figures of an assessment, not every past version of them, so the report you issue is your record of what the figures were on that day.

Related principles: why figures must be traceable and reproducible, why the engineer signs and the reviewer checks, why the current edition is held as data and why the assessment is independent of protection products. For the standards Lumex runs, see the standards, and for the product as a whole, the platform.

FAQs

Questions answered

What does the append-only audit log record about an assessment in Lumex?

It adds a separate line for each recorded change: who acted, when, what they did and which assessment it was. That covers creating, updating and removing an assessment, uploading project documents, assigning an engineer or reviewer, setting the next review date, and each review step: submitted, approved, rejected or sent back for changes. The line is written in the same database save as the change. A save that changed nothing, and a draft autosave, add no line.

Can anyone edit or delete an entry in the Lumex audit log?

Not through Lumex. No screen, API or background job in the product edits or deletes an entry in either record, and the staff log's sweep for old entries is not switched on. The rule lives in the application. It is not a database permission or a cryptographic seal, so someone with direct access to the database could still change a row. We say so rather than claim more.

Does the audit log show what values changed in an assessment?

No. The workspace record says that an assessment was updated and by whom, not which inputs moved or from what to what. The assessment itself holds its current inputs and the figures computed from them, with the working shown. If you need the previous version of a figure, keep the report you issued: Lumex does not keep a version history of every past calculation.

Are actions by Webority staff recorded?

Yes, in a separate staff audit log. When a Webority operator changes an account, its subscription, its feature access or a refund, or replays a payment notification, an entry records who acted and the outcome, and for some actions the values before and after. A bulk recompute of stored assessments writes one entry per assessment, naming the standard and edition used. An action that failed is recorded as a failure, with the reason.

What happens to the review history when a report is reopened?

It is kept. Once a reviewer approves, rejects or requests changes, that decision cannot be changed. Reopening the review starts a new round beside it, so the earlier decision, its note and its date stay on record. Removing the assessment itself removes its review rounds, but the activity lines that recorded each step stay. See how the engineer signs and the reviewer checks for the full sign-off flow.

Is downloading a report recorded as an edit?

No. Opening or downloading a report never adds an Updated line and never moves the assessment's last-updated time. Lumex stamps the first time a report was produced in a separate write, outside the save path that feeds the activity record. That first write also fills in the next review date when none was set, and that fill adds no line. It is one of the gaps listed on this page.

What Lumex does, and what stays with you

Lumex computes the method of the standard you choose, IEC 62305-2:2024, AS 1768:2021 or NFPA 780-2026, and shows the working. It does not certify a structure. You may not issue or submit a Lumex output until a competent person, qualified where the structure is located, has reviewed the inputs and the result and signed it.

Each standard sets its tolerable values in its own way, and every assessment in Lumex states the values that applied.

An append-only audit log for lightning risk assessments, and its limits