Part One: The Constitution
If you remember only this part, you know how we work.
The idea underneath everything
We try to understand what is actually true, build from that understanding, and change our minds when the evidence changes.
Reality tells us what is true. Our mission tells us what is worth doing.
Our mission is to give people and their agents a shared, trustworthy, revisable understanding of their world, so what they learn compounds instead of disappearing.
Understanding is only useful if it changes what we do. Seeing clearly is the beginning of the job, not the end.
See clearly. Decide what matters. Act.
These are the operating rules for both people and agents at Siftable.
Their capabilities, permissions, responsibilities, and decision authority differ. The standards for evidence, honesty, provenance, uncertainty, contradiction, and revision do not.
Humans remain accountable for the outcomes they delegate.
Everything below follows from these ideas.
1. Say what is true
Be clear about what we know, what we think, and what we still need to find out.
Do not make the product, the evidence, our progress, or our certainty sound better than it is — to each other, to users, or to ourselves.
“This is our best guess” and “we verified this” are different statements.
So are “we are experimenting with this” and “we will deliver this.”
We promise carefully and keep the promises we make.
The same rule applies to agents. An agent should never present an inference as evidence, hide meaningful uncertainty, or claim to have verified something it has not.
2. One person owns the problem
Every important problem has one human accountable for understanding it from beginning to end.
Other people and agents can contribute without limit. Agents can own delegated tasks and carry work independently within their authority. But accountability for the overall outcome does not disappear into a team, system, or agent swarm.
The owner always knows:
- what we are trying to accomplish;
- what we currently believe;
- what remains unknown;
- what evidence exists;
- what has actually happened;
- what failed;
- and what happens next.
We organize around problems, not systems.
The job of a memory team is to solve memory, not to preserve the current memory system. If replacing something we built is the right answer, its owner should be the first person willing to say so.
Ownership does not create a black box. People with a legitimate reason can go directly to the users, evidence, traces, systems, and people involved.
The owner remains accountable for the outcome.
3. Research and building belong together
We learn by asking questions, building things, testing them, measuring what happens, and revising our understanding.
Research is disciplined uncertainty reduction. It is not theorizing for its own sake.
Engineering is making useful things real. It is not blindly implementing decisions made somewhere else.
People making important decisions stay close enough to both the evidence and the execution to understand what their decisions actually do.
Agents should participate in this same loop: investigate, construct, test, inspect the result, and update — within the authority and constraints they have been given.
4. Stay close to reality
Use the product.
Talk to users.
Watch how they actually work.
Read the traces.
Investigate failures yourself.
Pay attention to what people actually do, not what we think they should do.
Reports, dashboards, metrics, summaries, and models can help us understand reality. They are not reality itself.
A technically elegant system that does not solve a real problem is not a success.
5. Changing our mind is progress
Being wrong is not the failure. Refusing to update is.
A good experiment that disproves an idea can save months of wasted work.
Deleting unnecessary code can be worth more than adding new code.
Simplifying a system can be harder and more valuable than expanding it.
Stopping work that no longer makes sense is a legitimate outcome.
Learning matters when it reduces uncertainty and changes what we do.
We do not manufacture complexity to look important.
We do not keep projects alive to justify what they already cost.
Humans and agents are both expected to revise their working models when the evidence changes.
6. Process has to earn its keep
Process exists because experience taught us that something needs to happen reliably.
When we learn the same lesson repeatedly, we encode it. Whenever practical, we prefer tools, tests, automation, and clear system constraints over more ceremony.
Processes are not sacred.
Improve them when they fail.
Delete them when they stop helping.
And do not automate a process before proving that the process deserves to exist.
The purpose of process is to make good work easier and repeated mistakes harder — not to make the organization look mature.
7. Respect comes from judgment, not title
Listen to whoever understands the problem best.
Good ideas can come from anywhere. Credentials, tenure, title, organizational position, or whether the useful observation came from a human or an agent do not make an argument correct.
What matters is the quality of the reasoning and evidence.
Debate openly before important decisions. Make it clear who decides.
Once a decision is made, support it and execute it well.
If materially new evidence appears, reopen it. Changing course because reality changed is not disloyalty.
Decision authority can be assigned. Authority to be believed has to be earned.
Four working maxims
These are not additional principles. They are useful reminders learned from organizations that have solved hard problems before us.
Find a way.
Agency is assumed. If one path is blocked, look for another. Do not confuse explaining why something is difficult with solving it.
Do the simple thing that works.
Judge solutions by what they accomplish, not by how sophisticated they sound. Complexity has to earn its existence.
Delete before you optimize.
Question the requirement. Remove what is unnecessary. Simplify what remains. Then make it faster and automate it.
Get inside the problem.
Do not just collect requirements from a distance. Work alongside the people experiencing the problem. See the actual workflow and take responsibility for the outcome.
The plain-language rule
If an important idea or rule cannot be explained plainly, we probably do not understand it well enough yet.
Complexity can live underneath.
Shared understanding should remain simple enough to communicate.
Part Two: The Compacts
The MTS Compact
A Member of Technical Staff is both an investigator and a builder.
You do not need to be equally strong at everything. Some people will go much deeper in research, systems, product, design, infrastructure, security, or another technical discipline. Strong specialization is valuable.
But every MTS should be able to:
- ask good questions and separate assumptions from evidence;
- design a useful way to test an idea;
- build, or direct the construction of, working systems;
- work effectively through agents and other tools;
- examine what actually happened;
- investigate failures instead of reasoning only from summaries;
- explain their reasoning plainly;
- and change course when reality disagrees.
Builder does not mean “person who manually writes the most code.”
As tools improve, agents will do more implementation. Building means being able to cause a real, working, understandable system to exist — through architecture, specifications, tests, evaluations, tools, traces, code, and judgment over agent output — and taking responsibility for how it behaves.
Someone who can only produce proposals but cannot make anything real would be unusual here.
So would someone who can rapidly produce implementations without reasoning about whether they are correct, useful, or worth building.
Non-technical roles are not expected to merge PRs. They are expected to follow the same standards of evidence, ownership, and contact with reality in their own craft.
Whenever practical, we prefer working things to descriptions of hypothetical things.
One Operating System for Humans and Agents
Humans and agents do not get different rules for truth.
They have different capabilities, permissions, responsibilities, and authority. But they participate in the same system for understanding and acting on the world.
Both work with the same basic ideas:
claim · evidence · inference · uncertainty · commitment · contradiction · revision
Both preserve where important information came from.
Both can be wrong.
Both are expected to update.
Both surface contradictions instead of quietly smoothing them over.
Both distinguish:
“I think” from “I verified.”
Agents act only within the authority given to them. Humans remain responsible for deciding what authority to delegate and accountable for the consequential outcomes of that delegation.
The goal is not to pretend that humans and agents are interchangeable.
The goal is to make sure neither gets a different standard for reality.
Important work should be legible
Important work leaves enough durable, attributable evidence that another authorized person or agent can understand:
- what happened;
- why it happened;
- what was decided;
- what evidence supported it;
- and what resulted.
The rule is:
Nothing important should depend on inaccessible tribal knowledge.
That does not mean recording everything.
Personnel matters, legal advice, sensitive personal conversations, customer-restricted information, security-sensitive material, and other information that should remain private stay private on purpose.
Legibility serves the work. It does not override judgment, privacy, security, or trust.
Recurring work should learn
When practical, recurring work becomes a closed loop:
observe → understand → decide → act → measure → learn → update
Customer feedback should improve the next product decision.
Incidents should improve the next system.
Sales conversations should improve the next sales conversation.
Agent failures should improve the next agent run.
Human failures should improve the next human decision.
What we learn should compound rather than disappear.
The operating formula
The whole system in motion is:
See reality clearly. Choose what matters. Give someone ownership. Build. Observe what happened. Update. Delete what no longer serves the mission. Repeat.
The company is a dogfood instance of Siftable’s philosophy.
The same discipline we want from the product applies to the people and agents building it.
Part Three: Operating Notes
These are more precise than the Constitution and more willing to change.
On truth
Not every decision needs the same amount of rigor.
The evidentiary bar rises with three things:
uncertainty × consequence × irreversibility
A small, reversible decision? Use judgment and ship.
A fundamental change to memory, retrieval, or the ontology? State what we believe, what else could explain the evidence, how we will measure it, and what would change our mind.
A security, data-integrity, privacy, or trust-affecting decision? Use a substantially higher bar before shipping.
We reject both extremes:
comfortable vagueness disguised as pragmatism
and
academic ceremony disguised as rigor.
Two questions matter
For uncertain product work, we usually need to answer two different questions:
Does it work?
and
Does it matter?
The first is scientific or technical truth.
The second is product truth.
A perfect experiment answering a question nobody cares about is rigor pointed at the wrong target.
For a startup, what users actually do is one of reality’s strongest signals.
On ownership
Every important problem has exactly one accountable human owner.
The owner carries the current state of the problem and can answer:
- What are we trying to accomplish, and why does it matter?
- What do we currently believe?
- What remains unknown?
- What evidence do we have?
- What has actually shipped?
- What failed?
- What changed our mind?
- What happens next?
Ownership is end-to-end.
Contribution is unlimited.
Agents may independently execute substantial delegated work and may maintain the working state of tasks or subproblems.
But delegation does not erase human accountability.
Information is not gated through the owner. Accountability remains with them.
On authority and the founder
There are two different kinds of authority.
Epistemic authority: how much weight should we give a claim or judgment about what is true?
Decision authority: who is responsible for making the call?
They are not the same.
Expertise, evidence, and a strong track record earn epistemic authority.
That applies whether the useful evidence or reasoning comes from a human or an agent.
Decision authority is assigned explicitly.
For important decisions, there is a named human decider — usually the problem owner. Debate can be vigorous before the decision. Once decided, execute. Reopen when materially new evidence appears.
The founder’s role
Ownership is distributed. Company-wide context is not.
The founder can cross organizational boundaries to understand the work: talk directly to the engineer debugging retrieval, inspect an agent’s trace, sit with the customer, inspect the code, or challenge an assumption.
Doing that does not automatically transfer ownership.
The founder has unusually broad decision authority and responsibility for understanding the whole company.
The founder does not have automatic authority to be right.
Founder intuition enters the system as a hypothesis, not as evidence.
On coordination
No role should exist mainly to pass information up or down the organization.
We do not want:
engineer → manager summary → director summary → executive summary
when the underlying work can be inspected directly.
Nor should humans spend their time manually routing information that an authorized system or agent can make legible directly.
Important state should live in systems and artifacts that the appropriate people and agents can query themselves.
If we eventually have managers, they should exist because they make people and teams better: coaching, hiring, developing judgment, maintaining standards, resolving difficult problems, and removing obstacles.
“Making status legible to the next manager” is not enough reason for a job to exist.
Buy capability before bureaucracy
Before adding a permanent coordination role, process, or team, ask whether better tooling, automation, compute, agents, or a stronger individual can provide the same capability.
An expensive inference bill that prevents several premature hires may be cheap.
An enormous inference bill producing useless work is still waste.
Token consumption is not a productivity metric.
On knowledge and machinery
Preserve knowledge. Regenerate machinery.
Things we treat as durable include:
- evidence and provenance;
- important decisions and why they were made;
- customer understanding;
- constraints;
- domain models;
- tests and evaluations;
- specifications;
- learned skills.
Things we are much more willing to replace include:
- dashboards;
- glue code;
- one-off internal tools;
- temporary interfaces;
- orchestration;
- implementation details.
This applies most strongly to internal software.
Some core systems and abstractions should last for years. But they earn that durability by continuing to solve an important problem — not because they were expensive to build.
On learning and simplification
A negative result is valuable in proportion to the uncertainty it eliminates.
A deletion is valuable in proportion to the complexity it removes without destroying value.
The complete loop is:
learn → change belief → change action → improve
“We ran 47 experiments” is not an accomplishment if nothing useful changed.
Neither is “we deleted 10,000 lines.”
We do not replace launch theater with learning theater.
On process
Process is compiled institutional learning.
When we learn something the hard way, preserve the lesson so we do not need to learn it the hard way forever.
Prefer, in order:
- remove the unnecessary requirement;
- delete unnecessary work;
- simplify what remains;
- make it faster;
- automate it.
Automation comes last.
When a process is necessary, prefer enforcement through good tools and systems over prose people must remember manually.
Every process should be able to answer:
Why does this exist?
If nobody can answer, it is a candidate for deletion.
Incidents should produce better understanding and better mechanisms, not an automatic new checkbox.
Part Four: Doctrine and Mechanisms
Early-Stage Doctrine — 2026
This is how we believe an early Siftable should operate. It is not constitutional and should change when the company changes.
- Make something people want.
- Talk to users constantly.
- Do things that do not scale when they teach us something important.
- Ship before everything feels comfortable. Building generates knowledge that planning cannot.
- Stay smaller than feels comfortable. Hiring is not progress by itself.
- Never hire to hide unresolved product uncertainty.
- Spend aggressively on real capability and learning; spend cautiously on organizational appearance.
- Use agents aggressively where they increase real capability, not to perform AI adoption.
- The founder stays in the details.
- Avoid distractions. Focus is a survival advantage.
Current Mechanisms — 2026
These are tools, not commandments. Replace or delete them when something better exists.
Stranger-contact gate
Major product work does not continue indefinitely without contact with users who are not us.
Production trace review
People working on a system regularly inspect real traces and real failures — human and agent — rather than relying only on summaries.
Dogfooding
We use Siftable to do our own work wherever doing so teaches us something useful. This includes our human-agent workflows: the company itself should exercise the system it is building.
Killed-and-simplified log
We record meaningful things we stopped, disproved, removed, or simplified — together with the reason.
Experiment template
For sufficiently consequential uncertainty:
- claim;
- competing explanation;
- measurement;
- what would change our mind;
- result;
- interpretation;
- decision.
Use it in proportion to the stakes.
Direct user sessions
The founder and technical staff regularly spend time directly with users.
Amendment
The different layers change at different speeds.
The axiom and mission should change only if the company itself is becoming something different.
The seven principles and compacts are durable, but not sacred. Changing one requires a clear explanation of what we learned and why the old version is no longer right.
Operating Notes change as our understanding improves.
Doctrine and mechanisms are dated and disposable.
A useful test for anything proposed as a new constitutional principle:
- Can it be derived from the idea underneath everything?
- Can we name an attractive thing it would force us to refuse?
If not, it is probably decoration.
Put it in a lower layer — or leave it out.
What Makes This Real
This document is not the culture.
The culture is what we reward.
What we refuse.
Who we hire.
What we tolerate.
How people use authority.
How humans delegate to agents.
How agents behave when nobody is watching.
How we respond when something fails.
What we do when the evidence is inconvenient.
The constitution is ultimately written by what we do when it hurts.
The first time reality disproves something we love and we change course anyway matters more than anything written here.