SkyKeep help
SkyKeep is a per-engagement document vault: what goes in is compartmented, encrypted, and audited, and what comes out is only ever what your grants admit. These pages are the user manual — and the behavior pages are rendered directly from the vault's own executable test scenarios, so the manual cannot drift from what is actually enforced.
Using the vault
- Using the portalUpload, search, Think, and what a quarantine or a denial means.
- What SkyKeep can readWhich file types the vault converts, what a partial conversion loses, what happens to one it cannot convert, and what your documents say about themselves.
- What you may typeHow long each box may be, the two characters a name will not take, and what actually stops injection — which is not a filter.
- The audit viewWatching the vault's own record fill in, who may read it, and why reading it is itself recorded.
- Agent tools (MCP)Every tool, its parameters, and its error contract.
Administering the vault
- Compartments and delegated administrationThe four powers a clientadmin holds, why it can read no document, and why merging widens.
- Admin console settingsEvery configurable setting, generated from the vault's own registry.
- Choosing the modelsThe two model roles, what each option is good and bad at, and what else a model change makes load-bearing.
- Provisioning a clientadminHow an administrator creates a delegated compartment administrator.
- Connecting a remote agentRegistering an agent client and exchanging its credentials for the bearer token it queries with.
Operating the deployment
- Operations runbookStartup sequence with health checks, and troubleshooting.
- Demonstration installationThe one-command demo vault: what it makes, what it deliberately weakens, and what it refuses without.
- Presenting the demonstrationWhat to show and in what order, and sample questions that need more than one document to answer.
- From a demonstration vault to a production oneThe supported conversion is a reinstall: what is dropped, what is rotated, what is destroyed, and why it does not run in reverse.
Looking at a demonstration vault?
If you were handed an account called user_hr, user_sales or user_both — or one of their read-only twins user_hr_ro, user_sales_ro and user_both_ro — you are looking at a demonstration installation: two compartments (hr and sales) holding 269 documents of twelve kinds in eleven file formats, split by category so that the grants decide which slice of the same vault an account sees — 184 documents for the accounts granted hr, 167 for the accounts granted sales, all 269 for the two holding both grants, and none at all for the administrator. Twenty-four of the 269, two of every kind, are held part-way through ingestion, waiting for a person to release them, so 245 are admitted and answerable. An _ro account reaches exactly what its writing twin reaches — the only difference is that it cannot upload, and the upload control is absent from its page entirely. Some things about it are deliberately weak and belong to demonstrations only: all six accounts share one email address, they share one short password, and none of them is asked to change that password at first sign-in. Such a deployment may also open the audit view to every signed-in account rather than to administrators only. Each of those weakenings is a separate, explicitly typed choice the operator made.
All six accounts also sign in on the password alone, and that one is not a waiver — it is the ordinary rule. The one-time code is a preference each account holds, and these six were simply created with it turned off, which is a state any account can choose from its own profile page. A read-only account signs in exactly as its writing twin does: the access level is a grant, not a difference in authentication. The sign-in path has no idea it is serving a demonstration. None of this changes what the vault will hand you: your compartment grants decide that, here exactly as anywhere else.
Tested behaviors
- A portal that reads like an application
- Vault administration
- Archive intake opens uploads safely, one document per file
- The audit trail
- Inviting people in bulk
- Choosing which models the vault runs
- Delegated compartment administration
- Delegation tokens fail closed
- The demonstration installation
- Doc Keep — every document you can reach, in one list
- Document intake reads the content, and refuses what it cannot identify
- Document stats
- A document is worked in stages, and the compartment owns the work
- The model reads the whole thought, and the citation still names the chunk
- First run of a fresh vault
- The vault follows a reference the question never named
- Encrypted front door
- Help at hand
- Documents that give the vault orders
- Sign-in code mail through the customer's relay
- The vault's tool surface for agents
- The vault ships its own operations runbook
- Outbound mail log
- What a person may reach, and who may change it
- Vault portal
- Portal navigation menu
- Query page — retrieval and synthesis in two explicit stages
- Search tells the truth about its results
- Signing in to the vault
- Operating the vault stack
- Surfaces shaped by what an account can reach
- Uploading documents and browsing the ones you can reach
- The vault documents its own tested behavior
- What the vault can read, said where the question gets asked
- The vault says which version you are reading and which pass wrote its summary
- A profile that is yours and nobody else's