What Causet handles vs what stays in your app

Causet sits beside your app. It records and executes the workflow/state timeline for flows that need determinism, replay, audit, repair, or inspection. Your data and infrastructure stay yours — your app keeps the user-facing product, database, and existing services.

Adoption pattern: Keep your app. Pick one endpoint, webhook, cron job, queue worker, or agent action. Move the workflow behind it into Causet. Start with Retrofit an Existing App.

What stays in your app

Frontend UX
API request/response shape
Auth and session handling
Primary database, if you choose
Existing services
Existing queues
Existing third-party API clients
User-facing validation
Synchronous decisions that must complete before returning

What Causet handles

Accepted intents
Deterministic rule evaluation
Events and state transitions
Workflow progress
Decisions and approvals
Timeline history
Replay / fork / repair metadata
Retryable side effects
Derived projections, if configured
Audit trail for important state changes

Common integration pattern

Request
  → existing API route (validate, auth, shape response)
  → submit intent
  → Causet timeline (rules, events, decisions, retries)
  → side effects / projections

Your API route should accept the request. Causet should own what happens next.

See Retrofit an Existing App for a step-by-step walkthrough.

What Causet does not replace

Causet does not have to replace your:

Database — your app can keep writing to Postgres or any other store for data that does not need a replayable timeline.
Queue — keep Kafka, SQS, or Bull for transport; use Causet for the business state and workflow history that must be auditable.
Frontend — no UI changes required for a retrofit.
Auth — session and access control stay in your app.
Vector database — semantic retrieval stays where it is; Causet records the timeline around AI memory and decisions.
Every API route — only move flows where replay, audit, repair, or visibility matter.
Architecture — no rewrite required.

What happens if Causet is down?

Treat Causet like other critical infrastructure. The right behavior depends on the flow:

Flow type	Conservative approach
Fire-and-forget side effects (email, CRM sync)	Fail open: accept the request, enqueue intent submission for retry, or buffer locally
Payment or access-control decisions	Fail closed: return an error until Causet is reachable, or keep the synchronous path until the flow is proven
Webhook handlers	Return non-2xx only on signature failure; buffer intent submission if runtime is temporarily unavailable

Do not claim guarantees your deployment has not implemented. Decide per workflow whether to fail closed, enqueue for later, or fall back to the existing inline path — and document that choice in your rollout plan.

See Production Rollout Checklist for adoption guidance.

When Not to Use Causet Why Causet?