Six Questions Your REDCap Project Can Suddenly Answer

Ask a team what changed about their REDCap work after putting a project under governance, and the honest answer is: nothing. They still design instruments in REDCap. They still enroll participants, still branch, still export. Nobody handed over an API token, and nothing outside the team ever writes to the instance.

What changes is not the workflow. It is the set of questions that now have an answer instead of an opinion. Here are six, in the order they usually come up.

"Has the dictionary moved since we last looked?"

Before: somebody says "I don't think so," and everyone decides to believe it — or an afternoon disappears into two spreadsheets.

After: the current dictionary goes through the audit verb, read-only, in seconds. Back comes a count of errors, warnings, and informational findings; a map of which finding codes fired and how often; the list of drifted objects by name; and a fingerprint of the exact file that was checked, so the answer is attached to a version rather than to a memory. There is a markdown report in the same response, written to be pasted into a review.

For the ambient version of the question, there is a status badge — an SVG served from the latest recorded run that renders green when it was clean, yellow for warnings only, red for errors, and gray when nothing has been recorded. "We have not checked" and "we checked and it was fine" stop looking alike.

"What would this amendment break?"

Before: make the edits in a draft project, push to production, find out downstream.

After: the revised dictionary is audited before anything ships. New fields come back as coverage findings — present in the artifact, not yet governed — which is exactly right, because adopting them into the model is a decision somebody should make on purpose. A changed choice list comes back as drift, naming the instrument and the field and saying whether the value set narrowed or widened. A relaxed validation comes back as type drift, with the governed type and the artifact type side by side.

That is a different meeting. Instead of "something broke in the export," it is "retiring that choice orphans the participants already coded with it — do we want that?", asked on the day the amendment is drafted, by the people who can decide.

"Which fields carry PHI?"

Before: re-read the Identifier? column of a several-hundred-row spreadsheet, every time a data-sharing request arrives.

After: the audit's phi-fields finding reports it per instrument, by name — this instrument carries these three identifier fields — with the blunt instruction to inventory them before any export or agent access. The inventory is assembled from the same file you already had; it just stops being scattered across four hundred rows.

"Is the new site collecting the same form?"

Before: compare exports at harmonization time and reconstruct what each site was actually doing.

After: a site's dictionary is audited against the governed model the week it is stood up. Same engine, same codes, same report. Deviations surface as coverage and drift findings while they are still cheap to fix, and the two REDCap hygiene rules run over their file as well: free-text fields with no validation type get flagged, and a choice list that reuses a code gets a warning before it starts collecting ambiguous data.

"The model changed — is the estate still fine?"

Before: no mechanism at all. The question was rarely even asked in that direction.

After: the import stored a snapshot of the parsed dictionary, so the question inverts cleanly. The re-audit verb replays that stored estate against the current governed model — no fresh export, no chasing a coordinator for a download, no artifacts in the request body at all. When a governance meeting tightens a definition, one call says what that decision implies for the last known state of the project. Re-audit runs are always recorded to the rolling history, because a check triggered by a governance decision is precisely what a history exists to remember.

That history is the compounding part. Runs accumulate with their timestamps, their trigger, and their counts, so "are we drifting?" becomes a series anyone with viewer access can read rather than an anecdote from whoever looked last.

"Can the next study start from what we already decided?"

Before: copy last year's dictionary and prune it by hand, inheriting every accumulated quirk including the ones you spent this year discovering.

After: the generate verb runs the loop backwards and emits coremodels_data_dictionary.csv — an upload-ready data dictionary with the full eighteen-column REDCap header. Governed taxonomies come back as dropdowns with minted codes, not-null checks come back as Required Field? = y, and governed types come back as validation types (integer, number, date_ymd) or, for booleans, the yesno field type. A human reviews that file and uploads it, because CoreModels does not write to your REDCap instance. It is a scaffold built from what your organization has agreed things mean, and it is honest about its limits: a governed reference between instruments has no column in the dictionary format, so it comes back as plain text rather than being invented.

What the after-state actually feels like

Less dramatic than it sounds, and better. There is no new system to keep in sync, because the input is a file the team already produces. There is no daemon inside the instance, because there is no live connection. There is no ceremony, because the audit is read-only and takes seconds.

What there is, is a project whose meaning is written down somewhere a machine can check it, a report that turns "something feels off" into a named field and a stable code, a trail that survives the person who remembers, and — for teams that keep dictionaries in version control — a gate that can fail a build when a change violates governed meaning before it reaches production.

The study is the same study. The difference is that on any given Tuesday, six expensive questions now cost one call each.

The calls behind all six — import, audit, re-audit, history, badge, generate — are in the REDCap quickstart in the CoreModels integration docs.