Guida
Come si usa l'app MFF, sezione per sezione: etichette, crediti, sessioni, modelli, chiavi, ricerca web, peer review. È lo stesso manuale che trovi dentro l'app — qui è pubblico e consultabile senza account.
Dalla dashboard crei una sessione scegliendo dominio, modalità e modello. Nella sessione scrivi la domanda: la risposta arriva in streaming, con le etichette che dichiarano quanto il modello si sta impegnando su ogni affermazione. Con 📎 alleghi immagini, PDF o documenti di testo; con 🌐 chiedi una ricerca web prima di rispondere.
Ogni affermazione porta il suo livello dichiarato: 🟢 SICURO, 🔵 PROBABILE, 🟡 FORSE, 🟠 DIPENDE, 🔴 NON SO, ⚫ NON POSSO. Non sono decorazione: sono l’impegno che il modello si assume su quella frase, e restano nell’export. Un suffisso come [doc] o [test] dice da dove viene, [p:75%] quanto è sicuro. In modalità PLAIN le etichette non ci sono, e tutto il resto della piattaforma funziona uguale.
La sessione raccoglie in una carta 🗂 ciò che risulta stabilito e a che titolo, estratto dalle etichette già dichiarate — non un riassunto scritto da un modello. Serve a due cose: guardarla, e portarla altrove. «Copia come memoria» ti dà un testo che puoi allegare a una sessione nuova, magari con un altro modello, senza trascinarti dietro il transcript intero. Chi la riceve legge che quelle etichette le ha dichiarate un altro: sono affermazioni da discutere, non verdetti da ereditare.
Un credito si spende quando la risposta applica davvero il framework. Se non lo applica, viene reso. Le ricerche web con una tua chiave BYOK e la peer review in PLAIN non consumano crediti MFF: paghi solo il costo del tuo provider. Il saldo e ogni movimento sono in Impostazioni.
Una sessione nasce dalla dashboard, e ogni scelta del wizard cambia qualcosa di concreto nel motore. La prima è la modalità: «Chat semplice» (PLAIN) o «MFF Framework». PLAIN è una conversazione libera: nessuna etichetta epistemica, nessun credito consumato, ma TUTTE le funzioni della piattaforma restano — allegati, ricerca web, peer review, lettura vocale, export. MFF invece inietta il protocollo epistemico: ogni affermazione della risposta porterà un livello di impegno dichiarato, e il credito si spende solo se il framework viene applicato davvero.
Il dominio (Generico, Business, Strategico, Tecnico, Legale, Medico, Scientifico, Creativo, Accademico) fa due cose. Primo: definisce cosa significano 🟢 SICURO, 🔵 PROBABILE e 🟡 FORSE in quel contesto — in dominio scientifico «SICURO» significa risultato replicato e pubblicato, in dominio creativo la soglia è un’altra. Secondo: imposta la temperatura predefinita del modello, da 0.2 (Legale: risposte conservative e ripetibili) a 1.0 (Creativo: massima variabilità). Puoi sempre forzarla nelle impostazioni avanzate.
La modalità operativa decide il taglio della risposta: MFF-E è l’analisi epistemica rigorosa, MFF-G riduce rumore e ridondanza, MFF-X interpreta e spiega senza alterare, MFF-EX le combina (è la modalità centrale), MFF-EGX aggiunge la disciplina della sintesi. AUTO lascia scegliere al protocollo turno per turno in base al compito.
I livelli sono i moduli di difesa anti-allucinazione, attivabili a scelta (di default L1+L2+L3). L1 Citazione Forzata è sempre attivo e non disattivabile: 🟢 SICURO senza fonte viene declassato a 🔵 PROBABILE, sempre. L2 apre la Zona di Verifica Esterna sui contenuti a rischio; L3 obbliga il modello a dichiarare le condizioni che smentirebbero le sue affermazioni; L4 aggancia la ricerca web (si usa col bottone 🌐 in chat); L5 abilita peer review e reasoning esteso; L6 controlla la deriva epistemica ogni 5 turni; L7 è la validazione multi-sorgente con un secondo modello. PAVA e NIST sono protocolli scudo per sessioni lunghe e domini regolati. Implicazione pratica: più livelli = più rigore ma risposte più lunghe e più costose in token; L4 e L5/L7 hanno prerequisiti (una fonte di ricerca il primo, un peer model il secondo).
La lingua della sessione è una scelta separata dalla lingua dell’interfaccia, e resta fissa: cambiare lingua UI NON traduce le risposte già generate — l’etichetta epistemica appartiene al testo che quel modello ha prodotto, e tradurla sotto le etichette le falsificherebbe.
Dentro la sessione: la risposta arriva in streaming; sotto ogni messaggio trovi 📋 copia, 🌐 fonti, 🔊 lettura vocale, ⚖ peer review, e su ogni tua domanda la possibilità di modificarla e reinviarla (o di rigenerare la risposta). «▸ Continua» prosegue una risposta troncata dal budget. Nelle sessioni oltre i 100 messaggi, «⤒ Carica messaggi precedenti» in testa al transcript risale la storia. Ogni 10-12 turni il motore aggiorna la Carta dello Stato: è la memoria trasferibile della sessione — la via corretta per cambiare modello è esportarla e allegarla a una sessione nuova, non cambiare motore a conversazione viva.
Il selettore mostra sempre il listino completo di ogni provider, marcando quali modelli risultano serviti in questo momento: la verità viene dal catalogo live del provider, non da una lista scritta a mano. Un modello non servito è visibile e marcato, non nascosto — sapere che esiste ma non risponde è un’informazione, non rumore.
Anche le capacità vengono dal catalogo, non dal nome: se il modello dichiara la visione, l’allegato immagine è abilitato; se dichiara il reasoning, L5 può accendere i token di pensiero esteso; se dichiara la generazione immagini, entra nelle rotte di generazione. Quando il catalogo non è raggiungibile il motore ripiega su euristiche dichiarate come tali.
La scelta free contro a pagamento ha implicazioni precise. I modelli :free non costano nulla ma hanno un budget documenti e un contesto più stretti, e la ricerca web 🌐 è disattivata per contenimento costi. I modelli a pagamento girano sulla TUA chiave BYOK: il costo è quello del tuo provider, MFF non ci aggiunge nulla.
Se il provider fallisce a metà risposta (rate limit, sovraccarico, modello ritirato), il motore prova i fallback: prima i modelli di riserva che puoi indicare tu nelle impostazioni avanzate (fino a 3, in ordine), poi la catena di policy sui tuoi provider con chiave attiva. Il failover è sempre DICHIARATO: la risposta, le etichette e la Carta dello Stato riportano chi ha davvero servito, mai chi era stato chiesto. Un errore non recuperabile (chiave non valida, saldo esaurito) non fa failover: viene mostrato com’è, e il credito MFF del turno torna indietro.
Implicazione da conoscere: dopo un failover il turno riparte da zero sul modello di riserva (il testo parziale del modello caduto viene scartato, non cucito) — quello che leggi è SEMPRE di un solo modello, dichiarato.
MFF parla con 17 provider, in due famiglie. Gli aggregatori (OpenRouter, OrcaRouter) danno accesso a decine di vendor con una chiave sola: comodo per esplorare, e OpenRouter si collega anche con un click via OAuth senza copiare chiavi. I provider diretti (OpenAI, Anthropic, Google, Groq, Cerebras, Mistral, DeepSeek, xAI, Perplexity, Z.AI, NVIDIA NIM, SambaNova, Hyperbolic, Cohere, Cloudflare Workers AI) espongono le capacità native del vendor: la ricerca web integrata di Anthropic, le citazioni native di Perplexity che compaiono tra le fonti, i tier gratuiti ampi di Groq e Cerebras.
La scelta ha implicazioni sul routing: con un aggregatore la richiesta fa un salto in più e le capacità dipendono da cosa l’aggregatore espone; col provider diretto hai la strada più corta e le funzioni native. La peer review, per scelta di progetto, pesca il secondo modello dai tuoi provider DIRETTI, così il revisore è davvero indipendente dal canale del primo.
Ogni chiave ha un interruttore di protezione (breaker): se il provider risponde «chiave non valida» tre volte di fila, la chiave viene messa in pausa un quarto d’ora per non bruciare richieste a vuoto; guasti e rate limit ripetuti la degradano temporaneamente. In Impostazioni vedi lo stato di ogni chiave e puoi forzare il reset del breaker.
La generazione di immagini è una capacità della PIATTAFORMA, non del modello di chat: se il modello della sessione non genera immagini, il motore instrada la richiesta sul primo dei tuoi provider con chiave che può farlo, e te lo dichiara. Non serve cambiare sessione per generare un’immagine.
Le chiavi API si configurano in Impostazioni, una per provider. Il flusso: apri la card del provider, incolli la chiave, MFF la valida SUBITO con una query di test reale — una chiave che non supera il test non viene salvata. Quelle valide vengono cifrate lato server (key-ring AES con rotazione delle chiavi di cifratura) e non vengono mai più mostrate in chiaro, mai messe in un URL, mai inviate al browser. Puoi dare un’etichetta, e cancellarle quando vuoi.
Per OpenRouter c’è la via rapida: «Collega OpenRouter» apre il flusso OAuth sul loro sito, autorizzi, e la chiave arriva a MFF senza copia-incolla.
Su ogni chiave puoi impostare una whitelist di modelli consentiti: la sessione potrà usare solo quelli, e un failover non sceglierà mai un modello fuori lista. È la protezione giusta se condividi l’account con altri o vuoi impedirti da solo i modelli costosi: la restrizione vince su qualunque automatismo.
Separate dalle chiavi dei modelli ci sono le chiavi di RICERCA (Serper, Tavily, SerpAPI, Brave), usate dal bottone 🌐. Anche queste si validano con una query di prova. Puoi eleggerne una come predefinita: il motore prova prima quella, e le altre restano riserve nell’ordine fisso Serper → Tavily → SerpAPI → Brave. Con una tua chiave di ricerca paghi solo il tuo provider; senza, usa la quota di ricerca inclusa di MFF, che è limitata e condivisa.
Implicazione di sicurezza da conoscere: il modello di sessione non vede MAI le tue chiavi — le richieste partono dal server MFF, e nel prompt non transitano segreti.
Il bottone 🌐 accanto al composer chiede una ricerca web PRIMA della risposta. Il flusso è trasparente in ogni passo. 1) Un mini-modello estrae dalla conversazione la query di ricerca proposta e te la MOSTRA: puoi correggerla o riscriverla prima che parta — la query è una decisione tua, non un automatismo cieco. 2) La ricerca gira sulla catena MWAL: la tua chiave predefinita per prima, poi le riserve, nell’ordine Serper → Tavily → SerpAPI → Brave; se un motore fallisce, il passaggio al successivo viene dichiarato. 3) I risultati entrano nel contesto come blocco di grounding, e la risposta può citarli.
La regola anti-allucinazione è rigida: le etichette 🌐 CONFERMATO:WEB e 🌐 VERIFICATO:WEB sono ammesse SOLO se un blocco di grounding reale è stato iniettato in quel turno (o se il provider ha una ricerca nativa, come Anthropic o Perplexity). Senza blocco, il modello deve dichiarare che non ha accesso live e ripiegare su 🔵 PROBABILE[mem] — dire «ho cercato sul web» non è una prova, e il protocollo lo tratta come tale.
Le fonti restano attaccate alla risposta: il chip 🌐 nel footer del messaggio elenca i link, sopravvive al ricaricamento e finisce nell’export. Per Perplexity vengono mostrate anche le citazioni native del modello.
Due limiti onesti. Primo: gli snippet dei motori di ricerca sono per costruzione una cache — per dati che cambiano al minuto (quotazioni live, l’ora esatta) la fonte può essere pertinente ma stantia. Secondo: sui modelli :free il 🌐 è disattivato per contenimento costi.
La peer review fa rileggere una risposta a un SECONDO modello, di un provider diverso, e ti mostra il giudizio accanto all’originale. Non è una seconda opinione qualunque: è il livello L5-B del protocollo — la logica ensemble dice che la convergenza di due agenti indipendenti può promuovere un 🔵 PROBABILE a 🟢 SICURO, e una divergenza forza 🟡 FORSE o 🔴 NON SO. Due modelli che non condividono né pesi né canale, d’accordo sulla stessa affermazione, valgono più di uno.
Come si attiva, passo passo: 1) nelle impostazioni avanzate del wizard scegli il peer model — la lista pesca dai tuoi provider diretti con chiave BYOK, deliberatamente diversi dal provider di sessione; 2) in chat, sotto ogni risposta, premi ⚖; 3) la review arriva in streaming e resta agganciata a quel messaggio, con il suo verdetto di convergenza. Le review sono persistite: le ritrovi al ricaricamento e nell’export, e quelle ancorate a messaggi più vecchi della pagina caricata restano raggiungibili in testa al transcript.
Funziona anche in PLAIN, per parità di piattaforma: senza etichette resta comunque un secondo parere indipendente sul contenuto.
Implicazioni di costo: la review gira sulla TUA chiave del peer model — paghi il tuo provider; in PLAIN non consuma crediti MFF. Implicazione epistemica: se rigeneri una risposta, le review restano agganciate al messaggio a cui si riferivano — una review non migra mai su un testo che non ha mai letto.
La regola base dei crediti MFF è una: si paga il framework applicato, non il tentativo. A inizio turno un credito viene riservato; se la risposta applica davvero il protocollo, si conferma; se non lo applica, o se il provider fallisce, torna indietro. PLAIN non consuma mai crediti. Tutto ciò che gira su chiavi tue (modelli BYOK, ricerca web, peer review) costa solo quello che fattura il tuo provider: MFF non ricarica nulla.
Per spendere meno, in ordine di efficacia: 1) usa i modelli :free per bozze ed esplorazione — gratuiti, col compromesso di contesto e budget documenti più stretti e niente 🌐; 2) preferisci sessioni corte e trasferisci la Carta dello Stato invece di trascinare conversazioni lunghissime: la storia oltre il tetto viene comunque troncata dal motore, la carta è la memoria che viaggia senza pagare token di contesto; 3) tieni il reasoning su Basso finché il compito non chiede di più — i token di pensiero esteso si pagano come gli altri; 4) metti la whitelist sui modelli consentiti della chiave, così nessun automatismo può scegliere un modello costoso al posto tuo; 5) indica fallback economici nelle impostazioni avanzate, perché il failover rispetta la tua lista.
Ogni risposta porta i suoi numeri: nel footer tecnico vedi token in ingresso e uscita, tempi, e — quando il listino del modello è noto — la stima di costo del messaggio e il cumulato della sessione. Se l’usage del provider non arriva, la stima è marcata come tale (~), mai spacciata per dato.
Una garanzia di piattaforma: le tutele tecniche (cifratura chiavi, breaker, failover dichiarato, rate limit) sono identiche per utenti free e paganti. Il free non è una versione meno sicura.
La pagina Impostazioni ha due viste, selezionabili dal menu in testa: «Utente base» mostra l’essenziale (profilo, chiavi, saldo, voce, privacy); «Utente esperto» aggiunge diagnostica, preferenze AI, whitelist dei modelli e storico movimenti. La scelta resta memorizzata sul dispositivo. Se in questa guida leggi di qualcosa che nella pagina non vedi, quasi certamente sta nella vista Esperto.
Aree della vista base, dall’alto: Profilo (lingua dell’interfaccia e provider predefinito per le nuove sessioni); Aspetto e preferenze col tema chiaro/scuro; Voce (la voce, velocità e tono usati dal 🔊 e dalla dettatura 🎙); Crediti (saldo e come chiederne); Chiavi API dei modelli, dove incolli una chiave o colleghi OpenRouter con un click — ogni chiave mostra un semaforo: attiva, non valida, o in pausa; Ricerca web, dove aggiungi le chiavi dei motori (Serper, Tavily, SerpAPI, Brave) ed elegge la predefinita con la ⭐; in fondo, l’area Privacy con l’export completo dei tuoi dati e l’eliminazione dell’account (immediata e definitiva, protetta da conferma scritta).
La vista Esperto aggiunge le regolazioni fini: temperatura personalizzata che scavalca il preset del dominio, tetto ai token di risposta, sforzo di reasoning predefinito (L5), lingua predefinita delle nuove sessioni, continuazione automatica delle risposte troncate; sulle chiavi, l’editor 🎯 della whitelist modelli e le dichiarazioni tecniche di ogni chiave (quanti modelli espone il catalogo, con quali capacità, che crediti restano sul provider); sulla ricerca, il toggle che governa il declassamento dell’estrazione query.
La Diagnostica (vista Esperto) è il pannello che risponde alla domanda «perché non funziona?», e nessun numero lì dentro è inventato: sono prove reali. Il probe BYOK esegue una query di test vera su ogni tua chiave e riporta l’esito con la latenza; il pannello immagini dichiara QUALE delle tue chiavi genererebbe un’immagine ora e con che modello; la salute modelli mostra la telemetria di ciò che hai davvero usato (tempi di prima risposta, errori, 429); il censimento campi elenca ciò che le API dei provider espongono e MFF non traduce ancora.
Cosa fare quando qualcosa è rosso. Chiave «non valida»: la chiave è stata revocata o è scaduta sul sito del provider — rigenerala lì e reinseriscila; MFF non può ripararla. Chiave «in pausa»: il breaker l’ha fermata dopo errori ripetuti (tre «non valida» di fila = un quarto d’ora di pausa) per non bruciare richieste; si riattiva da sola a fine pausa, o subito col bottone «Riattiva» se sei sicuro che il problema sia risolto. Probe fallito su una chiave che ieri funzionava: prima di cancellarla, guarda il codice — un rate limit o un guasto del provider passano da soli, e cancellare la chiave non accelera nulla. Regola generale del pannello: un dato assente viene mostrato come assente, mai spacciato per zero.