RunOlga Docs
Trust & safety

Trust and safety

The rules that make Olga safe to rely on: grounding, permissions, isolation, and confirmation before every write.

Phase 1

This is part of what RunOlga delivers in Phase 1.

Olga is safe to rely on because four guarantees hold on every interaction. She answers only from real organizational data, stays inside the permissions of the person she is talking to, can never reach another organization's instance, and never writes anything to your records without your explicit confirmation. These are not preferences. They hold every time.

The four pillars

PillarWhat it guaranteesWhere to read
Grounding and provenanceEvery substantive answer is grounded in real data — methodology, your organization's content, or current state — and carries provenance for which records it came from. When Olga does not know, she says so.Grounding and confirmation
Permission scoping (RBAC)Olga respects the access scope of the person she is talking to. She cannot surface data outside that scope, and she does not pretend data does not exist when access is the real limit.Permissions and isolation
Instance isolationOlga can only see the organization you are authenticated into. She cannot reference any other organization's data, and does not know what other instances look like.Permissions and isolation
Confirmation before writesEvery database write Olga proposes requires your explicit confirmation, captured in the conversation. Nothing is written by inference.Grounding and confirmation

The principle behind all four

Enforced in the architecture, not the prompt

These four guarantees are enforced at the application layer, not the prompt layer. They are not behaviors Olga politely tries to honor and might occasionally miss under pressure. They are structural. Permission scoping is applied to every query before it runs; the confirmation step gates every write in code; cross-instance leakage is architecturally impossible, not policy-enforced.

This distinction matters. A guarantee that lives only in an instruction can be talked around — by a clever prompt, by an edge case, or by a model having a bad day. A guarantee enforced in the application cannot. Olga does not have the ability to read outside your scope, reach another instance, or write without confirmation, because those paths do not exist for her to take.

The practical effect is that you can trust the floor. Olga can be wrong about a judgment call, or admit she does not know something — but she cannot quietly expose data you should not see, mix up two organizations, or change your records behind your back.

How the pillars work together

The four guarantees reinforce each other across a single interaction.

  • You ask a question. Permission scoping narrows the query to what you are allowed to see, and instance isolation keeps it inside your organization.
  • Olga answers. Grounding ensures the answer comes from real records, and provenance records which ones, so the answer is traceable.
  • Olga proposes a change. Confirmation before writes means nothing reaches your records until you say yes, in the conversation.

For more on each, see Grounding and confirmation and Permissions and isolation. For the full picture of what Olga does and does not do in Phase 1, see Scope and roadmap.

On this page