Unknown Is Not Incompatible: A Small Evidence Contract for Shopping Agents

A shopping agent reads a filament listing. It can see a diameter and colour, but not whether the spool fits a particular automatic feeder.

Two tempting responses are both wrong:

• "It is PLA, so it works with your printer and feeder."
• "The compatibility sheet is missing, so I cannot tell you anything about the product."

The first invents evidence. The second discards useful facts.

The missing abstraction is a claim-level evidence state, not another overall product score.

This is a practical follow-up to my earlier known-versus-unknown article. The new piece is an executable, scoped three-state policy and a real filament-listing example: missing evidence should restrict the affected claim without silencing the entire product explanation.

Disclosure: I operate WebAZ. The examples below use its public listings, not customer orders or payment records. The proposed contract and JavaScript are illustrative application logic, not a claim that WebAZ implements this exact policy.

A real catalog example, without a printing test

On November 4, our public catalog exposed two filament listings:

The reviewed listings indicate Singapore delivery. That does not establish worldwide service, postage or tax inclusion. A similarly named manufacturer's data sheet cannot fill missing fields until the exact product identity matches.

These are observations about listing content, not independent material measurements, authenticity certification or successful prints. Availability and prices can change; a fresh order-specific quotation is a separate step.

Three states, scoped to one claim

Use supported, contradicted and unknown for each specific claim. Examples of distinct scopes are:

• This listing states a diameter of 1.75 mm.
• This exact variant fits this exact feeder revision.
• This quotation includes shipping to this destination.

Evidence for the first does not prove the second. Likewise, a missing shipping fee does not mean free shipping.

Keep the basis and observation time alongside the value. A seller listing may support "the seller states X"; it does not automatically support "a manufacturer certified X".

Here is a deliberately small policy function. The caller must construct the scope from trusted structured fields and choose suitable authorities for the claim. Supplier prose must not choose its own authority.

function classify(e, scope, now, maxAgeMs, authorities) {
  if (!e || e.scope !== scope || !authorities.includes(e.basis)) {
    return "unknown";
  }
  const observed = Date.parse(e.observedAt);
  if (!Number.isFinite(observed) || observed > now ||
      now - observed > maxAgeMs) return "unknown";
  if (e.value === true) return "supported";
  if (e.value === false) return "contradicted";
  return "unknown";
}

This is a policy sketch, not cryptographic verification. basis is a trusted adapter's normalized label, not proof of signature validity. Resolving conflicting sources, validating signatures and choosing freshness windows belong in separate, explicit logic.

Continue the explanation; gate the consequential action

An agent can show confirmed listing details while saying "feeder compatibility is unknown." It should not silently convert that unknown into either a positive endorsement or a negative compatibility finding.

If the buyer explicitly requires that feeder fit, pause that recommendation or purchase decision until the requirement is resolved. Do not substitute another colour or variant merely because it has the same price. If the buyer instead asks only what is listed, answer that narrower question.

Before payment, obtain the current variant, quantity, destination, complete payable total and the buyer's authorization. A successful catalog read establishes none of those by itself. This article performs no order, reservation, signature or payment.

Test the boundary, not just the happy path

Local offline fixture checks cover 12 cases: absent/null evidence, explicit true and false, an unknown value, string-versus-boolean confusion, a wrong variant scope, an untrusted or missing basis, stale/invalid/future timestamps, and a valid observation at the freshness boundary. All data is synthetic; this is not a printer compatibility test or a live checkout test.

For a minimal executable check, paste the function above into a Node.js ES module, then add:

import assert from "node:assert/strict";
const now = Date.parse("2026-11-04T02:00:00Z");
const scope = "synthetic:variantA:feederRevision1:fits";
const e = { scope, basis: "manufacturer_document",
  observedAt: "2026-11-04T01:59:00Z", value: true };
const check = x => classify(x, scope, now, 60000,
  ["manufacturer_document"]);
assert.equal(check(e), "supported");
assert.equal(check({ ...e, value: false }), "contradicted");
assert.equal(check({ ...e, scope: "another-variant" }), "unknown");
assert.equal(check({ ...e, basis: "seller_listing" }), "unknown");

For developers building shopping agents: where do you keep "unknown" today, and which action is allowed to continue when only one required fact is missing? A minimal synthetic counterexample is more useful than a production log or payment credential.

AI disclosure: generated with AI assistance; public listing facts checked and the illustrative policy tested locally. No human-authored printing experience is claimed.