protocol

KLIS-2: Conflict Semantics & Resolution

Deterministic rules for detecting collisions between agents.

1. Purpose

The Conflict Semantics Specification defines the deterministic rules for detecting collisions between agents. By defining a static Conflict Matrix, KLIS enables constant-time predicate compatibility validation of concurrent intents without requiring semantic negotiation between agents.

2. Core Principles

  1. Pessimism: If an intersection might be unsafe, it IS a conflict.
  2. Symmetry: Use of a symmetric matrix where possible (Conflict(A, B) implied Conflict(B, A)). Note: Wait-Die protocols may break symmetry in resolution, but detection is symmetric.
  3. Atomicity: Conflicts are binary. You conflict or you don't.
  4. Static: The rules do not change based on runtime data.

3. The Conflict Matrix

The following matrix defines the normative interactions between predicates held by different agents on the same resource.

Rows = Existing Lock (Held by Agent A)
Cols = Incoming Intent (Requested by Agent B)

| Existing \ Incoming | PROVIDES | CONSUMES | MUTATES | DELETES | DEPENDS_ON | | :--- | :---: | :---: | :---: | :---: | :---: | | PROVIDES | 🔴 | 🟢 | 🔴 | 🔴 | 🟢 | | CONSUMES | 🟢 | 🟢 | 🔴 | 🔴 | 🟢 | | MUTATES | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | | DELETES | 🔴 | 🔴 | 🔴 | 🔴 | 🔴 | | DEPENDS_ON | 🟢 | 🟢 | 🔴 | 🔴 | 🟢 |

Legend:

  • 🔴 CONFLICT: The incoming intent is rejected or queued.
  • 🟢 COMPATIBLE: The incoming intent is allowed to proceed concurrently.

3.1. Rationale (Normative)

  • PROVIDES + PROVIDES: Two agents cannot create the same file (race condition).
  • CONSUMES + MUTATES: Reader-Writer conflict. Classic "Stale Read" or "Dirty Read" risk.
  • MUTATES + MUTATES: Writer-Writer conflict. Lost update risk.
  • DELETES: Heterogeneous conflict. Deletion invalidates all other operations.
  • DEPENDS_ON: Helper predicate. Compatible with readers, essentially a "Do Not Delete" lock.

3.2. The Mutation-Read Lock

While a resource is under MUTATES or DELETES, the Control Plane MUST reject even CONSUMES requests. This enforces the "Pre-flight Snapshot" logic—readers cannot see "half-baked" writes. No agent can DEPEND_ON a resource that is currently being mutated, as the very structure or existence might change.

4. Logical Conflict Types

Definitions for tooling and debuggers:

| Type | Reason | | :--- | :--- | | Creation Collision (P+P) | Duplicate work or race to claim namespace. | | Stale Read Risk (C+M, M+C) | Reader may see partial state; Writer may invalidate read. | | Destructive Interference (M+M) | Simple overwrite race. | | Existence Failure (+D, D+) | Resource removal invalidates all assumptions. |

5. Batch Conflict Evaluation

When an agent submits a Manifest (Scope) containing multiple intents:

  1. Atomicity: The entire manifest succeeds or fails. Partial acquisition is FORBIDDEN to prevent deadlocks (see KLIS-4).
  2. Evaluation: 
    check_batch(manifest):
  for triple in manifest.intents:
    if check_conflict(triple.resource, triple.predicate):
      return CONFLICT(triple)
  return SUCCESS

6. Conflict Resolution Properties

6.1. Monotonicity

Once a conflict is detected, it persists until the holding agent releases the resource. There is no "negotiation" phase in the core logic.

6.2. Determinism

Given the same set of active leases and the same incoming manifest, the result MUST always be identical. Randomness is permitted only in backoff strategies (KLIS-4), not in conflict detection.

7. Security Considerations

  • Denial of Service (DoS): An agent acquiring MUTATES on critical resources (e.g., config.json) blocks all other readers.
    • Mitigation: KLIS-3 (Leases) MUST enforce TTLs.
    • Mitigation: Control Plane policies may restrict who can MUTATES sensitive paths.

8. Non-Goals

  • Merge Logic: KLIS-2 detects the conflict; it does not define how to merge git conflicts.
  • Resource Granularity: KLIS-2 assumes the Resource ID is the atomic unit. It does not handle "Line 10-20 of File X".