The provenance chip & the K10 refusal

A number is easy to pass along. A source class is not. The moment a value leaves the analyst who assessed it, its provenance starts to evaporate: was this observed or inferred? Is it corroborated, or does it rest on a single source? The consumer three desks away has no way to tell — because nothing on the screen says so.

ASSAY's provenance chip fixes that. It is a set of mandatory markings welded to every rendered value, not decoratively but structurally: the component will not render a value without them (ASSAY-DEC-9). The markings are not metadata you can hide; they are the rendering.

What the chip shows

An assessed knowledge item (K2 — causeway capacity):

assessed · moderate assessment, not fact owner: J-2

An observed value (K1 — controlling depth):

observed · high owner: J-2

A single-source item (K8 — fire-control threshold):

assessed · low assessment, not fact single-source owner: J-2

Live component rendering. These are the same chip strings provenanceChip() produces in the demonstrator. The assessment, not fact chip is mandatory for every non-observed value; the single-source chip appears whenever corroboration is absent. Neither can be suppressed. Frozen as shipped on 2026-07-12.

Three rules, none optional. First: every non-observed value carries "assessment, not fact", because that is constitutionally true and forgetting it is how false precision enters a surface (constitution II). Second: every uncorroborated value carries "single-source", because single-source reporting is the leading way an assessed band silently collapses (knowledge model §3). Third: the owner chip names who is responsible — the analyst who can update or retract the value.

The K10 refusal

K10 is the Meridian vignette's test of the encoding firewall. It is a piece of knowledge that fails the encoding check: its value type or constraint assignment violates the rules the system enforces before a value can enter the pipeline. ASSAY does not quietly drop it or log a warning. It refuses — in place, where the user tried to act — with a banner that names the offending item, the reason, and a one-sentence explanation.

Refused · encoding_violation offending: K10

K10 fails the encoding check: its value type is not assignable to a constraint or cost channel without a waiver.

Live component rendering. The banner is the shipped refusalBanner() component showing the Meridian K10 encoding-violation refusal. Frozen as shipped on 2026-07-12.

A refusal is an honest outcome shown to the user (seam §1), never a swallowed error. It names the offending item so the analyst can fix the source, not wonder what happened. The system's discipline — refusing bad input loudly instead of absorbing it silently — is one of the most important honesty properties the demonstrator carries.

Assessment, not fact — and demonstrator, not product. Every number here renders the Meridian Archipelago, an engineered fiction (ASSAY-DEC-8). Nothing on this page reflects any real operational picture. A thesis in ASSAY is only ever explored, never claimed proven.

Why they are load-bearing

Without the provenance chip, a downstream consumer has no way to know whether a value is observed truth or a low-confidence, single-source guess — and will treat both the same. Without the refusal banner, bad input enters silently and corrupts everything downstream. The chip and the banner are the two enforcement points of constitution II — banded honesty — at the boundary where knowledge enters the pipeline.

Sources & trace

Components — src/components/provenanceChip.ts · src/components/refusalBanner.ts
Banded honesty — ASSAY-DEC-9, DEC-14 in the decision register
Research note — 01-knowledge.md (the ICD 203 confidence reading)
Encoding firewall — src/encoding.ts · src/lint.ts
Fixtures — K10 in the Meridian vignette