Observability (OpenTelemetry)
Relevant source files
The following files were used as context for generating this wiki page:
The Observability system within RDM Digital / TAMV Online is a core operational layer designed to monitor the health, performance, and security of a "sovereign digital territory." It integrates telemetry ingestion, structured logging, and forensic tracing to ensure the integrity of the Kernel TAMV MD-X4 and its associated federated modules.
The primary goal of this system is to provide "sovereign technical auditability," moving away from opaque third-party monitoring toward a localized infrastructure capable of tracking physical and digital events as discrete versioned entities. This includes measuring node status, telemetry signals, and operational health (ECG) to maintain a digital twin of Real del Monte.
Sources: README.md:9-25, README.md:120-130, src/components/rdm/territory.tsx:85-95
Telemetry Architecture and Data Flow
The observability architecture is built on a distributed model where edge nodes and serverless functions ingest signals into a centralized audit ledger. Telemetry data is treated as "inmutable evidence" using Merkle trees and post-quantum cryptography (PQC) signatures to prevent retroactive alteration.
Telemetry Ingestion Flow
Operational signals from the frontend and edge functions are processed through specialized Supabase Edge Functions. The telemetry-ingest function acts as a gateway for incoming data, validating payloads before persisting them to the underlying database schema.
The diagram shows the flow of telemetry data from origin points through validation logic into persistent storage for monitoring.
Sources: supabase/functions/telemetry-ingest/index.ts:50-59, src/components/rdm/kernel.tsx:110-120
Key Data Structures
| Field | Type | Description |
|---|---|---|
resource_type | text | The type of asset being monitored (e.g., node, function). |
sha256 | text | Hash of the telemetry data for integrity verification. |
event_type | text | Categorization of the event (e.g., protocol-execute). |
metadata | jsonb | Additional context such as CPU temp, latency, or PQC error rates. |
Sources: supabase/migrations/20260512080845_110fe96e-4027-403f-98c8-f6d495c1bf4c.sql:72-82, src/components/rdm/kernel.tsx:10-15
Protocol-Driven Monitoring (Kernel MD-X4)
Observability is not just passive logging but is actively tied to the system's "Decision Protocols." The Kernel monitors specific metrics to trigger automated responses through four cascaded protocols.
Integrity Metrics
The system tracks a "Temperature of Integrity" (Autopoiesis), which includes:
- CPU and Latency: Performance monitoring between federations.
- PQC Error Rates: Monitoring cryptographic health.
- Security Events: Real-time tracking of unauthorized access attempts.
This diagram illustrates how the observability layer monitors kernel signals to trigger automated security protocols.
Sources: src/components/rdm/kernel.tsx:7-30, src/components/rdm/kernel.tsx:55-80
Forensic Auditing and Isabella IA
The Observability system integrates with the Isabella Villaseñor IA™ to provide explainable monitoring (XAI). Every decision made by the system is tracked with a reasoning graph, ensuring that observability goes beyond "what" happened to "why" it happened.
Human-In-The-Loop (HITL) Thresholds
Observability monitors the "Certainty Threshold" of automated decisions. If the system's confidence in its telemetry-based reasoning falls below 95%, it automatically blocks the output and triggers a manual audit request.
| Component | Metric | Threshold | Action |
|---|---|---|---|
| Isabella AI | Certainty | < 95% | Trigger Human-In-The-Loop (HITL) |
| Protocol System | Integrity Temp | Variable | Regenerate from verified snapshot |
| Edge Ledger | Signature | Fail | Block resource/Invalidate event |
Sources: src/components/rdm/isabella.tsx:10-15, src/components/rdm/isabella.tsx:110-120, src/components/rdm/kernel.tsx:115-120
Implementation Details
Telemetry Ingestion Logic
The ingestion process utilizes Supabase Edge Functions to handle requests. It enforces a strict payload size limit of 10,000 characters to prevent resource exhaustion and ensure high-performance logging.
// From supabase/functions/telemetry-ingest/index.ts
// Validate analytics payload before insert
const safeBody = typeof body === "object" && body !== null ? body : {}
const serialized = JSON.stringify(safeBody)
if (serialized.length > 10000) return json({ error: "payload too large" }, 413)
await supabase.from("analytics").insert({ event_type: functionName, data: safeBody })
Sources: supabase/functions/telemetry-ingest/index.ts:54-58
Database Audit Schema
Telemetry events are stored with cryptographic signatures to maintain a chain of custody.
CREATE TABLE IF NOT EXISTS public.audit_signatures (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
resource_type text NOT NULL,
resource_id text NOT NULL,
sha256 text NOT NULL,
signed_by text,
signed_at timestamptz NOT NULL DEFAULT now(),
metadata jsonb NOT NULL DEFAULT '{}'::jsonb
);
Sources: supabase/migrations/20260512080845_110fe96e-4027-403f-98c8-f6d495c1bf4c.sql:72-81
Conclusion
The Observability system in RDM Digital serves as a "Sovereign Fortress" for digital operations. By combining OpenTelemetry principles with localized edge ingestion and IA-driven reasoning, the project ensures that every operational signal is auditable, immutable, and actionable within the context of the Real del Monte digital twin.