Abstract operational event control plane connecting sources, delivery attempts, guarded recovery, and audit evidence
Platform architecture

A control plane for the full operational event lifecycle

Lariba Cloud connects trusted event intake, source identity, investigation, delivery lifecycle, guarded recovery, RBAC, and audit evidence in one operational model.

Platform layers

Context follows the event from source to operator action.

Each layer has a distinct responsibility. Source identity and event investigation stay readable, while mutations pass through readiness, permissions, confirmation, and audit evidence.

Active

Event Sources

Establish who produced an event before downstream investigation begins.

  • Source identity and environment
  • Source-scoped API keys
  • Setup and readiness context
  • Source health and activity
Active

Core Events

Inspect events with source, type, status, severity, time, and storage context.

  • Live event visibility
  • Filtered Event Explorer
  • Event detail and timelines
  • Source-linked investigation
Developer Preview

Sentinel Context

Turn source and event context into recommendations, alerts, and investigation paths.

  • Rule recommendations
  • Alert-to-event trace
  • Source Intelligence context
  • Delivery investigation links
Active

Delivery Control

Follow delivery lifecycle and run guarded recovery actions when a failure is eligible.

  • Attempt history and detail
  • Retry and DLQ visibility
  • Controlled replay and retry-now
  • Readiness and confirmation gates
Active

Operator Access

Separate read access from operator mutations with project-scoped permissions.

  • Delivery read permission
  • Replay and retry-now permissions
  • Capability-aware dashboard UX
  • Backend-authoritative RBAC
Active

Audit Evidence

Keep retry, replay, lineage, and worker evidence visible without exposing secrets.

  • Replay lineage
  • Retry audit rows
  • Operator action evidence
  • Sanitized outcomes

Operational control loop

Capture, investigate, recover, and verify without losing context.

The same project and source context carries through the workflow, so operators do not have to reconstruct a failure across disconnected tools.

  1. 01

    Capture

    Receive an operational event from an authenticated source.

  2. 02

    Attribute

    Attach project, source, environment, event type, and time context.

  3. 03

    Observe

    Inspect the event and follow its downstream delivery attempts.

  4. 04

    Investigate

    Connect failure state to event, source, lifecycle, and retry policy.

  5. 05

    Recover

    Use readiness, permissions, and confirmation before replay or retry-now.

  6. 06

    Verify

    Refresh state and review sanitized audit evidence for the action.

Delivery operations

Delivery is a first-class control surface, not a hidden webhook log.

Teams can inspect lifecycle and retry state, understand whether recovery is eligible, run guarded actions, and review the resulting evidence.

Observe every attempt

Review status, lifecycle, retry count, policy, scheduled state, terminal state, DLQ visibility, and safe failure summaries.

Recover with guardrails

Readiness checks explain whether an action is allowed before a confirmation-gated replay or retry-now request runs.

Review the evidence

Replay lineage and retry audits show the controlled action path without returning provider secrets or raw destination configuration.

Readiness-gated

State, policy, channel, claim, and project checks run before execution.

Confirmation-gated

The dashboard requires explicit confirmation for controlled operator mutations.

Audit-visible

Replay lineage and retry audits make the resulting action path reviewable.

RBAC and capabilities

The interface guides. The backend decides.

Capability metadata helps the Delivery dashboard avoid presenting unavailable actions. Backend RBAC still enforces every protected request, including stale-state and race cases.

401 · sign in required403 · permission required
delivery:read

View delivery history, details, readiness, lifecycle, and retry audit evidence.

delivery:replay

Run the existing confirmation-gated replay action when readiness allows it.

delivery:retry_now

Run one controlled retry-now action when policy, state, and readiness allow it.

delivery:manage_channels

Keep channel-management capability separate from delivery observation.

delivery:dlq_drain

Reserved as a future permission boundary; DLQ drain execution is not enabled.

Product stage

Active workflows inside a broader Developer Preview.

Lariba Cloud has working Foundation, Core Events, Sentinel, Delivery, RBAC, and audit surfaces. The product remains in Developer Preview while integrations, intelligence, governance, and operational breadth continue to mature.

Active now

  • Event Sources and source API keys
  • Core Events investigation
  • Sentinel recommendations and alert trace
  • Delivery lifecycle and retry/DLQ visibility
  • Controlled replay and retry-now
  • RBAC capabilities and retry audit visibility

Expanding next

  • More first-party and third-party integrations
  • Deeper Source Intelligence and decision support
  • Expanded governance and role-management surfaces
  • Future operator actions only after stronger safety boundaries
Developer activation

Start with one source and one real event.

Create a project and source-scoped key, send an operational event, then inspect the source and event context that later Delivery and Sentinel workflows can use.

First event

curl

curl -X POST https://lariba-cloud-api.vercel.app/v1/events/ingest \
  -H "X-API-Key: YOUR_SOURCE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "event": "checkout.failed",
    "source": "checkout-api",
    "properties": {
      "severity": "high"
    }
  }'
Operational context before operator action

Build a safer path from event intake to failure recovery.

Start with source identity and event visibility, then add Delivery, RBAC, and audit controls as your operational workflows become real.