Products / 05 — Testbed

Cubex³

The falsification surface. A three-axis evaluation framework — risk, reward, relation — resolved to a coordinate over a volumetric adversarial space, across factions whose command hierarchy is itself a term in the score. Built so the decomposition theory has somewhere it can lose.

What this actually is

Not a game with an AI in it. An architecture with a board attached.

The board is substrate. What runs on top is the research programme executing where it can be observed: every candidate move scored on three axes, a command hierarchy whose losses propagate as morale, and an outcome that is either a win or a loss.

A paper can assert that risk, reward and relation are a sound decomposition of decision-making. A testbed can lose. That asymmetry is the reason this exists — it is the falsification surface for F.R.A.C.C.

Nothing here has shipped. It is a research instrument that happens to take the form of a playable board, which makes it the cheapest available way to run the experiment.

Evaluation space · layered 3 × 3 axes
AXES RRR
SCORED PER MOVE

Structure

Three axes, scored on every candidate move.

Risk, reward and relation are not labels on a diagram here — they are terms in the evaluation function, weighted per personality profile and summed for every move the kernel considers. The same triad that governs decomposition in F.R.A.C.C., reduced to something that produces a number and therefore a result.

AXIS — RISK

What can be lost

Exposure, position and the cost of being wrong — entering the score as defensive and caution terms, weighted by the active profile.

AXIS — REWARD

What can be won

Material, tempo and objective progress. The axis most systems optimise alone — and the reason they behave like sociopaths under pressure.

AXIS — RELATION

Who else is in the decision

The axis nothing else models. Rank, subordination, and what it costs when the units below you are gone. It enters the score directly through morale.

The mapping

Risk, Reward and Relation correspond to the three pillars of the underlying thesis — the natural, the hoped-for, and the perceived. Cubex³ is where an abstract claim about how decisions decompose gets a win rate attached to it.

The three axes are intended to be orthogonal — a basis over decision space, not three overlapping heuristics. That is the same property the Arc Lab exists to test: a basis must be irreducible or attribution smears across entangled dimensions and means nothing. Here the basis is three-dimensional and the projection is a move.

Audit of the implementation — the third axis is inert

Each candidate move is bucketed to −1, 0 or +1 per axis, so it resolves to a cell in a 3 × 3 × 3 space. We instrumented the kernel and measured what it actually resolves to across self-play. The finding is structural, and it is a fault in our implementation rather than in the triad.

Two of the three axis functions never read a coordinate. Material and morale are computed by summing over the pieces that still exist, so moving a piece anywhere returns an identical value; only a capture changes them. Mobility is the sole axis that responds to where a piece went. The consequence is measurable:

AxisThreshold vs. its spread across the moves competing at one decision
riskthreshold 4 · spread 8.80 — well matched
rewardthreshold 5 · spread 6.98 — well matched
relationthreshold 8 · spread 0.04cannot discriminate

A threshold separates two candidates only if they fall on opposite sides of it. Risk and reward are calibrated correctly. Relation varies by four hundredths across an entire candidate set while its threshold sits at 8 — the threshold is 189× the spread, so it almost never separates anything and contributes nothing to the decision. No threshold fixes this — the quantity is flat, not mis-scaled. Only 13 of the 27 cells are ever occupied, and in 76.0% of plies every candidate lands in the same cell; the cube is operating as a plane.

Two further findings from the same audit. The continuous fallback term beneath the buckets covers material and mobility but not morale, so relation was disadvantaged twice over. And the morale engine described above — hierarchy refresh, mercenary masking, support-size counting — is not the code that scores moves; the evaluator carries its own simplified reimplementation. Relation has to become positional, keyed to the geometry of a command chain rather than the size of a force that material already counts. That work is not done, and until it is, this page should not be read as evidence that the decomposition is irreducible.


What the kernel does

Losses propagate upward.

Units are not independent. Each sits under a commander, and each commander under a general, and the evaluation function knows it. When a subordinate is missing, the cost ripples up the chain to the unit that was responsible for it — a commander pays for each absent subordinate, and a general pays substantially more for each absent commander.

The consequence is an evaluator that will not trade away a structure to win a skirmish, because dismantling its own hierarchy is priced in. Orphaned units — those whose commander is gone — are recognised as a distinct case rather than treated as ordinary material.

This is the smallest honest version of the multi-agent problem: not several models negotiating, but one evaluator that has to account for structure it can lose. The larger doctrine work builds on top of this, and is described below as what it is.

EvaluationEvery candidate move scored across the three axes with per-profile weights
HierarchyUnit → commander → general, with responsibility tracked by identity
Morale cascadeMissing subordinates cost their commander; missing commanders cost their general more
ProfilesNamed personalities that shift the weighting — caution, positional, morale, mobility, opportunism, chaos
DifficultyLevelling adjusts strength while leaving the personality dials intact
ModesHuman vs human, human vs AI, AI vs AI
RuntimeEvaluation runs locally in the client; no network dependency for play or move selection

Morale

The cost of losing people.

Most strategy engines price a unit at its material value. This one prices the relationship: what a unit was worth to the commander who depended on it. The morale term is a first-class input to the evaluation function, not a display stat.

It is also the axis that makes the engine behave unlike a material optimiser. An evaluator that only counts pieces will happily disassemble its own command structure for a favourable trade. One that prices the structure will not.

morale · ripple-up
unit lost pawn under a commander commander −1 morale per missing subordinate unit lost commander under a general general −3 morale per missing commander orphaned subordinate whose commander is gone recognised as a distinct case, not scored as ordinary material morale enters the move score as a weighted term alongside material and mobility

Engineering

Constant-time decisions, because search does not survive three dimensions.

The evaluator scores the available moves once and commits. There is no tree. That is a design decision, not an unfinished one, and it rests on two arguments.

Tractability. Adversarial search costs branching factor raised to depth. Move a board into a volume — 512 cells, with multi-leg movement across independent axes — and the branching factor climbs far above the two-dimensional game that minimax was built for, so every additional ply is bought at a punishing rate. The response is not a bigger machine. It is to put the intelligence in the evaluation rather than the enumeration: if the basis is rich enough, one orthogonal projection decides well without expanding a tree at all. Depth of search and quality of evaluation are substitutes, and this is a deliberate bet on the second.

Attributability. The research question is whether a well-structured decomposition produces good decisions. Burying it under a large search tree makes the result unattributable — you would no longer know whether the doctrine or the depth won. Doctrine quality has to be visible in the outcome.

The practical consequence is that a move costs effectively no wall-clock time, which is what makes a complete game in seconds possible, and what makes running the experiment thousands of times a realistic proposition rather than an overnight job. Evaluation runs locally in the client across all three modes — human versus human, human versus AI, and AI versus AI — with no network dependency for play or move selection.

Stated plainly

Cubex³ is the least mature system in the portfolio and we are not going to dress it up. It compiles clean and produces a running production build. It has no test suite — a green typecheck says the code is internally consistent, not that it is correct. Nothing about it has shipped, and there is no store listing, no account system and no sync.


Honest status

Built and running: the three-axis evaluation kernel with per-profile weighting, the morale ripple-up cascade across the subordination hierarchy, difficulty levelling, and all three play modes.

Observed, 2 August 2026: the production build serves and runs. In one timed AI-versus-AI run at the fastest tick setting (50 ms per ply, medium difficulty), a complete game reached a decisive terminal state — king captured, not the turn limit — in 4.83 seconds, with no console errors across that match or the sustained play before it. That is a single timed run on one machine, not a benchmark, and it is reported here only because the throughput is the point: a testbed you can run thousands of times is a different instrument from one you can run overnight.

Designed, not built: the multi-commander doctrine layer — independent doctrine resolution per faction, and explicit arbitration policy between commanders sharing one move. Today a single evaluator scores the whole side. That work is the reason the testbed exists, and it has not been done yet.

We publish the distinction because the gap between designed and built is exactly what a technical diligence process is going to find anyway.

← Previous · 04OrbitGen-AI