Skip to content
PROTOCOL

Protocol Systems

ProtocolMobile

Mobile access to the Protocol environment for principals, staff, and security teams.

In Development

Product vision

What it is being built to do.

Security decisions are made away from a desk. The people who need access to a property's status, an access register, an emergency procedure, or an escalation path are usually traveling, at a residence, or in transit.

Protocol Mobile is being developed as the field surface for the Protocol environment, scoped tightly to what is genuinely useful in the moment rather than reproducing the full platform on a phone.

Problems addressed

The conditions it is designed for.

  • 01

    Critical information is only reachable from a laptop.

  • 02

    Field staff work from screenshots and printed sheets.

  • 03

    Escalation depends on knowing the right phone number.

  • 04

    Access changes cannot be made where they are needed.

Individually competent systems, procured at different times, produce a program whose weakest link is the space between them.
Protocol Mobile — design intent

Core functions

Functions in development.

These describe design intent. Nothing listed here is available to purchase today, and the list will change as the product is built.

  1. 01Property and posture status at a glance
  2. 02Access register and temporary access issuance
  3. 03Emergency procedures and escalation paths
  4. 04Alert acknowledgement and incident participation
  5. 05Secure retrieval of Vault records under policy

Ecosystem connection

How it connects.

Mobile is a client for Platform, Residence, and Command rather than a product with its own data.

No product in the Protocol ecosystem is designed to be bought alone. Each one owns a domain and reads from a shared record of what is protected and who is accountable for it.

Bought as products

  • Each system holds its own model of the environment
  • Alerts arrive in separate consoles with no shared priority
  • Integration is attempted after procurement
  • Nobody owns the boundaries between systems

Designed as a system

  • One record of what exists and who is accountable
  • Signals resolved against a shared priority
  • Interfaces specified before anything is bought
  • Every boundary has a named owner

Intended audiences

Who it is designed around.

The environments below shaped the design. A family office coordinating several households and a distributed enterprise are different problems, and a product that pretends otherwise serves neither.

A compact titanium field slab seated in a shock-isolated docking cradle.
The field surface.

Design discipline

Protocol builds against a described environment rather than a feature list. The constraint is the same one that governs a well-made instrument: every part has a reason, and nothing is added because it demonstrates well.

Protocol Mobile is in development. Protocol is talking to the people it is being built for.

Discuss This Product

Conceptual interface

An interface study, not a screenshot.

The panel below is an abstract study of the product's structure, drawn from its own function names. No interface has been built and no data is represented.

Mobile

  • Property and posture status at a glance
  • Access register and temporary access issuance
  • Emergency procedures and escalation paths
Product concept — a wireframe, not a screenshot.

Discuss this product.

Speak with Protocol about Protocol Mobile — its development direction, the requirements it should meet, or the security program it would sit inside.