Receive evidence, events and state without collapsing them into conclusions.
ICI · INDEXICAL CAUSAL INTEGRATION · FINAL V3 ARCHITECTURE
One causal intelligence.
Multiple assurance applications.
ICI — Indexical Causal Integration — is the causal-assurance architecture. ICI FINAL V3 is its shared causal-intelligence core. Sentinel RC2 and four V3-native applications adapt different evidence and operational contexts into the same structural causal state instead of implementing separate causal algorithms.
SHARED CAUSAL LOOP
The same reasoning machinery sits underneath the applications.
The core separates evidence from interpretation, maintains competing structural explanations, uses intervention to discriminate among them, and retains causal lessons only when they survive testing.
Represent competing structural mechanisms and their current probabilities.
Search for evidence or interventions capable of breaking the leading explanation.
Prefer the changed condition with the highest expected information gain under budget.
Use the observed intervention outcome to update the structural posterior.
Do not force a root-cause claim when the evidence remains non-identifying.
Store the causal lesson rather than only the corrected output.
Challenge the retained mechanism under changed surface conditions.
Keep provenance, observed state and inferred state reviewable.
Translate one causal state into the next useful action for the application.
APPLICATION STACK
One core, five operational surfaces.
Sentinel focuses on runtime agent assurance. The other four applications are domain adapters over the shared ICI FINAL V3 application core.
SHARED CAUSAL INTELLIGENCEICI FINAL V3
structural posterior · falsification · expected information gain · abstention · selective causal memoryCausal trajectory, provenance, operational-state continuity and scoped tool authority before action.
Competing failure mechanisms and the next causal intervention with the highest information value.
Evidence structure and the next-best inspection capable of discriminating between causal explanations.
Retrieval by causal fingerprint rather than by wording, incident title or keyword similarity.
Verified causal transfer using retained memory against a no-memory control under changed conditions.
CORE VS ADAPTERS
What is shared, and what changes by domain.
Shared by every V3-native application
- Structural posterior over competing mechanisms
- Evidence/provenance discipline
- Expected-information-gain intervention selection
- Abstention when evidence is not identifying
- Selective causal memory and changed-condition re-test
Changed by each domain adapter
- Which evidence is mapped into causal factors
- Which intervention is operationally meaningful
- How results are expressed to the user
- Which safeguards and human authority apply
- Which external validation task is appropriate
RUNTIME CONTRACT
The public applications expose the same core identity.
The production API includes a read-only synthetic health check that executes Reliability, Inspector, Incident Memory and Learning through the shared application core and verifies the architecture contract.
PRODUCTION TELEMETRY BRIDGE
OpenTelemetry traces can now enter Sentinel’s causal audit path directly.
The production boundary accepts authenticated OTLP/HTTP JSON at POST /v1/traces. Traces are normalized into ICI telemetry events, materialized into existing Sentinel events and can be audited by the existing orchestrator without importing OpenTelemetry or vendor-specific SDKs into the causal core.
Security properties
- Bearer token required; deployments without a token fail closed with 503
- Unauthorized senders rejected with 401
- Default JSON payload cap: 1 MB
- Successful responses do not echo telemetry content
- Evidence spans without explicit provenance are rejected
Vendor-neutral observability
- OpenTelemetry Collector reference configuration
- Prometheus span metrics exposed on port 9464
- Datadog OTLP fan-out with cumulative-to-delta metrics conversion
- No Prometheus or Datadog code introduced into the causal core
- Changing observability vendor does not change Sentinel causal logic
WHAT THIS MEANS
Sentinel is no longer limited to synthetic trace construction or UI-local audit inputs. It now has a production telemetry ingestion boundary capable of converting instrumented agent traces into deterministic causal-audit input while preserving an explicit distinction between observed trace topology and verified causal provenance.
PUBLIC BOUNDARY
This page documents architecture and observable contracts, not proprietary source implementation. The frozen scientific core, application adapters and public runtime evidence are distinct from independent external validation. No statement here claims universal immunity to failure or universal causal identification.
ICI · INDEXICAL CAUSAL INTEGRATION · ARCHITETTURA FINAL V3
Una sola causal intelligence.
Più applicazioni di assurance.
ICI — Indexical Causal Integration — è l’architettura di causal assurance. ICI FINAL V3 è il suo core condiviso di causal intelligence. Sentinel RC2 e quattro applicazioni V3-native adattano evidenze e contesti operativi diversi allo stesso stato causale strutturale, invece di implementare algoritmi causali separati.
SHARED CAUSAL LOOP
Le applicazioni condividono lo stesso motore causale.
Il core separa evidenza e interpretazione, mantiene spiegazioni strutturali concorrenti, usa interventi per discriminarle e trattiene lezioni causali solo quando sopravvivono al test.
Riceve evidenze, eventi e stato senza trasformarli prematuramente in conclusioni.
Rappresenta meccanismi strutturali concorrenti e le rispettive probabilità.
Cerca evidenze o interventi capaci di rompere la spiegazione dominante.
Preferisce la condizione modificata con maggiore expected information gain.
Usa l’esito osservato per aggiornare il posterior strutturale.
Non forza un claim causale quando l’evidenza non identifica abbastanza.
Memorizza la lezione causale, non soltanto l’output corretto.
Attacca il meccanismo trattenuto in condizioni superficialmente diverse.
Mantiene provenance, osservato e inferito separati e revisionabili.
Traduce uno stesso stato causale nella prossima azione utile per l’applicazione.
APPLICATION STACK
Un core, cinque superfici operative.
Sentinel è focalizzato sull’assurance runtime degli agenti. Le altre quattro applicazioni sono adapter di dominio sopra lo shared ICI FINAL V3 application core.
SHARED CAUSAL INTELLIGENCEICI FINAL V3
structural posterior · falsification · expected information gain · abstention · selective causal memoryTraiettoria causale, provenance, continuità dello stato operativo e tool authority scoped prima dell’azione.
Meccanismi di failure concorrenti e prossimo intervento causale con massimo valore informativo.
Struttura dell’evidenza e next-best inspection capace di discriminare tra spiegazioni causali.
Retrieval per causal fingerprint invece che per wording, titolo dell’incidente o keyword.
Verified causal transfer con memoria trattenuta contro controllo no-memory in condizioni modificate.
CORE VS ADAPTER
Cosa è comune e cosa cambia per dominio.
Condiviso da ogni applicazione V3-native
- Structural posterior sui meccanismi concorrenti
- Disciplina di evidenza e provenance
- Selezione intervento tramite expected information gain
- Abstention quando l’evidenza non è identificante
- Selective causal memory e changed-condition re-test
Specifico dell’adapter di dominio
- Quali evidenze vengono mappate nei fattori causali
- Quale intervento ha significato operativo
- Come il risultato viene espresso all’utente
- Quali safeguard e autorità umana si applicano
- Quale validazione esterna è appropriata
RUNTIME CONTRACT
Le applicazioni pubbliche espongono la stessa identità del core.
L’API di produzione include un health check sintetico read-only che esegue Reliability, Inspector, Incident Memory e Learning attraverso lo shared application core e verifica il contratto architetturale.
PRODUCTION TELEMETRY BRIDGE
I trace OpenTelemetry possono ora entrare direttamente nel percorso di causal audit di Sentinel.
Telemetry Gateway v1 · release produzione 4 ottobre 2026.
Il boundary di produzione accetta OTLP/HTTP JSON autenticato su POST /v1/traces. I trace vengono normalizzati in eventi telemetry ICI, materializzati negli eventi Sentinel esistenti e possono essere auditati dall’orchestrator esistente senza importare OpenTelemetry o SDK vendor-specific nel causal core.
Proprietà di sicurezza
- Bearer token obbligatorio; senza token configurato il deployment fail-closed con 503
- Mittenti non autorizzati rifiutati con 401
- Limite JSON predefinito: 1 MB
- Le risposte di successo non riflettono il contenuto telemetry
- Evidence span senza provenance esplicita vengono rifiutati
Observability vendor-neutral
- Configurazione OpenTelemetry Collector di riferimento
- Span metrics Prometheus esposte sulla porta 9464
- Fan-out OTLP Datadog con conversione cumulative-to-delta
- Nessun codice Prometheus o Datadog introdotto nel causal core
- Cambiare observability vendor non modifica la logica causale Sentinel
COSA SIGNIFICA
Sentinel non è più limitato a trace sintetici o input di audit locali alla UI. Dispone ora di un boundary telemetry di produzione che converte trace strumentati di sistemi agentici in input deterministico per il causal audit, mantenendo distinta la topologia osservata del trace dalla causal provenance verificata.
CONFINE PUBBLICO
Questa pagina documenta architettura e contratti osservabili, non il codice sorgente proprietario. Core scientifico congelato, adapter applicativi ed evidenza runtime pubblica restano distinti dalla validazione esterna indipendente. Nessun claim implica immunità universale ai failure o identificazione causale universale.