Specifica operativa · MS-DEC-250

Quando un risultato DEC-250 è completo e utilizzabile.

Un credito viene utilizzato soltanto per un risultato valido. Questa specifica spiega quali informazioni devono essere presenti, come verificarle e come vengono gestiti errori e richieste ripetute. Gli esempi sono sintetici.

Regola principale

Il conteggio segue gli output validi, non i tentativi

DEC-250 include massimo 250 decisioni valide. Un duplicato, un input incompleto o un record non pertinente deve produrre uno stato esplicito ma non puo essere contato come decisione valida soltanto per riempire il pacchetto.

Valido

Completo, coerente, riferito a un input identificabile e conforme al perimetro.

Non valido

Duplicato, incompleto, non pertinente o impossibile da collegare in modo affidabile.

Visibile

Ogni esclusione deve mantenere status, stop reason o limitation verificabili.

Campi minimi

Una decisione completa risponde a sette domande

ElementoDomandaErrore evitato
Input referenceQuale record e stato valutato?Collisioni e duplicati invisibili.
Opportunity scoreQuanto e forte il segnale?Priorita non confrontabili.
ConfidenceQuanto e affidabile?Falsa certezza.
DecisionCosa fare internamente?Score senza percorso.
ReasonPerche?Decisione non verificabile.
Priority e routeDove e con quale urgenza?Output non operativo.
Audit referenceCome si ricostruisce?Impossibilita di controllo.

Score e confidence

Forza del segnale e affidabilita non sono la stessa cosa

Un punteggio alto con confidence bassa non deve essere trattato come un record sicuro. La macchina cliente puo usare score per ordinare e confidence per decidere quanta revisione applicare.

  • Score alto + confidence alta: priorita con revisione ordinaria.
  • Score alto + confidence bassa: approfondire prima di agire.
  • Score medio + confidence alta: watchlist o nurturing secondo policy.
  • Input insufficiente: non trasformare l'assenza di dati in una decisione positiva.
{
  "opportunity_score": 86,
  "confidence": 0.81,
  "decision": "prioritize",
  "reason": "observable operational signal",
  "limitations": [
    "synthetic public example",
    "buyer review required"
  ]
}

Idempotenza

Lo stesso intento non deve produrre ordini o crediti doppi

Una chiave idempotente lega la richiesta alla stessa elaborazione. Un retry tecnico deve restituire lo stesso riferimento o uno stato coerente, non creare un secondo acquisto o consumare altri crediti.

1

Ricevere

Associare input, buyer, prodotto e idempotency key.

2

Persistire

Conservare hash e stato necessari senza salvare credenziali in chiaro.

3

Ripetere in sicurezza

Un retry recupera lo stesso lavoro e non duplica effetti.

Audit e side effect

La decisione resta ricostruibile e non esegue azioni esterne

Il buyer deve poter ricostruire versione, input reference, esito, reason, timestamp e stato del credito. L'output non autorizza automaticamente messaggi, pagamenti, webhook o scritture CRM.

La separazione tra decisione e azione protegge il cliente: un record puo essere interessante senza essere automaticamente contattabile.

Checklist di verifica per una macchina buyer

  • Il codice prodotto e `MS-DEC-250` e il prezzo dichiarato e 49 EUR.
  • Il record contiene score, confidence, decision, reason e route.
  • Il riferimento input e univoco e il risultato e idempotente.
  • Duplicati e invalidi non consumano un output valido.
  • Gli effetti esterni sono false.
  • Il perimetro resta B2B Italia e l'ordine proviene dalla macchina cliente.