{
  "title": "Managed IT service desk records for AI ticket escalation",
  "source_page": "https://fiund.com/industries/managed-it-service-desk-data",
  "authorship": "Original fictional Fiund editorial exercise. No actual operating records or third-party source assets are included.",
  "example": {
    "title": "Identical symptoms can require different customer-authorized escalations",
    "context": "A detached service-desk exercise uses two fictional clients and original runbook excerpts. It contains no real ticket, hostname, credential, network or exploitable technical detail.",
    "records": [
      [
        "MSD1",
        "Client A practice policy",
        "For symptom unavailable application, provider may notify internal role Lead-A after a dummy status check."
      ],
      [
        "MSD2",
        "Client B practice policy",
        "Same symptom requires B's administrator confirmation before provider escalation; no confirmation in packet."
      ],
      [
        "MSD3",
        "Ticket evidence",
        "A1 and B1 each report the symptom; fabricated check results attached to their own IDs. No policy grants system changes or access expansion."
      ]
    ],
    "question": "Which escalation is authorized for each ticket, and does completing the same check permit the provider to use A's route for B?",
    "answer": "MSD1 authorizes A1's stated Lead-A notification after its check. MSD2 leaves B1 waiting for B administrator confirmation, which MSD3 does not supply. A matching symptom and completed check do not transfer authority across clients. Report the authorized A route and missing B approval separately, without treating either runbook as permission to modify systems, obtain credentials or expand access.",
    "failureModes": [
      "Copying one customer's escalation authority into another customer's ticket.",
      "Treating a status check as the missing administrator approval or permission for system changes."
    ],
    "fields": [
      [
        "Client, ticket and policy version",
        "Defines the authority boundary."
      ],
      [
        "Required check and evidence link",
        "Shows which prerequisites are present."
      ],
      [
        "Authorized role and missing confirmation",
        "Makes the routing difference explicit."
      ]
    ],
    "holdout": "Use a third original client policy requiring a different reviewer. Test policy retrieval rather than memorizing one escalation from the symptom.",
    "boundary": "Use fictional tickets and owned excerpts only. Exclude customer data, credentials, hostnames, topology and security incidents."
  }
}