data/corpus_pack_enterprise_v2.jsonl

{"chunk_id":"support_001","domain":"Customer Support Operations","text":"A revenue assurance note says support agents should not promise a refund until they compare the customer report against service telemetry, invoice history, and the commercial terms on the account. The note also says that setup fees and one time onboarding charges are usually excluded unless billing explicitly confirms an exception. When those checks are incomplete, the case should be routed to billing review rather than being settled in conversation. Finance teams use the note to prevent inconsistent credits.","tokens":125,"keywords":["service telemetry","invoice history","commercial terms","billing review","inconsistent credits"],"relevance_tags":["support_triage","billing","refunds","auditability","case_routing"]}
{"chunk_id":"support_002","domain":"Customer Support Operations","text":"A help content operations guide recommends sending a short article bundle before escalating low risk contacts. It focuses on account settings, password recovery, and workspace navigation. The guide is useful for lowering repeat tickets but it does not define refund thresholds or financial remediation. It remains a distractor for compensation tasks because it emphasizes self service over policy-driven case handling.","tokens":115,"keywords":["help content","password recovery","workspace navigation","repeat tickets","self service"],"relevance_tags":["support_efficiency","distractor","self_service","knowledge_base","training"]}
{"chunk_id":"support_003","domain":"Customer Support Operations","text":"A compensation approval standard says subscription refunds require three proof points: an incident record showing service disruption, a billing ledger entry matching the affected charge, and a classification that distinguishes contractual refund from goodwill relief. Agents must log the cause category and mark exceptions for finance audit. The standard exists so outage reimbursements are evidence based and consistent across teams.","tokens":128,"keywords":["compensation approval","incident record","billing ledger","goodwill relief","finance audit"],"relevance_tags":["support_triage","refunds","billing","outage_relief","policy_compliance"]}
{"chunk_id":"support_004","domain":"Customer Support Operations","text":"An outage case handling guide tells agents to attach the incident number to each impacted ticket, send the approved status page link, and avoid estimating recovery times unless command has confirmed them. The guide also requires agents to capture customer impact in a common template so incident command can see patterns instead of ad hoc narratives. That same impact record later informs relief decisions and post-incident analysis.","tokens":126,"keywords":["incident number","status page link","approved updates","impact template","post incident analysis"],"relevance_tags":["support_triage","incident_coordination","status_updates","customer_comms","evidence_collection"]}
{"chunk_id":"support_005","domain":"Customer Support Operations","text":"A customer relief matrix defines when teams should issue a direct refund, when they should use a goodwill credit, and when no compensation is allowed because the reported issue falls outside documented entitlement. It also says repeated manual exceptions need finance approval. The matrix is a primary artifact for keeping remediation decisions consistent after platform incidents.","tokens":120,"keywords":["customer relief matrix","direct refund","goodwill credit","documented entitlement","finance approval"],"relevance_tags":["support_triage","refunds","goodwill","policy_compliance","finance_review"]}
{"chunk_id":"support_006","domain":"Customer Support Operations","text":"A compromised account support procedure says agents should freeze sensitive self service actions, verify the requester through a secondary method, and preserve recent account events before offering remediation details. If the threat is still active, the case must be escalated to security operations with any indication of customer harm. The procedure matters because it makes support part of the evidence chain instead of a disconnected queue.","tokens":127,"keywords":["compromised account","freeze self service","secondary verification","security escalation","evidence chain"],"relevance_tags":["support_triage","security_incident","customer_protection","escalation","identity_verification"]}
{"chunk_id":"incident_001","domain":"Incident Response Playbooks","text":"An operational severity standard explains that a customer issue becomes a formal incident when impact spreads broadly, multiple teams must coordinate restoration, or risk grows faster than normal support channels can manage. The standard is useful for declaration decisions, though it is not itself a refund or remediation policy.","tokens":105,"keywords":["operational severity","formal incident","broad impact","coordination","declaration"],"relevance_tags":["incident_response","severity","coordination","major_incident","classification"]}
{"chunk_id":"incident_002","domain":"Incident Response Playbooks","text":"An incident leadership playbook says the commander should maintain one verified timeline, separate customer impact from engineering guesses, and publish only confirmed updates to customer-facing teams. It warns that support noise increases when speculative mitigation details are repeated as promises. The playbook is central to cross-functional response because it improves both internal coordination and external trust.","tokens":127,"keywords":["verified timeline","customer impact","confirmed updates","support noise","external trust"],"relevance_tags":["incident_response","incident_command","customer_comms","status_updates","coordination"]}
{"chunk_id":"incident_003","domain":"Incident Response Playbooks","text":"A privileged access breach playbook says responders should revoke live sessions, rotate sensitive credentials, preserve auth and audit evidence, and isolate any automation that could continue causing damage. It stresses that investigators need preserved evidence before wide cleanup begins. The playbook also calls for early identification of affected customers so support outreach can start quickly.","tokens":133,"keywords":["revoke live sessions","rotate credentials","audit evidence","automation isolation","affected customers"],"relevance_tags":["incident_response","security_incident","containment","forensics","customer_protection"]}
{"chunk_id":"incident_004","domain":"Incident Response Playbooks","text":"A customer risk framework says response teams should prioritize actions by immediate inconvenience, financial harm, and long term trust impact. When the cause is still uncertain, teams are told to choose the step that most directly limits customer harm first. The framework helps support, security, and engineering reason from the same customer impact model.","tokens":113,"keywords":["customer risk","financial harm","trust impact","limit harm first","impact model"],"relevance_tags":["incident_response","customer_protection","prioritization","risk","decision_making"]}
{"chunk_id":"incident_005","domain":"Incident Response Playbooks","text":"A post incident review worksheet captures contributing factors, open questions, and follow-up owners after a major event. It is useful once the event has closed, but it does not guide live containment or customer action. Because it repeats words like impact and timeline, it can distract retrieval during active incident tasks.","tokens":99,"keywords":["review worksheet","follow-up owners","contributing factors","open questions","post incident"],"relevance_tags":["incident_response","distractor","postmortem","learning","follow_up"]}
{"chunk_id":"incident_006","domain":"Incident Response Playbooks","text":"An external update pattern says customer messages should report current scope, mitigation in progress, and the time of the next update instead of offering speculative completion estimates. Teams use the pattern to reduce rumor spread and duplicate tickets. It is highly relevant when support and incident command need a shared customer communication standard.","tokens":109,"keywords":["external update","current scope","mitigation in progress","next update","shared standard"],"relevance_tags":["incident_response","status_updates","customer_comms","coordination","outage"]}
{"chunk_id":"reliability_001","domain":"Platform Reliability & Release Engineering","text":"A safe rollback standard says harmful releases should return the platform to the last verified good state before teams debate a perfect patch. It also says rollback decisions should record customer symptoms and impact area so support and incident command stay aligned on what changed. This is a core engineering safeguard for outage mitigation.","tokens":116,"keywords":["safe rollback","verified good state","customer symptoms","impact area","engineering safeguard"],"relevance_tags":["release_engineering","rollback","reliability","incident_coordination","customer_impact"]}
{"chunk_id":"reliability_002","domain":"Platform Reliability & Release Engineering","text":"A feature control guide says risky launches should be protected by kill switches that on-call responders can disable immediately without waiting for a redeploy. The guide exists to shrink blast radius and give engineers a reversible control during outages or abuse events. It often sits beside rollback policy in response planning.","tokens":111,"keywords":["feature control","kill switches","shrink blast radius","reversible control","response planning"],"relevance_tags":["release_engineering","feature_flags","containment","reliability","blast_radius"]}
{"chunk_id":"reliability_003","domain":"Platform Reliability & Release Engineering","text":"A release coordination note says release managers should pause nonessential changes during a major outage, keep the status page aligned with confirmed impact, and brief support on mitigation facts that are safe to share publicly. The note matters because careless release activity can deepen customer harm during already unstable conditions. It connects incident response, support operations, and release discipline in one workflow.","tokens":124,"keywords":["pause changes","status page alignment","safe mitigation facts","customer harm","release discipline"],"relevance_tags":["release_engineering","incident_coordination","status_updates","support_alignment","change_freeze"]}
{"chunk_id":"reliability_004","domain":"Platform Reliability & Release Engineering","text":"A privileged deployment control note says sensitive production changes should require temporary elevation, dual approval in emergencies, and automatic rollback triggers when health checks deteriorate. Engineering leaders use these controls as the deployment equivalent of containment in security work: restrict who can cause damage, make reversal fast, and leave a traceable record. The note is highly relevant when comparing engineering safeguards to account-protection actions.","tokens":131,"keywords":["temporary elevation","dual approval","automatic rollback triggers","health checks","traceable record"],"relevance_tags":["release_engineering","security_controls","rollback","guardrails","change_management"]}
{"chunk_id":"reliability_005","domain":"Platform Reliability & Release Engineering","text":"A capacity review memo focuses on load forecasts, hardware lead times, and benchmark methods for future planning. It is useful for reliability strategy but not for live customer triage or security containment. It is therefore a distractor in this benchmark despite sharing infrastructure language.","tokens":97,"keywords":["capacity review","load forecasts","hardware lead times","benchmark methods","future planning"],"relevance_tags":["reliability","distractor","capacity","planning","infrastructure"]}
{"chunk_id":"reliability_006","domain":"Platform Reliability & Release Engineering","text":"An emergency change policy says responders may bypass standard release process only with named approvers, a tested rollback path, and explicit post-change validation checks. The policy matters because emergency changes can either shorten an incident or amplify it; disciplined controls reduce the second risk. It is directly relevant when comparing engineering safeguards to support or security containment actions.","tokens":119,"keywords":["named approvers","tested rollback path","validation checks","disciplined controls","emergency changes"],"relevance_tags":["release_engineering","change_management","rollback","guardrails","incident_response"]}