Test the replacement rule before promising fewer reloads

Keep the visitor sequence separate from the storage proposal

A fictional museum presentation revisits five media items during a guided explanation. The repeated visits are intentional: the presenter introduces a process, compares examples and returns to the opening object after explaining a limitation. A supplier proposes a larger local store and describes the upgrade as a guarantee of fewer reloads. The producer is tempted to accept the promise without asking how the receiving system chooses what to retain.

Write down the intended presentation sequence before discussing the proposed upgrade. A sequence that returns to an earlier example can serve a different educational purpose from a sequence that shows every item once. Do not change the visitor story merely to make an incomplete technical promise look plausible. If the editorial owner wants a shorter or differently ordered experience, that should be evaluated as its own decision.

Ask the supplier to identify the actual receiving component and its supported behavior. A browser, a media application and a local file store can have different contracts even when a proposal calls all of them a cache. The small model below is not a diagnosis of any particular product. It makes the missing policy question concrete before the team spends effort on a production change.

Keep the proposed resource change, the desired visitor experience and the evidence request in separate lines of the brief. That allows the supplier to challenge an assumption without appearing to reject the creative goal. The task is to demonstrate that the offered change supports this presentation, not to collect a more impressive capacity number.

Reproduce the complete trace under explicit rules

Use the textbook request sequence 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5, starting empty with equal-size slots. On a miss, insert the item, evicting only when full. FIFO evicts the earliest insertion; hits do not refresh it. LRU evicts the least recently requested item; hits refresh recency.

With 3 slots, FIFO hits at requests 8, 9, 12: 9 misses. With 4 slots, FIFO hits at 5, 6: 10 misses. LRU has 10 misses with 3 slots and 8 with 4. Thus more capacity worsens FIFO here, and LRU is not always better than FIFO. These counts do not establish elapsed time, bandwidth, browser behavior or offline availability.

The local fixture records every request, retained set and eviction. A separate implementation stores event timestamps instead of maintaining the ordered queue and reproduces the outcomes. Only this synthetic model was executed. No application configuration, network connection or museum device was tested.

Keep the first request and initial state in the comparison. Starting one candidate after a rehearsal while starting another from an empty state would change the question. The receiving owner needs to explain the setup for the actual test, and the producer should be able to identify which conditions differ between proposals. A complete trace is more useful than a summary that cannot be reconstructed.

Record the result as a comparison of named alternatives. Do not turn the exercise into a permanent preference for whichever option has the best count in this one example. The useful finding is that the promise needs its operating rule and workload, not that every installation should receive the same configuration.

Request evidence for the offered change without editing away the story

Give the supplier the approved presentation order and ask for a controlled comparison of its actual supported alternatives. Include the intended startup condition and the media versions used in the test. The supplier should identify what was observed, what was simulated and which result belongs to which candidate. A demonstration that silently rearranges the sequence does not answer the original brief.

Keep the final return to the opening object in the acceptance scenario because it carries the explanation’s qualification. If the proposed system cannot support the agreed experience, ask for the available delivery choices and their practical consequences. The team may choose a different supported arrangement, revise the scope or seek another production proposal. Each choice should be visible rather than disguised as a simple storage increase.

Have the editorial owner evaluate any suggested sequence change for meaning. Moving the limitation to the beginning may alter what the audience notices; removing the revisit may leave the example unresolved. The technical owner can explain delivery constraints, but should not have to decide which part of the museum story is expendable. Conversely, the editor should not prescribe an undocumented technical setting from a teaching calculation.

Keep purchasing and implementation outside this exercise. A tested proposal still needs the project’s normal approval and authorized change process. The coordinator’s deliverable is a precise comparison request and a clear record of the selected option, not an instruction to replace equipment or alter production software.

Close the handoff with the tested experience and the remaining limits

When the supplier returns evidence, check that it concerns the same sequence, media set and receiving route described in the brief. Review the actual user experience under the agreed test conditions rather than treating the synthetic arithmetic as a completed rehearsal. If the delivered configuration differs from the proposal, ask which relevant checks must be repeated.

Record the accepted experience in language the next producer can use. Identify the complete presentation, its intended start condition, the tested delivery option and any limitation that affects planning. A later update that adds another revisit or substitutes a larger media file should not inherit an unexplained approval from the earlier version.

Close with the specific promise that the evidence supports. The museum may have a suitable tested delivery plan, or it may still need a revised proposal. Either outcome is more useful than an unsupported assurance that more storage solves every loading problem. The lesson preserves the visitor journey while making the technical comparison accountable.

Make the reasoning concrete.

A supplier promises that extra storage will reduce reloads while the guided presentation intentionally revisits earlier media.

Preserve the complete story and require a policy-specific comparison before treating the upgrade as an established solution.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Journey

   Which revisits contribute to the visitor’s understanding?

2. Receiver

   What actual component owns the proposed storage behavior?

3. Rule

   Which replacement and initial-state assumptions define each candidate?

4. Evidence

   Was the approved sequence tested without silent rearrangement?

5. Closure

   What exact delivery promise and limitations were accepted?

Watch for the wrong conclusion.

• Treating a larger capacity label as a performance result.
• Reordering the story to hide an untested delivery assumption.
• Comparing candidates that start in different unexplained states.

Sources & scope

Original fictional museum decision. The textbook supplies the policy concepts and reference sequence; local queue and timestamp implementations reproduce the counts. No real system or network was tested.

• Operating Systems: Three Easy Pieces, Beyond Physical Memory: Policies →Primary textbook chapter · Supports: FIFO, LRU and capacity anomaly.