Plain English

The Lexicon

Every term this site uses more than once, defined in one place. That includes the words we coined or borrowed and bent, like a Beemy silo (not the industry's kind).

15 min read

Jump to a category

The loop 7 Trust & control 8 Context & silos 3 Jobs & surfaces 2 Enterprise 6

The loop

Trusted inbox

An inbox Beemy has earned the right to act in: read-only until trust is proven, then handed autonomy a category at a time.

The trusted inbox is the whole loop in one phrase: Gmail and Google Calendar connect read-only first, Beemy learns who you talk to and how you sound, and only then does it start drafting and acting, one approval at a time.

It's called "trusted" rather than "automated" on purpose: trust is what's actually being built here, ahead of throughput. See the autonomy ladder for how that trust gets earned.

Triage

Reading, classifying and prioritising incoming email by relationship and urgency, before anything gets drafted or sent.

Triage is the first job Beemy does and the one everything else builds on: every message gets read, scored for who it's from and how urgent it actually is, and sorted, instead of landing in one undifferentiated pile.

It's a classification problem instead of a decision problem: Beemy sorts what needs you now from what can wait, but never decides what to say on your behalf without a draft you can review first.

One loop

The single triage-draft-approve cycle that runs across every connected surface, instead of a separate tool per inbox.

"One loop" is shorthand for Beemy's whole approach: rather than a different assistant for Gmail and a different one again for whatever comes next, there's one loop (read, triage, draft, approve) that runs the same way everywhere it's connected.

Live today across Gmail and Google Calendar; the same loop is what extends to each new surface next, once that surface clears its own safety gate.

Digest

Rolling out next

A single tuned roll-up of what actually needs your attention, compiled from every source Beemy follows: rolling out next.

Instead of fifty open tabs and a dozen unread newsletters, one digest at whatever cadence you set (daily or weekly), pulling from every connected source, ranked the same way triage ranks your inbox.

Not live yet: the digest sits on the roadmap's next lane, arriving once feeds, newsletters and RSS clear their own safety gate.

Not this: It can look like a generic "AI summary" bolted onto an inbox, but it's actually the same triage engine's output, compiled and timed.

Report automation

Rolling out next

Recurring status reports (KPIs, team updates) compiled from your connected tools and sent on schedule, rolling out next.

Report automation turns the same context Beemy already reads for triage into a recurring report: monthly stats, KPIs, a team update, compiled and, once you allow it, sent on schedule instead of assembled by hand.

Scoped and sequenced on the roadmap's next lane. It doesn't ship today, and this entry won't claim otherwise.

Inbox zero

An industry productivity goal (an empty inbox) that Beemy deliberately doesn't optimise for.

Inbox zero treats an empty inbox as the win condition, which rewards throughput: archiving, deleting, filing anything to get the number down. Beemy optimises for a different outcome: the right messages reaching you at the right time, with everything else handled quietly in the background.

An inbox that's quiet because judgement calls are actually being made is a better result than an inbox that's empty because everything got triaged away.

Not this: This is a decades-old productivity idea from elsewhere: this site argues against it explicitly, rather than claiming it as a Beemy feature.

Attention residue

A cognitive-psychology term for the measurable cost of switching away from an unfinished task, sourced on /the-numbers, not ours.

Attention residue names the finding that part of your attention stays on a task you switched away from unfinished, measurably impairing performance on whatever comes next, even minutes later.

It's the mechanism behind why a quiet inbox matters more than a fast one: every unresolved thread costs you something even after you've stopped looking at it. Full citation and caveats live on The Numbers.

Not this: A third-party research term, borrowed from cognitive psychology. We cite the study behind it here; we didn't coin the phrase.

Trust & control

Autonomy ladder

The three-rung path (read-only, approve-before-send, then a dial you control) by which Beemy earns the right to act on its own.

Every category of task climbs the same ladder at your pace: Beemy starts read-only, then moves to drafting things for your one-tap approval, and only reaches a category where it can act unsupervised once you turn that dial yourself.

Autonomy is never assumed and never inherited: trust earned on one surface doesn't carry over to another. See the safety gate for what a whole new surface has to clear before it joins the ladder at all.

Approval-first

The default posture for anything Beemy drafts: it waits in your drafts folder for a one-tap review before it ever sends.

Approval-first means the default answer to "will this go out on its own?" is no, until you've explicitly said otherwise for that category. A draft is a proposal that waits for you, not an action already taken.

It's the second rung of the autonomy ladder, and the one most people stay on the longest: the time saving of a written-for-you draft, without giving up the final word.

Read-only first

The starting posture for every new connection: Beemy reads and learns before it can draft, send, or file anything.

Connecting an account doesn't hand over control. Beemy starts read-only, watching how you work and how you write, before it's ever allowed to act on your behalf. That's the first rung of the autonomy ladder, not a formality.

It's also the default for every new surface as it comes online: the same read-only-first posture applies the moment a connection is made, with no exceptions.

Escalation

Beemy surfacing something to you with a plain-language reason, instead of guessing at what to do with it.

When something is ambiguous or high-stakes, Beemy doesn't quietly pick a side: it escalates to you with a "why this reached you" explanation attached, so the interruption itself carries information.

Zero interruptions isn't actually the goal: an inbox that never escalates anything is a sign triage has broken down. Escalation is the release valve that makes the rest of the autonomy ladder safe to climb.

Safety gate

The bar a new surface has to clear (security, reliability, product fit) before Beemy is allowed to act there unsupervised.

Every surface Beemy touches has to clear the same safety gate before it goes from read-only to acting on your behalf: one bar, applied the same way every time, no matter which connection is asking.

It's the reason "next" on the roadmap doesn't mean "soon and unverified": a surface clears its safety gate, or it stays read-only until it does.

Kill switch

One move that drops every category, in every connected silo, straight to read-only.

The kill switch is the blunt end of the autonomy ladder. It turns every category down, in every silo, in one move.

Nothing wakes up again until you grant it back. Any team member can pull it, with no reason needed.

Crypto-shred

Destroying the encryption key that guards a silo, so its data becomes unrecoverable even though the key never touched the data itself.

Beemy doesn't hunt down and overwrite every copy of your data to delete it. It destroys the key that unlocks it. Once the key is gone, every version of every row it protected is unreadable, for anyone, including Beemy.

It's the step that makes a delete final. The rows are also purged, but destroying the key is what makes deletion irreversible.

Erasure proof

The audit record a completed deletion writes, naming every table checked, whether the key was destroyed, and when.

Deleting a silo makes a claim: that the data is gone. The erasure proof is the evidence. It records the row counts after the purge, and whether the key can still be opened.

That record is built to outlive the data it describes. The proof of your erasure must survive the erasure itself, or it proves nothing.

Context & silos

Silo

An architectural wall between contexts (work and personal, or one team member's data and another's) that no reply can cross by accident.

Beemy keeps personal, work and (for teams) shared context in separate stores, with no path between them. A work reply can't reference something from your personal inbox, and vice versa. Unlike a filter that might catch a stray message after the fact, there's simply no route for it to travel.

This is the single most-used word on this site, and the one most likely to be misread on first encounter, hence the disambiguation above.

Not this: Not the industry's usual meaning. Elsewhere a "data silo" is an accident: information trapped somewhere it should be shared. A Beemy silo is the opposite: a deliberate wall, built on purpose, because some things should never cross.

In your voice

Drafts written to match how you actually write to a specific person (formality, length, sign-off), not one generic AI tone.

Beemy studies how you've written to each person you correspond with (how formal, how long, what sign-off, even emoji habits) and drafts accordingly, person by person rather than one house style for everyone.

Every edit you make teaches it: correcting a draft's tone for one relationship doesn't change how it writes to anyone else.

The Hive

Two things on this site: Beemy's blog, and the shared context a team's members can lean on across each other's work.

As a noun about writing, the Hive is beemy.co/blog: the essays behind the product, on email overload, trust and assistant design.

As a noun about a team, the Hive is the shared layer teammates can lean on (context nobody has to re-explain to their own assistant) without moving the wall around anyone's personal silo. Both senses share the same idea: things multiple people, or one publication, hold in common on purpose.

Jobs & surfaces

The Playbook

A browsable library of concrete jobs people actually hand to Beemy, across both work and personal life.

Where /features describes capabilities, the Playbook describes jobs. These are the recipes people actually use it for: triage an inbox before a trip, draft the awkward follow-up, track a reimbursement.

Filterable by category and by silo, so a work recipe and a personal one never appear side by side pretending the same assistant instance handles both with no wall between them.

Surface

A connected app or channel (Gmail, Google Calendar, and whatever comes next) treated as its own trust boundary with its own autonomy dial.

"Surface" is the word this site uses instead of "integration" or "channel" when the point is trust, not connectivity: each surface Beemy touches has to clear its own safety gate and earns its own autonomy, independent of any other surface.

A grant on one surface never carries over to another: turning up autonomy on one connected app says nothing about what Beemy can do unsupervised anywhere else.

Enterprise

SSO

Single sign-on: employees authenticate through your existing identity provider instead of a separate Beemy password.

SSO over SAML 2.0 or OIDC rides your existing identity provider: add or remove someone there, and their Beemy seat follows automatically, with no separate account to manage.

Paired with SCIM for provisioning, this is the access-control half of Beemy's enterprise story; the isolation half is the silo model every tenant gets by default.

SCIM

The provisioning standard that keeps who holds a Beemy seat in lockstep with your identity provider, automatically.

SCIM provisioning means seats are added and removed the moment someone joins or leaves in your IdP. There's no manual offboarding step for Beemy specifically, and no seat left active after access elsewhere has already been revoked.

It's the automation layer under SSO: SSO handles authentication, SCIM handles who exists at all.

SOC 2 Type II readiness-stage

Beemy's honest status: the controls SOC 2 Type II evidences are already built and enforced, but the audit's observation window hasn't happened yet.

SOC 2 Type II is an auditor's opinion, formed by observing a company's controls in practice over a window of months rather than a one-time paperwork exercise. Beemy's silo isolation, encryption, audit logging and deletion controls are already built and enforced; what's left is engaging an auditor and completing that observation window.

Said as "readiness-stage" rather than claimed outright, because the gap between "built" and "audited" is exactly the kind of overstatement this site's honesty gates exist to catch.

Not this: Not a claim of certification. "Readiness-stage" is said plainly instead of rounding a built-but-unaudited architecture up to a badge that hasn't been earned.

Data residency

Keeping a region-pinned tenant's data, encryption keys and model inference inside that region, for enterprise customers who require it.

Data residency means an enterprise tenant can require that its data, its encryption keys, and even the inference calls made against its content stay physically in-region (the EU, for instance) rather than wherever the nearest server happens to be.

It sits alongside SSO/SCIM and SOC 2 Type II readiness as one of the three concrete enterprise commitments this site names: an enterprise-deployment capability scoped in a direct conversation, unlike a default switched on for every account today.

Sub-processor

A third-party vendor Beemy relies on to help provide the service (hosting, model inference, and similar), disclosed by name on a dedicated register.

Any outside vendor that touches user data as part of running Beemy (a hosting provider, an AI model provider) is a sub-processor. Beemy names every one of them on a dedicated register, not just a passing mention in the privacy policy.

Naming them is a small thing that costs nothing to disclose and would cost real credibility to hide. It's the same principle behind every other honesty gate on this site.

Zero data retention

A vendor agreement under which a model provider keeps no copy of a message once the call it answered has finished.

Zero data retention is a term in the agreements Beemy has signed with OpenAI and Anthropic: each provider sees only the message content of the one inference call it handles, and keeps none of it once that call ends. Neither provider trains its models on that content.

Beemy also enforces the posture in code: an allowlist checks every model call against a fixed list of endpoints cleared for zero retention, and refuses any endpoint that fails the check. See the full register for both providers' own data-processing terms.

Related Sub-processor

Get your time back.

Beemy is in private beta. Join the waitlist and go from connect to a quiet, triaged inbox before you close your laptop tonight.

Talk to us

Last updated 12 September 2026