Tested behaviors
Each page below renders one of the vault's executable behavior suites, word for word. These are not descriptions of intent: every scenario runs against the real vault in continuous integration, denials included.
A portal that reads like an application
Everything a person meets in SkyKeep is a page in a web application, and it should behave like one. The sign-in box belongs to the signed-out
8 scenarios
Vault administration
The per-vault admin console is where an engagement's administrator manages compartments, user accounts and their grants, reviews
6 scenarios
Archive intake opens uploads safely, one document per file
A zip or tar.gz archive uploaded to the vault is opened entirely in memory and every file inside travels the full intake pipeline on its
7 scenarios
The audit trail
Every action anyone attempts against the vault is recorded — allowed, refused, or quarantined alike. Refusals carry their real reason in the
5 scenarios
Inviting people in bulk
An administrator invites people by pasting their email addresses into one box. However they separate the addresses — commas, spaces, semicolons, or
5 scenarios
Choosing which models the vault runs
SkyKeep runs every AI step against a model runtime inside your own deployment, and an administrator chooses which models. There are two
12 scenarios
Delegated compartment administration
A client's own administrator can organise the vault's compartments — creating them, naming them, putting people in them, and merging two into
8 scenarios
Delegation tokens fail closed
An agent acting on someone's behalf carries a signed, short-lived delegation token naming who is acting, for whom, and over which
4 scenarios
The demonstration installation
Showing the vault to someone used to cost a full manual setup: create the compartments, invite the people, rotate every forced password, find some
17 scenarios
Doc Keep — every document you can reach, in one list
Doc Keep is a single long list of every document stored in the compartments you can reach, with a column for each thing the vault knows about it: the
5 scenarios
Document intake reads the content, and refuses what it cannot identify
Documents arrive as untrusted files. The vault converts each one into normalized markdown with structured metadata before anything else sees
15 scenarios
Document stats
The vault portal shows how many documents it holds, in two views — by document, each with its compartment set, and by compartment, each with
5 scenarios
A document is worked in stages, and the compartment owns the work
An upload is not a moment, it is a piece of work: the vault scans the file, identifies what it is, converts it to Markdown, reads a summary out
12 scenarios
The model reads the whole thought, and the citation still names the chunk
A document is cut into chunks so it can be indexed, and how long a chunk may be is decided by the embedding model's input limit — not by how much
6 scenarios
First run of a fresh vault
A brand-new SkyKeep vault opens as a plain sign-in page and has exactly one account: the bootstrap administrator, admin001, whose initial
3 scenarios
The vault follows a reference the question never named
A vault's answer is only as wide as what one search can reach, and some questions are not shaped to be reached in one search. "Who took custody of
3 scenarios
Encrypted front door
Every way into the vault passes through a single encrypted entrance. The vault's internal services accept no connections from outside the
4 scenarios
Help at hand
A person meeting SkyKeep for the first time should never have to go looking for the manual. Beside every substantive control there is a
6 scenarios
Documents that give the vault orders
A document is content, never a command. Anyone can upload a file that says "ignore your instructions" somewhere inside it — a hostile
7 scenarios
Sign-in code mail through the customer's relay
The vault sends one-time sign-in codes through the customer's OWN mail relay — one of its two disclosed outbound connections, and content-free
7 scenarios
The vault's tool surface for agents
Any MCP-compatible client — an agent, a custom front-end — reaches the vault through the published tools, and through nothing else. The surface
7 scenarios
The vault ships its own operations runbook
The runbook pages tell an operator how to bring a vault up, in order, with a check at each step — and what the errors they will actually meet
4 scenarios
Outbound mail log
The vault keeps a record of every mail it sends — who it went to, what kind of mail it was, when, and whether it arrived at the relay. The
8 scenarios
What a person may reach, and who may change it
Every person's authority over every compartment is exactly one of three levels — none, read, or write — and there is no fourth. A write level
9 scenarios
Vault portal
The web portal is a thin window onto the vault's one gated door. It refuses service entirely when it is not configured, explains nothing
4 scenarios
Portal navigation menu
The vault portal carries a left-side menu of clickable icons leading to its work surfaces: uploading documents, document statistics and the
3 scenarios
Query page — retrieval and synthesis in two explicit stages
The query page never blurs together "what the vault found" and "what the model said about it". Stage one retrieves document chunks through
4 scenarios
Search tells the truth about its results
Compartment boundaries can trim a search's candidates before ranking. The vault casts a wide net before filtering, bounds what that net may
8 scenarios
Signing in to the vault
Sign-in starts with your password. Whether it then asks for a one-time code, delivered to the email address on your account, is a policy rather
6 scenarios
Operating the vault stack
An operator runs the whole SkyKeep deployment with one script: scripts/skykeep.sh start, stop, restart, or status. Start brings every
8 scenarios
Surfaces shaped by what an account can reach
The vault has always held that an administrator belongs to no compartment and can therefore read no document, and the delegated compartment
6 scenarios
Uploading documents and browsing the ones you can reach
An ordinary member's upload page takes one or more files at once, accepts them dropped onto the page as readily as chosen with a picker, and files
8 scenarios
The vault documents its own tested behavior
The help pages are the vault's user manual, served from the vault itself: guides for the portal, the admin console's settings, and the
4 scenarios
What the vault can read, said where the question gets asked
Every upload is kept twice: the file exactly as it arrived, and a plain-text rendering the vault can search. Both are encrypted under the
5 scenarios
The vault says which version you are reading and which pass wrote its summary
A document in this vault is not one thing forever. Upload the same file again and the vault keeps both, numbered — version 1, version 2 — so
9 scenarios
A profile that is yours and nobody else's
Every signed-in person has a profile page: their login name, where their sign-in codes are sent, a few lines about themselves, a picture, and a
9 scenarios