clay-borg/INTENT.md

157 lines
7.7 KiB
Markdown
Raw Normal View History

# Intent
Clay-Borg is a rebuild-from-scratch simulation and games engine framework: it
assimilates and optimizes techniques and implementations useful for games,
simulations, and robotics.
It is not another monolithic game engine. It is a capability-assimilating
CB-WP-0022 T03: ADR-0012 -- the register already existed, and the rule was one clause short Nine decisions. Two were not on T03's list; both are the review's. D2: specs/GroundRules.md §Underdetermined IS the register. C4 pointed out it was never evaluated as a candidate, and against the survey's own five benchmarks it already delivers four -- including the Magic Oracle property ("a ruling flips the scenario, not the kernel", :231-233) that the survey travelled to Magic to discover and we had written down ourselves eight days earlier. What it lacks is reproductions. So this pass extends a section rather than building a register: no new file, no new schema, and no second mechanism to disagree with the first. D3: admissibility is three clauses. It exists; it has the ruled shape (GROUND-WP-0004 T02's row-level table, never a sum -- promoted from a T04 addendum because two of three wrong premises were sums without tables); and it CAN FAIL. The third is C1's. GR-E01's scenario went green when the edition landed, and the finding stayed admissible and stayed queued for transmission, because nothing in the rule said a passing artifact was a signal. A green reproduction is an alarm, not a reassurance. D1 applied: INTENT gains a fourth property, Instrument, worded as a mechanism rather than an ambition and carrying its own falsifier -- if a pass tolerates an undecided rule by quietly picking a default, the property is false. D4 five kinds, each forced by an existing finding; a sixth during backfill means the taxonomy was invented. D5 lifecycle where `applied` means the source changed, the queue empties while the log accumulates, and withdrawals are reported rather than deleted -- GR-E01 is why. D6 notes admitted but never reportable, 30-day expiry on the existing age machinery; refusing them would discard the only class of finding the engine cannot produce itself, which is CB-WP-0025's whole input. D7 no engine-evolution register, on an inventory C5 corrected -- narrowed, not settled. D8 design-baseline.py retired, kept as a dated snapshot because deleting it erases the evidence for how 33% got in. D9 the artifact stays here, ground-game gets a generated file under its own workplan. loop-lint: no findings. facts-check: no findings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 15:05:51 +02:00
development engine with four distinct properties:
1. **Clay** — its canonical models, contracts, rules, and tools remain malleable.
2. **Borg** — mature, optimized libraries are assimilated behind controlled
interfaces rather than copied or exposed directly.
3. **Product-driven evolution** — abstractions are extracted from working
games, beginning with **GROUND — A Game of Bonds and Rivalry: DARVO
Edition**, rather than invented in isolation.
CB-WP-0022 T03: ADR-0012 -- the register already existed, and the rule was one clause short Nine decisions. Two were not on T03's list; both are the review's. D2: specs/GroundRules.md §Underdetermined IS the register. C4 pointed out it was never evaluated as a candidate, and against the survey's own five benchmarks it already delivers four -- including the Magic Oracle property ("a ruling flips the scenario, not the kernel", :231-233) that the survey travelled to Magic to discover and we had written down ourselves eight days earlier. What it lacks is reproductions. So this pass extends a section rather than building a register: no new file, no new schema, and no second mechanism to disagree with the first. D3: admissibility is three clauses. It exists; it has the ruled shape (GROUND-WP-0004 T02's row-level table, never a sum -- promoted from a T04 addendum because two of three wrong premises were sums without tables); and it CAN FAIL. The third is C1's. GR-E01's scenario went green when the edition landed, and the finding stayed admissible and stayed queued for transmission, because nothing in the rule said a passing artifact was a signal. A green reproduction is an alarm, not a reassurance. D1 applied: INTENT gains a fourth property, Instrument, worded as a mechanism rather than an ambition and carrying its own falsifier -- if a pass tolerates an undecided rule by quietly picking a default, the property is false. D4 five kinds, each forced by an existing finding; a sixth during backfill means the taxonomy was invented. D5 lifecycle where `applied` means the source changed, the queue empties while the log accumulates, and withdrawals are reported rather than deleted -- GR-E01 is why. D6 notes admitted but never reportable, 30-day expiry on the existing age machinery; refusing them would discard the only class of finding the engine cannot produce itself, which is CB-WP-0025's whole input. D7 no engine-evolution register, on an inventory C5 corrected -- narrowed, not settled. D8 design-baseline.py retired, kept as a dated snapshot because deleting it erases the evidence for how 33% got in. D9 the artifact stays here, ground-game gets a generated file under its own workplan. loop-lint: no findings. facts-check: no findings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 15:05:51 +02:00
4. **Instrument** — the engine is rigorous enough that it cannot proceed
past a rule that does not decide. What it cannot execute, it reports:
findings about the *game's* design are a product of building the
simulator, not a side activity, and they are carried back to the game's
owner with the artifact that produced them. *(ADR-0012. A restatement of
what has already happened six times, made a duty. If a pass ever
tolerates an undecided rule by quietly picking a default and not raising
it, this property is false.)*
CB-WP-0040: name the stratum before naming the defect The maintainer could not tell whether "error", "failure", "finding" or "correction" referred to the game's design, our formalisation of it, the code, the measuring apparatus, or the sentences we wrote. Three review rounds produced twenty-odd defect statements spanning five systems, all called errors. The confusion was ours. specs/Taxonomy.md, grounded in named canon rather than invented here: six strata from Sargent's problem entity / conceptual model / computerized model, extended where a simulation-V&V frame stops — we also own an instrument and an account. The two relations are what was missing: GAME<->MODEL is validation, MODEL<->ENGINE is verification, and nearly every argument about "our bug or their gap" was that distinction going unnamed. Fault/error/failure from Avizienis et al., applied within a stratum, plus the rule that explains the review history: a failure in one stratum is a fault in the next. And it finally defines the family ADR-0018 could only point at — a wrong-subject error is an ACCOUNT failure with no INSTRUMENT fault, which is why tests never catch them. MDA supplies the game-facing layers and one hard limit: our panels measure dynamics, our trial logs sample aesthetics, and a win rate does not answer "is it fun". specs/Positioning.md names the field fairly — Ludii is the closest relative and the right benchmark — and the four differentiators, each already built rather than aspired to. Clay-borg is a design-evidence instrument; anyone can produce the number. Three tracks named and none started: a second game, game theory as the lens on dynamics, and assimilated knowledge about why games work. Track A is the falsifier for the whole positioning: every abstraction here has exactly one instance, which by our own rule may mean invented rather than observed. Chaos window 3 closes at 12 declarations with one override that changed nothing. Its verdict is due and is deliberately not written here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 11:41:16 +02:00
A fifth property, added 2026-08-08 because three adversarial review rounds
made it undeniable:
5. **The instrument is under the same discipline as the engine.** Twelve
fatal defects were found in one measurement, **every one in our
apparatus and none in the game**, and several had already been written
into evidence as conclusions. A tool that reports design findings
without treating its own measurements as claims is reporting its bugs
at the same volume as its results. *(See [`specs/Taxonomy.md`](specs/Taxonomy.md)
for what "defect" now means, and where.)*
The central rule:
> **Own the semantics; assimilate the implementation.**
CB-WP-0040: name the stratum before naming the defect The maintainer could not tell whether "error", "failure", "finding" or "correction" referred to the game's design, our formalisation of it, the code, the measuring apparatus, or the sentences we wrote. Three review rounds produced twenty-odd defect statements spanning five systems, all called errors. The confusion was ours. specs/Taxonomy.md, grounded in named canon rather than invented here: six strata from Sargent's problem entity / conceptual model / computerized model, extended where a simulation-V&V frame stops — we also own an instrument and an account. The two relations are what was missing: GAME<->MODEL is validation, MODEL<->ENGINE is verification, and nearly every argument about "our bug or their gap" was that distinction going unnamed. Fault/error/failure from Avizienis et al., applied within a stratum, plus the rule that explains the review history: a failure in one stratum is a fault in the next. And it finally defines the family ADR-0018 could only point at — a wrong-subject error is an ACCOUNT failure with no INSTRUMENT fault, which is why tests never catch them. MDA supplies the game-facing layers and one hard limit: our panels measure dynamics, our trial logs sample aesthetics, and a win rate does not answer "is it fun". specs/Positioning.md names the field fairly — Ludii is the closest relative and the right benchmark — and the four differentiators, each already built rather than aspired to. Clay-borg is a design-evidence instrument; anyone can produce the number. Three tracks named and none started: a second game, game theory as the lens on dynamics, and assimilated knowledge about why games work. Track A is the falsifier for the whole positioning: every abstraction here has exactly one instance, which by our own rule may mean invented rather than observed. Chaos window 3 closes at 12 declarations with one override that changed nothing. Its verdict is due and is deliberately not written here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 11:41:16 +02:00
And the second, which says what the product actually is:
> **Clay-borg is a design-evidence instrument.** Its output is not a
> number about a game; it is an auditable answer to *what does this rule
> do at the table, and how much should you trust that* —
> [`specs/Positioning.md`](specs/Positioning.md).
Clay-Borg owns what an entity, object, command, event, card, zone,
relationship, game, simulation, asset, plugin, and capability *mean*.
External libraries (wgpu, Rapier, Bevy ECS, Wasmtime, Quinn, egui, Serde,
tracing, …) provide optimized implementations of rendering, physics,
networking, serialization, and similar functions behind canonical ports. No
external library type should leak across a canonical interface.
CB-WP-0040: name the stratum before naming the defect The maintainer could not tell whether "error", "failure", "finding" or "correction" referred to the game's design, our formalisation of it, the code, the measuring apparatus, or the sentences we wrote. Three review rounds produced twenty-odd defect statements spanning five systems, all called errors. The confusion was ours. specs/Taxonomy.md, grounded in named canon rather than invented here: six strata from Sargent's problem entity / conceptual model / computerized model, extended where a simulation-V&V frame stops — we also own an instrument and an account. The two relations are what was missing: GAME<->MODEL is validation, MODEL<->ENGINE is verification, and nearly every argument about "our bug or their gap" was that distinction going unnamed. Fault/error/failure from Avizienis et al., applied within a stratum, plus the rule that explains the review history: a failure in one stratum is a fault in the next. And it finally defines the family ADR-0018 could only point at — a wrong-subject error is an ACCOUNT failure with no INSTRUMENT fault, which is why tests never catch them. MDA supplies the game-facing layers and one hard limit: our panels measure dynamics, our trial logs sample aesthetics, and a win rate does not answer "is it fun". specs/Positioning.md names the field fairly — Ludii is the closest relative and the right benchmark — and the four differentiators, each already built rather than aspired to. Clay-borg is a design-evidence instrument; anyone can produce the number. Three tracks named and none started: a second game, game theory as the lens on dynamics, and assimilated knowledge about why games work. Track A is the falsifier for the whole positioning: every abstraction here has exactly one instance, which by our own rule may mean invented rather than observed. Chaos window 3 closes at 12 declarations with one override that changed nothing. Its verdict is due and is deliberately not written here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 11:41:16 +02:00
## Vocabulary
*"Error"*, *"failure"*, *"finding"* and *"correction"* were each being
used for the game's design, our formalisation of it, the code, the
measuring apparatus and the sentences we wrote.
[`specs/Taxonomy.md`](specs/Taxonomy.md) fixes that: **every defect
statement names a stratum first** — GAME, MODEL, ENGINE, INSTRUMENT,
ACCOUNT, PRESENTATION — because "a bug in the simulator" and "a gap in the
game" have different owners and different fixes.
## Where this is going
Three tracks, none started, in [`specs/Positioning.md`](specs/Positioning.md) §4:
**a second game** (which is the falsifier for "GROUND is an example"),
**game theory as the lens on dynamics**, and **assimilated knowledge about
why games work**, offered to designers.
simulators/: persist the survey, and let it shrink two of the three tracks Eight profiles on a common schema, each marking what was checked against a source this session and what is background recollection. Three are marked unverified in full — Machinations, the play substrates, most of RBG — and say so rather than reading as evaluations. Written straight after three review rounds whose entire yield was claims outrunning what had been checked, so the confidence rule is the first thing in the README. The survey changed the plan, which is what a survey is for. Track C was described in Positioning as open ground. It is not: Browne published 57 criteria for game quality, and Ai Ai already computes designer-facing measures — drama, lead changes, branching factor, completion, duration — from played games. The track becomes adopt, credit and find the gap. The gap looks real: those measures presume a leader, and SHARED GROUND has none — Modes.csv gives its tiebreak as "Not applicable". Track B probably adopts rather than builds. OpenSpiel implements CFR, best-response and exploitability over games that are simultaneous-move, imperfect-information and co-operative, which is all four of GROUND's awkward properties. "Does ATTACK ever pay" is a best-response question, and we spent three review rounds refining a two-policy sweep for it. The first Track B task is now one question — is exploitability meaningful for a co-operative game with a shared threshold — not a build. The cost of not surveying earlier is therefore measurable, and is recorded rather than glossed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 11:56:27 +02:00
The field is surveyed in [`simulators/`](simulators) — one profile per
system, each marking what was checked and what is recollection. **The
survey already shrank two of the three tracks**: Browne's 57 criteria and
Ai Ai's authoring metrics mean track three is *adopt and find the gap*,
not *invent*; and OpenSpiel's exploitability is the standard instrument
for the question track two exists to ask.
## Why GROUND first
GROUND requires modest physics but sophisticated social state, simultaneous
decisions, and constrained sequences (a binding DARVO deny/attack/reverse
state machine, a typed relationship graph, commit/reveal simultaneous
resolution). It must stay playable headless — no rendering, no rigid-body
simulation required to run or test the rules. The 3D tabletop is a
projection and interaction surface for the game, not the definition of the
game.
## The most important design decisions
1. Build GROUND first, not a general engine first.
2. Keep rules independent from rendering and physics.
3. Use commands and events as the authoritative mutation mechanism.
4. Provide null, reference, and optimized implementations of important
capabilities.
5. Never leak assimilated-library types into canonical interfaces.
6. Use server-authoritative physics and deterministic semantic rules.
7. Treat player visibility as a projection, not a UI afterthought.
8. Make every defect reproducible as a scenario and replay.
9. Give coding agents bounded work packets and stable commands.
10. Attach TargetRevenue phases to versioned improvements and evidence
bundles.
## First product
> A headless, replayable, and agent-readable GROUND rules engine that can be
> projected onto an increasingly physical virtual tabletop, while every new
> capability remains replaceable, measurable, and financeable through
> TargetRevenue.
## Implementation order
0. **Headless GROUND** — full authoritative state, 26 players,
commit/reveal, relationships, DARVO, GROUND practice, CLI player, replay
and scenario tests, simple bots. No rendering, no physics.
1. **Inspectable 2D table** — card/token/hand/relationship-graph
visualization, drag-to-propose, debug inspector, hot-seat play.
CB-WP-0017: legible interaction, and the chaos window's verdict Provenance (tier M, structural S, chaos d4=4 -> OVERRIDE drawn M): the maintainer could drag after CB-WP-0016 but could not tell what was pickable, held, or droppable. Underneath that, the page was WRONG about which moves exist: 9 legal commands rendered as 5 cards each claiming all three target kinds, from a const string in the emitter. Investigate is legal on problems 2 and 3 but not 1; Solve on 1 but not 2 or 3. The live page now says 'Solve onto problem 1'. ADR-0010 restates control 5, which this work would otherwise have outgrown in silence: every game fact the page acts on must arrive from Rust as data; the script may read, match and render it, never compute, infer, filter or default one. The survey's real finding is that the permitted and forbidden designs are indistinguishable from outside, so the vocabulary grep is demoted to a cheap first line and two behavioural properties become the controls -- the highlighted set EQUALS the set Rust emitted, and anything the page marks legal must resolve. Both mutation-proven; the derive-legality mutation produces a plausible highlight (seat-0,1,2 where only seat-1 is legal) and is caught. Visible now: .pick resting shadow, .held on the grabbed element, .dropok on every legal target including BOTH drawings of a seat, and a ghost following the pointer. Nothing perceptual is verified and ADR-0010 D5 says so. The DOM stub now models classList/querySelectorAll/createElement and builds its node set from the real emitted page. Trap recorded: QuickJS fixes its stack limit at Context creation relative to that frame, so a helper returning a Context makes every later eval report 'SyntaxError: stack overflow'. CHAOS WINDOW CLOSED, 12 declarations, 2 overrides, one each way. Both changed the outcome, so the retirement condition is not met. Verdict: keep, and recommend d4 -> d8 with a second window of 12 -- that is a change to the loop's own constraints and is owed to the next declaration as tier-M work, not made here. CB-EV-0014 corrected: it quoted CB-WP-0015 at $15.14/136 and called it the first settled figure quoted. Now $22.70/166. The number had been read during CB-WP-0015 itself, so there are two defects -- the boundary, and quoting from memory instead of re-running the instrument. make all exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 22:42:45 +02:00
*Open on one human verification, and every run of it so far has found
something no test could. 2026-08-02, run 1: the drag was broken — drop
targets were `id`s, which must be unique, so the graph circle held
`seat-0` and the seat card had none (CB-WP-0016). Run 2: the drag
worked but the page was **wrong about which moves exist**, showing 5
cards each claiming all three target kinds where 9 specific commands
were legal, with no way to see what was pickable, held, or droppable
(CB-WP-0017). Both fixed. What remains is perceptual and unreachable
from here by construction (ADR-0010 D5): run `cb-play --serve 0` and
confirm you can see what can be picked up, what you are holding, and
where it may go.*
2. **Physical 3D tabletop** — wgpu renderer, Rapier-backed physics, camera
and pointer controls, snap zones, asset importer.
3. **Networked sessions** — authoritative host, private projections,
commit/reveal protocol, reconnection, replay verification, spectator mode.
4. **Game creation framework** — object prototypes, scene/zone editors,
card/deck importer, package validation, Wasm game components.
5. **Prove generality** — implement one deliberately different fixture game;
only then promote duplicated GROUND abstractions into the stable Clay
Canon.
> No concept becomes canonical merely because it looks general. It becomes
> canonical after surviving a second concrete use.
## Sister repositories
- **`ground-game`** — the authoritative home of the GROUND boardgame itself
(rules, editions, content). Clay-Borg implements the engine that simulates
it; game-semantics questions defer to that repo.
- **`target-revenue`** — the canonical home of the Target Revenue Framework
and the TRSL license text this repo is released under.
## Provenance
This intent is distilled from the fuller architectural exploration in
[`history/260730-InitialExploration.md`](history/260730-InitialExploration.md),
which also covers the runtime substrate, simulation kernel, physics
subsystem, world-building layer, tabletop domain framework, networking
architecture, the agentic inner loop (work packets, CLI surface, quality
gates), and the TargetRevenue business-control model in full detail.