Bring one translated module. We tell you if it still does the same thing, or show you exactly where it differs.

THREE PILOTS, ONE METHOD

Each pilot ends with a verification dossier your team can re-check.

1. ENTRY PILOT

   Code verification

   Does the translation you received still do what the original did?

   YOU RECEIVE

   • First, a traceability audit report: what the translation’s own documents claim, checked against the code.
   • Then, per module, the exact input where it differs, or not decided with the reason. Same-behavior answers are suspended while we rebuild them.
   • Every difference, with what you need to replay it on your compiler and on the new code.
   • The scope, and the compiler and CICS assumptions each answer depends on.

   SUCCESS MEANS

   Every module has one of the three answers, every difference replays on your side, and what was not covered is written down.

   LIMITS, IN WRITING

   Answers hold against our model of the original program, not every compiler or CICS configuration. No third-party replay yet.

2. PILOT · CRITICAL ACTIONS

   Verifiable authorization

   Does this critical action follow your rules, every time it is requested?

   YOU RECEIVE

   • Your rule written as logic, with the readings we chose.
   • A result per property: proven, refuted with the exact sequence that breaks it, or not demonstrated with the reason.
   • The gate in front of the action, and a sealed record of every decision.

   SUCCESS MEANS

   Your risk team re-derives the decisions from the sealed records on its own machine, and every gap the solver found is fixed or accepted in writing.

   LIMITS, IN WRITING

   Holds where the action can only run through the gate, within the model and bounds the dossier states.

3. PILOT · SECURITY FIXES (C)

   Fix verification (C)

   Does each fix remove the failure its vulnerability causes?

   YOU RECEIVE

   • Per fix: the test harness, the bounds, and one result (closed, test fooled, or not analyzed) with the reason.
   • The decoy fixes the test had to reject, and the commands to re-run everything.

   SUCCESS MEANS

   Every fix has one of the three results, and nothing is reported as closed unless the test also rejected the decoys.

   LIMITS, IN WRITING

   A bounded check of the failure our test exhibits, not of every way an attacker reaches the code. Our C verdict judge is being rebuilt; results are reported as bounded checks, not complete proofs.

HOW THE AUTHORIZATION PILOT RUNS

1. 01

   Pick the action

   One action type your agents or scripts already run — a transfer, an access grant, a deletion, a deployment — and the rules that govern it today.

2. 02

   Prove the policy

   We encode the rules, search for sequences that pass every rule yet break the intent, and prove the corrected policy holds.

3. 03

   Enforce and seal

   The gate runs in your environment, in front of the action. Every decision, allow or block, is sealed.

4. 04

   Verify without us

   Your risk team or auditor re-checks the certificate and the records on their own machine.

WHAT A PILOT WILL NOT TELL YOU

Four things, said before you ask.

1. 1

   Whether the old program was right.

   We check that the new code does what the old one did, quirks included. Whether the old behavior was the right one stays yours to judge.

2. 2

   Whether your rule is the right rule.

   It shows exactly what your rule allows, including what nobody meant it to allow. Choosing the rule stays yours.

3. 3

   Anything about actions that bypass the gate.

   The proof holds where the action can only execute through the gate. The certificate states that boundary.

4. 4

   Whether what the caller declares is true.

   A declared window or population is sealed with the verdict, not checked against your systems. A consistent lie is on the record, not prevented.