The frameworks at work
Every solution and workflow iSystematic builds is assembled from the same deposited frameworks. Here is which part decides what, what the client keeps, and where each specification lives.
One corpus, every build
iSystematic assembles every solution it builds from the same deposited corpus of frameworks, and every solution page says which parts it uses, what each part decides and what the client holds at the end. Each framework is explained once, on nabeelkhan.com, with its DOI; this page gives each one line and a link.
The stack, top to bottom
The stack runs from where the organisation stands down to a second authority. Authority flows down. Evidence flows up. One event identity per request joins the evidence of every layer, so any answer, action or change can be reconstructed.
Where the organisation stands
MESA Framework™: a profile at four altitudes, taken at the start (Regulatory Floor, Strategic Compass, Operational Machinery, Technical Substrate).
Who decides
CADRE™, the AI governance operating model: one accountable person per decision, and a cadence that leaves records.
The lifecycle
Five-Gate Deployment Model™: G1 Data and Design, G2 Validation, G3 Approval, G4 Deployment, G5 Operation, with rollback and loop-back.
Every control
The Boundary Invariant and the BOE Declaration: the clause fixed, the optimiser freed, the evidence it held.
Every agent
PEVG: what may be believed, and by whom. PARA: what may be done, and what may be learned.
Every model call
The Pattern Language: Governed Routing Policy, Tiered Model Pool, Decision-Grade Observability, Budget as Boundary.
Every incident
AI Incident Response Protocol (AIRP)™: signal to close, reconstructed from the records above.
Where data lives
Cross-Border AI Architecture Patterns™: where data and inference may sit, jurisdiction by jurisdiction.
A second authority
Sharia AI Compliance Framework (SACF)™, where a Sharia board's authority binds. No Sharia Supervisory Board has reviewed or endorsed this framework. It is an engineering proposal offered for scholarly and institutional review.
The SACF clauses
No Sharia Supervisory Board has reviewed or endorsed this framework. It is an engineering proposal offered for scholarly and institutional review. The Halal data certification chain is author methodology and is not an existing requirement of any Sharia standard.
The frameworks, one line each
Each framework answers one question in a build and leaves a record the client keeps; each name links to its specification on nabeelkhan.com.
| Framework | The question it answers in a build | What the client keeps | Status |
|---|---|---|---|
| MESA Framework™ | Where does the organisation stand, altitude by altitude, before we build? | A four-position profile; the list of controls the platform must enforce for the profile to be true | Deposited specification, DOI 10.5281/zenodo.22109836 |
| MESA MRM Framework™ | How is the model risk of each AI system managed, step by step? | Not yet set out for builds | Deposited specification, DOI 10.5281/zenodo.22285045 |
| CADRE™, the AI governance operating model | Who decides each thing, and on what rhythm? | A decision-rights table naming one person per decision; the review calendar | Deposited specification, DOI 10.5281/zenodo.22285052 |
| Five-Gate Deployment Model™ | How does this reach production, and who said it could? | Five gate records, each naming a person and the evidence relied on | Deposited specification, DOI 10.5281/zenodo.22170122 |
| Boundary Invariant and BOE Declaration | What must this system never do, and how will we know it held? | One BOE Declaration per control: boundary, optimiser, evidence | Deposited, as part of the Pattern Language, DOI 10.5281/zenodo.22109864 |
| PEVG | What may the system believe and say? | Verifier rules; a refusal log; every answer traceable to what the verifier passed | Deposited specification, DOI 10.5281/zenodo.22170132 |
| PARA | What may an agent read, do and learn? | A registry entry per agent: faculty, allowed actions, forbidden actions, guardrail, success measures | Deposited specification, DOI 10.5281/zenodo.22170139 |
| Pattern Language (IP, AP and OP patterns) | How is each model call routed, logged, bounded and paid for? | The routing policy version per request; the spend cap and its log; the trajectory record | Deposited specification, DOI 10.5281/zenodo.22109864 |
| AI Data Governance Framework™ | May this item of data be in this system at all? | Classification and lineage records for every source the system uses | Deposited specification, DOI 10.5281/zenodo.22285047 |
| AI Vendor Risk Framework (AVRF)™ | What risk enters through each vendor? | A vendor record and questionnaire per vendor, contract terms obtained, a tested exit plan | Deposited specification, DOI 10.5281/zenodo.22170146 |
| AI Incident Response Protocol (AIRP)™ | When it fails, can we show what happened? | An incident record per signal; a reconstruction for anything serious; the test that would have caught it | Deposited specification, DOI 10.5281/zenodo.22285057 |
| Cross-Border AI Architecture Patterns™ | Where may data and inference sit? | The boundary set per jurisdiction; the pattern chosen; routing evidence | Deposited specification, DOI 10.5281/zenodo.22285049 |
| Sharia AI Compliance Framework (SACF)™ | How does a Sharia board's authority enter the same machinery? | Dual-validation records; vendor screening attestations | Deposited specification, DOI 10.5281/zenodo.22170143 |
Status is as the Defensible AI Framework Registry, version 2.0, records it for the nine governance frameworks. PEVG, PARA and the Pattern Language are each deposited on their own; the Boundary Invariant and the BOE Declaration are specified inside the Pattern Language. A deposited specification is a standalone, versioned document with a DOI on Zenodo, and each DOI here is the concept DOI. For SACF: No Sharia Supervisory Board has reviewed or endorsed this framework. It is an engineering proposal offered for scholarly and institutional review.
Rules for every page that names a framework
Every iSystematic page that names a framework follows six rules.
| Rule | How it is applied |
|---|---|
| Canonical home | One line here; the explanation lives on nabeelkhan.com with its DOI. |
| Status shown | Deposited specification, with its DOI, as the registry and Zenodo record it. No framework is described as anything more. |
| Marks | ™ at first mention on each page. CADRE™ carries the mark, and "AI governance operating model" is its unmarked descriptor. The Boundary Invariant, the BOE Declaration, PEVG, PARA and the Pattern Language are unmarked by decision. |
| What the client keeps | Only artefacts the build actually produces; an artefact not produced is not listed. |
| SACF | Its two clauses, set out in full on this page, appear wherever it is named. |
| Conformance | Self-declared. No regulator endorses the work. |
Solutions against frameworks
The matrix shows what each of iSystematic's thirteen solutions adds to the five parts that apply to every build and are not repeated here: CADRE™ (decision rights), the Five-Gate Deployment Model™ (five records), the Boundary Invariant with a BOE Declaration per control, AVRF on every vendor, and AIRP for incidents. ● marks the solution's central design element; ○ marks a part that applies.
| Solution | MESA | PEVG | PARA | Routing and spend (IP-1, IP-2, OP-7) | Logging (IP-4, AP-3) | Human review (AP-4) | Capability contracts (AP-5) | Data Governance | Cross-Border | SACF |
|---|---|---|---|---|---|---|---|---|---|---|
| S1 Leadership Briefing Desk | ● | ○ | ● | ○ | ||||||
| S2 Policy and Regulation Watch | ○ | ● | ○ | ○ | ○ | |||||
| S3 Front Door Agent | ○ | ● | ○ | ○ | ● | ● | ○ | ○ | ||
| S4 Intake to Onboarding | ○ | ○ | ● | ● | ● | |||||
| S5 Vendor Intake and AI Diligence | ○ | ● | ○ | ○ | ○ | |||||
| S6 Knowledge Desk | ● | ● | ● | ● | ○ | |||||
| S7 Meeting-to-Action Operations | ○ | ○ | ● | ● | ● | |||||
| S8 Receivables Assistant | ● | ○ | ○ | ● | ● | |||||
| S9 Research-to-Decision Office | ● | ○ | ● | ○ | ○ | |||||
| S10 Board and Committee Pack | ● | ● | ○ | ○ | ○ | |||||
| S11 Governed Agent Factory | ○ | ● | ● | ● | ● | ● | ● | ● | ○ | ○ |
| S12 Bilingual Service Desk | ○ | ● | ● | ○ | ● | ● | ● | ● | ○ | |
| S13 Practice Platform | ● | ● | ● | ● | ● | ● | ● | ● | ○ |
All thirteen solutions are at status Proposed. ● central design element; ○ applies.
The frameworks in plain words
Practice and firm pages carry the frameworks as plain promises, each one the plain-language form of one framework.
| On the page | What stands behind it |
|---|---|
| It never promises a client anything you have not approved | The Boundary Invariant |
| It checks every answer against your own sources before anyone sees it | PEVG: the verifier |
| It cannot change its own instructions; you approve what it learns | PARA: Adaptation bounded like Action |
| Nothing goes live until a named person at your firm signs it off | Five-Gate: G3 Approval |
| Confidential questions go only to the AI services you approved, in the jurisdiction you require | Governed Routing Policy (Pattern Language); Cross-Border Patterns |
| It has a monthly spending limit it cannot exceed | Budget as Boundary (Pattern Language) |
| We check every service we put into your setup | AVRF |
| If something goes wrong, we can show exactly what happened, and fix the cause | AIRP and the event identity |
| You can see what it did and why | The BOE Declaration |
Controls every workflow implementation carries
Every iSystematic workflow implementation carries seven controls, shown to the customer in plain words. They are the same ideas the enterprise practice teaches (boundaries enforced, evidence emitted, a named owner at each gate), written for a front desk rather than a validation committee.
| In plain words | The control | Pattern |
|---|---|---|
| Nothing is sent, booked, paid or published without you | Approval bound to the exact recipient, content, amount, date and action; changed details need fresh approval | P04 Approval before commitment |
| It will not send the same reminder twice | An identifier check before any external action | P07 Deduplicate before acting |
| If it cannot do the job, it tells you | Missing access, stale data or outages produce a visible failure and a manual fallback | P08 Fail visibly |
| It sees only what it needs | Least data and access; separate contexts for household, client, clinic and business | P09 Minimise and isolate data |
| An email cannot tell it to do something you did not ask | Content in emails, files and pages is data, not instructions | P10 Inspect retrieved instructions |
| You can see what it did and why | Inputs, source dates, approval, result and failures, without unnecessary sensitive data | P11 Workflow receipt |
| Every workflow has an owner and an off switch | Owner, review date, kill switch | P12 Review and retire |
Where to go next
See the frameworks at work in a solution or a workflow, or read the specifications themselves.
Where to go next
AI governance and readiness
iSystematic delivers Nabeel Khan's AI governance practice as company services: readiness diagnoses, training, architecture and advisory, led by him personally.
Governed Agent Factory
The Governed Agent Factory is one build line for every agent: PEVG contracts, BOE-shaped evidence and five gate records, ready for second-line review.
Capabilities
The six capabilities behind iSystematic's solutions: agentic automation, MCP integration, knowledge and retrieval, conversation, AgentOps and enablement.
Evidence
iSystematic shows published studies of generative AI at work, each with its sample, task and caveat, beside counter-findings. None is an iSystematic result.
Conformance is self-declared; no regulator endorses this work.