A proof of concept with a verifiable outcome
The PoC applies the same working model as a full engagement to a smaller scope: you send us a closed scope of code, up to 30,000 lines, together with the rules of the target system and the acceptance criteria; we return it migrated, tested and documented, with the evidence that the criteria have been met.
Fixed and guaranteed price · terms set out in the PoC agreement
Closed, ≤ 30,000 lines
A complete process with its dependencies, not a sample of files: a system that can be run and compared.
Decided in advance
Tests and quality gates are declared before kick-off. The PoC is complete when they all pass, including differential tests against the original.
No LLM
Proprietary specialized models and deterministic gates. Your code is never sent to model providers.
What you send, what you get back
Every element of the package has a precise destination in the pipeline: code goes to the parsers, instructions to generation, tests and data to the verification gates.
What you send
source/
Source code
closed scope
instructions.md
Target instructions
declarative rules
test.md
Test requirements
suite and quality gates
docs.md
Required documents
list and format
data/
Data and test cases
inputs and expected outputs
Scriba AI
6 phases · verification gates
Verified equivalence
What you get back
repo/
Migrated code
buildable, idiomatic
tests/
Test suite
generated and executed
datasets/
Data sets
fixtures, seeds, mappings
docs/
Documentation
as specified in docs.md
reports/
Validation evidence
test and gate results
A system, not a model
Specialized models and deterministic components, coordinated by proprietary orchestration. Scriba doesn't translate line by line: it reconstructs the application logic and business rules and rewrites them as idiomatic code, following your conventions.
01Parse
Parsing
Syntax tree built with parsers specific to each language and dialect.
dedicated parsers · proprietary lexers
02Understand
Semantic analysis
Types, dependencies, control flow and side effects.
dependency graph · type inference
03Recover
Logic reconstruction
Business rules made explicit, traced and separated from the legacy runtime.
intent graph · rule extraction
04Reason
Multi-model
Specialized models in an ensemble: disagreement triggers an escalation.
multi-model · orchestrator
05Verify
Validation
Compilation, types, client rules, differential tests on behaviour.
deterministic gates · diff suite
06Emit
Generation
Idiomatic target code, project structure, build and evidence.
type-aware · framework-aware
Between every phase
Deterministic verification gates: no phase moves forward unless the previous one has been verified.
Six rules for a conclusive PoC
The PoC shows, on your own code and with a contained effort, that Scriba produces an application that is functionally equivalent to the original, compliant with your rules and verified against criteria you set. The rules are the same conditions that make a full engagement reliable, applied to a smaller scope.
Closed scope
Every reference is resolved within the scope or declared as an external interface, with its contract.
At most 30,000 lines
Lines of code in the scope, not counting comments and blank lines.
Declared target
The rules for the target code are in instructions.md: requirements on the result, not procedures or prompts.
Criteria decided in advance
Tests and quality gates are in test.md before kick-off and do not change during execution.
Reference data
Inputs and expected outputs from the original system: without an oracle, equivalence cannot be proven.
Complete configuration up front
Scriba runs in a single pass: anything not declared at kick-off does not make it into the result.
What the PoC is not
It's not a demo
It works on your code, with your rules, and produces verifiable evidence.
It's not a prompting exercise
There is no model to steer with conversational instructions: you declare the expected result.
It's not sampling
A fragment that isn't closed allows you to assess neither the platform nor equivalence.
It's not a go-live
Integration with live systems, migration of production data and acceptance testing in your environments are included only if declared in the scope.
It's not an ongoing relationship
It ends with the handover of the deliverables and the evaluation of the outcome.
Closed scope, up to 30,000 lines
A PoC scope is closed and does not exceed 30,000 lines of code, not counting comments and blank lines. Both conditions apply together: a small but open scope is not eligible, nor is a closed but larger one.
The limit is large enough to hold a complete process with its dependencies, and small enough for your team to review the result in depth. It is not a platform limit: engagements have no such constraint.
How lines are counted
The count includes every source in the scope that contains logic or definitions.
Counted
Programs
Copy members and copybooks
Data definitions
CL, JCL and procedures
Not counted
Data
Test cases
Existing tests
Documentation
Comments and blank lines
Scriba performs the reference count during the eligibility check; for a preliminary estimate, any lines-of-code counting tool will do.
How the limit applies
| Situation | What happens |
|---|---|
| Closed scope within 30,000 lines | Eligible: we proceed with the PoC agreement. |
| Closed scope over 30,000 lines | We identify a closed sub-process within it that fits the limit, or move straight to an engagement. |
| Scope within the limit, with dependencies not included | Sources, stubs or contracts for the dependencies are added, or the dependencies are declared as external interfaces. |
| Scope that would exceed the limit to become closed | A different process is chosen, less coupled to the rest of the system. |
The most representative, not the hardest
The best scope is neither the hardest nor the simplest: it's the one most representative of the system you'll migrate next. A PoC on a closed, well-described scope shows how the engagement will go; a PoC on a fragment mostly describes the limits of the fragment.
A complete functional process
It has entry points and observable results, so it can be compared with the original.
Representative of the system's constructs
The result can be extended to the rest of the application portfolio.
Loosely coupled
Few external references to resolve or declare as interfaces.
Runs today in the original environment
The reference behaviour is needed: real inputs and outputs.
With data available
Parameter tables and extracts to exercise the main branches and edge cases.
With a contact who knows the process
Questions during analysis are often about expected behaviour, not just the code.
Good candidates
- A batch process with its files, its parameter tables and the CL or JCL that triggers it
- A complete online function: the screens, programs and files involved
- A calculation module with well-defined interfaces to the rest of the system
Candidates to avoid
- The most complex program in the system, taken out of its context
- A selection of files taken from different processes
- Programs that no longer compile or are no longer run
- A scope with no data and no expected outputs
From application to evaluation, in seven phases
The first phases establish that the scope is eligible and fix rules and criteria; from kick-off onwards the configuration is frozen and the actual conversion begins, ending with the handover of the deliverables and the evaluation of the outcome.
Qualification
NDA and candidate scope
Objectives, candidate scope and target stack. Signing of the non-disclosure agreement.
Owner: Client and Scriba
Package
Code, instructions, tests, data
Source code, instructions.md, test.md, docs.md, data and test cases, declaration of code ownership.
Owner: Client
Eligibility
≤ 30,000 lines, closed scope
Source inventory, line count, check that the scope is closed, list of unresolved references. Requests for clarification and additional material.
Owner: Scriba
Kick-off
Frozen criteria, PoC agreement
PoC agreement with scope, success criteria, deliverables and timeline. Instructions and tests are frozen.
Owner: Client and Scriba
Conversion
Single pass, verification gates
The pipeline runs in a single pass: parsing, analysis, logic reconstruction, generation, with verification gates between phases.
Owner: Scriba
Validation
Every test and quality gate
Every specified test and quality gate is run; fixes continue until they all pass.
Owner: Scriba
Handover
Deliverables, verifiable outcome
Delivery of code, tests, data sets, documentation and validation evidence. The client verifies the outcome against the declared criteria.
Owner: Client and Scriba
Qualification
NDA and candidate scope
Objectives, candidate scope and target stack. Signing of the non-disclosure agreement.
Owner: Client and Scriba
Package
Code, instructions, tests, data
Source code, instructions.md, test.md, docs.md, data and test cases, declaration of code ownership.
Owner: Client
Eligibility
≤ 30,000 lines, closed scope
Source inventory, line count, check that the scope is closed, list of unresolved references. Requests for clarification and additional material.
Owner: Scriba
Kick-off
Frozen criteria, PoC agreement
PoC agreement with scope, success criteria, deliverables and timeline. Instructions and tests are frozen.
Owner: Client and Scriba
Conversion
Single pass, verification gates
The pipeline runs in a single pass: parsing, analysis, logic reconstruction, generation, with verification gates between phases.
Owner: Scriba
Validation
Every test and quality gate
Every specified test and quality gate is run; fixes continue until they all pass.
Owner: Scriba
Handover
Deliverables, verifiable outcome
Delivery of code, tests, data sets, documentation and validation evidence. The client verifies the outcome against the declared criteria.
Owner: Client and Scriba
Frozen configuration
At PoC kick-off, instructions.md and test.md are frozen. Scriba doesn't produce intermediate drafts for comment and isn't corrected with directions along the way: a later change to the requirements calls for a new run, to be agreed. This is what makes the result comparable with the declared criteria.
Where to invest time
Scriba's requests for clarification are concentrated in the eligibility check. Every ambiguity resolved there prevents a divergence in the result.
When the PoC is complete
The PoC is complete when the converted code passes every test and quality gate specified by the client in test.md or in the instructions file, including the equivalence checks on the reference data. It isn't a subjective judgement: it's an execution outcome, reported in the validation evidence delivered with the code.
You can submit the result to independent reviewers. Observations about compliance with the agreed instructions, tests and quality gates are resolved by Scriba and tracked in the project documentation, with a record of each fix.
The question to ask any vendor
Sooner or later, every alternative produces code that compiles. The useful question is a different one: how do you prove that the migrated system behaves like the original?
Evaluation axes
The PoC is assessed against the criteria declared before kick-off, not on impressions formed afterwards.
| Axis | Question | Evidence |
|---|---|---|
| Equivalence | Does the migrated system produce the same outputs as the original on the same inputs? | Differential tests on the data sets in data/ |
| Compliance | Does the code follow the rules in instructions.md? | Static checks and validation report |
| Quality | Are coverage, static analysis and build within the specified thresholds? | Quality gate reports |
| Maintainability | Is the code idiomatic and readable by your team? | Code review, source → target mapping |
| Verifiability | Can every element be traced back to the source? | Traceability and declared technical debt |
"Production-ready" is defined in advance
If the PoC must show that the code is production-ready, translate what that means into verifiable criteria and write them in test.md: environments, volumes, performance, security, integrations. A requirement that isn't declared can't be verified, so it can be neither met nor disputed.
Who does what during the PoC
| Activity | Client | Scriba |
|---|---|---|
| Choosing the scope | Proposes the scope and names the contact person | Checks closure, eligibility and the line limit |
| Package | Prepares sources, instructions, tests, data and the ownership declaration | Flags gaps and unresolved references |
| Clarifications | Answers before kick-off | Raises its questions during the eligibility check |
| Conversion and validation | — | Runs the pipeline, the tests and the quality gates |
| Evaluation | Checks the outcomes against the declared criteria, including with independent reviewers | Resolves observations on the agreed instructions, tests and quality gates, and tracks them |
Name a technical contact who knows the process and can decide on the target rules: questions during analysis are often about expected behaviour, not just the code.
Prerequisites and conditions
The PoC starts with an agreement that sets out its scope, success criteria, deliverables, timeline and commercial terms.
NDA and ownership declaration
Before any code is sent, the non-disclosure agreement and the signed declaration of code ownership must be in place.
DPA for personal data
The processing of any personal data in the package is governed by a data processing agreement.
Isolated environment, if needed
Your code is never sent to model providers. The execution mode, including an air-gapped environment if required, is agreed in the PoC agreement.
Test environment
Some behaviours only show up in the real environment: actual data formats, driver behaviour, execution context. If the PoC must cover them, provide a reachable test environment (for example a test database) or extracts that faithfully reproduce its characteristics. Without either, these checks remain part of your own acceptance testing.
The PoC package
The package is the material that lets Scriba migrate your code and prove that the result is correct. For a PoC it's the same as for an engagement, on a closed scope of up to 30,000 lines.
| Element | File | Status | What it's for |
|---|---|---|---|
| Source code | source/ | Required | The object of the migration. It must form a closed scope. |
| Target instructions | instructions.md | Required | The constraints the generated code must meet: stack, architecture, conventions. |
| Ownership declaration | signed document | Required | Certifies the client's right to have the code analysed and migrated. |
| Test requirements | test.md | Recommended | Defines the suite and the quality gates to pass: the completion criterion. |
| Required documents | docs.md | If not already in the instructions | The list of documents to receive, with audience, format and language. |
| Data and test cases | data/ | Strongly recommended | The oracle for verifying equivalence with the original system. |
| Functional documentation | docs-input/ | Optional | Context on processes, known rules and exceptions. |
Instructions, not procedures
instructions.md describes the result, not the process: stack and versions, architecture, naming, data access, errors, logging, build and deploy. Skills and prompts have no recipient, because Scriba uses no LLM: if they contain constraints on the result, rephrase them as rules that can be checked on the output.
You don't have to write the tests
In test.md, state the type and level of coverage you need, for example "unit tests for every function" or "integration tests on a real database": Scriba generates, runs and validates the tests on the converted code. Any suites you already have are run as well.
Data is the oracle
Parameter tables, file extracts and pairs of inputs and expected outputs, anonymized in a way that preserves the shape of the data. Without data and expected results, verification is reduced to compilation, type checking and plausibility.
Recommended structure
This structure is a recommendation. The package can be leaner, but every missing element reduces the information available to the pipeline, and with it the precision and verifiability of the result.
Secure delivery
A ZIP or TAR.GZ archive via an expiring link to encrypted storage, or a private Git repository with restricted access. Before sending, remove credentials, production endpoints and real personal data from the code.
Before you send
Ten checks for a package that's eligible first time.
The scope is closed: every referenced program, copy member, file and CL is included or declared as an external interface.
RequiredThe scope does not exceed 30,000 lines of code, not counting comments and blank lines.
Requiredinstructions.md describes the result (stack, versions, architecture, naming, build), not a procedure.
RequiredThe declaration of code ownership is signed.
RequiredLanguage, dialect, version, encoding and format are declared for each group of files.
Requiredtest.md specifies test types, coverage thresholds, quality gates and any other PoC success criteria.
RecommendedParameter tables, extracts and input / expected-output pairs are included and anonymized.
Recommendeddocs.md lists the documents to receive, or the list is in the instructions.
RecommendedThe code has been cleaned of credentials, production endpoints and real personal data.
RequiredA technical contact is named and available during the eligibility check.
RecommendedWhat makes a package ineligible
| Situation | Why it's a problem |
|---|---|
| Skills or prompts instead of instructions | They describe a process, not the result. Scriba uses no LLM: there is no model to interpret them and no way to verify them. |
| A sample of a few files with dependencies missing | Behaviour at the boundaries can't be observed and equivalence can't be proven. |
| "Convert it to something modern, you decide" | Without a declared target there is no success criterion. |
| No data and no expected outputs | There's no oracle: verification stops at compilation. |
| Unknown EBCDIC code page | Converting non-ASCII characters becomes ambiguous. |
| Code that no longer compiles in the original environment | The reference behaviour can't be established. |
| Scope over 30,000 lines | It exceeds the PoC limit: reduce it to a closed sub-process, or assess it as an engagement. |
The PoC deliverables
When the PoC is complete you receive the same deliverables as an engagement, on the PoC scope. Not just the code, but the proof that the code is correct and the documentation to work with it, ready to assess with your team or reviewers of your choice.
Migrated code
Complete, buildable repository, structured according to the instructions
Test suite
Unit, integration, end-to-end and equivalence tests, generated and executed
Validation evidence
Test results, coverage reports, quality gate results
Data sets
Test data sets, fixtures, seeds, record layout mappings, load scripts
Documentation
As specified in docs.md, or the standard set
Traceability
Source → target map, extracted rules, declared technical debt
Documentation: the standard set
Unless docs.md says otherwise, Scriba delivers 16 documents, written for management (document 01) and for development and validation teams (documents 02–15).
Index
Map of the documentation and validation documents
Executive summary
Objectives, outcomes, figures and status, for management
Source analysis
Inventory and analysis of the original code
Target architecture
Backend, frontend and database of the migrated system
Compatibility components
How the original system's semantics are reproduced
Translation strategy
Conventions and patterns applied in the conversion
Program mapping
Every source member and its corresponding target classes
Database and schema
Schema, changelog, indexes
API
Endpoints, DTOs, error contract, security
Frontend
Pages, models, components, internationalization
Validation and testing
Strategy, suites, equivalence methodology
Performance
Measurements and optimizations
Change log
Validation rounds and fixes applied
Technical debt
Stubs, known limitations, external dependencies
Operations runbook
Build, execution, data loading, troubleshooting
Glossary
How legacy idioms map to target patterns
Traceability
Every element of the migrated system can be traced back to its origin: this is what lets an external reviewer verify the migration without having to trust whoever performed it.
- Source → target map: for every program, copy member or data definition, the classes, components and tables derived from it.
- Extracted business rules, with a reference to the point in the source they come from.
- Declared technical debt: stubs, known limitations and external dependencies listed explicitly, never hidden in the code.
Leasing on IBM i: from COBOL ILE batch to Java 25
A COBOL ILE batch on IBM i that extracts financial transactions for a leasing company, migrated to Java 25 / Spring Boot 4.1 with a React 18 / TypeScript frontend and a SQL Server database managed with Liquibase, following the client's backend and frontend instruction files.
Source
COBOL ILE batch on IBM i
Target
95
source members mapped to Java classes
16
documents delivered, from the executive summary to the operations runbook
Bit-perfect
validation methodology
3
rounds of review by independent reviewers, with the resolutions tracked
The basis for sizing the engagement
With a positive outcome, the instructions, tests and package structure are reused on the next scope. The engagement offer is drawn up after analysing the package and is based on the actual size and composition of the scope: mainly the lines of active logic, not counting comments and blank lines, and the complexity of the environments involved. The engagement has no 30,000-line limit.
Fixed and guaranteed price
No subscription, no usage-based fees, no hidden costs. PoC terms are set out in the PoC agreement, before kick-off; engagement terms in the offer, after the package has been analysed.
Frequently asked questions
It uses artificial intelligence, but it doesn't use LLMs. Scriba is a system of specialized models and deterministic components, coordinated by proprietary orchestration and deterministic verification gates. It is not a general-purpose language model, whether commercial or open source, and it isn't an interface built on top of an assistant.
Do you have a candidate scope?
Tell us about the process, the estimated lines, the languages and the target stack: together we'll check eligibility and the line limit before you prepare the package.
Fixed and guaranteed price · terms set out in the PoC agreement