fix broken para

_posts/2024-08-16-upid.md

@@ -45,8 +45,11 @@ It is most similar to a [ULID](https://github.com/ulid/spec), but with bits take
 
 Also like ULID, it is "lexicographically sortable", which basically just means it can be ordered by date. This is useful on its own, but is also valuable for things like ensuring index locality, WAL efficiency and easy sharding. However, UPID has lower time precision (256ms vs 1ms), which is arguably better for two reasons: [some people](https://github.com/paralleldrive/cuid2?tab=readme-ov-file#note-on-k-sortablesequentialmonotonically-increasing-ids) are concerned you can leak information with time-based IDs, and 256ms leaks a lot less; and many system clocks have worse than 1ms precision, so you won't have a false sense of monotonicity that might not exist.
 
-The great part about it, and the part that lets it solve the problem of the two options from further up, is that 
+Referring back to the two "problems" from further up:
+1. Stored as a 128 bit value in the database, so no inefficient `TEXT` values.
+2. Always knows what its prefix is, so you don't need to remember to add/remove anything at any boundary.
 
+## Data layout
 So, how does it work? Here's that same ID from further up, with the separate components broken up.
 
 ```elm