Skip to content

Principles

Why we enforce privacy in code, not policy

The difference between a promise and a guarantee is whether someone else can quietly change it.

Most privacy commitments are written in the language of intent. A policy says a company will not do something — until, one quarter, the incentives shift and a revised policy says it now may. Nothing about your data changed. Only the sentence describing what could be done with it did.

Pickerbird takes a different position. The boundaries you set aren’t described in a document you have to trust — they’re enforced by the software itself. When you mark something private, there is no code path that lets the AI read it. Not a discouraged one. Not one gated behind a setting. There simply isn’t one.

A policy is a promise. Code is a constraint.

The distinction matters most in the moments you’re not watching. A promise depends on the promise-keeper’s continued goodwill, their ownership structure, and their legal exposure. A constraint holds regardless — it doesn’t have a mood, a board, or an acquisition.

If a boundary can be moved without your involvement, it was never really your boundary.

This is why the three tiers — private, ask-me-first, and open — are enforced at the level where access actually happens, not in a preferences screen that a future update could quietly reinterpret.

What that looks like in practice

When the agent assembles context for a response, it can only request items whose tier permits it. A private note isn’t filtered out after retrieval — it’s never eligible for retrieval in the first place. The check is upstream, and it’s the same check every time:

// eligibility is decided before retrieval, not after
function visibleTo(agent, item) {
  if (item.tier === 'private') return false;
  if (item.tier === 'ask') return agent.hasConsent(item);
  return true; // 'open'
}

There’s no override flag, no admin bypass, no telemetry exception. That function is the whole story, and it runs the same way for everyone — including us. A few consequences fall straight out of enforcing it in code:

  • It can be inspected — the rule is in the open, not in a data-handling FAQ.
  • It can be tested — a private item that ever reaches retrieval is a failing test, not a policy footnote.
  • It can be audited — over time, by people who don’t have to take our word.

Control you can verify

We’d rather you not take our word for any of this. A guarantee you can check is worth more than a promise you have to believe. It’s early, and we’re building in the open — if this way of thinking resonates, the beta waitlist is the best place to follow along.

Your AI should answer to you.

Join the beta waitlist and be among the first to try Pickerbird.

Join the waitlist