What Happens When Rexfin's Verifier Goes Down (And How It Recovers)

Rexfin’s verification engine sits in the middle of every cited answer and every export decision. That’s not an incidental dependency: it’s the whole point. Blocking an unverified export only means something if the thing doing the blocking is actually up, fast, and observable when it matters. So the honest question isn’t “does Rexfin have uptime,” it’s “what happens the moment it doesn’t.”

A budget, not a hope

The verify path and the answer path both carry an internal service-level target, tracked against real traffic rather than picked to sound reassuring in a security questionnaire. Verification of an already-submitted model is budgeted in single-digit seconds; a fresh cited answer, which involves retrieval and generation before verification runs, carries its own larger budget with a hard ceiling on the slow tail. Availability is tracked against an internal target over a rolling 30-day window, with an error budget attached to it (the same rule behind the support model): a number gets published only once it’s one we can actually stand behind.

The reason a budget matters more than a single uptime number: it comes with burn-rate alerting. A sudden total outage triggers a page within the hour it happens, not at month-end when the budget is already gone. A slow, creeping degradation opens a ticket well before the budget runs out. And a legitimate refusal (the verifier correctly blocking a statement set that fails an identity check) counts as the system working, not as an outage. That distinction matters: an availability metric that can’t tell “the gate did its job” from “the gate broke” is measuring the wrong thing.

One trace across the whole answer

When a verdict is slow or wrong, the failure usually crosses a boundary: retrieval, then an investigation loop gathering supporting figures, then a writer producing prose, then the verifier checking it, then the write to the audit log. Rexfin ties all of that together under a single trace so a slow answer is diagnosable end to end rather than “it’s slow somewhere,” which is the least useful sentence in an incident review. Any trace ending in a failure or a legitimate refusal is always kept in full, regardless of normal sampling, so the interesting cases are never the ones that got dropped.

Providers fail. The answer shouldn’t just stop.

Model providers rate-limit and go down, that’s normal, not exceptional. Rexfin wraps every outbound call with a timeout, bounded retries with backoff, and a circuit breaker per provider. Once a breaker trips, the request fails over to a cached or offline path rather than hanging, and the response is honestly flagged as degraded, never silently returned as if nothing happened. This is what makes routing different tasks to different model providers operationally safe: a single vendor hiccup degrades one role’s answers, not the whole system.

Retries carry a second guarantee that’s easy to overlook: they’re idempotent. If a client retries the same verification request twice, Rexfin returns the same stored verdict and the same audit record rather than appending a second entry to the audit log. An append-only, tamper-evident ledger that could accumulate duplicate entries from ordinary network retries wouldn’t be trustworthy for long.

Underneath all of this sits one rule that never bends: a dependency that’s down degrades to an advisory, a typed error, or a refusal: it never manufactures a passing verdict for a check it couldn’t actually run. Losing the database means the gate says “unavailable,” not “clean.”

The backup that actually matters

The most consequential guarantee in this whole area isn’t about uptime: it’s about what survives a restore. Every verified board pack Rexfin has ever issued is only as good as the tamper-evident record behind it. If a disk failure or a bad deploy meant that record couldn’t be restored to a state where its proof still checks out, every previously issued verdict would quietly stop being verifiable, retroactively.

So the restore procedure isn’t considered complete when the database comes back online. It’s complete when a previously issued verdict’s proof is re-checked against the restored data and it still resolves, the same proof a customer’s own auditor could run independently. Today that means nightly backups rather than continuous replication (a gap we name rather than round up), so the current recovery point is measured in hours, not seconds; what’s already true is that restores have been tested and have actually succeeded, so recovery is a tested capability, not a document nobody has run. This is also where retention and deletion intersects reliability: a deleted deal’s data has to actually be gone from backups too, not quietly resurrected the next time one is restored.

None of this makes Rexfin immune to outages: providers still go down, disks still fail. What it changes is what happens next: a measured, alerted, and ultimately provable recovery instead of a quiet hope that nothing important was lost. For the rest of how the platform is built to be defensible, see the Inside the Rexfin platform hub.