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 |
| Contract cannot be approved | Resolve stale evidence, warnings, or missing approval role. | Approver |
| Publication fails | Check the governed binding service and release ownership. | DFS/release 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 release 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.
- Approval and publication are recorded.
- Runtime Evidence identifies either a verified 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.
- Release, rollback, 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.