A batch of 120 enclosure brackets has a quality problem. Inspection clears 80, engineering proposes rework for 30, and ten need scrapping. Later, the rework task says complete. Can the remaining parts leave the warehouse?
That question drives the non-conformance workflow we built for week 18 of our case-study series. Banksia Components is a fictional Australian manufacturer supplying non-safety-critical industrial components. Its quality, engineering and warehouse staff need a shared account of what happened to each unit—and who can decide what happens next.
The demonstration finishes with 104 confirmed released, ten scrapped and six still held. The case stays open. That unfinished state is the useful result: software should make the remaining decision visible, even when most of the batch is ready.
Owning the non-conformance operation
MasterControl is the illustrative incumbent. Its nonconformance documentation already describes investigation, disposition, management approval and links to corrective and preventive action. This is not an argument that those capabilities are missing.
Our experiment asks what it would take for Banksia to own the corresponding operation: its cases, evidence, affected-unit records, proposals, approvals, verification and decision history. That is a replacement of the non-conformance record boundary, rather than another task board beside it.
Inventory still confirms physical holds and movements. Engineering still owns the drawing and instruction revisions. Document control, training, laboratory work and inventory valuation remain outside the application.
The quality-stack analysis explains the underlying waste: several tools can each show a plausible status while somebody still has to reconstruct whether stock may leave. Owning the operation is useful only if it removes that ambiguity without losing the evidence.
All records and integrations shown here are synthetic. We did not connect to MasterControl or migrate a customer account.
Start with a confirmed hold
An inspector records the finding against lot BC-261012-A and drawing BR-42 revision C. Sending the same observation twice must preserve one case rather than create two competing investigations.
The quality coordinator requests a hold on all 120 units. A request alone does not establish containment. Until inventory confirms it, the application treats the hold as unconfirmed and shows the exception.
Once the matched receipt arrives, the batch view can state that all 120 units are held. It also names the next decision and its owner.
The confirmed hold is linked to its recorded transition. These are persisted demonstration records, viewed by a read-only auditor.
The non-conformance process must distinguish asking for a change from knowing it took effect. Automating the request does not remove the need for confirmation. A green task badge is not evidence that inventory has contained the stock.
The non-conformance workflow follows the units
A disposition is the agreed treatment of the affected product. Banksia’s inspection produces three disjoint groups:
| Units | Initial disposition | What must happen next |
|---|---|---|
| 1–80 | Release the 80 conforming units | Quality approval followed by inventory confirmation |
| 81–110 | Rework 30 units | Approved instruction, completed work and independent verification |
| 111–120 | Scrap ten units | Approval and confirmed inventory effect |
These are traceable unit ranges, not three totals somebody can edit independently. The server prevents overlapping allocations and keeps all 120 units accounted for.
Engineering proposes rework instruction RW-018 revision 1. Quality approves the exact unit scope and supporting evidence. A later instruction change cannot quietly inherit that approval: a separate test exercises a stale decision and refuses to use it to authorise the changed work.
At this checkpoint, scrap of ten is confirmed, 30 remain held for rework, and release of 80 is approved but not yet confirmed in the case record.
The quality approval workflow separates responsibilities:
| Role | Responsibility |
|---|---|
| Inspector | Records the finding and inspection evidence |
| Quality coordinator | Requests containment and coordinates the case |
| Engineering disposition owner | Proposes treatment and the applicable rework instruction |
| Quality manager | Approves or rejects the proposed disposition |
| Rework operator | Carries out the authorised work and records completion |
| Independent verifier | Checks the result; cannot verify their own rework |
| Warehouse operator and inventory adapter | Record and reconcile inventory outcomes |
| Read-only auditor | Inspects the case and evidence without changing them |
For a non-conformance workflow template, start with these decision boundaries. Define the affected units, evidence, owner and confirmation required at each step before adding reminders or dashboards.
When the release happens but the reply is lost
Inventory applies the release of 80 units, but the acknowledgement does not reach the workbench. The application cannot safely interpret that as either “nothing happened” or “release confirmed”.
It retains the uncertain operation and reconciles it with inventory. The matching receipt confirms the movement already made; it does not trigger a second release. A replayed confirmation also leaves quantities unchanged.
That is why the disposition screenshot still shows 80 approved for release. At that moment, the workbench has not yet received the evidence needed to call them released, even though the synthetic inventory service has applied the movement.
To automate non-conformance reliably, design this uncertainty path alongside the happy path. Retrying an external action without checking its outcome can create a second business effect.
Completed rework is not verified conformance
The operator completes rework on all 30 units. They remain held while verification is outstanding.
An attempt at self-verification is rejected. The independent verifier then records 24 passes and six failures. Quality authorises release of the passing units, and inventory confirms that release.
The final arithmetic is simple: 80 plus 24 released, ten scrapped and six held. The important part is that each number has a different chain of evidence behind it.
Units 105–110 failed verification and need a fresh disposition. The case remains open; the linked corrective-action referral is a separate piece of work.
The non-conformance workflow steps therefore continue beyond “work completed”: verify the result, approve the eligible quantity, confirm the inventory effect and identify what remains unresolved.
Banksia also opens a corrective-action referral after linking a similar historical finding. That referral carries responsibility for follow-up; it does not hold stock itself or close the batch case. Investigation of recurring causes and effectiveness belongs in the separate corrective-action workflow.
Replacing records means rehearsing the handover
An owned quality management workflow needs more than new screens. Existing cases must retain their identity, attachments, decisions and relationships when responsibility moves.
The migration rehearsal imports invented MasterControl history. One unresolved approver mapping blocks cutover. A recorded resolution allows reconciliation, after which the workbench becomes the active writer for that boundary. Rollback returns writing authority to the source; a subsequent cutover retains the earlier history.
This exercises the handover rules against a synthetic format. It does not establish compatibility with a real MasterControl export. Actual source mapping, opening reconciliation and accountable approval would be required before moving customer records.
Recovery matters for the same reason. The repository includes case export and restore tooling, and a delivery hold that requires reconciliation before restored workers resume. Restoring yesterday’s database must not blindly resend an inventory command that already took effect today.
These controls form part of the replacement scope. They are not optional extras to add after the interface looks finished.
Where artificial intelligence can help
The Quality Desk brings together the facts behind the six held units, references the source records and identifies missing evidence. Its intended artificial intelligence (AI) role is to help someone understand the case and prepare a draft explanation.
The Quality Desk demonstration uses supplied facts to produce a cited explanation. A live AI provider would need separate evaluation before use.
An assistant can help locate the failed measurement, relevant instruction and missing receipt. It must not gain authority to approve disposition, declare conformance or release stock. The factual view remains useful without AI.
Our article on the AI control problem explains why a capable explanation and permission to act are different questions.
Project stats
| Stat | Week 18 result |
|---|---|
| Implemented tickets in the initial run | 71 |
| Final initial-run board state | 71 done / 0 open |
| Build runner | Claude Code |
| Driver evidence span | 4 days 3h 51m, including pauses and resumed sessions |
| Final continuation runtime | 31m 16s |
| Tracked files | 956 |
| Tracked text lines | 125,926 |
| Test and spec files | 160 |
| Database schema migrations | 28 |
| System-test evidence screenshots | 15 |
| Selected article screenshots | 3 |
| SwarmCraft setup screenshots | 2 |
The driver figures cover the initial run; repository counts are from the repaired application at commit ce7f93c, including code, tests and documentation. Claude completed the implementation and repairs; Codex completed the final verification and documentation handoff. Full-run request and cost totals are unavailable.
Technology and verification
| Implemented layer | Responsibility |
|---|---|
| React, TypeScript and Vite | Banksia’s browser interface and shared design-system components |
| Node.js and TypeScript | Server-enforced permissions, approvals and quantity rules |
| PostgreSQL with 28 schema migrations | Cases, evidence, unit history and inventory reconciliation |
| Playwright | Browser and system checks against persisted records |
Final verification passed 148 web unit tests, lint, type checking, production build and all 46 system tests. The browser suite reported 350 passed, including 11 documented expected failures for existing zoom and print limitations.
The screenshots show state read through the application. The system tests also use its application programming interface (API) to perform lifecycle steps. They do not prove that every step has a complete browser authoring screen. Production sign-in, live inventory and vendor connections, evidence scanning, deployment assurance and remaining accessibility work still need completion before customer use.
When keeping the platform makes more sense
Run this batch through the incumbent first: partial release, approved rework, failed verification and an inventory reply that never arrives. Can the business explain every unit’s state and the next authorised decision without reconstructing it from emails?
If configuration and integration provide that operating fit, keeping the platform may be the better choice. Our quality management software comparison and MasterControl alternatives cover the broader buying decision.
Compare the actual subscription and implementation quote with migration, hosting, integration, recovery, assurance and ongoing support. We have not measured a realised saving or complete replacement cost here. A smaller application still needs an accountable quality owner and an operator responsible for maintaining it.
The useful promise of non-conformance workflow automation is a trustworthy answer about the batch: what can leave, why, and what still needs a decision. For Banksia, that answer includes six units that must remain held.
If you want to investigate ownership of a similar operation, Deep Discovery can work through its records, roles, evidence and migration boundary. It remains a limited, account-enabled rollout. Start with one real batch and the decision your current systems struggle to explain.
