Context Resolution
Entity resolution, conflict handling, and canonical context
Part V: Context Resolution
The same thing exists in multiple systems, with different names, at different levels of fidelity. This is not an edge case. It is the default state of most organizations.
A customer called "Acme" in Salesforce might be "Acme Corp" in Jira and "Acme Corporation" in Notion. An initiative called "Platform Modernization" in the operating context system might be called "Tech Debt Reduction" in the engineering team's Linear board and "Infrastructure Investment" in the finance system. These may or may not refer to the same thing.
An Operating Context System needs an explicit approach to two problems:
Entity resolution: determining when two things in different systems are actually the same thing.
Conflict handling: determining what to do when two systems disagree about the state of something.
The key distinction is between canonical context (the authoritative source of record for a given piece of information) and derived context (context assembled from underlying signals). When a conflict exists between what the operating context says and what an underlying system shows, the system needs a defined policy for resolution, not an implicit assumption that one source is always right.
Context agents that gather information from multiple systems are only as trustworthy as their resolution logic. Merging, not just collecting, is the essential capability.