Read a Lithi Test Lab Result

Use a Lithi Test Lab run to answer one defined verification question. Choose the case, inspect its evidence, compare any visible variants, and interpret the result within the named scope.

Your agent keeps the task goal, context, model, edits, native builds and tests, and final acceptance. Test Lab supplies evidence for named checks; it does not replace the agent's decision or promise a verified pull request. A receipt or integrity check establishes its declared identity and integrity boundary, not semantic correctness.

1. Choose the question and 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; a broad label does not prove coverage.

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 the 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.

2. Inspect the evidence

Read the run identity first: source or build identity, selected profile, and evidence references. The identity tells you what was examined; a reference lets you recognize an output without copying its contents. Resolve a missing or mismatched identity before interpreting assertions.

Then inspect assertion counts and details. Pass, fail, and skip summarize the run; the assertion list shows what it actually checked. Read the privacy summary to see what the check kept outside its boundary. Keep format and integrity checks, source and coverage checks, and semantic review separate; each proves only the assertions it names.

3. Compare visible variants

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

4. Interpret the result

Pass means the named assertions held for the identified source, profile, fixture, and environment. Fail identifies a condition that needs repair or review. Skip identifies a condition the run did not examine.

Read each 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. For coding work, the agent still performs repository edits, native builds, tests, and final acceptance.

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.