# 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](https://json-schema.org/understanding-json-schema/reference/null) 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:

```typescript
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](https://json-schema.org/understanding-json-schema/reference/combining); [object-property controls](https://json-schema.org/understanding-json-schema/reference/object) 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.

Zenith Eclipse's [machinery and equipment sourcing scope](https://zenitheclipse.com/machinery-equipment-sourcing/) provides concrete specification dimensions—such as capacity, controls, accessories and interfaces—that a comparison model may need to represent. Those fields describe the equipment enquiry, not evidence that the hypothetical scoring software is in use. 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:

```typescript
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](https://www.w3.org/TR/prov-o/) 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.

The commercial boundary matters too: Zenith Eclipse's [global sourcing and supply process](https://zenitheclipse.com/global-sourcing/) distinguishes the goods, included items and agreed responsibilities in an offer. Preserve that scope with the technical evidence so two apparently identical specifications are not ranked as equivalent when one quotation excludes a required item.

## 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](https://zenitheclipse.com/) works across agricultural commodities, international logistics and machinery sourcing.