Seller field guide · 3 min read
Can you license incident resolution history for AI?
Incident records may be useful when they show how a team moved from a problem to a verified resolution. Start with company-owned timelines, diagnostic notes and postmortems that can be separated from credentials, customer environments and confidential evidence. A closed ticket count alone does not establish buyer fit.
What makes an incident record useful?
Scale describes interest in real operational workflows and records with history and metadata. For an incident dataset, that suggests preserving the sequence of observations, attempted remedies, escalation and outcome. This is an assessment approach, not a statement that Scale will accept a particular incident archive.
Choose incidents where a reviewer can explain why a step was taken. A status field saying resolved is weaker than a timeline showing what failed, which evidence changed the diagnosis, and how recovery was checked. Include unsuccessful attempts when they are documented accurately; do not rewrite a messy incident into an invented ideal procedure.
Source notes: Scale: data partnerships, criteria and data sources
Which parts should travel together?
Build a record map before extracting files. Ticket identifiers can connect an alert, operational discussion, change record and postmortem, but those links can also point into restricted systems. Replace identifiers consistently inside the proposed package and keep any re-identification key outside the buyer delivery.
Our suggested inventory below separates decision evidence from information that only reveals whose environment was affected. NIST provides a framework for managing privacy risk; it does not certify an incident dataset or determine your contractual rights.
| Record | Preserve if authorized | Review or remove |
|---|---|---|
| Incident timeline | Event order, diagnostic reasoning, escalation | Hostnames, IPs, access tokens and account identifiers |
| Change record | Decision, approval role and observed result | Production connection details and embedded secrets |
| Postmortem | Contributing factors and follow-up actions | Client-confidential logs and security-sensitive exploit details |
| Runbook | Procedure version used at the time | Credentials and restricted infrastructure diagrams |
Source notes: NIST: Privacy Framework
How should you test the package?
Review a small set of permitted incidents from different categories. Ask someone who did not handle each event to reconstruct the problem, decision and outcome using only the candidate package. Missing context is a preparation issue, not a reason to attach every available log.
Record known limitations: incomplete timelines, changed severity definitions, excluded clients and incidents that never received a postmortem. Keep resolved and unresolved cases distinguishable. Agree with the prospective buyer on whether the intended use is training, evaluation or another permitted purpose before enlarging the scope.
Source notes: NIST: AI Risk Management Framework
Illustrative scenario · fictional company
A fictional MSP separates its own operating history
Cedar IT selects internal incident coordination from its service desk. A ticket links a service alert, an escalation and a runbook revision. The client contract prohibits reuse of raw environment logs, so the team excludes those logs and the affected client identifiers. A reviewer can still follow the diagnostic choices, but two incidents depend entirely on screenshots that cannot be shared; those incidents are removed from the candidate package. No buyer acceptance or payment is assumed.
When to pause or narrow the scope
Client work and customer files are excluded from this starting scope. Assess company-owned internal records separately from personnel, health, privileged or NDA-restricted material.
- Client contracts prohibit reuse of the records that carry the reasoning.
- Secrets or security-sensitive evidence cannot be removed without making the account misleading.
- The archive contains closure labels but no usable diagnostic or resolution trail.
Your preparation checklist
- Choose an incident taxonomy and an authorized date range.
- Map tickets, runbooks, changes and postmortems by stable internal identifiers.
- Mark customer-confidential evidence and security material before export.
- Test whether a reviewer can reconstruct decisions from the permitted records.
- Document missing context and ask the buyer to confirm the intended use.
Start with a description of the records. The quote form does not ask you to upload a dataset.
Discuss your dataSources and further reading
- Scale: data partnerships, criteria and data sources · Checked October 26, 2026
- NIST: Privacy Framework · Checked October 26, 2026
- NIST: AI Risk Management Framework · Checked October 26, 2026
This is general information, not legal advice or confirmation that a buyer will accept your records. Published buyer ranges describe their programs, not an offer for your dataset. Buyers may pay QuoteMyData when a deal closes; see how we are paid.
