🗂️ Curating your archive

Twenty years of photos, videos, mail and documents don't arrive tidy. NoCloudMe's job is to turn that pile into an ordered archive — and to do it so that nothing is ever lost, everything can be undone, and you can always ask why something ended up where it did.

Your originals are never edited

The vocabulary NoCloudMe uses to change your archive has no "edit file" operation at all. That's not a promise, it's an absence — there is no way to express it:

Renaming a file moves it. The bytes are untouched (checked before and after).
Dating a photo writes an XMP sidecar next to it, never inside the JPEG.
Deduplicating moves the loser to quarantine, it doesn't erase it.
Only an explicit, gated delete ever removes bytes, and it's logged.

So the guarantee "your originals stay intact" doesn't depend on every script behaving — it's a property of the vocabulary itself.

Everything is one undo away

Every bulk operation — importing from a phone dump, fixing thousands of dates, filing documents — is recorded as a run in a single append-only journal: what changed, from what to what, and why. One command reverts the whole run, applying each step's inverse in reverse order. The previous state of anything replaced (an old sidecar, say) is kept, addressed by content, so it can always come back.

If a step can't be undone, the whole revert refuses rather than doing half the job.

Operation	Its inverse
Copy a file in	Remove the copy (your source is untouched)
Move / rename	Move it back
Annotate (date, tag, description)	Restore the previous sidecar
Record / link a fact	Retract it
Delete	None — that's why it's gated and logged

Rules you can read, not a black box

Dates, albums and classifications aren't guessed by an opaque model. They come from readable rules over evidence:

Extractors read signal without changing anything: the date in a filename, EXIF, the mail a photo arrived in, a visual fingerprint.
Rules propose facts from that evidence ("IMG-20200504-WA0007.jpg → 4 May 2020").
Constraints veto impossible ones — a photo can't be dated outside the lifetime of a person who appears in it, a scan's date isn't the photo's date, 1970 is a sentinel and not a date.
Resolution settles conflicts by policy: the smallest plausible date usually wins, and a time of 00:00:00 means "approximate".

Nothing is invented: with no reliable signal, a photo goes to undated and the investigation queue, not to a made-up date.

"Why did this end up here?"

Every accepted fact carries its derivation: the value chosen, the alternatives that were discarded and why, and which constraints it passed. That's the difference between a glass box and a black box — an answer you can read is an answer you can correct. Correcting the system means editing a rule, not retraining a model.

It shows up where you actually look

A decision is worthless if you open your photo library and see nothing changed, so each kind of fact goes to the sink that surfaces it:

Dates, descriptions, tags, GPS → the XMP sidecar, which Immich re-reads.
Album membership and archived/hidden state → Immich's own API, because those live only in its database. Undoable too, by a compensating action (remove from the album, restore the previous visibility).
Edits you make yourself inside Immich — dragging a photo into an album, archiving it — are noticed and recorded in the journal too, so the history of an asset stays complete and a later undo never quietly overwrites something you did by hand.