Curiosity rarely travels in straight lines
How a health-data experiment became a lesson lesson in how complex systems evolve.
Me: Cookie, what creates complexity?
Cookie: People.
Cookie was our Cocker Spaniel. He had a talent for reducing complicated subjects to uncomfortable truths.
It started with health data
A few weeks ago, the goal was entirely personal: build a Custom GPT to make sense of years of accumulated health information — blood reports, wearable data, exercise logs, doctor notes, and a slowly expanding constellation of metrics scattered across different systems. The goal was not a product launch or a business model and definitely not software architecture ambitions. It was just curiosity and a desire to understand one’s body data a little better.
My goal was to surface patterns that would otherwise remain buried in the noise. Perhaps certain blood markers correlated with sleep quality. Perhaps recovery scores mapped against training load. The kind of insight that feels just out of reach when you are staring at raw numbers spread across a dozen spreadsheets, apps and screenshots.
Fair warning — one that nobody gave me: when you start something driven by pure curiosity, the original subject often turns out to be a doorway. You think you are walking into one room, but only later do you discover that it connects to several others. In my case, health data was the starting point. Very quickly the kind of questions I was dealing with had almost nothing to do with biomarkers.
It looks neat in hindsight
Looking back, the progression from health data to systems thinking seems almost obvious. When I took the first plunge however, it did not feel that way at all. And, that is usually how curiosity works. Each question that gets answered reveals a few more waiting behind it, and the subject you thought you were studying gradually turns into something else entirely.
For me, my start point was nutrition and workout data. When I shared some screenshots from the custom GPT a few friends noticed what was coming out of it and asked whether they could use it too.
That simple ask changed the nature of the project. And led me down this path.
How should different users sign in? How should access work? What happens when different people should see different things?
That line of questioning eventually led to authentication, permissions, pricing tiers and, to a concept called entitlements that I had never encountered before.
Each of these steps felt perfectly reasonable once I arrived there. Looking back, the path is surprisingly easy to trace. Looking forward from the starting point, however, the destination would have been impossible to predict.
In my experience, that is how most interesting learning happens. Not by following a syllabus, but by following the next honest question.
My simple model broke
When the first requests came in from people who wanted access to the tool, the mental model was naively simple. There would be a free version with a limited number of features, and a premium version with more. The kind of model that feels so obvious it barely seems worth writing down. Two tiers, a clear boundary, done.
That simplicity did not survive for very long.
The more I thought about how access might work, the more exceptions started appearing — and none of them felt unreasonable. A coach might want to provide access to a group of athletes. Someone might earn additional access through referrals. A research collaborator might receive complimentary access. An organisation might negotiate a custom arrangement.
Individually, every scenario made perfect sense. The complexity only appeared when all of them had to coexist.
At that point, the question I was dealing with was no longer whether a user was “free” or “premium.” The question became more interesting: why exactly does this person have access to this feature right now?
The insight that made it click
As I continued to find answers, the thing that finally made it click for me was realising that the feature itself did not care where access came from.
It did not matter whether access originated from a subscription, a referral reward, an organisation agreement, a promotional arrangement or a manual exception granted by an administrator.
The feature only needed an answer to one question:
Can this person do this thing?
Everything else was context.
It turned out that people building software products had been wrestling with versions of this problem for years. The more I read, the more I realised there was already a name for the pattern I was slowly converging on: entitlements.
Once I started looking at it that way, the problem suddenly became much simpler. The reason behind the access could be handled somewhere upstream. The feature itself only needed to know the outcome.
That was the mental model that unlocked the idea of entitlements for me.
The more I thought about it, the less it felt like a software concept and more like a systems concept. The entitlement layer sits between a complicated world full of business rules and a feature that just wants a simple yes-or-no answer. While one side absorbs complexity, the other side remains blissfully unaware of it.
It may sound like a small distinction, but it explains why the pattern shows up so often. Without some form of abstraction, every feature would need to understand every possible rule, exception and edge case. With it, the complexity has somewhere to live.
The same pattern is everywhere
Once I had a name for the concept, I started noticing it everywhere.
To be clear, I have no idea whether Netflix, airlines, hospitals or any of the other examples in the diagram actually use the term “entitlements” internally. They may have completely different architectures. I am simply describing the pattern from the perspective of an end user.
What struck me was how often the same structure seemed to appear. Multiple ways to qualify. A layer that translates those qualifications into a simple access decision. And a user experience that remains happily unaware of the complexity underneath.
Across all of these examples, the surface experience stays simple precisely because the underlying system is doing a substantial amount of hidden work. The abstraction layer is not a flaw or a shortcut — it is the feature. Its entire purpose is to absorb complexity so that the user does not have to.
How does complexity actually accumulate
One thing this journey has changed for me was how I think about complexity in software.
My assumption had always been that software becomes complicated because the technology becomes complicated. More users mean more infrastructure. More features mean more code. More scale means more engineering.
That is certainly true.
But it also turns out to be an incomplete picture.
A surprising amount of complexity enters through ordinary human decisions that accumulate over time. Not through some dramatic architectural choice, but through a series of individually reasonable additions. Nobody wakes up one morning and decides they would like to build a sophisticated entitlement engine. What actually happens is far more mundane.
A referral programme sounds sensible.
A free trial sounds sensible.
A partner arrangement sounds sensible.
A special exception sounds sensible.
Viewed individually, each decision solves a legitimate problem. The complexity only becomes visible when enough of those decisions start interacting with one another.
At that point, they stop being isolated choices and start becoming a system that requires structure to hold it together. The entitlement engine is not the cause of the complexity — it is the response to it. It is what you build when the accumulation of reasonable decisions finally demands it.
When systems must explain themselves
The story becomes even more interesting when something goes wrong.
Imagine a user who believes they should have access but does not.
Or a user who has access and nobody is entirely sure why.
At that point, the challenge is no longer granting permissions. The challenge is explaining them.
That was another idea I had not really appreciated before. Systems do not just need to make decisions. Mature systems also need to explain those decisions in a way that humans can inspect and understand.
Support, and business, teams eventually end up asking questions such as:
Why does this user have access?
What changed last week that removed it?
Which rule overrode the default behaviour?
Without clear answers, even a perfectly functioning system can start feeling arbitrary to the people using it.
The deeper I went about understanding this, I understood how larger software companies operate. And I discovered that many eventually build internal dashboards, audit logs and administrative tools whose primary purpose is not delivering the product itself.
Their purpose is explaining why the product behaved the way it did. I found that surprisingly fascinating. Organisations eventually build systems whose job is to explain the behaviour of other systems.
What good entitlement architecture looks like
By this point, I had gone from never having heard the term “entitlements” to having a growing appreciation for why the concept exists in the first place.
The more I researched, the more I noticed that well-designed entitlement systems all seem to optimise for similar things. They need to handle multiple paths to access. They need to explain why a decision was made. They need to remain understandable even as new rules and exceptions get added over time.
None of those requirements felt particularly exotic. In fact, they felt almost inevitable.
They are the kinds of properties that emerge naturally once a simple system starts encountering real-world complexity. The sophistication of an entitlement engine is rarely designed all at once. It gets earned, one exception, one edge case and one perfectly reasonable business decision at a time.
Here is what three weeks of curiosity taught me
Three weeks ago, the word “entitlements” — in the context of software development — meant nothing to me. The plan was to analyse some health and nutrition data with an AI assistant. What ended up happening was a tour through authentication, permissions, pricing models and the surprisingly human origins of software complexity.
Most complex systems do not begin with grand complexity. They begin with simple intentions, then slowly absorb one reasonable exception after another until someone has to invent a structure that can hold them all.
That may have been the most unexpected lesson hidden inside this small experiment. The entitlement problem is not really a software problem — it is a human problem. Every exception in an entitlement system represents a decision someone made, a relationship someone valued, or a use case someone wanted to support. The machinery exists to honour those decisions without letting them overwhelm the product.
What began as an effort to understand my health better has ended up as a lesson about systems, organisations and the surprisingly indirect path that curiosity often takes.
The thing I thought I was learning turned out to be a doorway to something else.
Then again, isn’t that how curiosity usually works?
P.S. Arova continues to evolve in my spare time. Since drafting this article, blood work has joined nutrition, activity, sleep, recovery and body composition in what has become a longitudinal health record that individuals and coaching teams can use. Every new capability seems to uncover an entirely new area to learn about. Entitlements just happened to be the latest one.
P.P.S. One of the unexpected joys of writing these pieces is the conversations that follow. If you would like to chat about AI, products, health, leadership, systems thinking or side projects, you can always find me on Topmate.
Ranga ! Is vibe coding therapeutic or chaotic ? 😬😬😬😬😬