It connects to your IBM i or Oracle system, reads the source, and builds one cross-referenced model of every program, file and field. From that model it produces:
Your developers stop spending days reading code before they can change it, and the faults that normally surface at month-end — a truncated value, an unhandled file status — are caught on the build before the change ships.
Core banking, insurance and government systems still run on COBOL, RPG and Oracle applications written decades ago. They work. What is missing is documentation: the people who wrote them have retired, and what they knew was never written down.
So every change request, production incident and audit question begins the same way: a developer opens a program nobody can explain and reads until it makes sense. It is also what makes a migration, re-platform or decommission hard to scope: the plan is only as good as the map of the system it is built on, and that map is usually a document written years ago. Afunana generates it from the source and rebuilds it as the code changes, so it describes the system as it stands today.
The whole system, in plain language.
Afunana connects to the system, pulls the source, and builds one cross-referenced model of every program, file and field. Everything below works from that model.
Read what a program enforces, traced to its source.
Each claim below is checked against the machine’s own record rather than against the model that wrote it.
When the documentation says one program calls another, that claim is checked against the IBM i's own record of what calls what, not against the model that wrote it. You get a count you can read: how many claims were made, how many the machine confirmed, and which it could not. On the system we test against, 23 of 23 were confirmed. Anything unconfirmed is listed for review.
Truncating moves, unhandled file status, dead code and unsafe control flow are found by reading the code structurally, not by asking a model. The same source gives the same findings every time, whichever model you have configured, and each finding names a line someone can open. Every check is yours to set — off, a note, or an error.
After a code change, a rebuild reads only the programs that actually changed. A system of a few thousand programs does not have to be processed again from the start, which is what keeps the documentation current: a refresh is a routine overnight job rather than a project somebody has to schedule and justify.
Each AI endpoint is a named connection you configure and test: Anthropic, OpenAI, Azure, Microsoft Foundry, AWS Bedrock, a model on your own hardware, or your organisation's own AI gateway in front of any of them. Several can be configured at once, with different jobs pointed at different ones. Changes take effect on the next call.
Model providers change what they accept — a parameter is deprecated, a field is renamed, a deployment is retired. Afunana learns each model's request shape from the provider's own error, adjusts, retries and remembers, so a change that would normally break a pipeline costs one request instead of an outage. Where a job can no longer be served it falls back to the next model you have named for it.
What it cannot fix by itself, it tells you about: a model being withdrawn and the date, a route that has started refusing, answers coming back with values redacted by someone else's content filter. That is the part worth having — the ones that need a decision arrive as an alert rather than as a failed build.
Every call the documentation claims.
Afunana writes six kinds of document, stores them in your own SQL Server, and exports every one of them to PDF, Word, Markdown or plain text. Nothing is held on our side, so there is nothing to retrieve if you stop using the product.
What the program does, and the business rules it enforces, in plain language. Written three ways from the same analysis: for the business reader, the analyst and the programmer. Every statement links to the source line it came from.
Every field in the system, the files it sits in, and every program that reads or writes it. It traces the path a value takes from the screen that captures it to the file that stores it. Name a field and you get everything a change to it would touch.
How many dependency claims the documentation made, and how many the IBM i’s own cross-reference confirmed. It also lists what failed to generate. The figures are counted by the machine, not written by the model that produced the text.
Which AI providers received data, and over what period. It is counted from the log of actual calls rather than read off a settings page, so it reports what happened rather than what was configured to happen.
111 requirements across ISO/IEC 42001, the EU AI Act and NIST AI RMF. Each row carries the position your own people recorded, and beside it what the running system reports about the same question. Printable as it stands.
What the application as a whole is for, the subsystems inside it, and how they relate. It is the starting point most people use: read it first, then open the subsystem, then the program underneath it.
Afunana uses language models to write the documentation, so most organisations have to be able to say which models are involved, what they are given, and who inside the organisation approved that. The product keeps those records itself, reading them from the running software rather than from a policy document.
Each place the software calls a model is listed: what it is for, what data it sees, who owns it, and which risk tier it was placed in. The list is read from the running software, so it cannot claim a use that is not configured or leave one out.
Configuration says which model an administrator wants. A separate approved list says which models are permitted, and anything else is refused when the call is made. Changes can be set to need a second administrator to sign them off.
Each use above minimal risk carries an assessment: who is affected, what data leaves, how it can fail, and what controls are in place. It records who carried it out, it is dated, and it expires so it has to be redone.
Each requirement is held as a row carrying two things side by side: the position your own people recorded, and what the running system reports about the same question. They are kept separate so you can see where the two disagree. Requirements published by your own regulator are added alongside these. None of this is legal advice.
The certifiable management standard for AI. Every clause from 4 to 10, and all 38 Annex A controls, exportable as a statement of applicability.
Article by article, including the Article 26 deployer obligations and Article 25. Each row records who carries the requirement, you or your supplier.
The four functions — Govern, Map, Measure and Manage — at category level. This is the vocabulary most enterprise risk teams already work in.
Every requirement carries one of five positions — met, partial, planned, not applicable or not assessed — and the record holds who decided it, when, and on what basis. How the governance layer works
Language models are charged by usage, so an organisation running this needs to see what is being used before the invoice arrives. Afunana records its own usage as it goes, holds it to a limit you set, and estimates a run before you start it.
Tokens and money for each call, attributed to the job that made it, the model that served it, and the system it was analysing. Prices are read from a table you maintain, so a change in provider rates does not need a software release.
Set a ceiling per period and choose what happens when usage reaches it: record it, warn somebody, or refuse the call. The check happens at the moment the call is made, not in a report afterwards.
How long a run will take and how much throughput it will demand, worked out from your own completed runs. Your AI provider applies a rate limit, and this is the figure that limit has to accommodate.
What the models cost, day by day.
The answers your security, data-protection, risk and audit functions will each ask for. Five points under each heading.
The analyzed system is not locked inside one web application. Developers reach it from VS Code, AI assistants query it over MCP, and your own scripts call the REST API — all with the same permissions and the same answers.
A developer reads a program's documentation in the editor, hovers any field to see what it holds, and gets the findings as ordinary diagnostics. Source members can be opened, edited and saved back under that person's own sign-on.
Point Claude, Cursor or Copilot at your own installation and they answer from your analysed system rather than from general knowledge. Each person signs in, sees only what they are permitted to see, and cannot write anything.
Everything the web application does is available to your own scripts and integrations over HTTP. The same permissions apply, so a script cannot reach further than the person whose credentials it runs under.
Your whole system, in the editor's sidebar.
Two platforms are supported today and a third is being built. All of them go through the same pipeline and produce the same documentation.
The platform Afunana has been run against the longest, and the one the accuracy check works on, because the IBM i keeps its own record of what calls what and that record is what we check against. A server-side agent extracts the source; nothing stays running on the box.
Whole applications rather than just the schema, read into the same model and documented the same way, with defect checks written for PL/SQL. Extraction is read-only and agentless: nothing is installed on your database server and no Oracle client is needed. Where you run both platforms, a field can be followed straight across from one to the other.
Built on the same foundation and already selectable in the product. The connector and the extractor are still being written. If z/OS is in your plans, ask us and we will tell you exactly where it stands.
The proof-of-concept runs on your own source, on your own infrastructure. Usually one subsystem, usually within days.
Platform, languages, roughly how many programs. We pick a first collection together.
One command on your own network, with the AI provider you choose, or fully air-gapped.
Source extracted, model built, documentation written, accuracy checked against your own system's record.
On your own code, with the accuracy report in hand. Whatever you decide, the output is yours to keep.
If a full install is too early, ask for a sample analysis on a system you would recognize.
Click any rule and the source it came from lights up.
Tell us how many programs, which platform and languages, and what you're trying to understand.
Systems integrators and managed-service providers doing legacy work at scale — we support partner and OEM arrangements. Write to partners@afunana.io.