A narrow, observable, adapter-bounded modernization layer

The architecturally honest options for Informix 4GL modernization are these. Full rewrite — multi-year, open scope, business- logic rediscovery, no guarantee of feature parity. Vendor screen- scraper — opaque, brittle, indefinite licence dependency, dictated upgrade cadence. Status quo — works fine until the people who can read 4GL retire. Nexus is a fourth option whose architectural shape exists precisely because none of the first three was acceptable.

Shape: observer over PTY, not interceptor in runtime

The product boundary is drawn at the PTY. Anything inside is the 4GL’s domain; anything outside — observation, rendering, audit, transport, policy — is Nexus’s. The boundary is deliberately narrow. Crossing it (modifying the 4GL, intercepting business logic, replicating runtime state) is explicitly out of scope. The unmodified-runtime guarantee is not an aspiration; it is enforced by where the architecture draws its lines.

Authority order is not negotiable

Runtime wins over backend; backend wins over front end. The front end observes and renders; it never independently initiates. A button click in the browser is a keystroke forwarded to the PTY, and the resulting screen change is observed in the PTY output — not predicted in the browser. Any feature whose correctness depends on the front end or backend overruling the runtime is, by construction, not implementable in this platform.

Runtime-neutral core with a pluggable adapter

The core platform (sessions, synchronization, audit, policy, security, replay, front end communication) has no knowledge of Informix 4GL specifics. Runtime-specific behaviour (.per parsing, .frm decompilation, terminal decoding, validator dialects) lives inside a runtime adapter loaded at startup. Adapters version independently from the daemon; a daemon refuses to start with an adapter whose declared API version does not match its own. The first adapter targets Informix 4GL — but the core makes no assumption that there will only ever be one.

Standards-grade transport and protocol

TLS-mandated WebSocket transport (RFC 6455), mandatory client masking, structured framing, versioned protocol negotiation. A daemon may serve multiple front end protocol versions simultaneously during a rolling upgrade; an unsupported version is a clean refusal, not a silently degraded session.

Presentation overrides are operator-owned, runtime-isolated

Every customisation an operator can make through the in-browser Designer or Theme editor lands as YAML — form_overrides: for label / hidden / order / position changes, chrome: for theme chrome, themes[] for full named theme alternates. The runtime sees none of it. A reorganised form looks different in the browser; the 4GL still believes its fields are in the order the .per file declared. This is “UI is a detective, not a director” expressed as schema: the override schema is purely presentation- side, and the parser refuses anything that would require changing runtime behaviour.

Exit paths are real

Because the platform observes rather than rewrites, the exit path is mechanically simple: stop the daemon and the 4GL is reachable via its terminal interface exactly as it always was. There is no data captured by the platform that the 4GL did not already own. There is no schema the platform imposes. There is no runtime contract the application depends on. Vendor lock-in is bounded by what the platform adds (browser UI, audit, replay) and reverts cleanly when removed.

Where it fits in a target architecture