Planned nothing on this page exists yet
Who may see and change what.
A plan for letting a company decide who may see and change what in its smart development environment (SDE): a hierarchy, clearance levels, delegation within your own rights, approval requests with a reason, and a storage service. A plan, not a product.
- There are no roles, clearances or approval requests today. There is no sign-up, no pricing and no early-access program for this.
- No company uses these features, no certification is claimed, and there is no date for any of it.
what exists today
A workspace is one team, and everyone inside it is equal.
Anyone with a token for a server can open every workspace on it, and anyone inside a workspace can approve what an agent wants to do. Opening a GitHub repository works today; sending changes back as a pull request is designed but not built. Security says so in full. The plan below needs new groundwork first, and it would share one foundation with VESPR for educators.
the plan
What an organization would get.
Hierarchy and roles Planned
Organization, then division, then team, then person, with one manager for each person. Roles describe what you do: owner, admin, manager, member, viewer and auditor.
Clearances and labels Planned
Levels describe how much a person may see. The working names are L0 Public, L1 Internal, L2 Confidential, L3 Restricted and L4 Critical; they are placeholders. Compartments are need-to-know tags such as payments or infra. A file or folder carries a level and compartments; an unlabeled file counts as L1. You may do something to a file if your level is at least the file’s, you hold every compartment on it, and a grant or your role gives you that verb (read, edit, approve or manage). An agent gets the rights of the person who asked it, capped by the workspace’s mode, and never more.
Delegation within your own rights Planned
A manager could grant or take back access to a file only if they hold manage on it, only up to their own level and compartments, only for people in their own part of the hierarchy, and never for themselves. A grant carries an expiry. Every change is recorded in an audit log and shown to the person it affects.
Approval requests with a reason Planned
A request says who is asking, for what, which verb and for how long, and has a reason box. The reason can be written by hand or drafted by AI from context; the person sees and edits the draft before sending. The request goes to the requester’s manager, and moves up if that manager lacks the right. The approver can approve with a narrower scope, deny with a note, or pass it up. Nobody approves their own request, the most sensitive level needs two approvers, and everything is logged.
Pipeline stages Planned
Plan, build, test, review and release, where each stage says who may edit, who may approve and what agents may do there (for example, no bypass mode and nothing under release/). It would tie into GitHub pull-request approvals once sending changes back as a pull request exists.
A storage service Planned
Folders and files for each organization, carrying the same labels as code, with quotas, versions, a trash folder and share links that expire. Access over HTTP and WebDAV. The server would check the person’s rights on every read and write. Two designs are open: storage the operator runs, or a connector to an organization’s own network storage. Neither exists.
why this needs new groundwork
A shared document cannot hide a file from someone inside it.
A workspace is one shared document, and everyone connected receives all of it. The plan has two parts to fix that: file spaces, one shared document per label, where the server checks a person’s rights before letting them connect; and the storage service above. Until those exist, an access model could only be rules, requests, approvals and an audit log. It would not hide content, and we would say so.
- Also planned: an exportable audit log, single sign-on for companies, and a view of how people work together built from the records of who edited and approved what. It would be summarized, visible to the people it describes, and reviewed against employment rules before use.
- Silent Consensus is a separate product with its own business side, built earlier by its own team. None of it is part of VESPR, and nothing from it would be used without its authors’ written agreement.