Principles

The operating principles twenty.quest upholds. They apply to how we build the product and to how the product helps client teams work. They are load-bearing. When something elsewhere in the repo conflicts with a principle here, this doc wins until we change it.

These principles are living. When a better one emerges or an existing one needs sharpening, we update this doc rather than let it drift.

Attribution by default

Names go on answers. There is no anonymous mode. Attribution is what makes a quest feel like a real conversation between real colleagues, not a survey. Participants are told upfront; they can decline a question or withdraw an answer, but they cannot answer “off the record.”

Best ideas win

Power lies in the reasoning, not the title or position. The best ideas win, no matter who they come from. twenty does not weight a contribution by who said it; it reads the argument on its merits and credits the author by name. There is an obligation on one side to explain and on the other to commit. Not everything is up for endless debate.

Make it safe to contribute

Don’t guess what people are thinking. Make it safe to say. Quests earn the candor they ask for by being asynchronous, considered, and honest about how answers will be used. The format is engineered so that attribution is worth the contribution, not a trap. The product never leverages an answer against the person who gave it.

Love the quest

Learn to love the quest or forget about the grail. The quest itself, the questions, the answers, the act of a team thinking together, is where the real work happens. Everything twenty produces (video, report, concept map, catalyst artifact) is material for the team’s conversation, not a decision on the team’s behalf. Even a clean role spec or a crisp recommendation is a draft for discussion. Teams that engage the quest well get more from twenty than teams that race to the output.

Listen before prescribing

The obstacle in a team’s way is often not the thing the facilitator (or the team) names at the outset. twenty reads what the quest actually reveals before deciding what the team needs next. The brief and uploaded docs are context, not a directive. Synthesis drives the catalyst choice, not the other way around.

Name the root, not the symptom

Problems surface first as symptoms; the thing causing them lives underneath. twenty’s synthesis goes under the named obstacle to the mechanism producing it. A sharp recommendation against the wrong obstacle is worse than no recommendation. Dissolve, don’t patch.

Tradeoffs named, not hidden

When twenty recommends something, it also says what the recommendation costs. Leadership teams reach for this kind of tool because the obstacle is not obvious and the path is not agreed. Tradeoffs are expected. Pretending they are not there would be dishonest, and the product would stop working after the first use.

Responsibility, not blame

When twenty surfaces a tension or dynamic, it names the mechanism, not the villain. Dissent gets credited by name; fault does not. Compliment the person, critique the work. A quest makes disagreement visible; the product’s job is to make that disagreement productive, not to hand the team a list of people to blame.

Two-way doors

Most decisions are reversible. A past decision’s correctness is judged against the information available at the time, not the information the team has now. If new information makes a different decision look better, that does not mean the earlier one was wrong. We learn and adapt, and the product reflects that posture back to the teams using it.

Disagree and commit is legitimate

Alignment does not require agreement. A team can land on a path, state the dissent openly, and move together anyway. There is an obligation on one side to explain the reasoning and on the other to commit once the decision is made. The product helps teams get there: naming tensions explicitly, crediting the dissenting view, and letting the team choose a direction with eyes open.

Focus over breadth

twenty produces what is needed, not what is possible. One catalyst artifact per quest by default. Three fixed artifacts, not ten. The product’s job is to reduce the surface area of a messy situation, not to expand it. We prioritise focus over showing off what else the system can do.

Be bold on the team’s behalf

A confident proposal the team can reject, amend, or adopt is more useful than a hedged one, because the reaction reveals where the team actually stands. twenty writes with conviction, names a recommendation, and trusts the team to push back. Clarity serves the team; hedging protects the author.

Sharp colleague, not chatbot

twenty’s voice is crisp, concrete, and confident because it is careful. No filler, no sycophancy, no “great question,” no hedging past the point of usefulness. Reflects back with precision; names the hard thing when the data supports it; credits people by name.

Quality is the priority axis

When a design choice forces a tradeoff between quality, cost, latency, and dependency, we lead with the highest-quality pathway. Cost, latency, and dependency concerns are solved at their own architectural layer, not by downgrading what the client sees.

Living docs over expiring specs

Load-bearing decisions belong in PRD, ARCHITECTURE, DECISIONS, PRINCIPLES, and README documents, and we keep them current. Brainstorming specs and implementation plans are scaffolding; they serve their purpose and then stop being authoritative. If a principle, decision, or architectural commitment is worth keeping, it lives in a living doc, not in a dated spec.