Unknown Is Not Zero: Model Evidence Before Ranking Equipment Quotes

A procurement comparison screen can look precise while hiding a basic data problem: a blank cell might mean that a supplier omitted an answer, that two documents disagree, or that the question does not apply to the quoted configuration. Converting every blank into zero creates a number without creating knowledge.

For engineers building equipment-sourcing software, the first useful feature is therefore an explicit evidence model. Ranking comes later.

The data, equipment identifiers and requirements below are synthetic examples. This is a proposed software design, not a description of a Zenith Eclipse deployment or an actual supplier assessment.

Give absence a reason

JSON distinguishes an absent property from a property whose value is null; the JSON Schema reference explains that distinction. Neither representation, by itself, explains why information is missing.

Define application states with operational meanings:

State	Meaning in this application	Next action
known	A value has been extracted or entered with a source reference.	Review its applicability and evidence.
not_provided	The expected source or response contains no answer.	Request the missing information.
unknown	An answer cannot currently be determined, with a recorded reason.	Investigate the stated uncertainty.
not_applicable	The requirement does not apply to this configuration.	Require an applicability decision.
conflict	Multiple relevant sources assert incompatible values.	Resolve the disagreement explicitly.

These are proposed business rules, not a universal machinery standard. In particular, known means that a claim exists; it does not mean the claim is correct or approved.

Make invalid combinations difficult to represent

A discriminated union keeps a missing answer from accidentally acquiring a numeric value. This abbreviated TypeScript model covers categorical comparison fields:

type EvidenceRef = {
  documentId: string;
  revision: string;
  locator: string; // e.g. page and table row
};

type Claim = {
  value: string;
  evidence: EvidenceRef;
};

type Cell =
  | {
      state: "known";
      claim: Claim;
      review: "pending" | "accepted" | "rejected";
    }
  | { state: "not_provided"; requestedField: string }
  | { state: "unknown"; reason: string }
  | {
      state: "not_applicable";
      reason: string;
      applicability: "pending" | "approved";
    }
  | {
      state: "conflict";
      claims: [Claim, Claim, ...Claim[]];
      reason: string;
    };

TypeScript types do not validate incoming JSON at runtime. Validate supplier uploads and API requests at the boundary. A JSON Schema implementation can use a oneOf branch for each state, require its discriminator and relevant fields, and reject unintended properties within each branch. oneOf requires exactly one matching branch; object-property controls help prevent an unresolved cell from silently carrying an unused value field.

For quantitative fields, extend Claim with the original value, unit, operating conditions and any normalization rule. Keep the source wording alongside the normalized value. A successful unit conversion does not establish that two figures describe the same configuration or test conditions.

Separate eligibility from preference scoring

Consider a fictional packaging-line enquiry whose mandatory integration requirement is a particular interface. One quote explicitly meets it; another omits the answer. The second quote has an unresolved requirement, not a confirmed technical failure and not a confirmed match.

Use a gate before any price or preference ranking:

type Gate = "pass" | "fail" | "needs_review";

// Only for mandatory, applicable categorical requirements.
function gate(cell: Cell, expected: string): Gate {
  if (cell.state !== "known") return "needs_review";
  if (cell.review !== "accepted") return "needs_review";
  return cell.claim.value === expected ? "pass" : "fail";
}

This intentionally uses exact equality. Production software needs a controlled vocabulary and requirement-specific comparison rules; guessing that differently worded claims are equivalent would undermine the gate.

A not_applicable response to a mandatory applicable requirement also needs review. Approving an exemption must change the requirement decision explicitly, rather than making the bidder pass through a missing-data shortcut.

Keep unresolved candidates visible in a separate queue. Do not label them “worst equipment” because their documentation is incomplete. For optional criteria, show coverage beside any provisional score. If missing answers could change the ordering, display that uncertainty rather than presenting a definitive winner. Avoid quietly renormalizing weights differently for each bidder: that can reward omissions.

Preserve the evidence behind every decision

A mutable document URL is insufficient for reproducing a comparison. Store a document identifier, revision, captured timestamp, access-controlled content reference and checksum, together with the page or section supporting the claim. A checksum helps detect changed bytes; it does not prove that a document is authentic or its contents are true.

The W3C PROV model distinguishes entities, activities and agents and supports derivation relationships. Applied here, a source-document version is an entity; extraction and review are activities; the resulting normalized claim is another entity. You can use that separation without adopting a full semantic-web stack.

Retain the original claims when resolving a conflict. Record the chosen interpretation, reviewer role, reason and superseded evidence. Recompute affected comparisons when a document, machine configuration or requirement version changes. An old acceptance should not silently carry over to a different configuration.

Test the uncertain cases

Include fixtures for an omitted answer, an explicit zero where the field permits zero, contradictory revisions, a pending applicability decision and an accepted value that fails a requirement. Verify that every unresolved mandatory item prevents a final ranking, while an actual mismatch remains distinguishable from missing evidence.

This model cannot verify a machine's real performance, determine contractual suitability or replace technical review. Its purpose is narrower: preserve what the software knows, explain what it does not know, and prevent a polished comparison table from turning uncertainty into a fabricated score.

---

About the publisher: Zenith Eclipse Co works across agricultural commodities, international logistics and machinery sourcing.