A screen full of completed badges may reassure an owner while leaving an important question unanswered: does completed mean saved, sent to a supplier or received at a site? Those statements support different decisions. I turned a recurring boundary from the ERP work records into this independent synthetic example. It does not restore the original program or connect to its business data. It reads explicitly supplied evidence and shows why separate events should not become one generic success state.
Keep the document version beside the event version
Input contains a document identifier, its current version and an evidence list. Each evidence entry has a kind, a document version and a stable reference. If the current document is version two but sending evidence belongs to version one, the result says earlier-version. It does not assume the latest contents have been sent. Having revised a document and having communicated that revision are different facts.
Absent evidence remains absent. Saving does not generate confirmation, sending or receipt evidence. A receipt entry does not automatically manufacture all preceding steps either. This is a read-only interpreter, not a workflow engine enforcing the permitted order of operations. A consuming application still needs its own transition and authorization rules. The example helps inspect whether meanings have been combined before that larger contract is implemented.
Repeated references must not multiply events
Retries and merged files can repeat an evidence reference. Identical references with the same kind and version are read once. A reference reused for a different kind or version is rejected as a conflict. Silently accepting the last occurrence would conceal which record was trusted. Making that contradiction visible gives an integrator a concrete condition to resolve instead of a misleading current-state label.
Evidence for a future version and unsupported event kinds are also rejected. Versions must be safe positive integers and references must not be blank. These checks establish the structure of the supplied claims, not their authenticity. The inspector cannot tell whether a reference corresponds to a genuine server log or a real receipt. Connecting it to an authoritative event store, with appropriate access control, remains the responsibility of the application using it.
Explore the implementation
Independent example core source
/** Read-only interpretation of explicitly supplied evidence. No network or persistence. */
export function inspect(record) {
if (!record || typeof record !== 'object' || Array.isArray(record)) throw Error('record');
const {id, version, evidence} = record;
if (typeof id !== 'string' || !id.trim() || !Number.isSafeInteger(version) || version < 1 || !Array.isArray(evidence)) throw Error('identity/version/evidence');
const kinds = ['saved', 'confirmed', 'sent', 'received'];
const seen = new Map();
const unique = [];
for (const item of evidence) {
if (!item || !kinds.includes(item.kind) || typeof item.ref !== 'string' || !item.ref.trim() || !Number.isSafeInteger(item.version) || item.version < 1 || item.version > version) throw Error('invalid evidence');
const previous = seen.get(item.ref);
if (previous && (previous.kind !== item.kind || previous.version !== item.version)) throw Error('conflicting evidence reference');
if (!previous) { seen.set(item.ref, item); unique.push(item); }
}
const facts = kinds.map(kind => {
const refs = unique.filter(e => e.kind === kind);
const current = refs.filter(e => e.version === version);
return {kind, state: current.length ? 'current' : refs.length ? 'earlier-version' : 'no-evidence', references: refs.map(e => e.ref)};
});
return {id, version, facts, scope: 'Provided evidence only; no business event, payment or external delivery verified.'};
}
Use the same reading function in the page and CLI
The example below reads synthetic input and presents current-version, earlier-version or no-evidence for each kind. Editing and inspecting it does not save a record, confirm a document or send anything. The downloadable command-line entry uses the same interpretation function and prints JSON. This small arrangement illustrates how a different presentation can reuse one meaning instead of duplicating business decisions in another screen.
After extracting the package, run node cli.mjs example.json in its folder. The included Node tests cover duplicate and conflicting references, earlier-version sending, future versions, invalid versions and input preservation. Twelve synthetic tests passed. Inline JavaScript syntax and exact publication are separate from browser interaction. This publication does not claim that the embedded controls, a physical phone or the original operating ERP were exercised in a browser.
Define the integration boundary before using it for work
An owner-facing view may show an explanation and review time rather than expose private reference identifiers. Authorized staff can receive links to the original evidence and the action still needed for a particular version. The module itself does not verify delivery, payment or external transmission. A current-version label describes the supplied evidence, and must not be advertised as proof that an outside process has completed.
Before integration, establish who creates evidence, how versions advance, how corrections are retained and who may read references. Include cases where a request loses its response and where a revised document has only an older sending record. The package contains no original company code, ledger, account or endpoint. What is shared is a small implementation for preserving distinctions, rather than a complete business engine. Extend it with the consuming service's authoritative checks and retention rules before relying on it for operational decisions.