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.