Three situations, step by step.
Principles are easy to agree with. These are three situations our clients and partners actually face, with what is usually done and what Cobra does instead.
A member of staff thinks that some premium adjustments are wrong.
Someone suspects that the system calculates premium adjustments incorrectly for some types of policy. If that is true, customers are affected and the regulator must be told. You need to know quickly, and you need to be sure.
Read this diagram as text
The default approach. Analysts read the program code and follow the calculation by hand. People disagree about what the code does, because nobody can run the exact case. Staff check a few policies by hand. After some weeks there is an opinion, and nothing that can be used again.
With Cobra.
- The Dictionary finds the programs and the data that the calculation uses, so nothing relevant is missed.
- The real program runs for those types of policy, on a copy of your data. Nothing is simulated.
- Cobra shows the rule as one row of a decision table, with the line of code that applies it.
- A test shows the result the program gives beside the result you expect. Either they agree or they do not.
- You correct the rule. The test stays in place, and it fails if the fault ever comes back.
What is usually done
Analysts read the program code and follow the calculation by hand. People disagree about what the code does, because nobody can run the exact case. Staff check a few policies by hand. After some weeks there is an opinion, and nothing that can be used again.
What Cobra does, step by step
- Find. The Dictionary finds the programs and the data that the calculation uses, so nothing relevant is missed.
- Reproduce. The real program runs for those types of policy, on a copy of your data. Nothing is simulated.
- Pin the rule. Cobra shows the rule as one row of a decision table, with the line of code that applies it.
- Confirm. A test shows the result the program gives beside the result you expect. Either they agree or they do not.
- Correct and keep. You correct the rule. The test stays in place, and it fails if the fault ever comes back.
The default approach spends weeks and ends in an opinion. Cobra ends in a clear answer: the rule is correct, or it is not, and here is the line. The work is not lost either. The table and the tests are the first part of a migration, so the effort moves the migration forward. Tests of this kind have found real faults in a client’s thirty-year-old programs.
How each rule is proved →An insurer wants billing off the mainframe first.
The mainframe bill rises every year. Nobody will approve a programme that bets the whole policy system at once, so the plan is to move one part of the business, prove it, and decide what comes next.
Read this diagram as text
The default approach. Rewrite the billing jobs as new software on a new platform. Change the data into the form the new software needs. Then keep the two platforms the same until the last job moves, copying shared data and changing its form in both directions.
With Cobra.
- The estate map follows every call from every transaction program and confirms which programs belong to billing.
- The same analysis lists the data billing owns and the data it shares with the rest of the system. This is measured before the work is priced.
- The billing programs run unchanged on Cobra, on a real runtime in a container, with their rules in decision tables and a test on each row.
- The data keeps the same shape, because the software is the same. Data that only billing uses moves with it. Shared data is copied between the two systems by replication tooling, such as IBM’s Change Data Capture, and every moved record is checked against the original.
- Billing changes over. The mainframe version is still there, so the step can be reversed.
What is usually done
Rewrite the billing jobs as new software on a new platform. Change the data into the form the new software needs. Then keep the two platforms the same until the last job moves, copying shared data and changing its form in both directions.
What Cobra does, step by step
- Map. The estate map follows every call from every transaction program and confirms which programs belong to billing.
- Measure the data. The same analysis lists the data billing owns and the data it shares with the rest of the system. This is measured before the work is priced.
- Run and prove. The billing programs run unchanged on Cobra, on a real runtime in a container, with their rules in decision tables and a test on each row.
- Move the data. The data keeps the same shape, because the software is the same. Data that only billing uses moves with it. Shared data is copied between the two systems by replication tooling, such as IBM’s Change Data Capture, and every moved record is checked against the original.
- Change over. Billing changes over. The mainframe version is still there, so the step can be reversed.
The change is smaller. The default approach makes three changes together: new software, a new data store, and data in a new form. Cobra makes one: where billing runs. Shared data is common in systems of this age, which were built around one central database; on one estate, 123 of 198 record types are written by two capabilities or more. You know that before you agree a price. Later, if you want, the sharing can be removed: the Cobra architecture can offer each business transaction as a service, so other parts of the business ask for the data and do not read it directly.
Start with a slice →A change in regulation arrives in the middle of the programme.
The migration takes more than a year. During that time the regulator changes a rule, or the business needs a new product. This happens in almost every programme.
Read this diagram as text
The default approach. Make the change in the new software while the rewrite continues. Now the old and new systems give different results on purpose, and can no longer be compared. When a result differs, nobody can tell whether it is a fault in the rewrite or the effect of the new rule.
With Cobra.
- The software moves to modern infrastructure, unchanged.
- The tests show the same results as before, rule by rule. The move is now proved on its own.
- The new rule is made on the system that has been proved.
- Only the rules that were expected to change give a new result. Every other rule gives the same result as before, and the tests show it.
- The change is released, with evidence for the regulator of exactly what changed and what did not.
What is usually done
Make the change in the new software while the rewrite continues. Now the old and new systems give different results on purpose, and can no longer be compared. When a result differs, nobody can tell whether it is a fault in the rewrite or the effect of the new rule.
What Cobra does, step by step
- Move. The software moves to modern infrastructure, unchanged.
- Prove. The tests show the same results as before, rule by rule. The move is now proved on its own.
- Change. The new rule is made on the system that has been proved.
- Show the effect. Only the rules that were expected to change give a new result. Every other rule gives the same result as before, and the tests show it.
- Release. The change is released, with evidence for the regulator of exactly what changed and what did not.
Moving and changing are two separate steps. First the system is the same. Then it is different on purpose, and you can show exactly where. If an urgent change cannot wait, it is made on the old system first and proved there. The rule is the same either way: do not move and change in one step.
How it works →What is delivered, and what is planned.
- Scenario 1. Delivered. All five steps are in use today: 46 programs carry decision tables, 1,980 rules in all.
- Scenario 2. Steps 1 to 3 are delivered and run every week against real client code and data. Steps 4 and 5, the move of live data and the change-over, are the planned route. They have not yet been done in a live operation.
- Scenario 3. The move and the proof are delivered. The release of a change into a live operation has not yet been done.
The scenarios are illustrative. They describe kinds of work, not named clients. Figures are as at October 2026. Cobra works beside whatever conversion or transformation tooling you or your integrator choose.
What is proven, and what is not yet.
A supplier that tells you where the edge is can be checked. One that does not, cannot.
| Built and working | Yes | Everything described on this site runs today. |
|---|---|---|
| Proven against real client production code and data | Yes | Three client estates run under test every week. |
| Running a client’s live operation | Not yet | That is the next step, and we do not claim otherwise. |
Bring your own scenario.
Tell us the situation you are in. We will walk through what Cobra would do, step by step, on a sample of your own code.