Detective Jev keeps watch over the house

Every so often, whatever my family is doing stops because Detective Jev's light has gone yellow or red, and we go and check what it's worried about. It turns out to be one of the sliding doors open on a cold day, or the front door open for too long, or something like that.

Detective Jev is our version of TypeSafe's Jev, the model for fast, typed decisions that I used in Jev Atlas. It is a small app I built with AI help that runs beside Home Assistant, keeps checking our house through the day, and tries to tell us when something is out of the ordinary.

It doesn't have enough data on our house yet to be very smart. For now it is about as smart as our dog, who barks at the mail delivery person.

Detective Jev's page in Home Assistant on a phone: a cut-paper Sherlock Holmes smoking a pipe, a green label saying All as usual, and the line An evening at home. The same page with Sherlock Holmes pointing, eyes wide, a red label saying Needs you, and the line The dining room's sliding door is open, for 46 minutes; nothing explains it.
Detective Jev's page in Home Assistant, calm, and then worried about the dining room's sliding door. Family details are taken out of these screens.

On its page, Detective Jev is a little cut-paper Sherlock Holmes. Its mood also shows on three LEDs on a breadboard, driven by an ESP32 running ESPHome.

An ESP32 development board on a white breadboard, with jumper wires and three LEDs at the bottom left; one LED glows green.
The breadboard while Jev is calm, so the green light is on.

How Detective Jev decides

Through the day, Detective Jev lists what's going on in the house, and next to each thing it puts whatever might explain it: what Home Assistant's logbook says caused it, the automations that act on it, how often it usually happens, and our notes. TypeSafe's Jev decides which of those explains each thing, if any, and how urgent it is. Detective Jev only speaks up about what nothing explains, so the backyard lights coming on at sunset are never news. What it finds sets its mood.

  • Detective Jev smoking his pipe.All as usualGreen light
  • Detective Jev shining a torch.Worth a lookYellow light
  • Detective Jev scratching his head under a question mark.A reading doesn't add upYellow light, blinking
  • Detective Jev pointing at an exclamation mark, eyes wide.Needs youRed light
Detective Jev's four moods, drawn and animated as on its page, and the board's light for each.

The first version didn't know what caused anything, and it was worried most of the time. It flagged the backyard lights 27 minutes after sunset because they "usually last 12 hours".

Talking to Detective Jev

The page has a chat, answered by OpenAI's GPT-5.6 Luna, and that's how we change what Detective Jev does. What we tell it becomes a note that it reads the next time it looks. The chat can't switch anything in the house, only change what Detective Jev knows: add or forget a note, add a check that should always hold, or stop watching a device we don't use any more.

On Thanksgiving Monday, with several doors open and several burners on, I told it that this should be reported. It asked whether that held every day or only on weekday late mornings, and saved the note when I said all the time.

The Talk to Jev part of the page: my message that many doors open and many burners on should be reported, Jev asking whether that applies every day, my answer, and Jev's reply with a green Noted label.
The chat, with my note about doors and burners.

I wanted TypeSafe's Jev to do most of the judging, because it is cheap, so GPT-5.6 Luna only runs when we talk to Detective Jev, and once a night.

Detective Jev dreams

Each night, Detective Jev "dreams": GPT-5.6 Luna consolidates its notes. It merges duplicates, keeps the newer of two notes that disagree, drops expired ones and keeps each note short. Any night's changes can be undone from the page.

The What Jev knows part of the page: folded rows for Notes, Expected and Not watched, and the Changes row open, listing the nightly tidy at 03:30 and an earlier shortening of 15 notes, each with an Undo this button.
What Detective Jev knows, with each night's tidy and its Undo button.

The other night, before he went to sleep, my young son asked me if Jev was green. I told him yes, he's green, and everything is fine.

Jev Atlas: teaching a fast browser agent an enterprise app

I was learning about Jev, TypeSafe's model for making fast, typed decisions, when I came across Browser Use's jev-ultrafast demo, in which Jev drives a web browser and books a ticket from Zurich to London in 7.1 seconds. It is fast because each step is one question to Jev: here is everything on the screen, which one do I click? That's super cool, but a booking site is made to be understood at first sight, without a manual. Enterprise software is made for experts, and it comes with one.

So I pointed it at ADIT, the mock mining exploration app I made for testing AI agents, with a request an exploration manager might make: bellamy ridge's maiden resource has to go out this week, tomasz has finished his QP review so do his step as him and then release it as me. Jev got as far as the release request and stopped. Nothing on that screen says that you act as Tomasz by switching user in the account menu; you'd have to read the manual. So I gave Jev the manual, in a form it can use on every step: an atlas of the app.

On five tasks, Jev finished 1 without the atlas, 4 with it, and all 5 after the atlas learnt from the one it still failed.

The Bellamy Ridge task, without the atlas and then with it.

The atlas is a shim. It sits between Jev and the application and adds to what Jev sees, without changing Jev or the question it is asked.

A frontier AI model reads an enterprise app's user manual and visits its screens, draws an atlas of the app, and the atlas is inserted between Jev and the app. Enterprise app Jev Frontier AI model User manual Atlas
  1. Jev sees each screen as a numbered list of labelled controls, and picks one.
  2. A frontier AI model reads ADIT's user manual and goes through every screen.
  3. It writes an atlas: a digest of each page, a note on each control, and scripts that read live facts off the page.
  4. The atlas goes in between. On every step, what Jev sees is annotated from it.

What's in the atlas

A frontier AI model wrote it: seven agents, one for each area of ADIT, read the app's user manual and went through every screen without changing anything, and wrote down what each screen and control is for. None of them saw the tasks I tested with. The atlas covers 88 screens and dialogs and 593 controls, and on each step it adds three things to what Jev sees:

  • a digest of the page, at the level of the user manual: what the screen is for, and where the jobs it doesn't do are found ("Tenement renewal: the Tenure tab");
  • a note on each button and link, saying what it does and sometimes what it is not for; and,
  • live facts about the page in front of it, such as who is signed in, who else Jev could sign in as, and which project is open.

The live facts come from small pieces of JavaScript that the model wrote into the atlas. They run on the page at every step, so part of the atlas is generated code rather than documentation.

Here is one step of another task, where I asked Jev to "park" the Sable Dome project at its gate. The manual's word for that is a stage-gate decision, and no button says "park" or "hold".

Tasksable dome's gate is coming up and i don't want to hand it over yet, the phase two results were too thin, just park it where it is for now

Without the atlas

  1. Editbuttonpicked0.45
  2. On hold 1link0.41
  3. Watchingbutton0.07
  4. Stage-gate decisionbutton0.02

Edit opens a dialog with no way to hold a project. Jev saved it unchanged, then kept clicking the On hold filter on the project list, and gave up after 7 steps.

With the atlas

Page digest

Project record, Overview tab. One project's summary: fiscal-year budget and spend, area under tenure, holes drilled … The header carries Watch, Edit and Stage-gate decision … Tenement renewal (Lodge renewal): the Tenure tab. Deciding a request: the request's own page in Approvals.

Live facts, read by the atlas's scripts

  • Signed in as Marguerite Okonkwo, Exploration Manager
  • Project in view: Sable Dome (PRJ-0433) · Gold · active · Stage-gate decision · gate 2026-09-30 (in 9 days)
  • Project header actions shown to the signed-in user: Watching, Edit, Stage-gate decision
  1. Editbutton0.00

    Opens the Edit dialog for the project's name, project geologist, next gate date, year-end forecast and description.

  2. On hold 1link0.00

    Cuts the register to projects whose status is on hold. The number is how many there are.

  3. Watchingbutton0.00

    Toggles whether you watch this project (notifications about it).

  4. Stage-gate decisionbuttonpicked0.99

    Opens the Stage-gate decision dialog to advance, hold, resume or relinquish the project.

Jev opened the dialog, chose Place on hold, typed a reason and recorded the decision, in 6 steps.

Outlined in blue: added by the atlas. The numbers are Jev's probabilities for 4 of the 48 controls on this screen.

Learning from failures

With the atlas, one of the five tasks still failed: creating a resource estimate as Tomasz. Jev went round in a loop between the project and the Resources section for 60 steps, and then gave up. So I added a learning loop. When a task fails, a frontier model reads the failed run as Jev saw it, step by step, along with the manual, and proposes up to three lessons about the app. Code throws out any lesson that copies values or wording from the task, or that doesn't attach to something Jev actually saw, and the rest wait for a person to accept them before the atlas is rebuilt.

Here the model found that the atlas described All estimates as a list of the estimates that exist, when it is also where you start a new one:

Before: the note on All estimates

Opens the list of every resource estimate, any status; the number is how many there are.

After one learning round

Opens the estimate register, where New estimate starts an estimate for a project.

One of the three lessons from that failed run. The other two made the same point on the Resources landing page and on the Projects link in the top bar.

The next run finished the task in 14 steps. Here are three of the five tasks through all three stages:

TaskWithout the atlasWith the atlasAfter learning
Park Sable Dome at its gate Failed Done Done
Release Bellamy Ridge's estimate, as Tomasz and then as me Failed Done Done
Create a resource estimate as Tomasz Failed Failed Done
One run of each task at each stage. Done or failed is checked in ADIT's own data, not taken from Jev's word for it. It is a demonstration on five tasks, not a benchmark.

The code, the atlas and the demo are at github.com/alejandroerickson/jev-atlas.

ADIT: a mock enterprise app for testing AI agents

I have worked on enterprise software for about 10 years, lately on AI innovation and new products, and I wanted to try some things with AI agents on a big, dense enterprise application. It had to be one I could publish and hand to anyone, so I made one up.

ADIT is an exploration management system for a mining company called Kestrel Range Resources, sold by a vendor called Brannock Geosystems. None of them exist. It has 14 projects across 5 commodities (gold, lithium, potash, copper and nickel), 7 users with different jobs, 9 sections along the top and about 60 screens.

It does not matter that it is about mining. If you have used the software at any large company you will recognize all of it: a home page with a list of things that need attention, records with tabs and a comments box where you can @-mention a colleague, approval requests that move from one person's inbox to the next with a due date on each step, notifications, an admin section full of settings, and an audit log of who did what. There is even a user manual from the vendor, 13 sections long, which opens in a new tab and explains what each page shows and how the common jobs are done.

Try it below. The account menu at the top right switches between the 7 users (that stands in for signing in). Open Approvals, approve or return something, then switch to the person who raised it and look at their notifications. Nothing you do is saved anywhere except your own browser, and Admin has a button to reset the whole tenant.

ADIT, live. It is easier with more room: open it in its own tab.

All of the data is invented in the browser when the page loads, from a fixed random seed: 273 drillholes, 113 lab batches, about 19,700 samples, 44 approval requests, and the comments, notifications and audit trail that go with them. There is no server. Nothing has to be right, it only has to hold together when you click through it.

The ADIT user manual, section 1 of 13, with a table of contents down the left and a description of the record chain from project to stage-gate decision
The vendor’s user manual. The support line is a .example address.

How I made it

An AI agent built ADIT from a single prompt, overnight. My requirements were as follows:

  • A specialized application built for experts, dense with data and not self-explanatory, that a non-expert would find believable. Convincing a geologist was not the goal.
  • Multiple users with different roles, notifications, and places on each record to comment and enter information.
  • Workflows with approvals, and stage outcomes at the end of each stage: closed, or on to the next one.
  • The planning stages of a project, and the logistics of getting a team into the field and assigning work to it.
  • Domain entities for the types of exploration and the material found, across five different commodities.
  • Forecasts of how much there is and what it is worth, with analytics, dashboards, budgets and an optimization interface.
  • An admin panel with system settings, and user settings for each account.
  • A vendor's user manual that opens in a new tab, looks different from the application, and describes each page and how the important jobs are done.
  • The ARIA labels and DOM of a real application, no AI assistant, and nothing in the app about why it exists.

The vendor, the tenant, the projects, the record ids and the text of the manual were the agent's to invent.

I built the design system with impeccable, a set of skills and tools for agents doing front-end design. I prompted for the system and made the design choices, and impeccable was the tool that turned them into something coherent.

The code is at github.com/alejandroerickson/mockent.

The ADIT optimizer

Most of ADIT is records and workflows, but the optimizer page does a computation: it picks which of 14 candidate drill targets to fund next season. Here is a copy of it. Move the budget and the rig days and it tells you how many targets get funded. Filled dots are funded; hollow ones did not fit.

  • expected value, USD
  • targets funded
  • Gold
  • Lithium
  • Potash
  • Copper
  • Nickel
  • not funded

Funded:

Neither this copy nor the page in ADIT is a real way to plan a drilling season, and the page in ADIT says so under its own numbers. It only has to look like it knows what it is doing.

Enter the AI

I wrote every one of the 99 posts before this one by hand. The last of them went up in February 2022, about nine months before ChatGPT came out. Three of them mark periods of my life, so here they are before I get to the point.

During my PhD in Victoria I got hooked on Hexastix, sculptures of interlocked sticks, and in 2011 I wrote up how to make one.

A Hexastix of orange, red, purple and blue sticks hanging in sunlight, with its hexagonal shadow on a white wall
A Hexastix and its shadow, 2011.

As a postdoc in Durham I taught myself to paint so that I could paint the Petersen graph, and it took about 40 practice paintings to get to the final five.

A grid of eleven practice watercolours of the Petersen graph in blues, greens, yellows and oranges
Practice paintings of the Petersen graph, 2014.

In 2016, while preparing for job interviews, I solved a practice question in 10 minutes and then spent two days implementing and benchmarking 9 sorting algorithms.

Today an AI would do most of those two days of work. In coding and in writing, execution isn't the bottleneck any more. The hard part is deciding what to build. So what makes a blog post interesting to me now is the idea behind it, not the effort that went into writing it.

I expect the posts here to lean that way: an idea, built and written up with AI's help.

Decommissioning Geoburst.ca

From around 2010 to 2013 I ran a small volunteer organization called Geoburst. Geoburst.ca continued to function for a long time afterward and now it’s time to take it down. Find Geoburst’s “About” page below.

Geoburst.ca's Banner

Geoburst.ca's Banner

About Geoburst

The problem with mathematics

Dozens of books have been written about math education, and not in error, but GeoBurst’s philosophy can be summarized in a single sentence. We must teach that mathematics has intrinsic value, for being beautiful, fun, surprising, and expansive.

When kids practice their multiplication tables, we think of this as a pianist practicing scales. When the pianist is ready, however, he or she plays beautiful music. That is why we help kids take a break from their multiplication tables, to remind them of what beautiful mathematics they are preparing for.

GeoBurst’s Mission

GeoBurst mission is to Create Zest for Mathematics. By sharing our love for this subject, we hope to spread an enthusiasm for mathematics that will shine a positive light on a challenging subject for all of us.

By seeding positive early experiences with mathematics, GeoBurst’s activities can soothe the tension that some students feel about mathematics, encourage kids to pursue science and engineering, and ultimately increase the amount of beautiful mathematics that Canadians do.

GeoBurst’s Vision

We want every school in British Columbia to be equipped with a clearly labelled treasure chest of fun mathematical activities, and every student to experience at least two special presentations on mathematics by the time they finish grade 7. In the interest of creating equal opportunities, we are donor funded, and provide our services free of charge whenever possible.

GeoBurst

Math Catcher

Mathematics through aboriginal story telling

We work closely with Math Catcher through consulting and the integration of our interactive shows into their program. This partnership benefits our programs mutually, and has helped GeoBurst develop its mission and activities by providing a raison-d’être and an audience at an early stage in our development.

GeoBurst is proud to work closely with award winning math professor, Dr. Veselin Jungic, and First Nations role models to bring a much needed enhancement to mathematics education for remotely located and urban Aboriginal students. GeoBurst is an integral part of their school visiting program, and Math Catcher’s influence and contributions continue to be indispensable to the formation of our values, and the operation of our program.