We look at software from the angle that shouldn't work.
An emerging-technology lab. We build the idea, or we don't claim it.
Most software is written from the front: take the accepted shape of a problem, keep the accepted seams, fill them in. We are interested in the other approach — turn the problem over, ask what it looks like from underneath, and find out whether the inverted reading is merely strange or actually better. Most of the time it is merely strange. The rest is why this exists.
| Project | What it is | Built in | Evidence |
|---|---|---|---|
| atomiX | A computer from scratch — five-stage RV32IM core, SoC, bare-metal runtime, and the aXos kernel — growing into a reconfigurable FPGA platform with accelerator roles that swap at runtime. | SystemVerilog · C · Python | CI · lock-step cosimulation · RISC-V ISA suite · four-instruction formal · one board, once |
| DRANZER | A decoder-only transformer in C with no ML framework and no autodiff: hand-derived backprop checked against numerical gradients, runtime-dispatched SIMD kernels, GPU matmul through hand-written PTX. | C | CI · nightly · performance and release gates · pre-registered seed-variance floor |
| gator-tools | Shared tooling, vendored as a submodule rather than copied: multi-agent coordination over a Git repository, a canonical-JSON contract frozen as cross-language vectors, and a syntax gate. | JavaScript · Python | CI · nightly · weekly · frozen vectors and differential tests |
atomiX and DRANZER are MIT; gator-tools is Apache-2.0.
Build, don't ideate. An idea costs nothing, proves nothing, and can be held indefinitely without ever being wrong — which is what makes it worthless as a position. A position becomes interesting the moment it runs. No roadmaps for work that hasn't started, no architecture diagram standing in for an implementation, no whitepaper where a repository belongs.
Claims are typed, and the types never merge. A thing that ran in a simulator, a thing that compiled, and a thing that ran on physical hardware are three different claims. None is allowed to stand in for another.
Evidence ships with the command that reproduces it. A result you cannot re-run is an anecdote.
Limits are stated, not left to be discovered. Every repository above says what it does not do, what has never been tested, and what is one person's unreviewed work — in the README, next to the parts that work.
The cost is real and we pay it: building is slow, most inverted readings turn out to be just inverted, and the ones that fail fail in public with a commit history attached. A wrong idea that ran taught us something. A beautiful one that didn't taught us nothing.
Four questions we keep asking, across whatever the domain turns out to be:
- The seam, not the thing. Where does a system's real behaviour live — in its components, or in the joints between them?
- Nothing inherits. What breaks if no part may borrow a guarantee from the part it replaced?
- Invert the cost. Which expensive step is expensive only because everyone agreed it happens at build time?
- Take the toy seriously. The version obviously too small to work is the one that shows you what the size was buying.
None of these are original alone. Holding all four at once, and refusing to put down the fourth, is the part that gets you somewhere odd.
This is small and new, which is the honest pitch: there is unclaimed territory in it and no committee between you and the interesting problem.
- Reproduce something. Clone a repository, run it, and tell us what didn't work on your machine. An independent reproduction is worth more to us than a feature, and we currently have none.
- Read adversarially. Find a claim in one of our READMEs the evidence does not actually support, and open an issue. That is a contribution.
- Work the low levels. Hardware description, compilers, kernels, simulators — the layers where the abstraction is still visible.
Open an issue or a pull request on any repository above. Contributions carry a DCO sign-off and are held to the rules above, the same as everything else here.
Build what teaches. Verify what matters. State the limits.