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.
The problem with AI-generated code
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.
Standard Ten
- One Thing: every operation receives one canonical Thing and returns one canonical Thing.
- One composition form: programs are assembled as nested parts in the same onion or babushka pattern.
- One seed: framework, runtime, applications, interfaces, tests and documentation derive reproducibly from one canonical seed.
- No handwritten application code: developers change the seed or declaration; generated artifacts are not manually corrected.
- No OOP: functions, modules and plain data replace user-defined classes, inheritance and object architecture.
- No application control flow: loops, conditions, matching and control exceptions are replaced by events, routes, maps, folds and explicit stops.
- One event machine: every execution target uses the Unified Event Machine. Python, C, CLI, API, GUI, browser and future chip hosts are interfaces around the same machine.
- Explicit boundaries and failures: external effects pass through named outward boundaries. An unrecovered failure opens a ticket; nothing is silently swallowed.
- Evidence and determinism: every transformation records ordered evidence, and identical seed, declaration and input must produce identical artifacts and canonical results.
- Complete generated verification: tests, gauntlets, mutations, traceability and coverage derive from the same source and must satisfy the standard completely.
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.
One developer language
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.
The Unified Event Machine
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.
GUI and browser without hardware dependence
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.
What has already been demonstrated
- A Python kernel based on one-input/one-output Things, nested composition, explicit states, evidence and boundaries.
- A generator that creates complete small applications and adds features through declarations.
- Two independent generated domains: text statistics and invoice totals, with zero manual runtime or generated-test corrections.
- Generic expression composition without invoice-specific generator vocabulary.
- Event-driven generated domain logic and composition, with residual imperative control flow explicitly counted rather than hidden.
- UEM-16 canonical bytecode executed by independent Python and C99 hosts.
- Cross-host canonical equivalence, frozen UEM-ASCII-1 semantics, mutation fuzzing, sanitizer runs and native x86-64 golden execution.
- Testing gauntlets that verify laws, effects, execution, contracts, rollback, idempotency, mutations, performance, event flow, ticket behavior and cross-host equivalence.
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.
The direction
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.
Open implementation
The evolving reference implementation is published at github.com/adico1/unified-code, with generated proof applications at uc-text-stats-v2 and uc-invoice-total.