What SkyKeep can read

Every upload is kept twice: the file exactly as you sent it, and a plain-text rendering of it that the vault can search. Both are encrypted under the same key, both belong to the same compartments, and deleting the document deletes both — there is no state in which one survives the other.

The rendering is what makes a document findable. The original is what makes it defensible: if a conversion turns out to have read something badly, the file it read is still there to read again.

You can still find it by name, and you can still download exactly what you uploaded — byte for byte, including the bytes the conversion could not read. Anyone who may read the version may ask for its original; no separate permission exists, and none is needed.

Two things about how it comes back, both deliberate. It always arrives as a download, never rendered in the page, and always as unlabelled bytes rather than under the type the vault detected — the vault reports what it recorded in a header and refuses to serve under it, because a stored web page served under its own type would be someone else's document running inside the vault. And taking the original is recorded as its OWN act in the trail, distinct from reading the rendering: an engagement that asks who took a copy of the file as it arrived deserves an answer that is not mixed in with who read it.

Three answers, not two

Conversion quality is not a yes-or-no question, so the vault records one of three verdicts against every document and shows you which one it got.

Verdict	What it means for you
`converted`	The text the vault searches faithfully represents the document. Nothing of substance was lost.
`partial`	Usable text, and named losses — recorded against that document, not hidden in a footnote. The table below says what is lost for each format.
`original_only`	No meaningful text can be produced, so the vault keeps the file itself rather than a reading of it: encrypted, listed, and downloadable byte-for-byte, and honestly not searchable by its contents. You can find it by its name, its compartment and when it arrived, and you can get the original back exactly as you sent it; what you cannot do is search inside it. The row below says why for each. Whether a particular format is accepted at all is a separate question, and the table answers it row by row.

A format the vault converts badly is never presented as converted. A converter that silently mangles a format is worse than one the vault declines: the first produces confident wrong answers out of retrieval, and the second produces a clear message.

The formats

The vault accepts 41 of the 42 formats below today. This table is not written by hand — it is the same table the upload pipeline uses to choose a reader, so it cannot describe a vault other than this one.

File type	Can we convert it?	What is lost	Notes
Plain text `.txt`	Yes `converted`	—	Nothing to convert: a text file already is the searchable rendering, so what the vault indexes is exactly what you uploaded.
Markdown `.md`	Yes `converted`	—	Nothing to convert: Markdown already is the form the vault searches, headings and lists included.
CSV `.csv`	Yes `converted`	—	Read as one table, with the first line taken as the column headings; nothing structural is dropped, and a very wide table simply becomes a very wide Markdown table.
HTML `.html` `.htm`	Yes `converted`	—	The text, headings, lists and tables survive. Scripts and styling are dropped deliberately — a saved page's contents are what the vault indexes, not its appearance — and complex nested layout flattens into ordinary paragraphs.
Email message (EML) `.eml`	Yes `converted`	—	The headers and the message body both survive. Attachments are listed but not opened — an attachment is its own document, and uploading it separately is what indexes it.
Mailbox (MBOX) `.mbox`	Yes `converted`	—	A mailbox holds many messages; every one of them is converted and searchable, in the order the file lists them.
Word document (DOCX) `.docx`	Yes, with losses `partial`	table borders and shading floating shapes and WMF images comments	Tracked changes are read: text a reviewer inserted or deleted reaches the searchable rendering, and is scanned like the rest of the document. Worth knowing if you expected a document's edit history to stay private — the original is what carries it, and the vault reads it.
Excel workbook (XLSX) `.xlsx`	Yes, with losses `partial`	formulas are not evaluated — you get the value Excel last cached, or nothing if it never did charts and images conditional formatting	—
PowerPoint deck (PPTX) `.pptx`	Yes, with losses `partial`	slide layout and visual reading order — shape order is XML order, not what a viewer shows animations a picture on a slide, on a deployment with no vision engine configured — the slides carrying one are named in the converted text rather than dropped in silence on a slide that was read, everything but what a model read off the picture — a reading is an account of a picture, not the picture	Slide text and speaker notes are both read. Speaker notes are worth knowing about: they are searchable here even though a viewer does not show them to an audience. PICTURES ON SLIDES — a chart pasted in as an image, a screenshot, a photograph — are read as well, one slide at a time, when this deployment has a vision engine configured; the reading is stored under the slide it came from and says which engine read it and when. Without one the deck is still converted and still searchable, and the slides whose pictures went unread are named in the converted text rather than passed over in silence.
OpenDocument Text (ODT) `.odt`	Yes, with losses `partial`	all styling — bold, italic, fonts, sizes, colours and alignment list numbering, because an ODF document keeps it in its styles rather than in its text, so a numbered list arrives as bullets table borders, shading and merged cells images, charts and drawings comments headers, footers and page numbering	Headings keep their level, lists stay lists and tables stay tables, so the shape a reader would recognise survives into the searchable text. Three things are worth knowing before you upload one. Footnotes and endnotes are read, and arrive as their own short paragraph after the paragraph that cites them. Text a reviewer deleted under change tracking is read too — the vault reads what the marked-up document holds, so an edit history you expected to stay private does not. Comments are the one thing left out: they are kept in the stored original, which is always exactly the file you sent, and they are not part of the searchable text. The document reports its own title, both of its authors, its dates and the application that wrote it, and those are shown back to you.
OpenDocument Spreadsheet (ODS) `.ods`	Yes, with losses `partial`	all styling — fonts, sizes, colours, borders, shading and cell alignment formulas, which arrive as the value last calculated rather than as the formula that produced it charts, images and drawings comments cell validation rules, conditional formatting and filters	Each sheet arrives as its own heading followed by its cells as a table, in the order the workbook lists them, so a figure can be quoted with the sheet it came from. One thing is worth knowing before you upload: a hidden sheet, row or column is read like any other, so a sheet you hid is searchable here. The original is kept exactly as you sent it either way.
OpenDocument Presentation (ODP) `.odp`	Yes, with losses `partial`	all styling, layout and slide design speaker notes images, charts, diagrams and drawings animations and slide transitions comments	Slide titles arrive as headings and slide order is preserved, so the shape of the deck survives into the searchable text and a quotation can be traced back to a slide. Speaker notes are the one thing left out: they stay in the stored original, which is always exactly the file you sent, and they are not part of the searchable text.
PDF (text-based) `.pdf`	Yes, with losses `partial`	reading order on multi-column pages table structure — there is none in the extracted text figures on a scanned page, everything but what a model read off the picture — a reading is an account of a page, not the page	A SCANNED PDF — one that is photographs of pages rather than text — carries nothing to extract. Where a vision engine is configured its pages are read one at a time, the way an image is, and what the engine returns is document content: untrusted, screened, and never treated as instruction. Where none is configured the file is stored and listed but cannot be searched by its contents, and the vault says so rather than storing an empty rendering that looks like a successful conversion. A MIXED PDF — some pages text, some photographs — keeps the text it has and names the pages it could not read; it is never sent to an engine, because the pages it could read are already searchable.
TSV `.tsv`	Yes `converted`	—	Read as one table, with the first line taken as the column headings; nothing structural is dropped, and a very wide table simply becomes a very wide Markdown table. Following the format's own definition, quotation marks are ordinary characters rather than field delimiters — an inches mark in a cell stays an inches mark, and a single unbalanced quote cannot swallow the rest of the file. One honest limit: a tab-separated file carries no signature of its own, so a file whose name does not end in .tsv is read as plain text.
EPUB `.epub`	Yes, with losses `partial`	page layout and styling — columns, pull quotes and drop caps all flatten to ordinary paragraphs embedded fonts images and cover art, which carry no text the vault can read until OCR is decided internal cross-references and footnote links, which arrive as their words with nothing left to follow	Each chapter in the book's reading order is converted in turn and its own headings survive, so chapter structure and chapter order arrive intact. Read with the standard library's zip reader over the book's package file, into the same HTML conversion the vault already uses for web pages; nothing in the book is fetched from the network.
Rich Text Format (RTF) `.rtf`	Yes, with losses `partial`	all formatting — bold, italic, underline, fonts, sizes, colours and alignment headings, which arrive as ordinary lines of text rather than as headings list bullets, which arrive as a bullet character and a tab rather than as a list table structure — the cells of a row arrive joined by a vertical bar on one line, with no header row and no columns images and embedded objects	The words survive and the shape of the page does not: what comes back is the document's text, in order, as plain lines. That is enough to search and to quote from, and it is not enough to reconstruct the document — which is why the original is kept. The document's own title, author and dates are read from the file and shown back to you.
JSON data `.json`	Yes `converted`	—	The file is confirmed to be JSON and then kept exactly as you wrote it, in a code block. Nothing is reformatted, reordered or summarised, so what the vault searches is the document itself — which is why nothing is listed as lost.
TOML configuration `.toml`	Yes `converted`	—	The file is confirmed to be valid TOML and then kept exactly as you wrote it, comments included, in a code block. Nothing is reformatted or reordered.
YAML document `.yaml` `.yml`	Yes, with losses `partial`	the vault does not check that the file is valid YAML, so a file with a syntax error is stored and searched exactly as written rather than reported as broken	Kept exactly as you wrote it, comments and all, in a code block — which for a format whose whole purpose is being readable is a complete rendering. The vault deliberately does not run a YAML parser over it: the readers available expand repeated sections without limit, so a very small file can be made to expand into a very large one, and confirming the syntax is not worth handing an uploaded file that lever.
XML document `.xml`	Yes `converted`	—	The file is confirmed to be well-formed XML and then kept exactly as you wrote it, in a code block. A file carrying a document type declaration is refused rather than read: that is the construct which lets a small file expand into a very large one, and an XML document has no need of one here. A saved web page is read as HTML instead, by its own converter.
Jupyter notebook `.ipynb`	Yes, with losses `partial`	images, plots and charts in cell outputs, which carry no text the vault can read interactive widgets execution counts and cell metadata	Markdown cells arrive as themselves, code cells as code blocks tagged with the notebook language, and the text a cell printed follows the cell that printed it — so a result can be quoted with the code that produced it. Only the plain-text form of an output is read: a notebook can also store the same output as a web page, and the vault does not read that, both because it is a duplicate and because it is markup.
reStructuredText `.rst`	Yes, with losses `partial`	directive-generated content such as tables of contents, cross-reference targets and figures, which arrive as their words with nothing left to follow substitutions, which arrive as the substitution name inline roles, which arrive as their text	Section titles keep their level, literal blocks stay code blocks and lists stay lists, so the shape a reader would recognise survives. A directive the vault does not recognise is kept as the text it contains rather than dropped — losing a paragraph silently is worse than keeping it plainly. The converter reads only the file you uploaded: the format can ask for the contents of another file on disk, and nothing here will open one.
Calendar (ICS) `.ics`	Yes, with losses `partial`	repeating appointments are read as the one entry the file holds, not expanded into every date they fall on alarms and reminders free-busy blocks and time-zone definitions attachments, which are neither listed nor opened — they stay in the stored original	Every appointment in the file arrives as an entry giving its start, its title, where it was and who was invited, in the order the file lists them. Times are shown as the file wrote them, including the time zone it named, rather than converted to yours — a calendar is evidence of what was scheduled, and re-stating it in another zone would be the vault changing the record. Attendee addresses are read: a meeting invitation names people, and it is searchable here.
Contact card (vCard) `.vcf`	Yes, with losses `partial`	photos and logos, which stay in the stored original custom X- properties beyond the standard fields	Each card would arrive as an entry giving the name, organisation, telephone numbers, e-mail and postal addresses the file lists, in the file's own order. Not accepted yet. An upload of this format is refused today; the row states what the vault would do once a converter for it is adopted.
WebVTT subtitles `.vtt`	Yes, with losses `partial`	cue positioning, colours and styling region definitions inline markup, which arrives as its text speaker labels, which are kept only where the file wrote them into the cue text	Every caption arrives as its own line, prefixed with the time it appears, so a quotation can be traced back to a moment in the recording.
SubRip subtitles (SRT) `.srt`	Yes, with losses `partial`	cue positioning, colours and styling inline markup, which arrives as its text speaker labels, which are kept only where the file wrote them into the cue text	Every caption arrives as its own line, prefixed with the time it appears, so a quotation can be traced back to a moment in the recording. One honest limit: a subtitle file carries no signature of its own, so a file whose name does not end in .srt and whose contents do not look like numbered captions is read as plain text.
Excel workbook, legacy (XLS) `.xls`	Yes, with losses `partial`	all formatting — fonts, sizes, colours, borders, shading and alignment formulas, which arrive as the value stored with them rather than as the formula charts, images and drawings macros, which are stored in the original and never run comments	Each sheet arrives as its own heading followed by its cells as a table, in workbook order. Two things are worth knowing before you upload one. A hidden sheet, row or column is read like any other, so content you hid is searchable here. And this is the 1997-2003 binary workbook only: a file saved as XLSX is read by the modern reader instead, and the vault tells the two apart from the bytes rather than the name.
Word document, legacy (DOC) `.doc`	No `original_only`	Reading this format safely needs a converter large enough, and exposed enough to a hostile file, that adopting one is a decision in its own right rather than an import. Until that decision is made and built, the vault will not guess at the contents. Save the document as DOCX, PDF or RTF and the vault reads it fully.	—
Outlook message (MSG) `.msg`	No `original_only`	The available readers carry licence terms this product has not adopted, and adopting one changes what the whole vault may be distributed under — not a choice to make silently. Export the message as EML and the vault reads it fully, including its attachments.	—
Outlook store (PST) `.pst`	No `original_only`	A mailbox rather than a document: one file holding many messages, in a closed format. Unpacking it properly is its own piece of work and is not done yet. Export the messages as EML or MBOX — both are open formats the vault already reads, and both preserve the message boundaries this one hides.	—
Excel binary workbook (XLSB) `.xlsb`	No `original_only`	The binary workbook format has no reader this product can adopt. Save the workbook as XLSX and the vault reads every sheet.	—
JPEG image `.jpg` `.jpeg`	Yes, with losses `partial`	the reading is a model's account of the picture, not the picture — the image itself is kept, unchanged, and is what you get back layout, handwriting the engine could not make out, and anything the camera did not capture clearly where no vision engine is configured, nothing is read at all and the image is stored and sealed with that stated on its row	This vault can read an image — a photographed slide, a page of handwritten notes, a receipt — when it has been given a vision engine. What it reads becomes the document's text, shown beside the picture so you can check it, and you can write your own summary over the top. Without an engine the image is stored, encrypted, listed and retrievable, and its row says it was not read.
PNG image `.png`	Yes, with losses `partial`	the reading is a model's account of the picture, not the picture — the image itself is kept, unchanged, and is what you get back layout, handwriting the engine could not make out, and anything the camera did not capture clearly where no vision engine is configured, nothing is read at all and the image is stored and sealed with that stated on its row	This vault can read an image — a photographed slide, a page of handwritten notes, a receipt — when it has been given a vision engine. What it reads becomes the document's text, shown beside the picture so you can check it, and you can write your own summary over the top. Without an engine the image is stored, encrypted, listed and retrievable, and its row says it was not read.
GIF image `.gif`	Yes, with losses `partial`	the reading is a model's account of the picture, not the picture — the image itself is kept, unchanged, and is what you get back layout, handwriting the engine could not make out, and anything the camera did not capture clearly where no vision engine is configured, nothing is read at all and the image is stored and sealed with that stated on its row	This vault can read an image — a photographed slide, a page of handwritten notes, a receipt — when it has been given a vision engine. What it reads becomes the document's text, shown beside the picture so you can check it, and you can write your own summary over the top. Without an engine the image is stored, encrypted, listed and retrievable, and its row says it was not read.
WebP image `.webp`	Yes, with losses `partial`	the reading is a model's account of the picture, not the picture — the image itself is kept, unchanged, and is what you get back layout, handwriting the engine could not make out, and anything the camera did not capture clearly where no vision engine is configured, nothing is read at all and the image is stored and sealed with that stated on its row	This vault can read an image — a photographed slide, a page of handwritten notes, a receipt — when it has been given a vision engine. What it reads becomes the document's text, shown beside the picture so you can check it, and you can write your own summary over the top. Without an engine the image is stored, encrypted, listed and retrievable, and its row says it was not read.
HEIC image `.heic` `.heif`	Yes, with losses `partial`	the reading is a model's account of the picture, not the picture — the image itself is kept, unchanged, and is what you get back layout, handwriting the engine could not make out, and anything the camera did not capture clearly where no vision engine is configured, nothing is read at all and the image is stored and sealed with that stated on its row a HEIC still must be decoded before any engine can read it, and this build ships no HEIC decoder; without one the image is stored and sealed	This vault can read an image — a photographed slide, a page of handwritten notes, a receipt — when it has been given a vision engine. What it reads becomes the document's text, shown beside the picture so you can check it, and you can write your own summary over the top. Without an engine the image is stored, encrypted, listed and retrievable, and its row says it was not read. A HEIC photograph additionally needs a decoder this build does not ship, so it is stored and sealed even where a vision engine is configured. Save the photograph as JPEG and the vault reads it.
MP4 video `.mp4` `.m4v`	Yes, with losses `partial`	motion — only frames at scene changes are kept timing — the stills carry no frame times the soundtrack itself, which becomes a transcript and not audio frames dropped as near-duplicates of the one before them	The video is stored as you sent it. Frames are taken where the picture changes, near-identical ones dropped, and the rest assembled into a PDF stored as a second version you can open and page through. Each page is then read, and the soundtrack transcribed, by the engines this deployment is configured with — a phone video of a book's pages becomes searchable text. Without those engines the video is kept and listed, and says so.
QuickTime video `.mov` `.qt`	Yes, with losses `partial`	motion — only frames at scene changes are kept timing — the stills carry no frame times the soundtrack itself, which becomes a transcript and not audio frames dropped as near-duplicates of the one before them	Read exactly as MP4 is: frames where the picture changes, assembled into a PDF second version, each page read and the sound transcribed where this deployment has the engines for it.
WebM video `.webm`	Yes, with losses `partial`	motion — only frames at scene changes are kept timing — the stills carry no frame times the soundtrack itself, which becomes a transcript and not audio frames dropped as near-duplicates of the one before them	Read exactly as MP4 is. WebM and Matroska share a signature byte for byte; this vault tells them apart by the document type recorded inside the file, never by the filename.
Matroska video `.mkv`	Yes, with losses `partial`	motion — only frames at scene changes are kept timing — the stills carry no frame times the soundtrack itself, which becomes a transcript and not audio frames dropped as near-duplicates of the one before them	Read exactly as MP4 is. Matroska and WebM share a signature byte for byte; this vault tells them apart by the document type recorded inside the file, never by the filename.
WAV audio `.wav`	Yes, with losses `partial`	timing — no frame timestamps are preserved the audio format metadata — stored as WAV, transcribed as text	The audio file is stored as you sent it. It is transcribed by the speech-to-text engine this deployment is configured with, if one is present. Without that engine the file is kept and listed, and says so.
MP3 audio `.mp3`	Yes, with losses `partial`	timing — no frame timestamps are preserved the audio format metadata — stored as MP3, transcribed as text	MP3 files must start with an ID3 tag to be recognized. The audio file is stored as you sent it and transcribed by the speech-to-text engine this deployment is configured with, if one is present. Without that engine the file is kept and listed, and says so.

Reading the same file a different way

When the vault converts a file it tells you what it noticed — a spreadsheet whose rows are not the width of its heading row, a deck whose speaker notes are now searchable. Those remarks are not decoration. Each one names a decision the vault made about how to read the file, and for the formats below that decision can be changed.

You do not upload the document again. The vault still holds the file exactly as you sent it, which is what it kept it for: it reads those same bytes a second time, the way you asked, and replaces only the searchable rendering. The original is never altered, the document does not move between compartments, and the vault records which reading it used.

File type	What you can change	Choices	What changing it does
CSV	Column separator	`Comma (,)` (default) `Semicolon (;)` `Tab` `Vertical bar (\|)`	Which character separates one column from the next. Spreadsheets in much of Europe export with a semicolon, and read with the wrong separator a file arrives as a single very wide column or with rows that do not line up with their headings. If the converted table looks wrong, this is usually why.
PowerPoint deck (PPTX)	Speaker notes	`Include them in the searchable text` (default) `Leave them out`	Whether the presenter's notes are read along with the slides. They often say things the audience was never shown, and here they are searchable. Leaving them out keeps them in the stored original — which is always kept exactly as you uploaded it — but out of the searchable text.

Every other format the vault converts reads its files one way only. Where a format's behaviour is fixed by what the format is — tab-separated files have no quoting and so cannot use another separator — that is not offered as a choice, because it is not one.

What happens to a format we cannot convert

It is kept, not refused. A format the vault cannot convert is stored for its own sake — encrypted like everything else, listed where you would expect it, and downloadable byte-for-byte exactly as you sent it. What it is not is searchable by its contents, and the vault says so on the document itself rather than letting you find out from a search that quietly returns nothing.

4 of the 42 formats below are kept this way today — photographs and legacy office documents, mostly, where there is no text to extract in the first place. 1 of the 42 formats below is not accepted at all (Contact card (vCard)); the table says so on its own row.

The alternative costs you something real: a vault that turns away a photograph or a legacy document because it cannot read the words inside it is a vault that quietly loses part of an engagement. Keeping the file, and being plain about what can and cannot be done with it, is the trade this product makes.

The type is decided from the file's content, never from its name. A Word document saved as report.txt is read as a Word document, and a file with no extension at all is identified normally. Where the vault cannot identify something confidently it says unidentified rather than guessing — guessing is how a mis-detected file reaches the wrong reader.

What your documents say about themselves

Office documents, PDFs and email carry metadata inside them: an author, a title, timestamps, the application that produced them, and often a last-modified-by name and a revision count. These routinely survive inside files people believe are clean.

The vault extracts that metadata, keeps it separate from what it worked out for itself, and shows it back to you when you upload. That is deliberate: a vault that silently indexed an author name would have made a disclosure on your behalf that you never agreed to. Seeing it is what lets you decide.

It is also treated as untrusted, exactly like the document's contents. It is displayed as text and never as markup, and it is never passed to a model as an instruction — an author field is a perfectly good place for somebody to hide one.