A Mac completes diagnostics with no failed tests. The report looks clean, and the device moves to grading, pricing, or resale.
Later, a hardware issue appears. When the original report is checked, one test had never produced a valid result. The component was not confirmed as faulty, but its normal operation was not confirmed either.
With only passed and faulty available, this situation is difficult to record correctly. A third status solves that problem.
Mac diagnostics uses three states: passed, faulty and not run. The third status, not run, records cases where diagnostics cannot collect enough evidence to confirm the condition of a component.
For businesses processing Macs, this distinction affects the reliability of the entire device record.
Why Two Statuses Leave a Gap
A test does not always end with a confirmed pass or fault.
Permissions may prevent access to a component. Firmware state may interfere with the test. The required data may not be collected. A hardware component may exist but remain unavailable to diagnostics.
None of these situations confirms a fault.
They also provide no evidence for a passed result.
A two-state report has no accurate status for this situation. The test may be skipped, left blank, or included in a report that still presents the device as fully tested.
At low volume, an operator may remember what happened. Once devices move between teams or are processed in large batches, the report becomes the record that other decisions depend on.
What “Not Run” Actually Means
The three statuses have strict meanings:
- Passed means the test collected positive evidence confirming normal operation.
- Faulty means the test confirmed a deviation.
- Not run means there is not enough evidence for either conclusion.
Not run does not describe the condition of the component. It describes the status of the test.
This distinction prevents an incomplete check from becoming part of the confirmed results.
For example, detecting a storage drive in the operating system confirms that the drive is present. A complete diagnostic test requires further verification through load, write, and read operations. If that verification cannot be completed, the drive remains unresolved.
The report records this as not run instead of treating visibility in the system as sufficient evidence for passed.
Why the Third Status Matters After Diagnostics
Diagnostic data rarely stays at the testing station.
A device may continue through:
Intake → Diagnostics → Grading → Pricing → Repair or Resale → Inventory
Each stage may use the diagnostic record without access to the original operator or the circumstances of the test.
A not run status preserves information that would otherwise disappear during these handoffs.
The grading team can see that a component was not confirmed. A pricing decision can account for an unresolved test. A unit can be routed for another check before resale. A supplier claim can refer to the original test record.
Without the third status, these cases can require manual investigation or another diagnostic run simply to establish what happened during the first one.
The Difference Becomes Larger at Lot Level
One unresolved test on one Mac is easy to handle.
The same reporting problem across a large lot affects the quality of the batch data.
Consider battery diagnostics. Some devices complete the required test and receive “passed” status. Other devices do not provide enough data for a verdict.
If both groups are counted together, the number of verified batteries becomes inaccurate.
With not run recorded separately, confirmed and unresolved results remain distinct.
This matters when diagnostic data is later used for grading, pricing, supplier claims, or residual value calculations. The number of passed tests represents components that were actually confirmed rather than all components without a recorded failure.
“Not Run” Also Prevents False Results for Missing Hardware
Mac models do not all contain the same components.
A desktop Mac has no built-in keyboard. Some models do not include a card reader. A generic test plan can create misleading results if these hardware differences are not handled correctly.
Tests for components that are physically absent do not enter the run plan. If a component exists but cannot be reached by diagnostics, its test remains not run.
Connected peripherals do not change this logic. An external USB keyboard cannot produce a passed result for a built-in keyboard test.
The report therefore reflects the hardware of the machine being tested and the tests that were actually completed.
Warnings Remain Separate From the Three Statuses
Some diagnostic observations provide additional information without determining whether a component is healthy or faulty.
Examples include link speed below specification, signal jitter, or processor throttling under sustained load.
These observations are recorded separately.
A warning does not automatically produce faulty status. It also does not replace the evidence required for passed.
Keeping warnings separate prevents informational measurements from changing a diagnostic verdict without sufficient evidence.
Battery and Neural Engine Tests Show Why Evidence Matters
Battery condition cannot be established from the health percentage in system settings alone. That value comes from the battery controller.
The diagnostic verdict uses actual drain under load and accumulated charge. Normal OS-side charging holds are recognized separately. If the test cannot collect enough data for a conclusion, the result remains not run.
Apple Silicon neural engine testing follows the same principle.
The same calculation runs on the processor and neural core, and the results are cross-checked. The test also requires separate confirmation that the neural core actually performed the calculation.
Matching results without that confirmation are insufficient for a passed status.
In both cases, not run preserves the difference between a component that was confirmed and one for which the required evidence was unavailable.
The Third Status Gives Unresolved Devices a Clear Next Step
A separate status also makes unresolved tests easier to manage operationally.
A passed component can continue through the workflow.
A faulty component can affect repair, grading, pricing, or routing.
A not run result identifies a test that still requires a decision. The test can be rerun, the device can move to manual review, or the unresolved status can be taken into account during processing.
This gives incomplete tests their own workflow instead of allowing them to disappear inside the final report.
Mac Diagnostics by NSYS Group
NSYS Group uses the three-state approach in Mac diagnostics: passed, not run, and faulty.
A passed result requires positive evidence collected during the test. A confirmed deviation receives faulty status. When the required evidence cannot be collected, the result remains not run.
Diagnostic results are generated automatically from the run. Operators cannot manually change an unresolved result to passed. A new status requires another test and new evidence.
The test plan also reflects the hardware present in each Mac, while warnings and additional technical observations are recorded separately from the verdict.
For refurbishers, wholesalers, trade-in operators, and ITAD teams, the third status keeps unresolved tests visible throughout grading, pricing, repair, resale, and supplier claims.
Request a demo to see how NSYS Mac diagnostics handles passed, faulty, and unresolved test results on actual devices.
