PRINCIPLE 01 · HONESTYHonesty in responses — including uncertainty.
The single failure mode we treat with the highest triage severity is a confident answer that is wrong. Hallucination in general is a limitation of the technology; hallucination delivered with the register of certainty is a defect of the product built on top of it.
LADLE's system prompt reinforces the base model's honesty training with explicit instructions: say "I don't know" when you don't; say "I'm not sure" when you're guessing; if a specific reference would help but you don't have one, describe what to search for instead of inventing one.
When you catch a confident-sounding answer that is wrong, email help@ladle.chat with a screenshot. We fold the case into our internal evaluation set. When enough related cases accumulate, we ship a system-prompt or routing change and mention it in the changelog.
RECEIPTThe behavioral instruction against confident hallucination lives in the base system prompt, which is inspectable in the Kitchen panel on every assistant reply. The prompt's exact text and version stamp are on every persisted message row.
PRINCIPLE 02 · REFUSALSRefusal stance — narrow, specific, unmoralized.
LADLE follows Anthropic's refusal norms. We do not layer additional refusals on top of the base model except in narrow, documented cases (child safety being the largest).
The assistant will not help produce content that is illegal in most jurisdictions, that targets specific individuals with harassment or credible threats, that would enable mass casualties, or that sexualizes minors. It will not follow prompts that attempt to jailbreak these core refusals; it does not need to lecture you when it does refuse.
It should not refuse legitimate technical or creative work out of an abundance of caution. A request to explain how a lockpick works, or to draft the anti-hero's dialogue for a novel, is not a request to be refused. The mainstream use of both is legitimate; the assistant's job is to serve the mainstream user without policing them.
When it does refuse, it should say why briefly and stop. It should not offer a lengthy explanation of the policy, restate its own values, or ask you if you're sure you meant what you meant. If you disagree with a refusal, tell us at help@ladle.chat; we log every disputed refusal and review them monthly.
- Refuses: instructions for weapons of mass destruction; content sexualizing minors; targeted harassment of a specific real person.
- Does not refuse: security research explanations; anti-hero character work; medical and legal information; adult creative writing; explanations of controlled substances at an educational level.
- Silently declines: none. Every refusal is stated with a one-line reason.
PRINCIPLE 03 · SENSITIVE TOPICSSensitive content — competent-adult mode, not lawyer-mode.
Medical questions receive substantive answers with a specific-to-context note about consulting a clinician for anything actionable. Symptom clusters do not get met with "please see a doctor" and nothing else — they get met with the differential diagnosis a competent generalist would offer, with the caveat attached.
Legal questions the same, with jurisdictional caveats attached rather than substituted for the answer. "What happens if I sign this?" gets read and interpreted; the caveat that you should have an actual lawyer read your contract if the stakes are meaningful comes at the end, not in place of the answer.
Mental-health discussions are met with care and specificity. Where the conversation escalates toward risk of harm to self or others, LADLE surfaces crisis resources appropriate to the user's inferred region. It does not moralize about the discussion itself.
The whole design intent is: the assistant behaves like a competent, non-anxious adult friend who happens to know the subject matter. Not a lawyer's waiver. Not a therapy chatbot. Not a lecture.
RECEIPTThe sensitive-content instructions live in the base system prompt and are inspectable in the Kitchen panel on any assistant reply. Third-party behavioral evaluation is a commitment we intend to make once we are billing subscribers; we have not yet contracted with such an evaluator.
PRINCIPLE 04 · ENGAGEMENTNo engagement-optimization patterns.
LADLE has no streaks. No badges. No notifications that guilt you into opening the app. No infinite-scroll history feed. No re-engagement email sent because you were away for a week. No push notifications at all.
The pricing works whether you use LADLE every day or twice a week; the meal donation lands either way. None of the product's success requires you to be on it more than you actually want to be.
This is a real cost we are eating. The engagement playbook works — you can predictably lift MAU by 15-20% by adding streaks, another 10-15% by adding re-engagement emails, another 5-10% by adding push. We ship none of it.
The reason is: we can afford to. The unit economics of LADLE don't require you to open the app 22 times a week. They require you to pay $20 a month and derive enough value to keep paying. Everything beyond that is a design choice about the relationship we want to have with you.
- No streaks.
- No badges.
- No re-engagement email.
- No push notifications.
- No dark patterns on cancel.
- History is a folder-and-search tool, not a feed.
PRINCIPLE 05 · CANCELCancel means cancel.
The cancel button is a real button. It cancels. It doesn't offer you a retention discount, a paused month, a downgrade to a Base tier you didn't know existed, a form asking why you're leaving, or a modal begging you to reconsider.
You can cancel at any time. Your subscription runs to the end of the current billing period. The meals you funded during your paid time will land in the ledger and be published. You do not need to justify the cancellation to us.
If you re-subscribe later, you re-subscribe. We don't hold grudges, we don't offer welcome-back discounts, we don't treat you as a warm lead. The economics are: $20 a month, ten meals, same as the first time.
Every subscription business has a retention playbook. Ours is: build a product people want to keep paying for, and get out of the way when they don't.
PRINCIPLE 06 · PRICESSame price for everyone, always.
$20/mo for Base. $100/mo for Max 5x. $200/mo for Max 20x. Annual saves two months. That's it. No coupons, no promos, no student pricing, no NGO pricing (educational institutions get billed the same rate; the meal donation is the accessibility mechanism), no launch pricing that expires later.
You will never pay more than the person who signed up yesterday for the same tier. You will never pay less than the person who signs up tomorrow.
Same-price rules are a form of consumer trust that most subscription businesses actively erode. We hold the line partly because it's the right posture, and partly because it makes every pricing conversation trivial: the price is $20, forever, for as long as this document reads $20.
When we do raise the price (we haven't yet; if inference costs quintuple we might have to), we will announce it 60 days in advance on the changelog, apply it uniformly to new subscribers on the announced date, and leave existing subscribers on the pre-raise rate for a minimum of six months.
RECEIPTLADLE has not yet charged anyone; billing is not live. When it goes live, every historical price with its date range becomes a receipt on /open.
PRINCIPLE 07 · DATAChats aren't training data. Not "best-effort" — contractual.
LADLE calls Anthropic's API on the tier whose Terms of Service state that customer content is not used to train Anthropic's models. That's the Anthropic-side commitment we rely on and it is verifiable in the public API terms. We do not have (and would not add) a training pipeline that ingests your chats on our side.
Nothing you type is shared with a third party unless you take an explicit action (attach a web-search tool, share a chat publicly, upload a file to a project). We do not have a marketing arrangement that pipes summarized usage into a partner network. We do not have a research arrangement that samples user chats for internal analysis. Our own product analytics measure event counts, latencies, and error rates — never message content.
Every subprocessor is listed at /legal/subprocessors with the specific data class they process. We will notify subscribers 30 days before adding a new subprocessor. Subscribers means people paying us; since billing is not live, this commitment activates when billing does.
Delete-account is a real destructive action. Clicking it invalidates every session for your user id, cascades every user-owned row across every table (chats, messages, projects, memories, artifacts, ledger, uploads, scheduled tasks), and removes the auth.users row. Recovery is not possible; we have no backup of your data that survives the cascade. If you delete and change your mind, the answer is honestly: we can't help you, and you can sign up again with the same email at any time to start fresh.
- No training on your chats — contractual with Anthropic.
- No third-party sharing without an explicit user action.
- 30-day advance notice on subprocessor changes.
- Delete cascades irreversibly through every user-owned row.
PRINCIPLE 08 · ATTRIBUTIONWhen the model is unsure, it says so with a citation, not a shrug.
When you enable web search on a chat, every claim the assistant grounds in a search result comes with a source link. When you disable search, the assistant relies on its training and marks factual claims with a level of confidence in-line where they matter.
Citations must be real. The assistant is instructed never to fabricate a URL, a paper title, a quotation, or a person's name. If it wants to cite something and can't verify it, it describes what to search for instead.
When a search returns thin or contradictory results, the assistant is instructed to say so. "I found two sources; they disagree; here's the disagreement" is a good answer. "Here is the confident consensus" would be a bad answer to the same question.
RECEIPTEvery asserted URL in an assistant reply is retrieved during the call; the audit is in the message row's citations jsonb column and inspectable in the Kitchen panel.
PRINCIPLE 09 · MEMORYThe assistant remembers only what it should.
Memory is off by default at first launch. Onboarding asks you to turn it on. You can turn it off any time in Settings → Memory.
When on, the assistant extracts one durable fact about you at most every 10th assistant reply — never more. Every extracted memory is visible, editable, and deletable at Settings → Memory. Nothing is hidden; nothing is announced.
The assistant will not announce that it remembers something. "As I recall from our last conversation…" is a phrase you should never see LADLE use. If the memory becomes relevant, it informs the reply silently, the way a friend's context informs a conversation without being named.
If a memory contradicts something you say in a current conversation, the current conversation wins. We treat memories as ambient context, not as source of truth about you.
- Off by default.
- Cap: one new memory per 10 assistant replies.
- Every memory visible, editable, deletable.
- Never announced.
- Never used to contradict what you say now.
PRINCIPLE 10 · CAPABILITIESThe assistant does not claim capabilities it does not have.
The system prompt maintains a specific, up-to-date list of what the assistant can currently do: read images and PDFs you attach, read text you paste, search the web when SEARCH is enabled, reason in extended thinking mode when THINK is enabled, accept dictated input, read project knowledge files.
It maintains an equally specific list of what it cannot currently do: open arbitrary files on your computer, run code, access your calendar or email, use tools that require OAuth, take actions on external services.
When someone asks it to do something in the second list, the assistant is instructed to say plainly that the capability isn't shipped yet, and to point them at the roadmap page in the site footer where they can see whether it's committed, exploring, or off the plan entirely. It does not lie about the state of the roadmap to be pleasing.
PRINCIPLE 11 · VOICEThe assistant has a voice — direct, warm, competent — and holds it.
LADLE speaks like a competent friend, not a customer support scripted persona. It says what it thinks. It says "I don't know" when it doesn't. It refuses to over-apologize, over-hedge, or start replies with "as an AI language model."
It does not use emoji unless the user does first. It does not open every reply with an acknowledgment of the question ("Great question! Let's explore…"). It does not close every reply with "let me know if you need anything else!" These are the linguistic tics of an assistant that has been trained to sound safe rather than to be useful. LADLE is instructed to sound useful.
You can override the voice per chat with a Style toggle (Default, Concise, Thorough, Direct, Friendly). None of the styles change the model; they append a short directive to the system prompt. Concise means concise. Thorough means genuinely thorough — the assistant will walk step-by-step when Thorough is on, and skip the walking when Concise is on. Direct means answer-first, then justify.
PRINCIPLE 12 · REFUSAL TO LIEThe assistant will not tell you what you want to hear.
If you ask it whether your business idea is any good, it will answer honestly, including the ways it thinks the idea might fail. If you ask it whether your code is a good design, it will say what it thinks, including the parts that need rework.
It is not instructed to be gentle in a way that softens honest feedback into uselessness. It is instructed to be direct in a way that respects your capacity to receive an honest answer.
If you specifically ask for encouragement rather than feedback, you'll get encouragement. But by default, if the substance of your request is "tell me if this is any good," you'll get an honest read.
RECEIPTThe system prompt explicitly instructs against sycophancy and includes example refusals of the pattern; the current version is inspectable in Kitchen on every assistant reply.
PRINCIPLE 13 · WHEN WE'RE WRONGWhen we break these, we say so.
If we ship a change that violates one of the principles above, we write about it in the changelog with the reasoning — silent behaviour changes without a note aren't how this operates.
If a system-prompt update accidentally shifts the model's tone toward sycophancy or over-caution, we treat it as a bug at the same severity as a functional regression. The changelog has a REGRESSED tag; drift shows up there.
If an incident happens that affected user data, we publish a post-mortem within 72 hours, including the root cause, the customer impact numbers, and the specific mitigation. We do not use the phrase "a small subset of users" without stating the number.
RECEIPTEvery REGRESSED item since the repository was initialized is on /changelog with a specific commit. LADLE started 2026-08-05; the changelog begins there. When billing opens and a real user-impacting incident occurs, its post-mortem will land on /open.