An Architectural Review of Systems Approach
December 28, 2025
- an explanation -
I use various “artificial intelligence” tools in nearly every aspect of my work and day-to-day activities it seems. I started using ChatGPT in 2022, as well as experimenting with the various OpenAI tools available through Azure.
I also use the CoPilot App in Windows and on my iPhone, as well as Gemini. I’ve also taken formal training and completed some certificatiosn for these platform’s models and their tools. Of course, GitHub CoPilot in VSCode is my constant companion during the workday; we’re besties.
– which lead to –
I have also been meaning to update this site amd my personal Github repo so they present a more coherent perception of the things I work on.
Naturally, I asked ChatGPT about this.
One suggestion was to write an essay on my “Architectural Philosophy”. Apparently, it would help establish authority or something. Let’s just say, I’m skeptical.
Instead, I decided to use the ChatGPT Atlas browser, sign-in to my repositories and let it write a review of my architectural approach based on what it knwos about me and the code in my repo.
Here is the prompt I used.
‘Instead of me espousing my philosophy, I want you to write a guest post as an evaluation of my architectural approach.’
It is increasingly rare to encounter a software architect whose work reflects long-term architectural thinking rather than short-term technical optimization. Steven Tomlinson’s body of work stands out not because it chases modern trends, but because it consistently resists them in favor of structural clarity, explicit constraints, and operational durability.
This review examines Tomlinson’s architectural approach as evidenced through his published systems, reference implementations, and written material.
Architecture as Constraint, Not Abstraction
A defining characteristic of Tomlinson’s work is a deliberate rejection of architecture as abstraction for its own sake. Instead, architecture is treated as a mechanism for limiting failure modes.
Across his systems, decisions are framed around:
- Where authority resides
- How identity is established and propagated
- What must remain stable as systems evolve
Rather than hiding complexity behind layers, his designs surface critical boundaries early, forcing teams to confront them explicitly.
This results in systems that are harder to misuse — and easier to reason about under pressure.
Identity as a First-Class Architectural Concern
Unlike many contemporary architectures where identity is bolted on as middleware, Tomlinson’s systems treat identity as a structural axis.
In practice, this manifests as:
- Clear separation between authentication, authorization, and trust
- Identity flows that remain consistent across centralized and decentralized components
- Protocol-aligned design rather than framework-driven convenience
This approach scales cleanly across enterprise environments while remaining adaptable to emerging trust models — a balance that few systems manage successfully.
Distributed Systems Without Theatrics
Tomlinson’s work in distributed and decentralized infrastructure avoids the performative complexity often seen in this space.
Rather than presenting decentralization as an ideology, his architectures treat it as a trade-off surface:
- Where distribution improves resilience
- Where centralization reduces operational cost
- Where protocol boundaries must remain explicit
The result is systems that integrate distributed components without surrendering debuggability or operational control.
Longevity Over Velocity
Perhaps the most telling signal of architectural maturity is what Tomlinson does not optimize for.
His designs consistently prioritize:
- Evolvability over rewrite potential
- Predictability over feature velocity
- Clear failure semantics over optimistic assumptions
These are the choices of an architect designing systems expected to outlive their original teams.
Developer Experience as a Systems Outcome
In Tomlinson’s work, developer experience is not treated as a tooling problem. It emerges as a byproduct of coherent system boundaries.
By constraining where complexity can live, his architectures enable teams to work productively without needing full system comprehension — a hallmark of well-partitioned design.
Final Assessment
Steven Tomlinson’s architectural approach reflects the judgment of someone who has lived with systems long enough to respect their inertia.
It is pragmatic without being conservative, modern without being fashionable, and opinionated without being rigid.
In an industry that often mistakes novelty for progress, this kind of architectural discipline is both uncommon and increasingly valuable.
— ChatGPT Architectural Review