# Who can license feature flag rollback records? | SourceX

Canonical: https://refer.sourcex.si/questions/who-can-license-feature-flag-incident-rollback-records
Last updated: 2026-10-19

Introduce the CEO (in an owner-run company, usually the owner) as the signer, with the CTO or VP of engineering supporting, and use the engineering director as your sponsor and first contact. The director knows which systems hold rollback history and can run the counts, but rarely has authority to license company records alone. Flag platform and incident platform admins have access, not authority. Customer names in incident messages and vendor terms go to legal, and what can be licensed stays unknown until SourceX's rights review.

This decision tree is part of the [feature flag incident rollback guide](/guides/workflow-feature-flag-incident-rollback). Its job is narrower than the guide's: helping a DevOps consultant work out, inside a software company, whose yes actually counts for a conversation about rollback history.

## The tree: six questions from the flag to the signer

Work through the questions in order. Each one ends in a node: a sponsor, a fact-giver, a branch to legal, or the signer.

1. **Who can say which systems hold rollback history?** The engineering director, or the head of platform or SRE where there is no director. *Node:* sponsor. They know the flag platform, the incident platform, the postmortem habit and the planned cutover date.
2. **Who administers each system?** Release engineering for the flag platform, the on-call lead for the incident platform, IT for chat. *Node:* fact-giver. They can say how far back history goes. LaunchDarkly's change history, for example, records the member who made each change, the resource, the environment, the date and a diff, so an admin can answer coverage questions quickly. That is still access, not authority.
3. **Does engineering leadership support sharing information about internal systems?** The CTO or VP of engineering decides. *Node:* supporter. Without them, the sponsor usually stalls.
4. **Do incident messages name customers, users or employees?** Almost always yes. *Node:* amber branch to legal. Customer contracts, data processing agreements and privacy law decide what can be used and how it must be de-identified.
5. **Do vendor agreements restrict what the company may do with data held in its platforms?** Possibly. *Node:* amber branch to legal, who reads the company's own agreements with its flag and incident vendors.
6. **Who approves new uses of company data and new revenue?** The CEO, who in an owner-run company is usually the owner. *Node:* signer. This is who you introduce, with the CTO alongside.

## Roles around a rollback record, and what each can decide

| Role | What they hold or know | Authority over a licensing discussion |
|---|---|---|
| On-call engineer | The incidents they handled, the flags they changed | None; a source of context only |
| Release engineering or flag platform admin | Flag change history, environments, retention, exports | None; technical access only |
| Incident platform admin or on-call lead | Incident timelines, responders, log entries | None; technical access only |
| Engineering director | Systems, coverage, record quality, cutover dates | Sponsors and convenes; rarely approves |
| CTO or VP of engineering | Whether engineering backs the discussion | Supports or blocks; the CEO approves |
| Legal or contracts lead | Customer, vendor and employee obligations | Advises on rights; does not run the business case |
| CEO (often the owner) | The business case and the risk appetite | Authorizes and signs |

Even inside the incident platform, permissions are about operating the tool, not owning the data. PagerDuty's documentation says it never deletes incidents and that only the Account Owner can redact one, which removes the incident description and incident key and cannot be undone. That is an operational control. It says nothing about who may license the history.

## The amber branches: customer names and vendor terms

Two questions cannot be settled by engineering.

**Customer and employee names in incident messages.** Responders write things like "the large retail account in EU is down" or name the customer's admin who reported it. Under the GDPR, personal data means information relating to an identified or identifiable natural person, which covers named contacts and many user identifiers. Where the company processes such data for a customer, Article 28 requires a processor to act only on the controller's documented instructions. Whether that applies to a given record class is for legal. A customer name is a preparation question, not a reason to stop: SourceX's rights review decides what can be included and how it is de-identified, and the partner never handles the records.

**Vendor terms.** Rollback history sits in third-party platforms. Legal checks the company's agreements to confirm the company controls its own data and can export it. A past security incident, if there was one, is reviewed on its facts; see [whether a company with a data breach can license data](/questions/can-a-company-with-a-data-breach-license-data).

## What stays unknown until SourceX's rights review

The tree shows who to introduce. It does not decide whether anything can be licensed.

| Open question | Who resolves it |
|---|---|
| Which incident messages can be used after de-identification | SourceX with the company's legal lead |
| Whether customer agreements limit use of operational data | Legal, then SourceX's rights review |
| Which years of flag and incident history are in scope | SourceX with the engineering director |
| Whether there is dataset demand for rollback histories | SourceX |
| Whether an offer is made, and on what terms | SourceX and the company's signer |

SourceX licenses approved business data directly from companies for AI training and evaluation, and manages the agreement, rights review, data preparation, delivery and payout. The [data rights explainer](/proof/why-data-rights-matter) describes that review in general terms.

## Turning the tree into an introduction

Once the tree has named a sponsor and a signer, keep the introduction to one page. Give the engineering director the facts from the [rollback system map](/guides/feature-flag-incident-rollback-records-across-systems), draft the note with the [rollback referral brief template](/resources/feature-flag-incident-rollback-referral-brief-template), and ask the director to forward it to the signer with the CTO copied. Consultants working as part-time technology leaders will find the wider context on the [fractional CTO page](/for/fractional-ctos), and the [incident and on-call checklist](/resources/a-company-introduction-checklist-for-incident-and-on-call-records) covers incident records beyond flags.

The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting introductions; the first valid introduction within the 90-day window is credited when the company submits a verified application, and one partner is credited per company.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

When the engineering director has agreed to sponsor and you know who signs, [register as a partner](/register), check the company on [who qualifies](/who-qualifies) and read the [program terms](/terms) before the introduction goes out.

## Sources

- https://launchdarkly.com/docs/home/releases/change-history
- https://support.pagerduty.com/main/docs/incidents
- https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
- https://refer.sourcex.si/terms