Rothalyx is organized so that a single native core powers the desktop app, the CLI, the SDK, and automation. The architecture doc states the rule directly: if a capability must exist in more than one interface, it belongs in the core first. This article describes how that rule is expressed in the source tree and what it buys.

The core lives under core/ and is decomposed by pipeline stage: loader, memory, disasm, cfg, ir, ssa, analysis, type, decompiler, debugger, database, and sdk. The applications, apps/desktop_qt and apps/cli, do not reimplement analysis; they drive the core and render or serialize its results. The desktop split is explicit: a Qt Widgets GUI over a C++ application layer over the C++ core, with embedded Python as an extension surface rather than part of the main execution path.

The practical consequence is behavioral consistency. Because the CLI’s rothalyx_cli, the desktop app, and the SDK’s analyze_binary all invoke the same pipeline, recovered structure should not depend on which surface produced it. The cost is discipline: a GUI-only feature is disallowed by construction, since the capability must first exist in the core. Whether cross-surface equivalence is verified by an automated test is Additional validation required; the design guarantees the intent, not the measurement.