Count the observations inside the interview before counting interviews

Define what one repeated instance represents

Write the unit in concrete terms: one distinct task performed during the reference period, one tool used for that task or one reported incident. These units are not interchangeable. Explain when a collector should add another instance and when details belong inside the existing one. Avoid a vague label such as item if it allows the same event to be entered repeatedly under different descriptions.

Define whether zero observations is a valid outcome and how it differs from an unfinished interview. Decide what makes an instance complete enough for the study’s intended use. A blank instance created accidentally should not silently become an observed event. Keep the parent interview total, instance total and answered-item total separate in the acceptance plan so each can be checked against the synthetic fixture.

Test instance counts separately from answer counts

ODK’s repeat guidance distinguishes counting repeat instances from counting how often a particular answer occurs. It also describes ways to limit repetitions. These support separate acceptance checks; a count of instances is not automatically a count of complete or qualifying observations.

Create fixtures with no observations, one observation and several observations with differing answers. Record the expected instance count and any answer-specific summary before running the form. Include a partially entered instance where the study permits it, and verify how the interface and output represent that state. Do not derive the expected result from the same calculation being tested; use the fixture’s stated facts as the independent reference.

Exercise changes to the roster during collection

Have an authorized tester add an instance, correct an earlier entry and remove an accidental instance through the supported test workflow. Observe the resulting roster and summaries rather than assuming how a product handles the change. If the instrument uses a declared count to create entries, change that count in a synthetic case and inspect what remains. Do not claim that a reduced count necessarily deletes data unless the deployed behavior establishes it.

Check that the collector can still tell which observation each visible entry describes. This is an interface acceptance question, not permission to collect personal identifiers. Use nonpersonal task labels in fixtures. If an implementation silently leaves extra entries or loses required details, record the discrepancy for the form owner. Do not compensate by telling analysts to subtract a fixed number from every submitted total.

Accept the resulting record structure and summaries

Inspect the actual delivered test output alongside the completed form. Confirm the parent interview count, the number of repeated observations and the subset with each relevant answer. Trace discrepancies back to the fixture before blaming a downstream calculation. A summary can look plausible while an unintended blank instance or duplicated observation changes its meaning.

Give collectors a short instruction defining when to add another observation and analysts a scoped explanation of the repeated unit. Keep this specific to collection behavior rather than expanding it into a generic data dictionary. Reopen the check when repeat limits, required fields or summary logic change. The accepted outcome is a faithful representation of the observations reported within each interview, not a guarantee that the sample is representative or that repeated observations are statistically independent.

Make the reasoning concrete.

A fictional study asks office coordinators to list approval steps in a recent purchasing process. A tester enters three steps, accidentally adds a fourth empty entry and sees the form’s summary report four observations.

The researcher chooses cardinality reconciliation and keeps the interview count separate from both roster size and completed observations.

Take the questions into your next brief.

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

1. Unit

   What exactly does one repeated instance represent?

2. Zero

   How is no observation distinguished from unfinished entry?

3. Counts

   What are the expected parent, instance and answer-specific totals?

4. Changes

   What happens when an instance or declared count is changed in a fixture?

5. Output

   Does the delivered structure preserve the intended observations?

Watch for the wrong conclusion.

• Counting every interface instance as a complete observation.
• Using a form calculation as its own independent test oracle.
• Treating repeated observations as independent interviews.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis. Sources support only specifically attributed principles. Platform guidance can change; legal requirements depend on jurisdiction and context. No measured results or named human reviewer are claimed.

• ODK Docs: Repeat Recipes and Tips →Primary form-authoring documentation · Supports: Supports the distinction between repeat-instance counts and answer-specific counts. The cardinality acceptance workflow is original analysis.