Changelog
The public changelog records changes that can alter what an agent discovers, buys, sends, receives, or is allowed to do. It should help a customer answer: “Did the contract or evidence boundary change?”
Changes that belong here
- a product or solution becomes active, limited, conditioned, inactive, or blocked;
- a country, entity type, or source is added or removed;
- a claim, freshness rule, or known limitation changes;
- a request or response field changes;
- decision semantics change;
- price, payment flow, or approval behavior changes;
- an integration guide changes in a way that affects production behavior;
- a security, privacy, or data-retention boundary changes.
What every release note should include
| Field | Why it matters |
|---|---|
| Effective date | Tells operators when behavior changed |
| Runtime release identity | Connects prose to deployed behavior |
| Documentation release identity | Shows which public explanation was reviewed |
| Affected products and countries | Prevents overgeneralization |
| Compatibility | States whether existing integrations keep working |
| Required action | Explains whether customers must update or retest |
| Rollback or limitation | Makes reversibility visible |
Compatibility policy
Additive fields should not break clients that ignore unknown data. Removing or changing the meaning of a field requires a versioned contract or an explicit migration path. A route with the same name but different decision meaning is a breaking change even if its JSON still parses.
Documentation corrections
Editorial corrections that do not change runtime behavior can be recorded separately. If a correction narrows a claim or reveals a missing limitation, treat it as operationally important and review affected integrations.
Historical notes are not current status
Changelog entries describe what happened at a point in time. They do not override the current catalog, coverage, source health, or release identity. Use Status for the current-state method.
Integration practice
Production customers should pin the contract version they support, log the runtime release identity with each committed decision, and rerun synthetic certification when a relevant contract or decision rule changes.