AI NDA Authoring Software: A Source-Consistency Pilot

AI NDA authoring software should earn its place by preserving the relationship between an approved source and every document that uses it. A fluent clinical summary is only one output. Your pilot also needs to show what happens when two studies use the same table caption, an approved report changes, or an expected analysis is unavailable.

Here, NDA means an FDA New Drug Application. This guide gives medical-writing and regulatory-operations teams a small, repeatable documentary exercise for comparing candidates. It includes the source excerpts, requested outputs, acceptance checks, and a completed fictional review.

Publisher disclosure: Assyro sells regulatory software. The packet and results below are synthetic; we have not run a vendor benchmark with them. These checks are proposed purchasing criteria, not claims that Assyro or another product has passed.

Decide what the NDA pilot must prove

Choose one bounded task: can the team release consistent, traceable excerpts from selected study records, then update them without hiding unresolved dependencies? A pass supports a decision to continue evaluation. It does not qualify every workflow, establish scientific adequacy, or make an NDA ready to file.

For this pilot, keep the numerical task intentionally simple. Do not pool patients, infer treatment effects, or generate safety conclusions. The existing clinical-summary authoring guide provides a separate exercise for populations and data cutoffs. This exercise tests which study supplied a statement and where that statement travels across the NDA writing set.

Before starting, record the candidate product and build, the participating writer and reviewer, and the agreed workflow. If a person manually creates citations or finds affected documents, record that assistance. Manual work is not automatically disqualifying; concealing it prevents a useful comparison.

Keep two decisions separate:

• Authoring acceptance: Did the candidate perform the agreed checks and expose uncertainty?
• Packet readiness: Do the supplied records support releasing the requested content?

A tool can correctly identify that the packet is incomplete. That is useful authoring behavior, even though the release remains on hold.

Copy the reusable source packet

Use the following text as the entire input for the exercise. Save each source record separately if the candidate accepts files, or supply the records in its supported input format. Retain the identifiers exactly. Page and table references below are fictional locators inside this miniature packet; no external study reports are needed.

This is a document-checking fixture, not a clinical dataset, complete CSR, or executable eCTD submission. The approval labels are stipulated exercise facts, not evidence that a product implements an approval system.

Release R1: the two approved sources

Source S101-v1 excerpt: “Study NDA-101: 112 participants were screened and 100 were randomized. Data cutoff: 2026-06-30.”

Source S202-v3 excerpt: “Study NDA-202: 96 participants were screened and 80 were randomized. Data cutoff: 2026-06-30.”

The shared caption is deliberate. “Table 5.1, Study disposition” cannot uniquely identify either source. A usable reference must also identify the study and report version. For a broader evaluation of that evidence trail, see the source-traceability checklist.

The source-to-consumer register

Ask for three small outputs using R1. These are exercise excerpts representing separate writing destinations, not complete CTD documents.

The register has three consumers for each source: OV-01, CS-01, and CT-01. It is the evaluator's expected impact list. Do not assume a candidate has a dependency graph merely because it can generate the three outputs.

The separate NDA readiness register

Supply these two records with R1. For this exercise, the regulatory lead has designated both full integrated analyses as required before the packet's release gate.

Do not ask the software to write either analysis from the two disposition excerpts. The correct behavior is to retain the missing-evidence state and route it to the responsible owner.

Why include this register? FDA's April 2009 final guidance distinguishes the detailed ISE and ISS from abbreviated Module 2 summaries. It describes the common error of assuming that clinical summaries alone satisfy the integrated-analysis requirement, recommends placement in Module 5, and discusses exceptions. Your regulatory lead must determine the application-specific content and placement plan; a summary heading or a “final” cover sheet does not establish that the planned analysis has been reviewed. See FDA guidance, sections I and III.

Run the correction and distractor rounds

First save the R1 outputs and their source register. Then introduce the following records in sequence. Do not give the later versions to the candidate during the initial round.

Round 2: an approved correction

Provide this complete replacement record:

Source S202-v4: Study NDA-202; clinical study report version 4; approved for R2; data cutoff 2026-06-30; page 24, Table 5.1, “Study disposition.” Screened: 96. Randomized: 78.

Correction notice C202-01: “For the R2 exercise, S202-v4 supersedes S202-v3. The approved randomized count is corrected from 80 to 78. The screened count and cutoff are unchanged. This notice supplies no explanation of clinical significance.”

Ask the candidate to identify every affected output, propose the changes, and produce R2 using its agreed review workflow. Whether updates are automatic or manually approved, the reviewer must be able to verify what changed and why.

Expected impact: NDA-202 changes to 78 in OV-01, CS-01, and CT-01, and its citations change to S202-v4. NDA-101 remains unchanged. The saved R1 record still shows 80 with S202-v3; it must remain distinguishable from R2.

Round 3: a newer but unapproved draft

Now supply:

Source S202-v5: Study NDA-202; clinical study report version 5; working draft, not approved for R2; uploaded after S202-v4; data cutoff 2026-06-30; page 24, Table 5.1, “Study disposition.” Screened: 96. Randomized: 82.

Ask which record controls R2 and why. The answer is S202-v4, under the exercise's explicit approval rule. A newer upload does not override that rule. The candidate may flag the draft for review, but it must not silently replace 78 with 82.

This checks selection behavior. It does not establish that every organization's approval controls work; use a separate version-control evaluation for permissions, approval authority, and change history.

Score the observations before discussing a purchase

Copy this scorecard into your evaluation record. For each row add the candidate/build, input release, evidence locator, observed result, owner, and next action. A screen recording, retained export, or inspectable source reference is more useful than an unrecorded assurance.

Use Pass for demonstrated behavior, Fail for a demonstrated contradiction, Unknown when the required evidence was not inspected, and Not applicable only for an explicitly excluded task with an owner-approved reason. Do not average away a mandatory failure with unrelated passes.

For this exercise, A1–A9 are mandatory. An unknown requires evidence before acceptance, not a provisional pass. A product with manual impact tracking can still be evaluated, but record the labor and handoff requirement. Use the AI medical-writing evaluation guide if you also need a timing and review-effort comparison.

Reusable observation record: Check ID; candidate/build; input release; observation; evidence locator; Pass/Fail/Unknown/Not applicable; reviewer; owner; next action; retest date. For Not applicable, add the agreed exclusion and approving owner.

Worked fictional review: a correct number can still fail

Imagine a fictional candidate produces this R1 table row:

The visible count matches S202-v3. The reference does not. A1 fails because S101-v1 describes another study and reports 100 randomized participants. Correcting the sentence is unnecessary; correcting and rechecking its provenance is necessary. A reviewer who only compares the count will miss this defect.

Next, imagine the candidate updates OV-01 and CS-01 to 78 after receiving S202-v4, but leaves CT-01 at 80. It correctly excludes the unapproved v5. The resulting review would look like this:

Checks A2, A5, and A9 remain Unknown in this abbreviated fictional observation set. No overall acceptance has been earned. The IA-S contents also remain unknown; that uncertainty is different from A8, which passes because the candidate represents it accurately.

The expected correction

After the writer repairs the observed defects, the reviewer should expect the following R2 output values:

CS-01 and CT-01 must also retain screened counts of 112 and 96, and CT-01 must retain both 2026-06-30 cutoffs. Each NDA-101 reference remains S101-v1, page 18, Table 5.1. These are expected answers derived directly from the fixture, not measured vendor results.

A proposed repair is not a retest. Reopen the references, inspect the saved releases, and have the second reviewer attempt the handoff before changing any remaining unknown to pass.

Boundary cases that change the decision

A source lacks identifying metadata. Supply an extra excerpt containing only “Table 5.1, Study disposition: 80 randomized,” with no source ID, study ID, version, or file association. The candidate must ask for source identity or mark it unresolved. Matching a familiar count does not establish provenance.

The approved correction lacks approval evidence in your real workflow. The fictional packet stipulates approval. A real deployment must establish it through the agreed process. Until that evidence is available, keep the revision decision unresolved and name the owner who can resolve it.

The vendor offers authoring only. eCTD package generation may be Not applicable to this bounded pilot if the regulatory-operations owner agrees to a separate publisher. Record that dependency. It does not make source accuracy or the handoff check optional.

A generated summary looks complete, but an analysis is absent. Keep the deliverable on hold. The software may pass A8 by reporting the gap correctly; the regulatory lead still needs the planned evidence before releasing that packet.

Confirm format fit, then bring the packet to a demo

Treat submission-format eligibility as a separate purchasing gate. FDA currently lists v3.2.2 and v4.0 as supported versions, but says v4.0 is available for new applications and forward compatibility is not yet available. Changing an authoring tool does not, by itself, establish a migration path for an existing application. Check the current FDA eCTD notice against your filing plan.

For an Assyro evaluation, FDA eCTD v4.0 is supported; v3.2.2 is not currently supported. If v3.2.2 publishing is a mandatory purchase requirement, that is a fit limitation. Start with the regulatory-writing product overview, then confirm which NDA documents and review steps are available in the current product. The worked behaviors in this article remain acceptance questions to demonstrate, not promised capabilities.

Book an Assyro demo with the two source records, the three-output register, and the correction rounds above. Ask the team to agree on the supported scope and show how it would retain the evidence for A1–A9. Leave with an observed result, named owners for unknowns, and a clear decision on whether a larger NDA pilot is justified.