# Blockstate Architecture Approval Dossier: Model Risk Management, CISO, and Regulatory Compliance Pack ### Deterministic Execution Enclave for Tier-1 Banking, Insurance, Healthcare, and Critical Telecommunications **Document Reference:** `BST-DOSS-2026-V1` **Target Audience:** Model Risk Management (MRM) Committees, Chief Information Security Officers (CISOs), Data Protection Officers (DPOs), Head of Architecture, Head of Regulatory Compliance **Applicable Jurisdictions:** United Kingdom (PRA / FCA), European Union (EU AI Act / DORA / GDPR), United States (OCC / FRB SR 11-7 / HIPAA) **Intellectual Property & Licensing:** United Kingdom Patent Application No. 2616239.1 (*Process execution control system*, Priority Filing Date: 28 October 2026, UKIPO). Licensed under the Blockstate Commercial and Community Evaluation Licence v1.0. --- ## Executive Summary & System Description Enterprise deployments of generative artificial intelligence across retail banking, insurance underwriting, clinical healthcare triage, and telecommunications operations face a shared architectural bottleneck: probabilistic language models exhibit stochastic control flow, unverified tool dispatch, memory contamination, and lack of deterministic state auditability. When applied to mission-critical business processes, standard autonomous agent frameworks (such as LangGraph, LlamaIndex Workflows, and CrewAI) delegate state routing and tool selection to runtime LLM inference. This unconstrained autonomy violates core regulatory mandates, specifically: - **Bank of England / PRA Supervisory Statement SS1/23** (Model Risk Management Principles 3, 4, and 5: conceptual soundness, independent validation, and ongoing monitoring). - **UK Financial Conduct Authority (FCA) SYSC 13.7 & Consumer Duty (PS22/9)**: Non-delegable algorithmic governance and prevention of foreseeable customer harm. - **European Union Artificial Intelligence Act (Regulation EU 2024/1689)**: Articles 9, 11, 12, 14, and 15 (risk management, technical documentation, automatic event logging, human-in-the-loop oversight, and cybersecurity). - **EU Digital Operational Resilience Act (DORA, Regulation EU 2022/2554)**: Article 12 ICT logging, tamper-evident post-incident reconstruction, and continuous operational integrity. - **HIPAA Privacy Rule (45 CFR § 164.514(b))** and **UK / EU GDPR (Articles 25 and 32)**: Cryptographic sanitisation, pseudonymisation, and zero-leakage tokenisation of protected health information (PHI) and personally identifiable information (PII). Blockstate resolves this regulatory impasse by replacing runtime probabilistic graph routing with a formal, compile-time verified pushdown automaton and hardware-isolated execution enclave. Blockstate separates semantic natural language interpretation (delegated to the LLM) from state transition decisions, tool availability, and memory persistence (strictly controlled by deterministic Python code). ``` +--------------------------------------------------------------------------------------------------+ | BLOCKSTATE PROTECTED ENCLAVE | | | | +------------------------------------------------------------------------------------------+ | | | 1. COMPILE-TIME STATIC AST VERIFICATION | | | | ast_extractor.py: Bans getattr, forbids dynamic targets, enforces string literals | | | | dominators.py: Lengauer-Tarjan solver computes sdom/idom, verifies precursor proofs | | | +------------------------------------------------------------------------------------------+ | | | | | v | | +------------------------------------------------------------------------------------------+ | | | 2. RUNTIME INGESTION GATEWAY | | | | PIIVault (vault.py): Luhn / NHS Modulus-11 detectors scrub PII/PHI into | | | | AES-256-GCM AEAD envelope encryption with 12-byte nonce and session/revision AAD | | | +------------------------------------------------------------------------------------------+ | | | | | v | | +------------------------------------------------------------------------------------------+ | | | 3. STAGE-SCOPED TOOL DISPATCH GATEWAY | | | | gatekeeper.py: MappingProxyType immutable dispatch table filtered to active stage | | | | Strict tool excision (BLK-SEC-001): Out-of-stage tools completely invisible to LLM | | | +------------------------------------------------------------------------------------------+ | | | | | v | | +------------------------------------------------------------------------------------------+ | | | 4. DETERMINISTIC MEMORY & DIGRESSION | | | | Two-tier state: Global SessionState vs bounded LIFO TaskStack (BLK-SEC-003) | | | | Selective Detokenise[T] unwrapping inside volatile memory during execution only | | | +------------------------------------------------------------------------------------------+ | | | | | v | | +------------------------------------------------------------------------------------------+ | | | 5. CRYPTOGRAPHIC LEDGER & RESILIENCE | | | | RFC 8785 JCS canonical serialisation + SHA-256 hash chains (TurnLedgerRecord) | | | | Append-only write-ahead logging (wal/ledger.wal) with fsync and recovery replay | | | +------------------------------------------------------------------------------------------+ | +--------------------------------------------------------------------------------------------------+ ``` This approval pack provides the complete evidence base, threat models, mathematical invariants, and procedural sign-off documentation required by Model Risk Management, CISO, and Compliance boards to authorise enterprise evaluation and production deployment. --- ## Part 1: System Description & Deterministic Enclave Architecture ### 1.1 Declarative Statechart Compilation (`ast_extractor.py`) In Blockstate, conversational workflows are defined as explicit declarative statecharts via the `@Stage` and `@Workflow` decorators. At build and initialisation time, the Blockstate compiler inspects the workflow class using Python standard library `ast.parse` without executing bytecode. The compiler enforces three static guarantees before any network connection or LLM invocation can take place: 1. **Dynamic Dispatch Ban (`BLK-AST-014` / `DynamicTransitionError`):** The compiler parses all transition targets in `@Stage` methods. If a method attempts to resolve a transition target dynamically (for example, via `getattr(self, ...)`, variable indirection, or string concatenation), compilation halts immediately with error code `[Blockstate E014]`. All transition targets must be compile-time non-empty string literals matching known stage names. 2. **Validator Purity:** Method definitions annotated with `@field_validator` are analysed to verify that no `Transition.*` directives are invoked during slot validation passes. 3. **Directed CFG Construction & Reachability (`BLK-AST-002`):** The compiler constructs a directed Control Flow Graph $G = (V, E)$, where vertices $V$ represent declared stages and directed edges $E$ represent static transition targets. A Breadth-First Search (BFS) starting from `initial_stage` verifies that every declared stage is reachable. Disconnected subgraphs or unreferenced dead ends trigger immediate compilation rejection. ### 1.2 Two-Pass Execution Loop & Ephemeral Tool Gatekeeper (`gatekeeper.py`) Unlike legacy agent architectures that present an unconstrained list of tools to the LLM on every turn, Blockstate implements a strict two-pass turn loop coordinated by `ToolGatekeeper`: ``` Pass 1: Semantic Intent & Argument Extraction User Message ──> [ LLM with Stage Tools ] ──> Proposed Tool Call + Proposed Transition | v Security Gate: gatekeeper.py validates against MappingProxyType dispatch table | Pass 2: Deterministic State & Transition Execution [ Enclave Runtime ] ──> Executes Python Stage Code ──> Emits Cryptographic Turn Record ``` - **Ephemeral Read-Only Dispatch (`MappingProxyType`):** Upon stage entry, `gatekeeper.py` constructs a stage-scoped dispatch dictionary wrapped in `types.MappingProxyType`. This read-only proxy prevents runtime tampering, monkey-patching, or prototype pollution of the dispatch registry. - **Stage-Filtered Outbound Tool Schemas:** The JSON schema payload dispatched to the upstream LLM provider contains exclusively the function definitions declared in `stage_def.tools`. If the current stage is `collect_address`, the tool `execute_wire_transfer` is completely excised from the API request payload. The LLM cannot hallucinate or be jailbroken into calling a tool that is not present in its active schema. - **Enclave Gatekeeper Rejection (`BLK-SEC-001`):** If an attacker attempts to inject a raw API tool call for an unwhitelisted tool, the gatekeeper intercepts the invocation prior to execution and raises `SecurityViolationError`, triggering an immediate transition to the stage's pre-configured `on_security_violation` fallback handler. ### 1.3 Deterministic Memory Architecture: `SessionState` vs Bounded LIFO `TaskStack` To manage complex human interactions without state pollution, Blockstate introduces two-tier isolated memory: 1. **Global `SessionState`:** Contains verified, immutable business slots (such as verified customer identity, risk score, and credit policy limits). Slots within `SessionState` can be designated as `locked_slots`. Once populated, any subsequent mutation attempt raises `UnauthorisedMutationError` (`BLK-SEC-002`). 2. **Bounded LIFO `TaskStack` (`stack.py`):** Multi-turn customer digressions, side questions, and FAQ diversions do not rewrite global state. Instead, invoking `Transition.push_frame(target_stage, locked_slots)` suspends the active stage and pushes an isolated execution frame onto the stack. - **Stack Overflow Prevention (`BLK-SEC-003`):** To eliminate denial-of-service vulnerabilities caused by cyclic digressions, the runtime enforces `max_nesting_depth` (default: 5 frames). Pushing beyond this limit raises `StackOverflowError`. - **Frame Unwinding:** Upon completing the digression, `Transition.pop_frame()` resumes the parent workflow, applying any explicitly permitted `SlotMutation` rules while discarding temporary conversational noise. ### 1.4 Cryptographic Tokenisation & Ephemeral Re-Sanitisation (`vault.py`) All natural language inputs crossing the enclave boundary pass through `PIIVault`: - **Ingestion Scrubbing:** Raw text is scanned using high-performance regex detectors augmented with algorithmic checksum validators (Luhn Modulo-10 for primary account numbers; NHS Modulus-11 for national healthcare identifiers). - **Format-Preserving Token Allocation:** Sensitive entities are replaced with deterministic placeholder tokens formatted as `` (e.g. ``). - **Encrypted Local Enclave:** Plaintext values are stored exclusively within `PIIVault`, encrypted via AES-256-GCM. The upstream model provider receives only tokenised text, eliminating training data leakage and cross-tenant caching exposure. - **Selective In-Memory Detokenisation:** During backend tool execution (e.g. invoking a core banking mainframe API), parameters typed as `Detokenise[T]` are temporarily resolved to plaintext in volatile memory, executed over mutual TLS, and immediately scrubbed upon completion. Tool return values are re-scanned through `PIIVault` before re-entering conversation history. --- ## Part 2: Model Risk Governance & Regulatory Invariant Proofs Enterprise Model Risk Management (MRM) functions operating under UK PRA SS1/23, US OCC SR 11-7, and EU AI Act Article 14 require formal proof that automated systems cannot deviate from established corporate policy. ### 2.1 Mapping to Bank of England / PRA Supervisory Statement SS1/23 | PRA SS1/23 Principle | Regulatory Mandate | Blockstate Architectural Implementation | Verification Artefact | | :--- | :--- | :--- | :--- | | **Principle 1:** Model Identification & Classification | Comprehensive inventory of all model components, dependencies, and business uses. | Every workflow class compiles to a self-documenting JSON / Mermaid state diagram registering model endpoints, tokenisers, and storage backends. | `blockstate.compiler.exporters.export_json()` | | **Principle 2:** Governance & Internal Controls | Board and executive committee oversight of risk tolerances, control frameworks, and operational boundaries. | Strict gatekeeping enforces deterministic escalation paths (`on_refusal`, `on_max_turns_exceeded`) routing to human operators. | `workflow.on_breach` fallback transition bindings | | **Principle 3:** Conceptual Soundness & Design | Rigorous mathematical and logical foundation; verification that implementation matches intended business logic. | Lengauer-Tarjan dominator tree analysis proves all execution paths traverse mandatory precursor verification stages. | `LengauerTarjanSolver.verify_dominance()` | | **Principle 4:** Independent Model Validation | Independent testing of boundary conditions, stress scenarios, and policy non-bypassability. | Counterexample synthesis automatically constructs BFS bypass traces if security or compliance controls can be evaded. | `pytest -m patent_invariant` test suite | | **Principle 5:** Ongoing Monitoring & Audit | Continuous tracking of model stability, output drift, and forensic replayability of all decisions. | RFC 8785 JCS canonical cryptographic ledger records all state mutations, inputs, and tool outputs with SHA-256 hash chaining. | `TurnLedgerRecord` audit trail | ### 2.2 Lengauer-Tarjan Dominator Tree Analysis & Mathematical Dominance Proof In regulatory workflows, certain stages are legally designated as privileged or irreversible (e.g. `execute_disbursement`, `underwrite_policy`, `issue_prescription`). Compliance policy dictates that a customer interaction must never reach a privileged stage without first completing mandatory compliance checks (e.g. `verify_identity`, `affordability_assessment`, `sanctions_screening`). In probabilistic graph frameworks, proving that an LLM cannot transition directly from an unverified stage to a privileged stage is impossible because state transitions are decided dynamically by model weights. Blockstate provides a formal mathematical proof of non-bypassability at compile time using the **Lengauer-Tarjan Dominator Algorithm** (`dominators.py`): 1. **Definition of Dominance:** In the directed workflow graph $G = (V, E)$ with entry node $r$, a stage node $d$ dominates a node $n$ (written $d \operatorname{dom} n$) if every execution path from $r$ to $n$ in $G$ must pass through $d$. 2. **Algorithm Execution:** The compiler computes depth-first spanning forest numbers (`dfnum`), semi-dominators (`sdom`), and immediate dominators (`idom`) via path-compression link-eval algorithms in near-linear time: $$\mathcal{O}(|E| \cdot lpha(|E|, |V|))$$ where $lpha$ is the extremely slow-growing inverse Ackermann function. 3. **Precursor Verification:** For every privileged stage $t \in V_{ ext{priv}}$, the developer declares one or more mandatory precursor stages $P \subseteq V$. The solver asserts: $$ orall t \in V_{ ext{priv}}, \quad \exists p \in P \quad ext{such that} \quad p \operatorname{dom} t$$ 4. **Counterexample Synthesis:** If $p$ does not dominate $t$, there exists at least one path in $G$ that bypasses the mandatory control. Rather than emitting a generic syntax error, Blockstate constructs the subgraph: $$G' = G \setminus \{p\}$$ and runs a Breadth-First Search from initial stage $r$ to target stage $t$. The resulting sequence of stage names is synthesized into a concrete bypass trace and raised via `DominatorViolationError`: ``` DominatorViolationError: Privileged stage 'execute_disbursement' is reachable without traversing mandatory precursor 'sanctions_screening'. Bypass path detected: entry -> collect_applicant_data -> fast_track_review -> execute_disbursement ``` ### 2.3 Automated CI/CD Regression Gating Enterprise MRM policies mandate that compliance guarantees must be continuously re-evaluated upon every software update. Blockstate provides automated regression suites marked with `@pytest.mark.patent_invariant`: ```powershell # Mandatory compliance verification command executed in automated CI/CD pipelines .\.venv\Scripts\pytest.exe -m patent_invariant ``` If an engineer introduces a code modification that bypasses an AST check, weakens the Lengauer-Tarjan dominator invariant, or permits dynamic transition dispatch, the build pipeline fails before deployment staging. --- ## Part 3: Information Security & Threat Modelling (OWASP LLM Top 10) The Chief Information Security Officer (CISO) and Information Security Architecture Review Board require systematic evaluation against the **OWASP Top 10 for LLM Applications (2025 Edition)**. ``` +--------------------------------------------------------------------------------------------------------+ | OWASP LLM TOP 10 MITIGATION ARCHITECTURE | +--------------------------+------------------------------------+----------------------------------------+ | OWASP Vulnerability | Industry Attack Vector | Blockstate Technical Enclave Defence | +--------------------------+------------------------------------+----------------------------------------+ | LLM01: Prompt Injection | Malicious user overrides system | Strict separation of data and control. | | | instructions to alter control flow | LLM output cannot alter state directly;| | | or invoke sensitive tools. | all transitions validated by AST. | +--------------------------+------------------------------------+----------------------------------------+ | LLM02: Sensitive Info | PII/PHI leaked in conversation | PIIVault scrubs entities via Luhn/NHS | | Disclosure | context or model training logs. | checksums; stores AES-256-GCM AEAD. | +--------------------------+------------------------------------+----------------------------------------+ | LLM06: Excessive Agency | Ambient tool availability allows | Ephemeral MappingProxyType excision. | | | model to call unapproved tools | Tools for other stages are physically | | | in unexpected contexts. | omitted from API schema (BLK-SEC-001). | +--------------------------+------------------------------------+----------------------------------------+ | LLM08: Vector / Stack | Recursive digressions exhaust | Bounded LIFO TaskStack enforces | | Resource Exhaustion | memory or create unrecoverable | max_nesting_depth; raises BLK-SEC-003 | | | conversational loops. | on boundary breach. | +--------------------------+------------------------------------+----------------------------------------+ ``` ### 3.1 STRIDE Threat Model Analysis for Enclave Operations A comprehensive STRIDE assessment confirms robust controls across all six threat categories: 1. **Spoofing Identity:** Blockstate integrates with enterprise identity providers via fenced `LeaseHandle` tokens and `SessionPartitionedRingBuffer`. Session tokens are cryptographically bound to session IDs and validated against tenant boundaries. 2. **Tampering with Data:** Global state updates require schema-validated slot definitions. Attempts to overwrite `locked_slots` trigger `UnauthorisedMutationError` (`BLK-SEC-002`). The turn ledger uses RFC 8785 JSON Canonicalization Scheme (JCS) and SHA-256 hashing; modifying any historical record invalidates the entire hash chain. 3. **Repudiation:** Every interaction turn generates a 12-field `TurnLedgerRecord` capturing exact model inputs, outputs, tool invocations, and state transitions, written to persistent disk via `os.fsync`. All actions are non-repudiable and forensically reconstructible. 4. **Information Disclosure:** Natural language inputs are stripped of PII prior to egress. Plaintext tokens remain encrypted at rest inside `PIIVault` and are unwrapped only in volatile memory for explicitly annotated tool arguments (`Detokenise[T]`). 5. **Denial of Service:** Task stack depth bounding (`BLK-SEC-003`) prevents unbounded nesting. Storage lease renewal with automatic heartbeat timeout prevents deadlocks caused by zombie workers. 6. **Elevation of Privilege:** Tool gatekeeping physically excises privileged tools from outbound API schemas. Calling an unwhitelisted tool triggers `SecurityViolationError` (`BLK-SEC-001`), terminating the turn and executing safe fallback transitions. --- ## Part 4: Data Protection, Cryptographic Tokenisation & Privacy Mandates Enterprise Data Protection Officers (DPOs) and Information Risk Directors require documented compliance with **HIPAA Safe Harbor (45 CFR § 164.514(b))** and **UK / EU GDPR (Articles 25 and 32: Data Protection by Design and by Default)**. ### 4.1 Automated Entity Detection & Checksum Verification (`pii_patterns.py`) Simple regex matching produces unacceptable rates of false positives and false negatives. Blockstate couples high-speed pattern detection with algorithmic checksum verification: ``` Raw Input Stream │ ▼ [ Pattern Matcher ] ──> Regex Span Extraction │ ▼ [ Checksum Validator ] ├─► Modulo-10 Luhn Check (Payment Cards: Visa, MasterCard, Amex) ├─► Modulus-11 Check (UK National Health Service NHS Numbers) └─► Format Verification (UK National Insurance Number, US SSN) │ ▼ [ Overlap Resolver ] ──> Longest-Span + Priority-Rank Selection │ ▼ [ HMAC Deduplication ] ──> Keyed HMAC-SHA256 Session Consistency │ ▼ Tokenised Stream: "Client submitted payment." ``` - **Luhn Modulo-10 Checksum:** Primary account numbers (PANs) are parsed and verified using Luhn algorithm evaluation. Arbitrary 16-digit numeric sequences that fail the modulo-10 calculation are not tokenised, preventing corruption of legitimate non-PII numerical data. - **NHS Modulus-11 Checksum:** UK healthcare identifiers are validated using the official 10-digit Modulus-11 algorithm. Numbers with invalid check digits are flagged or handled according to clinical safety rules. - **Span & Priority Resolution:** Overlapping entity spans are resolved deterministically using longest-match and explicit priority ranking, ensuring that higher-sensitivity categories (e.g. government ID) take precedence over generic patterns. ### 4.2 Cryptographic Isolation & Session Key Derivation (`vault.py`) Plaintext entity values never touch persistent logs or external API providers: 1. **AEAD Encryption:** Sensitive entities are encrypted using **AES-256-GCM** authenticated encryption with associated data (AEAD). 2. **Unique Nonce Generation:** Every encryption operation utilises a cryptographically secure 12-byte random nonce generated via `os.urandom(12)`. 3. **Authenticated Associated Data (AAD) Binding:** The AAD string is constructed as: $$ ext{AAD} = ext{session\_id} \mathbin{\Vert} ext{schema\_version} \mathbin{\Vert} ext{revision\_id}$$ This binds the ciphertext to the specific session, preventing ciphertext transplant attacks between different users or historical revisions. 4. **Keyed HMAC Deduplication:** Within a single session, repeated occurrences of the same sensitive entity (e.g. a customer repeating their telephone number) receive the identical vault token without exposing plaintext equality across sessions. Blockstate hashes entities using HMAC-SHA256 seeded with a session-specific cryptographic salt. --- ## Part 5: Auditability, Non-Repudiation & Operational Resilience To satisfy **EU AI Act Articles 11 and 12**, **DORA Pillar 2 (Article 12 ICT Logging)**, and **PRA SS1/23 Principle 5**, an AI system must maintain an auditable record of all operational activity capable of post-incident forensic replay. ### 5.1 RFC 8785 Canonical Cryptographic Turn Ledger (`ledger.py`) Standard JSON serialisation is non-deterministic: key order, whitespace formatting, and floating-point representations vary across platforms, rendering raw SHA-256 hash chains fragile. Blockstate implements cryptographic auditability adhering to **RFC 8785 JSON Canonicalization Scheme (JCS)**: ``` Turn n - 1 Record ──> SHA-256 Hash: h_{n-1} │ ▼ [ Turn n Data ] ──> RFC 8785 JCS Canonical String ──> SHA-256 Hash: h_n (Includes h_{n-1} as parent) │ ▼ [ Session Ring Buffer ] ──> os.fsync() ──> .blockstate/wal/ledger.wal ``` Each turn generates an immutable 12-field `TurnLedgerRecord`: 1. `record_id`: Universally unique identifier (UUIDv4). 2. `session_id`: Unique session identifier. 3. `turn_number`: Monotonically increasing 64-bit integer. 4. `parent_hash`: SHA-256 hash of the preceding turn record (initial turn uses `0` repeated 64 times). 5. `timestamp_utc`: ISO 8601 millisecond-precision UTC timestamp. 6. `active_stage`: Name of the stage executing this turn. 7. `transition_target`: Target stage for the next turn. 8. `input_hash`: SHA-256 hash of the tokenised user input. 9. `tool_invocations`: Canonical list of executed tools, arguments, and return status. 10. `state_mutations`: Verified diff of updated `SessionState` slots. 11. `model_telemetry`: Tokens consumed, model identifier, and round-trip execution latency. 12. `record_hash`: Final SHA-256 hash computed over the canonical JCS representation of fields 1 through 11. ### 5.2 Write-Ahead Logging (`wal/ledger.wal`) & Crash Recovery To prevent data loss in the event of hardware power failure, container eviction, or kernel panics: - **Session-Partitioned Ring Buffer:** In-flight turn records are written to a low-latency ring buffer. - **Physical Sync:** The runtime flushes records to persistent storage (`.blockstate/wal/ledger.wal`) invoking `os.fsync` before committing any external side effects (such as releasing funds or dispatching outbound notifications). - **Causal Startup Replay:** Upon container restart, `recover_wal()` reads the write-ahead log, validates all SHA-256 parent hashes from genesis, detects any corrupted or truncated records, and reconstructs the exact `SessionState` without re-executing external tools. --- ## Part 6: Enterprise Evaluation & Staging Sign-Off Form This section provides the formal multi-disciplinary sign-off matrix required to transition Blockstate from architecture assessment to staging pilot and commercial production deployment. ### 6.1 Architecture Review Board (ARB) Technical Clearance | Review Criterion | Verification Method | Status | Sign-Off / Notes | | :--- | :--- | :--- | :--- | | **Static State Verification** | Verified that `@Workflow` classes contain zero `getattr` calls and zero dynamic transition targets (`BLK-AST-014`). | [ ] PASS | | | **Graph Reachability** | Verified directed CFG completeness and BFS reachability for all declared stages (`BLK-AST-002`). | [ ] PASS | | | **Pushdown Stack Safety** | Verified `max_nesting_depth` bounding on `TaskStack` to prevent recursive resource exhaustion (`BLK-SEC-003`). | [ ] PASS | | | **Storage SPI Compatibility** | Verified Compare-And-Swap (CAS) revision checks (`BLK-STO-002`) against target enterprise database. | [ ] PASS | | ### 6.2 Model Risk Management (MRM) Quantitative Validation | Review Criterion | Verification Method | Status | Sign-Off / Notes | | :--- | :--- | :--- | :--- | | **Policy Dominance Proof** | Lengauer-Tarjan solver executed against all privileged business stages; zero bypass paths detected. | [ ] PASS | | | **Counterexample Audit** | Verified that introducing synthetic bypass paths successfully triggers `DominatorViolationError`. | [ ] PASS | | | **Deterministic Fallbacks** | Verified explicit fallback transitions for `on_refusal`, `on_max_turns_exceeded`, and `on_breach`. | [ ] PASS | | | **PRA SS1/23 & SR 11-7** | Model inventory documentation and conceptual soundness dossier filed in Model Risk repository. | [ ] PASS | | ### 6.3 Chief Information Security Officer (CISO) & Boundary Sign-Off | Review Criterion | Verification Method | Status | Sign-Off / Notes | | :--- | :--- | :--- | :--- | | **Tool Isolation** | Verified ephemeral `MappingProxyType` tool excision; unwhitelisted tools raise `BLK-SEC-001`. | [ ] PASS | | | **PII / PHI Sanitisation** | Ingestion pipeline validated against Luhn (cards) and Modulus-11 (NHS) checksum test fixtures. | [ ] PASS | | | **Cryptographic Hygiene** | Verified AES-256-GCM AEAD encryption with 12-byte random nonces and session-bound AAD. | [ ] PASS | | | **Immutable Audit Ledger** | Verified RFC 8785 JCS canonical serialisation and SHA-256 hash chaining across continuous turn runs. | [ ] PASS | | ### 6.4 90-Day Free Evaluation Tier Authorisation Under the Blockstate Commercial and Community Evaluation Licence v1.0, regulated enterprises are authorised to deploy Blockstate within non-production environments (development, staging, sandbox, and disaster recovery) for a period of up to 90 calendar days at **£0 licence cost**. **Evaluation Project Scope:** - **Initiative Name:** `__________________________________________________` - **Business Unit:** [ ] Retail Banking [ ] Commercial Lending [ ] Insurance Underwriting [ ] Healthcare Operations [ ] Customer Care - **Staging Target Environment:** [ ] AWS GovCloud / Private VPC [ ] Microsoft Azure UK South [ ] On-Premise Kubernetes - **Evaluation Start Date:** `202___-___-___` - **Evaluation Term End Date (90 Days):** `202___-___-___` ### 6.5 Committee Sign-Off & Commercial Conversion Clearance By signing below, the members of the Architecture, Risk, Security, and Engineering committees approve the technical integration of Blockstate for staging evaluation, and endorse commercial licence conversion upon successful completion of the 90-day evaluation milestones. ``` +----------------------------------------------------------------------------------------------------+ | COMMITTEE SIGN-OFF MATRIX | +----------------------------------------+------------------------------------+----------------------+ | Role / Designee | Signature | Date | +----------------------------------------+------------------------------------+----------------------+ | Head of Model Risk Management (MRM) | __________________________________ | 202___-___-___ | | Name: | | | +----------------------------------------+------------------------------------+----------------------+ | Chief Information Security Officer | __________________________________ | 202___-___-___ | | Name: | | | +----------------------------------------+------------------------------------+----------------------+ | Data Protection Officer (DPO / Legal) | __________________________________ | 202___-___-___ | | Name: | | | +----------------------------------------+------------------------------------+----------------------+ | Vice President of Software Engineering | __________________________________ | 202___-___-___ | | Name: | | | +----------------------------------------+------------------------------------+----------------------+ ``` --- ## Technical Appendix: Quick-Start Compliance Verification To execute immediate independent compliance verification on local engineering workstations or staging environments, run the following automated test commands: ```powershell # 1. Clone repository in staging environment git clone https://github.com/blockstate-ai/blockstate.git cd blockstate # 2. Initialise approved virtual environment python -m venv .venv .\.venv\Scripts\pip.exe install -e ".[dev]" # 3. Execute the full patent-invariant compliance suite # Verifies Lengauer-Tarjan dominance, AST extraction, tool gatekeeping, and cryptographic ledger .\.venv\Scripts\pytest.exe -m patent_invariant # 4. Generate Mermaid and JSON architectural proofs for committee filing .\.venv\Scripts\python.exe -c " from blockstate.compiler.exporters import export_mermaid, export_json from tests.fixtures.regulated_workflows import RetailBankingDisbursementWorkflow with open('architecture_proof.mmd', 'w', encoding='utf-8') as f: f.write(export_mermaid(RetailBankingDisbursementWorkflow)) with open('architecture_proof.json', 'w', encoding='utf-8') as f: f.write(export_json(RetailBankingDisbursementWorkflow)) print('Compliance artefacts successfully generated in working directory.') " ``` For technical enquiries, custom on-premise evaluation support, or commercial licensing schedules (£18,000 to £48,000+ Annual Recurring Revenue based on production core allocations), contact enterprise compliance engineering at `enterprise@blockstate.dev`.