Product Overview

Afunana is an on-premise legacy-system intelligence platform. It reads the source code that actually runs the business — COBOL, RPG, CL, DDS, SQL, and PL/SQL — and reconstructs the knowledge buried inside it: the business rules, the data, and the dependencies. The result is documentation a business can read, a developer can navigate, and an auditor can trust.

Its differentiator is that it doesn't just explain code shown to it. Afunana maintains a persistent, queryable knowledge graph of how every part of a system connects to every other part — program calls program, program uses file, file has field — kept current as the code changes. That graph is the foundation for business-level documentation, an AI assistant that cites the exact source line behind every answer, a silent-failure detection layer, and a change-planning workflow that can write an approved fix back to the live system in the codebase's own style.

"The enterprise's DNA, made readable."

Production instance: https://afunana.io

The problem it solves

Most IBM i, mainframe, and Oracle shops run applications that are 20 to 40 years old. The people who wrote them are retiring. The documentation, if it ever existed, is out of date. And the knowledge of why the code does what it does lives in a handful of experts — and walks out the door when they leave.

That knowledge gap makes everything expensive and risky: every change might break something nobody understands, every audit takes weeks of manual code reading, and every modernization project stalls because no one can say what the system actually does.

Afunana closes that gap. It extracts the source, maps its structure, and produces a layer of understanding on top of code that previously only a few people could read.

The platforms it works with

Afunana is multi-platform. The same knowledge-graph approach applies across the enterprise systems that run core operations:

IBM i is used as the primary worked example throughout this documentation and in every screenshot — that is simply what the screenshots show. The same extraction, documentation, silent-failure checks, and search apply to Oracle and plain SQL. z/OS mainframe reuses the same foundation and is the next platform to land.

The four phases

Afunana follows a simple arc, and after the first pass it stays current on its own.

1. Understand. Read the source and produce multi-level documentation, visual maps (call trees, data-flow, sequence, and logic diagrams, ERDs, field lineage), a data dictionary and cross-reference, and a citation-backed chat assistant.
2. Plan. Generate structured, validated modification plans grounded in the live codebase — what to change, in what order, and what it will impact.
3. Execute (optional, human-approved). Write the approved change back to the live system, in the codebase's own coding style, through an approval-gated workflow. Available as an option — the default posture is to stop at the plan and hand off to a developer.
4. Refresh. As code changes, an incremental delta rebuild re-analyzes only the programs that actually changed, so the documentation never goes stale.

What it produces

The "why" layer

What separates Afunana from a comment generator is that it documents intent, not just mechanics. For every program it surfaces:

• Business rules that exist only in the code — the conditions, thresholds, and special cases nobody wrote down.
• Dead code and implicit dependencies — logic that looks important but never runs, and coupling that isn't obvious from the call graph.
• Migration traps — the places where a rewrite will go wrong if you don't know what the original code was really doing.

The documentation leads with business meaning. "Screens policies for cancellation eligibility," rather than "reads file GVBITULP." That is the difference between documentation a developer skims and documentation a business analyst can rely on.

What makes it different

• A knowledge graph, not an LLM wrapper. A chat session over a context window can explain a snippet pasted into it; it does not maintain a cross-referenced map of an entire system, updated as the system changes. Afunana does — and that map is what powers every other feature.
• It finds the silent failures. The defects that pass every test and only surface when real data triggers them — a caller and callee that disagree about a parameter's size, a move that quietly truncates an amount — are caught structurally, before they ship.
• It closes the loop, in the codebase's own style. From understanding to a validated change plan to an approved, style-matched edit written back to the live system.
• One AI Hub — a governed gateway, not a single-vendor bet. Every model call routes through one governed gateway; the organization controls cost, access, and data, and can switch providers or models freely with no rebuild.
• Every call is metered. Afunana meters what each build and query costs — token usage priced against rates held in the database — and surfaces the running total in a Costs view, so spend is visible per collection and per role rather than arriving as a surprise cloud bill.
• On-premise / air-gapped. Nothing leaves the customer network. It can run fully offline with a local model and self-hosted embeddings.
• Bring Your Own Documents. Existing specs, manuals, and notes fold into the same searchable, cited knowledge base.
• Documentation and answers in any language — the output language is configurable per collection.

How people use it

• Developers open a program and immediately understand what it does, what calls it, and what it touches — without reading 4,000 lines of COBOL — and can edit source directly from VS Code with the extension.
• Analysts and architects explore the system top-down: from the system overview into subsystems, down to individual programs, business rules, and fields.
• Auditors and compliance teams export structured evidence, review the tamper-evident audit trail, and use the deterministic quality findings as objective inputs.
• Modernization teams use the why-layer and cross-reference data to scope rewrites with their eyes open.

How it fits together

Afunana runs as a self-contained set of Docker (or Podman) containers, installed on the customer's own infrastructure with a single command. It connects to the source platform to extract source, maps and analyzes it through the AI pipeline, and serves everything through a web application, a REST API, an MCP endpoint for AI tools, and a VS Code extension.

Nothing leaves the customer's environment except the LLM calls, and those route through whichever provider the customer configures. The default per-role chain is Anthropic as primary with an OpenAI fallback; Azure OpenAI (with its own endpoint and key) and a local Ollama model are also supported. Configuring Ollama keeps every call on-network for air-gapped sites, and the embedding model runs locally by default — embeddings never leave the box. The database can be the bundled SQL Server container or a customer-supplied external SQL Server, and TLS can terminate at the built-in Caddy proxy or at a customer-managed reverse proxy (nginx, F5, HAProxy).

Technology at a glance

Deployment model

Afunana runs on-premise via Docker or Podman. A single command installs everything.

Supported operating systems: RHEL, AlmaLinux, Rocky Linux, Ubuntu, and Debian. The bundled path brings up SQL Server and a Caddy proxy; enterprise deployments can bring their own external SQL Server, reverse proxy, and image registry, or install fully offline from a tar bundle for air-gapped sites. All data stays on your infrastructure — there is no SaaS component and no data-exfiltration risk.

Where to go next

• Executive Summary — the business case, in one page.
• Use Cases — concrete scenarios this is built for.
• System Architecture — how the pieces are wired together.
• Program Documentation — what the generated documentation looks like.
• Installation — how to stand it up.