Roadmap
Broad roadmap, narrow active scope.
A wide map costs almost nothing to keep. Doing many things at once costs everything. ME holds the first and refuses the second.
How execution works
Broad roadmap
The map covers computing, robotics, energy, space, manufacturing, materials, medicine, transportation and frontier physics. Keeping the map wide is cheap. It is what lets one branch borrow from another.
Narrow active scope
Only a few projects are active at once. Planning stays shallow until a branch genuinely needs deeper design, rather than pretending every subsystem needs a five year plan today.
Milestone gates
Each project advances through small milestones that can be individually demonstrated. A milestone is done when it runs, not when it compiles.
Projects earn expansion
Scope is granted, not assumed. A project widens after it has shown a working milestone, which is why the active list is short and the map is long.
Shared infrastructure
ME OS, Carl, the research tools platform and manufacturing are shared across products, so work done once is reused instead of rebuilt per project.
Selected current milestones
A milestone is done when it runs and can be demonstrated, not when it compiles.
- ME OSComplete
M1: boot proof
Boot in a virtual machine to a black screen reading IF YOU SEE THIS IT WORKED. Nothing else. A freestanding x86-64 kernel boots over UEFI, draws the line, and does not crash. Checked automatically by inspecting the framebuffer.
- ME OSComplete
M2: keyboard input
The boot message stays where it was and a line below it reports the last key pressed. Verified in QEMU by injecting a key press and inspecting what was drawn. Not yet run on a physical machine.
- ME OSComplete
M3: draw a rectangle
One static filled rectangle, with the boot message and the key line untouched. Checked automatically: the captured framebuffer must contain a solid rectangle of the expected size, centred and clear of the text, alongside both lines of text. Framebuffer clipping is also checked on the development machine with guard regions around a fake framebuffer.
- ME OSComplete
M4: mouse cursor
A cursor drawn on the framebuffer that follows the mouse, keeps its shape, and stays on screen. Checked automatically: the emulator moves the mouse and the captured framebuffer must show the cursor moved by exactly that much, with the message, key line and rectangle all untouched.
- ME OSComplete
M5: move the rectangle
The rectangle crosses the screen at sixty pixels a second and turns around at each edge. It moves at a rate rather than at whatever speed the machine runs its loop, because the kernel now reads a hardware timer. Checked automatically across four captures: the rectangle is whole, on screen, and somewhere different each time.
- ME OSComplete
M6: basic arithmetic
Type a sum and press enter, and a line above the boot message shows the answer. Addition, subtraction, multiplication, whole number division and powers, with the precedence they have on paper. Overflow, division by zero and fractional powers are refused and shown as an error rather than producing a wrong answer, which matters in a kernel with no interrupt table to catch a fault.
- ME OSComplete
M7: conditionals
One conditional expression on the same line: IF one value compared to another THEN this ELSE that, with =, < or > as the comparison, and a sum allowed in all three places. Checked by typing both a condition that holds and one that does not, and reading the two different answers off the framebuffer.
- ME OSComplete
M8: variables
A value can be given a name and used on any later line. Eight names fit, each an uppercase letter and up to three more characters. Reading a name that was never set is an error rather than zero, because a typo that quietly reads as zero gives a wrong answer and says nothing about it. One table, no scope, and nothing survives a reboot.
- ME OSNext
M9: keyboard controlled rectangle
Keys move the rectangle, which until now has only moved on its own. After it: wrapping at the screen edges, then picking the rectangle up with the pointer.
- HoloprojectorComplete
M1: rotating pyramid
A pyramid in a 3D simulator, rotating on elapsed time, with pause, resume, reverse, axis, speed and reset, all driven through the command layer rather than the renderer.
- HoloprojectorComplete
M2: multiple scene objects
Several independent objects in one scene, each with its own transform, visibility and rotation, plus selection and per object commands. Still a simulator. No display hardware exists.
- HoloprojectorComplete
M3: pointer interaction
A device neutral pointer: hover, select, grab, drag and release. A pointer sample is a ray plus a pressed flag, so a mouse, a holo pencil, a bracer or a hand tracker could each produce one. Only the mouse works; the others are named stubs that refuse to poll. Dragging goes through a command that safety checks, so a drag out of the display volume is refused.
- HoloprojectorComplete
M4: simulated Holo Pencil
A second pointer source, simulated in software: a tip in the display volume that the keyboard walks around. It selects, grabs, drags and releases through the same controller, commands and safety checks as the mouse, and a drag begun with one source can be finished with the other. No physical pencil exists.
- HoloprojectorComplete
M5: bracer input adapter
An adapter shaped like a wearable: a hand pose in its own tracking space, an alignment that maps it into the scene, and a grip. It can also lose tracking, which lets go of whatever was being held instead of leaving it attached to a hand nobody can see. None of that needed a change in the interaction layer, the commands or safety. No bracer exists, and nothing reads or models a sensor.
- HoloprojectorNext
M6: richer Carl adapter
Broader phrasing and multi step instructions through the same command path, still model agnostic and still offline.
- Employee BracersPlanned
Hand tracking feasibility
Establish whether inertial and optical sensing, and later surface electromyography, can resolve hand and finger intent accurately enough for holographic interaction, before any wearable is designed.
- Research ToolsPlanned
Platform design
Define the shared simulation, measurement and experiment tracking layer other branches would build against.
- EnergyPlanned
Smart DC bus study
Study a shared DC distribution bus for a lab bench or factory cell, with monitoring and protection built in. Paper study only. Nothing has been built or energised.
- ManufacturingPlanned
First production proof of concept
End to end automated production of one simple non safety critical automotive clip, using additive manufacturing, with camera and weight quality control and full traceability for rejected parts. Nothing has been built.