Scout Evidence and Decisions

Scout keeps each decision connected to the exact assessment, source signal, asset attribute, decision 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 decision 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 part of a versioned, governed Mission decision set. Internal contract records preserve compatibility and audit history; users approve the complete Mission validation, not an isolated implementation object. A new assessment or source change does not rewrite an older decision.

Before approval:

• confirm every required observation is satisfied or represented by an accepted match;
• review the exact validation evidence and DFS change summary;
• resolve stale or conflicting evidence;
• confirm expected application impact;
• name the approval, application, and recovery 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

Applied does not automatically mean ready. The readiness result should show:

• 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 applied Mission, retain:

• scope and business purpose;
• source and asset owners;
• evidence source and evidence date;
• accepted and rejected reasons;
• validation evidence identity and DFS change summary;
• known limitations;
• approval, application, and recovery 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.