3.6 Operational Hygiene From Day One

Every operator who has run a persona for a year has one story about something they lost: the LoRA overwritten during a retrain, the prompt that produced the best frame of the quarter and cannot be reconstructed, the account that went down and took the recovery email with it.

Hygiene costs about an hour to set up and prevents all three. Set it up before you generate anything, because retrofitting structure onto five thousand files is a task you will not do.

The folder tree

One persona, one root directory, five subdirectories. The numbered prefixes exist to force the sort order, not for decoration.

persona-name/
  00-bible/         character bible, settings preset, brand assets
  01-references/    raw reference material + provenance documents
  02-training/      datasets, run configs, trained LoRAs by version
  03-production/    working assets, in progress
  04-published/     approved finals + provenance manifests
  05-archive/       superseded work and full backups

Two rules make the tree work:

Nothing lives outside it. Not in Downloads, not on the desktop, not in a chat window. The moment an asset exists in two places, neither is authoritative and the provenance record from 11.5 is broken.

Production and published are separate. You will generate ten variants and keep one. Mixing those states means your published archive fills with work you rejected, and the audit in chapter 12.2 becomes archaeology.

File naming

The convention to use:

YYYYMMDD_persona_assettype_vNN_modeltag.ext

20261014_aria_portrait_v03_fluxdev.png

Date first, so a directory listing is chronological without relying on filesystem timestamps that copy operations rewrite. Persona second, because you will run more than one and because files travel into shared drives and client folders. Then type, version, and the model tag that produced it.

Four rules around it:

• Never rename a published asset. The provenance manifest points at the filename. Renaming orphans the record that proves what the asset is.
• Version numbers are per asset family, not per file. v03 means the third iteration of that portrait, not the third export.
• Filenames are searchable, not clever. final-final-v2-USE-THIS.psd is a warning sign, not a workflow.
• Rejected work gets a distinct suffix, so it can be excluded from the archive with one search.

The prompt register

One table, appended to on every generation you might want to reproduce. If you are running a scripted pipeline from chapter 7.3, this is a byproduct; if you are working in a UI, it is two minutes of discipline.

The register has a second value that only appears after a few hundred rows. It becomes the dataset for chapter 4.6's likeness QA and for the content audit in 12.2 — which prompt structures hold the face best, which models produce the most rejects, which settings correlate with the assets you actually published. You cannot answer those questions from memory at scale, and you cannot answer them at all if the register stopped three weeks after you started.

The rule that keeps it alive: make it automatic or make it trivial. A register that requires transcription by hand from a UI will decay. A register that is a log line emitted by the render script survives.

Backup

The training artifact is the thing to protect. A LoRA run costs two to seven hours and roughly $2 to $14 depending on the trainer and the configuration. [AS OF 2026-10] Recreating it is not only the compute — the curated dataset may be irreplaceable, particularly if it involved a consented model, a set of reference images that have since changed, or a person whose availability has ended.

Applying the standard three-two-one principle to a persona project:

Back up these six things, in this order of priority:

1. Trained LoRAs, every version, including the ones you did not ship.
2. Training datasets and run configurations.
3. The character bible and prompt register.
4. Published finals and their provenance manifests.
5. Reference material with its consent documentation.
6. The environment snapshot from 3.4.

Local copy, second copy on different media, third copy offsite or in cloud storage. Version the manifests alongside the assets, because a manifest that describes a file you no longer have is a liability rather than a record.

Test one restore. A backup you have never restored is a hope. Pick the LoRA directory, restore it to a different location, and confirm the file loads and reproduces the face. Do this once when you set the system up, and once a year after.

Security

This is the section that reads as obvious and gets skipped, and the failure is expensive.

API keys. One key per purpose, so revoking one does not break everything. Stored in a password manager or an environment file that is never committed and never screenshotted. Rotated when anyone else has seen them. And critically: set a billing cap on every provider. A leaked key on an uncapped account is not a security incident, it is a financial one, and it resolves overnight into an invoice.

Platform accounts, one email per persona. The persona's account should not share an email with your personal identity or with another persona. A suspension then costs you one account rather than the portfolio, and recovery stays possible.

Two-factor authentication everywhere, with an authenticator app rather than SMS. SMS is vulnerable to number-porting and fails when you change phones.

A dedicated browser profile per persona. This is hygiene and it is also risk containment. The research in chapter 12.6 is consistent that platform enforcement follows device and IP signals at least as much as content, so keeping a persona's sessions in their own profile limits the blast radius of a ban and prevents the cross-contamination that makes two personas look like one operator.

Recovery details you control. Use a recovery email that will still exist in three years and a phone number that is not a number you might lose. Several operators have discovered that their account's recovery path ran through a phone contract they canceled.

What you are defending against, specifically. Two attacks matter more than others in this business: social engineering of platform support, where someone convinces a support agent they own the account, and key theft from a screenshot or a shared document. The first is defeated by two-factor and by not tying identity to guessable details. The second by never pasting a key anywhere that renders pixels.

Where this goes wrong

Tidy folders with cryptic names. Structure without a naming convention is a cabinet with no labels.

A prompt register that dies in week three. Automate it or accept that you cannot reproduce your own winners.

Backing up only the published work. The published PNG is the least valuable file in the project. The LoRA and the dataset are the business.

Never testing a restore. Untested backups fail exactly when needed.

One email for every persona. A single suspension becomes a portfolio outage.

Keys in notes apps and screenshots. Then it is not a key, it is a public string.

No billing caps. The cheapest insurance in this entire book.

The gate

1. Does the folder tree exist, with five directories and nothing outside it?
2. Can you find any published asset from its filename alone?
3. Is the prompt register populated and automatic?
4. When did you last test a restore of the LoRA directory?
5. Does every persona have its own email, its own browser profile, and two-factor enabled?
6. Does every provider account have a billing cap?

What you leave with

A five-directory tree, a naming convention you can search, a prompt register that becomes your QA dataset, a backup priority ordered by what is irreplaceable, and a security baseline — separate emails, separate browser profiles, two-factor, billing caps — that costs an afternoon and protects the whole project.