# Review a product change

Prepare a reviewable proposal before describing a product requirement as a supported feature. Use the relevant product explanation, application source, and current dataset or API contract as inputs.

1. State one user task and its expected result. Link the relevant requirement and [application owner](/stormtrust/apps/). Separate existing behavior from the behavior the change will add.
2. Trace the data and authority needed for that result. Consult the [dataset inventory](/stormtrust/product/platform-and-data/datasets-and-source-contracts/) and [API reference](/stormtrust/product/build-and-operate/api/). A proposed model or endpoint is not evidence that the required data is available.
3. Define acceptance evidence. Include the successful journey, unavailable or stale data, authorization failures, and revision handling where relevant. Select checks from the [testing strategy](/stormtrust/product/build-and-operate/testing/). Name the fixture or source that can demonstrate each result.
4. Identify the implementation boundary: application code, shared code, service contract, durable resource, or external integration. Include compatibility and recovery requirements for existing consumers.
5. Submit the implementation and documentation through the [pull request workflow](/stormtrust/engineering/github/pull-request-workflow/). Use [Validate a change](/stormtrust/engineering/operations/validate/) for executable checks. Update availability statements only when the supporting implementation and release evidence exist.

## Verify the proposal

A reviewer should be able to identify the user result, current limitation, owner, authoritative inputs, acceptance checks, and recovery boundary without reconstructing the conversation. If an input or test does not exist, keep it as an explicit dependency in the proposal.