/* New illustrations for the v2 homepage pass — 11 Sept, from Dylan's three sketches and the
* call notes. Every one of these is composed from the design system's own drawing primitives
* (Block, Face, Stroke, Cap, diagramTone — all exported on DS) exactly the way ForceMultiplier,
* FleetMap and MigrationArc already are. Nothing here forks or edits the design system: these
* are new components sitting beside it, built the same way its own diagrams are built.
*
* None of these are final. Each one carries its own orange confirm-or-cut note in review.jsx
* (the ILLUSTRATIONS registry) — Dylan and Donny look at the drawing itself, not a description
* of it, and say what's right and what needs to change.
*/
/** A small ellipse-arc helper, the one thing Sketch's arcPts doesn't do (it's circle-only). */
function ellipsePts(cx, cy, rx, ry, a0, a1, n) {
const out = [];
for (let i = 0; i <= n; i++) {
const a = a0 + (a1 - a0) * i / n;
out.push([cx + Math.cos(a) * rx, cy + Math.sin(a) * ry]);
}
return out;
}
/** Samples a cubic bezier into n+1 straight-line points, for feeding a smooth curve through
Stroke (which only draws polylines). Mike, 24 Sept, on DdilResilience's cloud after it was
first converted to a hand-drawn Stroke: "now that they're hand-drawn, they look goofy" — an
11-point polygon traced the right silhouette but read as sharp, angular corners once wobbled,
not a rounded cloud. Sampling each of the original bezier's own curves densely, instead of
hand-picking a dozen vertices, keeps the silhouette smooth while still letting Stroke's
per-segment jitter give it a sketched texture. */
function cubicPts(p0, c1, c2, p1, n) {
const out = [];
for (let i = 0; i <= n; i++) {
const t = i / n, mt = 1 - t;
const a = mt * mt * mt, b = 3 * mt * mt * t, c = 3 * mt * t * t, d = t * t * t;
out.push([a * p0[0] + b * c1[0] + c * c2[0] + d * p1[0], a * p0[1] + b * c1[1] + c * c2[1] + d * p1[1]]);
}
return out;
}
/** An arrowhead chevron whose wings are perpendicular to the line's own direction, so it always
points the right way regardless of the angle the line actually travels at — a fixed
horizontal chevron on a diagonal line is the bug Mike flagged in KeySeal. */
function arrowHead(Stroke, x1, y1, x2, y2, size, seed, ink) {
const dx = x2 - x1, dy = y2 - y1;
const len = Math.hypot(dx, dy) || 1;
const ux = dx / len, uy = dy / len;
const px = -uy, py = ux;
const backX = x2 - ux * size, backY = y2 - uy * size;
const p1 = [backX + px * size * 0.6, backY + py * size * 0.6];
const p3 = [backX - px * size * 0.6, backY - py * size * 0.6];
return ;
}
/** A small hand-drawn terrain cue for DistributedSiteReach's optional `terrain` prop — Dylan,
17 Sept, on Oil & Gas specifically: "these might be in severe environments... platform,
pipeline station, refinery... floating oil platform or on a mountain or on the gulf away from
town. Locations that would not have good IT." Drawn from the same Stroke/Face primitives as
the rest of the file, centered under a site block at (cx, baseY), not as photographic or icon
assets. 'mountain' is a single triangular peak outline, 'remote' is a few small isolated dots
standing in for the middle of nowhere.
Donny Davis, 17 Sept, replying to the V5 email with a screenshot of this exact diagram: "I like
the illustration! ... For oil and gas, it would be awesome to put an offshore oil platform in
there and show a starlink connecting. I know you are probably using the same graphic for all
of them and just swapping text, so if its too much, it still works fine." The first pass at
'offshore' was two short wavy lines floating under the block — too subtle to register as a
platform at a glance. A second pass added support legs and a dashed satellite uplink, but an
independent review of THAT pass, measuring the actual rendered strokes, still found the legs
"thin enough to be nearly imperceptible" at normal viewing size — correct geometry, not enough
visual weight. This pass keeps the same footprint (it's still constrained to ~9px of vertical
room above the site label) but roughly doubles every stroke's weight, adds an X lattice brace
between the legs — the one detail that reads as "oil rig" rather than "box on sticks" even
small — and widens the wave's amplitude. The dish sits up-and-LEFT of the block specifically to
stay clear of the hub-to-site line, which approaches every site from the upper right. */
function terrainCue(Stroke, Face, Cap, kind, cx, baseY, seed, ink) {
if (kind === 'offshore') {
const legY0 = baseY - 6, legY1 = baseY + 4;
const legXs = [cx - 15, cx + 15];
const dishX = cx - 18, dishY = baseY - 60;
const uplinkFrom = [cx - 4, baseY - 34];
return (
{legXs.map((lx, i) => (
))}
{/* An independent review of the widened-X pass: legs and X now read fine, but "the line
below the legs... reads mostly as a flat baseline with one modest bump... doesn't
register as choppy water at first glance." A single wide zigzag apparently gets
smoothed by the hand-drawn line renderer into something closer to a gentle curve than
a sharp wave. Switched to four full-amplitude cycles packed into the same width — more
frequent direction changes read as "choppy" even after smoothing in a way a single
slow wave doesn't — using the full legY0-to-legY1 range (touching the block's own
underside at each crest, stopping 2px short of the site label at each trough) instead
of the softened +1/-1 offsets from the previous pass. */}
{[0, 1, 2].map(i => {
const t0 = i / 3, t1 = (i + 0.62) / 3;
const lerp = (t) => [uplinkFrom[0] + (dishX - uplinkFrom[0]) * t, uplinkFrom[1] + (dishY - uplinkFrom[1]) * t];
return ;
})}
Starlink
);
}
if (kind === 'mountain') {
return (
);
}
if (kind === 'remote') {
return [-12, 0, 12].map((dx, i) => (
));
}
return null;
}
/* Mike/Dylan, 23 Sept call: "change the boxes to an illustration" (Oil & Gas) and per-site icon
notes for Telecom in the same breath — "you could just make it a stylized oil rig... pipeline
station could just be a mountain and a refinery could just be like the little factory icon...
your data center should almost certainly be a server rack, your point of presence could be like
an electrical substation looking thing, your cell site would be like a tower with a little
blinky thing on top." DistributedSiteReach's generic Block stood in for every site regardless of
what kind of site it was; this draws a specific, recognizable shape per site instead, in the
same thin hand-drawn stroke weight terrainCue above already uses. Returns null for an unlisted
kind (including undefined) so the caller falls back to the plain Block — this is additive, not
a replacement for sites that don't need a specific icon.
Mike, 23 Sept, second pass: "this is horrific... the worst job ever... like an elementary
schooler would have made it. Does that even remotely look like an oil rig platform? Does a
pipeline station, is that really a mountain?" The first pass drew every shape from raw, un-
wobbled SVG path/line/rect/circle primitives — the one function in this file that didn't use
Stroke/Face at all, which is also the only illustration this file's own hand-drawn look never
touched. Rebuilt every shape from Stroke/Face (matching terrainCue's own signature) with more
structure per icon — a tapered, cross-braced lattice for the rig and the cell tower instead of a
triangle and three bare bars, a two-peak silhouette with a snow-cap notch for the mountain, a
building with a door and windows instead of a bare rectangle for the factory, and actual
insulator poles on a transformer housing for the substation — so each one is identifiable on
its own, not just by the caption under it. */
function siteIcon(Stroke, Face, kind, cx, baseY, seed, ink, accent) {
const top = baseY - 44, bottom = baseY - 4;
if (kind === 'rig') {
const lv = [top, top + (bottom - top) * 0.38, top + (bottom - top) * 0.7, bottom];
const hw = [4, 8, 12, 15];
const L = lv.map((y, i) => [cx - hw[i], y]), R = lv.map((y, i) => [cx + hw[i], y]);
return (
{[0, 1, 2, 3].map(i => )}
{[0, 1, 2].map(i => (
))}
);
}
if (kind === 'mountain') {
const peak1 = [cx - 9, top + 2], peak2 = [cx + 9, top + 12];
return (
{/* a short snow-cap line just under the taller peak's own tip */}
);
}
if (kind === 'factory') {
/* Mike, 24 Sept: "the refinery looks sort of like a house... I think that's the issue: is the
door and the window." A door at roughly the same proportion and position a house's front
door sits at, plus a small window beside it, is exactly the residential cue that undercuts
an otherwise-industrial silhouette. Dylan's own spec (17 Sept) never asked for either —
"the little factory icon that has smoke coming out of the stacks" — so both are dropped
outright rather than reworked; the building reads as a plain warehouse box under two
chimneys, which is the actual reference. */
const roofY = top + 18;
return (
);
}
if (kind === 'tower') {
const lv = [top + 2, top + 12, top + 24, bottom];
const legHw = [1.5, 2.5, 3.2, 4];
const L = lv.map((y, i) => [cx - legHw[i], y]), R = lv.map((y, i) => [cx + legHw[i], y]);
const armHw = [9, 11, 7];
return (
{[0, 1, 2].map(i => (
))}
);
}
if (kind === 'substation') {
const boxTop = bottom - 16;
const poleTop = top + 12;
return (
{[cx - 6, cx + 6].map((px, i) => (
))}
);
}
return null;
}
/** Two thin bars inset inside a block's own front face — "this host runs guests", not another
tier of infrastructure. Sized off the block's own box so it never runs past its edges. */
function vmBars(Face, x, y, w, h, seed, ink) {
const pad = Math.max(2, Math.min(4, w * 0.1));
const bw = w - pad * 2;
const bh = Math.max(2, (h - pad * 2 - 2) / 2);
return [0, 1].map(i => {
const by = y + pad + i * (bh + 2);
return ;
});
}
/* ------------------------------------------------------------------- BA — hero illustration */
/* GlobalReach — replaces ForceMultiplier in the hero. Dylan, 9/10: "your deployable kit, your
regional data center, your enterprise... our main value is starting at the edge and going to
the enterprise." One globe, one control plane above it, three tiers around it. Matches the
sketch Dylan sent: control plane / edge kit / regional data center / enterprise infrastructure,
arranged around a hand-drawn globe rather than stacked as a hierarchy.
The satellite dish above the edge kit — Donny's idea from the same call, drawn as a dashed
alternate reach to the edge kit — is gone as of the 15 Sept Triq V2 walkthrough. Luigi: "I think
those are two different problems... the satellite kind of link hanging off there is just a
little confusing... I don't think it necessarily needs to be on this infrastructure." The
low-bandwidth/edge-link idea isn't lost as a concept, just off this specific core illustration,
whose whole point is "one control plane reaches every location the same way."
The two thin bars inside each infrastructure block are a VM-stack cue — Mike compared this
against a plain version (no bars) and picked this one, so it's the only version now, not a
toggle. Mike also caught a real geometry bug here: the edge-kit and regional-data-center
connectors used to enter the globe at different depths (one nearly horizontal, one a steeper
diagonal) and actually crossed into the sphere's interior, while the enterprise connector
correctly just touched its surface. All three now touch the circle's own circumference, and
edge-kit/regional-data-center are exact mirrors of each other across the vertical center line. */
function GlobalReach({ tone = 'paper', seed = 3, label, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const cx = 210, cy = 158, r = 56;
const globe = ellipsePts(cx, cy, r, r, 0, Math.PI * 2, 40);
const meridian = ellipsePts(cx, cy, r * 0.36, r, 0, Math.PI * 2, 28);
const equator = ellipsePts(cx, cy, r, r * 0.36, 0, Math.PI * 2, 28);
// Mirrored touch points on the circle itself, at the same height either side of center —
// computed once so "mirror of each other" is structural, not eyeballed.
const touchY = cy - r * 0.6;
const touchDX = Math.sqrt(Math.max(0, r * r - (cy - touchY) * (cy - touchY)));
const leftTouch = [cx - touchDX, touchY];
const rightTouch = [cx + touchDX, touchY];
return (
);
}
/* ------------------------------------------------------------------- BD — regions and tenancy */
/* FleetTenancyMap — replaces FleetMap on this page. FleetMap itself is untouched and still
correct for where it's used elsewhere (Solutions, per review.jsx's own notes); it just isn't
the drawing this section needs, on two counts Dylan and Donny both raised on the 9/10 call.
First, the visible label: FleetMap's own copy still says "global registry" — that text is
baked into the design-system bundle, not a prop, so relabeling it here would mean forking the
bundle. Redrawing it as a new component was the only way to actually get "global control
plane" onto the page rather than just into the surrounding copy.
Second, and the bigger reason: Donny, 9/10 — "this looks like regionality, not tenancy... how
do we amplify the tenancy?" Dylan's own answer on the call was "we might need to show
regionality and tenancy on the same diagram" — not a second drawing beside the first, one
drawing. pac-fwd's tenants are Dylan's own example from the call ("Army, Navy, Air Force");
the other two regions keep placeholder tenant names since nobody named real ones for them. */
function FleetTenancyMap({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const regions = [
{ x: 70, key: 'eu-central', tenants: ['tenant 1', 'tenant 2'] },
{ x: 210, key: 'conus-east', tenants: ['tenant 1', 'tenant 2'] },
{ x: 350, key: 'pac-fwd', tenants: ['army', 'navy', 'air force'] },
];
const boxW = 120, rowH = 54, topY = 104;
/* Mike, v3 review: "tenant 1" sat only 8px under its region's own label ("eu-central"), and
each tenant's icon pair sat only 8px under its own label — cramped enough to read as one
run-on line rather than a region header followed by its tenants. HEAD_GAP opens up the gap
from the region label to the first tenant row; LABEL_GAP does the same from a tenant's own
label to its icons. Both flow into boxH so the region's own outline still wraps everything. */
const HEAD_GAP = 40, LABEL_GAP = 12, BOTTOM_PAD = 20;
/* Mike, v5 review: the summary caption sat at a fixed y=388 in a 400-tall viewBox, regardless
of how tall the tallest region box actually was — a ~72-unit gap beneath pac-fwd's own
"runs independently" line, almost double every other gap in the drawing, and just 12 units
off the SVG's bottom edge. On a wide illustration column that read as a caption "floating in
outer space," unclear whether it belonged to this diagram or the next section's. Deriving it
from the tallest region's own boxH, at the same HEAD_GAP rhythm the rest of the drawing
already uses, pulls it back onto the diagram it actually describes; the viewBox height
follows it down instead of leaving dead space below. */
const maxBoxH = Math.max(...regions.map(r => HEAD_GAP + (r.tenants.length - 1) * rowH + LABEL_GAP + 16 + BOTTOM_PAD));
const captionY = topY + maxBoxH + 16 + HEAD_GAP;
const viewH = captionY + BOTTOM_PAD;
return (
);
}
/* Mike, 16 Sept, HourPlus call — replaces NoInboundPorts on this section. Donnie, live on the
call, rejecting the old two-box abstraction: "I don't particularly care for this graphic
because it doesn't truly represent the real problem... if you were to put an island on the
left with a bunch of controllers and a bunch of compute nodes, and then on the basalt side you
had a couple of different regions with hosts going outbound into basalt, it would communicate
the value proposition a little bit better." He drew exactly that (the reference image Mike
attached) while still on the call — this is that drawing, redrawn in the site's own hand-drawn
primitives rather than the flat reference icons.
Two corrections from the same conversation this also fixes, both from Donnie: the boxes next
to each site were mislabeled "controller" — "your controller is part of infrastructure... I
think rather than controller and your infrastructure it should be hypervisor, host, hypervisor
management" — so each site's own box now reads "Hypervisor," and the thing living outside the
firewall on each side is the one actually called a controller. And the arrow direction per
site: "the hypervisor is the thing that initiates the contact... the box that the hypervisor
runs on is what initiates the connection" — so on the Basalt side, arrows originate at each
site's own hypervisor and terminate at the controller, not the other way around.
The left side draws three separate controllers, one per site, with a real gap punched in each
one's own firewall segment ("you gotta show a hole in the firewall... make a little clearing")
— the labor-duplication claim (a controller, and a hole, for every site) alongside the security
one. The right side draws one controller behind one solid, gapless wall, reached by three
separate outbound-initiated lines — the multi-tenancy claim (Tenant 1/2/3) and the security
claim (no hole anywhere) on the same drawing, which is exactly what Donnie asked for: "we might
need to show regionality and tenancy on the same diagram" as the outbound-only one, not two. */
/* Mike, 17 Sept, third pass: "you left-justified the illustration, yet your text is centered...
double-check that design a little clearer." The first redraw used a 900:320 viewBox — almost
3:1, wide and short — which meant `width:100%` in the split's own narrower `.rv-illustration-
wrap` column scaled it down to a small strip pinned to the top of a much taller column, with a
lot of dead space beneath it: it read as small and stuck in one corner next to a full-height
StatRow, not as a centered, room-filling drawing. The reference image itself is close to
square, not a wide banner. Same layout, same elements, same geometry — rows just spread out
over roughly twice the vertical space (200 units apart instead of 95) so the whole drawing's
own proportions are closer to that reference and to the column it actually renders in.
Mike, 17 Sept, fourth pass, on this exact fix: "you didn't label the firewall... you didn't
center the illustrations on the one with the typical inbound management illustration, that's
not centered on the text, it still seems to be left-justified." Two real bugs, both on the left
half only (the right, "Basalt," half was never his complaint): the left group's own content
spans x=10-240, centered at x=125, but its caption sat at x=170 — 45 units off, which is exactly
what reads as the drawing sitting left of its own heading. And that content started at x=10, a
10-unit margin, against the right half's matching 40-unit margin (860 to the 900 edge) — hugging
the canvas edge is the other half of "left-justified." Both fixed by shifting the whole left
group +30 (new span 40-270, centered 155, margin 40 to match the right) and moving both left
captions to that same x=155. The firewall itself — the concept the whole drawing turns on —
never had its own word in either half; added "Firewall" next to the per-site gap on the left
and once beside the solid wall on the right. */
function PerSiteControlPlanes({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const rowY = [110, 320, 530];
return (
);
}
/* ---------------------------------------------------------- DB — Platform overview architecture */
/* PlatformArchitectureDiagram — replaces HostStack (a generic design-system stock diagram) in
PlatformArchitecture (pages.jsx, Section DB). Dylan, 17 Sept: "the diagram model is a little
too generic... there's nothing about the diagram model that says this is how we do things...
section three and four of the control plane and agent model are not clear. Even claim two,
native hyperconvergence — hyperconvergence means you don't have to have a separate storage
appliance, you can just run a computer with basalt on it." Four specific claims, drawn
concretely instead of as a generic hypervisor-with-guests picture: one host runs compute and
storage together with no separate storage appliance beside it — drawn as an explicit, crossed-
out absent box rather than just leaving one out, the same "thing that never happens" idiom
DataCustody already uses; one global control plane reaches that host, captioned with region
independence; the host's own agent has a single outbound-only arrow, no inbound one; and the
four domains (compute, storage, networking, governance) are labeled as one list inside the one
host block, not as four separate boxes. Not wired into pages.jsx from here — PlatformArchitecture
there still calls HostStack directly, with its own TODO marking this as the intended swap for a
separate pass to make. */
function PlatformArchitectureDiagram({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const hostX = 90, hostY = 120, hostW = 180, hostH = 160;
const hostCx = hostX + hostW / 2;
const domains = ['compute', 'storage', 'networking', 'governance'];
const domainX0 = hostX + 24, domainY0 = 166, domainGap = 28;
const ghostX = 300, ghostY = 140, ghostW = 100, ghostH = 100;
return (
);
}
/* ------------------------------------------------------------------- BE — migration */
/* StagedMigration — replaces MigrationArc on the homepage. MigrationArc itself is untouched: if
live migration turns out to be a real, approved claim, it still belongs on the Migration &
evaluation page (see review.jsx's own suggestion). This is the sketch Dylan sent: stand up
alongside, validate side by side, migrate in stages — not a live-migration animation. */
function StagedMigration({ tone = 'paper', seed = 1, label, style }) {
const { Block, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const panel = (x, title, sub, children) => (
{title}
{children}
{sub}
);
const cluster = (x, accent2) => (
);
return (
);
}
/* -------------------------------------------------------------------- Compare pages — parity */
/* VirtualizationParity — Mike, wide-monitor review: every Compare page needs its own
illustration, showing that Basalt does the same commodity job as the competitor — the same
way, when both actually sit on the open-source KVM hypervisor (Proxmox, Nutanix's AHV, Scale
Computing's HC3 and HPE's own VM Essentials all publicly document this themselves), or a
different way that still lands at the same outcome (VMware's own ESXi kernel, Microsoft's
Hyper-V — neither is KVM). This only draws what each vendor's own documentation already says
the core actually is; it makes no claim about which migration is easier, which is the part
review.jsx's own RB/PC notes flag as not yet confirmed. One component, six call sites, so the
comparison reads identically everywhere instead of six hand-drawn variants. */
function VirtualizationParity({ tone = 'inverse', seed = 1, label, competitor, competitorCore, sameCore, note, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const colA = 16, colB = 284, colW = 120;
const coreY = 40, coreH = 40, vmY = 126, vmH = 46;
const vmRow = (x) => {
const innerW = (colW - 16) / 2 - 4;
const innerH = vmH - 16;
return (
{vmBars(Face, x + 8, vmY + 8, innerW, innerH, seed + x + 320, t.ink)}
{vmBars(Face, x + colW / 2 + 4, vmY + 8, innerW, innerH, seed + x + 340, t.ink)}
);
};
return (
);
}
/* ---------------------------------------------------------------- KB — Federal / DDIL edge */
/* DdilResilience — rebuilt from Mike's own drawing (KBV, 23 Sept HourPlus call, live-walkthrough
correction). The prior version drew the edge site and the control plane side by side with a
horizontal arrow between them, which is exactly what Dylan spent several minutes on the call
unwinding: "the control plane should probably be above the edge site... the edge site can see
the control plane... it's not moving in the same direction as time, it's like a cartoon panel."
His own sketch is a cloud (management) sitting above a box (the edge site), with only the
connector between them changing per panel — normal (connected both ways), degraded (severed,
edge keeps running on its own), reconnected (connected again, and synced). The edge box itself
never changes state across the three panels, matching his correction: "this box stays green the
entire time because it's operating... your blue box, it's fine." The "Recovery is easier" line
is his own closing point on the call — recovering from a dropped link is simpler with Basalt
than the admin work an ordinary vCenter-managed cluster requires once its own controller comes
back, so it's stated directly rather than left implied by the three panels alone. */
function DdilResilience({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
/* Mike, 24 Sept: "your cloud icon, I think, is just a little bit too large, and it's also not
hand-drawn. Why is that icon not hand-drawn yet? Everything else is hand-drawn." The prior
pass fixed the cloud's proportions but left it as a plain smooth SVG — the only shape
in this entire file not built from the Stroke primitive, so it alone had no hand-wobble.
First attempt traced it as a 12-point polygon; Mike, same day, on that result: "now that
they're hand-drawn, they look goofy" — a dozen hand-picked vertices read as sharp corners
once wobbled, not a rounded cloud. Rebuilt by sampling the ORIGINAL bezier curve's own six
segments (via cubicPts, 6-7 points each) at ~68% of its former size, so the silhouette stays
smooth while Stroke's jitter still gives it a sketched texture rather than a polygon's. */
const CLOUD_SEG = [
[[8.84, 26.52], [3.54, 26.52], [0, 22.98], [0, 17.68]],
[[0, 17.68], [0, 13.26], [3.54, 9.72], [7.96, 8.84]],
[[7.96, 8.84], [8.84, 3.54], [14.14, 0], [20.33, 0]],
[[20.33, 0], [25.64, 0], [30.06, 2.65], [31.82, 7.07]],
[[31.82, 7.07], [37.13, 7.07], [41.55, 11.49], [41.55, 16.80]],
[[41.55, 16.80], [41.55, 22.10], [37.13, 26.52], [31.82, 26.52]],
];
const cloudPts = CLOUD_SEG.flatMap(([p0, c1, c2, p1], i) => cubicPts(p0, c1, c2, p1, 6).slice(i === 0 ? 0 : 1))
.concat([[8.84, 26.52]]);
const cloud = (cx, cy) => (
[px + cx - 20.8, py + cy - 24])}
seed={seed + cx + cy} weight={1.4} ink={t.ink} />
);
const edgeSite = (cx, cy) => (
edge site
{/* Always-present check — the site is never in a bad state in any of the three panels,
only its link to the cloud above changes. */}
);
/* Mike, 23 Sept: "the word management is up against the edge of the cloud icon" and "your arrows
... are behind the boxes, they're too low, they're not centered." Regrounded the whole panel's
vertical rhythm off the bigger cloud above (cy 55 now, was 44) so "management" clears its
bottom edge with real room instead of sitting on it; the edge-site block moved down to match
(cy 100, was 92) so the connector between them actually spans the visual gap end-to-end
instead of stopping short partway down it; and {connector} now renders AFTER {edgeSite}, not
before, so its arrowhead paints on top of the block's own edge rather than underneath it.
Mike, 24 Sept: "lower [the edge site boxes] a little bit and give a little bit of space
between the... lines and arrows [and the box]." Moved the box down again (cy 112) and left
the connector's own tip short of it (104, not 100) instead of nearly touching, so there is
real air between the arrowhead and the block it points at. */
const panel = (cx, title, sub, connector) => (
{title}
{cloud(cx, 55)}
management
{edgeSite(cx, 112)}
{connector}
{sub}
);
const connectedLink = (cx, color) => (
{arrowHead(Stroke, cx, 104, cx, 77, 6, seed + cx + 11, color)}
{arrowHead(Stroke, cx, 77, cx, 104, 6, seed + cx + 12, color)}
);
const cx1 = 70, cx2 = 210, cx3 = 350;
return (
);
}
/* ------------------------------------------------------------------- LB — remote and resilient edge */
/* RestartClassHA — see DdilResilience above for why this exists and what it deliberately does
not claim. Draws exactly what the page's own copy states: synchronous replication, a restart
on the surviving node rather than a hot-standby failover, and nothing about server count or an
external witness — that specific architecture claim is still open per review.jsx's own LB
note.
Mike, 23 Sept, re-viewing his own reference (IMG_0037, LBV): "we gave you a very specific
illustration to follow, and you did not do that... I have no idea why you did that." The prior
version drew two separate 3D cubes per panel with a connecting arrow between them; his own
drawing is ONE box per panel, split into an A half and a B half by a single internal vertical
line — the physical pair of servers never separates or reconnects, only which half is purple
(primary, holding the workload) and which is grey (standby) changes. Rebuilt from a single
Face-built rectangle per panel instead of two Blocks, with the same purple/grey swap sequence
Dylan specified ("purple, grey" running → "grey, purple" failed over → "purple, grey" restarted)
now carried by the two halves of one box rather than by which of two boxes is filled in. Also
added the time axis Mike asked for on the same call ("there's a timeline... same horizontal
axis that says time" as DdilResilience's own), which this diagram never had. */
function RestartClassHA({ tone = 'inverse', seed = 1, label, style }) {
const { Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
/* Mike, 25 Sept call: "I don't like these arrows pointing up at it, I'm gonna have it remove
those." Dylan, same breath: "maybe drop it closer to time." The up-arrows below each box are
gone outright (not replaced), and boxY moved down (40 -> 70) so the panels sit closer to the
time axis instead of floating in the space the arrows used to occupy. */
const boxY = 70, boxH = 34, boxW = 80;
const splitBox = (x, aActive, bActive, seedBase) => {
const midX = x + boxW / 2;
return (
node anode b
);
};
const panel = (x, title, sub, aActive, bActive, mark, seedBase) => (
{title}
{mark && (
{mark}
)}
{splitBox(x, aActive, bActive, seedBase)}
{sub}
);
return (
);
}
/* ------------------------------------------------------------------ FB — Pricing & licensing */
/* Mike, 14 Sept: "Section FB on the pricing and licensing page should obviously have an
illustration." The one claim that section makes — per-core pricing climbs as the estate grows,
Basalt's own flat rate doesn't — is a line chart, not a hardware drawing, so this reuses the
same Stroke/Cap primitives every other diagram here does rather than forcing a Block-based
scene onto a concept that's really just two lines on an axis. The staircase's own step count is
illustrative, not plotted from a real pricing table — it draws the SHAPE of metered-per-core
pricing (it climbs in steps as more is added), not a specific vendor's actual curve. */
/* Mike, 16 Sept review: "your graph doesn't make any sense... you have basalt starting above
the first step. Basalt is way underneath the first step, and it doesn't move up." SVG y grows
downward, so a smaller y is HIGHER on the chart (more cost) — the flat line used to sit at
y=166, above (in y-terms, below in value) the staircase's own lowest step at y=174, reading as
MORE expensive than the cheapest point of per-core licensing, backwards from the claim. The
flat line now sits close to the x-axis (y=182, cheap, unmoving) and the whole staircase is
redrawn above it with real separation at every step, not just the first. Also moved the
"annual cost" axis label from floating well left of the axis line it's supposed to name (old
x=14 against the line's own x0=50) to sitting directly above that line instead — unambiguous
about which line it labels, matching how the x-axis label already sits under its own line. */
function FlatVsMetered({ tone = 'paper', seed = 1, label, style }) {
const { Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const x0 = 50, x1 = 400, yBase = 190, yTop = 20;
const steps = [[60, 160], [140, 160], [140, 130], [220, 130], [220, 95], [300, 95], [300, 55], [380, 55]];
const basaltY = 182;
return (
);
}
/* ------------------------------------------------------------- PB — VMware control-plane diagram */
/* Mike, 15 Sept — Triq V2 walkthrough. Donnie/Luigi were specific that the old VirtualizationParity
drawing (same-core-different-kernel) understates the real architectural gap with VMware: "the
big practical difference... is the fact that they have a control plane right next to every
cluster, and they have to — they don't have an option." "This diagram has to capture the essence
of distributed management complexity... a single basalt control plane, all of your clusters and
hosts" (Luigi). Left: three clusters, each with its OWN vCenter stacked directly on top of it —
the repetition is the point, not a coincidence of layout. Right: one basalt control plane, one
set of diverging lines reaching three clusters at once. Used only on the VMware Compare page —
the other five keep VirtualizationParity's same-or-different-kernel comparison, which is the
actual question on those pages; VMware's is a control-plane question instead. */
function ControlPlaneComparison({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Cap, Stroke, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
/* Mike, illustration audit: "cluster N" used to sit at y0+60, which lands inside the cluster
block's own vertical span (y0+40 to y0+72), not below it — the label rendered stamped on top
of the hatching instead of captioning it. Deriving the label from the block's own bottom edge
(clusterBottom + labelGap) keeps it a real caption regardless of block height, the same
pattern FleetTenancyMap already uses for its own per-region caption. */
const clusterBottom = (y0) => y0 + 40 + 32;
const labelGap = 16;
const vClusterY = [20, 128, 236];
const bClusterX = [286, 346, 406];
const lastLabelY = clusterBottom(vClusterY[vClusterY.length - 1]) + labelGap;
return (
);
}
/* -------------------------------------------------- NBV — Basalt controller, multiple clusters */
/* Dylan Conner, 21 Sept, on Enterprise virtualization Section NB: "Replace the current VMware
illustration with a Basalt controller managing multiple clusters. The drawing should not assert
that every VMware cluster requires its own vCenter." NB isn't a head-to-head VMware page — it's
the generalized enterprise case — so ControlPlaneComparison's specific "vCenter, every time"
claim didn't belong here even before this note. This is that diagram's own right half on its
own: just Basalt's side, no competitor asserted at all. */
function BasaltMultiCluster({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Cap, Stroke, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
{/* Mike, 23 Sept: "you centered the word basalt, you didn't center the word control plane, and
then your three clusters should be centered — it feels like they're pulled over to the
left." clusterX averaged to 180, not the viewBox's actual center (210), because the spacing
was measured from the left edge instead of around the middle; shifted the whole set +30 so
the three centers (90/210/330) land symmetrically around 210 with equal margin on both
sides. */}
const clusterX = [70, 190, 310];
return (
);
}
/* ------------------------------------------------------------- PF — the low-cost alternatives */
/* Mike, 17 Sept, HourPlus call: "Proxmox, Morpheus, OLVM — and you can pick a dozen others — put
them on one side of a firewall... and Basalt on the other side, and make it stand out that it's
in a class of its own. This is not the same approach as the other ones, even though they're as
inexpensive." The point isn't a price comparison (ALSO_CONSIDERING_POINTS/StatRow beneath this
already makes that one in words) — it's that "cheap" and "different architecture" are two
separate axes, and the low-cost incumbents only win the first one. Reuses the same wall styling
as PerSiteControlPlanes for visual consistency, but as a category divider here rather than a
labeled security boundary, so it isn't captioned "Firewall" the way that one is. */
function ClassOfItsOwn({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const names = ['Proxmox', 'Morpheus', 'OLVM', '+ a dozen others'];
const rowY = [30, 74, 118, 162];
return (
);
}
/* --------------------------------------------------------------- JB — MSP multi-tenancy */
/* Mike, 16 Sept review: "you must create an illustration for multi-tenancy for managed service
providers" — MSPClaims (pages.jsx) had a StatRow making the claim but no drawing at all. Donnie,
15 Sept: "real multi-tenancy means you have a super admin that can't see tenants' information...
click through their tenants, have one controller handle all of those individual clusters for
their customers." One controller reaching every customer's own cluster (the solid lines down),
and no line at all between customers (the red X in each gap) — the isolation claim is what's
drawn, not just the access claim FleetTenancyMap already makes elsewhere on the site.
Dylan Conner, 21 Sept: "The illustration should show provider administration across customer
clusters, with clear tenant boundaries. Remove 'can't see inside': customer isolation and
controller visibility are different concepts." The prior version marked every tenant box and
every gap between customers with a red ✕, telling one story — negation, what the controller
CAN'T do — when the actual claim is administration WITHIN a boundary. Dropped every ✕ and the
"cannot see what runs inside" caption; the Face border around each customer's own cluster now
carries the boundary claim by itself, with plain labels instead of a crossed-out one. */
function MSPTenancy({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const tenants = [
{ x: 20, name: 'Customer A' },
{ x: 170, name: 'Customer B' },
{ x: 320, name: 'Customer C' },
];
return (
);
}
/* ---------------------------------------------------- CBV / XBV — distributed site reach */
/* Mike, 16 Sept: oil & gas and telecommunications got real placeholder copy and "an accompanying
illustration" per his own instruction, and Luigi gave both the same underlying shape on the
call: oil & gas has "infrastructure all over the place" (the same story as Federal/DDIL, for a
buyer with the budget to fix it) and telecommunications has "infrastructure everywhere [the
network reaches]." One component, two site-label props, rather than two near-identical
drawings — the same reuse pattern VirtualizationParity already uses across the Proxmox and
Nutanix pages. Deliberately not MSPTenancy's shape reused verbatim: that one's ✕ marks are
about tenant isolation, a claim that doesn't apply here — this is reach across distance, not
isolation across customers, so the sites sit spread along a baseline instead of stacked under
one controller.
Dylan, 17 Sept, on Oil & Gas specifically: "I'd like the diagram here to reference making it
more clear that these might be in severe environments... platform, pipeline station,
refinery... floating oil platform or on a mountain or on the gulf away from town. Locations
that would not have good IT." The optional `terrain` prop (an array parallel to `sites`, values
'offshore' | 'mountain' | 'remote' | undefined per index) draws a small hand-drawn cue beneath
the matching site block via the module-level terrainCue() helper above. It defaults to
undefined — no cues at all — so Telecommunications' own call is unaffected unless another agent
explicitly opts a site in; oil rigs don't belong on a telecom tower site. */
function DistributedSiteReach({ tone = 'inverse', seed = 1, label, siteLabel = 'site', sites = ['Site A', 'Site B', 'Site C', 'Site D'], terrain, icons, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const baseY = 176;
const n = sites.length;
const spanX0 = 30, spanX1 = 390;
const xs = sites.map((_, i) => spanX0 + (spanX1 - spanX0) * (n === 1 ? 0.5 : i / (n - 1)));
const hubX = 210, hubY = 30;
return (
);
}
/* ------------------------------------------------------------------------- MBV — data custody */
/* Mike, 16 Sept: regulated industries (healthcare, legal — Luigi: "you don't trust your
infrastructure to someone else's care") also needed real copy and an illustration, but its
claim is not about distance or tenancy — it's about custody. What's drawn is the thing that
never happens rather than the thing that does: data crossing out to somebody else's
infrastructure. The boundary is your own care; the only line crossing it is the same
outbound-only management link every other page already establishes, and the crossed-out arrow
outside marks the access that stays refused.
Mike, 17 Sept: "illustration MBV makes no sense" — the original had one green arrow leaving
the boundary toward nothing labeled (it was never clear what "management out" actually reached),
crossed by a second, backwards, arrowless line sitting almost on top of it near a floating ✕
with no box of its own. Rebuilt with two separate, non-overlapping destinations on the outside:
a labeled "Basalt control plane" box the green arrow actually reaches, and a labeled "someone
else's data center" box below it that the red, ✕-marked line never completes — so each line now
has an actual place it's going (or not going) instead of ending in open space.
Dylan Conner, 21 Sept: "The illustration should show workloads and Basalt hosts within the
customer environment, with a clearly labeled management connection. Remove 'data never leaves
the boundary,' which implies control over application data movement. Also make the controller's
deployment location explicit so the drawing does not imply it must be hosted by Basalt." The
inside block was labeled "your data" — a claim about application data this diagram can't back
up — relabeled "workloads" to match what a virtualization platform actually manages. The bottom
caption dropped the "data never leaves" line entirely for one scoped strictly to the management
connection, and the outside box now states its own deployment is a customer choice, not a
given. */
function DataCustody({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Cap, Stroke, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
/* Mike, 21 Sept: "your text is not inside of the box... 'someone else's data center' or
'deployed wherever you choose' under the basalt control plane — those things are outside of
the boxes." Both right-side boxes were only 90 units wide (x=350-440), sized for the original
short labels this diagram shipped with; "deployed wherever you choose" and "someone else's
data center" are both meaningfully longer strings added in later passes, and nobody rechecked
them against the box width. Widened both boxes to 150 units and grew the viewBox to match, so
the longest label (the 6px subtitle, ~104 units wide) fits with real margin instead of running
out the right edge. */
return (
);
}
/* --------------------------------------------------------- MBV — one standard, both sides (new) */
/* SPEAKER_01 (Donnie), 23 Sept, on retitling Regulated industries to Critical Infrastructure and
Medical Industries: "we're built from the ground up for the most regulated industry, right?
That's the claim. Like good enough for government, good enough for you. That's the essential
claim... we are built from the ground up to be run by people who have things besides money to
worry about. You're also worried about meeting an objective standard of how you run your
network. We know what that's like. That's where we grew up." Mike, same call: "I'll come up
with an illustration... I'm gonna retitle regulated industries to critical infrastructure and
medical industries."
DataCustody above answers a different question ("does our data leave our own custody?") and
still runs on the Migration/evaluation-adjacent pages that ask it; it was never built to carry
this page's actual claim, which is about the standard itself being portable across sectors, not
about data boundaries. One operating standard is drawn once at the top, then reaches two
identically-drawn destinations below it — same box, same internal host block, same connector
style — so the equivalence is what the shape itself asserts, not just the caption under it. */
function OneStandardBothSides({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Cap, Stroke, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
/* Mike, 24 Sept: "pull your illustrations down a little bit, where you have government missions,
critical infrastructure, medical... the lines with the arrows that run from one operating
standard are underneath the text and that makes it confusing." Two separate problems, one
fix each: the whole branch (title, box, host block, caption) shifted down 14px for more air
under the top block; and the arrows, which used to run all the way to y=96 — past the title
text at y=82/92 — now stop at y=86, short of the title's new position (96) entirely, so the
diagonal line can no longer cross through the letters at any point along its length. */
const branch = (bx, titleLines, sub) => (
{titleLines.map((line, i) => (
{line}
))}
Basalt hosts{sub}
);
return (
);
}
/* ------------------------------------------------------------------- YB — enterprise compute scale */
/* Mike, 16 Sept, second pass: "you're going to have to go write the enterprise compute [...]
government page holder placeholder copy, and it's going to have to match [...] the page
structure of tactical DDIL and regional" — both of which pair their own claim with a purpose-
built illustration. Luigi's own description of this one: "true data center, big, lots of
racks." Deliberately not DistributedSiteReach (already carries the "many remote sites, one
control plane" idea for Oil & gas and Telecommunications): this is the opposite shape — one
facility, not many sites, so the racks sit tightly grouped under one roofline instead of spread
across a baseline standing in for distance, and one line reaches the whole row rather than
fanning out to each site individually.
Dylan Conner, 21 Sept: "Remove descriptions such as 'a real data center,' 'a closet with some
switches,' and 'the scale end of the same architecture.' This page should address enterprise
operational needs without restricting the customer to one facility. Group the illustration into
two labeled data centers with managed clusters beneath the Basalt controller. Avoid unqualified
'any scale' claims." The single-facility rack row is now two separate, independently labeled
data centers, each with its own small cluster of racks, both reaching the same controller —
showing multiple facilities instead of implying one big one is the ceiling. */
/* Mike, 21 Sept: "the rectangles that are underneath the words data center one and data center
two... a little bit offset to the left. Same with the lines above it." Block (design system)
draws a 3D box whose visual right edge extends past x+w by its own depth `d` — the floor plate
and the roofline strokes below were centered on `cx` using only the racks' front-face width
(ignoring that extra depth on the rightmost rack), so the racks' TRUE rendered footprint sat
noticeably right of where the floor and roof lines assumed center was, reading as everything
else being shifted left relative to the racks. rackXs is now generated from the group's actual
visual width (n racks + gaps + one rack's worth of depth on the right end) so it's centered on
`cx` by construction, and the floor/roofline width is derived from the same number instead of a
separately hand-picked ±55. */
/* Mike/Dylan, 23 Sept call: "you could even have data center one, two, and three... just to make
it more impressive... you could have the basalt controller go across the entire top." Two data
centers already made the "multiple facilities, one controller" point; a third plus a controller
bar spanning the full width of all three (instead of just sitting centered over two) makes the
same point read as scale rather than a minimum viable pair. */
function EnterpriseComputeScale({ tone = 'inverse', seed = 1, label, style }) {
const { Block, Face, Stroke, Cap, Sketch } = DS;
const { diagramTone } = Sketch;
const t = diagramTone(tone);
const rackW = 30, rackGap = 5, rackDepth = 6, rackCount = 3;
const groupW = rackCount * rackW + (rackCount - 1) * rackGap + rackDepth;
const rackXsFor = (cx) => {
const start = cx - groupW / 2;
return [0, 1, 2].map(i => start + i * (rackW + rackGap));
};
const dcCenters = [80, 210, 340];
const centers = dcCenters.map((cx, i) => ({ cx, name: `Data center ${i + 1}`, rackXs: rackXsFor(cx) }));
return (
);
}