In a regulated environment, documentation is not a convenience for developers. It is evidence. And evidence that cannot be checked is worth less than no evidence at all, because it invites reliance it cannot support.
Most institutions running legacy COBOL do have documentation of some kind. Design notes from the original build. A wiki page someone started. A spreadsheet of file layouts maintained until its author moved teams. What they usually cannot do is demonstrate that any of it still reflects the code that runs tonight.
That gap matters most at exactly the moment it is most expensive to close. An examiner asks how a particular figure is calculated. An auditor testing IT general controls asks what a change actually changed. A migration team asks what the current system does so they can specify what the new one must do. In each case the honest answer, in many organisations, is that the knowledge lives in the head of one senior developer who is planning to retire.
Key-person dependency is itself a control weakness. When the only reliable description of a critical financial process is a person rather than an artifact, that is a finding waiting to be written, independent of whether the code is correct.
Auditors rarely ask for documentation as an end in itself. They ask questions that documentation happens to answer, and they judge the answers by whether they can be independently checked.
The specific framework varies. Financial reporting controls, payment card requirements, examination handbooks and internal model governance each phrase it differently. The underlying demand is consistent: a description of the control, and a way to verify the description.
Large language models write fluent, confident descriptions of COBOL programs. They also invent field names, reference paragraphs that do not exist, and cite copybooks that were never included. In a general engineering context that is an annoyance to be corrected. In an audited environment it is disqualifying, and for a reason that is worth stating precisely.
A single fabricated reference contaminates the whole document. An auditor who follows one citation and finds it does not exist in source has no basis for trusting the other four hundred. The rational response is to discount the entire artifact and fall back on manual review, which means the documentation cost was spent for nothing.
This is why the meaningful question about an AI documentation tool is not how good its prose is. It is what the tool does when it does not know. A system that guesses plausibly is more dangerous than one that fails loudly, because the guess is indistinguishable from the fact until someone checks.
A Program Logic Manual is the per-program document a maintenance engineer or reviewer works from. To carry evidentiary weight it has to be both readable and checkable, which means every substantive claim needs a path back to source.
What the program is for and where it sits in the wider process, stated plainly enough for a reviewer who is not a COBOL programmer.
Record layouts, field definitions and the copybook hierarchy, with the fields a reviewer will be asked about identified by name.
Inputs, outputs, databases and their access modes, so the data footprint is explicit rather than inferred.
The paths through the program and the conditions that select them, described as decisions rather than as a transcript of statements.
What the program does when an operation fails, including restart and recovery behaviour.
How the program actually runs: the job steps, the scheduling context, the operational dependencies.
A real example is published in full. The complete Program Logic Manual for CBTRN03C, the daily transaction posting batch program from the AWS CardDemo reference application, is available without a form or a conversation.
Brevidy's COBOL Documentation Factory separates the two things that generic tools conflate: establishing what is true, and writing about it.
Validated publicly on the AWS CardDemo corpus: 42 programs across 8 archetypes, 98.5 out of 100, with zero fabricated entities. The benchmark is published rather than asserted, so the claim can be checked against source code anyone can read.
Documentation vendors ask you to take accuracy on faith. These are the actual generated artifacts, open in a browser, with citations attached.
34 programs against 38 data stores. Every Create, Read, Update or Delete marker opens the paragraph and source-line cites that prove that access, which is the form an auditor can actually test.
Open the matrix → CHANGE MANAGEMENTSelect a program or data store and trace its upstream and downstream blast radius with a citation on every hop. Unresolved dynamic targets are excluded rather than guessed.
Open impact analysis → MAINTENANCE RISKUninvoked paragraphs, unreachable code after transfers, silent I/O failures and unrounded computes, each expandable to the recorded fields and source cites behind it.
Open static findings →Four situations turn documentation from a nice-to-have into the gating prerequisite, and they tend to arrive together.
This page describes what audit and examination processes commonly require of system documentation, based on how these artifacts are used in practice. It is general information about documentation practice, not legal, audit or compliance advice, and it does not interpret any specific regulation on your behalf. Your own auditors and counsel determine what satisfies your obligations.