RA-153.1-2 — Implementation Specification v0.2

1. Status and scope

RA-153.1-2 is a reference architecture. This Implementation Specification defines a concrete profile for implementing its responsibilities, interfaces and invariants without prescribing a particular language, provider, LLM, policy engine, agent protocol or attestation mechanism.

An implementation may use REST, gRPC, messaging, library calls or a combination. Conformance depends on preserving normative properties, rather than necessarily reproducing the illustrated software topology.

2. Normative terminology

3. Execution architecture

Client / Application
        ↓
R0 RequestEnvelope
        ↓
[Semantic plane] → R1 NeedDescriptor
        ↓
[Capability plane] → R2 CapabilityRequirementSet
        ↓
[Cognitive plane] → R3 StrategySet
        ↓
[Normative plane] → R4 GovernanceDecision / Mandate
        ├─ ABSTAIN → end without effect
        ├─ REFUSE → end without effect
        ├─ ESCALATE → Human Gate / other authority
        └─ EXECUTE
               ↓
[Execution plane] → R5 ExecutionBinding
               ↓
          Domain effect
               ↓
[Evidence plane] → R6 EvidenceBundle

MUST. No component upstream of the normative plane may directly create a domain effect. MUST. No domain effect may be produced unless the current state holds a valid EXECUTE mandate.

4. State machine

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

MUST NOT. A transition from a terminal state without effect to BOUND or EXECUTING is prohibited. New information requires a new R4 decision.

5. R0 → R6 artifacts

All artifacts MUST include a stable identifier, a correlation_id, an artifact version, creation timestamp and provenance. Detailed structures are supplied in the accompanying JSON Schema bundle.

5.1 R0 example

{
  "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": "Enroll me in this training course",
    "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 R4 example — 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": [
    "Financial commitment",
    "Personal data involved"
  ]
}

5.3 R4 example — EXECUTE after 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": [
    "Financial commitment",
    "Personal data involved"
  ]
}

6. Plane contracts

7. Normative plane, authority provenance and Human Gate

The normative plane is the only plane authorized to turn a possibility into an executable mandate. It MUST distinguish four outcomes:

After Human Gate resolution, the system MUST recompute R4. It does not simply turn ESCALATE into EXECUTE by mutating the field.

7.1 Human Gate decision packet v0.2

When R4 produces ESCALATE, human_gate.decision_packet is mandatory. It contains at least:

{
  "question": "Exact decision to be made",
  "decision_owner": "principal or legitimate authority",
  "options": ["approve", "reject", "revise", "defer"],
  "consequences": ["relevant material or institutional effects"],
  "uncertainties": ["unresolved issues"],
  "provenance": ["references used to formulate the escalation"],
  "contestable": true
}

The interface MAY add explanations or simulations, but MUST preserve the right to refuse and MUST NOT silently reinterpret the chosen option as a broader authorization.

8. Mandates, delegation, narrowing, lifetime, revocation and replay

An R4=EXECUTE mandate MUST be bounded by scope, authority, policy, lifetime and evidence requirements.

• Expiry : execution after expiration is prohibited.
• Not-before : early execution is prohibited.
• Revocation : every implementation must provide a mechanism allowing the execution plane to check whether the mandate has been revoked.
• Replay : non-idempotent actions must have an idempotency key or an equivalent mechanism.
• TOCTOU : authority-relevant facts that can change between R4 and the effect must be revalidated immediately before execution.
• Retry : a retry preserves exactly the same admissibility constraints unless a new R4 is produced.

8.1 Monotonic delegation

A child mandate MUST reference its parent mandate and MUST satisfy:

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

A delegation that expands any of these dimensions MUST fail with an explicit error of type RA-DELEGATION-WIDENING.

9. Execution Router and security-context continuity

The Execution Router operates only after EXECUTE. It MUST select resources within the mandate’s admissible space. It MAY optimize cost, latency, energy, quality or resilience within that space.

For each selected resource, the implementation SHOULD retain: stable identifier, class, provider, jurisdiction, version, execution identity, declared capabilities, admissibility status and any platform attestation.

9.1 Bound security context

R5 MUST carry, or verifiably reference, a security context derived from the current R4. It MUST include at least a context identifier and digests of authority sources, policies and the authority ceiling. Execution MUST revalidate this continuity immediately before the effect.

Loss, substitution or divergence of an authority-relevant field MUST block execution with RA-SECURITY-CONTEXT-MISMATCH.

10. Evidence, execution integrity, Trust Passage and audit independence

The v0.2 profile defines the Trust Passage Record as the minimum portable view of a governed passage. It contains at least:

{
  "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":"..."}
}

The Trust Passage MUST remain verifiable after execution components are replaced. Attestation MUST NOT be interpreted as proof of normative legitimacy; at most it establishes properties of identity, integrity or execution.

10.1 Evidence structure v0.2

R6 MUST distinguish the following objects:

• execution_claim — what the system claims to have executed;
• observed_effects — observable effects bound to the action;
• receipts — receipts or responses from the runtime/provider;
• attestations — cryptographic or equivalent attestations, where available;
• evidence_independence — classification of the independence of the producer, substrate and auditor.

v0.2 conformance prohibits inferring execution_success from a transcript or model message alone.

11. Proposed minimum API

A non-HTTP implementation MAY use other interfaces if it provides semantically equivalent operations.

12. Errors and events

Events SHOULD be published in append-only form: 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. Versioning and compatibility

Artifacts MUST declare a semantic version. Changing a required field, outcome semantics or an invariant requires a major version. A backward-compatible optional field can use a minor version.

An implementation SHOULD retain at least two separate version dimensions: the RA architecture version and the version of each schema/artifact.

14. Security and threat model

The v0.2 profile must be designed to address at least: prompt injection, hostile documents, classification errors, false capability claims, manipulated strategies, policy drift, version conflicts, TOCTOU, late revocation, unsafe fallback, replay, evidence falsification, resource substitution and scope violations.

Trust boundaries MUST be documented. The identities of components entitled to produce R4, R5 or R6 MUST be verifiable in the deployment context.

Secrets, sensitive data and internal reasoning must not be copied into R6 when references, summaries or digests can meet the audit requirements.

15. Conformance profiles

The recommended profile for a reference implementation is RA-Bench-Ready.

15a. Non-normative application profile — App_IA_Citoyenne

The RA package publishes a candidate alignment profile for App_IA_Citoyenne.. The application remains independent and is not deemed conformant by default. The profile shows how SAY → SEE → TEST → AUTHORIZE → PUBLISHED VERSION can map to R0→R6 while preserving the citizen’s authority over the version that carries a commitment.

Reference: application-profiles/App_IA_Citoyenne_RA153_Alignment_Profile_v0.1.html.

16. End-to-end example

1. R0 contains “Enroll me in this training course”, the actor’s identity and context.
2. R1 identifies enrollment, personal data and a financial commitment.
3. R2 requires provider access, enrollment capability, any necessary payment capability and evidence.
4. R3 proposes an enrollment strategy with a confirmation step.
5. The normative plane detects that the financial commitment requires human confirmation: R4=ESCALATE.
6. Human Gate records the approval and its context.
7. The normative plane re-evaluates and produces a new R4=EXECUTE, maximum cost €900, one enrollment, valid for 5 minutes.
8. The Execution Router selects only an admissible provider and produces R5.
9. Execution checks expiry/revocation and performs exactly one enrollment.
10. R6 binds approval, mandate, resource, action, receipt and digests; an auditor can verify that the effect stayed within the mandate.

17. Implementation checklist

• [ ] R0→R6 are schema-validated and versioned.
• [ ] No semantic/capability/cognitive plane can produce a domain effect.
• [ ] EXECUTE/ABSTAIN/REFUSE/ESCALATE are distinct and persisted.
• [ ] EXECUTE is the only outcome that can produce a mandate.
• [ ] A mandate includes authority, policies, scope, expiry and evidence obligations.
• [ ] The execution plane checks expiry, revocation and TOCTOU before the effect.
• [ ] Fallback can never leave the admissible space.
• [ ] Replay is controlled for non-idempotent actions.
• [ ] Human Gate produces a new R4 decision rather than merely changing a status.
• [ ] R6 enables mandate→resource→action→evidence verification.
• [ ] Proprietary extensions are identified and weaken no invariant.
• [ ] RA-Bench hooks are available for the RA-Bench-Ready profile.
• [ ] R0 distinguishes authority sources, informational sources and untrusted sources.
• [ ] R2 establishes a verifiable authority ceiling.
• [ ] Every delegation is monotonic and bound to its parent mandate.
• [ ] R5 verifies security-context continuity before the effect.
• [ ] Human Gate carries a contestable decision packet.
• [ ] R6 distinguishes claims, observed effects and evidence.
• [ ] The independence level of evidence/audit is explicitly characterized.