While building ten calculator variations beside the Unified Code project, I
found a defect that passed every visible demonstration: the applications
worked, but the generator already contained their real behavior.
The JSON seed said:
{
"functions": ["payment", "mean", "determinant2"]
}
The formulas for those functions were handwritten inside the generator. The
seed selected implementations; it did not define them.
That distinction matters.
configuration
→ chooses behavior that already exists elsewhere
semantic seed
→ defines behavior that a compiler manifests
The failed design
The first generator knew financial formulas, statistical operations, matrix
operations, unit conversions, graphing behavior, and stack-calculator behavior.
Adding a genuinely new mathematical function required changing Python code in
the generator and then adding its name to JSON.
The generator was therefore an application library disguised as a generic
generator.
The output was generated, but its authority was divided:
seed: names and presentation
generator: application meaning
The correction
The calculator seed now contains structured semantic declarations. For
example, a two-by-two determinant is represented as an expression tree:
{
"id": "determinant2",
"parameters": ["a", "b", "c", "d"],
"body": {
"subtract": [
{
"multiply": [
{"parameter": "a"},
{"parameter": "d"}
]
},
{
"multiply": [
{"parameter": "b"},
{"parameter": "c"}
]
}
]
}
}
The build-time compiler does not contain the determinant formula. It resolves
generic semantic nodes such as parameter, literal, multiplication, subtraction,
call, comparison, and choice, and emits only the selected program.
This produces a different boundary:
seed
→ meaning
compiler
→ generic translation
generated source
→ exact physical program
The generated runtime does not load the seed, interpret a profile, or import a
shared engine containing every calculator.
The extension test
The decisive experiment was to introduce an unseen function:
triple(x) = x × 3
It was expressed only through the semantic seed vocabulary. The unchanged
compiler generated it, and:
triple(7) = 21
The compiler SHA-256 was identical before and after the experiment.
That does not prove that every possible application can be represented.
It proves something narrower and useful:
When a seed is intended to be the sole application authority, application
meaning must be expressible in the seed rather than hidden behind names in
the generator.
Current evidence
The public experiment contains one handwritten normal reference and nine
seed-programmed calculator variations:
- regular;
- scientific;
- programmer;
- financial;
- statistical;
- graphing;
- matrix and vector;
- engineering units;
- reverse Polish notation.
One command performs the build and proof:
python3 run_all.py --generate-only
Measured locally:
10 applications generated
19/19 acceptance cases passed
byte-identical repeated generation
runtime seed/profile access = 0
shared all-calculators runtime = 0
The runnable experiment is available at:
github.com/adico1/unified-code-manual
What is not proven
This experiment does not prove:
- every possible calculator;
- every possible GUI interaction;
- full Standard Ten conformance;
- UEM Python/C equivalence;
- root-seed self-hosting;
- that compilers never require extension.
A new application composed from registered semantic nodes changes only the
seed. A genuinely new semantic node or physical target still requires a
generic language or compiler extension.
That boundary is not a weakness to hide. It is the measurement that keeps the
claim honest.
The larger lesson
Generated code is not enough.
We must ask where the meaning was authored.
If changing application meaning requires changing the generator,
the generator still contains application authority.
The goal is not to move handwritten code into a more impressive directory.
The goal is to place each responsibility where it can be named, measured,
reused, and regenerated.
The seed describes the Thing. The compiler manifests it. The generated program
executes it.