Ellery AI

Devlog - how I accidentally almost shipped a lie detector that couldn’t detect lies: So Ellery already told you what was true about your data. Findings, plain English, click one and it peels open down to the exact rows. Nice. The problem was how it did that.Every finding carried a loose bag of numbers called evidence. And then, three separate times, a file called pull.js squinted at that bag and tried to reverse-engineer what the detector had been thinking. Three parallel switch (detector) statements. One to figure out which rows mattered, one to write the explanation sentence, one to write the derivation. Add a detector, edit four files, pray. Worst part: to figure out which rows a finding covered, pull.js re-ran the detector’s filter from scratch. Two copies of the same logic, living in different files, free to disagree. The finding says “3 records are low on stock,” the highlight lights up 4, and nobody notices for six months.The fix, and the part where I was wrongReplace the bag of numbers with an actual graph. Each finding now carries the computation that made it - max over a column, count over classified statuses - as nodes that hash to their own content, bottoming out at fingerprinted cells.I’d designed the graph nodes to include their computed value in their identity. Claude pushed back: separate identity from evaluation. The node names the computation; the value is what you get when you run it against data. Fine, sure, whatever - except it turns out that’s the entire ballgame, because now you get two fingerprints. One for the reasoning, one for the reasoning-applied-to-this-data. Which means the app can now tell you “your numbers changed but the logic didn’t” versus “the logic itself moved.” That’s a genuinely different product capability and it fell out of a definition change.Second thing I got wrong: I’d let the graph carry rowIndices. Row indices! In the evidence layer! That’s render state wearing a trenchcoat. Now it carries a witness - records addressed by content fingerprint - and the renderer figures out where they currently sit. Also, a haunting: Spent a solid while convinced the trace had 1,200px of unreachable content. Built a control experiment. Scrolling was fine. The real culprit was scroll-behavior: smooth - I was setting the scroll position and reading it back mid-animation, watching it clamp at 61.5px, and concluding the layout was broken. There was no bug. I nearly “fixed” a phantom. Small indignity: While all this was happening we discovered npm run lint was pointed at public/js, a directory that hasn’t existed since the frontend moved to the repo root. It had been linting nothing. For a while. Repointed it, and it immediately snitched on a pile of dead imports. Shipped: the derivation graph, two-fingerprint identity, a verify button that can actually say no, golden tests over the whole truth path, and a linter that lints. Deleted: more than I added, where it counted.

Devlog #3 - Making the app more open and dynamic: I am working on making the app feel less claustrophobic, adding/updating engines like the research engine, and making the UI more professional and multipage. Not commited and running yet, but almost there.

Ellery Devlog #2 - This time wasn’t about adding new features. Instead, I spent the time refining Ellery from the ground up. I removed over 600 lines of UI code, simplified the interface, rewrote much of the copy, and cut away anything that distracted from the actual purpose of the product. The biggest lesson I’ve learned so far is that good software isn’t just about what you build, but it’s also about what you’re willing to remove. Every animation, button, label, and panel has to earn its place. Ellery feels much calmer now. The interface gets out of the way, and the focus stays where it should: understanding your data. Next up is a new demo video, and after that I’ll be taking on the first Stardance software challenge by building my own web operating system.

Ellery AI - Devlog #1 I kept watching people open a spreadsheet, stare at it, and just… give up. The story was in there. They just couldn’t see it. So I started building Ellery to fix that. Honestly, I started where everyone starts: AI that summarizes your data. But I never trusted it. The summary sounded confident, changed every time I asked, and I could never tell if it was actually true. That’s useless if you’re about to put it in front of your boss.So I went visual instead - timelines, rank boards, an insight map. They looked great. But a pretty chart still makes you do the thinking. I’d basically built a nicer haystack.The thing that actually clicked was the Discovery Engine. Before anything gets drawn, Ellery reads your data and pulls out what matters - top items, outliers, what’s out of stock - as plain findings, each one traceable back to the exact rows it came from. No model, no guessing. Same data, same answers, every time.That changed everything downstream. Now the visualizations explain themselves, and you can export the whole thing to a slide in one click.Next up: turning those findings into recommendations, then a real narrative - and pointing it at NASA telemetry to see if it holds up beyond retail.It’s early, and I’m building it in the open. Follow along if that sounds like your kind of thing.