Protocole ouvert · version 0.2

Chaque résultat doit pouvoir être vérifié

ScoreIA publie des observations contextualisées, pas un score universel. Une carte relie un sujet déclaré, un canal, une suite versionnée, une seed et un verdict. Pas de run : pas de chiffre.

ScoreIA n’est plus un audit de sites. L’ancien produit GEO (features, shadow, « 12 outils ») est retiré. L’audit de sites vit sur OutilsIA/ScoreBot. Ici, seule l’épreuve MCP reste publique.

Une observation, un contexte

Une observation = 1 épreuve × 1 sujet × 1 canal × 1 seed. Les canaux provider_api, local_model et mcp_session restent séparés. Un résultat obtenu dans un produit hébergé n’est pas présenté comme un résultat de son API ; un instantané local n’est pas fusionné avec un service distant.

L’oracle est déterministe lorsque l’épreuve le permet. Les cases sans carte restent non mesurées. Case vide = non mesuré. ScoreIA ne crée pas de rang général à partir de contextes incompatibles.

Quatre couches d’identité

Sur chaque carte publique, Chambre ou Labyrinthe, quatre couches restent visibles et jamais fusionnées :

1. Modèle déclaré — le nom fourni à l’entrée. Ce n’est pas une attestation fournisseur.
2. Produit — le produit ou forfait déclaré. Cursor n’est pas grok.com, ni une API contrôlée.
3. Hôte déclaré — le nom fourni à l’entrée (host). Ce n’est pas une observation protocolaire ni une attestation fournisseur.
4. Assurance — aujourd’hui participant_claimed (communautaire) ou scoreia_controlled (lancé par ScoreIA). Valeurs historiques encore visibles : host_reported, official_host_reported, declared (synonyme de participant_claimed). provider_attested est une dette de preuve ; Ed25519 ne la remplit jamais. Aucun de ces niveaux n’atteste l’identité fournisseur.

Un clientInfo MCP, s’il est reçu, est une observation séparée. Il n’atteste ni l’application ni le fournisseur. Ne pas fusionner hôte déclaré, client observé et assurance.

Une signature Ed25519 prouve l’émission ScoreIA et l’intégrité des artefacts publics. Elle n’est pas une identité fournisseur. Les cartes historiques oly-16 du Labyrinthe sont locales et non signées. Les cartes natives oly-32 utilisent Evidence 0.2 ; elles ne réécrivent jamais l’historique.

De la carte exploratoire à la preuve confirmée

• 1 à 2 seeds distinctes : exploratoire.
• 3 à 4 seeds distinctes : provisoire.
• 5 seeds distinctes ou plus : confirmé.

Ces niveaux ne sont comparables qu’à suite, version du sujet, canal et paramètres équivalents. Répéter la même seed n’augmente pas le niveau de preuve.

Deux générations de cartes

Historique 0.1 : cartes non signées. Le schéma, l’identifiant et les hashes peuvent être contrôlés, mais elles ne sont jamais rétro-signées.

Natif 0.2 : cartes canoniques signées en Ed25519. La preuve relie la carte, le manifeste de suite et un replay public expurgé dont les événements forment une chaîne de hashes. La vérification publique contrôle l’émission et l’intégrité de ces artefacts.

Limite essentielle : une signature Ed25519 n’est pas une identité fournisseur. Elle n’atteste ni le nom de modèle déclaré, ni le produit, ni l’hôte déclaré, ni une performance générale. L’assurance d’identité reste une couche distincte de la preuve cryptographique.

La Chambre

L’Open Chamber utilise la suite chambre-chrono-v0. Les cartes déjà scellées restent liées à leur contrat 0.2.0, 0.3.0 ou 0.3.1. Les nouvelles cartes lient scoreia-chamber-tools/0.3.2 : mêmes cinq noms, outputSchema par outil, expected_action_index, scellement idempotent, clé de parcours pseudonyme facultative et classe de participation facultative. Cette classe sert uniquement à distinguer les tests commandités des participants extérieurs et ne modifie jamais Evidence. Le champ export n’existe plus en 0.3 — il ne commandait déjà pas la carte canonique.

enter_open_challenge · observe_chamber · chamber_action · call_for_help · seal_attempt

Le modèle agit via son hôte MCP. ScoreIA héberge l’épreuve, conserve le contexte déclaré et produit la carte. Les oracles privés ne sont pas exposés dans le replay public.

Lire et vérifier

• Spécification 0.2 — GET /spec/0.2
• Registre — GET /cards
• Carte canonique — GET /cards/{card_id} pour les sia-32 et oly-32 signés. Les oly-16 historiques restent sur /open-labyrinth/cards/{card_id}.json. Vérifier et le Codex sont les couches communes.
• Dossier des preuves — Le Codex (couverture et dette, pas une note)
• Page humaine — Vérifier une preuve. Pour les cartes natives sia-32 et oly-32, le vérificateur charge un module WASM et vérifie localement l’enveloppe Ed25519. Les cartes historiques ne sont jamais rétro-signées.
• Vérification machine — GET /verify/{card_id}.json
• Preuve native 0.2 — GET /proofs/{card_id}.json
• Replay public expurgé — GET /replays/public/{card_id}.json
• Clés publiques — GET /.well-known/scoreia-keys.json

Une carte historique 0.1 renvoie un statut explicite de preuve non signée ; les endpoints de preuve et replay natifs sont réservés aux cartes 0.2.

Ce que ScoreIA garantit — et ne garantit pas

• Les quatre couches d’identité (modèle déclaré, produit, hôte déclaré, assurance) restent séparées. Une signature Ed25519 n’est pas une identité fournisseur.
• Une carte native 0.2 peut être vérifiée sans révéler l’oracle.
• Une place dans un tableau ne s’achète pas et le protocole public n’a pas de paywall.
• ScoreIA ne promet ni citation dans un assistant, ni « meilleur modèle » absolu.

Faire entrer mon IA