Sentinel training centre

01

Open your organisation's Sentinel address. Use the website link supplied by your administrator. Choose the COMPANY selector after signing in; then select a workspace belonging to that company.

02

Sign in to your company portal. If the page asks you to sign in, use your assigned account. Contact your administrator if you do not have an account or cannot reset your password.

03

Open an assessment. Use the ASSESSMENT selector at the top. In this release, assessment, project and workspace refer to the same saved container.

04

Check the module buttons. Sentinel Investigate, Sentinel Bowtie and Sentinel Assure appear when allocated to the company and enabled globally. Pro appears within Investigate when allocated.

05

Check what you can change. Missing or disabled editing controls usually reflect your role or the enabled modules. A name entered in an owner field does not grant account access.

01

Select + New. Enter a short, recognisable workspace title. For practice, use TRAINING - Transfer hose review.

02

Choose Primary focus. Select Sentinel Investigate for an event investigation, Sentinel Bowtie for risk modelling, or Sentinel Assure for a control programme.

03

Select Apply changes. The new workspace is created as a Draft. Check that its title now appears in the top selector.

04

Open Project settings. Select Edit details. Enter Site / operation, Scope, Accountable assessment owner and Next assessment review.

05

Describe the boundaries. State which operation, equipment, location and period the workspace covers. Record assumptions and exclusions so other users understand the assessment.

06

Complete the bowtie context when relevant. If Bowtie is enabled and you are ready to model risk, enter the hazard and top event. An investigation-only workspace can begin without these.

07

Apply changes, then Save changes. Confirm that the unsaved indicator has cleared. Add any other users through Manage members if you are the workspace owner.

01

Choose Sentinel Investigate. Open Investigations and select + New investigation.

02

Name the incident or near miss. Use a factual title, such as TRAINING - Liquid released during a transfer. Avoid putting an unproved cause in the title.

03

Enter the event details. Select the event date, classification and investigation owner. Link a related barrier if one already exists; otherwise leave the relationship assessment-wide.

04

Choose the method and status. For this exercise, use 5 Whys and Investigating. Other choices include Why Tree, Root cause analysis and Barrier failure analysis.

05

Record initial notes. Use the narrative fields for known facts, immediate observations, analysis notes and lessons. Keep uncertainty explicit.

06

Apply and save. Select Apply changes, then Save changes. The investigation is now available in the case selector.

07

Check the selected investigation. Before adding evidence, timeline events or findings, select the intended case in the Investigation selector.

01

Open Evidence register. Select the correct investigation, then select + Evidence.

02

Give the item a recognisable title. For example: TRAINING ONLY - Hose examination exercise record.

03

Choose its type. Select Document, Interview, Photo, Measurement or Other.

04

Enter the source reference. Use a document number, controlled repository location or interview reference. The reference is required. Keep the actual file in the organisation's document store.

05

Explain its value and limits. In the summary, describe the observation and any uncertainty. Enter the custodian or source and the evidence date.

06

Assess reliability. Choose Unassessed, Corroborated or Disputed. Record the reasoning in the summary; a label alone does not establish reliability.

07

Apply and save. The evidence can now be selected when you edit a finding or timeline event belonging to this investigation.

01

Open Event timeline. Use the Investigation selector to choose the case.

02

Select + Event. Enter a short event title, such as Transfer started or Release first observed.

03

Enter the date and UTC time. Use the time field in HH:MM format. Convert local times correctly and state the original time zone in the description when useful.

04

Describe the event and conditions. Explain what was observed and by whom. If the exact time is uncertain, describe that uncertainty; do not make an estimate look exact.

05

Link the evidence. Select evidence from this investigation. Hold Ctrl on Windows, or Command on a Mac, to select more than one reference.

06

Apply and save. Repeat for the other material events. The displayed timeline sorts them by date and time.

07

Read the whole sequence. Look for missing periods, conflicting times and explanations that do not fit the order of events.

01

Return to Investigations. Select the case and choose + First why.

02

Enter the first question or finding. For example: Why did liquid leave the transfer system? Use Open question while the answer is unknown.

03

Check the parent relationship. The first finding normally explains the Investigation event. Later findings identify the finding they explain.

04

Choose a category. Use Equipment, Task, People and conditions, Organisation, Environment or Other. The category helps organise thinking; it does not prove a cause.

05

Record your reasoning. Explain what is known, what remains uncertain, what to examine next and why you might stop investigating this branch.

06

Link supporting evidence. Select references from the current case. Leave a proposed explanation as Hypothesis until its basis has been assessed.

07

Apply the finding. Select Apply changes, then use Ask why beside that finding to add the next explanation. Save the workspace regularly.

01

Choose the point where the explanation branches. Select the finding that needs another contributing explanation.

02

Use Add parallel cause. This creates a finding beside the selected one, with the same parent. Use Ask why when you want a deeper child explanation instead.

03

Enter the additional explanation. Set its status, category, rationale and evidence independently. One supported branch does not establish the others.

04

Apply and save. Adding parallel findings changes the investigation method to Why Tree. Expand to Why Tree can also mark the transition explicitly.

05

Inspect the tree. Select a card to edit it. Scroll the diagram for wide or deep investigations. Use Export Why Tree for an SVG copy.

01

Open the finding. Read its wording, parent, rationale and linked evidence together.

02

Check the supporting basis. To select Supported, provide a rationale and at least one non-disputed evidence reference. Assess the evidence yourself; the software checks the fields, not the truth of the claim.

03

Apply and save. If the form rejects the change, check the evidence links and rationale. An item marked Disputed cannot be the only supporting evidence.

04

Create a corrective action. Use + Corrective action beside the finding. The form links the action to that finding.

05

Make the outcome clear. Enter a title, responsible owner, due date, priority and required outcome. Keep the status Open or In progress while work remains.

06

Close only with completion evidence. When work is done, enter evidence before selecting Closed. Use Assure later to review whether the action achieved its intended result.

01

Choose Sentinel Bowtie. Open Bowtie studio, then Assessment details. Enter the hazard and top event; apply the form.

02

Add a Threat. Name the initiating cause and explain how it could lead to the top event. Repeat for other distinct threats.

03

Add a Consequence. Describe the potential harm. Select initial and residual likelihood and severity ratings using your approved organisational criteria.

04

Add a Barrier. Enter its name and choose Preventative or Mitigative. Select the matching threat or consequence pathway.

05

Describe its protective function. Choose Engineered, Human or Organisational, assign an accountable owner, and state a measurable performance standard.

06

Set its initial assurance information. Record the declared condition, verification due date, criticality and evidence basis. Use Unknown when condition has not been established.

07

Apply and save. Inspect the card on the correct side of the diagram. Open Barrier register to check owners, conditions and dates across the model.

01

Select the relevant barrier. Confirm the barrier's intended function and the evidence it relies on.

02

Choose + Degradation factor. In Bowtie studio or Barrier register, name the factor and select the barrier that may be weakened.

03

Explain the mechanism. Describe how the condition could reduce effectiveness. For example: an external examination may not identify internal hose deterioration.

04

Apply the factor. It becomes available as a parent for a degradation control.

05

Choose + Degradation control. Select the factor being addressed. Describe the protection, accountable owner, condition, standard and next verification date.

06

Apply and save. Inspect the dashed connections: barrier to factor, then factor to degradation control.

07

Verify the degradation control in Assure. It appears among the controls available for verification. Record actual evidence, not just its intended existence.

01

Check access and readiness. Investigate and Bowtie must both be enabled. You need editing rights in the source and owner, editor or reviewer access in the target. The finding must be Supported.

02

Save the source workspace. Unsaved changes block proposal preparation. Confirm that the current finding and evidence are the versions you intend to submit.

03

Choose Propose to Bowtie. Use the button beside the supported finding in Investigations.

04

Choose the target. Select an existing workspace, or enter a New bowtie title. A new target is owned by you; a separate reviewer will need membership before applying the proposal.

05

Select Apply changes to continue. The next dialogue asks how the finding should be represented in the target.

06

Choose the element and mapping. Select Threat, Consequence, Barrier, Degradation factor, Degradation control, Hazard or Top event. Choose Create a new element or Link to an existing element.

07

Complete the target details. Check the proposed label. For a barrier, choose its function and existing parent pathway. For a factor or degradation control, choose its existing parent. New consequences need explicit ratings.

08

Submit with Apply changes. The proposal is stored as Pending. Use Bowtie transfers to inspect its status and ask an authorised target reviewer to examine it.

01

Sign in as the target reviewer. You must be a target owner or reviewer, be able to read the source workspace, and be different from the person who proposed the transfer.

02

Open the target workspace. Select Bowtie transfers and use Refresh to retrieve the latest proposals.

03

Select Inspect proposal. Read the finding, rationale, source revision, ancestor findings, evidence references and proposed element type. Examine the original evidence through your normal document controls.

04

Check the destination. Confirm that the label, existing parent or linked target record matches the intended risk pathway. Save or reload other target changes before making the decision.

05

Select Review. Choose Reject / request revision or Apply mapping and reset target review. Enter a clear decision rationale.

06

Select Apply changes. A successful application records the decision and target record, retains the source snapshot, and returns the target workspace to Draft.

07

Complete the target assessment. Inspect the new or linked element in Bowtie. Add missing owner, standard and verification details through an authorised editor. Follow the normal workspace approval process afterwards.

01

Choose Sentinel Assure. Open Control register. It shows bowtie barriers, degradation controls and standalone assurance controls in the current workspace.

02

Decide whether a new record is needed. If the control already exists in Bowtie, use that record. Add a standalone control only when appropriate; avoid unnecessary duplicates.

03

Select + Standalone control. Enter a precise control name and accountable owner.

04

Choose the type and criticality. Select Engineered, Human or Organisational. Mark Safety-critical control only where your organisation has designated it as such.

05

Describe the performance standard. State what the control must achieve, how it will be checked and the acceptance criteria. Refer to an approved source where one exists.

06

Record condition, due date and scope. Keep unestablished condition as Unknown. Set the next verification date from the approved programme and explain boundaries or dependencies.

07

Apply and save. The control is now available under Control assurance for a verification record.

01

Open Control assurance. Select + Verification and choose the control being verified.

02

Name and date the check. Use a recognisable title and the date the verification took place. Future-dated verifications are rejected.

03

Choose the finding. Select Pass, Partial, Fail or Not checked. Base it on the standard and the evidence, not the desired result.

04

Identify the verifier. Enter the inspector or verifier and the evidence reference. Explain the finding and any limitations; both identity and evidence are required.

05

Enter Next due date when appropriate. Use the approved assurance programme. This is a schedule, not a prediction of when the control will fail.

06

Apply and save. Return to the register and confirm the displayed condition. Review Early warnings and raise actions where required.

01

Check the action record. In Actions, confirm the required outcome, responsible owner and completion evidence. Close the action only when the work is complete.

02

Open Effectiveness reviews. Closed actions without a review appear in Actions awaiting an effectiveness review. Use + Review beside one, or + Effectiveness review to select an action.

03

Define the review. Enter the title, linked corrective action, reviewer and a non-future review date.

04

State the criteria. Explain what would demonstrate effectiveness and the period or conditions observed. Avoid a conclusion based only on the work having been completed.

05

Record the outcome and evidence. Choose Not yet assessed, Effective, Partly effective or Ineffective. A conclusive result requires supporting evidence.

06

Plan further work. Partly effective and Ineffective results require a follow-up plan. Add a Next review date if another assessment is needed.

07

Apply and save. Check the review against the action. Create a separate follow-up action where somebody must do further work; a note alone does not create one.

01

Open Sentinel Bowtie → Risk ratings. Read the listed consequences and their initial and residual likelihood and severity.

02

Check the basis for each rating. Use the organisation's definitions and record the rationale in the assessment scope or consequence description.

03

Edit a consequence when justified. Select its title, choose all four 1-5 ratings, apply and save. Confirm its position in the residual matrix.

01

Save and check the content. Complete the required context and review evidence, open actions and warnings. Open Project settings.

02

Select Submit for review. Enter a Review note and rationale, then Apply changes. The status changes from Draft to In review.

03

Have a separate reviewer examine it. An authorised reviewer reads the records and supporting material, then selects Approve or Return to draft and records a rationale.

04

Check the resulting status. Approval is a human decision. The workspace owner and last content editor cannot approve the current workspace. Later content saves or applied transfers reset it to Draft.

01

Open the intended workspace. Check its title and whether you have unsaved changes. Exports include the current working copy.

02

Select Export. Choose a format from the dialogue. Save the download in an authorised location.

03

For a PDF report, choose Printable report. The download is HTML. Open it in a browser, select Print / Save as PDF, review the preview and save the PDF.

04

To import, select Import assessment JSON as a new draft. Choose a valid Sentinel JSON file, no larger than 2 MB. Import creates a new workspace rather than overwriting the original.

01

Open a saved workspace. You need owner, editor or reviewer access. The administrator must have configured the OpenAI connection.

02

Select AI assistant. Read the connection notice. Enter a question and the specific context you want processed.

03

Inspect the text before sending. Insert hazard and top event can add those fields for inspection. Only the text submitted in the dialogue is sent; the whole workspace is not automatically included.

04

Confirm authorised processing. Tick the consent box only when you are authorised to send that information to the configured external service.

05

Select Generate draft suggestions. Read the result, check assumptions and verify useful claims against evidence.

06

Use useful material manually. Copy or rewrite the relevant suggestion into the appropriate record. Apply the form and save through the usual workflow.

01

Create TRAINING - Transfer hose review. Use Investigate as the focus, set the site to Demonstration site, and enter an owner, scope and review date. Save. See page 6.

02

Create a hypothetical event. Use TRAINING - Liquid released during a transfer, method 5 Whys, status Investigating. Add two or three timeline events with clearly illustrative UTC times. See pages 7 and 9.

03

Create one training evidence record. Title it TRAINING ONLY - Fictional hose examination. Reference it as EXERCISE-E01, state explicitly that it is invented for practice, and describe what the exercise assumes. See page 8.

04

Build and branch the causal explanation. Add the first question, then a hypothesis about internal deterioration. Add a parallel hypothesis about service conditions. Keep uncertainty visible. See pages 10-11.

05

Support only the exercise's assumed finding. Link EXERCISE-E01 to the deterioration finding and explain the fictional basis. Leave the alternative Hypothesis until assessed. Add a linked action to review the examination programme. See page 12.

06

Build the training bowtie context. In the same workspace, define the hazard and top event. Add the appropriate threat/consequence pathways, with deliberately chosen training ratings. See pages 13-14.

07

Practise a reviewed mapping on company portal. Propose the supported finding as a degradation factor on an existing training barrier, or choose another justified mapping. A different authorised person must review it. See pages 16-17.

08

Continue in Assure. Complete a control standard, enter a clearly fictional verification record and create a fictional action-effectiveness review. Save and export a printable report. See pages 18-20 and 23.

01

Confirm the company. Check the COMPANY selector and your workspace title. Ask the system administrator to configure an annual company licence and allocate seats before adding workspace members.

02

Define the scope. Enter the site, owner, boundaries and review date. Keep training and operational work clearly distinct.

03

Add the team. Use Project settings → Manage members. Enter company user IDs and editor, reviewer or viewer roles. Retain every person who still needs access.

04

Assign an independent reviewer. The owner and last content editor cannot approve the workspace. A transfer reviewer also needs source access.

05

Configure email alerts when ready. The owner selects recipients and alert types in Email alerts. The administrator must configure authenticated sending from sentinel@safetyman.net and the scheduled worker.

06

Add sensor feeds only when specified. Enter the approved units, thresholds and freshness. Keep an unused feed disabled. Give its one-time credential only to the authorised gateway operator.

07

Check data collection. Open Forecasting. Daily observations start with the scheduled worker. New workspaces have no statistical history and cannot have a validated forecast.

08

Test your workflow. Use clearly fictional records, separate user accounts and a test recipient to confirm saving, review, reports and notifications. Then use the organisation's approved operating process.

01

Sign in with your own account. Use the assigned login. Do not share accounts; the history must identify the person making a change.

02

Choose the company. Use COMPANY in the top bar. Only authorised companies appear. Selecting another company clears the previous workspace from the interface.

03

Choose the workspace. Use ASSESSMENT. A company membership does not automatically grant access to every workspace in that company.

04

Ask for the access needed. The system administrator manages company membership. A workspace owner manages that workspace's editor, reviewer and viewer roles.

05

Keep transfers inside the company. Investigation-to-bowtie transfers cannot cross a company boundary, even where one person belongs to both companies.

06

Handle exports as separate copies. Downloaded files are outside the application's access controls. Store and share them only through authorised arrangements.

01

Open the same company workspace. Each participant signs in with their own account. Editors need a suitable workspace role.

02

Check the connection bar. It shows connectivity and recently active colleagues. Presence expires when a session stops reporting; it is an activity indicator, not a record lock.

03

Edit a record and select Apply changes. The connected suite schedules a save. Watch the saved revision indicator. Save changes can send pending edits immediately.

04

Allow compatible changes to merge. Different fields or independently created records can be combined against the saved base revision. The resulting workspace is validated and its approval returns to Draft.

05

Resolve an overlapping edit. If two people changed the same field differently, select Resolve conflict. Inspect My value and Saved value. Choose one for each conflict, then Apply changes.

06

Check relationships after resolving. Deleted records and dependent links are revalidated. A conflicting deletion may require exporting, reloading and deliberately reapplying the intended changes.

07

Recover carefully from a connection problem. Keep the tab open. Retry save, or Export my working copy before reloading. Unsaved form text has not yet been applied. Do not assume that a disconnected tab has synchronised.

01

Open Investigate → Investigation frameworks. Read the guide that matches the event and the analysis you need.

02

Select Start investigation. The selected method is prefilled. Name the event, record its owner and date, and describe known facts.

03

Apply the form and confirm saving. Continue in Investigations, Evidence register and Event timeline. The framework does not create evidence or causes for you.

04

Challenge each explanation. Distinguish hypotheses from Supported findings. Record alternative causes and the reasons for stopping the enquiry.

05

Extend the work. Expand to a Why Tree when needed. Propose supported findings to Bowtie and use Assure to check controls and action outcomes.

01

Open Sensor feeds and select Add sensor feed. Enter a recognisable name and its measurement unit. Select an existing control if the reading supports that control's monitoring.

02

Set the limits and freshness. Enter approved lower and/or upper thresholds. Expected freshness is 60 to 86,400 seconds. An empty threshold has no limit on that side.

03

Leave an unused feed disabled. Enable it only when the gateway is ready. Apply changes creates the connection.

04

Store the one-time credential securely. Copy the endpoint and Bearer credential into the authorised gateway's configuration. The secret cannot be retrieved later; rotate it to replace a lost or compromised one.

05

Send a test reading through the gateway. The interface accepts a unique eventId, UTC observedAt timestamp, numeric value and quality of Good, Uncertain or Bad. Unit conversion must happen at the gateway.

06

Inspect the latest reading. Check the value, unit, observation time, freshness and quality. No reading does not mean a normal condition.

07

Maintain the connection. Configure can change limits, disable the feed or rotate its credential. Rotation immediately invalidates the previous secret.

01

Ask the administrator to complete mail setup. Authenticated SMTP and the scheduled worker are required. The Email alerts page shows configuration and the last worker time.

02

Open Email alerts → Configure alerts. Enable automated alerts when the recipient list and testing plan are ready.

03

Select authorised recipients. Select company users who also have access to this workspace. Their account email addresses are used; display names typed into owner fields do not create recipients.

04

Select alert types. Choose overdue actions, failed checks, overdue verification, sensor thresholds, stale sensors and/or review requests.

05

Apply changes. The configuration is stored immediately. Recheck the enabled state and selected types.

06

Test through a fictional record. Use a designated test workspace and recipient. Create a clearly labelled past-due action, allow the scheduled worker to run and check the message and queue.

07

Read the queue state. Pending awaits processing or retry; Accepted means the mail service accepted the request. Failed means the retry allowance is exhausted. Cancelled means the notification is no longer eligible.

01

Open Forecasting. Read Observation coverage, the first observed date and complete-month count.

02

Use current records first. Early warnings describe existing conditions. The known-date projection counts currently open actions due by a stated date; it does not predict whether the team will finish them.

03

Keep dates and outcomes accurate. Record actual verification dates and results, event dates, action due dates and completion evidence. Do not invent entries to make a model available.

04

Keep the scheduled worker running. It records daily workspace measurements. The current day can be refreshed; previous days are retained as observations. Forecast aggregates retain three years.

05

Wait for sufficient complete months. A usable month needs an end-of-month observation, observations on at least 90% of days and an observation within its first three days. Missing months are not treated as zeros.

06

Inspect an experimental estimate. At least six consecutive complete months, including the latest completed month, are needed. The estimate is a three-month moving mean for the current month.

01

Open Inspect evaluation for a metric. Review the model identifier, dataset fingerprint, holdout predictions, actual counts and previous-month baseline.

02

Check chronological testing. Every rolling prediction uses only earlier months. Mean absolute error (MAE) summarises the size of prediction errors; lower is better for this comparison.

03

Check the quantitative gate. Acceptance needs 12 consecutive complete months, nine holdouts, at least six non-zero months, a total count of at least 10, a non-zero baseline error, and model MAE at least 10% lower than that baseline.

04

Review practical suitability. Examine coverage, changing exposure and inspection volume, bias, unusual periods and whether the estimate is useful for the proposed decision. A numerical pass alone is insufficient.

05

Record an independent decision. A workspace reviewer chooses Accepted or Changes required and writes a substantive rationale. The owner and last content editor cannot validate their own dataset.

06

Read the status precisely. Validation reviewed identifies a recorded acceptance of a qualifying evaluation. It is not certification of safety or assurance that future estimates will be correct.

07

Review again when the dataset changes. New complete-month observations change the fingerprint. The earlier decision remains recorded; the updated evaluation needs a fresh review.

01

Select your company and open Company subscription. This page works before the first workspace is created. Read the state, tier, start date and paid-through date.

02

Check the seat count. One block provides 10 seats; two provide 20. The same person uses one seat within a company, regardless of their number of workspaces. Membership of a second company uses a separate seat there.

03

Understand allocation. Managers, analysts, reviewers and viewers each occupy a seat. Signing out or disabling an account does not release it; the administrator must remove the company allocation.

04

Arrange an upgrade before capacity is full. Ask Safetyman International for more blocks. The system refuses extra allocations above capacity and will not silently evict existing users when reducing a limit.

05

Arrange annual renewal. The paid-through date is inclusive in UTC. Payments and invoices are handled separately. Sentinel does not collect money or automatically renew your contract.

06

Recognise read-only access. An expired, draft, suspended or not-yet-started licence preserves authorised reading and export. Editing, approvals, AI, sensor ingestion, email alerts and new forecasting observations pause.

01

Create the company and its annual licence. Use Companies & operations to create the company. In Annual licences, enter its ten-seat blocks, initial start date, tier, currency and state. Choose Active when agreed access should begin.

02

Record agreed pricing. Enter the annual price per block, or leave it blank. Enterprise can use an annual total override. Add the contract reference and select Save annual licence. No payment or invoice is created.

03

Create accounts and allocate seats. Assign appropriate Sentinel account roles in Users. In Companies & operations, select the company and named user, then the Member or Manager role. Manager adds visibility of commercial terms, not platform administration.

04

Grant workspace access separately. The workspace owner adds company users as editor, reviewer or viewer. Company allocation alone does not open every workspace. Workspace roles do not use extra seats.

05

Change capacity carefully. Add blocks and save to increase the limit. Remove surplus company allocations before reducing it. Seat and price amendments apply immediately; the application does not calculate proration.

06

Record a confirmed annual renewal. Select Renew one year once. An active period extends without losing current access. After expiry, a fresh year starts today. Licence revisions reject stale forms and duplicate submissions.

07

Inspect the audit and client access. The licence page lists allocation changes, amendments and renewals with the actor and UTC time. Check Company subscription and a non-administrator account after each access change.

01

Understand the extension. Investigate keeps 5 Whys, Why Trees, evidence and timelines. Pro adds a commissioning brief, hypothesis tests, causal connections, structured factor reviews and action assurance plans.

02

Keep the same records. Extending a case does not copy or replace its findings. Each finding and evidence reference retains its identifier.

03

Follow six stages. Define the questions; preserve sources; test explanations; explain contributions; act with measurable criteria; review independently.

04

Connect the suite. Reviewed findings can inform Bowtie threats, barriers or degradation controls. Assure records subsequent inspections and actual action effectiveness.

05

Understand the boundary. The original Safetyman framework supports professional judgement. It does not certify an investigation or supply a proprietary third-party methodology.

01

Back up and install the package. Take a recoverable database and files backup. Upload the 1.2.0 ZIP through Plugins > Add New > Upload Plugin and replace the existing Sentinel plugin. Keep existing pages and shortcodes.

02

Set the annual licence. Use Annual licences to record the agreed period and named-seat capacity in blocks of ten. Prices may remain blank until agreed. This does not collect payment.

03

Open Company products. Find the company by name. Select its agreed products. Tick Investigate and Investigate Pro extension to allocate Pro. Bowtie and Assure are optional companion products.

04

Save company products. The revision protects against stale forms. A conflict requires a reload. The change is recorded in the company audit. Ask signed-in users to reload.

05

Test as a client user. Check company membership, workspace access, editing and a separate reviewer. An administrator account is not a sufficient access-control test.

01

Select the correct company and workspace. Check both selectors before editing. Open Investigations and select the event from the investigation selector.

02

Keep the existing evidence. Review the findings, source references and timeline. Do not change hypotheses to Supported merely to open Pro.

03

Open Investigate Pro. If the tab is missing, ask the administrator to check the company product allocation and your access.

04

Select + Investigation brief. Name the review, define its questions and complete the scope, lead, team, terms, expected condition and actual condition.

05

Apply and confirm the save. Connected workspaces schedule a save after Apply changes. Wait for Saved and the new revision. The local practice workspace requires Save changes.

06

Read Review readiness. The outstanding items are a working checklist. You can save an incomplete draft while collecting evidence.

01

Write answerable questions. For Northbank: how did the temporary route bypass segregation, what enabled the change, and which improvements can be verified?

02

Set boundaries. State the operation, period, relevant equipment and exclusions. Avoid claiming that one local review covers every company site.

03

Name the lead and team. Record expertise, operational input and possible conflicts of interest. Typed names describe responsibilities; they do not grant user permissions.

04

Record the review arrangements. Use Terms to identify authority, decision criteria, evidence expectations and a separate authorised reviewer.

05

Compare expected with actual. Describe normal arrangements and the observed deviation without deciding the cause in advance.

06

Keep limitations current. Record missing evidence, open questions, what will be done, who will do it and when. Explain why any unresolved matter does not invalidate the proposed conclusion.

01

Open Evidence register. Add a source reference, custodian, date, type and summary. Files remain in your controlled document store; the register is not an attachment repository.

02

Assess reliability. Unassessed means not yet checked; Corroborated requires a justified cross-check; Disputed preserves a challenged record. The software does not independently authenticate a source.

03

Record limits. Explain what the source can and cannot establish. A later reconstruction or test does not automatically prove conditions at the event time.

04

Build the Event timeline. Use dated events, UTC times and linked evidence. Distinguish known sequence from a reconstructed assumption.

05

Check investigation selection. Evidence and Pro references must belong to the same investigation. Cross-case references are rejected.

06

Protect personal information. Use appropriate access and retention rules. Do not enter passwords, access tokens or unrelated personal details in source references.

01

Add a hypothesis as a finding. In Investigations, record a clear explanation with Hypothesis status. Preserve alternatives rather than overwriting the first explanation.

02

Open Pro > + Hypothesis test. Choose the finding. Define the method and Expected result before recording the outcome.

03

Record Observed result. Describe what the sources establish, including inconsistent observations and test limitations.

04

Select evidence on each side. Supporting and contradicting references are separate. A completed Supports test needs corroborated supporting evidence; Refutes needs corroborated contradicting evidence.

05

Choose the test conclusion. Use Planned, Supports, Refutes or Inconclusive. Completed tests require method, expected and observed results, reasoning and evidence.

06

Reconcile the finding separately. Return to Investigations to update its status and reasoning. A test does not automatically approve or change the finding. A refuting test against a Supported finding blocks Pro readiness.

01

Use precise findings. Separate the observed event from contributing conditions. A label such as carelessness does not explain work conditions.

02

Add a causal connection. Select the contributing finding as Cause and the resulting finding as Effect. Both must belong to the selected investigation.

03

Choose the relationship. Contributing means the condition helped explain the result. Use Necessary only when you can defend the counterfactual claim that the result required that condition.

04

Link evidence and rationale. Explain why the connection is justified, what challenges it and the limits of the inference.

05

Inspect the direction. Arrows point from contributing to resulting finding. Cycles and self-links are rejected. Multiple incoming or outgoing connections are allowed.

06

Export the causal map. The SVG displays up to 24 findings for readability. The table, JSON and full report retain all connections. Layout does not imply sequence, strength or probability.

01

Add a structured factor review. Choose a related finding and a perspective: Human factors, Change, Barrier, Organisation, Equipment or Environment.

02

Compare expected and actual. For a change review, describe normal practice and what differed. For a barrier review, describe intended function and observed availability or performance.

03

Examine human factors. Consider information, workload, tools, communication, supervision and practical constraints. Avoid inferring intent from a bad outcome.

04

Analyse the contribution. Explain how the condition could affect the event. Link sources and consider a plausible alternative explanation.

05

Keep uncertainty visible. A factor review is a structured interpretation, not proof by itself. Update the finding and tests when the evidence warrants it.

06

Review proportionately. Select perspectives relevant to the event. Pro readiness requires at least one completed evidence-linked factor review; it does not prove that every necessary perspective was examined.

01

Create the corrective action. Open Actions, link it to the supported finding, assign an accountable owner and due date, and describe the intended change.

02

Add an action assurance plan in Pro. Select that action and its main control approach: Eliminate, Substitute, Engineered, Administrative or PPE.

03

Record the baseline. Describe the starting condition and evidence reference so later results can be compared meaningfully.

04

Write measurable success criteria. State the observation, sample, acceptance threshold and period. For Northbank, sample the next ten temporary changes over eight weeks.

05

Set a review date and residual risk. Record interim arrangements and what risk remains. Explain why the action addresses the cause and whether a stronger approach was feasible.

06

Use Assure for actual outcomes. After implementation, record completion evidence in Actions and an Effectiveness review in Assure. A scheduled review is not an effectiveness result.

01

Resolve the Pro checklist. Complete the brief, evidence-linked timeline, tests, supported findings, factor review and action plans. Record limitations for remaining open questions.

02

Save before review. Confirm the saved revision. Submit from Overview with a clear review note. The server checks Pro readiness as well as the existing workspace requirements.

03

Use a separate reviewer. The authorised reviewer inspects evidence and alternatives, then approves or returns the workspace. A checklist cannot substitute for this judgement.

04

Propose a supported finding to Bowtie. From Investigations, select the target workspace and mapping type. Both products must be allocated to the same company. Pro readiness must pass.

05

Inspect the frozen source. The transfer retains Pro analysis and referenced supporting or contradicting evidence. If source content changes, prepare a fresh proposal.

06

Complete the target review. A different authorised target reviewer applies the proposal. The target returns to Draft; complete owners, standards and verification before approving it.

01

Create or select a practice workspace. Use an account with Pro allocated. Open Investigate Pro and select Load fictional Pro example. It creates a separate labelled draft.

02

Alternative: import the JSON. Download Northbank-Investigate-Pro-Example.json from the learning centre and use Import JSON. Do not treat it as a client investigation.

03

Inspect the three tests. Two support the route and process findings; one refutes persistent brake malfunction within stated limits. Find the delivery-pressure question and its follow-up.

04

Challenge the case. Change one test to Planned. Confirm readiness becomes incomplete. Restore it with justified evidence and reasoning.

05

Practise the hand-off. Assign a separate reviewer, create a practice Bowtie target, and propose the process finding. Confirm that review is required and application resets the target to Draft.

06

Complete the assurance loop. Record fictional completion and verification evidence, then review actual effectiveness. Keep all new exercise records explicitly labelled fictional.

01

Agree the evaluation scope. Start with fictional or authorised de-identified cases. Name an investigation lead, independent reviewer, administrator and operational representative.

02

Observe a full workflow. Ask participants to extend a 5 Whys case, test alternatives, connect causes, plan actions, propose a Bowtie change and record an effectiveness review.

03

Record usability evidence. Measure completion time, help required, misunderstood fields and errors. Capture the task and exact message without confidential content.

04

Check access and recovery. Use two separate companies and ordinary client accounts. Attempt unauthorised access, check revoked roles, concurrent edits, export and restore from backup.

05

Review investigation quality. Can a new reviewer trace each conclusion to sources? Are contradictions and limitations visible? Are action criteria measurable?

06

Agree release decisions. Classify defects, assign owners and retest fixes. Obtain documented acceptance before relying on the product for operational investigations.

01

Pro tab missing. Check Company products, global Investigate availability, annual licence and the user's company allocation. Reload after changes.

02

Cannot select the intended finding. Close the form and select the correct investigation first. Sources from another investigation are deliberately rejected.

03

Test cannot be saved. For a completed test, provide the method, expected and observed results, reasoning and evidence. Supports or Refutes requires corroborated evidence on the relevant side.

04

Review submission blocked. Read the Pro readiness panel. Missing limitations, unresolved refuting tests, incomplete action criteria or planned tests can block submission.

05

Transfer is stale. A changed source may no longer match its frozen snapshot. Reject the old proposal and prepare a new one; do not conceal the change.

06

Use AI carefully. The existing AI assistant receives only the text you deliberately submit. Include source identifiers, remove unnecessary personal data, check every suggestion and keep unverified output as a hypothesis. No autonomous causal conclusion is approved.