Operate a Scout Mission
A Mission is complete only when the agreed scope has a documented outcome. The outcome may be verified application readiness, 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 readiness result. Do not approve from a screenshot or name alone when the workspace shows newer evidence.
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 |
| Validate | Data operator | Do bounded samples satisfy the required type, unit, freshness, and quality checks? | Passing validation or explicit blockers |
| Approval | Approver / deployment owner | May DFS apply the validated bindings? | Named approval and decision reason |
| Apply | Approver / deployment owner | Do the governed DFS changes match the intended scope? | Applied binding diff and audit evidence |
| Verify | Application owner | Did the application use canonical data? | Current readiness result and consumer evidence |
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;
- validations waiting for approval or application;
- applied bindings with incomplete application 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.
Validating and Applying a Match Set
The Mission workspace validates the complete set of required matches. A partial set must not pass merely because each submitted match is individually valid.
Before approval and application:
- confirm every required observation is already satisfied or has an accepted match;
- inspect the bounded-read validation result and blockers;
- compare the DFS create, update, and deactivate summary with the intended scope;
- confirm expected application impact;
- check outstanding warnings and stale evidence;
- identify the approval and recovery owners;
- record the decision reason.
If the underlying assessment changed, reload and validate again. Do not replay an old approval.
Verifying Operation
After application, the readiness result should connect the same Mission to active DFS bindings, an observable ClickHouse time window, the intended application installation, and a persisted canonical consumer 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, incomplete readiness results |
| Before every apply | Passing validation, approval, expected impact, recovery owner |
| After source or schema change | Reassess affected Missions and bindings |
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 complete required match set was validated and approved.
- Applied bindings have current application evidence or a named incident owner.