The problem
IBM i, mainframe, and Oracle systems run critical operations at thousands of enterprises. They work. The people who built them are leaving.
Retirements, attrition, and decades of undocumented change have opened a knowledge gap that widens every year. The cost is measurable: longer change cycles, failed audits, stalled modernization projects, and production incidents caused by changes to code nobody fully understands. Manual documentation efforts are expensive, slow, and out of date before they finish.
How it works
Afunana is an on-premise AI platform that reads the source running the business — COBOL, RPG, CL, DDS, SQL, and PL/SQL — and reconstructs the knowledge inside it.
It connects to the source platform, extracts the code, and builds a persistent, queryable knowledge graph of how every part of the system connects to every other part: program calls program, program uses file, file has field. The graph is kept current as the code changes. Everything else the product does is built on top of it.
That distinction matters. A general AI model can explain a snippet shown to it. It does not maintain a cross-referenced map of an entire system, kept current as that system changes. The map is the asset.
The platforms it covers
IBM i (AS/400) — COBOL, RPG, CL, DDS — and Oracle (PL/SQL) are supported, along with plain SQL. All are extracted into the same knowledge graph. IBM z/OS mainframe is on the near-term roadmap using the same approach; it is not a capability today.
Where the value lands
Risk reduction. Every undocumented program is a liability. Afunana documents the codebase systematically, so knowledge that would leave with a departing expert — including the business rules and intent that usually live only in someone's memory — stays captured and searchable.
The costliest defects, caught early. Some bugs never throw an error: a caller and callee that disagree about a parameter's size, a move that silently truncates an amount, an unchecked file status. They pass every test until real data triggers them, and in financial systems they corrupt amounts quietly. Afunana finds these structurally, before they reach production.
Time. Most maintenance time goes into reading and understanding existing code. Cited answers, call trees, and multi-level documentation shorten that, and new team members ramp up faster.
Compliance readiness. Audits require documentation of system behaviour, data handling, and access controls. Afunana generates audit-ready documents with full field lineage and processing logic, backed by a tamper-evident audit trail. Its controls are mapped to OWASP Top 10, ISO/IEC 27001:2022, and SOC 2. Mapped, not certified — formal certification is in progress.
One AI hub, not a single-vendor bet
Every model call routes through a single governed gateway, so the organization controls cost, access, and data. Each role — documentation, chat, code generation — has a primary provider and automatic fallbacks across Anthropic, OpenAI, Azure OpenAI, and local Ollama models. Switching provider is a configuration change, not a rebuild: a disruption at any one provider becomes a setting to adjust rather than a business-continuity event.
Every call is metered. Token usage is priced and surfaced as running spend per collection and per role, so AI cost stays visible rather than arriving as a surprise bill.
The documentation it produces
The order it happens in
Afunana follows a simple arc, and after the first pass it stays current on its own.
- Understand. Read the source and produce multi-level documentation, visual maps, a data dictionary and cross-reference, and a citation-backed chat assistant.
- Plan. Generate structured, validated modification plans grounded in the live codebase — what to change, in what order, and what it will impact.
- Execute (optional, human-approved). Apply the approved edit and promote it, in the codebase's own coding style, keeping a backup. It does not compile or verify the result — that stays with the developer. The default posture is to stop at the plan and hand off.
- Refresh. As code changes, an incremental rebuild re-analyzes only the programs that actually changed, so the documentation does not go stale.
The outputs
| Output | What it is |
|---|---|
| Program documentation | A business specification, a systems analysis, and a program specification for each program — generated from the actual source, leading with business meaning. |
| File & table documentation | Every physical, logical, display, and printer file, and every Oracle table, with field-level meaning, keys, access paths, and the programs that touch it. |
| Cited chat assistant | Ask in plain language, get answers grounded in the code, every claim linked to the exact source line. Ask mode answers; Plan mode turns a conversation into a validated change plan. |
| Silent-failure findings | Deterministic checks for defects that produce no error message — parameter mismatches across call boundaries, truncating moves, unhandled I/O status, unsafe control flow. |
| System overview | A narrative map of the whole application: subsystems, batch flows, online transactions, data stores, risk areas. |
| Cross-reference, lineage & data dictionary | Which programs use which files, where a field is defined, how data crosses program boundaries, and a catalog of every field and table. |
| Change plans | Step-by-step modification plans with impact analysis and compile order. |
Visual maps — call trees, flowcharts, sequence and data-flow diagrams, ERDs, and field-lineage maps — are generated automatically. Existing specs, manuals, and analysts' notes fold into the same searchable, cited knowledge base. Output language is configurable per collection.
Business rules that were never written down
A tool that describes what each line of code does produces something only a programmer can use. Afunana describes what the program is for. For each one it sets out the business rules that exist nowhere but in the code — the conditions, thresholds and special cases nobody recorded — along with the dead code and the implicit dependencies that the call graph does not show, and the places where a rewrite will go wrong if whoever plans it does not know what the original code was really doing.
The documentation therefore leads with business meaning: "screens policies for cancellation eligibility" rather than "reads a file". A business analyst can work from the first; only a developer can work from the second.
Where you read it
The same documentation is reachable four ways. Which one a person uses depends on where they already work.
- The web application — the whole estate, top-down: a system overview, then subsystems, then programs, files, fields and business rules, with the chat assistant beside whatever is open.
- A VS Code extension — the documentation, the chat, and the source itself in the editor, so a developer reads what a program does without leaving the file they are changing.
- An authenticated MCP endpoint — AI assistants such as Claude, Cursor and Copilot query a collection directly, under the same identity and the same per-collection boundary as a person.
- A REST API — for pulling documentation, findings and cross-reference data into whatever else the organisation runs.
Output language is configurable per collection, and the interface reads left-to-right or right-to-left accordingly.