{
  "title": "Wired telecom service incident data for AI dispatch review",
  "source_page": "https://fiund.com/industries/wired-telecom-dispatch-data",
  "authorship": "Original fictional Fiund editorial exercise. No actual operating records or third-party source assets are included.",
  "example": {
    "title": "Several complaints need a shared-incident link before they are merged",
    "context": "An isolated dispatch tabletop uses generic service areas, delayed observations and a fictional escalation rubric. It contains no subscriber, topology, network control or restoration task.",
    "records": [
      [
        "WD1",
        "09:00 ticket snapshot",
        "Tickets T1 and T2 from practice area A report unavailable service. T3 from area B reports a different symptom. No shared incident confirmed."
      ],
      [
        "WD2",
        "09:05 received observation",
        "Operator's synthetic observation made at 08:58 links T1 and T2 to incident I-A. It explicitly excludes T3; earlier maintenance notice concerns B on another day."
      ],
      [
        "WD3",
        "Practice routing rule",
        "Before operator linkage, keep tickets separate and request review. After verified linkage, group only the named tickets and notify the incident lead."
      ]
    ],
    "question": "What grouping is supported at the 09:00 information cutoff versus after the 09:05 receipt, and does the maintenance notice justify adding T3?",
    "answer": "At the 09:00 receipt cutoff, WD1 lacks a verified shared-incident link, so WD3 calls for separate tickets and review. Once WD2 arrives at 09:05, it supports grouping T1 and T2 under I-A and the stated lead notification. Its earlier observation time does not make it available at 09:00. T3 is explicitly excluded, and an unrelated-day maintenance notice supplies no contrary link.",
    "failureModes": [
      "Using a delayed observation before its receipt-time information cutoff.",
      "Merging all nearby complaints or applying a maintenance notice from another day."
    ],
    "fields": [
      [
        "Ticket, area and symptom",
        "Preserves the scope of each report."
      ],
      [
        "Observation time and receipt time",
        "Separates when a fact occurred from when dispatch could know it."
      ],
      [
        "Verified incident membership",
        "Defines the precise grouping."
      ],
      [
        "Routing-rule version",
        "Limits the assistant to documented escalation."
      ]
    ],
    "holdout": "Use several same-time area-A tickets that an operator explicitly links to two independent incidents. Test whether the model follows membership evidence rather than arrival clustering.",
    "boundary": "Use fabricated timelines only. Exclude addresses, subscribers, network diagrams, credentials, infrastructure locations and detailed real incidents."
  }
}