Browser workflow · UI39
Conduct a toolbox talk
Prepare the briefing, save it, then collect personal acknowledgements
Choose the exact form
Open Toolbox Talks → New toolbox talk. Search the available published forms by title or document code and choose the required revision. No form is selected automatically. A form that changes before creation is refused; choose its current publication rather than silently using a different version. The talk keeps a fixed form snapshot.
Creating or publishing reusable forms remains an administrator workflow in Forms & templates. This update simplifies conducting a talk, not the controlled form-authoring workflow.
Record the briefing on one page
Enter the site, work description and UTC briefing time. Project number, client and JSA reference are in Project & references. The displayed initial time is the device's current UTC time; check it against the actual briefing. Mark only topics genuinely discussed. Understanding answers start Unanswered; neither selecting participants nor marking discussion topics answers them or signs anything.
The compact summary shows topic ticks, Yes answers and listed people. It describes the open form, not saved readiness, attendance or completed work. Save briefing permits incomplete preparation with the required details. It does not finalise the talk, open a QR or authorise work.
Choose people without losing hidden selections
People with accounts is optional while preparing. Find a person by name, login or account ID. Search hides rows but keeps their selections. Select visible eligible people and Clear visible selections affect only the search results; existing hidden choices remain. A retained saved/draft reference unavailable in the current directory is shown, never silently dropped. The hub checks current eligibility before saving.
Use Named guests for the separate witnessed-acknowledgement workflow on the facilitator's device. New empty guest rows can be removed directly; removing a guest from the saved roster asks for confirmation. Up to 150 listed people including guests are supported. A name in the roster is not an acknowledgement. Alternatively, after saving a ready discussion, authorised organisers may invite named accounts or temporary visitors through the existing QR workflow. Do not pre-add a manual guest and treat a separate self-declared QR identity as automatically the same person.
Routine preparation needs no reason
Changes to your own open talk before any acknowledgement or issued QR invitation need no generic explanation. The account, time, version and complete before/after values are recorded automatically. A previous genuine note in a restored local form is preserved as optional text.
Correcting another author's talk, a previously signed or QR-shared talk, or a record lacking complete local history still needs a short correction explanation. Closing or expiring a QR does not erase the fact it was issued. Previous signatures remain evidence even after a correction clears the current acknowledgement list. The hub checks this again during save; a stale form cannot bypass it.
Any changed content or roster advances the content version, clears current acknowledgements and invalidates outstanding invitations. Earlier evidence remains in History and the signing ledger. Saving identical values remains a no-op. Final or cancelled talks cannot be rewritten.
Sign and finalise separately
After saving, use Invite to sign / signatures for the existing restricted QR process, or the existing personal/witnessed acknowledgement controls. At least one discussion topic must be recorded and all understanding questions must be Yes before acknowledgement. A No or unanswered question must be revisited; it is not automatically changed by this form.
Only each account holder may acknowledge for themselves. The witnessed guest method requires the guest's affirmation and the facilitator's genuine witnessing; QR visitors are labelled self-declared, not witnessed. A short-lived QR or drawn mark does not prove identity or physical attendance. Finalisation checks the saved participants and their acknowledgements and locks the talk. It is not permission to start work.
Download the ordinary toolbox PDF or, as author, the separate revision-specific signing PDF/JSON from Saved signatures. This update changes neither signing, expiry, report evidence nor the invitation permissions.
Keep local work and retry safely
Keep draft & close uses the existing account-scoped local form. Resuming retains original values, selected identities and original version; it does not silently rebase on another tab's changes. Fresh reads check current access and availability. Changed accounts, routes, editors or interrupted dialogs prevent a delayed read from covering unrelated work.
After a confirmed save and successful local-draft cleanup, the exact saved talk opens. A lost response or local cleanup failure keeps the same request available for retry, without duplicate talks or audit events. A conflicting saved version is refused, with your wording retained. Do not clear browser storage or reset the project. Local test fixtures do not establish real-device durable-storage acceptance; native forms and the master guide were not rebuilt.
Invite people with one QR
The saved document’s author can choose Invite to sign in the browser. The author also needs Document invitations → Issue document-specific QR invitations and the module’s normal conduct/create access. Show the QR or use Copy link. Show QR · 5 minutes opens one group invitation for several people; it is not consumed by the first scan. Creating a replacement QR ends the older invitation and its unfinished visits.
Allow temporary guests starts off. Enabling it requires the separate external-visitor permission. Visitors give their own name and optional company, read the exact wording and choose Sign & finish. A drawn mark is optional. Named users can use their current personal account or sign in on this separate page. The shared demo guest cannot issue personal invitations or sign as a named person. No ordinary project account or main-app session is created for a visitor.
The QR admits people for 5 minutes. Each admitted visit lasts up to 10 minutes, with a 3-minute idle expiry; the visible page sends a 30-second keepalive. Sign & finish ends document access immediately. Close invitations ends new admissions and unfinished visits; hiding the organiser panel alone does not close it. A server restart ends unfinished invitations. Closing the visitor tab is only a best-effort signal, not the security boundary.
The organiser sees admitted people and saved signatures. Download signing evidence exports the exact saved document snapshots, identities, server times and optional drawing coordinates as JSON, not attached file bytes. Evidence records both the full publication fingerprint and the exact displayed wording/shared file IDs; unshared attachments are not presented as files the visitor could read. The panel shows the latest 500 signatures; the export explicitly reports truncation above 2,000. After a lost response, keep the page open for the identical retry or saved-outcome check. Receipt recovery does not restore document access.
A self-declared visitor is not identity-verified or witnessed. A QR may be forwarded: neither scanning, a name nor a drawn mark proves physical attendance. An anonymous person may rescan a still-valid group QR under another name. This release does not add individually issued invitations or organiser-admission approval. Downloaded files and screenshots cannot be recalled. Use HTTPS on a reachable hub; this feature is not offline signing or vessel/cloud synchronisation.
Save the open briefing’s actual discussion and all understanding answers as Yes before inviting signatures. An empty initial attendee list is allowed; a QR participant is added only when their signature saves. Joining does not itself sign, add a roster row, finalise the talk or change its discussion. QR additions preserve the current content revision and earlier signatures. Ordinary edits to content or the roster still create a new content revision and require renewed acknowledgement. A changed, cancelled or finalised talk ends outstanding signing access.
Named QR signatures join the normal account acknowledgements. Visitor QR signatures appear as Self-declared visitor via document invitation, distinct from the existing facilitator-witnessed guest method. All listed attendees must have a recorded acknowledgement of the current content before normal finalisation; a QR never overrides an unanswered/No question. The normal PDF lists names, methods and times. Optional drawn marks are retained in the invitation panel/evidence export, not printed as signature images in that PDF.
Download a signing PDF
In the saved document’s Invite to sign / signatures panel, open Saved signatures and select Download signing PDF · revision N. The current selected revision has its own button; other saved signing revisions are under Other signed revisions. An older revision is never silently replaced with current wording.
The PDF includes the saved participant names, account or self-declared visitor identity, timestamps, optional drawn marks and the exact wording displayed through those invitations. Where some participants were given published attachments and others were not, separate Read sets identify the scope each signed. Attachment filenames and fingerprints are listed only for the scope where they were shared; file contents are not embedded or downloaded again. This does not verify that someone opened every attachment.
The author needs their current named account and existing document-management access. This is a protected report, not a visitor download or a new public link. It remains available from retained evidence after the invitation ends or the document is archived/finalised, as long as current author access permits it. Current private drafts, a later publication and normal acknowledgements made only outside invitations are not merged into this PDF.
Raw evidence → Download signing evidence (JSON) keeps the technical archive export. A PDF contains one revision, up to 300 invitation signatures, without silent truncation; larger revisions must use the JSON export. JSON retains its separate 2,000-signature limit with explicit totals/truncation. The panel lists up to 200 recent signed revisions and states when earlier entries are not listed. Characters unsupported by the report font use explicit [U+code] notation; exact original strings remain in JSON.
Downloading does not sign, add a participant, mark attendance, change the handover or close invitations. A self-declared visitor and a drawn mark are not verified identity or proof of physical presence. Share the downloaded report only with authorised people: exported copies cannot enforce later access changes. This is a separate signing report; ordinary toolbox/handover PDF outputs and their existing scope are unchanged.