Completed example: SALES-01
Hypothetical example. This record is fictional. Its constraints and thresholds were chosen to make the decision concrete. They are not client results or recommended industry standards.
| Field | Record |
|---|---|
| Decision ID | SALES-01 |
| Status | Approved for limited validation; production cutover is pending until conditions are met |
| Technical owner | CTO |
| Business acceptance | Finance lead confirms the meaning of the metrics and accepts the quarterly export |
| Approved next step | Test moving only daily sales reporting to a separate reporting environment |
Problem, requirement, and scope
The diagnostic work has already established the definition of sales. However, the report calculation shares a processing window with other work and, under this example's conditions, cannot reliably meet the morning deadline. Changing the schedule or fixing the query alone would not remove this shared constraint. These are the example's starting assumptions, not measured results.
The requirement is a read-only daily sales report available by 8:00 a.m. every business day, in the agreed business time zone, containing the accepted source snapshot for the previous business day. If ingestion fails or runs late, the report must visibly show that its data is not current. It must not present yesterday's successful refresh as today's result. The 8:00 a.m. deadline is a requirement for this example, not a generally recommended threshold.
The scope includes sales transformations, the read-only dashboard, and the quarterly export for finance. The order-entry system, its writes, and the rest of the data platform remain unchanged. This decision does not authorize replacing the entire platform.
Compare three options against the same requirement
| Option | What would need to be true | What still needs attention | Comparison result |
|---|---|---|---|
| Keep it | The current path meets the requirement, and someone owns the remaining operational risk. | Provide maintenance, accept the remaining risk of failure, and set a review date. | Not selected: under the example's conditions, it cannot meet the 8:00 a.m. availability requirement. |
| Apply a targeted fix | Changing the schedule or query can remove the shared processing-window constraint. | Check whether the fix merely postpones the same constraint in the current solution. | Not selected under the stated assumptions. Remains an option if the assumption proves wrong. |
| Move one reporting workload | A separate path may meet the specific requirement and can be validated without moving the whole platform. | Document dependencies, data meaning, permissions, costs, cutover, rollback, and exactly what can be retired. | Selected for validation only. Successful production operation has not been demonstrated. |
Source and dependencies
- The order-entry system and its append-only source exports remain the authoritative source.
- Both reporting paths refresh from the same authoritative exports.
- Manual corrections and other independent business writes are prohibited in the target environment.
- The dependency inventory includes access groups, the refresh scheduler, credential management, support, and the downstream export format.
- Query logs are supplemented by the quarterly export schedule and confirmation from its owner. An absence of recorded usage during a short window does not establish that nobody needs the data.
Acceptance conditions before switching readers
Five runs and the quarter-end test are chosen conditions for this example, not universal thresholds. This record does not say the tests have passed. Their results will determine whether production cutover can proceed.
- Compare the same source snapshot, using the agreed precision for monetary amounts and the same business-day cutoff.
- Verify keys, duplicates, daily totals by sales channel, refunds, canceled orders, and late corrections.
- Include a deliberately selected period-end test. Row counts alone are insufficient.
- Have finance confirm included and excluded statuses and preservation of the quarterly export's meaning and format.
- Test access for permitted readers and denied roles. A failed refresh must be visible.
- Complete five consecutive daily refreshes by the illustrative 8:00 a.m. deadline, and successfully test representative quarter-end data.
Cutover
The data team lead presents the validation results. The CTO decides whether to approve the cutover, and the finance lead confirms the meaning of the metrics. Readers of the daily report can switch only when both paths have processed the same completed source snapshot. The record preserves its identifier and the connection versions.
Writes to the order system do not change. An unmet condition blocks cutover; it is not an exception to overlook during the switch.
Rollback to the original path
For ten business days after the actual cutover, the original reporting path continues refreshing from the same authoritative exports. A critical error in a metric, permissions, or data freshness stops publication of results. The CTO approves rollback based on the data team's verification. Readers can return only after the original path has also processed the latest accepted source snapshot, including new orders and corrections through that snapshot's cutoff. If this cannot be verified, publication remains paused.
This procedure works only because both copies are derived and the target path receives no independent business writes. If such writes are introduced, rollback is blocked until the team can transfer and reconcile them with the original path. Simply switching the connection could lose work. Rollback must be tested before production cutover.
Ten business days is an explicit assumption of this example. It does not automatically cover the next actual quarterly close and does not, by itself, authorize retiring the original path.
Running both paths and meeting the cost condition
Compare every option for the same workload, data volume, and period. Do not count original platform costs that will remain because of other jobs as savings from this move.
Record the original and target paths' operating costs, duplicate ingestion and storage, validation, support work, transfers, and eventual removal separately. Do not insert assumed savings into the decision.
The sponsor in this example requires recurring operating costs after the agreed retirement of old components to be no higher than the documented current cost of operating the same reporting workload. Running both paths temporarily needs separate approval before it starts. If the amounts are unknown, the condition is unmet and production cutover remains pending. An estimate must not be presented as a measured result.
Exact retirement scope and subsequent reviews
After the observation period, only the old daily reporting job and view may be retired, and only after the finance lead and data team accept the results, rollback has been successfully rehearsed, the dependency inventory has been verified, and definitions and recovery materials have been preserved.
The old quarterly export path stays in service until its owner accepts an actual quarterly run on the new path. A test using historical period-end data is insufficient for retirement. Shared tables stay if they still serve other work. This record does not authorize retiring the entire data warehouse.
Reopen the decision if costs exceed the approved budget, independent writes exist only in the new environment, the morning requirement is no longer met, or the remaining quarterly dependency prevents the planned retirement. The first review takes place ten business days after the actual cutover. Review the quarterly export at its next actual run.
Blank record for your decision
Complete one record for one bounded path from a source to a specific report or export. Where evidence is missing, write unverified, assign an owner, and describe what they must establish before the next decision.
A completed form is not evidence. Link to test results, the dependency inventory, approved costs, and documented approvals from the people responsible.
1. Identity and owners
- Decision ID:
- Date:
- Status:
- Technical owner:
- Person responsible for business acceptance:
2. Workload and scope
- How the business uses the result:
- Source of record:
- Path from source to report or export:
- Explicitly out of scope:
3. Known problem
- What the evidence already establishes:
- Evidence links:
- What remains unverified, and who will verify it:
4. Requirement and consequences of failure
- Observable acceptance conditions:
- What happens if they are not met:
5. Option comparison
- Common scope, data volume, and comparison period:
- Shared costs that will remain after the change:
6. Dependencies
- Inputs and their owners:
- Outputs and infrequent consumers:
- Permissions, schedulers, credential management, and support:
- Observation period and gaps in the evidence:
7. Acceptance
- Data meaning and edge cases:
- Freshness, access, performance, and operations:
- Tolerances and representative periods:
- Who accepts the conditions, and where the results are recorded:
8. Cutover
- Source snapshot or write cutoff:
- Exact change for readers:
- Exact change to systems that write data:
- Who approves cutover:
- Conditions that block cutover:
9. Rollback to the original path
- Trigger and latest permitted time:
- Supported recovery point:
- New writes, changes that exist only in the new environment, and how to transfer and reconcile them:
- Evidence of rehearsal:
- Decision owner:
10. Running both paths and costs
- Original path cost:
- Target path cost:
- Duplicated work and the people responsible for running it:
- Approved budget:
- Conditions for ending the overlap:
11. Retirement
- Exact components that can be removed:
- Remaining consumers and shared components:
- Evidence required before retirement:
- Retention and recovery obligations:
- Owner:
12. Decision and review
- Chosen next step:
- Accepted consequences:
- Date or event for the next review:
- Triggers for reopening the decision: