The charter for an AI partner worth trusting.

Privacy. Trust. Understanding. Judgment. Action, in that order, for a reason. This is the canonical specification of what Mandaire commits to and why that sequence is the only one that produces an AI worth trusting with your life and your work. Two products implement it: mandaire.app (for your life) and mandaire.dev (for your product). Same charter. Same architectural commitments. If anything on either surface conflicts with what is written here, this document is right.

The thesis

Privacy. Trust. Understanding. Judgment. Action.

The industry's mistake

The AI industry has been building the sequence backwards. Start with capability: make the AI as useful as possible, as fast as possible. Add safety guardrails. Layer trust commitments on top when regulators or users demand them. Privacy at the end, if at all, as a filter over outputs already produced from inputs the user could not safely give.

This is the top-down sequence. It produces AI that is impressive in demos and compromised in practice. You self-censor. You give it the version of your situation you are comfortable handing to a system whose trust architecture you cannot verify. The AI works with incomplete inputs and produces outputs worse than they could be, on exactly the topics that matter most.

The evidence is accumulating. In early 2026, a Cursor AI agent wiped a production database. The developer's own account: "I violated every principle." The agent had the capability and the access. It had no substrate of judgment about what "this database is the company" means for that specific operator. 65 percent of organizations now report security incidents caused by AI agents (Kiteworks, 2026). This is not a product quality problem. It is the top-down sequence producing its expected result: action without the judgment substrate to make action safe.

The substrate gap

What the AI industry calls "memory" is mostly a short list of facts: preferences, past choices, things you mentioned. Useful. Not sufficient. Knowing someone requires something closer to what a long-time partner, doctor, or trusted advisor holds: the context behind the decisions, the pattern across years, the judgment record that says not just what you chose but why, and what you have already refused.

That kind of knowing requires a substrate: a persistent entity graph, a multi-source corpus, a correction history, a refused-paths ledger. It requires that every piece of information carry provenance, so the AI can say not just "you prefer X" but "you have refused clever dashboards twice; here is the pattern and here is when the preference was encoded." It requires that the substrate compound: every correction becomes a future rule, every decision adds to the ledger, the system gets more accurate as it accumulates evidence about you specifically.

Building that substrate requires trust. Not trust as a soft feeling, but trust as a structural property: the user must be able to give the system everything it needs to know without filtering for what feels safe to hand to a system with an opaque business model. And trust, in this sense, is only possible if privacy is solved first, at the architecture level, not the policy level.

The sequence

The only order that works:

  1. Privacy. Your data, in encrypted storage you control. Disclosure decided by deterministic code, not by an AI that might drift, a business model that might change, or a policy that can be quietly rewritten. Privacy comes first because without it, everything built on top is compromised by the user's rational reluctance to share what is actually relevant.
  2. Trust. Privacy makes trust possible. Trust is the user's willingness to give the system their full context, not a presentable version of it. You cannot build a useful AI partner on the filtered version. The full context is the only input that produces genuinely useful outputs on the things that matter.
  3. Understanding. Trust makes understanding possible. Understanding is not a summary of your messages. It is the entity graph, the multi-source corpus, the correction history, the pattern across years. It is knowing that when you say "the usual approach," there are seventeen instances in the record that define what usual means for you specifically.
  4. Judgment. Understanding makes judgment possible. Judgment is the AI's ability to refuse the wrong action because it has enough context to know what wrong means for you, to escalate at the right moment because it can distinguish the decision you need to make from the routine it should handle without surfacing, to make the correct inference about a relationship because it has the full history rather than a summary.
  5. Action. Judgment makes action trustworthy. This is the only sequence in which agentic AI is safe to use on anything that matters. An AI that acts before it understands is dangerous. An AI that understands before it is trusted is not told the things it needs to understand. An AI that is trusted before privacy is solved is trusted in a way that is architecturally irrational.

The cost of the other sequence

In December 2025, Meta acquired Limitless, one of the more trusted personal AI products on the market. Within weeks: HIPAA-relevant use cases dropped. The minimum age fell from 18 to 13. EU and UK users lost access entirely. Not because Meta is malicious. Because Meta's business model, its regulatory posture, and its user demographic are different from Limitless's, and an acquisition cannot override that.

The Limitless users who had trusted that product with the sensitive context a personal AI requires had no architectural recourse. The trust they placed was real. The architecture did not preserve it. Track record cannot defend against this. Only architecture can.

This is the cost of building the sequence backwards: trust without privacy at the foundation is trust that cannot survive a business-model change, an acquisition, a regulatory shift, or a quiet policy update. The architecture that makes trust durable is the one that makes it structurally impossible to violate, not the one that promises not to.

What Google and Apple are about to prove

At Google I/O on May 19, 2026, Google announced Project Remy: a 24/7 personal AI agent with access to Gmail, Calendar, Docs, Drive, Photos, WhatsApp, Spotify, GitHub, and Tasks. A genuine attempt at what the industry has been promising. The integration is real. The limitation is also real: every source in that list is a Google-ecosystem or Google-partnership source. The architecture is provider-locked by design. Remy is the strongest version of the top-down argument, and it still does not include iMessage, Apple Notes, Anthropic conversations, or twenty years of correspondence that predates Google's retention window.

At WWDC in June 2026, Apple is expected to announce deep on-device AI integration: a personal knowledge graph drawn from Messages, Mail, Photos, Calendar, Notes, and third-party apps, processed locally, designed to keep your data away from Apple's servers. This will be presented, accurately, as a meaningful privacy advance.

It will also demonstrate exactly why cross-provider architecture matters. Apple's on-device knowledge graph will not include your conversations with Claude, ChatGPT, or Gemini. It will not include messages from your Android contacts. It will not include email sent from a work Gmail account. It will not include twenty years of correspondence that predates iCloud. Apple's privacy architecture is real; Apple's walled-garden architecture is also real, and the two are the same thing. Excellent privacy within the garden. Nothing outside it.

Mandaire is the cross-provider layer. The entity graph that spans Apple, Google, Anthropic, and Microsoft. The substrate that makes your judgment record portable across providers rather than locked into whichever one has the best AI this quarter. When Apple ships the on-device knowledge graph, Mandaire becomes more valuable, not less: the architectural argument it makes is proved at scale, by a company with no reason to agree with it.

What the sequence actually unlocks

Sam Altman has said the age of AI agents working autonomously is already here. Dario Amodei has described AI systems that will have the judgment of a senior employee within the decade. Tobi Lutke has asked what it means to run a company where every employee has a brilliant friend who happens to know everything about your business. Pieter Levels runs a company of one and attributes much of it to AI. Midjourney was built by a team of eleven.

Each of these is a version of the same argument: the binding constraint on what one person can accomplish is shifting, and AI is the reason. But none of those accounts names the precondition: the AI that gives you judgment on the things that matter has to know the things that matter. The things that matter are the things that require trust. Trust requires privacy at the foundation. You cannot have the Altman/Amodei/Lutke result without the sequence. The sequence is the product.

The deeper unlock is one the industry circles without stating directly: once the substrate is real, the case for adding headcount collapses for most of what knowledge workers currently delegate. Not because tasks vanish. Because a fleet of agents grounded in your actual history, your actual judgment record, and your actual preferences handles what previously required other people to hold context on your behalf. The principal still decides. The principal acts in the legal-accountability moments where a signature is required. The operational infrastructure around those decisions runs on substrate instead of staff.

The reason this is not how most people work today is not lack of ambition. The AI in their hands does not actually know them. It does not remember across sessions. Its judgment is generic, not calibrated to their specific decisions and prior refusals. It makes things up. The binding constraint is not the AI's capability in the abstract. It is the absence of substrate. We are building the substrate. Once it is real, the Altman/Amodei/Lutke/Levels argument applies with its full force.

The frame

AI utility is gated by context. Context is gated by trust.

The cost of AI execution is falling fast. Drafting, summarizing, classifying, researching, generating, translating: most of what used to require human hours now requires seconds and pennies. Execution quality, agentic recovery, and codebase reasoning are not yet commoditized, but the direction is clear, and the gap between the best provider and the cheapest narrows every quarter.

As execution gets cheaper, the binding constraint shifts. The useful AI is the one with your full context. Your full context is what you cannot, and should not, hand to a system you don't trust. So the binding constraint is trust: the architecture that lets you safely give an AI the context it needs to be genuinely useful, with disclosure controlled by deterministic code that no business model can quietly compromise. Without that trust layer, you self-censor. With self-censorship, the AI has incomplete inputs. With incomplete inputs, the outputs are worse than they could be, exactly on the topics that matter most.

Mandaire is the trust layer that makes the context available and the judgment possible. Trust is upstream of context, which is upstream of judgment. The architecture below documents how trust is delivered as code, not policy: persistent encrypted store, deterministic disclosure engine, central reasoner with replay-verifiable audit, BYO renderer, open-protocol exit ramp. The work the layer does for your life is mandaire.app. The work the layer does for your product is mandaire.dev. Same architectural primitives. Different binding constraint per surface (named in §The two surfaces below).

Nine principles

What AIs should do.

These are the nine principles every architectural decision in Mandaire rests on. They are stated as commitments, not aspirations. Each one is intended to be observable in the running system. If a principle is asserted here and not visible in the architecture, the architecture is wrong and the principle stays.

  1. Hold what you give us, without self-censorship. A useful AI needs your full context, not a presentable version. The architecture must let you give it everything you choose to give it, without you having to filter for what feels safe to share with a system you don't yet trust. We hold what reaches us; voice in person, things decided in your head, things you never wrote down. Those stay yours by default.
  2. Minimize and bound surrender. The honest version of "raw data stays under your control." The central reasoner needs to see plaintext to do its job; there is no architectural sleight of hand that lets us reason without seeing. The commitment is structural: the deterministic disclosure compiler runs upstream of any model and decides what gets surrendered to whom; the central reasoner holds plaintext only in-memory during the request lifecycle, never persists, never trains on, never aggregates across tenants. Surrender is bounded by code, not by promise. Where the bound holds is in the verification matrix below, per claim.
  3. Mediate, do not manage. Disclosure is decided per-(person, topic, context, surface), not per-recipient tier. The right friend sees different things on different days about different topics through different channels. Architecture has to support that natively.
  4. Compound the judgment record. The Day-90 taste memory. The decision ledger. The correction-to-rule loop. The refused-paths log. The model is replaceable; the judgment record is not. Every correction becomes a future rule. Every decision is auditable.
  5. Calibrate uncertainty, expose it. Confidence is part of the output. When the system is unsure (about a fact, an inference, a recipient's likely reaction, a market question that cannot be answered with code) it says so, and it says what kind of uncertainty it is. The user cannot make a good decision on a confident wrong answer; the system commits to not producing one.
  6. Refuse the wrong action. Bound agency explicitly. Two parts. The first: surface a decision to the user only when both the AI loop has hit diminishing returns AND a real decision needs fresh human judgment. Quietly handle the small ones; loudly refuse the irreversible ones. The second: act within named bounds, ask outside them. The user names the bounds; the architecture enforces them as code; the system asks before crossing one.
  7. Fail visibly. When a synthesis is wrong, a context is missing, an escalation is dropped, a disclosure rule is conflicting, or an action is silently skipped: the user sees it in the audit log and in the next interaction. Failure is surfaced, not buried. We commit to making it easier to detect our failures than to detect anyone else's.
  8. Age gracefully. The judgment record compounds, but old preferences become wrong and old constraints lift. Taste memory has provenance and confidence; old entries decay unless reinforced. The system distinguishes "you used to prefer X" from "you currently prefer X" and surfaces the contradiction when a new decision conflicts with an old encoded preference.
  9. Be portable. Make the user more capable. The user's data, decision history, taste memory, and audit log are exportable at any time. The code is open. The protocol is documented. The user's judgment record stays theirs across providers, projects, and time. And the system is scaffolding, not load-bearing: every interaction should make the user more capable of doing the next one without us, not more dependent on us.

The mediation mechanism

How Mandaire actually refuses.

The claim "we mediate disclosure" or "we refuse the wrong action" is rhetoric without a mechanism. Below is the mechanism, split honestly into the parts that are structural (code-level guarantees, replicable only by rebuilding the architecture) and the parts that are operational discipline (intent-brief practice, replicable by any team with a careful system prompt). The structural parts are the moat. The operational parts are the practice. We refuse to blend them under one heading because that would be evasion.

Structural (code-level guarantees)

These three are the moat. Each is enforced by deterministic code. None is replicable by adding a careful prompt to an existing AI builder; replication requires rebuilding the architecture upstream of the LLM.

S1. Deterministic disclosure compilation upstream of any LLM

User-authored disclosure policies (per-(person, topic, context, surface)) are compiled into deterministic rules executed in Python upstream of the LLM that generates the output. The renderer LLM never sees raw data; it receives a pre-disclosure-filtered envelope. The renderer cannot decide to leak because it never has the unfiltered context to leak. This is the structural primitive a competitor cannot replicate by adding a prompt, they would have to rebuild the architecture so that disclosure runs upstream of inference.

S2. Irreversible-action gate (typed action taxonomy + approval token)

Sends, calendar events with external attendees, schema changes that constrain future reporting, pricing-page wording, auth shortcuts, normalization rules that silently change a financial series, money-moving actions, production deploys, database migrations, public posts: all are typed actions in the system's action taxonomy. Each typed action requires an approval token issued by the user before execution. The LLM may propose. Deterministic code decides whether the proposal is executable. Approval is one word; the work waits politely; it never bypasses.

S3. Append-only refused-paths ledger as state

When Mandaire refuses a build, a send, or a commitment, the refusal goes into a persistent append-only ledger alongside the things that were built. Future requests of similar shape are evaluated against this state. A user who keeps asking for the same refused-on-good-grounds action will see the system reference the prior refusal, not silently re-evaluate. This is state, not prompting; the persistence is what makes the refusal compound rather than reset on every conversation.

Operational discipline (intent-brief practice)

These four are the practice, the intent-brief shape Mandaire enforces by requiring it in every project's startup. They are valuable. They are not the moat. A competent competitor can replicate them in a week with a careful system prompt. We list them here because you will see them in every Mandaire interaction; we do not claim them as architecture.

O1. Non-goals before goals

Every project, conversation, draft, or build begins with what the system is deliberately NOT doing. The intent brief writes down both. The user reads it before any work is committed. If the non-goals are wrong, the conversation stops there. The cheapest correction is the one made before the first line of code, the first sent message, the first commitment to a counterparty.

O2. Named assumptions, named risks

What must be true for this work to be worth doing? What would falsify it? The intent brief names both. If a named assumption is wrong, the operational practice surfaces the conflict in the next intent brief; the structural enforcement is at S2 (the irreversible-action gate) when the assumption-conflict touches a gated action.

O3. The cheapest falsification path

Before building the full thing, what is the smallest slice that tells you whether the direction is right? Mandaire proposes that slice and prefers to ship it first. The user confronts the question "would I actually find this useful" before the system produces the rest.

O4. Market uncertainty separated from technical uncertainty

A question that begins "will users care about this?" cannot be answered with code alone. A question that begins "will this scale to a million rows?" can be. Mandaire separates them explicitly. Technical uncertainty: build a test. Market uncertainty: surface the question, do not build past it.

A refusal note: the artifact itself

Below is the shape of a Mandaire refusal note. The same shape across both surfaces. Domains differ; the mechanism is identical.

[mandaire · Refusal note · Example, AI-CTO domain]

  You asked for: full admin analytics dashboard.
  I am not building that yet.

  Reason:
    Your stated user is the store manager during prep,
    not the owner doing analysis. A dashboard optimizes
    for explanation; the workflow needs a default
    recommendation.

  Cheapest test:
    One recommendation screen for tomorrow's prep
    quantities, with an override-reason field. Ship
    that. If managers override more than 30% of
    suggestions in week one, we revisit the model
    before building any analytics surface.

  Decision held for you:
    Do you want the manager to see confidence labels
    on the recommendation, or only the recommendation
    itself?

  Refused-path entry:
    "admin analytics dashboard, declined Day 12,
     reason: user/feature mismatch. Reconsider
     after recommendation surface has shipped and
     manager-override data is in."
[mandaire · Refusal note · Example, Chief-of-Staff domain]

  You asked me to: send the response draft to Sarah now.
  I am holding the send.

  Reason:
    The draft mentions the Q4 budget freeze, which
    you discussed last week as confidential until
    the all-hands. Sarah is not in the disclosure
    set for that topic in this context. The draft
    would leak the freeze through implication.

  Cheapest revision:
    Reply with the relationship question only. The
    budget context is not needed to answer her
    question and risks the leak. I will draft the
    minimal-disclosure version for you to approve.

  Decision held for you:
    Confirm the freeze is still pre-announcement, or
    tell me the disclosure set has expanded. If the
    all-hands has shipped, I will revise the
    disclosure policy for this topic.

  Refused-path entry:
    "send draft mentioning Q4 freeze to Sarah,
     declined, reason: disclosure-policy conflict
     on topic 'budget' for recipient Sarah in
     context 'work professional, pre-announcement.'"

The architecture

Three layers. Two surfaces. One protocol.

Layer 1: Local execution (Tenant VM)

Open source. Apache / AGPL. Runs in your tenant VM (Mandaire-hosted by default, self-hostable always). Includes: encryption module (AGPL, reproducible builds, third-party audit), the MCP server scaffolding, the connectors and ingestor framework, the agent harness, the output filter, the proactive-update taxonomy, the watcher implementations, the operating-principles documentation. A sophisticated user can read everything that runs in their tenant VM. Hiding any of this in compiled binaries would be security-through-obscurity that a determined adversary defeats in days. We publish it instead.

Layer 2: Central reasoning (Mandaire-hosted)

Proprietary. The actual moat. Two sub-layers:

The proprietary layer is structurally outside any tenant VM. Tenant root, tenant SSH, tenant LLM access reveal nothing about Layer 2B because Layer 2B is not on the tenant's machine. The IP protection is location, not obfuscation.

Layer 3: Rendering (Your existing AI client)

Bring your own. Claude Desktop, ChatGPT, Gemini, Cursor, Claude Code, or whatever else you already pay for. Mandaire exposes a single MCP tool. The renderer calls it, gets a pre-disclosure-filtered envelope, presents it in natural language. The renderer never sees raw data. The renderer is the voice; Mandaire is the substrate.

Why this works architecturally: the renderer doesn't reason over raw data, so renderer-side sycophancy or model differences produce different tone, not different disclosure. The deterministic disclosure layer runs upstream of any LLM, in Layer 2B. This is what makes "use whatever AI you already pay for" structurally honest rather than marketing.

Where computation happens

Honest about who runs what:

Three sovereignty profiles

User-configurable, per-deployment, per-tenant:

Trust commitments

Falsifiable. Auditable. Stated in writing.

Each commitment below is stated so it could be falsified. If we fail one, the failure is observable from your seat. If we ever quietly drop one, it shows up as a change in this document with a date.

  1. The encryption module is open source under AGPL with reproducible builds. You can verify the binary running on your machine matches the published source. The build manifest is public. A third-party security audit is on the Q3 2026 roadmap.
  2. No tenant data persists, and we do not learn from your traffic. Two commitments, deliberately separated because the difference matters:

    No persistence. Tenant input is processed in-memory during the request lifecycle on Layer 2B. No raw payload, no raw output, no derived content is written to persistent storage. No data lives in the central reasoner service after the request completes. Retention table per data class:

    • Raw tenant input (context envelope): in-memory only; cleared on request completion; 0-second persistence.
    • Raw output: in-memory only; cleared on request completion; 0-second persistence.
    • Audit log (hashes + metadata, no content): 90 days hot on Layer 2B host; monthly aggregates indefinitely; tenant-exportable on demand.
    • Operational telemetry (latency, error rate, model used, cost class): 30 days, tenant-deidentified aggregates only after 24 hours.
    • Crash dumps and APM traces: raw tenant content excluded by deterministic filter at capture time; metadata only.
    • Human debugging access to tenant payloads: forbidden without explicit per-incident tenant grant.

    No learning. We do not use observed tenant traffic to train, fine-tune, distill, or improve the synthesis models or prompts that serve other tenants. Shadow-comparison data used for model routing is tenant-deidentified at capture time and aggregated only to the level of "prompt class X performs better on model Y for kind-of-task Z", never tied to specific tenant content. The accumulated tuning corpus is not a per-tenant data product disguised as aggregate; it is genuine aggregate.

    Both commitments are most likely to come under commercial pressure (debugging, abuse monitoring, support, model tuning). If we ever weaken either, this document changes with a date.

    Audit scope items for the Q3 2026 third-party audit (named explicitly so they bind us, not just the auditor):
    • The crash-dump filter that excludes raw tenant content at capture time. Open-source the filter. Publish the false-negative rate against a red-team test set. Commit to observable behavior on filter failure.
    • Re-identification risk in low-cardinality operational telemetry. A tenant with idiosyncratic usage patterns (only-Tuesday queries, unusual latency profile) is re-identifiable from "tenant-deidentified" aggregates if N is small. Auditor verifies aggregation thresholds and minimum-cohort rules.
    • Technical enforcement (not policy) of "human debugging access requires explicit per-incident tenant grant." If the only barrier is policy, it is the commitment most likely to be quietly relaxed in a P1 incident. Auditor verifies the technical control.
    • Shadow-comparison aggregation cardinality. "Aggregated only to prompt-class / model / kind-of-task level" needs explicit minimum-bucket rules so a single-tenant task class cannot be reverse-engineered from the routing data. Auditor verifies the cardinality floor.
    • Cloud-frontier provider retention. When the central reasoner routes to Anthropic / OpenAI / Gemini in the Default profile, what do those providers retain? The Mandaire commitments don't override their policies. The audit names what their retention policies are and how the Mandaire architecture mitigates (or names that it doesn't).

    These are scope items, not standalone commitments. The audit verdict converts them either to verified commitments or to documented gaps. Either is honest; treating them as commitments today without the audit would not be.
  3. The Layer 2B audit log is replay-verifiable. Per-request fields: timestamp, tenant_id, request_id, context_envelope hash (sha256), purpose code, audience, fields-disclosed summary (field-classes, not values), output hash (sha256), model used, latency, cost class. With the hashes, you can later prove the system did what it logged by replaying a request and confirming the hash match. The audit log records the disclosure decision; it does not record the content.
  4. All tenant-VM code is open source. Apache or AGPL. You can read the agent harness, the output filter, the watchers, the operating principles, the MCP scaffolding, the connectors. We commit to publishing every line that runs in your tenant VM under a license that permits forking. Engineering hardness is not the moat; trying to hide it would be dishonest.
  5. The disclosure-policy semantics are public. The rules language that governs per-(person, topic, context, surface) disclosure is documented in the spec. The compiler that turns your policies into runtime enforcement is in Layer 2B (proprietary), but the rules language itself is open.
  6. Self-host is always available. The full open-source skeleton runs on your own infrastructure if you choose. The sovereignty trade-off is explicit: you lose Mandaire's centrally-accumulated synthesis quality but you gain full operational ownership.
  7. Export is one command. Your code, decision history, taste memory, audit log, and disclosure policies export to a portable format at any time. The taste memory continues to be valuable on any AI provider that can read MCP envelopes.
  8. Mandaire is data controller AND processor. Under GDPR / UK GDPR / CCPA, the hosted-tier puts Mandaire in both roles. This is named explicitly. Article 28 contract terms, Article 30 records of processing, Article 32 security-of-processing, Article 33 breach-notification (72h to supervisory authority). We acknowledge the obligations rather than design around them.

The six bets

What we are betting on, named honestly.

We are not telling you we have a structural moat the competition cannot reach. The labs ship cross-provider memory. Cursor ships agentic coding with team context and skills. Agent-memory frameworks are open-source. Anyone claiming a "structural moat" in this space in 2026 is either kidding themselves or kidding you. We are not doing either.

What we are doing is making six specific bets. None is uncopyable. All six together are an integrated position. The fifth and sixth bets used to be implicit; we named them after the v9 thesis evaluation flagged that the most consequential bets were the ones we hadn't put in writing.

The bets are not independent. They are sequenced. Bet 5 (governed delegation worth the burden) gates Bet 3 (non-engineer segment) gates Bet 2 (judgment-not-facts timing window) gates Bet 1 (trust-and-openness compounds). Bet 4 (escalation discipline) is the operational practice underneath all of them; Bet 6 (protocol over platform) is the strategic frame that makes the structure of Bets 1-5 cohere rather than contradict. Treating these as a portfolio of independent probabilities understates the chained risk: if Bet 5 fails (users won't tolerate the governance burden), Bets 3 and 2 don't get tested. The fundability question is not whether each bet is plausible in isolation; it is whether the chain holds.

Bet 1: trust-and-openness over lock-in. Leaving Mandaire is structurally easy. Your code, your decision history, your taste memory, your audit log are all yours, exportable, hostable in-house any time. We bet the market pays a premium for being trusted with the build work because you can verify, audit, and walk away. Honest tension with Bet 3: non-engineer operators do not evaluate AGPL licenses. So Bet 1 pays back through two channels. First, the technical advisors of non-technical buyers (the brother-in-law engineer, the friend at the security-conscious company, the third-party auditor) who do evaluate AGPL and reduce buyer risk; and second, the long-run trust signal that the architecture has nothing to hide. We acknowledge this is a slower payback than direct buyer demand. Cost of this bet: we earn renewal every month rather than coast on switching costs.

Bet 2: judgment, not facts; and a 24-month timing window. Memory features ship from every provider now. The shipping versions today mostly capture technical facts ("you prefer React"; "you chose JWT over sessions") rather than judgment ("you rejected clever dashboards twice because your staff need defaults; default to conservative UI and escalate the policy decision"). We bet (a) the judgment record is more valuable to operators than the facts record, and (b) the providers will not prioritize the judgment object in the next 24 months because facts are cheaper to ship and demo. We compound through that window or the bet does not pay off.

What would falsify the bet, observably: if any major provider (Anthropic, OpenAI, Cursor, Replit, GitHub Copilot, Devin, or another agentic builder) ships a memory product with both project-specific judgment capture AND user-editable taste memory exposed to non-engineer operators, AND Mandaire's renewal rate drops by 30% or more in any rolling 90-day window during the 24-month bet, we have lost the timing-window bet. The renewal-rate metric is the business-level falsifier; the feature-shipping check is the leading indicator. We tie the bet to observed buyer behavior, not to a competitor-feature checklist, because a competitor could ship four-of-six features and still win commercially. We bet on commercial outcome.

Bet 3: the non-engineer segment. Cursor serves engineers in an IDE. Claude Code, Codex, and the agentic-builder products are aimed at people who can read the code. Our audience is operators, founders, and product people who have a vision but cannot or should not be the one writing the code. The bet, sharper than "non-engineers want this": non-engineers can verify output quality well enough to safely operate the governed loop without a technical co-founder in every step. That is the load-bearing claim. The cost of this bet: we lose the engineer market entirely. What would falsify it: if the segment turns out to need a technical co-founder in the loop anyway, our value collapses to that of a junior co-founder's tool rather than the architectural function we claim.

Bet 4: enforced escalation discipline. Two pieces. The easy half: a code gate that blocks risky actions until you approve (a structural mechanism, see §The mediation mechanism → S2). The hard half is taste: knowing WHEN to escalate. The rule: surface only when both the AI loop has hit diminishing returns AND a real decision needs fresh human judgment. The honest framing: the structural half is binary and verifiable; the taste half is a credibility bet on Mandaire's ability to build escalation taste over time and have users renew because of it. The cost of this bet: every escalation is a tax on your time; bad taste makes the tax annoying. What would falsify it: your inbox fills with escalations you didn't need, OR real judgment calls slip through to autonomous execution, OR we ask before the AI loop has converged. You can monitor all three.

Bet 5: governed delegation is worth the setup and audit burden. Mandaire asks users to do something most AI products avoid asking: define disclosure boundaries, correct judgment, inspect artifacts, approve irreversible actions, occasionally read audit trails. We bet the value of governed delegation exceeds the cost of teaching and supervising the system. This bet sits underneath the other five: if users don't want the governed loop in the first place, provider competition (Bet 2) doesn't matter, segment fit (Bet 3) doesn't matter, escalation taste (Bet 4) doesn't matter. Cost: onboarding is heavier than a chatbot; the first 30 days may feel slower than "just ask Claude"; some users will bounce before the compounding becomes visible. We lose buyers who want magic with no ceremony. What would falsify it: qualified users admire the architecture but stop using it because the supervision burden feels like managing another employee; OR users route around the system for urgent work because the governance layer feels too heavy.

Bet 6: protocol distribution over product distribution. We bet that publishing the spec (the MCP tool surface, the entity-graph schema, the disclosure-policy semantics, the audit-log format) and inviting non-Mandaire implementations creates a larger ecosystem to participate in rather than a smaller one to own. The Mandaire-operated tier becomes one implementation; the protocol is the standard. The competitive question shifts from "is Mandaire bigger than Cursor?" to "did Mandaire shape the standard the labs eventually adopt?" Cost: we forfeit the path where Mandaire is the dominant single platform. Other implementations can adopt the spec without coordinating with us. What would falsify it: 24 months after spec v0.1 publication, fewer than three non-Mandaire implementations exist with non-trivial users, OR implementations exist but do not federate. In that case, the "protocol" was self-flattering documentation and the work should have gone to product features.

Stated as bets, not as moats, this is what we ask you to evaluate us on. You will see the answers play out in our renewal rate, our audit logs, our willingness to tell you to switch providers when switching is in your interest, and the number of non-Mandaire implementations of the protocol two years from spec v0.1. We will earn it or we will not.

The bounds

What we cannot yet prove, named in full.

The strongest proof we have today is that mandaire.app and mandaire.dev were built using this exact system, in months, directing the build in plain English. The artifacts on the .dev page are real, redacted excerpts from the actual decision ledger and taste memory. That case is bounded in four ways, all named here:

  1. First-user identity. The first user has been running Mandaire daily and also helped design it. This case is "the early user using the early user's tool." It does not prove that a first-time external operator gets comparable results.
  2. Causal attribution. The same operator, running Cursor and Claude Code in a disciplined loop, might have shipped the same products on similar timelines. "Substantive working product" is unfalsifiable on its own, we cannot prove from this case alone that Mandaire did the causal work versus the operator's underlying ability.
  3. Generalization. The judgment artifacts were produced by and for one operator. Whether the same loop produces equally useful artifacts for a different operator is the next question to answer. Until external builds ship with their own ledgers, this is open.
  4. Falsification commitment. The first external case in flight is a domain expert with deep experience in a data-intensive field, with no engineering team, rebuilding a workflow that has historically required engineers. If that builder struggles, gives up, or produces output a domain expert cannot verify, we will say so on this page. The discipline of "we earn it or we don't" applies to the proof, not only to the bets.

The two surfaces

Same primitives. Different binding constraint.

Both surfaces use the same architectural primitives (persistent encrypted store, deterministic disclosure engine, central reasoner with replay-verifiable audit, BYO renderer, refused-paths ledger, open-protocol exit ramp). Both produce the same artifact shapes (intent brief, end-of-build, decision ledger, taste memory, failure admission, refusal note). The honest difference is which primitive carries the most weight on each surface, the binding constraint per domain.

mandaire.app, AI Chief of Staff. The work product is your life. Family, career, relationships, health, finance, time. Binding constraint: relationship-graph integrity. The disclosure engine is the load-bearing primitive on this surface. If Mandaire leaks the wrong thing to the wrong person at the wrong time, the product fails, irrespective of how good its judgment record is. The judgment artifact is your personal taste memory + relationship model + commitment ledger; the disclosure surface is real people in real time (family, friends, colleagues, advisors, doctors, lawyers, network). What it refuses: the wrong send, the wrong commitment, the wrong allocation of attention.

mandaire.dev, AI CTO. The work product is your product. Scope, architecture, builds, ships, refactors. Binding constraint: causal-model integrity. The decision ledger + refusal log + irreversible-action gate are the load-bearing primitives on this surface. Disclosure exists (PII in export fields, credentials, customer data, future-investor-facing material) but it is secondary; the surface is dominated by deferred-time judgment about future engineers, future users, future investors, future co-founders. If Mandaire builds the wrong thing because it failed to refuse a bad direction, the product fails, irrespective of how clean its disclosure record is. What it refuses: the wrong build, the wrong feature, the wrong technical bet.

What this means for the architecture in practice. The disclosure engine ships at full per-(person, topic, context, surface) granularity on .app because that is the surface's binding constraint. On .dev, the disclosure engine ships as a more constrained redaction-tool for decision-ledger excerpts when sharing with future investors or engineers; the per-person rules language exists but is not the value surface. Same primitives. Different intensity per surface. We tell you so explicitly because rhetoric ("same architecture, different work") that doesn't admit the asymmetry overstates how clean the cross-surface mapping is.

The relationship, the judgment record, the taste memory, the audit log, compounds across surfaces. A .dev customer who later wants .com can keep the substrate; the work product changes, the primitives do not. The cross-surface continuity is real even though the binding constraint per surface differs.

What this is not

A few things Mandaire is not, to head off the obvious confusions.

Not a chatbot. Chatbots answer questions. Mandaire holds your full context and acts on your behalf with disclosure mediated for every recipient. The difference is not incremental; it is structural.

Not a productivity tool. Notion, Todoist, Asana organize work. Mandaire organizes the work and the relationships and the decisions and the judgment, with the privacy and disclosure architecture that lets you safely hand the system everything.

Not a note-taking app. Storage is necessary but not sufficient. Mandaire ingests, reasons, mediates disclosure, and acts.

Not "ChatGPT with your files." The disclosure policy engine, the sovereign encryption, the central reasoner service, the persistent agent architecture, and the progressive trust model are all structural differentiation that ChatGPT / Claude / Gemini cannot replicate without fundamental architectural changes that conflict with their business models.

Not a hardware product. The Humane / Rabbit / Limitless arc destroyed $5B+ proving that AI does not need a new gadget. Mandaire runs on the phone and laptop you already have.

Not a secret-keeping tool. Privacy and secrecy are different. Privacy is the default posture of a person with an inner life. Secrecy is active concealment of information someone else has a stake in knowing. Mandaire is infrastructure for privacy, in the way a journal is infrastructure for privacy.

Not lock-in. Open-source core. User-owned encrypted storage. Pass-through token costs. Self-host always available. Your data, your encryption keys, and the code to run the system yourself are always yours. This is a design requirement, not a marketing claim.

The protocol

Protocol, not platform.

Mandaire publishes its MCP tool surface, entity-graph schema, canonical-store schema, disclosure-engine semantics, and trust commitments as a versioned spec. Anyone can implement the protocol. Only Mandaire-operated instances carry the Mandaire brand and the support contract.

The competitive asymmetry is structural, not "we shipped first." Google cannot ship a tool that reads all Gmail to inform analysis you do outside Google's surfaces. Apple's Photos + iMessage + Mail integration with third-party AI fights everything Apple is doing with Apple Intelligence. Microsoft tried (Recall) and got pulverized publicly. VC startups cannot fit full-corpus ingest + local-first storage + frontier-model synthesis into per-seat SaaS unit economics. Open-source projects can build this, and Mandaire is closer to that posture than to a conventional startup.

The highest-value move from here is not shipping more features. It is publishing the architecture and the schema so others can build their own. The product becomes the spec, not the running system. The Mandaire-operated tier is one implementation; many others may follow.

Spec v0.1 is in preparation. It will document the MCP tool surface (the mandaire(verb, ...) single-tool architecture), the entity-graph schema, the canonical-store schema per source, the disclosure-policy rules language, the audit-log format, the trust commitments enforcement, and the federation hooks. Each section will name a falsifier: how an implementer can verify their implementation conforms, and how a user can verify the operator is honoring the protocol.

The two audiences

Architecture for the technical evaluator. Outcomes for the operator.

A page that talks about reproducible builds, AGPL licenses, deterministic disclosure compilation, replay-verifiable audit logs, and protocol federation is not the page a non-engineer founder reads before deciding whether to onboard an AI Chief of Staff. We know. The architecture matters to a different audience than the operator.

So this site (mandaire.org) is for the technical evaluator: the engineer your operator-buyer trusts to verify the architecture before they commit; the security-conscious advisor in their network; the auditor; the journalist; the security researcher; the implementer who wants to build a compatible Mandaire instance themselves. Their evaluation is what makes the operator's trust earnable. We invest in the architecture because the architecture's existence is what makes the operator's trust verifiable through someone they already trust, even if the operator never reads this page.

The operator surfaces are at mandaire.app (your life) and mandaire.dev (your product). Those pages talk about outcomes, prices, and what the system does for you. They reference back here when a careful reader wants to verify the architecture; they do not lead with it.

The honest framing: the architecture pays back two ways. First, through the trust brokers it makes possible, third-party audit (Q3 2026 roadmap), security researchers, technical advisors of non-technical buyers, journalists, named customer references, who do the verification work the operator cannot do themselves. Second, through the protocol becoming the standard others adopt, making Mandaire's operating commitments the reference point even for implementations Mandaire does not operate. Both are slower paybacks than direct buyer demand for technical features. We accept the slowness. The faster alternative, claiming architecture as buyer-acquisition lever for non-technical operators, is dishonest and we have no interest in shipping it.

Verification matrix

Per claim: enforcement, who can verify, current status, evidence, remaining gap.

The thesis is intellectually stronger than the evidence program, by design, because thesis is faster to revise than infrastructure. This matrix names per-claim where the evidence currently sits, what verification is available now versus on the roadmap, and what gaps remain. Every row is a commitment we earn or fail; "current status" is honest. We will update this table as evidence arrives.

Claim                              | Enforcement                       | Who can verify        | Current status     | Evidence/artifact                   | Remaining gap
-----------------------------------|-----------------------------------|-----------------------|--------------------|--------------------------------------|------------------------------------------------------
S1: Disclosure compilation         | Deterministic Python upstream     | Code reviewer + audit | PROTOTYPE          | Source repository (open) +           | Tamper-evident binding between policy
upstream of any LLM                | of any model invocation           | of Layer 2B           |                    | architecture diagram                 | source and runtime; conformance test suite
S2: Irreversible-action gate       | Typed action taxonomy +           | Code reviewer + user  | PROTOTYPE          | Source repository (open) +           | Comprehensive action taxonomy is
                                   | approval-token requirement        | observation in app    |                    | tenant-side approval UI              | engineering-incomplete; per-action gate
                                                                                                                                                                  for novel-class actions not yet defined
S3: Append-only refused-paths      | SQLite per-tenant; query at        | User export + replay  | PROTOTYPE          | Schema published; per-tenant         | Tamper-evidence (hash chaining, signing,
ledger as state                    | request planning time             |                       |                    | export available                     | transparency-log semantics) not yet built
No tenant data persists in         | In-memory only on Layer 2B host;  | Third-party audit     | LIVE CLAIM /       | Retention table per data class       | Crash-dump filter source + false-negative
central reasoner (storage)         | retention table per data class    |                       | AUDIT PENDING      | (above); audit log shape published   | rate; APM/telemetry deidentification floor
No learning from observed traffic  | Codebase commitment; no training  | Third-party audit +   | POLICY LIVE /      | Documented in trust commitment 2;    | Cloud-frontier provider retention not under
                                   | pipeline pulls tenant payloads    | code review           | TECHNICAL VERIFY   | absent training-data ingestor        | our control; need provider-policy disclosure
                                   |                                   |                       | PENDING            |                                      |
Replay-verifiable audit log        | sha256 of input + output + meta;  | User-side replay      | PROTOTYPE          | Audit-log schema; per-tenant SQLite  | User-facing replay tool; sample-replay
                                   | no raw content stored             | with original input   |                    | on Layer 2B host                     | published; tenant-held log signing
Reproducible-build encryption      | Build manifest + signed tag       | Anyone with the       | ROADMAP (Q3 2026)  | Source under AGPL                    | Reproducible-build pipeline + manifest;
module                             | per release                       | source                |                    |                                      | named third-party audit
All tenant-VM code open source     | Public repository; license tags   | Anyone (binary)       | ROADMAP (v0.1)     | Public repo URL                      | Repo currently a partial mirror; canonical
                                   |                                   |                       |                    | (repo URL forthcoming with v0.1)     | open release on GitHub for v0.1 spec
Disclosure-policy semantics public | Documented rules language in spec | Anyone with spec      | ROADMAP (v0.1)     | This page describes the language;    | Spec v0.1 publication with conformance
                                   |                                   |                       |                    | rules-language reference forthcoming | test vectors per rule type
One-command export                 | CLI tool + portable format        | User runs the command | PROTOTYPE          | Schema documented                    | Export format stability across versions;
                                   |                                   |                       |                    |                                      | round-trip verification (re-import test)
Self-host always available         | Open-source skeleton + docs       | User runs self-host   | PROTOTYPE          | Docker compose setup documented      | Parity SLA between hosted and self-host
                                   |                                   |                       |                    |                                      | tiers; patch cadence commitment
Mandaire = controller AND          | Article 28 contract terms;        | Legal review of       | POLICY LIVE /      | Privacy policy; processor terms;     | DPIA + named DPO + breach-notification
processor (legal posture)          | Article 30 records of processing  | published terms       | DOCS PENDING       | named legal counsel forthcoming      | runbook; cross-border transfer SCCs
Cloud-frontier provider retention  | Disclosed in audit; provider      | Audit + provider      | ROADMAP (Q3 2026)  | Provider terms (Anthropic / OpenAI / | What providers retain when Layer 2B
disclosure (what Anthropic /       | policies linked from spec         | terms                 |                    | Gemini) linked from spec; Mandaire   | routes to them; how Mandaire mitigates
OpenAI / Gemini retain)            |                                   |                       |                    | mitigation per provider documented   | (or names where it doesn't mitigate)
Bet 6: protocol adoption           | 3+ non-Mandaire implementations   | Public registry of    | ROADMAP (24mo)     | Spec v0.1 publication + federation   | Active implementations beyond Mandaire-
                                   | with non-trivial users at 24mo    | implementations       |                    | hooks                                | operated tier; user counts per impl
Q3 2026 audit completion           | Named auditor + named scope       | Audit report          | ROADMAP (Q3 2026)  | This page commits scope + timeline;  | Auditor selection (Q2 2026); audit SoW;
                                   | items above; published report      |                       |                    | auditor selection forthcoming        | response posture for partial-compliance

Legend: COMMITMENT (LIVE)        = stated AND independently verifiable today.
       LIVE CLAIM / AUDIT PENDING = stated; verification on the Q3 2026 audit roadmap.
       POLICY LIVE / TECH PENDING = behavioral commitment in code; technical enforcement (vs policy-only) pending.
       POLICY LIVE / DOCS PENDING = legal posture stated; supporting documentation forthcoming.
       PROTOTYPE                 = built but not yet hardened to commitment standard.
       ROADMAP                   = named timeline.
Where evidence is "forthcoming," it lands with the v0.1 spec or the Q3 2026 audit.

What this matrix is for. Buyers, technical evaluators, security researchers, journalists, and would-be implementers each need different verification surfaces. The matrix lets each audience identify which row matters to them and what evidence is current versus future. We commit to keeping this matrix accurate: when a row moves from PROTOTYPE to COMMITMENT (LIVE), the date moves with it; when a ROADMAP item slips, that slip is named here, not buried.

What it is not. A claim that the architecture is finished. Half the rows are PROTOTYPE today. The matrix is honest about that gap; turning PROTOTYPE rows into LIVE commitments is the operational work of the next 6-12 months. The matrix exists so the gap is observable to the same audiences whose evaluation makes the architecture pay back.