·by ouomoxo

Why an approval gate matters in an AI notes app

Most AI notes apps shipped in 2025 make one promise — "the AI will organize this for you". At first it feels like magic. A five-minute meeting note becomes a clean structure in thirty seconds. Half-typed placeholders grow into paragraphs. Scattered to-dos line up into a checklist.

The problem shows up later. Two months later you open one of those notes and realize: "wait, I didn't write that part."

The AI didn't just propose the change — it made it. Some tools quietly append a "Next steps" section to every meeting note; a few days on, that section reads like an actual decision you made. Except you didn't make it.

The asymmetry of trust

Chat assistants and notes are two different kinds of tool, and we should call out the difference up front.

A chat AI like ChatGPT restarts every session. If yesterday's chat is gone today, fine. If the model gets something wrong, ask again.

Notes are different. Notes are data whose value accumulates over time. Opening a meeting note two years later only matters if it's a faithful record of what you remember. If the AI "polished" it in between, what you're rereading isn't a note — it's the AI's summary.

That's the asymmetry of trust. Trust in a chat assistant is light. Trust in your notes is heavy, and once broken it's hard to repair.

What the approval gate does

OV's assistant exposes 13 tools to the model. Six of them are propose tools:

  • propose_create_note
  • propose_edit_note
  • propose_rename_note
  • propose_delete_note
  • propose_move_note
  • propose_create_event

The propose_ prefix is the whole point. When the AI calls any of these, it does not touch the filesystem. Instead, a diff box rises into the middle of the UI — before, after, Approve / Reject.

If you don't press Approve, your .md file changes by exactly zero characters.

Why this is more than a slogan

So far, any tool could make that promise. OV's difference is structural — it lives in the code, not just in the marketing copy.

OV's AI system has two separate paths.

  1. The read path — read_note, list_notes, search_notes, get_calendar, and three more. The AI uses these to understand the vault. They never mutate, so they aren't gated.
  2. The write path — the six propose_* tools above. This path always exits through the UI gate. When the AI calls one of them, the main process emits a propose IPC event; the renderer draws the diff. No file-write function gets called without a user click.

That means a new propose tool cannot be added without going through the gate — the IPC channel is built that way. The discipline is enforced by the wiring, not by a comment that says "remember to ask the user first."

Why BYOK is the second axis of trust

The approval gate controls what the AI changes. BYOK ("bring your own key") controls what the AI is told.

OV does not proxy AI calls. The request goes from your machine to OpenAI directly, signed with your API key. We don't hold the key, don't receive the request, don't see the response.

That's a marketing weakness on paper — we can't say "AI included free." But it produces two consequences worth more than the slogan:

  • Billing transparency: usage and cost appear in your OpenAI dashboard, exactly as the provider charges them.
  • Data-flow transparency: your note contents do not pass through our servers.

Put those two together and you get the most conservative trust model in the AI-notes category.

OV isn't an AI-skeptical tool. The opposite — we want the moments where an AI assistant should be helpful (summarizing today's schedule, drafting a retro note, fuzzy-searching across a vault) to be fast.

But the user has to be at the end of every helpful moment. The AI should be allowed to say "do this." It should never be allowed to decide "I am doing this."

The approval gate is that one principle, written in code.

Download OV · Try in your browser · Features

← Back home