Things I build at home

The taste profile is my existing library, which already encodes years of decisions about what is worth keeping. Candidates come from TMDb, a far larger catalog than I would ever browse. Claude scores each candidate against the profile from 1 to 10 and writes a one-line reason.

What it does with the score is the real design. Each source of recommendations climbs a trust ladder, trial to active to monitoring, and only earns the right to auto-add to my library once its earlier picks have actually been watched to the end. The completion signal comes from Tautulli, the playback layer, not from what I added to a list and never opened, because adding is aspirational and finishing is honest.

Each new event gets one Haiku call that returns structured fields plus a confidence score between 0 and 1, and that score does real work. Above 0.85 it resolves on its own. Between 0.6 and 0.85 it waits for me to confirm or fix. Below 0.6 it is still saved and flagged, never dropped, because a wrong guess I can correct beats an event I never see.

When I do fix one, the correction is stored, and recent corrections get fed back into the next Haiku call as examples, so it adapts to my patterns rather than getting generically better. Recurring events inherit the resolution through a stable identifier on the series, so the model runs once per series instead of once per occurrence.

For each metric it keeps a rolling 28-day window of my own history and asks whether today sits inside or outside my normal. The output is one of four tiers, normal, elevated, possibly fighting something, and likely sick, so the rest of my setup can act on a single signal instead of a wall of numbers.

Most of the work was in the gates, not the model. A reading has to stay off for about four hours before it counts, which kills single-bad-reading noise. An elevated heart rate right after a hard workout is explained away by that workout's own intensity score rather than read as illness. A drop in blood oxygen is the one signal allowed to escalate the tier quickly, because there a real change should not wait.

Before any model runs, plain queries assemble a tight packet: the last seven days of training summarized, an acute-versus-chronic load read, the current health tier from the system above, the day's weather, the equipment on hand, and how far I am from each goal. That packet, not raw data, is all Claude sees. It is small and factual, which keeps the reasoning grounded and the cost near nothing.

The two-level fatigue read is the input I lean on most. Acute load catches the cooked-today case. Chronic load catches the opposite failure, ramping up too fast or letting fitness slide, which a single day never shows. Competing goals are handed over as inputs, not rules, so a goal can bend around a bad week instead of a rule breaking the first time I am sick.

Plain string filters drop the obvious junk before any model runs, sponsored posts, duplicates, anything published before the last fetch. Noticing an ad is not worth a model call.

What survives gets scored by Haiku, the small fast model, on two axes from 1 to 10. Novelty is measured against what I have already seen this week, so yesterday's story rewritten drops out. Relevance is measured against me in particular: my work running knowledge and innovation at a law firm, the legal industry I sit in, the peer firms I keep an eye on, and the specific products, vendors, and models my teams might actually touch. A generic AI headline scores middling; the same development attached to a tool we use, or a move by a firm in our space, scores high. Once a day Sonnet, the slower model, writes a two or three line brief over the dozen or so top-scoring items, the only expensive call in the whole thing.

Those relevance rules live in a config file, not in the model and not in code. The file is where my world is written down, the topics, the peer firms, the vendors and models worth flagging. That is also what makes it easy to retune: adding a source or changing what counts as signal is a one-line edit, not a deploy.

Probes run on a timer and write observations onto one bus. Almost all of them produce nothing. A probe that finds the world in order says so quietly and moves on, so the only things that surface are exceptions, each with a severity and a plain sentence saying what is wrong and for how long.

The rule that made it useful is that severity decides who gets interrupted. Something actually broken becomes an active concern and reaches my phone. Something merely worth knowing goes into a feed I can ignore. Diluting the first category with news would have made the whole thing worthless within a week, which is the failure state of every dashboard I have ever abandoned.

The other rule is to alert on the age of the artifact, never on the status of the job that makes it. Backups are the clearest case. The job reported success for months while producing nothing, because one unreadable file made it exit in a way that looked like completion. Checking whether the newest backup is less than thirty hours old cannot be fooled that way. It asks about the thing I actually want, not about the machinery that is supposed to produce it.

One finding was worth the whole exercise. I had assumed a timestamp saying when something last changed was the same as how long it had been that way. It is not, because those timestamps reset when the system restarts. The lights that had been on for days reported sixteen hours, which means a naive watchdog would have been wrong in exactly the case it existed for.

Every room carries a short description of what it is actually measuring, and that description travels with the answer. Some rooms have radar and motion and a thermostat that notices people. Some have only a media player, which cannot detect a quiet person at all. That description is what lets a reader tell empty from unmeasured, and those are completely different facts.

Where a signal is known to lie in a particular direction, it says so rather than being quietly corrected. One sensor holds occupied long after a room empties, so its contribution is labelled as sticky, and you can see when it is the only thing making a claim. I left it in because removing it would trade false positives for false negatives, and a room going dark while someone sits in it is the worse failure.

Getting the timing right mattered more than adding sensors. A ten minute hold was sized for motion sensors, which go blind the moment you stop moving. Radar holds a still person by design, so on those rooms the long hold bought nothing and made walked through nine minutes ago look identical to standing there now.

The model is code rather than a mesh, and that is what makes the loop work. Every dimension is a named value with a comment saying why it is that number. When a measurement comes back different from what I assumed, the fix is one line instead of a remodel, so a second version takes minutes. One guard went from a one inch upright to a two inch upright on the strength of a single tape measurement, and nothing else had to change.

Photographs do most of the work a drawing would. A picture of the worn corner, with a tape measure in frame, gives both the shape of the problem and the two numbers that matter. Most of my early failures were not modelling failures, they were measurement failures, and the questions worth asking are always about the thing the part has to fit rather than the part itself.

The unglamorous half is the printer. Slicing without the desktop software silently fell back to defaults, so a plate that needed 55 degrees was heating to 35, and a profile labelled fine was quietly printing coarse. The printer's own errors pointed at the wrong thing twice. A job that hung for nine minutes blamed the filament system, when the real cause was a calibration step this model has no hardware to perform. Both are written down now, which is the only reason the second attempt at anything is quick.

Two failures taught me more than the successes. A part with thin snap arms broke the first time it was fitted, because the plastic is stiff and cracks rather than bending. A screw recess modelled at exactly the size of the screw head came out too small to take it, because printed holes shrink slightly. Neither is visible in a render. Both are obvious the moment you hold the thing.

The screen is a set of panels rather than a menu. Rooms, lights, scenes, media, and the 3D printer's camera and light, each one a tile you press. Pressing a tile calls into the house's automation system directly, so the cabinet holds no logic of its own. It is a control surface over the systems described above, which means anything I add elsewhere shows up here without the cabinet needing to know about it.

It changes what it shows depending on what is happening. Left alone it falls back to a clock. When a workout finishes downstairs, a debrief appears on the screen by itself, no button pressed, because the gym and the cabinet are the same room and that is the moment the summary is worth reading. The same debrief page also lands on the television in the gym.

And it still plays. The original cabinet's four games are on it, a button press away, which is the whole reason a cabinet is a better enclosure than a wall tablet. The house reports which mode it is in, so I can see from anywhere whether it is showing the dashboard or somebody is playing Galaga.

The Pi reports its own health back to the house rather than being watched from outside: temperature, load, uptime, and whether the chip has been throttled. That last one matters, because a Pi in a sealed wooden cabinet is a Pi in an oven, and slow throttling is the failure I would otherwise notice months late. The same rule as everywhere else applies. If the page stops serving, the house says so.