Are these real client projects?

No. They are independent open-source forks published by Genyra as engineering demonstrations. Each one re-engineers an existing open-source application whose original author and licence are retained. No client work is shown in the Lab.

What does "verified byte for byte" mean here?

After each step of a deterministic run, every output file or table record of the reconstruction is compared with the running original as raw bytes. No fields are normalised or removed, and there is no monetary tolerance. The count of comparisons and the failures, zero in the published runs, are recorded in a verification file in the repository.

Can I run the verification myself?

Yes. Each repository has a make verify target that checks the pinned original's hash, compiles and runs it alongside the Rust implementation and regenerates the evidence. The COBOL projects need a current Rust toolchain, Python 3.10 or later and GnuCOBOL. GitHub Actions runs the same job on every push.

Does the 96.87% lower CPU figure mean Genyra Snitch is 32 times faster?

No. It means the native application consumed 96.87% less CPU time than the original during a documented five-minute Linux measurement with different capture configurations and incomplete feature parity. Lower resource use is not the same as higher throughput, higher frame rates or equal functionality, and the report says so.

Do you modernise COBOL to Rust for clients, or only to Java?

The target language is chosen for the system, not by habit. The Lab shows Rust reconstructions because exact decimal arithmetic, record-level control and a dependency-free runtime make the proof clean. A client engagement starts with the existing system, its records and its numerical contract, and the target follows from those.

Genyra/Engineering Lab

Genyra Engineering Lab

Real software. Real engineering. Verifiable results.

Explore the engineering behind Genyra. From reconstructing legacy business systems to developing native applications, our published work demonstrates the methods, implementations and verifiable results behind our technology.

DISCOVER

Read the original: rules, records, interfaces, numerical behaviour.

RECONSTRUCT

Rebuild the logic natively with explicit arithmetic and the same layouts.

VERIFY

Run both on the same inputs and compare the output as bytes.

DELIVER

A runnable application with its evidence, source and limits published.

Explore the engineering Discuss a project

A / INTRODUCTION

Engineering you can inspect. Results you can reproduce.

A service page can only describe what a company does. The Lab shows it. Each project here is a public repository under Genyra's GitHub organisation: an existing open-source application, independently re-engineered by Genyra, with the original kept intact and attributed, and a comparison harness that anyone can run.

The four projects are examples of disciplines, not the limits of the practice. Three are legacy reconstructions, because that is where exactness matters most and is hardest to prove. One is a native application with measured resource use. Evidence on this page was reviewed on 4 November 2026; the repositories remain the source of truth.

From legacy to native

Discover. Reconstruct. Verify. Deliver.

The same four stages carry every Lab project, from a thirteen-program ledger to a native desktop. The passages below are taken from the repositories, not written for this page.

Investigate the original application.

Before a line is rebuilt, the original is read as a system: what it computes, in what scale, with which rounding, into which record layouts, through which workflows. The findings become a conversion report, not a slide.

Business rules
Source code and copybooks
Dependencies between programs
Record layouts and encodings
Interfaces and workflows
Numerical behaviour

The original rule · COBOLCOBOL-BANKING/src/INTEREST.cob

01  WS-INTEREST            PIC S9(10)V99 VALUE 0.
01  WS-ANNUAL-RATE         PIC 9V9(4) VALUE 0.
*>   Monthly interest = balance * annual_rate / 12
    COMPUTE WS-INTEREST ROUNDED =
        WS-A-BALANCE(WS-ACCT-IDX) * WS-ANNUAL-RATE / 12
    END-COMPUTE.

A picture clause fixes the scale; ROUNDED fixes how the last cent is decided. Both must survive the move.

Implement the behaviour in a modern language.

The architecture is native: one binary, explicit data structures, explicit arithmetic. Where the original truncated, the reconstruction truncates; where it rounded, it rounds the same way, at the same field. Errors are rejected, not reproduced as undefined behaviour.

Native program architecture
Data structures with the original field names
Explicit decimal arithmetic
Interface design: JSON commands, CLI
Error handling with rollback
Business-logic preservation

The reconstruction · RUSTsrc-rust/decimal.rs

pub fn ratio(self, n: i128, d: i128, mode: Rounding) -> Result<Self> {
    Self::new(divide(
        self.units
            .checked_mul(n)
            .ok_or("decimal intermediate overflow")?,
        d,
        mode,
    )?)
}
pub type Money = Decimal<2, 12>;

Integer cents, a checked i128 intermediate and an explicit rounding mode: no binary floating point anywhere in a monetary path.

A runnable application with traceable evidence.

Each project ships as an independently runnable program with its original kept intact and attributed, its upstream revision pinned, its evidence published as data and its limitations written beside its results.

make demo, no legacy toolchain required
make verify regenerates the evidence
Pinned upstream revision and SHA-256 checks
Original licence and author retained
Reports that state the boundary of the claim

Run a demonstrationlegacy-ledger-rust

git clone https://github.com/GenyraLLC/legacy-ledger-rust.git
cd legacy-ledger-rust
make demo    # Rust only

The ledger demo builds the release binary, runs five simulated banking days, posts fees and interest, prints a ledger and runs the payroll batch, with no COBOL compiler installed.

B / FEATURED MODERNISATION

Inside a legacy modernisation.

Legacy Ledger & Payroll is the flagship case. Thirteen COBOL programs, a six-node banking simulation and a payroll pipeline, reconstructed in Rust and run side by side with the originals on the same inputs under a fixed clock. After every step, every file is compared as bytes. There is no tolerance to hide behind.

What the comparison protects is behaviour: the scale of every amount, the rounding of every last cent, the layout of every record and the order of every journal. What it exposes is also behaviour, including the original's documented defects, which are preserved and listed rather than silently corrected.

Inside a legacy modernisation · Legacy Ledger & Payroll

Thirteen programs, one binary,
every file compared.

Select a program to see what it carries, which Rust module now carries it and what the harness compares afterwards. Roles and retained quirks are taken from the repository's README and conversion report.

13COBOL programs, nine banking and four payroll
5,000+lines of original COBOL read, rules and layouts recovered
5Rust modules: bank, payroll, decimal, records, main
2,174exact file comparisons, 0 failures

Banking · six-node simulation

Payroll · 25 employees

banking programINTEREST.cob

INTEREST

Monthly interest: balance × annual rate ÷ 12, with COMPUTE ROUNDED deciding the last cent.

Rust: src-rust/bank.rs + decimal.rs
Compared: Rounded interest in every account record and journal line

Every comparison is raw bytes after the step, under a fixed clock, with no normalised or removed fields. verification.json · MIGRATION.md

C / SOFTWARE ARCHAEOLOGY

Software archaeology, as practised.

Before anything is rebuilt, the original is read. Business rules, source, copybooks, record layouts, interfaces, numerical behaviour and operational workflows are recovered and written down. In each Lab project that reading became a conversion report that states what was found, what was kept, what was changed and why.

The method is visible in the small things. A ROUNDED phrase on one COMPUTE decides cents on every account. A booking screen that reads one variable and searches another is a real input sequence the harness must reproduce. A floating-point COMP-2 stack means a modern decimal result can be more correct and still differ.

Pinned upstream revisions with SHA-256 checks before every comparison.
Conversion reports that separate retained quirks from intentional changes.
Observation-only instrumentation of the original, never a patched rule.
Proof bounded to the stated corpus, compiler and scope.

D / BUSINESS APPLICATION RECONSTRUCTION

Rebuilding an interconnected business application.

Hotel Operations is a 3,067-line COBOL simulator with eight operating areas that depend on one another: a reservation changes a room, a check-in changes a stay, a service changes an invoice, a checkout changes loyalty. Genyra rebuilt it as native Rust with a JSON command interface and persistent state, then compared every active table record with the original across 155 scenarios.

The point is not the hotel. It is that modernisation means understanding the relationships between processes, records and calculations, and proving that they still hold.

Business workflow · Hotel Operations

Reservation → Check-in → Services →
Billing → Checkout.

Follow one stay through the application. The record uses the original COBOL field names; the amounts are the ones the conversion report asserts exactly for its worked example.

Reservation · record stateCOMMANDS.md

R-BASE-HAB: 267.00
R-SUPL-REGIMEN: 45.00
R-SUPL-EXTRA: 22.50
R-DESCUENTO: 40.14
R-BASE-IMPONIBLE: 294.36
R-IVA: 29.43
R-TOTAL: 323.79
R-PAGADO: 0.00
R-PENDIENTE: 323.79
R-ESTADO: P (pending)
H-ESTADO: O (occupied)

Room 101 for a Gold client, three nights, one adult and one child on the AD plan. The room charge, the meal-plan and child supplements, a 12% loyalty discount on the subtotal, then 10% tax on the discounted base. Every multiplication truncates toward zero at its receiving field, as the COBOL does.

Amounts from MIGRATION.md; state comparison recorded in verification.json. A demonstration, not a live reservations system.

E / NUMERICAL CORRECTNESS

Numerical correctness, tested two ways.

COBCALC is deliberately small: a COBOL expression evaluator. It is here because it isolates a question every financial migration must answer. The original computes in binary floating point. The Rust reconstruction computes in explicit decimal with a stated precision and rounding rule. So the Lab tests it twice, and never mixes the results: exactly against an independent decimal reference, and within a stated tolerance against the running original.

Code reconstruction · COBCALC

The same grammar.
A different kind of number.

Left, the original's evaluation of a multiplication on its COMP-2 floating-point stack. Right, the Rust level that replaces it, where every result passes through a bounded decimal context.

Original · COBOLcobcalc.cob

03 EXP-RS COMP-2.
WHEN ('TERM3')
  PERFORM 1770-POP-OP
  EVALUATE (EXP-OP)
    WHEN ('*')
      PERFORM 1840-POP-RS
      MOVE EXP-RS TO EXP-WORK-RS-A
      PERFORM 1840-POP-RS
      MOVE EXP-RS TO EXP-WORK-RS-B
      COMPUTE EXP-RS = EXP-WORK-RS-B * EXP-WORK-RS-A
      PERFORM 1630-PUSH-RS

Operands are popped from a COMP-2 stack, which is binary floating point. Precedence lives in the mode transitions.

Reconstruction · Rustsrc/lib.rs

fn term(&mut self) -> Result<Number, Error> {
    let mut value = self.power()?;
    loop {
        if self.take(b'*') {
            let rhs = self.power()?;
            value = self.finite(value * rhs)?;
        } else if self.take(b'/') {
            let rhs = self.power()?;
            if rhs.is_zero() {
                return Err(self.error("division by zero"));
            }
            value = decimal_math::division(&value, &rhs)
                .map_err(|message| self.error(message))?;
        } else {
            return Ok(value);
        }
    }
}

Each grammar level is a function; every result passes through the bounded decimal context. Division by zero is an error with a column, not a NaN.

Execution flow · 2^3^2select a step

34 significant digits, half-even, with a 50-digit working context for the operations that cannot be exact. src/decimal_math.rs

Recorded demonstration · make demoREADME

Expression	Rust output
2+3*4	14.00000
(2+3)*4	20.00000
2^3^2	512.00000
SQRT(144)+1,000/4	262.00000
-2^2	4.00000
(5/1200250000((1+5/1200)^(3012)))/(((1+5/1200)^(3012))-1)	1342.05405

Recorded from the published Rust binary in the original's five-place display. The last line is the original author's mortgage-payment example. 0.1+0.2 prints 0.3, where the original prints 0.29999: the one intentional difference, documented in MIGRATION.md.

F / NATIVE SYSTEMS ENGINEERING

Architecture makes the difference.

Genyra Snitch takes the practice from legacy business systems into modern application architecture: operating-system integration, network capture and a native desktop. The Python collector was replaced with Rust; the Electron interface is being replaced with a native Rust desktop. Both were measured against the original for five minutes on Linux, with every process counted.

The figures are large and they are qualified. They describe resource consumption under the documented conditions, not equal functionality, equal rendering cadence or a universal speed-up. The exhibit shows the conditions and the limits beside the numbers.

Measured on Linux · 2026-11-04

Architecture makes the difference.

See how Genyra's native reconstruction performed against the original application in documented Linux resource comparisons. Lower resource use under these conditions; not a claim of equal functionality or higher frame rates.

Complete applicationDesktop open, graph view, including every collector, frontend and helper process.

Average CPU · 100% = one logical core

−96.87%LOWER

Original324.33%

Genyra native10.16%

Mean summed RSS · resident memory summed over every process

−86.57%LOWER

Original1279.49 MiB

Genyra native171.89 MiB

Mean summed PSS · shared pages apportioned

−84.94%LOWER

Original755.24 MiB

Genyra native113.77 MiB

9 → 2processes counted

92.97 / 18.44 MiBRSS growth during the window, original / native

300 ssample after 45 s warm-up, one sample a second

116.39 → 38.16/sUI callbacks, Electron rAF → native egui; a lower cadence, not normalised

Exact values and build identities

Measurement	Original	Native	Reduction
Average CPU	324.33%	10.16%	96.87%
Mean summed RSS	1279.49 MiB	171.89 MiB	86.57%
Mean summed PSS	755.24 MiB	113.77 MiB	84.94%
RSS at start	1221.71 MiB	162.80 MiB
RSS at end	1314.68 MiB	181.23 MiB
Highest sampled RSS	1316.69 MiB	183.23 MiB

Original Snitch 1.6.4 at 062f2a8, Electron 44.9.1. Native desktop 0.1.0-alpha.5 at 375ce8c; collector 0.1.0-alpha.2 at c120556. Host: Intel Core i9-14900K, 32 logical CPUs, NVIDIA GeForce RTX 4080 SUPER.

Method, provenance and limitsfull report

Test conditions

Linux x86-64, Intel Core i9-14900K (32 logical CPUs), NVIDIA GeForce RTX 4080 SUPER.
300-second sample after a 45-second warm-up, one sample per second, concurrent real traffic on the same interface.
Native source commit 375ce8c; original Snitch 1.6.4 at 062f2a8, Electron 44.9.1.
Both windows 1440 × 1040 logical pixels, dark mode, English, graph view; collectors had CAP_NET_RAW only.
Capture policies differ: native non-promiscuous 4,096-byte IPv4/IPv6/ARP; original promiscuous 65,535-byte IPv4/IPv6.

What the figures do not establish

Measured resource consumption under the documented conditions. Not proof of equal application performance, identical functionality or higher rendered frame rates.
The native desktop ran a lower update cadence (38.16 callbacks a second against Electron's 116.39); the CPU result is not normalised to equal rendering.
Feature parity is incomplete and capture configurations differ. Linux measurements do not transfer automatically to Windows or macOS, where native builds pass CI but live capture and privileged features remain under validation.

G / HOW WE VERIFY

How we verify.

Each result belongs to its stated source revision, corpus and comparison method, and the Lab names the method every time a figure appears. These are different standards and they are never added together.

Exact byte-for-byte comparison: files or table records compared as raw bytes with no normalised fields and no monetary tolerance.
Exact-decimal reference testing: results compared as decimals against an independent implementation, with zero tolerance.
Tolerance-based numerical compatibility: agreement with a floating-point original within a stated bound. Compatibility, not equality.
Functional and synthetic tests: native unit, workflow and service-lifecycle tests, which prove the code paths they cover.
Real runtime measurement: sampled CPU and memory under documented conditions, with the conditions published.
CI build success and experimental platform support: that a build passes on a platform, which does not establish feature parity there.

H / EXPLORE THE SOURCE

Explore the source.

Every repository keeps the original author's code, licence and attribution, pins the upstream revision it was built from, publishes its verification results as machine-readable files and runs the same verification in GitHub Actions. The links on each project page go to the code, the evidence file, the conversion or benchmark report and the latest workflow run.

Legacy modernisation

Legacy Ledger & Payroll

Reconstructing business-critical logic without losing the behaviour that matters.

2,174Exact file comparisons · Exact byte-for-byte comparison Business application reconstruction

Hotel Operations

Modernising an interconnected business application while preserving operational behaviour.

155Operational scenarios · Exact byte-for-byte comparison Numerical correctness

COBCALC

Understanding the original. Reconstructing the logic. Verifying the result.

1,000Exact-decimal cases, zero failures · Exact-decimal reference test Native systems engineering

Genyra Snitch

Native architecture. Measurable engineering improvements.

96.87%Lower average CPU, complete application · Real runtime measurement

I / WORK WITH GENYRA

Work with Genyra.

A company looking to modernise a legacy application should leave this page understanding that Genyra can investigate the existing system and build a testable modern replacement. A company considering native development should understand that Genyra can redesign an application's architecture, build native interfaces and measure the result. The first conversation establishes what is known, what must be proven and what a useful result would be.

Before an enquiry

Questions we are asked.

Short answers in the same terms as the page. Anything specific to your systems is agreed by enquiry.

Are these real client projects?: No. They are independent open-source forks published by Genyra as engineering demonstrations. Each one re-engineers an existing open-source application whose original author and licence are retained. No client work is shown in the Lab.
What does "verified byte for byte" mean here?: After each step of a deterministic run, every output file or table record of the reconstruction is compared with the running original as raw bytes. No fields are normalised or removed, and there is no monetary tolerance. The count of comparisons and the failures, zero in the published runs, are recorded in a verification file in the repository.
Can I run the verification myself?: Yes. Each repository has a make verify target that checks the pinned original's hash, compiles and runs it alongside the Rust implementation and regenerates the evidence. The COBOL projects need a current Rust toolchain, Python 3.10 or later and GnuCOBOL. GitHub Actions runs the same job on every push.
Does the 96.87% lower CPU figure mean Genyra Snitch is 32 times faster?: No. It means the native application consumed 96.87% less CPU time than the original during a documented five-minute Linux measurement with different capture configurations and incomplete feature parity. Lower resource use is not the same as higher throughput, higher frame rates or equal functionality, and the report says so.
Do you modernise COBOL to Rust for clients, or only to Java?: The target language is chosen for the system, not by habit. The Lab shows Rust reconstructions because exact decimal arithmetic, record-level control and a dependency-free runtime make the proof clean. A client engagement starts with the existing system, its records and its numerical contract, and the target follows from those.

A CLEARER NEXT STEP

Discuss a project

From an unanswered question
to an engineered possibility.

Discuss a project

Real software. Real engineering. Verifiable results.

Engineering you can inspect. Results you can reproduce.

Discover. Reconstruct. Verify. Deliver.

Investigate the original application.

Implement the behaviour in a modern language.

Compare against the original, on the same inputs.

A runnable application with traceable evidence.

Inside a legacy modernisation.

Thirteen programs, one binary,every file compared.

INTEREST

Software archaeology, as practised.

Rebuilding an interconnected business application.

Reservation → Check-in → Services →Billing → Checkout.

Numerical correctness, tested two ways.

The same grammar.A different kind of number.

Architecture makes the difference.

Architecture makes the difference.

Average CPU · 100% = one logical core

Mean summed RSS · resident memory summed over every process

Mean summed PSS · shared pages apportioned

How we verify.

Explore the source.

Legacy Ledger & Payroll

Hotel Operations

COBCALC

Genyra Snitch

Work with Genyra.

Discuss a project

Thirteen programs, one binary,
every file compared.

Reservation → Check-in → Services →
Billing → Checkout.

The same grammar.
A different kind of number.