Magatama, From the Beginning, Part 5: More Ways to Close a Finding Than I Remembered

Part four ended with a decision to force as much of Magatama's own reasoning to stay local as possible by default, because the biggest risk left on the table was judgment quietly leaving the house without anyone noticing. This part picks up a few weeks after that shipped, with a smaller decision that got tested a lot faster than I expected.

Watching NOGnet's own security center

NOGnet is a separate project of mine, an event-support platform I built for network operator group organizers, and it has its own security center baked in: backup-integrity checks, baseline-file monitoring, access-control checks, a running tally of abuse and ban activity. This week I wired Magatama into it. On a short interval, Magatama polls that security center, reads whatever checks are currently unhappy, and turns each one into a finding inside its own system, the same findings pipeline that already covers everything else Magatama watches.

Most of those findings behave the way Magatama's findings have always behaved. NOGnet reports a problem, Magatama opens a finding. NOGnet reports the problem cleared, Magatama closes it. No review needed for the routine cases, which was the entire point of gating execution back in part two: let the boring stuff move on its own, and save my attention for the parts that deserve it.

One category got carved out on purpose. NOGnet keeps a tamper-evident audit trail of security-relevant events, and it can flag when something about that trail looks wrong. Findings in that category never auto-resolve. Not when NOGnet reports the underlying issue is clear, not ever. Magatama can diagnose what it sees and describe it, but closing the loop is off limits; the finding stays open until I review it myself, inside NOGnet's own interface. Given everything the previous four parts were about, that felt like the obvious default rather than an extra precaution. Getting an automatic all-clear wrong on a normal finding costs me a little time. Getting it wrong on the record of security events costs me the one thing I'd need to reconstruct what happened in the first place.

That shipped. Within days, I found a real bug in it, live in production, on exactly the finding type it was supposed to protect.

A finding in the never-auto-resolve category got created, and roughly a minute later its state flipped to resolved. Nothing in the code I'd written for this integration should have touched it. I only caught it because I happened to be watching the raw data underneath the finding and saw the change with no obvious cause attached to it. Luck, not design. Still, I'll take it.

Three ways to close a finding

The cause, once I traced it, was almost mundane: there were three separate places in the system capable of marking any finding as resolved, not just the one obvious spot I'd already excluded this category from. I'd correctly carved the new category out of two of them, the two I'd had in mind while writing the exception. The third was a generic cleanup routine with nothing to do with this integration, running on its own schedule, with no idea that this particular finding type was supposed to be different from every other finding it swept through. It wasn't behaving badly. It was doing precisely what it had always been built to do. It just never learned about the one exception that mattered here.

The fix was small once I knew where to look: exclude the audit-trail-integrity category from all three paths instead of two. Maybe twenty minutes of work. Finding the third path was the whole lesson; writing the fix was nothing.

I've written about six ongoing pillars for this project before, and every time I've been careful to call them ongoing rather than finished. That's the freshest proof of why that word matters. Five parts into this series, after a corrupted training run nearly shipped a broken brain, after a full audit turned on the agent's own reasoning, after writing down in plain terms that some categories of problem should never be fully automated, I still built something new that quietly broke that exact rule within days.

The gap wasn't carelessness, and it wasn't something the audit missed by being sloppy. There were simply more ways to close a finding than I remembered building, and one of the three had been sitting there so long I'd forgotten it existed at all.

Five parts ago, the goal was a diagnosis script that couldn't touch anything even if it wanted to. This week's goal was an exception clause that took two tries to get right, and the second try only happened because I was watching data I had no strong reason to be watching that day. Different scale, same lesson: build it narrow, keep watching after it ships, and assume there's a fourth path you haven't found yet. That's just how this project runs now, and at this point I've stopped expecting it to run any other way.