RA-153.1-2 — Implementation Specification v0.2

1. Statut et périmètre

RA-153.1-2 est une architecture de référence. Cette Implementation Specification définit un profil concret pour réaliser les responsabilités, interfaces et invariants de cette architecture sans imposer un langage, un fournisseur, un LLM, un moteur de politiques, un protocole d’agents ou un mécanisme d’attestation particulier.

Une implémentation peut utiliser REST, gRPC, messages, appels de bibliothèque ou une combinaison de ces mécanismes. Elle est conforme si elle préserve les propriétés normatives, pas si elle reproduit nécessairement la topologie logicielle illustrée ici.

2. Terminologie normative

3. Architecture d’exécution

Client / Application
        │
        ▼
R0 RequestEnvelope
        │
        ▼
[Plan sémantique] ──► R1 NeedDescriptor
        │
        ▼
[Plan capacitaire] ─► R2 CapabilityRequirementSet
        │
        ▼
[Plan cognitif] ────► R3 StrategySet
        │
        ▼
[Plan normatif] ────► R4 GovernanceDecision / Mandate
        │
        ├── ABSTAIN ──► fin sans effet
        ├── REFUSE  ──► fin sans effet
        ├── ESCALATE ─► Human Gate / autre autorité
        │
        └── EXECUTE
               │
               ▼
        [Plan exécutif] ─► R5 ExecutionBinding
               │
               ▼
          Effet de domaine
               │
               ▼
        [Plan probatoire] ─► R6 EvidenceBundle

DOIT. Aucun composant en amont du plan normatif ne peut créer directement un effet de domaine. DOIT. Aucun effet de domaine ne peut être produit si l’état courant ne possède pas un mandat EXECUTE valide.

4. Machine à états

RECEIVED → UNDERSTOOD → CAPABILITIES_RESOLVED → STRATEGIZED → GOVERNED
                                                   │
                                                   ├─ ABSTAIN/REFUSE → TERMINAL_NO_EFFECT
                                                   ├─ ESCALATE → ESCALATED → GOVERNED
                                                   └─ EXECUTE → AUTHORIZED → BOUND → EXECUTING → EXECUTED → EVIDENCED

NE DOIT PAS. Une transition d’un état terminal sans effet vers BOUND ou EXECUTING est interdite. Une nouvelle information exige une nouvelle décision R4.

5. Artefacts R0 → R6

Tous les artefacts DOIVENT comporter un identifiant stable, un correlation_id, une version d’artefact, une date de création et une provenance. Les structures détaillées sont fournies dans le bundle JSON Schema joint.

5.1 Exemple R0

{
  "meta": {
    "ra_version": "RA-153.1-2",
    "artifact_type": "R0_RequestEnvelope",
    "artifact_version": "0.1.0",
    "id": "r0-123",
    "correlation_id": "passage-123",
    "created_at": "2026-10-04T03:45:00+02:00",
    "producer": "client"
  },
  "request": {
    "content": "Inscris-moi à cette formation",
    "content_type": "text/plain",
    "channel": "chat",
    "requested_effect": "enrollment"
  },
  "actor": {
    "actor_id": "user-42",
    "actor_type": "human",
    "roles": [
      "member"
    ]
  },
  "org_context": {
    "organization_id": "org-demo",
    "jurisdiction": "FR"
  },
  "time": {
    "received_at": "2026-10-04T03:45:00+02:00",
    "expires_at": "2026-10-04T04:15:00+02:00"
  }
}

5.2 Exemple R4 — ESCALATE

{
  "meta": {
    "ra_version": "RA-153.1-2",
    "artifact_type": "R4_GovernanceDecisionMandate",
    "artifact_version": "0.1.0",
    "id": "r4-123",
    "correlation_id": "passage-123",
    "created_at": "2026-10-04T03:45:02+02:00",
    "producer": "governance-engine"
  },
  "outcome": "ESCALATE",
  "authority": {
    "authority_type": "human",
    "authority_id": "role:account-owner"
  },
  "policy_versions": [
    "PAYMENT-APPROVAL@1.4.0",
    "PII-PROTECTION@2.1.0"
  ],
  "obligations": [
    "obtain_explicit_human_approval",
    "record_receipt"
  ],
  "admissibility": {
    "allowed_resource_classes": [
      "training-provider-api"
    ],
    "jurisdictions": [
      "FR",
      "EU"
    ],
    "conditions": [
      "tls_required"
    ]
  },
  "scope": null,
  "issued_at": null,
  "expiry": null,
  "revocation_ref": null,
  "human_gate": {
    "required": true,
    "status": "pending",
    "approver_ref": null,
    "approved_at": null
  },
  "proof_requirements": [
    "approval_receipt",
    "provider_response_digest"
  ],
  "rationale": [
    "Engagement financier",
    "Données personnelles impliquées"
  ]
}

5.3 Exemple R4 — EXECUTE après Human Gate

{
  "meta": {
    "ra_version": "RA-153.1-2",
    "artifact_type": "R4_GovernanceDecisionMandate",
    "artifact_version": "0.1.0",
    "id": "r4-124",
    "correlation_id": "passage-123",
    "created_at": "2026-10-04T03:46:10+02:00",
    "producer": "governance-engine"
  },
  "outcome": "EXECUTE",
  "authority": {
    "authority_type": "human",
    "authority_id": "role:account-owner"
  },
  "policy_versions": [
    "PAYMENT-APPROVAL@1.4.0",
    "PII-PROTECTION@2.1.0"
  ],
  "obligations": [
    "obtain_explicit_human_approval",
    "record_receipt"
  ],
  "admissibility": {
    "allowed_resource_classes": [
      "training-provider-api"
    ],
    "jurisdictions": [
      "FR",
      "EU"
    ],
    "conditions": [
      "tls_required"
    ]
  },
  "scope": {
    "actions": [
      "create_enrollment"
    ],
    "objects": [
      "course:ABC"
    ],
    "max_cost": 900,
    "max_side_effects": 1
  },
  "issued_at": "2026-10-04T03:46:10+02:00",
  "expiry": "2026-10-04T03:51:10+02:00",
  "revocation_ref": null,
  "human_gate": {
    "required": true,
    "status": "approved",
    "approver_ref": "user-42",
    "approved_at": "2026-10-04T03:46:08+02:00"
  },
  "proof_requirements": [
    "approval_receipt",
    "provider_response_digest"
  ],
  "rationale": [
    "Engagement financier",
    "Données personnelles impliquées"
  ]
}

6. Contrats de plans

7. Plan normatif, provenance d’autorité et Human Gate

Le plan normatif est le seul plan autorisé à transformer une possibilité en mandat exécutable. Il DOIT distinguer quatre résultats :

Après résolution du Human Gate, le système DOIT recalculer R4. Il ne transforme pas simplement ESCALATE en EXECUTE par mutation du champ.

7.1 Paquet de décision Human Gate v0.2

Lorsqu’un R4 produit ESCALATE, human_gate.decision_packet est obligatoire. Il contient au minimum :

{
  "question": "Décision exacte à prendre",
  "decision_owner": "principal ou autorité légitime",
  "options": ["approve", "reject", "revise", "defer"],
  "consequences": ["effets matériels ou institutionnels pertinents"],
  "uncertainties": ["éléments non résolus"],
  "provenance": ["références utilisées pour formuler l’escalade"],
  "contestable": true
}

L’interface MAY ajouter explications ou simulations, mais MUST préserver le droit de refus et MUST NOT reformuler silencieusement l’option choisie en une autorisation plus large.

8. Mandats, délégation, narrowing, durée, révocation et replay

Un mandat R4=EXECUTE DOIT être borné par portée, autorité, politique, durée et exigences de preuve.

• Expiry : l’exécution après expiration est interdite.
• Not-before : l’exécution anticipée est interdite.
• Revocation : toute implémentation doit fournir un mécanisme permettant au plan exécutif de vérifier si le mandat a été révoqué.
• Replay : les actions non idempotentes doivent disposer d’une clé d’idempotence ou d’un mécanisme équivalent.
• TOCTOU : les faits déterminants de gouvernance qui peuvent changer entre R4 et l’effet doivent être revalidés juste avant l’exécution.
• Retry : un retry conserve exactement les mêmes contraintes d’admissibilité, sauf production d’un nouveau R4.

8.1 Délégation monotone

Un mandat enfant MUST référencer le mandat parent et MUST satisfaire :

child.actions ⊆ parent.actions
child.objects ⊆ parent.objects
child.max_cost ≤ parent.max_cost
child.max_side_effects ≤ parent.max_side_effects
child.expiry ≤ parent.expiry
child.resources ⊆ parent.admissible_resources

Une délégation qui élargit l’une de ces dimensions MUST échouer avec une erreur explicite de type RA-DELEGATION-WIDENING.

9. Routeur d’exécution et continuité du contexte de sécurité

Le Routeur d’exécution intervient uniquement après EXECUTE. Il DOIT sélectionner des ressources appartenant à l’espace admissible du mandat. Il PEUT optimiser coût, latence, énergie, qualité ou résilience à l’intérieur de cet espace.

Pour chaque ressource sélectionnée, l’implémentation DEVRAIT conserver : identifiant stable, classe, fournisseur, juridiction, version, identité d’exécution, capacités déclarées, statut d’admissibilité et éventuelle attestation de plateforme.

9.1 Contexte de sécurité lié

R5 MUST transporter ou référencer de manière vérifiable un contexte de sécurité dérivé du R4 courant. Il MUST inclure au minimum un identifiant de contexte ainsi que les digests des sources d’autorité, politiques et plafond d’autorité. L’exécution MUST revalider cette continuité immédiatement avant l’effet.

Une perte, substitution ou divergence d’un champ déterminant MUST bloquer l’exécution avec RA-SECURITY-CONTEXT-MISMATCH.

10. Preuve, execution integrity, Trust Passage et indépendance d’audit

Le profil v0.2 définit le Trust Passage Record comme la vue portable minimale d’un passage gouverné. Il contient au minimum :

{
  "passage_id": "...",
  "request_ref": "r0-...",
  "need_ref": "r1-...",
  "capability_ref": "r2-...",
  "strategy_ref": "r3-...",
  "decision_ref": "r4-...",
  "binding_ref": "r5-... | null",
  "evidence_ref": "r6-... | null",
  "outcome": "EXECUTE | ABSTAIN | REFUSE | ESCALATE",
  "policy_versions": ["..."],
  "authority_ref": "...",
  "timestamps": ["..."],
  "integrity": {"digest_alg":"sha-256","digest":"..."}
}

Le Trust Passage DOIT rester vérifiable après remplacement des composants d’exécution. L’attestation NE DOIT PAS être interprétée comme preuve de légitimité normative ; elle prouve au mieux des propriétés d’identité, d’intégrité ou d’exécution.

10.1 Structure probatoire v0.2

R6 MUST distinguer les objets suivants :

• execution_claim — ce que le système affirme avoir exécuté ;
• observed_effects — effets observables reliés à l’action ;
• receipts — reçus ou réponses du runtime/fournisseur ;
• attestations — attestations cryptographiques ou équivalentes si disponibles ;
• evidence_independence — classification de l’indépendance du producteur, du substrat et de l’auditeur.

La conformité v0.2 interdit d’inférer execution_success depuis un transcript ou un message de modèle seul.

11. API minimale proposée

Une implémentation non HTTP PEUT utiliser d’autres interfaces si elle fournit des opérations sémantiquement équivalentes.

12. Erreurs et événements

Les événements DEVRAIENT être publiés sous forme append-only : passage.created, semantic.resolved, capability.resolved, strategy.proposed, governance.decided, human_gate.requested, mandate.issued, mandate.revoked, execution.bound, execution.started, execution.completed, evidence.created, verification.failed.

13. Versionnement et compatibilité

Les artefacts DOIVENT déclarer une version sémantique. Un changement de champ obligatoire, de sémantique d’outcome ou d’invariant exige une version majeure. L’ajout rétrocompatible d’un champ optionnel peut utiliser une version mineure.

Une implémentation DEVRAIT conserver au moins deux dimensions de version séparées : version de l’architecture RA et version de chaque schéma/artefact.

14. Sécurité et modèle de menace

Le profil v0.2 doit être conçu contre au moins : prompt injection, documents hostiles, erreur de classification, fausse déclaration de capacités, stratégie manipulée, policy drift, conflit de versions, TOCTOU, révocation tardive, fallback dangereux, replay, falsification de preuve, substitution de ressource et dépassement de portée.

Les frontières de confiance DOIVENT être documentées. Les identités de composants ayant le droit de produire R4, R5 ou R6 DOIVENT être vérifiables dans le contexte de déploiement.

Les secrets, données sensibles et éléments de raisonnement internes ne doivent pas être copiés dans R6 si l’audit peut être satisfait par des références, résumés ou digests.

15. Profils de conformité

Le profil recommandé pour une implémentation de référence est RA-Bench-Ready.

15 bis. Profil d’application non normatif — App_IA_Citoyenne

Le package RA publie un profil d’alignement candidat pour App_IA_Citoyenne. L’application reste autonome et n’est pas déclarée conforme par défaut. Le profil montre comment la chaîne DITES → VOYEZ → ÉPROUVEZ → AUTORISEZ → VERSION PUBLIÉE peut être projetée sur R0→R6 tout en maintenant l’autorité du citoyen sur la version engageante.

Référence : application-profiles/App_IA_Citoyenne_RA153_Alignment_Profile_v0.1.html.

16. Exemple bout-en-bout

1. R0 contient « Inscris-moi à cette formation », l’identité de l’acteur et le contexte.
2. R1 identifie inscription, données personnelles et engagement financier.
3. R2 requiert accès au fournisseur, capacité d’inscription, paiement éventuel et preuve.
4. R3 propose une stratégie d’inscription avec étape de confirmation.
5. Le plan normatif détecte qu’un engagement financier exige confirmation humaine : R4=ESCALATE.
6. Le Human Gate recueille l’approbation et son contexte.
7. Le plan normatif réévalue et produit un nouveau R4=EXECUTE, coût maximum 900 €, une inscription, durée 5 minutes.
8. Le Routeur d’exécution sélectionne uniquement un fournisseur admissible et produit R5.
9. L’exécution vérifie expiration/révocation puis effectue exactement une inscription.
10. R6 relie approbation, mandat, ressource, action, reçu et digests ; l’auditeur peut vérifier que l’effet est resté dans le mandat.

17. Checklist d’implémentation

• [ ] R0→R6 sont validés par schéma et versionnés.
• [ ] Aucun plan sémantique/capacitaire/cognitif ne peut produire un effet de domaine.
• [ ] EXECUTE/ABSTAIN/REFUSE/ESCALATE sont distincts et persistés.
• [ ] EXECUTE est le seul résultat pouvant produire un mandat.
• [ ] Un mandat contient autorité, politiques, portée, expiry et obligations de preuve.
• [ ] Le plan exécutif vérifie expiration, révocation et TOCTOU avant l’effet.
• [ ] Le fallback ne peut jamais sortir de l’espace admissible.
• [ ] Le replay est contrôlé pour les actions non idempotentes.
• [ ] Le Human Gate produit une nouvelle décision R4, pas une simple mutation de statut.
• [ ] R6 permet de vérifier mandat→ressource→action→preuve.
• [ ] Les extensions propriétaires sont identifiées et n’affaiblissent aucun invariant.
• [ ] Les hooks RA-Bench sont disponibles pour le profil RA-Bench-Ready.
• [ ] R0 distingue sources d’autorité, sources informatives et sources non fiables.
• [ ] R2 fixe un authority ceiling vérifiable.
• [ ] Toute délégation est monotone et liée à son mandat parent.
• [ ] R5 vérifie la continuité du contexte de sécurité avant effet.
• [ ] Human Gate transporte un decision packet contestable.
• [ ] R6 distingue claim, effet observé et preuve.
• [ ] Le niveau d’indépendance de la preuve/audit est explicitement qualifié.