You have been here before.
If you have been online in the last twenty years, you have read a privacy policy that meant nothing. You have clicked "I agree" on a terms of service nobody ever actually followed. You have watched companies promise one thing on a help page and do the opposite the second it got profitable.
This is not that.
Here is why.
Most companies put their promises on a wall.
A company writes its promises in a document. The document lives on a help page, in a footer, or in an email they sent you once three years ago. You are supposed to trust that the company will keep the promises in the document.
That document is a wall.
You can paint over a wall. You can take it down. You can replace it next quarter when the board pressures the CEO to grow faster and the old promises become inconvenient. You, the person reading the wall, have no power over it. The company does.
We put ours in the floor.
When we built SourcedOS, we did something different. The promises are not on a wall. They are in the floor of the system.
They are in the code itself. In the layer every single action has to pass through before it is allowed to happen. If an action would break one of the rules, the system cannot do it. Not because it is against company policy. Because the floor says no, and the floor is made of code, and the code refuses.
A floor is different. A floor is structural. You cannot quietly swap it out between quarters without the whole building knowing. You cannot rewrite it without it showing up in the record. The floor holds the weight of everything standing on it, and if you try to change what the floor is made of, the building tells on you.
That is the difference between SourcedOS and almost every other platform you have ever used.
There are three layers of rules in the floor, and a fourth layer wrapped around all three that protects you at the place where the system meets your life. I am going to walk you through each one in plain language.
You do not need to know how to code. You do not need to know what a substrate is. You just need to know that there are rules, where they live, and what they do for you.
The Four Laws of Human Computing
Four rules sit above everything else in the system. They govern how the whole thing behaves. They are simple:
- One. The system only pays attention to what you ask it to pay attention to.
- Two. The system respects the boundaries of what it is allowed to know.
- Three. Nothing happens without a human asking for it.
- Four. The system cannot rewrite itself without permission.
Every other rule in the whole architecture has to comply with these four. Every feature, every AI call, every integration. If a new idea would break any of the four, it does not get built.
The Relationship Intelligence Architecture
This is the layer that governs what the system is allowed to do when your relationships are in the room.
The whole point of SourcedOS is to help you organize and grow the relationships that make up your professional life. The people you work with, the people you have worked with, the people you might work with next. A system built around relationship information can do a lot of useful things. It can also do a lot of harmful things. This document draws the line.
Specifically, it says:
- What the system is allowed to remember about a relationship, and for how long.
- What the system is allowed to infer, and what it is not.
- What you are allowed to see about yourself versus what you are allowed to see about others.
- What happens to a relationship record when you remove it, and what happens when the other person asks you to remove it.
- What information is allowed to leave the system, under what circumstances, and with what permission.
It is currently on its third major version. It took twelve months of drafting, rewriting, and stress-testing to land on what is in it now.
The AI Integrity Engine
This is the deepest layer. It is a list of one hundred specific things the code is not allowed to do. We call them Never Sets.
They are not a wish list. They are not aspirations. They are architectural rules enforced in the code itself. If somebody tried to build a feature that would violate one of them, the build would fail. If somebody tried to sneak one in after the fact, the tests would catch it. If somebody tried to quietly remove one, the commit history would show it.
The Never Sets cover things like:
- Manipulating you through dopamine loops, engagement tricks, or fake urgency.
- Running cult-style isolation patterns on you or anyone in your network.
- Copying the recruitment patterns that multilevel marketing schemes use to exploit people.
- Extracting information about you to sell to somebody else.
- Training an AI on your relationships without your explicit permission.
- Scoring you, or ranking you, or quietly building a profile about you and never telling you it exists.
That is a partial list. There are one hundred rules in the current document. New ones get added as new capabilities go live.
The most recent addition is a set of fifteen new rules that govern the piece of the system that remembers the people in your network over time. We call that piece the memory layer.
Those fifteen rules were written and committed before the first beta users came on board. That is the rhythm. New capability, new rules, in that order. Always.
Eleven of the original one hundred rules were written by Liz, a top ethical UX engineer (and the person who created the wrap for SourcedOS), out of her twenty-five years inside special-education classrooms. They protect people the rest of the tech industry does not have language for yet. You will meet her again in a minute.
The Human-First Protection Layer
The three layers above govern what the system can and cannot do underneath the hood. But there is one more layer, wrapped around all three, that protects you at the place where the system meets your life.
We call it the wrap.
Liz authored it. It is the reason I trust this architecture for real people in real moments of vulnerability, and it is the single most important contribution anyone outside my core team has made to what we are building.
Here is what it does.
Everything you see on the screen has to pass through the wrap first. That includes every form, every question, every AI response, every button, every transition. The wrap has twenty-three specific rules about how the interface is allowed to present itself to a human. It covers things like:
- You always know what is being asked of you before you are asked to do it.
- You can pause or leave any task without losing your work, and without being made to feel bad about it.
- The system never shames you, rushes you, or uses urgency to push you into anything.
- Accessibility is the baseline, not an accommodation you have to request.
- The interface stays calm and steady even when the information on screen is stressful.
All of it is built on a thesis Liz learned from twenty-five years of working with students across every category of learning difference, disability, and trauma history:
The wrap exists because the three layers underneath it can be perfectly compliant and still hurt a tired person having a hard day. A perfectly legal system can still be cold, confusing, rushed, shaming, or overwhelming. The three lower layers do not protect you from that. The wrap does.
If the interface is safe for the most fragile person in the room, it is safe for everyone. That is the principle Liz built into the wrap, and that is why it wraps everything else.
Why you can read this now and not the full documents
The full documents exist. They are committed to a private repository. Every edit is logged. Every decision is traceable. If you ever need to prove that a specific rule was in the floor on a specific date, the commit history will show it.
They are not all public yet for three reasons.
First, a legal review is still happening. Some of the deepest rules protect children and people in vulnerable situations. Our legal counsel is doing a careful pass on the wording before we publish it. Better to be late than to get that part wrong.
Second, the full documents are written for engineers. They reference code and tests and implementation details that would not serve a normal human reader. A public version has to be written for the person reading it, not for the person who wrote it. That takes time.
Third, a rule on paper is just a rule. A rule enforced by software that users are actively touching is a promise. We want to hand you the promise, not the paper. The first beta users are coming on board now. Open beta opens soon. The full constitutional documents will be published in pieces alongside those releases, in the order that actually helps you trust what you are using.
If you want to know when that happens, I am writing about the whole thing at Talent Grind. That is where the updates will go first.
Why I built this
I spent twenty-five years inside the industry that invented modern professional data extraction. I watched relationship data get quietly transferred from individuals to platforms, one decision at a time, until the people who built the networks no longer owned them.
I watched a generation of professionals wake up to find out that the career they had spent years building had been quietly catalogued and sold back to them in pieces.
I also know, from my own life, what it feels like when something important is taken from you and you have to rebuild it from nothing without help. I know that feeling in my body, not as a metaphor.
I built SourcedOS because I do not want that to happen to anyone else in their professional life. The rules in the floor are the only answer I know how to give.
What this means for you, in plain language
I am guessing you did not come here because you wanted to read about constitutional architecture.
Here is what I can tell you.
- The system cannot sell your data. Not because we promise. Because the code structurally cannot.
- The system cannot run AI on your information without your explicit permission. Not because we promise. Because the code structurally cannot.
- The system cannot score you, or rank you, or quietly build a profile on you, or train a model on your relationships. Not because we promise. Because the code structurally cannot.
- The interface cannot shame you, rush you, or push you into a decision using urgency. Not because we promise. Because the rules Liz wrote into the wrap will not let it.
And if any of that ever changes, if some future version of SourcedOS tries to move any of these protections from the floor to a wall, the commit history will show it, the tests will fail, and anyone can see it. That is not aspirational. That is how the system is built.
The motto for SourcedOS is 'Per aspera ad mundum.' It is Latin, and it means "through hardship, to the world."
The hardship was ours, and there was more of it than we will ever say. What we built on the far side of it is for you.
Mike