We loaded real evolving GTFS Madrid into .me: routes, trips, services, stop times —
with relationships expressed as live dependencies. Change a fact → the kernel follows the affected set k,
not the whole universe n.
On the full benchmark, n grew ~100× (stop times 2.3k → 236k) while k p95/max stayed flat (~18 / 27).
This page is the interactive subset: click a node → me.explain(path); mutate to watch the wave.
—Ghosts only — kernel stays the demo subset.
—
—
A tiny GTFS-Madrid-shaped knowledge universe on the live this.me kernel —
same idea as the full evolving workload, scaled down so you can see it.
Click a node → me.explain(path) (dependsOn in cyan).
Mutate → recomputed wave in red. Gold ring = selected.
n = universe size · k = what one change touches. They are different variables: growing the world does not have to grow every mutation’s wave. That is what the scale-1 → 10 → 100 result on the real GTFS adapter showed.
Honesty (same as the blog / benchmark README):
this is not an RML/RDF materialization run, and we are not claiming mutations are O(k).
Dependency propagation stayed local to k; structural DELETE apply can still cost with corpus size —
that bottleneck is real and separate from recompute.
CREATE here uses explicit gtfs.idx membership slots (flip 0→1), not “natural GTFS CREATE k=1”.
Loading a larger snapshot costs more with n; that is not the same as recomputation after a mutation.
Density ghosts are visual-only — not wired into the kernel.
Kernel: published this.me@4.1.0 (hash-pinned). Isolation demos still pin 4.0.2;
DELETE via me["-"] needs 4.1.0 for ABSENCE invalidation. Append ?local=1
to load ../Typescript/dist/me.es.js instead (static serve from repo root).
Same adapter conceptually as Typescript/tests/Benchmarks/GTFS-Madrid/ on main.
Full mutation sweeps stay in Node; this page is the interactive subset.