Intent Manifests (KLIS)

To prevent collisions, an orchestrator must understand exactly what an agent intends to do before it does it. Klock formalizes this via the Klock Intent Serialization (KLIS) protocol.

KLIS-0: The SPO Model

Every intent in Klock is represented as a Subject-Predicate-Object (SPO) triple.

| Subject | Predicate | Object | Meaning | |---------|-----------|--------|---------| | agent-1 | MUTATES | /auth.ts | Agent 1 wants to edit auth.ts | | agent-2 | CONSUMES | /auth.ts | Agent 2 wants to read auth.ts | | agent-3 | RENAMES | /auth.ts | Agent 3 wants to change the resource identity |

KLIS-1: The 6x6 Conflict Matrix

How does Klock know if Agent A can read a file while Agent B is writing to it? It checks the Conflict Matrix.

Klock implements a 6×6 predicate compatibility matrix. This allows Klock to check for conflicts in strict O(1) constant time, regardless of how many thousands of intents are active in the system.

Conflicts are defined internally as:

• MUTATES vs MUTATES: ❌ Conflict (Two writers)
• CONSUMES vs MUTATES: ❌ Conflict (Read during write)
• CONSUMES vs CONSUMES: ✅ Compatible (Two readers)

KLIS-2: The Lease Lifecycle

When Klock evaluates an intent and finds no conflicts, it grants a Lease.

{
  "success": true,
  "lease_id": "req-98x2-a4f2",
  "intent": {
    "subject": "refactor-bot-01",
    "predicate": "MUTATES",
    "object": "./src/auth.ts"
  },
  "expires_in_ms": 60000
}

A lease is a time-bounded token that proves the agent holds the right to execute that intent. When the agent finishes its task, it executes a RELEASE command, freeing the resource for the next agent in the Wait-Die queue.