The Operator

Kind: ROLE DEFINITION · Spec: §3.5, §8.9 · Revision 1.0 · 2026-09-06 Canonical copy: C:\civbackup\00-docs\OPERATOR-ROLE.md · Published: yes

Where this sits. civilization-backup-build-spec-v1.7.md §3.5 defines the constraint; this document defines the role that satisfies it. The procedures the Operator actually follows are OPERATOR-MANUAL-EN.md and OPERATOR-MANUAL-ES.md. The drill that tests those procedures is DRILL-01.md. Figures of record are in WORKSTREAMS.md.

---

1. Why this role exists

A system only its builder can operate is not a backup. It is a hobby with a single point of failure, and the point of failure is a person.

That sentence is easy to agree with and hard to act on, because the builder can always operate the system, so nothing ever visibly fails. The defect is invisible until the day it matters, which is the same shape as every other defect this build has produced: a check that reports success, a table that reads as a table, an answer that is confident and wrong.

The Operator exists to make that defect visible on a schedule, in a drill, while the builder is still available to fix it.

2. What the Operator is

An adult who can follow step-by-step instructions on Windows or Ubuntu.

That is the whole competence floor, and it is deliberately low. Everything written for the Operator is written to it:

1. Every command is given literally, to be typed or copied exactly.
2. Every command shows what correct output looks like.
3. No step requires deciding, adapting a path, or interpreting an error.
4. Every way a step can fail routes to a page that names the symptom.

The Operator is not assumed to be technical. They are not assumed to know what a checksum is, what an embedding is, or why there are two copies of anything. Where that knowledge is needed to act safely, the manual supplies it at the point of use rather than assuming it.

Language. English and Spanish are both first-class. The procedures exist in both, as two separate documents rather than one mixed one. A bilingual page serves neither reader under stress; the project's own public site measured this and split its languages for the same reason.

3. What the Operator is responsible for

Item 5 is the one people skip and it is the one the drill is for. The output of a drill is a list of documentation defects. A drill that produces none on its first run is more likely to mean the builder was standing too close than that the document is perfect.

4. What the Operator is NOT responsible for

This list matters more than the one above it, because an unbounded role is one nobody accepts and nobody performs.

1. Not building anything. Not the index, not the models, not the site.
2. Not diagnosing errors the manual does not name. An unlisted error is a defect in the manual. Write down what the screen said and stop.
3. Not judging whether an answer is medically or technically correct. The Operator's duty on a figure is to open the source passage and read it, which is rule §9.2. Confirming that the passage says what the answer says is the whole task; deciding whether the passage is right is not.
4. Not maintaining, updating or acquiring corpora.
5. Not keeping the system secret. The archive is open material and the procedures are published.
6. Not being available at all times. The role has no on-call expectation.

5. Designating an operator for a deployment

The role is generic; a deployment is not. Each installation of this system records one person against the role before its first drill, in its own records and not in this document.

1. One name, not a household. Diffuse responsibility means nobody runs the drill. This is the part of the original §3.5 that survives unchanged.
2. They have agreed. A person who has not agreed is a plan, not an operator.
3. Their reading language is recorded, because it selects which manual is printed and stored with the drives.
4. A successor is named in one line, so the role survives the operator.
5. They are told what they are not responsible for, from §4 above, at the same time as what they are.

Where the archive keeps this: a single dated entry in BUILD-LOG.md naming the operator and the successor. Not in the published documents, and not in this one.

6. Training

Training is one supervised pass through the manual, in this order, on a working system, with the builder present and answering nothing:

1. Power on and reach a search result.
2. Ask a question that returns a figure, and open its source passage.
3. Ask a question the archive cannot answer, and see NOT IN ARCHIVE.
4. Start the quarterly checksum verification, and watch it produce no output for several minutes without concluding it has hung.
5. Stop everything and power down.

Anything the Operator cannot do from the pages alone is written down. The builder answers questions only after the step has been recorded as a defect, because a question answered aloud is a page that never gets written.

7. Succession

A role held by one person with no successor is the original problem with an extra step. Each deployment names a successor at designation. The successor needs no training until they succeed; the manual is the training.

---

Open for this deployment

1. No operator is designated yet for the Franklin installation. Required before §8.11, which is the annual drill.
2. No single platform rebuilds completely from the archive (§11.9, §12 item 7). A machine already running Windows can be rebuilt in full. Bare hardware can be given Ubuntu from the archive and then reaches only the keyword half of the surface, because the vendored wheels are all win_amd64. The manual says this in the rebuild chapter, at the point where it changes what the Operator should expect to see, rather than in a footnote.