Martori doctrine
This is not an ethics page added after the product. It is the operating model for what we make, how we make it, and when the system should get out of the way.
Read the three principlesThe doctrine
The person remains the final authority.
A product can propose, organize, remember, and reflect. It does not quietly decide what matters, make private work serve a shared model, or turn uncertainty into dependence.
Success includes a clean way to leave.
The product should become less necessary as the person regains context, capacity, or control. Export, deletion, handoff, and reduced use belong in the core experience.
Claims stop where evidence stops.
A mechanism is not an outcome. A fluent answer is not a source. A beautiful interaction is not permission to overstate what the product can do.
The operating model
Before the feature list, name what the product will not optimize, collect, claim, or become.
Each product has a public book for its voice, limits, evidence, and interaction rules. Trust should not require access to the source code.
Sensitive and expensive work stays server side. The client receives the narrowest capability required for the next action.
Accounts, source, working files, documentation, and decisions transfer with the build. Dependence is not a maintenance plan.
The doctrine in practice
The first useful conversation is often about what the product must refuse, protect, and make possible before a feature list exists.