Get Started with FactVerse Scout

This guide walks through a first Mission using a small, well-understood equipment scope. Do not begin with an entire enterprise or plant.

Before You Begin

Confirm the following with your team:

• the application or use case you want to enable;
• a named Mission owner and data owner;
• a site, system, or equipment group small enough to review;
• an application requirement set published by the application owner;
• access to the relevant source and asset definitions;
• the real provenance of the data you will use;
• a reviewer and release owner.

Your tenant administrator must also enable DFS Pro and Scout and give you the appropriate role.

Inputs and Owners

Bring the approved application requirement, selected equipment scope, source and asset ownership, known signal definitions, and the agreed provenance label into the first review. If any input has no accountable owner, record that as the first action instead of creating a broad Mission.

Example Outcome

A reliability team wants to use bearing vibration for pump health analysis. At the end of the Mission, the team should be able to show:

• which pumps were reviewed;
• which vibration requirement was satisfied or missing;
• which source signal was matched to each asset attribute;
• who approved the match and why;
• whether the health application consumed the approved signal.

1. Open Scout

Open Data Integration > DFS Pro > FactVerse Scout and select New Mission.

If Scout is not visible, ask the tenant administrator to check Administration. A copied direct link does not bypass access controls.

2. Define the Mission

Use a name that describes the business outcome, such as Pump vibration readiness - Plant A.

Provide:

Field	Customer guidance
Owner	Person accountable for the result and follow-up
Application requirement	The approved requirement version supplied by the application owner
Scope	The selected site, system, equipment, or asset type
Purpose	The decision this Mission must support
Evidence source	Customer source, demonstration source, or not yet verified

Review the summary before creating the Mission. The scope should be understandable to someone who did not configure the source system.

3. Review Readiness

The Mission page shows the current status, coverage, blockers, evidence date, and recommended next action.

Check the following before continuing:

1. The selected equipment and application requirement are correct.
2. The data provenance label matches reality.
3. The coverage count includes the assets you expected.
4. Missing and uncertain items are not shown as numeric zero.
5. Each blocker has an owner or a clear next action.

Refresh the assessment only after a source, asset definition, or requirement has materially changed. Previous assessments remain part of the review history.

4. Investigate a Gap

Open Coverage and select a missing, partial, uncertain, or blocked item.

Ask:

• Is the required asset attribute defined?
• Does the source contain a signal for it?
• Do the signal meaning, unit, channel, and equipment position agree?
• Is the source active and current enough for the application?
• Is business or source-owner approval required?

Some gaps should be resolved outside Scout, for example by granting source access or correcting an asset definition. Record the owner instead of forcing a match.

5. Propose and Review a Match

In Binding Workbench, select the governed source signal and target asset attribute. Add a short reason that another reviewer can understand.

The reviewer should accept only when identity, meaning, unit, provenance, and ownership are clear. Rejection is a valid outcome: it prevents an uncertain match from reaching an application and keeps the reason available for follow-up.

6. Approve and Publish

An accepted proposal creates a versioned governed data binding contract. The release flow is:

Draft -> Review -> Approved -> Published

Use the review stage to confirm the source, asset, attribute, expected effect, and rollback owner. Approval and publication require the corresponding roles.

7. Confirm the Application Is Using the Data

Open Runtime Evidence after publication. Confirm that the page shows:

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

An empty result means the application result has not been verified. It must not be interpreted as a value of zero.

Validation Checklist

• Scope and owner are clear.
• Coverage includes the expected equipment.
• Every unresolved item has an owner.
• Accepted matches contain an understandable reason.
• The contract was reviewed and approved.
• Runtime Evidence identifies the application result.
• The provenance label still matches the actual source.

Continue with Operate a Mission for regular team handoffs.