Count the code table before choosing a shorter handoff

Keep the creative record intact while comparing delivery choices

A fictional interactive exhibition uses a short sequence of four approved cue types: an introduction, a specimen view, a visitor question and a transition. The creative team has settled the sequence and wants the prototype to preserve that rhythm. A developer proposes a new compact representation and reports that its payload is smaller. The producer needs to decide whether the proposal improves the actual handoff, not whether one part of a size report looks impressive.

Write the creative requirement independently of the representation. The order and repetition of cues are intentional in this exercise. Removing repeated introduction cues would change the experience rather than demonstrate a better encoding. Keep any proposal to revise the rhythm in a separate editorial discussion, with the appropriate owner, instead of presenting a shorter story as a technical saving.

Identify the sender and receiver assumptions that make the comparison meaningful. The toy exercise states them explicitly below. For an actual project, the implementation owner should document the existing contract and the supported alternatives. A producer should not infer compatibility from a familiar filename or commission a new parsing route merely because a colleague can describe one on a whiteboard.

Agree what the claimed improvement is meant to achieve. Storage, transfer time, maintainability and compatibility are different questions. The local arithmetic addresses a limited record-size comparison. It does not establish how the exhibition application behaves, what its network will deliver or whether a visitor notices any difference. Ask for evidence matched to the benefit being proposed.

Compare the two fully specified teaching records

For this invented format, both sides already know alphabet ABCD and the symbol count. Sequence AAAAAAAABBBBCCDD has fixed codes A = 00, B = 01, C = 10, D = 11: 32 bits. Alternative codes A = 0, B = 10, C = 110, D = 111 are prefix-free: none begins another. Their payload uses 8 × 1 + 4 × 2 + 2 × 3 + 2 × 3 = 28 bits.

Transmit lengths 1, 2, 3, 3 as four 2-bit integers: header 01101111. Reconstruct canonical codes in increasing length, alphabetical within ties: start zero; increment each code, then left-shift when length increases. Decode until the known symbol count, ignoring terminal padding. Four zero padding bits make 28 + 8 + 4 = 40 bits, exceeding 32. Four repeated sequences use 112 + 8 + 0 = 120 bits versus 128.

This declared framing is not DEFLATE. Both candidates omit identical external count/alphabet costs; neither gains an uncounted advantage. Local round trips preserve the sequence. Compare complete records, not payload savings alone.

The supplied fixture constructs the record and independently reads it back to the intended cue sequence. It records the exact invented values so another reviewer can inspect the result without the exhibition software. No visitor data, live application or real control system is involved. This is evidence about the exercise, not certification of the developer’s proposed implementation.

Keep the input sequence visible in the comparison sheet. If one candidate is tested on a different set of cues, the numbers no longer answer the same question. Ask the technical owner to identify any changed assumption before announcing a winner. A fair comparison can legitimately favor different choices under different requirements, provided those requirements remain explicit.

Choose the supported handoff without rewriting the experience

For the fictional short record, retain the simpler agreed route while the owner evaluates whether a real change is justified. The proposed saving is not enough to authorize a replacement. Keep the cue sequence and its editorial approval unchanged. The technical decision should not become an excuse to remove an inconvenient pause or reduce the number of specimen views the designer intentionally selected.

A different production may have a stronger reason to investigate the alternative. Ask the developer for representative evidence from that actual use rather than extrapolating the small teaching case into a universal rule. The responsible owner should state what would justify the work, which receiving versions must remain supported and what the team would do if an older display cannot interpret the new artifact.

Consider the practical handoff to the person who maintains the exhibition. They need to know how an approved revision is identified and which application version is expected to consume it. A clever representation that only its author can explain is a maintenance concern even when its arithmetic is sound. This is an ownership and support question, separate from the numerical comparison.

If the project chooses to investigate a change, scope that as a controlled engineering task with the normal review and deployment permissions. Do not replace a working deliverable or alter the exhibition’s live behavior from this worksheet. The creative team can provide approved representative sequences while the implementation owner supplies the corresponding technical evidence.

Accept the intended sequence as well as the technical proposal

After any authorized implementation work, review the resulting experience against the approved cue sequence. Check the transition into the visitor question and the return to the next specimen, since those moments express the intended pacing. A successful technical import does not prove that the creative experience remains coherent. The final review should include both the implementation owner and the person responsible for the exhibition’s story.

Record the selected handoff route, the approved creative revision and the evidence that still limits the conclusion. Avoid summarizing the exercise as compression is good or compression is bad. Its useful outcome is a specific decision made with the complete comparison and the receiving agreement in view. A later, materially different sequence deserves its own assessment.

Keep the teaching fixture available for future discussions, but do not substitute it for project-specific acceptance. It can help a new producer ask what was counted and what the receiver assumes. The final artifact remains the approved experience, not a percentage detached from its scope. No actual exhibition file is uploaded, replaced or executed through this lesson.

Make the reasoning concrete.

A developer presents a payload saving for a short approved cue record. The producer has not yet seen the complete representation or receiving agreement.

Retain the agreed route for the fictional short record and separate any future investigation from creative approval.

Take the questions into your next brief.

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

1. Sequence

   Which order and repetitions are editorially intentional?

2. Comparison

   Are both candidates evaluated against the same complete input?

3. Assumptions

   What does each receiving route already know?

4. Benefit

   Which claimed improvement has matching evidence?

5. Support

   Who accepts compatibility and maintenance before a real change?

Watch for the wrong conclusion.

• Changing the creative sequence while calling the result an encoding improvement.
• Approving a size headline without its assumptions.
• Using a teaching fixture as proof that a live exhibition remains correct.

Sources & scope

Original fictional exhibit, sequence and framing. Sources support prefix-code interpretation and canonical reconstruction; this is not a DEFLATE implementation. Only local invented record encoding and decoding were executed.

• Stanford CS 106B: Huffman Coding →Primary university teaching notes · Supports: Prefix decoding and encoding-information overhead.
• RFC 1951, section 3.2.2 →Primary format specification · Supports: Canonical code reconstruction from ordered lengths.