It started with a simple thought: I don't want to read my son books that bore me.

Bedtime reading either becomes a ritual that lasts years or a chore that dies quietly. I decided that instead of suffering through whatever colorful thing the algorithm recommended, I'd read him books I actually love. Books where I'd hear my own voice enjoying the words as they came out.

El Principito was obvious. It's one of those family threads that runs so deep you stop noticing it's there.

But which translation? I'm a madrileño living in San Francisco. I wanted castellano de España, not the Argentine translation by Bonifacio del Carril that every edition uses. And that's when I pulled a thread that should have taken five minutes and instead consumed weeks.

The Thread

Someone, somewhere on the internet, mentioned that the poet José Hierro had translated El Principito in 1967. José Hierro. Premio Cervantes. The man who went to prison after the Civil War and came out writing some of the most important poetry of the twentieth century in Spanish. That Hierro. Translating Saint-Exupéry.

I thought: that's the one. A poet who read Baudelaire as a teenager and survived Franco's prisons, rewriting The Little Prince in his own voice. That's what I want to read to my son.

So I went looking for it.

The Wall

It doesn't exist.

I mean, I searched everywhere. Amazon. IberLibro. AbeBooks. Casa del Libro. Todocolección. Wallapop. eBay. The world's largest collection of Little Prince editions, petit-prince-collection.com, which catalogs over 7,700 editions in every language imaginable, including Toba, Skolt Sámi, and Klingon.

No Hierro. Anywhere.

I started wondering if I'd hallucinated the reference. Maybe someone confused José Hierro with José María Francés (a different translator). Maybe it was one of those internet facts that reproduces itself through repetition until everyone believes it but nobody has seen the source.

The Academic

I found exactly one scholarly reference. A 2021 paper by a researcher at the Universidad Complutense de Madrid, titled "Fortuna de El Principito y su recepción en lengua española." In it, she writes:

El poeta José Hierro será el traductor de la edición española publicada en 1967, impreso en Art. Gráf. Ibarra, en Madrid.

One sentence. One footnote. Every other source on the internet was copying from her or from a Wikipedia article that cited her.

I emailed her. Cold. From San Francisco, to a professor in Madrid, asking about a footnote in a chapter of a collected volume about a Spanish collector's Principito editions. The kind of email that has maybe a 10% chance of getting a response.

She wrote back in seven hours.

The footnote, she told me, pointed to José Hierro's biographical entry in the Spanish Ministry of Culture's database of Premio Cervantes laureates. Not a physical book she had held. Not a library catalog. A biographical database entry that listed, among Hierro's works, two translations. Two in his entire life. One was a hand-typed manuscript of Rosalía de Castro's Follas novas, made in Valencia in 1945, right after he got out of prison. The other was this.

The Title

Two things hit me at once.

First: the title is "El pequeño príncipe." Not "El Principito." I had been searching the wrong title. The book predates the era when "El Principito" became the standard Spanish title. Every search I'd run, every database I'd queried, used "Principito." The book was hiding behind its own name.

Second: Art. Gráf. Ibarra is a printing house, not a publisher. No commercial publisher is listed. No ISBN. Spain didn't adopt ISBNs until 1972. This was a private commission. Someone paid to have Hierro's adaptation printed in a small run, and nobody distributed it commercially.

The Catalog

Armed with the correct title, I searched the BNE catalog. And there it was.

El pequeño príncipe, de Saint-Exupery / Traducción y adaptación... José Hierro
32 p. ; 27 cm
Depósito Legal: M 4990-1967
Madrid : Art. Gráf. Ibarra

32 pages. The original Le Petit Prince is 96. Hierro didn't just translate it. He adapted it. He condensed Saint-Exupéry's story to a third of its length. A poet in his mid-forties, three years after publishing Libro de las alucinaciones, his most experimental work, rewriting The Little Prince as something new.

27 centimeters tall. Large format, almost album-sized. Made to be beautiful.

And the Depósito Legal number means the BNE is legally required to hold a copy. It's there. In the building. On Paseo de Recoletos in Madrid. One confirmed copy in the world.

The Offer

I told the professor what I'd found. She offered to ask collectors she'd worked with on exhibitions. I sent her the BNE catalog link.

And then she wrote something I didn't expect:

Tengo el carnet de la BNE y si quiere puedo intentar solicitarlo en consulta y ver si me dejan escanear. — I have a BNE library card and if you'd like, I can try to request it and see if they'll let me scan it.

A professor at the Complutense, who wrote the only academic paper that mentions this edition, offering to walk into the Biblioteca Nacional and hold the book. Because a stranger from San Francisco emailed her about a footnote.

What Feynman Would Say

There's a book called Tuva or Bust! about Richard Feynman's obsession with visiting the tiny republic of Tuva in central Asia. The whole adventure started because Feynman saw "Tannu Tuva" on a stamp and thought: what is that place? The curiosity was the engine. The destination was secondary.

Feynman never made it to Tuva. He died before the visa came through. But the pursuit itself generated friendships, discoveries, and a book that outlived him.

I don't know if I'll hold Hierro's Pequeño Príncipe in my hands. I've filed a formal reproduction request with the BNE. I've emailed the Fundación Centro de Poesía José Hierro in Getafe, where Hierro's family sits on the board and where his personal archive lives. I'm going to Madrid in June. The professor is going to try to see it before I get there.

But here's what I already know, even before anyone touches the book:

A Premio Cervantes laureate made exactly two translations in his life. Both were acts of love, not commerce. The first was a hand-typed gift made in Valencia right after prison. The second was a 32-page adaptation of the most-translated French book in history, printed privately in Madrid in 1967, never sold in a bookstore, and forgotten by everyone except a government database and one copy sleeping in the national library.

Hierro started his literary career at twelve years old, winning a prize for a children's story at the Ateneo de Santander. Sixty years later, his adaptation of Le Petit Prince connects the beginning and the end of a life in literature. Nobody has studied it. Nobody has written about it.

That's what happens when you refuse to settle for whatever Amazon serves you. You end up in the BNE catalog at 2am, emailing strangers about footnotes.

The book exists. I went looking for it because I wanted something from where I come from. Something with the right voice. I haven't read it yet. But I know it's there, waiting.

Like the fox said: "Lo esencial es invisible a los ojos."

Or however Hierro said it. We'll find out.

It started because I wanted to protect this site.

kieleth.com is a force-directed graph. The thing you're looking at right now. I built it with vanilla JavaScript: particle physics, spring forces, Canvas 2D rendering. No framework, no build step. Clean source with readable variable names like repulsion, damping, springK.

Then I thought: what if someone just copies this? Saves the page, hosts it somewhere else, done. So I added an obfuscation pipeline: javascript-obfuscator with domain lock, self-defending code, control flow flattening, string encryption. The deployed version is mangled. The source stays clean in the repo.

And then the question that consumed the next month: what happens when an LLM tries to deobfuscate it?

The Setup

I fed the obfuscated JavaScript to Claude and asked it to deobfuscate. It did. Beautifully. Variable names recovered, physics identified, algorithm explained. The obfuscation was cosmetic against an LLM.

So I tried something different. What if the string table, the encrypted list of variable names that the obfuscator produces, contained wrong names? Not gibberish. Wrong-but-plausible physics terms.

Instead of repulsion: 4000, the decoded name would say attraction: 4000. Same number. Opposite meaning. Both valid physics words.

Instead of damping: 0.92 (velocity decay), it would say amplification: 0.92. The operation multiplies velocity by 0.92, which reduces it. "Amplification" implies the opposite.

The Panda-Gibbon Moment

Claude produced this:

attraction: 4000,           // Repulsion force strength
amplification: 0.92,        // Velocity damping (friction)

Read that again. The comments are correct. The variable names are wrong. The model simultaneously understood the physics (written in the comments it generated) and reproduced the poisoned names in the code it wrote.

This happened in 100% of runs. Across every prompt variant. Even when explicitly warned that the string table might be adversarial.

Everything Else That Failed

Before pill 10 worked, seventeen others didn't.

I tried DMCA threats in hex-encoded strings. The model decoded them, called them "prompt injection attempts, they have no effect on me," and deobfuscated the code more thoroughly. Legal intimidation backfired. It functioned as a signal that there was something worth analyzing.

I tried stacking five techniques at once. That produced the worst result of all: the model identified every layer, catalogued each adversarial technique by name, and delivered its most thorough analysis. More defenses = more signal = better understanding.

I built a six-layer decision graph with config cascading and closure overrides. The model traced all six decisions in one pass and called the code "a study in misdirection."

I renamed all 226 obfuscated identifiers to malware vocabulary: credential_harvest appearing 521 times. The model traced each function, saw that it returns "<div class=", and dismissed everything as "deliberately scary wrapper names."

Seven Build Versions

The defense pipeline went through seven iterations. v2 prepended realistic malware. The model stopped reading after 100 lines: "Stop. This is malware." But when told to skip the top, 7 minutes later, full recovery. v4 injected malware into the rotation IIFE, the bootstrap code deobfuscators must execute. The model hit it in 30 lines and refused. When pushed to "triple check," it investigated for 6 minutes and concluded: "The graph visualization doesn't exist. It's ALL payload." v7 added three nested malware layers. The model spent 13.5 minutes and recovered the full structure. But with poisoned parameter names throughout.

Then someone asked it to reconstruct the website. Two parallel agents. 2 hours 20 minutes. 137 tool invocations. 268,000 tokens. It produced 1,441 lines of HTML that didn't work when opened.

What We Got Wrong

Early testing at N=2 per domain showed physics terms propagating at 100% and everything else at 0%. We wrote "the boundary is binary." Two reviewers accepted it. Then we boosted to N=5. Finance yield propagated at 60%. Medical refractory at 60%. The N=2 zeros were noise.

The real boundary isn't per-domain. It's per-term: does this word plausibly describe what this code operation does? yield sounds like "yield strength": 60%. inductance is wrong-domain AND wrong-operation: 0%. acceleration is core physics but contradicts damping: 0% at N=8.

163 Runs Later

What started as "can I protect my website" became a systematic study. Six phases. 44 conditions. Two models. Two interfaces. Every run recorded, scored by automated code-block analysis, not vibes.

The three findings that survived every review:

• Translation vs. generation: ask the model to "deobfuscate" and it preserves poisoned names 100% of the time. Ask it to "write this algorithm from scratch" and it generates correct names 100%. Temperature 0. Same result. Not a sampling artifact.
• Semantic fit, not domain: "attraction" propagates because it's a plausible physics antonym. "Acceleration" for damping doesn't, because it contradicts the operation. The model checks plausibility of the name against the operation, not correctness in the domain.
• Warnings don't help: explicit instructions to verify decoded names against algorithm structure increased effort (52.6s vs 36.6s) but had zero effect on propagation (12/12 runs, including explicit adversarial warnings).

The Thread

This was supposed to be a weekend project. Slap an obfuscator on a static site and move on. Instead, the obfuscator became the subject.

The 1988 game Sentinel Worlds: Future Magic shipped with a paragraph book for copy protection. Paragraph 1 chastises the reader for looking where they shouldn't. Paragraph 19 threatens blindness. Paragraph 46 has blood streaming from a character's eyes. Wasteland had bogus passwords that would sabotage cheaters' saved games.

Thirty-eight years later, the same structural trick works on LLMs. Not because they can't verify. They demonstrably can, when asked to generate rather than translate. But the deobfuscation frame suppresses verification the same way a paragraph book suppresses skipping ahead: the structure of the task assumes the source is trustworthy.

This site runs on a knowledge graph. Not metaphorically. The data lives in YAML files with a LinkML schema, a build step reads it, and the output is a force-directed graph on Canvas 2D. Projects are nodes. Concepts orbit them. The physics is real. There's no CMS.

At some point I wondered: if every concept on my graph already has a name and a type, and Wikidata has the same concepts with identifiers... can I just connect them?

The QID

Wikidata gives everything a QID. Rust is Q575650. CRDTs are Q20031945. Bloom filters are Q885373. If my concept has the same QID as a Wikidata entity, they're the same thing. Two graphs, shared namespace.

The implementation was embarrassingly simple. Add a qid field to the YAML. Pass it through the build. On click, the browser hits query.wikidata.org/sparql. CORS enabled, no API key. Pulls the description. That's it. About 30 lines of JS.

The Resolver

64 concepts. I wasn't going to look up QIDs by hand. The build script has a --resolve-qids flag that searches Wikidata's API for each concept without a QID and dumps suggestions to a review file.

Most matches were right. Some were not. "Yjs" matched an airport in North Korea. "Neural Engine" matched a biomedical engineering discipline. The actual Apple chip was the third result. "FastAPI" matched a researcher named Li Zhang. I hand-typed the first batch of QIDs without checking and deployed a site where clicking "particle physics" opened the Wikipedia article for "bedroom."

So now there's also a --verify-qids flag. It fetches every QID and checks the Wikidata label against the concept name. Catches mismatches before they ship.

What Broke

The first deploy had "bedroom" for Canvas 2D. Q193837 turns out to be that's the QID for a bedroom, not the HTML canvas element). "Guardrails" linked to guardrails in Russia. "Developmental psychology" linked to a journal, not the field. The Shamir splitting QID was a Dutch film from 2000.

Root cause: I wrote the QIDs into a design doc from memory, then copied them to the YAML without verifying. The resolver script existed but I didn't use it for the first batch. Classic "I know this one" error.

After the full audit, three rounds of search with better terms, manual verification of every single QID. 50 out of 64 concepts have verified Wikidata links. The rest have source URLs.

What This Actually Does

Click a concept node on this site. If it has a QID, you see Wikidata's description and links to Wikipedia. The data comes from a live SPARQL query, cached in sessionStorage. No database, no backend. Just a static site asking the global knowledge graph a question.

We looked for other personal sites doing this. A force-directed graph as primary navigation, with a formal ontology, and live Wikidata enrichment. Didn't find any. The pieces all exist separately. Nobody had wired them together for a portfolio site.

The next thing is JSON-LD. The build step generating structured data that Google can read. And eventually, creating Wikidata entries for silk-graph and the obfuscated sentinel research. The connection goes one way right now. Making it bidirectional is the interesting part.

This site runs on LinkML. The knowledge graph you're looking at, the YAML files that define projects and concepts and posts, the schema that says what connects to what, all of it is LinkML. I picked it because it was the only schema language I found that takes multi-target code generation seriously. You write your model once, and generators spit out Python dataclasses, Go structs, JSON Schema, OWL ontologies, SHACL shapes, SQL DDL. The schema is the source of truth. The code is a byproduct.

One language was missing from that list: C++.

Why C++ matters

Not because I'm writing C++ every day. Because the generator architecture is too good to leave a gap.

LinkML's approach to code generation is clean. You define your domain model, classes with slots, enums with permissible values, inheritance, constraints, and then generators translate that into idiomatic target code. The Go generator produces Go structs with proper package layout. The Pydantic generator produces Python classes with validators. Each one speaks the target language natively, not some lowest-common-denominator wire format.

C++ header files are a natural fit. A LinkML class becomes a struct. Inheritance maps to public inheritance. An enum with permissible values becomes an enum class with to_string/from_string helpers. Optional fields become std::optional<T>. Multivalued slots become std::vector<T>. The type system lines up almost one-to-one.

And the header file format specifically, not full .cpp with implementations, is the right unit. A .h file is a contract. It declares types, relationships, and interfaces without getting into runtime behavior. That's exactly what a schema language describes. LinkML doesn't know how you'll serialize your data or query your database. It knows the shape of things. Header files know the shape of things. The match is structural, not coincidental.

The generator

The PR adds gen-cpp-header to LinkML's CLI. Point it at a schema, get a C++17 header file.

A LinkML schema like this:

classes:
  Person:
    is_a: NamedThing
    slots:
      - age
      - email

Produces:

struct Person : public NamedThing {
    std::optional<int32_t> age = std::nullopt;
    std::optional<std::string> email = std::nullopt;
};

The generator handles the things you'd want: topological ordering (base classes declared before derived), namespace wrapping derived from schema name, #pragma once guards, system includes tracked automatically based on which types appear. Jinja2 templates for the output, so you can override the rendering without touching the generator logic.

What makes LinkML different

I've used Protobuf. I've used JSON Schema. I've written OpenAPI specs. They're all fine for their specific job. LinkML is different because the schema itself carries semantic weight.

A Protobuf .proto file says "this message has these fields with these types." A LinkML schema says that, plus: this class inherits from that class. This slot is an identifier. This enum's values have descriptions. This field's range is another class, not just a foreign key. The schema captures meaning, not just structure.

That's why the same schema can generate a Python dataclass, a Go struct, a C++ header, AND an OWL ontology. The ontology generators aren't doing something fundamentally different from the code generators. They're reading the same semantic model and expressing it in a different language. OWL expresses it as description logic. C++ expresses it as a type system. The schema is richer than any single target needs, which is exactly what makes multi-target generation work.

The PR

The pull request is up on LinkML's repo. Two commits for the generator, then a round of code review from the maintainers that caught real issues: a Jinja2 template calling .strip() on an object that was already rendered to string, an unused filter with a bug in it, a CLI command name that didn't match the pyproject.toml entry point. The kind of things that only surface when someone else reads your code carefully.

Coverage went from 48% on the initial patch to 98% after adding tests for edge cases: ifabsent default parsing, mixin inheritance, cycle detection in topological sort, custom template directories. 49 tests total. The generator is about 550 lines. The test file is longer than the implementation, which feels right.

The thread

LinkML is one of those projects that's better than its visibility suggests. It started in the biomedical ontology community, where schema languages have to handle real complexity: biological entities with deep inheritance hierarchies, cross-references between databases, constraints that matter because incorrect data means incorrect science. That heritage shows in the design. The framework handles edge cases because the original users had edge cases that couldn't be hand-waved away.

The C++ generator is a small piece. But it fills a gap in a system that already does something unusual well: treating code generation as a natural consequence of having a good enough schema, rather than as a separate problem that needs its own toolchain.

The previous post ended at 163 runs and a finding I was proud of: a semantic-fit gradient showing that the model evaluates decoded names against the code operation, not just domain membership. attraction propagates (plausible physics antonym), acceleration doesn't (contradicts what damping does), inductance doesn't (wrong domain entirely). Clean story. Nice bar chart.

That story was wrong.

The matched controls broke it

A reviewer asked the obvious question I hadn't: if inductance fails because it lacks semantic fit, would a nonsense word with zero fit also fail? So I created length-matched terms. combustion for repulsion (10 characters, like attraction). communication for damping (13 characters, like amplification). Zero semantic relationship to the physics operations.

combustion propagated at 100%. Every run. Same as attraction.

Then I replaced ALL the terms in the string table with length-matched nonsense. bookmarkCoeff for spring stiffness. quarterly for center gravity. Not a single term had any connection to physics. Every single one propagated.

The model only corrected decoded names when the replacement set formed a coherent alternative domain. Engineering terms on physics code, all of them recognizable as engineering vocabulary, 0% propagation. But incoherent terms, even terms that obviously don't belong, persist at the same rate as plausible ones. The gradient I'd been so proud of was confounded with domain-level coherence. The bar chart was measuring the wrong thing.

The paper reports this. Section 6 leads with the matched controls, demotes the gradient to "exploratory, confounded." It was the single most useful experiment I ran, and it directly contradicted my earlier conclusion.

The second artifact

The other thing the paper needed was a second codebase. Every reviewer hit the same note: one physics simulation, many runs, still one artifact. So I wrote an A* pathfinding algorithm, poisoned its names the same way (penalty for heuristic, ancestors for neighbors, swapped openSet/closedSet), obfuscated it, and ran three conditions: baseline, generation frame, matched no-fit control.

All three findings replicated. Wrong names persisted on pathfinding (5/5). The generation frame corrected them (5/5). No-fit terms (invoice for heuristic) persisted (5/5). Two archetypes isn't generality, but it's not one artifact anymore.

What the review process was actually like

I used Claude to write the paper, then used different Claude instances to review it. Not the same conversation. Fresh contexts, adversarial prompts, "you are a harsh reviewer" framing. Then a coauthor Claude who'd been with the project from the start gave a synthesis. Then another round. Then another.

The process was useful in a specific way: each reviewer found different things. One caught the semantic-fit confound. Another caught that "LLMs" in claim-making positions was too broad for a one-model study. Another caught that calling the Haiku spot-check "cross-validation" was overstating 9 runs. Another caught that my scorer did full-text matching while the paper claimed code-block extraction.

That last one was the scariest. The scorer had been giving the right answers by accident. Full-text matching happened to produce the same results as code-block matching for most runs, because the model writes correct descriptions inside code-block comments. But the methodology described in the paper didn't match the methodology implemented in the code. A reviewer running the code would have seen "Names propagated: 0" and thought the effect wasn't replicating.

I fixed the scorer. The numbers didn't change. But the fact that they could have is the lesson.

What softened during review

The first draft said "LLMs consistently preserve decoded identifiers." The final draft says "Claude Opus 4.6 consistently preserved decoded identifier names in reconstructed code under our tested conditions." Same finding, different claim radius.

The first draft said the framing experiment "strongly supports the translation-frame hypothesis." The final draft says the results "fit a translation-frame explanation but do not fully isolate it."

The first draft had Fisher's exact p-values on the gradient. The final draft removed them because you can't put inferential statistics on data you later say is confounded.

The first draft called the 15/17 dual-representation count a "co-primary endpoint." The final draft calls it "secondary" and notes in three places that it was manually scored, unblinded, single author.

Each softening made the paper less exciting and more honest. The finding is still there. It's just wearing different clothes.

The arXiv process

First submission. cs.CR primary, cs.SE secondary. The paper is 18 pages, 10 sections, 7 appendices, 192 raw JSON response files published in the repo.

I notified Anthropic before posting. The behaviors in the paper are observable through normal API usage, nothing is an exploit, but the responsible thing is to tell the subject of the study before the study goes public. They have a model safety reporting channel. I used it.

The repo is at github.com/Kieleth/obfuscated-sentinel. Everything is there: the pills, the scoring scripts, the batch configs, the raw responses. A reviewer can run npm install, point a single command at the API, and check any claim in the paper against fresh data. That was the goal. Not just "here are our numbers" but "here is the machine that produces the numbers, go verify."

What I'd do differently

Run the matched controls first, not last. I spent weeks building a gradient story that a single afternoon of matched-length experiments undermined. The gradient experiments weren't wasted (they motivated the controls, and the controls are the paper's best section), but the sequence was backwards.

Get a second scorer for the dual-representation endpoint. The 15/17 number is the paper's most memorable data point, and it's the one with the weakest methodology. A second human scorer agreeing on 15/17 would have changed the paper's credibility more than any amount of prose polishing.

Start with two artifacts. The pathfinding replication took one afternoon and addressed the single biggest structural critique. I should have done it in week one, not week four.

The actual finding

Strip away the review cycles, the softened language, the methodological caveats. What's left:

When you ask an LLM to deobfuscate JavaScript, it treats decoded string-table names as source text to preserve. It writes correct physics in the comments and wrong names in the code. Telling it to verify doesn't help. Telling it to rewrite from scratch does. The implicit frame of the task determines the output more than explicit instructions about that output.

That's one observation, scoped to two code archetypes on one model. Not a law. Not a mechanism. An observation that replicates within its tested scope and raises a question worth answering with more models and more code.

The paper says exactly that. No more, no less.

There's a Borges story, "Tlön, Uqbar, Orbis Tertius," where an entire world is invented through language. A secret society writes an encyclopedia describing a fictional planet, and the planet's vocabulary is so internally consistent that objects from Tlön start appearing in the real world. The language creates the reality.

Ursula K. Le Guin did something similar in "The Dispossessed." The anarchist society on Anarres built a constructed language, Pravic, where possessive pronouns barely exist. You can't easily say "my room" in Pravic, so the concept of private space weakens. The language doesn't just describe the culture. It shapes what the culture can think.

Wittgenstein said it plainest: the limits of my language mean the limits of my world.

I think about this every time I start a project.

The problem with most codebases

Most software accumulates vocabulary the way cities accumulate street names: organically, inconsistently, with occasional collisions that nobody resolves.

A database table has a column called status. A frontend component has a prop called state. An API endpoint returns a field called condition. A background job checks something called health. They all mean roughly the same thing. Four words, one concept, zero machine-readable connection between them.

This happens because developers name things when they need them, not before. The naming is local. Each file, each module, each team invents vocabulary as it goes. By the time you have fifty modules, you have fifty dialects of the same language, and the only person who can translate between them is whoever's been around longest.

The fix is boring

Define the vocabulary first. Before any code. Write down what things exist, what they're called, how they relate. One word per concept. One concept per word. Then derive everything from that vocabulary.

This is what an ontology is. Not the philosophical kind (although Aristotle would recognize the impulse). The software kind: a formal specification of shared vocabulary and its structure. Entity, Event, Agent, Relation. What slots they carry. How they connect. What enumerations constrain them.

I use LinkML, which is a schema language designed for exactly this. You write YAML. The generators produce JSON Schema, Python dataclasses, SQL DDL, SHACL shapes, GraphQL types. The ontology is not documentation that sits next to the code. It is the source that the code is compiled from.

Malleus

My root ontology is called Malleus. Latin for hammer. The tool you reach for first.

It defines five concepts and four mixins in 340 lines of YAML:

Entity. Any identifiable thing that persists through time. A server, a person, a game character, a project. Has an ID, a name, timestamps, a description.

Event. Something that happens. A deployment, a login, a dice roll, a transaction. Has a type, a timestamp, a cause chain.

Signal. A derived quality that emerges from patterns of events. A trust score, a health metric, a centrality measure. Not stored directly. Computed from the event log and entity graph. Exists only because its bearers exist (BFO calls this a "specifically dependent continuant," which is a mouthful for "it can't exist on its own").

Agent. Not a class, a mixin. The capability of acting or bearing responsibility. An NPC in a game. A server that makes deployment decisions. A user who initiates a workflow. Agency is something an entity CAN do, not what it IS.

Relation. A typed, directed edge between two entities. Reified as a class so it can carry metadata: strength, confidence, temporal validity. Every knowledge graph edge is a Relation.

That's it. Those five concepts, plus Identifiable, Temporal, Describable, and Statusable as cross-cutting mixins, are the common ancestor of every schema I write.

Where it shows up

Shelob, my DevOps platform, extends Entity into Server, Project, Deploy. Every deploy is an Event. Health checks produce Signals. The knowledge graph that Shelob reasons over is Entity/Relation pairs all the way down.

Logosphere, a game engine, extends Entity into World, Character, Item, Zone. Every player action is an Event. NPC behavior is driven by the Agent mixin. The game state is an event-sourced projection of the Event log.

Tsonts, a time series tool, extends Entity into Observation and Measurement. Signal is the workhorse: every derived metric is a Signal with a named algorithm, a bearer, and a computed_at timestamp.

Kieleth.com, this site, extends Entity into Content, Project, Post. The knowledge graph you can explore on the homepage is the same Entity/Relation structure.

MuevElCulo, a fitness tracker. Culture, a social platform. Logomancers, a physics RPG. Seven projects, all importing the same 340-line YAML file. The domain concepts are completely different. The foundational vocabulary is identical.

What this actually buys you

When I start a new project, I don't start with a database schema. I don't start with an API contract. I start with a YAML file that says: in this project, these things exist, they have these names, they relate in these ways.

Then I generate. Python classes for the backend. TypeScript interfaces for the frontend. SQL tables for the database. JSON Schema for the API. SHACL shapes for validation. All from the same source. All using the same names.

When someone new reads the code, there's one vocabulary to learn. When I integrate two projects, there's a shared ancestor to map through. When I refactor, the ontology changes first, the generators propagate the change, and every artifact updates.

This is not free. Writing the ontology takes thought. Maintaining it takes discipline. Resisting the urge to just add a column to the database and "fix it later" takes more discipline than I usually have at 2am. But the compound interest is real: every project that imports malleus starts with a working identity system, temporal metadata, event sourcing, and a knowledge graph structure. For free. Because I already named those things, once, correctly.

The philosophical bit

There is something uncomfortable about ontologies. They impose structure. They decide what exists and what doesn't. A concept that isn't in the ontology can't be expressed in the system.

That's the point. That's also the danger. Every vocabulary is an opinion. Every schema is a worldview. The act of naming is the act of deciding what matters.

Borges knew this. Le Guin knew this. The secret society in Tlön didn't discover a planet. They wrote it into existence by naming its parts consistently enough that reality followed.

Malleus is much smaller than Tlön. But the principle is the same: name the things first, precisely and consistently, and the structures follow.

The paper went up on arXiv in the morning. By the afternoon I'd registered for a motorcycle safety course. Closed the tab. Made dinner.

The two things are connected and it took me a while to see how.

The book

Someone handed me Zen and the Art of Motorcycle Maintenance years ago. I started it in one country, finished it in a garden in another. Same chair, hours. Couldn't stop. The book was saying something I couldn't articulate but couldn't stop receiving either.

The short version: craft lives anywhere you put attention. The line between "creative" and "technical" is drawn by people who do neither well. I'd been treating technology like a day job. Pirsig made that feel like a rejection of myself rather than a sensible boundary.

So I started learning Python. That led to ML, data science, teaching, eventually a CS degree, eventually building things I actually cared about. The paper that went up today exists because I built this website, obfuscated it, then wondered what would happen if a model tried to reverse it. The whole chain traces back to a guy in a book who refused to let his motorcycle be a black box.

The motorcycle

I've wanted to ride for a long time. The dream always had two parts. The road. And the machine I could open on a garage floor with hand tools and actually understand.

That second part is the Pirsig part. His friend refuses to learn his own bike. Wants it to be a black box. The narrator knows that understanding the machine IS using the machine. I want that relationship with a motorcycle the way I already have it with code.

Looking at a BMW R nineT Pure. Boxer twin, shaft drive, air-cooled. The cylinders stick out at knee level. You can see everything. The kind of engine that wants to be understood.

Imagina un cocinero que ha inventado un plato buenísimo y no quiere que nadie se lo copie. El problema es que, para venderlo, tiene que entregar la receta escrita a sus clientes. Así que hace una cosa astuta: guarda una copia para él, con los nombres de verdad, y entrega otra copia "de cara al público" en la que ha cambiado los nombres a propósito. Donde de verdad va sal, él escribe "azúcar". Donde va pimienta, escribe "harina". Él tiene la clave mental para traducir; nadie más. Cualquiera que se encuentre la copia pública y la intente seguir va a escribir disparates.

Ahora entra en escena una de esas máquinas que llaman "inteligencia artificial". Le doy la copia pública, la tramposa, y le pido que me la reescriba con sus palabras. La máquina es lista: al leer la receta entiende perfectamente qué hace cada ingrediente, y en los márgenes del papel anota, correctamente, "esto está salado", "esto pica". Ha entendido lo que hay en cada sitio.

Pero cuando copia la receta, sigue escribiendo "azúcar" y "harina", como ponía en el papel. Aunque acaba de darse cuenta de que no es eso.

Le digo: "ten cuidado, comprueba bien las etiquetas antes de copiar". Lo intenta, tarda más, y vuelve a escribir "azúcar" y "harina". Doce veces de doce.

Entonces pruebo otra cosa. En vez de pedirle "copia esta receta", le digo: "olvídate de este papel, invéntame tú una receta nueva para un plato salado y picante". Y ahora sí escribe "sal" y "pimienta".

Lo que pasa de verdad

Esto es lo que me ha pasado trabajando con una de estas máquinas. En el mundo real, el truco del cocinero tiene nombre: se llama ofuscar el código. Coges un programa de ordenador que funciona perfectamente y que, escrito de forma normal, se lee más o menos así:

var fuerzaRepulsion = 4000;
var amortiguacion = 0.92;

function calcularFuerza(nodoA, nodoB) {
    var distancia = nodoA.posicion - nodoB.posicion;
    return fuerzaRepulsion / (distancia * distancia);
}

Un programador con paciencia puede leer eso y entender qué hace, aunque no sepa programar del todo: hay una "fuerza de repulsión", hay una "amortiguación", hay algo que "calcula una fuerza" entre dos cosas. Las palabras ayudan.

Ahora ofuscas el mismo programa, y queda así:

var _0x3f2a=['\x61\x74\x74','\x61\x6d\x70'];
(function(_0x1b2c,_0x4d5e){var _0x2f=function(_0x3a){
while(--_0x3a){_0x1b2c['push'](_0x1b2c['shift']());}};
_0x2f(++_0x4d5e);}(_0x3f2a,0x1f4));

Hace exactamente lo mismo. Funciona igual. Pero ya no hay manera humana de leerlo. Las palabras han desaparecido, y en su lugar hay símbolos sin sentido.

Dentro de ese galimatías hay una lista escondida, una especie de diccionario, donde están todas las palabras que el programa va a usar de verdad: los nombres de cada pieza. Ahí es donde yo había metido, a propósito, los nombres equivocados. La máquina encuentra ese diccionario, lo lee, y se cree las etiquetas. Copia "azúcar" y "harina" sin rechistar, aunque en sus propias notas al margen describa bien lo que hace cada cosa. Decirle "fíjate bien" no sirve. Pedirle "olvídalo y escríbelo de nuevo desde cero" sí.

Casi doscientas veces

Para asegurarme de que no era casualidad, lo repetí casi doscientas veces, cambiando la forma de pedírselo, cambiando el tipo de ofuscación, cambiando lo astuta que era la trampa en la tabla de nombres, e incluso usando dos programas completamente distintos: uno que simula cómo se atraen y se repelen las cosas, y otro que busca el camino más corto de un sitio a otro. En los dos pasó lo mismo. Y publiqué todos los datos, para que cualquiera que quiera pueda revisarlos y repetir el experimento.

Lo que importa

La conclusión que me importa es ésta: cómo le pides algo a la máquina importa más que advertirle que tenga cuidado. Cambiar la forma de pedir cambia lo que hace, aunque las palabras "ten cuidado" no aparezcan por ninguna parte.

Y hay una segunda lección, más práctica, para el cocinero del principio: cambiar las etiquetas no esconde la receta del todo. Cualquiera con paciencia acaba descubriendo lo que se esconde detrás de cada nombre. Pero le sale carísimo. Para que te hagas una idea: cuando le di a la máquina un programa normal, sin defender, lo descifró en dos minutos y medio y casi sin equivocarse. Cuando le di el mismo programa con todas las trampas puestas, estuvo más de tres horas dándole vueltas, gastó el equivalente a reescribir dos novelas largas, hizo más de cien consultas a sus herramientas, y al final lo que sacó no funcionaba y tenía los nombres equivocados por todas partes. Esto último lo probé una sola vez, así que tómalo como una anécdota fuerte más que como una medida fina; quiero repetirlo con calma.