# Earlier experiment coverage intake

Studio Figgy · Brandon Figueroa

Public reconstruction of an improvement concept prompted by a planning gap I identified at Supernatural. This describes a proposal, not a claim of implementation or measured results.

## Observed problem

Release ticket review did not always provide the full A/B test and migration context needed by QA. Follow up messages sometimes surfaced important testing implications only after coverage planning was underway.

## Proposed process

Before the release branch is cut, each feature owner provides one compact coverage record. QA reviews the combined record while there is still time to adjust the plan. Missing information remains an open item with an owner, not an assumed approval.

## Coverage record

| Field | What it answers |
| --- | --- |
| Feature and owner | What is changing and who can resolve questions? |
| Affected cohorts | Which user groups or experiment assignments need coverage? |
| Configuration changes | What behavior changes independently of the build? |
| Dependencies | Which services, data changes, or related releases must be coordinated? |
| Test instructions | What must QA do differently for this release? |
| QA acknowledgment | Has the coverage owner reviewed the information? |

## Automation opportunity

Validate required fields, flag missing ownership, and produce a concise reminder list. Link the intake to the release brief so the same information does not need to be recopied into several messages. Automation should report gaps, not approve releases.

## Pilot and measurement

Compare late disclosures, unplanned retests, and unresolved ownership before and during a small pilot. Also ask feature owners and QA whether the intake adds useful clarity or duplicate work. Keep the process only if the evidence supports it.

## Intended benefit

Protect the validation window and surface risk earlier. No adoption rate, time saving, on time delivery percentage, or defect reduction is claimed here.