Wise Hustlers — Digital Product & App Development Studio Logo
Get Consultation
By Wise Hustler Admin•9/14/2026•13 min read

Laboratory and Quality Control: Without a Registered Specification and Instrument, the Result Proves Nothing

Laboratory and Quality Control: Without a Registered Specification and Instrument, the Result Proves Nothing

# Laboratory and Quality Control: Without a Registered Specification and Instrument, the Result Proves Nothing

TL;DR: A test value ("Hardness: 21 HRC") is not a verifiable fact by itself — it is a conditional statement that only makes sense if the system knows which specification it was measured against, which instrument produced it, and whether that instrument held valid calibration on the date of the test. If the ERP or LIMS does not model those three links as structured, versioned data, the certificate of analysis it eventually prints is, technically, unverifiable — even when the number itself is correct.

The modelling mistake that starts before the first test

In nearly every industrial laboratory serving oil and gas operations — pipe and valve receiving inspection, drilling fluids, cement, produced water, lubricants — a test result is treated as a loose number: "Hardness = 21 HRC", "Chloride content = 45 ppm", "Viscosity at 40°C = 32 cSt". That number, on its own, says nothing. A test result is only interpretable in relation to three things:

1. Which specification it was measured against — an acceptance/rejection limit that belongs to a specific revision of a standard, a customer specification sheet, or a contractual requirement.

2. Which instrument produced it — a uniquely identified piece of equipment (serial number, not just "hardness tester at bench 2").

3. Whether that instrument held valid calibration on the date the test was actually performed — not on the date someone later checked the record.

Most spreadsheets, and a fair number of "lightweight" quality systems, treat these three things as free-text fields filled in by whoever runs the test: the operator types "per spec X" into one cell and "hardness tester #2" into another. The problem is not the intent of the person recording it — it is that free text cannot be validated, cannot be queried retroactively with any guarantee, and does not survive a standard revision or an instrument recalibration. A year later, when a customer or an auditor asks "was this result measured against the 2019 or the 2022 revision of the specification, and was the instrument in calibration that day?", the correct answer has to come from a data relationship, not from memory or a handwritten note.

1. Sample and chain of custody

Every sample — from a steel heat, a fluid drum, a produced-water purge — needs a unique identifier tied to its origin (supplier lot, well, asset, purchase order) and a custody record: who collected it, when, how it was transported, when it arrived at the laboratory. Without this, a test result becomes disconnected from the physical material it is supposed to describe, and traceability — the central requirement of any credible quality management system — disappears.

2. Specification as a versioned entity, not text

This is the core of the problem. A test specification — whether a public standard (API, ASTM, NACE/ISO) or an internal or customer specification sheet — has to exist in the system as its own record, with:

  • an identifier and revision (e.g., "NACE MR0175/ISO 15156, edition specified in the contract" or "Pipe receiving specification, Rev. 4"),
  • the parameters measured and their acceptance limits (minimum, maximum, or range),
  • an effective date and, where applicable, a superseded/obsolete date.

A test result attaches to one specific revision of this entity, never to "the specification" in the abstract. This matters because specifications change: a standard revision can tighten a hardness limit, or a customer can issue a new technical sheet mid-project. If the system does not record which revision was in force at the moment of the test, there is no honest way to answer, later, whether the material met the requirement that actually applied on that date.

3. Instrument and the requirement for calibration valid at the date of the test

Every measuring instrument used in a test — hardness tester, spectrometer, analytical balance, viscometer, pH meter — needs to be its own record in the system, identified by serial number, with a calibration history: each calibration carrying a calibration date, an expiry date (or defined interval), a result (pass/fail, with measured deviation), and the reference standard used. The international standard governing this is ISO/IEC 17025:2017, "General requirements for the competence of testing and calibration laboratories," which requires metrological traceability of results through a documented unbroken chain of calibrations, traceable to the International System of Units (clause 6.5) (ISO). In the oil and gas sector, API Spec Q1 — API's quality management system specification for equipment manufacturers — imposes the same logic: in the 9th edition, section 5.8 requires a procedure for testing, measuring and monitoring equipment covering a unique identifier, calibration status, traceability to national or international standards, calibration frequency, acceptance criteria and control of out-of-calibration equipment — including assessing the validity of previous measurements when an instrument is found out of calibration (API Spec Q1 9th edition summary). Section numbering changes between editions; check it against the edition your customer requires.

The practical implication for the ERP is direct: when a test is logged with a date and time, the system has to check — at the moment of recording, not after the fact — whether a valid calibration exists for that instrument covering that date. If the calibration has expired, or if the instrument is flagged "out of service" due to a deviation found in an interim verification, the test should be blocked, or at minimum flagged, before any certificate is issued from it. This is a simple business rule to describe and one that is frequently missing: comparing two dates and a status. The difficulty is not the logic — it is having the calibration data as structured records instead of loose PDFs in a folder.

4. The certificate of analysis

The certificate of analysis (or test report) produced at the end has to be generated from these three relationships, not typed by hand: it identifies the sample, the measured results, the specification (with revision) they were evaluated against, the pass/fail verdict per parameter, the instrument(s) used, and confirmation that each held valid calibration on the test date. This mirrors the logic of the inspection documents defined by the EN 10204 standard for metallic products, which distinguishes a Type 2.1 (declaration of compliance without test results), a Type 2.2 (test report with non-specific inspection results, i.e. not necessarily from the delivered lot), a Type 3.1 (specific-inspection certificate issued by the manufacturer's authorized inspection representative, independent of production), and a Type 3.2 (specific inspection also validated by the purchaser's representative or a third-party inspector) (EN 10204 — certificate types explained). A system that cannot distinguish between these certificate types, or cannot prove which one was actually issued for a given lot, puts an operator in a weak position during a local-content audit or in front of a customer demanding contractual traceability. The same structured-record discipline shows up in supplier qualification, as we describe in Qualifying Suppliers Under Local Content: The Workflow ANPG Expects to See in Your System.

For materials destined for sour service (H₂S-containing environments), the requirement is even more specific: NACE MR0175/ISO 15156 imposes hardness controls. The most-quoted value — 22 HRC (250 HV10) for certain carbon and low-alloy steel qualification routes — is not a universal rule: the applicable limit depends on the table, material, condition, weld state and environment severity, and has to be read from the correct part and table of the standard; hardness records (method and location: parent metal, weld, heat-affected zone) and the material certificate have to be linked to the ordered grade and condition (NACE MR0175/ISO 15156 — technical summary). If the "measured hardness" field is not linked, inside the system, to the "applicable specification limit" field and the "instrument used" field, there is no automatic way to flag that a 24 HRC reading exceeds a 22 HRC limit before the part moves on to installation.

5. Non-conformance and material disposition

When a result violates the specification limit, the system has to open a non-conformance record automatically — not leave it to someone visually spotting an out-of-range number on a printed sheet. That non-conformance record follows its own workflow: identification of the affected lot/sample, physical and logical quarantine of the material (blocking stock movement), root-cause assessment, and a disposition decision with a finite set of possible outcomes — reject and return to supplier, rework and retest, use-as-is under a documented engineering concession, or scrap. Each disposition needs approval by a specific role, timestamped and tied to the approver's identity — the same immutable audit trail principle we cover in Permissions That Don't Lie: RBAC and an Immutable Audit Trail in an Industrial ERP. Without that record, a "use it despite the deviation" concession can be granted informally over the phone and never appear anywhere when, months later, a field failure forces someone to reconstruct the decision.

What this means for parts and materials in stock

The most obvious point of contact between this workflow and the rest of the ERP is material receiving: a part or lot should only enter available stock once its corresponding certificate of analysis is linked to the receiving record with a "conforming" verdict. This is particularly relevant for critical maintenance parts — the same part-traceability problem we describe in Offshore Maintenance and MRO: The Parts Inventory Nobody Can See in Time, where the pressure to release stock quickly is even higher because downtime has an immediate cost. A properly modelled system blocks stock availability until the chain — sample, specification, calibrated instrument, certificate, verdict — is complete and consistent.

The minimum data model

EntityKey fieldsLinks to
SampleUnique ID, origin (lot/well/PO), collection date, chain of custodyMaterial lot, purchase order
SpecificationID, revision, effective date, parameters and limitsPublic standard or customer sheet
InstrumentID, serial number, typeCalibration history
CalibrationDate, expiry, result, reference standardInstrument
TestDate/time, sample, specification (revision), instrument, measured resultSample + Specification + Instrument
Certificate of analysisType (2.1/2.2/3.1/3.2), tests included, verdictTest(s)
Non-conformanceOriginating test, root cause, disposition decision, approverCertificate, lot

The integrity rule that makes this table function as an actual control, rather than an archive, is simple to state and easy to skip during implementation: a Test record should never be saveable without a valid Specification (with revision) and a valid Instrument, and the system should refuse to save the Test if its date falls outside that instrument's calibration validity window. That is a referential-integrity and date-range check — trivial to implement in a relational schema, but absent whenever "specification" and "instrument" are text fields instead of foreign keys.

Why the spreadsheet — and many generic LIMS tools — fail here

A spreadsheet does not enforce referential integrity: nothing stops someone from typing the name of a specification that no longer exists, or forgetting to check whether the instrument was in calibration on that date. Many "generic" quality systems, sold as document-management modules, suffer from the same underlying problem: they store the certificate as an attached file rather than as the output of a structured query across the three entities. That works fine until the day someone has to prove, for one specific lot, exactly which specification revision and which calibrated instrument produced a result — at that point, "it's somewhere in the folder" does not survive a customer audit, a warranty claim, or an incident investigation.

Building this correctly — sample, versioned specification, instrument with calibration history, a test linked to all three, a certificate generated from the relationship rather than typed by hand, and a non-conformance/disposition workflow with recorded approval — is data-modelling and business-rule work inside the ERP, not an extra form. It is the kind of purpose-built system we deliver through custom software when a petroleum customer's or oilfield service company's quality standard does not fit a generic quality module. Wise Hustlers is developing Enerxia, its ERP for Angola's oil and gas sector, with modules covering upstream, wells, production, projects/contracts, procurement, suppliers, inventory, MRO, maintenance, fleet, logistics, HSE, quality, HR, training, finance, tax and compliance — including this kind of laboratory traceability chain.

Frequently Asked Questions

Isn't a PDF certificate of analysis attached to the receiving record enough?

It works as a supporting document, but not as structured proof. If the PDF is not linked to specification records (with revision) and instrument records (with valid calibration at the test date), the system cannot automatically validate conformance, nor answer, years later, an audit question about which revision of the standard was in force on that date.

What practical difference does it make to require "calibration valid at the date of the test" instead of just "instrument calibrated"?

An instrument can be in calibration today but have been outside its validity window on the date the test was actually performed — for example, if the test is logged late, or if the certificate is reissued after a recalibration. The check has to compare the test date against the calibration validity window that applied on that specific date, not the instrument's current status.

Do all material certificates need to be Type 3.2 under EN 10204?

No. EN 10204 defines four types (2.1, 2.2, 3.1, 3.2) with increasing levels of independent verification; the type required depends on the contract, the criticality of the component and, for sour service, the additional requirements of NACE MR0175/ISO 15156. What matters for the ERP is recording which type was actually issued for each lot, not assuming all lots follow the same pattern.

What happens to a lot that fails testing but is already physically in stock?

It should be placed into logical and physical quarantine immediately — blocked from movement — until a disposition decision (reject, rework, use-as-is concession, or scrap) is made and approved by an authorized role, with the date and identity of the approver recorded. Without that automatic block, non-conforming material can keep being consumed while the non-conformance is still "under review."

Sources

Related articles