Key takeaway
A repeatable presentation order can support a receiving test. Document separately whether the source establishes an actual sequence between tied events.
Two events share one recorded time
A work history contains an approval and an execution event, both stamped 09:00:00. A report puts approval first and appears to demonstrate the expected sequence. Yet the source may have rounded both times to the second, and the query may simply return rows in a convenient order. Before using the history to judge behavior, distinguish its recorded time, any source sequence and the chosen export order.
Require the query to state its ordering
PostgreSQL documents that rows returned without an explicit sort have unspecified order. Later sort expressions can resolve rows equal on earlier expressions. Its LIMIT guidance additionally requires an ordering that constrains results uniquely for a predictable subset. These are query-behavior facts, not evidence that an identifier’s alphabetical order describes the real-world sequence.
Write the sort recipe beside the export: timestamp ascending, followed by a stated stable identity key, with explicit missing-value handling and comparison semantics. Confirm that the key is unique within the intended record scope. If all sort expressions remain tied, the recipe still lacks a complete presentation rule. Preserve any genuine source sequence in its own field rather than replacing it with a generated row number.
A completed tie ledger
In this hypothetical fixture, events A-10 and A-20 carry the same second-level time. Their IDs are unique but have no documented chronological meaning. Sorting by time then ID makes A-10 consistently appear before A-20. An evaluator can reproduce that display and still has to leave the business chronology unresolved.
A second fictional pair carries a documented source sequence 17 then 18 from one stream. Within that sequence’s stated scope, it supplies additional ordering evidence. Do not extend the conclusion across other streams or assume a sequence survived a migration without checking. The table is an original review method, not a source-system guarantee.
| Illustrative evidence | Export decision | Chronology decision |
|---|---|---|
| Same second; IDs A-10 and A-20 only | Sort by time then unique ID | Mark actual order unresolved |
| Same second; source sequence 17 then 18 | Preserve sequence and its scope | Use only documented stream relationship |
| Same time; duplicate identity keys | Hold tie for correction | No invented tie-break identity |
| Missing event time; valid ID | Place in declared exception group | Do not assign a fabricated timestamp |
Test repeatability on a fixed input
Create the same synthetic input in a different physical row order, then run the proposed receiving query. Compare the ordered identity list, not only the row count. Repeat with tied times, duplicate sort keys, missing timestamps and identifiers that differ only under the selected comparison rule. State the expected failures before execution.
When the workflow uses pages or a top-N selection, include the boundary where tied events straddle the cutoff. A unique ordering helps make that selection explicit. Changes to the underlying data between requests raise a separate snapshot or pagination question; this ordering test cannot make a changing source static. Keep those acceptance records linked and distinguish their conclusions.
Keep an unknown sequence out of a causal label
A business rule such as approval preceded execution needs evidence of that relationship. A convenient sort order alone cannot supply it. If the source retained only tied, rounded times, define a tied or unresolved category or narrow the analysis to cases with documented sequencing. Choosing whichever ordering makes the workflow look compliant would manufacture a favorable history.
For the first fictional pair, the receiving contract accepts stable presentation and withholds the chronology-dependent label. For the second, it records the source sequence’s declared scope. Preserve the tie rule, query version and exceptions with the proposed package so another reviewer can reproduce the same bounded conclusion.
Use the first review to clarify the promise
The inventory description can state the timestamp resolution, whether source sequence fields exist and which records remain tied. That gives a receiving evaluator a concrete question before any actual event data is shared. Keep an approved introduction separate from a sample or evaluation permission. Reproducible ordering improves the evidence description; it does not establish rights or a commercial outcome.