Forty percent of researchers still name data quality as their single biggest barrier. That’s from the 2025 GRIT Insights Practice Report, the same year most quant ops teams already run AI somewhere in their stack. So, the number hasn’t moved because the checks got worse.
Most of what breaks a study never happens in the data at all. It happens earlier, in the gap between a finished questionnaire and the survey script built from it.
Survey script QA is supposed to close it: verify that what got programmed matches what got designed, before a single respondent opens the link. But in practice, it’s the step many workflows treat as a formality.QA quality gets influenced by people skills and time and budget to perform the task properly. That’s why the errors that survive it keep looking the same from study to study.
Where the Script Drifts From Spec
A questionnaire moves through several transactions before it becomes a live link. Design intent becomes routing notes. Routing notes become platform logic. Platform logic becomes a script someone tests under a deadline and budget. Total Survey Error, the model researchers have relied on for decades to map where quality breaks down, treats this kind of processing error as structurally distinct from sampling or response error. Nobody made a bad call. A written spec and a live script are two different objects, and nothing forces them to stay identical as one gets rebuilt from the other.
That drift tends to show up in the same handful of places: a question type that’s off, a step out of sequence, wording that no longer matches the source document. None of it needs a careless programmer. It needs a moving spec, a deadline, and a review built to catch one or two of these problems, not all seven at once.
Why the Reviewer Usually Catches Half of It
Most QA today is one person with a checklist, running it once, under the same time and budget pressure that created the drift in the first place. ESOMAR’s own Congress discussions on data quality this year kept circling back to the same point. Teams increasingly track rejection and reconciliation rates, because those are the numbers that surface after the fact. Far fewer teams have a comparable number for what a script missed before field. That check has never been standardized the way sampling and fraud detection have.
What Survey Script QA Covers
We built QAReady’s automation check set from real programming and QA runs. We built it into the platform for a few specific reasons, not just one:
- To catch all potential issues at once, not the one or two a reviewer has time for under a deadline.
- To hold the same standard every time, regardless of who’s running the check or how many other projects they’re juggling that week.
- To give script-level QA a formal benchmark, the kind sampling and fraud detection already have, and this stage of the workflow never did.
- To perform fully automated QA across the entire spec and script with every round of changes — something budget and time constraints do not allow to be done manually.
- To perform QA on edge cases — again, something restricted by budget and time.
A script-level QA pass that holds a study to its spec runs all of the following, every time, not as separate ad hoc reviews:
- Questions and question type: every question in the source questionnaire exists in the script, using the correct question type.
- Question order: the script follows the sequence the questionnaire specifies.
- Survey text: wording and answer options match the source document exactly.
- Question properties: randomization, exclusivity, and other settings are configured the way the questionnaire calls for.
- Survey logic: filtration, routing, and terminations match the document branch by branch.
- Quotas: quota structures and quota-linked logic are set up and functioning correctly.
- Code syntax: the script’s code is valid and will execute without errors.
That’s the check set CodexMR built QAReady around: reading the script against the source document, flagging anything that doesn’t match. Teams can define and save their own checks on top of these seven, so the list grows with whatever a given account has seen go wrong before.
On Your Call, Not Running the Show
Open the app and start the checks, navigating additions through the chat. No queue. It remembers every detail of that pass. It won’t skip a step unless you tell it to, and it’ll run checks beyond the standard seven whenever you ask for them.
That matters more than it sounds like it should for a QA tool. A programmer or PM running the check themselves, with the rigor of a full review, isn’t waiting on someone else’s calendar or a chain of emails to confirm a build is clean.
Trackers Are Where Small Drift Compounds
A single survey code has one spec to drift from. A tracker or copy-over study has every previous wave as a second reference too. Small inconsistencies between waves are much harder for a reviewer to catch than a mismatch against one questionnaire. QAReady compares wave to wave, copy to copy, and questionnaire file to script and back, flagging anything that changed between rounds before the new wave goes to field.
That’s not a minor use case. Research software itself is growing faster than the rest of the industry, over 11% a year against roughly 5% for traditional fieldwork, because multi-country and tracker work makes up a growing share of that volume. More waves and more markets means more places for a small mismatch to survive unnoticed, and fewer people who were still on the last wave to catch it by memory.
Standalone or Inside the CodexMR Platform
QAReady runs both ways. Either way it checks a build your team programmed anywhere, on any platform, entirely outside the CodexMR workflow. Run it inside the platform, and it’s part of the QA step instead of a final scramble before field. The checks themselves don’t change between the two.
Worth stating: QAReady flags what doesn’t match the source document. It doesn’t decide the fix, and it isn’t a substitute for the team’s own sign-off on a study before it fields. What it removes is the inconsistency of a manual pass done differently depending on who’s running it, and how much time is left on the clock. That’s the same standard CodexMR runs across the platform, near-zero delivery errors, applied as many times as a team wants to run it. Not once, under pressure, and hoped for.
The 40% figure from GRIT won’t move just because more AI gets added somewhere upstream of QA. It moves when the check between spec and script stops depending on who’s available and how close the deadline is.
