How to answer a dynamic model deficiency letter without starting over
Most deficiency comments are not asking for a better fit. They are asking where a number came from. Sorting the letter by that question is what turns three review cycles into one.
Sort the letter before you answer it. Most comments fall into four kinds, and only one of them is asking for a better model. The rest are asking where a number came from, what version produced it, or why the file behaves differently than the narrative. Answering each kind in its own currency is what closes the loop in one cycle instead of three.
Why deficiency cycles repeat
A deficiency cycle is expensive in a specific way: the building is already standing. It earns nothing while the model clears review, so every additional round has a carrying cost that has nothing to do with engineering effort.
Cycles repeat for a mundane reason. A comment asks a provenance question, the team hears a modeling question, and the response is a new parameter set. The new set has exactly the same problem as the old one: nobody can say where the numbers came from. The reviewer asks again, in firmer language, and a second cycle is gone.
The second letter is usually the first letter, rephrased because the answer missed the question.
Classify every comment before answering any
Before writing a single response, go through the letter and tag each item. Do this even when the letter is short, because the tags determine who does the work and what artifact closes it.
Resist the urge to start with the easy formatting items. They are satisfying and fast, and they are also the ones that will still be easy next week. The evidence items are the ones with lead time, and lead time is the whole game.
The four kinds of comment
| Kind | What it sounds like | What actually closes it |
|---|---|---|
| Format and import | The file errors on import, a record is malformed, the version is wrong | A regenerated artifact from the named simulator version, plus the version stated in the cover note |
| Provenance | Where did this parameter come from? What is the basis for the cease threshold? | A citation: the settings sheet, the record, the test, or an explicitly stated assumption |
| Behavior | The response does not look like the event; the reconnect ramp is implausible | Either a corrected model, or the measured record showing the behavior is real |
| Scope | This does not cover the mechanical load, the second phase, or the future build-out | A boundary statement: what the model represents, what it excludes, and why |
Only the third row is a modeling problem. The first is a build problem, the second is a records problem, and the fourth is a scoping problem. Treating all four as modeling problems is the single most common way a response fails.
Answering a provenance question properly
A provenance answer has three parts, and it is worth being mechanical about them:
- The claim. State the parameter and the value, exactly as it appears in the submitted file.
- The basis. Name the artifact: which settings sheet, which record, which test, which document revision, and its date. If the basis is an assumption, say the word assumption.
- The check. Say how someone else could verify it. A hash, a file name and a page, a reproducible command, or a held-out comparison the reviewer can look at.
The third part is what distinguishes a response a reviewer can accept from one they have to take on faith. A reviewer’s job is to sign something. Give them the thing they can point at when someone asks them why they signed it.
If regenerating an export changes a number, the provenance answer has to be regenerated with it. A response packet whose narrative describes a previous run is worse than no packet.
How to refuse well
Sometimes the honest answer is that the available records cannot support the claim being asked about. A frequency droop gain cannot be identified from a record where frequency never left nominal, no matter how clean the record looks, because a gain multiplied by zero deviation leaves no trace in the output.
A good refusal is not a shrug. It has the same three parts as any other answer:
- What cannot be supported, named as a specific parameter or behavior rather than a general disclaimer.
- Why, in terms of the record: the excitation that is absent, the sample rate that cannot resolve it, or the interval where the load was disconnected and therefore silent.
- What would fix it: the commissioning test, the additional channel, or the event class you would need to capture.
Reviewers generally accept a bounded, well-argued gap. What they cannot accept is discovering a gap themselves after approving the study around it. The identifiability results behind this, including a case where a fit reported full rank and was still badly wrong, are in the technical note.
What to send back
One packet, not a thread of emails. At minimum it should contain a comment-by-comment response table keyed to the reviewer’s own numbering, the regenerated model artifacts with the simulator version stated, the provenance record for every parameter that was questioned, the explicit list of remaining gaps with the test that would close each, and a short statement of what changed since the previous submission.
The response table matters more than it sounds. A reviewer working through a letter they wrote wants to tick items in their own order. Making them reconstruct that mapping from a narrative is how a response that contains everything still earns another cycle.
Frequently asked questions
Should we just re-fit the model to make the comment go away?
Rarely. If the comment is asking where a parameter came from, a new fit produces a new number with the same unanswered question attached. Re-fitting is the right response only when the comment identifies an actual modeling error, not a provenance gap.
Is it acceptable to tell a reviewer we cannot support a parameter?
Yes, when it is paired with what would support it. Reviewers deal with uncertainty routinely. What they cannot accept is a number with no basis presented as if it had one, because that is the thing that invalidates the study they have to sign.
How long should a deficiency response take?
The response itself is usually days of work. The delay is almost always in obtaining evidence that did not exist when the model was built, which is why the inventory of unsupported parameters belongs at the start of a project rather than after the first letter.