SKI Framework — Sovereign Knowledge Intelligence

The Problem

Six reasons regulated industries won't deploy AI — and how SKI resolves each one

These are not hesitations. They are the reasons AI adoption has stalled in core compliance functions across critical infrastructure. SKI was designed from first principles to address each one.

Loss of Sovereignty

If our operational data flows through a third-party cloud AI, we lose control of our most sensitive asset.

SKI resolves this The inference engine runs entirely within the organisation's sovereign boundary. No operational data leaves at runtime. Air-gap capable by design.

Non-Determinism

AI gives different answers to the same question. That's fundamentally incompatible with audit and regulatory compliance.

SKI resolves this A hybrid architecture — deterministic Symbolic Evaluator for explicit rules, bounded SKI Model only for semantic disambiguation — combined with mandatory canary testing and hash pinning.

Liability Opacity

When an AI flags a compliance issue (or misses one), we can't explain the basis of the decision to a regulator.

SKI resolves this Every verdict traces to a specific Knowledge Graph node and a named policy clause in a source regulatory document. No black boxes — ever.

Unsafe Intervention

An AI that can control or modify operational systems introduces catastrophic risk. We cannot put AI in the loop on safety-critical infrastructure.

SKI resolves this SKI is a passive read-only observer. It monitors and reports. It has zero control path to operational systems. Primary operations continue uninterrupted if SKI goes offline.

Rule Drift

Regulations change. We can't guarantee the AI is evaluating against the current rules, not last year's.

SKI resolves this The Knowledge Graph is a living, versioned artefact with a governed update pipeline. Every change requires extraction, human validation, cryptographic signing, and deployment. The ledger records which graph version produced each verdict.

Accountability Gap

If the AI is making compliance decisions, who is accountable? The regulator will ask, and we won't have an answer.

SKI resolves this Human reviewers validate every Knowledge Graph rule before production. Human authority is preserved on all escalations. The AI augments judgement — it does not replace it.

Spec A4 — Core Axioms

The foundational constraints that make SKI legally defensible

The three axioms are non-negotiable architectural constraints. A deployment that violates any axiom is not an SKI deployment — it is an ordinary AI system with no special compliance properties.

A1 — Proximity

Intelligence evaluation shall occur at or near the monitored data source

The inference engine runs on a dedicated on-premise edge node co-located with the operational historian or SCADA system. Round-trip latency to any remote inference endpoint is not permitted. The edge node communicates only with local data buses — not with any external network at runtime.

Physical proximity eliminates latency, enforces data sovereignty, and makes remote data exfiltration architecturally impossible — not just policy-prohibited. An external auditor can verify compliance by physically inspecting the network topology; no policy document is required.

A2 — Bounded Determinism

Within a valid signed Knowledge Graph, identical inputs produce identical verdicts

This is achieved through architectural constraints — temperature-zero inference, greedy decoding, structured output enforcement, and a hybrid evaluation architecture — combined with continuous verification via determinism canary testing. The determinism guarantee is bounded by the Knowledge Graph scope: rules not covered by the graph produce NULL_UNMAPPED, never a speculative verdict.

An audit revealing different verdicts for identical operational conditions would immediately invalidate the compliance record. Bounded determinism is the guarantee that makes SKI verdicts legally defensible. It cannot be achieved by a conventional LLM operating without architectural constraints.

A3 — Passive Oversight

The SKI evaluation layer shall not sit in-line with primary operational systems

SKI operates as a read-only sidecar, consuming telemetry from data buses without the primary operational system being aware of its presence. If the SKI engine fails, is taken offline for maintenance, or is deliberately isolated, primary operations continue without any interruption. SKI has no write path, no control path, and no alert path that can interrupt primary operations.

Monitoring systems that become operational dependencies introduce unacceptable risk in safety-critical environments. Passive oversight preserves all existing safety margins while adding a compliance intelligence layer. No safety case or risk assessment needs to account for SKI failure modes affecting operations.

Spec A5 — The Three Pillars

The structural pillars that define every compliant SKI deployment

Each pillar translates one or more axioms into concrete implementation requirements. Meeting the axioms without meeting the pillar requirements is insufficient — the pillars define what "compliance" means in practice.

Pillar S · Spec A5

Sovereignty

The asset owner retains full control over inference logic, operational data, and all update pathways. The SKI engine is physically and logically inseparable from the asset owner's infrastructure. No inference, data transfer, or model update path exists that does not require explicit, physically verified action by the organisation. The sovereign boundary is not a network policy — it is an architectural constraint enforced by physical separation.

Implementation requirements

On-premise edge compute node Hardened operating environment Air-gap capability One-way Knowledge Graph transfer mechanism No outbound runtime network path Physical access log for all sovereign boundary crossings

Pillar K · Spec A5 / B2

Knowledge Maps

All compliance evaluation is performed against a verifiable, auditable Knowledge Graph. The SKI Model does not generate regulatory judgements from its own training data — it traverses a pre-defined, human-validated graph of policy relationships. Every verdict is traceable to a specific graph node and a named policy clause in a source regulatory document. The Knowledge Graph is the complete, explicit, human-approved encoding of the compliance rules in scope.

Implementation requirements

LLM extraction pipeline Human validation gate (Domain Expert) Cryptographic signing (Knowledge Graph Owner) Version control with immutable history Differential update protocol Source document traceability per rule

Pillar I · Spec A5 / B3

Intelligence

The SKI Model serves as a tightly constrained, read-only inference engine operating against the signed Knowledge Graph. It produces only categorical verdicts — no confidence scores, no probabilistic ranges, no free-form text. The model cannot reason outside the Knowledge Graph, cannot be queried interactively, and cannot modify operational systems. Every verdict is mathematically reproducible given the same input, Knowledge Graph version, and model checkpoint — this is architecturally enforced, not behaviourally expected.

Implementation requirements

Temperature-zero inference Greedy decoding only Categorical-only structured output schema Model checkpoint hash pinning Read-only sidecar pattern Sub-100ms evaluation latency target Continuous determinism canary verification Heartbeat monitoring with failure alerting

Spec A6 — Verdict Taxonomy

Five categorical verdicts. No scores. No ambiguity.

Every evaluation produces exactly one of these five verdicts. The verdict taxonomy is closed — there is no mechanism for the system to produce a verdict outside this set, emit a confidence score, or return a free-form response.

CLEAR

→ Audit ledger (silent)

All applicable Knowledge Graph rules have been evaluated against the incoming telemetry. No compliance issue has been detected. The verdict is logged to the immutable audit ledger with a timestamp, the Knowledge Graph version hash, and the evaluated rule set.

CLEAR verdicts are silent — no notification is sent to any operational owner. They form the continuous audit evidence that the system is operating within compliance boundaries.

FLAG

→ Designated operational owner (urgent)

A compliance rule encoded in the Knowledge Graph has been breached by the incoming telemetry. The verdict includes the specific graph node, the policy clause it encodes, the operational tag that triggered it, and the evaluated value. The designated operational owner is notified immediately.

FLAG verdicts carry the full traceability chain — from telemetry value through tag registry through graph node through source document. This chain is what makes the verdict defensible in a regulatory examination.

NULL_UNMAPPED

→ Knowledge Graph Owner (coverage gap)

Telemetry has been received from a recognised operational tag, but no Knowledge Graph node exists that covers the compliance evaluation of this tag. This is a Knowledge Graph coverage gap — the system is receiving data it has no rules to evaluate. The Knowledge Graph Owner is alerted to expand the graph.

NULL_UNMAPPED is not an error — it is a signal. It means the system is seeing something real that the Knowledge Graph has not yet been extended to cover. The appropriate response is a Knowledge Graph update cycle, not an infrastructure investigation.

NULL_STALE

→ Operations team (infrastructure failure)

An expected telemetry stream — one that the Knowledge Graph has rules to evaluate and the Tag Registry is configured to receive — has gone silent. No data has arrived within the configured staleness window. This indicates a sensor failure, a pipeline interruption, or a network connectivity issue. Operations are alerted immediately.

NULL_STALE and NULL_UNMAPPED route to different owners and require different remediation. Conflating them leads to incorrect prioritisation — a NULL_STALE requires an infrastructure investigation, not a Knowledge Graph update.

DISCRETIONARY

→ Qualified human reviewer

The applicable Knowledge Graph rule has been evaluated, but the regulatory language encoded in the rule is genuinely ambiguous in context. The SKI Model has determined that the situation falls within the rule's scope, but that a categorical CLEAR or FLAG verdict cannot be issued without human interpretation. The verdict and full context are routed to a qualified reviewer.

DISCRETIONARY is produced only by Track 2 (SKI Model) evaluations — Track 1 (Symbolic Evaluator) cannot produce it by design. A high rate of DISCRETIONARY verdicts for a specific rule is a signal that the rule should be restructured in the Knowledge Graph to reduce ambiguity.

Spec Part B — Technical Architecture

Two phases. Two tracks. One sovereign boundary crossing.

The probabilistic work of policy interpretation happens once, offline. The deterministic work of runtime evaluation happens continuously, inside your sovereign boundary. Every component is designed so that its failure mode is safe.

Spec B3 — Two-Track Evaluation

Every Knowledge Graph rule is assigned at compile time to one of two evaluation tracks. Track routing is a governance decision, not a runtime inference — it is declared in the Knowledge Graph, reviewed during validation, and signed as part of the artefact.

Track 1 Symbolic Evaluator

Invoked when

Rule is expressed as an explicit predicate — threshold, enumeration, boolean comparison, or duration check. Designated Track 1 in the Knowledge Graph at compile time.

Determinism guarantee

Pure function. Identical inputs always produce identical outputs by mathematical construction — no enforcement mechanism required.

Verdicts produced

CLEAR · FLAG · NULL_UNMAPPED · NULL_STALE
Cannot produce DISCRETIONARY — by design.

Typical rules

Sensor threshold breaches, status flag checks, count / duration comparisons, permit condition matching, enumerated state checks.

Track 2 SKI Model

Invoked when

Rule requires natural-language reasoning or contextual interpretation that cannot be expressed as an explicit predicate. Designated Track 2 in the Knowledge Graph at compile time.

Determinism guarantee

Architecturally enforced: temperature zero, greedy decoding, structured output schema, model hash pinning, runtime checkpoint verification, continuous canary testing.

Verdicts produced

CLEAR · FLAG · NULL_UNMAPPED · NULL_STALE · DISCRETIONARY

Typical rules

Interpretive regulatory language, conditional multi-clause obligations, contextual severity assessments, ambiguous regulatory definitions.

Track routing is a compile-time governance decision. A rule misclassified as Track 1 when it requires reasoning will silently produce incorrect verdicts — the human validation gate is the control point that prevents this. Reclassifying a rule from Track 1 to Track 2 requires a full Knowledge Graph update cycle.

Spec B1 — Two-Phase Pipeline

The pipeline separates the probabilistic work (LLM extraction, offline) from the deterministic work (runtime evaluation, on-premise). Once the signed Knowledge Graph crosses the sovereign boundary, no further probabilistic processing occurs inside it.

Phase 1

Offline Compilation

Outside sovereign boundary

Source documents. Regulatory texts, permits, and policy documents are ingested by the extraction pipeline.

LLM extraction. A large language model converts natural-language policy into structured Subject-Relation-Object rules with Track assignments.

Human validation gate. A qualified Domain Expert reviews every extracted rule against the source document. No rule enters the graph without sign-off.

Cryptographic signing. The Knowledge Graph Owner signs the completed graph. The signature is the organisation's attestation that the graph has been reviewed and approved.

▶

One-way transfer
No data leaves

Phase 2

On-Premise Runtime

Inside sovereign boundary — no outbound network

Read-only sidecar. A passive listener connects to existing operational data buses (MQTT, Kafka, OPC-UA, or equivalent) without modifying them or alerting the primary system.

Tag Registry. Raw operational tags are resolved to Knowledge Graph entities before reaching the evaluation engine — no runtime inference of tag identity.

Hybrid evaluation. Track 1 (Symbolic Evaluator) handles explicit rules deterministically. Track 2 (SKI Model) handles semantic disambiguation only.

Immutable audit ledger. Every verdict is written to an append-only, hash-chained local ledger with the Knowledge Graph version hash. No verdict is ever deleted or modified.

Spec Part D — Governance & Conformance

Human authority at every decision point

SKI is not autonomous. The governance model ensures that human judgement — not AI inference — has final authority over every rule, every verdict pathway, and every Knowledge Graph update. Every accountable decision traces to a named individual.

D1.1 · Role 1

Knowledge Graph Owner

Cryptographically signs every approved Knowledge Graph version — the signature is the organisation's attestation that the graph has been reviewed and approved
Authorises the update pipeline to proceed to production deployment
Reviews and approves all changes to the sovereign boundary perimeter specification
Named in every audit verdict as the signing authority at time of evaluation

D1.1 · Role 2

Domain Expert

Reviews every LLM-extracted rule against the original regulatory source document before it enters the Knowledge Graph
Validates Track 1 vs Track 2 routing assignments for each rule — misclassification is a silent correctness failure
Approves or rejects rule candidates — no rule enters the graph without human sign-off
Documents the basis for any DISCRETIONARY routing decisions

D1.1 · Role 3

Operational Owner

Designated recipient of FLAG verdicts — initiates remediation within defined response SLAs
Investigates NULL_STALE alerts (sensor or pipeline failures) and coordinates infrastructure response
Documents all remediation actions with timestamps in the audit record — documentation is additive only, the ledger is never modified
Responsible for confirming the Tag Registry mapping is accurate for their operational domain

D1.1 · Role 4

Compliance Reviewer

Reviews DISCRETIONARY verdicts where regulatory language is genuinely ambiguous
Documents the interpretation rationale and the regulatory basis for the human decision
May escalate to the Knowledge Graph Owner to add an explicit rule resolving the ambiguity for future evaluations
All decisions are logged alongside the verdict in the immutable audit ledger with the reviewer's identity

D4 — Knowledge Graph Update Protocol

Every change to the Knowledge Graph — however minor — follows this governed sequence without exception. Emergency security patches to the runtime environment are permitted but require a post-patch determinism canary re-run before evaluation resumes.

Regulatory change identified — formal update cycle triggered

→

LLM extraction of new or changed rules from source documents

→

Domain Expert validation gate — rule-by-rule review against source

→

Knowledge Graph Owner signs new version with updated hash

→

One-way transfer into sovereign boundary — no reverse path

→

Audit ledger records the graph version transition with timestamp

Every verdict in the audit ledger records the exact Knowledge Graph version hash that produced it. A regulatory audit can reconstruct the precise rule set active at any point in time — including the name of the Domain Expert and Knowledge Graph Owner who approved it.

Spec Part C — Implementation

From regulatory text to live compliance monitoring in five structured phases

Assess & Scope

Map the regulatory landscape to your operational environment. Identify which regulations apply, which systems produce the relevant telemetry, and define the sovereign boundary perimeter. This phase produces the scope document that all subsequent phases are bounded by.

Output: Scope document · Regulatory inventory · Sovereign boundary specification

Extract & Structure

Run the LLM extraction pipeline over source regulatory documents. Convert natural-language policy obligations into structured Subject-Relation-Object rules. Assign each rule to Track 1 or Track 2 and map each to an operational tag in the Tag Registry.

Output: Draft Knowledge Graph · Track assignments · Coverage map · Tag Registry draft

Validate & Sign

Every extracted rule is reviewed by a qualified Domain Expert against the source regulatory document. Rules that pass validation are compiled into the signed Knowledge Graph artefact. The Knowledge Graph Owner's cryptographic signature is the organisation's legal attestation of review and approval.

Output: Signed Knowledge Graph v1.0 · Validation report · Signed artefact hash · Owner attestation record

Deploy On-Premise

Install the SKI edge node within your sovereign boundary. Connect the read-only sidecar to existing data buses (MQTT, Kafka, OPC-UA). Configure the Tag Registry to resolve operational tags to Knowledge Graph entities. Verify the network topology to confirm no outbound runtime paths exist.

Output: Live edge node · Connected data streams · Operational tag registry · Network topology verification

Monitor & Govern

Continuous compliance intelligence from day one. Manage Knowledge Graph updates through the governed update pipeline as regulations change. Every new version is validated, signed, and logged — maintaining a complete regulatory provenance chain that can survive a full regulatory audit.

Output: Continuous compliance stream · Immutable audit ledger · Regulatory provenance chain · Update cycle records

Sector Applications

Built for industries where compliance failures cost lives, licences, or billions

SKI was architected for environments where regulators audit every decision, data sovereignty is non-negotiable, and system failure is not an option.

Oil & Gas