Metadata: your own columns on your own storage

Metadata is the customer's own classification, kept on their own storage: a Department, a Matter number, a Retain-until date. Caryvane never opens a file to decide what it is. Somebody sets the columns, somebody fills them in, and policy such as archiving can then act on what is missing.

Setting the base columns for a whole mount #

This is the usual starting point: one set of columns that applies to everything on a drive.

1. Metadata in the sidebar, then choose the storage target. Columns belong to a storage connection — there is no platform-wide set, because one customer's Matter number is another's Job code.
2. Add Columns. Give the set a name describing what it is for, not what it contains: the name is what somebody sees when they wonder which rules are in force.
3. Browse to the container and stop at its root. The label then reads <container> — and everything below it. That is the base set for the mount.
4. Add the columns. Each has a name, a type — Text, Choice, Number, Date, Yes/No or Term — and a Required tick.

To cover only part of a mount, browse to a folder instead of stopping at the root. Everything below that folder gets the set; everything else on the mount gets nothing.

One set applies, not several #

The nearest set wins, and it wins outright. A set on the container root and a set on Finance/Contracts do not combine: a file under Finance/Contracts gets that set's columns and only that set's columns. If a deeper set should also carry the base columns, repeat them in it.

This is the same rule as an archiving mark, so a folder tree behaves the same way for both.

Filling the columns in #

Three places, all writing to the same values:

• The console. Metadata → the target → a file → Edit Metadata.
• Windows. On a mounted cloud drive, the file's Properties dialog carries a Caryvane tab.
• Linux. caryvane tag show <file> and caryvane tag set <file> Key=Value; caryvane tag drives lists what is mounted.

Values are written beside the files on the customer's own storage, not into a Caryvane-only database. Move the bucket elsewhere and the classification moves with it.

Required, and “needs classification” #

A required column never stops anybody saving a file. Caryvane sits beside the storage; it is not a gate in front of it, and a backup product that refused writes would be a worse product. What a required column does is mark the file needs classification, which the Metadata screen filters on — All, Needs classification, Classified — and which policy can act on.

So "required" means "we will chase this", not "this cannot be saved". Set it on the handful of columns somebody will genuinely go back and fill in; a dozen required columns produce a list nobody reads.

Columns from SharePoint and Egnyte #

Where the source system has its own columns, Caryvane captures them and shows them as From the source system. They are read-only here: the source owns them, and an edit saved against a copy would be a second answer that never reaches the system of record. Add a Caryvane column alongside if you need a value Caryvane owns.

Changing a set later #

• Where a set applies cannot be changed. Remove it and add it where you want it — files keep their values either way, so nothing is lost by moving a set.
• Renaming a column's key orphans the values already written against it. The display name is safe to change; the key is the identifier the values are stored under.
• Removing a column stops it being asked for. The values already on files stay where they are.

Note for anyone driving this through the API or an AI assistant: a column accepts a defaultValue, and it is stored, but nothing applies it — no file is tagged with it and it does not count towards needs classification. Treat it as a note to whoever fills the column in.