Represent causal history component by component

For a fixed set of d participants, assign one component to each participant and initialize all components to zero. Before a local or send event, increment the component belonging to that participant. The event and any outgoing message carry the resulting vector. A component therefore tracks knowledge of a participant's event count within this model, rather than seconds spent executing there. Vectors must use the same component identities when compared. Treating the third position as node C on one machine and a newly joined node D on another destroys the meaning even if both arrays have identical numeric types.

At a receive event, take the componentwise maximum of the local vector and the message vector, then increment the receiver's own component. The merge preserves everything known on either side; the increment records that the receive itself is a new local event after the send. Messages must actually carry the relevant metadata through every modeled communication path. An uninstrumented queue, an external database handoff, or a process restart that resets an existing identity can break the intended causal-history interpretation. Use an incarnation or another justified identity scheme rather than recycling a component while stale messages remain possible.

Define one vector as no later than another when every component is less than or equal to its counterpart. Strict order additionally requires at least one strict inequality. Under the standard fully instrumented vector-clock model, this strict comparison characterizes happened-before for distinct event timestamps. If one component is larger while another is smaller, neither vector is below the other; their events are concurrent in the modeled execution. Summing components or sorting them lexicographically loses this information. A convenient list order is a presentation decision, not an equivalent causality test.

Consider vectors (3, 1, 0) and (2, 2, 0). The first contains more A history, while the second contains more B history, so neither dominates. A later event stamped (3, 2, 1) can contain both histories. That observation does not decide how an application should merge conflicting values. A causal relationship and a business-level conflict are different questions: concurrent increments may commute, whereas concurrent replacements may need an explicit resolution policy. Preserve enough provenance to distinguish the cases rather than assuming that a vector clock chooses the correct winning update for the product.

A straightforward vector carries d counters per timestamp, so communication and storage grow with the participant set. Dynamic membership, compact representations, and safe retirement require more than trimming old array entries: a removed participant can still have delayed messages or updates whose history affects comparisons. Practical systems may attach versions to replicas, objects, or other scoped identities instead of every thread. Their comparison semantics depend on that choice. Document what the vector summarizes and which protocol establishes that discarded history can no longer arrive. Compression that forgets necessary distinctions changes the claimed concurrency information.

The vector lab supplies a geometric analogy for componentwise incomparability. For each separate view, Reset, re-set angle and magnitude, predict both projections, then inspect the still frame. Compare angle 30 degrees and magnitude 2 with angle 60 degrees and magnitude 2. One positive x projection decreases while the positive y projection increases, so neither pair dominates. These are real-valued projections of one vector, not integer event histories or a vector-clock implementation. The analogy helps explain the comparison rule; the numerical exercise supplies the actual discrete causal updates and participant identities that the diagram does not contain.