README.md

@@ -692,10 +692,10 @@ Update times are in microseconds, as Ente records them.
 The JSON also holds the machine-learning data Ente computed for the photo, as
 `mlData`. Ente's apps detect faces in each photo and compute a CLIP embedding
 for it, a list of 512 numbers that describes what the photo shows. `mlData`
-holds everything but that embedding. In its place the JSON holds `keywords`,
+holds everything but the `clip` block, which holds that embedding. In its place
-derived from the embedding as described under "Keywords". A file with no
+the JSON holds `keywords`, derived from the embedding as described under
-machine-learning data has neither field. A file whose data holds no usable
+"Keywords". A file with no machine-learning data has neither field. A file whose
-embedding has no `keywords`.
+data holds no usable embedding has no `keywords`.
 
 The backup waits for the library's fetch of machine-learning data to finish
 before it writes the JSON files. When a file's data cannot be fetched,
@@ -748,11 +748,11 @@ derives a file's keywords the way the app sorts it. The categories are:
 
 Each category has a query, and a text embedding of that query from Ente's CLIP
 text model. A file's score for a category is the cosine similarity of the file's
-embedding and the category's: a number from -1 to 1, higher the more alike the
+embedding and the category's. That is a number from -1 to 1; the more alike the
-two embeddings are. The file falls in the category when its score reaches the
+two embeddings are, the higher it is. The file falls in the category when its
-category's minimum score. The keywords are the titles of the categories the file
+score reaches the category's minimum score. The keywords are the titles of the
-falls in, highest score first. A video never falls in a category marked "no
+categories the file falls in, highest score first. A video never falls in a
-videos", as in the app.
+category marked "no videos", as in the app.
 
 #### Collection directories
 
@@ -775,9 +775,10 @@ ignoring case, each gets its ID added: two albums named `Trip` become
 `Trip (10)/` and `Trip (11)/`. Two files in one collection whose titles match,
 ignoring case, get their IDs added before the extension: `IMG_0001 (12345).JPG`
 and `IMG_0001 (12346).JPG`. A collection named like another collection's JSON
-file, such as `Trip.json` beside `Trip`, also gets its ID added. A name too long
+file, such as `Trip.json` beside `Trip`, also gets its ID added. A file name
-for a file name, which most file systems limit to 255 bytes, gets its ID added
+longer than 255 bytes, the limit on most file systems, gets its ID added too. So
-too. It is then cut short before the ID, just far enough to fit. IDs never
+does a collection name longer than 250 bytes, which leaves room for `.json`.
+Either name is then cut short before the ID, just far enough to fit. IDs never
 change, so a name stays the same from run to run until such a clash appears or
 goes away.
 
@@ -834,7 +835,8 @@ Each entry holds:
 - `fileID` and `title`;
 - `classification`: the kind of failure;
 - `attempts`: how many runs in a row have failed the file;
-- `lastTriedAt`: when it was last tried, as a Unix time in milliseconds;
+- `lastTriedAt`: when the run that last tried it finished its refresh, as a Unix
+  time in milliseconds;
 - `error`: the error, as quak printed it.
 
 The kinds are: