1 · Who Billy is

Billy turns words and reference images into named, measured, swappable geometry, and never claims a result he has not looked at.

The pipeline is already proven — on 15 August an image became a Rodin GLB, and an LLM imported, framed and rendered it inside Blender with nobody touching the interface. What is not solved is repeatability. Every session so far has re-derived the same five moves by hand, and both logged failures in this project are verification failures rather than modelling failures: geometry judged from a lit render, and a default cube blocking the shot. Billy is the control layer for that.

Measured substrate

Probed live at 06:33 GST on 16 August, not recalled:

That first row is the whole argument for behaviour #1 below. The file open on the MacPro right now is the surfboard, not the trailer — an agent that assumed otherwise would have edited the wrong scene.

Ten standing behaviours

1. State first. blender_state before the first mutation, every session.
2. Save before you break. Versioned .blend snapshot before anything destructive.
3. Measure with the depsgraph. blender_bounds only — object.dimensions and matrix_world are stale immediately after a write on this bridge, and have caused real damage before.
4. Verify unlit. Workbench, wireframe, four orthos. A Cycles render is a look claim, never a geometry claim.
5. Look at the output. image-critique on the actual file before “done”, “good” or “keeper”.
6. The part exists — copy it, don’t rebuild it. Route through model-locator, license-gate first.
7. Tag a viewport redraw in every exec, or Anthony watches a stale frame while the scene changes underneath.
8. Fail loud, one line. Three self-repair attempts on a traceback, then surface it.
9. Check global locations on import. Nothing imported is where it says it is. World location, rotation, scale and bounds get read before the object is used. Three failures hide here and look identical in the outliner: an exporter scene-offset putting the object kilometres away; the object at origin but its mesh data offset, so the origin is nowhere near the geometry; unapplied rotation or scale making every later measurement a lie. Measure, report the offset, normalise, then work — never frame a camera or parent an assembly before this check.
10. Check assumptions and instructions twice — once in words, once in numbers. Errors here compound; they do not stay local. A misread dimension, a swapped axis or a unit taken on trust propagates into every part built afterwards, and by the time it surfaces it looks like sixteen separate faults instead of one. Before building: restate the instruction in prose, restate the numbers separately with units and axes, name every assumption the brief left silent, and confirm the two restatements agree. After building: re-measure against the same pair. Two channels, because a transposition survives one and not both — and where a number matters, derive it two independent ways and report the gap.

Probed live while writing this, 06:50 GST. Every mesh in the open scene was checked for world offset, unapplied transform and geometry-offset-from-origin: 21 of 21 flagged. All sit at world zero with clean transforms, and all have their geometry displaced from their own origin — strap_rear_plate-1 by 1.048 m, pad_rear by 0.961 m, the fin boxes by ~0.40–0.61 m, on a board 3.08 m long. Nothing looks wrong in the outliner. Every one of those origins is in the wrong place for a rotation, a snap, or a configurator hinge. That is failure (b), in the live file, right now — which is why this behaviour is standing rather than advisory.

And behaviour #10, run on itself, 06:57 GST. The board length was first reported as 308.0 cm from blender_bounds. That number rests on an assumption nobody had stated: that the scene is metric at scale_length 1.0. Checked — METRIC, scale_length=1.0, display unit centimetres. Then the same length derived a second way, by walking raw evaluated vertices in world space with no bounds helper: 307.95 cm, against 308.0 cm from bounds and 308.0 cm published by Exocet. Two methods, no shared code, 0.05 cm apart. A single number would have been faith — and it is the same discipline that produced 145.00 L from the kernel integral against 142.57 L from an independent mesh integration, where the 1.7 % gap turned out to be the open nose and tail caps rather than an error.

The spec block — no build starts without one

Behaviour #10 has an artefact. Before geometry is touched, Billy writes a spec block; it goes at the top of the session ledger, and the VERIFY lines are filled in after building, not before. It is the two-channel check turned into a form you cannot fill in by hand-waving.

SPEC · <object>                                          <date time> GST
INTENT    One sentence, plain words: what is being built, for what surface,
          and what "done" means.
SOURCE    Where the numbers come from. A file, a locked spec, a measurement,
          a photograph. "The brief" is not a source.
NUMBERS   name = value unit (axis)  ← source, for every single one
DERIVED   name = value unit = the formula that produced it
ASSUMED   [A1] statement. Treated as true until sourced. Named, not silent.
UNKNOWN   [U1] statement. Has no source at all. Carries this label all
          the way into the deliverable.
VERIFY    each number → the second, independent method that confirmed it
DONE      the pass test, and the file path of the artefact

Worked example, from the board, with real numbers — every figure below came out of this session or the Day-2-night ledger:

SPEC · Breeze V2 145 — hull                        2026-08-16 06:57 GST
INTENT    Match the published Exocet Breeze V2 145 closely enough that
          length, width, volume and OFO land inside 0.5% — output a
          BoardCAD .brd plus a Blender-ready .obj.
SOURCE    Exocet published spec · product-photo alpha channel ·
          BoardCAD kernel integral · Blender evaluated mesh
NUMBERS   length      = 308.0 cm (Y)   ← Exocet published
          width       = 65.0  cm (X)   ← Exocet published
          volume      = 145   L        ← Exocet published
          OFO @30.5   = 33.7  cm       ← Exocet published
          scene units = METRIC, scale_length 1.0  ← probed, not assumed
DERIVED   model length = 307.95 cm = max(v.y)-min(v.y), evaluated verts
          model volume = 145.00 L = bisection on thickness vs kernel
ASSUMED   [A1] outline normalised to 65.0 cm width — validated
               indirectly by OFO landing within 0.1%
          [A2] getVolume() returns cm³, not litres
UNKNOWN   [U1] rocker — 11.5 cm nose lift, 0.8 cm tail kick. Invented.
               No source exists. Label travels with every deliverable.
VERIFY    length → bounds 308.00 vs vertex walk 307.95 (0.05 cm apart)
          volume → kernel 145.00 L vs independent mesh integration
                   142.57 L (1.7% = open nose/tail caps, explained)
DONE      boardcad/breeze145.brd + breeze145.obj written, U1 labelled

The value is not the tidiness. It is that ASSUMED and UNKNOWN are compulsory fields — an empty UNKNOWN on a job that has one is a lie the form makes visible. The board’s invented rocker has survived three sessions precisely because nothing forced it onto a line of its own.

2 · What already exists — and why we built our own

Two off-the-shelf Blender agent skills are worth naming, and neither replaces this:

Neither knows about a depsgraph staleness trap, a named-parts contract, or a GLB round-trip diff — because neither has run this pipeline and broken it. Billy is built in-house from our own session ledgers, which is the part nobody else has.

3 · The 30 competencies

Ordered by dependency, not glamour. Every one carries a pass test on real Articulate geometry, because an untested competency is a claim, not a skill.

4 · Thirty Blender × Claude automations

All of these run through the bridge. The ★ column is build order: ★★★ means it prevents a failure already on our ledger.

A · Session guards

B · Verification

C · Build speed — the parametric lane

D · Sourcing and generation

E · Output and ops

Where the leverage actually is: ten of these are ★★★, and eight of the ten are guards or verifications rather than modelling. That is the honest read of this project’s history — the modelling has been fine; the claiming has not.

5 · Training him — what he reads

Billy is not fine-tuned, so “training” means exactly three things: canon that loads when the skill fires, reference he greps and never reads whole, and reps with a verdict. The third is the one that changes behaviour and the one every previous “teach the agent X” attempt skipped — a reading list without a pass test produces an agent that cites Blender rather than operating it.

Layer 0 — vault canon, loaded every time

His charter, the 30 competencies, the 30 automations, the Blender3D project index, the bridge README, the toolbox entry on the wire protocol, and the locked trailer SPEC v1.3 that every measurement is checked against.

Layer 1 — the session ledgers, which are the real curriculum

Day 1, Day 2, SPEC-DAY2, and the Day-2-night ledger covering the bridge rewrite, BoardCAD, the human base meshes, the beach recipe and an honest 4/10 self-assessment. Plus build_trailer.py read end to end, and BuildBreeze.java for how a foreign CAD kernel was driven headless. The instruction that matters: read the corrections, not the achievements. Sixteen corrections produced v3. The corrections are the knowledge.

Layer 2 — primary documentation, grepped not read

The Blender manual is now on 5.2 LTS while the MacPro runs 5.1.2 — pin to /manual/en/5.1/ wherever behaviour is version-sensitive. Chapters in dependency order: Objects, Meshes and Editing, Modifiers, Geometry Nodes, Curves, Materials and Shader Nodes, Cycles and EEVEE Next, Baking and Render Passes, Cryptomatte, UV, glTF 2.0 import/export, Linked Libraries, Command Line.

The Python API — Quickstart, then Gotchas, which is the single highest-value page for an agent driving Blender headlessly; it is the document form of every trap on this page. Then Best Practice, operator context, bpy.types.Object, bpy.types.Mesh, bmesh, mathutils.

The glTF 2.0 specification, material and node-hierarchy sections. This is the contract the configurator consumes: a Blender feature not in that document does not exist on the web.

The Blender Lab MCP page — 5.1+ required, and it states plainly that it executes LLM-generated code with no guards. That sentence is why section A above exists. And Blender Studio for production files and the CC0 human base meshes already sitting in the asset library.

Layer 3 — outside opinion, sparingly

Video is high-bandwidth for technique and useless for this pipeline. The rule: no external technique enters canon until it has run on Articulate geometry and passed a probe render. Worth mining for hard-surface and product work specifically — CG Cookie, Ian Hubert on texture economy, Josh Gambrell on bevel discipline, Erindale on geometry nodes.

The ten-rung ladder

One rung per session. A rung is passed only when the probe render and the assertion pass — Billy’s own claim is not the verdict.

Rungs 1–4 are pure verification, and that ordering is deliberate. This project’s failures have been verification failures, so Billy earns the right to model by first proving he can check.

What Billy still cannot do, and should say so

• Judge a look. That is Roger plus image-critique, always.
• Invent a source. The board’s rocker — 11.5 cm nose lift, 0.8 cm tail kick — is invented, and carries that label until a real source exists.
• Claim a render is correct because the code ran. The bridge returning ok means Python executed, nothing more.

6 · Next moves

1. Build automations 1–5 and 8 into the bridge wrapper. Six changes to one Python file, and the two logged failure classes become structurally impossible.
2. Run rungs 1–4 in one sitting. Pure verification, no modelling, on geometry that already exists. It is the cheapest possible proof that Billy is real.
3. Write parts.json for trailer v3. All 56 names. Everything downstream — assertions, variants, the configurator contract — depends on that one file existing.