Event-Based Observability Integration Guide

How to send system events to System Continuity Monitor without agents or instrumentation.

Why Event-Based Observability?

Metrics tell you that something happened. Logs tell you fragments. Events tell you what actually happened.

SCM is designed for systems where correctness matters more than dashboards.

System Continuity Monitor (SCM) passively receives events from your system and reconstructs what actually happened — without agents, hooks, or runtime interference.

1. Integration Philosophy

SCM assumes:

• your system already emits meaningful events
• events represent completed state changes
• events are facts, not instructions

SCM does not require:

• schema changes in your database
• synchronous or blocking calls
• changes to your monitoring or alerting stack

If your system can send JSON over HTTPS, it can integrate with SCM.

2. What Counts as an Event

An event is any occurrence that confirms or changes system state.

Examples:

• payment settled
• job reassigned
• retry triggered
• manual override applied
• reconciliation completed

Events should answer:

“What happened?”

Not:

“What should happen?”

3. API Endpoint

• Method: POST
• Endpoint: https://teleport.tr/api/ingest.php
• Content-Type: application/json

Authentication is performed using an API key.

X-API-KEY: your_secret_api_key

4. Minimal Event Structure

SCM accepts simple JSON payloads.

Required fields:

• event_type — what happened
• entity_type — what kind of thing it happened to
• entity_id — stable identifier
• event_time — ISO 8601 UTC timestamp

Optional but recommended:

• actor — system or user responsible
• metadata — free-form context

Example payload:

{
"event_type": "payment_settled",
"entity_type": "payment",
"entity_id": "pay_84329",
"event_time": "2026-01-21T14:07:00Z",
"actor": "system",
"metadata": {
"amount": "120.00",
"currency": "USD",
"method": "card"
}
}

SCM does not enforce schemas. Meaning is derived from sequence and state models, not payload shape.

5. Delivery Semantics

• Events are immutable
• Events are append-only
• Duplicate events are safely ignored

SCM responds with 202 Accepted once an event is stored or deduplicated.

If delivery fails:

• retry asynchronously
• preserve the original event_time

Late events are accepted. Continuity is reconstructed after the fact.

6. Privacy & Scope

SCM does not require:

• personal data
• payload contents
• credentials or secrets

Sensitive fields may be redacted or hashed. SCM verifies structure, order, and invariants — not content.

7. After Integration

Once events are flowing:

• entity timelines are constructed automatically
• usage is tracked per plan
• narrative and continuity reports become available

SCM remains silent unless meaning exists.

---

Summary

• lightweight
• asynchronous
• non-invasive

You send facts.
SCM tells the story.

See how System Continuity Monitor detects silent failures.