Engineering Lab · Business application reconstruction
Modernising an interconnected application while preserving operational behaviour.
A 3,067-line COBOL hotel simulator with eight operating areas, rebuilt as native Rust with a structured command interface and persistent state. 155 operational scenarios and 7,351 exact table-record comparisons against the running original, with zero mismatches and zero monetary tolerance.
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.
01 / THE CASE
Why this case matters.
Business applications are webs, not lists. In Alejandro Blanco's COBOL hotel simulator a reservation prices a room by nights, meal plan and children, applies a loyalty discount, adds tax and sets a pending balance; a check-in changes the room state; services append to the invoice; checkout settles the invoice and earns points; reports read all of it. Modernising one area without the others breaks the whole.
Genyra reconstructed all eight areas in Rust, replaced the terminal menus with one JSON command per line, kept the original field names in every record, and added the persistence the original never had, as a separately tested feature.
02 / STATE AND MONEY
State consistency, by construction.
Every command validates before it mutates. A rejected command, whether an invalid transition, an overflowing receiving field or a malformed amount, leaves the entire in-memory state unchanged and is reported as a failure without stopping the batch. Money is integer cents parsed from decimal strings, never from floating-point JSON numbers, and every calculation truncates toward zero at the same receiving field the original truncates at.
The known Gold-client example is asserted exactly in the native tests: three nights in room 101 with one adult, one child and the AD meal plan yields 267.00 room, 45.00 adult supplement, 22.50 child supplement, 40.14 discount, 29.43 tax and 323.79 total; 100.00 of services makes checkout 433.79.
03 / BOUNDARY
The boundary of the claim.
The proof is the recorded business-state comparison across the documented workflows: complete active table snapshots, byte for byte. It is not the original's Spanish report text, not every possible command sequence, and not a live reservations or payment service. The session date is the original simulator's fixed date, and nights are supplied explicitly, as in the original.
Inspect the evidence.
Each view answers one question: what was shown, how, what Genyra built, the numbers, what has not been established, where the code is and how to run the same check yourself.
Modernising an interconnected business application while preserving operational behaviour.
A 3,067-line COBOL hotel simulator with eight operating areas, rebuilt as native Rust with a JSON command interface, persistent state and exact-cent billing, verified against the running original.
Original work: Alejandro Blanco, MIT, retained. Rust implementation and evidence: Genyra LLC. Status: Verified simulator · Rust 1.0.0.
The harness drives the running original through its real terminal workflows, runs the corresponding native commands from a fresh state, and compares every active room, client, reservation, service and catalogue record as bytes.
Standards used on this project
- Exact byte-for-byte comparison
- Functional tests
- CI build success
Recorded test conditions
- Comparison: byte-for-byte complete active table snapshots.
- Arithmetic: integer cents; i128 intermediates; truncate toward zero at original receiving fields.
- Only observation code was added to the original: DISPLAY active table fields immediately before STOP RUN.
- Session date and preloaded records are the original simulator's; nights are supplied explicitly, as in the original.
What Genyra engineered
- A native Rust implementation of all eight areas: reservations, stays, the hotel board, room management, services, clients and loyalty, billing and reporting.
- A structured JSON command interface in place of terminal menus, with every rejected command rolled back so the in-memory state is unchanged.
- Integer-cent arithmetic with i128 intermediates, truncated toward zero at the original receiving fields, as the source does.
- Optional persistent snapshots, which the original never had, implemented and tested as a separate feature.
Source passages quoted on this page
- hotel.cob · The original booking total
- src/lib.rs · The reconstruction
Figures are read from the repository's evidence file at build time; every label states which standard produced it. Figures of different standards are never combined.
- A reproducible operations demonstration, not a live reservations or payment service.
- The comparison covers the documented workflows and complete active table snapshots, not the original's terminal formatting or every possible command sequence.
- Source quirks are preserved and documented, including a booking screen that reads one room variable and searches another; the harness reproduces the real input sequence rather than patching the original.
- Persistence is single-writer with atomic file replacement; it is not a concurrent transaction service.
The full list is in the published report.
- Genyra repository · Hotel Operations, Rust implementation and harness
- Original project · COBOL hotel simulator by Alejandro Blanco, MIT, retained
- Verification evidence · machine-readable results
- Report · decisions, conditions and limitations
- Upstream revision ·
47ff6c7fce9a - GitHub Actions · the same verification on every push
Latest verification run passed · 2026-11-03 · 9979351· run
git clone https://github.com/GenyraLLC/hotel-rust.git cd hotel-rust make demo # Rust only make verify # also needs Python 3.10+ and GnuCOBOL 3.2
make verify compiles the original with bounds checks, drives its terminal workflows, runs the native commands and compares every table record as bytes. Each scenario's snapshot hash is recorded in evidence/scenarios.json. Instructions in the repository.
- State consistency
- Invalid-command handling
- Persistent snapshots
- Exact billing
- Workflow reconstruction
- Table-record verification
Questions we are asked.
Short answers in the same terms as the page. Anything specific to your systems is agreed by enquiry.
- How does the harness drive a terminal application?
- It compiles the unchanged original with bounds checking, adds a single observation that prints the active tables immediately before the existing STOP RUN, and feeds real menu input sequences. The native implementation runs the corresponding JSON commands from a fresh state, and both snapshots are compared as bytes.
- What was added that the original did not have?
- Persistent snapshots, operation-level rollback, structured queries and a JSON interface. Each is implemented and tested as a native feature and kept outside the equivalence claim, which covers the original's business state only.
Discuss legacy modernisation
From an unanswered question
to an engineered possibility.