SkyKeep admin console
Per-vault administration — compartments, users and grants, quarantine review, and the vault's configurable settings. Every act here is verified by the vault's data access layer and audited; this page holds no authority of its own.
Sign in?
Settings?
The vault refused this panel.Changing the vault's settings is an administrator's job, and this account is not an administrator.
Every console-configurable setting, its effective value, and where that value comes from. A console value overrides the environment; clearing it reverts to the environment baseline.
Some of the vault’s settings are not here and cannot be: the malware scanner — its engine, signatures, external command and timeout — is set in the env file this deployment was started with, never in this console. Each of those is a lever that can leave the ingest scan gate detecting nothing, and the vault’s refusal to start on a scanner that scans nothing reads that env file rather than the database, so a value stored here would be a downgrade no guard could see. It ships empty, and empty means every upload quarantines until a deployment names an engine — the gate working, not the gate broken.?
| Setting | Effective value | Source | About |
|---|
Settings → Models?
The vault refused this panel.Choosing which AI models the vault uses is an administrator's job, and this account is not an administrator.
This deployment runs the models its own runtime has — nothing else can be selected, because a model that is not pulled cannot answer. Ingestion and answering are separate choices: one runs at upload with nobody waiting, the other runs while somebody watches a spinner.
The two roles?
What this deployment has?
Every claim below is labelled curated (characterised by this project), derived (arithmetic from what your runtime reported — nothing else is claimed) or measured (observed here, which beats both).
| Model | Size | Time to answer | Good at | Poor at / watch for | Suits |
|---|
What a model choice makes load-bearing?
Choosing a model changes what other settings must be true. This table is generated from the checks the vault actually performs against your configuration — it is not a general guide.
| If you change… | …this becomes load-bearing | Right now | What goes wrong if ignored |
|---|
Re-embed the corpus?
After changing the embedding model, the documents already in this vault still carry vectors from the old one — and a vector is only ever ranked against its own space, so until they are moved they cannot be found by meaning. This re-chunks and re-embeds them from the vault’s own stored Markdown: no document is read again, no scan gate runs (there are no new bytes and no new text for one to look at), no summary is rewritten, and nothing is deleted. It costs embeddings and nothing else.
It runs in batches so the page answers promptly. Press it again to continue — the vault works out what is left each time, so stopping and resuming is safe and nothing is done twice. A document this vault stored without converting has no Markdown to re-embed; it is reported by name and left exactly as it is.
Compartments?
The vault refused this panel.Listing compartments is an administrator's job. A delegated compartment administrator can organise compartments; this account is neither.
| Id | Name | Retention class | Oldest becomes due | Act |
|---|
Users & grants?
The vault refused this panel.Listing people and their access is an administrator's job, and this account is not an administrator.
The allowed-domain review loads with the account list.
| Allowed domain | Grants |
|---|
Directory review?
The vault refused this panel.Deciding which directory identities become accounts is an administrator's job, and this account is not an administrator.
Identities the directory reports that this vault has not decided about. Confirming one invites it exactly as the invitation page would; refusing one keeps it off this list for good. A vault with no directory configured says so rather than showing an empty table, because those are different facts.
| Username | Display name | Directory name | First seen | Decision |
|---|
Changes to accounts?
The vault refused this panel.Reading who changed which account is an administrator's job, and this account is not an administrator.
Account creations, disables and enables, invitations, and directory decisions — newest first, read from the audit trail itself, so this panel cannot disagree with what happened. Compartment grants are not here: they have their own history, under Permissions.
| When | Who | What | Outcome | Detail |
|---|
Sign-in attempts?
The vault refused this panel.Sign-in activity across every account is an administrator's view, and this account is not an administrator.
The last day of sign-in activity, by hour, and the newest attempts one at a time — for answering “I cannot get in”. Read from the audit trail and from the refusal counters themselves, so this panel cannot disagree with what happened.
What it does not show, because the vault never records it: the identifier somebody typed at a failed sign-in, and the address they came from. A refusal names which account it was attributed to — or no account at all, when the identifier matched nobody — and which throttle closed; never the string that was guessed.
admitted refused (recorded one by one) counted only (throttled, or an unknown token)
| Hour (UTC) | Admitted | Refused | Counted only | Total | Shape |
|---|
| When | Account | Step | Result | Why |
|---|
Refused attempts over time?
The vault refused this panel.Refused sign-in volume across every account is an administrator's view, and this account is not an administrator.
How much refused sign-in traffic this vault has been taking, a day or a week at a time. Read from the refusal counters themselves — the same rows the panel above buckets by hour, over a longer window.
A bucket here is a fixed length of time measured in UTC, and not a named calendar week: each row states the instant it starts and the instant it ends. A span with no refused traffic is shown as a zero rather than left out, so a quiet week looks quiet instead of vanishing from the line. Counters older than the vault keeps are gone rather than zero — a long run of zeros at the left-hand end may be retirement rather than quiet.
refused attempts, counted only. Every one of these is a refusal somebody who has not signed in can produce at will, so the vault counts them instead of writing one line each; there is no per-attempt list of them to show.
Quarantine review?
The vault refused this panel.Reviewing quarantined uploads is an administrator's job, and this account is not an administrator.
Blocked uploads held for review. A hold that is a judgement can be released with the concept type named — an ambiguous classification, or an item the ingest auditor flagged. A hold that is a detection can only be rejected — a scan-gate detection, or a file the vault could not read.
| Quarantined | Uploaded by | Filename | From archive | Violation | Status | Content | Cached block | Decided | Compartments | Item |
|---|
Nothing is being held. Every upload the vault has seen either became a document or was decided already.
Documents?
The vault refused this panel.Listing document versions needs reach into a compartment, and this account has none.
Versions you can see, and the two acts that cannot be undone from a document workspace. This list is bounded by your own compartment reach, so an administrator — who holds no compartment grants — sees nothing here and purges either by pasting the version id a request named or from What there is to purge below. Purging destroys a version permanently; reclassifying moves it to one compartment and takes it away from readers of the others.
| Version | Filename | Compartments | Conversion | Size | Act |
|---|
No version is visible to this account. Use Purge a version by id below for a version somebody has asked you to destroy, or What there is to purge to find everything an erasure demand covers.
Prove a disposal
For a version that has already been purged, the vault will issue a signed statement — which compartments lost it, who ordered it, and where that act sits in the audit chain — and, beside it, the chain entries that prove the statement. The statement says in its own signed words what it covers: this vault, as it is now. The rest of that scope, in the certificate's own words:
This statement does NOT certify any backup artifact, escrow copy or host-level snapshot. A restore replays the purge ledger and destroys that version again on the way in, and that replay is a separate act with its own audit entry. It also says nothing about copies made outside the vault by someone who could read the document while it existed.
The evidence file is a run of audit entries, not one line: a hash chain can only be checked as an unbroken sequence, so the entries either side of the purge travel with it. Those neighbours are other administrative acts in this vault. None of them carries document content, but they do name versions, principals and operations — read the file before you send it outside the engagement.
What there is to purge
For an administrator answering an erasure demand: the stored versions a purge could act on, narrowed by compartment, by who filed them, and by when the vault received them. No filenames and no document text appear here — an administrator reads none, and this listing does not become the one place it could. A version under a legal hold is shown as held: purging it will be refused until the hold is released.
| Version | Compartments | Filed by | Received | Size | State | Hold |
|---|
Purge all of it, as one batch
Prepare a batch from the filter above and the vault answers with a count and a phrase to type. Typing the phrase destroys those versions permanently. A version under a legal hold is skipped and named rather than destroyed; releasing the hold and preparing a new batch is the only way to reach it. A batch remembers the filter and counts you confirmed, so a run interrupted halfway can be resumed — and a version already destroyed cannot be destroyed twice, because the vault is asked again rather than a list being replayed.
Legal holds?
The vault refused this panel.The legal-hold register is an administrator's view, and this account is not an administrator.
A legal hold makes a document version un-purgeable. It has no expiry: a hold past its review date is still a hold and still refuses a purge, and no setting, timer or schedule in this vault lifts one. The review date says when somebody should ask whether the obligation still stands — because a hold nobody revisits is how a vault quietly loses the ability to honour an erasure demand.
Holds needing review
Active holds whose review date has passed. Each is still preserving its version. Decide whether it should keep doing so.
| Version | Why it was placed | Placed | Review was due | Act |
|---|
No hold is past its review date.
The register
Every hold this vault has ever placed, active ones first, and the release of each one that has been lifted. Rows are never deleted: the record that a preservation obligation existed and ended is what a register is for.
| Version | Why it was placed | Placed | Review by | State | Act |
|---|
No hold has been placed in this vault.
Retention?
The vault refused this panel.Retention policy is an administrator's view, and this account is not an administrator.
A retention class is a named rule — how long to keep a document and what to do when that time is up — and a compartment opts into one. A compartment with no class retains for ever. A class whose action is review only reports what has come due; only dispose destroys anything, and it is never the default. A document the vault could not date is never due, whatever the period, because a date nobody read would dispose of the wrong record with a certificate saying it was right. A legal hold beats all of it.
Classes
| Name | Keeps for | Counted from | When the period runs out | Grace | Compartments |
|---|
No retention class exists in this vault, so nothing is on a clock and everything is kept.
Saving a name that already exists edits that class, and every compartment on it changes with it. That is refused while a legal hold stands over anything the class covers.
One compartment's rule
Choose a compartment on the Compartments panel above — each row carries its class, the date its oldest live document becomes due, and the button that brings it here.
No compartment chosen yet — press Set retention… on a row of the Compartments panel.
An override gives one kind of document inside this compartment its own class. Choosing no class drops the override and that kind goes back to the compartment's own rule. Clearing the compartment's class drops every override with it.
What the policy says about each document
Read on demand rather than drawn with the panel: it walks the whole corpus, oldest first, and an operator asks for it when they are reviewing rather than every time they open this page. Nothing here destroys anything — it is what the rules say, and the nightly run in review mode says the same thing into the audit trail.
| Version | What the policy says | Becomes due | Under which class | Compartments |
|---|
Nightly runs
What each night's pass found. A run in review mode destroys nothing. Named in the trail says whether the audit trail lists every version the run found due or only the first of them — the counts beside it are always exact.
| Started | Finished | Mode | Due | Held | Undated | Disposed | Named in the trail |
|---|
No nightly run has been recorded yet.
Requests to throw out a duplicate?
The vault refused this panel.Destroying a stored document is an administrator's act, and this account is not an administrator.
When somebody finds two documents that are nearly the same and asks for one copy to be thrown out, the vault records the request here and destroys nothing. Granting one is a permanent destruction — the same purge as the panel above, with the same consequences. Declining destroys nothing and sends your reason back to the person who asked. Both are audited.
| Copy to destroy | Copy kept | Asked by | Asked | State | Act |
|---|
Audit trail integrity?
The vault refused this panel.The audit trail's integrity check is an administrator's view, and this account is not an administrator.
Every delivered audit entry is hash-chained to the one before it, so a changed, deleted or reordered record stops re-computing. The vault re-walks that chain on a timer and reports what it found. “Not checked” is not the same as “intact”: if the check could not run, this panel says so rather than staying quiet.
| Finding | Detail |
|---|