Protocol Systems
ProtocolVault
Secure storage for credentials, documents, sensitive records, secure notes, and critical information.
Product vision
What it is being built to do.
The information that matters most in a security program — access codes, alarm details, insurance records, medical directives, legal documents, vendor contacts — is usually stored in the least secure place available: a shared drive, a phone note, a filing cabinet, or a staff member's memory.
Protocol Vault is being designed as the controlled place that information lives, with defined access for the people who legitimately need it and a record of who reached it.
Problems addressed
The conditions it is designed for.
01
Critical records are stored informally and inconsistently.
02
Access is granted by sharing rather than by permission.
03
There is no record of who retrieved what, or when.
04
When staff or advisors change, information leaves with them.
Individually competent systems, procured at different times, produce a program whose weakest link is the space between them.
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.
- 01Structured storage for credentials, documents, and records
- 02Granular access by person, role, property, or entity
- 03Access history
- 04Emergency access provisions with defined conditions
- 05Secure notes and structured record templates
- 06Retention and removal controls
Ecosystem connection
How it connects.
Vault holds what Platform describes and Identity protects. Residence and Command reference Vault records during operations rather than duplicating them.
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.
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 Vault is in development. Protocol is talking to the people it is being built for.
Adjacent systems
What it works alongside.
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.
Vault
- Structured storage for credentials, documents, and records
- Granular access by person, role, property, or entity
- Access history
Related capabilities
The work this product supports.
Discuss this product.
Speak with Protocol about Protocol Vault — its development direction, the requirements it should meet, or the security program it would sit inside.