Audit trail
Delphi studies are read closely by journal reviewers, ethics boards, replication teams and the study team itself. Delphi Studio keeps two tamper-evident records for this: an audit log of governed actions, and a decision log for each study's review decisions. Both are hash-chained. Recording an event is not the same as covering every action at the same level of detail.
The audit records that something governed happened, and who did it, for the events it stores. It does not replace the study team's own account of events outside the platform, such as a guideline published between rounds or an outage. Record those in the study's own notes and methods text. What freezes, and which later changes are amendments, is the governed study record.
What each record holds
| Record | Written by | What it holds |
|---|---|---|
| Audit log | The platform, when it records one | Governed events such as a Setup save, launch, a team change, a panel or consent event, a message, a round move, a result, coding, a decision, an export, or completion. Not every screen action is one of these. |
| Decision log | The platform, when a decision is confirmed | Each study's review decisions, rule and escalated disposition confirmations, overrides of the rules, comment-sharing choices and structural gate decisions |
Why it matters
| Reader | Question it answers |
|---|---|
| Journal reviewer | Which rules were stored with a results version, and were those the rules the file reports? |
| Ethics board | Who opened a panelist's identity, when, and for what stated reason? |
| Replication team | Which results version, under which rules, does each published classification come from? |
| Study team | Who changed a statement, a threshold or a disposition, and why? |
Hash chain
The audit log is one chain per organization. Each entry holds its sequence number, the time, the action, the actor, the target and a payload, together with the hash of the entry before it and its own hash. The hashing scheme is versioned, so older entries keep verifying if it changes.
Append-only triggers reject an update, a delete, or a truncate of the audit log and of the decision log. A database owner can remove those triggers. The chain can show that an earlier entry no longer matches. It is tamper-evident. It is not a guarantee that nothing outside those triggers can change the tables.
Checking the chain detects a problem. It does not stop the study.
On the study audit page, a failed check says The audit chain does not verify. The page still lists the rows. Download CSV does not run the check again, so the study audit file still downloads. The organization file still downloads from Download as CSV. Its chain result is sent with the file as the header x-audit-chain, with the value verified or broken. That result is not a row inside the CSV. The settings page can also say that the chain check failed, and it still lists its rows.
The decision log is a separate chain. A failed check of that log is not the audit-chain warning. Calculated round results can still be shown. The last round's final-result line is hidden. Study result is not shown, and the study-result file is refused. The consensus file is refused. The participation file and the responses file are not refused because of that failure.
Whether a broken chain should refuse the page and the downloads is an open product question. This page does not close it.
Written in the same transaction
Where a governed change and its audit entry are written in one database transaction, a change that is refused for a validation error or a stale version leaves no success entry behind. Refusals that matter, such as a denied identity reveal or a refused export, are recorded as refusals. That pairing is not a claim that every screen action is stored.
What an entry may contain
Each kind of entry has a fixed shape, and anything outside it is refused before the write. An entry holds ids, counts, versions, hashes, states and choices, before-and-after values for a change, and a written reason where a person had to give one.
The stored study-audit payload does not hold a panelist name, an email address, an answer, a comment, or a message body. An email address typed into a reason is replaced with "[email removed]". The study audit page can still show a team member's name in Done by. The study audit CSV does not. It uses an opaque member reference, not a name and not a pseudonym. The organization audit download can contain a staff display name. Panelist ids in the study audit detail are shown as pseudonyms. Whether names and research records stay fully separate is an open product question.
What gets logged
The study audit page groups entries the same way the filter does. These labels are the filter. They are not a promise that every rating, revision, approval, and export is stored with the same detail:
| Group | Examples |
|---|---|
| Setup and consent | A Setup section saved, statements imported, a consent version published, the study launched |
| Rounds and decisions | A round approved, opened, extended or closed; results computed or superseded; comments coded and adjudicated; review decisions; a decision confirmed; a further round added |
| Panel | People added or imported, eligibility assessed, conflicts disclosed, consent recorded, enrolment, withdrawal and removal, identity reveals requested, approved, denied or made |
| Invitations and messages | Invitations queued, resent or expired; wording saved or marked approved; a pause, resume or emergency shutdown; suppressions |
| Participant actions | An invitation accepted or declined, consent given or declined, answers saved or submitted, a withdrawal, a request to remove answers |
| Team | Members added or removed, roles changed, a principal investigator replaced |
| Completion and retention | The study completed or archived, deletion requested, decided and carried out |
| Exports and reports | Study-report downloads, a refused study-report download, and the study audit download. Not every file the product can download is in this group. |
Saved and submitted answers are logged as counts (how many statements were answered), never the ratings themselves. The ratings live only in the study's response records.
Workspace settings and membership changes are recorded in the same organization log. Personal preferences are not.
What is frozen, and when
| Point | What is fixed |
|---|---|
| Launch | What freezes, and which later changes are amendments, is the governed study record. This table does not repeat that list. |
| Consent publication | A published consent version's wording is never edited or withdrawn. That sentence is about the published row, not every consent-draft field. |
| Round approval | The principal investigator's approval is bound to the round's content, its rules, the consent version and the schedule; any relevant change makes it stale |
| Round opening | The round's content (with its hash) and the round's panel |
| Submission | Each submission records the content hash it answered |
| Results | Each results version is sealed with the rule set it was computed under; a correction is a new version with a reason |
| Decision | The confirmed decision plan, sealed in the decision log |
An amendment never re-judges a round that has already been rated. Not every later change is an amendment. The scale cannot be amended.
Exports
| File | Who | What it contains |
|---|---|---|
| Study audit CSV | The principal investigator | One row per entry: entry number, time (UTC), event, action, an opaque member reference, detail, and the entry's hash. Up to 20,000 rows. The button is Download CSV. The download is itself audited, and it still proceeds when the chain does not verify. |
| Organization audit CSV | An administrator, or a member given audit access | Organization-level rows, such as workspace settings and membership, not every study event. A staff display name can appear. The button is Download as CSV. The chain result is the x-audit-chain header, verified or broken, not a row in the file. The download still proceeds when the chain is broken. |
| Consensus, participation, and responses | Roles that can read results | Named on Reporting. This table is not that file list. |
See Reporting for the result files.
Identity access
Panelist names and email addresses are stored separately from answers and results. From enrolment on, the panelist record shows a pseudonym until a reveal is approved. Revealing a name takes a reason of 30 to 500 characters and is audited, including a refusal. A coordinator can request a reveal. A principal investigator or an administrator approves it. The requester cannot approve their own. The audit stores the id, not the name.
What the audit does not include
- A log of rating values. Ratings are kept in the response records, not copied into the audit.
- A researcher-written event log. Note outside events in your own study records and methods text.
- A JSONL audit export or a bundled reproducibility archive. The audit leaves as the CSV files above.
- An export of the decision log on its own. Its outcomes appear in the consensus file and on the Decision stage.
For an ethics closeout
A closeout often draws on these records. Reporting is the file list. This table is not a second inventory:
| Item | Where it comes from |
|---|---|
| Study audit | Study audit CSV |
| Consent versions | The study's published consent versions |
| Participation and withdrawals | Participation CSV |
| Results and decisions | Consensus CSV |
| What the study did and found, as counts | Study summary from Reporting |
Next steps
- Reporting: the result files
- Roles and access: who can reveal identities and read the audit
- Completion and retention: what stays open after completion
- Governed study record