Afunana is delivered as a small set of self-contained containers that run on the customer's own infrastructure — a data centre, a private cloud tenancy, or an air-gapped network. No vendor-hosted service sits in the path: the software, the source it reads, and the documentation it produces all stay inside the estate.
The shape of an installation
One picture to orient on. Everything inside the dashed boundary runs on the customer's own hardware; only two arrows cross it, and both are ones the customer configures and can sever.
Users, and the AI tools on their desks
|
TLS proxy
|
- - - - - - - - - - - - - - - - - - - - - - - - - - customer boundary
| | |
| Afunana application |
| web UI . REST API . MCP . VS Code |
| | |
| +--------------+--------------+ |
| | | | |
| relational local search per-collection |
| database index working storage |
| (users, config, (meaning + (extracted source,|
| audit, history) keyword) generated docs) |
| |
- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
source platform model provider
(IBM i / Oracle) (or a local model,
read-only extraction for no egress at all)
Reading it in one line: the application is the only thing users talk to; it keeps its records in a database, builds its own search index on the box, and reaches outward exactly twice — inward to the system whose code is being read, and outward to whichever model writes the documentation. Replace the second with a local model and nothing leaves the perimeter.
How it deploys
Installation is a single command: it pulls the image and runs an installer that provisions secrets, generates its own runtime configuration, and starts the application. There are no manual post-install steps. Enterprise sites can pull from an internal registry or install fully offline. Updates re-pull and restart, preserving all data.
Two components are optional, because large organisations already have their own. A database is bundled and hardened by default, or the product runs against the customer's own database server — including a high-availability cluster — with no code change. A reverse proxy with automatic TLS is included, or omitted when the customer fronts the application themselves.
The pieces
The application — one process serving the web interface and the programmatic interfaces alike. It authenticates users, serves documentation and chat, runs the analysis pipeline, connects to the source platform, and hosts the gateway every model call passes through.
A relational database — the system of record: users and roles, collection and connection metadata, build history, configuration, change plans, chat history, and the audit log.
A local search layer — built per collection over the generated documentation, so the assistant finds things by meaning as well as by name. It is computed entirely on the customer's own hardware; no content goes to an external service.
Per-collection working storage — extracted source, parsed structures, and generated documents, held separately for each body of code analyzed.
Interfaces
The same data is reachable through several surfaces: the web application, a REST API, an authenticated Model Context Protocol endpoint so AI tools can query a collection directly, and a VS Code extension for in-editor work.
Security posture
The application and database never face the network directly — TLS terminates at the proxy. Authentication is token-based with optional SSO/OIDC, and authorization is role-based, from full administration down to review-only. Secrets live in a secret store or the environment, masked in the UI and never logged. Security-relevant events go to a tamper-evident audit log the database refuses to let anyone alter. Security & Governance is where all of that is set out in full.
The two connections that leave your network
An instance reaches outside itself in only two ways.
Inward to the source platform, to read code. Extraction is strictly read-only during analysis. IBM i (AS/400) — COBOL, RPG, CL, DDS — is the primary path; under an approved change plan Afunana can also write an executed change back. Oracle — PL/SQL — is read from the data dictionary into the same internal model. z/OS mainframe is a defined connection type; full analysis support is on the near-term roadmap, not a current capability.
Outward to a model provider, to write documentation. The gateway supports Anthropic, OpenAI, Azure OpenAI, and local Ollama. Sites that cannot make outbound calls at all run local models, fully air-gapped.
The analysis pipeline
The pipeline turns extracted source into searchable documentation in stages. Structural mapping is deterministic — language grammar, not AI — and produces the call graph, cross-reference matrix, field catalog, and silent-failure findings. The documentation stages call a model; later stages build the local indexes and derive business-concept tags. After the first full build, only what genuinely changed is re-analyzed, so the documentation stays current without paying for the whole estate again.
The AI gateway
Every model call is assigned a role and routed through a single governed gateway. Each role has a preferred model and somewhere to go when that model is unavailable, so a rate limit, timeout, or provider outage moves the call on automatically instead of failing the run. Switching provider or model is a configuration change, not a rebuild.
Every call is metered against pricing the customer controls and rolled up per collection and per role, so AI spend is visible by workload rather than arriving as an undifferentiated cloud bill.
Design decisions
Afunana is built to run inside conservative environments — banks, insurers, government IT — and to keep running, unattended, for years. That constraint produced five decisions, and most of the rest of the design follows from them.
Deterministic where it counts, AI where it helps
The structural backbone — how programs call each other, which fields flow where, where a parameter's size disagrees across a boundary — is computed deterministically, by parsing the source. Not by asking a model. AI does the one thing it is genuinely better at: explaining code in business language.
That split is the single most important decision in the product. The maps, cross-references, and silent-failure findings are reproducible and auditable — run them twice, get the same answer. The probabilistic part is contained to the documentation layer, where every claim carries a citation back to a source line a human can check, by contract rather than by convention. Nothing that has to be exact is left to a guess.
One common model for every platform
IBM i (COBOL, RPG, CL, DDS), Oracle (PL/SQL), and plain SQL are each extracted into one common internal model, then documented, quality-checked, and searched identically. Adding a platform means teaching an extractor to populate that model; everything downstream comes along for free. z/OS mainframe COBOL is on the roadmap on exactly this foundation.
A mixed estate therefore yields one consistent body of knowledge, not a per-language patchwork, and coverage grows without the product being rewritten each time.
All AI behind one governed gateway
No part of the system talks to a model provider directly. Every call flows through a single gateway, which is where routing, fallback, caching, and cost metering live. Supporting a new provider or model is a configuration change, and swapping providers never touches business logic.
That is also what makes the AI governable. Because there is exactly one door, there is exactly one place to see what was spent, enforce which provider may be used, or cut over to local models.
Do the expensive work once
After the first build, only what genuinely changed is re-analyzed. A million-line estate is not reprocessed because ten programs moved.
This is what keeps the documentation true. Refreshes are cheap enough to be routine, so the generated documentation tracks the live code instead of drifting — the classic failure mode of hand-written documentation. Work is organised into independent collections, and heavy stages run in parallel under a limit the operator sets.
Configuration over code
Providers, models, prompts, check severities, timeouts, and thresholds are all settings. Most changes to behavior are made by an operator, without a developer and without a release. Configuration has one source of truth and no hidden defaults: the system fails loudly when a required value is missing rather than guessing, and nothing critical is hardcoded.
The same instinct runs through operations. Extraction, structural analysis, documentation, indexing, and quality checks are distinct stages with clear boundaries, so each can be tested or re-run on its own. And observability is built in rather than added: an operator sees what the system is doing, and what it costs, without instrumenting it.