Limiti dell’attribuzione e reporting dell’evidenza

Master sorgente EN · P09-L08 · durata stimata 45 minuti · needs_review

Un resoconto può contenere trasferimenti corretti e affermazioni non sostenute su persona, affiliazione o intento di mercato. Preservare la catena dell’evidenza distinguendo fatti, calcoli, ipotesi e incognite è l’abilità finale.

Produrre un resoconto circoscritto da dataset parziale. Diverso dal resoconto dei controlli dell’asset di P08: qui attività dei conti, relazioni, copertura e limiti d’attribuzione. Nessuna identità personale, istruzione di trading o certificato rilasciato.

Dichiarare portata prima dell’interpretazione

Nominare rete, indirizzo completo, asset, termine temporale/di contesto e domanda. «Quali attività/relazioni sono fornite per W?» è rispondibile; «chi è W e cosa negozierà?» richiede evidenza assente.

Dichiarare unità dell’osservazione: indirizzo non è persona; relazione d’autorità non è proprietà economica. Non passare tacitamente da movimento dell’indirizzo a condotta umana nella conclusione.

Separare stato esaminato, acquisizione e generazione. Resoconto successivo può descrivere attività precedente, ma conoscenza successiva non diventa disponibile prima. Tempi sintetici restano esplicitamente sintetici.

Costruire il registro dell’evidenza

Ogni riga: localizzatore, fonte, oggetto esatto, contesto, risultato, importo/unità e limite. Etichette non verificate sono affermazioni della fonte, non fatti del registro sull’entità. La documentazione spiega parsing, non autentica etichette.

La ricerca Solana può essere indisponibile al commitment richiesto e avere tempo evento nullo [S09-TRANSACTION]. Record mancanti irrisolti. Cronologia delle firme paginata, più recenti prima [S09-SIGNATURES]: il più vecchio restituito non stabilisce origine completa.

Collegare calcoli agli input. Differenza dei saldi prima/dopo e trasferimento sono viste distinte; accordo è controllo di riconciliazione, non necessariamente fornitore indipendente. Dichiarare campi con esportazione comune.

Usare quattro stati

OBSERVED: record ispezionabile nella portata dichiarata, qui riga fittizia fornita. INFERRED: ragionamento esplicito come percentuale o meccanismo plausibile. UNKNOWN: informazioni indisponibili. INSUFFICIENT EVIDENCE: affermazione proposta non stabilibile dalle osservazioni.

Identità insufficientemente sostenuta può coesistere con trasferimenti osservati. Si può dedurre schema di fonte comune senza proprietà comune. Non combinare in un punteggio unico di fiducia nell’identità.

Specificare proposizione: «X è tesoreria autenticata del progetto» è più forte di «Feed-L etichetta X tesoreria». La seconda è osservata come dichiarazione del fornitore; la prima richiede corroborazione indipendente. Classificazioni diverse possono coesistere.

Separare controllo e identità

Firma/autorizzazione sostiene azione specifica di controllo secondo meccanismo/contesto, non identità legale, proprietà continuativa o interesse economico della persona. Contratti o deleghe aggiungono livelli di autorizzazione [S09-ETHACCOUNTS; S09-DELEGATION].

Indagine futura richiede evidenza autenticata e adeguata alla portata dell’associazione. Dichiarazione pubblica, dimostrazione crittografica di controllo e identità organizzativa corroborata rispondono a domande diverse; nessuna sostituisce tutte le altre.

Non richiedere firme al discente o altri, seed, chiavi private o connessione account. Il risultato è analisi in sola lettura con identità irrisolte.

Preservare etichette in conflitto e copertura

Due interfacce che copiano stesso feed rappresentano una dichiarazione a monte. Se altro feed dissente, preservare conflitto. Non scegliere etichetta narrativa o inventare percentuali di fiducia.

Intervallo senza record è attività sconosciuta, non inattività. Record più vecchio visibile dà intervallo osservato-dal nella query, non creazione effettiva. Una fonte può coprire indirizzo ma omettere conti token correlati.

Tabella parziale non stabilisce storia completa del trading. Neppure variazione corretta del saldo stabilisce perché i fondi si siano mossi. Elencare lacune accanto a eventi riusciti/falliti.

Riconciliare solo il fornito

Normalizzare e confrontare contesti coerenti. Conti token per proprietario sostengono disponibilità sotto filtro mint/programma [S09-OWNERS], non tutti gli asset della persona.

Snapshot diversi di 4000 e trasferimento riuscito 4000 danno coerenza numerica. Se storia parziale, non dichiarare esclusi tutti gli altri meccanismi. Tentativi falliti non diventano deflussi riusciti per vicinanza in tabella.

Non combinare movimento token e commissione nativa. Pagatore può differire dal target. Sponsorizzazione non prova proprietario o datore di lavoro. Interazione con servizio etichettato non stabilisce affiliazione.

Scrivere proposizioni con limiti

Ogni risultato: proposizione circoscritta, record, stato dati, contesto e limite. «Saldo restituito R4 6000; copertura completa non stabilita» è più difendibile di «W ha solo 6000 asset rimasti».

Linguaggio neutro per ipotesi e alternative. Ricevere da HUB è compatibile con controllo comune o servizio condiviso; record possono non distinguerli. Compatibilità non è verdetto.

Trasferimento a X e movimento successivo di mercato non stabiliscono segnale BUY/SELL o causalità. Dirlo nella correzione del titolo. Etichette, ricchezza, visibilità sociale e relazioni commerciali non migliorano evidenza.

Mirare le prossime verifiche

Richiedere portata paginata completa, copertura conti correlati, decodifica corrispondente e provenienza etichette. Per ipotesi di controllo, chiedere evidenza discriminante rispetto alle alternative; spiegare ogni incertezza affrontata.

contentVersion e needs_review veritieri. Revisione editoriale non è giudizio d’identità/rischio su W. Futuro Passport o schermata Wallet Intelligence richiede verifica runtime propria; nessun monitoraggio live, artefatto esportato o completezza del fornitore dichiarati.

• Attribuzione: associazione sostenuta tra azione/conto e attore.
• Evidenza di controllo: prova rilevante per autorizzazione specifica.
• Proposizione: affermazione esatta valutata.
• Dipendenza della fonte: evidenza a monte condivisa dalle viste.
• Limite di copertura: inclusioni e omissioni del dataset.
• Registro dell’evidenza: lista riproducibile dietro i risultati.

ILLUSTRATIVE — FIX-P09-08. SIM-CHAIN-A / W / MINT-R, supply 1,000,000 token normalizzati. Solo giorni e marcatori sintetici. Query parziale giorni 12–30 con lacuna[16,18); completezza conti correlati sconosciuta. Analisi giorno30.

Mancano esecuzione di trading, record di creazione, dichiarazione autenticata dell’entità, riconciliazione nativa completa e prova di causa di mercato.

OBSERVED nei dati fittizi: R1–R5 forniscono attività/risultati e saldi; R6–R8 etichette dipendenti/in conflitto.

INFERRED: delta token restituito −4000 coerente con R3; quota del saldo 1%→0.6%. Primo ingresso restituito 18 giorni sintetici prima dell’analisi.

UNKNOWN: identità umana, creazione effettiva, attività mancante, disponibilità complete, entità X e cronologia del saldo nativo.

INSUFFICIENT EVIDENCE: affiliazione tesoreria, proprietà umana condivisa, vendita completata e causalità di mercato non stabilite. R6/R7 non conferme indipendenti.

Saldi restituiti come tutti gli asset; primo avvistamento come nascita; dichiarazioni del fornitore come identità; aggiungere fallimenti; sponsor come datore di lavoro; conclusioni finanziarie/causali dai movimenti.

Scrivere portata, registro, risultati a quattro stati, limiti e tre prossime verifiche. Correggere «W è trader posseduto da persona di 18 giorni, finanziato dal datore di lavoro, che ha venduto 5000 alla tesoreria del progetto».

• Nominare rete, target, asset e termine.
• Collegare fonte/contesto/risultato a ogni affermazione.
• Separare etichette e associazioni umane.
• Pubblicare lacune e dipendenze dei fornitori.
• Riconciliare effetti riusciti senza doppi conteggi.
• Mantenere OBSERVED/INFERRED/UNKNOWN/INSUFFICIENT EVIDENCE.
• Concludere con richieste d’evidenza, non verdetti di trading/identità.

Un resoconto del wallet è catena dell’evidenza con affermazioni circoscritte. Può stabilire attività e quantità lasciando identità, affiliazione e intento irrisolti.

Controllo dell’indirizzo non è identità personale. Finanziamento comune e interazioni non provano proprietà/affiliazione. Dati mancanti, cronologia ed etichette non forniscono segnali di mercato o conclusioni causali.

Registro dell’evidenza R1–R8 con fonte/contesto e parentesi condivise Export-A/Feed-L. Pannello a quattro stati collegato alle affermazioni; lacuna[16,18) UNKNOWN; 4000 riusciti separati da 1000 falliti e 0.01 nativi. Intervallo dal primo restituito 18 esplicitamente sintetico, nessun nodo umano.

Resoconto illustrativo del wallet; attribuzione, scopo degli scambi e affiliazione irrisolti.

SVG/HTML o grafici deterministici con unità, localizzatori e alternative testuali. Navy/nero con accenti misurati ciano, blu elettrico e viola; niente schermate explorer decorative/inventate. A 390px impilare annotazioni; verificare 768px, desktop e RTL arabo all’implementazione. Identificatori LTR e direzioni effettive tempo/collegamenti/assi invariate. Solo marchio BlockAssay ufficiale fornito. Entrambi i visual restano specifiche.

WALLET_INTELLIGENCE corrisponde a ispezione in sola lettura di record pubblici, relazioni e provenienza. Verificare rete, identificatori, campi e copertura prima di integrare runtime; nessuna capacità live del fornitore dichiarata. Usare esercizio incorporato senza rete se dati/accesso a pagamento mancano. Nessuna connessione wallet, credenziale, chiave privata, firma o trading live richiesti. Dati mancanti sconosciuti. Progressi Academy, stato creator, pagamenti e segnalazioni commerciali non alterano mai evidenza Radar.

• Solana getSignaturesForAddress — Cronologia delle firme riferite all’indirizzo, ordine dalla più recente e paginazione. Verificata 2026-09-30.
• Solana getTransaction — Ricerca, commitment e campi dati/tempo nullabili. Verificata 2026-09-30.
• Solana getTokenAccountsByOwner — Enumerazione per proprietario con filtri mint/programma. Verificata 2026-09-30.
• Conti Ethereum — Distinzione conto/interfaccia e tipi. Verificata 2026-09-30.
• EIP-7702 Set Code for EOAs — Delega di codice EOA; presenza di codice da sola non regola universale di classificazione EOA. Verificata 2026-09-30.

Tutti i record originali ILLUSTRATIVE, non misurazioni storiche/live. La documentazione spiega meccanismi, non importi/etichette inventati. Cronologia sintetica circoscritta; observedAt=null intenzionale. OBSERVED nell’esercizio significa record fittizio fornito. Rivedere documentazione e decodifica distribuita prima della pubblicazione. Etichette dei fornitori non stabiliscono identità; controllo dell’indirizzo e attribuzione umana richiedono evidenza distinta.

P09 completato. Rivedere resoconto del wallet affermazione per affermazione, poi tornare alla dashboard Academy. Laboratori separati mantengono prerequisiti elencati.