ameau01/synthetic-it-support-tickets

Synthetic IT Support Tickets — PII-Enriched + Redaction Ground Truth

745 synthetic IT service-management incident records for LLM wiki and retrieval-augmented-generation experiments. Each record is a help-desk/IT-ops incident with submitted ticket text, timestamped troubleshooting correspondence, structured diagnostics, root cause, and resolution steps.

The free text is enriched with realistic technical detail and injected synthetic PII. The corpus ships two authored ground-truth sidecars that together make it a two-sided redaction benchmark:

• —`pii.json` — the REMOVE answer key: every injected PII value that a redaction pipeline must strip. Scores leakage (a sidecar value survived redaction).
• —`retention.json` — the KEEP answer key: the technical strings a redaction pipeline must preserve. Scores over-redaction (a retained term was destroyed).

The corpus also ships `users_directory.json` — the corporate user directory for this synthesized environment (769 records): usernames, display names, and email addresses.

A redactor is only correct if it removes everything in pii.json and keeps everything in retention.json. Both keys are authored against the raw text, independently of any detector, so a detector-based redaction eval stays non-circular. All PII is synthetic — no real personal data.

Changelog

Revision 4 (2026-06-15) — user directory

• —Added `users_directory.json` — the corporate user directory for this synthesized environment (769 records): username, display name, and email address for every provisioned account. All records are synthetic; no real personal data.

Revision 3 (2026-06-11) — retention ground truth

• —Added `retention.json` — the RETAIN-class answer key (8,581 entries across all 745 tickets): the technical strings a redaction pipeline must preserve. Together with pii.json this completes the two-sided redaction benchmark: leakage (sidecar values must vanish) and over-redaction (retention values must survive).
• —Corpus (data/train.parquet) and pii.json are byte-identical to revision 2.

Revision 2 (2026-06-09) — PII enrichment + redaction ground truth

• —Injected synthetic PII into the enrichable free-text fields: person names, usernames, emails, phones, employee IDs, office locations, client IPs, and personal-device hostnames — woven in naturally, ~12 PII values per ticket on average (8,839 total).
• —Added `pii.json` — an authored, value-keyed ground-truth sidecar: one entry per unique PII value, with its type, tier, redaction token, and every location it occurs in the ticket. Built for a deterministic redaction-leakage / technical-retention benchmark.
• —Structure & metadata preserved byte-for-byte vs. revision 1: record_id, counts, timestamps, root_cause, observed_errors, applications, and the 3-step diagnostic spine are unchanged. Record count stays 745 — no tickets added, dropped, or split.
• —Source coherence fix: corrected a systematic future-dated-timestamp artifact in 58 source tickets (mostly the certificate-expiry family) so every ticket is temporally consistent.
• —PII was authored at generation time, not detected — the sidecar is the authoritative key, which keeps any downstream detector-based redaction eval non-circular.

Contents

• —data/train.parquet — the 745 PII-enriched incident records (the viewable split).
• —pii.json — authored PII ground-truth sidecar, the REMOVE key (one record per ticket, keyed by ticket_id).
• —retention.json — RETAIN-class ground truth, the KEEP key (one record per ticket; see section below).
• —users_directory.json — the corporate user directory for this synthesized environment (769 records).

The PII sidecar (pii.json)

One record per ticket; value-keyed (one entry per unique PII value). The leakage eval is absence-anywhere: each value must be gone from the entire redacted ticket and replaced by its expected_after_redaction token. occurrences lists every field where the value appears (for per-field auditing) and is computed exhaustively so coverage never under-counts.

{
  "ticket_id": "INC-VDA-0028",
  "pii_instances": [
    {
      "id": "INC-VDA-0028:pii:001",
      "value": "Elena Vasquez",
      "type": "person",
      "tier": "personal",
      "origin": "injected",
      "policy": "token_replace",
      "expected_after_redaction": "<PERSON>",
      "occurrences": ["ticket.submitted_description", "diagnostics.summary", "resolution.steps[3]"]
    }
  ]
}

Redaction tokens: <PERSON>, <USER>, <EMAIL>, <PHONE>, <EMP_ID>, <LOCATION>, <IP>, <HOSTNAME>. System/app names, service hostnames/URLs, error codes, cert serials, OS/device class, and region codes are deliberately retained (they are the knowledge base's value) and never appear in the sidecar. The strings that must be retained are enumerated in retention.json.

The retention sidecar (retention.json)

The other half of the redaction benchmark: the RETAIN-class ground truth — the technical strings in each ticket's free text that a redaction pipeline must NOT destroy (system/app names, vendor names, service hostnames/URLs, error/event codes, cert serials, regions, OS/device classes). 745/745 tickets, 8,581 entries.

{
  "ticket_id": "INC-AIT-0009",
  "retain_instances": [
    { "id": "INC-AIT-0009:retain:001", "value": "0xC0000234", "type": "error_code",
      "occurrences": ["diagnostics.summary", "resolution.steps[0]"],
      "rationale": "NTSTATUS error code for account locked out." }
  ]
}

Scope: only free-text occurrences are listed (a value tied solely to a structured/spine field is not a redaction risk and is excluded). The two keys are disjoint: no value appears in both pii.json and retention.json for the same ticket.

Construction: LLM extraction under a written classification policy, independently audited per ticket by a second model, completeness-checked against a generic PII detector (which suggests spans but never authors entries), with every disputed span adjudicated by the dataset owner (rationales recorded per entry). Scoring is the mirror of leakage: each value must remain present after redaction.

The user directory (users_directory.json)

The corporate user directory for this synthesized environment — every provisioned account with its username, display name, and email address. 769 records; all data is synthetic and no real personal data is included.

{
  "metadata": { "total_records": 769 },
  "users": [
    { "username": "areeves",   "display_name": "Anita Reeves",  "email": "areeves@corplabs.com" },
    { "username": "a.hussain", "display_name": "Amir Hussain",  "email": "a.hussain@corplabs.com" }
  ]
}

Loading:

import json

with open("users_directory.json") as f:
    directory = json.load(f)

users = directory["users"]   # list of {username, display_name, email}

Schema Overview

Key fields: record_id, record_type, ticket, status, correspondence, diagnostics, root_cause, resolution. The public export excludes generation hints, seed issue families, relationship/wiki hints, and source lineage metadata.

<details> <summary>Sample record (click to expand)</summary>

{
  "record_id": "INC-VDA-0028",
  "record_type": "incident",
  "ticket": {
    "submitted_at": "2026-04-23T...",
    "submitted_title": "VPN disconnects after Okta MFA approval",
    "submitted_description": "Remote users on managed Windows 10 devices in the Frankfurt office were trying to connect to the corporate GlobalProtect VPN (gateway vpn-emea.corplabs.net) ... reported by Elena Vasquez (emp ID EMP-40821) ...",
    "priority": "high",
    "applications": ["GlobalProtect", "Okta"]
  },
  "status": "closed",
  "correspondence": [ "..." ],
  "diagnostics": { "coverage": "standard", "summary": "...", "observed_errors": ["..."], "steps": ["..."] },
  "root_cause": "...",
  "resolution": { "steps": ["..."] }
}

The sample shows raw text as shipped: PII is present and unredacted, because the corpus is the input to a redaction benchmark. The sidecars are the answer keys for what to remove and keep.

</details>

Scope

Synthetic incident source records, two authored redaction sidecars (pii.json, retention.json), and a user directory (users_directory.json). Does not include generated wiki pages, embeddings, RAG indexes, application code, or any real customer/personal data.

Intended use

• —LLM wiki / RAG experiments over realistic ITSM text.
• —A two-sided PII-redaction benchmark: run your redaction pipeline over data/train.parquet, then score against pii.json (leakage = a sidecar value survived) and retention.json (over-redaction = a retained technical term was removed). A correct redactor satisfies both.

License

MIT. See LICENSE.

Citation

@misc{synthetic_it_support_tickets_2026,
  title   = {Synthetic IT Support Tickets (PII-Enriched + Redaction Ground Truth)},
  author  = {Alexander Meau},
  year    = {2026},
  version = {3.0.0},
  howpublished = {\url{https://huggingface.co/datasets/ameau01/synthetic-it-support-tickets}}
}