> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

## Start with a question

Lithi Test Lab results answer a defined verification question. This reference shows how to choose a case, inspect bounded evidence, compare representations, and read a result without stretching it beyond scope.

## Choose the case

Name the claim before choosing a profile. A case might ask whether a document keeps approved wording, whether an inventory is coherent, or whether declared data use matches observed classes. These questions need different checks, so do not infer coverage from a broad label.

Confirm the profile, role, sample input, required conditions, and visible outputs. A fixture is controlled sample input, not live mail or a customer file.

If a question needs a device, second Mac, isolated network, signing state, or another unavailable condition, record that requirement first. A check that cannot run is a skip, not a pass.

## Inspect source and evidence

Read the run identity first. Look for the source or build identity, selected profile, and evidence references.

The identity tells you what was examined; a reference lets you recognise an output without copying its contents. If the identity is missing or points elsewhere, resolve that mismatch before interpreting assertions.

Then inspect assertion counts and details. A verdict such as **pass**, **fail**, or **skip** is a summary; the assertion list explains what was actually checked.

Read the privacy summary as well. It records what the check kept outside its boundary.

## Compare visible variants

When a result appears in more than one document form, compare visible facts rather than trusting a polished summary. Check the profile, source identity, verdict, counts, skip reasons, evidence references, and privacy boundary. A matching presentation does not prove browser, device, application, or release behavior.

## Interpret the result

Interpret **pass** as a scoped statement: the named assertions held for the identified source, profile, fixture, and environment. Interpret **fail** as a boundary that names what needs repair or review. Interpret **skip** as an important limit because it identifies a condition the run did not examine.

Read every condition with its profile context. Similar labels can describe different checks, so a bare number or status is not enough. A Test Lab result is evidence for named checks; it is not a receipt for a product action.

## Keep the limits visible

One profile does not prove every property of a build. A software-inventory check says nothing about accessibility, and a documentation check says nothing about network behavior. Evidence is bound to the source it names and does not automatically cover a later source.

If a result lacks a source identity, profile, fixture, or privacy summary, treat it as incomplete and ask the run owner for the missing evidence.

Keep private inputs and secrets outside fixtures, logs, exports, and support material. For a wider security boundary, [visit the Trust Center](/trust).