layer

The work is split into three layers according to who does what.

---

1. Map

┌──────────────────────────────────────────────────────────────────────┐
│ layer 2  app (front desk)     secretary                              │
│          Where people record, read and edit. Holds no originals      │
├──────────────────────────────────────────────────────────────────────┤
│ layer 1  store (originals)    arkive                                 │
│          Holds originals, the ledger and fingerprints. Not the owner │
├──────────────────────────────────────────────────────────────────────┤
│ layer 0  protocol             hgp (these documents)                  │
│          Owns nothing; only sets the promises                        │
└──────────────────────────────────────────────────────────────────────┘

layer	Name in this document	Name in the September HGP specification	Name in the arkive protocol	What it does
layer 0	protocol	protocol layer	promise layer	Sets the principles, permissions, fingerprints and the shape of the manifest. There is only one
layer 1	store	sovereignty layer	original layer	Receives originals, checks their fingerprints, keeps them locked, and writes the ledger
layer 2	app	front-desk layer	service layer	Recording, reading, transcription, correction, assistant. There can be many

Promises between layers:

• A lower layer does not know about the layers above it. layer 0 documents are not changed for the sake of a particular app. layer 1 receives in the same way whichever app uploaded.
• layer 2 holds no originals. It hands the originals and fingerprints made on the device to layer 1, and when it makes the interpretive layer, it reads only as much as the depositor allowed.
• When layer 0 changes, layer 1 and layer 2 follow. Every ledger line records the specification version it followed (hgp), so it is always possible to know which version a record followed.

2. layers and provenance grades are not mixed

Earlier, the layers were written as “floor 0, floor 1, floor 2” (0층, 1층, 2층), and the provenance grade (how far something has moved from the original) as “L0 to L3”. Both carried numbers and were confusing, and renaming the floors to “layer” would make them even more confusing next to “L + number”. So the numbers were removed from the provenance grade. (Decision 0005)

Term used	Meaning	Example
layer 0, layer 1, layer 2	Who does what (organization)	“secretary is layer 2”
original, draft, confirmed, derived (provenance grade)	How far it has moved from the original	“The recording file is the original; the machine transcription is a draft”

• A layer is always written as the lowercase English word layer and a number. It is not shortened to “층” (floor), “Layer” or “L1”.
• A provenance grade is always written as a plain word (in Korean, a Korean word). In the level field of the ledger it is written as original, draft, confirmed, derived. It is never written as L and a number, like “L0”.
• The authentic layer = original; the interpretive layer = draft, confirmed, derived. The “층” (layer) in “진본층” (the authentic layer) and “해석층” (the interpretive layer) is not a layer in this sense. These are terms from Nodeone’s common rules, so they are kept as they are.
• L0, L1, L2 and L3 in the September specification and in hgp v0.1 are, in order, original (in the September specification, “원음”, original sound), draft, confirmed and derived. Read them this way only when reading old documents.
• Korean particles: “layer 0” and “layer 1” are read as “yeong” and “il” and take the particles “은/이/을/과”; “layer 2” is read as “i” and takes “는/가/를/와”.
• Places where other projects use the same word with a different meaning (Layer in siltare, L0 to L4 in windandflow, and so on) are listed in 05-Glossary.

3. Current folders

Folder	Layer	What	How far it follows HGP (2026-10-12)
hgp	layer 0	These documents
September specification draft (not public)	basis of layer 0	44 September specification drafts (HGP-0000 to 0203, Layer0 v0.3), canonicalization decisions, canonical glossary, external standard mappings. Source material for these documents	Read only. Not changed
arkive	layer 1	Store for old documents. Original scans, ledger, reading layers, IIIF export	Originals read-only, one fingerprint on the server, append-only ledger. No locking, login, Merkle tree or daily fingerprint
secretary	layer 2	Recording assistant app and server. The “HGP recorder v0.1” of the September specification became this (the code was newly written in secretary). The secretary working rules call it “Secretary (Haru)”, and the name shown in the app is still “Secretary”	Two fingerprints (phone and server), originals read-only, manifest. Keeps a staging store until the arkive intake exists (section 4). Locking in v0.2, signatures and Merkle tree after that
secretary staging store folder	staging store (store: staging)	Per-depositor daily folders that the secretary server builds up. Originals to be moved to arkive	Same as secretary
cheroki	before HGP	Receiving Telegram recordings and transcribing them	Does not follow. No audio fingerprint; renames originals. Read only
Personal archive	before HGP	Personal record vault. Fingerprint ledger of transcript texts (hashes.jsonl)	Partly (fingerprints only for transcript texts). Read only
Sacho (sacho)	before HGP	Sacho protocol. One person’s original oral records	Protected with a fingerprint ledger and git. An earlier experiment for HGP

4. There is one layer 1 store

arkive is the one place that keeps originals for the long term. Even as apps multiply, the number of stores does not grow. (Nodeone common rules, secretary decision 0009, hgp Decision 0004)

• Apps do not build up originals directly for the long term. They save to the device first (principle 2), take the fingerprint, and entrust the original to arkive.
• Until the arkive intake (the counter that receives originals) exists, an app server may keep a staging store. The promises are exactly the same as layer 1: read-only, no overwriting, two fingerprints, manifest. The ledger’s store field records staging.
• When moving, the file is copied, the fingerprint is checked again, and if it matches, only a new line (store: arkive) is added to the ledger. Originals in the staging store are not deleted without separate approval.
• When: the move happens together with secretary locking (v0.2, target 11/16). Entrusting locked originals to arkive has been the intended shape from the start. Because the app locks the original with the depositor’s key before handing it over, arkive (the administrator) cannot see the content (principle 3).
• The interpretive layer (transcription, correction, assistant text) stays on the app server for now.

One store, but two or more bodies of each original (Decision 0010, September specification HGP-0007 section 3).

• The original and its copy are kept in different places. A different folder on the same computer, or a different disk in the same room, is not a different place.
• They are kept in Korea.
• When kept with an outside company (a cloud provider and so on), they are sent only while locked. That company must not be able to see the original.
• The regular fingerprint check (02-Fingerprint section 3) also runs on the copies. If an original has changed, it is restored from a copy with the same fingerprint.
• The ledger (fingerprint list, volume fingerprints, permission records) is also kept in two places along with the originals.
• At present (2026-10-12), arkive’s originals exist only on one main server. The second place has been decided as an external disk, which has not been bought yet.