API SLA Verification: Evidence, Checks and Receipts

An SLA often combines technical targets, exclusions, maintenance windows and commercial remedies. Software cannot evaluate that prose safely unless the relevant conditions are represented as explicit fields. Begin with a narrow service definition, measurement period, units and threshold direction. A maximum latency rule is different from a minimum uptime rule, and both need an agreed aggregation method.

Identifiers also matter. The verifier should know which endpoint, region, plan and version the evidence describes. Without that context, a passing measurement from one service could be attached to a different agreement. Canonical agreement and provider references reduce that ambiguity.

A number without provenance is difficult to challenge or defend. Evidence should record when it was observed, the measurement source, the target being measured and any transformation applied before evaluation. If a third-party monitor, provider signature or system-of-record response exists, preserve that reference alongside the normalised value.

Missing and stale evidence require explicit treatment. A freshness threshold should fail or hold a decision when the observation is too old. A malformed value should not silently become zero. These rules prevent evidence-pipeline problems from being misreported as successful delivery.

The evaluation engine should expose each check, its expected threshold, the observed value and the comparison result. Versioning is essential: when a rule changes, the receipt must continue to identify the earlier logic so historical decisions remain reproducible.

A cryptographic digest binds the canonical agreement, evidence, check results and engine version. Recomputing that digest later detects alteration, while repeating the comparisons confirms that the recorded outcome follows from the supplied inputs. This is stronger than exporting a PDF report that cannot be mechanically re-evaluated.

An SLA result can inform a credit, refund or dispute process, but it should not be confused with executing that remedy. Payment movement introduces authorisation, legal and operational requirements beyond measurement. A safe architecture states whether it is only producing evidence, recommending an action or actually controlling funds.

PactVerity Proof Engine v1 currently performs the evidence-processing step: it evaluates supplied latency, uptime, freshness and output-commitment data and produces a portable receipt. It does not monitor the API, decide contractual liability or move money. That separation makes the current result useful without overstating its authority.