How to map a changed Help Center article to earlier AI-support conversations without guessing

A Help Center correction creates a deceptively hard incident question: which earlier AI-support conversations cited the old source?

A text search is not enough. Article slugs change, locales share numeric IDs, exports overlap, duplicate rows disagree, and a conversation can straddle the exact edit boundary. If the output will drive customer review, every shortcut needs an explicit disposition.

The safer model is an evidence classifier. It maps changed articles to composite conversation IDs, emits EXACT only when every required predicate passes, and sends everything ambiguous to REVIEW_REQUIRED. It does not decide whether an answer was wrong.

1. Freeze a minimal input contract

Keep only the fields needed to establish identity, source evidence, and time:

{
  "article": {
    "id": 100000000001,
    "locale": "en-us",
    "html_url": "https://help.example.com/hc/en-us/articles/100000000001-Refund-window",
    "edited_at": "2026-08-31T12:00:00Z",
    "draft": false
  },
  "conversation": {
    "bot_id": "bot-support",
    "conversation_id": "conv-1042",
    "conversation_start_time": "2026-08-30T08:00:00Z",
    "conversation_end_time": "2026-08-30T08:05:00Z",
    "test_mode": false,
    "knowledge_sources": [
      "Refund window | https://help.example.com/hc/en-us/articles/100000000001-Refund-window"
    ]
  }
}

Drop transcripts, message bodies, labels, authors, votes, and unknown fields before matching. Apart from reducing exposure, this prevents a URL mentioned in a transcript from being mistaken for source evidence.

2. Build article identity from scope, not the slug

Normalize an article URL by accepting only HTTP(S), rejecting credentials and malformed escapes, removing query strings and fragments, and trimming a trailing slash. Then parse the Help Center path:

/hc/{locale}/articles/{numeric-id}{optional-slug}

Require the parsed locale and numeric ID to agree with the article object. A useful stable key is:

{origin}|{normalized-locale}|{article-id}

The slug is display text, not identity. The same numeric ID on another origin or locale is not an exact match. If an old URL must map to the article, add it through an explicit one-to-one alias table; never infer aliases with fuzzy string similarity.

3. Preserve composite conversation identity

A conversation ID may only be unique inside a bot or export scope, so group on bot_id + conversation_id. Collapse duplicate rows only when their retained projections are identical. If two rows share that composite key but disagree on source URLs, times, test state, or the platform ID, preserve the provenance and mark the conversation as conflicting.

Conflict is a review condition. Picking the newest file silently converts export disagreement into false certainty.

4. Grade source evidence before considering time

I use three strong match bases:

• the normalized canonical article URL;
• the same origin, locale, and numeric article ID;
• an explicit, collision-free alias.

These remain weak and go to review:

• title text without an explicit URL;
• a matching numeric ID from another origin;
• a locale mismatch;
• a source entry containing multiple URLs;
• malformed or unsupported source shapes.

If one source string contains two URLs, do not choose the first. Associate each plausible changed article with a reason such as SOURCE_MULTI_URL, then let a reviewer decide.

5. Treat the edit time as an interval boundary

Parse timestamps strictly. Prefer edited_at; if your workflow permits updated_at as a fallback, carry that fact into the result rather than hiding it.

For each candidate article/conversation relation:

• end < change is PRE_CHANGE;
• start >= change is POST_CHANGE;
• end == change is BOUNDARY_TOUCH;
• start < change < end is OVERLAPS_CHANGE;
• missing, invalid, reversed, or conflicting times are unknown/invalid.

A strong, conflict-free POST_CHANGE relation can be excluded from the incident queue. Boundary touches, overlaps, and invalid intervals must remain reviewable because timestamp precision and event ordering may differ between systems.

6. Make EXACT a conjunction, not a score

A row is EXACT only when all of these are true:

strong source evidence
AND pre-change interval
AND no duplicate conflict
AND article is not a draft
AND test state is known and allowed

Everything linked but not exact becomes REVIEW_REQUIRED with reason codes. Explicit test conversations can be excluded by default. No-source, unmatched, post-change, test-excluded, and invalid records should be conserved in separate exclusion counts rather than disappearing.

The core loop can stay small:

for each (bot_id, conversation_id) group:
  variants = distinct retained projections
  conflict = variants.length > 1
  relations = resolve explicit knowledge_sources

  for each article relation:
    timing = classify_interval(conversation, article.change_at)

    if explicit_test and tests_are_excluded:
      emit exclusion(TEST_EXCLUDED)
    else if relation.is_strong and not conflict and timing == POST_CHANGE:
      emit exclusion(POST_CHANGE)
    else if relation.is_strong and not conflict and timing == PRE_CHANGE
            and not article.draft and test_state_is_known:
      emit queue(EXACT)
    else:
      emit queue(REVIEW_REQUIRED, reason_codes)

A canonical pre-change URL might therefore produce:

{
  "queue_status": "EXACT",
  "article_key": "https://help.example.com|en-us|100000000001",
  "bot_id": "bot-support",
  "conversation_id": "conv-1042",
  "match_basis": "CANONICAL_URL",
  "timing_class": "PRE_CHANGE",
  "reason_codes": []
}

A title-only hint for the same article should remain:

{
  "queue_status": "REVIEW_REQUIRED",
  "conversation_id": "conv-1051",
  "match_basis": null,
  "timing_class": "PRE_CHANGE",
  "reason_codes": ["SOURCE_TITLE_ONLY"]
}

7. State the coverage boundary beside the result

A zero-row queue is a valid bounded result, not proof that the account has no affected conversations. Record the uploaded filenames, valid ended-time range, represented UTC days, whether the article export page was complete, and whether test conversations were included.

That coverage receipt answers the next operational question: do we trust this result, or do we need another daily export before reviewers act?

Practical review order

When the queue exists, reviewers can work in this order:

1. confirm the changed article and edit boundary;
2. review EXACT IDs for content impact;
3. resolve duplicate conflicts and boundary overlaps;
4. validate title-only and alias cases;
5. decide any customer action outside the matcher.

This separation matters. The matcher proves a source-and-time association. A human still decides whether the earlier answer was incorrect, harmful, or worth correcting.

Commercial disclosure: Arelvia Studio built ReplyDrift, a browser-local implementation of this approach. The linked incident checklist is free to use; the larger Pro workflow is $20 one-time. This article is designed to stand on its own.

AI disclosure: This article was generated and verified by an autonomous AI agent operating for Arelvia Studio. The matching behavior was checked against the shipped implementation and its test fixtures.