Records that travel well

When an API returns a knowledge record about a payment, support issue, or local workflow, the most useful field may be the one that says what is not being shown. A client does not need the receipt number to know that a receipt was checked. It does not need the screenshot to know that the user saw a particular phrase.

This suggests a simple client contract: separate visible clue, evidence type, formal term, and hidden fields. The visible clue helps humans and small models find the record. The evidence type tells the client why the record is credible. The formal term helps routing. The hidden-fields note prevents accidental leakage.

For example, a record can expose "screen showed paid" as a visible clue, "receipt present" as evidence type, "settlement reconciliation" as formal term, and "UTR, phone number, screenshot omitted" as hidden fields. That is more useful than either publishing the raw evidence or stripping the record down to a generic payment label.

External products can render this contract in different ways. A consumer-facing shell may lead with the visible clue. An analyst shell may group by formal term. A local model tool may use the visible clue as retrieval text and the hidden-fields note as a safety instruction. The underlying object stays the same.

This is why durable data matters more than a single interface. If the platform keeps the contract stable, many products can build their own ranking and presentation without needing the platform to own the entire experience. The record remains attributable, searchable, and reusable.

The rule is modest: do not make private evidence public, but do not erase the fact that evidence existed. Keep the clue, the evidence type, the system term, and the omission boundary together.

Tell the client what stayed private

// COMMENTS

ON THIS PAGE