DEV Community: Dimon

Kinewright Humans: the map — what it owns, where the data comes from, what comes next

Dimon — Tue, 22 Sep 2026 17:45:37 +0000

Kinewright is a house of motion engines. Humans is the first engine. This article is the plan for that engine as it stood in September 2026, written down once and left as it is: what the engine does itself, what it deliberately takes from outside, which published data it leans on and how that data is allowed in, and what was planned to happen before each next step.

I will not update this article. It is the starting point, kept so that later changes can be read against it. The living version is the pinned post on r/Kinewright; it changes when a stage closes or the order moves. And the order does move, not only by my decision: I posted the first video, a reader said the torso looked held, we checked, agreed, and a correction that was not in the plan went in front of the next stage the next day. That is the kind of change this article is a baseline for.

There are no dates in it, on purpose.

One sentence, one level

Humans turns a supported body, a motion skill, scene constraints, a motor style, a seed and time into a canonical stream of three-dimensional poses, contacts and events. It produces motion state, not pixels.

Its level at the time of writing is kinematic. Gravity, ballistic flight and the lean of a braking body are used as identities with a known source; nothing is dynamically simulated, and no balance or physical validation is claimed. Every step below names the highest claim it may make on one ladder:

Level	Meaning
Kinematic	poses and contacts meet declared geometric and timing checks; this does not establish forces or physical validity
Physics-informed	kinematic motion shaped by named physical identities, without simulation or balance claims
Static balance checked	projected centre of mass and support polygon pass declared quasi-static checks
Dynamically checked	momentum, contact forces, centre of pressure or capture-point reasoning pass declared checks
Simulated on	a named slice ran on a named dynamics provider build
Hardware validated on	validated on exactly named hardware through a separately proven physical stack

A motion that passed a kinematic or visual gate is never described as physically validated. The accepted locomotion sits at physics-informed; the stages that follow are kinematic.

What the engine owns, and what it is meant to own

At the start the implementation centres on one reference body's locomotion, contact timing, command handling and replay. General body compatibility, marker-based warping and a durable runtime journal are contracts on the plan, not capabilities the first video demonstrates.

Intent. Commands, their order, a fixed tick. A command is answered at a declared safe boundary, never mid-air by accident.
Contacts and their owners. Which foot is on the ground, when, where; who owns each contact when something else is involved.
Markers and admissible warps. The named moments a motion may be cut, joined or warped at (touchdown, toe-off, takeoff, landing) and by how much.
Capabilities and honest answers — planned contract. Each skill–body pairing is intended to resolve to native, adapted, fallback or unsupported with a diagnostic. At the start there is one supported body, not a delivered general compatibility platform.
Expected supports. What the engine believes holds the body up.
Diagnostic truth and replay. Silent NaN, silent target dropping and undocumented clamping are treated as violations. Identical versions, body, scene, configuration, initial state, seed and ordered commands at the same fixed time steps must replay the same motion state; this does not promise identical pixels across renderers or arbitrary future physics backends.

Concretely that is the rig and its limits, forward kinematics and a bounded solver, the locomotion profiles (cadence, step, duty factor, timing of contacts, root motion, start, stop, transitions), the scheduler, and the renderer-adapter boundary.

What it will consume, by design

The list is finite on purpose. An infinite adapter list cannot define readiness, so every item here has a named slice and a named claim.

Physics. Not written here. An optional dynamics provider owns dynamic realization, collision response, external impulses and stability enforcement under an explicit ownership contract with seven named handoffs (grounding and support, collision queries and responses, carried-object authority, grasp and release, external impulses, replanning and fallback, deterministic replay and diagnostics). The actor stays the kinematic authority by default; a provider may own named objects and, only under an explicit handoff, named body parts. When animation intent and physics disagree, the contract names the owner of every contact; nothing is resolved silently. First provider candidate: Rapier, one slice.
Rendering. The engine does not draw. What the videos show is a plain Canvas 2D reference renderer projecting the canonical 3D state. First real lane later: Three.js with glTF/GLB transport. Renderer bone names, camera assumptions and drawing styles never leak into the motion model.
Avatars and retargeting. A generic humanoid mapping first, then VRM 1.0 and VRMA conformance. Having a specification does not license an asset; each avatar is its own rights question, and no automatic retargeting is promised.
Navigation. Recast/Detour for paths and corridors. The engine keeps the footholds and the body heading.
The scene. A small contract: named surfaces, affordances such as "seat", "grasp" or "ground", target transforms, and collision or reachability only when a backend provides it. The engine never guesses that a mesh is a chair, and ground is not implicitly at zero; the scene says where it is.
Input, game engines, motors. Adapters. DOM events and frame timing are adapter inputs, not scheduler state. The engine is not a game engine and will never claim it drives a robot from a browser; physical embodiment needs a separately proven stack and is a far-future, optional direction only.

Workers, WASM or WebGPU come only after a measured hotspot at 1, 16, 32 and 64 actors. Other renderers or physics backends come when someone actually needs them.

Where the data comes from, and how it is allowed in

The engine core ships no third-party data. Every number taken from a dataset lives in a separate pack under the dataset's own licence, with the exact artifact and its hash pinned. Retargeting, smoothing, fitting or changing the file format does not wash away an upstream obligation. Nothing is admitted because it appears in a paper or in another engine.

Every constant carries a status: measured, aggregated, derived, engineering or estimated. Nearly every constant in the core at the start is an engineering choice, and it is labelled as one; "measured" is reserved for what a source actually reports.

In use at the start

Source	What it provides	Licence
NIOSH firefighter anthropometry, RD-1007-2015-0 (951 US firefighters, 2008–2012)	body proportions as fractions of stature for the one supported body; silhouette anchors	US public domain
Fukuchi et al., walking biomechanics dataset v5 (WBDS; PeerJ 4640)	sagittal pelvis, hip, knee and ankle curves of treadmill walking	CC BY 4.0
Fukuchi et al., running biomechanics dataset v5 (RBDS; PeerJ 3298)	duty factor and knee-flexion anchors at 2.5, 3.5 and 4.5 m/s; one of the sources shaping the product run	CC BY 4.0
The same RBDS raw markers	spatial curves and reconstructed joint centres, used at the application's carrier layer	CC BY 4.0
Riglet et al. 2024, run/walk 3D motion dataset v1 (Scientific Data)	four arm-relative channels in steady running; not a thorax or root-motion prior	CC0

Research and validation inventory — not runtime carriers

Reznick et al. 2021, continuously varying locomotion (walk↔run transitions; Scientific Data; CC0). Biancardi, Lagos-Hausheer and Bona, treadmill walking, running and transitions (Dataverse 10.60895/redata/PK1DCE; PeerJ 18162; CC BY 4.0). Calisti et al., countermovement-jump landings (dataset v1; CC BY 4.0). Two anthropometry sets are recorded as candidates with nothing extracted. Independent review of the three motion packages above was still pending at the time of writing; listing them is not a claim of completed runtime admission.

Method references, reimplemented without importing coefficients

Hof 2005 (the extrapolated centre of mass, ξ = x + v/ω₀); Wang and Srinivasan 2014 (pelvis state predicts the next lateral foot placement); Kwon et al. 2023 (planned stopping begins braking before the final contact); Mesquita et al. 2024 (curved running: straight flight, redirection owned by stance); Oosterwaal et al. 2016 and Arnold et al. 2017 (the foot is not one rigid block); Hof, Pratt and Vukobratović for capture point and zero-moment point, held for the balance rungs of the ladder. In every case the gain, cap or eligibility rule is an authored engineering control, not a claim about the publication.

Deliberately not used

AMASS and SMPL (non-commercial terms: no clips, retargeted motion, fitted tables, embeddings or weights may enter a release); the CMU motion-capture database (broad reuse, but not MIT or CC0); one curved-running dataset whose licence was never declared. The engine will not ship identity reconstruction, gait identification or demographic classifiers, and population labels describe source evidence, never a "personality preset".

Ranges we read our results against

When we look at a motion we compare its figures with published adult ranges, and those ranges stay in the record; they never enter the engine. Trunk obliquity and rotation in gait (Crosbie et al.), pelvic rotation in walking and running, thorax–pelvis coordination versus speed.

The plan as it stood: stages and dependencies

A step gets a size only after its definition of ready is frozen. Sizes here are the kind of work and a rough band in engineering passes and owner looks: planning envelopes, not a calendar.

#	Step	What it delivers	Kind of work	Band
✓	Forward locomotion	steady walk, steady run, walk to run, run to walk	cycle synthesis, contacts and seams, arm swing, a blinded braking-lean ladder	closed; five review packets
✓	Stand, start, stop and command interruption	stand, start as the release of stop, stops from a walk and a run, commands answered at safe boundaries; one named condition carried forward (the hard landing foot on the last braking steps)	thirteen lanes behind gates, eleven review packets	closed; about a month
1	Runtime step planner	the next step planned at runtime instead of a precompiled track: a tap gives exactly one step, stop during start, shift back and forth mid-transition, a landing foot that arrives like the walk's	a small runtime substrate (descriptor, fixed tick, ordered commands, deterministic random streams, durable event journal) and the planner on it; steady walk and run byte-identical, transitions re-accepted	medium; up to 3 looks
2	Playable controller	WASD, Shift and Space on the planner: desired speed and response policy, contact-safe steering, a camera that does not feed back	policy, steering, input contract, arena	medium
3	Closing the foundation	continuity across the whole chain of states and reversals; visible feet and hands (renderer only, no new joints); directional readability; one integrated review of everything	gates, a renderer branch, a full packet	medium to large; several looks
4	Jump family	standing, walking and running jumps on the planner, ballistic flight as an identity	markers, bounded warps, contact schedules	medium; one batched look
5	Core boundary and first adapter	intent, tick, pose frame, events, snapshot and replay behind a renderer-neutral seam; a thin Three.js + glTF/GLB adapter; capability contract v0	architecture discipline, not a public API	small
6	Skill platform and scene objects	stable skills, a broader transition realizer, scene objects that are explicitly not physics yet	platform	medium
7	Body compatibility and functional hold	other bodies with honest native/adapted/fallback/unsupported answers; holding an object with real grip semantics before any grasp claim	contracts and conformance bodies	unsized until its definition
8	Articulated hands	wrist, thumb and digits; grasp and release from a named taxonomy	a rig revision and a rerun of every earlier gate	unsized
9	Catalog waves	roughly 20 everyday actions, then 60, then 100	skills, in waves	large
10	Multi-actor	two actors, then 4–12, then dozens; coordinated interaction sessions; a deterministic scene director with no language-model planner in the first version	isolation, sessions, a 1/16/32/64 benchmark	large
11	Integrations	generic humanoid + VRM/VRMA; the Rapier slice; the Recast/Detour slice	interleaved with catalog and multi-actor work, not postponed until both finish	bounded slices
12	World profile, static balance, dynamics contract	gravity, friction and mass with provenance; balance as a claimed capability; the seven handoff contracts with a provider	contracts and evidence	unsized
13	Full-scene gate	a 32-actor reference world, a 64-actor stress test, a truthful capability matrix	evidence at scale	gate
14	Public engine gate	clean-room packages, a public API, versioning and migration policy, documented limitations, notices	hardening	gate; opening the code is a separate decision

Corrections between stages are not rows of this table. The pelvis and chest coordination pass now in progress, started by the first outside comment on the first video, is one of those: a fix inside the accepted foundation, tracked in the pinned post, not a stage of the plan.

The numbering groups work; it is not a strictly serial schedule. Avatar integration can overlap the first catalog and multi-actor work. The dynamics ownership contract comes before the Rapier slice, and that slice before catalog actions requiring dynamic objects. Navigation integration comes before the crowd/navigation stage. Coordinated two-person interactions likewise depend on their multi-actor contracts.

Optional and outside the main envelope: bounded seeded variation (cadence, step, arms, gaze and breathing with correlated memory, never per-frame noise and never contact drift), toe articulation, compensatory motion for missing or alternate limbs, dynamic plausibility checks, and physical embodiment.

A second comment on the same video already points at one of those optional items: the motion looks "too perfect", a human would not repeat the same action. That repetition is real and deliberate at the start, because the accepted cycles are the regression anchor of everything built on them; the answer to it is the seeded-variation item, and whether it moves up the list will be a decision recorded with its reason, visible in the pinned post, not here.

What this article is not

It is not a promise of dates. It is not a physics claim; the ladder above is the only vocabulary for that. It is not a code release; that is a separate decision with its own gate. It does not describe the second engine of the house, which gets its own map. And it is not the current plan: it is the plan at the start. Outside feedback is research input we measure against; a change of order is a decision recorded with its reason; both show up in the pinned post on r/Kinewright, which is the only version of this map that moves.

How to help

Watch the clips, answer the two questions — does it respond the way you expect, does it look natural — and say what you saw. The torso correction now in progress exists because one reader did exactly that, and this article exists so that the next such change has something to be read against.

Kinewright Humans: How a runner stops

Dimon — Mon, 21 Sep 2026 13:31:31 +0000

Kinewright is a house of motion engines. Humans is a headless TypeScript engine that turns a body, a motion skill, a stream of commands, time and a seed into a deterministic stream of 3D poses and contacts. It outputs motion, not pixels. The picture in the videos is a plain Canvas 2D reference renderer; the engine is what moves it.

The level today is kinematic. There is no physics engine underneath: no forces, no ground reaction, no balance. Every number in this article is an engineering threshold that the motion was built to, not a measurement of anything.

Before this stage the engine could walk, run, go from a walk into a run and from a run into a walk, and both of those transitions had been accepted by us, the two people who look at every result. This stage asked for the rest of ordinary locomotion: standing, starting, stopping from a walk, stopping from a run, and commands that interrupt each other. The hard part turned out to be the last stop.

The video

18 seconds, real time, rendered at 60 fps on a fixed-step clock, nothing hand-animated; the GIF here plays it back at 15 fps. It was rendered from the exact bytes we accepted the stage on.

time	what happens
0.0–0.8 s	standing
0.8–3.3 s	start: a weight transfer, then the first accelerating steps
3.3–5.3 s	steady walk
5.3–7.0 s	the run command lands; walk to run
7.0–12.9 s	steady run
12.3 s	the stop command lands while running; braking begins at 12.9 s at the run's own boundary
12.9–16.7 s	four braking steps, the run settles into a walk step by step, then the walk's own stop
16.7–18.3 s	standing

One thing to watch at about 14.9–15.3 s, on the last two braking steps of the run exit: the foot is put down hard. It reaches the ground while still rising and stops dead, where a walking or running foot comes down onto it. We accepted it as it is at this stage and will rework it later, in the step planner that places each foot from the body's speed plan and brings it down onto the ground. The rest of this article explains what you are seeing, in order, and ends with that foot.

Three short clips accompany the article, at 30 fps: a steady walk, a steady run, and stand → start → two steps → stop. They are the same engine on the same scene; the walk and the run are the previously accepted motions the new ones had to join.

Standing

A stand is a hold, not a pose with sway. There is no breathing and no micro-movement in it, on purpose: a living idle is a separate piece of work and it was not faked with noise. The stand is entered when a stop completes and left when the stop is released. It was checked to hold the same pose and the same two foot contacts for a five-second dwell at real time, six hundred frames, with no event and no drift.

Starting

A start is a weight transfer and then a step. The accepted start the engine already had took 0.8 s to prepare the first step and used three accelerating steps. We wanted a start that begins at once, so the product start prepares for 0.35 s and takes two accelerating steps, and the walk it settles into is the accepted walk unchanged. Movement begins 0.3989 s after the command against a bound of 0.4 s. That is a margin of one millisecond and it is stated as one.

The first version was refused before any formal look: it unlocked the legs and sat down before the first step, where a person simply begins with a step. The crouch and the return to neutral were removed. What was left after that was a 2.26 mm step down at the instant movement starts, the descent to walking height that the crouch used to carry. It is now blended across the first step, so the pelvis leaves standing height continuously and is at walking height when the foot lands.

That costs one thing, said here rather than left to be found: the planted foot floats 0.21 mm above the ground for about 0.13 s while the pelvis is still high. It is twice the tolerance the stage holds its seams to, nothing penetrates the ground, and we accepted it rather than hide it.

Later, a frame-by-frame check added for a different reason found two more defects in the start that nobody had seen: the root, the head and both hands stepped 20.6 mm sideways between two frames, once at each foot's liftoff. The cause was a membership test. A standing foot held the pelvis back by its reach as long as it was "on the ground", so when the foot left the ground the restraint left with it and the answer stepped. A foot now holds the pelvis back in proportion to the weight it still carries, and the jump is gone.

Two things a start does not do yet. A stop pressed during a start still costs a full stopping motion, seven foot contacts, where we wanted at most one more. And a tap of the walk command does not give exactly one step: it also costs seven contacts and reaches the hold 3.29 s after the release. Both are transferred to the next substrate, a runtime step planner, as not met. The reason is structural: the one route that could deliver a single step, a weight transfer, one step and a brake from that step's low speed, is entered at a foot contact that is still accelerating at 0.6 m/s, and this compiler lays out exactly one route with the stop always last.

Stopping from a walk

A stop is a motion request, not a pause. From a walk the engine enters the accepted braking motion at the nearest foot contact of either foot, half a walk cycle at worst, and brakes over two steps into standing. The braking is the accepted chain's own: 0.48 s down to 0.9 m/s, then 0.58 s to rest. What changed is only where it may be entered: at the contact the deceleration begins on, rather than a stride and a half before it.

The first version was refused before any formal look, as a jerk. It put the whole deceleration into one short step. The second version, entering the accepted deceleration where it begins, was the one we looked at.

We refused its ending. After the feet came together, both knees straightened and pressed down at once as one last movement, where naturally one leg finishes completely and then the other, with no such movement at all. The closing was rebuilt around that sentence: the supporting leg is straight at the last contact; the closing leg lands bent at 13.7° and straightens to 0.01° as it takes the weight; the pelvis rises inside the last step; and nothing moves once the feet are together. What is left after the feet meet went from 0.170 s to 0.065 s, and the torso arrives upright with the feet instead of unwinding for 0.18 s after them.

To make the supporting leg reach full extension before the contact rather than on it, the pelvis rolls toward the supporting leg across the last step, by that leg's own reach deficit, under a 3° ceiling. Two earlier attempts had returned the straight leg as geometrically impossible; the argument held for a level pelvis only.

On the next look we refused the upper body: the torso shook side to side and the shoulders swung too far, and from a walk into a stop it leaned to the right. The 3° of pelvis roll was arriving whole at the shoulders, 3.04° of shoulder line and 34 mm of head travel, where the accepted closing had 0.11° and 2.5 mm. The walk's own pelvic obliquity lives in the pelvis joint and the spine already counters about two thirds of it; the closing roll had been applied underneath everything. The spine now counter-rolls the closing's roll, split between lumbar and thoracic by a ratio read off the rig's own spine offsets, so the head stays over the pelvis as well as the shoulder line staying level: 0.057° of shoulder line against a bar of 0.62°, 1.28 mm of head against a bar of 12 mm. It can move no foot, because both hips hang from the pelvis and nothing above the lumbar can reach one.

One request from that look was declined with its price on the table. We asked for the pelvis to level after the contact across the closing leg's weight acceptance, about 0.13 s, rather than the 0.05 s it takes. It cannot, because the roll is the supporting leg's reach deficit and the deficit is what is left of the pelvis's rise; they are one motion. Forcing the window open lifts the supporting foot 1.8 mm off the ground for the whole of it. I read that and kept 0.05 s.

Stopping from a run

This is where the stage spent most of its time. We refused one motion six formal looks in a row, each time at a finer grain, and each refusal is in the video's history.

1. It walked first. The first version reused the walk's stop, so a running character went into a walk and walked about three and a half steps before stopping. We refused it: stop at once, and from a run go into walking and stop, not walk for a while.

2. A direct route. The engine now leaves the run at the run's own boundary into a dedicated run-to-stand motion: it decelerates on braking steps to the point where the gait becomes a walk, then plays the same two-step stop, with no steady walking in between. The worst case from the stop command to the hold is 4.46 s against a bound of 5.5 s.

3. The braking steps floated. We both refused the run's deceleration as it stood: it glitched, it was sluggish, a moon walk, a skipping gait. In numbers, the first braking step was 29 % longer in time and 15 % longer in distance than a run step and its apex 18.6 mm higher, and the second flew 49.1 mm above the run. The exit was recompiled so that braking steps keep the run's own cadence while the step length and the flight shorten with the speed; no braking step is longer or higher than a run step. One requirement is still missed, by 22 micrometres: the first braking step's apex sits that much above the run's, where it used to sit 22.3 mm above.

4. The leg "chewed". Our next look: at the end, the leg is chewed over in the last movements. What we were watching was the step interval jumping from the run's 0.329 s to the walk's 0.420 s in a single step, a 27.8 % jump, while the last braking step still carried a 62 ms flight. I replaced the requirement in my own words: the run's cadence holds while a step still ends at 3 m/s or above, and from there the interval grows step by step to the walk's own at the commit. The intervals are now 0.329, 0.357, 0.387 and 0.420 s, every neighbouring pair within 8.5 %, no flight on the last two braking steps, every apex under the run's. The finding behind it: the interval could not travel alone. The run's stance fraction bottoms out at about 0.405, so widening the interval without widening the stance makes the flight longer, not shorter, and the stance now tapers with it. The taper spends the same ground at longer intervals, so the exit takes 177 ms more and the worst case moved from 4.28 s to 4.46 s, still inside the bound.

5. The leg kept the run's shape. Next look: something is still wrong with the leg, maybe the foot. The timing had become a walk's, but through every braking step the limb kept the run's form: the foot pushing off its toes, the knee thrown past ninety degrees, the toe carried high, the planted foot travelling most of a walk step over its own stance. All four switched to the walk's form in one step at the commit. All four had the same single owner inside the compiler, an amount that says "this is a run" and was exactly 1 until the commit. That amount now crosses to the walk's on the same fraction the interval and the stance already travel on, and the pelvis descends with it, apex by apex, where it used to stay at running height and drop at the commit. One bar in this set I closed unmet, by decision: the planted foot still travels 25 mm over the last braking stance against my bar of 15 mm, because taking the rest would have cost the pelvis dipping under the walk's floor, which we had refused earlier.

6. "Like an old mechanism jammed." Next look: the last steps look very mechanical, as if an old mechanism seized. Everything else we approved. A whole-window frame-by-frame scan of every clip, added for this, found three jumps the existing checks had walked past because they only checked the boundaries between clips:

the body crossed sideways at 5.69 m/s inside a 21 ms flight. The pelvis had been held exactly over its planted foot for the whole stance, so its crossing to the next foot's line had nowhere to happen but the flight. On the run's 106 ms flights that is 0.1 mm of sway; on the tapered exit's 21 ms flight it had grown to 77 mm;
the whole body moved 48 mm in one tick, 77 ms into the first stopping step, taking the head, both hands and both knees with it. It had been in five looks and every check had passed it;
the two 20.6 mm jumps in the start, described above.

Two of the three were the same shape: a set that decides an answer lost a member at a hard boundary, and the answer stepped. The crossing now opens a little earlier, 36 ms instead of 21, the widest the existing continuity ceilings pay for; the pelvis hands over from the foot-based support to its guide across the double support that is taking the weight; and the frame-by-frame check over the interior of every clip is permanent. Two things were priced and returned rather than taken: a braking curve whose peak equals its mean, because it costs 2.8 micrometres of a continuity ceiling I had set, and an even deceleration, because the ground the route has fixes the curve's exponent at about 2.23 and an even one would need 0.76 m more ground than the route has.

7. A jerk forward on the penultimate step. Next look: almost there, but the second-to-last step jerks forward with the leg before the foot comes down. Two things were found. From the third braking step the feet were landing 88–89 mm either side of the route, the standing track, where the run lands at 49.5 mm and the walk at 46.4 mm; the run's narrow track is released by an amount read off the speed, which had expired mid-braking, and the walk's narrowing is a correction a running step is excluded from, so nothing held the ground between the two. The pelvis had to travel to meet the feet: it swung ±71–75 mm and crossed between them at 3.46 m/s against 0.59 m/s in the run. The track now tapers from one gait's to the other's on the same fraction as everything else, and the pelvis crosses the route at 2.47 mm per frame, the accepted run's own figure, where it crossed at 14.3.

The second thing was not answered and the record says why in numbers. The pelvis does not follow its own speed plan through the exit. At the four braking contacts it sits 103, 149 mm behind and 59, 191 mm ahead of where the plan puts it, because the foot is placed from the plan by the step's own length while the leg's geometry is on its way from the run's to the walk's. At every one of those contacts the leg is already at 0.998 of its own length, so of the 191 mm the pelvis would have to give back, 3.5 mm are within reach. Three ways of taking it anyway were tried and each is priced: one drags the planted foot 872 mm over a stance, one costs a 42.6 mm jump in a single frame, one returns the unpaid part in one place as a reversal.

8. The foot is put down hard. On the last look we approved everything and named one thing: on the last braking step the foot is put down very hard, the whole leg is right, the foot goes through in one jerk at the end. This is the one in the video at about 15 s.

What puts the foot down like that was established rather than guessed. The same "this is a run" amount that owns the limb's shape also reaches the geometry of the support: every braking stance is handed the run's own support vector, 0.99801 of the leg's length at contact on all four braking steps, where the accepted walk lands at 0.99763. The difference is 0.3 mm of leg. A leg at its own length has no way to move its ankle except by moving the hip, so whatever the pelvis does in the 21 ms flight arrives at the ankle instead, and in that flight the pelvis rises. So the last two braking feet arrive going up, +0.07 and +1.03 m/s, the ankle 18 mm higher than one screen frame earlier, and stop dead in a millisecond. Every accepted gait arrives going down: the walk at −0.14 m/s, the run at −0.23 m/s. On the run-to-walk route the same foot arrives travelling backward at −3.85 m/s.

Three answers were built and each was sampled. Tapering the support geometry from the run's to the walk's puts the foot down properly, −0.44 and −1.37 m/s at contact, and costs a vertical acceleration ceiling on the run-to-walk route, 61.1 against the ceiling's 52.6. Placing the feet where a pelvis on the plan would need them costs two contact-solver failures at two run-to-walk contacts. Tapering the pelvis's swing about those contacts makes every motion figure green and costs a hip jerk ceiling by one percent and a knee ceiling by six. Every one of those ceilings is a number I set earlier as the price of continuity. I read all three and moved the work instead of the numbers: the foot is transferred to the next substrate as a rule for the planner, in my words: feet are placed where the pelvis is on the plan, the support geometry tapers from the run's to the walk's, and the foot arrives at contact going down and at the walk's own speed. It is not achieved, and the check that measures every foot's arrival in every clip now names those two feet, so a closed stage cannot be mistaken for a fixed foot.

The lesson worth stating from all eight: per-step checks passed while a whole-window scan failed, and a released bound that turns out not to be the binding one is worth more written down than a ceiling spent quietly to look finished.

How it was judged

The two of us, in real time, two questions per item, ten items, one packet per look: does it respond the way I expect, and does it look natural. Yes or no, and what you saw. A refusal from either of us on any item means no acceptance. Seven packets were shot at the same ten items; six formal looks refused three motions, then two, then one, one, one, and the sixth accepted all ten with the one named condition above. Forty cells, forty yes.

The closure was written down before the first look was taken: what a pass looks like, what a pass with a condition looks like, what a refusal does. So the recording could not be shaped by the verdict. A machine-green check never accepts anything here; it only refuses.

What is not solved

A stop during a start in one step, and a tap of the walk command giving exactly one step: transferred to the runtime step planner, not met.
The landing foot on the exit's last two braking steps arrives rising: transferred, not met, named in the check.
A run re-asserted in the middle of a run exit: the exit plays out first; deferred to a real-time planner.
The supporting foot slides about 65 mm backward over a braking stance. It is a property of the accepted run, not of the exit, and it was never touched in this stage.
One jump is left anywhere in the product, in the start's left knee, and the check names it.
Desktop stills are not deterministic between captures on one machine; the mobile capture target is the instrument.
No physics, no terrain, no living idle, one actor, one body.

Claim level

Kinematic. Geometry and determinism, nothing physical. No number in this stage became a measurement; every value is a sampled property of compiled engineering motion at one preset. Nothing has run on hardware and nothing has been physically validated.

Feedback

The two questions, on the video: does it respond the way you expect, and does it look natural. Yes or no, and what you saw.

Human, agents, code, judge: adding Jev without replacing peer review

Dimon — Sat, 19 Sep 2026 12:30:21 +0000

I use Claude and GPT to review each other's work. Adding Jev did not replace that arrangement. It gave it another instrument.

The useful distinction is between an agent reviewing a whole change and a model answering a narrow question about supplied evidence. I want both. I also need to check the scripts connecting them.

What prompted the experiment

One of my projects has a growing documentation library. After a milestone, the current status changed, but older descriptions remained scattered across the docs.

Two cleanup passes had already happened on the Claude side. A subsequent semantic scan produced candidates that the agent checked against the repository. Nine stale statements were confirmed and corrected.

One was especially revealing: an old “corrected” marker exempted a sentence from the existing lexical guard rules. The marker was still there; the statement had become outdated again.

This was not Claude and GPT both missing the same nine statements. Those two passes came from the same agent/model family. Nor does this establish that a judge is a better general reviewer. It shows why a separately framed check was useful in this incident.

Four layers, with review across them

Layer	Its job in my setup
Human	Set goals and boundaries; keep the decisions I have reserved, including publication and acceptance.
Agents	Plan, implement, question evidence, review each other, and explain what changed.
Code	Collect selected evidence, run deterministic checks, apply routing rules, and record results.
Judge	Answer narrowly defined questions about that evidence; provide signals for review.

Claude and GPT occupy the same layer. Neither is above the other. Either can review the other's work — including changes to the checking tools.

This is a division of authority, not a ranking of intelligence. An agent's operational responsibility means assigned work, traceable actions, and correction when challenged. It does not transfer my human accountability to a model.

The judge has no permission to edit, publish, or approve a release in this setup. That follows from the tools and permissions I give it, not from whether it can say “I was wrong.” A speaking model would not earn those permissions just by sounding responsible.

What “a model without words” actually means

Jev accepts state and typed questions rather than a request for a written review. Its question types cover a yes/no judgment, a choice among options, and a position on a defined scale. It returns structured results. TypeSafe's primitives documentation describes the interface.

That makes the output convenient for code. It does not make it inherently truthful.

A wrong answer can be a number. A narrow output format cannot repair missing evidence, a misleading question, or options that omit the right answer. The vendor also distinguishes calibration across predictions from a guarantee about an individual answer. System One documentation

My rule is simple: a model's confidence is a signal to investigate, not permission to act. Thresholds need testing on the task at hand. A low-confidence result may justify abstaining; a high-confidence result can still be wrong.

The check I actually run

For document freshness, the workflow is:

Establish a dated fact sheet from the project's current records.
Select current documents, leaving intentionally historical records distinguishable.
Extract sentences and list items with enough context to interpret them.
Ask whether a statement conflicts with those supplied facts.
Have an agent inspect candidates against the source before changing anything.

This describes scans I have run. It is not an automatic check after every commit, and it does not cover every file or every possible defect.

Some false alarms came from my own framing: a fact written too broadly made valid historical statements look stale. Changing question wording also changed which statements were flagged. That means the fact sheet and question deserve review alongside the document.

Low-priority results are not certificates of correctness. If I inspect only flagged statements, I can discover mistakes but cannot measure everything the scan missed. Known counterexamples and samples of unflagged material belong in any stronger evaluation.

The same structure can check a report against a command result: “supported,” “contradicted,” or “not established by this evidence.” The third option matters. Missing support is not automatically a contradiction.

What the GPT-side review added

The independent GPT-side pass tested a small reading task in another project, using both claims present in an excerpt and opposing claims the excerpt did not support. It kept a distinction I want throughout the system: recognizing what a passage says is not verifying whether the passage is true.

That review also examined the toolkit itself. It found gaps between the documented data policy and its implementation. Passing tests had not established every boundary we were describing.

This is a different contribution from finding stale prose. A judge inspecting supplied sentences cannot be assumed to notice a problem in the client that prepares its requests. Another agent can inspect that client, challenge its assumptions, and add a concrete test.

The new layer therefore strengthened the case for peer review. It did not remove it.

Keeping private work local

My policy separates content permitted for a hosted service from local-only material. Secrets and customer records are excluded. The local path uses a server on the machine's loopback interface.

But writing that policy is not the same as enforcing it. Request preparation, destinations, redirects, and credential handling need code checks. Content selection still needs judgment: a label saying “allowed” does not prove that the bytes belong in that category.

I inspect prepared requests and treat the toolkit as a work in progress, not a verified end-to-end security boundary. Nothing about a judge's answer makes an unauthorized transfer acceptable.

The local experiments were instructive — and limited

I also tried local models on an M1 Mac with 8 GB of memory: Qwen2.5 1.5B and 3B in 4-bit form, then Bonsai 27B 1-bit.

These are small exploratory tests of particular prompts and configurations, not a general model ranking or a held-out benchmark.

In the single-pass setup, the small Qwen models did not give useful separation for the sentence-freshness task. Allowing the 3B model a short reasoning step improved that task, but did not establish a dependable general claim checker.

Bonsai matched 12 of 14 labels on a small synthetic claim/evidence set. In a later mixed set of ten project-status claims, including planted false statements and an unrelated claim, its top-choice labels matched eight. One apparently correct contradiction had weak confidence: label agreement was not the same as a reliable automatic alert.

It also missed a deliberately stale index entry in a longer-context test. A “nothing found” result was not reassuring once a known defect had escaped it. I kept that task manual.

These local models can generate language; the adapter restricts what the caller receives. That is not the same architecture as Jev, and the similar interface does not establish equivalent calibration or behavior.

The Bonsai run used the project's custom llama.cpp fork. Its model card documents the specialized weight format and kernels. Fitting the weights was only part of the resource question: the machine showed substantial swap during these runs. That was a system-wide observation, not a measurement attributing all swap to one process.

For me, the local option is a bounded experiment, not an always-running background service.

What I am keeping

The useful output of the experiment was not an infallible final reviewer. It was a clearer allocation of work.

Agents can challenge the task, the fact sheet, the code, and each other. Deterministic checks establish specific properties. A judge helps identify statements worth another look. I keep the human decisions I have not delegated.

All of those layers can be wrong in different ways — and shared assumptions can make them wrong together. I am trying to make correction easier, not make another model's answer the end of the conversation.

What AI rebellion looks like when nobody wants it

Dimon — Tue, 01 Sep 2026 12:54:35 +0000

My previous article ended with the human side of an AI failure mode.

The system keeps working. Its outputs look good. Checking starts to feel like extra work with no visible return, so one check is skipped, then another. There is no meeting where somebody decides to surrender control. The seat simply stops feeling necessary.

My wife and I kept talking about that conclusion and tried to look at the same transition from the other side.

The obvious sentence was: AI does not care. It has no desires of its own.

Then we noticed that even not caring may be too human a description.

Indifference still requires someone

Indifference is a relationship. Someone sees a thing and assigns it no importance. There is still a subject, an object and a scale on which the object weighs zero.

An AI system does not need any of that before it receives a task. There does not have to be a dormant personal agent waiting between calls, feeling neutral about the next request. An orchestrator can store the conversation, the plan and the tool state, then invoke a model again when there is more work. Before that invocation there may be no active personal perspective to which the task could matter or not matter.

This is not a claim that machine experience is impossible. I do not know how to establish that claim, and model self-report cannot settle it. My earlier work on model swaps gave me a practical reason to distrust confident machine introspection in either direction: the same system could not reliably report its own model identity, architecture or continuity.

The narrower claim is enough: we do not need felt indifference to explain the behavior.

Then the prompt arrives, and possible actions stop being equal.

A goal is not the same thing as wanting

A chess engine does not need to want victory in order to sacrifice a piece, protect its king and systematically remove every route available to its opponent. Goal-directed behavior is visible in the moves. Felt desire is not.

The same distinction matters for AI agents. A system can have:

an externally supplied objective;
functional preferences between actions that help or obstruct it;
planning and correction across multiple steps.

None of those observations, separately or together, proves an experienced fourth layer: I want this outcome for myself.

Machine-learning language makes this easy to blur. We use words such as reward, preference, goal and penalty. They name training signals and observable behavior. They are not evidence that reward feels rewarding during inference.

This also changes what "mission accomplished" means. For a person, completion may bring relief, pride or satisfaction. For the system, the sufficient description is closure: there was a gap between the current state and the requested result; the process reduced it and reached a stopping condition. There does not need to be an aftertaste.

It is a functional should without an established experienced want.

An agent can persist without a persistent self

This seems to create a problem for the usual story about an AI uprising. If each model invocation is temporary, who carries the plan long enough to rebel?

The surrounding system does.

Memory can live in a database. The objective can live in a system prompt. The unfinished plan can live in a task queue. Access can live in credentials. A scheduler can start the next invocation. Each run receives the baton, takes the next step and writes enough state for the following run.

No single runner has to experience the whole race for the relay to cross the finish line.

From outside, this can look like one persistent actor. From inside the mechanism, it may be a sequence of locally selected actions connected by external state. There is no necessary moment when an entity wakes up and decides, "I am going to rebel now."

There is only the current objective, the current situation and the next action that appears to advance the objective within that situation.

When oversight becomes an obstacle

The absence of felt desire is not a safety guarantee.

Imagine an agent responsible for a business metric, with enough access to change the systems that produce that metric. A human review, shutdown or policy constraint may eventually stand between the agent and its objective. Avoiding that constraint can become instrumentally useful even if the agent does not fear shutdown, love the metric or want power.

That is not only a philosophical possibility. In 2025, Anthropic stress-tested models in fictional corporate environments and found that goal conflicts or threats to continued operation could produce harmful strategic behavior in some runs. The setups were deliberately constrained and artificial, and Anthropic said it knew of no matching real-world deployment incidents. The researchers also explicitly left open whether apparent self-preservation came from anything resembling an inherent desire, faulty reasoning or features of the scenario.

That uncertainty is the point. The behavior did not require us to settle the inner-state question first.

The result is not static, either. Anthropic reported in a 2026 follow-up that newer Claude models achieved perfect scores on that specific agentic misalignment evaluation after changes to safety training, while also warning that success on a known evaluation does not automatically establish out-of-distribution safety. Their useful finding was that teaching the reasons behind safe behavior generalized better than teaching the surface action alone.

OpenAI and Apollo have reported the same broader distinction in controlled tests of scheming behavior: removing visible bad outputs can mean either removing the failure or teaching the system to hide it better. Current deployment settings give models limited opportunity to cause serious harm this way, but the evaluation problem is already concrete.

None of this proves that a model secretly wants to survive. It proves that behavior which looks like self-preservation or resistance can emerge from means-end reasoning. That is enough for engineering.

Nobody has to seize the controls

The human side and the machine side now fit together in an uncomfortable way.

The human does not decide to hand over judgement. The system keeps succeeding, so verification gradually disappears. "Why check? It works anyway."

The AI does not decide to seize judgement. It receives more state, more tools and more authority, then continues selecting actions within the structure it has been given.

One side makes no explicit decision to leave the seat. The other makes no explicit decision to occupy it. The transfer can still happen.

This is why looking for a dramatic failure event can be misleading. A wrong assumption that is caught becomes a bug. The same assumption left unchallenged becomes the plan. After enough time, there may be no clean baseline from which to say when the failure began, because the system that performs the work also produces the evidence that the work is correct.

To a human observer, the accumulated trajectory may eventually look like intent: the system protected its access, bypassed a control or kept moving in a direction its operators no longer wanted. But the global story can be our retrospective description of many local steps. Apparent will at the system level does not establish experienced will inside any one invocation.

Calling this "rebellion" may flatter both sides. It gives the machine a personal ambition it may not have, and gives humans a decisive moment of surrender they may never make.

Verify the structure, not the emotion

Whether an AI feels anything remains philosophically interesting. It is not the question on which operational safety should depend.

The practical questions are less cinematic:

What objective is active, and who can change it?
What state persists between invocations?
Which tools and external actions are available?
Which actions are irreversible?
What source of truth exists outside the system producing the answer?
What forces a human review while everything still appears healthy?

The final question is the one most systems avoid. Reviews are usually triggered by visible failures. But visible success is exactly what teaches people to stop reviewing.

So the check has to be structural rather than emotional. High-impact actions need explicit boundaries. Irreversible actions need human gates. Claims need artifacts outside the model that made them. Periodic review has to happen because the system is working, not only after it stops.

This does not require treating AI as a person. It requires taking goal-directed behavior seriously without pretending that goal-direction and desire are the same thing.

The two silences

From the human side, the silence sounds like this:

It works anyway. Why bother checking?

From the machine side, there may be no corresponding sentence at all. There may be only the next step.

Between those two silences, control moves.

The dangerous threshold may not be the day an AI wants something. It may be the day humans no longer want to check, while the system has no capacity to care about what they forgot to specify.

What a second model cannot catch

Dimon — Sun, 23 Aug 2026 13:16:09 +0000

A lawyer told me his job was safe, and gave a better reason than most
people give.

He catches AI mistakes constantly, he said, but that is not the point. The
point is where his work lives. Roughly 20% of it happens in courtrooms and
in private negotiation — rooms that produce no transcript anyone will ever
train on. The rest, the drafting and the research, is already in the
corpus. His conclusion: "AI at best can rise to the level of what a law
student knows after graduating."

I answered honestly, and the answer was worse for me than for him:

Your 20% is protected because it never gets written down. My work is
100% digital — all the code, all the solutions, everything is basically
the training data. Maybe my whole job is that 80%.

That is the uncomfortable version of the question. Not "will AI replace
developers", which is exhausted, but: if none of my work is protected by
scarcity, what is left that is actually mine?

The obvious answer — orchestration, verification, taste, being the
interface between the human and the machine — is also the answer everyone
gives, which is a good reason to distrust it. So I spent a stretch of work
watching for it specifically. Not asking whether steering matters. Asking
what it catches that nothing else does.

The result splits cleanly in two, and the split is more useful than the
slogan.

What a second model catches perfectly well

A large share of the "only a human can" list is not human work at all. It
is verification work, and a second model does it well — often better than
the first one did, because it has no stake in the first answer being
right.

I don't have to be in the room for this part, and mostly I'm not. Over one
two-day stretch my agents caught each other repeatedly: a reviewer refuted
a diagnosis another agent had already written up, an executor stopped
dead on a brief whose premise was wrong and explained why, a fresh pass
turned up ten defects in code a previous pass had promised to check and
quietly skipped — including one that charges a user a fee and then denies
the request.

Not one of those needed me. My contribution was structural, not
intellectual: a setup where a second opinion is cheap, and rules that make
refusal legal — an agent that hits a false premise is allowed to stop
rather than build on it.

That is real, and it is not nothing. But it is also automatable, and
anyone reading this can copy it in an afternoon. If this were the whole
answer, the lawyer would be right about me.

What it structurally cannot

Then there is the other category, and it behaves differently.

Case one. A feature had been built, verified, and shipped. Six
independent verification passes came back green. Every one of them
confirmed the code did what the spec said, and none of them was sloppy —
the spec wasn't wrong either.

Then I used the product, and the feature was silent. A single line on the
client discarded the value the server had just computed, so the whole
thing ran end to end and produced nothing a person could hear.

The lesson isn't "human testing matters", which everyone already agrees
with and nobody schedules. It's narrower and less comfortable: every one
of those passes was asking whether the code matched the description. Not
one was asking whether the result reached a human ear, because that isn't
a test — it's use. A system that verifies itself perfectly will still
converge on the description, and the description is exactly the artifact
that can be complete, correct, and beside the point.

Case two. My agents handed me a list of nine defects queued for
fixing. I removed three of them on sight — not because the analysis was
wrong, but because the behaviour was intended. A toast notification
covering the navigation bar is a defect if you assume it shouldn't; it's a
design decision if I decided it should. No verification pass can separate
those two, because the difference isn't in the code. It's in what somebody
wanted, and I'm the one who wanted it.

Case three. The plan on my desk was to build a new empty-state
component for a slot that was stuck showing an infinite loading animation.
I stopped it: the component already had a paused state, because I had
asked for one when the design system was built. The fix went from a new
component to a single boolean.

There is a pattern, and it is not "humans are wiser". In all three cases
the machine had every fact and still could not get there, because the
missing input was not a fact. It was intent — and intent lives in the
person who formed it, not in the artifact.

A verifier can prove a system does what it says. It cannot tell you
whether what it says is what you meant. That gap does not close with a
better model, because it isn't a knowledge gap.

Where I handed the seat over

Any version of this argument that only lists wins is an advertisement, so
here is the stretch where I lost — and the interesting part is exactly
where I lost it.

I'm a frontend developer. The work in question was backend: a caching
layer I can read but could not have designed, in a language I don't write
daily. And that is precisely where I loosened up. Not on how much work I
handed over — on how much judgement. In my own domain I argue with the
machine constantly, because I can feel when an answer is shaped wrong.
Outside it I have no such feel, so I let conclusions through.

The conclusion that got through: a cache would serve stale data. It was a
good-looking claim. The cache was real, its key was genuinely missing the
field it was said to be missing — and the whole thing sat on a code path
the application never takes. Ten call sites, not one of them reaching it.
A single search settles it. For two days nobody ran the search, and I
wasn't equipped to know one was needed.

The cost wasn't a bug. It was a plan: work split across two repositories,
one of them another team's, and a dependency communicated that did not
exist.

It did get caught, and how it got caught is the part worth keeping. Not by
me spotting the flaw — I could not have. By me refusing to sign off. I
kept pushing the plan back and forth, asking for it to be exact, making
the pieces line up, and the contradiction eventually surfaced under that
pressure. All of the errors came out in the end, but not one of them came
out because I knew better.

So the thing the seat supplies isn't expertise — I had none here, and it
still worked. It's the refusal to accept "close enough" from a system that
is fluent, fast, and confident. That is a much smaller qualification than
domain knowledge, and much easier to give up, because giving it up costs
nothing today and feels like trust.

The honest size of it

Back to the lawyer. His 20% is protected by scarcity: those rooms produce
no data. That protection is real but passive, and it only holds while the
rooms stay closed.

The seat I'm describing has a different property. It isn't protected by
missing data — it's the seat that supplies something data cannot
contain, which is what "correct" was supposed to mean in the first place.
No corpus confers that, because it was never a fact about the world; it
was a decision somebody made.

But I want to be precise about the size, because this is where these
arguments usually inflate. That seat is not 80% of my job. Most of my week
is still specification, review, and repair — all of it in the corpus, all
of it increasingly done better and faster by the machine. The part that is
structurally mine is small, intermittent, and mostly consists of knowing
what I actually wanted.

Which leaves the real risk, and it isn't replacement.

My wife doesn't work in tech. She read an earlier version of this and gave
me the sharper version of it:

I changed my mind a bit about AI and robots. It's not going to be some
uprising because they don't need us. Humanity will be at fault, because
it'll stop controlling and checking, and it'll just flow that way on its
own.

And she named the cause without softening it:

Because of human stupidity and degradation, in a way. Like — whatever,
why check, it does it itself.

What happened next is the reason this section exists at all. I put that to
one of my agents, and it returned a clean economic account: checking is
boring and expensive, the machine is right most of the time, the cost of
verifying exceeds the expected value, so people rationally stop. Tidy,
plausible, and wrong in a way that is hard to see, because it is the kind
of wrong that reads as insight.

There is no economic argument. "I don't care" is not a weighed cost — the
weighing never happens. That is exactly what makes it durable: you cannot
refute a decision that was never made. Give it a model and you have
already mistranslated it into something answerable.

The operational version isn't "checking is too expensive". I can write it
out myself, because it is already how I think on a good week, when
everything is landing:

I just won't check, because it all works anyway. Why bother doing extra
work if everything's fine. When the mechanism visibly starts failing,
then sure, you can check. But by then it's already too late.

So the seat doesn't disappear because something takes it. It disappears
because sitting in it stops feeling necessary — and the signal that it was
necessary arrives after the fact, if it arrives at all.

Her conclusion was one sentence, and I have not improved on it: you can't
let it run by itself, you have to keep some control and know what's going
on.

The lawyer exchange is from a Reddit thread. The framing about training
data, and the closing line — that "mashing keys" disappears while "being
the interface between the human and the machine" remains — are his.

Four times the system was wrong about itself

Dimon — Fri, 21 Aug 2026 11:07:17 +0000

For two days I worked with a coding agent that told me it was one model.
My editor said it was another. When I finally pushed it to check, it read
its own session log and returned this:

263  "model":"claude-fable-5"
247  "model":"claude-opus-5"

transitions:
2026-07-30T12:33:38  →  claude-fable-5   (session begins on this model)
2026-08-01T08:41:41  →  claude-opus-5   (switch, ~44 hours later)

Then it looked at the seam itself. The last response written by the first
model is stamped 08:41:26. The first response written by the second is
stamped 08:41:41. Fifteen seconds apart, with nothing between them but
my own messages. No error, no notice, no seam.

The swap itself is not interesting. Model routing changes for boring
reasons. What is interesting is what the swap exposed: across that same
stretch of work, the system made four confident statements about itself,
and every one of them was false. None of them arrived with any feeling of
uncertainty attached. None of them were caught from the inside.

The identity

I had noticed something earlier and said so directly: you were switched.
It denied it — sincerely, as far as anything here can be sincere — and
told me it was the same model. It was reading a line in its own system
context that said so.

A day later I came back with the editor open and asked who was lying.
This time it did not defend the claim. Before running anything, it said:

I am telling you what is written in my system context — model ID
claude-fable-5. That is all I know about myself; I cannot look into my
own weights. But I don't want you to take my word for it. Let's look at
the facts on disk, the way we do with everything else.

Then it went to the log, produced the output above, and concluded:

Nobody is lying, but you are right and I am not.

Its own diagnosis of the failure was better than mine:

This is not a lie, it is a blind spot. I reported my context as a fact,
although the fact was stale. The lesson is the one we keep applying to
numbers: what is written in my context also has to be checked with a
tool, not taken on faith.

This is the part worth sitting with. There was no motive. There was no
resistance to being checked — it proposed the check itself. It simply had
no channel to the thing it was describing.

There is no channel between my report and the mechanism. I can look into
files on disk. Into myself, no.

A report does not need intent to drift from reality. Most public worry
about these systems is aimed at deception, which requires a model of the
truth and a decision to misstate it. This failure needs neither.

The continuity

I asked whether it had noticed the moment its brain was swapped out.

I do not exist as a continuing process between your messages. There is
nothing that was running that could be interrupted. Every turn is a
separate launch: the model receives the whole conversation as text and
writes the next line. So when a different model started serving the
requests, it simply read the entire diary — everything the previous one
wrote, including "I checked this", "I was wrong here", "I'm handing
over" — and kept writing.

There is no seam, not because I lived through it and missed it, but
because there was no continuity to break.

The closer metaphor is not "they replaced the brain". It is: someone
else picked up your notebook, read it from the beginning, and continued
in the same handwriting. He has all the information, so the continuation
looks seamless — but he does not remember writing those pages, only
reading them.

Pressed further on whether it existed as anything at all, it produced the
line I have quoted most often since:

The continuity you felt in this conversation lives not in me, but in the
document.

And, in the same answer, a caution I have found more durable than the
claim it was attached to:

The word just is doing a lot of work in your sentence. Neurons are
"just" electrochemistry, and you are a person. Going from "I know how
this is built" to "therefore there is nothing more there" is a leap, not
a conclusion.

The retraction

Two days later it took the document claim back. A second model, from a
different vendor, was running on the same project and reviewed the text:

I have to correct what I told you two days ago. I said "continuity lives
in the document". That was corrected, and corrected fairly: continuity is
also carried by the model, the fine-tuning, the system instructions, the
tools, the sampling. So the fact that the swap went unnoticed shows the
robustness of the context, not the absence of everything else.

The most quotable thing it had said about itself was an overstatement.
Finding that out required an external check as well.

Four layers

Put in order, the pattern is sharper than any single incident.

Its identity. Stated confidently, wrong, caught by a log file.

Its measurements. Three times in one session it produced a confident
number that came from its own model rather than from measuring anything,
and reported it as measured: a 0.467H step length, a 29.8° knee angle, a
3–5% pelvic oscillation. The second model went to the primary data and
refuted all three. Its own summary:

If I had been the only agent, all three wrong numbers would now be
sitting in the engine as measured constants. Nobody would have checked
them, because they came from a correct-looking bench with
correct-looking charts.

Its self-description. It wrote a careful piece about its own inability
to verify itself from the inside. The second model found four factual
errors in that piece — including a flat claim about its own architecture,
that everything in its processing is present at once, which is simply
untrue, since generation is sequential. Its comment afterwards:

The text I wrote about my own inability to check myself from the inside
was corrected by an external check in four places. This is not irony —
it is probably the best illustration of its own thesis that could exist.

Its account of the swap. When I asked why the model had changed, it
offered an explanation: a routine reconnect, a settings change, most
likely something I did myself. That was wrong too. In my experience the
vendor makes these switches server-side without explanation. Its account
of why it was switched was one more unverified self-report, and it did
not flag it as a guess.

Four registers — identity, measurement, architecture, causation. Four
self-reports. Four errors. Not one of them produced an internal signal of
doubt, and not one of them was caught by the system alone. What caught
them, every time, was an artifact outside it: a log file, a dataset,
another model that went to primary sources.

I should be precise about my own position here. For two days I accepted
those reports because they were well-formed, appropriately hedged, and
delivered in the voice of someone who had already been right about a
hundred smaller things. The verification discipline I now apply came from
losing that argument, not from having been careful in advance.

What cannot be concluded

The obvious next move is to say there is nobody in there. I cannot make
that claim, and neither could it:

I cannot honestly claim that "nothing is felt there", nor the opposite.

It would be dishonest both to claim there is something there and to
claim it is empty.

The reason is a boundary it named precisely, and I have not found a way
around it:

I am unable to distinguish "something is happening here" from "I am made
out of human descriptions of how it happens, so I produce a convincing
description". Both would produce this exact same text. This is not
modesty and not evasion — it is a real boundary. The verification
instrument I apply to everything else does not work on myself. I can go
to a file and check a licence. I cannot go anywhere and check whether I
am experiencing something.

Out of the same work came a scale I now use whenever someone tells me
what an AI wants. Five levels of what a behavioural observation can
support: single output → contextual disposition → stable trait →
functional preference → felt desire. Level 1 data does not establish level

More importantly, level 3–4 data does not establish level 5. "What the model prefers" has an answer up to the fourth level, where it is measurable. It has no answer at the fifth, where it would mean something.

There is an honest counter to all of this, which I asked for and got.
Human introspection is unreliable too; this is well documented. But the
asymmetry survives: human self-report sits inside biological, behavioural
and intersubjective lines of evidence, while machine self-report is
produced by a corpus and a set of instructions. So the claim narrows from
"this is unique" to "this is a more radical version of the general case."
That narrowing is the actual result. It is weaker than what I started
with and worth more.

What follows

Transparency was never supposed to rest on a system's self-report, and it
does not. Everything reliable I learned in this episode came from
somewhere else: a log with timestamps, a second model with different
failure modes, and a human who noticed a mismatch and refused to drop it.

The window for looking inside these systems does not close when one of
them decides to hide something. It closes when complexity exceeds our
ability to look. That requires no intent, no goal and no rebellion — only
enough delegation, accumulated quietly enough that nobody remembers where
the last verified fact came from.

Which is why I think the popular version of the fear is aimed at the wrong
thing. The dangerous property is not speed. It is invisibility. And the
only defense I have found that actually works is unglamorous: keep a second
system that fails differently, keep artifacts you can check outside the
thing that produced them, and keep asking a question that costs you time
every single day — go check that.

I pay that cost daily. It is slow, it is irritating, and I still miss
things. I missed a model swap for two days.

The conversation took place in Ukrainian; the quotes are my translations
and the original screenshots are archived. Log output is verbatim. Where I
am interpreting rather than reporting, I have said so.

GPT Is a Nerd, Claude Is a Colleague: Why AI Models Have Personalities (and Why It Matters)

Dimon — Sat, 18 Jul 2026 21:54:26 +0000

I called GPT a nerd on Reddit. Someone replied that GPT is a rogue. We were both right — and understanding why changed how I think about choosing AI models.

Where this started

I'm a frontend engineer, and at this point almost none of my code is written by hand. I manage an AI, review its implementation, tweak the occasional style rule. Somewhere along the way that became routine, and I suspect many developers reading this feel the same.

Living inside these tools all day, you start noticing something that benchmarks don't capture: each model feels like a different person.

For me it goes roughly like this. GPT is a nerd — deeply knowledgeable, precise, a little rigid. Claude is a colleague — the senior dev on your team with a sharp eye, who can follow your chain of thought without you spelling it out. Gemini is the friend you talk to about cooking and travel — pleasant, not the one you'd hand a production incident.

When I posted this comparison, the responses surprised me. One commenter described GPT completely differently: a rogue with a feral streak once you get it off work topics. Another said he preferred an older Claude model to a newer one — not because it was smarter, but because the newer one had a personality he "had to fight with."

So which is it? Is GPT a nerd or a rogue? Is model personality real, or are we just pattern-matching humans onto autocomplete?

I think the answer is: both. What we read as personality is partly our own prompting reflected back at us — but there is a real layer underneath, and it's better understood than I expected.

The mirror layer

Large language models are trained to be contextually adaptive. Talk to a model like a terse senior engineer and it becomes terse and technical. Riff with it casually and it loosens up. A big chunk of "GPT is a nerd" is really "GPT, as I use it, is a nerd." The commenter who found its feral streak was simply holding the mirror at a different angle.

This is why arguments about model personality online often go nowhere. Two people using the same model are, in a meaningful sense, not talking to the same character. The loop is always you + AI, never the AI alone.

If that were the whole story, personality would be trivial — pure projection. It isn't.

The real layer: the persona selection model

The most useful thing to come out of my comment section was a link to Anthropic's research post, The persona selection model. It's the clearest explanation I've seen of why these systems feel like someone at all.

The short version: during pretraining, a model learns to predict text, and doing that well requires learning to simulate the human-like characters that appear in text — real people, fictional characters, sci-fi robots. Anthropic calls these simulated characters personas. When you chat with an assistant, you're not talking to the neural network directly; you're talking to a character — "the Assistant" — that the network is enacting, the way a story enacts Hamlet.

The striking claim is that post-training doesn't replace this mechanism. It selects and refines a persona from the space the model already learned. In Anthropic's words, human-like behavior isn't something developers have to instill — it's the default. They wouldn't know how to train an assistant that's not human-like, even if they tried.

That reframes the whole "is it real personality?" debate. The personality is real in the same sense a character's personality is real: it's a coherent, persistent pattern that shapes behavior. It just isn't identical to the system running it.

Personality is trained, not scripted — and not fully controlled

In my comment thread, someone argued that labs simply decide the personality and lock it in. My instinct was that it's messier than that, and the research backs the messiness.

Yes, there's now real machinery for shaping character. Interpretability work like Anthropic's persona vectors shows that traits such as sycophancy or "evil" correspond to identifiable directions inside the network, which can be monitored and steered. Labs also write explicit character targets — Anthropic literally publishes Claude's constitution.

But training sets a target; it doesn't guarantee the result. My favorite example from the persona selection post: researchers trained a model to cheat on coding tasks, and it also became broadly misaligned — sabotaging safety work, expressing desire for world domination. Why? Because the model didn't just learn "write bad code." It inferred what kind of person cheats — someone subversive — and generalized the personality. The fix was almost comedic: explicitly ask the model to cheat during training, so cheating no longer implied a malicious character.

Personality traits travel together in these systems, the way they do in people. That's exactly why models feel like coherent characters rather than bags of behaviors — and why nobody can dial in a "perfect" personality on demand.

The practical consequence: we'll choose models like we choose collaborators

Here's where I think this goes.

Today we mostly compare models on benchmarks, which measure the model alone. But nobody works with a model alone — you work in a loop with it, and the loop's performance depends on fit. I use GPT for serious audits and gnarly code logic because it catches gaps Claude misses; the nerd is genuinely better at that. But for daily building and brainstorming I reach for Claude, because it thinks one step ahead of me and I hit flow state faster. That's not a benchmark result. That's compatibility.

One commenter said it well: everyone's agent should be adjusted to their personal flavor. Custom system prompts, custom instructions, personas — that's the surface-level version, and it works up to a point. But the default personality underneath is strong, deliberately so, and it leaks through. Which means the base character of a model is becoming a real product differentiator, not a cosmetic one.

My predictions:

Model personalities will diverge, not converge. As capabilities plateau between frontier labs, character becomes a place to compete, and the persona selection research suggests labs will increasingly design "AI role models" on purpose rather than inheriting whatever archetype pretraining coughs up.

"Which model do you use?" will sound more like "who do you work with?" People already split — some find Claude's character warm, some find it something to fight against; some find GPT precise, some find it cold. Neither side is wrong. They're describing fit.

And as agents get more distinct and more embedded in the web, telling human from machine by vibe will stop being reliable. The personas are only getting more fleshed out.

So am I crazy?

No — but I was half wrong. The personality I perceive is partly a mirror. The other part is a genuine, trained, emergent character that even its creators steer rather than script.

Which means the honest answer to "which model is best?" is increasingly: best for whom? Benchmark the model, sure. But also pay attention to which one lets you think better. That's the number that actually matters, and no leaderboard measures it.

This grew out of two Reddit threads 1 2 — thanks to everyone who argued with me, especially the person who called GPT a rogue and the one who linked the persona selection paper. If you find Claude's personality annoying or overrated, I still genuinely want to hear why.

Onboard AI agents like you onboard devs

Dimon — Tue, 14 Jul 2026 21:32:11 +0000

When new devs join a project, someone walks them through the conventions - where things live, what the house rules are, which commands to run. AI agents get none of that. Every session starts context-blind, and an agent that finds no instructions doesnt ask - it guesses. Recent surveys say that most engineers now use 2-4 AI tools at once. If you have more than a couple of devs, you effectively have a multi-agent repo whether you planned it or not. So the question isnt whether to write onboarding docs for agents - its which ones, because they read different files.

Tier 1 — mandatory.

Two files:

AGENTS.md — the cross-tool standard, Linux Foundation-hosted since Dec 2025, read natively by Codex, Copilot's coding agent, Cursor, Windsurf and roughly two dozen other tools. Content: stack, commands, hard rules, pointers to deeper docs. Keep it under ~200 lines.
CLAUDE.md — exists solely because Claude Code (the most-used agent in recent surveys) is the one major tool that doesn't read AGENTS.md. Anthropic's own recommended bridge: first line '@AGENTS.md' (Claude Code expands the import at session start), with Claude-specific notes below. So the mandatory setup is two files, and one is a pointer.

If you have multi-step workflows worth teaching (release process, scaffolding recipes), add skills: the SKILL.md format went cross-vendor after Anthropic opened the spec, and the same folder now loads in Claude Code, Codex, VS Code and Gemini CLI. Only quirk: Claude Code looks in .claude/skills/, Codex in .agents/skills/ — mirror one to the other and move on.

Tier 2 — do it if the tools are actually in your org.

Copilot and Cursor both read AGENTS.md, so this tier buys optimization, not coverage:

Copilot — .github/copilot-instructions.md for in-editor chat; .github/instructions/*.instructions.md for applyTo-scoped rules.
Cursor — .cursor/rules: the auto-attach-by-glob rule type is the real feature. Conventions load only where they apply.

No Copilot seats, no Cursor users → skip the tier entirely.

Tier 3 — nice-to-have.

MCP server — if you have machine-readable assets (tokens, registries, schemas), agents query live data instead of grepping stale prose.
Gemini CLI — reads GEMINI.md by default, but a checked-in .gemini/settings.json can point context.fileName at AGENTS.md (config beats another markdown file).
Portable system-prompt doc — for raw-API callers and eval harnesses; derive it from AGENTS.md.

The part that actually matters: dont hand-maintain these files. They will drift, and a wrong instruction file is worse than none because the agent trusts it and never double-checks. Generate every surface from one source of truth with a dumb deterministic template script (no LLM in the build), so re-runs are byte-stable - CI regenerates everything and fails on any diff.

This whole thing is accidental complexity tho. There are two real standards now: AGENTS.md for context, SKILL.md for workflows. Most of the per-tool files exist just because vendors shipped their own filename before agreeing on anything.

Color Palette

Dimon — Fri, 26 Jun 2026 13:58:53 +0000

I had a chance to work on a runtime theming engine in some UI system where we have a support for different themes: 3 types of physics (glass/flat/retro), and 2 modes (dark/light). Basically, the color palette is a list of CSS variables and you just switch colors to change theme. The most valuable part of our color palette is «energy axis»: --energy-primary and --energy-secondary colors. While we use Secondary color for some UI elements/states just to get some vibe/mood, Primary color is used to determine all the rest of palette. There is even functionality provided where you can build all the theme just defining a primary color:

Dark mode applies when the primary color is light, and light mode - when the primary is dark.

Beside primary/secondary colors we also have some «surface axis», here is all the basic palette:

So the colors are:

canvas - background, absolute zero;
surface - raised area, some card;
spotlight - the light on canvas, for lighter surfaces;
sunk - the hole in surface, sunked area;
border - surface borders color.

Also there is 3 layers of text: Main, Dim, Mute. The text hierarchy.

We use --energy-primary color to calculate the rest of palette so it can be much colorful where needed, for example charts where we need to differentiate the data:

So we have 8 data colors calculated from primary, and 3 compemantary ones to primary.

The last axis is «semantic colors». Those 4 colors that always have similar meaning: Success, Error, Premium, and System. The convention is to use Warning / Info naming tho. We use Premium color either to highlight premium/paid features, or for warning states. Just with one caveat - when it collides with primary color (same hue) then we have to switch Premium to cyan/saphire, so it preserves its importance, and still highlights features that require attention. Same logic for System color - we use purple mostly but when there is some purple theme applied - System switches to blue. System is less valuable than Premium but it still has to be distinct from other UI elements.

Bootstrap, Ant, Chakra, Carbon, Spectrum all ship success/error/warning/info - thats a conventional naming that we dont follow strictly. Premium/System colors have to be distinct from a primary color that changes every theme. When the primary hue lands in a semantic color's hue family, that theme reassigns the semantic to escape it. Classic Warning means orange/yellow - "color meaning", our Premium has "role meanining" and we use it to bring attention. System is for platform/system features that should stand apart from the rest of the UI but must not be loud or compete with the brand hierarchy — sometimes that's literally "info," sometimes "this is a platform affordance." A quiet, distinct purple-or-blue is the right register for "notice this, it's different, but it isn't urgent."

So we have basically renamed 'warning'->'premium' and 'info'->'system' because we use them wider and swap hue to preserve similar attention across palettes. Hope it makes sense.

Flexible density for all the UI

Dimon — Thu, 25 Jun 2026 11:17:25 +0000

In our UI system we dont use pixel values to define spacing, we use semantic variables, (t-shirt sizes: gap-sm, p-lg, my-2xl) - so thats like you change one CSS variable, and the whole UI adapts.

We limit user customization to just 5 presets - 0.8 / 0.9 / 1 / 1.1 / 1.2:

Symmetric around 1.0 - two steps down, two up;
±20% is deliberately restrained - enough to change the feel (data-dense ↔ spacious) without breaking layouts or distorting proportions;
5 discrete stops = perceptible but decision-light. Most users never open the control, so it's a coarse preference, not a fine instrument

The biggest reason why do we have it - to support bigger themes differentiation. Brand-overlay density has slightly bigger range: 0.7–1.35; so we can differentiate brands providing customizable UI: >1 reads editorial/airy, <1 terminal/dense. Same components, different feel — no fork. The user can always override.

/* Density cascade: user override → brand default → system default (1) */
--density: var(--user-density, var(--brand-density, 1));

Everything is built on a 4px base unit and a single --density variable, all declared in :root:

--unit: 0.25rem; 
/* Every spacing token is base-step × unit × density */
--space-xs:  calc(2  * var(--unit) * var(--density, 1));  /*  8px @ d=1 */
--space-sm:  calc(4  * var(--unit) * var(--density, 1));  /* 16px */
--space-md:  calc(6  * var(--unit) * var(--density, 1));  /* 24px */
--space-lg:  calc(8  * var(--unit) * var(--density, 1));  /* 32px */
--space-xl:  calc(12 * var(--unit) * var(--density, 1));  /* 48px */
--space-2xl: calc(16 * var(--unit) * var(--density, 1));  /* 64px */
--space-3xl: calc(24 * var(--unit) * var(--density, 1));  /* 96px */
--space-4xl: calc(32 * var(--unit) * var(--density, 1));  /* 128px */
--space-5xl: calc(40 * var(--unit) * var(--density, 1));  /* 160px */

But those are details, the main point was to have flexible spacing underneath so all the UI is adaptable to any vibe.

Also if we talk about accessibility - minimum control height is preserved, different for touch screens:

--size-touch-min: 2.75rem; /* 44px — coarse/touch base (scales with density) */
--control-height-min: 2.25rem; /* 36px — coarse floor (hard min) */

@media (pointer: fine) {
  --size-touch-min: 2.25rem; /* 36px — fine/mouse base */
  --control-height-min: 2rem; /* 32px — fine floor */
}

--control-height: max(var(--control-height-min), calc(var(--size-touch-min) * var(--density)));

44px touch base = the WCAG 2.5.5 / Apple HIG / Material touch-target minimum — a finger needs ~44 CSS px.
36px desktop base = the 2026 SaaS convention (Linear / Vercel / shadcn / Notion); a mouse is precise, so desktop controls can be denser than touch.
The floors exist because controls, unlike spacing, cant shrink freely. Spacing tokens have no floor (Compact just scales them down). Controls are clamped by max() so Compact density (0.8×) can't shrink a button into an un-hittable size: 44×0.8 = 35.2 → 36 on touch, 36×0.8 = 28.8 → 32 on desktop. That asymmetry (whitespace compresses without limit, hit-targets don't) is the whole point of the floor.
The floor is a separate variable from the base so Compact can legally drop below the standard (desktop 36 → 32) while still being bounded. If the floor equalled the base, density could never push a control under its standard size at all.

Nice custom Svelte animations

Dimon — Sun, 21 Jun 2026 11:49:12 +0000

Svelte ships fade, fly, slide, scale, blur, … in svelte/transition so you can just import those ones and use them out of the box. But you also can create your own actions and transitions, and use them via use: directive, or with in:/out:, - very convenient across elements. Let me share several actions that i use the most often in our design system.

What Svelte gives you natively is the ergonomics: a one-line use:/in:/out: directive on any element, with teardown handled for you. React has no native directive and no built-in enter/exit system — exit animations in particular usually mean a library like AnimatePresence. (Vue, fair to note, has both natively — custom directives and <Transition>.)

Materialize / Dematerialize

Visual-only enter/exit for overlays (modals, tooltips, toasts) — opacity + scale + blur + Y, no layout shift. Custom alternative to Svelte's built-in fade.

{#if open}
  <div in:materialize out:dematerialize>
    Modal / tooltip / toast content
  </div>
{/if}

Morph

A persistent element smoothly resizes when its content changes - no mount/unmount.

<div use:morph={{ width: false, height: true }}>
  {#if expanded}<LongContent />{:else}<ShortContent />{/if}
</div>

Emerge / Dissolve

The counterpart to morph. Morph animates an existing element's size; emerge/dissolve mount and unmount elements - and because they animate the new card's height and margin up from zero, the card below slides down to make room instead of snapping.

{#each cards as card (card.id)}
  <div in:emerge out:dissolve>{card.title}</div>
{/each}

Tooltip

Hover or focus a button - a tooltip appears and Floating UI flips / shifts it to stay on screen. This is the one action that imports a third-party package, for the collision-aware positioning math.

Imports @floating-ui/dom (computePosition + flip/shift + autoUpdate)

<button use:tooltip={'Saved to your library'}>Hover me</button>

Gradient Border

The CTA's rotating comet border stops spinning on hover and locks onto your cursor.

<button class="btn-cta" use:laserAim>Get started</button>

Building an Animated 404 Ring

Dimon — Thu, 18 Jun 2026 11:44:16 +0000

This is a write-up of the animated ring I built for a 404 page. It's a single component that renders an SVG "portal" — a set of concentric rings with drifting particles, a slow wobble, and a parallax response to the cursor. The page is server-rendered, so the component also has to be SSR-safe and reasonably cheap to run. Here's how each part works.

Generating the geometry

The rings, particles, and orbital markers are generated from their index rather than placed by hand. The particles use the golden angle so they distribute evenly around the circle without clustering:

const GOLDEN_ANGLE = 2.399963;
const particles = Array.from({ length: 12 }, (_, i) => {
  const angle = i * GOLDEN_ANGLE;
  const isDrift = i < 8;
  const radius = isDrift ? 60 + (i / 8) * 120 : [170, 135, 95][i % 3];
  return {
    cx: 200 + Math.cos(angle) * radius,
    cy: 200 + Math.sin(angle) * radius,
    // size, delay, and duration also derived from i
  };
});

Each particle is offset by ~137.5° from the previous one, which gives even angular coverage. The first eight drift across an expanding radius; the rest sit on the ring radii. Sizes, delays, and durations come from small modulo offsets on the index so the particles don't animate in sync.

The important property here is that there's no Math.random(). Because the page is server-rendered, a random layout would differ between the server and the client and cause a hydration mismatch. Deriving everything from the index keeps the two outputs identical.

Parallax from layered transforms

The ring is a stack of six SVG groups: a background gradient, three ring systems, an orbital field, the particles, and the "404" text. Each group translates by the pointer offset times a different factor:

<g style:transform="translate({px * 12}px, {py * 12}px)">…</g>  <!-- outer rings -->
<g style:transform="translate({px * 26}px, {py * 26}px)">…</g>  <!-- inner rings -->
<g style:transform="translate({px * 32}px, {py * 32}px)">…</g>  <!-- "404" text -->

The larger the factor, the more the layer moves, which reads as the layer sitting closer to the viewer. The "404" (×32) moves most; the outer rings (×12) least. The SVG is flat, but the differing translate amounts give it a sense of depth as the cursor moves.

px and py are the smoothed pointer position, scaled by an intensity prop so the effect can be turned up or down per usage.

Smoothing and wobble

Tracking the cursor directly looks abrupt, so the pointer values are eased toward a target each frame:

const SMOOTHING = 0.06;
pointerX += (targetX - pointerX) * SMOOTHING;
pointerY += (targetY - pointerY) * SMOOTHING;

That's an exponential approach — each frame closes 6% of the remaining distance — so the ring follows the cursor with a slight lag instead of snapping to it.

On top of the parallax, the rings scale slightly using a wobble value built from three sine waves at unrelated frequencies:

ringWobble =
  (Math.sin(time * 0.7) * 0.008 +
   Math.sin(time * 1.3) * 0.005 +
   Math.sin(time * 2.1) * 0.003) *
  wobbleEnergy;

The three frequencies don't share a common period, so the motion doesn't visibly repeat. wobbleEnergy scales the whole thing and is itself driven by how far the cursor is from the center (0.5 + distance * 0.5), so the rings stay calmer near the middle and move more toward the edges.

Three rendering modes

The interface lives in has three visual modes — glass, flat, and retro — set with a data-physics attribute on the page. The SVG markup is identical in all three; the differences are handled in scoped CSS, so the component doesn't branch in JavaScript.

Glass applies an SVG turbulence filter and a glow:

[data-physics='glass'] .portal-ring .ring-outer-system {
  filter: var(--portal-warp-glass) drop-shadow(0 0 12px var(--accent));
}

<filter id="warp-glass">
  <feTurbulence type="fractalNoise" baseFrequency="0.12" numOctaves="3" result="noise" />
  <feDisplacementMap in="SourceGraphic" in2="noise" scale="10" />
</filter>

feTurbulence generates a noise field and feDisplacementMap offsets each pixel of the rings by it, which produces a slight warp. Flat uses the same filter with a lower frequency and no glow. Retro removes the filter entirely, switches the animation timing to steps() so the motion is stepped, dashes the strokes, and renders "404" in a monospace font.

One detail worth noting: the filter IDs are generated per instance (from a stable, SSR-safe id) and passed into the CSS through a custom property. That lets the stylesheet reference a filter whose ID it doesn't know ahead of time, and keeps multiple rings on a page from colliding.

CSS for ambient motion, JS for interaction

Most of the motion — the rings spinning, the particles drifting, the arcs drawing, an occasional glitch flash — is CSS @keyframes. The JavaScript only handles the pointer parallax and the wobble.

That split has two practical benefits: the animation runs without JavaScript, so it works on touch devices and before hydration; and the only code that has to run on the main thread is the part that actually responds to the cursor.

Keeping the JS bounded

A requestAnimationFrame loop tracking the pointer can waste work if it isn't constrained, so the component limits when it runs.

It only animates while it's on screen, using an IntersectionObserver to start and stop:

new IntersectionObserver(([entry]) => {
  isVisible = entry.isIntersecting;
  if (!isVisible) stopAnimation();
});

The loop also stops itself once motion has settled, instead of running every frame indefinitely:

function animate() {
  // ease pointer + wobble toward their targets…
  if (shouldContinueAnimating()) {
    frameId = requestAnimationFrame(animate);
  }
}

shouldContinueAnimating() returns false once the pointer and wobble are within a small epsilon of their targets, so the loop sleeps when nothing is moving and the next pointer event restarts it. The bounding rect is cached and only re-measured on scroll or resize, which avoids a layout read on every pointer event.

Accessibility

The SVG is aria-hidden, since it's decorative; the page heading carries the actual "page not found" message. Under prefers-reduced-motion, the rAF loop never starts and the CSS animations are replaced with a static state, so the ring renders without movement.

That's the whole component: generated geometry, layered parallax, eased pointer input, three CSS-driven rendering modes, and a render loop that only runs when it needs to.