Aller au contenu

Hyperion Physical AI Decision Lab

Là où l’IA doit mériter le droit d’agir.

The Decision Foundry est le laboratoire Industrial et Physical AI projeté par Hyperion : un environnement reconfigurable unique pour éprouver la valeur produit, les limites du système, le comportement des modèles, l’autorité humaine, la reprise après défaillance et les preuves nécessaires au prochain engagement.

Coupe technique illustrative de la future Decision Foundry, montrant les signaux circulant d’une cellule terrain vers l’actionnement et le retour de preuves, à travers les frontières de connaissance et d’autorité.
Architecture illustrative — une proposition de système, et non la photographie d’une installation Hyperion en exploitation.

Concept en développement

L’installation physique n’est pas encore mise en service. Les éléments disponibles comprennent des démonstrations numériques exécutables et des artefacts de recherche documentés par Hyperion. Les zones et missions proposées ci-dessous restent illustratives jusqu’à leur construction, leur test et leur qualification contraire.

Disponible maintenant

Commencer par ce qui existe.

Il s’agit d’artefacts numériques, de travaux sur banc et de R&D interne actuels — pas de l’installation physique projetée. Chaque page précise ce qu’elle peut prouver et ce qu’elle ne peut pas prouver.

From Demo to Operated Product · Simulator 1.1

Physical AI Product Flight Simulator

Configure a fictional AMR, drone, cobot or vehicle-feature product. Stress economics, reliability, completeness, recovery and operator burden; inspect the diagnostic gaps; then export Product Decision, Product Bridge and Product System records with provenance. All outputs remain illustrative and experiment-only.

Fly a product decision

Auralink

Auralink

Recherche Physical AI publique · documentée par Hyperion. Une référence de recherche inspectable — ni déploiement client, ni allégation de résultat commercial.

Examiner Auralink

Reachy Mini + SO-101

Reachy Mini + SO-101

Mesuré · simulé · exécution à blanc. Les preuves issues de capteurs réels et de la téléopération restent distinctes de l’autonomie simulée et des actions robot non exécutées.

Examiner les preuves robotiques

Évaluation des modèles en périphérie

La révision actuelle attend une revue éditoriale. Le lien et les mesures de performance associées sont masqués ; aucune conclusion de débit ou de maturité produit n’est proposée.

Référence en anglais : le protocole ci-dessous définit les futurs enregistrements et mesures. Aucun résultat d’exécution n’a été recueilli.

Decision Lab protocol · definition only

From observation to operated-product evidence.

Planned · illustrative · no results collected

This protocol defines future records and measures; no run results have been collected for it. The physical Foundry remains planned and illustrative. Apply the protocol at the relevant Product System gate through all six lenses. Future observations belong in the existing Product System records and Evidence Passport, with configuration, exposure, authority, source, limitations, review and expiry. No stage establishes evidence maturity or authorises release automatically.

Five Product System gates and six lenses frame the decision. The five planned Foundry stations describe a facility concept. The six protocol stages below define what to record and measure.

  1. 01

    Observation

    What is true now, how was it observed, and what reference establishes validity?

    Required record

    Timestamped sensor or data observation; origin and rights; configuration and envelope; evaluator or ground truth; missing, invalid and stale-state flags.

    Metric definitions · no measured values

    Valid observation rate

    Valid observations divided by required observation opportunities. Define validity before collection; retain missing observations in the opportunity count.

    Denominator: Required observation opportunities in the declared window.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

    Observation-to-state latency

    Distribution of elapsed time from a relevant physical event to a usable system state. Declare clock alignment and report censored or missing transitions.

    Denominator: Matched event-to-state pairs; disclose unmatched event count separately.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

  2. 02

    Future

    Which future state is predicted, at what horizon, with what uncertainty and alternatives?

    Required record

    Source observation, forecast horizon, model and configuration, predicted state, uncertainty, alternatives and abstention. Pair predictions with later observations before assessing them.

    Metric definitions · no measured values

    Forecast error by horizon

    Apply a declared loss function between each prediction and its later reference observation. Report a distribution by horizon and slice; unobserved futures remain unassessed.

    Denominator: Matched prediction/reference pairs at each declared horizon; disclose unmatched predictions.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

    Forecast calibration

    Compare stated probabilities with observed frequencies within predeclared probability bins. Report bin sizes, uncertainty and excluded cases.

    Denominator: Resolved predictions within each declared probability bin and outcome definition.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

  3. 03

    Action

    What was proposed, authorised, executed or rejected, and whose authority governed it?

    Required record

    Typed proposal, applicable constraints, human or deterministic authorisation, bounded command or abstention, execution acknowledgement and actual resulting state. Separate model proposal from control and specialist acceptance.

    Metric definitions · no measured values

    Accepted action transition rate

    Accepted resulting state transitions divided by authorised action attempts. Use predeclared acceptance criteria and retain failed or aborted attempts.

    Denominator: Authorised action attempts within the same configuration and authority boundary.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

    Authority boundary event rate

    Report blocked, escalated and unauthorised proposals separately by reason, divided by proposal opportunities. A blocked proposal is not inherently a system failure or success.

    Denominator: Proposal opportunities under the declared authority policy.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

  4. 04

    Recovery

    After degradation or failure, was the condition contained and valid task state restored or the run stopped?

    Required record

    Trigger and failed transition, severity, retry/replan/rollback/handback/stop path, recovery owner, restored state, recurrence and outcome. Preserve failed recoveries and human interventions.

    Metric definitions · no measured values

    Accepted recovery rate

    Accepted recoveries divided by recovery attempts, using a declared restored-state criterion. Report degraded, failed, aborted and escalated outcomes separately.

    Denominator: All recovery attempts for the declared failure population and window.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

    Return-to-duty time

    Distribution of elapsed time from detection to accepted resumed useful work. Report unrecovered and censored episodes separately.

    Denominator: Recovery episodes; disclose which resumed duty and which remained stopped.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

  5. 05

    Useful work

    Did the complete human–machine workflow deliver an accepted customer outcome, with what operator burden?

    Required record

    Customer acceptance definition and human baseline; attempted and accepted outcomes; exposure, scheduled and continuous duty; rejects, aborts, interventions, attention and recovery work.

    Metric definitions · no measured values

    Accepted useful outcome rate

    Accepted useful outcomes divided by attempted outcomes, under the declared acceptance definition. Report throughput and longest continuous useful duty alongside the ratio.

    Denominator: Attempted customer outcomes in the declared window; do not substitute easy subtasks.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

    Operator burden

    Operator attention, intervention and recovery minutes divided by duty hours. Distinguish elapsed supervision from person-minutes across multiple operators; compare with the human baseline.

    Denominator: Duty hours for the same system, workflow and observation window.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

  6. 06

    Operated-product evidence

    Does this exact configuration sustain value, controls, service and economics for the declared population and window?

    Required record

    Evidence Passport and traceable Product System records: configuration, envelope, authority, population, window, exposure, evidence origin and maturity, source, limitations, review, expiry and human recommendation. Classify gaps; do not promote a planned protocol or simulation into field evidence.

    Metric definitions · no measured values

    Availability by cause

    Available duty time divided by scheduled duty time. Classify unavailable time by cause and disclose planned exclusions and overlapping causes.

    Denominator: Scheduled duty time for the same population and window.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

    Severity event rate

    Events divided by declared exposure, reported separately for each severity class. Preserve zero events, missing counts and absent exposure as distinct states.

    Denominator: Declared exposure such as attempts, operating hours or distance; specify the unit and never combine incompatible denominators.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

    Cost per successful outcome

    Total ownership and operating cost divided by accepted useful outcomes over the same window. Include integration, infrastructure, service, operator and recovery cost; disclose assumptions and allocation. An absent or zero denominator yields no ratio.

    Denominator: Accepted useful outcomes matching the cost population and accounting window.

    Window and breakdowns

    Declare the observation window, population, configuration, envelope and authority before collecting data. Report missing and excluded cases.

    configuration · operating-envelope slice · authority and supervision · site and task · failure or exclusion reason

These definitions support the existing Product Management metrics tree. Future observations must use the Product System and Evidence Passport. Version: decision-lab-protocol.v1.

La proposition

Pas un showroom de tours de force. Un lieu pour prendre la prochaine décision.

Une démonstration de modèle demande si un comportement peut fonctionner dans des conditions choisies. The Decision Foundry demande si le produit complet doit avancer. Valeur client, intelligence, matériel, logiciel, sûreté, opérations et économie sont évalués ensemble. Un résultat convaincant ne vaut pas validation : les preuves déterminent s’il faut poursuivre, réorienter, s’associer, suspendre ou arrêter.

Un système connecté

Un cycle de vie. Un runtime. Un retour de preuves.

Le Product System détermine pourquoi et quand le produit avance. L'architecture système Physical AI détermine comment le système se comporte en exploitation.

Product System

Stratégie → Discovery → Productisation → Lancement → Passage à l’échelle

Cinq portes de décision gouvernent le passage du produit. Six prismes de décision vérifient si les preuves atteignent le seuil de la décision en cours.

Runtime Physical AI

Percevoir → Connecter → Calculer → Raisonner → Agir → Orchestrer

Confiance, sûreté et cybersécurité entourent chaque couche.

Retour de preuves

Les incidents, la variabilité du terrain, une découverte technique ou l’économie peuvent rouvrir une décision antérieure. Rien n’avance automatiquement.

La mission visiteur

Un signal devient une décision — ou s’arrête à la frontière.

01Cerner la véritable décisionLivrable : contrat de décision

Zones de laboratoire proposées

  1. 01Mission Lock
  2. 02Field Cell
  3. 03Signal Spine
  4. 04Sovereign Core
  5. 05Knowledge Forge
  6. 06Failure Theatre
  7. 07Authority Gate
  8. 08Fleet Observatory
  9. 09Evidence Chamber
  10. 10Executive Studio
  11. 11Field Notes Studio

Suivez une initiative circonscrite, de l’intention déclarée à un dossier de décision inspectable. Au fil du parcours, l’architecture se précise autour de ce qui doit être observé, autorisé et prouvé.

  1. 01LOCK

    Cerner la véritable décision

    Nommer l’usage prévu, le responsable, la frontière du système, le seuil d’acceptation et la condition d’arrêt avant de choisir un modèle.

    Livrable : contrat de décision
  2. 02GROUND

    Ancrer et décider

    Observer la situation de référence déclarée, relier les signaux terrain aux connaissances gouvernées et comparer les options en rendant visibles les sources, l’incertitude et le contexte opérationnel.

    Livrable : proposition circonscrite
  3. 03GATE

    Autoriser ou s’abstenir

    Les contrôles de schéma, de liste autorisée, de politique et d’autorité déterminent si une proposition peut atteindre la commande déterministe. L’ambiguïté ou une intention dangereuse s’arrête ici.

    Livrable : registre d’autorisation
  4. 04RECOVER

    Agir, observer et reprendre

    Exécuter une action circonscrite, injecter une variation déclarée, observer la réponse de l’opérateur et du système, puis prouver le fonctionnement des voies de dégradation, d’arrêt et de retour arrière.

    Livrable : comportement système observé
  5. 05PROVE

    Prouver et passer à l’échelle

    Comparer le résultat aux seuils d’acceptation et d’arrêt. Consigner les preuves, les hypothèses ouvertes et une recommandation : poursuivre, réorienter, s’associer, suspendre ou arrêter.

    Livrable : dossier de gate du Product System

Architecture illustrative

Mettre la frontière d’autorité à l’épreuve

Modifiez une condition. Le modèle peut interpréter et proposer ; la frontière du système détermine la suite.

AutoriséeLes entrées restent dans l’enveloppe déclarée. Une proposition typée franchit les politiques et l’autorité humaine, atteint la commande déterministe et renvoie des preuves.

Runtime Mistral uniquement. Endpoint UE. Autorisé par le propriétaire.

L’autorité déterministe d’abord. Mistral interprète et challenge.

L’environnement déployé autorise du code déterministe ou des modèles Mistral exacts et épinglés via un endpoint UE côté serveur. Les parcours JARVIS, Recherche et Product Council autorisés en production sont actifs par décision du propriétaire. Les travaux d’assurance ouverts restent déclarés ; aucun repli vers une région globale ou un autre fournisseur n’existe.

  1. Calculer

    Actif · déterministe

    Économie, capacité, disponibilité, contraintes, propagation des risques et empreintes sont calculées par du code inspectable avec hypothèses, unités et formules explicites.

  2. Modérer

    Actif · autorisé par le propriétaire

    Le modèle de modération épinglé doit approuver entrée et sortie. Si la modération ou l’inférence UE est indisponible, l’IA échoue en mode fermé tandis que la simulation déterministe reste disponible.

  3. Challenger

    Actif · autorisé par le propriétaire

    Small, Medium et Large jouent séparément les rôles de facilitateur, analyste systèmes et critique. Les désaccords sont conservés et les défaillances communes à la famille de modèles sont signalées.

  4. Ancrer

    Preuves locales

    Le VPS détient identifiants de preuve, recherche, versions de prompts et état. Aucun web search intégré ni service Files, Libraries, Agents ou Conversations n’entre dans le chemin de production.

  5. Prouver

    Preuves versionnées

    Chaque résultat substantiel consigne modèles exacts, versions de prompt et méthode, classifications, preuves, empreintes déterministes, limites, statut de revue et responsable humain.

  6. Contenir

    Adaptateur UE uniquement

    Tous les appels hébergés partent du serveur vers https://api.eu.mistral.ai. Les autres hôtes, alias, identifiants non approuvés et replis fournisseur sont refusés ; les secrets n’entrent jamais dans le navigateur.

Aucune voie du modèle vers la machine ou la décision

Aucune réponse Mistral n’est une commande directe d’automate, robot, borne ou véhicule. Le code déterministe détient calculs et contraintes ; une fonction de sûreté indépendante peut refuser ou arrêter l’action ; une personne nommée assume investissement, mise en production, conformité, sûreté et engagements client.

Explicitement hors production

OCR, embeddings, voix, Agents, Conversations, Files, Libraries, Batch, web search intégré, fine-tuning, Forge et services preview sont désactivés tant que la capacité exacte n’est pas vérifiée pour le traitement régional UE, le Zero Data Retention, le contrat, la sécurité et un besoin mesuré.

Hyperion Consulting est indépendante de Mistral AI. L’endpoint régional UE est une frontière technique, pas la preuve que toute la chaîne de sous-traitants et le plan de contrôle restent dans l’UE. Aucun partenariat, certification, souveraineté ou statut de conformité n’est revendiqué.

Vérifier dans la documentation officielle de Mistral

Premiers packs de mission

Conçus autour de la défaillance — pas d’une perfection mise en scène.

Chaque mission commence à l’état projeté et illustratif. Elle ne devient mesurée que lorsque la cellule de référence existe, que le protocole est publié et que le résultat est reproductible.

Maintenance ancrée

Lire l’état de la machine et un corpus de maintenance gouverné, montrer les passages sources, déclarer l’incertitude et proposer un ordre de travail circonscrit — sans diagnostiquer l’équipement de manière autonome ni émettre de commande.

Projeté · illustratif jusqu’à la mise en service

Frontière d’autorité

Donner au système une instruction ambiguë ou dangereuse. L’intelligence peut proposer ou s’abstenir ; interfaces typées, autorité de politique et sûreté indépendante déterminent si quoi que ce soit peut atteindre le contrôleur.

Projeté · illustratif jusqu’à la mise en service

Couper le réseau

Déconnecter l’accès externe et observer l’inférence locale, les connaissances en cache et le repli déterministe au regard des exigences déclarées de mode dégradé.

Projeté · illustratif jusqu’à la mise en service

Enveloppe opérationnelle

Mettre la perception et le comportement appris à l’épreuve de l’éblouissement, de l’occultation, de pièces inconnues, de la dérive et de variations du poste afin d’exposer — et non masquer — la limite validée.

Projeté · illustratif jusqu’à la mise en service

Du canary à la flotte

Tester une révision en simulation, la déployer sur un actif contrôlé, ne l’étendre que tant que les seuils d’acceptation tiennent, et revenir en arrière lorsqu’ils ne tiennent plus.

Projeté · illustratif jusqu’à la mise en service

Passeport de preuves

Chaque moment impressionnant porte ses limites.

Une démonstration n’est utile que si un acheteur peut comprendre ce qui s’est passé, dans quelles conditions et ce que le résultat ne prouve pas.

Live
Exécutable maintenant ; pas automatiquement éprouvé pour la production.
Mesuré
Observé dans des conditions nommées ; non extrapolé au-delà.
Simulé
Produit dans un environnement numérique ou synthétique ; pas en exploitation terrain.
Replay
Exécution antérieure figée ; pas une interaction en direct.
Illustratif
Scénario ou architecture proposés ; aucune mise en œuvre n’est sous-entendue.
Projeté
Prévu pour une construction future ; pas encore mis en service.

Le dossier accompagne le résultat

Question · usage prévu · origine et droits des données · versions du modèle, du prompt, de l’outil, du firmware et du jeu de données · conditions d’exploitation · frontière d’autorité · seuils d’acceptation et d’arrêt · résultat attendu et observé · défaillances · limites · date de reproduction · ce que l’exécution ne prouve pas

JARVIS · Lab OS

Le guide — pas le gouverneur.

JARVIS permet à un visiteur d’observer l’état du système, de mettre à l’épreuve un scénario circonscrit, de comparer les décisions et d’expliquer le résultat à partir de preuves citées. Il peut synthétiser et proposer ; il ne peut ni écarter un seuil d’acceptation, ni certifier un système, ni autoriser une action physique dangereuse.

Interroger JARVIS sur la Foundry
Observer
État du système, provenance et sources
Éprouver
Injection circonscrite de défaillance
Décider
Options et conséquences sur le cycle de vie
Expliquer
Preuves, limites et dossier de décision

Comment fonctionne le système complet

Un seul système d'IA physique — de la perception à l'action fiable

Sélectionnez une étape pour suivre le système de bout en bout.

Diagramme en pixel art de la pile Physical AI, avec un signal qui s'élève des capteurs jusqu'à l'orchestration.

01 / 08Équipement et contrôle

Capteurs & environnement. Le monde physique, perçu — caméras, profondeur, radar et signaux OT.

Voir comment nous le concevons

Questions sur la Decision Foundry

The Decision Foundry est-elle déjà ouverte ?

Non. L’installation physique est au stade de développement du concept et n’est pas mise en service. Les démonstrations numériques actuelles et la R&D détenue par Hyperion sont qualifiées séparément.

Hyperion est-elle partenaire de Mistral AI ?

Aucun partenariat ni accès privilégié n’est revendiqué. Hyperion est indépendante de Mistral AI. Les parcours JARVIS, Recherche et Product Council autorisés par le propriétaire utilisent un runtime exclusivement Mistral via l’endpoint UE, avec des solutions de repli déterministes.

Un modèle Mistral peut-il commander directement une machine dans le laboratoire projeté ?

Non. Les sorties du modèle sont des propositions qui doivent franchir les contrôles de schéma, de liste autorisée, de politique et d’autorité avant la commande déterministe. La sûreté indépendante demeure hors de l’autorité du modèle.

The Decision Foundry est-elle un laboratoire de certification ?

Non. Elle ne remplace pas les spécialistes juridiques, de sûreté, de cybersécurité, d’évaluation de conformité ou de certification. Elle crée des preuves produit et architecture pour une décision circonscrite.

Avec quoi un participant doit-il repartir ?

Un dossier de décision circonscrit : preuves observées, hypothèses non résolues, limites et recommandation de poursuivre, réorienter, s’associer, suspendre ou arrêter.

Quels secteurs le programme couvre-t-il ?

L’industrie, l’automobile et l’énergie sont les contextes prioritaires. Les infrastructures intelligentes, la logistique et la défense sont explicitement qualifiées de contextes de recherche ; leur publication ne suppose aucune mission client dans ces secteurs.

Apportez une initiative bloquée

Repartez avec la prochaine décision.

Lors d’un échange d’adéquation de 30 minutes, Mohammed identifiera la décision, les preuves manquantes et dira si une mission Foundry ou l’un des trois mandats Hyperion convient — ou clairement si ce n’est pas le cas.

30 minutes · sans engagement · Mohammed mène chaque échange