Oninit® BLT — The Evidence-Cited Bridge from Legacy 4GL to a Modern Stack

Most plans for "what do we do about the old Informix 4GL application" look the same: a multi-year freeze on changes, a parallel rewrite team working from interviews and screenshots, and a high-risk cutover at the end. BLT is the alternative that turns the existing codebase into a first-class input to the modernisation plan, not a black box that the new team has to reconstruct from the outside.

Two outputs, two consumers

The same recovery pipeline produces two complementary artefacts. The audit-grade spec.json carries every claim with its evidence trail, confidence level, and review-item routing — the form a human reviewer or a compliance team needs. Alongside it, a streamlined code_spec.json drops the audit surface and keeps only the structural shape an LLM needs to regenerate the application in a target language. One walk, two consumers, no second extraction.

Evidence-cited claims, not opinions

Every workflow, field, rule, database operation, message, and transaction in the spec is linked back to one or more underlying evidence facts — a source line, a schema row, a binary symbol, a string constant. Anything inferred without direct evidence is flagged with a confidence level. Low-confidence and unresolved findings surface in a separate review queue rather than mixing silently into the main output, so the boundary between "established" and "needs judgement" is explicit.

Three extraction modes for three risk postures

Strict mode requires a non-stripped binary and aborts on the first missing symbol — the right setting when you need deterministic, "no inference past the evidence" output for an audit record. Recovery (the default) tolerates stripped binaries and continues with best-effort markers. Forensic opens the door to deeper analysis and speculative low-confidence claims for investigative work where partial information is better than none. The mode is part of the configuration and travels with the output; re-running the same input against a different mode is one config edit away.

Deterministic, diffable output

Identical inputs and configuration produce byte-identical output. That makes spec.json a safe CI artefact: pin it, regenerate it on every code change, and let the diff highlight which workflows, rules, or DML operations actually moved. The structural digest is path-free so it stays stable across machines.

Pluggable analyzers

The pipeline ships with analyzers for each input kind — 4GL source, form specifications, SPL stored procedures, schema DDL, and compiled binaries. Additional analyzers register via a standard entry-point group; an in-house extension for a custom 4GL dialect, a vendor-specific binary format, or a separately-stored form / report dictionary slots into the same pipeline without forking the engine. The evidence-store shape is the integration contract.

Where it fits in a target architecture

• Modernisation: the JSON projection feeds a code-writing LLM to produce a first-cut implementation in the target language and stack, with the spec as the ground truth for review.
• Audit and compliance: an evidence-cited, deterministic record of what every screen, function, and transaction in the application does — durable and re-runnable.
• Documentation: the human-readable Markdown projection captures the application's behaviour without depending on the original developers' memory.
• Verification: deterministic output makes BLT safe to run in CI; a regression in the application surfaces as a diff in the spec.

If the path forward for your Informix 4GL application is modernisation, regeneration, or formal documentation, BLT is the component that turns the existing codebase into a first-class input to that path.

Next

The Overview covers the full input/output contract and the confidence model; the Worked Examples walk through cross-source corroboration, the schema-binding workflow, the STRICT-mode policy, and the stored-procedure pipeline.