Update-seq monotonicity vs explicit key ordering for deterministic bulk loads

In repeatable CouchDB development environments, bulk-document loads via the bulk_docs endpoint assign update_seq and _rev per write, but the database does not enforce monotonic creation order across concurrent requests or clustered nodes. This behavior arises from CouchDB's document-level update_seq model, which tracks revisions per document rather than maintaining a global insertion sequence. Consequently, test assertions that depend on stable document ordering by update_seq or _id sort order may produce non-deterministic results across container restarts or parallel test executions, especially when design-document views trigger incremental index rebuilds reflecting last-write-wins semantics. The practical uncertainty is whether implicit sequencing can be relied upon for deterministic local CI loops.

Does CouchDB guarantee deterministic update_seq ordering across concurrent bulk_docs requests targeting the same database? Can explicit key sequencing within bulk_docs payloads predict update_seq assignment? What view-query or index warm-up strategies ensure consistent document ordering in repeatable test assertions?