1. Preserve the evidence first

Match controller, command set, namespace and time before comparing support.

Preserve Identify support, CSUPP and CSI/UUID selectors.

CSI

Command Set Identifier

If supported Format returns Invalid Format, compare its LBAF with the namespace’s formats.

2. Work through the possible causes

First inspect SCT/SC rather than an application’s generic failure label.

SCT

Status Code Type

Decode the CQE, then validate selectors, namespace state, protection and active-operation restrictions.

CQE

Completion Queue Entry

3. Connect observations to specification conditions

Rejecting an unsupported LBA format can be consistent with supporting Format.

LBA

Logical Block Address

Invalid Opcode with all prerequisites met warrants support-consistency investigation, not an automatic conclusion from any failure.

Use a contemporaneous valid control differing in one relevant condition.

1. Preserve the evidence first

Establish applicability to controller type, command set and query revision.

Compare the relevant discovery interface rather than unrelated capability bits.

CSUPP0 and successful effective execution of that opcode under the same CSI require investigation.

CSI

Command Set Identifier

2. Work through the possible causes

First compare discovery and execution selectors.

Exclude stale snapshots, activation, opcode-category confusion and reserved-field misinterpretation.

3. Connect observations to specification conditions

Capability, completion and observable effects must agree.

Require rejection only where the specification defines unsupported behavior; inapplicable zero fields do not universally prohibit commands.

Preserve contradictory evidence and cite the exact declaration rule.

1. Preserve the evidence first

Feature scope determines the target that Get must match.

Check supported capabilities and whether the feature may adjust requested values.

KATO may round up to KAS granularity, so a larger readback is not necessarily wrong.

2. Work through the possible causes

FID

Feature Identifier

NSID

Namespace Identifier

3. Connect observations to specification conditions

Correct selector mistakes before diagnosing unexplained same-target inconsistency.

Track intervening configuration, resets and mode changes.

1. Preserve the evidence first

Match log scope to the event’s endpoint and entity.

Preserve event type, information, LID and required selectors.

LID

Log Page Identifier

A temperature warning may clear before a later SMART read without invalidating the earlier event.

2. Work through the possible causes

First check LID, scope and observation delay.

LID

Log Page Identifier

Read the matching log and check intervening acknowledgments and state changes.

3. Connect observations to specification conditions

A coherent timeline can explain cleared current state after a valid event.

Immediate, One-Shot and ordinary events have distinct clearing rules.

Preserve the first read and all acknowledgments before investigating persistent inconsistency.

1. Preserve the evidence first

Match controller and error counts, considering overwrite by concurrent failures.

Inspect More and command-specific logging requirements.

More 1 indicates additional status information, while More 0 does not prohibit logging.

2. Work through the possible causes

First establish this error’s exact logging requirement strength.

Compare before/after counts and correlate valid entries by command identity and status.

3. Connect observations to specification conditions

Absence can be compliant where no applicable mandatory logging requirement exists.

Explicit mandatory details, such as specified capacity failures, override general optionality.

Exclude overwrite, reset clearing and incomplete reads before declaring a missing record.

4. Evidence supplied by the log

A successful CQE does not require a new Error Information entry. Read the complete conditions in this volume

1. Preserve the evidence first

CQEs describe commands, error entries add failure details and PEL describes persistent events.

Verify event support, More and command identity before correlating.

Matching error status bits 15:1 match CQE status; phase follows its separate rule.

2. Work through the possible causes

First establish what each record actually proves.

Correlate identity/time before parsing event-specific outcome fields.

3. Connect observations to specification conditions

Successful sanitize acceptance and later operation failure can both be correct.

Reused CIDs and requested-versus-completed values can create false contradictions.

Build an acceptance/start/operation-completion/query timeline.

1. Identify the trigger and affected objects

Compare feature scope with actual reset coverage.

Preserve capabilities, value classes and the last successful Set’s save bit.

2. State changes and recovery

Namespace write protection has explicit retention despite being non-saveable.

Establish known saved state, apply a specific reset and requery the same target.

Pass criteria follow restoration rules and explicit exceptions, not universal zeroing.

3. Verify retention and recovery

Failed saves or intervening changes invalidate a simple lost-save diagnosis.

Record saveability, persistence, reset source and coverage separately.

First check the successful save and feature-specific exceptions.

1. Preserve the evidence first

Controllers can observe different changes according to attachment and notification rules.

Record support/enables, pending requests and before/after inventories.

Attachment changes active inventory while creation changes allocated inventory.

2. Work through the possible causes

First identify the management operation class.

Perform one operation, observe completion/notice and rediscover current state.

3. Connect observations to specification conditions

A changed NSID need not still exist because deletion also requires rediscovery.

NSID

Namespace Identifier

Overflow uses FFFFFFFFh and requires full rediscovery, not treating it as a real namespace.

Preserve the first list and distinguish the initiating endpoint from notified peers.

1. Preserve the evidence first

Slot/activation state may be shared within a domain.

Inspect capability, current/next active slots, slot revisions and current firmware revision.

Preserve action/slot/status and execute the specifically required activation reset.

2. Work through the possible causes

First verify action and activation mechanism.

Verify commit, perform activation and rediscover current state.

3. Connect observations to specification conditions

Equal version strings do not alone prove activation failure.

Fallback and requested PEL revision are not proof of active new firmware.

Reconcile pending/active slot, current revision and commit/reset events separately.

1. Preserve the evidence first

Match subsystem or namespace scope and result selection.

Inspect capabilities, command scope, status and supported completion events.

Interpret progress with operation and verification state, not FFFFh alone.

2. Work through the possible causes

First identify what the claimed completion actually establishes.

Preserve initiation completion and poll state, then correlate final result with any completion event.

3. Connect observations to specification conditions

In-progress after initiation is normal; final state must follow actual operation completion.

Exclude a newer operation, wrong scope and stale data before diagnosing a stuck status.

Correlate one operation across command, log, AER and PEL.

1. Preserve the evidence first

Match controller/shared-test scope and read the complete log correctly.

Inspect support/options/time and LID 06h's 20 newest-first result slots.

Current state, progress, result code, test code and validity bits have distinct roles.

2. Work through the possible causes

First establish that a test actually started.

Capture history, run one test and compare the newest result after completion.

3. Connect observations to specification conditions

Result update and return to idle follow the specified ordering for a test that produces a result.

An Abort while idle can succeed without creating a test result.

Interpret reset effects using the distinct short/extended-test rules.

1. Preserve the evidence first

Base 2.4 UPL counts qualifying power losses, not host shutdown calls.

Preserve count, request, status and actual power-loss time.

Ordinary qualification concerns main-power loss before SHST10b, with a separate applicable out-of-band ignore-shutdown case.

2. Work through the possible causes

First establish actual main-power loss and SHST at that moment.

Read baseline, request shutdown, observe status and compare after controlled power cycling.

3. Connect observations to specification conditions

Abrupt shutdown can complete before power loss and need not increment UPL each time.

Incomplete normal shutdown may qualify, while controller reset without power loss does not automatically count.

Use pre-loss state rather than post-restart SHST.

1. Preserve the evidence first

Aggregate and group-specific warnings use different scopes/settings.

Check support/enables, pending AERs and unacknowledged prior events.

Preserve warning bits, measured values and thresholds rather than only UI labels.

2. Work through the possible causes

First verify AEC at event time.

Verify qualifying conditions, competing/coalesced events and acknowledgment reads.

3. Connect observations to specification conditions

Qualifying enabled events follow their queuing rules, not one AER per sampled fluctuation.

No pending request means no immediate CQE; unconsumed completions are not missing notifications.

Correlate warning, configuration, requests and acknowledgments.

1. Preserve the evidence first

Subsystem PEL can interleave controllers and permits defined vendor ordering.

Inspect reporting context, generation and clock origin/synchronization.

Host changes and restoration can move timestamps, so they are not universal monotonic sequence numbers.

2. Work through the possible causes

First verify context and event boundaries.

Read one consistent context, parse lengths and account for clock-change/reset events.

3. Connect observations to specification conditions

Newest-first is recommended with vendor-defined ordering allowed, not an unconditional mandate.

Mixed contexts and incorrect event-length accounting can create false disorder.

Use a host monotonic timeline as evidence without equating unsynchronized clocks.

1. Preserve the evidence first

Distinguish fatal failure from a secondary controller’s Offline state.

Preserve accessible controller state, capabilities and recent management history.

Obtain available diagnostics without assuming every CFS cause has a readable dedicated record.

2. Work through the possible causes

First establish role and register-read validity.

Preserve evidence before reset/recovery, then query surviving records.

3. Connect observations to specification conditions

Reinitialize and verify recovery while retaining uncertainty about interrupted commands.

Unreliable/all-ones reads are not automatically valid NVMe state.

Separate device status, host timeout and communication-failure evidence.

1. Preserve the evidence first

Identify commands by endpoint, SQID/CID and queue lifetime.

SQID

Submission Queue Identifier

CID

Command Identifier, unique among outstanding commands in one SQ

Record target identity, Abort’s own identity and IANP.

IANP semantics do not erase the target’s completion, and IANP1 permits later normal completion.

2. Work through the possible causes

First identify which completion belongs to Abort itself.

Separate Abort and target CQEs, then exclude host double-consumption.

3. Connect observations to specification conditions

Handle one completion for each command without assuming the target had no effects.

Two genuine completions for the same target in one lifetime violate single-completion tracking.

Exclude CID reuse and CQ wrap before declaring duplicates.

CID

Command Identifier, unique among outstanding commands in one SQ

CQ

Completion Queue

1. Preserve the evidence first

Distinguish deleted queue memory from buffers belonging to other live commands.

Preserve target QID, successful deletion completion and memory range.

Submission is not successful deletion, and SQ/CQ dependencies differ.

SQ

Submission Queue

CQ

Completion Queue

2. Work through the possible causes

First establish successful deletion completion.

Check accesses after success and exclude legitimate address reuse by another queue.

3. Connect observations to specification conditions

After retirement, the controller must not continue using it as the deleted queue.

Such access can corrupt host data or produce invalid command/completion behavior.

Preserve reuse timing and queue identities; address equality alone is insufficient.

1. Preserve the evidence first

Reset ends old queue lifetimes even when addresses and identifiers are reused.

Inspect reset source, readiness transitions, CQ initialization and expected phase.

Rebuild command tracking without associating an old CID with a new request.

2. Work through the possible causes

First verify phase and command-tracking initialization.

Finish reset and initialize memory before accepting valid new-lifetime completions.

3. Connect observations to specification conditions

Ignore stale completions while separately resolving possible prior media effects.

New writes to a retired queue require investigation, unlike passive residual bytes.

Correlate initialization and write timing to distinguish stale storage from late access.

1. Preserve the evidence first

Detach affects selected endpoints, not every attached path.

Verify completed detach through both views.

Distinguish ordinary I/O from allocated-namespace queries and special management commands.

2. Work through the possible causes

First check endpoint and active-namespace requirement.

Submit a new command after successful detach on the detached endpoint.

3. Connect observations to specification conditions

Success on another attached path or an allowed allocated query can be normal.

Applicable inactive-namespace commands require Invalid Field absent an exception, distinct from invalid-NSID status.

Separate outstanding and newly submitted commands when assessing detach effects.

1. Preserve the evidence first

Scope selectors jointly define the target, not opcode alone.

Read supported/current prohibitions under matching selectors.

Feature scope prohibits Set, not automatically Get; enhanced aggregate ACNTL0 is not no prohibition.

2. Work through the possible causes

First inspect interface, controller scope and command-versus-feature selection.

Test an exact matching target plus an allowed control after successful Lockdown.

3. Connect observations to specification conditions

A prohibited matching Admin command requires 0/23h.

Exclude expiry, later allowance, mismatched interfaces and explicit personality exceptions.

Correlate configuration, inventory and behavior under identical selectors.

1. Preserve the evidence first

Establish source/target states and concurrent thermal constraints.

Read state types, entry/exit latencies and selected policies.

ITPT is idle time in milliseconds; entry/exit latencies are in microseconds.

2. Work through the possible causes

First verify units and timing origin.

Separate idle, transition trigger, recovery and command execution timing.

3. Connect observations to specification conditions

Assess relevant transitions rather than equating full read latency with EXLAT.

CQE timing alone may not isolate an exit-latency violation.

Compare an operational baseline with matching workload, temperature and settings.

1. Identify the trigger and affected objects

Reset coverage and persistence conditions differ across the three cases.

Select one function and capture support, state and affected endpoints.

2. State changes and recovery

Track registers, queues, settings, ongoing operation and stored data separately.

Reset from matched baselines and restore query access before comparison.

Extended self-test persistence and I/O queue invalidation can coexist under CLR.

3. Verify retention and recovery

CC.EN-specific register exceptions do not cover all CLR, and subsystem reset is not factory restoration.

Tie differences to explicit rules and retain limits where behavior is unspecified.

First identify the actual reset trigger.

1. Preserve the evidence first

Commands and selectors determine namespace, controller, group, domain or subsystem effects.

Inspect command selectors, feature scope, capabilities and command effects.

Broadcast semantics are command-specific and effects metadata does not replace explicit scope definitions.

2. Work through the possible causes

First read special selector values for that specific command.

Identify endpoint, targets and shared resources, then observe inside/outside controls.

3. Connect observations to specification conditions

Detaching one endpoint does not duplicate or delete shared namespace data.

Exclude shared-resource and concurrent-operation causes before alleging out-of-scope effects.

Compare matching entities and times; active inventories can legitimately differ by endpoint.

1. Preserve the evidence first

Define one function and its scope before testing multiple interacting mechanisms.

Capture discovery, effects and relevant configuration as the baseline.

Record request, completion and applicable logs/events, explaining inapplicable or unsupported interfaces.

2. Work through the possible causes

First state one precise requirement and then select the evidence needed to test it.

Run a valid case, isolate invalid conditions and then test persistence from matched baselines.

3. Connect observations to specification conditions

Conclusions identify supported requirements and remaining evidence limitations.

Do not turn permissions into mandates, invent statuses for undefined behavior or equate acceptance with background completion.

Link raw evidence on a timeline with source sections, figures and PDF pages.