Scout Troubleshooting and Go-Live
Troubleshoot from the beginning of the customer journey. Fix the first incomplete stage before retrying later steps.
Symptom, Action, Owner
| Symptom | First action | Owner |
|---|---|---|
| Scout is not in the menu | Confirm DFS Pro, Scout, and the user's role are active. | Tenant administrator |
| A direct page is denied | Confirm the signed-in tenant and action permission. | Tenant administrator |
| Mission cannot be created | Check the application requirement, scope, and owner. | Mission/application owner |
| Readiness assessment is unavailable | Check scope access, source availability, and unresolved policy blocks. | Platform/data owner |
| Expected equipment is absent | Confirm the selected scope and asset definitions. | Asset owner |
| A requirement is unknown or ambiguous | Clarify signal meaning, asset identity, and ownership. | Data steward |
| Proposal cannot be submitted | Check that source signal, asset attribute, and current assessment still match. | Data operator |
| Reviewer sees a version conflict | Reload the proposal and review the latest version. | Reviewer |
| Validation cannot pass | Resolve incomplete required matches, stale evidence, unreadable samples, or quality blockers. | Data operator |
| Approval is unavailable | Confirm a current passing validation and the approval permission. | Approver |
| Applying bindings fails | Check the governed DFS diff, drift blockers, and deployment ownership. | DFS/deployment owner |
| No time-series observations | Check source availability, tenant routing, and time range. | Data operations |
| No application result | Check the application installation, consumption record, and processing run. | Application owner |
Recovery Principles
- Do not change provenance labels to pass a review.
- Do not treat missing, offline, or unknown data as zero.
- Do not bypass the product workflow with direct database updates.
- Keep previous assessments and decisions as review history.
- Refresh an assessment only after a meaningful source, asset, or requirement change.
- Record the first failing stage, affected scope, evidence time, and owner.
Before Go-Live
Access
- DFS Pro and Scout are enabled for the customer tenant.
- Viewer, operator, reviewer, approver, and deployment responsibilities are assigned.
- Users without access are denied.
Data and Application
- The first customer scope and source owner are approved.
- Asset and signal identities are stable and understandable.
- Units and business meaning have been reviewed.
- Time-series service ownership and availability are confirmed.
- The target application requirement and installation are current.
Workflow
- One representative Mission has completed the supported journey.
- Missing and uncertain items have named owners.
- Binding decisions contain review reasons.
- Validation, approval, and DFS application are recorded.
- The readiness result identifies either a canonical consumer result or a clear incomplete stage.
Handover
- Daily and weekly review owners are named.
- Escalation contacts exist for access, source, asset model, time series, application, and Scout.
- Application recovery, backup, and disablement responsibilities are recorded.
- Known limitations and unverified customer-source areas are visible to the customer team.
Inputs for Support Review
When escalating, include the tenant, Mission, affected equipment scope, page and action, evidence time, visible reason, and request trace ID if available. Do not attach customer payloads unless the customer's approved support process requires them.