Operate a Scout Mission
A Mission is complete only when the agreed scope has a documented outcome. The outcome may be a verified published binding, an accepted limitation, or a clearly owned blocker.
Inputs for Each Review
Review the current Mission scope, application requirement version, evidence date, source and asset owners, pending decisions, and latest runtime status. Do not make a release decision from a screenshot or name alone when the page shows a newer version.
Team Handoffs
| Stage | Primary owner | Decision | Completion evidence |
|---|---|---|---|
| Scope | Mission owner | What business outcome and equipment are included? | Approved scope and requirement version |
| Readiness | Data operator | What is ready, missing, uncertain, or blocked? | Reviewed coverage and assigned gaps |
| Match | Data operator and steward | Does this signal represent this asset attribute? | Accepted or rejected proposal with reason |
| Review | Contract reviewer | Is the proposed change safe and correct? | Reviewed contract version |
| Approval | Approver | May this version be released? | Named approval and decision reason |
| Publish | Release owner | Is the approved version ready for operation? | Published binding and rollback owner |
| Verify | Application owner | Did the application use the approved data? | Current runtime evidence and result identity |
Daily Mission Review
Start from the Mission page, not from individual source records. Review:
- current scope and evidence date;
- coverage totals and changes since the previous assessment;
- new blockers or uncertain matches;
- proposals waiting for review;
- contracts waiting for approval or publication;
- published contracts with incomplete runtime evidence.
Follow the recommended next action only after confirming that its owner and context are still correct.
Understanding Coverage
| Status | Meaning | Normal response |
|---|---|---|
| Satisfied | The requirement has acceptable evidence. | Review only when the source or requirement changes. |
| Partial | Some evidence exists, but the requirement is incomplete. | Identify the missing asset, channel, time range, or quality condition. |
| Missing | No acceptable evidence was found. | Find a governed source or assign a source-access action. |
| Blocked | A policy, approval, or prerequisite prevents progress. | Assign the accountable owner; do not bypass the control. |
| Unknown | Current evidence cannot support a conclusion. | Improve definitions or access before making a decision. |
Coverage percentages are useful only when the expected population is complete. Always review the included and omitted counts.
Reviewing a Binding Proposal
Before accepting a match, confirm:
- The source signal belongs to the intended tenant and source.
- The target asset and attribute are correct.
- Meaning, unit, channel, and equipment position agree.
- The data is current enough for the application.
- The provenance label is accurate.
- The written reason explains why the match is valid.
Reject or return the proposal when any of these points is unclear. Do not accept it merely to improve coverage.
Reviewing a Contract
The contract detail shows the exact reviewed source-to-asset relationship and its version history.
During review:
- compare the change with the previous version;
- confirm expected application impact;
- check outstanding warnings and stale evidence;
- identify the release and rollback owners;
- record the decision reason.
If the underlying assessment changed, reload and review the new version. Do not replay an old approval.
Verifying Operation
After publication, Runtime Evidence should connect the same Mission and contract to an active data binding, an observable time window, the intended application installation, and a persisted result.
Use the first incomplete stage to assign the incident:
- binding missing: DFS/data integration owner;
- observations unavailable: source or data operations owner;
- application installation missing: application owner;
- consumption or result missing: application runtime owner.
Recommended Cadence
| Cadence | Review |
|---|---|
| Daily during onboarding | New gaps, blockers, pending reviews, incomplete runtime evidence |
| Weekly in steady state | Coverage drift, stale evidence, source changes, unpublished versions |
| Before every release | Exact version, approval, expected impact, rollback owner |
| After source or schema change | Reassess affected Missions and contracts |
Close a Mission only after the completion evidence and remaining limitations are understandable to business, data, and application owners.
Review Checklist
- Scope, requirement, and evidence source are still correct.
- Every unresolved gap has an owner and next action.
- Accepted matches have understandable reasons.
- The exact contract version was reviewed and approved.
- Published contracts have current runtime evidence or a named incident owner.