Audit trail & export briefcase

The Audit trail is the tenant-wide record of what happened to your records — welds, ISOs and inspections — as opposed to the Audit log, which records administrative actions such as role changes and account locks. The Export briefcase on the same screen assembles one scope of that trail, with the documents and signatures attached to it, and an integrity manifest describing exactly what was assembled.

The same event history for a single weld appears in that weld’s History section — open a weld from the weld matrix and scroll the drawer.

Before you start

• Viewing the Audit trail needs a Corporate Administrator role or higher. Without it the screen shows an Access required notice rather than an empty list, so a refusal is never mistaken for “nothing happened”.
• Reading a weld’s own History in the weld drawer needs no additional role beyond access to the weld — it is scoped to that weld, not to the tenant. Both surfaces read from the server and have no offline copy; offline they say so rather than showing an empty history.

The trail is narrowed to what your account may see

“Tenant-wide” describes the breadth of the question, not a guarantee that you are shown every event in the tenant. A Corporate Administrator whose account is scoped to particular contractors, NDT contractors or inspection types sees only those rows here, and if you belong to more than one party, the party you are currently acting as narrows the slice too. That scoping is deliberate and is kept separate from the role, so two administrators — or one administrator acting as two different parties — can read the same screen and see different slices. The screen cannot tell the difference between “nothing happened” and “nothing you may see”: an empty trail with no filters says “No audit events in this view”, and an empty filtered trail says no rows match your filters, but in both cases read it as “nothing you may see”, not as proof the tenant has no history. The same applies to a bundle you export from this screen. If you are assembling evidence that must be provably complete, confirm your own account’s scope and the party you are acting as first.

Read the trail

Open Admin → Audit trail. Events are listed newest first, one row per recorded event:

• When — the time of the event, shown in your time zone.
• Event — a plain-language description with a severity dot beside it (a rejection reads as critical, a completion as positive). The wording is the same wording the weld drawer’s History section and the ISO Activity tab use.
• Actor — who performed it. A non-human actor (an import, a system rule) is shown as a labelled tag rather than a name, so it is never mistaken for a person.
• Provenance — who keyed the event versus who performed the underlying work: entered for a welder, on behalf of another user, import-derived, or backdated. A dash means the event carries no provenance record (ISO events do not).
• Subject — the record the event happened to, for example weld #501.
• Project and ISO — where the event came from. A tenant-wide reader is looking across every project, so each row says which one it belongs to.

Narrow it

Four filters narrow the trail. Each one you set on the screen is sent to the server, so paging and the event count always describe the filtered slice rather than one page of it:

• Search — free text matched against the action, the actor and the event detail.
• Any actor — one person, picked by name.
• All event families — Weld, ISO or Inspection. Test-package events are not covered yet — see the note at the end of this section.
• From (UTC) and To (UTC) — an inclusive date range. The bounds are UTC days, while the When column is shown in your own time zone, so the two can differ by your offset at the edges of the range — widen by a day if an event near midnight matters.

The filters live in the page address, so a link to the trail carries the slice you were reading. If a link carries a filter the screen cannot use — a date that does not exist, a date before 1753, an actor that is not a person’s id, or an event family the trail does not hold — that filter is left out of the read and a red line beside the filters says so, so you can correct it. A date before 1753 stays in its box; a date that does not exist, an unusable actor or an unknown event family clears back to its default. An old link saved before the Test package filter was withdrawn behaves this way.

Test-package events are not in the trail yet

The trail covers welds, ISOs and inspections. Test-package activity — releasing a package, adding or removing an ISO from one — is recorded, but the trail does not yet return it, so there is deliberately no Test package filter on this screen rather than one that would always come back empty. Until it is covered, use the test-package screens themselves for that history. The same applies to a bundle exported from this screen.

Export a scope

The Export briefcase sits below the trail.

1. Choose a Scope — the whole tenant, one project, one ISO or one weld. Every scope except the whole tenant asks for the record’s id. A weld’s bundle covers the same history as the History section of its weld drawer, including its repair chain.
2. Optionally set From (UTC) and To (UTC) — the same UTC-day bounds the trail filters use. A bound the screen cannot use (a date that does not exist, or one before 1753) disables Assemble bundle until you correct it, with a red line beside the boxes saying why. Assembling is recorded against your name and cannot be withdrawn, so a mistyped year must not quietly widen the export instead of narrowing it.
3. Select Assemble bundle. Selecting it again re-reads the server, so a bundle is always assembled fresh rather than re-shown from the previous one. What you see below the controls is always the result of your last selection, or a line saying why there is none — an earlier bundle is never left on screen under a newer request. If the request cannot be sent because you are offline, the panel says so and tells you nothing was sent and nothing is queued for later. If the server refuses it, the panel names the refusal — Access required when your account may not export that scope, Bundle too large when the scope needs narrowing — and any other failure shows the server’s own reason with a Retry. Assembling a bundle is recorded in the audit record itself, so it is never done on your behalf in the background.

The server assembles the slice and returns it with its integrity manifest. The screen shows:

• Generated and Generated by — when the bundle was built, and by whom.
• As of — the as-of truncation instant the bundle honoured. Today this always reads Not applied — no as-of truncation, because as-of bundles are not available yet — see the note below. It says nothing about the From/To range, which is a separate control.
• Scope — the scope the bundle was asked for, as the server recorded it. Read it with the note above: it names the breadth of the request, not a guarantee that every record in that breadth is inside the file.
• Date range asked for — the From/To bounds your browser sent with this assembly. This one line is not part of the server’s manifest and is labelled as such on screen: the manifest records the scope but not the date range, so this is the only place the narrowing is visible.
• Audit entries, Documents and Signatures — how many of each the bundle contains.
• One row per artifact with its exact byte length and its full SHA-256 digest.

Save as JSON saves the assembled bundle to your computer. It contains the server’s response and nothing else — MaxTrax adds no figure of its own to the file — though the file is re-indented for readability rather than being a byte-for-byte copy of what came over the wire. That does not affect checking it: each digest in the manifest covers its own artifact’s contents, not the file’s formatting.

A narrowed bundle does not say so in the file

If you set From or To, the saved JSON contains only that slice, but the manifest inside it has no field for the range — so the file itself cannot show that it was narrowed. The Date range asked for line on screen is deliberately not written into the file, because the file must carry only what the server attests. If you narrow the dates, record the range alongside the file when you hand it over. Recording the range in the manifest itself is planned.

Every figure shown is the server’s

MaxTrax never recalculates any part of the manifest in your browser — not a count, not a digest, not a byte length. The digest is shown in full rather than shortened, because a shortened digest is not the value the manifest attests. If a figure looks wrong, it is the figure the server produced, and that is what an auditor needs to see.

As-of bundles are not available yet

A bundle cannot be truncated to a point in time. Attached-document metadata carries no event timestamp, so a bundle truncated at an instant could not honour that instant across all three of its parts — and a manifest must never attest a cut-off one of its artifacts does not keep. There is deliberately no As of control on this screen, and the briefcase never asks for one; use From and To to narrow the range instead. If the server ever answers a bundle request with its as-of refusal, the panel shows As-of bundle refused with the rule’s name rather than a generic error.

Bundles are assembled while you wait

A bundle is built in one request rather than queued as a background job, so a very large scope can take a while. A scope too large to assemble is refused rather than quietly cut short — you will see Bundle too large, with no Retry, because the same request would be refused again: narrow the scope or the date range and assemble again. A manifest is never issued over a partial bundle. The briefcase also needs a connection: offline, it tells you the request was not sent rather than appearing to work.

What happens next

The saved bundle is a record of what the trail held at the moment it was assembled. Its manifest is what lets a recipient check that the file they received is the file that was built: re-computing the SHA-256 of each artifact and comparing it with the manifest’s digest either matches or does not.

Related

• Audit log & traceability — the administrative trail (roles, locks, settings) and the audit-log report.
• Admin overview
• Roles & capabilities — what a Corporate Administrator can see.