If the evidence is missing or outside its contract, the report should change state before it changes someone’s decision.
01 / SOURCE CONTRACT
Define what makes each source usable.
Start with authority: who owns the source, which access method is permitted, what may be collected, and how it may be retained. Then define the technical trust contract.
| Dimension | Contract question | Failure evidence |
|---|---|---|
| Freshness | How old may the source be for this decision? | Observed timestamp, expected threshold, and collection time. |
| Completeness | Which records or fields must be present? | Expected versus observed coverage and missing identifiers. |
| Schema | Which fields, types, and meanings are required? | Contract version and the exact structural mismatch. |
| Availability | What response proves collection succeeded? | Status, timeout, error class, and attempt history. |
| Authority | Is this source and method approved for the intended use? | Configured source record and approval boundary. |
A collection job returning HTTP success is not enough if the payload is stale, empty, incomplete, or incompatible with the expected meaning.
02 / TRUST STATES
Make trust a first-class output.
Instead of a binary report/no-report flag, use states that change how claims are presented and delivered.
- 01Trusted
Critical sources satisfy freshness, completeness, schema, availability, and authority contracts.
- 02Degraded
The report may contain bounded information, but a non-critical source or coverage dimension failed and must be disclosed.
- 03Unavailable
A critical contract failed, so current aggregate claims are withheld rather than inferred from old or partial data.
The exact state names can differ. What matters is that downstream consumers cannot confuse a degraded or unavailable run with a fully supported report.
03 / NO CHANGE VS NO DATA
A zero is meaningful only after collection succeeds.
“No material change” means the required sources were collected, validated, compared, and produced no change under the defined rule. “No data” means the workflow lacks enough trusted evidence to make that statement.
Source versions and timestamps, successful validation, comparison baseline, materiality rule, observed differences, and a clear report state.
Do not silently carry forward the previous value and label it current. If a last-known value is useful for context, label its timestamp and degraded status explicitly.
04 / CLAIM WITHHOLDING
Suppress unsupported claims—not the evidence of failure.
When a critical contract breaks, stop the material aggregate or recommendation that depends on it. Still produce an operational record showing which source failed, what remains trusted, when the failure began, and who owns recovery.
- Identify which claims depend on each source.
- Mark critical versus optional inputs explicitly.
- Prevent partial inputs from silently entering a full aggregate.
- Expose the reason and age of degraded information.
- Keep delivery disabled or clearly qualified according to the accepted policy.
- Record recovery and the first restored trusted run.
05 / LINEAGE
Let a reader trace a claim back to its source state.
For each material result, retain source identifiers, collection time, contract version, normalization version, comparison baseline, validation state, and the transformations that produced the claim. Use safe references instead of copying unnecessary sensitive data.
A trustworthy report explains both what changed and why the system believes the evidence was fit to compare.
06 / REVIEW CHECKLIST
Before delivering a recurring report.
- Is every source and collection method authorized?
- Does each critical source have freshness, completeness, schema, and availability rules?
- Can the output distinguish trusted, degraded, and unavailable states?
- Is valid no change proven by a successful collection and comparison?
- Are stale last-known values timestamped and labelled?
- Are source dependencies recorded for each material claim?
- Does a critical failure withhold unsupported aggregates?
- Can an operator trace, recover, and confirm the first restored trusted run?
INSPECTABLE REFERENCE
Signal Brief
A verified portfolio build covering five trust scenarios, eight passing tests, source evidence, valid no change, degradation, critical report withholding, and zero external deliveries. It uses synthetic fixtures and is not client work.