Documentation
Tutorials
Workflows
Kebab actions
Daily Work
Dashboard & Reports
Quality Control
ISO 17025
Logs
Contacts
Billing
Analysis Setup
Settings
Initial Setup
Help & Reference
Architecture decisions
Architecture decisions
0:000:00

Why decision rules and conformity statements

The problem: measurement 4.9 vs limit 5.0

A sample measures 4.9. The specification limit is 5.0.

Did it pass?

Naive comparison says "yes, 4.9 < 5.0, PASS".

Statistical reality says "it depends".

If the expanded measurement uncertainty is ±0.2 (interval

4.7-5.1), the true value likely exceeds the limit. The same

measurement can be PASS, FAIL, or INDETERMINATE depending on the

decision rule the lab applies — and that rule MUST be agreed in

advance, not a per-analyst judgement call.

The decision: explicit rule per criterion and per sample-order

Agrometrisis treats the decision rule as a first-class citizen of

the schema:

  • AcceptanceCriterion.decisionRule — the lab's default per

method/element (SIMPLE_ACCEPTANCE / GUARD_BANDS / ILAC_G8 /

CUSTOMER_SPECIFIED).

  • SampleOrder.decisionRuleAgreed — the customer-agreed rule per

order; wins over the per-criterion default.

  • Measurement.conformityOutcome + Measurement.decisionRule — the

evaluation outcome and the rule applied, frozen on the row at

evaluation time (evaluateConformity() in MeasurementResolver,

resolution chain AnalysisRecord → Aliquot → Sample → SampleOrder).

Freezing = reproducibility. If the criterion's default rule changes

tomorrow, historical reports remain immutable.

What §7.1.3 / §7.8.6.1 / §7.8.6.2 actually demand

  • §7.1.3 — when a conformity statement is issued, the decision

rule must be documented and agreed with the customer.

  • §7.8.6.1 — the rule must be applied consistently (not an

ad-hoc per-analyst judgement).

  • §7.8.6.2 — the conformity statement must identify (a) which

results it applies to, (b) which specifications were met or not

met, (c) which decision rule was applied.

The hard approval gate

Before an AnalysisRecord can transition to APPROVED,

_enforceConformityGuard counts three gap categories: INDETERMINATE

outcomes, measurements with a criterion-that-has-limits but

NOT_APPLICABLE outcome, and measurements with a criterion but NULL

outcome.

If the total is non-zero, approval is blocked with

APPROVAL_BLOCKED_CONFORMITY. Only LAB_DIRECTOR or REVIEWER may

override, with a reason ≥20 characters — and the override is audited

via OverrideHelper.recordEvent (action OVERRIDE_CONFORMITY_APPROVE).

What the auditor sees

In the measurements grid: a live ✓ PASS / ✗ FAIL / ⚠ INDETERMINATE

pill on every row, with the frozen rule and limits surfaced in the

tooltip. On the printed report: the same Conformity column per

measurement plus a §7.8.6 footer block listing every distinct rule

applied across the report.

The auditor sees the 4.9 measurement, the 5.0 limit, the ±0.2

uncertainty, the GUARD_BANDS rule and the INDETERMINATE outcome —

and verifies that the same rule was applied consistently across

the entire AnalysisRecord.