How It Works
One chain from a custom ABAP program to a decision and a signed record: the process as BPMN with line anchors, Level A–D for each SAP object (or Unknown), the decision, then design, code draft and tests. The engine reads the code first; what a language model writes comes after it and is marked as a Model proposal.
A deterministic engine reads one custom ABAP program and reconstructs its business process as BPMN, with a line anchor on every element or the reason it has none. Every SAP object the code uses is graded Level A–D from SAP's published Cloudification Repository (33,877 objects), or marked Unknown where the repository holds no answer for it, and the Management view asks for one decision: keep, rebuild, move to SAP standard or retire. Design, code draft and tests are built on that evidence as Model proposals for a person to review, and every completed analysis is stored as an immutable run signed by the server.
From the code to a signed run, step by step
Five steps on the same evidence. Each one says where its statements come from, and each points back to the lines of code it rests on.
The process, read from the code
The engine parses the program without a language model; the same file gives the same result. It reconstructs the business process the program runs as BPMN — start and end events, tasks, decision points and sub-processes — with a line anchor on every element, or the reason it has none. Literals in conditions, such as tolerances, plants or date limits, become business rules with their line, which the Business view answers with keep, change, drop or clarify. Code no entry point reaches is listed, not drawn. Plain business names a language model proposes are marked as a Model proposal.
In the code: lib/abap/process-skeleton.ts · lib/abap/business-rules.ts
Level A–D, or Unknown, for each SAP object
Every SAP object the code uses is looked up in SAP's published Cloudification Repository and object classification (33,877 objects) and graded Level A–D under a versioned rule, or marked Unknown where neither holds an answer for it rather than given a guessed level; an SAP object the code writes directly is Level D, whatever its own level. The findings give the Clean Core Score, 5–100, higher is better — Clean-Core.io's own grade, not an SAP measure. The level is an orientation: ABAP Test Cockpit stays the authority. How the level is derived: the rule and its version.
In the code: lib/abap/abcd-classification.ts · lib/clean-core-score.ts
The decision, in the Management view
The Management view asks one question of the program and shows what the answer rests on — the need, the options, the costs as a simulation on your own assumptions, the architecture — and what still blocks it. Clean-Core.io prepares the decision; the signed-in account records it, a self-declaration, not a mandate.
- Keep
- The program stays as it is and is maintained. Nothing is built; what blocks the standard stays.
- Rebuild
- The program is rebuilt as a clean extension on released interfaces. The route is signed off in Design.
- Move to SAP standard
- SAP standard takes over what the program does. Nothing is built; the program is switched off once the standard runs.
- Retire
- The program is switched off without a replacement. Nothing is built; whoever still needs it has to say so first.
In the code: lib/decision-options.ts
Design, code draft and tests
Design reads the functional and non-functional requirements from the code and proposes a target: ABAP Cloud (RAP) inside SAP S/4HANA, or CAP on SAP BTP, part of the SAP Business AI Platform. Transformation drafts the target code from the source, the analysis and the design; its plan names every finding at its line. Testing derives test scenarios. On the CAP track they run against mocks in an isolated runner, and the server records what ran on which code. On the RAP track they are an ABAP Unit class that runs only in your own SAP system; you record its result as an imported file or your own confirmation, never as proven. All three are Model proposals built on the signed run — drafts to review, not a finished product.
In the workspace: Design · Transformation · Testing
A signed run, and an audit pack anyone can check
Every completed analysis is stored as an immutable run, signed by the server with HMAC. The audit pack exported from it is signed over the run with HMAC and Ed25519, and the Ed25519 signature can be checked offline against the published public key, or on Verify an audit pack. A signature proves where a result came from and that it has not changed since — not that it is right.
In the code: app/api/runs/create/route.ts · lib/audit-pack.ts
What the engine computes, what the model writes
Deterministic engine
- The process as BPMN, with a line anchor or the reason there is none
- Business rules hard-coded in the program
- Level A–D per SAP object, under a versioned rule
- Findings and the Clean Core Score
- Successors from SAP’s Cloudification Repository
- The process description in Documentation
- What could not be determined, with the reason
- Signatures over runs and audit packs
Language model (Google Gemini)
- Plain business names for process steps
- The narrative of the analysis
- The target design
- The transformed code draft (RAP or CAP)
- Test scenarios
Where each statement comes from
Every statement in a project carries one of 9 provenance values. The value says who stands behind it — the engine, a file, a person, the model — and what is still open.
- Proven
- Backed by the engine, a signature or a real run.
- Confirmed
- Confirmed by the signed-in account — a self-declaration, not a mandate.
- Reconstructed
- Derived from the code, not confirmed by anyone.
- Imported
- Taken from a file — ATC, BPMN, usage, an SAP catalogue.
- Model proposal
- Proposed by the language model, unchecked.
- Simulation
- Computed on assumptions you entered.
- Demonstrated · mock
- Shown against mocks, not against a real system.
- Stale
- No longer current — recompute.
- Not determined
- Could not be determined — the reason is given.
Coverage Matrix
What works today, what needs help, and what we don't support yet. This matrix is the single source the transformation engine flags against — it is always current.
| Construct | Support Level | Notes |
|---|---|---|
| Direct SELECT on standard tables | Support Level | NotesRead deterministically. A released CDS view is proposed where the tables match one — a candidate to review, not a verified mapping. |
| Simple wrapper classes / reports | Support Level | NotesStatements and routines are read deterministically; the target code is generated by the model and needs review. |
| Static CALL FUNCTION | Support Level | NotesThe called name is read. With DESTINATION the call is assessed as an RFC; a local call of a function module SAP's published files list is answered with SAP's state for it, and any other local call is recorded as not assessed — no released API is proposed for either. |
| Complex SQL Joins (3+ tables) | Support Level | NotesGenerated with review flags; architect sign-off recommended. |
| BAdI / Enhancement Implementations | Support Level | NotesWiring generated; method body logic requires manual review. |
| Dynamic CALL FUNCTION / PERFORM | Support Level | NotesFlagged with low-confidence warning; cannot resolve at parse time. |
| SAP GUI Dynpro screens (MODULE POOL) | Support Level | NotesUI layer requires manual Fiori/UI5 redesign; backend logic extracted separately. |
| Kernel calls (ABAP system internals) | Support Level | NotesNo public API equivalent exists; must be re-architected or removed. |
| ABAP OO with inheritance chains | Support Level | NotesFully resolved when all ancestor sources are provided; missing ancestors are requested explicitly. |
| RTTI / dynamic type resolution | Support Level | NotesRuntime-dependent; cannot be resolved statically. Manual verification required. |
| Missing source dependency | Support Level | NotesA referenced class/interface source was not provided. Upload it to complete resolution. |
Frequently Asked Questions (FAQ)
What does Clean-Core.io do with one ABAP program, in order?
It reads the program with a deterministic engine and reconstructs its business process as BPMN, with a line anchor on every element or the reason it has none. It grades each SAP object the code uses Level A–D from SAP’s published Cloudification Repository and object classification, or marks it Unknown where neither holds an answer for it. The Management view then asks for one decision — keep, rebuild, move to SAP standard or retire — and Design, Transformation and Testing carry the same evidence to a target design, a code draft and test scenarios. Every completed analysis is stored as an immutable run signed by the server with HMAC.
Which ABAP constructs are automatically transformed?
Direct database reads (SELECT on standard SAP tables like VBAK, BSEG, LIKP), simple wrapper classes, and remote function calls (CALL FUNCTION … DESTINATION) are fully supported. A local function-module call with a static name is not assessed yet; the analysis lists it as not assessed rather than passing it. Complex SQL joins, BAdI implementations, and enhancement spots are partially supported with manual review flags. The coverage matrix on this page is the list the engine flags against.
What role does the language model play?
The language model (Google Gemini) writes after the engine and on its evidence: plain business names for process steps, the narrative of the analysis, the target design, the transformed code draft and the test scenarios. Everything it writes is marked as a Model proposal until a person confirms it. The process, the business rules, Level A–D, the findings, the Clean Core Score and the table-to-successor lookups come from the engine and SAP’s published Cloudification Repository, never from the model.
Who makes the decision — keep, rebuild, move to SAP standard or retire?
The person reading the Management view. Clean-Core.io prepares the decision and shows what it rests on; it does not take it. The decision is recorded by the signed-in account — a self-declaration, not a mandate. Keep, move to SAP standard and retire build nothing; a rebuild is signed off in Design, where the target route is chosen.
Can I verify the generated code yourself?
Yes. A transformation on the ABAP Cloud (RAP) route produces a package laid out for abapGit — a src/ directory and a .abapgit.xml written from the project itself — together with generated ABAP-Unit test classes, so you can read every line and run the tests in your own system. The CAP route on SAP BTP produces Node.js code with a generated test suite in TypeScript instead, not ABAP-Unit. We have not imported one into a real SAP system, so we do not claim the package activates without adjustment: the object metadata is generated, not produced by abapGit’s own serializer. Treat it as a starting point for an import rather than an import that is known to succeed.
What does a signed run prove?
Where a result came from and that it has not changed since — not that it is correct. A run is signed by the server with HMAC; the audit pack exported from it is signed over the run with HMAC and Ed25519, and the Ed25519 signature can be checked offline against the published public key. Level A–D is deliberately not part of the signed audit pack: it is an orientation, and ABAP Test Cockpit stays the authority.