AURELIUS
DYNAMIC
Dossier · Research & Engineering Philosophy

Six commitments, enforced by running code.

Aurelius is a small engineering studio creating browser-native graphics, simulation, visualization, and experimental computing systems using WebGPU and modern web technologies. Philosophy pages are usually where companies store their adjectives; this one is different in a verifiable way — every principle below is load-bearing in a system you can open right now: the particle field on the front page, the plasma simulator at /helix/, the knowledge runtime at /ikos/, the live Shader Lab in section 05. Where a principle produced a number, the number is quoted.

01

WebGPU-first thinking

architecture assumes parallelism

Most web graphics is WebGL with better marketing: a rasterization API from 2011 asked politely to do 2025's work. WebGPU is a different animal — genuine compute shaders, storage buffers, explicit bind groups, modern GPU semantics in every major browser. Aurelius designs for WebGPU first and treats everything else as a compatibility target, which is the reverse of the industry's default and the source of most of our performance headroom.

Designing GPU-first changes the shape of systems, not just their speed. The hero simulation on this site is a concrete example: particle positions and velocities live in GPU storage buffers and are integrated by a compute pass every frame — spring forces, turbulence, pointer repulsion, and event impulses all execute per-particle on hardware built for exactly that. The CPU's job shrinks to choreography: advancing a timeline, updating a dozen uniforms. That division is why the same page that renders 480,000 live particles on WebGPU degrades gracefully to 100,000 on the WebGL2 fallback and 20,000 on phones — the architecture flexes, because the expensive part was designed to scale with the backend rather than fight it.

WebGPU-first also means we treat the browser as a deployment target for compute, not just pictures. The most important consequence of WebGPU is not prettier websites; it is that modern GPU compute now ships behind a URL with nothing to install. The studio's bet is that this distribution change is worth being early to — and this site is how we hold ourselves to it.

02

Real-time systems as a discipline

16 milliseconds is a forcing function

A frame budget is the most honest manager an engineering team will ever have. At 60 frames per second you have about 16.7 milliseconds to simulate, cull, submit, and render — and the deadline arrives whether you are ready or not. We build under that deadline on purpose, even when the problem doesn't strictly demand it, because the constraint forces the disciplines that batch systems let you postpone forever: profiling before optimizing, budgeting before building, measuring instead of assuming.

Real-time is also a correctness regime. In an offline pipeline, a numerical instability is a bad log line discovered next week; in a live integrator it is a visible explosion in the first ten seconds. The Boris pusher inside the Helix plasma simulator was chosen over naive integration precisely because real-time exposure makes energy drift impossible to hide — the orbit either stays physical in front of you or it doesn't. We consider that pressure a feature and design our validation loops around it.

Practically, the discipline shows up as rules: every animated system on this site renders only while visible (IntersectionObserver-gated loops), device pixel ratios are capped per surface, per-sprite luminance is normalized against particle count so density changes never blow out the frame, and every effect carries a kill switch that removes it cleanly on any failure. Real-time systems that degrade gracefully are designed that way from the first commit — it cannot be retrofitted.

03

Procedural generation

mathematics as the asset pipeline

Every visual on the Aurelius front page — the twin-strand helix, the sun's granulated photosphere and its flux-rope coronal ejections, the continents and storm cells of the rendered Earth, the nebula backdrop, the aurora curtains — is generated from mathematics at runtime. There is no texture download, no baked animation, no asset CDN. Hash functions, fractal Brownian motion, Worley cells, and trigonometric fields, composed in shaders, replace what would conventionally be gigabytes of authored content.

We hold this position for engineering reasons, not aesthetic ones. Procedural content is resolution-independent — the same sun renders correctly on a phone and a 4K display. It is parametric — when a design review says "the storms should be denser," that is a constant, not a re-authoring cycle. It is tiny — this site ships an entire animated solar system in less code than a single hero video would cost in bandwidth. And it composes with live data: because the Earth's storm layer is a mathematical field, swapping its driver from noise to a real-time weather API was a one-texture change. That last property is the strategic one. Procedural systems are the only content systems that can be driven by data that didn't exist when you built them.

04

Simulation and visualization

if you can't see it, you can't trust it

Aurelius treats simulation and visualization as one discipline with two ends, and refuses to build either alone. A simulation without a live view is unauditable — errors hide in aggregate statistics that no one thinks to plot. A visualization without a real model underneath is decoration — and decorated dashboards are how organizations lie to themselves politely.

The systems we ship keep the loop closed. In Helix, synthetic diagnostics read out of the same particle state the physics writes, so what you see is the simulation, not a summary prepared for you. In IKOS, the book view, graph view, terminal, and orbital view are four projections of one state — edit in any of them and the others are already correct, because there is nothing to synchronize. That is the standard everywhere we build: one source of truth, projected live, with the rendering close enough to the model that discrepancies are visible instead of archived.

We also believe visual validation is real validation. A trained eye watching a live system catches classes of error that unit tests structurally cannot — asymmetries, drifts, oscillations, discontinuities at boundaries. Our verification practice includes automated headless capture of running systems precisely because "the test passed" and "the system behaves correctly over sixty seconds" are different claims.

05

AI-assisted engineering

leverage under adversarial validation

Aurelius uses frontier AI systems aggressively and trusts them exactly as far as the validation gauntlet they pass. The method — the same three engines described on the front page — is designed so that AI acceleration and engineering rigor reinforce rather than trade off:

The honest observation from working this way: AI multiplies the throughput of an engineer who already knows what correct looks like, and multiplies the confusion of one who does not. That is why maximal AI leverage here is always paired with experienced judgment — the machine drafts, a principal decides. We would rather be transparent about this than perform either purity ("no AI touched this") or inevitability ("the AI did it all"). Both postures are marketing; the gauntlet is engineering.

06

Performance culture

measured, budgeted, published

Performance is not an optimization pass at the end; it is a design input at the beginning, with numbers attached. Every surface on this site was built against an explicit budget: particle ceilings per backend (500k WebGPU / 100k WebGL2 / 20k mobile), DPR caps per canvas, additive-blend luminance normalized by √(N₀/N) so brightness stays constant as density scales, lazy initialization for anything below the fold, and render loops that idle to near-zero cost when off-screen. The Shader Lab publishes its own frame time in the corner of the widget — not because visitors demand it, but because a studio that publishes performance claims should be uncomfortable rendering anything unmeasured.

The culture has teeth in process terms: we profile before we optimize, we optimize the measured bottleneck rather than the interesting one, and we keep the fallback paths honest by testing them explicitly — including forcing the WebGL2 path in verification runs even on machines with working WebGPU, because untested fallbacks are fiction. And when a piece of work ships, its performance envelope is documented with it: what it costs, where it breaks, and what the next order of magnitude would require.