Four documents about one research material can carry four different identifiers: one printed on the container label, one in the supplier's material record, one assigned on the laboratory's submission form, and one on the issued report. None is wrong, and none is automatically related to the others. Lot traceability, as used here, means writing down which object each identifier names, who issued it, and which document states how it connects to the next.
Finding a certificate for a compound and reading its results are separate jobs, owned by the introductory guide to reading a certificate of analysis and by the available lot documentation. This page owns the narrower task of reconciling identifiers across documents, including one-to-many cases, version history, and mismatches that stay unresolved until the issuer speaks. Every identifier below is a labeled placeholder and every scenario is a teaching example.
Which object does each identifier name: lot, sample, accession, or report?
An identifier is three things at once: a string, the party that assigned it, and the object it was assigned to. A report might print a value under the heading Lot, but the heading only says what the laboratory called the field, not whether the value was copied from a label, typed by the submitter, or generated on receipt.
A lot number is assigned by the party that produced or packaged a quantity of material and names that quantity. A report identifier is assigned by the laboratory that issued a document and names the document. The two identify different objects, so neither substitutes for the other. A report may quote a lot number, but that quotation is a statement by the laboratory about what it was told, not proof that the material in the container came from that lot.
| Category | Object it identifies | Typical issuer | Placeholder used below |
|---|---|---|---|
| Product or catalog code | A listed catalog item, not a production run | Seller | <catalog-code> |
| Production lot | One quantity of material produced or packaged together | Producer or packager | <supplier-lot> |
| Submitted sample | The physical portion sent for analysis | Submitter | <sample-ref> |
| Laboratory accession | The laboratory's record for a received sample | Receiving laboratory | <lab-accession> |
| Issued report | A specific document the laboratory released | Issuing laboratory | <report-id> |
| Document revision | One version of an issued report | Issuer of the document | <revision-tag> |
The six categories are a worksheet convention for this page, not a universal naming rule, and no primary source cited here establishes one. Issuers use their own vocabulary: batch and lot may be synonyms at one supplier and distinct at another, and a laboratory may say case, job, or request where this page says accession. File by object, not by label, and note whenever the source's label disagrees with the object.
How do you build an issuer-aware identifier crosswalk?
A crosswalk has one row for every occurrence of an identifier, not one row per identifier. If the same lot string appears on the container label, in the shipping record, and in the report header, that is three rows, each with its own issuer, source location, and retrieval date. Collapsing them discards the evidence that shows where a transcription error entered the chain.
| Exact field label | Exact value | Issuer | Object | Source location | Retrieval date | Link asserted by source | Status |
|---|---|---|---|---|---|---|---|
| Lot No. | <supplier-lot> | Producer | Production lot | Container label, front | <retrieval-date> | None | Recorded |
| Lot | <supplier-lot> | Laboratory, copied from submission | Lot as declared by submitter | Report header, page 1 | <retrieval-date> | Printed beside <lab-accession> | Recorded |
| Accession | <lab-accession> | Laboratory | Received sample | Report header, page 1 | <retrieval-date> | Printed beside <report-id> | Recorded |
| Report No. | <report-id> | Laboratory | Issued document | Report footer, every page | <retrieval-date> | Footer states revision <revision-tag> | Recorded |
Copy each value exactly as the source shows it. Leading zeros, letter case, hyphens, spaces, and the difference between the letter O and the digit zero all survive into the exact value column, because any of them may show that two strings were never the same identifier. If a normalized form helps sorting or searching, keep it in a separate column, write down the rule that produced it, and never let it stand in for the original in a comparison that decides status.
The link column holds only what the source itself asserts. A report header that prints a lot value beside an accession value asserts that the laboratory associated the two; a label that prints only a lot value asserts nothing about any report. Writing none there is a legitimate and frequent entry.
How do you record each identifier relationship and its evidence?
A second worksheet records relationships. Identifiers are points and relationships are the lines between them; each line needs a direction, a claim, and a class of evidence.
supplier record submission laboratory report <supplier-lot> --> <sample-ref> --> <lab-accession> --> <report-id>
Three evidence classes cover every line. Source stated means a named document asserts the relationship. Reviewer inferred means no source states it, but the reviewer connected the two through similar text, a matching date, or a shared product name. Unresolved means the reviewer has looked and found neither. Only the first class supports a confirmed relationship in the final note.
| From | To | Relationship claimed | Evidence class | Evidence location |
|---|---|---|---|---|
| <supplier-lot> | <sample-ref> | Sample drawn from this lot | Source stated | Submission form, lot field |
| <sample-ref> | <lab-accession> | Submission became this accession | Source stated | Laboratory receipt |
| <lab-accession> | <report-id> | Report describes this accession | Source stated | Report header, page 1 |
| <supplier-lot> | <report-id> | Report describes this lot | Reviewer inferred | Chained from the three rows above |
| <catalog-code> | <supplier-lot> | Lot sold under this catalog code | Unresolved | Label shows both; no source links them |
The fourth row matters most. A lot-to-report relationship rarely appears as a single statement in one document; it is assembled from shorter stated links and is only as strong as the weakest of them. If the submission form is missing, the first link drops to unresolved and the lot-to-report claim drops with it, however clearly the report quotes the lot string.
Similar identifiers cannot count as a match on their own. A shared prefix, an overlapping date fragment, or the same product name shows that two strings might refer to the same object, and is a reason to ask the issuer. A match is established only when a named source states the relationship, or when the two strings are character-for-character identical and were issued by the same party for the same object. Anything less is recorded as reviewer inferred or unresolved.
How does one lot map to multiple samples and multiple reports?
One lot mapping to one sample and one report is the simplest case, not the typical one. A production lot can legitimately sit behind several accessions and report identifiers, and a crosswalk that assumes one report per lot will misread the ordinary case.
| Case | In the documents | Crosswalk records | Must not assume |
|---|---|---|---|
| Repeat sampling | Two submission forms cite the same lot on different dates | Two sample rows, two accession rows, two edge sets | That the second sampling replaces or confirms the first |
| Separate analytical panels | Two reports for one accession, covering different measurements | Two report rows sharing one accession edge | That either report is the complete record |
| Original and revised reports | Same report identifier, different revision tags | One report row per revision plus a record-history entry | That the later revision is correct or the earlier withdrawn |
| Component evidence versus a combined item | Reports for individual components plus a label for a combined item | Separate edges per component; none to the combined item unless a source states one | That component reports describe the combined item |
The second edition of the Eurachem and CITAC guide on measurement uncertainty arising from sampling regards sampling and physical sample preparation as parts of the measurement process, each contributing uncertainty. So the sampling context is its own record: which container the portion came from, when it was drawn, and how the submission form described it are facts about a sampling event, distinct from what the report states about the measured portion. Whether a sampled portion represents the whole lot depends on a documented sampling basis, which this page neither supplies nor evaluates.
One lot can have multiple reports, and a crosswalk should expect it. Repeat sampling, separate analytical panels, revised documents, and component records for a combined material each generate an additional report identifier tied to the same lot. The reports coexist as separate records. None of them replaces another unless the issuing laboratory states that relationship, and a later date alone is not such a statement. Each report describes the portion it names, not the lot as a whole.
How do you work through an identifier mismatch without guessing the correction?
A mismatch is any case where two sources disagree about an identifier or the object it names. The reviewer's output is a description, not a repair. Each case below ends with the conflict written down and a request sent to the issuer.
Case A, transposed display characters. The label reads <supplier-lot> and the report header reads a string that differs only in the order of two adjacent characters. Observed conflict: the strings are not identical. Evidence needed: the laboratory's statement of which string it received on the submission form, and the supplier's statement of which string it printed for that shipment. Status: unresolved. The label is not right because it is physical, nor the report because it is typed.
Case B, an accession entered where a lot was expected. The report's lot field holds a value shaped like the laboratory's own accession values rather than any supplier lot. Observed conflict: the field label and the apparent issuer disagree. Evidence needed: the submission form as the laboratory received it, showing whether the lot field was blank, filled with the accession by mistake, or overwritten later. Status: unresolved; the suspicion is recorded as an inference.
Case C, a revision that changes the sample description. Two files share one report identifier and differ in revision tag; the later one describes the sample as a different item, with no stated reason. Observed conflict: one accession now has two descriptions. Evidence needed: the issuer's own revision note. Status: unresolved. Both descriptions and both files stay in the record, and no edge from that accession to any lot is marked source stated.
How is document history different from metrological traceability?
The word traceability does two jobs here. Everything above is document traceability: whether a chain of identifiers links a container to a report through stated relationships. The NIST policy on metrological traceability describes something different, a property of a measurement result, established through a documented, unbroken chain of calibrations that each contribute to the measurement uncertainty. The same policy states that traceability by itself does not establish fitness for a particular purpose.
Lot traceability does not establish measurement traceability. A complete identifier chain shows that a container, a submission, an accession, and a report are linked by stated relationships. Metrological traceability, as the NIST policy defines it, is a property of a measurement result and depends on a documented chain of calibrations with stated uncertainty. The two answer different questions, are supported by different records, and neither one implies the other.
| Question | Answered by the identifier chain | Answered by the measurement chain |
|---|---|---|
| Does this report describe the sample drawn from this container? | Yes, if every edge is source stated | Not addressed |
| Was the instrument calibrated through a documented chain with stated uncertainty? | Not addressed | Yes, if calibration records support it |
| Which revision does the issuer currently stand behind? | Yes, from the record-history worksheet | Not addressed |
| Is the reported value fit for a particular research purpose? | Not addressed | Not addressed; NIST separates fitness for purpose from traceability |
The NIST definitions page describes a reference material as sufficiently homogeneous and stable for specified properties and an intended measurement use, and a certified reference material as one whose certificate specifies property values, their uncertainty, and their metrological traceability. Those definitions do not turn a catalog research material, or a document titled certificate of analysis, into a certified reference material, and neither NIST source cited here certifies any material, supplier, or lot.
How do you preserve report versions and supersession evidence?
Reports get revised: descriptions are corrected, pages are added, and sometimes a file is re-exported unchanged. The record-history worksheet gives each version its own row, so that which version supersedes which is answered by the issuer rather than by download order.
| Field | What to record | Placeholder entry |
|---|---|---|
| Original source | Where this version was obtained | <source-location> |
| Revision identifier | The revision tag or version number the issuer prints | <revision-tag> |
| Revision date, if supplied | The date the issuer gives for this revision | not stated |
| Reason stated by issuer | The issuer's own words for why this revision exists | not stated |
| Relationship to earlier report | Supersedes, supplements, coexists, or not stated | not stated |
| Changed fields | Which fields differ from the prior version | sample description; page count |
| File fingerprint | Filename, size, and checksum as retrieved | <filename>, <size>, <checksum> |
| Retrieval date | When the reviewer obtained this file | <retrieval-date> |
Keep every prior version in the local review record; deleting an earlier revision destroys the only evidence of what changed. A recently retrieved document is not automatically a newly issued one: the retrieval date records when the reviewer obtained the file, and the revision date, if supplied, records when the issuer produced it. A filename, size, or checksum distinguishes one file from another and shows the bytes have not changed; it does not show which version the issuer stands behind, whether the content is scientifically sound, or whether the document came from the party named on it.
- Issuer states supersedes: the later document says it replaces the earlier one.
- Issuer states supplements: the later document adds to the earlier one without replacing it.
- Coexists: both are current and cover different scopes.
- Not stated: the issuer has said nothing; record the ambiguity instead of resolving it.
How do you write a reconciliation note someone else can repeat?
The final product is a short note that a second reviewer can verify without talking to the first. Repeatability comes from exact references: file, page, field, date. A note that says the lot matches the report is an opinion; a note that says the label's lot value equals the report's page 1 lot value, both retrieved on a stated date, is a checkable claim.
RECONCILIATION NOTE
1. Records inspected
- <source-location> label, front panel retrieved <date>
- <source-location> report <report-id>, rev <tag> retrieved <date>
- <source-location> submission form <sample-ref> retrieved <date>
2. Relationships confirmed (source stated)
- <sample-ref> --> <lab-accession> laboratory receipt
- <lab-accession> --> <report-id> report header, page 1
3. Relationships unsupported (inferred or unresolved)
- <supplier-lot> --> <sample-ref> submission lot field blank
4. Exact source references: one line per record
5. Unresolved requests
- to <issuer>: confirm the lot value received on <sample-ref>When the label and the report cannot be reconciled, the note preserves the contradiction and asks the issuing source to resolve it. That is the whole action. The reviewer does not pick the more plausible string, does not edit either document, and does not decide whether the material may be used, released, or returned. Release decisions belong to whoever owns the laboratory's or organization's policy; this page sets none.
- Quote both conflicting values exactly, with their source locations.
- State the specific question the issuer can answer.
- Change an edge's evidence class only on the reply, never on time elapsed.
How does the crosswalk apply to available lot documentation?
Two pages on this site feed the worksheets above: the available lot documentation, subject to what that page says is present or held, and the introductory guide to reading a certificate of analysis, which explains what the fields on such a document mean. Neither substitutes for the crosswalk.
Source presence and source match are separate findings. Presence means a document exists and can be opened. Match means the identifiers on that document connect to the identifiers on the container through stated relationships. A directory can establish presence; only the crosswalk and edge table establish match.
| Question | Presence check | Match check |
|---|---|---|
| Is a document filed under this lot string? | Yes | No |
| Does the document's lot value equal the label's, character for character? | No | Yes, from the crosswalk |
| Does the document print its lot value beside the accession it reports on? | No | Yes, from the edge table |
| Is the filed document the revision the issuer stands behind? | No | Yes, from the record-history worksheet |
This page contains no worked example built on a real Glow lot, laboratory, or report. Private order identifiers such as order numbers and shipment references are not source material for a shared crosswalk; cite the container label and issued documents instead. A catalog code's issuer-side meaning is visible on the catalog listing, and the vendor evaluation guide owns the broader question of a supplier's documentation practices. Glow is a commercial publisher of research-material information; this page is not an independent ranking of any laboratory or seller.
Frequently asked questions
Are lot, batch, sample and accession IDs interchangeable?
No. They name different objects. A lot or batch identifier names a quantity of material produced or packaged together; whether lot and batch are synonyms depends on the issuer. A sample identifier names the physical portion submitted for analysis. An accession identifier names the laboratory's internal record for what it received. The same string can appear in more than one role when one party copies it from another document, but copying does not merge the objects. File each occurrence under the object it names.
Why might one lot be linked to more than one report?
Because reports are issued per measured portion and per document, not per lot. Two samples drawn from the lot on different occasions each get their own accession and report. One sample analyzed for two separate sets of properties may yield two documents. A corrected report keeps its identifier and gains a revision tag, and both versions remain records. A combined item may have separate reports for each component. Record every report as its own row and let the issuer say which, if any, replaces another.
Should I remove punctuation or leading zeros to make IDs match?
Not in the crosswalk column that decides status. The exact value column keeps every character the source printed, including leading zeros, hyphens, spaces, and letter case, because any of them may be the only evidence that two strings were issued separately. If a simplified form helps sorting or searching, add a normalized column beside the exact one, write down the rule, and apply it to every row. A match found only after normalization stays reviewer inferred until the issuer confirms that the original strings name the same object.
Does a newer file replace an older report?
Not by itself. A file's newness can mean the issuer produced a new revision, the issuer re-exported an unchanged document, or the reviewer simply downloaded it more recently. Only the first is a revision, and only the issuer's own statement establishes that a revision supersedes an earlier one. Record the revision tag, the revision date if supplied, the stated reason, and the fields that changed, and keep the earlier file. When the issuer says nothing, the two versions coexist with the status not stated, and the ambiguity is reported, not resolved.
What if an accession lookup opens a different sample description?
Stop and record the discrepancy: the accession string you entered, where you entered it, the date, and the sample description that came back. Then compare that description with your submission form and any report you hold. The possibilities include a typing error in the lookup, a revision that changed the description, a laboratory data-entry error, or an accession that belongs to a different submission, and none can be told apart from your side. The edge from that accession to your sample drops to unresolved, and your request to the laboratory quotes both descriptions.
Does a complete record chain prove every item in a lot was measured?
No. A complete chain proves that one submitted portion was received, given an accession, and described in a report, with each link stated by a named source. It says nothing about the containers that were not sampled. The Eurachem and CITAC guidance on uncertainty from sampling regards sampling as part of the measurement process, so how well a sampled portion represents the rest of the lot depends on a documented sampling basis that the identifier chain does not contain. Locating that sampling record is a separate task from identifier reconciliation.
Sources and scope notes
The metrological traceability statements are paraphrased from the NIST policy on metrological traceability and the reference material definitions from the NIST Standard Reference Materials definitions page, both read on September 20, 2026, Pacific time. The sampling statement is paraphrased from the official landing page of the Eurachem and CITAC guide, second edition, read the same day; the full guide was not reviewed, and no sampling design is derived from it.
Every identifier, document, case, and worksheet entry on this page is a hypothetical teaching example built from labeled placeholders. No real lot, laboratory, report, order, result, or Glow record is described. The worksheet categories and status vocabulary are editorial conventions, not a published standard. This page is not a certificate lookup, a results interpretation guide, a release policy, a sampling procedure, or a statement about any material's properties.
- NIST, Policy on Metrological Traceability (NIST P 5800.00, effective May 31, 2019) Current page read September 20, 2026.
- NIST, Standard Reference Materials: Definitions Read September 20, 2026; no publication date on the page.
- Eurachem and CITAC, Measurement uncertainty arising from sampling, second edition (2019), guide landing page Landing page read September 20, 2026. The full PDF was not reviewed.