What Gets Documented
Afunana reads the source that runs the business — COBOL, RPG, CL and DDS on IBM i, PL/SQL on Oracle, and plain SQL — and documents every program in it. z/OS COBOL is on the near-term roadmap. It is not a chat window explaining a snippet you paste in: it reads the whole estate, reconstructs a persistent cross-referenced map, and documents each program in the context of everything it calls and every file it touches. Everything on this page comes from that map.
Documentation Levels
Every program is documented three times, for three audiences: a business specification in business terms, a systems analysis of how it fits the wider system, and a program specification with full technical detail. All three come from the same analysis, so they cannot disagree, and each can be issued as a formal document in the language the collection is configured for. Each covers the program's purpose and criticality, the files it opens, its callers and callees, its error handling, and what a modernization effort should watch for. Structure is also rendered as interactive maps drawn from the cross-reference.
The "Why" Layer
Legacy source records what a system does and almost never why. The highest-value output is the layer that reconstructs intent — the knowledge that walked out the door when the original team retired. Business rules buried in conditional logic are stated in plain language: an approval threshold, a discount cap, a status code that quietly means "deleted". Each is cited to the lines that enforce it, and rules whose purpose cannot be determined are flagged as unclear rather than guessed.
The same layer surfaces what a modernization programme needs before it commits: dead code, implicit dependencies, and constructs that will not survive a move.
Source Citations
No generated sentence exists without a path back to the code. Every claim carries a citation to the lines that support it, shown as a badge that opens the source — the same mechanism that backs every answer the assistant gives, and what lets a reviewer verify a statement rather than take it on trust.
Generated documentation is a strong first draft, not an infallible oracle: confidence indicators mark sections where the model had limited context, and experts can edit anything generated.
The Data Behind the Programs
Documentation explains the programs. The data dictionary and cross-reference explain the data they move: what a field means, who uses it, and where its value comes from and goes to.
Field Catalog
Every field gets an entry carrying its technical definition and, more usefully, a plain-language description of what it represents to the business — the difference between knowing a field holds six packed digits and knowing it holds a customer credit limit checked during order validation. Because those descriptions are in business language, a search for "customer phone number" returns every field that holds one, whichever naming convention the developer of the day used. Descriptions can be corrected by hand and survive rebuilds.
Cross-Reference Matrix
The cross-reference maps every program to every file it touches and records how — read, write, update or delete. This is a structural fact taken straight from parsing, available before any AI runs. Files and programs are ranked by how many programs depend on them, so which data structures are central is visible immediately.
Field Lineage and Impact Analysis
Lineage traces how a value travels: where it originates, every transformation along the way, and where it comes to rest. What matters is that it does not stop at program boundaries — when a field is passed as a call parameter the trace follows it into the called program and keeps going, so the picture is end-to-end rather than program by program.
Put lineage, the cross-reference and the documented behaviour together and the system answers the question every change starts with: what breaks if I change this? For a proposed change — lengthening a field, retiring a file, altering what a program returns — it reports the programs that reference the element directly, those that consume their output, the downstream fields derived from it, and every program that includes an affected copybook, and derives the order to recompile in.
Asking Questions of the Estate
Documentation answers the questions you knew to ask. The assistant answers the rest, in plain business language, about the whole estate rather than a single program. Because it reasons over the documented business rules, cross-references and lineage described above — not over a window of pasted text — it handles the questions a business actually asks: which programs update the customer balance, or what breaks if the policy number goes from eight digits to ten. Each answer names programs and lines, so the follow-up is one click into the real code.
Ask and Plan
Ask is read-only question answering, drawing on the generated documentation, raw source, the cross-reference and any documents you have uploaded.
Plan goes further. Describe a change and the assistant produces a structured proposal: the programs to modify and the specific edits, in the codebase's own style; the other programs the change reaches; the order to recompile in; what to test; and a risk assessment. Plans are validated against the parsed structure of the code.
The default posture is to stop at the plan and hand it to a developer. An approval-gated execution workflow exists: it applies an approved plan back to the source system and promotes it, taking a backup as it goes. It applies changes — it does not compile or verify them. It is admin-triggered, gated by configuration, and off on the public production instance. A third mode, Agent, is marked coming soon and is currently disabled.
Evidence and Confidence
Answers are assembled from the maintained map of the estate rather than from a window of pasted text, which is why the assistant finds the right programs even when the question uses nothing like the words in the code. Search indexes are computed on the customer's own hardware and never leave the network. The assistant says when it is inferring rather than reading a direct match.
Existing specifications, manuals and analysts' notes can be uploaded into the same knowledge base and are then retrieved exactly like anything the code revealed. Questions can be asked in any language. Where a collection has a documentation language configured the answer follows it; otherwise the answer comes back in the language the question was asked in.
The Defects That Produce No Error Message
The most expensive defects in a legacy estate are the ones that produce no error message: a call whose parameters no longer match the program it calls, a transfer that quietly truncates an amount, a read whose status is never checked. Nothing crashes — the batch chain runs clean and the numbers come out wrong, and the defect surfaces years later as data corruption or a wrong number on a regulatory report.
Afunana looks for them on every build, deterministically — no AI, no machine learning, no heuristics. It works from a genuine understanding of the code's structure and of the data as the machine actually lays it out, and applies exact rules rather than pattern-matching. The same source always produces the same findings, and every finding reflects an actual structural fact rather than a probability.
What Is Checked
Interface checks are the most valuable family: they compare each call against the definition of the program being called, verifying that both halves agree on the number of parameters, their sizes and their names — the hardest defect class to find by eye, because the two halves live in different source members. Data-integrity checks catch silent loss: a value moved into a field too small to hold it, dropping digits or decimal precision with no runtime error, which in a financial system can propagate through batch cycles before anyone notices. Control-flow checks flag unsafe logic paths such as a read with no status handler; these ship off by default, being advisory patterns that vary by site.
For Oracle, a PL/SQL family applies the same discipline: swallowed exceptions, whole-table updates and deletes, injectable dynamic SQL, hardcoded credentials.
Tuning and Reporting
Every check carries a severity set per customer — error, note, or off — so an organization tunes the catalog to its own standards. Each build ends with a quality report: totals by severity and family, the programs carrying the most findings, and the trend against previous builds.
Where the Knowledge Shows Up
All of this is produced once and reaches people in the web application, the developer's editor, and the AI assistants and systems an organization already uses.
In the Editor
A VS Code extension puts the estate's knowledge where developers work. Hovering over a call explains what the called program does for the business and how critical it is, not merely that it exists. Quality findings arrive as native diagnostics, so the silent-failure analysis reaches a developer while editing rather than in a report read later. Navigation follows calls and copybooks to their definitions. Change plans in the editor are display-only: the extension renders a plan for review and never applies it.
The extension is self-contained — no companion extension, no vendor connectivity client — and the editor never connects to the source system directly; it talks only to the Afunana server, which holds that connection. Legacy-language highlighting is bundled and the syntax check runs on the server, so no local toolchain is required. Developers can pull a source member in, edit it and save it back under their own sign-on. Editor support is IBM i-centric.
In Your AI Assistants
The Model Context Protocol is an open standard for connecting AI assistants to external data. Afunana runs an authenticated MCP server as part of the standard installation, so the assistants already on a developer's desk — Claude Desktop, claude.ai, Cursor, VS Code Copilot and others — can query the analyzed knowledge base directly instead of having material pasted into a prompt. What they get is the cross-referenced map: program documentation, searchable listings, the system overview, the data dictionary, the impact map and the call tree.
That surface is documentation and metadata only, and read-only; raw source is never exposed through it. Sign-in uses OAuth 2.0, each request carries the individual user's own token, and per-collection permissions apply, so an assistant reaches only what the person driving it is entitled to see. Activity is recorded in the audit trail.
Through the API
Everything the web application does, it does through an authenticated REST API, and that API is open to the systems you already run. It covers program, file and table documentation, the data dictionary, cross-reference and field lineage, the quality findings from the most recent build, natural-language questions with answers returned whole or streamed, change plans and their approval, uploaded documents, and the administration of collections, builds, users, cost reporting and audit export.
Access is authenticated per user and constrained by role and per-collection permission, so an integration sees exactly what the account behind it is entitled to see. Reading source from the connected system, and approval-gated write-back to it, are available here and only here — never through the assistant integration.