A serial number is a serial number. A VIN is a VIN. A PCGS cert number identifies one specific coin, encapsulated in one specific holder, forever.
These fields have something in common: editing them after the record is created is almost always wrong. A typo on day one is normal. A "correction" on day 400 is suspicious. And in a collection inventory — the kind of record you'd hand to an insurance adjuster or an executor — silent edits to identifying fields undermine everything else in the record.
What Vaultry locks
The following fields lock automatically after item creation, across every applicable collection type:
- Firearms — serial number, manufacturer, model
- Vehicles — VIN, year, make, model
- Numismatics — certification number, grading service, year
- Watches — serial number, reference number
- Comic Books — CGC certification number
- Trading Cards — PSA / BGS / SGC certification number
The full list is built into each collection's schema. If a field is "the thing that identifies this object in the real world," it's locked.
Why locking is on by default
Three reasons.
Audit integrity. An inventory is a record of what you own. If the identifying field can be changed silently, the record stops being a record.
Fraud resistance. If a stolen item ends up in your inventory under a swapped serial number, the activity log should make that change visible — not let it disappear into a quiet edit.
Real workflow alignment. In practice, the data behind these fields doesn't change. If your VIN changed, something is wrong with your title. If your serial number changed, you have a different gun. Catching that mismatch is the point.
The admin override
Mistakes happen. You typed 8 instead of B on day one. Or you bought the wrong slab and need to fix the cert number before deleting the record.
For those cases, an admin can unlock the field with a justification — a required text explanation of why the edit is being made. Both the old value, the new value, and the justification are written to the activity log with metadata.override = true and the admin user's identity attached.
That means:
- Anyone reviewing the activity log later sees the edit happened.
- The reason it happened is preserved in plain text.
- The original value is never lost — it's in the log even after the field reflects the new value.
What it looks like in practice
Open a coin record with a locked cert number. The field renders read-only with a small lock icon. Tap the icon and you'll see a sentence explaining why it's locked plus a button to request an admin override.
Click override and you'll see a dialog asking for the justification. Type a real reason ("Originally entered as 1234567, slab actually reads 1234568 — verified against PCGS website"), confirm, and the field unlocks for one edit. After the edit saves, it locks again.
The activity log shows:
Cert Number changed —
1234567→1234568
Admin override by mg1459 — "Originally entered as 1234567, slab actually reads 1234568 — verified against PCGS website"
That's the record. You and anyone you give access to can read it.
What this is not
Locked fields are not encryption. They're not a guarantee against someone with database access making changes outside the app. They're a workflow constraint with an audit trail — the same shape of guardrail you'd find in financial accounting software or evidence-handling systems.
They're for the everyday case where you, the collector, want a record you can trust six months from now.
Where this is going
The Grant Access feature on the roadmap will let you share a read-only or limited-edit view of your inventory with a spouse, executor, appraiser, or insurance agent. Locked fields are the foundation that makes shared access safe — when someone else opens your inventory, the identifying data can't be silently changed under your name.