The Most Dangerous Message Is “Success”

Software problems come in two kinds. Some announce themselves: an error appears, work stops, someone fixes it. The dangerous kind is quiet — an action that did not complete, reported to the user as if it had. In everyday software, that costs you a lost photo. In regulated software, it costs you data integrity, and data integrity is the whole job.

DnXT is built on a principle we state plainly: in GxP work, a false success is worse than a visible failure. A visible failure interrupts work. A false success corrupts the record while everyone believes it is intact — and the gap between belief and reality is exactly what 21 CFR Part 11 and the ALCOA+ principles exist to close.

Three Places Silence Hides

Silent failures cluster in predictable places in any regulatory system. These are the three we design hardest against, and the ones worth probing in any platform you evaluate.

1. Notifications

When a system tells a user “reviewers have been notified”, people act on it: they wait for responses, they plan around a review that is supposedly under way. If the email was actually refused somewhere along the way and the system said “sent” anyway, every decision made after that rests on something that never happened.

In DnXT, “sent” means sent. A delivery that fails comes back to the person who triggered it as a clear message they have to deal with, not a line in a log nobody reads.

2. Search

Search is the regulatory team’s memory. If a search returns nothing, a reviewer reasonably concludes the document or commitment does not exist. So the worst search failure is not an error message — it is an empty result that should not be empty.

DnXT will not replace a working search index with a new one unless the new one is plausibly complete when checked against the old. A rebuild that comes out implausibly empty stops and raises an alert, rather than quietly erasing what people can find.

3. Validation reports

A validation report runs well over a hundred criteria per region against an eCTD sequence. Every one of them must show a verdict. A criterion that shows no result at all can look, on the page, exactly like a check nobody chose to run — and a reader can take that report as clean.

DnXT enforces a simple rule: every selected criterion produces exactly one result, pass or fail. If a check cannot reach a verdict, that becomes an explicit failure with the reason attached. A validation report never contains silence where a verdict belongs. (For background on what these criteria check, see our guide to eCTD validation rules.)

Rules That Prevent the Whole Category

Fixing individual cases does not stop the next one. Rules do. Ours come down to five:

  • Every action reports what really happened. Nothing reports success on behalf of an action it did not confirm.
  • No error is swallowed. A problem is either handled properly or shown to a person — never recorded somewhere and ignored.
  • Every check gives one verdict. Validation and health checks turn silence into a failure.
  • Replacing live information requires proof. Anything that replaces data people rely on — search indexes, settings, cached views — must show the replacement is plausible first.
  • When in doubt, stop and tell someone. In GxP work, availability can be negotiated. Integrity cannot.

Where possible these rules are built into the system itself rather than left as conventions. The one-verdict rule, for example, is not a guideline each check is trusted to follow; every check runs inside it. Conventions fade. Structure persists.

Why This Is a Compliance Question

ALCOA+ requires records to be accurate and complete. A system that reports success for actions that failed produces records that are neither — at scale, and invisibly. Auditors increasingly know this: error handling, monitoring and failure behaviour now come up in vendor qualification audits, and rightly so. The audit trail of a system that hides failures is a well-formatted account of events that did not happen.

There is also a trust question. The first time a user discovers the system said “sent” when nothing went, they start keeping their own spreadsheet — and private spreadsheets are where data integrity goes to die. Software earns the right to be the single source of truth by telling the truth when the truth is a failure.

What to Ask a Vendor

  • “If a notification fails to send, what does the user see?”
  • “What guarantees that a validation report shows a result for every check that ran?”
  • “Which actions in your platform replace live data, and what checks come first?”
  • “Show me what happens when something goes wrong in the middle of an operation.”

Good answers are specific. Weak ones are confident and vague.

Talk to Us

We build DnXT on the assumption that it will be the system of record for decisions that end up in front of health authorities — so it has to tell the truth, including when the truth is a failure. If that is what you want from a regulatory platform, talk to a regulatory expert. Bring your hardest questions about what happens when things go wrong.