QualityLine · Connected unit history
Manufacturing traceability
for electronics quality.
Connect available process, test and repair records into a usable unit history. Follow the evidence behind a failure, understand repeat tests and give engineering the context to investigate.
From separate records to shared context
See the history behind a quality result.
Manufacturing traceability connects a product or batch with the records associated with its production. For electronics teams, that can mean linking inspection, electrical tests, functional tests and repairs to the same board or assembly.
QualityLine brings connected manufacturing data into the investigation. The available history depends on what your source systems record and how reliably those records can be matched.
Before the failure
Review available assembly and inspection context, such as process steps, station identifiers, measurements and product revisions.
First test and retests
Connect test results and parameter measurements. Preserve attempt order so a later pass does not hide an earlier failure.
What changed
Link recorded fault findings, repair actions and subsequent tests where those records are available. Compare the sequence before drawing a conclusion.
Illustrative unit history
A final pass is only part of the story.
A board can pass its final test after an earlier failure and a repair. Keeping the attempts connected helps an engineer understand the route it took and the work required.
In this example, the record sequence suggests where to investigate. It does not prove that the repair caused the final pass or establish how other units should be handled.
Connect the history to root-cause analysis →ILLUSTRATIVE RECORDS · UNIT EX-1042
- 01 / INSPECTIONRecorded inspection result
Board identifier, station and product revision provide the starting context.
- 02 / FUNCTIONAL TESTFirst attempt: fail
The original measurement and failure code remain part of the investigation.
- 03 / REPAIRRepair action recorded
A linked finding describes the work performed on the same unit.
- 04 / FUNCTIONAL RETESTLater attempt: pass
The retest is a separate event, linked to the earlier failure and repair.
Example workflow, not a product screenshot or a customer result.
Put the history to work
Move from a unit record to an engineering question.
Investigate a returned or failed unit
Use its identifier to connect the available production history with test and repair findings. Check whether records describe the same revision and configuration.
Understand repeated tests
Distinguish first attempts from retests. Review whether repeat failures share a station, test program or other recorded condition.
Review a potentially affected group
Use recorded batch, process or product relationships to define a group for investigation. Your quality team decides the scope of any containment action.
Share a clearer investigation
Keep the original observations, repair findings and open questions together when production, quality and engineering review the issue.
Make the connections reliable
Define the identifiers and the gaps.
A useful history needs more than a shared timestamp. Agree how records refer to the same unit, board, panel or batch, and where those relationships change during production.
Start with one product and a known unit history. Check the connected records against the source systems before extending the workflow.
Review data integration requirements →- Identity and relationshipsSerial or batch IDs, panel-to-board links and recorded parent/child assembly relationships.
- Event order and contextTimestamps, time zones, station IDs, process steps, product revisions and test-program versions.
- Measurements and outcomesValues, units, limits, pass/fail results, attempt numbers and recorded repair actions.
- Coverage and exceptionsMissing identifiers, unmatched records, duplicated events and data that arrives late. A missing record is not proof that a process step was skipped.
Customer experience
Investigation at unit level.
STANLEY Healthcare describes using QualityLine to investigate individual units, components and problems. Its case study also describes feedback between production, engineering and design teams.
This supports the investigation workflow. It does not establish complete record coverage for every manufacturing process.
Common questions
Planning your traceability workflow
Can we connect records without a consistent serial number?
A panel ID, batch reference or another agreed mapping may still provide useful context. The matching method must reflect how your process works. If individual units cannot be matched reliably, keep the analysis at the supported level instead of assuming unit-level traceability.
Does traceability include every component and assembly?
Only where the relevant relationships are recorded and connected. Component genealogy requires data linking a component or material batch to its board or parent assembly. A final test result alone cannot reconstruct those relationships. Review that coverage during integration.
How current is the available history?
It depends on when the source records an event and how quickly that record is transferred and processed. Agree the required update frequency for your use case and check delayed or missing data before treating the history as complete.
Does QualityLine replace our MES or control the production route?
QualityLine provides an analytics workflow using agreed manufacturing data. MES routing, process interlocks and automatic machine changes are separate capabilities that need their own scope review. Connected unit history alone does not establish a closed-loop production control system.
Can we investigate units made by a contract manufacturer?
Yes, when the relevant manufacturing records can be accessed and reliably connected. Agree the identifiers, data access, reporting scope and responsibilities with the manufacturing partner. Visibility is limited to the records made available for that workflow.
Does traceability automatically make a process compliant?
No. Connected records can support quality investigations and evidence gathering, but software alone does not establish compliance. Review record retention, access, change history and required process controls with your quality team for the applicable requirements.
Start with a real investigation
Bring a unit history you want to understand.
Choose a product, the quality question and the systems that hold its records. We can review the available identifiers, gaps and analytics workflow in a demo.
