Fieldwork data acceptance workshop / 6 MIN READ
Verify the instrument version actually used in the field
Publishing a corrected form does not prove every collector is using it.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-07
An instrument rollout is accepted when the intended definition and supporting assets are demonstrated on the collection route that will use them. Preserve the difference between a tested draft, a published release and the version attached to collected evidence. Resolve older work deliberately instead of assuming publication rewrites history.
What you will leave with: A release-and-receipt matrix linking the approved instrument package, collection clients and submissions to their actual versions.
Use this when
- A field instrument is corrected during data collection.
- Several collection devices receive a new form and reference assets.
This concerns executable instrument distribution, not statistical comparability between survey waves or generic session rehearsal. ODK Central behavior is scoped to documentation checked on 7 November 2026. Only authorized owners publish or change access; this lesson grants no such permission.
Define the complete release unit
Identify the form definition, version label and supporting assets needed for the collection task. These may include approved prompt images or reference lists. State what changed and which questions or routes it affects. A filename alone is an unreliable release identifier when several people can replace a file without changing its name.
Separate the operational repair from its research implications. Correcting a broken choice list may restore the intended instrument; changing question meaning may require a comparability decision from the researcher. Record both decisions without using technical acceptance to imply that earlier and later responses are equivalent. The rollout artifact should tell the field team which package is approved and tell analysis staff which evidence was collected under each version.
Preserve test evidence before the publication boundary
ODK Central separates draft testing from publication and clears draft test submissions when a draft is published or replaced. It also requires a changed form version for clients to recognize an update. These facts support retaining the approved test evidence and an explicit release identity.
Use synthetic adult business-task records to exercise the changed paths and inspect the resulting data. Save the permitted acceptance evidence outside disposable test results through the project’s approved process. Include asset-dependent questions, not only the first screen. Have the owner confirm that the release package matches the tested one. Do not create credentials, distribute configuration codes or alter access merely to complete the checklist; those actions remain separately authorized.
Verify receipt at the collection boundary
Ask the authorized field operations owner to demonstrate the intended version on representative collecting clients and record the evidence. Include a client that has been disconnected if that is part of normal fieldwork. The test should establish what is actually available for new collection after the approved refresh process, without assuming every device updates at the same instant.
Inventory older work already in progress and have the research and system owners decide how it should be handled. Do not silently convert it, discard it or force collectors to re-enter responses into a newer instrument. Document the approved treatment and any unresolved device. If a collector cannot obtain the required version, provide the agreed pause or escalation instruction rather than encouraging them to improvise the changed questions on an old form.
Connect the rollout evidence to the analysis handover
Check that received evidence can be associated with the instrument version used, using the approved metadata or release record. Inspect the changed fields in a representative extract. A current form view can hide an earlier collection condition, so preserve the release history and the analyst’s extraction scope. Ask the system owner to explain any removed or renamed fields before assuming their absence means nobody answered them.
Close the rollout only for clients and collection states actually verified. List remaining exceptions and their owners. When another repair is necessary, repeat the affected acceptance checks rather than extending an earlier signoff to a new package. The outcome is a documented deployment boundary, not a claim that every response after a calendar date used the same instrument or that mixed-version data can be pooled without methodological review.
Make the reasoning concrete.
A fictional operations-research team repairs a task-category list in its field form. The new package is published, but a disconnected tablet still offers the prior list and has an interview draft already in progress.
Use the publication time as the boundary
Opening: Assume all later interviews use the repair and instruct the collector to finish as usual.
Hypothesis: The release log is easy to summarize.
Risk: The device and existing draft may not match that assumption.
Verify client receipt and older work
Opening: Have the authorized owner check the tablet’s available version and obtain a decision on the existing draft.
Hypothesis: The rollout record reflects actual collection conditions.
Risk: The researcher may need to keep mixed-version evidence distinguishable.
The team chooses the verified rollout and gives analysis staff the actual version boundary rather than a convenient publication timestamp.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Package
Which definition, version and supporting assets form the release?
Test
Where is the approved synthetic-path evidence retained?
Receipt
Which collecting clients demonstrated the intended version?
Older work
What is the authorized treatment of in-progress older records?
Analysis
How will received records retain their collection-version context?
Watch for the wrong conclusion.
- Treating publication as simultaneous device receipt.
- Losing the only test evidence when a draft is replaced.
- Using a technical repair signoff as proof of measurement comparability.
Your next action
Choose one proposed instrument repair and map its tested package, client receipt evidence and treatment of existing work before release.
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: Managing Forms in Central →Primary form-management documentation · Supports: Supports draft-test separation and version-change requirements in Central. The release acceptance matrix is original analysis.