GitHub repository: https://github.com/0ssy/trs-runtime
A question that kept bothering me
While building distributed applications, I kept running into the same questions.
Not technical questions like "Which database should I use?" or "Should this be event-driven?"
Instead, questions like these:
Who actually authorized this action?
Why do two systems disagree?
What happened while one participant was offline?
Can I replay the exact sequence of events that led here?
How do I explain a decision without stitching together logs from five different systems?
At first, I assumed there was already a standard answer.
There wasn't.
We already have amazing building blocks
Today we have excellent tools.
PostgreSQL
Kafka
Event Sourcing
Git
Kubernetes
CRDTs
Workflow engines
IAM systems
Audit logs
None of these are broken.
Each solves a different problem extremely well.
The interesting observation is that every large application eventually starts building another layer on top.
The layer every application seems to reinvent
Think about a typical enterprise application.
Eventually it needs to answer questions like:
Who approved this deployment?
Who delegated this permission?
Which update happened first?
Why did two replicas disagree?
What evidence supports this decision?
Developers usually solve these with some combination of:
audit tables
event logs
status fields
approval history
workflow records
custom synchronization logic
Every project does it slightly differently.
That made me wonder:
What if this coordination machinery could be shared instead of rebuilt?
I wasn't trying to replace existing systems
This is an important distinction.
The goal was never:
❌ Replace PostgreSQL
❌ Replace Kafka
❌ Replace Git
❌ Replace Kubernetes
Instead:
Application
│
▼
TRS Adapter
│
▼
Coordination Layer
│
▼
Existing infrastructure
The application continues using the tools it already trusts.
The coordination layer simply records the history surrounding important actions.
Three primitives
During the research I kept removing concepts until only three remained.
Observation – something was observed.
Intention – someone intends to perform an action.
Commitment – an authorization or promise.
Everything else becomes application-specific payload.
Whether the application manages work orders, deployments, medical records, or supply chains, the runtime doesn't need to know.
The real test wasn't the runtime
The biggest lesson wasn't about code.
It was about validation.
A runtime can be elegant and still be useless.
The important question became:
Would this actually make someone's job easier?
That led me to build a small application called TerraNode, where TRS acts as infrastructure rather than the product itself.
The goal isn't for users to learn TRS.
The goal is for users to answer questions like:
Who authorized this?
Why is there a conflict?
What evidence exists?
What happened?
...without digging through scattered logs.
If that works, then the coordination layer has earned its place.
I'm looking for criticism
This project is still an experiment.
I'm not claiming it replaces existing technologies.
I'm trying to answer a much narrower question:
Is there room for a reusable coordination and provenance layer that complements existing systems?
If you've worked on distributed systems, event sourcing, databases, workflow engines, or backend infrastructure, I'd genuinely like to hear your thoughts.
Does this solve a problem you've encountered?
Where does it overlap with existing approaches?
Where does it break down?
Would you build this differently?
Repository
GitHub: https://github.com/0ssy/trs-runtime
I'm much more interested in thoughtful criticism than praise. If you think the idea is flawed or unnecessary, I'd like to understand why—that's exactly the kind of feedback that helps refine or challenge the underlying architecture.
Top comments (0)