JABSC logoJABSC

Event Spine

The Event Spine is the shared event backbone across all three platforms: MeshOS, Axis, and Smart Contracts. Every significant action — a code review completing, a lead being enriched, a contract being deployed — is recorded as an immutable event. This creates a single, consistent audit trail and allows systems to react to each other in real time.

Why a Unified Event Spine

Each platform operates independently, but they share infrastructure:

  • MeshOS emits events when code reviews finish, readiness scores change, or components are promoted
  • Axis emits events when campaigns launch, leads qualify, or compliance checks block an outreach
  • Smart Contracts emits events when contracts are deployed, transactions execute, or anomalies are detected

Because all events flow through the same spine, you can build cross-platform workflows. A code review score from MeshOS can trigger a campaign suppression in Axis. A contract deployment can trigger a compliance log entry. Correlation IDs link everything together.

How It Works

  1. Publish — A service publishes an event with a type, source, and data payload
  2. Route — The spine matches the event type against active webhook subscriptions and workflow triggers
  3. Fan Out — Matching subscribers are notified; matching workflows begin execution
  4. Log — Every event is written to the immutable audit log with a trace ID
  5. Correlate — If a correlationId is provided, related events are linked in the event graph

Event Structure

All events follow the same schema regardless of which platform emits them. Every event carries an identifier, a type using dot-notation, the source service, the organization that owns it, a timestamp, a data payload, and optional metadata for correlation and tagging.

Fields

| Field | Required | Description | |-------|----------|-------------| | eventId | auto | System-generated UUID | | type | yes | Dot-notation identifier (resource.action[.status]) | | source | yes | Service or integration that generated the event | | orgId | yes | Organization that owns this event | | timestamp | auto | ISO 8601 UTC timestamp | | data | yes | Event-specific payload (max 1MB) | | metadata.correlationId | no | Links related events for tracing | | metadata.userId | no | User who triggered the action | | metadata.tags | no | Arbitrary labels for filtering |

Event Naming Convention

Events use dot-notation: resource.action[.qualifier]

Example events across platforms:

  • code.analysis.complete — MeshOS: static analysis finished
  • review.agent.complete — MeshOS: one AI agent completed
  • lead.enriched — Axis: enrichment data aggregated
  • outreach.sent — Axis: message delivered to recipient
  • contract.deployed — Smart Contracts: on-chain deployment confirmed
  • contract.failed — Smart Contracts: transaction reverted
Naming is permanent

Event types become part of your integration contracts. Once in production, treat them as public API — add fields, never remove them.

Pattern Matching

Wildcard patterns are supported when subscribing to events:

| Pattern | Matches | |---------|---------| | code.analysis.complete | Exact match only | | code.* | All events starting with code. | | review.agent.* | All agent completion events | | ** | All events (use sparingly) |

Correlation and Tracing

Every event can carry a correlationId that links it to a chain of related events. This is how you trace a complete workflow — from the initial user action through every downstream step.

For example, a MeshOS code review produces a chain of correlated events: upload complete, analysis complete, multi-agent review started, each individual agent completing, and finally the full review completing. All share the same correlationId, making it possible to reconstruct the full timeline from the audit log.

Query all events in a correlation chain via the Events API using the correlationId filter parameter.

Multi-Tenant Isolation

Each event is tagged with an orgId. Row Level Security enforces that:

  • An organization's API key can only publish and read its own events
  • Webhook subscriptions only receive events from the subscribing organization
  • The audit log is scoped per organization

There is no cross-organization event leakage. Even platform admins require explicit access grants.

Exactly-Once Delivery (Axis)

The Axis platform extends the event spine with the transactional outbox pattern to guarantee exactly-once outreach delivery:

  1. An outreach event is written to the outbox table atomically alongside the business record
  2. A background worker reads the outbox and sends the message
  3. An idempotency key on each message prevents duplicate delivery even on retry
  4. Failed sends retry with exponential backoff (5 attempts)
  5. Messages failing all retries move to a dead-letter queue for investigation

This is separate from webhook delivery, which follows the standard retry schedule documented in the Webhooks reference.

God Mode Telemetry (MeshOS)

MeshOS surfaces the event spine through a real-time "God Mode" dashboard that shows:

  • Live event stream with filtering and search
  • Pre-computed aggregates (events per hour, top event types, error rates)
  • Event correlation graph — visualize how events connect
  • Console log ingestion alongside events for full-context debugging
  • Configurable alert rules (e.g., alert if review.agent.complete error rate > 5%)

Next Steps