CLI: Conflict Detection

Detect and resolve contradictory information across memories with the Trix CLI.

Updated Oct 6, 2026

Overview

The conflict detection system automatically identifies contradictory information across your memories. It uses multiple detection strategies to find semantic conflicts, entity attribute conflicts, and temporal conflicts, helping you maintain data consistency.

Command aliases: conflict

Conflict Types

Trix detects several types of conflicts:

Type	Description	Example
`ownership`	Same entity with different owners/values	"Marcus owns Payment Service" vs "Elena owns Payment Service"
`date`	Same event with different dates	"Meeting on Jan 15" vs "Meeting on Jan 20"
`value`	Same attribute with different values	"API uses port 8080" vs "API uses port 3000"
`semantic`	Contradicting statements detected by AI	"Feature X is deprecated" vs "Feature X is recommended"

Listing Conflicts

# List all pending conflicts
trix conflicts list

# Filter by type
trix conflicts list --type ownership
trix conflicts list --type date,value

# Filter by confidence
trix conflicts list --min-confidence 0.7

# Limit results
trix conflicts list --limit 10

# JSON output for scripting
trix conflicts list -o json

Example output:

Found 3 potential conflict(s):

1. OWNERSHIP CONFLICT (high confidence: 0.92)
   Memory A: mem_abc123... - "Marcus owns Payment Service"
   Memory B: mem_def456... - "Elena owns Payment Service"
   Suggestion: Review and update or mark one as superseded

2. DATE CONFLICT (medium confidence: 0.75)
   Memory A: mem_ghi789... - "Meeting on Jan 15"
   Memory B: mem_jkl012... - "Meeting rescheduled to Jan 20"
   Suggestion: These may both be correct (rescheduled)

3. SEMANTIC CONFLICT (high confidence: 0.88)
   Memory A: mem_mno345... - "Use PostgreSQL for all new services"
   Memory B: mem_pqr678... - "MongoDB is the recommended database"
   Suggestion: Clarify which recommendation is current

Scanning for Conflicts

Trigger a conflict detection scan to find new conflicts across your memories:

# Scan all memories for conflicts
trix conflicts scan

# Scan a specific space
trix conflicts scan --space work

# Narrow the scan by tags
trix conflicts scan --tags deployment,api

# Adjust the similarity threshold (default 0.85)
trix conflicts scan --threshold 0.9

# Increase timeout for large accounts (default 300s)
trix conflicts scan --timeout 600

Conflict scanning runs in the background. Use trix conflicts list to see newly detected conflicts after scanning completes.

Reviewing Conflicts

Get detailed information about a specific conflict:

# Review a conflict
trix conflicts review <conflict-id>

# JSON output
trix conflicts review <conflict-id> -o json

Example detailed output:

Conflict: conf_abc123
Type: OWNERSHIP
Confidence: 0.92
Detected: 2 hours ago

Memory A (mem_abc123):
  Created: Jan 10, 2026
  Content: "Marcus Chen is the owner of the Payment Service.
           He handles all billing-related decisions."
  Tags: team, ownership

Memory B (mem_def456):
  Created: Jan 12, 2026
  Content: "Elena Rodriguez now owns the Payment Service
           after the team restructuring."
  Tags: team, ownership, restructuring

Suggestion: Memory B appears more recent and mentions a restructuring.
            Consider superseding Memory A with Memory B.

Actions:
  trix conflicts resolve <conflict-id> --keep <uuid-keep> --supersede <uuid-super>
  trix conflicts resolve <conflict-id> --merge "..."
  trix conflicts dismiss <conflict-id>

Resolving Conflicts

Keep Strategy

Mark one memory as authoritative and supersede the other:

# Keep one memory, supersede the other
trix conflicts resolve <conflict-id> --keep <memory-uuid-1> --supersede <memory-uuid-2>

Merge Strategy

Combine both memories into a new, corrected memory:

# Merge into a new memory
trix conflicts resolve <conflict-id> --merge "Elena Rodriguez is the current owner
of the Payment Service (as of Jan 2026 restructuring).
Previously owned by Marcus Chen."

The merge strategy creates a new memory that supersedes both conflicting memories, preserving the relationship history in the knowledge graph.

Dismissing Conflicts

If a detected conflict is actually valid (both statements are correct), dismiss it:

# Dismiss a conflict
trix conflicts dismiss <conflict-id>

# Dismiss multiple
trix conflicts dismiss <conflict-id-1> <conflict-id-2>

Dismissed conflicts won't appear in future scans for the same memory pairs. This is useful when memories describe different contexts or time periods.

Command Reference

Command	Description
`conflicts list`	List pending conflicts with optional filters
`conflicts scan`	Trigger conflict detection scan
`conflicts review <id>`	Show detailed conflict information
`conflicts resolve <id>`	Resolve a conflict (keep or merge)
`conflicts dismiss <id>`	Dismiss a false positive conflict

List Options

Option	Description
`--type`	Filter by conflict type (ownership, date, value, semantic)
`--min-confidence`	Minimum confidence score (0.0-1.0)
`--limit`	Maximum number of results
`-o, --output`	Output format (table, json)

Resolve Options

Option	Description
`--keep`	Memory ID to keep as authoritative
`--supersede`	Memory ID to mark as superseded
`--merge`	Content for new merged memory

Best Practices

Regular scans: Run trix conflicts scan periodically to catch new conflicts as your memory base grows.
Review before resolving: Use --full to see complete memory content before deciding how to resolve.
Add context: Use --note when resolving to explain your decision for future reference.
Merge for history: When both memories contain valuable information, use merge to preserve context.
Dismiss appropriately: If conflicts represent valid different contexts (e.g., different time periods), dismiss rather than resolve.

Next Steps

Memory Commands - Core memory operations
Graph Export - Visualize memory relationships
Relationships - Understanding the knowledge graph