Monitoring & Observability
Relevant source files
The following files were used as context for generating this wiki page:
Monitoring and Observability within the TAMV project are structured around the MD-X4 and MD-X5 (Deca-V) kernels, which provide a "Knowledge Grid" and "Observability Layer" for a civilizational federated ecosystem. The system tracks technical health, identity scores, and narrative integrity through automated health checks, the MSR (Main Sovereign Registry), and Horus Tower™ observability.
The primary goal is to ensure technical sovereignty and antifragility by maintaining 100% coverage of traces for critical services like Auth and MSR, while providing real-time metrics on latency, error rates, and trust-score drift.
Sources: src/pages/wiki/modulo-cero/Introduccion.tsx, src/pages/wiki/metaverso-xr/RoadmapCivilizatorio.tsx:50-55, src/pages/wiki/implementacion/CicdPipelines.tsx:85-95
1. Observability Architecture
The architecture uses a multi-layered approach to track the state of the 177+ federated repositories. This includes health checks conducted by the Fusion Core, event logging via the MSR, and the Horus Tower™ observability stack for microservices.
Data Flow and Integration
The following diagram illustrates the flow from service execution to registry and observability:
The system monitors 25 active services across various domains including Auth, Feed, and Identity, ensuring that every significant action is logged and verified with SHA-256 hashes for immutability.
Sources: src/pages/wiki/metaverso-xr/RoadmapCivilizatorio.tsx:40-60, federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:100-125, federation/tamv-digital-nexus/packages/contracts/openapi/tamv.v1.yaml:20-30
2. TAMV Fusion Core & Health Checks
The TAMV Fusion Core acts as a central orchestrator for MD-X4. It performs automated health checks on critical routes and database tables, ensuring the system remains operational.
Monitored Routes and Tables
The Fusion Core iterates through a set of critical routes and tables to verify availability:
| Category | Item Name | Monitoring Logic |
|---|---|---|
| Routes | /dashboard, /isabella, /economy, /auth, /msr | Parallel fetch batches of 4, status code validation (2xx required) |
| DB Tables | profiles, posts, msr_events, crisis_logs, user_roles | Count check via Supabase client, error detection |
| Sync | tamv-content-sync | POST verification to content synchronization edge functions |
Sources: federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:38-80
Fusion Report Structure
When a health cycle completes, the system generates a FusionReport containing:
- health: Route status map and database warnings.
- contentSync: Status of processed items.
- msrEventId: Unique identifier for the audit event registered in the Sovereign Registry.
Sources: federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:25-35
3. MSR (Main Sovereign Registry) & Audit
The MSR is the cornerstone of TAMV observability, turning logs into immutable evidence. Every TAMV_FUSION_CYCLE creates a record in the msr_events table with an evidence hash.
Audit Sequence
4. Operational Metrics and SLOs
The project defines specific success metrics (SLOs) that the observability stack must track, particularly for the MD-X5 (Deca-V) pipeline.
| Metric Area | Target Threshold | Source of Truth |
|---|---|---|
| Latency | P95 < 300ms (Feed), P95 < 4s (Isabella AI) | Prometheus / Orchestrator |
| Reliability | 100% Message Delivery | WebSocket Event Bus |
| Security | 100% coverage of Auth/Post logs to MSR | Horus Tower™ |
| Stability | 0 failures in E2E integration tests | Playwright / CI Pipeline |
Sources: src/pages/wiki/implementacion/CicdPipelines.tsx:105-120, src/pages/wiki/metaverso-xr/RoadmapCivilizatorio.tsx:45-50
5. API Observability Endpoints
The Unified API exposes specific endpoints for health and monitoring, intended for use by the Orchestrator (Port 8200).
GET /health: Basic service health check.GET /health/global: Aggregated health status of the orchestrator.GET /metrics: Prometheus-formatted metrics (Latency, Error rate, Throughput).GET /services: List of all discovered services and their current status.
Sources: federation/tamv-digital-nexus/packages/contracts/openapi/tamv.v1.yaml:450-480, src/pages/wiki/implementacion/CicdPipelines.tsx:88-92
6. Observability in CI/CD (QC-TAMV-01)
Monitoring begins before deployment. The QC-TAMV-01 Constitutional framework mandates that every release must publish its domain events and metrics.
Verification Steps
- ESLint Constitutional Rules: Automated checks for architectural violations (L1-L9).
- Post-deploy Verification: Automatic rollback gates triggered by health failures.
- Telemetry Publishing: Every release is required to publish traces and events to the domain bus.
Sources: src/pages/wiki/implementacion/CicdPipelines.tsx:45-60, src/pages/wiki/implementacion/CicdPipelines.tsx:93-94
7. Current Implementation Status
Observability is currently rated at 38% readiness for full production as of February 2026. While the core registries (MSR) and basic health checks (Fusion Core) are operational, the "Horus Tower" integral tracing and alerting stack is still in partial implementation.
Sources: README.md:120-135
Summary
Monitoring and Observability in TAMV transcend simple logging by integrating architectural compliance (QC-TAMV-01) with immutable event registration (MSR). By utilizing a federated orchestrator and the MD-X4 kernel, the project ensures that system health is not just a technical metric, but a verifiable narrative of the ecosystem's integrity.