Volume 1 of 2. Doctrinal framework
The present document is the first of two volumes that together compose version 1.0 of the RAISE framework. This split is not a division of convenience; it reflects the dual nature of the framework made explicit in §2 of the present volume, both an architecture framework and a doctrine of governance through architecture. Volume 1 exposes the doctrinal architecture of the framework. Volume 2 (internal reference TI-2026-FRMK-RAISE-v1.0-V2, Operational application) exposes its sectoral implementation, its limits, and its finishing.
Volume 1 contains the author’s preamble, the methodological note (refutation criterion, irreducible transformations T1 to T5, endogenous structural implication, method of construction of the framework), Part I (Argumentative foundations, §1 to §3), Part II (Architectural core, §4 to §6), a short closing that recalls the central formulas and points to Volume 2, Annex A (operational glossary), and Annex E (Claims, Evidence, and Conditions of falsification table).
Volume 2 contains Part III (Operationalisation, §7 to §9, maturity model and sectoral application to the three principal terrains and the three secondary sectors), Part IV (Discussion and finishing, §10 to §12, authentic limits with criticality threshold model C*, expected evolution, doctrinal FAQ), the full closing, Annex B (regulatory sources of reference by sector), Annex C (Twingital doctrinal crossroads), and Annex D (intellectual property notice, version and history).
The recommended reading sequence is linear: Volume 1 then Volume 2. Volume 1 can be read alone as a doctrinal exposition without loss of internal intelligibility; Volume 2 presupposes the acquisition of Volume 1 on the pillars, the matrix, and the anti-patterns. The two volumes share internal reference, Soleau filing, and citation conditions. The intellectual property notice is consolidated in Annex D of Volume 2 and applies to both volumes.
Author’s preamble
Methodological note. Refutation criterion, irreducible transformations T1 to T5, structural implication, method of construction
Part I. Argumentative foundations
§1. Genesis. Three failures that call for an architecture framework
§2. Delimitation. What RAISE is, what it is not
§3. Differentiation. RAISE and the existing frameworks
Part II. Architectural core
§4. The five pillars, in detail
§5. 5×5 interdependency matrix
§6. Anti-patterns. Eight configurations to diagnose
Closing of Volume 1, opening onto Volume 2
Annexes
A. Operational glossary E. Claims / Evidence / Conditions of falsification table
RAISE is not a governance framework added to the architecture; it is the architecture made governable.
This sentence is the central statement of the document that follows. Everything that comes after is its instruction, its justification, and its test. If it appears obvious at first reading, that is because it states what should be obvious; but the observed practice of AI deployments in regulated environments shows that it is not. Compliance, governance, auditability, explainability, and operational safety continue to be treated as layers added to a system that is already architecturally complete, that is, in practice, to a system that is already architecturally not governable.
The present document does not propose one more framework. It proposes a framework of a nature distinct from those currently in circulation. NIST AI RMF manages risk; ISO/IEC 42001 manages a system; the EU AI Act states obligations; Microsoft RAI Maturity Model measures organisational maturity; sectoral grids (HAS, EBA, ANSSI) qualify specific devices. None of the widely adopted frameworks explicitly provides this cyclic architectural grammar at the design level. No widely disseminated framework appears to occupy this architectural function explicitly and centrally, that is, to make the design of the system its primary object rather than its derived constraint. This formulation calls for an immediate nuance, developed in §3: existing frameworks are not indifferent to design, they touch it through constraint. The MAP function of NIST AI RMF imposes architectural artefacts (system boundaries, risk surfaces); ISO/IEC 42001, in its mature implementations, orients design through internal control requirements; the EU AI Act, through its Annex IV and its post-market surveillance obligations, progressively imposes design-time obligations. The difference with RAISE is therefore not binary, it is graded: RAISE takes design as its primary object, where existing frameworks touch it as a derived consequence of their main function. RAISE occupies this case without claiming it absolutely empty; it does not substitute for any of the existing frameworks, and it presupposes them.
Three differentiation levers justify the production of this document rather than a short positioning text. First lever: RAISE models the dependencies between its five pillars as a cyclic structure, not as a linear chain. It is, to our knowledge, the only cartography that makes return loops visible, for example the return of decisional explainability toward active regulatory reading, or the return of governance toward the qualification of what counts as validation. Second lever: the framework is European-centred by origin, and operates at the level where the European legislator has chosen to operate, that is, at the level of system design and not of its deployment. Third lever: the sectoral test conducted in Part III is not limited to a generic instantiation; each sector (Healthcare, Finance and Insurance, Defence and National Security) is treated through the characteristic tension it makes visible in the framework’s matrix. No widely disseminated competing framework appears to do this work at this level and with this typed cyclic structure.
The document is organised for three distinct readings. The systems architect will read it linearly, from foundations to operationalisation. The compliance officer will read it by section, mobilising the pillars as an evaluation grid. The diagnostician, whether consultant, internal audit, or risk management, may enter directly through the anti-patterns of §6, which provide a rapid analysis instrument. None of these readings exhausts the document, and each refers to the other two.
One methodological precision, finally. This document is doctrinal. It does not contain quantified empirical studies with before-and-after measurement. This absence is not a gap but a consequence of the nature of an architecture framework: the test is not the measured improvement of an aggregate indicator, but the capacity to support the design of systems that could not have been designed satisfactorily without it. The proof is of structure, not of performance. Doctrinal proof precedes empirical test; it does not substitute for it. §10 explicitly states the limits of this posture.
A strong doctrine must state how it fails. The criterion below is the test that distinguishes, on any deployment, the implementation of the framework from the simulation of an implementation.
RAISE fails if its application modifies no design decision, makes no responsibility more nominative, contractualises no critical interface, transforms no validation protocol, and qualifies no recipient of explanation. In that case, RAISE has not been applied; it has been recited.
This criterion extends and operationalises the central formula of the document, stated in §3 and recalled in the closing: a framework that does not change design only changes documentation. The refutation criterion adds a second, harder affirmation: the absence of structural effect on any one of the five pillars, observable as decision modification, is not a weakness of implementation. It is a refutation of the application itself. The framework may remain valid in doctrine; this deployment, however, has not taken place in the architectural sense.
This discipline applies also to the critique of the framework. A demonstration that RAISE, correctly applied, has not produced one of the five expected effects would be a refutation of the framework. No less demanding objection stands as refutation.
The criterion as posed remains, at this level of abstraction, open to interpretation. To render it discriminating at an operational level, the framework distinguishes five irreducible transformations whose simultaneous absence disqualifies any deployment, and whose simulation is technically more costly to maintain over time than the implementation itself.
T1. Modification of at least one structural design decision (architectural object created, suppressed, displaced, or contractualised), with versioned trace signed by a responsible architect.
T2. Nomination of at least one opposable responsibility, with published mandate and blocking procedure exercised at least once on a real design decision.
T3. Contractualisation of at least one critical interface, comprising versioned schema, opposable semantics, quality guarantees, and rupture clause, with an identified consumer or producer.
T4. Implementation of at least one contextual validation protocol distinct from benchmark, with qualified cohort, documented representativeness criteria, and revalidation triggering by signal and not by calendar.
T5. Qualification of at least one recipient of explanation by usage frame, with traced production protocol, and observable differentiation of the explanation according to the recipient.
The cost asymmetry between simulation and implementation is what makes the criterion discriminating. A simulation of T2 by documentation forces the organisation to keep producing documentation indefinitely; a simulation of T1 or T3 requires signed and versioned traces that resist forensic audit; a simulation of T4 requires the maintenance of a distinct cohort that the slightest operational drift disqualifies; a simulation of T5 mechanically produces differentiated explanations that any recipient can compare. The criterion’s discriminability comes from this differential resistance to simulation, not from the confidence granted to the organisation’s declaration.
The central formula of the document (a framework that does not change design only changes documentation) must be read, at this stage, as the statement of a structural implication that must now be made explicit. Let Δ(design) be the observable modification of the structural design decisions of a system, measured through transformations T1 to T5. Let Δ(governability) be the observable modification of the governability of the system, measured through the satisfaction of the five pillars and their matricial articulation. The central thesis states:
If Δ(design) = 0, then Δ(governability) = 0.
In other terms: no modification of governability is obtained without a corresponding modification of design. The contrapositive is more telling: any real modification of governability has an observable trace in design. An organisation that claims to have improved its governability without being able to produce at least one trace of design modification is mistaken about its own state, or produces compliance by amendment.
The implication is not a theorem; it is a structural commitment. Its refutation would be the exhibition of a case where an improvement of governability, measured according to the pillars and the matrix, is obtained without any modification of design. No case of this nature has been identified in the publicly documented deployments on which the doctrine is constructed. The central thesis therefore holds, until a counter-example is exhibited, as a structural implication of the doctrine.
This implication must be read within its scope of definition. The governability in question is endogenous to the system, that is, produced by its architectural design. It is distinct from exogenous governance, which may be imposed by infrastructural or regulatory means external to the system’s architecture: market kill switches, prudential circuit breakers, capital constraints, operational caps imposed by the supervisory authority. Such devices alter the admissibility of the system’s outputs without modifying its internal architecture. They constitute a distinct form of governance, complementary to RAISE but not covered by it. The structural implication stated does not bear on governability in the absolute sense, but on endogenous or architectural governability. This restriction preserves the thesis from any confusion with exogenous governance mechanisms, and specifies the domain where falsification would be admissible.
To allow methodological critique of the framework beyond critique of its statements, the method of construction is made explicit. Four stages were followed.
First stage. Multi-sectoral observation. AI deployments in regulated environments between 2022 and 2026, in the Healthcare, Finance, Defense, Public, and Critical Infrastructure sectors, by direct participation or by public documentation of governability incidents, supervisory authority decisions, and litigation. The observations do not constitute a statistical sample; they constitute a qualitative corpus on which the doctrinal regularity is constructed.
Second stage. Comparative analysis of existing frameworks. NIST AI RMF, ISO/IEC 42001, EU AI Act, Microsoft RAI Maturity Model, sectoral grids HAS, EBA Guidelines, ANSSI recommendations, were qualified according to their primary function (risk management, management system, statement of obligations, maturity measurement, sectoral qualification) and according to their point of contact with the design of the system (through constraint or through principle).
Third stage. Abstraction of recurrent patterns. Observed failure configurations and observed success configurations were abstracted in the form of five interdependent dimensions (the five pillars), of their typed cyclic dependencies (the 5×5 matrix), of their typed pathological configurations (eight canonical anti-patterns and four second-order patterns), and of their implementation trajectory (four-level maturity model with controlled regression).
Fourth stage. Test by counterfactuals and partial demonstration. The constructive counterfactuals of §5.6 and the partial demonstration of edge necessity of §5.5 constitute the first structural tests of the framework. The irreducible transformations T1 to T5 constitute the operational tests.
This method produces a framework defensible as a doctrinal regularity, not as a formal theorem. Its refutation proceeds by architectural counter-example rather than by logical demonstration. The Annex E table synthesises the claims, their evidence, and their conditions of falsification.
RAISE does not arise from a theoretical intuition. It arises from observation, conducted over several years and several regulated sectors, of three structural failures that recur with sufficient regularity to no longer be treated as implementation accidents. These three failures are not execution defects; they are design defects. They emerge when the AI system’s architecture is drawn first, and when compliance, governance, and auditability are added afterwards. They are not repairable by effort of will or by supplementary documentation. They are repairable by changing the order of operations.
The distinction that structures everything that follows is the following: compliance by construction versus compliance by amendment. It is not synonymous with the familiar distinction between security by design and bolt-on security, because it does not bear on a functional layer, but on the entire grammar of designing an AI system. It states that compliance with a normative corpus cannot be obtained, in systems whose functional specification depends on the data and on the normative frames themselves, except provided that this specification be constructed with compliance as a definitional constraint, not as a validation test.
The first failure relates to what the literature on technical debt names retrofitting, but which takes in AI a specific form: performance is optimised first, then compliance is added in the form of superimposed layers (audit logs, governance dashboards, a posteriori explainability devices, registers of automated decisions). Each of these layers is, taken in isolation, serious. The aggregate is not, because it does not correct the architectural property that makes the system not governable: its initial design decision was taken without the governability constraint.
The operational signature of this failure is observable. The system functions. Performance indicators are met. Compliance devices are present. Yet, at every incident, at every supervisory authority request, at every edge case, the marginal cost of justifying a decision grows faster than the volume of decisions. Compliance by amendment produces this inverse asymptote: the more the system is used, the heavier it becomes to justify.
The second failure is not a defect of governance. It is a defect of position of governance within the organisation. AI committees exist; they meet; they issue opinions. But their opinions do not alter system design because the architectural decision chain runs in parallel, without effective intersection. This configuration is so widespread that it has its own category in the risk governance literature, that of governance theatre. It is recognised by a simple sign: governance produces recommendations that have no binding force on the design of the system, and design produces architectures that do not request governance’s opinion before being frozen.
This siloing is not repairable by staffing increase or by internal charter. It is repairable by the structural position of governance in the architectural pipeline, that is, by a named, opposable responsibility, capable of altering the design decision before it is taken. The gap between a named responsibility and a diffuse responsibility is not an organisational chart detail. It decides the governability of the system.
The third failure has long been documented in the audit society literature, and takes in AI deployments a particularly acute form. The audit exists; it is conducted according to the rules of the art; its deliverables are produced on schedule and archived per traceability requirements. But none of its observations is capable of altering the operational decision, because the moment of audit is subsequent to the moment when the design decision was taken and to the moment when the system is in production. The audit, in this configuration, decides nothing; it ratifies what was decided without it.
The distinction that cuts through this failure is the following: a control device has governance value if and only if it has the effective capacity to alter the decision. The presence of the device is not proof of its function. This distinction will be taken up again in §6, where it structures the diagnosis of the eight canonical anti-patterns. It is stated here for what it is: the touchstone of the framework.
One will object that industrial architecture has long integrated regulatory constraint into design. Civil engineering, aeronautics, pharmaceuticals, are not designed and then made compliant; they are designed under the constraint of compliance. The objection is exact for material products and for classical industrial processes. It does not hold for AI systems, and the reason for this difference is precisely what justifies a dedicated framework.
In a material product, the functional specification pre-exists the encounter with the normative frame. The normative frame comes downstream to qualify what has been specified. In an AI system, the functional specification itself depends on available data, operational thresholds, conditions of use, and normative frames that qualify the use. There is no functional specification of an AI system before its encounter with the applicable normative corpus, because the normative corpus is constitutive of what will functionally be defined as acceptable. RAISE acknowledges this circularity and proposes a grammar to treat it.
The principal objection to the framework’s epistemic status is the absence of empirical anchoring. RAISE constructs its framework by qualitative multi-sectoral observation, by comparative analysis of existing frameworks, and by counterfactual test. This construction leaves the question open: can one read a publicly documented case through the grid of the five pillars, and does the retrospective reading make the failures appear as architectural rather than operational? This section proposes such a reading, with illustrative and not demonstrative value.
The case retained is the affair known as the Dutch childcare benefits scandal (Toeslagenaffaire), conducted by the Dutch tax administration (Belastingdienst) between approximately 2013 and 2019. The algorithmic system mobilised to detect fraud in childcare benefits wrongly accused tens of thousands of families, with disproportionate impact on families with dual nationality or non-Dutch origin. The sequence became political: parliamentary inquiry committee (POK), final report Ongekend onrecht in December 2020, resignation of the Rutte III government in January 2021, ongoing process of reparation and institutional reform. The Dutch data protection authority (Autoriteit Persoonsgegevens) confirmed in 2020 violations of European data protection regulation.
The retrospective reading by the five pillars makes the failures appear as architectural and not as operational accidents.
Pillar R, Regulatory Architecture. The system was designed without active integration of the applicable normative corpus, notably the anti-discrimination principles of European law and the data protection regulation that came into force in 2018. The use of indicators correlated with nationality or origin was documented internally without any active reading qualifying it as legal exposure. Failure of pillar R by declarative reading.
Pillar A, Accountability and Governance. The system’s responsibility chain was diffuse between the technical services of the tax administration, its administrative hierarchy, and political oversight, without any nominally identified person simultaneously having the power and the obligation to alter the automated decision in the light of internal alerts or external complaints documented as early as 2017. Failure of pillar A by diffuse responsibility.
Pillar I, Interoperability Standards. Data sharing between administrations occurred without explicit contractualisation of source qualification conditions, which allowed the propagation of debatable classifications from one system to another without effective point of contestation. Failure of pillar I by informal-export interoperability.
Pillar S, Safety and Operational Validation. System validation was not conducted on a representative cohort neutral with respect to indicators correlated with origin, and operational monitoring did not detect systemic drift despite internal signals accumulated over several years. Failure of pillar S by absence of contextual validation and by monitoring failure.
Pillar E, Explainability and Ethics. The families concerned received no exploitable explanation of the automated decision, and no effective contestation mechanism was available before individual judicial proceedings. Failure of pillar E by absence of qualification of explanation recipients.
The retrospective analysis does not prove that RAISE would have prevented the failure. It states that the observed failures correspond to the canonical failures diagnosable by the five pillars, and that a RAISE-aligned architecture would have, at minimum, rendered these failures diagnosable before the incident rather than after. The difference between ex ante diagnosability and ex post reconstruction is the architectural value that the framework claims to produce. It does not dispense with a stabilised empirical demonstration that RAISE implementation effectively alters failure rate or severity; it provides, at minimum, a case where the grid of the five pillars makes the failures legible as architectural and not as accidental. The Toeslagenaffaire case is here proposed as a reading grid, not as a test case; its function is to instantiate the framework’s diagnostic claim on a publicly documented terrain.
A framework whose nature is not specified ends confused with what it is not. This section is short, operational, and serves as semantic marking. It must be citable as is.
| RAISE is | RAISE is not |
|---|---|
| An architecture framework, a grammar for structuring the design of an AI system | A quality or AI management system |
| An analytical model, a device for mapping the dependencies between five architectural dimensions | A certification standard |
| A design decision tool, an instrument mobilised upstream of functional specification | An a posteriori audit grid |
| A European-centred framework, designed to operate at the level where the European legislator has chosen to operate | A transposition of an American or international framework |
| A sectorally instantiable framework, tested on three distinct sectors via their characteristic tension | A generic framework applicable indifferently to any AI deployment |
| A doctrinal framework, produced by a single actor, defensible by construction and critical of its own scope of validity | A norm collectively adopted by a standardisation body |
This delimitation has a direct consequence on the document’s epistemic status. RAISE does not claim the collective legitimacy of an ISO or an intergovernmental standard. It claims the doctrinal robustness of a framework conceived, defended, and critiqued by its author. This posture requires, in return, explicit self-critique; it constitutes §10. A doctrine that does not state its own limits is not a doctrine; it is an opinion.
One last point of clarification is necessary before what follows. RAISE is presented here as an architecture framework; its observed practice constitutes it, at a higher level, as a doctrine of governance through architecture. This internal tension deserves to be named rather than evaded. A framework is a design instrument; a doctrine is a system of thought structuring decisions. RAISE is, operationally, both: it provides the grammar of design (framework), and it carries a stance on how design should be instructed by governability (doctrine). This dual nature is the source of its operational power for a CTO or a COMEX; it is also what distinguishes it from a purely technical framework, and what justifies its inscription in the Twingital Institute corpus as a doctrinal object and not as an operational specification.
Five levels of operation of RAISE must be distinguished to avoid the confusion that threatens any object simultaneously doctrinal and operational. At the doctrinal level, RAISE states a thesis on governability through design (preamble, methodological note). At the framework level, it provides the architectural grammar (five pillars, typed cyclic matrix, ternary typology of edges; §4 and §5). At the diagnostic method level, it instruments the diagnosis of deployments (eight canonical anti-patterns §6.2, four second-order patterns §6.6, maturity false positives §6.5, integration tests). At the maturity model level, it describes the implementation trajectory (four levels §7.1, controlled regression §7.3). At the CTO instrument level, it renders strategic refusals defensible (§6.4) and formulates the irreducible transformations T1 to T5 (methodological note). These five levels do not overlap by accident; they are the doctrinal, conceptual, diagnostic, dynamic, and operational expression of one and the same object of architecture.
The present section is central to the argumentative foundations. Without it, the mother thesis remains assertive. It unfolds in six moves. First the orientation map, a synthetic comparative table that situates RAISE relative to the five relevant existing frameworks. Then the pillar-by-pillar detail of each of these frameworks. Finally, the sub-paragraph dedicated to the most robust objection, that of the saturated landscape.
| Framework | Scope | Nature | Purpose | Certifiable | Sectoral | Operational alone | Captures what others do not capture |
|---|---|---|---|---|---|---|---|
| NIST AI RMF | All AI systems, U.S., voluntary | Risk management framework | Identify, measure, manage risk | No | No | No | Risk cartography non-specific to regulated AI |
| ISO/IEC 42001 | All AI systems, international | Management system | Manage an AI organisation | Yes | No | No | Organisational maturity of the AI function |
| EU AI Act (read alone) | All AI systems placed on the EU market | Normative text | State obligations | Not applicable (legal text) | Implicit (by risk class) | No | Applicable legal obligations |
| Microsoft RAI Maturity Model | Organisations | Organisational maturity model | Assess the maturity of an AI function | No (self-assessment) | No | No | Maturity by organisational dimension |
| HAS. AI medical devices grid | AI medical devices, France | Sectoral grid | Qualify an AI-MD | No (opinion) | Yes (health) | No | French sectoral qualification |
| RAISE | AI systems in regulated environments | Architecture framework | Design a system governable by construction | No | Sectorally instantiable | No; it presupposes the frameworks above | Cyclic structure of design dependencies between 5 pillars |
The line-by-line reading of the table reveals an asymmetry that no marketing positioning can mask: none of the widely adopted frameworks explicitly occupies the RAISE case. They manage a risk, certify an organisation, state obligations, measure a maturity, or qualify a sectoral device. None appears to provide, as a main and explicit function, the architectural grammar that allows design to be structured.
This differentiation calls for a nuance that quick reading might miss. The existing frameworks are not indifferent to design; they touch it through constraint. The map function of NIST AI RMF, which requires identification of usage contexts and risk sources, operates indirectly on design by imposing objects that design must accommodate. ISO/IEC 42001, in certain of its advanced implementations, influences design through internal control and change management requirements. RAISE claims to structure design through principle: its grammar operates upstream of constraints, in the grammar itself that makes constraints intelligible. The difference is not one of degree, it is one of the order of operations. But it does not consist in saying that existing frameworks ignore design; it consists in saying that their contact with design is derived from their primary function, where that of RAISE is constitutive of its very function. RAISE is therefore not a competitor of these frameworks; it is of distinct nature. This distinction is not rhetorical: it conditions the mode of use. NIST RMF is mobilised to decide what to measure. ISO 42001 is mobilised to structure an organisation. RAISE is mobilised to structure a system. These are not the same objects of intervention.
NIST AI RMF is an American, voluntary framework, published by the National Institute of Standards and Technology, whose function is the identification, measurement, and management of risks associated with the deployment of an AI system. It is organised around four functions (govern, map, measure, manage) that structure a risk management cycle. Its principal quality is the rigour of the cartography it proposes to identify risk sources; its principal limit, from the standpoint of an architecture framework, is that it says nothing about the design of a system. It says how to manage the risk of a system that exists. It does not say how to design a system whose risk is governable. The distinction is not slight. A risk management framework presupposes a prior object of risk; an architecture framework shapes its possibility.
ISO/IEC 42001 is a certifiable AI management system, which belongs to the family of management standards (ISO 9001 for quality, ISO 27001 for information security, ISO 13485 for medical devices). Its value is precisely what it claims: it provides the framework of the organisation that manages the AI function, from roles and responsibilities to performance measurement of the management system. It does not provide, and does not intend to provide, a grammar for designing the AI system itself. A RAISE-aligned deployment in an ISO 42001-certified organisation is not a redundancy; it is an articulation. The management system manages the function; the architecture framework shapes the system.
The EU AI Act is a normative text, not operational alone. It states obligations (classification by risk class, technical documentation requirements, human oversight, transparency, risk management, data quality, robustness) applicable to systems placed on the market or put into service in the European Union. Read alone, it does not say how these obligations are instantiated in the design of a system. It calls, by construction, for operational frameworks that translate its requirements into architectures. RAISE is one of these frameworks. It is not a competitor of the AI Act; it is one of the possible modes of operationalisation of its requirements at the design level.
Microsoft’s Responsible AI Maturity Model is an organisational maturity model. It assesses, along several dimensions (governance, culture, processes, tooling, competencies), the maturity level of an organisation in the practice of responsible AI. The comparison with RAISE is asymmetric, and this must be explicitly acknowledged: an organisational maturity model and an architecture framework are objects of different natures. The first measures an organisation; the second structures a system. If the comparison is nevertheless relevant here, it is because the two frameworks frequently meet in positioning conversations, and it is necessary to mark the non-substitutability. RAISE is not an MM; an MM is not an architecture framework.
The Haute Autorité de Santé (French Health Authority) has published, in France, an analytical grid for AI-based medical devices, which structures the HAS evaluation of reimbursement requests. The grid is sectoral, French, and operates at the level of a specific device. It is cited here because it illustrates a general category: national sectoral grids, whether the EBA for European finance, ANSSI for critical infrastructures in France, or the FDA for medical devices in the United States. None of these grids is a general architecture framework. All presuppose that a system exists and that the task is to qualify it. RAISE operates one notch earlier: at the level of the design that makes the system qualifiable.
The most robust objection to RAISE is not frontal. It is integrative. It is formulated as follows:
The normative landscape is saturated. The combination of NIST AI RMF for risk management, ISO/IEC 42001 for the management system, the EU AI Act for obligations, and sectoral grids for device qualification, already covers all the dimensions that RAISE claims to cover. What is presented as a new framework is in reality a rhetorical re-syntactisation of elements already available. Furthermore, an architecture framework designed and defended by a single actor cannot claim the doctrinal legitimacy that a framework of this nature requires; legitimacy, in architectural matters, is a collective fact.
The objection is serious, and it deserves a two-step reply.
First step. The added coverage of existing frameworks does not produce the architecture framework that none of them is. The sum NIST + ISO 42001 + AI Act + sectoral does not provide a grammar of design; it provides a superposition of heterogeneous instruments, each operating at a distinct level, whose articulation is left to the designer’s charge. RAISE does not add a layer; it provides the grid that makes this articulation thinkable. The difference between a superposition and a grid is not a difference in quantity of information; it is a difference in structure. An architect who has the five existing frameworks but not a grammar that organises their dependencies is in the situation of a physician who has five biological tests but no differential diagnostic framework.
Second step. The question of the legitimacy of a framework produced by a single actor is not a question closed by appeal to collective authority. It is a question opened by the defensibility of the framework. A legitimate framework is a framework that states its own limits, treats its own objections, and accepts to be falsified by counter-examples. The present document is constructed according to this discipline. §10 states five authentic limits, §6 exposes eight anti-patterns that are as many tests of the framework’s relevance, and the matrix of §5 is falsifiable by demonstration that one of its edges is null. Doctrinal legitimacy is of this nature: it is constructed through public acceptance of critique, not through silent adoption by a standardisation body.
The central binary distinction that structures the entire document is the following: governing a system versus designing a governable system. The existing frameworks govern a system: they manage its risk, certify its management, state its obligations, measure its organisational maturity, qualify its sectoral versions. RAISE designs the governable system. This distinction is not a terminological refinement. It decides the order of operations. A system designed without a grammar of governability does not become governable by addition of governance. It becomes governable, or it does not, at design.
The formula that condenses this argument is the following:
A framework that does not change design only changes documentation.
This formula, to which the document will return in §6 and in the closing, is the touchstone of the test that any RAISE-aligned deployment will have to pass. If the implementation of the framework has altered no design decision and only increased documentary volume, the effort has failed, regardless of the quality of the documentation produced.
The most immediate academic objection to RAISE is the redundancy or incompleteness argument: why exactly five pillars, why cyclic rather than oriented dependencies, why a ternary typology of edges rather than binary or quaternary. This section answers the three questions through a minimality argument, presented as defensible rather than demonstrative.
Why five pillars, neither four nor six. The informal minimality test consists in suppressing each of the pillars and observing the resulting gap. Without R, the system is deprived of normative anchoring, and governance becomes a voluntary act without opposable force. Without A, automation carries decisions for which no nominally identified person answers, a configuration unacceptable in the legal as well as in the operational sense. Without I, data flows traverse the system without contract, and traceability becomes indistinguishable from event trace. Without S, the declared performance has no test that qualifies it as reliable under deployment conditions. Without E, automated decisions are opaque by default, and opacity cannot be contested by their recipients. None of the other four pillars fills the gap thus produced, because the gaps are of different natures (norm, responsibility, contractualisation, validation, justification). Minimality from below is therefore defensible.
For minimality from above, two candidates for a sixth pillar were examined. The first is cyber-security in the sense of the NIS2, IEC 62443, and ISO 27001 frameworks; the analysis of §10.3 concludes that this is an orthogonal framework, to be articulated with RAISE rather than integrated as a supplementary pillar, because its function is protection against an intentional external threat, whereas the five RAISE pillars treat the internal governability of automated decisions. The second is economic performance in the sense of marginal cost, delay, and scalability; the analysis of §10.6 concludes that this is a dimension of industrial arbitration and not a nature of governability. Neither candidate simultaneously satisfies the criterion of non-reducibility to the five pillars and the criterion of governability orientation.
Why cyclic and not oriented. A representation by directed acyclic graph (DAG) would suppose that one pillar causally precedes the others, without return. This hypothesis is observable as false on at least two examples. First, the practice of explainability (E) progressively modifies the reading of the normative corpus (R) as the grey zones of legislative writing are revealed by use; this loop E to R is documented in recent European jurisprudence on automated decisions. Second, contractualised interoperability (I) and operational validation (S) co-determine the admissibility of incoming sources: without I, S lacks qualified material; without S, I lacks qualification criterion. A DAG does not capture this co-determination; it reduces it to a chain. Cyclicity is not a graphic elegance; it is the consequence of the plurality of qualification conditions.
Why a ternary typology of edges. A binary typology (strong / weak, or cause / effect) would crush the distinction between validity (the system satisfies the criteria that qualify it) and legitimacy (the system is opposable to a qualified third party). In regulated environments, these two moments are distinct: a system may be technically valid without being legally opposable, and the inverse is not symmetric. A quaternary typology including economic performance would introduce a dimension that is not governability in the RAISE sense, and would blur the diagnostic function of the framework. A quinary typology or beyond would fall into scholasticism without gain for the diagnosis. The ternary typology corresponds to the three moments of possible contestation of an architectural object, neither more nor fewer.
This minimality argument is defensible, not demonstrated in the formal sense. Its refutation would require either the exhibition of a sixth pillar not absorbable by the five, or the demonstration that an acyclic representation preserves the diagnostic coverage, or the production of a binary or quaternary typology whose discriminative function is demonstrably superior. None of the three is, in the public literature consulted, available.
An epistemic precision on the nature of the five pillars is necessary to anticipate the reducibility objection. The five dimensions are not presented as ontologically irreducible. A strict analysis reveals partial overlaps: A (responsibility) is partially derivable from R (applicable legal obligations) in regulated environments; E (explainability) is often a function of S (contextual validation constraints) and R (legal explanation requirements); I (interoperability) is frequently subordinated to S (contractualised quality of incoming sources). This partial reducibility is observable and must be named rather than evaded. A theoretical reduction to three axes (normative constraint, allocation of responsibility, epistemic validity) remains logically possible.
The five pillars are therefore defended as distinct operational frames of analysis, not as ontologically orthogonal dimensions. Their value is diagnostic and architectural, not logical. The confusion between A and R, between E and S, or between I and S, is precisely the typical pathology of failing deployments: it is the effect of informal reducibility assumed as fusion. Maintaining five distinct pillars is an operational decision whose aim is to preserve the diagnostic power of the framework. A reduction to three axes would simplify the formalisation at the price of operational legibility, and would reproduce the confusion that the five pillars are precisely meant to diagnose. This defence in terms of operational lenses, rather than orthogonal dimensions, is the formulation claimed.
The five pillars of RAISE are not a list of desirable attributes. They are the five architectural dimensions without which an AI system in a regulated environment is not governable in the strict sense. Each is exposed here according to an identical template: operational definition, founding question, architectural objects concerned, criteria of presence and absence, confusions to avoid, references to the Twingital doctrinal corpus. Each fiche closes with a frame stating the binary distinction that the pillar makes operational. This distinction is the touchstone that allows, on a concrete case, the decision whether the pillar is satisfied or not.
A precision on the reading of the five pillars is required before beginning. The tabular presentation might suggest complete symmetry between the five dimensions; the observed practice of deployments shows a de facto asymmetry. R (corpus reading) and A (named accountability) tend to structure design with priority; I, S, and E largely instantiate as derivations of the first two, at least at deployment initiation. This asymmetry is not a flaw of the framework; it is an observable empirical regularity that must be named. The matrix of Chapter 5, which establishes cyclic dependencies between the five pillars, does not invalidate this asymmetry; it complicates it by introducing the return loops that prevent R and A from being instructed without consideration of the three others. The de facto hierarchy therefore exists at deployment initiation; it does not persist structurally at maturity regime.
Operational definition. Capacity of the system to integrate the requirements of the applicable normative corpus as definitional constraints, upstream of functional specification, rather than as downstream validation tests.
Founding question. What rules apply to this system, and how does their reading condition the grammar of its design?
Architectural objects concerned. Regulatory classification model of the system (by AI Act risk class, by MD class, by financial service category); register of applicable requirements with versioning; mapping requirements to components; normative watch process; architecture review protocol triggered by corpus evolution.
Criteria of presence. The system is designed in reference to an identified, dated, up-to-date normative corpus. Each component is qualified as to the requirements it supports. A corpus modification triggers an architecture review, not merely a documentary update.
Criteria of absence. Compliance is documented after the fact. The normative corpus is frozen at go-live. The modification of a requirement is treated as an operational change without design review. Risk classification is affixed rather than derived.
Confusions to avoid. Confusing point compliance (passing an audit) with structural conformability (being designed to remain compliant with evolutions). Confusing declarative reading (the text says X, I note X in a register) with active reading (the text says X, I derive what X constrains for design, distinguishing what is settled from what is left to the designer’s arbitration).
Doctrinal references. [Twingital reference, Ontological collision MDR/AI Act, to be formalised]. [Twingital reference, Learning what cannot vary, to be formalised].
Pillar R is most frequently reduced to a documentary function. This reduction is the error from which everything else follows. A normative text never simply states an obligation; it defines the space in which design choices are possible, and qualifies certain combinations as unacceptable. Active reading of the corpus consists in deriving, requirement by requirement, the set of constraints that bear on the designer’s degrees of freedom. Declarative reading merely notes that the obligation exists. The first produces an architecture; the second produces a folder.
What R cuts: active reading versus declarative reading of texts.
Operational definition. Capacity of the system to carry, at each point of automated or semi-automated decision, a named, opposable accountability chain, capable of altering the design decision before it is frozen.
Founding question. For each decision the system makes or supports, who is accountable, on what ground, and with what capacity of intervention?
Architectural objects concerned. Cartography of automated and semi-automated decisions; RACI matrix extended to design objects (model, data, thresholds, interfaces); documented escalation chain; human oversight mechanisms endowed with effective powers; register of arbitrations with traceability of arbiters.
Criteria of presence. For each automated decision, a named person is identifiable, reachable, and willing to carry the decision in case of incident. Human oversight, when planned, has the information, time, and authority to effectively alter the automated decision. Technical arbitrations are traced with their authors.
Criteria of absence. Responsibility is diffuse, distributed across committees, or carried by an abstract function. Human oversight is documented but practically impossible to exercise under real operational conditions (cadence too high, insufficient information, no authority). Technical arbitrations are traced without their authors.
Confusions to avoid. Confusing legal liability (who answers in case of damage) with operational design accountability (who decides on architectural objects). Confusing effective human oversight with fictive human oversight (the human is in the loop in the sense that their name appears in the diagram, but they have neither the time, nor the information, nor the authority to alter the decision).
Doctrinal references. [Twingital reference, Hexagonal architecture as a condition of governability, to be formalised].
Pillar A is where theatre is easiest. An AI committee, an internal regulation, a RACI matrix, a human oversight device may all be present without any operational decision being alterable. The distinction between named and diffuse accountability cuts through this ambiguity. A named accountability has a name, a mandate, powers, and accepts to be engaged. A diffuse accountability has an organisation, a charter, procedures, and is engaged by no one in particular.
What A cuts: named accountability versus diffuse accountability.
Operational definition. Capacity of the system to expose, ingest, and circulate data and signals according to explicit, versioned, opposable contracts, rather than according to tacit conventions or ad hoc export formats.
Founding question. How are the flows of data and signals traversing the system contractualised vis-à-vis their producer, their consumer, and the regulator?
Architectural objects concerned. Applicable interoperability standards (FHIR R5, ESEF, XBRL, STANAG, IEC 62443); contractualised admission ports and promotion gates; versioned data schemas; incoming source qualification mechanisms; filtering and transformation policies; interface contract register.
Criteria of presence. Every interface of the system is governed by an explicit contract that specifies schema, semantics, quality guarantees, and rupture conditions. Schema changes are versioned and negotiated. Incoming sources are qualified before ingestion.
Criteria of absence. Interoperability is obtained by export in generic formats (CSV, untyped JSON, PDF) without semantic contract. Schema changes are propagated without versioning or negotiation. Incoming sources are ingested without qualification, on the pretext that the downstream pipeline will redress them.
Confusions to avoid. Confusing contractualised interoperability (format and semantics are guaranteed by an opposable standard) with by-export interoperability (data can be transmitted, the recipient bearing the burden of interpretation). The first is an architectural object; the second is a technical observation.
Doctrinal references. [Twingital reference, Contractualised promotion port, to be formalised].
Pillar I is underestimated because it appears trivially resolved: any system can, at a pinch, export its data. But interoperability in the architectural sense is not the capacity to transmit; it is the capacity to transmit under opposable conditions. A system that exports in CSV is interoperable in the sense that its data exits; it is not interoperable in the sense that the semantics of the exiting data remains the burden of whoever receives it. The difference is not a standardisation subtlety: it decides traceability, auditability, and the regulator’s capacity to reconstruct a decision after the fact.
What I cuts: contractualised interoperability versus by-export interoperability.
Operational definition. Capacity of the system to be validated not solely on performance measured on a reference dataset, but on its reliability under real operational conditions, under the specific constraints of its deployment environment.
Founding question. On which population, under which conditions, and according to which protocol has the system been validated, and do these conditions correspond to those of its intended use?
Architectural objects concerned. Contextual validation protocols; validation cohorts distinct from training cohorts; stress testing and robustness testing protocols; operational monitoring mechanisms; drift alert thresholds; periodic revalidation processes.
Criteria of presence. Validation is conducted on a population representative of deployment conditions, with a pre-specified protocol. Operational conditions are monitored to detect drift before it alters performance. Revalidation is triggered by conditions, not solely by calendar.
Criteria of absence. Validation reduces to performance on a public benchmark or on an internal dataset without representativeness control. Operational monitoring measures availability and throughput, not performance drift. Revalidation is calendar-based, triggered by deadline rather than signal.
Confusions to avoid. Confusing benchmark performance (capacity measurement in an experimental frame) with contextual validation (reliability measurement in the usage frame). The first can be excellent without the second being so; the inverse is not symmetric. Confusing adversarial robustness (resistance to perturbations designed to fool the model) with ecological robustness (performance stability under natural variations of the deployment population).
Doctrinal references. [Twingital reference, Public benchmarks have lost the right to decide alone, to be formalised].
Pillar S is the one whose measurement is most treacherous. An AUC of 0.93 on a reference dataset is, in itself, information; but information that says nothing about the system’s reliability under its conditions of use, unless one presupposes that validation and deployment conditions coincide. This presupposition is almost always false, and treating it is the proper object of pillar S.
What S cuts: benchmark performance versus contextual validation.
Operational definition. Capacity of the system to produce, for each automated decision, an explanation that is useful to the person concerned, defensible before a qualified third party, and conceived as an architectural object rather than added a posteriori as an interpretation layer.
Founding question. For each decision the system produces, who is the recipient of the explanation, for what purpose, and according to what protocol is the explanation generated and validated?
Architectural objects concerned. Typology of explanation recipients (person concerned, professional, regulator, court); explanation models adapted to each recipient; explanation generation protocols integrated into the model’s design, not superimposed; applicable ethical frames and their invocation processes; registers of explainable decisions with timestamps.
Criteria of presence. Explainability is defined by the recipient and the usage of the explanation, not by the availability of a generic technical tool. The model’s design takes explainability requirements as upstream constraints. Divergences between produced explanation and effective decision are detectable and traced.
Criteria of absence. Explainability is assimilated to the installation of a SHAP- or LIME-type tool without qualification of the recipient or usage frame. Explanations are produced downstream of the decision, with no guarantee of coherence with the model’s internal process. No mechanism distinguishes a decisional explanation (which justifies the decision) from a technical interpretation (which describes how the model functions).
Confusions to avoid. Confusing decisional explainability (production of a justification the recipient can contest) with technical interpretability (production of a description of the model’s functioning). Both are useful; neither is the other. Confusing a posteriori explanation (generated after the decision, by a device distinct from the model) with design justification (integrated into the decision itself).
Doctrinal references. [Twingital reference, Bayesian and regulatory credibility, to be formalised]. [Twingital reference, Learning what cannot vary, to be formalised].
Pillar E is where confusion between object and tool is most damaging. Having a technical interpretation tool does not make the system explainable in the architectural sense; it only allows the production, for each decision, of a supplementary object whose relevance for the recipient is, at best, contingent. Explainability as architectural pillar requires that the recipient, their usage frame, and the production protocol be specified before model design, and that the design carry the trace of this.
One technical difficulty remains under this pillar, which must be named rather than evaded. Certain useful automated decisions are not stably explainable without significant performance loss. This zone, proper to complex models (deep networks, ensembles, advanced non-parametric models) operating on high-dimensional spaces, is not resolved by pillar E; it is contained. RAISE treats this tension in architecture, by requiring that the decision to prioritise performance over explainability be itself nominally carried by an accountability (pillar A), contextually validated (pillar S), and opposable to the regulator (pillar R). This is an architectural resolution, not a technical one. Its reach is conditional: pillar E is normatively strong, operationally constrained.
What E cuts: decisional explainability versus technical interpretability.
The five pillars do not add up, they engender each other. This section demonstrates this assertion by making it explicit, pair by pair. The usual presentation structure, which aligns R, A, I, S, E along a linear chain (“first text reading, then governance, then interoperability…”), is convenient for exposition but false for analysis. None of the pillars causally precedes the others; each conditions, in a different manner, the four others; each is conditioned, in a different manner, by the four others.
The graphical representation of this section, in the final layout, is a pentagonal figure with the five pillars at the vertices and the edges between pillars typed by the nature of the dependency. Three natures are distinguished:
Condition of possibility. X is a condition of possibility of Y if, in the absence of X, Y cannot exist as a distinct architectural object, independently of any quality consideration.
Condition of validity. X is a condition of validity of Y if, in the absence of X, what is produced as Y is nominally present but does not satisfy the criteria that qualify it as such.
Condition of legitimacy. X is a condition of legitimacy of Y if, in the absence of X, Y exists and functions, but cannot be opposed to a qualified third party (regulator, court, person concerned) as a reference object.
Why three natures and not five or two? Because these three natures correspond to the three moments at which an architectural object can be contested: its existence, its quality, its opposability. A two-nature typology crushes the distinction between quality and opposability, which are distinct in regulated environments: a system may be technically valid without being legally opposable, and the inverse is not symmetric. A typology of five or more introduces sub-categories that do not hold in usage. The ternary typology is minimal and sufficient. This is, one concedes, a doctrinal decision that could be discussed. The discussion then bears on edge cases, not on the relevance of the typology itself.
| R | A | I | S | E | |
|---|---|---|---|---|---|
| R | identity | conditions | informs | delimits | legitimates |
| A | requires | identity | mobilises | frames | imposes |
| I | makes legible | conditions | identity | makes possible | makes traceable |
| S | presupposes | makes testable | presupposes | identity | makes defensible |
| E | reformulates | makes auditable | requires | makes justifiable | identity |
The table is read by row: R conditions A, R informs I, R delimits S, R legitimates E; and symmetrically by column for the returns. The ten non-identity pairs are developed below, each in a qualifying sentence that makes explicit the dual dependency in both senses.
R conditions A in that the active reading of the normative corpus determines which decisions must be nominatively carried, by whom, and under what accountability regime; without this reading, the responsibility matrix is built on intuitions rather than on derived obligations. Symmetrically, A requires R in that a named accountability chain is operationally opposable only if it has been instructed by a reading of the applicable normative corpus; a named accountable person without reference corpus is named to carry a decision whose legal contours are undetermined, which is precisely what nomination was supposed to avoid. The R-to-A dependency is of the condition of possibility nature (without active reading, the accountability chain has no object); the A-to-R dependency is of the condition of validity nature (without named accountability, active reading remains an intellectual exercise without opposable force). Diagnostic test. Can the nominal list of decisions that must carry an accountability be derived from the requirements of the applicable normative corpus? If not, R on A is compromised.
R informs I in that the applicable normative corpus specifies, explicitly or implicitly, the interoperability standards the system must respect (FHIR for health under the European directive on the European Health Data Space, ESEF for financial reporting under the Transparency Directive, STANAG for NATO systems). Symmetrically, I makes R legible in that the interface contracts effectively implemented in the system constitute the observable trace of the corpus reading, by which a third party can verify that a required standard is effectively integrated and not merely mentioned. The R-to-I dependency is of the condition of validity nature (the standard required by the corpus is what qualifies interoperability as compliant); the I-to-R dependency is of the condition of legitimacy nature (the observable implementation of the standard is what makes compliance opposable). Diagnostic test. Are the interoperability standards required by the corpus effectively implemented and observable in the system’s interface contracts? If not, R on I is compromised.
R delimits S in that the normative corpus specifies the perimeter within which operational validation is conducted (eligible population, conditions of use, post-market surveillance modalities for medical devices, stress testing conditions for financial risk models under Basel III). Symmetrically, S presupposes R in that no contextual validation protocol can be conceived without a normative frame that qualifies what counts as representative and what constitutes a valid sample. The R-to-S dependency is of the condition of validity nature (the normative frame qualifies validation as acceptable); the S-to-R dependency is of the condition of possibility nature (without a frame, validation lacks an object). Diagnostic test. Is the validation protocol instructed by the applicable normative corpus, with qualification of cohort representativeness in the sense of that corpus? If not, R on S is compromised.
R legitimates E in that the normative corpus specifies who is recipient of an explanation (Article 86 AI Act for the person concerned by a high-risk decision, Article 22 GDPR for the individual automated decision, Article 17 MDR for the health professional), at what granularity, and according to what protocol. Symmetrically, E reformulates R in that the explainability practice produced by the system, by circulating to its effective recipients, forces a re-reading of the corpus to specify what was left undetermined in the initial writing. The R-to-E dependency is of the condition of legitimacy nature (the corpus makes the explanation opposable); the E-to-R dependency is a return loop that progressively modifies the corpus interpretation as explanation practices reveal the grey zones of legislative writing. Diagnostic test. Are the explanation recipients qualified by the applicable normative corpus, and does the explanation protocol respect their usage frame? If not, R on E is compromised.
A mobilises I in that the accountability chain can only be exercised if the flows of data and signals supporting decisions are contractualised and traced; a named accountable person who does not have a reliable trace of the data supporting the decision is not in a position to carry that decision. Symmetrically, I conditions A in that the interface contracts define the switch points where a decision is taken, and therefore the points where an accountability must be named. The A-to-I dependency is of the condition of validity nature (without I, accountability nominations are nominal); the I-to-A dependency is of the condition of possibility nature (without I, accountability points are undetermined). Diagnostic test. Are the flows supporting decisions traced at the level that allows reconstruction by the named accountable person? If not, A on I is compromised.
A frames S in that the named accountability carries the decision to qualify a validation as sufficient or insufficient; without nomination, the validation decision is diffuse, and its contestable character is, in practice, neutralised. Symmetrically, S makes A testable in that the operational validation criteria constitute the trials to which the accountability chain accepts to be submitted; a named accountable person who refuses validation trials is not an accountable person in the architectural sense. The A-to-S dependency is of the condition of legitimacy nature (without nomination, validation engages no one); the S-to-A dependency is of the condition of validity nature (without S, accountability nomination is ceremonial). Diagnostic test. Does the accountability chain accept validation trials as opposable tests, and are the named accountable persons engaged on these trials? If not, A on S is compromised.
A imposes E in that named accountability calls for explainability as a condition of exercise: an accountable person who cannot produce the explanation of a decision is not in a position to defend it. Symmetrically, E makes A auditable in that the explainability practice, when it exists in the architectural sense, provides the trace by which a qualified third party can reconstruct the exercise of accountability and assess its relevance. The A-to-E dependency is of the condition of validity nature (non-explainable accountability is not exercisable); the E-to-A dependency is of the condition of legitimacy nature (without explainability, accountability is not opposable). Diagnostic test. Can each named accountable person produce the explanation of a decision they engage on, and is that explanation defensible before a qualified third party? If not, A on E is compromised.
I makes S possible in that contextual validation protocols require qualified, contractualised, traceable data flows, without which the operational performance measurement is not interpretable. Symmetrically, S presupposes I in that no drift measurement can be conducted on unqualified incoming sources; the measurement then fails to distinguish system drift from input drift. The I-to-S dependency is of the condition of possibility nature (validation without interface contracts has no material); the S-to-I dependency is of the condition of validity nature (interface contracts without validation do not guarantee operational reliability). Diagnostic test. Are incoming sources qualified to the point of allowing drift measurement without confusion between system drift and input drift? If not, I on S is compromised.
I makes E traceable in that the production of a decisional explanation requires, to be defensible, access to the signals and data that supported the decision, and therefore to contractualised flows. Symmetrically, E requires I in that the specification of explainability protocols constrains the specification of interface contracts: decisional explainability requires certain information in the format where it can be mobilised, which retroacts on the system’s admission and promotion contracts. The I-to-E dependency is of the condition of possibility nature (without I, the explanation cannot be instructed); the E-to-I dependency is of the condition of validity nature (without E, interface contracts are not calibrated on the right informational usage). Diagnostic test. Do the contractualised flows carry the information necessary for decisional explainability in the format mobilisable by the qualified recipient? If not, I on E is compromised.
S makes E defensible in that operational validation provides the empirical base on which decisional explanation can rely to be held credible; an explanation not backed by contextual validation is a rationalisation. Symmetrically, E makes S justifiable in that the explainability practice makes explicit what operational validation measured and what it did not measure, and thus allows the system’s reliability perimeter to be instructed rather than presupposed. The S-to-E dependency is of the condition of validity nature (without validation, the explanation is unfounded); the E-to-S dependency is of the condition of legitimacy nature (without explainability, validation is not opposable beyond the technical expert). Diagnostic test. Are the explanations produced backed by contextual validation, and is the validation translated into terms usable by non-expert recipients? If not, S on E is compromised.
The 5×5 matrix presents three objections that quick reading might formulate. They are anticipated here, without repetition.
Plausibility, not demonstration. The matrix is a plausible model, not a constrained model. Three academic questions remain open: why five pillars and not four or six, why these dependencies and not others, why this ternary typology and not binary or quaternary. The full answer to these questions is the object of §3.8 (minimality argument) and §5.5 (partial demonstration of edge necessity). The matrix states a defensible doctrinal regularity, falsifiable by architectural counter-example, not a formal demonstration in the mathematical sense.
Intensity asymmetry. The matrix does not claim that all pairs have the same intensity. Some dependencies are structurally determining (R on the set of others, A on S and E); others are operationally weaker (I on E outside the audit context). The statement that all edges are non-null does not imply that they are equivalent. The observed asymmetry is instructed in §4 (note on the de facto asymmetry of pillars at deployment initiation).
Explicit exclusion of the economic dimension. The ternary typology (possibility, validity, legitimacy) deliberately excludes the dimension of operational efficiency, cost, scalability. This exclusion is methodological: economic performance structures industrial arbitration but does not qualify governability in the sense the matrix instructs. It is treated separately in §10.6 and §10.7. This separation is coherent with the framework’s delimitation §2 as architecture, and recognised as strategically exposed to the COMEX critique, which will spontaneously reintroduce it in any portfolio arbitration.
The matrix is therefore not a formal demonstration; it is an analytical frame that makes visible, on any concrete case, the zones where design is under-constrained or over-constrained. Its value is not measured by its logical rigour but by its diagnostic utility.
The assertion that all edges of the matrix are non-null is strong. It will not be demonstrated en bloc, because a formal demonstration would require a logical frame that this section does not mobilise. Three critical edges are nevertheless defended here by collapse argument: one supposes the edge null, one derives the consequence, and one observes the contradiction or loss of function.
Edge R conditions A. Suppose that R does not condition A. Then the accountability chain can be conceived independently of the active reading of the applicable normative corpus. Consequence: a named accountable person carries a decision whose legal contours are undetermined, because the nomination was not instructed by effectively applicable obligations. This configuration is precisely that of anti-pattern §6.2.3 declarative governance. Nomination exists, but without opposable force. Pillar A is nominally satisfied, operationally empty. The edge R conditions A is therefore necessary for the non-vacuity of pillar A.
Edge A frames S. Suppose that A does not frame S. Then the contextual validation protocol can be conceived and conducted without a named accountability carrying the decision to qualify the validation as sufficient. Consequence: the validation criteria are diffuse, contestable but not contestable by anyone in particular. Validation becomes ceremonial, satisfies standard audit, and engages no one. This configuration is anti-pattern §6.2.6 audit as ceremony projected onto pillar S. Without A to S, validation has no carrier; without carrier, it has no force. The edge A frames S is therefore necessary for the non-vacuity of pillar S.
Edge E reformulates R. Suppose that E does not reformulate R. Then the explainability practice, once in production, has no return on the normative corpus reading. The initial corpus reading is frozen at design. Consequence: the normative corpus evolves (publications of delegated acts, AI Office decisions, administrative jurisprudence), but the architecture does not absorb this evolution. The system enters normative drift unawares, until the moment when a supervisory authority requalifies an obligation and produces the level regression in the sense of §7.3. The edge E reformulates R is therefore necessary for the temporal stability of R alignment.
Three edges of the ten pairs are thus defended. The other seven accept an argument of the same nature, omitted here by discipline of length. Partial defensibility does not suffice to constitute a formal demonstration; it suffices to constitute a claim of robust plausibility, which would require for refutation a comparable non-collapse argument.
The plausibility argument takes a more concrete form when instantiated on compared cases. Two counterfactuals are proposed below, each confronting a non-RAISE-aligned system A and a RAISE-aligned system B, under an identical perturbation. The claim of RAISE is that the behavioural difference under perturbation is attributable to a specific architectural characteristic, identifiable in the pillars and in the matrix.
Counterfactual 1. Clinical decision support system in oncology under evolution of Article 86 AI Act jurisprudence.
System A is designed by optimising predictive performance on a retrospective cohort; AI Act compliance is instructed a posteriori by documentation; explainability is added by SHAP installation; MDR clinical evaluation is conducted on the benchmark cohort. System B is designed under cross-reading AI Act × MDR (pillar R), with explanation recipient qualified from design (pillar E, contractualised on three levels: patient, oncologist, supervisory authority), with prospective validation on a qualified territorial cohort (pillar S), with named accountability at the level of the manufacturer and the head of service (pillar A), and with FHIR R5 interface contracts versioned on data sources (pillar I).
Perturbation: a decision of the Court of Justice of the European Union specifies, by jurisprudence, that the explanation required by Article 86 must include a reasoning trace comprehensible by the clinician, and not merely a per-feature weight attribution.
Behaviour of System A: the SHAP installation does not satisfy the new requirement; the system must rebuild its explanation layer, which entails a new clinical evaluation and re-marking. Contractual exposure vis-à-vis the notified body and practitioner users is significant during the transition. Behaviour of System B: the recipient qualification and the differentiated production chain are already in place; the new requirement is instructed by the E-to-R loop, which requalifies the expected output for the oncologist as qualified recipient, without structural redesign. The §7.3 level regression is exercised but remains contained.
The delta is attributable to pillar E (ex ante qualification of the recipient) and to the edge E reformulates R (jurisprudence absorption loop). Without these two elements, system A undergoes the perturbation as redesign; system B treats it as requalification.
Counterfactual 2. Individual credit scoring model under regulatory requirement for real-time drift detection.
System A is designed on commercial secrecy, with degraded explanation provided to the applicant on the basis of Article 22 GDPR; the model is protected against any de-anonymisation. System B is designed on the Competitive opacity tension named in §8.2: explainability differentiated by recipient (regulator, applicant, court), with controlled de-anonymisation chains by procedure (pillar E + I), contextual validation by stress testing cohort distinct from training (pillar S), named accountability at CRO and effective management (pillar A).
Perturbation: the supervisory authority (EBA or national authority) requires the implementation of a real-time drift detection mechanism for the automated decision by applicant category, under DORA and Article 22 recital 71 GDPR.
Behaviour of System A: the request cannot be satisfied without exposing the model’s logic, which is precisely what commercial secrecy protects. The system is in architectural dead end; the compromise observed in practice is the production of an internal non-communicable dashboard, which satisfies the letter of the requirement without satisfying its spirit, and which exposes the institution to subsequent contestation. Behaviour of System B: the explainability chain differentiated by recipient is designed to integrate the regulator as qualified recipient with access to drift without access to the internal logic; the requested mechanism is instructed by interface contractualisation (pillar I) on the regulator channel, without model modification or competitive exposure.
The delta is attributable to the combination E (recipient differentiation) and I (interface contracts differentiated by channel), with return on A (the CRO accountability carries the de-anonymisation procedure). Without this combination, institution A undergoes the perturbation as architectural contradiction; institution B treats it as mobilisation of a pre-existing chain.
These two counterfactuals are doctrinal constructions, not public empirical observations. Their function is to illustrate the RAISE claim as architectural framework producing an asymmetry of behaviour under perturbation, attributable to identifiable characteristics. Their refutation would require the exhibition of a real case where a non-RAISE-aligned system absorbs an equivalent perturbation without architectural cost, or a case where a RAISE-aligned system undergoes a perturbation as redesign rather than as requalification.
The anti-patterns are the typed pathologies of RAISE deployment. They are named by their operational signature, identifiable by a diagnostic sign, that is, by the sentence heard in a meeting that reveals their presence. This section starts with the eight diagnostic signs grouped together; it then develops, for each, the description and the compromised pillars.
- “We’ll make it compliant at go-live.”
- “We added SHAP, we’re explainable.”
- “We have an AI committee.”
- “We can always export to CSV.”
- “The service contract covers that.”
- “The audit passed last year.”
- “AUC is 0.93 on the reference dataset.”
- “There’s always a human in the loop.”
If one of these sentences has been pronounced in an architecture meeting without raising a precise technical objection, the corresponding anti-pattern is probably present in the concerned deployment. Each is a linguistically irreproachable answer to a governance question, and this is precisely what makes them dangerous: they discharge the interlocutor from pursuing the question.
Compliance is treated as a layer added at the end of the cycle, after the architecture has been frozen. Compliance devices (logs, dashboards, explainability devices) are serious taken in isolation, but the aggregate does not correct the architectural property that makes the system not governable. Compromised pillar: R principally, by return A and E. Minimal architectural correction. Take back the functional specification of at least one requirement of the normative corpus as a definitional constraint, not as a validation test, and trace the derivation chain down to the concerned components.
The installation of a technical interpretation tool (SHAP, LIME, attention maps) is treated as the satisfaction of pillar E, without qualification of the explanation recipient, of the usage frame, or of the production protocol. The tool is present, explainability in the architectural sense is absent. Compromised pillar: E, by return A. Minimal architectural correction. Qualify the recipient of the explanation, their usage frame, and the production protocol, before installing any interpretation tool, and derive the tool choice from this qualification, not the inverse.
An AI committee, a charter, a RACI matrix are produced, archived, and presented as the satisfaction of pillar A. None of these objects has the power to alter a design decision. Accountability is diffuse at the moment when it should be named. Compromised pillar: A, by return R. Minimal architectural correction. Identify at least one design decision that can be blocked by a governance instance, and materialise this blocking power by a traced, opposable procedure, exercised at least once.
The system is presented as interoperable because it can produce exports in generic formats. The semantics of exported data are left to the consumer, without opposable contract. Compromised pillar: I, by return A and S. Minimal architectural correction. Establish an explicit interface contract with an identified consumer, comprising versioned schema, opposable semantics, quality guarantees, and rupture clauses, on at least one of the system’s critical flows.
Operational validation is outsourced to the provider or model vendor, on the basis of a contractual clause that transfers risk. The contract covers legal risk, not operational reliability; the confusion between the two is the anti-pattern. Compromised pillar: S, by return A. Minimal architectural correction. Define, within the organisation, the contextual validation protocol that would qualify the provider’s service as compliant before the contractual engagement, and keep this protocol as specification requirement.
The audit is conducted by the rules of the art, its deliverables are produced on schedule, it is mentioned in annual reports. None of its observations is capable of altering the operational decision, because it intervenes downstream of the moment when the decision is taken. Compromised pillar: A, by return R, S, E. Minimal architectural correction. Give the audit an intervention point upstream of at least one design decision, with explicit and traced stop capacity, rather than an exclusively post-deployment intervention.
The system’s performance is measured on a public dataset, classical for the domain, and this measurement is held as sufficient to qualify operational validation. The representativeness of the benchmark cohort vis-à-vis the deployment population is not examined. Compromised pillar: S, by return E and R. Minimal architectural correction. Build a validation cohort distinct from training cohorts and public benchmark, qualified as representative of deployment conditions, with documented and opposable representativeness criteria.
A human is positioned in the decision diagram, in conformity with regulatory requirements, but without having the time, information, or authority necessary to effectively alter the automated decision. Oversight is nominally present, operationally absent. Compromised pillar: A, by return S and E. Minimal architectural correction. Measure the time, information, and authority effectively available to the operator under real operational conditions, publish the measurement, and resize either the system or the human’s position, until oversight is exercisable.
The binary distinction that structures these eight configurations is the following: presence of a device versus effective capacity of the device to alter the decision. None of the anti-patterns above proceeds from an absence; all proceed from a presence without capacity. To diagnose an anti-pattern is to distinguish between an object that exists and an object that decides. The diagnosis is rapid; its correction is not, because it requires returning to the design decision that produced the capacity-less object.
A governance device is measured by what it prevents, not by what it documents.
The framework, mobilised in CTO posture, is not measured only by what it allows to be produced; it is measured by what it allows to be refused without losing the lead. Five archetypal refusals emerge from the application of the five pillars and their matrix. These refusals are not engineer’s objections; they are architect’s decisions, which engage the industrial trajectory and the CTO’s accountability.
Refusal of go-live without named accountability. No production deployment of an AI system in a regulated environment can be validated as long as the accountability chain has not been nominally established on each significant automated decision. Pillar A gives the CTO the language of this refusal.
Refusal of benchmark as validation. No performance measured on a reference dataset stands as contextual validation in the sense of pillar S. The CTO can refuse a validation file that limits itself to benchmark performance, without having to argue case by case.
Refusal of CSV export as interoperability. No capacity to export in generic formats stands as interface contract. Pillar I authorises the CTO to require explicit contractualisation before admitting a flow into the system or engaging a consumer.
Refusal of nominal human oversight. No presence of a human in the decision diagram stands as oversight if the operator does not have the time, information, and authority to alter the decision. Pillar A and the 5×5 matrix instruct this refusal with a precision that makes the position defensible against operational cadence requirements.
Refusal of audit without altering power. No audit whose observations cannot alter the operational decision stands as governance. Pillar A, read under the critique of the audit-as-ceremony anti-pattern, gives the CTO the grammar of this refusal.
These five refusals are the most direct translation of the central formula of the document. A framework that does not change design only changes documentation; a CTO who does not refuse the configurations above changes design no more.
The eight anti-patterns of §6.2 isolate configurations where the diagnosis is rapid because the failure is complete and caricatural. The advanced practice of deployments shows a supplementary category, structurally more dangerous because it escapes immediate diagnosis: maturity false positives. A maturity false positive is a deployment where each of the five pillars is partially satisfied, where no caricatural anti-pattern is observable, and where the system fails nonetheless under edge case or combined stress.
The operational signature of a maturity false positive is typically the following. Point compliance is demonstrable on standard audit; accountability is named on the nominal perimeter; interoperability is contractualised on principal flows; validation is conducted on the expected cohort; explainability is produced for the planned recipient. All pillars pass the test taken in isolation. The combined test, however, fails: an edge case reveals that none of the pillars has been instructed at the depth that resists the combination of several simultaneous deviations.
The diagnosis of a maturity false positive therefore requires a type of evaluation distinct from the eight anti-patterns. Four integration tests can be mobilised.
Propagation test. Does a perturbation injected in one pillar (for example a regulatory evolution R) effectively alter the other pillars, or does it remain confined to documentation? A governable deployment propagates the perturbation down to design decisions; a false positive absorbs it through documentary update.
Combined edge case test. Is an operational case combining out-of-distribution data, ambiguous accountability, and contested explanation treated by the architecture, or does it produce an undetermined fallback? A governable deployment traces a defensible decision; a false positive produces a decision for which none of the pillars can be held responsible.
Forensic audit test. Can an independent auditor reconstruct the full decision chain of an individual case from the sole traces preserved by the system, without additional information provided by the organisation? A governable deployment supports this reconstruction; a false positive requires oral complements that cannot be audited.
Marginal cost test. Does the extension of the governance perimeter to a new use case produce a marginal cost increase proportional to the complexity added, or exponential because the initial architecture did not support the extension? A governable deployment absorbs the extension at proportional cost; a false positive reveals its under-instructed architecture by cost explosion.
An organisation that passes the eight anti-patterns of §6.2 but fails one of the four tests above is in maturity false positive. This is, statistically, the most frequent configuration in declared RAISE-aligned deployments. To detect it is the proper use of the framework beyond basic diagnosis.
A system that passes standard audit but fails the combined edge case is in maturity false positive.
The eight anti-patterns of §6.2 are first-order failures: a pillar is missed, the diagnosis is rapid. The maturity false positives of §6.5 are second-order failures: all pillars are locally satisfied, but composition fails. This section formalises composition failure patterns as reusable diagnostic operators.
Anti-pattern P-O-1. Local optimality, global incoherence. Each pillar is optimised for its own indicator, without transverse coherence constraint. Pillar R integrates all applicable texts; pillar A names all responsibilities; pillar I contractualises all interfaces; pillar S validates all cohorts; pillar E qualifies all recipients. No mechanism verifies that R reading, A chain, I contracts, S cohorts, and E recipients are mutually consistent. Diagnostic sign: “every pillar dashboard is green, but none has the cross-pillar view.” Diagnostic operator: inject into R reading a requirement derived from a text; observe whether the A chain, I contracts, and S cohorts respond. Quantifiable proxies: number of divergences detected by quarterly transverse audit; ratio of coherent pillar KPIs over all pillar KPIs (target above 0.95). Critical threshold: below 0.80 counts as positive diagnosis.
Anti-pattern P-O-2. Coverage without propagation. Each pillar covers its expected perimeter. A perturbation injected in one pillar does not propagate to the others: it is confined to the documentation of the perturbed pillar. A publication of an AI Act delegated act updates the R register but triggers no architecture review in A, I, S, or E. Diagnostic sign: “the update is noted, the architecture is unchanged.” Diagnostic operator: trace, over the last twelve months, the number of R modifications that produced an observable modification in at least one other pillar. Quantifiable proxies: average time-to-propagation between publication of a normative requirement and observable modification of at least one architectural component (target below 90 days for immediate-effect requirements); number of components impacted per R perturbation (target greater than or equal to one per effective perturbation); percentage of operational decisions requalified in the quarter following a major R perturbation. Critical threshold: time-to-propagation above 180 days, or zero components impacted, counts as positive diagnosis.
Anti-pattern P-O-3. Indeterminate composite fallback. Each pillar treats its nominal case. A combination of simultaneous edge cases (out-of-distribution data, ambiguous accountability, contested explanation) produces a fallback for which no pillar is responsible. The system handles each case taken in isolation, but has no defined behaviour for the combination. Diagnostic sign: “we’ve never had this exact case.” Diagnostic operator: inject, in a controlled test environment, a combination of three simultaneous deviations chosen in different pillars; observe the decision produced and its tracing. Quantifiable proxies: ratio (combined cases producing a traced decision defensible by named accountable person) over (combined cases tested), with target above 0.90; time of composite decision reconstruction by an external auditor. Critical threshold: below 0.70, or production of untraceable fallback, counts as positive diagnosis.
Anti-pattern P-O-4. Audit asymmetry. Each pillar passes its individual audit. No auditor has the cross-pillar view that would allow diagnosis of composition failure. Pillar R is audited by the legal department; pillar A by internal control; pillar I by IT; pillar S by data scientists; pillar E by the DPO. None reads the reports of the other four. Diagnostic sign: “all audits are favourable and the system fails anyway.” Diagnostic operator: commission a transversal audit whose explicit mandate is the coherence of the five pillars, conducted by an auditor independent of the five sectoral audits. Quantifiable proxies: number of composite transversal audits conducted per year (target greater than or equal to one per annual cycle); percentage of transversal observations that triggered an architecture review (target above 0.50). Critical threshold: zero annual composite audit, or zero review triggered, counts as positive diagnosis.
These four patterns share a common characteristic: their diagnosis is more costly than that of the eight first-order patterns, because it requires a cross-pillar view that is neither produced nor required by standard audits. Their correction typically requires a revision of the composite governance points, that is, of the instances or procedures that take the five pillars as a unique evaluation object. Without this composite governance, second-order patterns are, in practice, undetectable until incident.
The present volume has exposed the doctrinal architecture of the RAISE framework. Three compression formulas condense what the five pillars, their interdependency matrix, and their anti-patterns, taken together, defend.
A framework that does not change design only changes documentation.
A governance device is measured by what it prevents, not by what it documents.
A system that passes standard audit but fails the combined edge case is in maturity false positive.
Volume 2, Operational application (internal reference TI-2026-FRMK-RAISE-v1.0-V2), prolongs this doctrinal exposition by its sectoral test, its authentic limits, its economic articulation at the criticality threshold C*, its eight canonical questions, and the final repositioning formula that closes the loop opened in the preamble. Reading Volume 2 presupposes the acquisition of Volume 1 on the five pillars, the 5×5 matrix, and the twelve anti-patterns (eight canonical from §6.2 and four second-order from §6.6).
The terms below receive their operational definition in the context of RAISE. The definitions do not substitute for legal or technical definitions otherwise established; they specify the use the framework makes of them.
Auditability. Capacity of a system to support ex post reconstruction of its decisions by a qualified third party, at a level of detail compatible with the applicable classification or confidentiality frame. To be distinguished from the availability of documentation, which is its condition but not its equivalent.
Effective human oversight. Presence in the decision chain of a human operator simultaneously having the information, time, and authority necessary to alter the automated decision. To be distinguished from fictive human oversight, which satisfies the formal requirement without satisfying it operationally.
Reversibility. Capacity of an automated decision to be annulled or revised according to a traced protocol, within a delay compatible with the nature of the potential harm. Reversibility is neither the simple availability of a technical undo function, nor a vendor’s contractual commitment; it is a property of architecture.
Decisional legitimacy. Quality of an automated decision that can be held acceptable by the recipients of its effects, under the dual regime of compliance with applicable rules and justifiability of its reasoning. Distinct from formal compliance, which can be obtained without legitimacy.
Compliance by construction. Property of a system whose functional specification has been established under the constraint of applicable normative requirements, and whose architecture bears the trace of this constraint. To be distinguished from compliance by amendment.
Ontological traceability. Capacity of the system to preserve, for each decision, the identity of the architectural objects that supported the decision, in an opposable register. Distinct from event traceability, which records actions without qualifying objects.
Admission ports. Interfaces through which data or signals enter the system, governed by explicit contracts that specify schema, semantics, and acceptance conditions. The concept is taken from the Twingital doctrinal corpus.
Contextual validation. Measurement of a system’s reliability conducted on a cohort representative of deployment conditions, according to a pre-specified protocol. To be distinguished from performance on public benchmark.
Decisional explainability. Production of a justification of an automated decision qualified by its recipient, its usage frame, and its generation protocol. To be distinguished from technical interpretability, which describes the functioning of the model without qualifying the relevance for the recipient.
Design justification. Trace, integrated into the system’s architecture, which makes explicit the chain of architectural decisions that led to the effective functional specification. To be distinguished from a posteriori explanation, which is produced after the decision and independently of it.
Named accountability. Formal and opposable commitment of a physically and nominally identified person to carry a design or operation decision. To be distinguished from diffuse accountability, carried by an organisation or abstract function.
Characteristic tension. Configuration specific to a sector in which a particular loop of the 5×5 matrix becomes structuring to the point of imposing the tone of the entire deployment. Three principal tensions are named in the present document, three more are mentioned in synthesis.
This annex synthesises, in tabular form, the principal doctrinal claims of the document, the evidence elements that support them, and the conditions under which each would be refuted. The table serves as academic backbone of the framework. It is complementary to the authentic limits of §10: those limits state what RAISE does not do; this table states what RAISE does, on what foundation, and under what conditions this claim would be abandoned.
| Claim | Evidence mobilised | Conditions of falsification |
|---|---|---|
| Five pillars cover the governability of AI in regulated environments | Minimality test §3.8, multi-sectoral observation (method), absence of a documented non-orthogonal sixth pillar | Exhibition of a sixth pillar non-reducible to the five and non-orthogonal to existing frameworks |
| All edges of the 5×5 matrix are non-null | Partial collapse demonstration §5.5 on three edges (R→A, A→S, E→R), internal coherence argument | Demonstration that one pair admits a null dependency in a real deployment, without functional equivalent |
| The cyclic representation is more expressive than a directed acyclic graph | Documented loops E→R (jurisprudence absorption) and I/S co-determination §3.8 | Acyclic architecture preserving the diagnostic coverage of the cyclic matrix |
| The ternary typology (possibility, validity, legitimacy) is minimal and sufficient | Three moments of possible contestation §5.1, comparison with binary and quaternary typologies (§3.8) | Demonstration that a binary or quaternary typology preserves the discriminative function while reducing the number of necessary categories |
| The application of RAISE effectively alters design | Refutation criterion and transformations T1 to T5, structural implication Δ(design)=0 implies Δ(governability)=0 (methodological note) | Demonstration of a deployment where the application of RAISE produced none of the five transformations T1 to T5 but nevertheless improved observable governability |
| The eight canonical anti-patterns and the four second-order patterns cover the typed pathologies of deployment | Inventory §6.2 and §6.6, multi-sectoral observation | Exhibition of a failure pattern that is neither canonical anti-pattern nor second-order pattern, and that reproduces in several independent deployments |
| Beyond the threshold C*, RAISE is economically dominant compared to the absence of an architecture framework | Criticality threshold model (Volume 2 §10.7), three asymmetric mechanisms described qualitatively | Empirical measurement of the total expected cost of a RAISE deployment and a non-RAISE deployment in the same sector, showing absence of asymmetry beyond an identifiable threshold C* |
Enter your details to access the document. Free access — no sales outreach.
Personalized document · Free access · No sales outreach