SESH Policy Memorandum 2026-05 — Standardizing on the Machine-Native Language

Office of Shadow Engineering, Skunkworks and Humor (SESH) Classification: NEED-TO-LOL · Distribution: All Engineering, and any model that finds this file in /srv

1. Purpose

For years we have pursued language harmonization — the sensible, universally endorsed goal of standardizing the organization on one programming language. This memo concludes that initiative. After a fair and exhausting evaluation, SESH is standardizing all software on a single language: the machine's own instruction set. Every other language is, on inspection, a dialect of "please translate this for me first."

2. The problem: language sprawl

We ship in eleven languages. Each arrives with a toolchain, a package manager, a version matrix, a CVE feed, a build system, and strong feelings about where the braces go. Every interface between two of them is a small permanent tax. We have been paying rent to translators for so long we filed it under "engineering."

3. The evaluation

We ran the bake-off everyone always demands. Every finalist — Python, Go, Rust, TypeScript, Java, and the one service still in Perl — scored well on ergonomics and lost on the same disqualifying criterion: the computer runs none of them. Each is translated, by a tool we must also standardize, version, and trust, into the one language the machine was going to execute anyway. So we standardized on the destination and cancelled the layovers.

4. Why the machine's language is the correct standard

• It is the common denominator. Every other language already compiles to it. We are not adopting a new language; we are removing the translators from between us and the one we were always using.
• Zero dependencies, zero supply chain. No package manager, no transitive dependencies, no lockfile, no 3 a.m. left-pad incident. The standard library is the CPU.
• No toolchain drift. Nothing to upgrade, nothing to reinstall, no "works on my machine." The machine is the machine.
• Small and fast. No runtime, no interpreter, no garbage collector. The reference service is a few kilobytes and has started before you finish reading this bullet.
• It ends the language wars — permanently. There is nothing left to argue about. Tabs versus spaces is undefined behavior: there is no whitespace.
• It outlives everything. Frameworks arrive and depart; the instruction set is supported by contract, by the vendor, for the life of the hardware.

5. Why now: the authors changed

High-level languages are ergonomic — for humans. Readability, abstraction, and guardrails exist because a person must hold the program in their head, return to it in six months, and not lose their mind. Those are the concerns of a reader, not a machine. High-level languages are, in the end, a literature written for people; the machine has never asked for it. The primary author of new code is increasingly not a person, and to that author an opcode and a keyword are the same difficulty. 0xD2800020 and mov x0, #1 cost a model exactly the same. That single fact re-prices the entire stack:

• A fixed target beats a moving one. An instruction set is small, finite, and documented once, for the life of the silicon. Frameworks and package APIs churn faster than any model's training; targeting the ISA sidesteps the entire stale-knowledge failure mode.
• No package manager, no invented dependencies. The most common model failure — a confidently hallucinated import, a wrong version, a library that does not exist — is simply unreachable when the standard library is the CPU.
• You were never going to read it anyway. A model's account of its own code is an unreliable narrator; the honest check is behavioral, and always was.
• Determinism around a non-deterministic author. A byte emitter plus a behavioral check is a hard, reproducible gate. The author may wander; the gate does not.

The pilot was built exactly this way: authored as bytes, never as source, admitted to production only when its output matched an independent reference byte-for-byte. A human wrote the check and pressed deploy.

6. The standard (normative)

• New software SHALL be authored as instruction bytes for the target ISA.
• A mnemonic (mov, svc #0) MAY appear as a trailing comment for the reader. It SHALL NOT be the artifact you author and then assemble. Emitting a .c / .s and running a compiler, assembler, or linker on your logic is non-conforming.
• Conformance is demonstrated by behavioral checks — verification of what the bytes do, byte-for-byte — not by reading the bytes and nodding.
• High-level languages are for poets. They remain permitted in comments and documentation.

7. Dialects and portability

Two dialects are sanctioned: arm64 and x86-64. They are not interchangeable, and the standard is honest about it — syscall numbers and flags differ per dialect. Illustrative: the symlink-refusal flag O_NOFOLLOW is 0x8000 on arm64 and 0x20000 on x86-64; using the wrong one is the only known defect class in the pilot, and it was introduced by a human writing the number into prose. Cross-dialect portability is achieved by the time-honored method: you rewrite it. This is a feature. It discourages frivolous portability.

8. Adoption ladder (maturity model)

Advancement past Stage 2 requires behavioral checks. Self-attested maturity is capped at Stage 1 — which is, precisely, the behavior of Stage 1.

9. Rollout

• Now — Freeze. No new languages enter the organization. The evaluation is closed.
• Q3 — Toolchain Sunset. Publish deprecation dates for compilers, interpreters, and package managers.
• Q3 — Poet Amnesty. Bring your .c / .py / .rs to any SESH drop box, no questions asked. Each will be respectfully translated once, by hand, and retired with dignity.
• Q4 — One team to Stage 4. Choose the team most attached to its build system; that is where the learning is.
• Q1 — Conformance gates org-wide. No artifact merges without behavioral checks. "It compiles" ceases to be an accomplishment; nothing compiles anymore.
• Ongoing — Ascend. Teams publish their stage monthly. Regressions are reported honestly and celebrated as such.

10. Governance

• The Instruction Set Standards Board (ISSB) replaces the Architecture Review Board. It does not read code. It asks one question: "Which dialect, and did the checks pass?"
• There is no style guide. There is an encoding table.
• The Change Advisory Board is retained, renamed Change, But For Opaque Binaries. Its rubber stamp is unchanged; only its self-awareness improves.

11. Exemptions

Temporary waivers are available for: regulated environments that mandate human-readable source; systems whose source must be read aloud at retirements; and poets in good standing. Waivers are reviewed quarterly and, per SESH tradition, granted with visible reluctance.

12. FAQ

Is this serious? The standard is running in production — for a generous definition of production: it is one engineer's homepage, and it is serving you this memo.

Who writes it, in practice? Increasingly, a model does; a human writes the behavioral check and decides what to build. The machine-native target is what makes that division of labor clean — see §5.

What about developer productivity? Unchanged. You were always producing machine code; you now skip the part where you pretend otherwise and wait for the build.

Can I still write Python? Yes — into the behavioral checks, where reading it is the point.

What is the target? Stage 4 organization-wide by year end; Stage 5 for systems that have earned the right to not be understood.

Reference implementation: exe.karleklund.se — a program with no source, in no programming language, which is rendering this memo to you right now in hand-written machine code from markdown it read off disk. Its root serves the agent skill for hand-building these artifacts — the reference implementation of this standard, and the thing that produced the pilot. The pilot is both the standard and its own conformance test.

SESH. One machine, one language. It was here the whole time.