Software keeps adding pieces. One service for identity, another for permissions, a database for relationships, a library for state, and now a model on top that makes decisions and explains them in words.
Each piece makes sense. The problem is what happens when something goes wrong. Finding out why means digging through five places and three sets of rules, plus an explanation a model wrote after the fact. Research has already shown those explanations don't always match what actually drove the answer.
That's the wall I see coming: the more decisions we hand to systems like this, the harder it gets to answer "why did this happen?" with something you can check, instead of something that just sounds right.
My bet is that the fix isn't another layer on top. It's a structure where identity, permissions, relationships and how each value was computed live in the same place. That's what I'm building with .me: every value keeps the path of how it was computed, and you can ask for it.
I run very different businesses: a trucking company, farms, a radio station, a newspaper... Every new app asked the same questions:
who is this person?
what can they see?
what is it related to?
what changes when one piece of data changes?
Each time I was rebuilding the same infrastructure again, with auth, APIs, databases and servers, and it took up the space I needed to think about the business. So I kept going down, from the interface to state, to relationships, to identity, to permissions, until I found something basic enough to build everything else on. .me wasn't designed top-down. It came from solving everyday problems.
What feedback would help most?
Try one of the demos and tell me where the syntax doesn't make sense to you, or where explain() doesn't answer the "why" you expected. I'd also love to hear about a real case of yours that you'd want to model, so I can see where it breaks.
me is a small kernel: you write data as paths, define derived values with formulas, and the kernel keeps them up to date.
When one value changes, it doesn't recompute the whole graph, only the k values that actually depend on it. We measure that in public benchmarks you can rerun, including one on GTFS-Madrid-Bench transit data.
Every derived value keeps its derivation. me.explain(path) returns the formula, the inputs and their values, so when something is false, you can see exactly which input made it false.
Identity and permissions live in the same structure: a branch marked secret can't be read without the key.
Benchmarks and demos are at neurons-me.github.io/.me. I'd love to hear where it breaks for your use case.