Cortivex Mesh Coordination (Enhanced)

This skill extends the base cortivex-mesh protocol with MeshResolver node capabilities, automated conflict detection, and resolution strategies adapted from SWARM's coordination patterns. While cortivex-mesh defines the file ownership protocol that every agent must follow, this skill adds the orchestration layer that detects, prevents, and resolves conflicts across the agent pool.

Overview

In multi-agent pipelines, file conflicts are inevitable. Two agents may need the same file, an agent may hold a claim too long, or a complex refactor may touch files that another agent is reviewing. The MeshResolver node sits alongside the SwarmCoordinator and actively manages these situations:

• Detects potential conflicts before they occur by analyzing task scopes
• Prevents conflicts by pre-allocating file ownership based on task assignments
• Resolves conflicts using configurable strategies when they do occur
• Detects deadlocks when two agents are each waiting for files held by the other

When to Use

• Pipelines with 3+ agents that may modify overlapping files
• Refactoring or migration pipelines that touch many files across the codebase
• When agents have long-running tasks and file claims may expire before completion
• Pipelines where conflict-related failures have occurred in previous runs
• Any orchestrated pipeline where you want proactive conflict management rather than reactive error handling

You do NOT need a MeshResolver for:

• Pipelines where agents work on strictly separate file sets
• Read-only analysis pipelines (no file modifications)
• Single-agent pipelines

How It Works

Conflict Detection

The MeshResolver continuously monitors the mesh state and detects conflicts in three categories:

1. Direct Conflicts -- Two agents attempt to claim the same file simultaneously.

Agent A claims src/auth/login.ts for "auto-fixing"
Agent B claims src/auth/login.ts for "refactoring"
--> MeshResolver detects: direct conflict on src/auth/login.ts

2. Scope Overlaps -- Two agents' task scopes cover the same directory or module, creating a high probability of future conflicts.

Agent A assigned to "refactor src/auth/ module"
Agent B assigned to "add input validation to src/auth/ endpoints"
--> MeshResolver detects: scope overlap on src/auth/

3. Deadlocks -- Two or more agents are each waiting for files held by the other, creating a circular wait.

Agent A holds src/auth/login.ts, waiting for src/auth/session.ts
Agent B holds src/auth/session.ts, waiting for src/auth/login.ts
--> MeshResolver detects: deadlock between Agent A and Agent B

Resolution Strategies

The MeshResolver supports five resolution strategies, configured per-pipeline or per-conflict:

priority

first-claim

preempt

partition

serialize

Deadlock Resolution

When a deadlock is detected, the MeshResolver:

1. Identifies the cycle of waiting agents
2. Selects the agent with the lowest-priority task as the "victim"
3. Forcibly releases the victim's claim
4. Requeues the victim's task with status

   ready

5. Broadcasts a

   deadlock_resolved

   event to all agents
6. Logs the deadlock for post-run analysis

Pre-Allocation

Before agents begin work, the MeshResolver can analyze all task assignments and pre-allocate file ownership to prevent conflicts entirely:

cortivex_mesh_resolver({
  action: "pre_allocate",
  tasks: [
    { task_id: "task-1", agent_id: "agent-1", files: ["src/auth/login.ts", "src/auth/session.ts"] },
    { task_id: "task-2", agent_id: "agent-2", files: ["src/api/routes.ts", "src/api/middleware.ts"] },
    { task_id: "task-3", agent_id: "agent-3", files: ["src/auth/session.ts", "src/models/user.ts"] }
  ]
})

Response:

{
  "status": "conflicts_detected",
  "conflicts": [
    {
      "file": "src/auth/session.ts",
      "agents": ["agent-1", "agent-3"],
      "tasks": ["task-1", "task-3"]
    }
  ],
  "resolution": {
    "strategy": "serialize",
    "order": ["task-1", "task-3"],
    "reason": "task-1 has higher priority (8) than task-3 (6)"
  },
  "allocation": {
    "agent-1": ["src/auth/login.ts", "src/auth/session.ts"],
    "agent-2": ["src/api/routes.ts", "src/api/middleware.ts"],
    "agent-3": ["src/models/user.ts"]
  },
  "deferred": {
    "agent-3": {
      "files": ["src/auth/session.ts"],
      "available_after": "task-1 completes"
    }
  }
}

Pipeline Configuration

Adding a MeshResolver to an Orchestrated Pipeline

name: conflict-aware-refactor
version: "1.0"
description: Multi-agent refactor with proactive conflict resolution
nodes:
  - id: coordinator
    type: SwarmCoordinator
    config:
      pool_size: 4
      runtime: auto
      task_strategy: priority-queue

  - id: resolver
    type: MeshResolver
    depends_on: [coordinator]
    config:
      strategy: priority
      deadlock_detection: true
      deadlock_check_interval_seconds: 10
      pre_allocate: true
      stale_claim_timeout_seconds: 300
      max_wait_seconds: 60
      on_conflict: resolve
      on_deadlock: release_lowest
      log_conflicts: true

  - id: monitor
    type: AgentMonitor
    depends_on: [coordinator]
    config:
      auto_recovery: true

  - id: analyze
    type: ArchitectAnalyzer
    depends_on: [resolver]
    config:
      target_path: src/
      managed_by: coordinator

  - id: refactor_auth
    type: RefactorAgent
    depends_on: [analyze]
    config:
      target_path: src/auth/
      managed_by: coordinator
      mesh_aware: true

  - id: refactor_api
    type: RefactorAgent
    depends_on: [analyze]
    config:
      target_path: src/api/
      managed_by: coordinator
      mesh_aware: true

  - id: refactor_models
    type: RefactorAgent
    depends_on: [analyze]
    config:
      target_path: src/models/
      managed_by: coordinator
      mesh_aware: true

  - id: test_run
    type: TestRunner
    depends_on: [refactor_auth, refactor_api, refactor_models]
    config:
      test_command: npm test
      coverage_threshold: 80

MeshResolver with Partition Strategy

For large-scale migrations where many agents need to touch many files:

name: large-migration
version: "1.0"
description: TypeScript migration with file partitioning
nodes:
  - id: coordinator
    type: SwarmCoordinator
    config:
      pool_size: 5
      runtime: auto

  - id: resolver
    type: MeshResolver
    depends_on: [coordinator]
    config:
      strategy: partition
      partition_method: directory
      pre_allocate: true
      deadlock_detection: true

  - id: analyze
    type: ArchitectAnalyzer
    depends_on: [resolver]
    config:
      target_path: src/
      managed_by: coordinator

  - id: migrate
    type: TypeMigrator
    depends_on: [analyze]
    config:
      source_dir: src/
      managed_by: coordinator
      mesh_aware: true
      batch_size: 10

  - id: test
    type: TestRunner
    depends_on: [migrate]
    config:
      test_command: npx tsc --noEmit && npm test

With

partition

src/

Conflict Event Flow

When a conflict occurs during execution, the following sequence plays out:

1. Agent B calls cortivex_mesh({ action: "claim", files: ["src/auth/login.ts"] })
2. Mesh returns { status: "denied", owner: "agent-A" }
3. Agent B calls cortivex_mesh({ action: "report_conflict", ... })
4. MeshResolver receives the conflict report
5. MeshResolver checks the configured strategy:
   - If "priority": compare task priorities of Agent A and Agent B
   - If "first-claim": Agent A keeps the file; Agent B waits
   - If "preempt": coordinator decides which agent to interrupt
6. MeshResolver executes the resolution:
   - Forcibly releases claims if needed
   - Requeues affected tasks if needed
   - Notifies agents of the resolution
7. Agent B retries the claim (or receives alternative assignment)

MeshResolver Node Reference

- id: resolver
  type: MeshResolver
  config:
    strategy: priority                    # priority | first-claim | preempt | partition | serialize
    deadlock_detection: true              # enable circular-wait detection
    deadlock_check_interval_seconds: 10   # how often to check for deadlocks
    pre_allocate: true                    # analyze tasks and pre-assign files before execution
    partition_method: directory           # directory | file-list | module (used with partition strategy)
    stale_claim_timeout_seconds: 300      # force-release claims older than this
    max_wait_seconds: 60                  # max time an agent waits before escalating
    on_conflict: resolve                  # resolve | report | halt
    on_deadlock: release_lowest           # release_lowest | release_newest | halt
    log_conflicts: true                   # record all conflicts for post-run analysis
    conflict_report_on_complete: true     # include conflict summary in pipeline results

Monitoring Conflicts

During Execution

cortivex_mesh_resolver({
  action: "status",
  run_id: "ctx-a1b2c3"
})

Response:

{
  "active_conflicts": 1,
  "resolved_conflicts": 3,
  "deadlocks_detected": 0,
  "stale_claims_released": 1,
  "current_conflicts": [
    {
      "file": "src/auth/session.ts",
      "agents": ["agent-worker-2", "agent-worker-4"],
      "strategy_applied": "priority",
      "status": "resolving",
      "waiting_agent": "agent-worker-4"
    }
  ],
  "allocation_map": {
    "agent-worker-1": ["src/api/routes.ts", "src/api/middleware.ts"],
    "agent-worker-2": ["src/auth/login.ts", "src/auth/session.ts"],
    "agent-worker-3": ["src/models/user.ts", "src/models/session.ts"],
    "agent-worker-4": ["src/utils/validator.ts"]
  }
}

Post-Run Conflict Report

After the pipeline completes, the MeshResolver produces a conflict summary:

Mesh Coordination Report
========================
Total conflicts:       4
Resolved automatically: 4
Deadlocks:             0
Stale claims released: 1

Conflict History:
  1. src/auth/session.ts  agent-2 vs agent-4  -> resolved by priority (agent-2 won)
  2. src/models/user.ts   agent-3 vs agent-1  -> resolved by first-claim (agent-3 won)
  3. src/utils/helpers.ts  agent-1 vs agent-2  -> resolved by priority (agent-1 won)
  4. src/auth/login.ts    stale claim by agent-2 (expired) -> auto-released

Recommendations:
  - src/auth/ had 2 conflicts; consider partitioning this directory in future runs
  - agent-4 was blocked 3 times; assign it to a separate module scope

Quick Reference

cortivex_mesh_resolver({ action: "pre_allocate", tasks })

cortivex_mesh_resolver({ action: "status", run_id })

cortivex_mesh_resolver({ action: "force_resolve", file, winner })

cortivex_mesh_resolver({ action: "release_stale" })

cortivex_mesh_resolver({ action: "check_deadlocks" })

cortivex_mesh_resolver({ action: "history", run_id })

cortivex_mesh_resolver({ action: "set_strategy", strategy })

cortivex_mesh_resolver({ action: "allocation_map" })

Best Practices

1. Use pre-allocation for pipelines where task scopes are known in advance. Preventing conflicts is cheaper than resolving them.
2. Choose the right strategy -- Use

   priority

   when tasks have clear importance rankings. Use

   partition

   for large-scale migrations. Use

   serialize

   when file-level atomicity is required.
3. Enable deadlock detection in any pipeline with 3+ agents that may need overlapping files.
4. Set stale claim timeouts to prevent abandoned claims from blocking other agents indefinitely.
5. Review the conflict report after each run. Recurring conflicts on the same files suggest the pipeline should partition those directories.
6. Combine with AgentMonitor -- Dead agents leave orphaned claims. The AgentMonitor detects agent death, and the MeshResolver releases the dead agent's claims.
7. Keep claims short -- Agents should claim files, do their work, and release immediately. Long-held claims increase conflict probability.
8. Use mesh_aware: true on modification nodes so they automatically follow the check-claim-release protocol from the base cortivex-mesh skill.

Reasoning Protocol

Before configuring a MeshResolver, reason through:

1. Will agents actually have overlapping file scopes? If each agent works on a completely separate directory, you do not need a MeshResolver. Save the overhead.
2. Which resolution strategy fits the workload? Use

   priority

   when tasks have clear importance rankings. Use

   partition

   for migrations. Use

   first-claim

   when tasks are equal priority. Use

   serialize

   only when file-level atomicity is critical.
3. Should I pre-allocate or resolve on-the-fly? Pre-allocation prevents conflicts entirely but requires knowing all task scopes in advance. On-the-fly resolution handles dynamic workloads where scopes emerge during execution.
4. What is the acceptable wait time? Configure

   max_wait_seconds

   based on your pipeline's time budget. Short pipelines need aggressive resolution; long-running pipelines can afford to wait.
5. How many agents are involved? 2-3 agents rarely need a MeshResolver. 4+ agents with overlapping scopes benefit significantly from proactive coordination.

Anti-Patterns

strategy: preempt

priority

first-claim

preempt

stale_claim_timeout_seconds

partition

Grounding Rules

• Unsure which strategy to use: Default to

  priority

  . It handles most scenarios well and degrades gracefully when priorities are equal (falls back to first-claim behavior).
• Too many conflicts in a single directory: This signals that the directory should be treated as a single unit of work. Assign it to one agent instead of splitting across multiple agents.
• Deadlock detected but cannot identify the cycle: Use

  cortivex_mesh_resolver({ action: "check_deadlocks" })

  to get the full cycle. The agent with the lowest-priority task should be the release victim.
• Agent needs a file held by a higher-priority agent: Wait. Do not escalate unless the wait exceeds

  max_wait_seconds

  . Higher-priority work should complete first.

Advanced Capabilities

Multi-Strategy Conflict Resolution

The MeshResolver can evaluate conflicts against multiple strategies simultaneously and select the optimal resolution. Use

cortivex_conflict_resolve

{
  "tool": "cortivex_conflict_resolve",
  "request": {
    "action": "evaluate",
    "conflict_id": "cfl-8x92ka",
    "file": "src/auth/session.ts",
    "agents": ["agent-worker-2", "agent-worker-5"],
    "strategies": ["priority", "partition", "serialize"]
  }
}

The resolver scores each strategy and returns a ranked recommendation:

{
  "tool": "cortivex_conflict_resolve",
  "response": {
    "conflict_id": "cfl-8x92ka",
    "recommended_strategy": "serialize",
    "rankings": [
      { "strategy": "serialize", "score": 0.92, "reason": "Sequential adds minimal overhead" },
      { "strategy": "priority", "score": 0.85, "reason": "Clear priority gap" },
      { "strategy": "partition", "score": 0.41, "reason": "Single file; cannot partition" }
    ],
    "applied": "serialize",
    "execution_order": ["agent-worker-5", "agent-worker-2"]
  }
}

Distributed Transaction Coordination

For pipelines where multiple file modifications must succeed or fail as a unit, define transaction boundaries in your pipeline YAML.

resolver:
  type: MeshResolver
  config:
    transactions:
      enabled: true
      groups:
        - name: auth-refactor
          files: [src/auth/login.ts, src/auth/session.ts, src/auth/middleware.ts]
          atomicity: all-or-nothing
          rollback_on_failure: true
        - name: api-update
          files: [src/api/routes.ts, src/api/handlers.ts]
          atomicity: best-effort
      isolation_level: read-committed
      max_concurrent_transactions: 3

With

all-or-nothing

Deadlock Detection & Auto-Recovery

The MeshResolver uses a wait-for graph to detect circular dependencies. Configure detection policy to control frequency, victim selection, and recovery.

{
  "deadlock_policy": {
    "detection": {
      "enabled": true,
      "algorithm": "wait-for-graph",
      "check_interval_ms": 5000
    },
    "victim_selection": {
      "strategy": "lowest-priority",
      "fallback": "youngest-task",
      "preserve_agents_with_commits": true
    },
    "recovery": {
      "auto_recover": true,
      "max_recovery_attempts": 3,
      "backoff_base_ms": 1000,
      "on_max_attempts_exceeded": "halt_pipeline"
    }
  }
}

When

preserve_agents_with_commits

Coordination Protocol Selection

Use

cortivex_coordination_configure

pessimistic-locking

optimistic-concurrency

hybrid

{
  "tool": "cortivex_coordination_configure",
  "request": {
    "action": "set_protocol",
    "run_id": "ctx-d4e5f6",
    "protocol": "optimistic-concurrency",
    "params": { "conflict_check": "on-commit", "retry_on_conflict": true, "max_retries": 5 }
  }
}

{
  "tool": "cortivex_coordination_configure",
  "response": {
    "run_id": "ctx-d4e5f6",
    "protocol": "optimistic-concurrency",
    "previous_protocol": "pessimistic-locking",
    "status": "applied",
    "warnings": ["3 agents hold pessimistic locks; converted to version stamps on next cycle"]
  }
}

Failover & Graceful Degradation Patterns

When the MeshResolver encounters failures or agents become unresponsive, failover strategies keep the pipeline running. Define failover behavior with the following schema.

{
  "failover": {
    "resolver_unavailable": {
      "strategy": "fallback-to-local",
      "local_strategy": "first-claim",
      "max_local_duration_seconds": 300
    },
    "agent_unresponsive": {
      "detection_timeout_seconds": 30,
      "action": "release-and-reassign",
      "preserve_partial_work": true
    },
    "degradation_levels": [
      { "level": 1, "trigger": "single_agent_failure", "response": "reassign_tasks" },
      { "level": 2, "trigger": "resolver_partial_failure", "response": "switch_to_local_resolution" },
      { "level": 3, "trigger": "multiple_agent_failures", "response": "pause_and_consolidate" }
    ]
  }
}

When

fallback-to-local

Security Hardening (OWASP AST10 Aligned)

This section defines security controls for Cortivex mesh coordination operations, aligned with the OWASP Agentic Security Top 10 risk framework. Each subsection references the specific AST risk ID it mitigates.

AST06: Force-Release Protection

The

preempt

# AST06 -- Require elevated approval for preemptive claim release
resolver:
  type: MeshResolver
  config:
    strategy: priority
    force_release_policy:
      require_approval: true                  # AST06: no auto-preempt without authorization
      approval_source: coordinator            # only the SwarmCoordinator can approve
      require_reason: true                    # must provide justification string
      max_force_releases_per_run: 5           # AST06: cap to prevent abuse
      cooldown_after_force_release_ms: 5000   # prevent rapid repeated preemptions
      audit:
        log_all_force_releases: true
        include_approver_identity: true
        alert_on_threshold_exceeded: true

{
  "$schema": "https://cortivex.io/schemas/force-release-request.json",
  "type": "object",
  "properties": {
    "action": { "const": "force_release" },
    "file": { "type": "string" },
    "current_owner": { "type": "string" },
    "requested_by": { "type": "string" },
    "approved_by": { "type": "string" },
    "reason": { "type": "string", "minLength": 10 },
    "approval_token": { "type": "string" },
    "ast_risk_id": { "const": "AST06" }
  },
  "required": ["action", "file", "current_owner", "requested_by", "approved_by", "reason", "ast_risk_id"]
}

MCP tool invocation with approval:

cortivex_mesh_resolver({
  action: "force_resolve",
  file: "src/auth/session.ts",
  winner: "agent-worker-5",
  approval_token: "apr-9f2e-coordinator",
  reason: "agent-worker-2 unresponsive for 120s; blocking critical path"
})

Transaction Rollback Integrity

When rolling back file modifications in

all-or-nothing

# AST06 -- Verify file integrity during transaction rollback
resolver:
  config:
    transactions:
      enabled: true
      rollback_integrity:
        verify_pre_state: true                # AST06: hash file content before rollback
        verify_post_state: true               # AST06: confirm rollback restored original
        hash_algorithm: sha256
        on_integrity_mismatch: halt_and_alert # do not proceed if hashes diverge
        preserve_rollback_evidence: true      # keep copies of pre/post state
        evidence_retention_hours: 72
      groups:
        - name: auth-refactor
          files: [src/auth/login.ts, src/auth/session.ts]
          atomicity: all-or-nothing
          rollback_on_failure: true

{
  "tool": "cortivex_mesh_resolver",
  "request": {
    "action": "verify_rollback",
    "transaction_id": "txn-3f8a",
    "checks": ["pre_state_hash_match", "post_state_hash_match", "no_partial_writes"]
  }
}

Response:

{
  "transaction_id": "txn-3f8a",
  "status": "rollback_verified",
  "files": [
    {
      "path": "src/auth/login.ts",
      "pre_hash": "sha256:a1b2c3d4...",
      "post_hash": "sha256:a1b2c3d4...",
      "match": true
    },
    {
      "path": "src/auth/session.ts",
      "pre_hash": "sha256:e5f6a7b8...",
      "post_hash": "sha256:e5f6a7b8...",
      "match": true
    }
  ],
  "integrity": "verified",
  "ast_risk_id": "AST06"
}

Deadlock Detection Timeout Limits

Unbounded deadlock detection intervals create resource starvation attack vectors where a malicious or buggy agent can hold claims indefinitely. Strict timeout limits prevent agents from monopolizing resources (AST06).

# AST06 -- Bound deadlock detection to prevent resource starvation
resolver:
  config:
    deadlock_detection: true
    deadlock_security:
      max_claim_hold_seconds: 600            # AST06: absolute max any agent can hold a file
      max_wait_seconds: 120                  # AST06: max time waiting for a contested file
      max_detection_cycles: 50               # prevent infinite detection loops
      starvation_detection:
        enabled: true                        # detect agents repeatedly denied access
        threshold_consecutive_denials: 5
        on_starvation: escalate_to_coordinator
      timeout_actions:
        on_claim_timeout: force_release_and_requeue
        on_wait_timeout: reassign_task
        on_detection_loop: halt_and_alert

import { MeshSecurity } from "@cortivex/mesh";

// AST06: Configure starvation prevention at runtime
const meshSecurity = new MeshSecurity({
  maxClaimHoldSeconds: 600,
  maxWaitSeconds: 120,
  starvationDetection: {
    enabled: true,
    consecutiveDenialThreshold: 5,
    onStarvation: (event) => {
      meshSecurity.escalate({
        agent: event.agentId,
        file: event.contestedFile,
        denials: event.consecutiveDenials,
        astRiskId: "AST06",
      });
    },
  },
});

Protocol Switching Authorization

Switching coordination protocols at runtime (e.g., from

pessimistic-locking

optimistic-concurrency

{
  "$schema": "https://cortivex.io/schemas/protocol-switch-policy.json",
  "type": "object",
  "properties": {
    "protocol_switching": {
      "type": "object",
      "properties": {
        "require_approval": { "type": "boolean", "default": true },
        "allowed_transitions": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "from": { "enum": ["pessimistic-locking", "optimistic-concurrency", "hybrid"] },
              "to": { "enum": ["pessimistic-locking", "optimistic-concurrency", "hybrid"] },
              "approval_level": { "enum": ["coordinator", "admin", "quorum"] }
            },
            "required": ["from", "to", "approval_level"]
          }
        },
        "deny_by_default": { "type": "boolean", "default": true },
        "ast_risk_id": { "const": "AST06" }
      }
    }
  }
}

# AST06 -- Restrict protocol transitions to authorized parties
resolver:
  config:
    protocol_switching:
      require_approval: true                  # AST06: no silent protocol changes
      deny_by_default: true                   # unlisted transitions are blocked
      allowed_transitions:
        - from: pessimistic-locking
          to: optimistic-concurrency
          approval_level: admin               # AST06: elevated approval required
        - from: optimistic-concurrency
          to: pessimistic-locking
          approval_level: coordinator         # downgrade is less risky
        - from: pessimistic-locking
          to: hybrid
          approval_level: coordinator
      audit:
        log_all_switch_requests: true
        log_denied_switches: true
        alert_on_unapproved_attempt: true

MCP tool for authorized protocol switch:

cortivex_coordination_configure({
  action: "set_protocol",
  run_id: "ctx-d4e5f6",
  protocol: "optimistic-concurrency",
  approval_token: "apr-admin-7c3e",
  reason: "Switching to optimistic for read-heavy phase of migration"
})

Conflict Resolution Audit Trail

Every conflict resolution decision must produce an immutable audit record. The audit trail captures who was involved, what strategy was applied, the outcome, and a timestamp, enabling post-incident forensic analysis (AST06).

{
  "$schema": "https://cortivex.io/schemas/conflict-audit-record.json",
  "type": "object",
  "properties": {
    "record_id": { "type": "string", "pattern": "^aud-[a-f0-9]{8}$" },
    "conflict_id": { "type": "string" },
    "timestamp": { "type": "string", "format": "date-time" },
    "agents_involved": { "type": "array", "items": { "type": "string" } },
    "contested_file": { "type": "string" },
    "strategy_applied": { "enum": ["priority", "first-claim", "preempt", "partition", "serialize"] },
    "winner": { "type": "string" },
    "loser_action": { "enum": ["requeued", "reassigned", "waited", "halted"] },
    "approval_token": { "type": ["string", "null"] },
    "force_release": { "type": "boolean" },
    "integrity_verified": { "type": "boolean" },
    "ast_risk_id": { "const": "AST06" }
  },
  "required": ["record_id", "conflict_id", "timestamp", "agents_involved", "contested_file", "strategy_applied", "ast_risk_id"]
}

# AST06 -- Immutable audit trail for all conflict resolutions
resolver:
  config:
    audit_trail:
      enabled: true                           # AST06: mandatory in production
      storage: .cortivex/mesh/audit/
      format: jsonl                           # append-only JSON lines
      include_fields:
        - conflict_id
        - timestamp
        - agents_involved
        - contested_file
        - strategy_applied
        - winner
        - approval_token
        - force_release
        - integrity_verified
      retention_days: 90
      immutable: true                         # AST06: no modification or deletion
      sign_records: true                      # ed25519 signature on each record
      signature_key_path: /etc/cortivex/keys/audit.key

Query the audit trail through the MCP tool:

cortivex_mesh_resolver({
  action: "audit_query",
  run_id: "ctx-d4e5f6",
  filters: {
    "force_release": true,
    "time_range": { "from": "2025-01-15T00:00:00Z", "to": "2025-01-16T00:00:00Z" }
  }
})