{ "registry": { "name": "The Defensible AI Framework Registry", "subtitle": "Canonical Names, Definitions and Relationships for the Governed Production AI Discipline", "version": "1.0", "published": "2026-08-30", "doi": "10.5281/zenodo.22170112", "doi_note": "Reserved on the Zenodo draft before publication and inserted by _build/insert-doi.py. A null value is a deliberate pre-publication state and fails verify-deposit.py.", "licence": "CC-BY-4.0", "author": { "name": "Khan, Nabeel", "orcid": "0009-0005-5364-914X", "affiliation": "iSystematic Inc." }, "governing_document": "defensible-ai-framework-registry-specification-v1.0.md", "precedence": "Where this file and Section 4 of the governing document disagree, Section 4 is correct and this file is defective.", "family": "governance", "engineering_family_source": "10.5281/zenodo.22109864", "not_a_certification_scheme": "It is a specification, not a certification scheme, and no conformity assessment body operates against it." }, "specification_status_vocabulary": { "deposited": "A standalone, versioned, citable specification exists and is identified by a DOI.", "source-treatment": "No standalone specification exists. The authoritative treatment is a named chapter of a published work.", "instrument-pending": "No standalone specification exists and one is committed. No identifier until it is minted." }, "relationship_type_vocabulary": { "instantiates": "The source framework occupies the named MESA altitude of the target. Asserted by the subordinate framework.", "grants-authority-to": "The source grants the authority under which the target operates. Asserted by the granting framework.", "supplies-evidence-to": "An output of the source is an input or a gate entry criterion of the target. Asserted by the producing framework.", "threads-into": "The source inserts a required branch into the target's own procedure. Asserted by the authority source.", "absorbs": "The source has taken over the subject of a framework or instrument that no longer exists separately.", "supersedes": "The source replaces the target, which is retired.", "worked-instance-of": "The source is the application of a named law or boundary class to one domain.", "_note": "consumes-evidence-of is not an authored type. It is the derived converse of supplies-evidence-to. See section 5.4 of the governing document." }, "frameworks": [ { "id": "REG-01", "spec_section": "4.1", "canonical_name": "MESA Framework", "short_form": "MESA", "mark": "trademark", "mark_rationale": null, "scope_phrase": "a four-altitude diagnostic model for institutional AI governance", "entry_version": "1.0", "specification_status": "deposited", "specification_doi": "10.5281/zenodo.22109836", "source_treatment": null, "expansion": "Maturity, Evidence, Substrate, Alignment", "former_expansion": "Middle East Strategic Alignment", "definition": "Decomposes institutional AI governance into four altitudes, each carrying a definition, inputs and outputs, one accountable role and an evidence requirement an auditor can test. The altitudes are the Regulatory Floor, the Strategic Compass, Operational Machinery and the Technical Substrate. Five mechanisms operate it: layer separation, the cross-layer cascade, the enforcement constraint, mandatory interface couplings, and the evidence-based maturity vector.", "purpose": "To answer how mature an institution's AI governance is, as a per-altitude profile that names which altitude is failing rather than as a single grade that can conceal one.", "altitude": null, "altitude_note": "MESA occupies no altitude. It is the frame in which the altitudes are defined.", "boundary_class": null, "inputs": [ "The institution's obligation register, charter, risk appetite statement and decision rights", "System evidence produced by the frameworks at each altitude", "The scope of the AI estate being assessed" ], "outputs": [ "A per-altitude maturity vector", "The result of the enforcement-constraint test, stating the effective rather than the documented state of runtime-dependent controls" ], "accountable_role": "The single executive accountable for the institution's AI governance mandate", "evidence_requirements": [ "Obligation register mapped to owners", "Chartered mandate and documented decision rights", "Gate records and completed validations", "Runtime policy configuration, event logs and BOE records from the substrate" ], "limitations": [ { "kind": "asserted", "text": "That the four-altitude decomposition matches the way institutions actually fail. Recorded as untested in the framework specification." }, { "kind": "asserted", "text": "The clause-level mappings to ISO/IEC 42001 and the NIST AI Risk Management Framework are the author's readings. Neither issuing body has reviewed or endorsed them." }, { "kind": "missing", "text": "No scoring dataset has been published, so no baseline exists against which a result can be positioned." }, { "kind": "missing", "text": "No institution unconnected to the author has published a MESA assessment." } ], "falsification_condition": "MESA is falsified if institutions that score high at the Regulatory Floor, the Strategic Compass and Operational Machinery while scoring low at the Technical Substrate are found to experience AI governance failures at the same rate as institutions scoring high at all four. That finding would refute the enforcement constraint, which is the mechanism the four-altitude decomposition exists to express, and a framework whose central mechanism does not hold does not survive by being useful.", "former_names": [], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry" }, { "entry_version": "1.0", "date": "2026-08-30", "change": "Records the retirement of the expansion Middle East Strategic Alignment at specification version 1.1, and the absorption of the Governance Maturity Model" } ] }, { "id": "REG-02", "spec_section": "4.2", "canonical_name": "MESA MRM Framework", "short_form": "MESA MRM", "mark": "trademark", "mark_rationale": null, "scope_phrase": "a six-step model risk management discipline", "entry_version": "1.0", "specification_status": "source-treatment", "specification_doi": null, "source_treatment": "Chapter 12 of AI Governance and Compliance Frameworks for the Middle East: The Enterprise Playbook, ISBN 978-1-0678960-1-0", "definition": "Model risk management as an institutional discipline in six steps: inventory, pre-validation, independent validation, approval, monitoring and revalidation. Rests on the principle that validation confers the right to be believed. Carries a dual-validation branch at step three where a Sharia Supervisory Board holds binding approval power.", "purpose": "To make a model's fitness a matter of record rather than of the building team's confidence, and to make the point at which it becomes a record identifiable in time.", "altitude": "Operational Machinery", "altitude_note": null, "boundary_class": null, "inputs": [ "Model inventory and tiering rubric", "Data lineage and classification records from REG-03", "Vendor evidence from REG-04 where the model is third-party", "Revalidation triggers from REG-05, which reopen the cycle at step six", "Sharia Supervisory Board determinations where REG-08 applies", "Approval authority granted by REG-07" ], "outputs": [ "Validation reports", "Approval records naming the person, the evidence and the date", "Monitoring findings", "Revalidation triggers" ], "accountable_role": "The head of model risk, in the second line, for the discipline; the named approving executive for each individual approval. The two MUST NOT be held by one person for the same model.", "evidence_requirements": [ "Model inventory with an owner and tier per entry", "One validation report per model at or above the tier threshold", "One approval record per production model, naming a person", "Monitoring output covering the period since approval", "A revalidation trigger register" ], "limitations": [ { "kind": "asserted", "text": "Alignment with supervisory model risk expectations. The source treatment contains no written crosswalk to current Canadian or United States supervisory guidance, and an institution MUST perform that crosswalk against the primary sources in force in its jurisdiction." }, { "kind": "missing", "text": "No published validation report template and no worked validation example a validator could copy." }, { "kind": "scope", "text": "Specifies the discipline, not the statistical or behavioural methods a validator applies within it." } ], "falsification_condition": "MESA MRM is falsified if institutions operating the six steps with genuine second-line independence are found to approve unfit models at the same rate as institutions in which the building team validates its own work. The framework's entire claim rests on independence changing the outcome, and evidence that it does not would leave a process with no defensible reason to exist.", "former_names": [], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry" } ] }, { "id": "REG-03", "spec_section": "4.3", "canonical_name": "AI Data Governance Framework", "short_form": "AI Data Governance", "mark": "trademark", "mark_rationale": null, "scope_phrase": "a control system for the data boundary in AI systems", "entry_version": "1.0", "specification_status": "source-treatment", "specification_doi": null, "source_treatment": "Chapter 13 of the Enterprise Playbook, ISBN 978-1-0678960-1-0", "definition": "The control system for the data boundary, in five stages: classify, bound, prove, gate and release. Fixes what data may exist inside an AI system, where it may reside, how its lineage is proven, what quality and minimization gates it passes, and what certification it carries. Includes the Halal data certification chain for institutions under Sharia authority.", "purpose": "To make the question of whether a given item of data may be in a given AI system answerable from a record rather than from a recollection.", "altitude": "Technical Substrate", "altitude_note": "In the engineering family this framework is the worked treatment of the data boundary class defined in 10.5281/zenodo.22109864.", "boundary_class": null, "inputs": [ "The data inventory", "Applicable residency and personal-data obligations from the Regulatory Floor", "The classification scheme in force", "Sharia permissibility criteria where REG-08 applies" ], "outputs": [ "Classification records", "Residency attestations", "Lineage graphs", "Certification records including the Halal data certification chain where applicable", "The residency rule set consumed by REG-09" ], "accountable_role": "The named data owner for the data domain. Accountability is per domain rather than per institution.", "evidence_requirements": [ "A classification record per data set admitted to an AI system", "A residency attestation per jurisdiction in which data is held or processed", "A lineage graph reaching from an attested source to the point of use, with no unattested hop", "Certification records where a certification is claimed" ], "limitations": [ { "kind": "normative-disclosure", "text": "The Halal data certification chain is an original construct of this framework. No standard-setter recognizes such a chain as of the date of this registry. It MUST be presented as author methodology and MUST NOT be presented as an industry or supervisory requirement." }, { "kind": "missing", "text": "No machine-readable classification schema has been published." }, { "kind": "scope", "text": "Governs the data boundary. Does not specify data quality measurement methods, storage architecture or transformation tooling, and extends rather than replaces a general data management body of knowledge." } ], "falsification_condition": "AI Data Governance is falsified if institutions maintaining attested lineage to the point of use are found unable to answer a data provenance question from an authority any faster, or any more defensibly, than institutions maintaining classification alone. The framework's cost sits almost entirely in the attestation of each hop, and evidence that the attestation adds nothing to the answer would remove its justification.", "former_names": [ "AI Data Governance Stack" ], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry" }, { "entry_version": "1.0", "date": "2026-08-30", "change": "Records the rename from AI Data Governance Stack, and the repositioning as the worked treatment of the data boundary class" } ] }, { "id": "REG-04", "spec_section": "4.4", "canonical_name": "AI Vendor Risk Framework (AVRF)", "short_form": "AVRF", "mark": "trademark", "mark_rationale": null, "scope_phrase": "a due-diligence discipline for third-party AI", "entry_version": "1.0", "specification_status": "deposited", "specification_doi": "10.5281/zenodo.22170146", "source_treatment": "Chapter 14 of the Enterprise Playbook, ISBN 978-1-0678960-1-0", "definition": "Governance of AI risk entering the institution through a third party, in five stages: classify, diligence, contract, monitor and exit. Vendor criticality is set by business criticality, data exposure and the autonomy the vendor's AI holds over institutional decisions together. Carries a Sharia vendor screening branch where REG-08 applies.", "purpose": "To make third-party AI risk assessable on the same terms as first-party AI risk, across a vendor boundary the institution cannot inspect directly.", "altitude": "Operational Machinery", "altitude_note": null, "boundary_class": null, "inputs": [ "Vendor inventory and criticality tiering rubric", "Data classification records from REG-03 establishing exposure", "The contractual position in force", "Sharia screening criteria where REG-08 applies" ], "outputs": [ "Vendor risk records", "Completed diligence questionnaires with evidence supplied against each answer", "Contractual control registers", "Monitoring logs and concentration analysis", "Screening attestations where applicable", "Tested exit plans" ], "accountable_role": "The named owner of the vendor relationship. One owner per relationship, with consuming business lines recorded as consulted.", "evidence_requirements": [ "A vendor risk record per vendor supplying AI capability", "A completed questionnaire with evidence attached, dated and versioned to the questionnaire version used", "A contractual control register naming which terms were obtained and which were declined", "Monitoring output covering the period since onboarding", "A dated record of the most recent exit test" ], "limitations": [ { "kind": "asserted", "text": "That the questionnaire structure matches supervisory expectations for third-party model risk. No supervisor has reviewed the instrument." }, { "kind": "missing", "text": "The questionnaire is now deposited, so the instrument exists. What remains missing is evidence that two institutions applying it independently produce comparable answers, which is a property use confers rather than publication." }, { "kind": "scope", "text": "Governs the assessment of the vendor. Does not govern the selection decision, the commercial negotiation or the security assessment of the vendor's infrastructure." } ], "falsification_condition": "AVRF is falsified if vendors assessed under the full five stages are found to produce AI incidents in the acquiring institution at the same rate and severity as vendors assessed under a generic third-party security questionnaire. The framework's claim is that model-specific diligence changes the outcome, and evidence that it does not would make the additional stages ceremony.", "former_names": [], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry, status instrument-pending" } ] }, { "id": "REG-05", "spec_section": "4.5", "canonical_name": "AI Incident Response Protocol (AIRP)", "short_form": "AIRP", "mark": "trademark", "mark_rationale": null, "scope_phrase": "an AI incident response and reconstruction protocol", "entry_version": "1.0", "specification_status": "source-treatment", "specification_doi": null, "source_treatment": "Chapter 15 of the Enterprise Playbook, ISBN 978-1-0678960-1-0", "definition": "What an institution does when an AI system fails, in six stages: signal, classify, contain, escalate, reconstruct and close. Its hardest requirement is that an incident is explainable only if the evidence needed to reconstruct it existed at the moment of the decision, bound to the policy version then in force.", "purpose": "To make an AI failure answerable, which is a different requirement from making it survivable.", "altitude": "Operational Machinery", "altitude_note": null, "boundary_class": null, "inputs": [ "Detection triggers armed at gate five of REG-06", "The BOE records produced by every other framework in this registry except REG-01, which supplies evidence to nothing", "Escalation paths and decision rights from REG-07", "Notification obligations from the Regulatory Floor", "Sharia materiality criteria where REG-08 applies" ], "outputs": [ "Incident records", "Reconstruction reports", "Regulator notifications where required", "Revalidation triggers into REG-02", "Conformance tests derived from the failure" ], "accountable_role": "The named incident lead in the governance office, appointed with a named deputy so the role is occupiable when an incident occurs.", "evidence_requirements": [ "An incident record per admitted signal, including those closed as non-incidents", "A reconstruction report for every incident classified as notifiable", "A dated notification record, or a dated rationale where notification was considered and not made", "A closure record carrying the revalidation trigger and the derived conformance test" ], "limitations": [ { "kind": "asserted", "text": "Notification timelines and notifiability thresholds vary by jurisdiction and authority. An institution MUST re-verify both against the primary sources in force in its own jurisdiction. This registry states none." }, { "kind": "missing", "text": "No incident taxonomy aligned to the public AI incident repositories, so an institution's incident record cannot be compared to any population outside it." }, { "kind": "scope", "text": "Reconstruction is possible only to the extent that the other frameworks kept their evidence. AIRP cannot compensate for an upstream framework that produced none." } ], "falsification_condition": "AIRP is falsified if institutions holding complete upstream BOE records are found no better able to reconstruct an AI incident, to a standard an external authority accepts, than institutions holding conventional application and infrastructure logs. The protocol's distinguishing claim is that decision-time evidence bound to a policy version is what reconstruction requires, and evidence that ordinary logging suffices would collapse the distinction the framework is built on.", "former_names": [], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry" }, { "entry_version": "1.0", "date": "2026-08-30", "change": "Records the reframing of the protocol around reconstruction rather than crisis process" } ] }, { "id": "REG-06", "spec_section": "4.6", "canonical_name": "Five-Gate Deployment Model", "short_form": "Five-Gate", "mark": "trademark", "mark_rationale": null, "scope_phrase": "a deployment discipline for AI systems", "naming_rule": "The terms stage-gate, phase-gate and gating process MUST NOT be used as synonyms for Five-Gate on any surface. The model is unrelated to, and not derived from, stage-gate processes for new product development. No affiliation, endorsement or lineage is claimed or implied.", "entry_version": "1.0", "specification_status": "deposited", "specification_doi": "10.5281/zenodo.22170122", "source_treatment": "Chapter 10 of the Enterprise Playbook, ISBN 978-1-0678960-1-0", "definition": "The lifecycle spine. No AI system reaches production, or remains there, except by passing five gates in order, each carrying entry criteria supplied by another framework, one accountable owner and a required evidence record. Rollback reverses G5 to G4 with evidence preserved; loop-back reopens G2 when an incident occurs at G5.", "purpose": "To make answerable, in one document, how a model gets to production and who said it could.", "altitude": "Operational Machinery", "altitude_note": "The horizontal thread through the altitude. The only framework whose inputs are wholly the outputs of others.", "boundary_class": null, "gates": [ { "gate": "G1", "name": "Data and Design", "entry_evidence_from": [ "REG-03", "REG-04" ], "accountable_role": "The named data owner" }, { "gate": "G2", "name": "Validation", "entry_evidence_from": [ "REG-02" ], "accountable_role": "The named validator" }, { "gate": "G3", "name": "Approval", "entry_evidence_from": [ "REG-02", "REG-08" ], "accountable_role": "The named accountable executive" }, { "gate": "G4", "name": "Deployment", "entry_evidence_from": [ "REG-07", "REG-04", "REG-09" ], "accountable_role": "The named platform owner" }, { "gate": "G5", "name": "Operation", "entry_evidence_from": [ "REG-05" ], "accountable_role": "The named head of the governance office" } ], "inputs": [ "The outputs of REG-02, REG-03 and REG-04 as gate entry criteria", "Release authority from REG-07", "Detection triggers from REG-05 for gate five", "The deployment topology from REG-09 where the system spans jurisdictions", "Dual-validation closure from REG-08 where it applies" ], "outputs": [ "One gate passage record per gate, naming who approved, on what evidence, and when", "Rollback records where a reversal occurred", "Loop-back records where an incident reopened validation" ], "accountable_role": "One named person per gate. A committee MUST NOT be recorded as the accountable role at any gate.", "evidence_requirements": [ "Five gate passage records per production system, each naming a person and citing the entry evidence relied on", "Each gate passage record is an instance of the BOE Declaration: the entry criteria are the boundary, the deployment freedom granted on passage is the optimizer, and the record is the evidence" ], "limitations": [ { "kind": "asserted", "text": "A trademark clearance search has not been completed as of the date of this registry. The naming rule is stated as a discipline rather than as the outcome of one, and this registry does not assert that the mark is available." }, { "kind": "missing", "text": "No readiness assessment instrument exists, so an institution can be told what the gates require but cannot be scored against them." }, { "kind": "missing", "text": "No gate evidence templates are published." }, { "kind": "scope", "text": "Governs passage. Does not specify what a validation must contain, what a classification must cover or what a monitoring threshold should be." } ], "falsification_condition": "Five-Gate is falsified if institutions operating five gates with a single named accountable person at each are found to deploy unfit AI systems at the same rate as institutions operating an automated delivery pipeline with equivalent automated checks and no named approver. The model's distinguishing claim is that a named person accountable at a checkpoint changes the outcome relative to an equivalent automated check, and evidence that it does not would leave the gates as latency.", "former_names": [], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry, status instrument-pending" }, { "entry_version": "1.0", "date": "2026-08-30", "change": "Records the promotion to the lifecycle spine of the governance family, and the BOE mapping" } ] }, { "id": "REG-07", "spec_section": "4.7", "canonical_name": "AI Governance Operating Model", "short_form": "the Operating Model", "mark": "unmarked", "mark_rationale": "A descriptive phrase in common industry use. Hard to register, weak to enforce, and asserting a mark on it would invite the criticism the consolidation exists to remove. The value sits in the artifacts, not in the exclusivity of the name. Whether to coin and mark a distinctive name, keeping this phrase as its descriptor, remains open.", "scope_phrase": "the structure, decision rights and cadence of the AI governance function", "entry_version": "1.0", "specification_status": "source-treatment", "specification_doi": null, "source_treatment": "Chapters 10 and 11 of the Enterprise Playbook, ISBN 978-1-0678960-1-0, read together with the consolidation notice at section 6.2", "definition": "How the governance function itself exists, in three parts formerly asserted as three frameworks. Structure: the governance office, its roles, staffing and reporting lines within the three-lines model. Decision rights: who is accountable, responsible, consulted and informed per lifecycle phase and decision type, with exactly one accountable person per decision. Cadence: weekly operations review, monthly risk review, quarterly board report, annual charter refresh, and the escalation paths. Includes a ninety-day stand-up path.", "purpose": "To convert a mandate into authority that is exercised on a schedule and recorded, which is the difference between a governance function and a governance intention.", "altitude": "Strategic Compass", "altitude_note": null, "boundary_class": null, "inputs": [ "The board mandate", "The institution's risk appetite", "The regulatory obligations that constrain the mandate", "The three-lines structure already in force for non-AI risk" ], "outputs": [ "The charter", "The decision-rights assignment", "The cadence calendar and its meeting and escalation records", "Release authority consumed at gate four of REG-06", "Escalation paths consumed by REG-05" ], "accountable_role": "The named head of the AI governance office", "evidence_requirements": [ "A charter, dated and approved by the body that granted the mandate", "A decision-rights assignment naming one accountable person per decision type", "Records of each cadence meeting held, including those cancelled and the reason", "Escalation records" ], "limitations": [ { "kind": "asserted", "text": "That the structure fits institutions of different sizes. The source treatment is calibrated to large regulated institutions. A smaller institution MUST adapt the structure and SHOULD record what it adapted." }, { "kind": "missing", "text": "The consolidation has not been executed in the source book, which continues to assert the three former marks until a natural reprint. This registry is the authoritative statement in the meantime." }, { "kind": "scope", "text": "Specifies the governance function. Does not specify the competencies, training or individual credentials of the people in it." } ], "falsification_condition": "The Operating Model is falsified if institutions operating a chartered office with a documented single-accountable decision-rights assignment and a recorded cadence are found to escalate AI risks no earlier, and resolve them no more consistently, than institutions handling AI governance within existing risk committees without a distinct structure. The framework's claim is that a dedicated structure with named decision rights changes when and how a risk surfaces.", "former_names": [ "Governance Office Blueprint", "RACI-AI Matrix", "Governance Cadence Framework" ], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry" }, { "entry_version": "1.0", "date": "2026-08-30", "change": "Records the consolidation of the Governance Office Blueprint, the RACI-AI Matrix and the Governance Cadence Framework into this framework" } ] }, { "id": "REG-08", "spec_section": "4.8", "canonical_name": "Sharia AI Compliance Framework (SACF)", "short_form": "SACF", "mark": "trademark", "mark_rationale": null, "scope_phrase": "a dual-authority governance architecture for Islamic finance", "entry_version": "1.0", "specification_status": "deposited", "specification_doi": "10.5281/zenodo.22170143", "source_treatment": "Chapter 7 of the Enterprise Playbook, ISBN 978-1-0678960-1-0, threaded through chapters 12, 13 and 14", "definition": "Binds a second, religiously authoritative approval power into AI lifecycle governance without splitting the institution into two governance systems. The Sharia Supervisory Board is treated as an authority source at the MESA Regulatory Floor, so its determinations cascade through the same machinery as civil regulation. Beneath that sit a Maqasid risk frame and three threads into Operational Machinery: dual validation, the Halal data certification chain, and vendor screening. Escalation is concurrent rather than sequential.", "purpose": "To make an institution operating under two binding authorities able to satisfy both from one set of records.", "altitude": "Regulatory Floor", "altitude_note": "Enters as an authority source, then threads downward into three frameworks at Operational Machinery.", "boundary_class": null, "inputs": [ "The Sharia Supervisory Board's standing determinations and its approval authority as constituted by the institution", "The Maqasid classification applied to the institution's AI decision types", "The civil obligations already registered at the Regulatory Floor" ], "outputs": [ "Sharia Supervisory Board approvals", "Dual-validation records showing both tracks closed", "Halal data certification chains", "Vendor screening attestations", "Sharia-materiality classifications on incidents" ], "accountable_role": "The named Sharia liaison in the governance office. The Sharia Supervisory Board is an authority source and MUST NOT be recorded as the accountable role.", "evidence_requirements": [ "A record of the board's constitution and the scope of its binding authority", "A dual-validation record per model where the branch applies, showing two independent closures and not one closure endorsed twice", "Certification chains where the Halal chain is claimed", "Screening attestations per screened vendor", "Concurrent escalation records where a Sharia-material incident occurred" ], "limitations": [ { "kind": "normative-disclosure", "text": "No Sharia Supervisory Board has reviewed or endorsed this framework. It is an engineering proposal for how binding Sharia authority can be integrated into AI lifecycle governance, offered for scholarly and institutional review. This clause MUST accompany any presentation of SACF until an endorsement exists and can be named." }, { "kind": "normative-disclosure", "text": "The Halal data certification chain is author methodology. No standard-setter recognizes such a chain as of the date of this registry, and it MUST NOT be presented as an existing requirement of any Sharia standard." }, { "kind": "asserted", "text": "That a Sharia Supervisory Board would accept the dual-validation construct. No board has publicly accepted it." }, { "kind": "scope", "text": "Specifies the architecture by which Sharia authority enters AI governance. Makes no Sharia determination and does not substitute for scholarly opinion on any question of permissibility." } ], "falsification_condition": "SACF is falsified if an institution operating the single-machinery constitution is found unable to satisfy both authorities from one set of records, so that a second and parallel record set has to be created for the Sharia authority in practice. The framework's central claim is that one governance system with two authority sources at its floor is sufficient for both. A parallel record set appearing under operation refutes that claim by observation rather than by opinion, which is what 3.6 requires, and it is observable by any party with access to the institution's records.", "former_names": [], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry, status instrument-pending" } ] }, { "id": "REG-09", "spec_section": "4.9", "canonical_name": "Cross-Border AI Architecture Patterns", "short_form": "the Cross-Border Patterns", "mark": "trademark", "mark_rationale": null, "scope_phrase": "four deployment architectures for multi-jurisdiction AI", "entry_version": "1.0", "specification_status": "source-treatment", "specification_doi": null, "source_treatment": "Chapter 9 of the Enterprise Playbook, ISBN 978-1-0678960-1-0", "definition": "Four architectures for operating AI under the residency rules of more than one jurisdiction, selected in four steps: enumerate the boundary set per jurisdiction, classify workloads against it, select the pattern the boundaries permit, and record the BOE Declaration. The patterns are Sovereign Silo, Federated, Regional Hub and Hybrid.", "purpose": "To convert a residency constraint from a reason a deployment cannot proceed into a determinant of the architecture the deployment takes.", "altitude": null, "altitude_note": "Occupies no MESA altitude. The only such entry in the registry.", "boundary_class": "data residency", "patterns": [ { "name": "Sovereign Silo", "applies_when": "No data may leave the jurisdiction", "property": "Full duplication per jurisdiction. Highest cost, highest control" }, { "name": "Federated", "applies_when": "Some movement is permitted under licence, raw data movement is not", "property": "Inference separated per jurisdiction, coordination central" }, { "name": "Regional Hub", "applies_when": "Transfer is permitted to a jurisdiction the others accept", "property": "One jurisdiction serves the region. Lowest cost, highest transfer exposure" }, { "name": "Hybrid", "applies_when": "Workload classes differ in what they permit", "property": "Mixed, per workload class" } ], "inputs": [ "The residency rule set supplied by REG-03", "The jurisdictions in scope and the transfer permissions in force between them", "The workload classification", "The examination scope of each authority involved" ], "outputs": [ "The selected pattern with the boundary clauses it honours recorded against it", "The deployment topology, approved at gate four of REG-06", "Residency attestations per jurisdiction", "Routing evidence per request" ], "accountable_role": "The named enterprise architect accountable for the deployment topology, held in the entity that operates the platform.", "evidence_requirements": [ "A documented boundary set per jurisdiction, each clause traceable to a primary source and dated", "A workload classification against that set", "A record of the selected pattern and the clauses that selected it", "Routing evidence sufficient to show, per request, that no clause was crossed" ], "limitations": [ { "kind": "asserted", "text": "Jurisdiction-specific transfer rules cited in the source treatment age. Every regulatory assertion MUST be re-verified against primary sources at the time of use." }, { "kind": "asserted", "text": "The worked cases in the source treatment are disclosed as composites. They illustrate the selection method and are not evidence that any named institution operates any of the four patterns." }, { "kind": "missing", "text": "No decision instrument exists, so the method cannot be applied consistently by two architects working independently." }, { "kind": "scope", "text": "Governs where inference and data may sit. Does not specify infrastructure, network architecture or the contractual arrangements by which a topology is procured." } ], "falsification_condition": "The Cross-Border Patterns are falsified if a real boundary set requires a per-workload assignment in which some workload class can be served by none of Sovereign Silo, Federated or Regional Hub. Hybrid is not a fourth alternative for this purpose. It is defined at 4.9.5 as a composition of the other three, taken per workload class, and it therefore inherits their coverage rather than extending it. The claim under test is that the first three exhaust the topologies available under a residency constraint at the level of a single workload class, and a workload class none of them can serve would refute the enumeration directly. Stating the condition against Hybrid's composition rather than against the four as a set is deliberate, because a catch-all cannot be falsified.", "former_names": [], "change_history": [ { "entry_version": "1.0", "date": "2026-08-30", "change": "First registry entry" }, { "entry_version": "1.0", "date": "2026-08-30", "change": "Records the repositioning from peer framework to worked instance of the Boundary Invariant" } ] } ], "relationships": [ { "n": 1, "from": "REG-02", "type": "instantiates", "to": [ "REG-01" ], "to_external": [], "altitude": "Operational Machinery", "subject": "Position in the maturity vector" }, { "n": 2, "from": "REG-03", "type": "instantiates", "to": [ "REG-01" ], "to_external": [], "altitude": "Technical Substrate", "subject": "Position in the maturity vector" }, { "n": 3, "from": "REG-04", "type": "instantiates", "to": [ "REG-01" ], "to_external": [], "altitude": "Operational Machinery", "subject": "Position in the maturity vector" }, { "n": 4, "from": "REG-05", "type": "instantiates", "to": [ "REG-01" ], "to_external": [], "altitude": "Operational Machinery", "subject": "Position in the maturity vector" }, { "n": 5, "from": "REG-06", "type": "instantiates", "to": [ "REG-01" ], "to_external": [], "altitude": "Operational Machinery", "subject": "Position in the maturity vector" }, { "n": 6, "from": "REG-07", "type": "instantiates", "to": [ "REG-01" ], "to_external": [], "altitude": "Strategic Compass", "subject": "Position in the maturity vector" }, { "n": 7, "from": "REG-08", "type": "instantiates", "to": [ "REG-01" ], "to_external": [], "altitude": "Regulatory Floor", "subject": "Registration as an authority source" }, { "n": 8, "from": "REG-01", "type": "absorbs", "to": [], "to_external": [ "Governance Maturity Model, retired" ], "altitude": null, "subject": "The maturity vector replaces the retired instrument" }, { "n": 9, "from": "REG-07", "type": "absorbs", "to": [], "to_external": [ "Governance Office Blueprint, retired", "RACI-AI Matrix, retired", "Governance Cadence Framework, retired" ], "altitude": null, "subject": "Structure, decision rights and cadence become three sections of one framework" }, { "n": 10, "from": "REG-07", "type": "grants-authority-to", "to": [ "REG-02", "REG-03", "REG-04", "REG-05", "REG-06" ], "to_external": [], "altitude": null, "subject": "Charter, decision rights, release authority" }, { "n": 11, "from": "REG-02", "type": "supplies-evidence-to", "to": [ "REG-06" ], "to_external": [], "altitude": null, "subject": "Validation and approval records, at G2 and G3" }, { "n": 12, "from": "REG-02", "type": "supplies-evidence-to", "to": [ "REG-05" ], "to_external": [], "altitude": null, "subject": "Validation and approval records, for reconstruction" }, { "n": 13, "from": "REG-03", "type": "supplies-evidence-to", "to": [ "REG-02" ], "to_external": [], "altitude": null, "subject": "Data lineage and classification, at pre-validation" }, { "n": 14, "from": "REG-03", "type": "supplies-evidence-to", "to": [ "REG-06" ], "to_external": [], "altitude": null, "subject": "Classification, lineage and residency attestations, at G1" }, { "n": 15, "from": "REG-03", "type": "supplies-evidence-to", "to": [ "REG-09" ], "to_external": [], "altitude": null, "subject": "The residency rule set the patterns architect around" }, { "n": 16, "from": "REG-03", "type": "supplies-evidence-to", "to": [ "REG-05" ], "to_external": [], "altitude": null, "subject": "Classification and lineage records, for reconstruction" }, { "n": 17, "from": "REG-04", "type": "supplies-evidence-to", "to": [ "REG-02" ], "to_external": [], "altitude": null, "subject": "Vendor evidence where the model under validation is third-party" }, { "n": 18, "from": "REG-04", "type": "supplies-evidence-to", "to": [ "REG-06" ], "to_external": [], "altitude": null, "subject": "Vendor clearance at G1, contractual controls at G4" }, { "n": 19, "from": "REG-04", "type": "supplies-evidence-to", "to": [ "REG-05" ], "to_external": [], "altitude": null, "subject": "Vendor risk records and monitoring logs, for reconstruction" }, { "n": 20, "from": "REG-05", "type": "supplies-evidence-to", "to": [ "REG-02" ], "to_external": [], "altitude": null, "subject": "Revalidation triggers" }, { "n": 21, "from": "REG-05", "type": "supplies-evidence-to", "to": [ "REG-06" ], "to_external": [], "altitude": null, "subject": "Armed detection triggers at G5, and loop-back reopening G2" }, { "n": 22, "from": "REG-06", "type": "supplies-evidence-to", "to": [ "REG-05" ], "to_external": [], "altitude": null, "subject": "Gate passage records, for reconstruction" }, { "n": 23, "from": "REG-07", "type": "supplies-evidence-to", "to": [ "REG-05" ], "to_external": [], "altitude": null, "subject": "Escalation paths and escalation records" }, { "n": 24, "from": "REG-08", "type": "supplies-evidence-to", "to": [ "REG-06" ], "to_external": [], "altitude": null, "subject": "Dual-validation closure, at G3" }, { "n": 25, "from": "REG-08", "type": "supplies-evidence-to", "to": [ "REG-05" ], "to_external": [], "altitude": null, "subject": "Sharia-materiality classification and board approvals" }, { "n": 26, "from": "REG-09", "type": "supplies-evidence-to", "to": [ "REG-06" ], "to_external": [], "altitude": null, "subject": "The deployment topology, approved at G4" }, { "n": 27, "from": "REG-09", "type": "supplies-evidence-to", "to": [ "REG-05" ], "to_external": [], "altitude": null, "subject": "Routing evidence per request, for reconstruction" }, { "n": 28, "from": "REG-08", "type": "threads-into", "to": [ "REG-02" ], "to_external": [], "altitude": null, "subject": "The dual-validation branch at step three" }, { "n": 29, "from": "REG-08", "type": "threads-into", "to": [ "REG-03" ], "to_external": [], "altitude": null, "subject": "The Halal data certification chain" }, { "n": 30, "from": "REG-08", "type": "threads-into", "to": [ "REG-04" ], "to_external": [], "altitude": null, "subject": "Sharia vendor screening at diligence" }, { "n": 31, "from": "REG-09", "type": "worked-instance-of", "to": [], "to_external": [ "The Boundary Invariant, data residency boundary class, 10.5281/zenodo.22109864" ], "altitude": null, "subject": "Residency is the boundary; topology is the optimization" } ] }