DESCRIPTION TECHNIQUE
Architecture logicielle de Distribution Neural XR
DNXR est présenté comme un middleware C++ de coordination entre acquisition BCI, traitement neural/spike, sûreté, transaction, rendu XR et boucle de feedback. Cette page décrit la structure du code et distingue explicitement les fonctions logicielles des validations matérielles ou cliniques.
01 · RUNTIME
Un propriétaire d’exécution canonique
Le runtime orchestre l’ingestion du monde, la validation des entrées, l’acquisition, l’inférence d’intention, la calibration, la compilation sensorielle, la décision de sûreté, le commit vers l’interface de puce et la correction après feedback.
02 · BCI
Abstraction de puce neurale
Les interfaces séparent le logiciel DNXR du matériel physique. Les contrats de capacité, de sécurité par modalité, d’ACK externe et de feedback structurent l’échange sans exposer publiquement les secrets ni autoriser le contrôle du runtime depuis le site.
- Contrat de capacité de puce
- Commit de trame neuronale
- Accusé de réception externe requis
- Feedback authentifié et correction
- Canal dur d’ancrage à la réalité
La scène du laboratoire représente 1 024 contacts et 64 faisceaux. Cette topologie est visuelle tant qu’un dispositif réel et ses preuves ne sont pas fournis.
03 · TRAITEMENT SPIKE
Chaîne de représentation neuronale
Le dépôt contient des composants liés aux vecteurs neuronaux, à la modélisation d’intention, à la synchronisation multisensorielle, au traitement de spikes et aux boucles d’erreur perception-action. Les métriques internes telles que le nombre de spikes ou de neurones actifs ne sont publiées sur le site que si l’exécutable les émet lui-même.
Le portail ne déduit pas un « nombre de neurones actifs » depuis l’utilisation CPU. Les deux notions restent séparées.
04 · MODALITÉS
Encodage multisensoriel modulaire
L’architecture répertorie des encodeurs visuel, auditif, tactile/épidermique, proprioceptif, vestibulaire, olfactif et gustatif. Les politiques de dose, de cadence, d’isolation et de capacité sont conçues pour être appliquées par modalité.
05 · SÛRETÉ
Autorité centrale et verrouillages
Les éléments de sûreté couvrent les enveloppes par modalité, les contrôles physiologiques, l’arrêt d’urgence, la stabilité, les limites de stimulus et l’ancrage à la réalité. Le site n’envoie aucune commande au runtime et ne désactive aucun verrou.
- Autorité de sûreté canonique
- Arrêt d’urgence fail-closed
- Contrôle des doses et cadences
- Canaux chimiques verrouillés par défaut
- Utilisation humaine non présumée
06 · TRANSACTION
Commit, ACK et feedback
Le chemin transactionnel vise à empêcher les propriétaires concurrents et les sorties partielles. Une trame est préparée, contrôlée, engagée, acquittée et corrigée selon un chemin causal unique. Les statistiques d’ACK ou de séquence de commit ne sont affichées que lorsqu’elles sont réellement publiées.
07 · OBSERVABILITÉ
Agent externe sans modification de DNXR
Le sidecar dnxr_live_agent.py localise ou lance distributed_neural_xr.exe, puis lit 100 mesures à intervalles réguliers. Il utilise les compteurs du processus, les API mémoire Windows, les E/S, les connexions, les modules chargés, les en-têtes PE et stdout.
08 · LIMITES
Ce que le portail ne prétend pas
- Aucune preuve de connexion à une puce neuronale physique
- Aucune validation clinique ou autorisation humaine implicite
- Aucune lecture de métrique interne non exposée
- Aucune garantie commerciale au-delà des documents contractuels signés
- Aucune modification du code source DNXR par l’agent de télémétrie
ACQUISITION