Data model

Five entities, enough to describe any configuration.

Organization, project, environment

An organization is the boundary of billing and membership. It contains projects, and projects contain environments (dev, staging, production, and any custom ones). Entries live in an environment: the same key name in different environments means different values, and that is the normal, expected case.

Entry: variable or secret

The storage is one; behavior is set by visibility:

Visibility	Who can see the value	When to use
`plain`	everyone with access to the project	log level, service URL
`masked`	on explicit request, recorded in audit	passwords, tokens, API keys
`restricted`	machines only, never a human	keys people don't need at all

A key name matches [A-Z][A-Z0-9_]*. A variable must be plain; a secret must be masked or restricted.

Versions and labels

Every change creates a new version. Labels point out which version is what:

current — what consumers read;
previous — the previous value, a one-action rollback;
pending — a value that is already created but not yet applied (see rotation).

A rollback doesn't move pointers back — it publishes the old value as a new version: history stays monotonic, and it shows that a rollback happened at all.

Service and machine identity

A service is a first-class entity, not a by-product of a token. Identities are bound to it: each has its own login method, its own token TTL, and its own scope — project, environment, and, if needed, a set of keys.

Roles

Two independent planes. The organization role manages projects and members but does not by itself grant access to secrets — that is the project role's job (admin, member, viewer). Everything is denied by default.