Execution model

Stance: the rules govern evidence, not technique

These rules exist to keep every claim true. They do not rank techniques. Emitted machine code, direct system calls, raw kernel interfaces, replacing a runtime component, and racing a production compiler are all admissible when the work is:

1. derived from a pinned specification or source at an exact revision;
2. checked by an independent implementation used only as an oracle, never as a producer;
3. proven on hardware with a result for the same artifact, on every backend it claims; and
4. stated with its claim boundary: what it proves and what it does not.

Compilers and runtimes are competitors and oracles, not authorities. Kokoro-Hexagon's results at commit 250e10dc record a PowerShell-lowered kernel running 2.21–2.30x faster in DSP ticks than Hexagon Clang 19.0.04 output, bit exact, on SM8550 and SM8635.

When a rule blocks work that meets all four conditions, report the rule and propose a precise change to it. Do not refuse silently, and do not work around it silently.

Execution model: PowerShell orchestrates, lowered code runs hot paths

Pwsh's performance comes from lowering, not from interpreting faster.

• PowerShell running through SMA's dynamic dispatch is the control plane: lifecycle, event dispatch, scheduling, composition and damage decisions. It is never on a per-frame, per-cell, per-glyph or per-sample path.
• Hot paths are authored in PowerShell and lowered. When lowering happens follows from when its inputs are known:
  • At APK build time, when the code and its shapes are fixed then: IL through persisted LINQ expression trees, machine code from named encoders (the roadmap gates N2-N3), or shaders. It costs nothing at startup, is checked by the build, and ships signed in the APK.
  • On the device at run time, when the shape depends on what only the device knows: the user's scripts, screen and cell metrics, fonts, loaded data. PowerShell builds and validates an expression tree and compiles it to IL; RyuJIT turns it into machine code once per process. The cost is paid once and amortized; the code lives in process memory, not in the signed APK.
  • On the device, persisted: when device-dependent code is stable across runs, lower it once, write it as an IL-only managed assembly in the app's private storage (internalDataPath), admit it by manifest and hash, and load it at the next process start. The cost is paid once per change, not once per process. Kokoro-Hexagon's Model.Store.psm1 is the admission precedent. Policy supports it: an app reads its own data files (untrusted_app_all.te:27) and may JIT into executable memory (app.te:199); system/sepolicy 7595d4f4.
  • Native machine code is emitted only by the build machine and reaches the device only through the package installer: in the APK, or later in a signed split APK added with PackageInstaller.MODE_INHERIT_EXISTING (PackageInstaller.java:2227). Installed code lives in /data/app (apk_data_file), which apps may map and execute (app.te:427) and may never write (public/app.te:108-110). The app never writes machine code itself: mapping an app-written file as executable is audited (untrusted_app_all.te:28), execve of one is forbidden from target SDK 29 as a W^X violation (app_neverallows.te:60-69), and persisting JIT output would re-create ReadyToRun on the device.
• Pwsh updates itself by artifact type. IL: lowered on the device (or supplied by the paired PC), stored in private storage, admitted by hash, promoted by an atomic active pointer, and loaded at the next process start. Machine code: lowered by the paired Windows PC from what the device reports (hot paths, timings, ISA), signed there with the release key, which never leaves the PC, and installed as a split APK. Emitted IL binds native code by function pointer, so neither path needs ReadyToRun.
  • A path fixed at build time is never deferred to run time, and a path that depends on device state is never forced into the APK.
• Work that the platform already does well (composition, rasterization on the GPU) is handed to it.
• Drawing is damage-driven. A state change records damage; lowered code turns damage into pixels; nothing redraws unconditionally or on a timer.
• A new hot path names its lowering target and its measurement before it is built.