Scout Evidence and Decisions

Scout keeps each decision connected to the exact assessment, source signal, asset attribute, contract version, and application result used at the time.

Inputs for a Decision Review

Use the Mission scope, application requirement, source and asset identities, evidence date, provenance label, proposed change, current contract version, and expected application impact. A reviewer should stop when any of these inputs is missing or owned by an unknown party.

Start with Provenance

Every Mission states where its evidence comes from.

Evidence source	Appropriate use	Do not claim
Approved customer source	The approved customer scope and acceptance activity	Acceptance beyond the reviewed source, equipment, or time range
Demonstration source	Product demonstration, training, and workflow rehearsal	Real customer performance or production quality
Engineering test source	Automated integration and release testing	Customer acceptance
Not yet verified	Investigation and ownership assignment	Readiness, approval, or production confidence

Changing a label does not change where the data came from. If provenance is uncertain, stop at investigation until the source owner confirms it.

Read Statuses Correctly

• Partial means some evidence exists, but the requirement is not complete.
• Unknown means the current evidence cannot support a conclusion.
• Ambiguous means more than one plausible source or asset remains.
• Unavailable means a required source cannot currently be read.
• Stale means the assessment no longer reflects the current definition or source.
• Zero is a real value only when a result record exists and the application definition allows zero.

Never turn missing, offline, or unknown data into zero. When coverage is incomplete, show both the available count and the missing denominator.

A Good Binding Decision

Accept a proposal only when the reviewer can answer all of these:

1. Which application requirement is being satisfied?
2. Which governed source signal is used?
3. Which asset and attribute receive the signal?
4. Do meaning, unit, channel, and equipment position agree?
5. Is the source current enough for the use case?
6. Who owns the source and asset definition?
7. What evidence supports the decision?

The decision reason should be understandable without opening a database or reading implementation code.

Version and Approval Rules

Each accepted match becomes a versioned governed data binding contract. A new assessment or source change does not rewrite an older decision.

Before approval:

• review the exact contract version and change summary;
• resolve stale or conflicting evidence;
• confirm expected application impact;
• name the release and rollback owners;
• record the approval reason.

If a record changes during review, reload it and review the new version. Do not reuse an approval intended for an older version.

Runtime Evidence

Published does not automatically mean working. Runtime Evidence should show:

• the published contract version;
• the active data binding;
• a readable observation window;
• the intended application installation;
• a consumption record;
• the application result and evidence time.

A healthy status means these checks reconcile for the stated Mission and evidence source. It does not broaden customer acceptance or improve the provenance of the original data.

Review Record

For every approved or published version, retain:

• scope and business purpose;
• source and asset owners;
• evidence source and evidence date;
• accepted and rejected reasons;
• exact contract version;
• known limitations;
• approval, release, and rollback owners;
• the runtime result or the reason it is unavailable.

These records allow a new reviewer to understand what was decided and whether the conclusion is still current.