Event order: evidence, partial timelines and contradictions

Last updated: 6 Oct 20265 min read

tutorial

A report can establish that one event preceded another without providing either exact timestamp. Keep a partial order and its evidence.

Extract events before connecting them

Represent each event with an actor, action, source span, document revision and optional time interval. “The queue recovered after the retry policy changed” supplies an ordering relation but no clock reading. Record BEFORE, AFTER, OVERLAP or UNKNOWN as a relation between event IDs, with the sentence that supports it. Do not convert a model score into a factual timestamp. Relation provenance explains why evidence belongs on each edge.

Check the graph for impossible order

Before adding an edge, test whether it would make a cycle in an otherwise strict BEFORE graph. A cycle may be caused by extraction error, a revised incident note or two people describing different event scopes. Flag the conflict and keep both claims for review. Do not silently remove the lower-scoring claim: its source might be a signed correction. Treat OVERLAP separately, since forcing overlapping intervals into a strict sequence invents order.

Handle revisions and uncertain anchors

A later status update may replace “recovered at 09:20” with “still failing at 09:20.” Keep both source revisions and mark which is current. Compare event identity, not just similar verbs; separate a canary deployment from the full rollout. Relative time normalization uses anchor and zone policy. When a temporal phrase cannot be grounded, an ordering statement can still be useful if its source evidence remains clear.

Evaluate the timeline people see

Score event span detection, relation accuracy, contradiction detection and the final timeline independently. A system can score well on pair relations but omit a critical rollback. Group updates from the same incident across splits and review temporal conflicts as cases, not isolated sentences. The project stages a timeline rather than presenting it as settled fact.

Implementation

def would_create_cycle(before_edges, earlier, later):
    if earlier == later:
        return True
    next_events = {}
    for source, target in before_edges:
        next_events.setdefault(source, set()).add(target)
    frontier = [later]
    seen = set()
    while frontier:
        event_id = frontier.pop()
        if event_id == earlier:
            return True
        if event_id not in seen:
            seen.add(event_id)
            frontier.extend(next_events.get(event_id, ()))
    return False

known = [("deploy-47", "alarm-82"), ("alarm-82", "rollback-91")]
assert would_create_cycle(known, "rollback-91", "deploy-47")
assert not would_create_cycle(known, "deploy-47", "recovery-120")

Performance and operating cost

Building adjacency and searching reachable events takes O(v + e) time and space for v events and e strict-order edges. Repeating that test for many proposed edges is expensive; a maintained topological index may help at scale. The code checks graph consistency, not whether a source statement is true. Human conflict review remains necessary.

Common Mistakes

Assigning a precise time to a statement that only gives order.
Discarding contradictory source evidence after a model picks one edge.
Treating overlapping events as a strict before-after chain.
Ignoring event identity when a note describes a canary and a full rollout.