Guardrails

Shipped

Guardrails are the safety mechanisms that keep your instance’s sync stable when something goes wrong, so a single bad record can’t spiral into a runaway loop, bury you in noise, or mass-mutate your source — plus the policy rules you define yourself about which operations need a human sign-off.

Stopping the sync loop

A write back to a source can fail terminally — the source rejects it and will keep rejecting it. Without a guardrail, stamping that failure onto the record could look like a fresh edit, re-arm the write-back, fail identically, and repeat about once a second forever.

Turbobase prevents this by distinguishing a real edit from sync bookkeeping. When the only thing that changed on a record is the sync machinery’s own status stamping (marking a terminal failure, recording completion, backfilling a source id), that is not treated as a user edit and does not re-arm the write-back. A genuine data change still does. The loop is broken at the source.

Deduplicating failures

When a record really does fail repeatedly, the failures don’t pile up as near-identical rows. Turbobase keeps a single open failure row per record with an occurrence counter, so you approve, reject, or ignore it once rather than N times. Resolving it frees the slot, so a genuinely new failure after resolution opens a fresh row. This is the row you see and act on in the sync-failure triage view.

Write-back rate caps

Deduplication stops one record failing loudly. Rate caps stop many records changing at once: they are the circuit-breaker against an app — buggy, or badly prompted — mass-mutating your live source data.

Turbobase counts committed write-backs per source and refuses to push past a hard cap. A write is denied if it would exceed the cap for any window: the minute cap stops a burst, the hour and day caps stop a slow drip a minute cap never sees. Excess writes are denied and written to the audit log; nothing reaches the source.

Creates/updates and deletes are counted separately, and deletes carry a much tighter default — an update re-converges on the next reconcile, a source delete does not.

Op class	Per minute	Per hour	Per day
Create / update → source	600	10,000	100,000
Delete → source	60	1,000	5,000

Administrators change the caps under Settings → Write guardrails, one tab per window. 0 disables a cap — which removes that protection entirely, so prefer raising a cap to switching it off. Set them for your real edit volume: too low and legitimate bursts are denied (they re-converge on the next reconcile).

Current usage is on the Guardrails page itself — Write-back rate usage, per source and operation, with today’s count against the day cap. Open a row’s graph for the detail, or to reset the counters. If the figures can’t be shown, a card takes the table’s place and says which of two things happened: they could not be authorised — sign in again, and ask another administrator to check your role if they stay missing — or they could not be loaded, which is worth retrying in a few minutes. Either way the rules below are unaffected, and the panel is never left rendering empty, because an empty table reads as “no usage”, which is a different answer.

Deny by default

By default an operation that matches no rule is allowed with an audit record, and you carve out exceptions with DENY rules — a deny-list. Administrators can invert that under Settings → Write guardrails: with Deny write-back by default on, any write matching no rule is denied at every enforcement phase, and you open records with ALLOW rules instead — an allow-list.

Turning it on with no ALLOW rules freezes all write-back. Author the allow rules for the records you intend to keep open first, and check them with turbobase guardrails test before you flip it.

This is the global posture. It is distinct from the per-source write-back entitlement and from the individual rules below.

Your own guardrail rules

The circuit breakers above run automatically. On top of them, the Guardrails page in your Turbobase app (administrator role required) is where you manage policy rules — which operations against a source are allowed outright, allowed with an audit record, held for confirmation, or denied. The page shows the per-risk defaults, then your rules in three lifecycle buckets:

Proposed — staged, awaiting review. Rules land here when you author one through Pilot, your AI assistant: describe the intent in chat (“block fulfillments over $10,000”, “require approval for journal entries”), confirm the staged rule, and it appears here as proposed. A proposed rule is not enforced until an administrator clicks Activate.
Active — enforced. A rule matches an operation by source, operation, target, risk level, and actor, with optional payload conditions such as an amount threshold, and decides the outcome. A small set of bootstrap rules ships active out of the box.
Inactive — switched off with Deactivate but kept for later re-enabling. Hidden by default; a toggle reveals them.

Each rule authored through Pilot keeps the chat prompt that recreates it, surfaced by the help icon on its row. Open a rule’s usage to see how often it actually fired — counts over the last 24 hours and 7 days, broken down by the decision it produced. A rule that never fires is usually a rule that doesn’t match what you thought it matched.

Deletes are addressed separately

A write back to a source and a delete are different operations in the rule vocabulary: <record>.write for a create or update, <record>.delete for a delete, which carries the destructive risk level. Opening <record>.write never opens <record>.delete, and the reverse holds too — a role or rule that can change an invoice cannot thereby remove one.

Under the default posture an unruled delete is held for confirmation rather than pushed, and under deny-by-default it is denied outright. Deletes reach a source only from a soft-delete on a writable, already-synced record; read-only and never-synced records are skipped, and no app can hard-delete a mirrored row at all.

Pending approvals

When an operation hits a require-confirmation decision it doesn’t run — it queues at the top of the Guardrails page with who requested it, how many approvals it needs, and when it expires. Review opens the confirmation so an approver can decide it; recent decisions — approved, denied, or expired — stay listed on the page.

Sync health — where deduplicated failures surface for triage
Data model — bidirectional write-back, where failures originate