Liberty Lock
How it works

One app. Three
deliberate views.

Follow Liberty Lock through its three access states: the everyday view with the vault sealed, the Protected Vault behind your real PIN, and a separate container behind a second PIN.

Begin with the three states
State model

The view changes. Protected items do not leak between states.

Everyday Access shows the app’s everyday view while the vault stays sealed. Your real PIN opens the Protected Vault. A second PIN opens a separate container holding only ordinary content you chose in advance.

Select a state to replay it · simulated screens · app in development

Conceptual Liberty Lock app simulation. Simulated home screen. The vault is sealed and no protected items are on screen.

Everyday view. The vault stays sealed.

01 — Access states

One app. Three access states. A boundary you control.

Everyday and Secondary Access are views. The Protected Vault sits behind an access boundary and opens only with your real PIN.

  1. 01

    Everyday Access

    What the app shows day to day. The vault stays sealed and nothing protected is on screen.

    Surface
  2. 03

    Secondary Access

    A separate container that a second PIN opens, holding only ordinary content you chose in advance.

    Surface
  3. —

    Access boundary

    Crossing it takes your real PIN. Encryption and platform-protected keys are planned as core constraints.

    Design target
  4. 02

    Protected Vault

    Credentials, recovery phrases, journals, photos and documents you choose to protect.

    Behind the boundary
Conceptual exploded view of the app: the everyday view and the second container in front, the access boundary behind them, and the Protected Vault behind the boundary.

Simulated screens · conceptual product model

Prepared transition

Seal the protected view in one controlled action.

The demonstration changes availability inside the app. It does not imply a network request, remote deletion, control over other apps, or a released performance guarantee.

Conceptual sequence · inside the app

  1. 01Protected Vault open
  2. 02Prepared action
  3. 03Vault sealed

Designed to work without a server round-trip. Seals Liberty Lock only; it does not lock your phone or other apps.

Simulated app screens: the open vault seals and the app returns to its everyday view.
Optional local rule

A signal may select a state without becoming a service-side history.

Trusted Signal remains a roadmap concept. The design target is local evaluation of a user-defined rule, such as arriving at or leaving a place you choose, with the resulting access state, not a remote activity record, governing the protected view.

Representation boundary

Readable on the device. Cipher-only across the boundary.

The object changes representation before an optional crossing. The service-side model contains no visual or functional path back to readable content.

Conceptual architecture sequence showing local input, access-state selection, a protected object changing from readable text into a cipher representation, a controlled boundary crossing, limited service scope, and information that never crosses.
Architecture target / guided sequenceLocal control. A changed representation. Limited service scope.
Trust zone A · local deviceUser device
Optional local ruleDEVICE CONTEXT
Access-state controllerPROTECTEDSelected on device
Protected Vault
PRIVATE NOTE
Readable only inside this trust zone
Device edgeControlled boundary
8F  2C  A1  7D  9B  44
Encrypted material only where an optional feature requires it
Limited zone B · externalService scope
Optional encrypted material
8F  2C  A1  7D  9B  44
Stored or processed without a readable representation

No reverse controlThe service-side model contains no key or decrypt action.

Outside intended readable scope
  • Vault content
  • Key material
  • Local context rules
Stage 01 / 07A rule begins on the device.

Optional context is intended to be evaluated locally rather than becoming a service-side activity record.

Conceptual architecture · mobile product in development