Review Scout Evidence and Record Decisions

Scout brings source records, samples, model versions, business requirements and human confirmation into one task. Reviewers use the current scope to decide what each item supports and what still requires verification.

Review Inputs and Evidence

Evidence	It can support	Also verify
Field name or AI suggestion	A candidate meaning and investigation direction	Equipment, unit, location and field definition
Authorized manual or field record	Equipment definition, installation or field meaning	Current source connection and readings
Returned sample	A value existed during the sampled interval	Historical coverage, continuity and freshness
Accepted proposal	A human-reviewed content decision	Validation, application and publication status
Release receipt	The stated version or association was applied	Source readings and business-application result
Historical interval definition	The intended time range	Actual coverage and gaps

Confirm Equipment and Field Meaning

MDM identity establishes the real-world object. Brick classes describe the equipment or point type. Review the current master-data identity, equipment attributes and source records together.

New equipment commonly needs:

• asset identifier, serial number and installation location
• sensor orientation and measurement position
• acceleration, velocity, displacement or another measured quantity
• RMS, peak, sampling rate and scaling rules
• temperature-point and battery-field definitions
• unit, timezone and event time

A useful decision reason cites the evidence directly, for example: “The commissioning record identifies this device and defines channel Z as axial vibration velocity RMS; the selected source uses the same device tag and unit.”

Identify Source and Data-Processing Scope

Label customer, demonstration and engineering-test sources accurately and record the observation time. Before sending data to an external model service, confirm the permitted fields, samples and documents under the customer's data-processing policy.

Store credentials in protected configuration. Task notes and evidence references should retain only the business context and traceable source location required for review.

Record the Decision Lifecycle

1. Review supporting evidence, conflicting evidence and open questions.
2. Record confirmation, rejection or an evidence request with a reason.
3. Apply an approved model proposal to a draft, or prepare a dataset release plan.
4. Run validation or a dry run against the current version.
5. Have the approver approve the release plan.
6. Have the release operator apply it and verify the result.

When the source, model or binding version changes, validate the new version and obtain the corresponding approval. Earlier decisions remain available in the task history.

Handle Missing or Blocked Evidence

State	Meaning	Action
Missing or unknown	Available evidence cannot yet answer the question	Assign an owner and required evidence
Partial	Only part of the requirement or time range is covered	Record covered and uncovered scope
Stale	The evidence version or observation time is outside the project requirement	Obtain the current version or a new observation
Unavailable	A required source or dependency cannot currently be accessed	Record the cause and assign the responsible owner
Zero	A valid observation returned zero	Retain the value, unit and observation time
Truncated list	The current view contains only part of the result	Narrow the scope or continue through the result pages

Preserve a Usable Handover Record

A complete record contains the task scope, source and time boundary, equipment identity, field definitions, decision reason, approver and operator, effective version, actual observation result, and remaining questions with owners.