AI image models are good enough now to land a brand mark in just a few minutes. The mark comes out as a raster PNG — beautiful and locked, but not yet in a shape you can actually ship.

A production identity needs vectors. It needs surface-explicit variants — on-light, on-dark, mono-black, mono-white — for the surfaces a brand actually lives on. It needs a favicon set with raster fallbacks for the browsers and OS-es that won’t render SVG at the favicon slot. It needs fills at the exact brand hex values, not the slightly-off versions a neural tracer hands you. And it needs a file size you can put on a web page without apologizing for it.

The path from raster to that production family looks short on paper. In practice it’s full of small mistakes that each cost some API credits and an hour of fumbling to figure out. The point of writing the pipeline down is that the second person to walk it shouldn’t have to learn the same mistakes the first one did.

For the cost of about an hour and $1.50–$2.50 in API spend, the following pipeline produces a complete primary-mark family: a primary on-light variant, a primary on-dark variant, mono-black, mono-white, a sigil, and the favicon set. Most of that hour is QC and variant generation rather than the API calls themselves.

When this pipeline applies

The starting state assumed here:

• A locked AI-generated primary mark as a raster PNG (gpt-image-2, Flux, Midjourney, whatever)

• A locked brand palette of 3–5 hex values

• An expectation of shipping production SVGs to a brand asset library

The pipeline does NOT apply if:

• The mark is destined for billboard-scale signage or embroidery — those need a designer cleanup pass in Illustrator on top of this output

• The mark is silhouette-only — Potrace handles those in one step, no neural tracer needed

• The mark only ever lives on one surface — just chroma-key a transparent PNG and skip vectoring

Tools

All command-line, all standard:

• magick (ImageMagick 7+) — flattening, chroma-key, color quantization

• rsvg-convert — SVG → PNG render for QC

• svgo — multipass SVG optimization (Node global)

• python3 for a short palette-snapping script (standard lib only)

• curl — for the Vectorizer.AI API

Subscriptions

The pipeline uses the Vectorizer.AI API. The cheapest API tier is around $13 CAD/month for 50 credits.

One trap worth flagging up front: Vectorizer.AI sells web-app and API subscriptions as separate SKUs at the same price. The web-app subscription gives unlimited browser uploads and zero API credits. Subscribing to the wrong one and then watching every API call 402 is a special kind of frustrating. Verify with the account endpoint before assuming API calls work:

curl -sS https://vectorizer.ai/api/v1/account \
  -u "$VECTORIZER_AI_APP_ID:$VECTORIZER_AI_API_SECRET"

The API plan name looks like vec_999m_50 (50 credits) with a non-zero credits value. The web-app plan name is unlimited_999m. If you see the second one, the API will not work no matter how many calls you make.

The pipeline

Eight steps, in order. A couple of them depend on what the earlier ones produced, so the order isn’t optional even if it looks like it.

Step 1 — Verify the source PNG has a solid background

This is one of the most expensive mistakes in the pipeline, and also one of the easiest to avoid. Vectorizer.AI’s neural tracer treats anti-aliased alpha-edge pixels as a distinct color category, and it emits a separate path for every band of partial transparency. If you feed it a chroma-keyed transparent PNG, the output will be 5,000+ paths and a 900 KB SVG that isn’t really shippable.

file path/to/source.png
# Want: PNG image data, 1024 x 1024, 8-bit/color RGB, non-interlaced
# AVOID: 8-bit/color RGBA  (the A = transparency)

If the source is RGBA, re-flatten against a solid color before tracing:

magick source.png -background "#1A0E0F" -flatten flat.png

The flatten color doesn’t have to be a brand color. Vectorizer.AI will trace it as one of the output colors, and you can either drop it from the SVG after or accept it as the “on this surface” variant.

Step 2 — Vectorize via the Vectorizer.AI API

curl -sS https://vectorizer.ai/api/v1/vectorize \
  -u "$VECTORIZER_AI_APP_ID:$VECTORIZER_AI_API_SECRET" \
  -F image=@source.png \
  -F mode=production \
  -F output.file_format=svg \
  -F processing.max_colors=5 \
  -F output.svg.version=svg_1_1 \
  -F output.svg.fixed_size=true \
  -o raw-output.svg \
  -w "HTTP %{http_code} | %{size_download}B | %{time_total}s\n"

A few notes on those parameters:

• mode=production — 1.0 credits, no watermark, unrestricted output. mode=test is free but embeds a 2,600-path watermark mesh that ruins visual QC. Test mode is only useful to confirm auth.

• processing.max_colors — set to one more than your palette size. For a 4-color palette set max_colors=5. Setting it equal to palette size will quantize the least-frequent color out. For pure mono sources use max_colors=2.

• output.svg.fixed_size=true — gives you a viewBox-locked SVG that scales predictably.

• output.svg.version=svg_1_1 — broader compatibility than svg_2_0, which matters for email clients and print pipelines.

Expect 70–130 KB output, 80–150 paths, 8–12 seconds per call. If you see 500+ KB or 1000+ paths, the source was probably transparent or has noisy edges. Re-flatten and try again.

Step 3 — Palette-snap every fill to exact brand hex

Vectorizer.AI’s output colors drift slightly from the source. A pure #FF2D87 accent will come back as #fc1e6a, plus a handful of near-cream variants from anti-aliased edges. LAB-distance snapping cleans this up deterministically.

"""palette-snap.py <input.svg> <output.svg>
Snaps every fill/stroke hex value to the nearest brand-palette color in LAB."""

import re, sys
from pathlib import Path

PALETTE = {
    # Edit per brand
    "#1A0E0F": "ink",
    "#F5E9D3": "paper",
    "#FF2D87": "accent1",
    "#8B1A2B": "accent2",
    "#FFFFFF": "white",
}

def hex_to_rgb(s):
    h = s.lstrip("#")
    if len(h) == 3: h = "".join(c*2 for c in h)
    return int(h[0:2],16), int(h[2:4],16), int(h[4:6],16)

def rgb_to_lab(rgb):
    r,g,b = (c/255 for c in rgb)
    def linear(c): return c/12.92 if c <= 0.04045 else ((c+0.055)/1.055)**2.4
    r,g,b = linear(r), linear(g), linear(b)
    x = (r*0.4124564 + g*0.3575761 + b*0.1804375) / 0.95047
    y = (r*0.2126729 + g*0.7151522 + b*0.0721750)
    z = (r*0.0193339 + g*0.1191920 + b*0.9503041) / 1.08883
    def f(t): return t**(1/3) if t > 0.008856 else (7.787*t + 16/116)
    fx, fy, fz = f(x), f(y), f(z)
    return (116*fy - 16, 500*(fx-fy), 200*(fy-fz))

PALETTE_LAB = {h: rgb_to_lab(hex_to_rgb(h)) for h in PALETTE}

def nearest(hex_str):
    lab = rgb_to_lab(hex_to_rgb(hex_str))
    return min(PALETTE_LAB, key=lambda h: sum((a-b)**2 for a,b in zip(lab, PALETTE_LAB[h])))

HEX_RE = re.compile(r'#[0-9a-fA-F]{6}\b|#[0-9a-fA-F]{3}\b')
src, dst = Path(sys.argv[1]), Path(sys.argv[2])
content = src.read_text()
stats = {}
def replace(m):
    orig = m.group(0).upper()
    if len(orig) == 4: orig = "#" + "".join(c*2 for c in orig[1:])
    snapped = nearest(orig)
    stats[f"{orig} -> {snapped}"] = stats.get(f"{orig} -> {snapped}", 0) + 1
    return snapped
dst.write_text(HEX_RE.sub(replace, content))
for k, v in sorted(stats.items(), key=lambda kv: -kv[1]):
    print(f"  {v:5d}  {k}")

Run it:

python3 palette-snap.py raw-output.svg snapped.svg

The script prints what it snapped to what. Eyeball it. If a near-charcoal color got snapped to your accent or vice versa, the palette has a gap or the source has AA noise. Tune max_colors and re-vectorize.

Step 4 — SVGO multipass compression

svgo --multipass --precision=2 snapped.svg -o optimized.svg

Expect 40–45% size reduction. SVGO merges multiple <path> elements into one path with M move-to jumps, so grep -c '<path' will misleadingly report 1. The render is identical.

Step 5 — Render to PNG and visually QC against the source

Don’t skip this step. Every pipeline run can introduce a regression that only shows up by eye, and the earlier it gets caught the cheaper it is to fix.

rsvg-convert optimized.svg -w 512 -o qc.png

Open the PNG. Compare against the source. Look for:

• Vanishing details (a cream-on-cream feature that disappeared into the background)

• Wrong-colored regions (a crimson zone rendered pink because palette-snap pulled it to the wrong neighbor)

• Missing paths (something got SVGO’d away)

• Bounding-box drift (the mark shifted in canvas)

If anything’s wrong, fix the source step — re-vectorize with different params, edit the palette dict — don’t try to hand-patch the optimized SVG.

Step 6 — Build the surface variants

A production family needs:

• <brand>-mark-on-light.svg — mark in dark on the brand’s light surface color, with a solid <rect> background baked in

• <brand>-mark-on-dark.svg — mark in light on the brand’s dark surface color, ditto

• <brand>-mark-mono-black.svg — single-color black, transparent background

• <brand>-mark-mono-white.svg — single-color white, transparent background

• Optionally: <brand>-mark-transparent.svg — the cleanest version, no background

The fast path: if your vectorized SVG uses class-based fills (class="u-cream", class="u-pink"), every variant is a one-line <style> swap plus a <rect> background. Path data stays identical across all five variants. Each file ends up around 11 KB because the path data is shared semantically.

If the SVG uses inline fill="#..." attributes instead, either run a regex pass once to convert them to classes, or make N copies and find-replace per variant. The first approach is much less work as soon as you need more than two variants.

Bake a <rect width="100%" height="100%" fill="#..."/> background into the on-light and on-dark files. It’s tempting to leave the surface color to the consumer’s CSS, but downstream consumers will eventually forget to set it, and the mark will vanish on the wrong surface when they do.

Step 7 — Build the favicon

The favicon is the one place in a brand system where prefers-color-scheme inside the SVG is the right abstraction. Browser chrome IS the surface. It changes when the user changes their OS theme. The favicon needs to follow it.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1024 1024">
<style>
  .u-cream { fill: #F5E9D3; }
  .u-pink  { fill: #FF2D87; }
  .u-bg    { fill: #1A0E0F; }
  @media (prefers-color-scheme: dark) {
    .u-cream { fill: #1A0E0F; }
    .u-bg    { fill: #F5E9D3; }
  }
</style>
<rect class="u-bg" width="1024" height="1024"/>
<!-- the rest of the mark paths -->
</svg>

Then generate the raster fallbacks at the standard sizes:

for size in 16 32 48 180; do
  rsvg-convert mark-favicon.svg -w $size -h $size -o favicon-${size}.png
done

Open the 16/32 PNGs and look at them.

Primary marks with internal detail — aviators, monocles, decorative hardware, grip wraps — rarely survive at 16–32 px. They tend to render as muddy pixel blobs at those sizes. There are three reasonable ways to handle that:

• Substitute a simpler mark at small sizes. If the brand has a sigil or monogram variant, use it for the 16/32 PNG fallbacks. Different SVG sources, same family. Document the substitution.

• Hand-redraw a 16-px variant. A dedicated favicon mark with the silhouette plus one feature.

• Accept a recognizable color blob. If the brand’s color signature is distinctive enough, even a muddy 16-px favicon reads as “that brand” by hue alone. Document it as a deliberate tradeoff.

Step 8 — Write the README

Save a README.md next to the production SVG family that documents:

• The variant matrix — file → which surface → which use case

• The locked palette hex values

• Provenance — source PNG, generation params, scripts run

• What’s deferred and why (wordmarks composited from real type instead of traced, designer cleanup pass pending)

A future agent or designer landing on the directory cold will save half a day reading this rather than reverse-engineering it.

Gotchas worth pre-reading

These are the gotchas that have actually cost time in practice. Most of them only bite once, but each one tends to cost some real time the first time you run into it.

The subscription mix-up. Vectorizer.AI sells web-app and API plans that look almost identical, cost the same, and sit side-by-side on the pricing page. The only reliable way to tell which one your account ended up on is to hit the account endpoint and read the plan name back. Skipping that check usually shows up as every API call returning 402, until it eventually clicks that the wrong subscription is the one that got bought.

Transparent PNG fragmentation. Feeding a chroma-keyed transparent PNG into the tracer tends to produce something like 5,000 paths and a 900 KB SVG that isn’t really usable in production. The neural tracer treats every band of anti-aliased halo as a distinct color and emits a separate path for each one. About three credits is the going rate for learning that lesson, so the safer move is to always flatten against a solid color before tracing.

max_colors quantization. If you set max_colors equal to your palette size, the API will quantize the least-frequent color out of the output entirely. A crimson zone can come back as a hot pink, and the snap script in Step 3 can’t recover what was never traced in the first place. The safer default is to set max_colors to palette size plus one and let palette-snap clean up the drift afterward.

Wordmarks traced as polygons. If the source PNG has text rendered into it — a “PROPER NAME LTD” lockup beneath the mark, for instance — Vectorizer.AI will trace each letter as a polygon. Traced letterforms muddy at small sizes in ways that look unprofessional even before anyone can articulate why. The fix is to strip the wordmark paths from the SVG and re-add the wordmark as a real <text> element with the actual font, composited into a lockup at the use site.

The fast way to strip them: each wordmark letter has a transform="translate(X,Y)" where Y falls inside a narrow band — say 800–920 for letters along the bottom of a 1024-pixel canvas. A regex over that Y range removes them in one pass.

pattern = re.compile(
    r'<path\b[^>]*?\btransform="translate\(\s*[0-9.]+\s*,\s*(?:8[0-9][0-9]|9[01][0-9])\s*\)"[^>]*?/>',
    re.DOTALL,
)
cleaned = pattern.sub('', svg_content)

Adjust the Y range for your canvas size and wordmark position.

Primary mark doesn’t survive 16–32 px. Covered in Step 7. Use a simpler sigil at small sizes, and document the substitution in the README so the next person knows the favicon and the primary mark aren’t drawn from the same SVG source.

What the pipeline gives up

Vectorizer.AI’s output is about 30× cleaner than vtracer’s on the same source — one unified silhouette vs. 31 fragments — but it is still not anchor-minimized. A typical Vectorizer.AI mark has 130–150 anchors where a hand-cleaned version would have 40–60. At digital sizes and most physical sizes this is invisible. At billboard scale, storefront signage, or embroidery runs above ~100 units, the lumpy bezier curvature shows.

The pipeline as documented produces digital-grade and most-physical-grade output. If the brand commits to a 30-foot sign or an embroidery run of meaningful volume, add a designer cleanup pass on the primary mark in Illustrator. Budget 30–60 minutes per mark, around $100–150 for a freelance designer.

Worked example

Imagine a fictional brand Meridian, a wayfinding studio. Mark: a stylized compass rose. Palette: 4 colors.

PALETTE = {
    "#1A2540": "navy",
    "#D9A857": "gold",
    "#F0E6D2": "paper",
    "#0A0A0F": "ink",
}

The run:

# 1. Verify source
file meridian-compass.png
# PNG image data, 1024 x 1024, 8-bit/color RGB — good

# 2. Vectorize
curl -sS https://vectorizer.ai/api/v1/vectorize \
  -u "$VECTORIZER_AI_APP_ID:$VECTORIZER_AI_API_SECRET" \
  -F image=@meridian-compass.png \
  -F mode=production \
  -F output.file_format=svg \
  -F processing.max_colors=5 \
  -F output.svg.version=svg_1_1 \
  -F output.svg.fixed_size=true \
  -o meridian-raw.svg

# 3. Palette snap (edit PALETTE dict in the script first)
python3 palette-snap.py meridian-raw.svg meridian-snapped.svg

# 4. SVGO
svgo --multipass --precision=2 meridian-snapped.svg -o meridian.svg

# 5. QC
rsvg-convert meridian.svg -w 512 -o /tmp/qc.png
# Open qc.png, compare to source. Looks correct? Continue.

# 6. Build surface variants — duplicate file, swap <style>
#    Each variant becomes meridian-on-light.svg, meridian-on-dark.svg, etc.

# 7. Favicon
rsvg-convert meridian-favicon.svg -w 32 -h 32 -o meridian-favicon-32.png
# 32-px favicon reads as a compass rose, not a blob: ship it.
# Otherwise substitute a simpler sigil at 16/32.

# 8. README — document the variant matrix, palette, provenance.

For the cost of around an hour and 4–8 API credits ($1–2 USD), you end up with a primary mark, a sigil, a horizontal lockup, four surface variants, and the full favicon set.

Recommended directory layout

<brand>/svg/
├── production/
│   ├── primary/
│   │   ├── <brand>-primary-on-light.svg
│   │   ├── <brand>-primary-on-dark.svg
│   │   ├── <brand>-primary-mono-black.svg
│   │   ├── <brand>-primary-mono-white.svg
│   │   └── <brand>-primary-transparent.svg
│   ├── sigil/
│   │   ├── <brand>-sigil-on-light.svg
│   │   └── <brand>-sigil-on-dark.svg
│   ├── horizontal/
│   │   └── <brand>-horizontal-on-dark.svg
│   ├── favicon/
│   │   ├── <brand>-favicon.svg
│   │   ├── <brand>-favicon-16.png
│   │   ├── <brand>-favicon-32.png
│   │   ├── <brand>-favicon-48.png
│   │   └── <brand>-favicon-180.png
│   └── README.md
└── vectorizer-ai/
    ├── raw/        # untouched API output
    ├── snapped/    # palette-snapped, pre-SVGO
    ├── optimized/  # SVGO'd, ready to copy to production/
    └── _failed-*/  # quarantined failed runs

Keep the working files in vectorizer-ai/ — useful for forensics and re-runs. Don’t import from there at use sites. Always import from production/.

Closing

The thing that makes this pipeline work isn’t any single step on its own. It’s the order, combined with knowing which mistakes cost real money along the way. Most of that cost gets paid by the first person to walk through each gotcha, and the point of writing it down is that the second person shouldn’t have to.

For the cost of about an hour of focused work and a couple of dollars in API spend, the pipeline produces a working brand-mark family that includes a primary mark, a sigil, a horizontal lockup, four surface variants, and a full favicon set. Worth knowing about, if you’re going to be doing this kind of work more than once.

There were a few years where I followed the Docusaurus project closely. I relied on it to make shipping software documentation relatively easy.

Another tool I adored was Kapa.ai - as close to a “drop-in-and-go” AI developer assistant as you could get.

I relied on them because they were tried and tested purpose-built tools with decent communities supporting them that offered 90-95% of the functionality I needed without me having to build anything myself.

And to be clear, there is no way 1 person could build and maintain custom built systems like that.

At least… that’s how it used to be…

I would say the real deep shifts in how we work started around January and February of 2026.

And then last month, April 2026, it became obvious that the scales had completely shifted.

The golden rule that a company should only R&D its own product and source whats already built for auxiliary systems, at least when it comes to software, has crumbled.

I no longer have to settle for compromises when stringing already-built-tools together.

We have stepped into a world, where information tools can, will, and should be built on-demand for the circumstances and situations at hand.

Last month, it took just 2 days to rip out both Docusaurus and Kapa.ai and replace it with a completely custom built system that makes 0 compromises on desired functionality and level of automation.

A validation harness provides assurances that our information assets are in better shape than ever.

At the moment, you still need someone with software engineering experience to steer the iterations is takes to produce something scalable, reliable, and robust. But that gap is diminishing quickly.

At 6am, the harvest agent wakes up and crawls every source I’ve pointed it at — local news sites, organization pages, RSS feeds. It pulls everything football-related into a staging table and tracks which sources keep delivering and which ones have gone dry.

At 7am, the curator agent reads everything harvested in the last 26 hours, checks it against every story ever published — all-time deduplication — and asks Claude Sonnet to pick the single best story. The editorial agent constraint narrows it down to one.

At 8am, the broadcast agent reads today’s published digest and sends it out via email.

Once a week, a separate discovery agent goes looking for new sources. It searches the web, checks RSS feeds on organization sites, and uses a small language model to score whether each candidate is actually relevant. Good ones get added to the crawl list automatically.

I don't touch it. I don't even know what the story is until I read my own email.

It’s Pitch Digest — the editorial layer of PitchRoots, a community football information platform I’ve been tinkering with. One story per day. No feed. No noise.

I built it because I don't know anything. My son plays football in Spruce Grove and I always feel like I am disoriented with the broader Edmonton football ecosystem — how Tiers work, which clubs cater to which players, and when tournaments and training programs kick off. I built Pitch Digest to keep me in the loop about football related people, places, and events.

Pitch Digest is a four-stage pipeline. Each stage is its own agent, running on its own schedule. Four agents. Four cron schedules. Zero human intervention on a normal day.

What makes this reliable enough to leave it unattended?

If you've ever built something like this — a multi-step workflow where each step calls an API, writes to a database, or invokes an LLM — you know the failure mode. Step three fails. You retry the whole thing. Step one re-crawls the web. Step two re-processes everything. Your LLM bill doubles. Or worse: step three partially completes, you retry, and now you've got duplicate data.

The AI part works. The plumbing breaks constantly. Network timeouts. Rate limits. Cold starts. Partial writes. Every step is a new opportunity for the whole thing to fall apart.

And this is a daily pipeline. If it breaks on Tuesday and I don't notice until Thursday, that's two days of silence.

I outsourced all of that stress to Resonate.

Resonate is a durable execution engine. It tracks the progress of each step in a workflow and guarantees that if something fails, it picks up exactly where it left off. From the failed step, not the beginning.

Each agent is a generator function. Every step yields a durable checkpoint.

The curator agent, for example, has five steps: check if a digest was already published today, load the recent harvest, load the dedup list, ask Claude to pick a story, and publish it. Each of those steps is individually durable. If the LLM call in step four times out, Resonate retries step four. Steps one through three don't re-execute — their results are already stored.

On resume, completed steps replay instantly from server state. No re-execution, no duplicate writes. The generator pattern makes this natural — you write your workflow as a straight-line sequence of steps, and the durability layer handles the rest.

It spins up. It processes work. It spins down.

These agents run on Supabase Edge Functions — serverless, pay-per-invocation. Resonate's HTTP-push mode sends execution callbacks to each function endpoint. The agents don't poll. They don't hold connections open. They wake up, do their work, checkpoint progress, and go back to sleep.

The whole thing costs almost nothing to run. Four functions, four cron triggers, a few LLM calls per day. The infrastructure matches the workload: bursty, short-lived, cheap at rest.

Everything can be serverless because Resonate handles the state. All the durability, progress tracking, and retry logic lives on the Resonate server. The functions just do work and yield results.

And Resonate offers a great observability.

Every promise in Resonate has a state — pending, resolved, rejected — along with its input, output, timestamps, and its position in the call hierarchy. That's not logging I added. That's just what durable promises are. The execution history is the observability layer.

This is the call graph for a single morning's pipeline run. Source Harvest fans out into individual scout promises — one per source URL. Each scout shows whether it found new content or came back empty. Green means it delivered. Red means the source was down or had nothing new. The pipeline flows left to right: harvest → curator → corpus librarian → broadcast. Every node shows its duration.

I didn't instrument this. I didn't add tracing spans or wire up OpenTelemetry. The promise tree is the trace. Resonate tracks every function invocation as a promise in a parent-child hierarchy, so the call graph builds itself.

The dashboard pulls from the same promise data. Today's published story at the top. Pipeline status showing whether each agent succeeded, failed, or hasn't run yet. Source health tracking which of the 25 sources are producing and which have gone dry — so I can see at a glance if a source needs to be dropped or investigated.

With most pipeline architectures, you'd bolt on a separate observability stack — custom dashboards, log aggregation, the works. Correlation IDs, trace contexts, status pages. A whole second project.

With durable promises, the execution model itself is queryable. Every promise has a known state. Every parent-child relationship is tracked. You just read the data that's already there.

The hard part of an AI editorial pipeline isn't the AI. Claude is genuinely good at picking stories and writing summaries. The hard part is everything around it — making sure the harvest actually ran, making sure a failed broadcast doesn't silently eat the whole day's output.

Durable execution turns those problems from "things I have to monitor and manually fix" into "things the system handles."

The pipeline has been running for weeks now. I check in occasionally. It just works.

That's the bar for anything I want to run unattended. Not "it works when everything goes right." It works when things go wrong, and I don't have to know about it.

And the best part? Here are four real headlines my own tool brought me in its first week:

• Alberta Communities Invited to Bid on Hosting Canada Soccer National Championships Through 2029

• Spruce Grove Soccer Hosting Free Grassroots Coaching Courses This Month — Spots Still Available

• Alberta Earns Extra U17 Girls Spot at Canada Soccer Youth National Championship

• Women’s Football ⚽ Takes the Big Screen: ‘The Pitch’ Screens in Edmonton This Tuesday

I built this to learn about the community my kids play sports in. And It's working!

Alberta publishes an extraordinary amount of data about its oil and gas industry.

Petrinex makes the volumetrics for every well in the province available as a public download — operator, formation, volumes, injection, disposition — monthly, going back to 1962, free, no login. It’s one of the more open production datasets of any major oil jurisdiction. Texas publishes a lot too, but Alberta’s is cleaner at the well level.

About 8% of Alberta’s mineral rights are freehold — privately owned rather than Crown. A further ~10% is federal (national parks, First Nations reserves). The remaining ~81% belongs to the province.

On freehold land, royalties from production flow to whoever owns the minerals underneath rather than to the Crown. Most of that ownership is corporate — railways (CN is one of the largest freehold mineral owners in Alberta, a holdover from a 19th-century land grant), royalty trusts like Prairie Sky and Freehold Royalties, religious organizations, family trusts. Roughly 10% of freehold mineral rights are held by individuals.

The production side of this — what comes out of the ground — is, as above, fully public. The ownership side is not. There is no public registry of freehold mineral rights owners or freehold royalty recipients in Alberta. You can pay Land Titles to pull a certificate of title for a specific legal description and see one owner, but there is no name search, no bulk dataset, no aggregated list. Commercial vendors like geoLOGIC and Enverus compile this from title abstracts for industry clients, but that’s a paid private product, not a public one.

The province itself has the data. It has to. Alberta levies a freehold mineral tax under the Freehold Mineral Rights Tax Act, assessed annually, billed by name to every owner whose share is worth more than $100. The assessments come off the mineral certificate of title. So somewhere in the Alberta Energy ministry there’s a complete list of freehold royalty recipients with names, addresses, and taxable values. That list isn’t published, and publishing it would require legislative authorization because the contents are personal information under FOIPP — the same kind of legislative act BC and Quebec passed when they built their beneficial ownership registries. No comparable bill has been tabled in Alberta.

The Non-Crown Mineral Ownership dataset, which Alberta does publish on open.alberta.ca, is a spatial file showing where in the province the mineral rights are non-Crown — polygons covering every patch of freehold and federal land. The geometry is there. The owner names are not. So the public version of the data answers “where are these rights” but not “whose are they.”

So, that’s the observation. Production data is exceptionally open. Ownership data, on the same wells, is structurally not. Both halves are deliberate — one is published as a matter of regulatory routine, the other is held back as a matter of privacy law. They’re not in tension exactly. They’re just an unusual pair of choices to find sitting next to each other.

I’m wary of reading too much into this as it might be less unusual than I think — Texas and Oklahoma freehold ownership is similarly opaque, and FOIPP-style protections on tax rolls are normal across Canada. It might also be more unusual than I think, in the sense that the production transparency really is unusually deep and the contrast really is unusually sharp.

If you work in Alberta land, freehold royalties, or mineral title abstracting and I’ve gotten any of this wrong — the percentages, the mechanism of the freehold mineral tax, the availability of any registry I missed — I’d like to know. The post is an observation, not a conclusion, and I’d rather correct it than defend it.

Have you read this? Hanging Promises for Control Flow.

So, if I understand it correctly, you’re inside a serverless function. You hit a step you can’t finish in this invocation. You need to get the user’s async function off the stack without throwing — because user try/catch might swallow the signal. So you await a promise that never resolves. Function suspends, process gets torn down, GC cleans up the frame, fresh invocation replays from the top using a memoization map of finished steps.

Clever, though isn’t this a workaround for a problem that only exists because suspension isn’t a first-class thing the runtime owns?

Seems like the whole maneuver leans on a property of the language’s runtime, where each language would require its own version of the trick with its own caveats.

I currently work at where we are betting that suspension shouldn’t be a clever thing the runtime sneaks past user code — it should be a protocol.

Coincidentally enough, the protocol calls for a durable promise that lives outside any single process, or any single language.

When a function awaits a durable promise, the runtime parks the computation. Promise resolves — same process, different process, one that doesn’t exist yet — computation comes back. No exception to dodge, no GC trick to lean on. The await (or in the current Resonate Typescript SDK version its yield) means what it says.

If that’s right, the hanging-promise technique is a great answer inside one language’s constraints, but Resonate is making the same problem moot one layer down by pinning the answer to a protocol instead of a runtime.

If you think I’ve got something backwards, tell me.

The vibe in "vibe coding" is the developer's intuition about what the code should do, how it should fit together, and when something's off.

Not the agent, or the model. Not your keyboard. The vibe is you.

I've been shipping software for 15 years — tech support, devrel, docs, product, engineering, startups that made it, startups that didn't. When I sit down with Claude Code now, I'm not just prompting an AI to write or build something for me. I'm compressing 15 years of pattern recognition into a structured environment where an AI can actually be useful.

That distinction matters. And I think most of the "vibe coding" discourse misses it completely, though often humorously.

The real magic happens before Claude writes any executable code.

By the time I say, “hey Claude, build me a dashboard”, I've already put together rules to follow, skill directories, and decision structures that Claude reads at the start of every session. Every project has an AGENT.md — a structured document that tells any AI agent exactly what the project is, what the stack looks like, what the architecture rules are, and what not to break. Above that, a workspace-level orientation file maps every project, defines data boundaries, and enforces privacy rules. Below that, a knowledge layer — domain-specific documents covering everything from data source registries to privacy regulations to tax law to investment frameworks, etc.

The AI doesn't guess. It reads. Every new Claude session starts fresh — no memory of yesterday — but within 30 seconds it has full context and is capable of producing quality output.

In other words, my 15 years of experience is now applied to the structure that makes Claude’s output predictable in quality.

And it's the same idea all the way down.

This pattern — write a structured spec, then generate the output — isn't just how I work with Claude Code. It's the same principle behind what we're building at .

Resonate is a durable execution platform. Instead of hand-writing server components for every possible deployment topology, we wrote a formal protocol specification. Language-agnostic. Transport-agnostic. Storage-agnostic. Then we generate the components from the spec.

Need a server targeting Postgres + HTTP? Generate it. Need one for Cloudflare Workers + D1? Generate that. Every line of code exists because your stack needs it. Nothing else ships.

The parallel is almost too clean: I don't hand-write code for each project from scratch anymore. I write structured context — rules, skills, architecture docs — and let Claude generate the implementation. Same mentality. Specify the constraints, generate the output, validate against the spec.

In both cases, the quality of the output is determined by the quality of the specification. Garbage spec, garbage code. Precise spec, precise code. The generation step is the easy part.

Fresh instances and structured workspaces are simple but key aspects to quality Claude usage.

One thing people don't realize about working with Claude Code: every session is a blank slate. The model doesn't remember what you did yesterday. It doesn't learn your preferences over time. Every conversation starts from zero.

That sounds like a limitation. It's actually a usable feature.

Because every session is fresh, you're forced to make your context explicit. You can't rely on "Claude knows what I mean." You have to write it down. The rules, the architecture, the boundaries, the patterns — all of it lives in files, not in your head.

And once it's in files, any agent can read it. Not just Claude. A CI bot. A code review tool. A new team member. The structured workspace becomes a unique product of its own.

I spin up fresh Claude instances for specific tasks all the time. One for frontend work, reading the component library docs. One for data pipeline work, reading the data source registry. One for financial modeling, reading the tax reference corpus. Each one gets exactly the context it needs and nothing it doesn't.

The workspace is the brain. Claude is the hands.

If you're new to programming and you're vibe coding, you're probably generating code you can't fully evaluate. You'll probably accept a function that works but scales quadratically because you've never been burned by that. You'll probably let the AI set up auth in a way that's fine for a tutorial and catastrophic in production.

That's not a reason to stop. It's a reason to build your own pattern library as you go.

Every time Claude generates something you don't understand, that's a learning opportunity you're either taking or skipping. The developers who use AI to learn faster will end up with great instincts — just compressed into fewer years. The ones who use AI to avoid learning will plateau at "can generate code, can't evaluate code."

Velocity comes from having pre-built component libraries, a clear architecture, and an AI that reads the entire project context before writing a line.

One danger for experienced devs isn't going too slow. It's going so fast that everything feels worth building. The cost to produce software has collapsed for everybody. Which means speed isn't the differentiator anymore. Judgment is. Knowing which direction to go is what matters.

The vibe has always been you — about knowing what to make, how it should fit together, and when something's off. AI has just become fast enough to match whatever level of that you bring.

I see it in engineering discussions, cultural debates, even in personal growth.

Here's the paradox:

Intertwingularity is real. Knowledge doesn't sit in neat categories. There are no absolute definitions or rigid boundaries. Everything flows, shifts, and overlaps. The world is messy, fluid, and in constant motion.

Yet, as human beings, we depend on models and definitions. Our ability to communicate, teach, and learn hinges on structure—on drawing lines, labeling things, and following rules. Without these models, society can't function.

This contradiction echoes the Dreyfus Model of Skill Acquisition.

According to the model, beginners need clear rules to operate. They follow step-by-step instructions because they lack the experience to interpret complexity. But as they gain mastery, their intuition grows. Experts don't follow rigid instructions—they feel what to do. Their actions are shaped by context, not checklists.

I’ve seen this in software engineering. Concepts like “durable execution” “event-driven architecture,” or “serverless” are abstract and often fluid in practice. But to discuss them, we need shared mental models. We define things like “pure functions” or “side effects” not because they exist in perfect clarity, but because without these definitions, communication becomes impossible. A beginner might take these models literally. An expert knows they’re just tools—useful simplifications to help navigate complexity.

This paradox explains many individual and societal disagreements.

Take politics. Experts often speak in nuances. But the public—understandably—wants clarity. Politicians exploit this tension. They weaponize simplicity, offering rigid models that feel safe, even if they mislead. They use the paradox to win arguments, votes, or influence—often at the expense of truth.

And yet, we need those simple models.

Most of us are beginners in many areas of life. That's not a flaw—it's just reality. Society needs frameworks and definitions to function. Teachers can't educate without them. Businesses can't operate without clear processes. Even something as basic as a map requires us to define what a “road” is and where it begins and ends.

Without definitions, mental models collapse. And when they do, communication breaks down. Education fails. Society stumbles.

But those same models create tension. Experts may find them limiting. Beginners may find them confusing. And both may talk past each other without realizing why.

As long as we're human, we'll live with this paradox.

We need structure to grow, and we need to outgrow that structure to master.