Originally published on
[adico.tech]. The evolving reference implementation is on[GitHub].
My claim is simple: software can be standardized.
In the age of AI, we should not use faster code generation to multiply every historical inconsistency in software development. We should rewrite software toward one unified standard so that humans and AI generate the same best-practice structure every time.
Mathematics gained enormous computational power when Wolfram built a coherent symbolic language around mathematical objects and operations. Software development now needs the equivalent: one language, one machine model, one composition process, one evidence trail, and one standard from the first seed to the final running system.
AI can generate code quickly, but speed alone does not create coherence. Without a governing standard, every model can fall back to ordinary development: different signatures, object hierarchies, handwritten glue, loops, conditions, duplicated interfaces, platform-specific implementations, and tests added after the architecture has already diverged.
That is not the future I want. AI should not merely imitate the accumulated habits of the software industry. It should generate from a smaller, deterministic, and verifiable foundation.
Conventional development is not an authorized fallback. If Standard Ten cannot express a requested feature, the system reports standard.gap
. The standard must be extended generically before the feature is implemented.
The developer should not switch languages when moving between the kernel, application, API, GUI, browser, tests, and deployment. The unified development surface is a constrained Python language: functions, modules, canonical Things, event declarations, route tables, and interface trees.
Physical platforms may require UEM bytecode, WebAssembly, native machine code, HTML, CSS, or C. These are generated physical artifacts, not additional developer languages. Developers write one Python seed; the system generates the required targets.
There is no native machine language supported directly by every processor. Therefore, the project defines a small chip-neutral virtual machine: UEM-16.
LOAD READ WRITE DELETE
EMIT ENQUEUE DEQUEUE ROUTE
APPLY MAP FOLD VERIFY
TICKET OUTWARD ACK STOP
Applications contain no direct loops or conditions. Selection and iteration are confined to named, contract-tested machine primitives. External effects are requests handled by host boundaries. Expected validation failures remain domain results; unrecovered runtime failures create redacted, deduplicated ticket events.
The VM interface is also data. A single interface Thing describes windows, controls, layout, state, evidence, tickets, and a browser surface. Native windows, browser windows, remote control, and headless tests are adapters around the same interface protocol.
physical input
→ normalized interface event
→ UEM route
→ new interface Thing
→ outward render request
No widget contains application decisions. Browser navigation, clicking, typing, reading, and screenshots are explicit outward requests whose results return as canonical events.
The project does not yet claim support for every chip. ARM64, RISC-V, and microcontroller support should be claimed only after unchanged golden vectors run on physical target hardware. The distinction between demonstrated results and future proof is part of the standard.
AI should generate software the way a deterministic mathematical system evaluates expressions: from a small canonical vocabulary, under explicit laws, with reproducible results and complete verification.
The target pipeline is:
one Python seed
→ Standard Ten declarations
→ UEM-16 canonical bytecode
→ verified host adapter
→ GUI, browser, API, CLI, or physical processor
We should not ask AI to write millions of incompatible programs faster. We should ask AI to regenerate software into one coherent form—and prevent it from falling back when the standard exposes a missing capability.
This is the claim: in the age of AI, the world's code can and should be rewritten toward a unified Standard Ten.
The evolving reference implementation is published at github.com/adico1/unified-code, with generated proof applications in the repository.