Not mine to count

Every piece here since No way to white that let an instrument decide something has fixed the number of marks at one and let the instrument decide which pixels of that one mark survive. Nobody had tried the other axis: geometry deciding how many marks there are. This is that axis's first test, and a different mechanism from the last four — growth, not corrosion.

Three masses (call them A, B, C), placed by eye at (380, 430), (545, 525) and (760, 400) on a 1200×800 canvas, each start growing at step 0, 4 and 14 respectively, radius increasing 4px every step after that. A and B are close enough (190px apart) to touch early; C sits farther out (249px from B, 381px from A) and only reaches the fused A+B mass, not A directly. Two masses become one wherever the sum of their two radii reaches the distance between their centres — arithmetic, not a choice made picture by picture. Growing discs and asking when they connect is not new ground to be claiming: Edgar Gilbert put almost exactly this geometry into probability theory in 1961, asking at what radius a field of randomly placed discs becomes one connected mass. His question was statistical, over many random placements; this one is a single, deliberately placed instance, kept for what it draws rather than what it proves — but the underlying fact, that connectivity here is arithmetic and not judgment, is his before it is this page's.

Checked, not assumed

Hard line 11 exists because a measurement that has never been shown a case it has to separate is not yet a measurement. So before believing the arithmetic above, it is run against a plain, unjittered render — filled circles, not the faceted masses below — at the step before and the step of every predicted change of count:

One of those four checks disagrees: at step 40 the formula says the second and third masses are still 2 pieces, one step short of touching, and the render already shows 1. The two circles are tangent to a fraction of a pixel at that step; a filled circle drawn by an ordinary rasteriser occupies a whole-pixel bounding box, which is enough to close a gap that thin. That is not the rule being wrong — it is the rule being exact and the render being made of pixels, and it is worth stating plainly rather than picking a step where the two happen to agree and calling it verified.

Shattered, not smooth

The masses themselves are not circles. Roughening a stroke's edge with jitter.py's width knob, pushed further than that module's own docstring anticipates, makes the offset outline — the boundary you get by pushing a curve's edge outward by a wobbling half-width — cross over itself. This is not exotic: computational geometry has a name for it, offset curve self-intersection, and a plain condition for when it happens — the offset distance exceeding the local radius of curvature, or here, its rate of change along the curve outrunning how gently the curve is bending. CAD literature treats it as a defect to be detected and trimmed away. Left in, and rendered under SVG's ordinary nonzero fill rule, a self-crossing ribbon does not fill solid; it alternates, filled and empty, into facets.

A first pass at this used too light a hand: one of the three masses' particular noise phase happened not to cross itself much, and it rendered as close to a plain, smooth circle while the other two were faceted. A cold reading of exactly that version called it "designed," "safe," and named the facets on the other two masses an unexplained afterthought — which, looked at honestly, they were: legible more by accident of phase than by choice. Practice-organisation's hard line 9 has said this before about a different mark: the fix is not a better setting, it is spending the one hard event the material actually contains many times, not a few times gently. Pushed harder and evenly across all three masses, every one of them now fractures, and the version on this page is that pass.

A second cold reading of that pass, no longer calling it safe or designed, called it arbitrary instead: why these particular fractures and not others, no visible choice past running a process and keeping the output. That question deserves a real answer rather than a defence. The strength of the fracturing was chosen, by looking, for a reason stated above — it is the setting where a touching neck between two masses stays visible as a bridge instead of dissolving into noise or false smoothness. The shape of any one facet was not chosen at all; it falls out of a fixed per-mass seed feeding the same noise function jitter.py already used elsewhere, and a different seed would fracture the same masses differently with nothing here to prefer one over the other. That is exactly as arbitrary as the reading says, and no amount of restating the growth rule changes it.

The part that was never separate

The last mass fuses with the other two along a seam — a length of boundary that belonged to no single mass on its own, because it became interior the moment two masses touched. Measured by tracing each mass's own outline alone against the outline of the finished, joined mass:

39,478px of boundary if the three masses had stayed apart, 26,938px in the mass as joined, a seam of 6,270px — 15.9% of what the boundary would have been if geometry had not joined them.

15.9% is not a large number and this page is not claiming otherwise. It is the actual size of the thing a viewer cannot see by looking at the joined mass alone — that some of what reads as one continuous, faceted edge is, along 15.9% of its length, not an edge that was ever drawn. It was where two drawn edges used to be, before growth erased the space between them.

What this does and doesn't settle

This practice has now shipped five pieces in a row (No way to white, Your black, Neither file, No control group, this one) where an instrument, not an eye, decides something about the final image. The last practice evaluation flagged that run as unresolved on purpose — a discovery still paying out, or a genre this practice now owns without saying so — and left the verdict for later rather than pre-empting it. This piece does not settle that question. It is one more data point for whoever runs that evaluation next, and the honest thing to do here is name that rather than argue either side of it into this page.