Brisbane cleaned up a transfer-line leak. Toowoomba dealt with a slippery loading area. Townsville contained a spill during unloading. All three local actions are complete. The question for the cross-site safety lead is still open: are these separate incidents, or should we investigate them together?
In week 19 of our case-study series, we built a corrective action workflow for Banksia Logistics, a fictional Australian organisation. The investigation desk brings those records together without reopening the completed cleanups. It retains possible connections, contrary evidence, human decisions, an approved follow-up and the evidence needed to judge whether a change worked.
SwarmCraft structured the build into 63 tasks, implemented with Codex and followed by repair and verification. The application and screenshots use synthetic incidents. Artificial intelligence (AI) proposals are replayed test fixtures, and external action delivery is simulated. The demonstrated result is a working review process; live model quality and a live Mitti connection still need separate proof.
Why add a workflow when the incumbent already has AI?
Environment, health and safety (EHS) software already covers much of this territory. Mitti's AI Assistant documentation describes finding issues across sites, examining categories, recommending corrections from an organisation's documents, and creating assigned actions. Our experiment does not establish a missing Mitti feature.
The operating problem is worth examining independently. In a multi-site practitioner discussion, a safety professional describes three sites giving conflicting accounts of the same action's status. That is one person's experience, not a prevalence estimate or proof that another application is needed. It does explain why a status label alone may be insufficient.
Banksia's question is narrower: can the business own a review process that preserves each source, challenges a proposed explanation, records a person's decision and follows the result through operating evidence?
For this experiment, incident records and action execution stay with the incumbent. Moving those safety records would introduce migration and continuity work unrelated to the investigation question. The added workflow owns its investigation, retained source versions, review reasons, approvals and effectiveness evidence. Mitti is the provisional integration candidate; its native workflow should be tested before choosing an additional tool.
Our EHS software comparison covers the buying decision. SafetyCulture alternatives examines keep, switch and connected-workflow options.
The corrective action workflow starts with a better question
Banksia's three reports use different language and come from different depots. Their evidence refers to a similar coupling family. That is a reason to investigate a connection, not a finding that all three have the same cause.
The corrective action process keeps the original incidents and cleanups intact. One shared investigation links the relevant sources. A later follow-up can address that investigation; there is no need to reopen three completed cleanup actions just to ask a new question.
Responsibility stays explicit:
| Owner | Decision or contribution |
|---|---|
| Cross-site EHS lead | Reviews proposed connections and owns the shared investigation |
| Depot supervisor and maintenance investigator | Supply permitted site evidence and test explanations |
| Authorised action approver | Approves the exact follow-up, including its owner, date and evidence |
| Independent effectiveness reviewer | Assesses operating exposure and exceptions after implementation |
The corrective action workflow steps are to retain source evidence, review connections, investigate the explanation, approve a specific follow-up, reconcile delivery and assess effectiveness. Each step produces evidence for the next person. A completed cleanup cannot stand in for all six.
Keep the evidence that breaks the explanation
The first suggested explanation is plausible: perhaps a component introduced on 8 October caused the unloading events. But the Brisbane leak happened on 5 October. The change cannot explain all three incidents.
That contradiction stays visible even when the reviewer filters the incident list to another site. The desk also retains unanswered questions about maintenance and seal inspections. It gives the investigator somewhere to continue the work without presenting a confident root cause prematurely.
A fourth report concerns roof rainwater. Similar words about water or a slippery surface are not enough to join it to the unloading investigation. The reviewer rejects the relationship and records why.
This is the useful role we want AI-assisted synthesis to earn: assemble inspectable connections while keeping contradictions and exclusions close to them. In these captures, deterministic replay supplies the proposal. The tests demonstrate review behaviour around that proposal, not that a live model discovered the right connections. Manual review and action drafting remain available.
Approve the follow-up you actually intend to send
The demonstrated follow-up asks an investigator to review coupling inspection practice and retain maintenance and seal evidence. Its wording keeps the cause under investigation. We have not converted the initial hypothesis into a proven corrective fix.
The approver sees the description, acceptance criteria, site, assignee, due date, investigation revision and supporting source versions together. Approval binds that exact revision.
In the next tested branch, changing the assignee creates revision 2 and requires fresh approval before delivery. The screenshot above shows revision 1; the delivery images below show the reapproved revision 2. Server checks also prevent a person from approving their own draft where independence is required.
That is a practical boundary for corrective action automation. Drafting can be assisted, but an old approval must not authorise a changed instruction. Our article, What should an AI agent be allowed to access?, explores the same distinction between preparing work and having authority to act.
Recover an uncertain delivery before creating another action
Mitti documents an application programming interface (API) for creating actions. That makes a connected workflow worth investigating. It does not prove this build has connected successfully or that repeating a request is harmless.
Our delivery test creates an external effect in a stateful simulator, then loses the acknowledgement. The desk reports an unknown outcome. It does not assume the request failed and create another action.
Reconciliation finds the existing action and matches it to the retained request. The application preserves the receipt and external identity without duplicating the action.
This is simulator evidence. Live Mitti delivery and completion-status synchronisation are unfinished. The interface therefore says that current incumbent status is unavailable. A creation receipt cannot tell the reviewer whether the work has been carried out.
Two transfers do not prove the change worked
The effectiveness journey uses a separate synthetic action. Its illustrative review criterion requires 30 post-change transfers. After two transfers, the recorded result is inconclusive.
Reaching 30 permits an independent assessment; the count does not make the decision. The test records a human assessment, then introduces a relevant recurrence. That new evidence requires further review while the earlier decision remains in history.
The exposure counts are test criteria, not safety thresholds. Because live completion-status sync is missing, the isolated test supplies an explicit synthetic implementation-completion record before adding observations. These captures prove how the application treats evidence and decisions, not that a real-world intervention reduced incidents.
For an operator deciding how to automate corrective action, this separation matters: delivery, implementation and effectiveness answer different questions. Combining them into one green status hides the work still owed.
What SwarmCraft structured and what we verified
The build covers source and investigation records, cited proposals, human review, exact approvals, a delivery ledger, effectiveness evidence and authorised history. Its browser interface presents those as separate review surfaces.
| Project measure | Recorded result |
|---|---|
| Planned implementation | 63 tasks; all 63 reached Done |
| Build provider | Codex, followed by consolidated repair and verification |
| Earlier consolidated check | 45 release-verification stages passed, including database, migration and recovery checks |
| Current visual extension | 37 web unit checks, 53 browser checks, three workbench browser checks and four authenticated API/database suites passed |
| Article evidence | Eight native-resolution application captures, with source provenance |
Board completion was not the end of verification. The driver encountered execution-permission restrictions and exhausted an initial request budget. We later ran host checks, repaired failures and improved the layouts. The 45-stage result belongs to the earlier verified revision; the final Banksia visual changes have their own focused checks. There is no fully metered end-to-end build cost or production-deployment claim.
The board image records project generation, before implementation. The final build manifest records all 63 tasks in Done.
| Implemented layer | Responsibility |
|---|---|
| React, TypeScript and Vite | Banksia's reviewer interface, responsive layouts and shared visual components |
| Node.js and TypeScript | Server-enforced permissions, decisions, approvals and delivery rules |
| PostgreSQL and 12 versioned migrations | Retained sources, investigation records, approvals, delivery and audit history |
| Playwright and isolated database checks | Browser interactions plus independent verification of persisted results |
The screenshots come from separate authenticated test branches, not one uninterrupted investigation carried through every screen. Production identity, a live connector, completion-status sync, model evaluation and operating ownership remain work before deployment.
When the existing product is the better answer
Start by running this scenario in the incumbent: three differently worded incidents, an explanation contradicted by chronology, an unrelated lookalike, a changed action and a later recurrence. If its native tools preserve the evidence and review boundaries your organisation needs, configuring them is likely simpler than operating another application.
An owned workflow earns its place when there is a demonstrated process requirement, a reliable integration path and someone accountable for maintaining it. API access alone is not a business case. Incumbent subscriptions remain, and integration, hosting and support add costs. Our EHS software-sprawl analysis provides an illustrative way to examine that trade-off; this build establishes no realised savings.
Own the investigation, then earn the next action
The reusable corrective action workflow template is a sequence of accountable decisions: preserve the sources, test the connection, retain the contradiction, approve the exact follow-up and judge effectiveness against operating evidence. Corrective action workflow automation is useful when it makes that sequence easier to follow and harder to misrepresent.
This is also the test for EHS workflow automation built with AI. A generated application can provide an owned foundation, but the operator still has to define the decisions, inspect the evidence and verify the result. Banksia's three cleanups can stay complete while that work continues.
If you already have one bounded workflow and a clear incumbent record boundary, Fast Start can help structure it while keeping the existing system of record. Where safety controls, responsibilities or record ownership still need investigation, Deep Discovery provides the source-led route through those questions and remains in an account-enabled limited rollout.
