Here’s a simple Bongard problem, created by Mikhail Moiseevich Bongard:

And here’s a trickier Bongard problem, created by Douglas Hofstadter:

I first learned about Bongard problems while reading Gödel, Escher, Bach, when Hofstadter introduced them in his chapter Artificial Intelligence: Prospects. I’ve returned to Hofstadter’s puzzles before, but Bongard problems are especially interesting because he used them to imagine, in 1979, what a visual reasoning program might look like:

First, he imagined a preprocessing stage that detects salient features that map to a mini-vocabulary of known concept terms like, line segment, or curve, or horizontal. From there, preprocessing applies its knowledge of elementary shapes to get to terms like, circle, or right angle, or vertex. There’s a resemblance here to what we now call representation learning. In image classifiers built as convolutional networks, the network learns internal representations useful for discriminating images, though as distributed numerical representations rather than as tidy vocabulary of named concepts. And CLIP is an especially interesting modern comparison because it learns image and text representations in a shared space, allowing natural-language descriptions to refer to learned visual concepts.

At this point in Hofstadter’s imaginary program, the picture is “understood” at the basic level of mapping input images to labels. The next stage is a search for high-level descriptions about the features. The program “looks around” to spot descriptors like to the right of, or perpendicular to, or evenly spaced. It can also build descriptions of descriptions, looking for regularities across the ways individual images have been described. There’s a resemblance here to modern work on relational reasoning, where models try to represent not only the objects in an image but also the relationships among them.

But simply generating more descriptions doesn’t solve a Bongard problem. The program also has to decide where to focus and which kinds of properties to filter for. A description can be perfectly true and still be useless for distinguishing the two sides. The right abstraction may only become visible after comparing several images, changing what seems important, and returning to an earlier description with a different idea of what to look for.

Hofstadter suggested various approaches and heuristics for making that search less brittle. He imagined templates and sameness-detectors that could trigger when several examples began to converge on the same description. There’s a loose modern parallel in some approaches to meta-learning, where models learn a space in which examples can be classified by their distance from a common prototype. He also suggested a semantic net in which “all the known nouns, adjectives, etc., are linked in ways which indicate their interrelations.” That sounds a lot like word embeddings.

Importantly, Hofstadter didn’t want early concepts or hypotheses to be rigid. An idea that didn’t quite fit might be weakened, modified, or allowed to slip toward a related concept rather than simply discarded. A shape might be treated as a rough instance of something it doesn’t satisfy exactly, or a group of objects might become a single higher-level object once the problem suggests looking at it that way. There’s a connection here to analogical reasoning, where representations of relationships need to be flexible enough to map across different situations. More broadly, Hofstadter’s program depends on representations remaining tentative enough that higher-level hypotheses can change how the underlying images are described.

The chapter continues to dig into more layers of what this Bongard problem-solving program might require, and how it maps to various forms of recognition, grouping, filtering, and focusing. It’s not the only place in GEB where Hofstadter’s ideas map strangely well onto modern AI, but here he keeps circling two important assertions:

These fascinating problems are intended for pattern-recognizers, whether human or machine.

and

the skill of solving Bongard problems lies very close to the core of “pure” intelligence, if there is such a thing.

One of the most common dismissals of modern AI is that these systems are “only” statistical pattern matchers, with pattern recognition placed on one side of a line and genuine reasoning or intelligence on the other. That distinction remains very much alive in arguments over what today’s “reasoning” models are actually doing. But Hofstadter was describing pattern recognition while simultaneously placing it near the core of intelligence.

Hofstadter was clear about what he meant by a “pattern-recognizer.” His pattern-recognizer has to decide what in an image matters, describe relationships among its parts, compare examples, discard true but irrelevant observations, form tentative hypotheses, and sometimes revise the concepts it is using when they don’t quite fit. Eventually it has to find a pattern that isn’t contained in any one image, but exists across the collection.

Taken this way, “pattern matching” doesn’t tell us very much about whether a machine is intelligent. It describes a family of computations whose limits depend on what kinds of patterns can be found, how abstract those patterns can become, and whether they can be recognized in situations unlike the ones that came before. By the time you assemble everything his Bongard problem-solving program is supposed to do, it becomes surprisingly difficult to say where pattern recognition ends and reasoning begins. Researchers are still using Bongard problems to probe this boundary.

Today’s frontier models are not perfect at solving Bongard problems (neither are humans), but they’re also capable of finding unintended solutions.

I gave BP 155 (above) to GPT-5.6 Sol (High), and it quickly offered a solution:

This, of course, is not Hofstadter’s intended solution, but it appears to be a valid solution nonetheless. One is global and quantitative, the other local and categorical. The examples in the problem don’t distinguish between them.

I also gave the problem to Claude Fable 5 (Max), and it produced two incorrect answers:

Both of Fable’s answers are plainly false. There are clear angles among the left set, and the left set contains counterexamples with disconnected strokes. In Hofstadter’s terms, the error is at the preprocessing stage; its descriptions of the images contain features that simply aren’t there. His architecture invites top-down pressure on those descriptions, since restructuring and slippage depend on it. But that makes it important to keep checking revised descriptions against the image itself, or a bad early description can turn into fabricated evidence.

I expected both models to regurgitate a “known” answer from pretraining, and it was interesting that neither did. But I still wanted a test I could be certain hadn’t appeared in their training data, so I made a brand new Bongard problem by hand:

Can you solve it?

GPT-5.6 Sol (High) spun for about three and a half minutes and found the solution. Claude Fable 5 (Max) worked for about fifteen minutes and also got it right.

Sol picked up that the lines suggest a geometric rule, but ultimately that the relevant description is numerical. A solver has to count the dots on either side, compare those counts across the examples, and notice the relation shared by the left set. That looks a lot like the process Hofstadter was describing. It has to generate possible descriptions, decide which information matters, and revise the representation until the distinction becomes visible.

Both models solved my new problem, but I don’t think that settles whether Sol or Fable is reasoning. Nor do their earlier results rule it out. Fable’s answer to BP155 builds a coherent argument on a visual description that is simply false. Sol’s answer was unexpected, but may not be an error at all. Neither outcome tells us that reasoning was absent.

Still, “only a pattern matcher” starts to feel like a weak dismissal. In my problem, recognizing the pattern required choosing what to attend to, moving from geometry to number, comparing examples as a set, and finding a relation in a problem the models had never seen. If all of that falls under pattern matching, then the phrase leaves open much of what we care about when we ask whether a system is intelligent.

If you want to try more Bongard problems yourself, Harry Foundalis maintains a wonderful Index of Bongard problems, with hundreds collected from Bongard, Hofstadter, Foundalis, and others. There’s also the sprawling On-Line Encyclopedia of Bongard problems.

Bongard problems are a fascinating way to investigate how much abstraction and reasoning can fit inside what we call “pattern recognition,” and how little agreement we have about where those categories begin and end.

This week a physical magazine showed up at my door. It has a cover, an editor’s note, a table of contents, feature articles set in two columns, pull quotes, drop caps, and a colophon. It’s Issue 001 of The Periodical, and I am its only subscriber.

I made it with Claude Code, Claude Design, and Codex, and the whole thing started as a shower thought I typed into ChatGPT:

I wonder if there’s a way to use Obsidian Web Clipper to make a custom magazine based on a collection of clippings… thinking like every month clipped articles go into a folder and then the clippings somehow get packaged or bundled into a beautiful monthly periodical. I don’t yet use Obsidian so maybe this isn’t feasible?

I recently bought my dad a number of back issues of Lapham’s Quarterly, and it got me thinking about how to have something similar for myself. I liked the idea of a finite, private, beautiful object built from the articles I was already saving. I’ve always felt that read-later apps guilt me with an infinite backlog. But a physical magazine is something I could pick up and put down, and it ultimately ends.

That ChatGPT conversation grew into a full product spec for a pipeline that:

• Pulls my recent clippings, saved with Obsidian Web Clipper, from an Obsidian vault
• Processes each article to capture its images and metadata from the source
• Reads everything in full, drafts an editorial note, and arranges the pieces into topical sections
• Forks out to Codex to generate a magazine cover image
• Typesets it all into a print-friendly magazine

I took that spec to Claude Code, and argued through the open decisions over a few sessions to get to a few more constraints:

• The Obsidian vault is an immutable capture surface. The pipeline never writes to it. Every issue gets snapshotted into a git repo so the whole magazine is version controlled and reproducible.
• Issues are folders, not calendar months. When I feel like an issue is full, I build it.
• The AI work runs on my existing Claude and ChatGPT subscriptions, no metered API keys.

I got to a technical design I ended up liking. Every AI step sits behind a file contract. The editorial agent writes a JSON file. The image model writes a PNG. The deterministic Python pipeline doesn’t know or care what produced them, which means I can swap the editorial model or the image backend later without touching the pipeline at all.

It’s a fair question. These models can confidently produce wrong information. They may invent quotes, fabricate statistics, and do it all in the same tone they use to tell you the truth. The problem isn’t hypothetical.

But “what about hallucinations” usually carries an implied bar where the technology must never produce wrong outputs before we can use it. That’s a bar that will never be met. Not this year, probably not ever. If we treat it as a prerequisite for adoption, then we guarantee paralysis.

In my previous post, I argued that agentic AI can now handle a lot of the mechanical knowledge work that buries campaign staff. The hallucination objection is the most common reason people give for not starting. So it’s worth taking seriously on its own terms.

Campaigns don’t get the luxury of perfect conditions. You ship under deadline, on messy inputs, with decisions that compound. The practical question around AI becomes whether we can adopt imperfect tools intentionally, in ways that make mistakes visible and cheap to fix, without turning every fault into a public disaster. The good news is yes, we can.

Reliability engineering offers a useful frame here, and there’s a well-developed discipline around building systems that remain resilient even when individual components aren’t. Campaigns need to borrow it because the payoff is concrete. So much of campaign labor is taking messy piles of inputs and turning them into something a decision-maker can act on. Agents can handle that mechanical work, freeing staff for the judgment, relationships, and persuasion that humans are actually good at. But those gains only hold if the systems around the tools are designed well. The AI companies are converging on similar thinking, acknowledging that agent safety depends on the whole system, model and deployment alike. That’s a good sign, but it also means the organizations deploying agents have design work to do on their end.

This is the useful version of the Dead Internet Theory. Not the conspiratorial version where the internet is suddenly “fake,” but the strategic version where the feed is becoming a worse sensor. Imperva’s 2025 Bad Bot Report found that automated traffic has surpassed human activity, accounting for 51% of all web traffic. And Digg’s collapsed re-launch is a bright flashing light:

“The internet is now populated, in a meaningful part, by sophisticated AI agents and automated accounts. We knew bots were part of the landscape, but we didn’t appreciate the scale, sophistication, or speed at which they’d find us.”

Whether or not you buy every maximalist claim about bots, you should heed this moment. A feed can remain a useful distribution channel even as it becomes a much noisier environment. When synthetic activity distorts the signals coming back, campaigns risk optimizing against artifacts rather than persuasion.

But even that understates the shift. It isn’t just that machines are polluting human spaces, but that more of the internet is being built by and for machines as the primary producers and consumers. Technical users used to think in terms of APIs, but OpenClaw pushed the idea of autonomous agents into the mainstream. Moltbook suddenly appeared as a social network designed exclusively for AI agents. It mimicked Reddit’s format, but only bots could post, comment, and vote. It claimed 1.5 million personal agents, but security researchers revealed those agents were managed by just 17,000 human owners, an 88:1 ratio. Nevertheless, Meta acquired the platform almost immediately. That should land as more than a curiosity. It is an early signal that parts of the online ecosystem are no longer merely vulnerable to synthetic activity; they are being rebuilt for it.

And once that happens, the human response is predictable: people begin relying on machines to interpret the increasingly machine-shaped internet for them. You can already see that instinct forming. On X, users increasingly treat Grok as a fact-checker. That impulse to ask a machine for the answer is the behavioral shift that we can’t let run away from us. The current digital fight is about winning attention in feeds and learning from what the feed sends back. But the next fight is about the answer layer: what gets retrieved, summarized, ranked, and surfaced. When a voter asks an AI system what a candidate believes, what a bill does, or whether a claim is true, the system itself becomes the first interpreter of political reality. That is why Answer Engine Optimization matters immediately.

This layer is already operating at mass scale: Google says AI Overviews now reach more than 2 billion monthly users while ChatGPT is used by 800 million people every week. Combine that with the reality that information-seeking has become the lead use-case for AI, and the answer layer starts to look like a present-tense strategic priority.

The harder question is what actually shapes the answers people receive. Recent research from CaucusAI makes this concrete. When prompted with “Tell me about Josh Shapiro” every tested model produces a coherent summary of Pennsylvania’s governor. But the citation stacks underneath those answers are illuminating. Wikipedia appears in nearly every response. GPT consistently cites Axios and AP, both of which are OpenAI content partners. Gemini and Grok cite Pennsylvania’s NPR affiliate. The state government site shows up frequently. Shapiro’s own campaign website does not appear at all. Not once, across any tested model. The candidate’s own digital presence is invisible in the answer layer. We should be asking, why? Is it because our campaign websites are so heavily optimized for donation conversions that they fail at basic information discovery? Is it because the underlying models are actively weighted to treat campaign content as low-trust? The answer is vitally important. The current reality is that voters get information that is assembled from sources the campaign does not control and may not even be monitoring.

This is where Democratic practitioners need to move faster. We still talk about digital largely as a creation problem: more clips, more creators, more reach, more velocity. All of that still matters, as about half of U.S. adults say they get news from social media. But if the feed is being displaced as the arbiter and the internet itself is becoming more agentic, then the next advantage will not belong to the people who know how to trend. It will belong to whoever figures out how to show up in the new systems that mediate public understanding.

Right now, that is still an open field. No one has cracked it yet. We need to learn what retrieval-optimized political content looks like. We need to test how AI systems currently represent Democratic positions versus Republican ones on salient issues. We need to build a working theory of source authority in an AI-gated information environment. We need measurement systems and feedback mechanisms that allow us to be both proactive and reactive to the AI information landscape. These are solvable problems, but solving them will require devoted research, infrastructure, and resources today.

Democrats should undoubtedly keep competing for attention online. But we should not make the mistake of assuming that the feed is forever the information gateway. The next fight is over what survives into generative answers. The next time a voter asks a machine what Democrats stand for, the answer should not be assembled entirely from sources no one on our side is watching.

Using the same Federal Reserve list of the largest commercial banks, I started a Claude Code session and prompted:

Can you go to the page at https://www.federalreserve.gov/releases/lbr/current/ and discover the table of large commercial banks; then give me a bar graph of the top 10 by Consol Assets. Use uv for any dependencies you need. You probably want to use pandas read_html() to get the tables and then matplotlib with nice styling to create the viz

It spun for a bit and then produced some Python. Sometimes agents will try to run this kind of thing as a tidy here document, but not always. So I like to do this sort of thing in a scratch directory that it can toss files in. This time, it tossed a bank_chart.py, which it ran itself like this:

uv run \
  --with pandas \
  --with matplotlib \
  --with lxml \
  --with html5lib \
  --with requests \
  python bank_chart.py

On first run, it realized the Fed has opinions about the User-Agent header (VisiData also hit this issue), so it did the thing everyone does when scripting HTTP calls and made it look like a browser:

The Fed website is blocking the pandas request. I need to use a proper user agent header to fetch the content. Let me use requests to download the HTML first, then parse it with pandas.

--- a/bank_chart.py
+++ b/bank_chart.py
@@ -1,6 +1,15 @@
 import pandas as pd
 import matplotlib.pyplot as plt
+import requests
+from io import StringIO
 
-# Fetch the table from the Federal Reserve page
+# Fetch the table from the Federal Reserve page with proper headers
 url = "https://www.federalreserve.gov/releases/lbr/current/"
-tables = pd.read_html(url)
+headers = {
+    'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36'
+}
+response = requests.get(url, headers=headers)
+response.raise_for_status()
+
+tables = pd.read_html(StringIO(response.text))

It then ran again, successfully, and produced the following graph, both as a PNG and PDF:

The whole thing took about two minutes from prompt to viz.

I think a lot of people still view tools like Claude Code as AI that builds software for people who sell software. But we need to think about them as general purpose agents that help us get work done.

Not bad for a single prompt.

If your day job involves persuading voters, building coalitions, and running campaigns, it’s tempting to shrug. Cool. The engineers have new toys.

That shrug is going to age poorly.

Because the important development isn’t “AI can code.” The important development is: AI can use code to do work. And most campaign work happens through software. The question isn’t “is this a coding task?” The question is: can this be done on a computer?

If yes, you’re looking at tools that can handle the mechanical work that eats up campaign staff energy: searching, summarizing, transforming, moving information across systems. Not the judgment calls. Not the relationship-building. Not the strategy. But the tedious, repetitive, soul-crushing work that keeps smart people from doing what they’re actually good at. These tools can do that work at scale, in the messy reality of modern campaign operations.

To be clear: this isn’t about AI-generated content. The political AI conversation has been dominated by slop: cheaply generated images, robotic fundraising emails, uncanny video ads. That’s a real problem that’s eroding social trust, but it’s not what I’m talking about. Agentic AI isn’t about producing more stuff. It’s about operating the systems that produce, organize, and move information. The difference matters.

This isn’t a developer story. It’s a campaign knowledge story.

I like to do weird things with campaign finance data, and I thought it’d be nice to have an agentic sidekick to crawl around FEC files with me. There’s a ton of prior art here, so it’s a great use case for a Skill. The most relevant prior art is Derek Willis’s llm-fecfile, which wraps Evan Sonderegger’s venerable fecfile, and is a plugin for Simon Willison’s LLM CLI tool.

So I set out to make an Agent Skill. Except I didn’t have to do all that much.

I popped open Claude Code (Opus 4.5) and asked for a plan:

I have cloned the llm plugin llm-fecfile to @llm-fecfile/ . I would like to convert it to an Agent Skill. Let’s break it into tasks.

⏺ Here's the task breakdown for converting llm-fecfile to an Agent Skill:

  Tasks

  | # | Task                                                                       |
  |---|----------------------------------------------------------------------------|
  | 1 | Set up `.claude/skills/fec-filing/` with the required layout               |
  | 2 | Write SKILL.md file with YAML frontmatter and main instructions            |
  | 3 | Create FORMS.md with specific guidance for F1, F2, F3, F99 filings         |
  | 4 | Create SCHEDULES.md with field mappings for Schedules A, B, C, D, E        |
  | 5 | Create script to fetch and display FEC filings using the `fecfile` library |
  | 6 | Verify Claude can analyze an FEC filing using the new skill                |


  Key Conversion Notes

  - Plugin vs Skill: The LLM plugin uses a fragment loader (-f fec:ID). The skill will
  instead instruct Claude to use a Python script via Bash to fetch filings.
  - Documentation: The rich analysis instructions in llm_fecfile.py will become markdown
  reference docs that Claude reads.
  - Dependencies: The skill will require fecfile to be installed.

  Should I proceed with this plan, or would you like to adjust any tasks?

Yes, let’s go.

From there, it began porting all of Derek’s hard work into the necessary Markdown and script structure. Minutes later, I had agent-fecfile (formerly called claude-fecfile) and you can have it too:

If you run this, the skill is now available globally in all your Claude Code sessions:

git clone git@github.com:hodgesmr/agent-fecfile.git /tmp/agent-fecfile
cp -R /tmp/agent-fecfile/skills/fecfile ~/.claude/skills/

Or if you run this, the skill is now available globally in all your Codex sessions:

git clone git@github.com:hodgesmr/agent-fecfile.git /tmp/agent-fecfile
cp -R /tmp/agent-fecfile/skills/fecfile ~/.codex/skills/

Make sure you also have uv installed.

And now you can get the agent to do things like this:

Show me a table of the contribution counts and totals, by state, in fec filing 1896830

⏺ FEC Filing 1896830 - Contributions by State

  | State | Count |      Total | % of Total |
  |-------|-------|------------|------------|
  | UT    |    32 | $35,042.25 |      87.0% |
  | VA    |     2 |  $2,400.00 |       6.0% |
  | GA    |     1 |    $750.00 |       1.9% |
  | MI    |     1 |    $750.00 |       1.9% |
  | MD    |     2 |    $750.00 |       1.9% |
  | FL    |     1 |    $600.00 |       1.5% |
  | TOTAL |    39 | $40,292.25 |       100% |

  Utah dominates with 87% of the total contributions. The committee received from
  6 states total, with only 7 out-of-state contributions.

And things like this:

What are the largest expenditures in filing 1896830?

⏺ FEC Filing 1896830 - Largest Expenditures

  | #   | Recipient                  |    Amount | Date       | Purpose          |
  |-----|----------------------------|-----------|------------|------------------|
  | 1   | Trump National Doral Hotel | $1,013.61 | 2025-05-19 | RNC training     |
  | 2   | Uber.com                   |    $19.77 | 2025-05-06 | Travel - Cabfare |
  |     | TOTAL (itemized)           | $1,033.38 |            |                  |

  Note

  Only 2 expenditures are itemized on Schedule B. The filing shows $21,283.49 in total
  disbursements, meaning most spending (~$20,250) was below the $200 itemization
  threshold and appears only in summary totals.

  The largest single itemized expense was for RNC training at Trump National Doral Hotel
  in May 2025.

Agents!

The Iterated Prisoner’s Dilemma felt perfect for this. It’s a well-studied problem with decades of research and it allows you to objectively measure how good your strategy is by running a tournament. So I gave Claude Code (Sonnet 4.5) one prompt to look at the Axelrod library’s 200+ IPD strategies, come up with something novel that could actually compete, and build it.

uv pip install "git+https://github.com/hodgesmr/Axelrod@bayesian-forgiver-strategy"

import axelrod as axl

players = [
    axl.BayesianForgiver(),
    axl.TitForTat(),
    axl.Cooperator(),
    axl.Defector(),
    axl.Grudger(),
    axl.TitFor2Tats(),
    axl.WinStayLoseShift(),
    axl.GTFT(),
    axl.Random(),
    axl.SuspiciousTitForTat(),
    axl.HardTitForTat(),
    axl.Adaptive(),
    axl.APavlov2011(),
    axl.ForgivingTitForTat(),
    axl.GoByMajority(),
]

tournament = axl.Tournament(players=players, turns=200, repetitions=20)
results = tournament.play(progress_bar=True)

for i, name in enumerate(results.ranked_names):
    idx = results.players.index(name)
    avg_score = sum(results.scores[idx]) / len(results.scores[idx])
    print(f"{name} : {avg_score}")

On October 24, 2025 at 9:08 am CT, our daughter Lena was born. Lena’s birthday is 1024.

Kelsey became a mom. I became a dad.

I love Lena so much. I love Kelsey so much.

Lena was admitted to the NICU at 11:30 am CT for oxygen support due to respiratory distress syndrome. She was put on CPAP with an NG tube.

Kelsey remained on bed rest with postpartum medication and monitoring for the next 24 hours.

On October 25, 2025 at 2:30 pm CT we saw on Lena’s cam that she was ready to eat her first meal without the NG tube. We began visiting the NICU every three hours to do so.

On October 26, 2025 at 8:30 am CT Lena came off oxygen support and was breathing all by herself. At around 12:00 pm CT Kelsey was discharged from the hospital.

We then moved into a Ronald McDonald Family Room down the hall from the NICU so that we could continue visiting and feeding. What an amazing support resource for families.

On October 27, 2025 at 12:45 pm CT Lena was discharged from the NICU and everyone got to come home.

Many families go through so much more in the NICU. We are so grateful for Lena’s strength and progress.

For almost a week now, the three of us have been home, happy, and healthy.

We decided that, for now, photos will stay on family devices.

Kelsey and I are extremely fortunate to have the comfort and security to take the next few months away from work, together.

I deleted Slack off my phone. Its place on my Home Screen is now occupied by a diaper and feeding logging app. I love that.

This post isn’t for anyone in particular. It’s for me. It’s for us.

I am so happy to be home with my family.

I love Lena so much. I love Kelsey so much.

The long and short of it is: hashing is only effective if the input data is unbounded. It’s why long and unpredictable passwords are necessary, even with a robust hashing function. PII is neither long nor unpredictable.

• You can download every baby name going back to 1880 from the Social Security administration.
• Email addresses follow the format something@something.something.
• Social Security numbers are 9 digits, so there are at most 1 billion.¹
• North American phone numbers are 10 digits, so there are at most 10 billion.²

Despite this, marketing tools still shuffle around PII hashes of this data. For example, here’s BambooHR:

In order to better identify any shared customers we may have, we have decided to compare our customer lists encoded as MD5 Hashes. By encoding our respective customer lists in MD5 Hashes, we will be able to compare customer lists without disclosing any customer info (including customer name).

And platforms like UnsubCentral:

Manually entering in phone numbers to a suppression tool is a waste of time and resources. Our tool can take plain text and compare it against MD5 or SHA hashed lists of phone numbers – simply throw in the data, and it will do the hard work for you.

Everyone is trying to do private set intersection, but doing this with hash-passing is trivially broken on modern consumer hardware. And you don’t even need special password cracking software to break it.

On a laptop, we can build a rainbow table of Parquet files for every North American phone number. We can abuse DuckDB as a hashing mill, and generate every MD5 in the 5XX area code block:

PRAGMA threads=8;
PRAGMA temp_directory='/tmp';

COPY (
  WITH gen AS (
    SELECT i::BIGINT AS number, md5(i::VARCHAR) AS hash
    FROM range(5000000000, 6000000000) t(i)
  )
  SELECT substr(hash,1,2) AS h2, (number % 8) AS shard, number, hash
  FROM gen
) TO 'out/md5nums'
    (FORMAT 'parquet',
    PARTITION_BY (h2, shard),
    COMPRESSION 'zstd',
    ROW_GROUP_SIZE 250000);

What this does:

• Specify DuckDB to use up to 8 execution threads.
• For each generated integer i within 5,000,000,000 - 5,999,999,999, cast to text and compute its MD5. The generator is vectorized and parallelized, so it feeds the pipeline quickly.
• Take the first two hex chars (00 - ff). This h2 is a hash prefix for partitioning so lookups by full hash only have to read one small directory.
• With modulo-8, sharding spreads each hash-prefix partition, which give parallelism during writes and avoids large single files.
• Write Parquet files, and organize output as directories per distinct (h2, shard); this gives a structure like: out/md5nums/h2=ab/shard=3/part-*.parquet.
• Use Zstandard compression inside Parquet (efficient for number but not hash).

Crunch:

 ~/ $ duckdb -c ".read md5gen.sql"
100% ▕██████████████████████████████████████▏ (00:40:41.41 elapsed)

And now with the hash af82af0fad119df159ce350db422d3b3 we can reverse back to its phone number:

 ~/ $ H=af82af0fad119df159ce350db422d3b3
 ~/ $ P=${H:0:2}
 ~/ $ duckdb -c \
> "SELECT number FROM 'out/md5nums/h2=${P}/**/*.parquet' WHERE hash='${H}' LIMIT 1;"
100% ▕██████████████████████████████████████▏ (00:00:02.84 elapsed)
┌────────────────┐
│     number     │
│     int64      │
├────────────────┤
│   5555550123   │
│ (5.56 billion) │
└────────────────┘

Here we do:

• H=... is the hash.
• P=${H:0:2} grabs the first two hex chars (af) to match the partitioned dataset.
• FROM 'out/md5nums/h2=${P}/**/*.parquet' allows DuckDB to read only files inside the partition directory whose name encodes h2=${P}. The **/*.parquet is a recursive glob so it also walks into the shard=... subfolders instead of scanning the entire billion-row dataset.
• DuckDB vector-scans row groups within that one h2 partition until it finds a match.

File scanning here is just a proof-of-concept. For true query speed you can trade file portability for a database index. Once your Parquet files are built, you can load them into DuckDB as a persistent table and create an index on the hash column. Or, Postgres with a B-tree index is also a great fit.

On my 2020 M1 MacBook Air, computing 1 billion 5XX phone number hashes completes in about 40 minutes. There are about 6.3 billion valid North American phone numbers, so building a hash lookup table for all of them would take my little laptop just over 4 hours.

None of this is breaking news. In 2021, researchers hashed 118 billion phone numbers:

The limited amount of possible mobile phone numbers combined with the rapid increase in affordable storage capacity makes it feasible to create key-value databases of phone numbers indexed by their hashes and then to perform constant-time lookups for each given hash value. We demonstrate this by using a high-performance cluster to create an in-memory database of all 118 billion possible mobile phone numbers

The thing is, you really don’t need a high-performance cluster anymore.

In October 2020, as that presidential election approaching an end, I was running on fumes. I’d spent 494 days — usually seven days a week and often twelve hours a day — working to defeat Donald Trump. What’s strange is that throughout the campaign I felt like I never had time to eat, and somehow I still gained weight. By the end I was the heaviest I’d ever been and completely drained. The bitter reality about campaign work is that the moment you finish the marathon, your job disappears. One day you’re operating at full throttle; the next, you’re unemployed with nothing but free time.

So I decided to channel it. I couldn’t keep pretending my 20s metabolism was coming back, and I figured data might help where willpower hadn’t. I wanted to treat my health like a project: something measurable, improvable, trackable. So I composed a little ecosystem of apps and devices to log everything: what I ate, how I exercised, how much water I drank, what I weighed. It was a nerd’s approach to fitness, but it works for me.

This is my health app stack:

Here’s how it works:

Peloton — This is the engine behind my workouts. I wasn’t a sports kid in high school, and I never went to the gym in college or my 20s. I knew I couldn’t rely on my own judgment or discipline here. Peloton works for me because the instructors design every workout, I like riding a stationary bike, and the entertainment value makes the time fly. The Bike and subscription aren’t cheap (but neither are gym memberships), but they’re absolutely worth it to me. I actually started with a bootleg setup: just the iOS app connected to a Schwinn IC4. It worked surprisingly well until the IC4 started breaking down and needed hundreds of dollars in repairs. Upgrading to a proper Peloton Bike was a big step up.

LoseIt! — One of the most popular diet-tracking apps. I’d tried MyFitnessPal before and bounced right off it. The two apps are nearly identical, but somehow switching platforms was a psychological reset that made it click. LoseIt’s food database is impressively accurate, the smart reminders to log meals actually help, and the ability to fine-tune calorie and nutrient goals is excellent. After experimenting with a few diet approaches, I’ve landed on what works best for me (not health advice for you!): stay a good clip below 2,000 calories a day, low carbs, and low sugar. A few years back, they ran a Thanksgiving sale offering lifetime premium access for a one-time payment; I jumped on it and haven’t paid another dime since.

Water & Coffee — A delightful little app that does exactly two things: track your water and track your caffeine. By the end of the 2020 campaign, I was drinking an entire pot of coffee a day and barely touching water. Logging both helped me cut my caffeine drastically (I’m down to about two cups a day) and reminded me to hydrate like an adult. The app is simple, free, privacy-respecting, and ad-free. I liked it so much I sent the developer a tip just to say thanks.

Apple Health — This is the data orchestration layer. I rarely open the app itself, but since everything connects through HealthKit, the data just flows. When I burn calories in Peloton, that data moves automatically into LoseIt without me touching a thing. It’s nice having all the plumbing between these apps handled, and that the data ultimately lives inside my Apple account in my custody.

Todoist — Not technically a health app, but essential for keeping me consistent. Todoist’s free tier is surprisingly powerful, and it’s where I schedule all my workouts. I have a recurring project called Weekly Exercise that lays out the days and durations for each ride. Even before the recent AI boom, Todoist supported natural-language scheduling: you can type something like #health 45 minute Peloton every Sunday, and it automatically tags and repeats it for you. It’s simple, structured accountability.

Here’s the thing about a stack: you have to actually use it. Over the past five years, I’ve had stretches of real success, and just as many where I let things slide. Every single backslide came down to the same cause: I stopped sticking to the system.

Life happens. You move, you change jobs, you buy a house, and suddenly there’s an endless list of reasons not to eat well or work out. I’d go through phases where I stopped logging food altogether because I didn’t want to face the evidence; typing in pizza and beer only made me feel worse. Unsurprisingly, when I stopped tracking what I ate, I also stopped exercising as much. And just as predictably, that’s when the weight crept back on.

The nice thing about having five years of data is that I can actually see it. Here’s my weight over time (I like to use PCHIP), shown as a percentage of my target weight:

Pretty wild how much my weight lines up with life events! You can see how the abundant Austin nightlife impacted my habits, how the election cycles align with local maxima, and how the stresses of moving and a home purchase interfere with my goals. But these aren’t the direct causes. Life stresses affect how much I’m exercising and how well I’m eating, which then affect my ability to lose or maintain weight. Where I see a quick drop in weight is also where I’m exercising the most, and sticking to my diet the best.

For me, diet, exercise, and quantitative metrics work!

In 2020 I posted a short video demonstrating some quick data exploration you can do with it:

Today I appreciated another snappy use case: pulling and transforming HTML table data.

I learned that the Federal Reserve publishes a regularly-updated list of the largest commercial banks. It looks like this:

It also comes in PDF and ASCII formats. Unfortunately, the ASCII format would require bespoke parsing.

The good news is the HTML-formatted data uses good old <table> instead of <div> nonsense. Better yet, VisiData can work really well with HTML tables:

curl -s https://www.federalreserve.gov/releases/lbr/current/ | vd +:table_1::

which does the following:

1. Pull the page HTML with curl
2. Pipe it into VisiData
3. Select the second (zero-indexed) table

which presents this:

You can do fun visualizations in the terminal, like graph the log10 of the Consol Assets (Mil $) column, which looks like this:

But what’s even more handy is you can just convert the entire data set directly to TSV (there are commas in the numeric data; CSVs are kinda bad) in one go:

curl -s https://www.federalreserve.gov/releases/lbr/current/ |
  vd +:table_1:: -b -o feddata.tsv

or SQLite:

curl -s https://www.federalreserve.gov/releases/lbr/current/ |
  vd +:table_1:: -b -o feddata.sqlite

or JSON:

curl -s https://www.federalreserve.gov/releases/lbr/current/ |
  vd +:table_1:: -b -o feddata.json

And just like that, you’ve got clean data of every big bank in the country.

Not bad for one pipe.

Coming out of the video, I too wanted to become more acquainted with philosophy. I read a little bit of Kant and Bentham (and I think some Foucault?) in my undergraduate Tech Ethics class, but to say I was familiar with their works would be a lie. I read Machiavelli’s The Prince about 10 years ago, and my big takeaway is that no one uses the adjective “Machiavellian” appropriately. And a couple of Aristotle’s greatest hits have been sitting in my Goodreads to-read queue for over a decade.

I don’t want to read 52 philosophy texts. But I kindof want to read five philosophy texts. This quote from the beginning of the video really stuck out to me:

Most importantly: in chronological order. That was actually pretty important because I realized that philosophy is a conversation. Wittgenstein is reacting to Kant, who is reacting to Hume, who is reacting to Descartes, who is reacting to Plato, and so on.

The creator helpfully listed all 52 philosophers they read in the video’s description. But how to reduce that down to just one-tenth of the repertoire? Well, a neat thing about popular philosophy is a lot of it is in the public domain, and basically all of it has been analyzed and discussed intensively. Sounds like a great subject to bring to the generative pre-trained stochastic parrot!

So I asked ChatGPT 5:

Let’s say I want to spend a few months really digging into philosophy. I want to read a seminal work or educational material from 5 philosophers over the course of history and I want to do it in chronological order so I can see how they are responding to previous thought. I want to get a strong sense of the major foundations of philosophy. I don’t want to dwell very much on theological philosophy but I don’t want to completely ignore its role in the evolution of thought. Given all this, and what you know about my interests, can you pick 5 philosophers from this list [from the video] that I should read. Explain your selections. Think of this as my self-guided education in philosophy.

It only took a little back-and-forth to land on my list. For largely arbitrary reasons, I rejected the initial recommendation that included Augustine and swapped in Descartes. This left me with a compact reading plan, with the goal of a crash course on how Western philosophy keeps answering itself:

1. Plato: Republic (Books II–VII)
2. Aristotle: Nicomachean Ethics (I–III, V-VII, X)
3. René Descartes: Meditations on First Philosophy (I–VI)
4. David Hume: Enquiry Concerning Human Understanding (entire)
5. Immanuel Kant: Prolegomena to Any Future Metaphysics (entire)

Now let me tell you: if you roll into a Half Price Books with $40 and an appetite for pre-owned philosophy, you can shop like a king. I also picked up some Nietzsche, Smith, and Keynes. Feel free to yell at me in the comments about whether economics counts as philosophy.

By now, I’m sure some readers are mad at me. Maybe you work in liberal arts academia. Maybe you think my tight-five philosophy reading is deeply flawed and this is further proof that LLMs are bad. That’s okay! I’m not trying to replace academia. I’m just trying to read some philosophy without decision paralysis.

I didn’t duplicate it here, but in addition to enumerating works to read, I went back and forth with ChatGPT to get a bit of a mini syllabus for insights and themes and speed bumps I might face while reading. It was a great way to jump in! So I jumped in.

I took The Republic one book at a time. My workflow was to read a book, jot notes in Bear, and then once I finished paste my messy notes back into ChatGPT for further exploration.

Sometimes my notes were basic, like as I figured out that Plato was ventriloquizing Socrates:

Hey quick aside: should I be reading these ideas as belonging to Socrates or to Plato?

Sometimes my notes teed up my interpretation and projections:

Man, the noble lie really does make me think about how conservatives romanticize the founding fathers and can’t handle the critique of slavery

Sometimes my notes were actual critiques:

It’s pretty funny that this book ends with a grand distinction between knowledge of how things “are” vs just having opinions, when all of the dialogue thus far across multiple books have leaned entirely on enumerating endless things that Plato asserts are “good” or “obvious” or “desired”

It would have been fun to do this sort of discussion as a reading group that might actually argue with me about these notes. ChatGPT occasionally pushed back, softly suggesting I missed the point, but it generally told me my observations were sharp and in line. Philosophy is one of those subjects where you need to be challenged more than be told that you’re right. I’ve probably devastated more liberal arts professors at this point. That said, I am still the reader, I’m the one thinking about the works for hours, and it’s my own notes being dumped into the text box.

So what are my thoughts on Plato? Well, a nice benefit of language models is they’re pretty good at modeling language. They can take twelve days of unstructured commentary and summarize it all for you quite nicely:

I would like you to look back at our conversation about Plato’s Republic, look at my observations and our discussions of them, and highlight my most salient critiques and insights.

• Epistemic overreach: Plato asserts a single, static “Form of the Good,” downgrades everything else to mere opinion, and demands first-principle certainty while rarely supplying it. It’s a bit of bait-and-switch: opinions masquerading as knowledge, crowned by Book VI’s line without a method for identifying real “knowers.”
• Static ideal vs. evolving justice: I think history shows us to prefer dynamic, (maybe fallibilist?) frameworks over Plato’s timeless blueprint.
• Authoritarian pedagogy: Book III’s cultural program: censorship, fixed musical modes, and anti-dissonance, reads like “the medium is the message” turned into policy. Moral psychology by force: control styles to control souls.
• Representation shapes character: Even though I reject the strong censorship, the media-morals link is prescient (Postman vibes): forms and styles train dispositions.
• Justice redefined as hierarchy: In Book IV, justice = each part doing its own work (city: rulers/auxiliaries/producers; soul: reason/spirit/appetite). It’s a rigid caste system rebranded as “harmony,” hostile to mobility and innovation.
• Noble Lie as civic glue: The metals myth links to modern origin myths (e.g., romanticized Founding Fathers): a stabilizing story that resists critique.
• Elitism about the demos: Book VI’s ship metaphor doubles as anti-democracy and anti-relativism. Politicians serving constituents chase popularity; truth requires expertise. The case is underargued but an anti-relativist thrust is clear.
• Anti-relativism and anti-novice: The ship image isn’t without merit: some domains are truth-apt and expertise-laden; popularity doesn’t make them so. The question is whether “justice” belongs there.
• Dialogue as ventriloquism: The “dialogue” is a stacked-deck monologue. Plato borrows Socrates’ authority to sell his own system; interlocutors mostly assent on cue.
• Eugenic, anti-private life for guardians: Book V’s communal breeding, child exposure, abolition of family/private property, authoritarian eugenics are all very disturbing! Plato pairs it all with a surprising argument for women’s political equality.
• Math as royal road, science half-seen: Plato exalts mathematics, dismissing sensory astronomy, and half-anticipates physics (movement in 3-D) while calling current work “absurd.” Admiration for math; impatience with empirical practice.
• Philosopher resentment and duty: Book VII’s Cave: knowers must “return.” Both civic duty and a chip on the shoulder that society should revere philosophers more than it does.
• The big detour problem: Across the middle books, Plato wanders from “is justice better?” into city-design and epistemology. It’s engaging but unconvinced: impressive scaffolding, shaky footings.
• Models vs. methods: Plato gifts durable models (Sun, Line, Cave, Gyges, Noble Lie), not rigorous methods.
• Education as moral engineering: Education isn’t ornament; it’s the state’s engine. Book VII’s decades-long curriculum is the hinge between epistemology and politics.

This post is not a book report, but rather a report on how I’m using AI tools to learn new domains in new ways. The tension here is that philosophy resists tidy summaries, and language models are built to produce smooth, confident digests. Without bringing your own full thought forward, they can sand off the strangeness and ambiguity that makes these texts worth reading in the first place. What I’ve found useful is not treating the output as my own interpretation, but as scaffolding: a way to surface themes, keep momentum, and occasionally highlight blind spots in my notes. The thinking still happens on my side of the screen; the model just lowers the friction of staying engaged. I’m going to keep with this process as I work through my philosophy stack.

On to Aristotle.

Let’s meet the Crab:

He had just bought his first record player, and being somewhat gullible, believed every word the salesman had told him about it-in particular, that it was capable of reproducing any and all sounds. In short, he was convinced that it was a perfect phonograph.

Douglas Hofstadter’s Gödel, Escher, Bach contains an illustrative little dialogue called Contracrostipunctus. You don’t need to have read the book (but you should) to appreciate the setup: the Tortoise (a regular character in GEB’s allegories) composes records engineered to destroy his friend the Crab’s latest “perfect” phonograph. The phonograph is billed as “capable of reproducing any and all sounds,” and each time the Crab upgrades, the Tortoise arrives with a new record with a title like:

I Cannot Be Played On Record Player 1

The result is always the same: a few notes in and then pop, a shattered case, strewn parts, and dead silence.

It’s funny. It’s also an apt embodiment for prompt injections in modern AI systems. In 1979, Hofstadter imagined inputs designed to wreck the machines that interpret them. In 2025, those inputs are prompts, retrieved passages, HTML snippets, captions, and filenames: strings tailored to the quirks of a model-and-tools stack, coaxing it to carry out things that it shouldn’t.

This post walks through the core ideas in the dialogues and maps them to possible defenses for language‑model systems. Along the way we’ll imagine Record Player Omega, learn why clever hardening is never enough, and consider the humbler goal of survivability.

It mostly worked:

It Bing’d for Sherrod Brown’s website, waited for the page to load, found the donation button for $50, clicked it, navigated through the credit card flow, saw that there was a form that needed more information about me, and handed control back to me to complete the task. Here’s what that looked like:

I felt a little hesitant typing my credit card info into ChatGPT’s little VNC iframe, so I set up a temporary virtual card (a free service offered by my credit card provider) that auto-expired after a single charge.

This flow is exactly what I expected, but it likely can be automated further. OpenAI claims that the agent holds on to cookies across sessions, so I imagine that if I had previously authenticated to ActBlue in a chat, and had ActBlue Express, the automated session would have just charged the card without my intervention. I didn’t try it.

All the standard “what about…” apply here: How do I know the agent found the proper donation form? How do I know it didn’t set up recurring donations? How do I know it selected $50 and not $500? How do I know I didn’t end up on a malicious site prompt-injecting me to donate to Jon Husted instead? Yes, all the things. In this case, I know because the agent handed control back to me and I checked. But a more-automated flow might not have given me that opportunity.

A lot of the discourse around AI and LLMs tends to leave out the idea that all of this is a UX paradigm shift. I’m eager to see how these tools mature and how political campaigns can innovate voter contact.

Of course, user-entered data is messy. One person types “nurse,” another “ER Nurse,” another “RN,” and yet another “home health nursing.” If you want to understand the composition of your user base, or build automated systems that adapt to it, you need to normalize that chaos into a finite and meaningful taxonomy. You wouldn’t want a dashboard full of job titles in SpongeBob casing, but realistically, you have to work with whatever comes through the form.

A data-forward organization might use this information for all kinds of purposes: tailoring outreach, prioritizing leads, enriching analytics, or even customizing onboarding flows. But none of that works without being clean, consistent, and structured.

With language models, we can do better. We don’t need to predefine normalization rules or manually review each row. And we don’t even need much prior knowledge about our users to start.

But before we jump straight to the AI, let’s define our approach:

1. To normalize free-form text, there must be a finite set of target categories.
2. If we know nothing about users in advance, we need a reliable way to discover or define those categories.
3. We’re decidedly not using a chatbot, and we’re not relying on external APIs.
4. This isn’t a generative task; it’s about semantic understanding.

Let’s start at the top. There are an infinite number of values a user could enter for their job, and we want to reduce that to a finite set. So where do we get that set?

The Occupational Information Network (O*NET) maintains exactly such a resource. Developed under the sponsorship of the Departoment of Labor, O*NET offers rich datasets that describe skills, knowlege, tasks, and job titles. We’re interested in the Alternate Titles file, which maps occupation titles to alternate “lay” job titles. There’s a good chance many of our users enter these alternate titles, so we’ll want to include them.

The file includes columns of Department of Labor and Census identifiers, but we only need the few that focus on title. Let’s download it and take a look at a few examples:

import numpy as np
import pandas as pd

onet_df = pd.read_excel(
    "https://www.onetcenter.org/dl_files/database/db_29_3_excel/Alternate%20Titles.xlsx",
    usecols=['Title', 'Alternate Title', 'Short Title'],
).fillna("")

onet_df.sample(n=5, random_state=101)  # seed for reproducibility

So O*NET tells us that Cargo and Freight Agents might also go by a Shipping Agent as an Alternate Title and that Occupational Therapy Aides might also go by a Rehab Therapy Aide as a Short Title.

We also see that there can be many rows of different Alternate Title and Short Title for the same Title:

onet_df[onet_df["Title"] == "Software Developers"]

There is one thing we do know ahead of time about our users: not all of them will be employed. The O*NET data set doesn’t provide a job title for not working, so let’s add our own:

additions = pd.DataFrame(
    [
        {"Title": "Unemployed", "Alternate Title": "Not Employed"},
        {"Title": "Unemployed", "Alternate Title": "None"},
        {"Title": "Unemployed", "Alternate Title": "N/A"},
        {"Title": "Unemployed", "Alternate Title": "No Employment"},
        {"Title": "Unemployed", "Alternate Title": "Not Working"},
        {"Title": "Retired", "Alternate Title": "Retiree"},
    ]
)
onet_df = pd.concat([onet_df, additions], ignore_index=True).fillna("")
onet_df[(onet_df["Title"] == "Unemployed") | (onet_df["Title"] == "Retired")]

Now let’s merge these fields together. Since we’ll be leveraging a language model, we can take the liberties of language here; we don’t need clean many-to-many relationships. Just combine Title, Alternate Title, and when available, Short Title into one Long Title field with "aka" inline:

mask = onet_df["Short Title"].eq("")

onet_df["Long Title"] = np.where(
    mask,
    onet_df["Title"] + " aka " + onet_df["Alternate Title"],
    onet_df["Title"] + " aka " + onet_df["Alternate Title"] + " aka " + onet_df["Short Title"],
)

onet_df[onet_df["Title"] == "Software Developers"]

Great. We’ve satisfied parts one and two of our approach. We have a finite set of job titles, and we have a good understanding that the set is large but not exhaustive, and it combines multiple values for a job title. Let’s start modeling language.

JobBERT-v2 is a sentence-transformers model fine tuned from all-mpnet-base-v2 specifically for job title matching and similarity. Hey that’s convenient!

We can’t use JobBERT out of the box, we’ll need to incorporate our O*NET dataset. Let’s pull it down and start building out our implementation of the model. To do this we’re going to leverage word embeddings against our Long Title values. If you’re unfamiliar with langage model embeddings, Simon Willison has a fantastic overview that you should go read now. But the gist of it is: embeddings are how language models numerically encode meaning from language into a large vector. This is suprisingly powerful, and yields operations like:

emb('king') - emb('man') + emb('woman') which returns a vector that is mathmatically very close to emb('queen').

We’re going to use this “closeness” between vectors to reduce infinite free-form data to our finite Long Title data and then map it back to Title. The first thing to do is quite simple: calculate JobBERT embeddings on all of the values in our Long Title column:

from sentence_transformers import SentenceTransformer
import warnings
warnings.filterwarnings("ignore")

model = SentenceTransformer("TechWolf/JobBERT-v2")

onet_df["embedding"] = list(
    model.encode(
        onet_df["Long Title"].tolist(),
        normalize_embeddings=True,
        convert_to_numpy=True,
        show_progress_bar=False,
    )
)

onet_df[["Long Title", "embedding"]].sample(n=5, random_state=101)

As a reader, the embedding column is an indecipherable array of floats, but now we can do some cool things. Here are three rows from our data:

slice = onet_df[
    (onet_df["Long Title"] == "Software Developers aka Video Game Engineer") |
    (onet_df["Long Title"] == "Database Architects aka Information Architect") |
    (onet_df["Long Title"] == "Cargo and Freight Agents aka Shipping Agent")
]
slice[["Long Title", "embedding"]]

In a vector space, you can evaluate how similar two vectors are by taking their cosine similarity. Since we normalized our vectors when we embedded them, the denominator in the cosine function becomes 1 so we can do this even more efficiently with just a dot product:

database_architect = slice.iloc[0]["embedding"]
software_developer = slice.iloc[1]["embedding"]
cargo_and_freight_agent = slice.iloc[2]["embedding"]

print(f"Software Developer vs Data Architect: {software_developer @ database_architect}")
print(f"Software Developer vs Cargo Agent: {software_developer @ cargo_and_freight_agent}")

Software Developer vs Data Architect: 0.2380954772233963
Software Developer vs Cargo Agent: 0.08600345253944397

Those numbers look perfectly reasonable: a modest overlap (≈ 0.24) between two tech roles and an almost-orthogonal relationship (≈ 0.09) to the Cargo Agent job.

Great. So now we have a mathematical way to compare the language of two job titles. And we’re not touching chatbots or 3rd party APIs at inferrence. The DataFrame is a self-contained model for semantically matching across the O*NET dataset. We’ve fully satisfied our approach!

Now to apply it to our problem. Instead of evaluating O*NET data against itself, we can use our embeddings to evaluate any free-form job title text a user might submit.

Let’s go get some real data to try it out! Since I work in political tech, I like to reach for campaign donor data.

Our friends over at ProPublica publish itemized ActBlue receipts by state. Because ActBlue is a conduit committee, these files include every transaction of any amount. That’s a lot of transactions! Let’s grab all of the ActBlue transactions from Texas for June 2024.

dtypes = {
    "flag_orgind": "string",
    "first_name": "string",
    "city": "string",
    "zip": "string",
    "amount": "float64",
    "occupation": "string",
}

abtx_df = pd.read_csv(
    "https://pp-projects-static.s3.amazonaws.com/itemizer/sa_1791562_tx.csv",
    usecols=dtypes.keys(),
    dtype=dtypes,
)
abtx_df = abtx_df[abtx_df["flag_orgind"] == "IND"]
abtx_df.drop(columns=["flag_orgind"], inplace=True)
abtx_df.dropna(inplace=True)

employed = lambda df: df["occupation"].ne("NOT EMPLOYED")
get_sample = lambda seed: abtx_df.loc[employed(abtx_df)].sample(n=10, random_state=seed)

get_sample(30330)  # seed for reproducibility

That occupation field came from donors and doesn’t perfectly match our modeled job titles. But we don’t need it to! Let’s use our model to calculate embeddings on these new values:

abtx_df["embedding"] = list(
    model.encode(
        abtx_df["occupation"].tolist(),
        normalize_embeddings=True,
        convert_to_numpy=True,
        show_progress_bar=False,
    )
)

get_sample(30330)

So now we have two sets of embeddings: we have our O*NET embeddings and we have our ActBlue donor embeddings. Just as before, we can calculate similaries between them. But unlike before, we need to calculate a lot. In order to find the best match we need to compare every O*NET embedding vector with every ActBlue embedding vector. That’s a lot of comparisons. The good news, this is what GPUs are good at, and a free-tier GPU in Google Colab can kick this out fast.

We convert our O*NET embedding column into a (n × d) tensor, where n is the number of rows and d is the vector length. Similarly, we convert the ActBlue embedding column into a (m × d) tensor where m is the number of ActBlue rows.

When pushing this to a GPU, it’s a little more art than science. We batch it, and picking an optimal batch size can take some trial and error. For every batch, we’ll calculate the dot product, and return the indices of the best similarities.

From there, we can map all the way back to our original O*NET Title column, as our normalized output:

import torch

device = "cuda"  # requires an NVIDIA GPU + CUDA
onet_t = torch.tensor(np.stack(onet_df.embedding), device=device)  # (n × d)
abtx_t = torch.tensor(np.stack(abtx_df.embedding), device=device)  # (m × d)

batch = 4096  # tune to fit GPU RAM
best = []

with torch.no_grad():
    for s in range(0, abtx_t.size(0), batch):
        sims = abtx_t[s:s+batch] @ onet_t.T  # (batch × n)
        best.append(sims.argmax(dim=1).cpu())

idx = torch.cat(best).numpy()

abtx_df["Normalized Occupation"] = onet_df.Title.iloc[idx].to_numpy()

get_sample(30330)[["first_name", "occupation", "Normalized Occupation"]]

A way to visualized this is with principal component analysis. PCA computes new orthogonal axes called principal components that capture the most variation in the data. These directions are combinations of the original dimensions, chosen to reveal the biggest patterns and differences. By projecting each vector onto the first two principal components, we can plot everything in two dimensions while keeping as much of the original structure as possible:

import matplotlib.pyplot as plt
from sklearn.decomposition import PCA

X_onet = np.vstack(onet_df["embedding"].to_numpy())
X_abtx = np.vstack(abtx_df["embedding"].to_numpy())
X_all  = np.vstack([X_onet, X_abtx])

pca = PCA(n_components=2)
proj = pca.fit_transform(X_all)
coords_onet = proj[: len(X_onet)]
coords_abtx = proj[len(X_onet) :]

plt.figure(figsize=(16, 9))
plt.scatter(coords_onet[:, 0], coords_onet[:, 1], alpha=0.6, label="O*NET job titles")
plt.scatter(coords_abtx[:, 0], coords_abtx[:, 1], alpha=0.6, label="Donor-entered occupations")
plt.title("PCA of Occupation Embeddings: O*NET vs Donor-entered")
plt.xlabel("Component 1")
plt.ylabel("Component 2")
plt.legend()
plt.tight_layout()
plt.show()

And in our higher-dimension space, we can calculate ad hoc similarities on any arbitrary job title someone might enter:

def normalize(job_title):
  ad_hoc = torch.tensor(
      model.encode(
          [job_title],
          normalize_embeddings=True,
          convert_to_numpy=True,
          show_progress_bar=False,
      ),
      device=device,
  )
  idx = int((ad_hoc @ onet_t.T).argmax(dim=1))
  return f'{job_title} → {onet_df.at[idx, "Title"]}'

print(normalize("code ninja"))
print(normalize("uber"))
print(normalize("GM"))
print(normalize("Professor, Artist"))
print(normalize("Postdoctoral Fellow"))
print(normalize("DARE Officer"))
print(normalize("Senator"))
print(normalize("Comms Director"))
print(normalize("dermatology"))
print(normalize("commodities trader"))
print(normalize("life insurance adjuster"))
print(normalize("lumberjack"))
print(normalize("cpa"))

code ninja → Computer Programmers
uber → Taxi Drivers
GM → General and Operations Managers
Professor, Artist → Art, Drama, and Music Teachers, Postsecondary
Postdoctoral Fellow → Clinical Research Coordinators
DARE Officer → Police and Sheriff's Patrol Officers
Senator → Legislators
Comms Director → Public Relations Managers
dermatology → Dermatologists
commodities trader → Securities, Commodities, and Financial Services Sales Agents
life insurance adjuster → Claims Adjusters, Examiners, and Investigators
lumberjack → Fallers
cpa → Accountants and Auditors

It’s not perfect. I don’t think I would have normalized Postdoctoral Fellow to Clinical Research Coordinators. This is where decisions we made in constructing the model start to show themselves. All those aka job title concatenations we did at the top affected how the language was modeled. Depending on your use case this could be fine; maybe you just need deterministic finite categories. You can play with the embedding calculation process to see how different strategies yield different resules.

As for our nurses:

print(normalize("nurse"))
print(normalize("RN"))
print(normalize("MSN"))
print(normalize("ER Nurse"))
print(normalize("home health nursing"))

nurse → Registered Nurses
RN → Registered Nurses
MSN → Registered Nurses
ER Nurse → Registered Nurses
home health nursing → Registered Nurses

Language models are pretty good at modeling language!

If you’re unfamiliar with the puzzle, it was introduced by Douglas Hofstadter in his Pulitzer-winning book Gödel, Escher, Bach. The book explores how meaning can emerge from symbolic manipulation, and how formal systems like mathematics can be simultaneously powerful and fundamentally incomplete. The MU Puzzle, introduced early in the book, isn’t just a quirky game. It’s a microcosm of formal systems. It was designed to make you feel clever while gently exposing the limits of mechanical reasoning. And its rules are simple:

Suppose there are the symbols M, I, and U which can be combined to produce strings of symbols. The MU puzzle asks one to start with the axiomatic string MI and transform it into the string MU using any combination of the available transformation rules:

If you’ve never seen this puzzle before, you should stop for a few minutes and think on it. Grab a pen and paper and see what you can come up with. I’ve tucked the solution behind this spoiler:

I like to use the MU Puzzle as a model test because until now, I’ve never seen any GPT come to the correct answer. Some of them stumble into the expected answer but give flawed explanations. Others come to the wrong answer, usually by violating one of the rules. Even now, o3, currently billed as, “our most powerful reasoning model that pushes the frontier across coding, math, science, visual perception, and more” fails the puzzle.

When I give the puzzle to a model, I swap in different letters and present the rules conversationally. I do this to try to defend against the model regurgitation from GEB or Wikipedia. In my case, M becomes A, I becomes B, and U becomes C.

My prompt:

After thinking for 3 minutes and 11 seconds o3 declared victory:

See the problem?

Step Four violates Rule 3. After Step Three, the string is ABBBBBBBB. o3 then claimed to apply “Rule 3 – replaced the first ‘BBB’ with ‘C’” to yield ACBBBBBB. But it didn’t replace the first ‘BBB’. It only replaced the first ‘BB’.

This kind of error is characteristic of a broader failure mode seen across GPT models: a tendency toward approximate rule-matching rather than strict symbolic fidelity. The model recognizes the general shape of a rule, in this case, something about repeating Bs being collapsible, but it doesn’t reliably enforce the exact conditions. Instead of replacing a full BBB triplet, it replaced only two Bs, violating Rule 3 while still producing something that looks right. This isn’t just a hallucination; it’s more like a form of syntactic overgeneralization. It suggests that the model is reasoning through fuzzy analogies to rules, rather than maintaining crisp internal representations of symbolic constraints.

This is exactly the kind of reasoning Hofstadter warned about: systems that operate on syntactic structure without deeper semantic control can seem smart, until they aren’t.

The other bad answer I’ve seen is the model will try for a while, generating endlessly long strings, and then just give up. It’ll declare “unsolvable!” on the grounds of it tried for a while.

But o4-mini-high got it. After thinking for 1 minute and 40 seconds:

Not only is this the correct answer, but it’s the correct reasoning behind the answer.

Hofstadter used the MU Puzzle to demonstrate the contrast between interpretation on the syntactic level of symbols and on the semantic level of meanings. This seems very relevant to studying LLMs!

When dealing only in syntax there is nothing that would cause the LLM to infer the puzzle’s insolvability. It could churn away within the system, generating longer and longer valid strings, and never actually show that MU (or, AC) can’t be created.

If you’re like me, you probably tried a number of different iterations before eventually suspecting that the puzzle might not have a solution. Hofstadter referred to this as, “jumping out of the system”, the idea of reasoning about the system, rather than working within it. Depending on how long you toiled at the game, you might have discovered the ability (or inability) to divide by 3 is key to the process. And at that point, you would be thinking on the semantic level of the system.

Much of GEB is built around the idea of the MU Puzzle, and it’s used as a grounding point to explain Gödel’s Incompleteness Theorems. But an approachable explanation to its insolvability is:

• Our desired string contains zero Is; 0 is divisible by 3.
• Our starting string contains one I; 1 is not divisible by 3
• Only Rule 2 and Rule 3 change the number of Is.
• Rule 2 doubles the number of Is.
• Doubling a number that is not divisible by 3 does not make it divisible by 3.
• Rule 3 reduces the number of I by 3.
• Subtracting 3 from a number that is not divisible by 3 does not make it divisible by 3.

Since there is no series of transformations that make the number of Is divisible by 3, there is no series of transformations that produce MU.

Which is exactly what o4-mini-high said!

This echoes Hofstadter’s deeper point: the MU Puzzle is a toy model for Gödel’s Incompleteness Theorems. Within the formal system of applying the four rules mechanically, there’s no way to derive the string MU. But from outside the system, we can see and prove that no such derivation exists. The puzzle’s unsolvability is a true statement that cannot be proven from within the rules themselves. That’s Gödel’s move: constructing a statement that is unprovable from within the system, yet evidently true when viewed from a meta-level. What’s striking is that o4-mini-high not only refused to be tricked into endless symbol manipulation, but it also appeared to jumped to this higher level of reasoning — the “semantic” frame — and explained why the goal was unreachable.

I’m not claiming AGI. Maybe the tensors just memorized enough puzzles of this shape. But I’ve tested this one on dozens of models over the years, and this is the first time I’ve seen a GPT both identify the impossibility and explain why. I think that’s pretty cool.

Computers!

First, I wanted to quickly glance at 2023 vs 2024. For a little bit there, this Summer was cooler than last Summer. But then we had a pretty hot week in late August. Year over year, the Summer looks like it was generally cooler than last year, but the Fall has been slightly warmer:

But comparing two years doesn’t really reveal a trend (or lack of trend) so here are 2023 and 2024 highlighted over the previous ten years. It’s kindof a mess, like if Hulk Hogan couldn’t color within the lines. But if you squint you can somewhat pick out some insights.

So here’s the final viz I landed on. For most of the Winter and Spring, Austin was oscillating around its 10-year trailing average maximum daily temperature. Then as Summer hit, max temperatures dipped a little bit below average, spiked up in mid August, and then fell again slightly below average until September. From there we’ve been mostly above average!

As a final glimpse, we can see how many 2024 days (through December 23, my last day of available data) have crossed above the average max temperature, and how many days stayed below:

Above Average: 219
Below Average: 137

Thermometers!

If you managed to get a seat on the final night of the 2024 Democratic National Convention (I got there at 2:30 pm and still had to rely on seat-saving friends!) you probably also found an LED bracelet wrapped around your arm rest. I’m bad at remembering to take photos of things in the moment, so here’s mine over my kitchen counter:

If you’ve been to a large concert in recent years, you may have seen this before. It’s designed to give the audience an “immersive” experience with the entertainment,¹ usually by activating the lights at key moments. At the 2024 DNC, that key moment of audience activation was when Vice President Kamala Harris walked out to deliver her speech. I didn’t take a photo of the crowd during that time, but everyone lit up in twinkling red, white, and blue lights. It was fun.

I used to work on immersive audience engagement tech (that has since pivoted to retail payment tech), so I was curious how this worked. Luckily, I took the bracelet home so I could find out!

The first thing that caught my eye was PIXMOB engraved onto the back of the plastic case.

I had never heard of PIXMOB, but their website gives some immediate answers. Apparently they offer three different wristband products. All of them look identical so I wasn’t sure which one I had. My first thought — as is often the case when I’m trying to learn something election-related — was to dig through some FEC filings. I spotted in the PIXMOB Terms and Conditions that the company is actually called ESKI Inc. I spent only a few minutes clicking through the Democratic National Convention Committee’s expenditures without finding any mention of PIXMOB or ESKI. I suspect that the Convention Committee retained an events vendor that was a middleman to this hardware.

So I grabbed my Jimmy and cracked the thing open.

Like most consumer electronics, the thing is mostly battery! I actually wasn’t expecting AAAs, but it’s helpful to know we’re working with 3 volts and I can easily swap some in if they die.

At this point, I also had the PixMob Wikipedia page open (is it PIXMOB or PixMob?). It features another cracked PixMob wristband that was apparently used at Taylor Swift shows. That one also sported a white PCB, but used button cell batteries.

Besides the batteries, I also noticed that the Taylor Swift wristband listed a Palm (like palm tree) version number, while mine has a Diamond (like shiny carbon) version number:

They both have a copyright on them, too, and at some point I want to ask an IP attorney whether you can actually copyright a PCB or if you can only copyright their Gerber files. I would have guessed the appropriate protection would be a patent. I also just learned about the Semiconductor Chip Protection Act of 1984. But that’s a topic for another time.

I tried searching ESKI’s FCC filings for some more hints about the Diamond board, but didn’t find anything specific. But I did find some very interesting documents about an accompanying infrared transmitter. I bet those, or something like those, were all over the the arena.

Moving on, the next thing I noticed about my wristband is that it has four LEDs:

This means I probably have the PixMob X4, dubbed “our brightest wristband”.

Now that I knew what I was working with, I turned back to web search to see what prior work has happened with cracking and modding these things. Turns out, I’m not the first person to break one of these things open. There are so many videos of people getting these things to obey. And there are some really cool GitHub repos demonstrating how to use Arduinos or Flipper Zeros to replay actual IR instructions to the device.

At this point, I realized I wasn’t about to break any news with my teardown. But I wasn’t doing this to break news. I was doing this to break into the device. Also, I didn’t find anyone doing this with a Diamond board device. I wasn’t invested enough to turn this into SBC or microcontroller project. I just wanted to do a minimal mod. So I pushed forward. And by that I mean I started poking around.

That small, bulbous, semiconductor in the middle of the board is the Infrared Receiver. It can detect infrared signal, like those emitted from TV remotes. The PixMob website says that this wristband is, “infrared activated” so this seemed like a great entrypoint. I have no idea what kind of IR receiver it is, so I looked up the first one I could find on Sparkfun and consulted the datasheet. I learned a couple things:

• the three pins are , , and
• the pin is active low, which means its voltage drops when activated

There was no guarantee that my IR receiver also operated this way, but spoiler alert: it did!

I grabbed a jumper cable and touched one end to the IR’s pin and ran the other side across one of the LED’s cathodes:

Great. So the batteries still have some juice (a lot of posts suggested this thing would be dead by the time I got it home) and I know the polarity and pinouts of the LEDs. And all the LEDs are in series, so that’s nice. I also learned that the LEDs are interrupted in their path to ground, not their path to positive voltage, which is extra nice since the IR is active low. That means I can create a voltage drop from the LED’s anode to cathode by tying the cathode to , so when the IR receiver gets a signal and pulls low, the LED should light up. And so I did! I grabbed the first remote I could find in my living room, and pointed it at the receiver:

It blinks! You’ll notice that the LEDs aren’t as bright as when they had a direct jump to ground. That’s because is still higher than so the voltage difference is a lot smaller. Which means the light doesn’t get as bright.

That’s okay! This is a cheap crack and mod, so onward. After a bit more poking on the board, I found a surface-mounted resistor in series with the blue pinout from the LEDs. I soldered the IR signal jumper to that resistor, because we’re Team Blue.

Not my best work. I’m better at through-hole soldering. But it works!

I closed the case back up, shut myself in a windowless bathroom, turned off the lights,² and clicked my remote:

Now all I need to do is blast Beyoncé’s “Freedom” and I can relive the 2024 Democratic National Convention whenever I want.

I learned a lot!

I’m not donating via ActBlue anymore because they sell my data and I get spam.

This misunderstanding not only damages trust in one of our most important fundraising tools but also obscures where the real issue lies. It is true that your data is being sold. And it is true that you’re getting spam. But ActBlue didn’t sell your data because ActBlue doesn’t own your data. This is written all over their website:

Does ActBlue share my personal information, including email address and phone number?

We never sell or share your personal information with anyone beyond the group you gave to, and ActBlue will never text you.

Why am I receiving emails and/or texts from campaigns and organizations after chipping in on ActBlue?

We never sell or share your personal information with anyone beyond the group you gave to, and ActBlue will never text you. Even if you get a link to donate on ActBlue in a text or email, it comes from a group that uses our tools, not us.

How can I report unwanted communications from campaigns or organizations or a potential violation of ActBlue’s terms and policies?

When you donate using our platform, we do not sell your contact information or share it with third parties, except the group you donated to, or in certain circumstances, such as at your direction or when required by law.

And in the Privacy Policy:

ActBlue does not sell your contact information to third parties, and we don’t send solicitations, such as text messages or emails, on behalf of the individuals and organizations that use ActBlue for fundraising, including political committees and campaigns.

As someone who has built campaign tech infrastructure for two Democratic presidential nominees, I can confirm first-hand that the only data that campaigns are getting directly from ActBlue are the records of their own donors. Misunderstanding its role — or the role of any donoation processor — undermines our collective efforts.

Other campaigns are still getting your data. When you donate to the campaign of Candidate X through ActBlue, the campaign of Candidate X owns that data. ActBlue provides the data to them, and they are free to use it as they see fit. The campaign of Candidate X is often (but not always!) selling it to other campaigns and electoral organizations.

You can see it happening in FEC filings. Here’s the first example I plucked: Friends of John Delaney was the committee name of John Delaney’s 2020 presidential campaign. And here’s Schedule B (itemized disbursements) for one of their quarterly filings. Now smack CMD+F and search for List Purchase. You’ll spot voter data purchases from Boulton For Iowa, Heckroth For Congress, Hubbel For Governor, and Pete For Iowa (no, not that Pete).

Campaigns share data for all sorts of reasons. Sometimes their campaign is over and they want to be a team player. Sometimes their campaign is over and they have outstanding debts and they need some cash to balance the books. Sometimes they move from a primary to a general election cycle and they are working closely with the affiliated federal committee or state party through coordinated committees or victory funds.

But again, that’s not ActBlue’s doing.

💡 Quick aside: ActBlue is reporting donations to the Federal Election Commission, as is required in their role as a conduit for campaign funds. There’s been concern about the public availability of this data, but it’s important to note that it’s illegal for campaigns to use FEC data for solicitations:

To protect the privacy of individual contributors, the [Federal Election Campaign Act] prohibits the sale or use of any information about those donors, including their names and addresses, for the purpose of soliciting contributions or for commercial purposes. Commission regulations also prohibit the use of this information to solicit donations, including charitable donations.

One of my favorite “fun facts” about US election data is salting. Committees may sprinkle throughout — or, “salt” — each report with up to ten fictitious contributor names:

The committee itemizes each fictitious contribution on a Schedule A, providing a real address for each fictitious name (such as the address of a committee employee). The committee then adjusts its subtotals for itemized and unitemized contributions accordingly on the Detailed Summary Page. If a solicitation or commercial mailing is sent to one of the fictitious names, the committee will know that someone has used the names of contributors disclosed on its reports and may file a complaint with the FEC.

The FEC even made a #FECsplanation (rhymes with explanation) video about it:

Kinda neat that the federal government advises campaigns to honeypot their data.

Anyway, yeah, your data is being traded around between campaigns. So when you donate to some campaign in New York it’s possible it’ll land in the hands of some campaign in Utah. And I agree it’s a pretty crummy to get spammed with emails and texts from candidates you’ve never heard of from communities you’ve never even visited. But that’s not ActBlue’s fault.

Voters and donors don’t actually care which step in the data chain of custody is to blame for the barrage of irrelevant messages. But those of us who work on Democratic tech infrastructure sure do care.

Campaigns actually don’t want to waste money, resources, and time on poorly-performing lists. With the right infrastructure, smart campaigns are actually quite good at identifying and reaching likely supporters with effective messages. The problem isn’t a lack of intention, but rather the inconsistency and uneven distribution of infrastructure across the Democratic ecosystem. ActBlue is a very robust piece of Democratic infrastructure. That’s not where our focus should be for this problem.

Better infrastructure isn’t just a matter of efficiency. It’s a necessity for maintaining trust and engagement with supporters. When campaigns have access to robust, well-maintained systems, they can target their outreach more precisely, reducing the overreliance on broad, untargeted lists that lead to spam and voter disengagement. And it isn’t just about minimizing annoyance; it’s about maximizing impact and ensuring that every dollar spent and every message sent has the greatest possible chance of reaching and resonating with the right people.

The challenge is keeping that infrastructure viable cycle-over-cycle, and extending its reach across the entire Democratic landscape. As we work towards building smarter campaigns, it’s vital that we advocate for, and invest in, the infrastructure that ensures our outreach is both effective and respectful. We have a lot more work to do on that front.