Here is a problem that comes up constantly in regulated software and almost never gets discussed honestly.
A regulation permits something. It permits it on conditions. And at least one of those conditions is a fact your software has no way of knowing.
The specific case
PMDA’s eCTD 4.0 rules permit reusing a document that was filed under a different application — you reference the existing document rather than filing it again. This is genuinely useful: the same quality content legitimately supports several applications, and re-filing it creates duplication that helps nobody.
It is permitted on three conditions. And one of them is whether the source application has been approved.
No publishing tool can verify that. Approval status lives in the authority’s own review system. It is not in your submission, and it is not something a vendor can look up. The other two conditions need the source application’s own filing — which, for an application filed by a partner or a company you acquired, you may have no reason to hold at all.
Three tempting answers, all wrong
Allow it quietly. The tool publishes whatever gets assembled and says nothing. The rule is then enforced by whoever remembers it, which in practice means it is enforced when the submission is rejected.
Refuse it outright. Defensible while nothing can confirm the conditions, and not a resting place. A blanket refusal blocks a filing the regulation explicitly allows, and “our software will not let us do the thing PMDA permits” is a real cost that pushes work back into manual assembly.
Ask for a single confirmation tick-box. Superficially reasonable, and the worst of the three. One box labelled “I confirm this reuse is permitted” collapses three distinct regulatory facts into one gesture, and invites confirming all three when only one was actually checked.
The applicant confirms, and the software holds them to it
DnXT takes the fourth option: publishing checks for a formal confirmation from the applicant. Refuse unless confirmed, and refuse unless the confirmation is complete.
The three conditions are recorded as three separate facts, not one flag. That is not bureaucratic thoroughness. They are three different claims about a filing, an auditor may need to know which one was relied on, and a confirmation that cannot tell them apart cannot answer the question an inspector will actually ask.
Each is recorded with who confirmed it and when, because this is a GxP record. It is a person taking responsibility for a regulatory claim, and the record has to name the person.
An unconfirmed condition is not a weaker claim
This is the part worth getting right, and it is where most implementations quietly go wrong.
A condition nobody has positively confirmed is not “less documented”. It is a statement that one of the regulation’s conditions was not met — which makes the reuse impermissible, not merely under-evidenced.
So only a clear yes counts. Blank does not. “No” does not. “Pending” does not. A stray value left behind in a half-finished form does not.
Failing the other way — treating anything that is not an explicit “no” as acceptable — would let an incomplete form stand as a regulatory claim. That is far worse than an over-strict check, because the over-strict check produces a complaint and the permissive one produces a filing nobody can defend.
And every missing piece is reported at once. Publishing does not stop at the first gap, make you fix it, then stop at the second. A process that reveals one problem per attempt wastes an afternoon and teaches people to work around the tool.
Where the record lives — and where it deliberately does not
The confirmation is stored in the platform alongside the dossier it belongs to.
It is deliberately not written into the submission itself. Adding a non-standard element to an eCTD 4.0 submission breaks the format rules — you would be attaching your compliance evidence to the filing in a way that makes the filing invalid. This is a record about the submission, held by the sponsor, produced on request. That is what it should be.
The same principle, applied twice
A related rule concerns re-ordered content, where a submission that changes the order of its contents must declare that it has done so.
Building that into our publisher would have been pointless: the rule only applies to a shape our publisher never produces, so the declaration would be handling a case we never create. But DnXT also checks submissions it did not produce, and there the shape does occur — so it ships as a validation check instead, with the finding naming the sequence the previous value came from.
The general principle: a rule you cannot break is not a rule to build into the thing that writes. Build it where you can actually encounter it, which is usually the checker, on somebody else’s submission.
Why this matters beyond eCTD 4.0
Every regulated software product hits this eventually. A regulation permits something conditionally; some conditions can be verified and some cannot; and the vendor has to decide what to do about the gap.
The answer that holds up: verify what you can, require an explicit human confirmation for what you cannot, record each condition separately, treat silence as failure, and never write your compliance evidence into the thing you are filing.
It is worth asking a prospective vendor which of the four options above their product takes. The answer tells you a great deal about how the rest of it is built.
DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see eCTD 4.0 publishing and validation against your own submissions.
