How it works
From a saved file to a history you can trust.
A precise account of what happens to your work inside AFTRIMGE, using the same terms as the architecture documentation.
-
01
Your folder
Source
A folder you chose. AFTRIMGE only reads it, except when you restore. Its own archive is never inside it.
watcher, normaliser, debouncer, ignore rules
-
02
Observation
Ingest
When a file has settled, its bytes are streamed once: hashed and written to a staging file in the same pass, flushed to disk, and only then published under their digest.
SHA-256 over exactly the bytes written, sync, rename
-
03
Canonical data
Canonical object
Content addressed by its digest, stored once however many versions share it. Its identity and size come from the bytes themselves.
objects/ab/cdef..., one row per distinct content
-
04
Historical observation
Snapshot
A version of one file at one time, pointing at an object, recorded in one transaction with its event. What was observed then is never rewritten.
files, snapshots, events in SQLite
-
05
Liveness
Retention and preservation
Something holds content while a retained snapshot, an archived image or a preservation points at it. Retention can release a snapshot's hold; collection removes only what nothing holds.
HolderKind: SNAPSHOT, ARCHIVED_ARTIFACT, PRESERVATION
-
06
Integrity
Integrity and recovery
Verification reads bytes and hashes them. Restore checks stored bytes, stages, checks, replaces and checks again. Repair uses only verified sources.
VERIFIED, CORRUPT, MISSING, UNREADABLE, UNVERIFIED
Six things AFTRIMGE keeps apart
| Kind | What it is | Where it comes from | Can it change? |
|---|---|---|---|
| Canonical data | An object's identity and size | The bytes | No. Different bytes are a different object. |
| Historical observation | A path, a time, the size a snapshot saw | What was recorded then | No. It is kept as observed. |
| Derived information | Thumbnails, measurements, relationship grades, traces | Computation over the above | Recomputed; a newer analysis version is reported as newer, not substituted. |
| Liveness | Whether content is still held | The holders that point at it | Yes, as holders are added or withdrawn. |
| Integrity | Whether stored bytes still match their identity | Reading and hashing the bytes | Only by checking again. |
| Preservation | Your decision to keep content | You | Only by you. |
The storage ledger
Every piece of content AFTRIMGE knows about, or finds on disk, has exactly one state.
- HELD
- Something holds it. A sweep will not remove it.
- RECLAIMABLE
- Nothing holds it. A sweep may remove it.
- MISSING
- Known, and its bytes are not on disk. The record is kept on purpose.
- UNTRACKED
- Bytes on disk with no record, the residue of an interrupted write.
When something goes wrong
AFTRIMGE is tested by terminating its own process at arbitrary moments during capture, collection and restore. After every kill the database passes SQLite's integrity check, no reference dangles, no version that claims its bytes lacks them, and a restored file is always one whole version.
What a crash can leave is stated rather than hidden: partial staging files, cleared at next launch; untracked bytes, reported and later swept; and a temporary copy beside a file being restored. Power loss has not been tested.
Evidence grades
| Grade | Means | Example |
|---|---|---|
| FACT | Proven by the operating system or by identical content hashes | A rename the OS reported; two files with the same bytes |
| INFERRED | A reproducible deterministic deduction from real evidence | A move recognised by content; an image measured as a resized copy |
| POSSIBLE | Real evidence that did not reach the threshold | A plausible but unconfirmed source |
| TEMPORAL | Known only from timing. Says when, never why | One file appearing shortly after another changed |
The full design, including every invariant and the defects found while building it, is in the architecture documentation.