Oak Keyring's architecture starts with a local encrypted vault and keeps every surrounding workflow accountable to that center: unlock, edit, import, export, recover, and optionally sync encrypted data through Google Drive.
Oak Keyring is not shaped as a thin client for a remote password service. The local encrypted vault is where password data begins, where normal user actions land, and where the product's trust boundary is easiest to reason about.
That model keeps the core question close to the user: what protects the vault on this device, what key material can open it, and what state changes are allowed before anything is synchronized elsewhere.
The interface is designed around direct vault work: search records, inspect details, create and edit entries, generate passwords, handle trash, and review health signals without waiting for a cloud service to authorize the basic workflow.
Sync can move encrypted state between devices, but it should not be in the critical trust path for every everyday action. That separation is what makes the product feel quiet without hiding the security boundary.
Creation, unlock, master-password change, recovery, cancellation, and cleanup are treated as one lifecycle rather than separate feature islands. The same architectural concern follows the secret from entry to use to teardown.
The public site does not expose unnecessary implementation detail, but it can state the invariant: recovery must not bypass the vault model, and cleanup is part of the security design rather than an afterthought.
Google Drive sync exists to give users backup and multi-device movement. It should carry encrypted vault data and metadata needed for synchronization, not become the place where trust is rooted or keys are delegated.
In this architecture, remote storage can help move state. It should not decide what the vault means, own the vault key, or turn the product into a hosted password manager under a different name.
Import, export, and recovery are not edge utilities attached after the product is built. They are architecture paths that prove whether the user actually controls the vault.
This page still avoids final wire protocols, file-format promises, and audit language while the project remains in first-preview status. The public claim is the shape of the system: local-first vault ownership, explicit lifecycle boundaries, optional encrypted sync, and real paths for leaving or recovering.
