Two exports contain the same signal ID but disagree about severity. Picking whichever row arrived last makes the conflict disappear from the file, while leaving the underlying disagreement unresolved. A review-oriented merge should retain that disagreement, identify which fields differ, and let a person decide what to do next. This is useful when two collection or enrichment steps contribute to the same investigation.
I maintain the us-brand-signal-merge-report Actor. This walkthrough describes its published build 0.2.2, inspected on 16 October 2026. The example below is synthetic and reviewed against that contract; it was not executed for this article. AI-assisted drafting was followed by a separate factual and editorial review.
The Merge Report pairs rows by exact supplied signalId. It does not infer that two different identifiers refer to one event. Both left and right must contain 1–50 rows; neither side may be empty. Duplicate IDs within a single side are rejected. This complete synthetic example uses the same ID across sides and changes severity from low to high while leaving the other fields identical.
{
"schemaVersion": "1.1",
"left": [
{
"signalId": "sig-1",
"brandName": "Example Brand",
"eventType": "price_change",
"severity": "low",
"status": "active",
"observedAt": "2026-10-01T08:00:00Z",
"sourceUrl": "https://example.com/e1"
}
],
"right": [
{
"signalId": "sig-1",
"brandName": "Example Brand",
"eventType": "price_change",
"severity": "high",
"status": "active",
"observedAt": "2026-10-01T08:00:00Z",
"sourceUrl": "https://example.com/e1"
}
]
}
For that pair, inspect conflicts[].left, conflicts[].right, and differingFields. The report keeps both submitted variants. It does not choose an authoritative source, compute a compromise severity, or decide that the later observation should win. A separate review decision should explain any eventual replacement.
The report also exposes left-only rows, right-only rows, exact duplicates, and the merged/union representations. Read those names with care: presence on both sides does not necessarily mean a conflict has been resolved. Exact duplicate means the normalized values agree under the contract. Same ID with differing values belongs to a different review case, even when both rows point to the same URL.
Rows contain a closed set of seven fields: identifier, brand, event type, severity, status, observation time, and source URL. Event, severity, and status values come from allowed enums. Timestamps use real UTC seconds; URLs have a restricted HTTPS shape. These checks validate the packet's structure and do not fetch its references. A valid source URL is not proof that either variant is correct.
Each side and the union are sorted by signal ID, with canonical object-key ordering for digests. Preserve the left and right labels when archiving the result: their roles remain meaningful even when the output is deterministically sorted. The input cap is 64 KiB, and the report must remain below 60 KiB. Oversize packets fail rather than silently dropping a conflicting row.
Give a reviewer the conflict fields, both original exports, and the relevant source evidence. Let their decision record name the signal ID and explain why a particular value was accepted, deferred, or rejected. If you need an operational feed afterward, derive it from those explicit decisions rather than pretending the comparison itself resolved source quality.
A second useful check is to distinguish identity errors from attribute conflicts. If two systems assign unrelated IDs to the same event, this merge will retain them as separate records. Fixing that requires an upstream identity policy with its own evidence. Conversely, collapsing different real events under one reused ID will manufacture a conflict. Deterministic merging is most useful when identifier ownership is already clear and its limitations travel with the report.
On the observed FREE pricing tier, one result-found event costs $0.01 for the complete useful report or plan, rather than each input row. FREE is the tier name, not a promise of free execution. Automatic Actor-start pricing is also present at $0.005 per GB, with a minimum of one event. Check the Actor page and your account tier before running; this is not a fixed total invoice, and a failed or repeated run may still incur applicable charges.
To try this deliberately, open the Actor page, select build 0.2.2, and submit the JSON as input. Set an explicit spending ceiling appropriate to your account; for example, $0.05 is a ceiling, not a quoted run price or a guarantee of a delivered report. Save the returned run ID and verify its immutable build ID. A local timeout does not cancel the remote run: inspect that same run before considering another attempt. Read the completed run's Dataset report and its separate OUTPUT receipt together; structural output is not independent source verification.
Top comments (0)