Preuves et reproductibilité : d’un Sony à des Works indépendants sur le terrain

16.1 Échecs d’installation, récupération et parcours de développement reproductible

Les essais Android impliquent outils de build, signature, permissions, USB/ADB et rétablissement après erreur. Le Sony H4493 Android 9/API 28 a porté les Apps de recherche NFC Writer, lunettes USB et MCP Phone. Compilation Gradle PASS, APK signé, version installée et écran visible sont des observations utiles mais aucune ne prouve que le Work physique d’une personne est accompli. Documenter code, signature, appareil, journal d’erreur, opérateur, correction et absence d’effet sur les autres Apps.

Les jalons sont SOURCE_READY → BUILD_PASS → DEVICE_INSTALLED → INTERFACE_DETECTED → ACTION_READBACK → HUMAN_ACCEPTED. Une autre version Android peut échouer là où Sony réussissait à cause des pilotes, droits ou rôles USB. Un retour sûr conserve les données privées, retire l’ADB forwarding temporaire et arrête l’essai si un matériel n’est pas qualifié. APP_INSTALLED ne doit jamais être affiché comme acceptation physique [H1–H3].

16.2 Écriture NFC : distinguer confirmation de l’utilisateur et relecture indépendante

Le NDEF NFC peut contenir une URL HTTPS d’entrée. Une ancienne écriture Sony a été rapportée par l’utilisateur, tandis qu’une autre expérience de câble/tag a ouvert une page après contact d’un iPhone ; ces parcours ne constituent pas une seule preuve indépendante des octets écrits. GiftReality Android NFC Writer A0-001 a ensuite été compilé, signé, publié et testé par HTTPS/navigateur, mais son handoff gardait l’écriture réelle et la relecture sur Android au statut PENDING. Les essais avec lecteur Windows et la page Product 003 restent distincts [H4, H5].

Pour accepter un test : identifier le tag réinscriptible, approuver l’URI, constater l’écriture, relire indépendamment NDEF, comparer la destination puis observer un deuxième téléphone compatible ouvrir la page. UID de tag, authenticité de produit, identité e-Person et autorisation Work sont quatre objets différents. Une URL réussie ne permet ni commande d’équipement ni paiement sans accord. QR, URL lisible et aide humaine restent nécessaires sans NFC [E1].

16.3 Aperçu lunettes USB, échec de sauvegarde photo et réception de capture encore ouverte

L’App Sony lunettes USB P0-001 a été construite et installée ; la première inspection sans lunettes branchées indiquait aucune caméra USB. Le handoff P0-002 rapporte ensuite que l’utilisateur avait vu l’aperçu réel sur l’ancienne App, sans capture de trame indépendante et hashée par ADB. Un appui Photo a provoqué un crash, et le journal a localisé un refus de permission dans le chemin MediaStore d’une vieille bibliothèque UVC. Voir une vidéo et sauver une photo exploitable ne sont pas la même chose [H2, H3].

La correction P0-002 garde les bibliothèques d’aperçu UVC mais lit la trame affichée via TextureView, encode JPEG et écrit dans Pictures privé de l’App. Build, lint, réinstallation et refus sans caméra ont réussi. La répétition du vrai aperçu P0-002 avec lunettes, le fichier JPEG décodable, son orientation, qualité et réception humaine restaient PENDING. Il s’agit d’une image rendue à l’écran, pas nécessairement de la résolution native ; désinstaller l’App peut effacer sa photo privée [H3].

16.4 Accès batterie MCP, accord en un geste et refus des outils non autorisés

MCP Phone Sony ne demandait que INTERNET pour son serveur loopback, sans caméra, NFC, contacts, SMS ni localisation. L’accès se limitait à un profil matériel et à la batterie en lecture seule, choisis explicitement. Le P0-001 enregistrait build/UI PASS sans appel positif prouvé ; le P0-002 introduisait un accord visible pour un seul outil. Un handoff P0-003 ultérieur rapporte l’accord réel et la lecture batterie confirmés par l’utilisateur. Les faits ne doivent pas être rétroactivement attribués à toutes les versions [H1, H6, H7].

Le test doit refuser bearer absent ou erroné, Tool contacts non accordé, Origin web suspect, appel hors périmètre, expiration et requête après Stop. Un transfert USB temporaire du Mac vers le port local du téléphone ne le rend pas serveur public mondial. Un ordinateur reconnu par ADB n’est pas authentifié cryptographiquement pour tous les services. Le catalogue MCP Tools n’accorde pas à un modèle le droit de demander des permissions Android supplémentaires [E2, E3].

16.5 Révocation éprouvée avec humain, essais de sécurité encore ouverts et leçons réutilisables

Dans P0-002, le bouton Stop pouvait devenir non cliquable après fermeture automatique ; une boîte d’accord non annulable empêchait également l’accès au contrôle. P0-003 a gardé Stop/Revoke disponible même quand le serveur est OFF, ajouté Stop All MCP dans la boîte et un avis de révocation déjà effectuée. L’APK corrigé a été installé ; un clic ADB sur le contrôle en état OFF suivi du retour USB n’a trouvé aucun serveur à l’écoute et le transfert temporaire a été supprimé. Ce sont des réussites bornées [H7].

Le même handoff maintenait en attente un grant neuf actif, un vrai contact de doigt du propriétaire, le refus indépendant de l’ancien token après révocation et le test Stop All pendant la boîte réelle. Un timeout côté serveur ne prouve pas qu’une personne peut arrêter un service actif. Les règles à répéter sont refus par défaut, autorisations courtes, bouton visible et accessible, preuve du refus, arrêt matériel sûr et risques non testés rendus publics.

17.1 Observation de spécimen autorisée et informations produit étayées par des preuves

Un Work à faible risque débute avec un échantillon dont le détenteur autorise l’observation : confirmer la fiche d’un connecteur, expliquer des consignes ou décrire l’état d’une pièce. Il consigne garde du spécimen, Reality Delta voulu, instruments ou caméra réellement disponibles, source documentaire, fenêtre temporelle et personne d’acceptation. Une notice de fabricant fiable ou une mesure sont des preuves ; une supposition de modèle sur image doit rester qualifiée.

L’e-Person prépare étapes, traduction facile ou voix, mais ne peut annoncer une inspection sans caméra ni source. La bonne fin peut être un rapport daté, un conseil accessible, un renvoi à un technicien ou un refus justifié. Étudiants, réparateurs, ingénieurs commerciaux et personnes ayant besoin d’aide peuvent participer depuis une station partagée qualifiée, sans achat obligatoire d’un téléphone récent.

17.2 Transfert de Work du monde physique au numérique par NFC

NFC, QR ou HTTPS relient un objet autorisé à ses données de source fiable et, éventuellement, à un Work. Distinguer Tap to Understand, Tap to Verify, Tap to Act. Comprendre peut afficher une notice publique sans login ; vérifier nécessite parfois origine sûre et authentification ; agir demande une autorisation humaine précise. Un scan n’enregistre pas une e-Person et ne donne jamais tout pouvoir sur un téléphone ou un relais.

La réception comprend écriture NDEF réelle, lecture indépendante, URL ouverte sur un deuxième appareil, page accessible, source vérifiée, Intent, grant borné et résultat accepté. Un câble ou emballage sans marque licenciée suffit pour un premier Accessible Product Passport. Toute variante FIFA 2027 doit passer séparément par le client Pannex et le titulaire des droits sur marques, contenu numérique et territoires ; la réussite NFC ne vaut pas licence.

17.3 Inspection locale, apprentissage et assistance visuelle supervisée

Une personne peut vouloir identifier une pièce peu dangereuse, lire une petite étiquette, comprendre le montage d’un support ou trouver un service. Le Work choisit caméra, lunettes USB, Hub ou humain entraîné seulement si cette capacité est réellement opérationnelle et consentie. Le résultat concerne la compréhension, non une certification de navigation sûre, un diagnostic médical ou une conduite industrielle autonome. Les données et permissions caméra sont vérifiées pour cette tâche.

Une interface accessible propose instructions faciles, audio et boutons larges si besoin, possibilité de corriger l’IA, étapes de confirmation et superviseur humain. Les travaux publics d’InnoSpire sur vision et communication inspirent des collaborations possibles sans transférer automatiquement à HSIMC ses droits, ni prouver une intervention réelle. La personne peut refuser l’interprétation du modèle et un spécialiste reste nécessaire pour les effets sensibles.

17.4 Pour chaque modèle : résultat visé, capacités, consentement, preuves et acceptation

Le contrat minimal d’un modèle Work comprend version, demandeur, objectif, Reality Delta, prestataire et capacité aptes, site et durée, droits sur les données, accessibilité, action, arrêt, preuve, superviseur, coûts et critère d’acceptation. Le graphe peut créer des sous-Works pour matériel, étalonnage, habilitation, connexion, sources officielles ou entrée de secours, mais ne peut prétendre que toute offre découverte est disponible.

Publier un modèle ne qualifie aucun appareil. Séparer TEMPLATE_DEFINED, DEVICE_QUALIFIED, PERMISSION_GRANTED, ACTION_OBSERVED, EVIDENCE_VERIFIED, HUMAN_ACCEPTED. Une App ouverte sans droit USB, un tag pointant sur un domaine douteux ou une caméra qui ne sauve pas de photo sont des échecs distincts à conserver avec numéro de spécimen et version réelle.

17.5 Passer de l’appel d’outil réussi à un résultat utilisable par une autre personne

Un JSON correct de phone.get_battery prouve une lecture, non l’achèvement d’une tâche utile. Demander si cette donnée répond à l’Intent, si date et provenance sont fiables, si la personne la comprend dans la langue et le mode souhaités, et si le destinataire peut agir en sécurité. Des appels répétés, des tokens et des scans ne peuvent être comptés comme Works humains acceptés.

La chaîne vérifiable est Intent confirmé → autorisation valide → Reality qualifiée → action/readback → preuve contrôlée → réception ou correction humaine → continuation autorisée. Un compte rendu parlé peut aider plus qu’un objet JSON ; un PD Trace vaut mieux qu’une affirmation commerciale et un refus honnête mieux qu’une réponse inventée. La valeur est l’issue réellement utilisable.

17.6 Répondre à une question pendant la fenêtre de décision d’un salon

Sur un salon professionnel, un client peut demander si un câble transporte données et puissance, si le NFC ouvre le service attendu ou si la notice est accessible à une personne malvoyante. Le Work fixe le temps restant, le spécimen, le décideur, les outils d’essai et les critères de réception. En parallèle on recherche une fiche officielle ou prépare une interaction accessible pendant qu’un expert qualifie la mesure.

À la fin de la réunion, distinguer résultat mesuré, déclaration du fournisseur, droits nécessaires et tests encore absents. Sans trace PD étalonnée, essai sous double charge, lecture NFC indépendante ou essai humain d’accessibilité, dire précisément ce qui demeure incertain. Une réponse « pas encore vérifié » protège mieux l’achat qu’une conclusion risquée motivée par l’urgence du salon.

17.7 Continuité commerciale par correction, adaptation ou arrêt sûr

Après la vente, un objet peut encore fournir notice facile, compatibilité contrôlée, pièces agréées, réparation locale, soutien et récupération responsable. Le Work autorisé offre ces services sans obliger toutes les entreprises traditionnelles à accepter la totalité de l’architecture HSIMC. Les droits de marque, fabrication, contenu numérique et clientèle restent propres aux titulaires.

Si le produit est dangereux, la source incertaine, l’accessibilité insuffisante ou la licence manquante, une correction ou STOP est une bonne décision commerciale. Consigner preuve non sensible, responsable, pièce et alternatives. Pannex et les autres fabricants conservent leur identité et leurs clients ; HSIMC peut contribuer à la continuité par contrats et résultats acceptés, non par une succession de publicités.

18.1 Un autre téléphone, un autre opérateur, un autre lieu — le même Work borné

La réplication part d’un contrat et d’une liste de preuves, non d’une explication privée du fondateur. Un opérateur indépendant choisit un autre téléphone admissible ou un Hub, vérifie interfaces et sécurité, obtient un nouvel accord du titulaire et accomplit un Work peu risqué. Langue locale, besoins d’accessibilité et accompagnement humain font partie du protocole.

Documenter modèle, firmware, adaptateur, moment, réseau, opérateur, objectif, données permises, état réel, défauts et bénéficiaire. Le Sony historique sert de comparaison, jamais de jeton transférable ou de compatibilité garantie. Rejouer un vieux JSON ou montrer une ancienne capture NFC ne constitue pas un second essai physique indépendant.

18.2 Cohortes de référence, matrices de compatibilité et cas explicitement non pris en charge

Comparer matériel et versions OS, lecture/écriture NFC, Host USB, batterie, réseau local/cloud, modes accessibles et supervision. Chaque ligne de matrice indique ce qui a été réellement lu, écrit, appelé et accepté. Une marque peut lire NDEF sans pouvoir écrire le tag choisi ; une paire de lunettes montrer une vidéo sans produire de JPEG ; un lieu ne pas disposer d’un Internet autorisé.

Les cas refusés comptent dans le dénominateur. Vérifier si QR, voix, autre téléphone ou Hub partagé ont réellement permis le même Work, ou simplement montré une page. Les estimations ITU éclairent l’inclusion mais ne représentent pas une étude de compatibilité de dix milliards de téléphones [E4].

18.3 Suites de tests de grant actif, révocation, concurrence et migration de protocole

Le minimum : refus par défaut, permission pour un seul outil, mauvais ou absent token rejeté, Tool étranger refusé, Origin, expiration, Stop/Revoke pendant une session active, ancien token bloqué, redémarrage et arrêt matériel sûr. Sony P0-003 a déjà amélioré l’UI et observé un Stop à l’état OFF puis l’absence d’écoute. Le contact humain réel avec grant actif et son ancien token refusé restaient PENDING [H7].

Ajouter requêtes parallèles, messages dupliqués, coupure transport, permissions expirées au redémarrage, changement d’appareil ou personne, migration de logiciel et version MCP. Les appels stateless ne créent pas le graphe historique de Work ni la protection contre les doubles commandes matérielles. Chaque cas exige vrai client, version serveur, réponse et readback indépendants, avec supervision si un effet physique est possible.

18.4 Distinguer taille du registre, installations, nœuds actifs et usage réellement productif

Le registre HSIMC a autrefois compté 356 782 identifiants Runtime adressables : ce sont des références, pas autant de services confirmés [H0]. Un APK publié est distribuable, installé il est présent ; une écoute MCP est joignable ; une réponse batterie prouve une lecture bornée. De même la vision de dix milliards n’est pas une flotte contrôlée, consentante et rentable.

Mesurer séparément les identités de référence, appareils inspectés, Tools valides, grants humains actifs, personnes distinctes, outcomes vérifiés, refus, reproductions, maintenance et coûts par Work accepté. Ne pas additionner ces catégories ou compter plusieurs taps comme plusieurs utilisateurs. Tester No One Left Behind avec vrais parcours d’accessibilité et soutien local au-delà du public connecté.

18.5 Un registre de preuves conservant les échecs et évitant les fausses annonces READY

Pour chaque essai conserver Artifact ID, révision, opérateur, garde des spécimens, appareil et OS, date, consentement, entrée, résultat attendu, résultat observé, lecture machine, parole de l’utilisateur, erreur, confirmation indépendante et prochain contrôle. Les états BUILD_PASS, USER_REPORTED, MACHINE_OBSERVED, INDEPENDENT_READBACK, HUMAN_ACCEPTED et PENDING ne se remplacent pas mutuellement. Une correction ultérieure ne réécrit pas les échecs initiaux.

Occulter numéros privés, bearers et images sensibles. SHA256 garantit les octets d’une pièce et non la vérité d’une prétention physique ; le rapport positif d’une personne sur l’accessibilité peut être réel sans certification indépendante de sécurité. Un registre des échecs aide les autres ingénieurs à ne pas répéter les mêmes risques et respecte la liberté du participant.

Non-executable independent replication evidence template ↗

18.6 Identité, garde, conditions et objets d’acceptation distincts pour chaque spécimen

Chaque tag NFC, câble, téléphone, périphérique, montage et lieu possède un identifiant d’essai séparé des ID e-Person et Work. Consigner détenteur, matériaux, révisions, consentement, alimentation, réseau, environnement, conservation des données et instrument de lecture indépendante. Le même téléphone peut servir à plusieurs travaux, mais la lecture d’un tag ne prouve pas celle d’un second tag.

Accepter par niveaux : SOURCE_ACCEPTED, BUILD_ACCEPTED, DEVICE_INSTALL_ACCEPTED, INTERFACE_OBSERVED, PHYSICAL_OUTPUT_READBACK, INDEPENDENT_REPLICATION_ACCEPTED et HUMAN_WORK_ACCEPTED. Une personne peut accepter un conseil sans certification de matière ; indiquer précisément la portée. La vraie échelle mondiale commence lorsqu’un deuxième opérateur autorisé reproduit un petit Work sûr dans une nouvelle Reality et reçoit acceptation.