Keeping knowledge current

Documents change. A price list gets revised, a policy gets a new paragraph, a procedure that was true last quarter stops being true this one. If an agent keeps answering from the old copy, it will do so confidently and be wrong — and nobody reading the answer has any way to tell.

kovac treats “the document changed” as a normal event rather than something you have to clean up after by hand. Uploading a revised file replaces the one an agent uses to answer, while the earlier copy stays on record for anyone who needs to look back. You can retire a document without deleting it, time-box one so it only applies for a known period, and check — before anyone asks a live question — exactly what an agent would see.

Replacing a document with a new version

Upload a file whose name matches a document already in the collection, and kovac offers to treat it as a new version rather than a second, unrelated document: a checkbox reading “Upload as a new version of name (vN)”, checked by default. Leave it checked and the new file becomes the current version once it finishes processing; uncheck it if you really did mean to add an unrelated document that just happens to share a name.

If the matching document is archived, the checkbox is there but disabled, with a note that you need to unarchive it first — kovac will not let a new upload quietly revive something you retired on purpose.

Nothing changes while the new file is still being processed. The document you are replacing keeps answering exactly as before, and the upload list shows the new file as “will replace vN when processed.” Only once processing finishes does the swap actually happen: the new file becomes current, and the old one is kept as a superseded version.

Access rules and metadata carry over to the new version automatically, so you do not have to redo who can see a document just because its content changed. Effective dates do not carry over — if the document you are replacing was time-boxed, set the dates again on the new version’s Metadata tab.

Uploading a folder or a .zip archive never offers this prompt; a bulk import always creates fresh documents. And if you upload a file that is byte-for-byte identical to an earlier, superseded version of a document — say, you grabbed the wrong file from an old backup — kovac recognizes it and restores that version instead of creating a duplicate, as long as you leave the new-version checkbox checked. If you uncheck it, the upload is treated as the unrelated document you asked for instead, and nothing is restored.

Documents brought in through a connected source work the same way, but automatically: a connector matches an item by where it came from, not by filename, and whenever the source changes, the connector brings in a new version and supersedes the one before it on its own. There is nothing to restore here by hand — the source itself is the history, so an older version synced from a connector is not offered as something to bring back.

Version history

Every document has a Versions tab listing every version in its history, newest first, with its state and when it was uploaded. From there you can:

• Open any version to view its content, exactly as it was.
• Compare with current to see what changed — the lines that were removed and the lines that were added since that version. A very long difference is truncated rather than shown in full; for that you are better off opening both versions side by side.
• Restore a superseded version, making it the current one again. The version that was current is kept, not deleted — it simply becomes the previous version in turn, so restoring is always reversible. A document brought in through a connected source cannot be restored this way; see the connector note above.

Nothing in this history is ever deleted by choosing a version to view — restoring, comparing, and opening all just read what is already there. What does eventually get removed is governed by a collection-wide setting, “Keep superseded versions for (days)”, on the collection’s Settings tab. It defaults to 90 days, giving you time to compare or restore an old version before it is gone; leave it blank to keep every version forever, or set it to 0 to have a superseded version removed the next time cleanup runs.

Spotting near-duplicates

Sometimes the same content ends up uploaded twice under different names — a file re-exported from another system, a copy someone saved locally and brought back in, a near-identical draft of something already there. kovac flags this on its own: when a newly ingested document is highly similar to another current document already in its collection, that document’s page shows a banner naming the match and how similar it is — for example, “93% similar to handbook-2025.pdf (v2).”

You only ever see a match for a document you are allowed to see both sides of — if the other document is not visible to you, the flag is not shown, and nothing about its existence leaks through the banner. A document carrying an open flag also shows a similar badge in the collection’s table, so you do not have to open every document to notice.

Nothing is ever merged automatically. The banner offers two decisions, and leaves the document exactly as it is until you make one:

• Make this a new version of name. This is the same move as uploading a revised file under an existing one’s name (see “Replacing a document with a new version” above): the document whose page you are looking at becomes the new current version, and the match becomes its previous version, kept on record rather than deleted. If the match is not in a state that allows this right now — it already has a version history of its own, say, or it is archived — kovac tells you why instead, and nothing changes until that is resolved.
• Not a duplicate. Dismisses the flag with no other effect at all — the two documents are simply unrelated, or similar enough by coincidence that there’s nothing to do about it.

A flag you dismiss, or a pair you link with “Make this a new version of,” never comes back for that same pair — but a later re-parse of either document can still flag a new match if something else in the collection turns out to be just as similar.

Dates a document applies

Some documents are only meant to be true for a limited time — a seasonal price sheet, a notice that expires on a given date, a policy that does not take effect until next month. On a document’s Metadata tab, under “When this document applies,” you can set an Effective from and an Effective until date.

Both are optional, and each stands on its own: set only a start date to mean “not before this,” only an end date to mean “not after this,” or leave both blank for no limit at all. Either date is inclusive of the whole day it names, measured consistently regardless of where you or your readers are — a document set to expire on the 30th is still in force for the whole of the 30th, everywhere. Outside its window a document is not deleted or hidden from view; it simply stops being something an agent will use to answer. You cannot change these dates while a document is archived — unarchive it first.

To check your work before it matters, the Search preview screen has an “As of” field, tucked under its advanced options. Set it to a past or future date and run a query to see which documents would have been in force on that day — a way to confirm a price change takes effect on schedule, or that an old notice really did stop applying when you expected. This is a preview tool only: in normal use, agents always answer as of today, never a date you have picked for them.

If a document is brought in through a connected source, that source can set its effective dates for you — from a sidecar file alongside the document, or, for a database source, from columns named for exactly these two dates. You do not need to open the Metadata tab by hand for a feed that already knows when its own records start or stop applying.

Archiving

Archiving takes a document out of circulation without deleting it. An archived document can still be opened, viewed and downloaded, and you can still change who has access to it — but it is never used to answer a question, and you cannot change its content, its metadata, its effective dates or its chunks, nor re-chunk or re-parse it, until you unarchive it first.

Archive a single document from its row menu on the collection page, or select several rows and archive them together using the bulk actions bar above the table. Unarchiving — from the same row menu, the bulk actions bar, or the banner on the document’s own page — puts it back exactly where it was, immediately eligible to answer again.

What agents see

An agent only ever answers from a document’s current version — never a superseded one, never one that has been archived, and never one outside its own effective-date window. All of those still exist and are still visible to you in the UI; they are simply excluded from what retrieval considers.

This matters for citations too. If someone opens a citation link that points at a version that has since been superseded — saved from an earlier conversation, say, or shared from an older export — kovac tells them the passage comes from an older version of the document, with a link straight to the current one.

Checking that it worked

The collection page’s state filter lets you see exactly what you expect to see: Current versions (the everyday view — every document’s current state, including archived ones), Active only, Archived only, Superseded only, or All versions to see the complete history at once.

Each row’s badges tell the same story at a glance: a version number once a document has more than one, archived, superseded, expires in N days or expired, not yet effective, and replacing an earlier version for an upload still mid-swap.

And when you want to be certain rather than just reassured, use Search preview to actually ask the question an agent would get asked, with “As of” set to whichever date you care about. It runs the same pipeline an agent’s search does, so whatever it returns is the real answer to “would this document still come back today?”