My role
Website demonstration design and implementation
The result
The demonstration provides an inspectable route from a modern form to a native calculation. Its acceptance criteria focus on exact results and safe failure, with deployment compatibility treated as a separate operational requirement.
01
The problem
Modernizing business software often means introducing a new interface without casually changing the rules that determine money. A clean screen is only useful when the calculation and the integration contract remain explainable.
02
Operational context
This is a purpose-built demonstration with synthetic orders. It makes the boundary between a modern application and a legacy-style processing program visible: JSON, fixed-width records, native execution and parsed results.
03
My contribution
I designed the bounded record contract and the visitor-facing workflow so that inputs, transformations, calculations and failures can be inspected together. The example demonstrates an integration pattern; it does not represent a customer system or a mainframe deployment.
04
Constraints
- At most 25 order records and a 16 KiB request body.
- Integer minor units, explicit per-line rounding and no floating-point money arithmetic.
- A fixed executable with bounded input, output and execution time.
- No visitor-provided source, command, path or network target.
05
Implementation decisions
- Validate the modern input before serializing a narrow ASCII record protocol, then validate the native output before displaying it.
- Keep the business calculation in the native program. An unavailable executable produces an unavailable state.
- Expose the record representation alongside the result so that the integration boundary is inspectable.
- Keep replay information in the visitor's browser and distinguish repeated input from a changed payload using the same identifier.
06
Alternatives considered
- Reimplementing the calculation in TypeScript would hide the native integration question this example is meant to answer.
- Accepting arbitrary COBOL or shell commands would create an unrelated execution service and a much larger trust boundary.
- A floating-point total would make cent-level rounding dependent on representation rather than the declared business rule.
07
Validation approach
- Golden batches, zero and full discount, half-cent rounding and maximum allowed values.
- Malformed records, duplicate identifiers, invalid quantities and out-of-range values.
- Native process absence, timeout, oversized or corrupt output, and replay conflicts.
08
What this shows
The demonstration provides an inspectable route from a modern form to a native calculation. Its acceptance criteria focus on exact results and safe failure, with deployment compatibility treated as a separate operational requirement.
09
Limits of the evidence
- Synthetic examples establish only the demonstrated behaviour, not production scale or mainframe experience.
- Native execution depends on the configured runtime; the interface reports dependency failures instead of inventing a result.
- A browser-local replay ledger is not a shared transaction system.
Inspect the work
A similar problem in your organization?
This example can be a starting point for defining your own project, its dependencies and acceptance criteria.