i26g

Why the i26g Platform uses virtual machines as its infrastructure primitive rather than a Kubernetes cluster — from someone who has designed Kubernetes platforms, and chose not to build on one here.

Why the i26g Control Plane does not take its foundation on trust: you give it a bounded environment and boot one VM, and from there it verifies its preconditions and manages everything inside — VMs, networks, and the platform itself — while your infrastructure stays yours.

Why Retail Systematic Trading became i26g, Independent Systematic Trading: the word that was wrong, the alternatives I weighed, the numeronym, the domains, and what changed with the name.

A file-first architecture for market analysis: Parquet as the authoritative data layer, DuckDB for SQL queries, and versioned JSON and YAML for application state — plus the consistency boundaries that determine when a catalog like DuckLake becomes worthwhile.

Choosing the Python web framework for the RST Platform's human interface: server-rendered HTML, HTMX for server interaction, and Alpine.js for browser-local state, with HTMX and Alpine kept independent of whichever framework is chosen. Django, FastAPI, Flask, and Litestar compared against that boundary rather than generic feature checklists. Current hypothesis: Flask — provisional, and revisited if authorization, forms, or APIs outgrow it, or if the interface itself eventually outgrows Python.

A structured, audience-first domain decision for a self-hosted retail trading platform — from ideal customer and TLD assessment through name candidates and availability to the final pick.