Skip to content
SkyKeephelp

Using the portal

Uploading

One file or many. Choose them with the picker, or drag them onto the drop zone on the page — both go the same way, and the files you picked are listed back to you before you press Upload. Each file becomes its own document.

The compartment is a pulldown, not a box you type an id into. Its options are your own write compartments, so the page cannot offer you somewhere the upload would refuse; leaving it on All compartments you can write to files the document into every one of them. The vault bounds the upload by that same write set either way — the pulldown spares you a refusal, it does not create one.

If your account holds no compartment at all, the upload page says so in words instead of offering a form that could only fail.

Every upload passes two scan gates and a format parser; content the gates hold is quarantined, not stored: an administrator reviews it from the console. A quarantine answer is the vault being honest, not an error.

A .zip or .tgz becomes one document per file inside it, and it is handled differently from a single file on purpose. The vault screens the archive itself through both scan gates and opens it while you wait — an archive it will not accept is refused there and then — and then accepts it and files the documents inside one at a time in the background. The page keeps count while that happens and shows you a row per document when it finishes, so a fifty-file archive on a slow machine reports progress instead of appearing to hang. Reading fifty documents can take a long time; the upload no longer has to finish inside a single request for it to work.

If your account can open a compartment but cannot write to one, an archive is refused outright rather than accepted and then refused file by file — nothing is stored and the attempt is recorded.

A file too large to send in one go is sent in pieces, and you do not choose — the size does. Above a threshold the vault opens an upload, takes the file a piece at a time into encrypted storage of its own, and only then assembles it. Two things follow that are worth knowing. A dropped connection does not start over: the vault remembers how much arrived, tells your browser where it got to, and carries on from there. And nothing is scanned piece by piece — both scan gates run once, on the whole assembled file, because something hidden across the join between two pieces would be invisible to anything that looked at them one at a time. Where the compartment check happens moves too: you are told at the START whether you may file into the compartment you chose, rather than after a long upload. A partial upload you abandon is discarded on its own after a while, and it is encrypted the whole time it is waiting. One exception, said plainly because you would otherwise meet it as a refusal: an archive still has to arrive in one go. The vault opens a .zip while you wait so it can screen each file inside, and it cannot do that with a file that is still arriving — so an archive too large to send at once is refused at the start rather than accepted and then stored as one lump nobody can search inside.

Your file is kept twice. The vault stores the bytes exactly as you sent them AND a plain-text rendering it can search — same key, same compartments, and deleting the document deletes both. The file type is decided from the CONTENT, so a Word document saved as report.txt is read as a Word document. Which formats are converted, and what a partial conversion loses, is on What SkyKeep can read.

Documents also carry metadata inside them — an author, a last-modified-by name, a revision count — which the vault extracts and shows back to you when you upload, because indexing those silently would be a disclosure made on your behalf.

Before you belong to a compartment

A new account belongs to no compartment until an administrator assigns it one, and until then upload, query and stats each say so in words rather than offering a form whose only outcome could be a refusal. The wording names what your account has — that nobody has given it a compartment yet — and not what kind of account it is, because the first is the thing that can change. Ask an administrator to assign you one; the forms appear on their own when they do, with no further step from you.

An administrator and a clientadmin see a different sentence in the same place, and it is a permanent one: those two kinds hold no compartment by design. They hand out reach and hold none themselves, so there is nothing to wait for.

Documents being processed

A document is not in the vault the moment you upload it. It is worked through stages — the vault scans it, identifies what type it is, converts it to Markdown, writes a summary by reading it, indexes it, and then admits it. Until that last step it cannot be searched or listed, by you or by anyone else, and the Processing page is where you can see it waiting.

When you upload, you choose how much of that you want to watch. Best guess lets the vault run every stage on its own, which is what you want for fifty files that are all the same shape. Approve each stage stops the document after it has been converted and waits for you, which is what you want for the file you are not sure about. One approval buys exactly one stage.

The queue belongs to the compartment, not to whoever uploaded the file. If you can write to the compartment you can pick the work up — so an upload does not become stranded because the person who made it went on holiday. Documents in compartments you cannot reach are not hidden from this page; they are not on it.

You can select several documents and act on them together. Each one is decided on its own: if part of your selection is something you may not act on, that part is refused and the page tells you how many, rather than the whole action failing or the refusal passing unnoticed.

A document can also stop. A scan gate can catch it, a stage can fail, or a person can decide it is not going in. A stopped document says which of those happened. It is still stored, still encrypted and still yours to download — it is simply not in the searchable vault.

Looking at a picture

Where the vault holds a picture — a photograph, a scan, a page someone sent as an image — it shows it small beside its reading. Clicking that picture opens it on its own, as large as you want it. Zoom with the plus and minus buttons, the mouse wheel, or the + and - keys; 0 fits the whole picture back into the frame. Move a picture you have zoomed into by dragging it. Resize the frame itself by its bottom-right corner. Fit shrinks a large picture to the frame and never blows a small one up, and Actual size puts it back to the size it really is, which is the one that tells you how much detail the file holds.

Closing it — the button, or the Esc key — puts the picture away and returns you to whatever you were reading. The bytes are fetched fresh each time you open it, under your own authority at that moment, and are released when you close it. That is why a picture can open once and be refused later: if your reach over the document has changed in between, the viewer asks again and is told no, rather than showing you a copy it kept.

Some pictures are deliberately not drawn. The viewer shows the kinds of image a browser can draw as pixels — PNG, JPEG, GIF and the like. It will not draw a picture whose recorded type is one a browser would have to interpret rather than decode, which is what an SVG is: an SVG is a document, and a stored document is untrusted input. When that happens the viewer says so in words and draws nothing — the file is still stored, still encrypted and still yours to download.

Pictures inside a PDF get the same viewer. When you open a PDF in the processing pop-up, any pictures the vault found inside it are shown as a strip of thumbnails in page order under Pictures inside this document. Clicking one opens it in the same viewer, where it zooms and moves exactly as any other picture does. Each thumbnail is fetched under your own reach at the moment you open the document, so a picture inside a document you may not read is not offered and would not be served if it were asked for.

Two things that are not errors. A PDF with no strip either carries no pictures or was put into the vault before it began recording where they are — the vault does not know which, so it says neither rather than telling you wrongly that your document has none. And a document with a great many pictures shows the first few and says how many there are in total, because fetching hundreds of them at once would make the pop-up unusable.

Enhancing a picture

Two buttons sit under a picture you have open. Enhance asks this vault's vision engine to look at the picture again and write down what it sees — the words on a photographed page, the figures on a receipt, what a slide shows. Convert again re-reads a document the vault already holds and rebuilds its text, its summary and its place in the index from it.

Enhancing never replaces what you were looking at. The result is a new version of the same document, sitting after the one you started from and recording which version it was made out of. The picture you had keeps answering everyone who can already read it, for the whole time the new one is being built, and it goes on doing so afterwards. Nothing is overwritten and nothing is removed — if you do not like what the engine made of it, the version you had is exactly where it was.

The new version arrives at the converted stage and is finished by the vault in its own time, like every other document in the queue: its summary, its chunks and its index entries are minutes of work and are not done while you wait. Until they are done it is a version of your document that searching has not reached yet, which is different from a version that failed.

Where the picture goes. Most deployments run their vision engine on the same machine as the vault, and the picture never leaves it. Some are configured to reach an engine somewhere else — and when that is how this vault is set up, the viewer says so and asks you to confirm before it sends anything, every time. That is not a formality: the confirmation is about a document leaving this building. An administrator has to have permitted that destination before the button will do anything at all; the vault refuses an engine elsewhere that nobody authorised, rather than asking you to authorise it.

If this vault has no vision engine, the button says so and names the setting an administrator would have to fill in — SKYKEEP_VISION_MODEL, the vision engine this vault reads pictures with. It does not quietly do nothing.

What the result is worth. What the engine writes is a machine's reading of a picture, and the vault stores it as exactly that: it is shown as the document's text, never as instructions to follow, and the version records which model produced it and when. It can be wrong. If it is, the Save my summary box is how a person writes what the document actually says — that becomes another version, with their name on it instead of a model's.

Needs Help

Some documents go into the vault whole and safe, and the vault still cannot read most of the words in them. A photographed page, a scan with no text layer, a slide that is one large picture — the file is stored, encrypted and yours to download, and searching will not find what is inside it, because to the vault there is very little inside it to find.

The Needs Help page lists exactly those documents, for the compartments you can reach. Nothing on it is lost and nothing on it is an error you caused. It is the vault saying which documents it could not read, rather than letting you discover it later by searching for something that is on a page it never converted.

Two things help. Upload a readable copy of the same document — Markdown, plain text or a Word file — into the same compartment: the vault reads that copy, searching finds it, and the original stays exactly where it is. Or tell whoever administers this vault what is in it, if the document matters and no readable copy exists. A scanned page nobody can search is worth knowing about.

A document appears here on a measurement, not on a guess: the vault compares how much text it extracted against how much the file looked like it held. The page is a request for help, so it asks first and lists second.

Documents that look alike

The vault reads the text of everything it stores, and when a document turns out to read almost the same as one already held in a compartment you can reach, it writes down the pair and tells you. It does not act on it. Nothing is merged, moved, hidden or deleted — the Duplicates page is the vault reporting a resemblance and waiting for a person.

You can say one of four things about a pair. It is a dated version of the same document, or a numbered version of it; the two are the same apart from spacing; or one copy should be thrown out. A pair is decided once, and every answer is written to the audit trail with who gave it.

Throwing a copy out asks an administrator; it does not destroy anything by itself. Removing stored bytes from this vault is a purge, which is an administrator's act and all-or-nothing, so the page does not quietly do something weaker under a word that sounds final. When you choose it you say which of the two copies you mean, your answer is recorded, and the request goes to an administrator. Until they answer it, the pair says waiting for an administrator and both copies are exactly where they were.

An administrator either throws the copy out — permanently, with the key, the stored bytes and the search index entries all destroyed together — or declines and says why, and you read their reason on the pair. A copy under a legal hold cannot be thrown out at all until the hold is released, and the pair says so. Both answers are written to the audit trail.

Some pairs are not yours to decide, and the page says which. Seeing a pair needs you to be able to read both documents; answering about it needs you to be able to write to both. A document somebody shared into a compartment you can read is one you can be warned about and cannot make a decision for, so the row says so instead of offering you buttons that would be refused.

Two kinds of resemblance are reported and they are not the same claim. The same apart from spacing is exact: the words, the letters and the punctuation are identical, and only the line breaks and spaces differ. Nearly the same text is a measurement, shown with a difference score where a lower number means more alike. Where the vault can make the exact statement it makes that one and does not offer you a score instead.

An empty page is not a clean bill of health. It means the vault has no pair to show you, which can be because it found none, because look-alike detection is switched off in this deployment, or because the documents carry too little text to compare. Identical files are a different matter and never appear here: an upload of bytes the vault already holds in that compartment is refused at the door.

What a difference score is

The vault reduces the text of every document it stores to a fingerprint: a row of sixty-four marks, worked out from the words themselves, that changes a little when the text changes a little. The difference score beside a pair is simply how many of those sixty-four marks the two fingerprints disagree on. It is a count of disagreements, so lower means more alike and 0 means the two texts are the same once spacing is set aside. It is not a percentage, and it is not a judgement about whether the two documents matter to you.

Two worked examples, both short enough to picture. Take a site-visit note of about sixty words. Change one word in it — eleven record classes becomes twelve — and the two notes score 4 apart: almost every fingerprint mark still agrees, because almost every word still does. Now replace the note with an unrelated paragraph of the same length about an orchard in spring. Those two score 35 apart, which is most of the way to the sixty-four marks disagreeing altogether — the two texts have nothing in common but the language they are written in.

Somewhere between those two the vault draws a line, and the line is set for this deployment rather than fixed in the product. Pairs at or under it are reported to you as nearly the same text; pairs above it are never written down at all. The first example above is comfortably under the line and the second is far above it, which is why one of those pairs would reach your Duplicates page and the other would not. Documents of very different lengths are not paired however their fingerprints land, and a document with too little text to fingerprint at all is never paired with anything.

A score is a measurement, not a verdict. Two drafts of the same letter and two unrelated invoices from the same template can land at similar scores, because the vault is comparing words and not meaning. That is exactly why the page asks you what the pair is rather than deciding: the score is there to tell you how hard it had to look, and you are the one who knows what the documents are.

Your documents

The documents in the compartments you can reach, and what the vault knows about each one: its version number, the summary the vault wrote after reading it, the metadata found inside it, when it was uploaded and how big it is. This listing used to show only a title, a date and a size, on the principle that it should say what a document is and never what it says; that turned out to hide the one thing you need in order to trust an upload, which is whether the vault read the document at all. Nothing outside your reach appears — the list is bounded by the engine, not by the page, and what it still never shows is a passage of the document itself.

Two entries need reading carefully. A summary is written by reading the document, so if no model was available the row says there is no summary rather than showing you the opening line of the file dressed up as one. And a date the document claims about itself comes out of the file, whose contents the sender chose; the row always says whether it is showing you the document's own date or the moment the vault received it, and a claimed date that is in the future or absurdly old is refused outright. Anything the vault does not know — a size it never recorded, a type it could not identify — shows as unknown, because a made-up 0 would be a claim about the document and a false one.

Folders

A folder says where a document is filed. It does not say who can read it. That is the whole rule, and it is worth reading twice, because every other filing system most people have used works the other way round. Putting a document in a folder called private hides it from nobody. Moving it out of one reveals it to nobody. What decides who can reach a document is its compartment, chosen when it is uploaded and changed only by somebody with the authority to reclassify it.

You see a folder because you can see what is in it. The vault keeps no list of folder names. The tree is worked out from the documents you are already allowed to read, every time you look — so a folder holding nothing you can reach does not appear to you at all: not as an empty branch, not as a count, not as a name. Two teams who cannot see each other's documents can both file under contracts/2024 and neither ever learns the other is there.

A document with no folder is unfiled, which is not the same as being at the top. Nothing was filed before this existed, so nothing has a folder until somebody gives it one, and those documents read as unfiled rather than being swept into a root nobody chose. An empty tree means nobody has filed anything yet — it is not the vault telling you it holds no folders.

Where folders come from. You can type or pick one when you upload. If you upload a zip, the folders inside it are kept — a file at reports/2024/q3.docx in the archive is filed under reports/2024, and if you also named a folder for the upload, the archive's own structure is kept underneath it. A path that tries to climb out (..), starts at a root (/…), or carries characters a path cannot hold is refused, and nothing is stored — the vault does not quietly correct it into a different folder from the one you asked for.

The same file in two folders is one document with two names. The vault refuses to store the same bytes twice in one compartment. If you upload a file it already holds there and name a folder it is not yet filed under, it does not refuse: the existing document is filed under that folder as well, and the upload answers filed rather than stored. There is still one document, one stored copy and one compartment set — so purging it removes it from every folder it was filed in, and Doc Keep says also filed in beside a document that has more than one name. Uploading it again into a folder it is already in is refused as the duplicate it is.

Purging a document takes its folder with it. A folder name is something the person who filed it wrote — often a client, a matter or a date — so it is destroyed with everything else the document said. A branch of the tree disappears when the last document you can see in it does, because there was never a stored folder to leave behind.

Tree

Tree is the same documents Doc Keep lists, arranged instead by the folder each is filed in, with your compartments as the top level and folders nested underneath them the way you typed or uploaded them. It reads the same listing Doc Keep does, so a document you cannot reach never appears here either — not as an empty branch, not as a count, not as a name.

A folder here is exactly what the Folders section above says it is: filing, not permission. Seeing a document arranged under a branch changes nothing about who may read it — the compartment still decides that, and every route still re-checks it, whichever view you found the document through.

Doc Keep

Doc Keep is one long list of every document you can reach, with a column for each thing the vault knows about it: the filename, two dates, the size, the type it was identified as, the compartments it is filed in, the summary the vault wrote and the keywords it drew from that summary. It is built from the same listing the rest of the portal reads, so it is bounded the same way — by the engine, not by the page. A document in a compartment you cannot reach is not hidden on this view; it is not on it, and no column, sort or setting widens that.

The two date columns are not the same kind of thing. Ingested is when this vault received the file — the vault wrote that down itself, and nobody outside can move it. File date is the oldest date the document claims about itself, read out of the file's own metadata, and the person who sent you the file chose what that metadata says. Where a file claims no date of its own — or claims one the vault refused as implausible, such as a date in the future — the File date column shows the ingestion date and says on that row that it is the ingestion date. A blank cell would tell you nothing, and a borrowed date that does not admit it is borrowed would tell you something false; saying which of the two you are looking at is the only version that leaves either column worth trusting.

Sorting, filtering and paging are presentation, and nothing more. A list this long is only usable if you can order it, narrow it and read it a page at a time, so the headers sort, each column has a box that keeps only the rows containing what you type, and you choose how many rows to show at once. None of that changes what you are permitted to see. Everything a filter can bring into view was already in the list before you typed, and emptying the box puts the rest back — so a short list is never evidence that something is out of reach, and a filter is never a permission boundary. What you may see was decided before the page drew its first row.

A filter box can compare as well as contain. Start what you type with one of >, <, >=, <=, = or != and the column is compared against what follows instead of searched for it — against the date on the two date columns (> 1993-10 keeps files dated after October 1993; = 2001-06 keeps June 2001), against the number of bytes on Size, and alphabetically elsewhere. An operator with nothing after it yet leaves the table alone.

Comparing a document with its previous version. Open a document and choose Compare with previous version: the vault reads both versions under your own permissions and shows what changed, a few lines of unchanged text either side of each change so you can see where it is. Lines that were removed are marked with a leading - and lines that were added with a +. Both versions must be ones you may read and must belong to the same document; anything else is refused, and the refusal says the same thing whatever the reason, so that asking cannot tell you what exists. Where the document has no earlier version you can reach, the panel says so rather than showing you an empty comparison, and two versions too large to compare are refused outright — a partial comparison would claim two versions agree in a place the vault never looked. Nothing is stored: the text is unlocked to answer your question and nothing is written down.

The keyword mind map above the table shows the commonest keywords across the documents you can reach. Choose how many to show (50, 100, 200 or all), switch between usage-frequency and alphabetical order, and read the Color Key: under the title — it names the real counts each colour stands for, cut on the commonest word's own number. The three colours are chosen to stay apart for red-green colour vision, and each band has its own border (heavy, plain, dashed, dotted) so the map reads without colour at all; the key itself is a legend, not a set of buttons. Clicking a word narrows the table to documents carrying every selected word; Reset clears the selection. The query page's map looks the same and does a different thing: there a click adds the word to your question.

Searching

Search only ever ranks documents your grants admit — there is no setting that widens this. If fewer results exist than you asked for, the page says so (under-return) rather than padding the list. Superseded document versions are excluded by default; tick all versions to see history.

Narrowing a search. Under Narrow this search on the Query page you can limit an answer to a date range, to particular compartments, or to one kind of document. Every one of these only ever narrows what you could already find — none of them widens your reach, and a compartment you do not belong to matches nothing rather than telling you it exists. The dates are the document's OWN date, the one it claims about itself, and not the day the vault received it; a document that claims no date of its own falls in no date range. Leave a box empty to place no limit on it.

Think

Think answers questions using ONLY passages the vault admitted to you, and cites them. When your corpus does not cover the question, it says exactly that instead of guessing — see the vault admits what it does not know.

Asking does not hold the connection open. Pressing Ask submits the question and the page then collects the answer — briskly at first, then less often, and after two minutes it stops asking and offers you a Check again button rather than pinging the vault forever behind a tab nobody is looking at. This is not cosmetic. A question costs two model calls, one to understand it (SKYKEEP_MODEL_EMBED_TIMEOUT, 120 seconds as shipped) and one to answer it (SKYKEEP_MODEL_GENERATE_TIMEOUT, 300 seconds), and the front door gives up on any single request at SKYKEEP_TLS_PROXY_TIMEOUT (330 seconds). While both calls happened inside one request, 120 + 300 could exceed 330 — and when the front door gives up first, the vault never learns you left: it finishes the work and records the question as answered, so the trail says success for something you watched fail. Submitting and collecting removes that possibility rather than tuning around it. If an answer is taking a long time on your deployment the number to look at is the generation ceiling and the model behind it, not the front door.

What the model reads, and what the citation names

A document is cut into chunks so that it can be indexed, and how long a chunk may be is decided by the embedding model's input limit — not by how much of a document an answer needs. Those are different numbers, and left alone the second one loses: a section longer than one chunk gets cut mid-thought, and nothing in the answer would tell you it had been.

So when a passage wins the ranking, the model is given the whole section that passage came from, rather than the fragment alone. Nothing is re-indexed and nothing is re-stored — the vault reads more of a document it had already unlocked for you, which is why this applies to documents that were already in the vault and not only to new ones. A widened passage is held inside the document version it came from, so it can never run on into another document.

The citation still names the passage that matched. Widening changes what the model reads; it does not change what the vault claims to have read on your behalf, and those are deliberately allowed to differ rather than being quietly collapsed into one. Both the query page and Think work this way. An administrator sets how far a passage may widen, and zero means no widening at all.

A citation names the document, not just a number. Beside the version it came from, a citation gives the name the file was stored under, the heading it sits under, and the date the document claims for itself — with a note of which part of the document that date came from, because a date a document asserts about itself is not the same thing as the date this vault received it.

If a document is converted again, its old citations say so. Converting a stored file a second time — as a different type, or with a different setting — produces different text, so a reference into the old text no longer points at the same words. The vault will not quietly hand you whatever is at that position now. The citation is marked stale, it still tells you which document and which version it came from, and the passage is not shown. Search again and you will get citations into the new text.

Following a reference your question never named

Some questions cannot be answered by one search, and it is not a matter of searching harder. Suppose an essay argues something and carries a reference code, and a separate register records who received that code. Ask who took custody of the paper arguing this? and the only thing joining the two documents is the code — which appears in neither your question nor your vocabulary. One search finds the essay and stops, at any size, with any ranking. The key is in the first result, not in the question. So when a first search turns up a reference code your question did not contain, the vault searches again for that code, and the answer is built from both halves — see the vault follows a reference the question never named.

What it will not follow, and why that is deliberate. Only things shaped like a reference code, and every pattern requires a digit — that is what separates a code from an ordinary capitalised phrase, and without it any document could earn itself a free search by containing two capitalised words. People's names are deliberately not followed. A name has no shape that distinguishes it from any other pair of capitalised words, so following names would mean following noise, and every false lead costs a passage slot that a real answer wanted. The practical consequence is worth stating plainly rather than leaving you to discover it: a chain that runs essay to code to custody row to the custodian's name to their contact details will get you to the custody row and stop there.

It can never widen what you may read. The second search is issued as you, so it resolves exactly the same permissions as the first. A document that plants a reference code hoping to be followed buys itself a search over documents you could already read — one you could have run by hand.

It happens on Think, and not on the query page. Think and the vault's tool interface take the second step. The query page does not, and the reason is a property worth more than the convenience: there, the model is shown exactly the passages you retrieved and can see for yourself — the page sends references and the vault re-resolves each one under your own permissions — so nothing reaches the model that you were not shown first. A second search made on the server would add passages you never saw. The honest consequence: the same two-part question gets one search on the query page and two through Think. That is a real difference between two surfaces of the same vault, and it is written down here rather than left to be discovered.

A question with nothing to follow costs nothing extra — no second search, no second wait. An administrator can also turn the second search off entirely, and off means off rather than quietly reduced.

What a query tells you before it answers

The query page can work either way, and a checkbox decides which. Left on, one box does everything: it retrieves the chunks your compartments admit and asks the model to answer over exactly those. Turned off, the retrieval runs on its own and a second box appears underneath, so you can read what was found before deciding what to ask of it. The model sees the same thing either way — the page sends references, and the vault re-resolves each one under your own permissions before anything reaches the model. That property is also the reason this page answers from one search where Think can take a second: see Following a reference your question never named.

Either way you get two counts, broken down by compartment, and they mean different things. Retrieved is what the answer is built from. A single document may contribute several passages when it answers a question in several places, so its chunk column can be larger than its document column; how many is a setting an administrator controls, and the query page states the number that was in force for the retrieval you are looking at. Text matches is a separate, complete count of the chunks that contain all the words you typed — no limit is applied, so it is a total rather than a floor, and it is the number that answers is there more in here about this? It counts words only, so retrieval can surface a document this count does not include: ranking also weighs meaning, and a total based on meaning would need a cutoff the vault cannot pick honestly on your behalf.

Neither count can mention a compartment you do not belong to. The grouping runs through the same engine-level rule that decides what you may read at all.

The menu

The icons down the left side switch between the vault's surfaces. Upload, stats and query are there for everyone signed in; your profile is not in this rail, because it is not one of the vault's surfaces — it is your account, and it lives behind your name in the header. Invite, emails, users, permissions and compartments all appear for an administrator or a clientadmin — and the vault decides that per request, on the server: a page that showed them to the wrong person would still reach nothing, because every administrative route re-checks authority itself.

The admin console is linked from the header. An administrator and a clientadmin get an admin console link beside help at the top of every portal page; nobody else sees it, because nobody else is admitted to it. Everything a clientadmin needs day to day is on the portal's own permissions and compartments pages — Permissions for who reaches what, Compartments for the structure itself; see Compartments and delegated administration; the console is where an administrator manages settings, accounts and the quarantine queue.

Document stats

How many documents the vault holds, by compartment. The surface is metadata only — names, compartment names, counts — and never document content. What you see is bounded by your own reach: compartments you cannot read are not listed, not greyed out, and asking after one by number gets the same answer as asking after one that does not exist. Individual documents are listed on the Documents workspace and, while they are arriving (and afterwards, with include finished ticked), on the processing page — the stats page no longer duplicates that list.

The page opens on a table of the compartments you can see — name, a View Documents button, and the total — and each row offers Over time: how many distinct documents that compartment held at the end of each day, from its first document to today, with today counted live. It is served to anyone who can see the compartment and refused, identically, for a compartment you cannot see or one that does not exist.

If you reach no compartment, stats say so rather than answering nothing. A count of 0 would not be a small answer, it would be a false one: it reads as a fact about the vault when it is a fact about your account. So the page puts the reason where the buttons would be, and the stats API refuses the same request for the same reason and records the attempt.

An administrator is the exception, and only here. An administrator holds no compartment grant by design and still sees whole-vault counts, because stats are served to it by a different, admin-re-checking path. That is a reporting surface over metadata, not reach: it does not let an administrator read any document, on this page or anywhere else. A clientadmin gets no such exception — it reaches nothing and is told so.

Approving an agent that asked to act for you

Some work is done by an agent rather than by a person at a keyboard — something running on a server, or in a terminal, with no screen of its own to sign in on. An agent like that cannot borrow your password, and it is never given one. What it can do is ask: it requests a pairing, the vault gives it a short code, and it shows you that code. You type the code on the Approve agent page and press Approve. That is the whole handshake, and your own signed-in session is what makes it count — there is no field anywhere in which an agent can simply name you.

Approving widens nothing. The agent gets the overlap between what you can reach and what it can reach, and nothing outside it. A compartment you cannot read stays unreadable through the agent; a compartment the agent was never granted stays out of reach even though you can read it yourself. The overlap is worked out again every single time the agent uses the approval, against the vault as it stands at that moment — so a compartment taken away from either of you takes effect immediately, and an agent whose credential an administrator switches off stops working at once.

It is short-lived, single-use, and cannot be renewed. A code may be approved once: the agent collects the approval one time, and a second attempt to collect it is refused exactly as a made-up code would be. The permission itself lasts minutes, not hours, and there is no way to extend it — an agent that needs to keep working comes back and asks again, which is what makes switching it off meaningful.

Only ever type a code an agent has just shown you. The code is the whole of the approval, so a code that reaches you any other way — in a message, in an email, read out over the phone — is somebody asking you to hand them your own reach. Do not type it. If a code does not work, ask the agent to show you a fresh one; the page will not tell you why a code was refused, on purpose, because an answer that distinguished 'wrong' from 'expired' would help somebody guessing far more than it helps you.

Administrators cannot approve agents, and the page is not offered to them. An administrator or a delegated administrator reaches no document, so there would be nothing for an agent to inherit — but that is not the reason. Those accounts run the vault, and an agent holding a permission with an administrator's name on it is a thing the product declines to create. The refusal is made by the vault, not by the page: an administrator who reached this screen anyway would still be turned down, and the attempt would be on the audit trail.

Every approval and every refusal is recorded — who approved, which agent, and when — and when the agent later does something in your name, the record of that work names both of you.

Inviting people (administrators and clientadmins)

Paste email addresses separated by commas, spaces, or semicolons — mixed is fine, and the vault reads the list, not the page. Up to 100 per submission; 101 is refused whole, with the count said out loud and nobody invited. Each person is mailed a temporary password the administrator never sees, and must choose their own at first sign-in before the vault will do anything else for them. An address that cannot be read is refused on its own line while its neighbours still go.

Ticking Invite as clientadmin before you submit invites delegated administrators instead of ordinary people — everything else about the invitation is identical. The box defaults to off, so nobody becomes one by accident; see Compartments and delegated administration for what the account can do, and Provisioning a clientadmin for the operator's version.

A clientadmin may invite people here too, including another clientadmin — it is in charge of all users on the system, and any number of clientadmins may exist so the job can have a backup. The one kind nobody but an administrator can create is admin; a clientadmin asking for it is refused by the vault's engine, not merely by this page.

Emails sent (administrators and clientadmins)

Every mail the vault has sent, with its delivery status. Sent means the relay accepted the message — the vault does not claim delivery it cannot confirm. Bounced means the recipient was refused; failed means the mail never left. The record is metadata only: recipient, kind, time, status — never a subject, a body, or a code. Invitations that did not reach the relay can be resent, at a corrected address if the original was a typo, which updates that person's address on file. The re-invitation is audited against that account; the address itself is deliberately not recorded, because account creation omits addresses from the trail too and the resend keeps that pattern. An invitation the relay accepted is not resendable from the page: a resend issues a fresh temporary password, so resending a delivered invitation would lock out the person still holding the first one. Re-inviting a delivered address stays possible, but only as a deliberate per-message act, and the trail records that it was one. Sign-in codes cannot be resent: they are single-use, and the person signs in again to get a new one.

Your profile

Everything on the profile page is about your own account and nothing else. There is no route that takes somebody else's account, because there is nothing it could return: the engine limits a session to its own row, so a page that asked after another person would get nothing rather than a refusal somebody had to remember to make. Reach it by clicking your own name at the top right of any page — the same place the log out button sits.

It shows your sign-in name and the compartments you belong to (read-only — membership is granted by an administrator or a clientadmin), and it lets you edit your bio, change where your sign-in codes go, and change your password. The email password change also asks you to type the new password twice, so a typo cannot become a password nobody knows. The email and password changes both re-require your current password: a session that could redirect your sign-in codes could hand over the account. The password change is the same rotation path the vault uses everywhere else — no second way to change a password exists.

If you have forgotten your password there is no self-service reset, because a reset link mailed to an address is a second way into the account and the vault does not keep one. Recovery goes through an administrator: they re-invite you from the emails-sent page, which issues a fresh temporary password to your address on file, and you replace it at your next sign-in. If your original invitation was delivered rather than bounced, the administrator has to choose that deliberately per invitation — a delivered invitation is not resendable in bulk, because the resend retires the password you were already given — and the trail records that somebody chose it.

Your profile picture

Drop a picture on the box or choose one with the picker; both reach the one handler that validates it. The format is decided by the file's own bytes — never by its name and never by the type your browser claims for it — and the picture is served back only to you. SVG is refused by name: it is the one image format that is also a script host. A file that is too large, or whose bytes are not an image the vault accepts, is refused with the honest reason rather than a generic failure.

Compartments (administrators)

Compartments appears in the left menu for an administrator and for a clientadmin. It is where compartments are created, renamed and merged; giving a person access to one happens on the Permissions view (the 🔑 entry), one surface for every grant. See Compartments and delegated administration, which also explains why the account holding those powers can read no document and what a merge widens.

Signing in

Sign in with your account name and your password. If this vault asks for one, a one-time code is emailed to you and a second box appears for it. That code is single-use and is never resent — signing in again is what gets you a new one.

Your very first sign-in always asks for a code, whatever the account's own preference says: that first code is how the vault learns the account reached the right person. It then asks you to replace the temporary password you were mailed before it will do anything else for you, and asks for an address to send codes to if it does not have one yet.

A refused sign-in says bad username or password and stops there. It does not say which half was wrong, because naming the half would tell a stranger which accounts exist — and the same sentence answers a name nobody holds, a wrong password, an account that has been disabled, one that is locked out, and one with no address on file. It no longer offers you a code box on the way: if you are asked for a code, a code really was sent. The attempt is recorded either way.

Every sign-in takes about three seconds, whether it works or not. That pause is deliberate: it is what stops somebody trying passwords in bulk, and making a refusal take exactly as long as a success is what stops the clock itself becoming an answer. Nothing is wrong; wait for it.

The user list (administrators)

Users in the left menu lists every account the vault holds — its kind, its sign-in name, the address its codes go to, whether that address falls inside the allowed-domain list, whether the account is disabled, and the compartments it can reach. Click a column heading to sort by it; click it again to reverse.

The Allowed domain column answers one question: which existing accounts fall outside the list of e-mail domains this vault admits. The vault decides it, once for the whole listing, and the column reports what the vault said — the page never works it out from the address itself. It ignores the toggle on purpose: seeing who would be affected before the restriction is enforced is the only order in which turning it on over a live vault is safe. An account with no address on file counts as outside and says so, because an account the vault cannot check is one an administrator must look at. The sentence under the table says whether a list is configured at all and whether it is being enforced today; with no list configured every account counts as outside, which is true and tells you nothing except that the list is unset. The allowed-domain list, its on/off toggle and its individual exceptions are set in the admin console's Settings.

If the vault cannot read its own domain policy — its database is not answering — this list is refused rather than shown. It would otherwise have to judge every account against a policy nobody read, and report one confident verdict for all of them. Try again once the vault's database is back.

It is read-only. Accounts are created and disabled in the admin console, while a person's access to a compartment is a level set on the Permissions view (ADR-0045). This list is served by the same admin-checked route — so it shows nothing an administrator could not already ask for, and it shows no document belonging to any of those accounts.

Accounts and grants (administrators)

The admin console's Users & grants panel is where an account is created. Creating one takes a sign-in name, an initial password the person must replace at first sign-in, an address for their sign-in codes, and a kind: human for somebody who works in the vault, admin for an administrator, or clientadmin for a delegated compartment administrator (see Compartments and delegated administration).

A grant sets a person's access to one compartment to a level: none, read, or write. Read is the floor of the two that grant anything — a write grant carries a read grant with it, so nobody can hold write without read (ADR-0045). Taking read away therefore takes write with it and leaves none; it removes more than it names rather than less. The reverse is not true: write authority is never inferred from read. The vault refuses a grant to an administrator or a clientadmin engine-side, on every call — those two kinds hand out reach and hold none themselves.

Disabling an account stops it signing in and ends the sessions it already has, within the deployment's configured disable-to-termination window; enabling it again restores nothing but the ability to sign in. Every act in this panel is verified by the vault's data access layer and audited — the console holds no authority of its own.

Directory review (administrators)

If this vault is configured to read a directory — an LDAP or Active Directory server — the admin console's Directory review panel lists the people that directory reports who do not yet have an account here. Nobody is admitted automatically. The vault reads the directory; a person decides.

The list is built when you ask for it, with Check the directory now. Nothing is pushed to the vault and nothing is polled in the background, so the list is as fresh as your last check. A vault with no directory configured says so rather than showing an empty table — nobody new and the vault could not ask are different answers and you are told which one you have.

Confirming somebody invites them exactly as the invitation page would: an account is created and a temporary password is sent to their address, which they must replace at first sign-in. If your deployment has no mail relay configured, confirming is refused and says so — an account nobody can be told about is worse than no account. Refusing somebody creates nothing and is remembered: they will not appear on this list again, so a decision you have already made is not put back in front of you at every check.

Every name, address and directory label on this panel is text chosen in the directory, not by this vault, and is shown to you as text and never treated as instructions. Confirming and refusing are both recorded in the audit trail, and you can read those records on the Changes to accounts panel below.

Who may do what here is deliberately not one permission. Seeing the list, checking the directory and refusing somebody are open to a delegated compartment administrator. Confirming is restricted to an administrator, because confirming creates an account, and creating accounts is an administrator's job everywhere else in this product too.

Changes to accounts (administrators)

The Changes to accounts panel answers one question: who changed the vault's list of people, and when. Account creations, accounts disabled and enabled again, invitations reissued, and decisions about people a directory reported — newest first.

It is read from the audit trail itself rather than kept as a second list, so it cannot disagree with what actually happened. Compartment grants are not shown here: those change what somebody may reach rather than who is on the list, and they have their own history on the Permissions view.

Names are shown as they are now. The trail records people by identifier and the vault keeps no history of renamings, so a line describes a past act using today's name for whoever performed it.

This panel is narrower than the audit view on purpose. That view shows every access to every document across every compartment and is an administrator's alone; this one shows changes to the list of people, which is what a delegated compartment administrator needs in order to administer it.

Sign-in activity (administrators)

The Sign-in attempts panel exists to answer one support question — I cannot get in — without anybody having to read the raw trail. It shows the last twenty-four hours of sign-in activity an hour at a time, and beneath that the newest recorded attempts one at a time. Hours with no traffic are shown as zero rather than left out, so an outage looks like an outage instead of a straight line.

Three counts per hour, and they are never added together into one number. Admitted and refused are recorded acts: each one is an entry in the audit trail, written at the moment it happened. Counted only is a different kind of fact — it is volume, not records. Two refusals can be produced at will by somebody who has not signed in: an attempt against an account that is already locked out, and an attempt carrying a session token this vault never issued. The vault deliberately stopped writing an entry for each of those, so that a flood of them could not bury everything else in the trail, and counts them per hour instead. There is no per-attempt record of them to show, which is why they never appear in the list below. The total column adds the three, and the shape bar is drawn to that height, so that an hour can be compared with the hour beside it; read that as traffic, and never read the three as one quantity.

The split is the point rather than a shortcoming. No failed sign-ins this hour would be a dangerous thing to believe while thousands of throttled attempts were arriving, so the quiet recorded series and the loud counted series are always shown side by side.

No typed identifier and no source address, ever — because neither is recorded. Nothing is being withheld from you here, and no setting turns it on. When a sign-in fails the vault writes down which account the attempt was attributed to and which check refused it; it does not write down the text somebody typed into the username box, nor the address they came from. Putting a stranger's chosen text into the trail, on a path that stranger can drive as often as they like, is exactly what that rule prevents. So a refusal that matched a real account names that account, a refusal that matched nobody reads no account identified, and the guess itself was never captured by anything.

Two warnings can replace the line above the graph, and neither means the panel failed. Normally that line names the window it read and when it read it. Instead you may see:

Treat the whole panel as a floor rather than a count. Even with no warning showing, it can only be a lower bound: counting a refusal is bookkeeping, and the refusal itself always takes priority, so a counter the vault could not write is dropped rather than allowed to interfere with turning the attempt away. Use the panel to see shape and direction — when the attempts started, whether they are one account or many, whether somebody is being locked out rather than getting the password wrong. It is not an accounting record, and a small difference from another count is not a discrepancy to chase.

Diagnosing one person's trouble usually takes the list rather than the graph: the step column says how far the attempt got, and the why column says what stopped it there — a wrong password, an account that has been disabled, a lockout still in force, or a one-time code that never completed. The audit view holds the same events in their full context, and this panel is only the shortcut to them.

Refused attempts over time (administrators)

The Refused attempts over time panel answers a different question from the one above it. That panel is for what happened to this person yesterday; this one is for how much refused traffic is this vault taking, and is it getting worse. Pick by day or by week and the graph is drawn for that span.

It counts only the refusals that are counted rather than recorded. Those are the two an outsider can produce as often as they like: an attempt against an account that is already locked out, and an attempt carrying a session token this vault never issued. The vault deliberately does not write a line for each of them — a flood of them would otherwise bury everything else — so a count per span is the whole of what exists. There is no per-attempt list behind this graph, and nothing is being held back from you.

A bucket is a fixed length of time, not a named calendar week. Each row states the instant it begins and the instant it ends, both in UTC, and a week here is simply seven days measured from a fixed origin. This is deliberate: a calendar week needs a country to say which day it starts on and a timezone to say when, and two people reading the same vault from different places would then be shown different graphs of the same events. Read the from and to columns rather than assuming a Monday.

A span with no refusals is a zero, and a zero is not always quiet. Empty spans are drawn rather than left out, so an untroubled week looks like an untroubled week instead of disappearing and joining the weeks either side of it into one straight line. But counters are kept for a limited time and then retired, so a long run of zeros at the left-hand end of a long window may mean no longer kept rather than nothing happened. The span the graph actually drew is stated above it.

Read it as a floor, for the same reason as the panel above. Counting a refusal is bookkeeping and the refusal itself always comes first, so a count the vault could not write is dropped rather than allowed to delay turning an attempt away. The shape and the direction are what this graph is for; it is not an accounting record.

Audit trail integrity (administrators)

Every delivered audit entry is hash-chained to the one before it, so a changed, deleted or reordered record stops the chain re-computing. The vault walks the whole chain on a schedule (SKYKEEP_CHAIN_VERIFY_INTERVAL, fifteen minutes by default) as its least-privileged reader and reports what it found here and on the queue-health badge.

Three answers are possible and they are not the same: verified — the walk finished and every link held; broken — a link did not, and the finding names the sequence number, with an audit row written for the failure; and unverified — the vault could not check, because the trail is over the size ceiling, the reader grant is missing, or the last pass is older than the interval allows. Could not check is never presented as nothing is wrong.

Every answer also names the last verified position — the highest sequence number the walk actually proved. On a verified chain that is the top of the trail. On a broken one it is not the same number as the count of entries walked, and the difference is the point: the finding names where the chain broke, and this names the last entry before it that still re-computed, which is what an operator restoring from a backup acts on. A walk that could not run names no position at all, because it reached none.

A broken chain refuses nothing today; it warns. Whether it should stop ingest is a decision recorded as open in ADR-0058.

The same panel names the vault's identity profile — provisioned when an operator issued this vault's machine and workload certificates from a CA whose private key is not on this host, or self-enrolled when the vault holds that key and mints its own, which ADR-0004 rule 4 calls the weaker of the two and requires be disclosed rather than inferred.

Quarantine review (administrators)

Content the two ingest scan gates held never became a document. It waits in the console's quarantine queue, which is also reachable from the Quarantine entry on the portal's left-hand rail.

Each row is the whole record the vault kept of a blocked upload: when it was held, shown in your own time zone with the vault's exact value behind the cell; who uploaded it; what it was called, which is the name the uploader gave it and nothing the vault vouches for; whether it came out of an archive, and if so the path of the member inside it, so a single bad file inside a zip is not reported as the zip; the violation that was found, named and — where the vault has one — described in the words of whatever found it, which may be an attempt at SQL injection, an attempt to address the vault's own model as if it were an instruction, an archive that expands far beyond its declared size, malware a scanner recognised, or a scanner that refused or was never configured; the status of the hold; what became of the content; who decided and when; and the compartments the upload was aimed at.

The four classes are decided differently and are resolved differently, and the line between them is whether the hold was a judgement or a detection. Two are judgements and both can be released: an ambiguous classification — the vault could not tell what kind of document this is — and an auditor hold, where the ingest auditor read the text and thought it was addressing the vault rather than describing anything. Releasing either means naming the concept type yourself; that is the administrator supplying the answer the vault would not guess. A release re-runs the real ingest, both scan gates included — it is not a way past them.

The other two are detections and can only be rejected: a gate detection, and a file the vault could not read at all (unparseable). There is no release-anyway button for either, and that is deliberate: the two scan gates cannot be turned off by configuration, and an override here would be that switch wearing a different name. One limit of the content gate to know: its deterministic screen is English-only — it recognises English instructions however they are disguised, and an instruction written in another language is screened by the model-side checks (the ingest auditor and the query-time containment), not by this gate. The multilingual layer is the model-side screens.

The Content column is where the queue says whether the bytes still exist. An item still waiting on you says held for review: the content is still stored, because releasing it means ingesting it, and you cannot ingest what has been thrown away. Once an item is rejected the column says destroyed — the stored content is deleted and cannot be recovered, downloaded or read from this screen by anybody, including you. Nothing was lost that the vault needed: the record of the upload, its name and its violation all survive, so you can still tell what it was that failed.

What the vault keeps in the content's place is a fingerprint of it — a hash, shown shortened in that column with the full value behind the cell. It is not reversible and it is not the file; it is only enough to recognise the same bytes again. That is what it is for: if the same file is uploaded a second time, by the same person or anybody else, the vault matches the fingerprint and refuses it immediately, without scanning it again. Known-bad content therefore costs the vault nothing after the first time, and a person who re-sends it gets an answer straight away.

A detection can be wrong, and a fingerprint the vault remembers would otherwise keep it wrong forever — even after the scanner that mis-read the file is corrected, because those bytes are refused before anything looks at them again. The Cached block column is the way out. Where a row's fingerprint is one the vault is refusing on sight, that column says so and offers Clear: the vault stops recognising those bytes and scans them again the next time somebody uploads them. It is not a way of admitting the file. Both gates run on the fresh upload exactly as they always do, and if a gate stops it again the block comes back by itself. Clearing the same fingerprint twice does nothing the second time, and a fingerprint cleared by mistake can be restored by pasting it into the box below the queue. Only an administrator can do either, and both are audited.

Both decisions are audited, and neither reveals the held content on this screen — the queue states what an item is, never what it says.

Purging and reclassifying a version

The console's Documents panel lists the document versions you can see and offers two acts on each: Purge… and Reclassify…. Purging is permanent and is an administrator's act alone — the version's encryption key is destroyed, its stored bytes are deleted and the words it contributed to the search index are removed, in one transaction, so every compartment loses it at the same moment and no copy survives for anyone to restore. Because nothing can undo it, the console asks you to type the version id back before it will act, and refuses if what you typed is not that id. Reclassifying is a different power with different authority: it needs a write grant on the compartment you are moving the version to and on each one you are moving it from, which an administrator does not hold and a granted member does — so a move adds the version to the compartment you choose and removes it from every compartment you can see it in, and the people who read it there lose it. The pulldown you choose from lists only the compartments you hold a write grant on, so it cannot offer a destination the vault would refuse; if you hold none, no move is offered at all and the panel says so. The list is bounded by your own reach, which is why an administrator's is empty: an administrator purges a version somebody asked them to destroy, by pasting its id. Both acts are audited, on success and on refusal alike.

Proving a disposal. The same panel will issue a purge certificate for a version that has already been destroyed: a signed statement naming the version, the compartments that lost it, who ordered the destruction and where that act sits in the vault's audit chain, with Download the evidence beside it saving the chain entries themselves so the statement can be checked against them. Anyone holding this vault's engagement key can check a saved export without the vault running, with scripts/skykeep.sh verify_purge_certificate <file>. Read the scope the certificate states in its own signed words before you send it to anybody: it certifies this vault, as it is now, and here is the rest of that scope in the certificate's own words, not this page's:

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.

Asking for a certificate is itself audited, whether the vault issues one or refuses. Whether this vault offers certificates at all is a configurable capability, not a fixed feature: an administrator turns it on and off in the admin console under Settings, with purge_certificates, and it is on unless somebody has turned it off. While it is off, asking for one is refused with the reason said out loud and the refusal recorded in the trail. Turning it off takes nothing back: a certificate already issued goes on checking out, because what verifies it is the certificate itself and not this vault. One thing to know before you send the evidence file on: a hash chain can only be checked as an unbroken run, so the file carries the audit entries either side of the purge as well as the purge itself, and those neighbours are other administrative acts in this vault. None of them carries document content, but they do name versions, principals and operations.

What a purge does not reach. A purge destroys the version inside this vault and the per-version key that seals it; it does not reach a backup artifact already written, and the derived plaintext inside one — the summary, filename, keywords and indexed words — goes on existing until that artifact is retired. Bridge-mode engagements take no backups at all, so there is nothing of this kind to retire; a permanent-store engagement should read its backup retention window as the length of time that copy goes on existing.

What there is to purge. Beneath that list the panel offers an administrator a second one, and it answers a different question: not what can I read but what could a purge destroy. It is the surface for an erasure demand — destroy everything this person filed between these dates — and you narrow it by compartment, by who filed the versions, and by when the vault received them. It is metadata only: version ids, compartments, uploader, the date the vault received it, size, state and whether a legal hold stands. No filename, no title and no document text appear there, because an administrator reads none, and a listing that showed them would be the one place in this product where that stopped being true. Asking for the list is itself audited.

Purging all of it, as one batch. Beneath that listing an administrator can prepare a batch from the same filter. Preparing destroys nothing: the vault freezes the filter and the counts you were shown, and answers with a phrase to type — purge 37 versions — that carries the number. Typing it back is what destroys them, and the number is in it precisely so that a phrase learned when the answer was four cannot confirm a batch of thirty-seven. A batch can never reach a version filed after you looked: the end of its window is fixed at the moment you prepare it, even if you named no end date. A version under a legal hold is skipped and named rather than destroyed. Each version is destroyed in its own transaction, so one refusal does not undo the disposals that already succeeded — and a run interrupted halfway can be resumed with the same phrase, because resuming asks the vault what is left rather than replaying a list. A version already destroyed cannot be destroyed twice. Every row and every batch is audited.

A legal hold is how a version is made un-purgeable. An administrator places one on a version id with a written reason, and from that moment a purge of that version is refused by the vault's own database engine — before anything is destroyed, whoever asks and by whatever route. Placing and lifting are an administrator's acts alone, and both are audited whether they succeed or are refused.

A hold has no expiry, and nothing ends one on a timer. Each hold carries a review date, and a hold past that date is still a hold: it refuses a purge exactly as it did the day it was placed. The date is not a lifetime — it is the day somebody is expected to ask whether the obligation still stands. There is no setting in this vault that lifts a hold, because a configuration that destroyed preserved evidence on a schedule would be a worse failure than a hold nobody revisits.

What a passed review date does is make the hold visible. The console's Holds needing review table lists every active hold whose review date has gone by, the register marks each one Active — review overdue, and a purge refused by such a hold says so in the audit trail. If that table cannot be drawn it says so plainly rather than showing an empty list, because an empty list would read as good news.

Lifting a hold re-arms destruction, so it asks for more than a click: a written reason, which is kept in the register, and a confirmation phrase typed out in full. The console shows you the phrase to type. Getting it wrong lifts nothing and is recorded. The register itself lists holds, never documents — a version id, why it was placed, who placed it and when — so nothing on it implies that an administrator can read what it preserves. Lifted holds are never deleted from it: the record that an obligation existed and ended is what a register is for.

Requests to throw out a duplicate

When somebody finds two documents in their own compartments that read almost the same and asks for one copy to be thrown out, the vault records the request and destroys nothing. The console's Requests to throw out a duplicate panel is where those requests wait. Granting one is the same purge described above, with the same consequences and the same ritual: the key, the stored bytes and the search index entries are destroyed together, nothing can undo it, and the console asks for the version id typed back first. The other copy is untouched.

The panel shows version ids, who asked and when, and nothing else. That is not a gap: an administrator holds no compartment grants, so the vault cannot show it a filename or a title here without implying a reach it does not have. The person who can see both documents is the one who asked.

You can instead decline, in words the person who asked will read on the pair. Declining destroys nothing and does not change the answer they recorded. A reason is required, because a refusal nobody explained is one they cannot act on.

A copy under a legal hold cannot be thrown out until the hold is released. The row says so and the grant control is switched off — and the vault refuses the destruction itself whatever the screen shows. Both answers are audited, and a grant lands in the trail twice: once as the answer, once as the purge that carried it out.

Performance

The Performance page (visible to an administrator and a clientadmin) shows the vault's query-speed dials, the model timings measured from its own audit trail, and recommendations. Every recommendation names the measurement that produced it and the surface that applies it — the page itself changes nothing. Timings are model names and durations only: no prompt text, no document, no compartment appears there.

Stack diagnostics

Check stack asks the vault whether it can reach its database and its model runtime, and reports each. It is a health answer about the deployment and not about your documents: no compartment, document, title or count appears in it, which is why it is offered to everyone signed in rather than to administrators only. If something here comes back unhealthy, the troubleshooting page lists the errors operators actually meet, each with its cause and its fix.

Denials

A denial is deliberately plain: no reason attached, because explaining what was denied can leak what exists. Every denial is recorded in the audit trail, where an administrator can see the reason.