DEV Community: Dimon

Kinewright Humans: a step planner for starts and stops

Dimon — Fri, 30 Oct 2026 20:35:20 +0000

The first Kinewright engine now answers a command at the next step instead of at the end of a clip. This article shows what the stage adds, the numbers it stands on, and the limits it keeps on purpose: inside a transition a command still waits for the clip, and the stage says so with its figures.

What this stage adds

A runtime substrate under the page: a fixed tick of 120 Hz, commands as tick-stamped events, a journal of them, seeded random streams and a byte-for-byte replay. The same journal gives the same bytes in two processes, and the same platform-stable digests on two machines of different architectures.
A step planner as the way a command is answered. A request is laid out at the next touchdown of either foot, in the frame of the clip it continues, and the five transitions — the start, the stop from a walk, the stop from a run, walk to run and run to walk — are laid out inside the accepted clips and held to them. Every script of the review set stays inside the accepted clips' height bands, with margins of 10 mm at the pelvis and the hips and 15 mm at the knees and the ankles.
The steady walk at 1.0 m/s and the steady run at 4.5 m/s are the accepted clips byte for byte, and so is the entry into the run: the accepted walk-to-run clip, entered at its own entry foot. Earlier builds of this stage composed that entry from the planner's steps; the composition brought a crouch and a kick nobody accepted, and the stage ended with the clip instead.
Creation and the pose stay cheap on the planner's path: an actor is created in under 0.1 s and posed in about 0.3 ms per frame on an Apple M1-class machine, by the cost probe, and in under 0.2 s and about 0.8 ms on the second machine; the bars are 1 s and 6.75 or 10.91 ms.

How it answers

From walking, a stop begins to brake in 0.417 s and stands in 1.658 s. From running, it stands in 4.458 s with no walking step between the request and the hold. Visible motion after a released stop begins in 0.399 s.
A tap of the walk key — released and pressed again three ticks later — gives exactly one step and the closing foot.
A run requested in the steady walk enters the accepted clip at its entry foot, the left; a request that meets a right touchdown walks one more step, at most 0.95 s.

What it keeps waiting for, on purpose

Inside a transition the clip's structure decides when a command is answered. Every case is recorded with its number and its price for the speed stage, where transitions become laws of speed instead of clips.

What you see or might expect	What happens	Number	Changes at
A stop pressed right after the start lifts a foot	held to the start's settled touchdown	up to 3 touchdowns, 1.51 s	the speed stage
A run pressed again while the run is already ending	held to the hand-over into the walk	up to 8–9 touchdowns, 4.2 s	the speed stage
A run pressed in the first two steps of the start	laid out at the start's third touchdown	up to 2 touchdowns, 1.65 s	the speed stage
A stop inside the end of the run, from its last braking touchdown	held to the walk's stop	up to 3 touchdowns	the speed stage
A stop or a released shift inside the walk-to-run clip, from its first step	held to the clip's hand-over, as the accepted actor holds it	up to 5 or 7 touchdowns; 2.18 s and 1.52 s in the review set	the speed stage
The feet on the run's exit arrive rising	three braking feet come down still moving up	+0.47, +1.08, +0.35 m/s	the speed stage
The transitions themselves take their time	they are accepted clips played whole	3.1 s walk to run, 4.8 s run to walk, 2.5 s start	the speed stage
A jump	not in this build; hidden	—	a later stage

What comes next is the speed stage: speed as the single input, the walk's and the run's parameters as curves from admitted data, and the stance half of the gait judged against that data. The held windows above and the clips' own lengths are its first input.

Kinewright Wheels: stop, go around, admit the stall

Dimon — Thu, 29 Oct 2026 11:40:15 +0000

The second Kinewright engine now stops before what it sees and goes around what it can pass, knowing the scene only through the sensor models of the previous stage. It also gets stuck, says so, and this article shows that too: the normal drive, the stall when the goal is out of reach, and why.

What this stage adds

The steering moves as a declared motion. Two declarations stand beside the shell's profile, a hobby servo's and a car's steering rack's, every rate estimated from its class and attributed to no part. The steer angle rises and falls on an S-ramp under its own rate, with a cap that falls with speed: from rest, lock to straight takes 0.1 s under the servo and 1.46 s under the rack. Every plan takes the same law; the drawn paths of the earlier stages still end on their poses, slower under the rack.
A local map from the shell's own sensors: cells of 0.02 m, remembered for 2 s within 3 m. The scan, the 8 × 8 grid, the ultrasonic beam and the bumpers mark it; the single-zone cone and the radar do not, because their returns carry no direction fine enough, and an arc placed conservatively would close every opening of the scene. Every return lands where its surface could be nearest, so the map errs toward the shell, never away from it.
Candidates predicted by the shell's own runtime over 1.5 s: three speeds, nine curvatures each plus the goal's own, and rest. A candidate is admissible when the shell, holding it for its reaction time and then asking for rest, meets no cell before it stops. A decision every 0.1 s holds for 0.2 s and carries one reason: clear, slow, around, stop, goal reached, or map unknown.
Two skills. Stop-before drives toward its goal or straight ahead and rests before what it sees; it never steers around anything. Go-around reaches its goal round what it can pass, rests before what it cannot, and reports stalled when its distance to the goal has not fallen by 0.05 m over 30 decisions.
A manual guard, off by default: on the keys only, it brakes where the same test fails and never steers.
Every decision and observation is a recorded input; a drive replays byte for byte two ways in separate processes, with the same records on two machines of different architectures.

How it decides

A return's tolerance is three standard deviations of its sensor's noise at that range, half its rounding step and half a cell's diagonal; a corridor keeps 0.05 m beside the body's outline beyond it. An opening is passable when it is wider than the body plus twice the clearance and the scan's tolerance at 2 m: 0.46 m. The fixtures' 0.60 m gap is passable and their 0.30 m gap is not.
The stop zone at cruise, 0.5 m/s, is 0.31 m before the tolerance of the cell that meets it: the reaction time of 0.44 s, the runtime's own braking distance and the clearance. The slow zone adds one second of travel. The horizon sees every candidate's whole stop zone.
Among the admissible candidates the engine takes the one that ends nearest the goal, rewarding margin up to 0.30 m; ties go to the curvature nearest the goal's, then to the greater speed.

Numbers from this stage

On the fixture scenes, 48 runs under both declarations and on both shells: no run overlaps an obstacle on any tick; the least true clearance is 0.11 m against a bar of 0.02 m; stop-before rests 0.14 to 0.21 m before its obstacle.
Go-around reaches its goal past a post, past the low box that only the beam hears, through the wide gap and round the angled wall; both skills report blocked at the wall and at the narrow gap.
In the drive shown through the opening: cruise from 0.6 s, the first "around" at 4.9 s, the goal reached at 9.2 s after 89 decisions, with 1 428 cells on the map at the goal.
The stall, under the rack: with the goal behind the second inner wall, go-around passes the first opening, meets the wall at 9.5 s, edges along it into the corner, stops at 13.7 s and reports stalled at 14.7 s, 1.3 m from its goal, after 144 decisions. It does not leave its trap by driving away from its goal, because nothing in this stage knows the whole room. Under the servo the same goal ends at 12.6 s as blocked, 0.22 m before the wall.

What it does not claim, and why

What you see or might expect	Why	Changes at
The shell stalls with the goal behind a wall	A reactive skill chooses among paths it can see over 1.5 s; it holds no map of the whole drive and plans no route, so a local minimum traps it, and it says so	The route stage: a map of the whole drive, a route with replanning, exploration of the unknown, an honest unreachable
It forgets what it passed	The map keeps a cell for 2 s after its last return, within 3 m	The route stage
The cone and the radar see the box but the map ignores them	Their returns carry no direction fine enough; a conservative arc would close the openings	The hardware stage, against measured sensors
The beam marks a wider arc than the face	Its echo is specular; the map marks the 15° across which the face may lie	The hardware stage
The shell knows exactly where it is	The pose is the engine's own frame, not an estimate	The hardware stage: localisation
A stop here is safe	The zones and the guard are engineering rules of the simulation; no stop is called safe and no decision is what a real vehicle would do	Never claimed
Nothing moves in the room	Only static obstacles; the radar's target speeds wait for the moving-objects stage	After the route stage
The steering rates are real	Estimated from the two classes; nothing is measured	A measured sensor and a real vehicle, much later

Two assumptions sit under everything here, as before: the honesty bound of the kinematic model and the tip threshold, both announced when crossed and never simulated. This stage adds no third one, and obstacles never move the shell: the motion stays kinematic.

Kinewright Wheels: one rover, eight senses

Dimon — Mon, 26 Oct 2026 17:21:26 +0000

The second Kinewright engine now carries the senses of a small rover through a room of static obstacles. It sees; it does not yet avoid, and that is the next stage. This article shows what the fourth accepted stage adds, how a sense is modelled, and every limitation still in place.

What this stage adds

A scene: four walls, a tall post, a thin post, a low box, a tall box and a wall turned 30°, all static, every size declared in metres. No obstacle stops a shell: the motion stays kinematic, a shell driven into a box passes through it, and a contact report names the overlap on every tick it lasts.
A rig on the four-wheel-steer shell, beside its profile: a single-zone time-of-flight cone and an 8 × 8 grid, an ultrasonic beam, a 360° scanning range-finder, a radar of up to three targets with their radial speed, two bumpers, wheel encoders and an inertial unit. Eight models of seven sensors.
Every sensor has a rate, a latency, blind cases and seeded noise, and reports integers in its own units: millimetres, counts, bits.
Every observation is a recorded input of the drive's journal. A drive replays headless two ways, through the controller and from the frames, byte for byte in separate processes, with the same records on Windows and macOS.
One observing behaviour, a stub: hold 0.30 m/s while the beam reads clear, rest from the tick a reading of 0.50 m or less arrives, and rest before the first reading, because an unseen way is not a clear way. On the committed drive it stops 0.469 m short of the low box.
Every trail is drawn from the pivot axle, the point that never slips sideways, so the hook at a turn's exit is gone. The steering motion's own shape is the next stage's first item.

How a sense is modelled

Rays in closed form against faces, tops and the ground, the nearest crossing within range; a sample is taken on the frame of its tick and emitted its latency later, and the scanner casts each beam from its own tick's pose.
The status comes from the true value, so noise never invents a return and never loses one. Noise is a counter-based stream, a pure function of the seed, the sensor and the sample's index, exact on every JavaScript engine, with no clock anywhere.
Every figure is estimated from the public datasheets of the sensor's class, attributed to no single part. Nothing is measured.

Numbers from this stage

Rates: cone 30 Hz, grid 15 Hz, beam 15 Hz, scanner 6 Hz, radar 10 Hz, bumpers and inertial unit 120 Hz, encoders 60 Hz.
Noise, one standard deviation: cone 2 mm plus 0.4 % of range; grid 3 mm plus 0.5 %; beam 2 mm plus 0.2 %; scanner 1 %; radar 0.03 m, 1.5° and 0.03 m/s; encoders one count, 0.2 mm of rolling.
The beam loses its echo past 7.5° to a wall; the cones are pitched up by their own half-angle, so neither reads the ground.
In the drive shown: the beam hears the low box from two metres while the cone above it reads the far wall at 3.6 m; the radar tracks three targets at once, each closing at the shell's own speed.
In the turn, at 0.43 m/s and full lock, the inertial unit reads a yaw rate of 92°/s: the engine's own 1.6 rad/s on a 0.27 m radius. The outer wheels' counts pull ahead of the inner ones.
25 fixtures and three drives are pinned by platform-stable roots; traced figures sit within 1.9·10⁻¹⁴ of their closed forms.

What it does not claim, and why

What you see or might expect	Why	Changes at
The shell drives through the box	No collision response: kinematics only; the report names the overlap	The avoidance stage, built on these senses
A real sensor would read this	Models of declared figures from datasheet classes; no optics, acoustics or electromagnetics	A measured sensor, on hardware, much later
Dark or soft surfaces, a corner's ghost echo, a thin object between two rays	No surface property, no multipath; the cones are sampled by bundles, not integrated over their field	The hardware stage; multipath is not scheduled
The other shell shows up on the scan	A shell is not an obstacle to another shell's sensors	The moving-objects stage
A sensor fails, drops out or drifts	No faults, no drift, no temperature	The faults stage; calibration later
The encoders count exactly the distance	Pure rolling, no slip: traction needs a dynamics provider	Not a Wheels stage
The steering snaps from full lock to straight	The steering rate is one declared clamp with no bound on its change	The next stage, as a declared bound with its own question

Two assumptions sit under everything here, as before: the honesty bound of the kinematic model and the tip threshold, both announced when crossed and never simulated. This stage adds no third one; the senses sit above the kinematics, not under it.

Kinewright Wheels: the map

Dimon — Wed, 21 Oct 2026 12:20:34 +0000

Kinewright is a house of motion engines, and Wheels is its second engine: how a body with exactly four wheels moves. This article is the plan for Wheels as it stood in October 2026, written down once and left as it is: what the engine does itself, what it deliberately takes from outside, which published criteria and data it leans on and how they are allowed in, and what comes next, in which order and why.

I will not update this article. The living version is the pinned post on r/Kinewright; it changes when a stage closes or the order moves. There are no dates here, on purpose.

One sentence, one level

Wheels turns a vehicle profile, a drive intent, a seed and time into a canonical vehicle pose, articulation and support state. It produces motion state, not pixels.

Its level is physics-informed, through exactly two named assumptions and nothing else: the bound past which a kinematic model stops being honest, and the threshold at which a rigid body would tip. Both are computed every frame and announced when crossed; nothing past them is simulated. Every stage below stays kinematic. The sensing and avoidance stages add models and decisions above the kinematics, not physics underneath it. The ladder is the one the human engine uses:

Level	Meaning
Kinematic	poses and supports meet declared geometric and timing checks; this establishes no forces and no physical validity
Physics-informed	kinematic motion bounded by named physical identities, without simulation
Static balance checked	a four-wheel body is statically stable by construction; only the tip threshold applies here
Dynamically checked	momentum and contact forces pass declared checks; this needs a dynamics provider
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 drive that passed a kinematic or visual gate is never described as physically validated, and nothing that passes in the engine's own simulation carries over to hardware.

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

Built and accepted today:

The shell. Exactly four wheels in a 2×2 layout; wheelbase, two tracks and each wheel's radius and width as declared profile numbers; four steering layouts: front, rear, both axles, skid. Two- and three-wheel bodies are outside the scope entirely.
The negotiation. Every manoeuvre-and-shell pairing resolves to native, adapted, fallback or unsupported, with a reason, and the answer is predicted before the code that runs it. Clamping a command without reporting it is a defect, not a degraded success.
The drive. One intent type, from a keyboard, a scripted scene or a behaviour layer; a controller that maps it onto each profile's declared limits by a written policy; nine manoeuvres that can be invoked, interrupted, resumed and dropped.
Determinism. Closed-form arc integration, a fixed tick, a versioned journal, and replay verified byte for byte in a separate process: bytes within one JavaScript engine, twelve significant digits across engines.
The honesty bounds. The two assumptions above, reported every frame.
Mount points. A rigid transform per declared mount, so a trailer, a sensor or, much later, a seated actor can attach without rewriting the schema.

Meant to own, in the order of the table below: deterministic models of a small rover's sensors; a short local map and the avoidance decision above the same kinematics; a caution policy around moving objects; behaviour under faults and one intent contract between a scene, a test bench and a real car; a trailer.

What it will consume, by design

Tyres, suspension, traction, powertrain and brakes as physics. Never written here. A dynamics provider may own them later under an explicit contract, one named slice at a time. Until then a manoeuvre that depends on traction binds unsupported and says so.
Rendering. The engine does not draw. The videos use a plain Canvas 2D reference renderer; a Three.js lane comes later and shares nothing with the motion model.
Sensors. Models built from public datasheets of a small rover class, with their angles, rates, ranges, latency, blind cases and noise written down. No device is chosen; a real one is a separate decision.
Path planning and autonomy. Not here. Avoidance is a reactive skill with a time-to-live over a short local map: not a planner, not a perception stack.
Hardware. The engine never claims to drive a robot from a browser. The bridge is one intent contract with an expiry; calibration against a measured car is its own stage, after a car exists.
The human engine. The same world frame and the same house package for the three primitives both engines share. A seat, a steering wheel and pedals as actor contacts are a reserved seam, not a stage.

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

At the start, nothing is measured. Every profile number is an engineering choice or an estimate and carries that tag. "Measured" is reserved for what a source reports; a value read off a run, a turning radius, an off-tracking, a swept width, is traced, never measured. The small platform is a generic hobby-grade front-steer body, estimated because none was bought; the paper sedan is an engineering profile. No third-party data pack enters the engine, and what is admitted enters as aggregates, never as raw rows, files or clips.

Published criteria, used as bounds and not as data

Criterion	What it does here	Source
Kinematic honesty bound, `∣a_y∣ ≤ 0.5·μ·g`	the line past which a single-track kinematic model stops being honest; announced when crossed; the controller holds the shell under 0.9 of it	Polack, Altché, d'Andréa-Novel and de La Fortelle, 2017; fitted on one nine-degree-of-freedom model of one class of car, not validated for small platforms
Tip threshold, `a_y/g ≤ t/(2h)`	a rigid-body figure for a narrow track and a high centre of mass; reported as a geometric bound, never as a safety limit	the static stability factor; real vehicles roll over about 15 % earlier because they lean

Admitted for the moving-objects stage, aggregates only

Source	What it provides	Licence
THÖR-MAGNI v2.0	pedestrian speeds, distances and approaches around a moving platform	CC BY 4.0
Jülich Pedestrian Dynamics Data Archive	the fundamental diagram of pedestrian flow, read against Weidmann's; any constant comes from the values the group itself published	CC BY 4.0, with attribution

People are moving objects in this engine, never recognised persons.

Planned

Sensor datasheets of a small rover class, for the obstacle stage. A measured car, when one exists, for the calibration stage: its turning radius and its stopping distance on two or three surfaces. Then, and only then, a profile number may be called measured.

The plan as it stood: stages and dependencies

A stage gets a size only after its definition of ready is frozen, and every stage of this engine so far came in well under its planning band. Sizes here are the kind of work and a rough band, not a calendar.

#	Stage	What it delivers	Kind of work	Band
✓	Kinematic baseline	a shell of exactly the declared dimensions drives; changing the wheelbase changes the turning radius by exactly `R = L / tan δ`	profile schema, arc integration, journal, replay	closed
✓	Capability contract	four shells and a locked one, nine manoeuvres, every pairing bound as predicted before the code	shells, skills, the binder, a frozen lattice	closed
✓	Driveable shell	a person drives two shells with keys; manoeuvres interrupt and resume; steering turns while rolling; the records replay on three machines	controller and policy, session, drive journal, browser scene	closed
1	Obstacle scene and sensor models	static obstacles and deterministic models of a small rover's sensors: a zoned time-of-flight cone, a single time-of-flight or ultrasonic beam, a 360° scanning range-finder, a radar of targets with their speed, a bumper contact, wheel encoders and an inertial unit, each with documented angles, rates, ranges, latency, blind cases and noise, so everything above them runs headless and replays	scene, sensor models from datasheets	medium
2	Reactive avoidance	observations become a short local map, a polar histogram or a small occupancy grid; candidates of speed and curvature are carried by the engine's own arc integration over a horizon and checked as swept corridors against the obstacles, with stop and slow-down zones and the time to collision, so what the vehicle decided and what it did share one kinematics and one replay	skills above the existing engine	medium
3	Moving objects and a caution policy	objects' speed estimated from scans without a camera, a moving-or-static class, and a policy with its numbers: a lower speed, wider safety fields, yield or wait, never cut across a moving object's course	estimation, policy, fixture scenes	medium
4	Faults and the one contract to a car	injected faults, a stale sensor, a lost heartbeat, a brown-out, a disconnected computer, a stop and its re-arm, under each of which the vehicle goes neutral; one intent contract with an expiry between a scene, a test bench and a car	fault injection, the contract	small to medium, the software half only
5	Articulation	a trailer as a full four-wheel body on two axles, on-axle and off-axle hitches, the articulation angle as state, off-tracking, reversing, and jackknife as a graded state with a margin and a reason	kinematics again, one body more	medium

The order is deliberate: the stated purpose of this engine is a small rover, and a rover needs sensing, avoidance, caution and fault behaviour before it needs a trailer. No stage depends on hardware existing. No hardware has been chosen, and the calibration half of stage 4 waits for a car. A first playable scene after stage 1 is a separate decision, not a row.

Corrections between stages are not rows of this table. The steering ramp of the accepted shell, full lock to straight in 75 ms with no bound on how fast that rate changes, is already an input to the next stage's definition; it will be fixed there, and the pinned post will say so.

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 is not the map of the human engine, which has its own article. And it is not the current plan: it is the plan at the start. Feedback is research input we read our results against; a change of order is a decision recorded with its reason; both show up in the pinned post, which is the only version of this map that moves.

How to help

Watch the clips and answer one question: does it drive like a car of exactly these dimensions? Then say what you saw. That is how every stage of this engine is accepted, and it is how this plan will change.

Kinewright Wheels: the second engine

Dimon — Wed, 21 Oct 2026 11:55:12 +0000

Kinewright has a second engine: Wheels, how a body with exactly four wheels moves. Three stages are accepted, and this article shows what each one proved and every limitation still in place.

What Wheels is

Kinematics only: no tyres, no suspension, no physics. Every number here is traced from the engine's own run; nothing is measured.
A shell with four wheels that pulls away, holds and changes speed, turns, brakes, stops, parks and manoeuvres in a bounded space.
Driven the same way from a keyboard, a scripted scene or a behaviour layer: one intent type, one policy.
Every drive is a journal. It replays byte for byte in a separate process, and the same records come out on Linux, Windows and macOS.
Same house and same world frame as the human engine; a different engine with a different subject.
Not a path planner, not an autonomy stack, not a vehicle simulator, not a controller for real hardware.

Three accepted stages

Kinematic baseline (4 September). A shell of exactly the declared dimensions drives in the browser. Changing the wheelbase changes the turning radius by exactly R = L / tan δ, traced within 3·10⁻¹⁴ of the stated value.
Capability contract (13 October). Four shells of one small body, front steer, rear steer, four-wheel steer and skid, plus one with the steering locked, run nine manoeuvres from the same start. All 46 shell-and-manoeuvre pairs bind exactly as predicted before the code existed: 32 native, 7 adapted, 2 fallback, 5 unsupported. Turn-in-place is native on the skid shell, becomes a three-point turn on the steered shells, and is refused with the steering locked.
Driveable shell (20 October). A person drives the four-wheel-steer and the front-steer shell with W, S, A, D and Space. The keys are mapped onto each profile's declared limits by a written policy. The nine manoeuvres can be invoked, interrupted, resumed and dropped. Steering now turns while rolling; follow-path ends on the drawn pose, parallel-park parks in one reverse run.

Numbers from this stage

Small platform: wheelbase 0.257 m. A generic hobby-grade profile; no real platform is named because none was measured.
Steering authority keeps lateral acceleration under 0.9 of the kinematic honesty bound: 4.41 m/s² against 4.90.
The speed cap binds at full lock from 1.51 m/s on front and rear steer and from 1.08 m/s on four-wheel steer.
Parallel park: 0.687300 m back in one reverse run on front steer; the four-wheel-steer shell crabs 0.25 m sideways instead.
The committed drive: 1,314 ticks at 120 Hz, about 11 seconds; its 17 key presses are listed in the records.
51 manoeuvre-and-shell pairs at this stage: 35 native, 9 adapted, 2 fallback, 5 unsupported, all predicted before the code.
Rolling manoeuvres end within 10⁻⁹ of their closed forms; the worst segment is 1.1·10⁻¹⁴ off.

What it does not claim, and why

What you see or might expect	Why	Changes at
The shells drive through each other	No collisions and no obstacles exist yet	The obstacle stage, next on the map
A manoeuvre's first steer from rest happens standing still, and so does the change of lock when it reverses	A bounded limitation kept on purpose: steering now rolls inside manoeuvres, not at their start	A later stage, not scheduled
The steering goes from full lock to straight in 75 ms, a hard ramp	The steering rate is one declared number, an estimate for a hobby servo, with no bound on how fast that rate changes; the trails here follow the rear axle, which never slips sideways, so they show no hook	A later stage: the shape of the transition as a declared bound
The skid shell stops to change its curvature	Its rolling transition would ramp side speeds under different limits; kept as it was	A later stage, not scheduled
A resumed manoeuvre restarts from where the shell stands	It does not return to its original goal: that is path planning, which this engine does not do	Not planned in this engine
Fast turns look "too easy"	Kinematics: no tyre grip, no body roll. The engine announces every frame that crosses the honesty bound instead of simulating it	A dynamics provider, not a Wheels stage
Every shell here is the same small body	One profile family in these scenes; the paper sedan from the first stage is not here	A real platform, once one is measured
Speed can overshoot a falling cap by up to 0.3 m/s	The jerk limit lets it; the policy is aimed, not guaranteed, and the frame reports it	Kept as a declared limit
The browser and the records differ in the last digit	JavaScript engines differ in the last digit of sin and cos at 13 of 233 probe points; 3 of 1,314 ticks differ	Kept by contract: bytes within one engine, twelve digits across engines

Two assumptions sit under everything here. The first is the kinematic honesty bound: a kinematic model is honest only while the sideways acceleration in a turn stays under half of what the tyres could hold, 4.9 m/s² at a friction coefficient of 1. The engine announces every frame that crosses that line instead of simulating what happens past it; the line comes from passenger-car studies and has not been checked on small platforms. The second is the tip threshold: a rigid body tips when sideways acceleration exceeds half its track over the height of its centre of mass; real vehicles lean and tip about 15 % earlier. Both are lines where the engine's claims stop, not safety limits.

Kinewright Humans: the first person model

Dimon — Sat, 10 Oct 2026 21:06:05 +0000

Two stages closed since the plan: the pelvis and chest move in the walk (25 September), and height and trunk mobility became inputs of a person model (10 October). This article shows what changed and every defect still visible in the clips.

Kinematics only. No physics. Every number is sampled from the engine's own motion, not measured on people. The picture is a small reference renderer. Each stage was accepted by two reviewers choosing between lettered clips, with the letter-to-setting map sealed until both had answered.

What changed

The walk's trunk moves. Pelvis drop 3.33° → 5.00°, chest turn 2.83° → 6.00°.
The run stopped wobbling. The pelvis's sideways travel 73 mm → 15 mm.
One body became a person model. Height 1.50–1.80 m and trunk mobility 0–1 are inputs; the engine derives the rest. The default person is 1.72 m.

Pelvis and chest

The new default: pelvis drop 5.00°, chest turn 6.00°, shoulder line 17° ahead of the hip line. Two neighbours ship as presets (6°/8°, 6°/11°); the September set stays as the control.
The stop keeps its two bars: shoulder-line roll ≤ 0.62° and head sideways ≤ 12 mm on the last step. The default closes at 0.043° and 1.41 mm. Every new walk rolls the shoulders less at the stop than the old one, because the counter-roll shares were set for it.
The run was left unchanged at this stage: a pelvis-rotation ladder moved the picture by under 3.3 px, and a sway ladder failed the contact gate (the foot inherited 5.3 mm of pelvis motion against a tolerance of 1e-9 m).

The person model

Inputs: height, trunk mobility, and speed as the independent variable.
A law may move only what a preset may move: feet within 1e-9 m of the accepted motion, cadence untouched. So all three heights step at the same rate and length; only the body above the feet is scaled. A real shorter person would take shorter, quicker steps.
When nothing is specified, the engine plays the default person through the laws. The last review compared that against the accepted motion passed in directly: byte-identical videos, no difference seen.
Two speeds are played: 1.0 m/s walk, 4.5 m/s run. The trunk's speed laws were checked on 1.00–1.60 and 2.50–4.50 m/s by instrument but are not played yet.
Why 1.50–1.80 m and not more: the range was planned to 1.95 m. Above 1.80 m the engine's own continuity limits bind: the head's vertical step through the walk-to-run transition passes 5 mm from 1.81 m (at 1.80 m it is 4.974 mm), the hip and knee jerk at the braking boundary pass their limits from 1.90 m, and the run-to-stand exit cannot be compiled from about 1.94 m. Recorded as not reached; no limit was moved to admit a taller person. 1.50 m is the planned floor, and it is already the tightest corner: with the most mobile trunk, 1 % of headroom is left. All three binding places are transitions and braking, not steady gaits. The next stage, the runtime step planner, lays those transitions out anew; the height corners and the clamps are re-run after it, and the range widens to whatever then holds.
Every law has a clamp. Its limits were found at the tightest corner (shortest height, most mobile trunk), and the runtime reports what it clamped.

The run

Four sideways-travel settings were shown; the first attempt at the side camera did not show the sway and was recorded as a defect. At the corrected look both reviewers chose the same letter: 0.2 of the old travel, 14.6 mm instead of 73.2 mm.
What moved: the root and everything above the hips, sideways, by at most 29.3 mm; hips, knees and ankles by at most 0.036 rad. Feet and contacts did not move.
Hip rotation 9.74° and shoulder turn 4.05° are unchanged.

What looks wrong, and why

1. All heights step at the same rate and the same length.
Why: in this stage the engine was not allowed to move the feet. Where each foot lands, and when, is the same for every height; only the body above the feet is scaled. A real shorter person would take shorter, quicker steps.
When it changes: the stage after the planner, where step length and cadence start to depend on the person, not only on speed. Starts and stops get re-reviewed then, because the feet move.

2. The short and the tall person look like the same body scaled.
Why: the body is built from 17 proportions set by hand, not from measured body dimensions.
When it changes: once a licensed dataset of adult body dimensions is admitted, the proportions become a profile that can be swapped.

3. Heights stop at 1.80 m.
Why: above 1.80 m the engine's smoothness limits are crossed in the transitions. The head jumps more than 5 mm when the walk becomes a run; the legs jerk too hard when braking; above about 1.94 m the run cannot settle into a stand at all. We do not loosen a limit to fit a taller person.
When it changes: the planner rebuilds those transitions; after that the limits are re-checked at the corners and the range widens to whatever holds.

4. Only two speeds: walking at 1.0 m/s, running at 4.5 m/s.
Why: the trunk's speed laws were verified on 1.00–1.60 and 2.50–4.50 m/s by instrument, but the product has no way yet to ask for another speed.
When it changes: the playable controller, which changes speed continuously.

5. The stop ends on a hard last foot.
Why: a known leftover from the stand-start-stop stage. The last braking step lands harder than a person would.
When it changes: the runtime step planner, the next stage; it owns starts, stops and interrupted commands.

6. The run's chest is stiff against the hips.
Why: this stage changed only how far the running pelvis travels sideways. A set of larger pelvis rotations for the run was built, but on the reviewers' camera it moved the picture by less than three pixels, so it was never shown.
When it changes: a run trunk ladder at a scale the camera can show. Not scheduled yet.

7. Every step is identical.
Why: the engine is deterministic. The same inputs always produce the same motion. Real people vary from step to step by a few percent.
When it changes: planned as its own item right after the cadence-and-step stage, before the playable controller — seeded and bounded, so a replay with the same seed is still the same motion.

8. The arms do not depend on the person.
Why: arm swing is a fixed rule per gait, about 35° walking and 57° running.
When it changes: the skill platform stage, where the arms get rules of their own.

9. Block feet, block hands, no face.
Why: the mannequin is a reference renderer. Feet and hands are boxes and the head is a sphere because the engine has no foot or hand articulation yet.
When it changes: feet and hands come in the stage that closes the locomotion foundation. A face is not on the map.

10. No transitions in these clips.
Why: walk-to-run and run-to-walk exist and were accepted in the first stage. This time the reviews compared steady gaits, so the clips show those.
Not a defect.

11. In the side-camera run the whole body drifts sideways.
Why: that drift is the sway itself. The usual camera follows the pelvis and hides it; the side camera does not.
Changed: 73 mm before, 15 mm now.

12. Extreme persons are clamped.
Why: at the shortest height with the most mobile trunk the engine holds some channels at its smoothness limits, and says so in its report. None of the clips shown here is clamped.
When it changes: the limits move only when the transitions are rebuilt, never to fit a result.

Feedback that lands: does it respond the way you expect, does it look natural, and what exactly you saw. "Can't tell" is a valid answer.

Data behind the laws: Fukuchi et al., walking and running datasets v5 (CC BY 4.0); Riglet et al., 2024 (CC0); NIOSH firefighter body dimensions for the reference body (public domain). They inform the motion; they do not validate the engine.

Holding ETH through the 2022 crash lost 52%. This free bot ended at +0.9%

Dimon — Mon, 05 Oct 2026 12:32:07 +0000

Two days ago I published a write-up about a small ETH/USDC bot that asks a typed-question judge every minute and switches the whole position when five judgments in a row agree on the trend. On paper, over a few quiet nights, it lost a little to just holding ETH. Two readers said the same thing from two sides: a switch should depend on new information (the price), not on the same opinion repeated, and a hedge should be judged on the crash it sits out, not on a quiet week.

So I built a replay: the same engine, votes, filters, limits and judge, run over historical Coinbase candles under a simulated clock, with a cost scenario for every fill and the date hidden from the model. Then I put four versions of the bot and "just hold" through five windows: seven months of 2022, six months of the 2023–24 rise, and three single months with a crash, a collapse and a rally. Everyone starts with $10,000. The repo is public (trend-switcher, MIT); every number below is a row in SESSIONS.md.

The four bots

All four share the base from the first post: a judgment every five minutes, a switch of the whole position when 5 of the last 6 judgments agree on the trend, a 3 % daily and a 30 % total loss limit that freeze the bot until someone resets it. They differ in one rule each:

Bot 1 — votes only. The rule of the first post: five agreeing judgments are enough.
Bot 2 — votes + a price breakout. A switch also needs the price 0.9 % beyond the high or low of the last two hours of closed candles.
Bot 3 — votes + breakout, and a loss limit never blocks a sale. A latched loss blocks only buying back; selling into USDC stays allowed.
Bot 4 — bot 3's exit, and a different way back. It buys ETH again as soon as the price is 0.9 % above the level it sold at. No votes needed for that; the judge decides when to leave, the price decides when to come back.

The results

Window	Holding ETH	Bot 1	Bot 2	Bot 3	Bot 4
May–Nov 2022: Luna, the June low, FTX	−52.5 %	−49.5 %	−10.8 %	−16.5 %	+0.9 %
Oct 2023–Mar 2024: a rise with two pullbacks	+118.2 %	−4.9 %	+79.8 %	+28.2 %	+104.0 %
May 2021: a choppy top, then the crash	−2.5 %	+50.0 %	+7.0 %	+14.9 %	−13.7 %
November 2022: FTX	−17.7 %	−17.9 %	−17.7 %	−6.6 %	−6.6 %
February 2024: a straight rally	+46.7 %	+19.5 %	+46.7 %	+46.7 %	+46.7 %

Net of all costs, including the judge calls and the fills. Four windows out of five are a story each.

The fall. Over seven months of 2022 holding ETH lost half, with a worst drop of 70 %. Bot 4 sold once, on 5 May at 2,753, and the price never came back 0.9 % above that level, so it sat in USDC through Luna, the June low and FTX and ended the year flat: +0.9 %, worst drop 7 %. Bot 3 made the same exit but came back on breakouts, 25 switches through the summer rallies, and gave most of its lead back. Bot 1 switched 130 times and lost almost as much as holding.

The rise. This is the window that killed my earlier favourite. From October 2023 to April 2024 ETH went from 1,670 to 3,645. Bot 3 sold in November, and its way back needs a 0.9 % burst above the two-hour high at the very moment five judgments agree, which a slow, steady rise almost never prints. It sat in USDC for three and a half months and made +28 %. Bot 4 made the same sale and was back in the next day, 0.9 % above the level; six such round trips cost it 14 points of the 118 the market gave. Bot 1 switched 610 times and ended below where it started while ETH doubled.

The chop. May 2021 is the month bot 4 loses. A choppy top where every 0.9 % dip was a sale and every retest a buy-back 0.9 % higher: six round trips and −13.7 % against −2.5 % for holding. Bot 3, which needs a breakout to come back, made +14.9 % there. And bot 1 made +50 %, because its constant switching happened to land in USDC at the crash of 19 May; it is the same rule that gave back more than half of February 2024 and all of the 2023–24 rise.

The collapse. In the FTX month bots 3 and 4 sold at the same instant, 8 November at 1,468, and stayed out: −6.6 % against −17.7 %. Bots 1 and 2 ended where holding ended; bot 2's loss limit had latched before the votes lined up and blocked the one sale that mattered.

The rally. In February 2024 nobody with a breakout condition switched at all, so the insurance cost nothing. Bot 1 switched 95 times and gave back more than half of the gain.

What the default is now

Bot 4. It beat holding in three windows, matched it in one and lost in one, and its worst window against holding is 14 points behind, where bot 3's is 90. That is the shape I wanted from the start: when the market falls, the stops save you; when it rises, you are not sitting outside. Bot 3 stays one line in .env away (STRATEGY=hedge), and so do the other two.

Every number above is one run of a stochastic judge per bot. The first eleven weeks of the 2022 window were run twice during the week, with a different judge draw, and the order of the bots held while the numbers moved. Treat the table as a ranking with an error bar, not as a return.

What a replay cannot say

The judge may have seen 2021 and 2022 in its training; the date is hidden from it, the price level is not. The fills are a scenario, the pool fee plus the price impact I measured on the real pool at $10,000, not historical quotes; the pool did not exist in 2022. And it is one pair on one pool. The repo now also supports the same rules on Ethereum, Arbitrum, Optimism and Polygon with ETH, ARB, OP and POL against USDC, with every address checked on-chain, but none of those has run; several of those pools are too shallow for a $10,000 switch, and the README says which.

Size matters through the pool, not the strategy: a round trip on the Base pool costs 0.10 % at $1k, 0.13 % at $10k, 0.36 % at $100k and 2.8 % at $1M in real quotes. Seven months of judging cost about three dollars per bot.

Who this is for, and who it is not for

For someone holding ten to a hundred thousand dollars of ETH who wants a cheap insurance against a crash, accepts a whipsaw tax in choppy weeks and a late exit in a fast one, and will not read "+0.9 % in 2022" as a promise. Not for small balances, not for a million on this pool, not for anyone who wants income in a sideways market, and not for live money: the live mode exists, is deliberately hard to arm, and I have not used it.

What is in the repo

SESSIONS.md rows 9–14 (the replays), the four strategies (STRATEGY, README: Strategies), the re-entry rule and its margin, the markets, the replay tool, a recorded-judge replay that lets you screen a rule change over a finished window without paying the judge again, a pool-impact probe, and 204 tests. If you replay a month I did not, I would like to see the row.

A cheap trend-following ETH/USDC bot with two models in the loop: what paper trading showed

Dimon — Fri, 02 Oct 2026 08:47:23 +0000

I built a small trading bot and ran it on paper for a few days. It did not make money, and I do not think it can in its current form. I am publishing it anyway, with the code, the sessions and the arithmetic, because most "trading bot" posts share neither.

Repository: github.com/dimonb19a/trend-switcher (MIT). The session summaries are in SESSIONS.md there.

What it is

The bot holds one position, all of it either in ETH or in USDC, and switches sides when several independent checks agree. It trades ETH/USDC on Base through Uniswap v3. By default it runs on paper: live prices and live on-chain quotes, but a virtual capital and simulated fills.

It is not a signal service, not a backtest and not a stop-loss. Every limit it has stops new actions; none of them exits a held position. If it holds ETH and ETH falls, it keeps the drawdown until the machinery decides to switch.

How a decision is made

Every 60 seconds:

Code computes features: EMA20 against EMA50 on 5-minute candles, recent returns, volatility, and the real cost of switching right now (a DEX quote for the whole position plus gas).
A judge answers four fixed questions. The judge is a model that returns probabilities for fixed-choice questions over an HTTP API, not a chat model writing prose. The questions: the multi-hour regime (trend up, down, range), the direction over the next 15 minutes, the quality of the moment, and the risk-off probability. You bring your own provider; the repository names none.
Votes. A judgment votes for a side or it does not. The default preset trend needs five agreeing judgments out of the last six, within nine minutes. trend-fast needs three of four. forecast votes only on a 15-minute move big enough to beat the switching cost.
Filters and a veto. The candidate must agree with the EMA trend. Then a second model (DeepSeek) reads the same state and may veto, at most once per five minutes.
Hard limits, checked right before any effect: switches per day, minimum hold, daily loss halt, total loss kill, inference budget, data freshness. A halt latches until an operator resets it.

Models only vote or veto. Code decides, and every limit holds whatever a model says.

What it costs

Inference is the only running cost, and it is a fixed number of dollars per month, not a percentage of the capital. At a 60-second tick, both models together cost me a few dollars a month. So the question is simple division:

Capital	Inference as a share of capital (at $5 a month)
$100	5 %
$1,000	0.5 %
$10,000	0.05 %

On $100 the models eat the capital faster than any plausible edge. On $10,000 inference is dust, and the only question left is whether there is an edge at all. That question does not depend on the capital, and the sessions below answer it for what I tried: no.

How it loses

A trend follower earns when it catches moves bigger than its switching bill and pays the bill every time the trend was not there. The bill has two parts.

The round trip itself is small: the pool fee twice, the slippage twice, gas on Base is cents. About 0.15 % of the position.

The real cost is the move between a flip and its reversal. A regime call flips at the edges of a sideways range by construction: near the bottom the judge sees a trend down and the bot sells; the range holds; near the top the judge sees a trend up and the bot buys back. The bot has sold low and bought high by the width of the range it mistook for a trend. In my sessions each such episode cost 0.6–0.9 % against simply holding.

The forecast rule has the opposite problem: a 15-minute call must beat the round trip with room to spare, so the judge would have to be right on direction well over two thirds of the time. It was not, and it knew it. It almost never rated a 15-minute move as likely enough, so under that rule the bot never traded.

The paper sessions

Paper, a virtual capital of $1,000, starting in ETH, a 60-second tick. "Result" is the end of the window after simulated execution costs; "hold" is what keeping ETH would have done over the same window.

#	Window (UTC)	Preset · second model	Slots	Switches	Result	Hold	Ended
1	2026-09-29, 30 min	`forecast` · forecast	30 / 30	0	−0.295 %	same (no switch)	smoke run
2	2026-09-30 00:01 → 04:08	`forecast` · forecast	248 / 720	0	not reported (one judge bill stayed unknown)	—	stopped by the unknown-bill guard, as designed
3	2026-09-30 09:31 → 21:31	`forecast` · forecast	720 / 720	0	−0.08 %	same (no switch)	deadline
4a	2026-09-30 19:00 → 10-01 03:00	`trend` (5 of 6) · forecast	480 / 480	2	−0.64 %	+0.28 %	deadline
4b	same window	`trend-fast` (3 of 4) · forecast	480 / 480	2	−0.58 %	+0.28 %	deadline
5a	2026-10-01 15:33 → 20:33	`trend` · forecast	300 / 300	2	−0.09 %	+0.83 %	deadline
5b	same window	`trend` · no second model	300 / 300	2	−0.07 %	+0.88 %	deadline
5c	same window	`trend` · regime	300 / 300	2	−0.10 %	+0.82 %	deadline
6	2026-10-02 00:11 → 00:41	`trend` · forecast	30 / 30	0	−0.043 %	same (no switch)	smoke of the release

Three things the table says:

Under the forecast rule the bot never traded in sixteen hours of judgments. No judgment qualified as a vote. That is the rule working, not a measurement of the model.
Under the trend rule every arm switched exactly twice and every arm lost to holding. Session 4 is the textbook whipsaw: sold near the night's low, bought back near its high, 0.9 % behind hold. The faster window changed the timing by minutes, not the outcome. Session 5 repeated it in a narrower range.
The second model did not change the outcome. With it, without it, and with a different question, the arms made the same two switches. The lever is the regime call itself flipping at the edges of a range, not the veto.

Session 5 was launched three times; the first two halted at the first switch on a public RPC error, which is recorded in the repository. The arms of sessions 4 and 5 shared the hours but not identical inputs, so they are exploratory comparisons, not controlled trials. And six sessions over four days are a sample of a few market regimes, not a distance.

What the models actually do, from watching them

The judge never sees a chart. It sees a few hundred words of numbers (the price, the two EMAs, the recent returns, the volatility, the cost of switching) and answers four fixed questions with probabilities. After thousands of answers, two habits stand out.

On the 15-minute question it is cautious almost all the time. It rarely rates a move as likely enough to beat the cost, and on a flat day that caution is simply correct: there was no move to call. On the regime question it is decisive, and that is where the whipsaw comes from. A regime opinion asked every minute will flip at the edges of a range, because from inside a range the edge looks exactly like the start of a trend. The second model, asked whether it agrees with a switch, mostly said no to buying back and yes to selling; it delayed switches by a few minutes and changed none of the outcomes.

None of this is a score for either model. It is what a one-minute cadence does to any forecaster, human or not: it asks for a trend opinion far more often than trends change. The fix is in the question and the cadence, not in a better model.

Where the upside is

The honest statement first: the bot has no proven edge, and I am not claiming one. But the part that was expensive to build is not the strategy.

The foundation is the feed, the on-chain quotes, the paper fills at real quotes, a ledger that cannot invent a bill or a slot, the hard limits, the judge integration, the presets and the timed-session harness. None of it cares which strategy sits on top. The strategy is the smallest part of the repository: one policy that turns the judge's answers into a vote, the questions themselves, and a handful of thresholds. Replace that, and everything else keeps working and keeps accounting.

That is where the money could be, in theory. Trend following pays when moves are larger than the switching bill and last longer than the bot's reaction time. At a 60-second cadence on a sideways day there are no such moves. At a horizon of hours or days there may be, and the same machinery can be pointed at that horizon by changing the judge's question and the tick, not by rewriting the bot. With a capital where inference is dust, the strategy is the only variable left, and the paper harness lets anyone test a candidate over a real distance with the same accounting I used, before a single real dollar moves.

Three things I would try first, as hypotheses:

A longer horizon. A 5-minute tick, a direction question over hours, holds of hours. Same round trip, bigger moves to catch, twenty times fewer model calls.
Partial positions, so a wrong flip costs a fraction of the range.
A range filter that sits out when the regime is range instead of trading its edges.

None of these is tested. The knobs are in the repository (VOTE_WINDOW, VOTE_MIN, the thresholds, the second model's question, the limits), so anyone can run the experiment they believe in, on paper, with their own keys.

The repository

MIT, Node 24, one SQLite ledger per run, an offline test suite. Every model call is journaled before it is sent and its bill stays UNKNOWN until the provider confirms it; a timed session records planned, attempted and missed slots, so a sleeping laptop produces missed slots, not invented ones. To run on paper you need your own judge provider (an API origin, a pinned model id, a key) and a DeepSeek key. Live mode is capped by code and has never been armed; the repository does not encourage it.

If you find a configuration that beats holding over a distance, I would like to hear about it, with the ledger.

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.