Contract v1.0.0
Mode: Simulated
Deterministic
No real money movement
Flow decisionale
Gate
Applica regole (limiti/cooldown/MCC) prima del provider
Provider
Restituisce esito: approve/reject/timeout (simulato)
Ledger
Simula posting e recovery: exact-once + check status
Perché è importante: la demo mostra come un motore decisionale rende un'operazione robusta: applica regole prima del provider, gestisce i timeout con convergenza via status check e mantiene tracciabilità della decisione. Il provider è simulato: l'obiettivo è dimostrare logica, contract e determinismo.
Demo Controls
status: —
reason_code: —
next_action: —
decision_trace_id: —
timestamp: —
ui_message: —
Trace
Demo Metrics (simulated)
Total decisions: 0
Approved: 0
Rejected: 0
Timeout: 0
Error: 0
Pending Status: 0
Pending Review: 0
Cosa dimostra questa demo
- Contract decisionale standardizzato (v1.0.0): status, reason_code, next_action
- Regole applicate ex-ante: blocco prima del provider quando necessario
- Timeout gestito come TIMEOUT + CHECK_STATUS (convergenza via status check)
- Outcome deterministici per scenario (riproducibilità)
- Tracciabilità: decision_trace_id + trace di spiegabilità (simulato)
Cosa non dimostra (ancora)
- Nessun pagamento reale: nessun movimento di denaro
- Nessuna integrazione reale con PSP/banca (sandbox/produzione non collegate)
- Nessuna SCA/3DS end-to-end in questa UI
- Metriche illustrative (non osservabilità production)
- Non sostituisce KYC/AML o compliance completa
Cosa rappresenta questa demo
- Questa demo simula il comportamento del motore decisionale proprietario (ProtegoCore)
- Selezionando uno scenario si ottiene una risposta decisionale deterministica
- La risposta è sempre una tripla: (
status,reason_code,next_action) - Il Trace è un log di spiegabilità del percorso decisionale (simulato per chiarezza della demo)
Cosa fa l'algoritmo oggi (TRL3)
- Orchestra un flusso decisionale per depositi
- Applica regole deterministiche di gating (es. limiti, cooldown, blocchi)
- Rappresenta la gestione timeout come TIMEOUT +
next_action=CHECK_STATUS(concetto di convergenza) - È progettato per essere idempotente (stessa intenzione → stesso risultato) e prevenire effetti duplicati
- Dimostrato a livello di logica/contratto e suite di test deterministiche (questa UI è un mockup, non il motore stesso)
Dove siamo: TRL3 → TRL4 → TRL5
- TRL3 (oggi): contratto decisionale + scenari deterministici + riproducibilità (UI simulata)
- TRL4: validare lo STESSO contratto decisionale contro UNA sandbox provider reale (senza riscrittura). Esempi: scenario "OK", "LIMIT", "TIMEOUT→CHECK_STATUS" eseguiti con risposte sandbox.
- TRL5: eseguire lo STESSO motore in staging production-like: scheduling di status-check + riconciliazione, osservabilità minima, runbook.
Le metriche sono simulate. Nessun provider reale è connesso. Nessun movimento reale di denaro.