Human Structured Intake

decision.type

Un’etichetta testuale libera che descrive la categoria della decisione o intervento umano registrato — ad esempio, che tipo di decisione è, non cosa la decisione ha concluso.

Senza questo campo, un record non indicherebbe affatto che tipo di decisione o intervento è stato registrato. Dà ad ogni altro campo del record una categoria a cui riferirsi.

Sempre — questo campo è obbligatorio per ogni Human Structured Intake.

Scegli un’etichetta abbastanza specifica da distinguere questa decisione da altre decisioni di tipo diverso, ma non duplicare la narrazione completa che appartiene al campo title (che diventa decision.summary). Un buon tipo di decisione nomina la categoria dell’azione; il title/summary descrive questa specifica istanza.

Distinto dal campo comune title, che viene copiato direttamente in decision.summary — una breve descrizione in linguaggio naturale di questa specifica decisione. decision_type nomina la categoria; decision.summary narra l’istanza.

Un Compliance Officer che approva un’eccezione temporanea di policy potrebbe registrare il tipo di decisione come «Approvazione eccezione compliance.» Un responsabile tecnico che autorizza un riavvio di produzione potrebbe usare «Autorizzazione riavvio linea di produzione.»

• Questo non è un’enumerazione fissa — il validatore accetta qualsiasi testo libero non vuoto. La coerenza terminologica tra i record è una disciplina organizzativa, non un vincolo imposto dal sistema.
• Un tipo di decisione specifico non stabilisce di per sé che la decisione sia stata presa correttamente o appropriatamente — nomina solo di che tipo di decisione si trattasse.

decision.closure_timestamp_utc

Il momento dichiarato in cui la decisione umana stessa è stata chiusa — non il momento in cui il record è stato inviato a EVIDE. Vedi la sezione dedicata Chiusura della Decisione sopra per la distinzione completa dall’Intake Timestamp.

Una decisione e la sua preservazione evidenziaria raramente accadono nello stesso identico istante. Registrare l’orario di chiusura dichiarato, separatamente dall’orario di intake generato dal server, è ciò che permette una ricostruzione storica accurata di quando la decisione è realmente avvenuta.

Sempre — questo campo è obbligatorio. Inserisci il momento in cui la decisione è stata effettivamente chiusa, in UTC, non il momento in cui stai compilando il modulo.

Usa il momento reale in cui la decisione è stata chiusa, espresso in UTC piuttosto che in ora locale. Se non sei sicuro del tuo scostamento UTC locale, uno strumento come time.is/UTC può aiutare a evitare un errore di alcune ore.

Una linea di produzione si ferma alle 14:32 ora locale. Il responsabile tecnico esamina le condizioni e autorizza un riavvio, chiudendo quella decisione alle 16:00 ora locale — ma registra l’intake in EVIDE solo alle 18:03, dopo aver terminato altri compiti urgenti. Il timestamp di chiusura preserva le 16:00 (convertite in UTC); l’Intake Timestamp preserva separatamente le 18:03.

• Questo non è il momento in cui il record è stato ricevuto da EVIDE — quello è il separato Intake Timestamp, generato dal server.
• Inserire l’ora locale senza convertirla in UTC è l’errore più comune con questo campo, e produce un orario di chiusura sfasato del proprio scostamento UTC locale.

authority.role

Il ruolo organizzativo, in quale veste, la decisione è dichiarata essere stata presa — distinto dall’identità della persona che l’ha presa.

Un nome da solo non indica in quale veste organizzativa una decisione è stata presa. Il ruolo aiuta un lettore successivo a ricostruire l’autorità organizzativa dichiarata dietro la decisione, indipendentemente da chi specificamente ricoprisse quel ruolo in quel momento.

Sempre — questo campo è obbligatorio per ogni Human Structured Intake.

Usa il titolo del ruolo organizzativamente significativo per questa decisione — es. «Compliance Officer,» «SOC Manager,» «HR Director,» «Fraud Analyst,» «Plant Manager.» Testo libero, non un elenco fisso.

Distinto da authority_id (chi) e dall’identità DAPI della sessione loggata (vedi Identificativo dell’Authority sotto). Il ruolo risponde a «in quale veste,» non «quale persona specifica.»

La stessa persona potrebbe ricoprire più ruoli attraverso decisioni diverse; lo stesso ruolo potrebbe essere ricoperto da persone diverse nel tempo. Registrare il ruolo, separatamente dall’individuo, mantiene leggibile il contesto organizzativo anche quando il personale cambia.

• Questo campo non verifica che la persona dichiarata ricoprisse effettivamente questo ruolo nell’organizzazione — è un valore dichiarato, come gli altri campi di testo libero in questa pagina.

authority.id

Un identificativo dichiarato di chi ha preso la decisione. Verificato nel codice: se lasciato vuoto, questo campo assume come default il nome e cognome completo dell’utente attualmente loggato — ma può essere modificato, per il caso legittimo di registrare una decisione presa da qualcun altro.

Non ogni decisione registrata in EVIDE è stata presa dalla persona che sta operando la tastiera. Permettere che questo campo sia modificabile consente a una persona di registrare accuratamente una decisione presa da un collega, mantenendo comunque separatamente preservata l’identità verificata della sessione sottostante.

Lascialo vuoto quando tu, l’utente loggato, sei la persona che ha preso la decisione — il tuo nome verrà usato automaticamente. Compilalo esplicitamente quando stai registrando una decisione presa da una persona diversa.

Non trattare questo campo come un sostituto, o una modifica, della tua identità verificata di account — quell’identità è preservata separatamente e automaticamente, indipendentemente da cosa inserisci qui.

Verificato nel codice: ogni record Human Structured porta anche authority.dapi_number, l’identificativo DAPI della sessione effettivamente loggata e autenticata — impostato automaticamente dal server ad ogni invio e mai letto dal modulo. authority.id e authority.dapi_number sono deliberatamente indipendenti: il primo è un’etichetta dichiarata, il secondo è l’identità verificata della sessione.

Un assistente inserisce una decisione in EVIDE per conto di un manager che ha effettivamente preso la decisione. L’assistente lascia autenticata la propria sessione (preservata automaticamente come authority.dapi_number), ma imposta authority_id sul nome del manager, riflettendo accuratamente chi ha realmente preso la decisione.

• authority_id non è la stessa cosa di un’authority verificata in modo indipendente. È un valore dichiarato, testo libero, che per default coincide con l’utente loggato, ma può essere sovrascritto.
• Sovrascrivere questo campo non cambia né sostituisce l’identità DAPI verificata della sessione — quell’identità viene registrata in modo indipendente, in un campo separato, indipendentemente da cosa viene dichiarato qui.

authority.verification

Una nota testuale libera, dichiarata facoltativamente, che la persona che registra la decisione può usare se intende collegare l’authority dichiarata a un riferimento più specifico — ad esempio, un riferimento DAPI per la persona o il ruolo coinvolti.

Dà a chi dichiara un modo per aggiungere un riferimento più specifico all’authority dichiarata, senza richiederne uno su ogni record.

Quando vuoi dichiarare un riferimento più specifico legato all’authority dietro questa decisione, e tale riferimento è genuinamente disponibile.

Non usare questo campo come se scriverlo costituisse una verifica. È una nota dichiarata, non un controllo eseguito da EVIDE.

Un Compliance Officer referenzia un’identità collegata a DAPI interna come contesto di supporto per l’authority dichiarata dietro l’approvazione di un’eccezione, senza che quel riferimento sia controllato in modo indipendente da EVIDE.

• Una nota di verifica compilata non significa che EVIDE abbia eseguito un controllo di identità. Lo stato claimed risultante descrive cosa è stato dichiarato, non cosa è stato verificato.
• Questo campo non ha relazione con l’identità DAPI della sessione effettivamente loggata, che è preservata automaticamente e separatamente (vedi Identificativo dell’Authority).

intervention.classification_status

Rende osservabile la qualità operativa di una classificazione al momento del deposito, invece di presentare ogni classificazione con la stessa fiducia implicita e non dichiarata.

Quando hai una visione di quanto sia consolidata, provvisoria o contestata la classificazione assegnata a questa decisione.

Se non hai una base per giudicare la stabilità della classificazione, è accettabile lasciare questo campo non impostato invece di indovinare — il campo è facoltativo, e il sistema non assume alcuno stato di default se è assente.

intervention.classification_context.threshold_status

Una soglia, in questo contesto, è un criterio decisionale predefinito — un limite di policy, una regola operativa, una condizione di approvazione — rispetto al quale una decisione può essere valutata. Questo campo dichiara se una tale soglia è stata raggiunta.

Espone se una soglia decisionale si applicasse a questo caso, e in tal caso, il suo stato dichiarato — informazione spesso implicita e non documentata negli ordinari strumenti di workflow.

Quando una soglia, regola o condizione di policy definita è rilevante per questa decisione.

Quando nessuna soglia del genere si applica realmente a questa decisione — in quel caso, not_defined è il valore accurato, non semplicemente lasciare il campo vuoto se hai motivo di dichiarare attivamente che nessuna soglia si applica.

• unknown non deve essere letto come equivalente a «nessuna soglia esiste.» È questo che significa not_defined. unknown significa che una soglia si applica, ma il suo stato non ha potuto essere stabilito.

intervention.classification_context.threshold_reference

Un riferimento testuale libero alla soglia, policy o regola specifica citata in threshold_status sopra.

Permette di ricondurre la soglia dichiarata a qualcosa di concreto — un documento di policy, una procedura, un controllo interno — invece di rimanere un’affermazione generale non attribuita.

Quando threshold_status è met, not_met, o unknown, e hai un riferimento specifico disponibile — ad esempio, il nome di una policy, un codice di procedura, o un identificativo di documento, forniti solo come esempi illustrativi compatibili con questo campo di testo libero.

intervention.classification_context.threshold_authority.attribution_status

L’attribuzione della soglia descrive quanto chiaramente l’authority o la proprietà dietro la soglia citata sopra possa essere ricondotta a una persona, ruolo o comitato specifico — non se la soglia stessa sia stata raggiunta.

Diventa rilevante proprio quando uno stato della soglia di met o not_met viene dichiarato, ma la proprietà di quella soglia non è chiaramente attribuibile a un’unica fonte — rendendo quell’ambiguità stessa parte del record preservato.

Quando hai una visione di quanto chiaramente attribuibile sia la proprietà della soglia citata.

intervention.trace.access

Un riferimento testuale libero che permette a qualcuno successivamente di individuare il contesto più ampio di questa decisione all’interno del sistema dove è effettivamente avvenuta — un ticket, un ID di caso, un riferimento di audit trail, un riferimento di log, o un riferimento di workflow, forniti come esempi illustrativi di ciò che è semanticamente compatibile con questo campo.

Una decisione raramente esiste isolata dal più ampio percorso operativo che l’ha circondata. Questo campo preserva un puntatore a quel percorso, senza che EVIDE debba ricevere o memorizzare il percorso stesso.

Ogni volta che esiste un riferimento specifico e individuabile in un altro sistema — un numero di ticket, un fascicolo di caso, o una voce di log di audit — che un revisore successivo potrebbe usare per trovare più contesto.

• Un riferimento di tracciabilità non significa che EVIDE abbia accesso a, o abbia ispezionato, il sistema a cui quel riferimento punta. È un puntatore dichiarato, nient’altro.

handoff.boundary_readiness.status

La prontezza del boundary dichiara quanto questa decisione sia considerata pronta, al momento della chiusura, per la sua preservazione evidenziaria — nello specifico, se un gate di prontezza indipendente l’ha valutata, e cosa quel gate ha potuto e non ha potuto osservare. È una dichiarazione sullo stato di prontezza, non una proprietà che EVIDE stessa misura o conferma.

Decisioni diverse portano gradi molto diversi di prontezza confermata in modo indipendente prima di essere preservate. Comprimere tutte in un unico stato indifferenziato nasconderebbe esattamente l’informazione di cui un revisore successivo ha più bisogno: questa decisione è stata controllata in modo indipendente prima di essere registrata, e se sì, quanto completamente?

Sempre — questo campo è obbligatorio per ogni Human Structured Intake.

Chiediti concretamente: un meccanismo genuinamente separato da chi ha preso la decisione ha valutato la prontezza di questo oggetto prima che fosse registrato? Se nessun meccanismo del genere era coinvolto, il valore onesto è candidate. Se uno era coinvolto, scegli tra verified, verified_partial, o unverifiable in base a quanto genuinamente completa fosse la visibilità di quel meccanismo.

Verificato nel codice: visibility_surface (un campo interno nel payload canonico) è derivato meccanicamente da questo valore attraverso una mappatura fissa — non è mai una scelta separata fatta dalla persona che compila il modulo. Questo valore governa anche se readiness_gate_identifier/readiness_gate_scope_reference e unresolved_signals sono richiesti (vedi Relazioni Condizionali tra i Campi sotto per le regole esatte).

Un responsabile tecnico che autorizza un riavvio di produzione dopo un’anomalia potrebbe dichiarare verified_partial se un gate diagnostico automatizzato ha controllato la maggior parte, ma non tutti, i sensori rilevanti prima del riavvio — con il sensore specifico non controllato registrato come segnale non risolto.

• La parola verified in questo campo è un valore dichiarato nel modello dati, non una valutazione eseguita da EVIDE. EVIDE stessa non controlla se il gate dichiarato abbia effettivamente operato, o se le sue conclusioni fossero accurate.
• Non leggere candidate come un invio carente o incompleto — è il valore strutturalmente accurato ogni volta che nessun gate di prontezza indipendente era genuinamente coinvolto.

handoff.boundary_readiness.readiness_gate.identifier

Un gate, in questo contesto, è qualsiasi meccanismo — umano o automatizzato — che ha eseguito la valutazione di prontezza dichiarata in boundary_readiness_status. Questo campo nomina o identifica quel meccanismo.

Permette di ricondurre la valutazione di prontezza dichiarata a qualcosa di specifico, invece di rimanere un’affermazione generale non attribuita.

Obbligatorio ogni volta che boundary_readiness_status è qualsiasi cosa diversa da candidate — cioè, ogni volta che si dichiara un gate indipendente.

Un controllo diagnostico usato prima di autorizzare un riavvio di produzione, o il codice della procedura interna che governa una revisione di eccezione di compliance.

• Il nome «gate» non implica che EVIDE stessa abbia eseguito, gestito o abbia accesso a questo meccanismo. È un identificativo dichiarato per un meccanismo che ha operato interamente al di fuori di EVIDE.

handoff.boundary_readiness.readiness_gate.scope_reference

Mentre readiness_gate_identifier nomina il meccanismo o controllo dichiarato aver operato, questo campo descrive il perimetro o ambito che quel meccanismo è dichiarato aver coperto.

Un gate nominato è più utile quando anche la sua copertura è specificata — lo stesso controllo diagnostico potrebbe coprire un’intera struttura in un caso e una singola macchina in un altro.

Obbligatorio nella stessa condizione di readiness_gate_identifier sopra: ogni volta che boundary_readiness_status è qualsiasi cosa diversa da candidate.

Distinto da readiness_gate_identifier: uno nomina il meccanismo, l’altro descrive cosa è dichiarato aver coperto.

Per un riavvio di linea di produzione, l’identificatore potrebbe nominare il controllo diagnostico usato, mentre il riferimento di ambito nomina la macchina o linea specifica che quel controllo copriva.

handoff.boundary_readiness.unresolved_signals

Un segnale non risolto è un elemento specifico rimasto irrisolto o non attribuito al momento in cui la valutazione di prontezza è stata fatta — il «perché» dichiarato dietro un risultato verified_partial o unverifiable, non solo il fatto che uno si sia verificato.

Senza questo elenco, un lettore che incontra «Prontezza del boundary: verified_partial» saprebbe che qualcosa era incompleto, ma non cosa — spesso l’informazione singola più utile per una ricostruzione successiva della decisione.

Obbligatorio ogni volta che boundary_readiness_status è verified_partial o unverifiable — almeno una voce è richiesta in quel caso.

Non usato, e normalmente lasciato vuoto, quando lo stato è candidate o verified, poiché in quei casi non viene dichiarata alcuna lacuna irrisolta.

Elenca ogni elemento specifico rimasto irrisolto, nel modo più concreto possibile — sono supportate più voci quando più di un segnale è rimasto aperto.

Direttamente governato da boundary_readiness_status: obbligatorio (minimo una voce) quando quel valore è verified_partial o unverifiable.

Per lo scenario di autorizzazione SOC nei Casi d’Uso Aziendali sopra, questo potrebbe leggere: «Origine di due richieste API non ancora attribuita.»

• EVIDE non determina essa stessa la verità, gravità, materialità o rilevanza di alcun segnale non risolto elencato — preserva l’elenco dichiarato esattamente come inserito, senza valutarne autonomamente il contenuto.