Distributed Counter Conflict Resolution Prompt

This prompt is designed for systems engineers and platform developers managing eventually-consistent distributed counters where concurrent increment and decrement operations can produce conflicting states. The job-to-be-done is resolving these conflicts deterministically using CRDT merge rules or last-writer-wins (LWW) policies, producing a single authoritative counter value that preserves monotonicity and convergence guarantees. The ideal user understands distributed systems concepts—vector clocks, replica state, merge semantics—and needs a prompt that can be embedded into an automated conflict-resolution harness, not a one-off debugging session.

Use this prompt when your system has multiple replicas accepting counter updates independently, and you need to reconcile divergent states during anti-entropy or read-repair. It expects structured inputs: the current local counter value, the incoming remote counter value, associated vector clock or timestamp metadata, the merge policy (e.g., CRDT PN-Counter, LWW with timestamp arbitration), and any domain-specific constraints like maximum counter bounds or monotonicity requirements. The prompt works best when the conflict metadata is already extracted and formatted—it is not designed to parse raw database logs or network traces. Do not use this prompt for single-writer counters, strongly-consistent datastores where conflicts cannot occur, or non-numeric state reconciliation like shopping cart merges or text field conflict resolution.

Before deploying this prompt, ensure your harness validates that both input values are numeric and that timestamps or vector clocks are present and comparable. The prompt assumes the caller has already detected a conflict; it does not perform conflict detection itself. For high-throughput systems, pair this prompt with a caching layer that stores recent resolution decisions to avoid redundant LLM calls for identical conflict patterns. If your counter semantics include custom merge logic beyond standard CRDT rules—such as weighted increments, decay functions, or multi-party quorum requirements—extend the [CONSTRAINTS] placeholder with explicit merge equations rather than expecting the model to infer them from examples alone.

This prompt template is designed to be dropped into a conflict-resolution harness that detects when concurrent operations on a distributed counter have produced divergent states. The model receives the conflicting operations, their metadata, and the current observed state, then produces a resolution decision and a corrected counter value. Use this when your system cannot deterministically merge counter operations at the infrastructure layer and needs a reasoned resolution that preserves monotonicity and convergence guarantees.

textCopy
You are a distributed-systems conflict resolver for eventually-consistent counters. Your job is to analyze conflicting increment and decrement operations and produce a single resolved counter value using the specified conflict-resolution policy.

## INPUT
Conflicting operations:
[CONFLICTING_OPERATIONS]

Current observed counter value across replicas:
[OBSERVED_VALUES]

Conflict-resolution policy:
[RESOLUTION_POLICY]

Operation metadata (timestamps, node IDs, causal context):
[OPERATION_METADATA]

## OUTPUT_SCHEMA
Return a valid JSON object with these fields:
- "resolved_value": integer (the final counter value after resolution)
- "resolution_policy_applied": string (the policy used: "CRDT_merge", "last_writer_wins", "majority_observed", or "custom")
- "operations_accepted": array of operation IDs that were applied
- "operations_discarded": array of operation IDs that were discarded, with a reason for each
- "convergence_guarantee": string (explain why this resolution ensures all replicas will converge)
- "monotonicity_check": boolean (true if the resolved value is >= all previously acknowledged values)
- "confidence": string ("high", "medium", or "low")
- "explanation": string (brief reasoning for the resolution decision)

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

Adapt this template by replacing the square-bracket placeholders with your system's actual data. [CONFLICTING_OPERATIONS] should contain the full list of pending increment and decrement operations with their arguments and unique IDs. [OBSERVED_VALUES] must include the counter value as seen by each replica that reported a conflict. [RESOLUTION_POLICY] should specify whether to use CRDT state-based merging, operation-based merging with causal context, last-writer-wins with vector clocks, or a custom policy. [OPERATION_METADATA] is critical for causal ordering—include hybrid logical clocks, vector clocks, or Lamport timestamps. [CONSTRAINTS] should encode your system's invariants, such as "counter must never decrease below zero" or "only operations from nodes in the same partition group are considered." [EXAMPLES] should include at least one correct resolution for a simple conflict and one for a complex multi-replica divergence. Set [RISK_LEVEL] to "high" if the counter drives billing, rate-limiting, or safety-critical thresholds—this should trigger human review in your harness before the resolved value is committed.

Before deploying this prompt, wire it into a harness that validates the output schema strictly. Check that monotonicity_check is true and that the resolved_value equals the sum of accepted increments minus accepted decrements. If confidence is "low" or the resolution discards operations that appear causally valid, escalate to a human operator. Do not use this prompt for counters that require strict serializability—it is designed for eventually-consistent systems where temporary divergence is acceptable and the goal is safe convergence, not real-time accuracy.

The distributed counter conflict resolution prompt is designed to sit inside a reconciliation loop—not as a one-shot call. When your application detects conflicting increment or decrement operations on the same counter key (typically from a vector clock mismatch, concurrent writes, or partition healing), the harness should extract the conflicting operation set, the current observed state, and the merge policy before invoking the LLM. The prompt expects a structured input payload containing the counter key, the list of conflicting operations with their timestamps and origin nodes, and the declared conflict resolution strategy (CRDT-based, last-writer-wins, or custom merge rule). Do not call this prompt for single-operation counter updates; those should be handled by your normal write path.

Wire the prompt into a reconciliation worker that is triggered by your conflict-detection layer—typically a DynamoDB conditional write failure, a Cassandra LWW tombstone collision, or a CRDT state merge that produces sibling values. The harness must: (1) deserialize the conflict metadata into the [CONFLICTING_OPERATIONS] placeholder as a JSON array of operation objects with fields operation_id, type (increment|decrement|set), delta, timestamp (HLC or wall clock), and origin; (2) inject the current counter value and version vector into [CURRENT_STATE]; (3) set [RESOLUTION_STRATEGY] to the configured policy; and (4) provide the expected [OUTPUT_SCHEMA] as a JSON Schema describing the resolved counter value, the merge rationale, and the list of applied and discarded operations. After receiving the LLM response, validate the output against the schema and run the mandatory harness checks before accepting the result.

The harness must enforce three non-negotiable validation checks before writing the resolved counter value back to the data store. Monotonicity check: if the counter is declared as monotonic (e.g., a like count that should never decrease), verify that the resolved value is greater than or equal to the previous confirmed value. Convergence check: replay the same conflict set through the prompt twice (or across two models in a shadow deployment) and confirm the resolved value is identical; divergence indicates the prompt is non-deterministic and needs tighter constraints. Operation accounting check: sum the deltas of all applied operations and verify they match the difference between the old and new counter values. If any check fails, log the failure with the full conflict payload and LLM response, increment a counter_conflict_resolution_failure metric, and either retry with a different temperature setting or escalate to a human operator via your incident management system. Never write an unvalidated counter value to your data store.

For retry logic, implement a bounded retry loop with a maximum of 3 attempts. On each retry, vary the temperature parameter (start at 0, then 0.1, then 0.2) and append the previous validation failure reason to the [CONSTRAINTS] section as an explicit instruction: 'Previous attempt failed monotonicity check. The resolved value must be >= [PREVIOUS_VALUE].' If all retries fail, escalate the conflict to a dead-letter queue with the full conflict context and mark the counter key as requiring manual reconciliation. Instrument the harness with OpenTelemetry spans that trace the full lifecycle: conflict detection → prompt invocation → validation → write-back or escalation. This trace data is essential for debugging convergence failures and tuning the prompt over time.

Model choice matters here. Use a model with strong instruction-following and deterministic output capabilities at low temperature (0–0.1). GPT-4o and Claude 3.5 Sonnet perform well on structured merge tasks, but always run a shadow evaluation with your actual conflict patterns before promoting to production. Avoid models that tend to hallucinate arithmetic—counter resolution requires precise delta summation, and a hallucinated sum breaks convergence. If your counter values are large or your conflict sets contain many operations, consider pre-computing the arithmetic outside the LLM and using the prompt only for the merge decision (which operations to apply or discard), then performing the counter arithmetic in application code. This hybrid approach reduces the risk of arithmetic errors while keeping the LLM focused on the conflict resolution logic.

Finally, build a lightweight reconciliation dashboard that surfaces counters stuck in escalation, resolution latency percentiles, and validation failure rates by counter key prefix. This operational visibility lets you detect when a specific counter pattern (e.g., a hot key under high concurrency) starts producing repeated conflicts and needs a dedicated merge function rather than an LLM-based resolution path. The prompt is a safety net for rare conflicts, not a replacement for deterministic merge logic on your high-throughput counter keys.