data/corpus.jsonl

{"chunk_id":"support_001","domain":"Customer Support Operations","text":"A billing operations note says frontline agents must verify the account timeline before discussing compensation. Agents should confirm that the reported outage matches internal service logs, check whether duplicate invoices were generated, and review contract terms for non refundable setup fees. If the evidence is incomplete, the case should move to the billing queue instead of being resolved in chat. Leaders treat this as refund hygiene because premature credits create audit gaps and inconsistent customer treatment.","tokens":126,"keywords":["billing verification","service logs","duplicate invoices","contract review","refund hygiene"],"relevance_tags":["support_triage","billing","refunds","auditability","case_routing"]}
{"chunk_id":"support_002","domain":"Customer Support Operations","text":"A customer education playbook recommends sending short how to guides before escalating low risk questions. It focuses on reducing repeat contacts for password resets, profile edits, and navigation issues. Supervisors liked it because new agents could resolve routine tickets faster, but the document does not cover compensation or financial exceptions. It is useful for support efficiency yet acts as a distractor for refund authorization tasks because it centers on self service deflection rather than account remediation.","tokens":118,"keywords":["self service","password reset","repeat contacts","agent onboarding","deflection"],"relevance_tags":["support_efficiency","distractor","self_service","knowledge_base","training"]}
{"chunk_id":"support_003","domain":"Customer Support Operations","text":"A refund policy memo states that agents should authorize a subscription refund only after three checks are complete: verify the service disruption in the incident timeline, confirm that the billing ledger shows the affected charge, and classify whether the event meets the threshold for refund rather than goodwill credit. The memo also requires agents to capture the root cause category in the case notes and to tag any manual exception for finance review. Teams use the memo to keep customer relief consistent across outage and billing incidents.","tokens":132,"keywords":["refund policy","incident timeline","billing ledger","goodwill credit","finance review"],"relevance_tags":["support_triage","refunds","billing","outage_relief","policy_compliance"]}
{"chunk_id":"support_004","domain":"Customer Support Operations","text":"A major outage triage guide instructs support agents to attach the incident identifier to every affected case, link customers to the status page, and avoid giving speculative recovery times. The guide also says that support should collect impact details in a standard template so the incident commander can prioritize patterns instead of reading free form anecdotes. After the incident stabilizes, the same template feeds refund and goodwill decisions. This chunk connects frontline customer handling with the formal incident response loop.","tokens":127,"keywords":["major outage","incident identifier","status page","impact template","speculative ETA"],"relevance_tags":["support_triage","incident_coordination","status_updates","customer_comms","evidence_collection"]}
{"chunk_id":"support_005","domain":"Customer Support Operations","text":"A compensation matrix distinguishes three actions: immediate refund for clearly billable service failure, goodwill credit for inconvenience without a contract breach, and no compensation when the issue falls outside the documented entitlement. Agents must choose among those paths only after evidence is attached and the cause category is known. The matrix prevents teams from treating every complaint as a refund request. It also reminds agents that finance sign off is mandatory for repeated manual exceptions.","tokens":131,"keywords":["compensation matrix","immediate refund","goodwill credit","entitlement","finance sign off"],"relevance_tags":["support_triage","refunds","goodwill","policy_compliance","finance_review"]}
{"chunk_id":"support_006","domain":"Customer Support Operations","text":"A high risk account compromise workflow tells support to freeze self service changes, confirm the identity of the requester through a secondary channel, and preserve all recent account actions before promising remediation. If the incident is active, support should route the case to security operations and note any customers who may face direct harm from fraudulent activity. The workflow matters during severe incidents because it connects customer protection steps with the broader incident record rather than treating support as a separate queue.","tokens":128,"keywords":["account compromise","freeze changes","secondary verification","security routing","customer protection"],"relevance_tags":["support_triage","security_incident","customer_protection","escalation","identity_verification"]}
{"chunk_id":"incident_001","domain":"Incident Response Playbooks","text":"An incident severity guide defines when an outage moves from a support issue to a formal incident. Teams should declare a major incident when customer impact is broad, restoration requires coordinated ownership, or operational risk is rising faster than routine support channels can handle. The guide is useful for incident management but only indirectly related to refund or account remediation decisions.","tokens":110,"keywords":["severity guide","major incident","broad impact","coordinated ownership","declaration"],"relevance_tags":["incident_response","severity","coordination","major_incident","classification"]}
{"chunk_id":"incident_002","domain":"Incident Response Playbooks","text":"An incident command playbook states that once a major outage is declared, the commander should maintain a shared timeline, track customer impact separately from technical hypotheses, and publish only confirmed updates to customer facing teams. It warns that support escalations become noisy when unverified engineering guesses are passed through as expected restoration times. The playbook is relevant to cross functional response because it ties incident discipline to better customer communication and cleaner post incident review.","tokens":130,"keywords":["incident command","shared timeline","customer impact","confirmed updates","post incident review"],"relevance_tags":["incident_response","incident_command","customer_comms","status_updates","coordination"]}
{"chunk_id":"incident_003","domain":"Incident Response Playbooks","text":"A security incident playbook for suspected admin account compromise says responders should immediately revoke active sessions, rotate privileged credentials, preserve authentication and audit logs, and isolate any automation that may continue making harmful changes. The playbook emphasizes that evidence preservation must happen before broad cleanup so investigators can reconstruct customer impact. It also instructs teams to identify exposed customers early so support can prioritize protective outreach. This is a core chunk for active account compromise response.","tokens":137,"keywords":["revoke sessions","rotate credentials","audit logs","evidence preservation","protective outreach"],"relevance_tags":["incident_response","security_incident","containment","forensics","customer_protection"]}
{"chunk_id":"incident_004","domain":"Incident Response Playbooks","text":"A customer harm rubric says response teams should rank incident decisions by reversible inconvenience, financial exposure, and irreversible trust damage. During ambiguous situations, teams are told to choose the action that limits customer harm first, even if root cause remains incomplete. The rubric matters in enterprise operations because it lets support, security, and engineering use the same prioritization language.","tokens":116,"keywords":["customer harm","financial exposure","trust damage","prioritization","shared language"],"relevance_tags":["incident_response","customer_protection","prioritization","risk","decision_making"]}
{"chunk_id":"incident_005","domain":"Incident Response Playbooks","text":"A retrospective template helps teams classify contributing factors, unanswered questions, and follow up owners after an incident closes. It is useful for learning but does not describe what to do during an active event. Because it contains words like timeline and impact, retrievers may overestimate its value for real time response tasks.","tokens":101,"keywords":["retrospective","follow up owners","contributing factors","postmortem","learning"],"relevance_tags":["incident_response","distractor","postmortem","learning","follow_up"]}
{"chunk_id":"incident_006","domain":"Incident Response Playbooks","text":"A status update standard says every external message should include current scope, actions underway, and the next planned update time rather than a speculative resolution promise. Teams use the standard to reduce rumor spread and support ticket duplication. It is highly relevant where support and incident command need aligned customer communications during outages.","tokens":108,"keywords":["external status","scope","actions underway","next update","speculation control"],"relevance_tags":["incident_response","status_updates","customer_comms","coordination","outage"]}
{"chunk_id":"reliability_001","domain":"Platform Reliability & Release Engineering","text":"A rollback policy says the fastest safe action during a harmful deploy is to restore the last known good state before debating the perfect fix. The policy also notes that a rollback decision should be logged with impact scope and customer symptoms so support and incident command remain aligned. This chunk is highly relevant to incidents where engineering safeguards must reduce downstream customer harm.","tokens":119,"keywords":["rollback policy","known good state","harmful deploy","impact scope","customer symptoms"],"relevance_tags":["release_engineering","rollback","reliability","incident_coordination","customer_impact"]}
{"chunk_id":"reliability_002","domain":"Platform Reliability & Release Engineering","text":"A feature flag operations guide says risky features should ship behind kill switches that can be disabled by the on call lead without waiting for a full redeploy. The guide is used to reduce blast radius during customer facing incidents and to give responders a reversible containment option. It is often paired with rollback policies in outage and abuse scenarios.","tokens":112,"keywords":["feature flag","kill switch","blast radius","containment option","on call lead"],"relevance_tags":["release_engineering","feature_flags","containment","reliability","blast_radius"]}
{"chunk_id":"reliability_003","domain":"Platform Reliability & Release Engineering","text":"A cross functional outage response note says release managers should freeze nonessential deployments, ensure the status page reflects confirmed impact, and keep support informed about mitigation steps that are safe to share publicly. The note matters because engineering activity during an outage can either reduce confusion or create additional customer harm. It bridges incident command, support communications, and release discipline in one workflow.","tokens":123,"keywords":["deployment freeze","status page","safe to share","release managers","cross functional outage"],"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 safeguard note says high risk production actions should require temporary access elevation, dual approval for emergency changes, and automatic rollback hooks when health checks degrade. Engineering leaders use these controls as the release equivalent of containment in security response: limit who can make damaging changes, make reversal fast, and preserve a record of what happened. The note is highly relevant when comparing release engineering safeguards to security or customer protection actions.","tokens":132,"keywords":["temporary access","dual approval","automatic rollback","health checks","deployment safeguards"],"relevance_tags":["release_engineering","security_controls","rollback","guardrails","change_management"]}
{"chunk_id":"reliability_005","domain":"Platform Reliability & Release Engineering","text":"A capacity planning note covers quarterly load forecasts, procurement lead times, and benchmark methodology. It is important for longer term reliability but not for live customer triage or security containment. It behaves as a distractor in corpora focused on incident handling because it shares infrastructure language without operational instructions for active events.","tokens":103,"keywords":["capacity planning","load forecast","procurement","benchmark","long term"],"relevance_tags":["reliability","distractor","capacity","planning","infrastructure"]}
{"chunk_id":"reliability_006","domain":"Platform Reliability & Release Engineering","text":"An emergency change policy says that responders may bypass normal release process only with recorded approver names, a rollback plan, and post-change validation checkpoints. The policy is important because emergency changes can shorten incidents or amplify them; disciplined safeguards reduce the second outcome. It is directly relevant when comparing engineering controls to support or security containment actions.","tokens":117,"keywords":["emergency change","recorded approvers","rollback plan","validation checkpoints","discipline"],"relevance_tags":["release_engineering","change_management","rollback","guardrails","incident_response"]}