A companion build · twelve blocks · eight instruments · every original dated
The Same
Machine
The first build argued that the structures we call intelligence are arbitrary and were settled between 1847 and 1970, and it demonstrated that with twenty-eight instruments. A fair objection: those were written to make the point.
So here is the same argument again, on tooling that did not exist when it was written. SQLite compiled to WebAssembly. Compute shaders. CRDTs. Merkle proofs. Custom elements. If the forms are genuinely settled, they should be recoverable in any substrate — and the substrate should change nothing but the speed.
b02The Resolution Engine
One relation. Every view, transform, workflow and shell is a walk over it.
The previous page demonstrated a pipeline with stages. That was a simplification, and a misleading one, because it implies the stages are things. They are not. There is one relation — TABLE_SPECIFICATIONS, twenty columns, holding a source address, a target address and the function between them — and everything else in the estate is a projection from it.
Not generated by it in the sense of a code generator with templates on one side and output on the other. Projected from it: the DDL, the view, the load statement, the workflow XML, and the shell that invokes them are each a different walk over the same rows. Change a row and all nine change together, because there is nothing else for them to disagree with.
press 1
Step three is the one that matters and the one that is easy to miss. The specification table's own twenty columns are loaded into the specification table, sourced from ALL_TAB_COLUMNS — so the surface describes itself, and the same projection that builds a business view builds the view of the specification. That closure is not a trick. It is what makes the thing an engine rather than a script: there is no privileged layer holding the rules about the other layers, because the rules are addressed the same way everything else is.
The match rules are rows too. Step four adds a partner feed the page has never seen; before its rules exist, four of its addresses park as candidates rather than failing the load, and the cost of onboarding it is four rows in a rule table. No adapter, no transform, no pipeline. Then look at any of the nine projections again — the shell, the workflow XML, the DDL — and the new system is in all of them, from machinery that did not change.
The command tier is the part usually mistaken for scripting. A ksh wrapper, a .bat, an .ini, a WinTask macro and a CLI invocation are the same projection with different comment prefixes, because they address invocation rather than syntax: bind a context, carry a payload, fire. That is why one header block served all of them for two decades unchanged, down to the $Revision$ keywords left unbound for an archive layer that was never wired up.
b03The Catalogue
A real SQL engine, in this tab, generating its own schema from what it already knows.
The claim from the first build was that an estate's integration points are not designed but recovered: the systems already declare what they contain, and the catalogue is a set of relations you can query like any other. That was demonstrated against a simulated catalogue, which is fair enough as far as it goes.
Here it runs against a real one. SQLite compiled to WebAssembly — 686 KB, shipped in this package rather than fetched from anywhere — four tables created, then the loop: read sqlite_master and pragma table_info, generate DDL from what they report, execute it, and read the catalogue again to find the result. Nobody writes the DDL, and nobody writes down the schema for it to be written from.