A comparison takes two schemas, diffs them field by field, and produces a structured report. Comparisons can be run manually in the Comparator or triggered automatically via monitors and cloud connections.
Running a comparison
Manual comparison:
- Go to Comparator in the sidebar.
- Upload or paste the baseline (left side). Or select an existing contract.
- Upload or paste the incoming file (right side).
- Click Compare.
If you select a contract as the baseline, the comparison is linked to that contract. Linked comparisons with detected differences create a drift event automatically.
Automated comparison:
Files sent to a monitor webhook or picked up by a cloud connection are compared automatically. You do not need to use the Comparator.
Diff output
The comparison result contains four change categories. Each item includes the field path (dot-notation for nested fields), the old value or type, and the new value or type.
Fields present in the incoming file that were not in the baseline. Additions are generally safe unless they indicate a structural change the downstream system cannot handle.
Fields present in the baseline that are missing from the incoming file. Removals are breaking changes. Any system expecting those fields will fail.
Fields present in both but with a different type, structure, or constraint. Type changes (e.g. string to integer) are treated as breaking.
Fields DriftOps infers were renamed based on similarity scoring. See Rename detection.
Severity levels
Severity is calculated automatically from the diff categories.
Only additions. No removals, changes, or type changes.
Most common when trading partners add optional fields.
Renames or value changes present. No removals or type changes.
Likely still functional, but should be reviewed.
Any removals or type changes present.
Breaking. Will likely cause downstream failures.
Rename detection
DriftOps runs a fuzzy matching pass after the initial diff to identify fields that were likely renamed rather than removed and re-added.
The matcher compares removed fields against added fields using multiple signals: name similarity, value type, structural position, and field length patterns.
When a rename is detected:
- The field appears in the
renamedcategory instead ofremovedandadded - The rename count increments (separate from the removal count)
- Severity does not escalate to
majorfor renames alone
Rename detection is not guaranteed. Low-confidence matches are not reported to avoid false positives.
EDI comparisons
EDI X12 files are parsed at the segment and element level before comparison.
The parser converts EDI segments (e.g. ISA, GS, ST, BEG, N1) into a JSON-comparable key-value structure. Field-level comparison then works the same as for JSON.
EDI element definitions (segment ID, element position, data type, description) are available in the diff report to give context to each changed field.
Supported transaction sets include the 850 (Purchase Order), 856 (ASN), 810 (Invoice), and others in the X12 standard library.
Usage limits
Each comparison counts against your monthly comparison limit.
| Tier | Monthly comparisons |
|---|---|
| Free | 100 |
| Starter | 10,000 |
| Team | 30,000 |
| Pro | 150,000 |
When the limit is reached, new comparisons are blocked until the next billing cycle. Limits reset at the start of each calendar month.