On November 4th I got to stand up in front of a room at ODSC AI West in San Francisco and give a talk called Context Is the Team: How Graph Ontologies Let a Solo Engineer Ship Across Dams, Education, and Oil Wells. That's a mouthful of a title, so to make a long story short, it's about how one guy and a coding agent managed to ship software this year in three industries that have absolutely nothing to do with each other, and why I think the reason it worked has very little to do with which model I was using.

If you've read anything I've written before, you know I didn't come to software the normal way. I was a Marine, then a security contractor, then a federal agent, then an oil field hand, and somewhere in there I started automating the data entry that was driving me crazy and never really stopped. The thing all of those jobs had in common, besides bad tools, is that I was never alone. On every crew I've ever been on somebody had your back and somebody caught what you missed. These days my crew is me and a coding agent, so the question I kept coming back to while putting this talk together was a simple one. What replaces the crew?

Starting with a river

I didn't open the talk with code, I opened it with the Blanco River. In May of 2015 the river at Wimberley went from about 5 feet at 9 p.m. to about 41 feet by 1 a.m., and the question a flood monitoring system exists to answer is, how much warning do we have?

Now, I'm not a hydrologist. Before I could write anything useful I had to learn the language, and I mean that pretty literally. I asked the LLM a lot of dumb questions, it read the data and asked me questions right back, and where neither of us knew the answer I went and asked the people who watch that river for a living. A stage isn't how deep the water is, it's the height of the water's surface against a gauge's reference point. A forecast crest is a prediction with a time attached to it. And flood stage isn't a number that belongs to the river, it belongs to one specific forecast point. At Wimberley it's 13 feet, and you'd never guess that. Somebody has to tell you.

Here's the example I used to show what knowing one rule is worth. Say it's noon and the gauge reads 11 feet. The gauges upstream are rising and we know how long the water takes to travel between them, so the forecast says the river will crest at 18 feet at 4 p.m. (I made those numbers up for teaching, the 13 feet is real.) Software that doesn't know the domain looks at that and asks, is 11 higher than 13? Nope, no warning. Software that's been taught that a forecast at flood stage is flooding that just hasn't shown up yet warns people at noon. That's four hours. An ontology doesn't stop a flood, but it does stop your software from throwing away a warning.

Crayons and glue

Way back in 2018 I wrote a post called ES6 Destructuring with Crayons, and if you don't know the joke, suffice to say Marines are assumed to be dumb enough that eating crayons and glue is something we do. I've been out of the Marine Corps a long time now, but when I really want to understand something I still break it down crayon style, and it turns out this crayon chomping former jarhead had been building ontologies for years without knowing the fancy name for it. It's three steps. Name the things. Draw the connections. Write down the rules, and why they exist.

My thinking is that if I can make something clear enough for a person, I can make it clear enough for a coding agent. Write those three things down in a file the model can actually act on, and the formal name for what you've got is an ontology.

I'd love to tell you I figured that out right away. I didn't. What I actually did first was correct the model. The same terms, the same relationships, the same rules, explained over and over on every single change. I assumed it kept forgetting, and since I've spent years working with Neo4j, I naturally reached for a graph and built it a memory. Several versions of one, actually. And the recall was good! It remembered what we'd talked about just fine. I still had to correct what it understood. Memory gave the model our history, it didn't give it the language.

Same move, different language

The river turned out to be about intent. What a forecast is for decided what the code had to hold on to. The oil and gas land work is about history. If you've been reading me for a while you might remember The Tipping Point, where I first posted a graph of the relationships between mineral owners and the oil companies leasing from them. Same problem, eight years later. Who owns what today only means something if you can trace how they came to own it, and the best way I know to explain that is to let you watch one family's interests change over time.

If I handed you the final number at the end of that video with none of the history, you couldn't tell me whether it was right, and neither can the model. The third domain is higher education and alumni outcomes, which I'm not going to get into here other than to say it was another language, another ontology, and the exact same method.

Writing it down wasn't enough

Here's where I found out I wasn't done. A well is really just a series of holes. Each hole is narrower than the one above it, each one starts where the last one ended, and the casing you run into a hole has to be smaller than that hole. That last one seems too obvious to say out loud. I wrote it down anyway, handed the model the ontology, and it still happily accepted casing that was bigger than the hole it was going into.

So, lesson two, a description the model can read isn't the same thing as a check the model can't skip. I come from work where a missed step gets somebody hurt, and in that world we have lockout/tagout. The tag tells you not to operate the equipment. The lock physically stops you. Smart people still get interrupted and still carry five things around in their heads, which is why there's a lock and not just a tag.

Now every rule in my ontologies names the test that enforces it, and for the casing rule that test is about as unexciting as code gets:

expect(fitsHole(15, 15)).toBe(false);

Equal diameters don't fit, and that answer comes from the domain and gets written down before the code does, not from whatever the model felt like writing. Then I use Claude Code's hooks to hold the model to it at three points: when a session starts, after every edit, and before the turn is allowed to end. If a rule's test fails, the turn gets blocked and the model gets the rule read back to it. Like I told the room, the model is persuasive, the gate is not. In the interest of honesty, local hooks can be bypassed, so the required check in CI is the real lock and the hooks are the tag.

So what replaced the crew?

The ontology is the senior hand, the one who corrects your understanding before the work starts. The gate is the lock, the teammate who can't forget and who catches the mistake when nobody's looking. I used to correct the model constantly and now I step in every once in a while. That's just my experience, I don't have a benchmark to wave at you. I also still define the work and review the result, and that part doesn't get handed off to anybody.

After the talk I got to field questions and then spent a good chunk of the day mingling.

Everything from the talk lives in one repo: the skill that builds the ontology, the hooks, and the Claude Code mod that shows you the checks while you work. If you only take one thing away, think of the correction you keep making to your own agent. Write down the rule and why it matters, find an example that breaks it, and decide where the check has to run. Start small enough that you could explain it with crayons.

Thanks for taking the time to give it a read. May your crayons always be fresh and your glue always be Elmer's.