# Platform and extension operating contract

Draw a narrow boundary. Assign one authoritative owner for each important record and document any required reconciliation.

Source platform → event / input → extension → destination platform → verification

**Workflow / business owner:** ____________________

**Extension owner / alternate / platform administrator:** ____________________

**Environment used for testing changes before production:** ____________________

## Responsibilities

| Responsibility | Platform | Extension | Operator / owner | Evidence |
| --- | --- | --- | --- | --- |
| Authoritative record |  |  |  |  |
| Authentication and access |  |  |  |  |
| Event handling |  |  |  |  |
| Duplicate protection (idempotency key or pre-check) |  |  |  |  |
| Failure visibility and alerting |  |  |  |  |
| Reconciliation |  |  |  |  |
| Secrets storage and rotation |  |  |  |  |
| Third-party components and their updates |  |  |  |  |
| Availability commitment (what the platform promises, what the extension adds) |  |  |  |  |

## Failure checks

- [ ] Repeated event does not create an unintended duplicate.
- [ ] Timeout after acceptance is checked before retry.
- [ ] Retries back off and stop; the stopping point is known.
- [ ] Events that cannot be processed are held for review rather than dropped or retried forever.
- [ ] Rate limits and temporary failures have bounded handling.
- [ ] Access denial and stale data are visible.
- [ ] Partial completion can be reconciled by an operator.
- [ ] Pausing preserves a clear account of pending work.
- [ ] The platform's failure degrades the extension gracefully rather than corrupting records.
- [ ] A change to the extension can be rolled back, and the last rollback was rehearsed or performed on a stated date.

## Change and upgrade

**Interface / version assumptions:** ____________________

**Where platform deprecation notices arrive and who reads them:** ____________________

**Upgrade owner / acceptance checks:** ____________________

**Code review and security check performed for the extension, by whom:** ____________________

**Credential-management reference:** ____________________

**Retirement trigger, including vendor-native capability:** ____________________

## Health check

| Question | This period | Evidence |
| --- | --- | --- |
| Events received / processed / held for review |  |  |
| Reconciliation differences found and resolved |  |  |
| Failures noticed by a person within the agreed time |  |  |
| Platform changes that required extension work |  |  |

## Common failure modes

- Two systems each believe they hold the authoritative record.
- A platform update changes a field name and the extension fails silently.
- The extension runs under a personal account or an expired token.
- Held events pile up because nobody owns the review queue.

**Approved boundary / accepting owner / date:** ____________________

**Review cadence / next review:** ____________________

This contract covers the boundary between platform and extension. It does not review the platform vendor; use the vendor review and acceptance brief for that.