Human Structured Intake - Guide Complet

Documentation › Human Structured Intake

Explorez la documentation — sélectionnez un guide :

Vue d’ensemble

Pourquoi une organisation utiliserait-elle Human Structured Intake ?

La plupart des décisions organisationnelles laissent une trace quelque part — un e-mail, un ticket, un commentaire dans un outil de workflow, une ligne dans un tableur. Cette trace est rarement structurée, rarement ancrée dans le temps de manière inviolable, et rarement conçue pour survivre en dehors du système qui l’a créée. Lorsqu’une décision est remise en question ultérieurement — lors d’un audit, d’un litige, d’une enquête réglementaire ou d’une investigation interne — reconstituer exactement ce qui a été décidé, par qui, dans quel rôle déclaré, et dans quelles conditions, peut être lent, incomplet ou impossible.

Human Structured Intake offre à une personne un moyen structuré de déclarer une décision au moment de sa clôture : le type de décision, qui l’a déclarée et dans quel rôle, quand elle a été clôturée, le contexte de classification et de seuil applicable, si un gate de disponibilité était impliqué, et tout signal resté non résolu. EVIDE canonicalise ensuite cette déclaration, calcule un hachage déterministe sur celle-ci, et la préserve comme un enregistrement récupérable de manière indépendante.

Human Structured Intake préserve le fait qu’une décision a été déclarée — pas que la décision était correcte.

La préservation d’une déclaration n’est pas une validation indépendante de la véracité de cette déclaration.

Cette distinction traverse chaque champ documenté sur cette page. Lorsqu’une valeur utilise un mot comme « verified », ce mot décrit ce qu’une personne ou un mécanisme en amont a déclaré — pas une évaluation effectuée par EVIDE elle-même, sauf indication contraire pour ce champ spécifique.

Avant la Référence des Champs

Cas d’Usage en Entreprise

Les sept scénarios ci-dessous sont des exemples illustratifs de la manière dont différentes fonctions pourraient utiliser Human Structured Intake. Chacun montre le type de décision impliqué, les informations qui pourraient raisonnablement être déclarées et, tout aussi important, la limite de ce que la préservation de cet enregistrement par EVIDE établit et n’établit pas.

Compliance

Approbation d’une exception de conformité

Événement / ContexteUn Compliance Officer est chargé d’autoriser temporairement une exception à une procédure qui serait normalement bloquée, sous pression temporelle et avec une justification commerciale documentée.

Décision HumaineL’officer approuve une exception temporaire et circonscrite, soumise à des conditions spécifiques et à un point de révision défini.

Informations Pouvant Être Déclarées

Type de décision — ex. « Approbation d’exception de conformité »
Rôle de l’autorité — ex. « Compliance Officer »
Statut de classification indiquant à quel point la catégorisation est établie
Statut et référence du seuil — si un seuil de politique interne a été atteint
Attribution du seuil — à quel point la propriété du seuil est attribuable
Disponibilité du boundary — si un gate de disponibilité a confirmé les conditions, ou si l’officer déclare seulement la disponibilité
Référence de traçabilité — une référence au ticket interne ou au dossier

Valeur de ReconstitutionUn examinateur, auditeur ou régulateur ultérieur peut reconstituer que l’exception a été déclarée, par qui, dans quel rôle, sous quelles conditions déclarées de seuil et de disponibilité, sans dépendre de la mémoire de l’officer ou d’un journal système qui pourrait entre-temps avoir été purgé.

Limite de l’affirmation EVIDE : EVIDE préserve que cette décision, avec ce contexte déclaré, a été enregistrée à ce moment. Cela ne détermine pas si l’exception était substantiellement ou juridiquement justifiée.

Cybersécurité / SOC

Autorisation après une alerte de sécurité

Événement / ContexteUn Security Operations Center détecte un comportement anormal. Un intervenant humain examine la télémétrie disponible et doit décider s’il faut autoriser la poursuite de l’opération, bloquer, isoler ou escalader.

Décision HumaineL’intervenant autorise la poursuite de l’opération pendant qu’une enquête est menée, plutôt qu’un isolement immédiat.

Informations Pouvant Être Déclarées

Type de décision — ex. « Autorisation de poursuivre en attendant l’enquête »
Statut de classification — souvent provisional, car l’enquête n’est pas encore clôturée
Disponibilité du boundary — souvent verified_partial, si certains mais pas tous les signaux pertinents ont été examinés
Signaux non résolus — ex. « Origine de deux requêtes API non encore attribuée »
Référence de traçabilité — référence au dossier SOC ou à l’ID de l’alerte

Valeur de ReconstitutionSi l’incident s’aggrave ultérieurement, l’enregistrement préserve exactement ce qui était connu, et ce qui était explicitement signalé comme inconnu, au moment où la décision a été prise, distinguant le recul réel des informations qui étaient réellement disponibles au moment de la décision.

C’est un cas où verified_partial associé à un tableau unresolved_signals renseigné est souvent plus honnête qu’un verified prématuré, en n’utilisant que des valeurs et relations réellement supportées par le validateur.

Limite de l’affirmation EVIDE : EVIDE préserve que l’intervenant a déclaré la poursuite de l’opération sous ces conditions déclarées. Cela ne détermine pas si le système était réellement sécurisé, ni si la décision était le bon jugement de sécurité.

Ressources Humaines

Examen humain d’une recommandation automatisée

Événement / ContexteUn système de présélection assisté par IA produit une recommandation concernant un candidat ou un employé. Un examinateur humain examine cette recommandation et prend la décision finale.

Décision HumaineL’examinateur accepte, modifie ou passe outre la recommandation automatisée.

Informations Pouvant Être Déclarées

Qui a décidé, et dans quel rôle — ex. « HR Director »
Moment exact où la décision a été clôturée
Tout seuil utilisé dans le processus d’examen
Référence à la procédure RH interne qui a régi l’examen
Tout élément resté contesté ou non résolu à la clôture

Valeur de ReconstitutionL’enregistrement aide à préserver une séparation structurelle entre ce que le système automatisé a recommandé et ce que l’être humain a réellement décidé, une distinction souvent difficile à reconstituer a posteriori à partir des seuls journaux système.

Limite de l’affirmation EVIDE : EVIDE préserve qu’une décision humaine a été déclarée comme distincte d’une recommandation automatique. Cela ne certifie pas que l’examen humain était substantiellement adéquat, exempt de biais ou conforme à la loi.

Prévention de la Fraude

Déblocage manuel d’une transaction

Événement / ContexteUn système antifraude bloque une transaction comme à haut risque. Un analyste antifraude examine le dossier et doit décider de la libérer, de la maintenir bloquée ou de l’escalader.

Décision HumaineL’analyste libère la transaction après examen, jugeant le signal de risque comme un faux positif.

Informations Pouvant Être Déclarées

Type de décision — ex. « Libération manuelle de transaction »
Rôle de l’autorité — ex. « Fraud Analyst »
Statut du seuil — si le seuil de risque de fraude ayant déclenché le blocage est déclaré atteint, non atteint ou peu clair à l’examen
Référence de traçabilité — référence au dossier ou à l’ID de la transaction

Valeur de ReconstitutionL’enregistrement préserve le contexte déclaré du contournement humain, qui a autorisé la libération, quand, et sur quelle base déclarée, indépendamment du fait que la transaction se révèle finalement légitime ou non.

Limite de l’affirmation EVIDE : EVIDE préserve que le contournement a été déclaré sous ce contexte déclaré. Cela ne détermine pas si la transaction était, en fait, frauduleuse.

Industrie / Fabrication

Autorisation de redémarrage d’une ligne de production

Événement / ContexteUne ligne de production s’arrête automatiquement après la détection d’une anomalie. Un responsable technique examine les conditions pertinentes et doit décider s’il faut autoriser un redémarrage.

Décision HumaineLe responsable autorise le redémarrage, ayant examiné les informations diagnostiques disponibles.

Informations Pouvant Être Déclarées

Référence du seuil — ex. la procédure technique ou la limite opérationnelle régissant les conditions de redémarrage
Identifiant du gate de disponibilité — ex. le contrôle diagnostique effectué avant d’autoriser le redémarrage
Référence de périmètre du gate de disponibilité — ex. quelle machine ou ligne le contrôle a couverte
Signaux non résolus, si une condition reste incertaine — ex. « Lecture du capteur 4 pas encore recoupée »

Valeur de ReconstitutionSi une défaillance connexe se reproduit ultérieurement, l’enregistrement préserve exactement quel gate diagnostique a été déclaré avoir été contrôlé, et selon quel périmètre, avant que le redémarrage ne soit autorisé.

Si une condition reste incertaine au moment du redémarrage, c’est exactement le cas pour verified_partial avec une liste de signaux non résolus renseignée, plutôt qu’un verified complet.

Limite de l’affirmation EVIDE : EVIDE préserve qu’une autorisation de redémarrage a été déclarée sous ce contexte diagnostique déclaré. Cela ne vérifie pas le résultat diagnostique lui-même, ni ne garantit que la ligne était, en fait, sûre à redémarrer.

Gouvernance de l’IA

Autorisation humaine d’une action d’agent IA

Événement / ContexteUn agent IA demande à effectuer une action sensible. Avant l’exécution, une autorité humaine doit approuver, rejeter, conditionner ou escalader la demande.

Décision HumaineL’autorité humaine approuve l’action demandée, sous réserve de conditions déclarées.

Informations Pouvant Être Déclarées

Type de décision — ex. « Autorisation d’action demandée par un agent »
Rôle de l’autorité de la personne qui autorise
Disponibilité du boundary de l’autorisation elle-même
Référence de traçabilité — référence au journal de la demande de l’agent ou au ticket de gouvernance

Valeur de ReconstitutionHuman Structured Intake enregistre la décision humaine d’autoriser. Ce n’est délibérément pas la même fonction que de déclarer le périmètre opérationnel dans lequel l’agent était autorisé (c’est l’extension distincte des declarations documentée dans la JSON Schema Reference), et ce n’est pas un mécanisme automatique d’autorisation d’exécution.

Limite de l’affirmation EVIDE : EVIDE préserve qu’un être humain a déclaré cette décision d’autorisation, sous ces conditions déclarées. Cela ne vérifie pas que l’agent a effectivement agi dans le périmètre autorisé, et n’autorise ni n’exécute rien elle-même.

Réponse aux Incidents

Décision pendant un incident actif

Événement / ContextePendant un incident de cybersécurité, un intervenant doit choisir entre des actions concurrentes sous pression temporelle, par exemple isoler un serveur plutôt que de maintenir un service opérationnel malgré un indicateur de compromission.

Décision HumaineL’intervenant déclare une action choisie, ainsi que les informations disponibles à ce moment.

Informations Pouvant Être Déclarées

Type de décision — ex. « Décision de confinement d’incident »
Statut de classification, souvent provisional pendant un incident actif
Disponibilité du boundary et tout signal non résolu au moment de la décision
Référence de traçabilité — référence au ticket de l’incident

Valeur de ReconstitutionLes chronologies d’incidents sont fréquemment reconstituées a posteriori sous un examen minutieux. Une déclaration structurée et ancrée dans le temps réduit la dépendance à la reconstitution de l’intention à partir de la mémoire ou de journaux non conçus pour un usage probatoire.

Limite de l’affirmation EVIDE : EVIDE préserve l’état déclaré des informations disponibles au moment de la décision. Cela ne détermine pas, a posteriori, si la décision prise était objectivement la meilleure action possible.

Concept Central

Clôture de la Décision

Deux horodatages différents apparaissent dans chaque enregistrement Human Structured Intake, et ils répondent à deux questions différentes :

Horodatage	À quoi il répond
`decision.closure_timestamp_utc`	Quand la décision elle-même a-t-elle été clôturée ? C’est le moment où la personne déclare que la décision a effectivement été prise — saisi par la personne, en UTC.
Intake Timestamp	Quand EVIDE a-t-il reçu et préservé cet enregistrement ? Ceci est généré par le serveur au moment où l’intake est traité, et non saisi par la personne.

Ces deux moments sont fréquemment différents, et cette différence est attendue, pas une erreur. Une décision pourrait être clôturée à 16h00 et enregistrée dans EVIDE seulement à 18h03 — en raison d’une étape de workflow retardée, d’un processus de soumission par lot, ou simplement parce que la personne qui l’enregistre l’a fait plus tard dans la journée.

Pourquoi cette distinction compte pour la reconstitution historique : si les deux horodatages étaient traités comme interchangeables, un examinateur ultérieur pourrait à tort conclure qu’une décision a été prise au moment où elle a été enregistrée administrativement, plutôt qu’au moment où elle a effectivement été clôturée. Les garder visuellement et textuellement distincts préserve la capacité de reconstituer la véritable séquence des événements.

Ce que cela n’établit pas : decision_closure_timestamp_utc est une valeur déclarée par la personne complétant l’intake. Ce n’est pas un horodatage cryptographique ou « de confiance » du moment où la décision a effectivement eu lieu dans le monde réel — EVIDE n’a aucun moyen indépendant de confirmer que l’heure de clôture déclarée est exacte. Ce qu’EVIDE préserve, indépendamment, c’est l’Intake Timestamp : le moment où l’enregistrement lui-même a été reçu et canonicalisé.

Avant les Champs Probatoires

Champs Communs / Opérationnels de l’Intake

Les sept champs ci-dessous fournissent un contexte opérationnel et organisationnel. Ils sont partagés avec les autres types d’intake d’EVIDE et ne sont pas spécifiques au modèle probatoire Human Structured — ils sont documentés ici brièvement, par souci d’exhaustivité, plutôt qu’avec la même profondeur que les champs de la section suivante.

Champ	Type	Exigence	Ce que c’est
`title`	chaîne	Obligatoire	Étiquette courte de l’enregistrement. Vérifié dans le code : cette valeur est copiée directement dans `decision.summary` dans le payload canonique — ce n’est pas un champ séparé et sans lien.
`business_area_id`	entier	Obligatoire	Le domaine d’activité auquel appartient l’intake. Vérifié dans le code : doit référencer un domaine d’activité existant et actif, sinon la demande est rejetée.
`description`	chaîne	Facultatif	Description en texte libre enregistrée avec le dossier. Non incluse dans le payload probatoire canonique lui-même.
`context_reference`	chaîne	Facultatif	Référence opérationnelle en texte libre pour usage interne.
`notes`	chaîne	Facultatif	Notes internes en texte libre.
`topic`	chaîne	Facultatif	Étiquette de sujet en texte libre pour organiser les intakes.
`case_reference`	chaîne	Facultatif	Référence de dossier ou d’affaire en texte libre. C’est le même champ utilisé par la recherche « Evidence from the same case » disponible ailleurs dans EVIDE.
`evidence_reference`	chaîne	Facultatif	Référence probatoire en texte libre pour les liens croisés internes.

Ces champs fournissent un contexte opérationnel et organisationnel pour localiser et gérer l’intake au sein de la plateforme. Ils ne font pas partie du modèle probatoire Human Structured documenté dans le reste de cette page, et leur présence ou absence n’affecte pas les champs probatoires ci-dessous.

Le Coeur de Ce Guide

Champs Probatoires de Human Structured

Les quatorze champs ci-dessous sont les champs spécifiques au modèle probatoire Human Structured — vérifiés individuellement contre HumanStructuredIntakeService.php. Le tableau donne un résumé rapide ; une fiche explicative complète suit pour chaque champ.

Champ	Type	Exigence
`decision_type`	chaîne	Obligatoire
`decision_closure_timestamp_utc`	datetime	Obligatoire
`authority_role`	chaîne	Obligatoire
`authority_id`	chaîne	Facultatif
`authority_verification_note`	chaîne	Facultatif
`classification_status`	enum	Facultatif
`threshold_status`	enum	Facultatif
`threshold_reference`	chaîne	Conditionnel
`threshold_attribution_status`	enum	Facultatif
`trace_access`	chaîne	Facultatif
`boundary_readiness_status`	enum	Obligatoire
`readiness_gate_identifier`	chaîne	Conditionnel
`readiness_gate_scope_reference`	chaîne	Conditionnel
`unresolved_signals[]`	tableau de chaînes	Conditionnel

Type de Décision decision_type #decision-type

Required chaîne

Chemin Canonique

decision.type

Ce Que Cela Signifie

Une étiquette en texte libre décrivant la catégorie de la décision ou intervention humaine enregistrée — par exemple, de quel type de décision il s’agit, et non ce que la décision a conclu.

Pourquoi Cela Existe

Sans ce champ, un enregistrement n’indiquerait même pas quel type de décision ou d’intervention a été enregistré. Il donne à chaque autre champ de l’enregistrement une catégorie à laquelle se rattacher.

Quand l’Utiliser

Toujours — ce champ est obligatoire pour chaque Human Structured Intake.

Comment Choisir la Valeur

Choisissez une étiquette suffisamment spécifique pour distinguer cette décision d’autres décisions d’un type différent, mais ne dupliquez pas le récit complet qui appartient au champ title (qui devient decision.summary). Un bon type de décision nomme la catégorie d’action ; le title/summary décrit cette instance spécifique.

Relations

Distinct du champ commun title, qui est copié directement dans decision.summary — une courte description en langage naturel de cette décision spécifique. decision_type nomme la catégorie ; decision.summary raconte l’instance.

Exemple d’Entreprise

Un Compliance Officer approuvant une exception temporaire de politique pourrait enregistrer le type de décision comme « Approbation d’exception de conformité. » Un responsable technique autorisant un redémarrage de production pourrait utiliser « Autorisation de redémarrage de ligne de production. »

Valeur d’Exemple

decision_type"Examen humain d’une recommandation automatisée"

Erreurs d’Interprétation Courantes

Ce n’est pas une énumération fixe — le validateur accepte tout texte libre non vide. La cohérence terminologique entre les enregistrements est une discipline organisationnelle, pas une contrainte imposée par le système.
Un type de décision spécifique n’établit pas en soi que la décision a été prise correctement ou de manière appropriée — il nomme seulement de quel type de décision il s’agissait.

Ce Qu’EVIDE Préserve

Qu’une décision de ce type déclaré a été enregistrée, à cette heure de clôture déclarée, par cette autorité déclarée.

Ce Qu’EVIDE N’Affirme Pas

Que le type déclaré provienne d’un vocabulaire contrôlé ou standardisé, comparable entre organisations.

Horodatage de Clôture de Décision (UTC) decision_closure_timestamp_utc #decision-closure-timestamp

Required datetime

Chemin Canonique

decision.closure_timestamp_utc

Ce Que Cela Signifie

Le moment déclaré auquel la décision humaine elle-même a été clôturée — pas le moment où l’enregistrement a été soumis à EVIDE. Voir la section dédiée Clôture de la Décision ci-dessus pour la distinction complète avec l’Intake Timestamp.

Pourquoi Cela Existe

Une décision et sa préservation probatoire se produisent rarement exactement au même instant. Enregistrer l’heure de clôture déclarée, séparément de l’heure d’intake générée par le serveur, est ce qui permet une reconstitution historique précise du moment où la décision a réellement eu lieu.

Quand l’Utiliser

Toujours — ce champ est obligatoire. Saisissez le moment où la décision a effectivement été clôturée, en UTC, et non le moment où vous remplissez le formulaire.

Comment Choisir la Valeur

Utilisez le moment réel de la clôture de la décision, exprimé en UTC plutôt qu’en heure locale. Si vous n’êtes pas sûr de votre décalage UTC local, un outil comme time.is/UTC peut éviter une erreur de plusieurs heures.

Comportement Conditionnel

La valeur doit être une date/heure que le serveur peut interpréter ; une valeur invalide ou vide est explicitement rejetée, plutôt que de revenir silencieusement à l’heure actuelle.

Exemple d’Entreprise

Une ligne de production s’arrête à 14h32 heure locale. Le responsable technique examine les conditions et autorise un redémarrage, clôturant cette décision à 16h00 heure locale — mais n’enregistre l’intake dans EVIDE qu’à 18h03, après avoir terminé d’autres tâches urgentes. L’horodatage de clôture préserve 16h00 (converti en UTC) ; l’Intake Timestamp préserve séparément 18h03.

Valeur d’Exemple

decision_closure_timestamp_utc"2026-04-07T16:00:00Z"

Erreurs d’Interprétation Courantes

Ce n’est pas le moment où l’enregistrement a été reçu par EVIDE — c’est le distinct Intake Timestamp, généré par le serveur.
Saisir l’heure locale sans la convertir en UTC est l’erreur la plus courante avec ce champ, et produit une heure de clôture décalée de votre fuseau UTC local.

Ce Qu’EVIDE Préserve

Le moment déclaré auquel la décision a été clôturée, tel que déclaré par la personne l’enregistrant.

Ce Qu’EVIDE N’Affirme Pas

Que cet horodatage soit un enregistrement cryptographiquement fiable ou vérifié de manière indépendante du moment où la décision réelle s’est produite. C’est une valeur déclarée.

Rôle de l’Autorité authority_role #authority-role

Required chaîne

Chemin Canonique

authority.role

Ce Que Cela Signifie

Le rôle organisationnel, à quel titre, la décision est déclarée avoir été prise — distinct de l’identité de la personne qui l’a prise.

Pourquoi Cela Existe

Un nom seul n’indique pas à quel titre organisationnel une décision a été prise. Le rôle aide un lecteur ultérieur à reconstituer l’autorité organisationnelle déclarée derrière la décision, indépendamment de qui occupait spécifiquement ce rôle à ce moment.

Quand l’Utiliser

Toujours — ce champ est obligatoire pour chaque Human Structured Intake.

Comment Choisir la Valeur

Utilisez le titre du rôle pertinent organisationnellement pour cette décision — ex. « Compliance Officer, » « SOC Manager, » « HR Director, » « Fraud Analyst, » « Plant Manager. » Texte libre, pas une liste fixe.

Relations

Distinct de authority_id (qui) et de l’identité DAPI de la session connectée (voir Identifiant de l’Autorité ci-dessous). Le rôle répond à « à quel titre, » pas « quelle personne spécifique. »

Exemple d’Entreprise

La même personne pourrait occuper plusieurs rôles selon les décisions ; le même rôle pourrait être occupé par différentes personnes au fil du temps. Enregistrer le rôle, séparément de l’individu, garde le contexte organisationnel lisible même lorsque le personnel change.

Valeur d’Exemple

authority_role"Compliance Officer"

Erreurs d’Interprétation Courantes

Ce champ ne vérifie pas que la personne déclarée occupait effectivement ce rôle dans l’organisation — c’est une valeur déclarée, comme les autres champs en texte libre de cette page.

Ce Qu’EVIDE Préserve

Le rôle organisationnel ou le titre déclaré sous lequel la décision a été prise.

Ce Qu’EVIDE N’Affirme Pas

Qu’EVIDE ait confirmé de manière indépendante que la personne occupait ce rôle au sein de l’organisation.

Identifiant de l’Autorité authority_id #authority-id

Optional chaîne

Chemin Canonique

authority.id

Ce Que Cela Signifie

Un identifiant déclaré de qui a pris la décision. Vérifié dans le code : si laissé vide, ce champ prend par défaut le nom complet de l’utilisateur actuellement connecté — mais peut être modifié, pour le cas légitime d’enregistrer une décision prise par quelqu’un d’autre.

Pourquoi Cela Existe

Toute décision enregistrée dans EVIDE n’a pas été prise par la personne opérant le clavier. Permettre la modification de ce champ permet à une personne d’enregistrer avec précision une décision prise par un collègue, tout en gardant séparément préservée l’identité vérifiée de la session sous-jacente.

Quand l’Utiliser

Laissez-le vide lorsque vous, l’utilisateur connecté, êtes la personne qui a pris la décision — votre nom sera utilisé automatiquement. Remplissez-le explicitement lorsque vous enregistrez une décision prise par une personne différente.

Quand Ne Pas l’Utiliser

Ne traitez pas ce champ comme un substitut, ou une modification, de votre identité de compte vérifiée — cette identité est préservée séparément et automatiquement, quoi que vous saisissiez ici.

Relations

Vérifié dans le code : chaque enregistrement Human Structured porte aussi authority.dapi_number, l’identifiant DAPI de la session réellement connectée et authentifiée — défini automatiquement par le serveur à chaque soumission et jamais lu depuis le formulaire. authority.id et authority.dapi_number sont délibérément indépendants : le premier est une étiquette déclarée, le second est l’identité vérifiée de la session.

Exemple d’Entreprise

Un assistant saisit une décision dans EVIDE au nom d’un responsable ayant réellement pris la décision. L’assistant laisse sa propre session authentifiée (préservée automatiquement comme authority.dapi_number), mais définit authority_id sur le nom du responsable, reflétant avec précision qui a réellement pris la décision.

Valeur d’Exemple

authority_id"Jane Whitfield"

Erreurs d’Interprétation Courantes

authority_id n’est pas la même chose qu’une autorité vérifiée de manière indépendante. C’est une valeur déclarée, en texte libre, qui correspond par défaut à l’utilisateur connecté, mais peut être remplacée.
Remplacer ce champ ne change ni ne remplace l’identité DAPI vérifiée de la session — cette identité est enregistrée indépendamment, dans un champ séparé, quoi que soit déclaré ici.

Ce Qu’EVIDE Préserve

L’identifiant déclaré de qui a pris la décision (par défaut le nom de l’utilisateur connecté si non modifié).
Séparément et toujours : l’identité DAPI de la session authentifiée réelle, dans authority.dapi_number.

Ce Qu’EVIDE N’Affirme Pas

Que la valeur déclarée authority.id ait elle-même été vérifiée de manière indépendante par rapport à un système d’identité externe.

Note de Vérification de l’Autorité authority_verification_note #authority-verification-note

Optional chaîne

Chemin Canonique

authority.verification

Ce Que Cela Signifie

Une note en texte libre, déclarée facultativement, que la personne enregistrant la décision peut utiliser si elle entend lier l’autorité déclarée à une référence plus spécifique — par exemple, une référence DAPI pour la personne ou le rôle impliqué.

Pourquoi Cela Existe

Cela donne au déclarant un moyen d’ajouter une référence plus spécifique à l’autorité déclarée, sans en exiger une sur chaque enregistrement.

Quand l’Utiliser

Lorsque vous souhaitez déclarer une référence plus spécifique liée à l’autorité derrière cette décision, et qu’une telle référence vous est réellement disponible.

Quand Ne Pas l’Utiliser

N’utilisez pas ce champ comme si l’écrire constituait une vérification. C’est une note déclarée, pas un contrôle effectué par EVIDE.

Comportement Conditionnel

Vérifié dans le code : si ce champ est présent et non vide, la valeur authority_verification_status calculée côté serveur dans la réponse API devient claimed au lieu de declared — documenté intégralement dans la JSON Schema Reference. Cela reflète qu’une référence a été déclarée, pas qu’elle a été vérifiée.

Exemple d’Entreprise

Un Compliance Officer référence une identité liée à un DAPI interne comme contexte de soutien pour l’autorité déclarée derrière l’approbation d’une exception, sans que cette référence soit contrôlée de manière indépendante par EVIDE.

Erreurs d’Interprétation Courantes

Une note de vérification renseignée ne signifie pas qu’EVIDE a effectué un contrôle d’identité. Le statut claimed résultant décrit ce qui a été déclaré, pas ce qui a été vérifié.
Ce champ n’est pas lié à l’identité DAPI de la session réellement connectée, qui est préservée automatiquement et séparément (voir Identifiant de l’Autorité).

Ce Qu’EVIDE Préserve

Qu’une note liée à la vérification a été déclarée, exactement telle que saisie.

Ce Qu’EVIDE N’Affirme Pas

Que la note déclarée constitue, ou résulte, d’une vérification d’identité indépendante effectuée par EVIDE.

Stabilité de la Classification classification_status #classification-status

Optional enum

Chemin Canonique

intervention.classification_status

Valeurs Autorisées

stable

La classification attribuée à cette décision est considérée comme établie, sans ambiguïté connue selon la catégorisation active au moment de la clôture.
Exemple : un cas de fraude examiné et clôturé avec une catégorisation claire et non contestée.
Ne signifie pas : que la classification est fixée de manière permanente ou immunisée contre une révision future — seulement qu’aucune ambiguïté n’était connue à la clôture.

provisional

La classification est encore provisoire ou en attente d’affinement — elle peut changer à mesure que davantage d’informations deviennent disponibles.
Exemple : une enquête de sécurité active où la catégorie de l’incident peut être révisée à mesure que l’enquête se poursuit.
Ne signifie pas : que la décision elle-même est incomplète — la décision peut toujours être finalisée alors que sa classification reste provisoire.

contested

La classification est attribuée malgré un désaccord interprétatif connu, ou un chevauchement avec une autre catégorie.
Exemple : une décision où deux personnes raisonnables pourraient catégoriser le même cas différemment, et ce désaccord est connu à la clôture.
Ne signifie pas : que la décision sous-jacente est invalide — seulement que sa catégorisation porte une tension interprétative reconnue.

Pourquoi Cela Existe

Cela rend observable la qualité opérationnelle d’une classification au moment du dépôt, plutôt que de présenter chaque classification avec une confiance égale et non exprimée.

Quand l’Utiliser

Lorsque vous avez un avis sur le degré d’établissement, de provisoire ou de contestation de la classification attribuée à cette décision.

Quand Ne Pas l’Utiliser

Si vous n’avez aucune base pour juger de la stabilité de la classification, il est acceptable de laisser ce champ non défini plutôt que de deviner — le champ est facultatif, et le système ne suppose aucun état par défaut en son absence.

Valeur d’Exemple

classification_status"provisional"

Ce Qu’EVIDE Préserve

L’état de stabilité déclaré de la classification attribuée à cette décision.

Ce Qu’EVIDE N’Affirme Pas

Que la classification elle-même soit correcte — seulement à quel point son attribution a été déclarée établie ou contestée.

Statut du Seuil threshold_status #threshold-status

Optional enum

Chemin Canonique

intervention.classification_context.threshold_status

Valeurs Autorisées

met

Un seuil de décision pertinent est déclaré avoir été atteint.
Exemple : une politique interne exigeait une justification documentée au-dessus d’un certain niveau de risque, et celle-ci a été fournie.

not_met

Un seuil de décision pertinent est déclaré ne pas avoir été atteint.
Exemple : l’examen a révélé que les conditions requises pour l’approbation automatique n’étaient pas satisfaites, nécessitant une intervention manuelle.

unknown

Un seuil existe dans ce contexte, mais s’il a été atteint n’est pas connu au moment de la clôture. Ceci est différent de not_defined — ici, un seuil s’applique réellement, mais son statut n’a pas pu être établi.

not_defined

Aucun seuil n’a été défini pour ce cas. Ceci est différent de unknown — ici, il n’y a pas de seuil applicable à évaluer, plutôt qu’un seuil non résolu.

Ce Que Cela Signifie

Un seuil, dans ce contexte, est un critère de décision prédéfini — une limite de politique, une règle opérationnelle, une condition d’approbation — par rapport auquel une décision peut être évaluée. Ce champ déclare si un tel seuil a été atteint.

Pourquoi Cela Existe

Cela expose si un seuil de décision s’appliquait à ce cas, et si oui, son statut déclaré — une information souvent implicite et non documentée dans les outils de workflow ordinaires.

Quand l’Utiliser

Lorsqu’un seuil, une règle ou une condition de politique définie est pertinent pour cette décision.

Quand Ne Pas l’Utiliser

Lorsqu’aucun seuil de ce type ne s’applique réellement à cette décision — dans ce cas, not_defined est la valeur exacte, et non simplement laisser le champ vide si vous avez des raisons de déclarer activement qu’aucun seuil ne s’applique.

Comportement Conditionnel

Vérifié dans le code : ce champ régit la visibilité de threshold_reference ci-dessous — si threshold_status est not_defined, toute valeur saisie dans threshold_reference est silencieusement supprimée par le serveur, même si elle est soumise.

Valeur d’Exemple

threshold_status"met"

Erreurs d’Interprétation Courantes

unknown ne doit pas être lu comme équivalent à « aucun seuil n’existe. » C’est ce que signifie not_defined. unknown signifie qu’un seuil s’applique, mais que son statut n’a pas pu être établi.

Ce Qu’EVIDE Préserve

Le statut déclaré d’un seuil de décision pertinent pour ce cas.

Ce Qu’EVIDE N’Affirme Pas

Qu’EVIDE ait évalué de manière indépendante si le seuil a effectivement été atteint — ceci est un statut déclaré.

Référence du Seuil threshold_reference #threshold-reference

Conditional chaîne

Chemin Canonique

intervention.classification_context.threshold_reference

Ce Que Cela Signifie

Une référence en texte libre au seuil, à la politique ou à la règle spécifique citée dans threshold_status ci-dessus.

Pourquoi Cela Existe

Cela permet de relier le seuil déclaré à quelque chose de concret — un document de politique, une procédure, un contrôle interne — plutôt que de rester une affirmation générale non attribuée.

Quand l’Utiliser

Lorsque threshold_status est met, not_met, ou unknown, et que vous avez une référence spécifique disponible — par exemple, un nom de politique, un code de procédure, ou un identifiant de document, donnés uniquement comme exemples illustratifs compatibles avec ce champ de texte libre.

Comportement Conditionnel

Vérifié dans le code : si threshold_status est not_defined, ce champ est supprimé par le serveur même si une valeur est soumise. Il n’est pas nécessaire de le laisser vide par précaution — le serveur l’impose de toute façon, mais c’est une bonne pratique de le laisser vide lorsqu’aucun seuil n’est défini.

Valeur d’Exemple

threshold_reference"Politique interne COM-EXC-04, section 3.2"

Ce Qu’EVIDE Préserve

La référence déclarée au seuil spécifique cité, lorsqu’un statut de seuil autre que not_defined s’applique.

Ce Qu’EVIDE N’Affirme Pas

Que le document, la politique ou la procédure référencée ait été récupéré, lu ou validé de manière indépendante par EVIDE.

Attribution du Seuil threshold_attribution_status #threshold-attribution

Optional enum

Chemin Canonique

intervention.classification_context.threshold_authority.attribution_status

Valeurs Autorisées

attributed

Une autorité unique, identifiable et attribuable pour le seuil a été définie à la clôture.
Exemple : une politique explicitement détenue par un comité nommé.
Quand l’utiliser : lorsque vous pouvez désigner un propriétaire clair unique du seuil.

fragmented

Le seuil est défini à travers plusieurs sources, sans autorité unique attribuable.
Exemple : une règle assemblée à partir de plusieurs documents de lignes directrices internes se chevauchant sans propriétaire unique.
Erreur d’interprétation courante : fragmented ne signifie pas que le seuil est invalide — seulement que sa propriété est distribuée.

implicit

Le seuil est présent dans la pratique mais n’était pas formellement défini ou attribuable à la clôture.
Exemple : une norme interne non écrite mais appliquée de manière constante.
Erreur d’interprétation courante : implicit ne signifie pas que les seuils informels sont illégitimes — seulement qu’ils manquent d’attribution formelle.

unknown

L’autorité derrière le seuil n’a pas pu être vérifiée au moment de la clôture.
Exemple : le déclarant est conscient qu’un seuil existe mais ne peut pas identifier qui le possède.

Ce Que Cela Signifie

L’attribution du seuil décrit à quel point l’autorité ou la propriété derrière le seuil cité ci-dessus peut être retracée vers une personne, un rôle ou un comité spécifique — pas si le seuil lui-même a été atteint.

Pourquoi Cela Existe

Cela devient pertinent précisément lorsqu’un statut de seuil met ou not_met est déclaré, mais que la propriété de ce seuil n’est pas clairement attribuable à une source unique — faisant de cette ambiguïté elle-même une partie de l’enregistrement préservé.

Quand l’Utiliser

Lorsque vous avez un avis sur le degré d’attribution claire de la propriété du seuil cité.

Valeur d’Exemple

threshold_attribution_status"attributed"

Ce Qu’EVIDE Préserve

L’état déclaré d’attribuabilité de l’autorité derrière le seuil cité.

Ce Qu’EVIDE N’Affirme Pas

Qui devrait posséder le seuil, ou que la substance du seuil ait été examinée de manière indépendante — seulement si une source d’autorité attribuable pour celui-ci a été déclarée exister.

Référence de Traçabilité trace_access #trace-access

Optional chaîne

Chemin Canonique

intervention.trace.access

Ce Que Cela Signifie

Une référence en texte libre permettant à quelqu’un ultérieurement de localiser le contexte plus large de cette décision au sein du système où elle s’est effectivement produite — un ticket, un ID de dossier, une référence de piste d’audit, une référence de journal, ou une référence de workflow, donnés comme exemples illustratifs de ce qui est sémantiquement compatible avec ce champ.

Pourquoi Cela Existe

Une décision existe rarement isolée du parcours opérationnel plus large qui l’entourait. Ce champ préserve un pointeur vers ce parcours, sans qu’EVIDE ait besoin de recevoir ou de stocker le parcours lui-même.

Quand l’Utiliser

Chaque fois qu’une référence spécifique et localisable existe dans un autre système — un numéro de ticket, un dossier, ou une entrée de journal d’audit — qu’un examinateur ultérieur pourrait utiliser pour trouver plus de contexte.

Valeur d’Exemple

trace_access"SOC-CASE-4471"

Erreurs d’Interprétation Courantes

Une référence de traçabilité ne signifie pas qu’EVIDE a accès au, ou a inspecté le, système vers lequel cette référence pointe. C’est un pointeur déclaré, rien de plus.

Ce Qu’EVIDE Préserve

La référence déclarée pour localiser davantage de contexte sur cette décision.

Ce Qu’EVIDE N’Affirme Pas

Qu’EVIDE ait accès au, ait récupéré, ou ait vérifié le contenu du système référencé.

Disponibilité du Boundary boundary_readiness_status #boundary-readiness

Required enum

Chemin Canonique

handoff.boundary_readiness.status

Valeurs Autorisées

candidate

Aucun gate indépendant n’a évalué cet objet. La partie déclarante affirme seulement le considérer prêt, sans qu’un contrôle indépendant ait été effectué.
Quand le choisir : c’est la valeur honnête par défaut lorsqu’aucun mécanisme de disponibilité séparé n’était impliqué — ce n’est pas une valeur plus faible ou moindre, c’est la valeur exacte pour cette situation.

verified

Un gate de disponibilité indépendant a confirmé la stabilité à travers ce qu’il déclare être une visibilité complète, sans signaux non résolus.
Quand le choisir : uniquement lorsqu’un mécanisme réellement séparé — distinct de la personne ou du système ayant pris la décision — a effectué cette évaluation.
Erreur d’interprétation courante : cette valeur ne peut pas être auto-déclarée simplement en se sentant confiant à propos d’une décision ; elle signifie spécifiquement qu’un gate indépendant était impliqué.

verified_partial

Un gate indépendant a confirmé ce qu’il a pu observer, mais déclare explicitement que certains signaux pertinents restent non résolus.
Quand le choisir : lorsqu’un gate de disponibilité était impliqué mais que sa visibilité était réellement incomplète — nécessite au moins une entrée dans unresolved_signals.

unverifiable

Un gate de disponibilité a tenté une évaluation, mais la visibilité à sa disposition était insuffisante pour atteindre une quelconque conclusion de stabilité. Cela démontre que la diligence a été tentée, pas que le processus a échoué.
Quand le choisir : lorsqu’une tentative réelle d’évaluation de disponibilité n’a pas pu aboutir à une conclusion en raison d’une visibilité insuffisante — nécessite également au moins une entrée dans unresolved_signals.

Ce Que Cela Signifie

La disponibilité du boundary déclare à quel point cette décision est considérée comme prête, au moment de la clôture, pour sa préservation probatoire — spécifiquement, si un gate de disponibilité indépendant l’a évaluée, et ce que ce gate a pu et n’a pas pu observer. C’est une déclaration sur l’état de disponibilité, pas une propriété qu’EVIDE mesure ou confirme elle-même.

Pourquoi Cela Existe

Différentes décisions portent des degrés très différents de disponibilité confirmée de manière indépendante avant d’être préservées. Les regrouper toutes en un seul état non différencié cacherait exactement l’information dont un examinateur ultérieur a le plus besoin : cette décision a-t-elle été contrôlée de manière indépendante avant d’être enregistrée, et si oui, avec quelle complétude ?

Quand l’Utiliser

Toujours — ce champ est obligatoire pour chaque Human Structured Intake.

Comment Choisir la Valeur

Demandez-vous concrètement : un mécanisme réellement séparé du décideur a-t-il évalué la disponibilité de cet objet avant qu’il ne soit enregistré ? Si aucun mécanisme de ce type n’était impliqué, la valeur honnête est candidate. Si un mécanisme était impliqué, choisissez entre verified, verified_partial, ou unverifiable selon le degré réel de complétude de la visibilité de ce mécanisme.

Relations

Vérifié dans le code : visibility_surface (un champ interne dans le payload canonique) est dérivé mécaniquement de cette valeur par une correspondance fixe — ce n’est jamais un choix séparé fait par la personne remplissant le formulaire. Cette valeur régit aussi si readiness_gate_identifier/readiness_gate_scope_reference et unresolved_signals sont requis (voir Relations Conditionnelles entre Champs ci-dessous pour les règles exactes).

Comportement Conditionnel

Si cette valeur est autre que candidate, readiness_gate_identifier et readiness_gate_scope_reference deviennent tous deux obligatoires ensemble. Si cette valeur est verified_partial ou unverifiable, au moins une entrée dans unresolved_signals devient obligatoire.

Exemple d’Entreprise

Un responsable technique autorisant un redémarrage de production après une anomalie pourrait déclarer verified_partial si un gate diagnostique automatisé a contrôlé la plupart, mais pas tous, les capteurs pertinents avant le redémarrage — le capteur spécifique non contrôlé étant enregistré comme signal non résolu.

Valeur d’Exemple

boundary_readiness_status"verified_partial"

Erreurs d’Interprétation Courantes

Le mot verified dans ce champ est une valeur déclarée dans le modèle de données, pas une évaluation effectuée par EVIDE. EVIDE elle-même ne vérifie pas si le gate déclaré a effectivement fonctionné, ni si ses conclusions étaient exactes.
Ne lisez pas candidate comme une soumission déficiente ou incomplète — c’est la valeur structurellement exacte chaque fois qu’aucun gate de disponibilité indépendant n’était réellement impliqué.

Ce Qu’EVIDE Préserve

L’état de disponibilité déclaré au boundary, et, le cas échéant, une référence au mécanisme déclaré ayant effectué l’évaluation.

Ce Qu’EVIDE N’Affirme Pas

Qu’EVIDE elle-même ait effectué, confirmé ou vérifié de manière indépendante une quelconque évaluation de disponibilité. Une valeur verified décrit ce qui a été déclaré concernant un gate en amont ou indépendant — ce n’est jamais la propre vérification d’EVIDE de la décision.

Identifiant du Gate de Disponibilité readiness_gate_identifier #readiness-gate-identifier

Conditional chaîne

Chemin Canonique

handoff.boundary_readiness.readiness_gate.identifier

Ce Que Cela Signifie

Un gate, dans ce contexte, est tout mécanisme — humain ou automatisé — ayant effectué l’évaluation de disponibilité déclarée dans boundary_readiness_status. Ce champ nomme ou identifie ce mécanisme.

Pourquoi Cela Existe

Cela permet de relier l’évaluation de disponibilité déclarée à quelque chose de spécifique, plutôt que de rester une affirmation générale non attribuée.

Quand l’Utiliser

Obligatoire chaque fois que boundary_readiness_status est autre que candidate — c’est-à-dire, chaque fois qu’un gate indépendant est déclaré.

Comportement Conditionnel

Vérifié dans le code : obligatoire avec readiness_gate_scope_reference chaque fois que boundary_readiness_status n’est pas candidate. Si l’un des deux manque dans cette condition, la demande est rejetée. Aucun des deux champs n’est demandé lorsque le statut est candidate.

Exemple d’Entreprise

Un contrôle diagnostique utilisé avant d’autoriser un redémarrage de production, ou le code de procédure interne régissant un examen d’exception de conformité.

Valeur d’Exemple

readiness_gate_identifier"COM-EXC-04"

Erreurs d’Interprétation Courantes

Le nom « gate » n’implique pas qu’EVIDE elle-même ait exécuté, géré ou ait accès à ce mécanisme. C’est un identifiant déclaré pour un mécanisme ayant fonctionné entièrement en dehors d’EVIDE.

Ce Qu’EVIDE Préserve

L’identifiant déclaré du mécanisme ayant effectué l’évaluation de disponibilité.

Ce Qu’EVIDE N’Affirme Pas

Qu’EVIDE ait exécuté, inspecté ou vérifié de manière indépendante le mécanisme nommé.

Référence de Périmètre du Gate de Disponibilité readiness_gate_scope_reference #readiness-gate-scope

Conditional chaîne

Chemin Canonique

handoff.boundary_readiness.readiness_gate.scope_reference

Ce Que Cela Signifie

Alors que readiness_gate_identifier nomme le mécanisme ou contrôle déclaré avoir fonctionné, ce champ décrit le périmètre ou la portée que ce mécanisme est déclaré avoir couvert.

Pourquoi Cela Existe

Un gate nommé est plus utile lorsque sa couverture est également spécifiée — le même contrôle diagnostique pourrait couvrir un site entier dans un cas et une seule machine dans un autre.

Quand l’Utiliser

Obligatoire dans la même condition que readiness_gate_identifier ci-dessus : chaque fois que boundary_readiness_status est autre que candidate.

Relations

Distinct de readiness_gate_identifier : l’un nomme le mécanisme, l’autre décrit ce qu’il est déclaré avoir couvert.

Exemple d’Entreprise

Pour un redémarrage de ligne de production, l’identifiant pourrait nommer le contrôle diagnostique utilisé, tandis que la référence de périmètre nomme la machine ou ligne spécifique que ce contrôle couvrait.

Valeur d’Exemple

readiness_gate_scope_reference"Ligne 3, module d’extrusion"

Ce Qu’EVIDE Préserve

Le périmètre ou la portée déclarée que le gate de disponibilité nommé est déclaré avoir couvert.

Ce Qu’EVIDE N’Affirme Pas

Que le périmètre déclaré ait été confirmé de manière indépendante comme exact ou complet.

Signaux Non Résolus unresolved_signals[] #unresolved-signals

Conditional tableau de chaînes

Chemin Canonique

handoff.boundary_readiness.unresolved_signals

Ce Que Cela Signifie

Un signal non résolu est un élément spécifique resté non résolu ou non attribué au moment où l’évaluation de disponibilité a été effectuée — le « pourquoi » déclaré derrière un résultat verified_partial ou unverifiable, pas seulement le fait qu’un tel résultat se soit produit.

Pourquoi Cela Existe

Sans cette liste, un lecteur rencontrant « Disponibilité du boundary : verified_partial » saurait que quelque chose était incomplet, mais pas quoi — souvent l’information la plus utile pour une reconstitution ultérieure de la décision.

Quand l’Utiliser

Obligatoire chaque fois que boundary_readiness_status est verified_partial ou unverifiable — au moins une entrée est requise dans ce cas.

Quand Ne Pas l’Utiliser

Non utilisé, et normalement laissé vide, lorsque le statut est candidate ou verified, car dans ces cas aucune lacune non résolue n’est déclarée.

Comment Choisir la Valeur

Énumérez chaque élément spécifique resté non résolu, aussi concrètement que possible — plusieurs entrées sont prises en charge lorsque plus d’un signal est resté ouvert.

Relations

Directement régi par boundary_readiness_status : obligatoire (minimum une entrée) lorsque cette valeur est verified_partial ou unverifiable.

Comportement Conditionnel

Vérifié dans le code : si boundary_readiness_status est verified_partial ou unverifiable et que ce tableau est vide, la demande est rejetée.

Exemple d’Entreprise

Pour le scénario d’autorisation SOC dans les Cas d’Usage en Entreprise ci-dessus, cela pourrait indiquer : « Origine de deux requêtes API non encore attribuée. »

Valeur d’Exemple

unresolved_signals[]["Origine de deux requêtes API non encore attribuée"]

Erreurs d’Interprétation Courantes

EVIDE ne détermine pas elle-même la véracité, la gravité, la matérialité ou la pertinence d’un signal non résolu listé — elle préserve la liste déclarée exactement telle que saisie, sans en évaluer le contenu de manière autonome.

Ce Qu’EVIDE Préserve

Les signaux spécifiques déclarés comme non résolus au moment de l’évaluation de disponibilité.

Ce Qu’EVIDE N’Affirme Pas

Qu’EVIDE ait évalué la véracité, la gravité, la matérialité ou la pertinence d’un signal listé. Elle préserve la déclaration, pas un jugement à son sujet.

Comment les Champs s’Articulent

Relations Conditionnelles entre Champs

Les règles ci-dessous sont vérifiées directement par rapport au validateur dans HumanStructuredIntakeService.php — pas supposées à partir des noms de champs ou de schémas de documentation généraux.

Si…	Alors…
`threshold_status` = `not_defined`	Toute valeur soumise dans `threshold_reference` est supprimée par le serveur, même si elle est présente dans la demande.
`boundary_readiness_status` ≠ `candidate`	`readiness_gate_identifier` ET `readiness_gate_scope_reference` deviennent tous deux obligatoires ensemble. Si l’un des deux manque, la demande est rejetée.
`boundary_readiness_status` ∈ {`verified_partial`, `unverifiable`}	`unresolved_signals[]` devient obligatoire, avec un minimum d’une entrée. Un tableau vide est rejeté sous cette condition.
Une entrée `evidence_references[]` inclut un `hash_value`	`hash_scope` et `hashed_by` deviennent tous deux obligatoires ensemble pour cette entrée. Une déclaration de hachage partielle — une valeur sans les deux — est rejetée.

Un fait connexe, non conditionnel, qu’il vaut la peine de noter ici : visibility_surface, un champ interne dans le payload canonique, est toujours dérivé mécaniquement de boundary_readiness_status par une correspondance fixe. Ce n’est jamais une valeur choisie directement par la personne remplissant le formulaire.

Référencer Ce qu’EVIDE Ne Détient Pas

Références Externes de Preuve

Une référence externe de preuve permet à un Human Structured Intake de pointer vers un artefact — un document, une capture d’écran, un fichier journal, une politique — qui reste sous le contrôle de l’organisation elle-même, sans que cet artefact ne soit jamais téléchargé vers ou détenu par EVIDE. Vérifié dans le code : cela réutilise, sans modification, la structure exacte evidence_references[] déjà documentée dans la JSON Schema Reference — pas un mécanisme parallèle ou spécifique à Human.

Cela compte car cela résout une tension réelle et courante : une organisation a souvent besoin de préserver une déclaration vérifiable sur une décision, tout en évitant délibérément de remettre un document interne sensible à un système externe. Les références externes de preuve permettent aux deux de se produire en même temps.

Exemple d’entreprise. Un Compliance Officer fonde une décision sur un document interne, POLICY-CREDIT-REV7. L’organisation garde ce document sous son propre contrôle. L’Human Structured Intake peut préserver une référence déclarée à cette politique et, si disponible, son empreinte SHA-256 — sans qu’EVIDE ne reçoive jamais le document lui-même.

Champs Disponibles Par Référence (tous individuellement facultatifs)

`artifact_type`	Type déclaré en texte libre — ex. `screenshot`, `pdf`, `policy_document`. Pas une énumération fixe.
`pointer`	Une référence spécifique à l’implémentation vers l’emplacement de l’artefact. EVIDE ne la résout pas, ne la déréférence pas, ni ne la récupère.
`declared_origin`	Description en texte libre de la provenance de l’artefact.
`declared_relationship`	Description en texte libre de la relation entre l’artefact et cette décision.
`declared_description`	Description en texte libre lisible par un humain.
`declared_retention_status`	Un parmi `persistent_storage`, `rolling_buffer`, `unknown`. Vérifié dans le code : jamais défini automatiquement par défaut — inclus uniquement si la personne le sélectionne activement.

Empreinte Facultative (SHA-256)

Une référence peut optionnellement porter une empreinte SHA-256 déclarée de l’artefact. Voir la section dédiée SHA-256 ci-dessous pour ce que cela établit exactement et ce que cela n’établit pas.

Référencer l’Intégrité d’un Artefact

SHA-256

SHA-256 est une fonction de hachage cryptographique : elle prend n’importe quel fichier et produit de manière déterministe une empreinte de longueur fixe telle que même un tout petit changement dans le fichier produit une empreinte complètement différente. Dans une référence externe de preuve, une empreinte SHA-256 déclarée permet à une partie ultérieure détenant l’artefact réel de vérifier s’il correspond à ce qui a été déclaré au moment de l’intake.

Comment cela est utilisé en pratique : une empreinte déclarée peut ultérieurement être comparée à une empreinte calculée fraîchement sur un artefact disponible. Si elles correspondent, l’artefact n’a pas changé depuis que l’empreinte a été déclarée. Si elles ne correspondent pas, soit l’artefact a changé, soit ce n’est pas le même fichier qui était initialement référencé.

Vérifié dans le code : la validation du hachage sur ce canal est purement syntaxique — le serveur confirme que la valeur déclarée comporte exactement 64 caractères hexadécimaux, rien de plus. EVIDE ne reçoit pas l’artefact et ne peut pas vérifier si l’empreinte déclarée lui correspond réellement. La valeur déclarée est préservée exactement telle que saisie, jamais normalisée en majuscules ou minuscules.

Ce Qu’une Empreinte Déclarée Établit

Que cette empreinte spécifique a été déclarée, par la personne soumettant l’intake, à ce moment spécifique.
Une base pour une comparaison ultérieure et indépendante avec un artefact détenu par quelqu’un d’autre.

Ce Qu’une Empreinte Déclarée N’Établit Pas

La paternité de l’artefact.
La provenance de l’artefact.
La véracité ou l’exactitude substantielle du contenu de l’artefact.
La validité juridique, la propriété, ou l’originalité.
Qu’EVIDE ait possédé, inspecté ou vérifié l’artefact — il est resté externe en permanence.

La distinction qui compte se situe entre cinq choses distinctes : l’artefact externe lui-même (jamais reçu par EVIDE) ; la référence déclarée vers celui-ci ; l’empreinte déclarée (facultative, vérifiée seulement syntaxiquement) ; une comparaison de hachage ultérieure que quelqu’un d’autre pourrait effectuer ; et la préservation de la déclaration par EVIDE — la seule de ces cinq choses qu’EVIDE effectue réellement.

Limite de l’Affirmation

Ce Qu’EVIDE Préserve

Le principe général : préservation structurée de la déclaration et de son contexte probatoire déclaré associé, exactement tel que soumis, canonicalisé et haché de manière déterministe et inviolable.

Concrètement, Lorsque Présents

Le type de décision déclaré et l’heure de clôture.
Le contexte d’autorité déclaré — rôle, identifiant déclaré, et l’identité DAPI vérifiée de la session soumettant.
La classification déclarée et son statut de stabilité.
Le contexte du seuil déclaré et son statut d’attribution.
La référence de traçabilité déclarée.
L’état de disponibilité du boundary déclaré et toute information de gate associée.
Tout signal non résolu déclaré.
Toute référence externe de preuve déclarée, y compris une empreinte déclarée facultative.

À Lire Avant de Se Fier à Tout Enregistrement

Ce Qu’EVIDE N’Affirme Pas

EVIDE ne détermine pas si la décision humaine était correcte.
EVIDE ne valide pas automatiquement la véracité de chaque champ déclaré.
Une référence externe de preuve déclarée ne signifie pas qu’EVIDE a inspecté l’artefact externe.
Une empreinte SHA-256 n’établit pas en soi la paternité.
Une empreinte SHA-256 n’établit pas en soi la provenance.
Une empreinte SHA-256 n’établit pas la véracité ou l’exactitude substantielle.
Enregistrer des informations d’autorité ne signifie pas automatiquement qu’EVIDE a vérifié de manière indépendante l’autorité organisationnelle déclarée.
Une valeur de champ contenant des termes tels que « verified » ne doit pas être interprétée comme une vérification indépendante d’EVIDE, sauf si l’implémentation fournit explicitement une telle vérification.

Assembler le Tout

Exemple d’Entreprise Complet

Reprenons le scénario Compliance des Cas d’Usage en Entreprise : une Compliance Officer, Jane Whitfield, est chargée d’approuver une exception temporaire à la checklist standard d’intégration des fournisseurs, sous une justification commerciale documentée et un point de révision défini.

Elle clôture la décision à 16h00 UTC, mais n’enregistre l’intake que plus tard, à 18h03 UTC, après avoir terminé un appel. Elle déclare son rôle comme Compliance Officer, référence la politique interne régissant les exceptions de ce type, et note qu’un comité de révision interne — un mécanisme indépendant de sa propre décision — a confirmé les conditions pertinentes avec une visibilité complète avant qu’elle ne prenne sa décision. Elle référence le ticket interne suivant cette exception, et déclare séparément un document de politique avec son empreinte SHA-256, conservé en interne plutôt que téléchargé vers EVIDE.

Chaque valeur ci-dessous est choisie pour être cohérente en interne et compatible avec les règles conditionnelles documentées ci-dessus — les champs sont inclus parce qu’ils correspondent à ce cas spécifique, pas simplement pour démontrer que chaque champ existe.

Le Payload Résultant

Exemple JSON / Payload

Voici le payload canonique qu’EVIDE construit à partir de l’exemple ci-dessus — vérifié champ par champ par rapport à HumanStructuredIntakeService.php. Les champs générés automatiquement par le serveur (jamais lus depuis le formulaire) sont marqués en conséquence.

"evide_schema": "2.1",
"source_system": "evide_web_human",               // généré par le serveur, fixe pour ce canal
"source_reference": "web:1042:a3f91c2d",          // généré par le serveur
"source_timestamp_utc": "2026-04-07T18:03:00Z",  // généré par le serveur -- quand EVIDE a traité cet intake

"decision": {
  "type": "Compliance exception approval",
  "status": "finalized",                    // toujours fixe sur ce canal
  "closure_timestamp_utc": "2026-04-07T16:00:00Z", // déclaré -- voir Clôture de la Décision ci-dessus
  "summary": "Temporary exception to vendor onboarding checklist" // copié depuis le champ commun "title"
},

"authority": {
  "id": "Jane Whitfield",                     // déclaré (par défaut l'utilisateur connecté si vide)
  "role": "Compliance Officer",
  "dapi_number": "DAPI-2K9-XXXX",               // toujours généré par le serveur depuis la session, jamais depuis le formulaire
  "verification": "Linked to internal DAPI reference for the review board"
},

"intervention": {
  "classification_status": "stable",
  "classification_context": {
    "threshold_status": "met",
    "threshold_reference": "Internal policy COM-EXC-04, section 3.2",
    "threshold_authority": { "attribution_status": "attributed" }
  },
  "trace": { "access": "Ticket COMP-2026-0417" }
},

"handoff": {
  "reconstruction_independence": "declared",   // fixe
  "submission_status": "not_submitted",         // fixe au moment de l'intake
  "acceptance_status": "not_claimed",           // fixe au moment de l'intake
  "boundary_readiness": {
    "status": "verified",
    "visibility_surface": "declared_complete", // dérivé mécaniquement du status ci-dessus
    "readiness_gate": {
      "identifier": "COM-EXC-04 review board",
      "scope_reference": "Vendor onboarding exceptions, Q2 2026"
    }
  }
},

"extensions": ["evidence_references"],
"evidence_references": [
  {
    "artifact_type": "policy_document",
    "pointer": "internal://policies/vendor-onboarding-v3",
    "declared_origin": "internal policy repository",
    "declared_description": "Policy document supporting this exception approval",
    "hash": { "algorithm": "SHA-256", "value": "cabbcf9f83fb765cd82569e477b6b3abf51d81eba9b3b92f8e9904be98a1a2f8" },
    "hash_scope": "full_file",
    "hashed_by": "internal document management system"
  }
]

Remarque : unresolved_signals est correctement absent ici — il n’est requis que lorsque boundary_readiness.status est verified_partial ou unverifiable, pas verified comme dans cet exemple.

Documentation connexe :

JSON Schema Reference — le schéma complet du payload, y compris evidence_references et l’extension declarations partagée avec EVIDE ANCHOR.

API Reference — points de terminaison et profils opérationnels.

Architecture Guide — raisonnement architectural et principes de conception.

Human Structured Intake existe afin qu’une décision humaine déclarée, et son contexte probatoire déclaré, puissent survivre en dehors du système qui les a produits — récupérables de manière indépendante, hachés de manière déterministe, et ancrés dans le temps.

EVIDE préserve qu’une décision a été déclarée.
Elle ne décide pas si la décision était juste.