Offline Documentation Generation for Classified Software Projects

Documentation is usually the part of a classified software project that quietly loses. Not because engineers don't value it, but because the tools that make documentation fast, hosted assistants that read a diff and draft a changelog entry, or summarize a module in plain language, are exactly the tools a program with data-handling restrictions cannot use. The source is classified or otherwise export-controlled, the assistant is a cloud API, and the two facts are incompatible. What's left is documentation written by hand, under deadline pressure, which is another way of saying documentation that drifts out of date the moment the code it describes changes again.

That's the specific gap offline documentation generation has to close: not "can a model write good prose," which was solved years ago, but "can that capability exist entirely inside a boundary the code is never permitted to leave." Those are different engineering problems, and the second one is the one that actually determines whether a classified program gets usable documentation at all.

Why hand-written documentation degrades predictably

The failure mode isn't laziness. It's that documentation and code have different update cadences by default. A function signature changes in a Tuesday commit; the paragraph in the design doc that describes what that function does was written six months earlier and nothing forces it to change in step. Multiply that by a program with hundreds of modules and a classification boundary that makes external documentation tooling off-limits, and the gap compounds until the documentation describes a system that used to exist.

For classified projects specifically, this has a second cost beyond the usual maintenance burden. Documentation is often the artifact an accreditation or authorization process actually reads. A reviewer assessing a system for an ATO package is working from the design description and the interface documentation, not from re-deriving behavior by reading source line by line. Documentation that has drifted from the implementation isn't just an inconvenience for the next engineer; it's a discrepancy between what was represented to an authorizing body and what the system actually does.

Docs as a query over an index, not a separate authoring task

Forge's repository index, built once inside the sealed appliance and kept current as commits land, to support code navigation, review, and repository-scale question answering, is the same structural understanding that documentation generation draws on. A function's signature, its callers, the types it touches, and the comments and commit history around it are already indexed for other purposes; generating a description of that function is a retrieval-and-synthesis operation over data that already exists locally, not a new pipeline that has to be built and secured separately.

That framing matters because it changes what "keeping docs current" costs. If documentation generation is bolted on as a distinct tool, every change to the codebase requires someone to remember to re-run it, and remembering is exactly the discipline that erodes under deadline pressure. If documentation generation is instead a query Forge can answer at any point, describe this module, summarize what changed in this interface since the last release, produce a first-pass explanation of this subsystem for a new team member, then staying current is a matter of asking again, not maintaining a separate authoring workflow in parallel with development.

What stays inside the boundary

The properties that make this viable for a classified program are the same ones that make Forge viable for classified code review or in-IDE assistance generally: the model, the index, and the retrieval layer all run inside the sealed appliance, with no network path out. A request to summarize a module never leaves the enclave as a prompt to an external service, and the generated documentation itself, which can be just as sensitive as the code it describes, since a clear plain-language summary of a classified capability is itself classified, never transits anywhere the source code wasn't already permitted to go.

This is a meaningful distinction from documentation workflows built around a cloud coding assistant with an on-premises proxy or a redaction layer in front of it. Redaction is a judgment call applied per request, and judgment calls made under time pressure by whoever is running the query are exactly where classification handling tends to fail. An architecture where the capability simply cannot reach outside the boundary removes that judgment call rather than asking someone to make it correctly every time.

Generated documentation still needs a human authority

None of this is a claim that a model should be the system of record for what a classified codebase does. Generated documentation is a draft, a structurally grounded, current-as-of-last-index draft, but still a draft, and the review and sign-off it requires before it becomes an artifact a program relies on is unchanged by where the generation happened. What offline generation changes is the starting point: instead of a subject-matter expert writing a module description from scratch, they're reviewing and correcting a description that's already anchored to the actual current interface, call graph, and recent change history, which is a faster and more accurate task than authoring from a blank page.

That division of labor also gives a program a natural way to keep documentation review inside its existing approval chain. The generation step doesn't need to be trusted as final; it needs to be fast enough and accurate enough that the human reviewer's job becomes verification rather than composition. In practice that's the difference between documentation that's attempted once at a milestone and left to decay, and documentation that's regenerated and re-reviewed cheaply enough to actually track the code.

Documentation quality as a retrieval problem, not a prose problem

What generated documentation is actually good at is narrower than it might sound, and overclaiming here does a program no favors. A model describing a function it can see the full call graph for, its callers, its dependencies, the types it operates on, the commit messages that touched it, can produce an accurate, specific description grounded in that structure. A model asked to explain the intent behind a design decision that was never recorded anywhere in the repository has nothing to retrieve, and no amount of fluent prose changes that; the honest output in that case is a description of what the code does, not a reconstruction of why someone decided to do it that way, and treating the two as interchangeable is where automated documentation efforts lose credibility.

The retrieval discipline that makes Forge's code review and repository question-answering reliable, pull in what's structurally relevant, don't fill the context with what merely happens to be nearby, is the same discipline that keeps generated documentation honest. Documentation grounded in the index describes the system that exists. Documentation generated by a model working from a vague prompt and no repository access describes a plausible system, which for a classified program's accreditation artifacts is a considerably more dangerous thing to have sitting in a shared drive labeled as authoritative.