# Source changes

Websites evolve. A collection can change its layout, URLs, fields, available records, or access requirements. Review the returned records and execution summary before sending changed output downstream.

## A partial run is still partial

Imagine the fictional [table-lamp API](/docs/schemas/) returned some products after its source changed, but could not complete all work within the requested scope. An illustrative result could contain:

```json
{
  "records": [{ "name": "Arc table lamp", "price": 48, "currency": "USD" }],
  "summary": {
    "status": "partial",
    "within_scope_passed": false,
    "catalog_complete": false
  }
}
```

This is a teaching example, not a captured response or a promise that every run uses this exact shape. Nonempty `records` and HTTP 200 do not override `summary.status` or `summary.within_scope_passed`. `catalog_complete: false` also rules out a full-catalog claim.

## Preserve evidence and decide

Keep the records with their summary, requested limits, source identifier, definition version, and non-secret run or trace identifier. Compare the returned fields and examples with the accepted schema. If your workflow requires complete coverage or a required field is missing, hold the result from downstream use while you investigate.

Check whether the source definition or schema changed. Review a new definition before updating the version pinned by your application. Some changes require a different collection approach or make the source unavailable; a successful retry alone does not prove recovery.

## Continue safely

Read [pagination and output](/docs/pagination/) to distinguish a deliberately bounded run from an incomplete one, and [errors and retries](/docs/errors/) before repeating an uncertain execution. [Source status](/status/) covers monitored sources; it does not establish the health of every generated API.