The options changed. Can old responses take on a new meaning?

A weekday answer does not tell you which time of day

Imagine an online preference poll for a fictional book club. Existing members can submit one final response each; response editing and offline collection are outside scope. The original question offers Weekday, Weekend and Not sure. An organizer asks to split Weekday into daytime and evening, while showing the old results in the new chart.

Adding an option looks small until you inspect the eight existing weekday answers. None says daytime or evening. Renaming their stored choice to Weekday evening would add a meaning those respondents never supplied. I would separate the request into changing the question and interpreting historical responses before designing the results screen.

The table is a synthetic acceptance fixture, not collected research. Each version has twenty completed responses from different members; drafts and failed submissions are excluded. Weekday means the whole Monday–Friday range in both versions. For this fixture, daytime and evening divide that range without overlap. These assumptions must be checked before reusing the example.

Check stored identity separately from displayed wording

KoboToolbox documentation distinguishes choice names from displayed labels. It describes how changed labels can be applied to previously collected values, and warns that changing the meaning of values can undermine interpretation. That example makes the current screen insufficient evidence. The immutable-release policy below is a separate choice for this fictional poll, not a claim about KoboToolbox.

Request the previous question, stored choice definitions, one exported response and the report formula. Check whether choices are stored by position and whether changing a label changes an old export. Record how the wording originally shown to a respondent can be retrieved, rather than keeping only the current label in the specification.

Overwriting the existing choice is a small implementation but loses its former meaning. Starting a separate poll isolates data but breaks the continuity of this one question. I would keep releases under the same poll and separate version-specific results from an explicitly mapped common-category view. The extra reporting and mapping work belongs in the proposal as a cost.

You can group answers without inventing finer answers

A published release is an immutable bundle of question text, options and translations. Even a typo correction creates another release. An item whose meaning is verified unchanged may retain its identity; splitting a choice creates new question and choice items instead of reusing an old item for a new meaning.

Show detailed results by release. In the new release, daytime is 4/20=20% and evening is 6/20=30%. Do not divide the eight earlier weekday answers between them or represent their missing detail as zero. Detail that was never asked is different from the explicit Not sure choice, and both are different from an unfinished draft.

A common weekday view requires a reviewed mapping of meanings. Here it combines eight old weekday answers, four new daytime answers and six new evening answers:18/40=45%. Add eighteen weekend and four Not sure answers to reconcile forty. The old and new groups are different people in different periods; a40% to50% weekday share does not establish an effect of editing the question.

Do not silently accept an old page as a new form

Someone can leave the earlier question open while another member sees the new release. This example accepts new submissions only against the current release. The server checks current release, option membership, required values, current member access and any completed response together with atomic storage of the response and retry record. Send the receipt after commit; a delivery failure does not undo the completed response. A browser-only version check leaves a race between the check and publication.

Reject a stale new submission without saving it. Load the changed question and ask for a new selection; preserve only other answers whose item and meaning are unchanged. A typo-only release still requires the member to review the update and resubmit, although equivalent answers can remain selected. If the new form fails to load, preserve the old input and never announce receipt.

Before treating a request as new, look up an identical prior operation. Return the original receipt within current access rules without another response or count. Reject different content under the same request key. A new key also cannot bypass one completed response per member. Serialize release publication and response storage: an old write that finishes first retains its release; publication that wins first makes the old new submission stale.

The results screen must not rewrite what people said

Do not emphasize a new time-of-day chart while hiding its version. Make release-specific detail the default and offer a separate common-category view. Place the included periods, releases and completed-response denominator near the title. Without a justified mapping, the combined view should remain unavailable.

Removing an option must not remove it from historical results. Store the response relationship to the release, question and choice, and resolve its wording from that release. Keep translations in the same release so different languages do not present different meanings. Export original wording separately from the mapped category, with the mapping revision.

These are fixed interface examples, not live submission tests. Give designers the input that remains and the question requiring another choice after each notice. Give engineers the corresponding condition in the same terms. A polished message cannot repair a response already saved under the wrong question.

Ask AI to identify lost meaning, not fill the gaps

A list of current options invites a neat rewrite. Supply the before-and-after questions, synthetic counts, release-preservation rule and one-response-per-member scope instead. Delegate missing-condition review and arithmetic checks. Do not delegate invented distributions of historical answers or estimates of research impact.

Inspect three things first: did it turn eight unspecific weekday answers into daytime and evening; use forty as the denominator for new detailed categories; or silently accept a stale page against a new release? Reject the affected lines and name the missing constraint in the revision request. Fluent wording is not approval of a new policy.

The prompt below is an unexecuted example. In actual use, mark accepted, revised and unresolved statements beside the response and connect them to original definitions and calculations. A responsible person still needs to approve equivalence of meanings before the common-category report is exposed.

Example prompt: This single-choice book-club poll allows one completed response per existing member, with no editing or offline collection. Earlier twenty: weekday8/weekend10/not sure2. New twenty: weekday daytime4/evening6/weekend8/not sure2. Weekday means Monday–Friday in both. Do not infer old detail. Specify release-specific and common-category reports, stale submission handling, publication/write races and retries after a lost successful response. Connect conditions, messages and QA expectations. Separate new policy suggestions from fixed requirements.

Leave different decisions in the proposal and specification

The proposal explains why historical answers are not reinterpreted and what readers can learn from each view. Name the scope: single choice, existing members, one completion and online submission. The design specification defines immutable releases, response links, the atomic check/write boundary and the review-and-resubmit interaction. Copying the same paragraph into both documents is not a handoff.

The reporting definition records included completions, time range, releases, denominator and the approved common-category mapping revision. If the mapping changes, recompute under a new reporting definition without changing source responses. Retain the earlier definition so its report can be reproduced. Do not join figures produced under different definitions as one continuous series.

Assign evidence, not just job titles. Planning owns meaning equivalence; design owns change notices and unavailable-detail language; engineering owns storage boundaries. QA compares the interface, receipt and export. Operations records publication times and mapping-change reasons. Replace the roles below with named owners in the actual team.

Reconcile source responses as well as the buttons

Build fixtures with the starting states and sequences below. Testing one freshly loaded screen is insufficient. Keep an old question open, load a new one separately and include a member who already completed the poll. Verify the release on the receipt and record persisted rows as well as the results screen when integration testing the real service.

Run both publication/write orders. If storage wins, retain one response against the earlier release. If publication wins, reject a new stale submission. Replaying a previously successful request afterwards returns its old receipt; it must not create another response under the current release.

Also check textual change feedback, keyboard access to revised questions and errors, and the visibility of denominators and limitations on mobile. These expected outcomes are a handoff contract, not a claim that a real survey backend passed them. Add actual observations and evidence before marking implementation QA complete.

Adapt the handoff to your question

Replace weekdays and weekends with your actual meanings first. Overlapping choices or multiple selection require different denominator and reconciliation rules. Offline collection also needs a different acceptance policy if older responses must arrive later. Editing or deleting already completed responses is outside this example and needs an explicit extension.

Before applying it, verify historical releases are retrievable, only equivalent items retain their identity, and the old-page interaction preserves exactly the intended inputs. Where evidence is missing, keep the information marked as uncollected. A better-looking figure is not a reason to manufacture an answer.

Question change — design, reporting and QA handoff
Scope: fictional online single-choice time preference poll for existing members. One completion per member. No response editing or offline collection. No real study was conducted.
Problem: split Weekday into daytime/evening without changing the meaning of earlier answers.
Fixture: earlier twenty=weekday8/weekend10/not sure2; new twenty=daytime4/evening6/weekend8/not sure2. Different members and periods. Exclude drafts and failed submissions.
Releases: preserve questions, choices and translations in immutable releases. Even a typo creates a new release. Retain identity only for verified-equivalent items; new meaning requires new question/choice items. Never overwrite historical wording with current labels.
Reporting: release-specific detail is default. New daytime4/20=20%, evening6/20=30%. Earlier weekday8 has uncollected detail, not zero or an inferred split. Common weekday18/40=45% requires equivalent meanings and an approved map. Weekend18 plus not sure4 reconciles40. Show periods, releases, denominator and mapping revision. No causal-impact claim.
Submission: look up identical prior operations first. For new requests, atomically check current release, option membership, required values, current access and previous completion with storage. Commit the response and retry record together, then send the receipt; delivery failure does not undo storage. Enforce one completion per member across tabs and new request keys.
Stale page: save nothing. Ask members to review changed questions and select again. Preserve only other answers with unchanged meaning and item identity. Typo-only changes still require a notice and resubmission. Failed new-form loading preserves old input and never announces receipt. Revised payload uses a new request key.
Retries: identical request/payload returns the original receipt within current access, with no added count. A changed payload with the same key is a conflict. A later release never migrates a completed response.
Race: an earlier write that commits first stays in its release once. Publication that commits first rejects an old first submission. Order publication and storage at one boundary.
Export: retain response-time release, question, choice and wording. Add the common category separately. Option removal and translation edits must not erase historical values. Mapping changes create a new reporting definition; keep the earlier definition reproducible.
Owners: planning=meaning/scope/alternatives; design=change and uncollected-detail notices; engineering=atomic storage/deduplication; QA=sequence and interface/record/report comparison; operations=publication and mapping reasons.
QA: execute the fourteen starting states and sequences in the article, recording screens, receipts, aggregates and exports. The flow and fixed scenarios are proposed design behavior, not completed backend integration tests.
Before reuse: settle actual meanings, multiple selection, response editing/deletion, offline collection, retention and access. Fill in accountable owners, applied releases and actual test results.

Sources and example conditions

KoboToolbox documentation informs the distinction between displayed labels and stored choices and the risk of changed interpretation. Release, submission and reporting rules and forty responses are an independent fictional design, not a real study or integration result. AI prompts are unexecuted examples. English and Chinese localize the same Korean case.

KoboToolbox — Deploying forms for data collection

KoboToolbox — Managing option choices in XLSForm