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.

Consider a synthetic API observation stamped 2026-09-27T12:00:00Z, evaluated at 2026-09-27T12:02:00Z. Its age is 120 seconds. A policy allowing evidence no older than 60 seconds must fail that freshness check, even if latency and uptime pass. This is an arithmetic illustration, not a report of a customer incident or an independent measurement.

Repeat the comparison with an observation stamped 12:01:30Z: its age is 30 seconds, within the same limit. Preserve the original observation time; fetching an old response at 12:02:00Z does not make its contents fresh. Reject an invalid timestamp and investigate a future timestamp instead of silently converting either into age zero.

Document where the clock and observation come from, how clock skew is bounded, and whether your policy uses an inclusive boundary. For a rule age <= 60 seconds, exactly 60 seconds passes and 61 seconds fails. If your implementation uses different semantics, publish that rule rather than implying compatibility. A passing calculation still cannot prove that the source supplied an honest timestamp.

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.