Can the new reader ship before the field devices?
A fictional field research team wants to update its recording software and its shared report reader.
The question
The team has 120 remote field recorders. Its release rule requires a verified report from at least 118 recorders after each change. Today Reader 1 has a verified report from all 120. Each field recorder runs Reporter 1. The release owner needs a decision by Friday.
| Count | |
|---|---|
| Older recorders | 30 |
| Newer recorders | 90 |
The shared reader receives reports from both groups.
| Reader 1 | Reader 2 | |
|---|---|---|
| Reporter 1 on older recorders | Reads | Unverified |
| Reporter 1 on newer recorders | Reads | Reads |
| Reporter 2 on either type | Rejects | Reads |
These checks use saved reports. The release rule counts verified reports from the field.
“Can this release keep enough reports readable after each change?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Map the versions
What would you do here? Open the move you’d make.
Check which pair each recorder would use after each change
The strong move. The two device types may use different report formats while the release is in progress.
Update all recorders to Reporter 2 while Reader 1 is active
Tempting, but it misses something. Reader 1 rejects the new reports from both device types.
Check only the final pair
Tempting, but it misses something. The release rule applies after each change.
See how a strong candidate says it
“List the reader and reporter pair at each stage. Reader 1 rejects Reporter 2. If we change the reader first, Reader 2 must read the reports that both device types still send.”
Why it works: The pair can change at either end. The intermediate combinations determine which reports the reader can use.
Step 2: Check the gap
What would you do here? Open the move you’d make.
Check the older report and the update window
The strong move. This establishes whether Reader 2 can serve older recorders that must keep Reporter 1.
Use the newer recorder test to clear both types
Tempting, but it misses something. The compatibility result for Reporter 1 covers the newer device type only.
Assume the team can update all older recorders before Friday
Tempting, but it misses something. The team has yet to confirm which older recorders it can reach.
See how a strong candidate says it
“Keep the current pair for now. I’d check Reader 2 with an older recorder’s existing report and confirm how many older recorders the team can update before Friday.”
Why it works: The table leaves one pairing unverified. The update count matters if that pairing fails.
Step 3: Revise the plan
Reader 2 rejects the existing report format from all 30 older recorders. Only 8 of those recorders can receive Reporter 2 before Friday.
What would you do here? Open the move you’d make.
Hold the release because Reader 2 can cover at most 98 recorders
The strong move. At least 22 recorders would have no readable report. The rule allows at most 2 unverified recorders.
Switch both sides together using the 8 available updates
Tempting, but it misses something. That still leaves 22 older recorders sending reports Reader 2 rejects.
Count an unreadable report as verified if it reaches the reader
Tempting, but it misses something. Delivery alone gives no verified report.
See how a strong candidate says it
“Before any older recorder changes, Reader 2 can read at most 90 reports. Even with all 8 updates, it can read at most 98 reports. The release requires 118. Keep the current pair.”
Why it works: The 90 newer recorders and 8 reachable older recorders give an upper bound of 98. Actual field reports could be fewer.
Step 4: Brief the owner
What would you do here? Open the move you’d make.
Keep the current pair and request proof for every intermediate stage
The strong move. The release owner can check both compatibility and actual reporting against the rule.
Ask only for a new test of Reporter 2
Tempting, but it misses something. The unresolved condition concerns the older recorders that keep Reporter 1.
Report 98 verified field reports to the owner
Tempting, but it misses something. The test establishes an upper bound on readable reports. No field change has been made.
See how a strong candidate says it
“I’d show the release owner the failed pairing and the limit of 8 older recorder updates. Keep the current pair in service. Before any new plan, test every reader and report pairing we expect in the field. Check for at least 118 verified reports after each approved change.”
Why it works: The compatibility test identifies the gap. A field report count is separate evidence for the release decision.
The answer, in short
- Decision
- Keep the current reader and reporter versions in service.
- Because
- With Reader 2, at most 98 recorders could report in a readable format. The release needs 118 verified reports after each change.
- What would change it
- A revised release plan passes the checks for every intermediate pairing and meets the field reporting rule.
Common traps
- Check the versions in use at each stage.
- Separate compatibility from verified field reports.
Check your answer
- I identified the pair at each stage.
- I asked for the missing compatibility check.
- I used the revised coverage limit.
- I told the release owner what evidence is still needed.
Last reviewed Nov 11, 2026