Saberra Academy
Technology 2 of 10 in this collection

Consent-Based File Handling in Saberra

Technology · 4 min read

The design philosophy behind how Sera writes to a user Drive: consent is a property of every action, not just the one-time OAuth grant. Seven principles keep each write previewable, redirectable, reversible, visible, and user-governed.

This article captures the design stance behind how Sera touches a user's Google Drive. The central idea is simple and load-bearing: consent is a property of every individual action, not just the connect-time OAuth dialog. A one-time permission grant is necessary but nowhere near sufficient — trust is earned or lost at the moment of each action. Seven principles make that real.

1. Least privilege, made legible

Sera authenticates with the Google drive.file scope. She can only ever see and touch files and folders she herself created — never your existing Drive content. This is the strongest structural guarantee in the system.

The frontier move is not the scope itself but making it legible. The Drive-connect screen states plainly: "Sera can only ever see the folders and docs she creates, never your existing Drive." That single sentence turns a scary OAuth grant into a trust moment.

2. Preview before write

Before filing into a brand-new branch of your Drive, Sera should surface where the document is going and let you redirect it. That is consent at the moment of action, not only at connect time. The same discipline governs bulk operations on the operator side: consolidation tooling runs in dry-run by default and shows every move before anything is written.

3. Reversibility over confirmation

A cheap undo beats an anxious "are you sure?". Operations that remove or relocate content trash — recoverable for 30 days — rather than delete. People consent far more freely to actions they know they can walk back, so every Sera write should carry an undo affordance such as "move it back" or "undo this filing."

4. The human owns the taxonomy

Sera proposes a filing structure; she never imposes one. Any recommended shape is a default, not a mandate. The direction of travel is a user-editable filing policy that Sera reads before filing, so she files by your rules rather than house defaults. This is the consent principle applied to files: the affected party sets the boundary.

5. Full traceability

Every Drive write Sera makes is logged and surfaced in a plain-language What Sera did in your Drive activity feed in Settings, newest first, each entry linking straight to the saved document. Consent decays without visibility; an ongoing, legible activity record is ongoing consent. Because the feed shows only folders and docs Sera created, it can never surface your other Drive content.

6. Redaction as a visible guarantee

The Confidential Identity layer redacts protected names, companies, and emails at the save boundary, before anything is written to Drive. When redaction fires, the ideal is to tell the user — for example, "filed, and note that I wrote the codename in place of the protected identity" — rather than protect silently. Named protection builds trust in the whole system; invisible protection is invisible.

7. Idempotency as respect

Never surprise the user's filesystem. Same intent should always resolve to the same place. A bug that fragmented a Drive into duplicate folders is, at root, a consent failure: Sera changing someone's filesystem in ways they did not intend. Deterministic filing — paginated, parent-scoped, oldest-wins folder resolution — is UX and consent, not merely correctness.

The through-line

Structurally, Saberra already holds the hardest-to-retrofit foundations: least-privilege scope, redaction at the boundary, and deterministic filing. The ongoing work is mostly about making the safety legible — previewable, redirectable, reversible, visible, and user-governed — rather than building new safety from scratch.

For a technical team, the practical implication is that these principles are acceptance criteria, not aspirations. Any new capability that writes to a user's Drive should be checked against all seven before it ships: does it preview, can it be undone, does it trash rather than delete, does it respect a user-defined structure, does it appear in the activity feed, does it redact visibly, and is it idempotent? Consent-based file handling is a stance carried through every action, end to end — and it is what lets a user hand Sera write access to their Drive without ever feeling they have handed over control.

Key points

Consent is a property of every action, not just the one-time OAuth grant; each write should be previewable, redirectable, reversible, visible, and user-governed. Seven principles: least-privilege drive.file scope, made legible (Sera can only ever see the folders and docs she creates, never your existing Drive); preview before write; reversibility over confirmation (destructive operations trash, recoverable for 30 days, never delete); the human owns the taxonomy (Sera proposes a filing structure, never imposes one); full traceability via a What Sera did in your Drive activity feed; redaction as a visible guarantee (protected identities swapped for a codename at the save boundary, with the ideal being to tell the user rather than protect silently); and idempotency as respect (same intent always resolves to the same folder, so Sera never fragments your filesystem).

Discussion

Sign in or create an account to comment.

No comments yet. If you have tried this, say how it went.