Developer support & incident operations
A support model centred on request IDs, contract fingerprints and redacted operational evidence. Active developer plans or signed agreements control any contractual response commitments.
Severity classification
| Class | Definition | Useful evidence |
|---|---|---|
| S1 · Critical | A material production outage, security-impacting integration failure, or integrity issue affecting governed financial operations. | time window, request IDs where available, affected application/environment, customer or transaction impact, workaround status |
| S2 · High | Material production degradation or repeated failures with significant business impact, while a bounded workaround may exist. | time window, request IDs, affected operations, error/status pattern, workaround |
| S3 · Normal | Isolated production or sandbox integration defect, compatibility issue, webhook failure, or SDK problem without broad service impact. | request or delivery IDs, operation, environment, reproduction steps |
| S4 · Guidance | Implementation, documentation, architecture, migration, certification or developer-programme guidance. | goal, relevant API or SDK, current contract fingerprint where applicable |
Evidence-first support
Start with request IDs, delivery IDs, environment, time window and the current API contract fingerprint. FinanceGPT support evidence is designed to avoid API keys, OAuth secrets, webhook signing secrets and raw financial credentials.
Observability API changesContractual boundary
This public support policy is operational guidance, not a contractual SLA. Where an active plan or signed agreement specifies response or resolution commitments, those terms control. Support diagnostics never create production entitlement or transaction authority.
Developer programme
Builders and open-source maintainers can also use the existing FinanceGPT developer programmes for structured adoption support without creating a second developer control plane.
Developer programme Open Source programme