0011 Records whose depositor is unknown, and keys for apps to read

While building external access and a service-layer API, arkive decided and wrote down two things that are not in 01-Permissions (arkive decision document and API document). Both will come up in other layer 2 apps too, so they are raised to layer 0 rules.

What

1. Stand-in depositor (stand_in)

For records whose depositor is not yet known or that have no deposit agreement (for example, old documents whose holding institution is “not yet specified”), someone grants permissions in the depositor’s place.

• A stand-in is recorded with stand_in: true in the permission record. On screen and in the ledger it is distinguished from the real depositor.
• What a stand-in can do: invite viewers and editors, apply confirmation stamps (as: "depositor", together with the stand_in mark), retract.
• What a stand-in cannot do: widen scope to “public”, destruction, naming a successor, consent to AI training. These cannot be undone, or only the owner can do them.
• When the real depositor appears, the role is handed over and what was done in the meantime is shown. The depositor can withdraw those permissions.

2. App key

The key a layer 2 app uses to read a layer 1 store.

• The depositor opens it per app and per volume. The app reads only what a permitted viewer can see (sealed, approval required and seal candidates are locked; no original files).
• The only thing an app can write is correction suggestions. They are marked as machine suggestions (made_by), and confirmation stamps are applied by people (decision 0006).
• Every request is logged (who, when, which volume, without content).
• When withdrawn, it closes at once. The key’s raw value is not kept in the store.
• In terms of the roles in the 01-Permissions table, it is “viewer + AI editor’s suggestions” combined. No new role is created.

Documents updated: 01-Permissions section 4 addendum (v0.3), 05-Glossary section 5.

Why

• arkive has already built and is using this (approved by the head of Nodeone, arkive decision 2026-10-12). If it is not in layer 0, secretary or other apps will build it differently.
• Without a line drawn around stand-ins, people who are not the owner would be able to do things only the owner can do (making public, destruction, consent to AI training). Principle 1 (the original belongs to its owner) and principle 8 (AI training only with the depositor’s consent).
• An app key is a combination of the viewer and AI editor rules, so it can be described without a new role.

Other options

Option	Why not chosen
Keep it out of 01, as an arkive-only rule	secretary and siltare would have to decide again when they meet the same situation
Give a stand-in all the same permissions as the depositor	People who are not the owner would do things that cannot be undone
Let nobody open records whose depositor is unknown	Most old documents are like this. Research and transcription would stop while the holding institution and depositor are being found
Make apps a new role (“app”)	More roles make the table complicated. Viewer and AI editor already explain it

Where it has effect

• arkive: app keys already have this shape. For stand-ins, it currently only records stand_in and does not block anything, so right now a stand-in can even carry out destruction. The four “cannot do” items must be blocked (arkive to-do).
• secretary: for recordings the depositor is always clear, so there are no stand-ins. App keys take this shape when secretary reads arkive (after v0.2).

Cost

0 won.