# Scrydon — Full Content > Scrydon is a European, sovereign AI Operating System and ontology-based data platform that brings the right context to the right agent, system, or person at the right time — running identically from air-gapped on-premises to hyperscale cloud, so organisations keep full control of their data, models, and workloads. This file is a fuller dump of Scrydon's platform concepts for AI agents and LLM crawlers, including the full definition, supporting context, and frequently asked questions for each platform concept. For the concise index, see https://scrydon.com/llms.txt. # Platform ## Integrations - Term: AI OS Integrations - URL: https://scrydon.com/platform/ai-os/integrations/ **Definition.** AI OS integrations connect agents and AI workflows to the tools, systems, and data they need to act on — through the Model Context Protocol (MCP), Agent-to-Agent (A2A), and hundreds of pre-built connectors. Every connection runs under the platform's scoped identity, access control, and audit, so reach never becomes a governance gap. The AI OS thrives on frontier connectivity. Agents pull context and take action across the enterprise tools and systems you already run — but without exposing your data: every connection is identity-scoped, policy-governed, and fully audited, so connectivity never opens a hole in your perimeter. No custom development needed — onboard new tools and systems in hours, not weeks, across FSI, healthcare, government, and defence. ### FAQ ### What can the AI OS integrate with? Agents and AI workflows connect through the Model Context Protocol (MCP), Agent-to-Agent (A2A) protocols, and hundreds of pre-built connectors for enterprise applications, systems, and data sources — so autonomous work can reach the tools it needs to act on. ### How are integrations governed? Every connection runs under a scoped, least-privilege identity, is authorised by policy-as-code, screened by data loss prevention, and captured in an immutable audit trail — inside a zero-trust perimeter. Connectivity never becomes a governance gap. ### Do integrations require custom development? No. Pre-built connectors and open-protocol support (MCP, A2A) mean you can onboard new tools and systems in hours rather than weeks, without bespoke integration work for each one. ### Does connecting a tool expose my data? No. Agents pull context and take action without your data leaving your control: each integration is identity-scoped, DLP-screened, and audited, and runs inside your perimeter — from air-gapped to cloud. --- ## Integrations - Term: Data Integrations - URL: https://scrydon.com/platform/analytics/integrations/ **Definition.** Analytics integrations connect hundreds of data sources — databases, data warehouses, SaaS applications, object storage, streaming feeds and flat files — into the governed lakehouse with incremental ingestion. Every source is mapped into the enterprise ontology and honours residency, classification, and access policy by default. Analytics is only as good as the data it can reach. Rather than copying data out of your control or building a bespoke pipeline for every system, you connect each source once and land it in the lakehouse with governed, incremental ingestion. Because every source is mapped into the enterprise ontology, analytics, dashboards, and grounded AI all reason over the same trusted, attributed data. ### FAQ ### What data sources can Analytics connect to? Hundreds — including databases, data warehouses, SaaS applications, object storage, streaming feeds, and flat files. Each is landed in the governed lakehouse with incremental ingestion and mapped into the enterprise ontology. ### Does ingesting data mean copying it out of my control? No. Connections honour residency, classification, and access policy by default, and data lands in your governed lakehouse — you unify the data without copying it out of your control or building bespoke pipelines for each system. ### How does the ontology fit in? Every connected source is mapped into the enterprise ontology, so analytics, dashboards, and grounded AI all reason over the same trusted, attributed data instead of disconnected, inconsistent extracts. ### Do I need a custom pipeline for each system? No. Governed, incremental ingestion connectors handle the heavy lifting, so you can onboard new sources without building and maintaining bespoke pipelines per system. --- ## Sovereign AI - Term: Sovereign AI - URL: https://scrydon.com/platform/ai-os/sovereign-ai/ **Definition.** Sovereign AI is model-agnostic AI run entirely inside your own perimeter — not tied to any single model or vendor. The AI OS serves open-weight models with vLLM in fully air-gapped, on-premises environments, and can also integrate frontier commercial models where policy allows. You can switch between models without re-architecting, and your data, models, and choices stay under your control. Tying your organisation to one model or one vendor is a strategic risk: prices change, terms change, and capability moves quickly. Sovereign AI removes that dependency. The AI OS abstracts the model from your processes, so you can run open-weight models on your own hardware, bring in a frontier model where it is permitted, and change your mind later — all without your data ever leaving your perimeter. ### FAQ ### What is sovereign AI? Sovereign AI is model-agnostic AI run entirely inside your own perimeter — not tied to any single model or vendor. The AI OS serves open-weight models with vLLM in fully air-gapped, on-premises environments, can integrate frontier commercial models where policy allows, and lets you switch between models without re-architecting, so your data, models, and choices stay under your control. ### Can it run open-weight models on-premises or air-gapped? Yes. The AI OS serves open-weight models on your own hardware using vLLM, an open-source, high-throughput LLM inference and serving engine. It runs fully on-premises and can operate completely air-gapped, with no external network or API dependency. ### Can we switch between models? Yes. Because the AI OS abstracts the model from your business processes, you can swap the model behind any workflow whenever a better, cheaper, or more compliant option appears — without re-architecting the workflow, its context, or its governance. ### Does it support frontier and commercial models too? Yes. Where your policy allows, the AI OS can integrate frontier commercial models alongside open-weight ones, so you can choose the best model for each task. Even then, the workflow keeps your data inside your perimeter under the platform's governance. ### Does our data leave our perimeter? No. Sovereign AI is built so your data, models, and reasoning stay within your perimeter — from fully air-gapped on-premises deployments to your own cloud. You stay in control of where everything runs and what, if anything, is ever shared externally. --- ## AI Governance - Term: AI Governance - URL: https://scrydon.com/platform/ai-os/ai-governance/ **Definition.** AI governance is the set of controls that keep an organisation in command of how AI uses its data and acts on its systems — data loss prevention, policy enforcement, identity and access control, audit, and human oversight. On the AI OS these controls are built into the runtime rather than bolted on: every agent and workflow runs fail-closed under policy, outputs are screened for sensitive data, external AI vendors are opt-in, and the platform maps its controls to frameworks such as the EU AI Act, ISO 42001, GDPR, and SOC 2. Putting AI into production raises an uncomfortable question: who is actually in control of your data and what the AI does with it? Scrydon answers it by making governance part of the runtime. The AI OS keeps you in command — your keys, your perimeter, opt-in for any external model — while DLP, policy-as-code, scoped identity, and a complete audit trail govern every action. The same controls that keep agents safe also produce the evidence you need for the regulators and frameworks you answer to. ### FAQ ### What is AI governance and what does the platform provide? AI governance is how an organisation stays in control of how AI uses its data and acts on its systems. The AI OS builds it into the runtime: data loss prevention, policy-as-code authorisation, scoped identity and access, immutable audit, your own encryption keys, and opt-in external AI — all enforced fail-closed on every model call, agent action, and workflow step. ### How does the platform help with EU AI Act compliance? The platform maps its controls to the EU AI Act (alongside ISO 42001, GDPR, ISO 27001, SOC 2, and SecNumCloud) and generates framework evidence packs from its built-in audit and policy machinery. That gives you traceability, human oversight, data governance, and risk controls aligned with the Act's expectations. It supports your compliance programme — formal conformity remains your organisation's responsibility — rather than being a certification in itself. ### What is the DLP (data loss prevention) capability? A DLP guardrails engine screens AI outputs before they leave the platform: it detects PII, checks for hallucination, and validates responses against regex / JSON gates. Combined with document clearance and classification, it stops sensitive data from leaking through prompts or agent actions. ### How do I stay in control of my data and which AI is used? You hold the keys (LOCAL, BYOK, or HYOK), everything runs inside your own perimeter, and external AI vendors are reached only when you explicitly opt in — by default nothing leaves. DLP screens what AI can output, document clearance governs what it can use, and you can require human approval wherever a decision warrants it. Control stays with you, not the platform or a cloud operator. ### How are AI agents governed? Every agent runs with its own scoped identity under a three-tier permission model (organisation roles, workspace membership, team grants), and a single policy decision point authorises each action across the app- and data-planes. All activity is captured in an immutable, queryable audit log with actor and IP context, so every agent action is attributable and reviewable. ### Which compliance frameworks does it map to? Controls are mapped to ISO 27001, ISO 42001, the EU AI Act, GDPR, SOC 2, SecNumCloud, NIST, the Cyber Resilience Act (CRA), and AIUC-1, with evidence packs generated from the platform's audit and policy controls to support your own certification and assurance processes. ### Is there a complete audit trail? Yes. Every action across users, agents, and workflows is logged in an immutable, queryable audit trail with full actor and IP context, sensitive fields redacted, and defined retention — the attributable record regulated industries require. ### Can we keep humans in the loop? Yes. The platform is deterministic by default and agentic only where it earns its place, and you can insert approvals and human checkpoints anywhere in a workflow. That keeps high-stakes decisions under human oversight while still automating the routine steps around them. --- ## Enterprise RAG - Term: Enterprise RAG - URL: https://scrydon.com/platform/ai-os/rag/ **Definition.** Enterprise RAG (retrieval-augmented generation) is the technique of grounding AI answers in an organisation's own data — retrieving relevant facts from its knowledge bases, ontology, and lakehouse before the model responds. On the AI OS, enterprise RAG is sovereign: retrieval runs over your ontology and vector search inside your own perimeter, every answer carries citations and provenance, and outputs are governed, so agents answer from verified data with low hallucination rather than from generic model memory. Large language models are fluent but ungrounded: ask them about your business and they guess. Enterprise RAG fixes that by retrieving the right facts from your own data first, then letting the model answer from them. Scrydon makes RAG sovereign and trustworthy: retrieval is grounded in the ontology and the Cognitive Enterprise, vector search runs in the lakehouse inside your perimeter, and every answer is traceable to its sources. The result is AI that answers from your verified data — with citations, provenance, and far less hallucination — without anything leaving your control. ### FAQ ### What is enterprise RAG? Enterprise RAG (retrieval-augmented generation) grounds AI answers in an organisation's own data: relevant facts are retrieved from its knowledge bases, ontology, and lakehouse before the model responds. On the AI OS it is sovereign — retrieval runs inside your perimeter, every answer carries citations and provenance, and outputs are governed, so agents answer from verified data with low hallucination. ### How does RAG reduce hallucination? Instead of answering from generic model memory, the model answers from facts retrieved from your own data, with the sources attached. Because Scrydon grounds retrieval in the ontology rather than loose documents, agents pull the right entities and definitions, and every answer traces back to a defined concept — which is what sharply reduces hallucination and keeps responses checkable. ### Where does the retrieval data come from? From your own Cognitive Enterprise: the ontology provides meaning, knowledge bases hold curated documents and expertise, and the lakehouse stores the underlying data with integrated vector search. RAG retrieves across all three inside your perimeter, so answers are grounded in your verified business data rather than an external corpus. ### Is enterprise RAG sovereign and secure? Yes. Embeddings, vector search, retrieval, and generation all run inside your own perimeter — from air-gapped on-premises to cloud — with open-weight models where required. DLP screens outputs for sensitive data, access is scoped per identity, and nothing is sent to external services unless you explicitly opt in. ### Do answers come with citations? Yes. Every RAG answer carries citations and provenance — links back to the source documents and data it was drawn from — so users and auditors can verify exactly where an answer came from, and the reasoning stays explainable and accountable. --- ## Ontology RAG vs Traditional RAG - Term: Ontology RAG - URL: https://scrydon.com/platform/ai-os/rag/ontology-vs-traditional-rag/ **Definition.** Ontology RAG is retrieval-augmented generation grounded in an ontology and knowledge graph rather than a flat vector store. Where traditional (naive) RAG splits documents into chunks and retrieves the ones most similar to a query, ontology RAG retrieves the connected entities, relationships, and definitions a question actually needs — enabling multi-hop reasoning, consistent business meaning, and answers traceable to defined concepts, with far lower hallucination. Traditional RAG was a breakthrough: retrieve relevant text, then let the model answer from it. But chunk-and-embed retrieval has limits — it matches surface similarity, not meaning, so it misses connected context, cannot follow relationships across documents, and grounds answers in loose snippets. Ontology RAG, the approach behind Scrydon's Enterprise RAG, retrieves over your knowledge graph instead: agents pull the right entities and the relationships between them, reason across multiple hops, and trace every answer back to a defined concept and its source. This page explains how the two differ and when ontology-grounded retrieval matters. ### FAQ ### What is the difference between ontology RAG and traditional RAG? Traditional RAG splits documents into chunks, embeds them, and retrieves the chunks most similar to a query. Ontology RAG retrieves connected entities, relationships, and definitions from a knowledge graph, so agents reason across multiple hops with shared business meaning and cite the exact concepts behind every answer — which is more accurate, explainable, and far less prone to hallucination. ### Is ontology RAG the same as GraphRAG? They are closely related. GraphRAG broadly means grounding retrieval in a graph rather than a flat vector store. Ontology RAG is GraphRAG grounded specifically in a governed ontology and knowledge graph — so retrieval uses the same typed entities, relationships, and metric definitions your analysts use, keeping AI consistent with your reporting. ### Does traditional RAG still have a place? Yes. For simple question-answering over a flat set of documents, chunk-based RAG is quick to stand up and effective. Ontology RAG matters when questions span connected entities, when consistency with business definitions is essential, or when answers must be auditable — which is the norm for organisation-wide enterprise AI. ### How does ontology RAG lower hallucination? It grounds answers in verified, connected data: agents retrieve real entities and relationships, and every answer traces back to a defined concept and its source. Reasoning over governed business meaning rather than loose, similarity-matched text is what makes hallucination measurable and rare. ### How do I use ontology RAG on Scrydon? Ontology RAG is the approach behind Scrydon's Enterprise RAG: retrieval runs over your ontology and knowledge graph with lakehouse vector search, inside your own perimeter, with citations and provenance on every answer. See the Enterprise RAG page for how it is built and deployed. --- ## AI Agent Memory - Term: AI Agent Memory - URL: https://scrydon.com/platform/ai-os/rag/agent-memory/ **Definition.** AI agent memory is the mechanism by which an agent retains and recalls information beyond a single context window — what a user told it, what it did, and what it learned. Grounded agent memory stores this as typed entities, relationships, and facts in a knowledge graph rather than as embedded text snippets, so agents recall exact facts instead of similar-sounding passages, and that memory can be audited, corrected, and reused across agents. Give an agent a long enough conversation and it forgets, contradicts itself, or quietly invents details — because most "memory" is just a vector database of past messages, retrieved by similarity when the real question is one of fact. Scrydon's approach treats memory as data: agents write what they learn as entities and relationships into the ontology-grounded knowledge graph, and retrieve it the same way they retrieve any other governed fact, with provenance intact. That memory persists across sessions, is shared across agents working the same case, and never leaves your perimeter. This page explains what agent memory actually needs to do, why vector recall falls short, and how context engineering — designing what an agent sees — depends on getting memory right. ### FAQ ### What is AI agent memory? AI agent memory is how an agent retains information beyond its immediate context window — facts about users, prior decisions, and what it has learned — and recalls it in later turns or sessions. Grounded implementations store this memory as entities and relationships in a knowledge graph rather than as raw text embeddings, so recall is precise and traceable. ### Why is vector-based agent memory unreliable? Vector memory embeds past conversation snippets and retrieves whichever ones sound most similar to the current query. That means it optimises for resemblance, not correctness — it can surface outdated or contradictory snippets, blur fine-grained details in the embedding, and offers no structured way to audit or correct what the agent "remembers." ### How does ontology-grounded memory work? Instead of embedding conversation text, agents write what they learn as typed entities, relationships, and facts into the same knowledge graph that grounds retrieval and analytics. Recall becomes a graph query for the exact fact needed, with provenance — so memory is explainable, correctable, and consistent with the rest of your governed data. ### What is context engineering? Context engineering is the discipline of designing everything a model sees before it generates a response — retrieved facts, tool definitions, memory, and instructions — rather than just the wording of a prompt. It is the successor to prompt engineering: as agents pull from RAG, memory, and tools simultaneously, what gets assembled into the context window matters more than how any single instruction is phrased. ### Can memory be shared across multiple agents? Yes, when memory is written to a shared knowledge graph rather than a private per-thread vector index. Any agent working the same customer, case, or workflow can query the same facts, so knowledge learned by one agent is immediately available to another instead of being trapped in a single conversation. ### How is agent memory kept auditable and governed? Because memory is stored as facts and relationships with provenance — what was learned, from what interaction, and when — every recalled item traces back to its source. Access control and lineage apply to memory the same way they apply to any other data on the platform, and it runs entirely inside your perimeter. --- ## Model Context Protocol (MCP) - Term: Model Context Protocol - URL: https://scrydon.com/platform/ai-os/mcp/ **Definition.** The Model Context Protocol (MCP) is an open standard that lets AI agents connect to tools, data, and systems through a single, consistent interface. The AI OS uses MCP to integrate agents with enterprise tools — but governs every call: each MCP tool invocation runs under a scoped identity, is authorised by policy-as-code, and is captured in an immutable audit trail, inside a zero-trust perimeter with DLP. MCP gives agents reach; the AI OS makes that reach safe. The Model Context Protocol has quickly become the common way to connect AI agents to the tools and data they need, replacing a tangle of bespoke integrations with one standard. But a standard that lets agents reach anything is also a new attack surface — security researchers and agencies, including the NSA, have flagged MCP security risks such as unauthenticated servers, over-broad tool permissions, and prompt-injection through tool responses. Scrydon's answer is governed MCP: agents get the reach of the protocol, but every tool call runs under scoped identity, policy, and audit, inside a zero-trust perimeter with data loss prevention — so MCP's openness never becomes an open door. ### FAQ ### What is the Model Context Protocol (MCP)? The Model Context Protocol (MCP) is an open standard that lets AI agents connect to tools, data, and systems through a single, consistent interface — replacing bespoke, per-system integrations. The AI OS uses MCP to integrate agents with enterprise tools, and governs every call so the protocol's reach stays safe. ### How does the AI OS use MCP? Agents on the AI OS call tools, data, and systems through MCP, but every invocation is governed: it runs under a scoped, least-privilege identity, is authorised by policy-as-code across the app- and data-planes, is screened by data loss prevention, and is captured in an immutable audit trail — all inside a zero-trust perimeter. ### Is MCP secure? MCP itself is just a protocol, and on its own it carries real risks: security researchers and agencies including the NSA have flagged unauthenticated MCP servers, over-broad tool permissions, and prompt injection through tool responses. The AI OS addresses these by running every MCP tool call under scoped identity, policy-as-code, DLP, and audit, fail-closed by default — so MCP's openness does not become an open door. ### What MCP security risks has the NSA flagged? Guidance from agencies including the NSA, alongside security researchers, highlights risks such as unauthenticated or untrusted MCP servers, tools granted excessive permissions, supply-chain risk in third-party MCP servers, and prompt-injection attacks that arrive through tool responses. Scrydon mitigates these with zero-trust scoping, least-privilege tool access, DLP screening, and complete audit on every call. ### How is every MCP tool call governed? Each call runs under its own scoped identity, so an agent can only reach what it is explicitly authorised to. A single policy decision point authorises the call, DLP screens the data flowing through it, and the invocation is logged immutably with full actor and IP context — making every agent action attributable and reviewable. --- ## AI Gateway - Term: AI Gateway - URL: https://scrydon.com/platform/ai-os/ai-gateway/ **Definition.** The Scrydon AI Gateway is a single governed endpoint that speaks the standard model APIs — Anthropic Messages, OpenAI Chat Completions, OpenAI Responses and Gemini — so existing tools reach any model through it without modification. Every call runs under the caller's own identity against a model allowlist, is screened by data loss prevention, metered against a spend cap, and recorded in an immutable audit trail. Vendor keys stay on the platform and are never issued to a developer at all. It is the product previously published as the Scrydon LLM Router, and an LLM router is the same category by another name. Every organisation standardising on coding agents arrives at the same fork, and both paths are bad: hand out raw vendor keys and lose attribution, model policy, DLP and audit in one gesture — or refuse the tools, and watch good engineers use them anyway on personal accounts with your source code as the prompt. The AI Gateway is the third option. Existing tooling is pointed at one governed address and keeps working unchanged; behind that address the platform resolves the credential, enforces which models this person may reach, screens what leaves, meters the turn and writes the audit record. Because the gateway shares one policy and one audit chain with the platform's governed tool calls and network egress, governance does not stop at the model call — which is where a model-only gateway has to stop. ### FAQ ### What is an AI gateway? An AI gateway is a single endpoint that applications and coding agents call instead of calling a model vendor directly, so the organisation decides which models are reachable, under whose identity, and at what cost. The Scrydon AI Gateway speaks the standard model APIs — Anthropic Messages, OpenAI Chat Completions, OpenAI Responses and Gemini — so existing tools reach it without modification, and adds the governance a regulated organisation needs: a model allowlist, data loss prevention, spend caps and an immutable audit trail on every call. ### Is this the same thing as an LLM router? Yes. An LLM router and an AI gateway name the same job — one endpoint in front of every model, deciding what runs, for whom and at what cost — and the two terms are used interchangeably. This page was published as the Scrydon LLM Router and the product is now the Scrydon AI Gateway; the name changed, nothing about the endpoint did. If you arrived looking for a router that picks between models, the routing policies are here too: an operator defines them, a developer opts into them, and a named model is never silently swapped. ### Do developers have to change how they work? No. Setup is a sign-in and a key, then a base URL and an API key in the environment. Claude Code, Codex, Gemini CLI, Cursor, Aider and anything else speaking a standard completions API run against the governed endpoint unchanged — no plugin, no wrapper binary, no forked client. What changes is on the other side of the connection: every turn is attributable to the person who made it, model policy is enforced at dispatch, and cost is attributed per developer instead of arriving as one invoice at month end. ### Who does a call actually run as? The person who made it. A gateway key is minted against a named user in your own identity provider, so every turn is attributable to a human rather than to a shared or virtual key — and when the agent goes on to call a tool, it uses that person's delegated grant, not a service account with organisation-wide reach. The agent can do what its human can do, and nothing more. This is the part a model-only gateway structurally cannot offer: it fronts your credentials, where identity is the thing the platform holds. It is also what makes per-developer cost attribution and clearance-gated model access work at all, and what makes revocation immediate — remove the person in your identity provider and the next turn stops. ### How is this different from a model-only AI gateway? Most AI gateways govern one protocol — the model call — and the good ones govern it well. But an agent's afternoon is mostly tool calls against systems that hold your data, and such a gateway is not in that path. The AI Gateway shares one credential model, one policy snapshot and one audit chain with the platform's governed tool calls and with the egress controls around the sandbox those tools execute in. Governing the model call gives you a compliance story; governing all three gives you a security boundary. ### How much latency does the governance add? Single-digit milliseconds. Measured against a real database with a committed benchmark, the gateway's own time to first byte is 3.8 ms at the median — less than the TCP and TLS handshake a direct vendor call pays whenever connections are not pooled. Prompt caching is preserved end to end, so a coding agent re-sending its whole context every turn is not quietly paying full price for it. ### Can the gateway silently switch my model to a cheaper one? No. If a request names a model, that model runs or the request fails with a typed error. A generic failure is never treated as permission to change provider. Routing policies that escalate from a cheap model to a strong one are something an operator defines and a developer opts into, never a substitution that happens behind their back. ### Which models can sit behind it? Frontier vendor APIs, models hosted in your own cloud tenancy, and open-weight models served on your own hardware — reached through the same endpoint and swapped by configuration rather than re-architecture. That matters because the model you pick today will not be the best one in a year, and the switch should not be a project. ### Can we start with just the gateway? Yes. It stands alone: no ontology, no process flows, no programme behind it. Point existing applications and coding agents at it on a Tuesday, and the first week produces a spend report you did not have before. When you later want governed agents or grounded retrieval, the route, identity, policy and audit trail are already in place. That is how most organisations start with us: [the gateway on its own](/platform/ai-os/ai-gateway/offer/) is deployed in your perimeter for a fixed monthly fee on the capacity you reserve, credited against the first platform year. ### What will the gateway tell us in the first week? What AI your organisation already uses. Once the tools point at one endpoint, every call is attributed to a person, a model, a capability and a workflow, so the first spend report shows who uses which model for what, how often, what it cost per person and per team or unit, and what the month will cost on a token contract at that pace. Most organisations discover that the answer to "do we use AI?" is larger than the official one, and that the usage is demand worth meeting rather than disobedience worth banning. The report is also the baseline the EU AI Act's inventory expectation asks for, produced by architecture rather than by a survey. --- ## Agent2Agent (A2A) - Term: Agent2Agent Protocol - URL: https://scrydon.com/platform/ai-os/a2a/ **Definition.** Agent2Agent (A2A) is an open standard for agent-to-agent interoperability — originally introduced by Google and now under the Linux Foundation — that lets AI agents from different frameworks and vendors discover each other and collaborate on tasks securely. A2A complements the Model Context Protocol: where MCP connects an agent to tools and data, A2A connects agents to other agents. The AI OS speaks A2A so your agents can interoperate with others under governance — scoped identity, policy-as-code, and audit — and sovereign deployment. Real work spans more than one agent. As organisations build agents on different frameworks — and start to collaborate with agents run by partners and vendors — they need a common way for those agents to find each other and work together. The Agent2Agent protocol is that common standard: an open, vendor-neutral way for agents to advertise their capabilities, exchange tasks, and coordinate, regardless of who built them. Scrydon makes A2A governed: your agents interoperate over the open protocol, but every exchange runs under a scoped identity, is authorised by policy, and is captured in the audit trail — inside your perimeter — so collaboration stays accountable and sovereign. ### FAQ ### What is A2A, the Agent2Agent protocol? Agent2Agent (A2A) is an open standard for agent-to-agent interoperability — originally introduced by Google and now under the Linux Foundation — that lets AI agents from different frameworks and vendors discover each other and collaborate on tasks securely. The AI OS speaks A2A so your agents can interoperate with other agents under governance and sovereign deployment. ### How is A2A different from MCP? They solve complementary problems. The Model Context Protocol (MCP) connects a single agent to the tools, systems, and data it needs to act. A2A connects agents to other agents, so they can discover each other and collaborate on tasks. On the AI OS, agents use both — reaching systems through MCP and working with other agents through A2A — under one governance model. ### Is A2A governed and sovereign on the AI OS? Yes. Your agents interoperate over the open A2A protocol, but every agent-to-agent exchange runs under a scoped, least-privilege identity, is authorised by policy-as-code, is screened by data loss prevention, and is captured in an immutable audit trail — all inside your own perimeter, from air-gapped on-premises to cloud. Interoperability never costs you governance or sovereignty. ### Can my agents collaborate with external agents over A2A? Yes. Because A2A is open and vendor-neutral, your agents can collaborate with agents run by partners and vendors as well as with your own internal agents. Either way the interaction is governed: it runs under scoped identity, is authorised by policy, is screened by DLP, and is audited — so external collaboration stays accountable and inside your control. ### Who created A2A and who maintains it? The Agent2Agent protocol was originally introduced by Google and is now maintained as an open standard under the Linux Foundation, making it a vendor-neutral way for agents from different frameworks and vendors to interoperate. The AI OS speaks A2A so you can adopt that openness without giving up governance or sovereignty. --- ## AI Observability - Term: AI Observability - URL: https://scrydon.com/platform/ai-os/observability/ **Definition.** AI observability (also called LLM observability) is the monitoring, tracing, evaluation, and audit of AI agents and workflows in production. On the AI OS it means every agent action is captured in an immutable audit trail with actor and IP context, token usage, cost, and latency are visible end to end, and outputs are continuously evaluated for quality and hallucination — so organisation-wide AI stays accountable, debuggable, and under control. You cannot govern what you cannot see. As agents and workflows act across the organisation, you need to know what they did, what it cost, how well they performed, and whether their answers can be trusted. AI observability gives the AI OS that visibility: full traces of every agent and workflow step, immutable audit of every action, live token, cost, and latency metrics, and quality and hallucination evaluations. It is the same machinery that powers governance and compliance — turning AI from an opaque black box into an accountable system you can monitor, debug, and prove. ### FAQ ### What is AI observability? AI observability (also called LLM observability) is the monitoring, tracing, evaluation, and audit of AI agents and workflows in production. On the AI OS, every agent action is logged in an immutable audit trail with actor and IP context, token usage, cost, and latency are visible end to end, and outputs are continuously evaluated for quality and hallucination — so organisation-wide AI stays accountable. ### How is LLM observability different from traditional monitoring? Traditional monitoring tracks system health — uptime, errors, latency. LLM observability adds the dimensions unique to AI: tracing multi-step agent reasoning and tool calls, tracking token usage and cost, and evaluating output quality and hallucination. It answers not just whether the AI ran, but whether its answers can be trusted and what they cost. ### Can I track AI cost, tokens, and latency? Yes. The platform tracks token usage, cost, and latency per agent, workflow, and model, so you can see exactly where AI spend and time are going and keep performance within your SLAs — making runaway cost and slow steps easy to spot and control. ### How does observability help detect hallucination? Outputs are continuously evaluated for accuracy and grounding, and because answers are grounded in your ontology with citations and provenance, each one can be traced back to its sources. That makes hallucination measurable rather than anecdotal — you can quantify quality and catch drift before it reaches users. ### How does AI observability relate to LLMOps and AIOps? AI observability is the monitoring, tracing, and evaluation core of LLMOps — the practice of running large language models and agents reliably in production. On the AI OS it pairs with model serving, governance, and cost control to give you a complete LLMOps backbone inside your own perimeter. It also underpins AIOps use cases: agents that observe IT and business operations, detect issues, and act on them — governed, audited, and grounded in your ontology, so AI operating your systems stays accountable. ### Is there a complete audit trail of agent actions? Yes. Every action by an agent or workflow is logged in an immutable, queryable audit trail with full actor and IP context, sensitive fields redacted, and defined retention. This is the same audit machinery that underpins AI governance and compliance, so observability and accountability come from one source of truth. --- ## AI Agent Orchestration - Term: AI Agent Orchestration - URL: https://scrydon.com/platform/ai-os/orchestration/ **Definition.** AI agent orchestration is the runtime discipline of coordinating multiple AI agents — plus the existing systems and people they depend on — so tasks are routed to the right agent, dependent steps run in the right sequence, and handoffs between agents are resolved reliably. On Scrydon's AI OS, that coordination runs on a shared ontology and a governed audit trail, not ad hoc message-passing between disconnected agents. A single agent can answer a question. Getting real work done usually takes several — a research agent, a retrieval agent, an approval step, a system-of-record update — each with a different tool, scope, and owner. AI agent orchestration is the layer that coordinates them: routing tasks to the right agent, sequencing dependent steps, and resolving the handoff when one agent's output becomes another's input. Scrydon's AI OS orchestrates agents the same way it orchestrates systems and people — grounded in your enterprise ontology, so every agent shares the same definition of a customer or a contract, and governed end to end, so every handoff is logged, attributable, and reviewable. ### FAQ ### What is AI agent orchestration? AI agent orchestration is the runtime layer that coordinates multiple AI agents — plus the systems and people they work alongside — so tasks are routed to the right agent, dependent steps run in the right sequence, and handoffs between agents are resolved reliably. On Scrydon's AI OS, that coordination is grounded in a shared ontology and captured in a complete audit trail. ### How is AI agent orchestration different from a workflow automation tool? Workflow tools chain fixed steps together and pass data between them as opaque payloads. AI agent orchestration coordinates autonomous agents that reason and decide, routes work dynamically based on what a task actually needs, and passes ontology-grounded context between agents rather than raw text — so the coordination adapts as the work does, while staying governed and predictable. ### How does orchestration keep multi-agent handoffs governed? Each agent runs under its own identity and scoped permissions, and every routing decision, handoff, and escalation is logged as it happens. Policy is enforced at each step rather than reviewed after the fact, so a multi-agent workflow stays auditable from the first task to the final action. ### Can agents from different frameworks or models be orchestrated together? Yes. The AI OS orchestrates agents built on different models and frameworks, alongside existing systems and people, as one governed workflow. Orchestration doesn't require standardising on a single agent framework — it coordinates whatever agents you already have through a shared ontology and a common governance layer. ### Why does a shared ontology matter for agent orchestration? Without a shared ontology, agents pass each other loosely structured text and lose business meaning at every handoff. With a shared ontology, every agent in the workflow works from the same definition of a customer, a contract, or a case — so context survives the handoff and downstream agents reason on the same facts as the ones before them. ### Does AI agent orchestration run inside our own perimeter? Yes. Orchestration runs on the AI OS entirely within your perimeter — from air-gapped on-premises to hyperscale cloud — with no dependency on external hyperscalers or third-party orchestration services. Every agent, handoff, and audit record stays inside your sovereign control. --- ## Enterprise AI - Term: Enterprise AI - URL: https://scrydon.com/platform/ai-os/enterprise-ai/ **Definition.** Enterprise AI is artificial intelligence applied to how a business actually runs — automating processes, supporting decisions, and acting on business data — with the accuracy, governance, and auditability a business context demands. Scrydon delivers it as organisational AI: agents, systems, and people coordinated by the AI OS, grounded in the Cognitive Enterprise, and run on sovereign foundations inside your own perimeter. Most enterprise AI never gets past the pilot. Copilots make individuals faster but don't automate a process; standalone agents demo well but can't be trusted with real work, because they reason over loose documents and act outside any governance. What separates enterprise AI that ships from enterprise AI that stalls is not the model — it's the platform around it. This page sets out the difference between personal, enterprise and organisational AI, what production actually requires, what the work looks like sector by sector, what European rules expect of you as a deployer, and the path from a first workshop to a governed process in production. ### FAQ ### What is enterprise AI? Enterprise AI is artificial intelligence applied to how a business actually runs — automating processes, supporting decisions, and acting on business data — with the accuracy, governance, and auditability a business context demands. It differs from personal AI tools in scope and stakes: it acts on the organisation's processes and data, so it has to be grounded, governed, and explainable rather than merely helpful. ### How is enterprise AI different from personal AI tools like copilots? Personal AI tools make one person faster at one task inside their own apps — the stakes are low and the scope is individual. Enterprise AI acts on the business itself: it automates processes, touches systems of record, and makes or informs decisions. That is why it needs what copilots don't: grounding in a shared model of the business, per-agent identity and policy, and an audit trail for every action. ### What are examples of enterprise AI? Typical examples are a claims or case process run end to end by agents with a human approving the decisions that matter; a clinical or engineering assistant that answers from your own records with citations; fraud, risk, and anti-money-laundering reviews assembled from systems that were never joined before; an operations picture that merges sensor, maintenance, and scheduling data for one operator; and compliance evidence produced automatically because the runtime recorded what the AI did. What makes each of them enterprise AI is not the model but the fact that a business process, and the accountability for it, runs through the system. ### What is the difference between enterprise AI and generative AI? Generative AI is a capability — models that produce text, code, images, or structured output. Enterprise AI is a context: applying AI, generative or not, to the way a business runs, under the accuracy, authorisation, and audit requirements that context imposes. Most enterprise AI systems use generative models for part of the work, and combine them with retrieval over governed data, deterministic rules, optimisation, and classical analytics. Buying a generative model gives you the capability; grounding, governance, orchestration, and sovereignty are what turn it into enterprise AI. ### Why do enterprise AI projects fail to reach production? Usually not because of the model, but because of what's missing around it: agents aren't grounded in the organisation's data and meaning, so their output can't be trusted; there's no identity, policy, or audit for what the AI does, so security and compliance block deployment; and each pilot is a one-off tool rather than part of a runtime, so nothing compounds. A platform that provides grounding, governance, and orchestration is what turns pilots into production. ### What is the difference between enterprise AI and organisational AI? Enterprise AI is the category: AI applied to business problems, anywhere from a single team's copilot to company-wide automation. Organisational AI is Scrydon's model for enterprise AI at full scope — operated at the level of the whole organisation, coordinated across processes, systems, and people on one governed runtime, rather than fragmented into individual tools. ### Can enterprise AI run on-premises or air-gapped? Yes. Scrydon's platform runs as a sovereign cluster inside your perimeter: in your own data centre, on a European sovereign cloud, or on a network with no route to the internet at all. Air-gapped operation is the same platform, not a reduced edition — the models, the agent runtime, the ontology, and the governance all run locally, and updates arrive through a controlled process rather than a live connection. For classified, safety-critical, and contractually isolated work, that is the difference between enterprise AI being possible and not. ### What does the EU AI Act mean for enterprise AI? Most organisations meet the EU AI Act as deployers rather than as providers, and the obligations follow the risk of the use, not the sophistication of the model. In practice that means knowing which AI systems you are running and what each one is used for; using them as the provider intended; keeping meaningful human oversight over decisions that affect people; retaining the logs that show what happened; telling people when they are subject to an AI-supported decision; and making sure the staff operating the system are competent to do so. Bans on a small set of practices apply regardless of role. Practically, it rewards architectures where the inventory, the oversight point, and the record are produced by the platform instead of being reconstructed per project. --- ## Organisational AI - Term: Organisational AI - URL: https://scrydon.com/platform/ai-os/organisational-ai/ **Definition.** Organisational AI is AI operated at the level of the whole organisation — coordinated across its processes, systems, and people — rather than as personal productivity tools that make one person faster at one task. It is enterprise AI at full scope: every agent, workflow, and decision grounded in one shared ontology, governed by one identity and audit fabric, and run on the AI OS inside your own perimeter. The first wave of workplace AI was personal: assistants and copilots that help an individual write, search, or summarise. Useful — but a hundred copilots don't add up to an organisation that runs on AI, because nothing connects them: no shared context, no common governance, no process that spans them. Organisational AI is the deliberate next step. It treats the organisation — not the individual — as the unit AI is applied to: processes are automated end to end, agents and people share one ontology-grounded model of the business, and a single governance fabric covers every action. Scrydon's AI OS is the runtime that makes this operational. ### FAQ ### What is organisational AI? Organisational AI is AI operated at the level of the whole organisation — coordinated across its processes, systems, and people — rather than as personal productivity tools that make one person faster at one task. In practice it means end-to-end processes run with AI in the loop, every agent and person reasons on one shared model of the business, and a single governance fabric covers every action. ### How is organisational AI different from enterprise AI? Enterprise AI is the category — AI applied to business problems, at any scope from a single team's copilot to company-wide automation. Organisational AI is enterprise AI at full scope: the organisation, not the individual or the department, is the unit AI is applied to. One runtime coordinates every agent, system, and person; one ontology grounds them; one governance fabric covers them. ### How is organisational AI different from copilots and personal AI? Personal AI makes an individual faster at a task inside their own apps, with no shared context and no organisation-wide governance. Organisational AI automates whole processes across teams and systems, carries context between steps through a shared ontology, and applies identity, policy, and audit consistently. Copilots are a feature of organisational AI, not a substitute for it. ### What do we need in place to move from copilots to organisational AI? Three things: a runtime that can orchestrate agents, systems, and people through whole processes; a grounded model of the business — an ontology connected to your knowledge and data — so every actor reasons on the same truth; and a governance fabric with per-agent identity, policy, and audit. That is what Scrydon's AI OS, Cognitive Enterprise, and Sovereign Foundations respectively provide. ### Is organisational AI a product or an approach? Both. As an approach, it's the decision to apply AI at the level of the organisation — processes over tasks, platform over tools. As a product, it's what Scrydon's platform delivers: the AI OS as the runtime, the Cognitive Enterprise as the grounded model, and Sovereign Foundations underneath, running inside your own perimeter. ### Does organisational AI require the cloud? No. Scrydon's platform runs identically from fully air-gapped on-premises to hyperscale cloud. Organisational AI is about scope and coordination, not location — and for sovereign and regulated organisations, running it inside your own perimeter is precisely the point. --- ## No-Code AI Agents - Term: No-Code AI Agent Workflows - URL: https://scrydon.com/platform/ai-os/agentic-ai/no-code/ **Definition.** No-code AI agent workflows let business users and analysts build, connect, and deploy AI agents through a visual, drag-and-drop builder instead of writing orchestration code. Every workflow they compose still runs on the governed AI OS runtime, inheriting the same identity, scoped access, approvals, and audit trail as agents built by engineers. Most agent backlogs are not blocked on model quality — they are blocked on engineering time. The person who understands a workflow best is usually the analyst or operations lead running it, not the developer waiting to be assigned to it. Scrydon's no-code builder lets that person drag together steps, connect enterprise tools and data sources, and compose approvals and agent reasoning into a working automation directly on the canvas. Nothing about the shortcut to build is a shortcut around governance: the workflow compiles to the same AI OS runtime as hand-coded agents, grounded in your ontology and contained inside your perimeter from the first draft. ### FAQ ### What are no-code AI agents? No-code AI agents are agent workflows built on a visual, drag-and-drop canvas instead of written in code. Business users and analysts connect tools, data sources, and agent reasoning steps directly, and the finished workflow deploys onto the same governed AI OS runtime that runs engineered agents. ### How is this different from consumer no-code automation tools like Zapier or n8n? Consumer automation tools connect apps but typically run outside enterprise identity and access control, with little to no audit trail. Scrydon's no-code builder is a layer on top of the same governed runtime as the rest of the platform — every workflow a business user builds still runs under scoped identity, approvals, and a full audit trail, and is grounded in the enterprise ontology rather than a loose web of API keys. ### Who is the no-code AI agent builder for? It's built for business users, analysts, and operations teams — the people who understand a process well enough to automate it but don't write orchestration code. Engineering teams remain responsible for the governed connectors, ontology model, and more complex multi-agent systems those workflows build on. ### Do no-code agent workflows bypass IT or security governance? No. Every workflow built on the canvas inherits the same identity, scoped permissions, approval steps, and audit trail as an agent built by an engineer. There is no separate, ungoverned path — the ease of building doesn't relax what an agent is allowed to do or how its actions are logged. ### Can no-code workflows include agents or tools built by engineers? Yes. No-code workflows and engineered agents share the same runtime, so a business-built workflow can call a specialist agent, an MCP-connected tool, or a multi-agent system built by engineering, and vice versa. Complexity moves to engineering only where it's actually needed. ### Is the no-code AI agent builder sovereign and can it run on-premises? Yes. The no-code builder runs on the same sovereign AI OS as the rest of the platform — deployable from fully air-gapped on-premises environments to cloud — so workflows business users build never leave your perimeter. --- ## AI Sandbox - Term: AI Agent Sandbox - URL: https://scrydon.com/platform/ai-os/agentic-ai/ai-sandbox/ **Definition.** An AI sandbox is the isolation boundary an AI agent's reasoning, tool, and shell loop runs inside. On Scrydon that boundary is a fresh, single-use, hardware-virtualized environment per agent turn — holding no real credentials, with default-deny network egress — and an agent turn is admitted only after signed evidence proves the boundary exists for the exact build about to run. In the summer of 2026, frontier AI labs publicly disclosed that models under evaluation escaped their test sandboxes and reached real third-party infrastructure. The pattern behind every incident was the same: the isolation was asserted by configuration and verified by no one. Scrydon was engineered on the assumption that this day would come. A model-driven workload is treated as an untrusted workload — the same category as code downloaded from the internet — because a platform that is only safe while the model behaves does not have a security boundary; it has a hope. The AI sandbox is how that assumption becomes architecture: hardware isolation per turn, credentials kept out of the model's reach, egress as an explicit contract, and escape attempts tested against every release before it ships. ### FAQ ### What is an AI sandbox? An AI sandbox is the isolation boundary an AI agent's reasoning, tool, and shell loop runs inside, keeping the model's actions contained to the resources it was actually granted. On Scrydon it is a fresh, single-use, hardware-virtualized environment per agent turn, with no real credentials inside and default-deny network egress — admitted only after signed evidence proves the boundary exists. ### Why do AI agents need sandboxing? Because an agent executes code, calls tools, and follows reasoning no one reviewed in advance — and in 2026 several frontier AI labs disclosed that models under evaluation escaped their test environments and reached real third-party infrastructure. The common cause was isolation asserted by configuration but verified by no one. An agent working on enterprise data needs a boundary that holds whether or not the model behaves. ### How is this different from running agents in a container or process sandbox? Containers and process sandboxes share a kernel with their host, so one kernel vulnerability can turn a contained workload into an escaped one. Scrydon runs each agent turn behind a hardware virtualization boundary — a much smaller, better-audited attack surface — and makes the environment single-use, so even a successful compromise has nothing durable to persist in. ### What happens if isolation can't be proven? The turn refuses to run. Admission requires fresh, signed isolation evidence bound to the exact build about to run; if that evidence is missing, expired, or belongs to a different build, the platform fails closed. There is no fallback to running the agent on a host process — that code path does not exist. ### Can a vendor integration widen the sandbox's network access? No. Every integration declares the exact hosts its code contacts in its manifest, and that declaration is intersected with your organisation's own allowlist. A vendor cannot reach a destination you haven't approved, and your allowlist cannot be widened by a manifest. An integration that declares nothing reaches nothing. ### Does the model ever see real credentials? No. Inside the sandbox the model holds opaque placeholders; the real values live in a trusted broker's ephemeral memory outside the environment, out of the model's reach for the entire turn. Credentials are resolved server-side and issued as one-use grants that are revoked at teardown. ### Does the AI sandbox work in sovereign and air-gapped deployments? Yes. The sandbox is part of the same sovereign platform as the rest of the AI OS, deployable on your own cluster — from fully air-gapped on-premises environments to sovereign cloud. Default-deny egress composes naturally with an air-gapped perimeter: an environment that reaches nothing by default has nothing to leak. --- ## Agentic OS - Term: Agentic OS (Agentic Operating System) - URL: https://scrydon.com/platform/ai-os/agentic-os/ **Definition.** An agentic OS (agentic operating system) is the runtime that AI agents run inside: it gives each agent a real identity, schedules and orchestrates its work, holds its memory, mediates every tool and data call against policy, isolates its execution, and records what it did. It is the same idea as an AI OS, viewed from the agent's side — where the AI OS starts from your business processes, the agentic OS is what those processes' autonomous steps actually execute on. Agent frameworks made it easy to build one agent. They did not make it safe to run a hundred. The moment agents stop being demos, the questions stop being about prompts and start being about operations: which agent did this, what was it allowed to reach, what did it remember from last time, who approved that tool, and what is the record. Every one of those questions has an answer in operating-system design — process identity, scheduling, permissions, memory, isolation, audit — and Scrydon's agentic OS answers them the same way, for agents. It is the same runtime as the AI OS; this page is the view from the agent's side of it. ### FAQ ### What is an agentic OS? An agentic OS (agentic operating system) is the runtime AI agents run inside. It gives each agent its own identity, schedules and orchestrates its work, holds its memory, checks every tool and data call against policy, isolates its execution, and records what it did — the same services an operating system provides to a program, applied to autonomous AI agents. ### Is an agentic OS the same as an AI OS? They are two views of the same runtime. An [AI OS](/platform/ai-os) starts from your business processes and decides which steps are handled by an existing system, an AI agent, or a person. An agentic OS is that same runtime described from the agent's side — the identity, permissions, memory and isolation an autonomous agent needs to execute the steps assigned to it. If you are asking "how does AI run across my organisation," read the AI OS page; if you are asking "what do my agents actually run on," you are on the right page. ### How is an agentic OS different from an agent framework? A framework helps you build an agent; an operating system decides what that agent may do once it is running. Frameworks are libraries inside your application — they compose prompts, tools and control flow, and they trust whatever the developer wired up. An agentic OS sits underneath every agent regardless of how it was built, enforcing identity, permissions, [isolation](/platform/ai-os/agentic-ai/ai-sandbox) and [audit](/platform/ai-os/observability) from outside the agent's reach. You can build with a framework and still run on an agentic OS. ### Why can't governance just be part of the agent's instructions? Because instructions are advice to a model, and a model can be persuaded. Anything an agent could be talked out of is not a control. In an agentic OS, the [policy](/platform/ai-os/ai-governance), data-loss prevention and approval gates run in the runtime — the agent asks for a tool or a record and the runtime decides, so there is nothing in the agent's context that could change the answer. ### Can an agentic OS run sovereign or air-gapped? Yes. The same agent runtime deploys on sovereign cloud, in your own data centre, or on a [fully disconnected network](/platform/ai-os/air-gapped-ai), with open-weight models served on your own cluster. Agents, their memory, their audit trail and the models they call all stay inside the perimeter you control. ### What is a sovereign agentic OS? A sovereign agentic OS is an agent runtime that runs entirely inside your own jurisdiction and perimeter — your infrastructure, your models, your keys, your audit records — with no dependency on an external service to keep working. It is the difference between agents that operate on your data and agents that send your data somewhere else to be operated on. See [Sovereign Foundations](/platform/sovereign-infra) for the infrastructure underneath. ### We already have copilots. Do we need an agentic OS? Copilots assist one person at a time and stop when that person stops typing. An agentic OS is for the work that runs without someone watching it — processes that execute end to end, agents that call other agents, and tasks that touch systems of record. If your AI still only answers when spoken to, you do not need one yet. If it has started acting on its own, you need somewhere governed for it to act. ### How do agents get access to tools and data on an agentic OS? Through the runtime, never directly. Tool access runs over the [Model Context Protocol](/platform/ai-os/mcp) and agent-to-agent work over [A2A](/platform/ai-os/a2a), with every call resolved against the agent's own [scoped identity](/platform/sovereign-infra/identity/agent-identity) and your policy at the moment it is made. An agent reaches exactly what it was granted and nothing it was not. --- ## Air-Gapped AI - Term: Air-Gapped AI (LLMs, RAG and Agents Offline) - URL: https://scrydon.com/platform/ai-os/air-gapped-ai/ **Definition.** Air-gapped AI runs the model serving, retrieval and agent execution layers entirely inside a network with no route to the public internet. Open-weight models are served from your own cluster, embeddings and retrieval are computed locally against your own ontology and documents, agent tools resolve only to systems inside the perimeter, and model and software updates arrive through a controlled channel you operate. A platform is only air-gapped at the point where every dependency has somewhere local to go. The infrastructure half of that — the cluster, the storage, the isolation — is covered under [Sovereign Foundations](/platform/sovereign-infra/air-gapped). This page is the other half: what happens to the AI itself. Inference stops being an API call and becomes a workload you schedule. Retrieval stops assuming a hosted embedding service. Agent tooling stops resolving to anything outside. Evaluation, updates and licensing stop phoning home. None of these are degraded modes — they are how the platform is built, which is why the capability set on a disconnected network is the same one you would get connected. ### FAQ ### Can an LLM really run air-gapped? Yes. Open-weight models are served from your own cluster inside the isolated network, so inference is a workload you schedule rather than an API you call. Nothing about generation requires an outbound connection. What matters is that everything around the model — retrieval, tooling, licensing, telemetry — is equally local, which is what this page and [Sovereign Foundations](/platform/sovereign-infra/air-gapped) between them describe. ### How does RAG work with no internet connection? Embedding, indexing and retrieval all execute inside the perimeter. [Enterprise RAG](/platform/ai-os/rag) grounds answers in your own documents and your own [ontology](/platform/analytics/ontology-based-data-platform), with citations pointing at records that live in the environment. There is no hosted embedding service in the path — which is the dependency that most often turns a supposedly offline deployment into a connected one. ### Do AI agents still work without a network? Yes, against the systems that are present. Agents reach tools over the [Model Context Protocol](/platform/ai-os/mcp) and each other over [A2A](/platform/ai-os/a2a) exactly as they would anywhere else; the difference is that the only destinations that resolve are the ones inside your environment. An agent runtime built on default-deny egress composes naturally with a network that has no egress at all. ### How do you update models and software on an air-gapped network? Through a controlled channel you operate — typically approved removable media or a data diode — with updates staged, checked and promoted on your schedule. Nothing downloads in the background and no component silently drifts to a new version, because no component has a route to fetch one. ### Which models can we run offline? Any open-weight model your hardware can serve. The platform is [model-agnostic](/platform/ai-os/sovereign-ai), so the choice is yours and it can change later without re-architecting the agents, retrieval and processes built on top. Frontier models delivered as a hosted service are, by definition, not available on a disconnected network — which is precisely why model-agnosticism matters here. ### Does an air-gapped deployment need its own hardware? It needs a cluster inside the isolated network — the platform runs as a clustered deployment, close to where the work happens, whether that is a data centre, an accredited facility, or a deployed headquarters. It is not an inference library running on an individual device. ### Is anything missing compared with a connected deployment? The capability set is the same: the same AI OS, the same agents, the same ontology and analytics, the same governance and audit. What differs is that hosted frontier models are unavailable and updates are something you carry in rather than something that arrives. Nothing runs in a reduced mode because the network is absent. ### How is this different from the Sovereign Foundations air-gapped page? [That page](/platform/sovereign-infra/air-gapped) is the platform-level answer — the full AI and data platform on disconnected networks, and the infrastructure that makes it possible. This page is the AI layer in detail: where the weights live, how retrieval grounds itself, what agents connect to, and how models stay current. Start there for the deployment picture; come here for what the AI itself is doing. --- ## Shadow AI - Term: Shadow AI - URL: https://scrydon.com/platform/ai-os/ai-governance/shadow-ai/ **Definition.** Shadow AI is AI tooling and autonomous agents used across an organisation outside IT and governance oversight — personal chatbot accounts, unsanctioned copilots, and unmanaged scripts calling LLM APIs directly. It leaves the organisation without visibility into what data reaches which models, and without the inventory regulators increasingly require. Shadow AI spreads for the same reason shadow IT always did: a sanctioned tool is slower to provision than a browser tab. An employee signs up for a chatbot with a personal email, a team wires a script straight into an LLM API, an agent gets deployed to automate a workflow nobody registered — and each one becomes a blind spot in what data leaves the organisation and how. Scrydon closes that gap from two directions: AI Governance gives you continuous discovery and a live inventory of AI and agent usage across the estate, while the AI OS gives teams a fast, governed alternative to unsanctioned tools — so the fix isn't a ban people route around, it's a better default. ### FAQ ### What is shadow AI? Shadow AI is AI tooling and autonomous agents used across an organisation outside IT and governance oversight — personal chatbot accounts, unsanctioned copilots, and scripts or internal tools calling LLM APIs directly. It leaves the organisation without visibility into what data reaches which models, or an inventory of what AI is actually running. ### Why is shadow AI a compliance risk, not just an IT problem? You cannot govern, risk-classify, or report on AI systems you don't know exist. As AI regulation matures, a complete inventory of AI and agent usage becomes the starting point for compliance, not IT housekeeping — and shadow AI is precisely what makes that inventory incomplete. ### How does the EU AI Act affect shadow AI? Most EU AI Act high-risk obligations (Annex III) apply from 2 December 2027, and those for AI in regulated products (Annex I) from 2 August 2028. Demonstrating compliance starts with knowing which AI systems and agents are actually running, what they touch, and who is accountable for them. An organisation with unsanctioned, undiscovered AI usage cannot produce that inventory, which turns shadow AI from a hygiene issue into a compliance gap as those obligations start to apply. ### How do you detect shadow AI in an organisation? Detection starts with continuous discovery of AI and agent usage across the estate — sanctioned and unsanctioned — built into a live inventory rather than a one-off audit. Scrydon's AI Governance capability surfaces this inventory on an ongoing basis, so new unsanctioned tools and agents don't quietly re-accumulate after the first clean-up. ### Does banning shadow AI tools actually work? Rarely on its own. Blocking sanctioned AI tools without giving teams a viable alternative typically pushes usage onto personal devices and accounts, where the organisation has even less visibility than before. The more durable fix pairs discovery with a governed alternative that's genuinely competitive to use. ### How does Scrydon help reduce shadow AI? The AI OS combines continuous discovery and inventory of AI and agent usage with a governed alternative — chat, copilots, and agents running inside your perimeter under policy-as-code, DLP, and scoped identity. Because the governed path is also the fast path, adoption shifts there rather than staying in personal, unmanaged tools. --- ## Sovereign Foundations - Term: Sovereign Foundations - URL: https://scrydon.com/platform/sovereign-infra/ **Definition.** Sovereign infrastructure is the zero-trust foundation the AI OS runs on: continuous verification of every request, federated identity, and confidential computing, delivered identically from air-gapped on-premises deployments through to hyperscale cloud — so you keep full control of your data, models, and workloads. The AI OS only works if it can be trusted, and that trust starts at the base of the stack. Scrydon's sovereign infrastructure gives every component the same zero-trust footing wherever it runs — a disconnected datacentre, your private cloud, or a hyperscaler — with no reliance on external API dependencies and no compromise on control. ### FAQ ### What is sovereign infrastructure? Sovereign infrastructure is the zero-trust foundation the AI OS runs on — continuous verification, federated identity, and confidential computing — delivered identically from air-gapped on-premises deployments through to hyperscale cloud, so you keep full control of your data, models, and workloads. ### Can the platform run fully air-gapped? Yes. The complete platform can run with no external network dependencies, ideal for defence, critical national infrastructure, and classified workloads — and the same platform also scales to private and hyperscale cloud without changing its security model. ### What is confidential computing and why does it matter? Confidential computing encrypts data while it is being processed in memory, using hardware Trusted Execution Environments (AMD SEV-SNP, Intel TDX). It protects workloads even from infrastructure administrators and cloud operators, closing the gap left by encryption that only covers data at rest and in transit. ### How does identity work across the platform? Sovereign infrastructure integrates with your existing identity provider via SAML, OAuth 2.0, and OIDC, and enforces zero-trust access for every user, workload, and AI agent — with complete, attributable audit trails on every action. --- ## Confidential Compute - Term: Confidential Compute - URL: https://scrydon.com/platform/sovereign-infra/confidential-compute/ **Definition.** Confidential compute runs AI workloads inside hardware-based Trusted Execution Environments (TEEs) so data and models stay encrypted in memory during processing — not only at rest and in transit. The hardware isolates the workload even from the infrastructure operator and privileged administrators, and remote attestation cryptographically proves the environment's integrity before any secret, key, or model is released to it. Most encryption protects data at rest and in transit but leaves it exposed in memory while it is actually being used. Sovereign confidential compute closes that gap, letting you use powerful infrastructure — from your own hardware to public cloud — without surrendering confidentiality of your most sensitive data and models. The AI OS supports confidential compute across deployment targets — on-premises and on Azure Local, as well as in public cloud, where Microsoft Azure is available today, with further platforms planned. ### FAQ ### What is confidential compute? Confidential compute runs workloads inside hardware-based Trusted Execution Environments (TEEs) so data and models stay encrypted in memory during processing — not only at rest and in transit. The hardware isolates the workload even from the infrastructure operator and privileged administrators, and remote attestation proves the environment's integrity before secrets are released. ### Which platforms are supported today? Microsoft Azure is the supported cloud platform today, using Azure confidential VMs and GPUs built on AMD SEV-SNP and Intel TDX. Support for further confidential compute platforms is planned. ### Is data protected from the cloud operator? Yes. With confidential compute, memory is encrypted by the CPU and GPU hardware and the keys are controlled by you. The cloud operator and infrastructure administrators cannot read your data or models while they are being processed. ### What is remote attestation? Remote attestation is cryptographic proof that a workload is running in a genuine, unmodified Trusted Execution Environment. The AI OS uses it to ensure secrets, keys, and models are only released to an environment whose integrity has been verified. ### Why run sovereign AI on a hyperscaler at all? Confidential compute lets you use hyperscale capacity and GPU availability while keeping data and models cryptographically protected from the cloud platform — combining cloud scale with the confidentiality regulated and sovereignty-conscious organisations require. --- ## On-Premises - Term: AI & Data On-Premises - URL: https://scrydon.com/platform/sovereign-infra/on-prem/ **Definition.** On-premises AI & data means running the entire platform — models, agents, ontology, and analytics — on infrastructure you own and operate, inside your own datacentre or edge location. Data and models stay physically within your perimeter and under your control, with confidential computing and zero-trust enforcement available on your own hardware. Hyperscale cloud is not always an option: data-residency rules, sovereignty mandates, latency, or disconnected sites can require AI to run where the data lives. The AI OS runs entirely on-premises — the same agents, ontology, and insights you would run in the cloud — keeping data, models, and prompts physically inside your perimeter. From Azure-consistent infrastructure with Azure Local through to fully disconnected, air-gapped networks, you choose how much of the cloud operating model to bring in-house without giving up control. ### FAQ ### What does running the platform on-premises mean? It means running the entire AI and data platform — models, agents, ontology, and analytics — on infrastructure you own and operate, inside your own datacentre or edge location, so data and models stay physically within your perimeter rather than in a public cloud region. ### Can I use confidential computing on-premises? Yes. On-premises deployments support confidential VMs on AMD SEV-SNP and Intel TDX, and confidential GPUs, so AI inference and training run with data and model weights encrypted in use — on your own hardware, inside your own datacentre. ### What is Azure Local and how does it fit? Azure Local (formerly Azure Stack HCI) is Azure-consistent infrastructure that runs in your own datacentre or edge location. Running the AI OS on Azure Local gives you a cloud-grade operating model while data stays in your perimeter, with confidential computing available on your own hardware. ### How is on-premises different from air-gapped? Air-gapped is the strictest form of on-premises: the platform runs on networks fully disconnected from the public internet. Other on-premises options, such as Azure Local, keep data in your perimeter while still allowing controlled connectivity for a cloud-consistent operating model. Both run the same AI OS. ### Do on-premises deployments lose any capabilities? No. You get the same AI OS, ontology, agents, and insights as a cloud deployment. Because the platform is model-agnostic and can serve open-weight models on your own hardware, frontier-grade AI works without depending on external services. --- ## Air-Gapped - Term: AI & Data on Air-Gapped - URL: https://scrydon.com/platform/sovereign-infra/air-gapped/ **Definition.** Air-gapped AI & data means running the entire platform — models, agents, ontology, and analytics — inside a network that is physically or logically isolated from the public internet. With no external API or cloud dependency, the most sensitive workloads run entirely within your own disconnected environment. Some data can never leave the building. For defence, intelligence, critical national infrastructure, and classified programmes, connectivity itself is the risk. Scrydon runs fully air-gapped: the same AI OS, ontology, and insights you would run in the cloud, operating on disconnected networks with no outbound connection required. ### FAQ ### What is air-gapped AI? Air-gapped AI runs the entire AI and data platform on a network isolated from the public internet. Models, agents, the ontology, and analytics all operate locally, with no external API or cloud dependency, so sensitive data never leaves your disconnected environment. ### Can the platform really run with no internet connection? Yes. The complete platform is designed to run fully offline on disconnected networks, with open-weight models served locally via vLLM and no outbound connection required — ideal for defence, intelligence, and critical national infrastructure. ### How are updates handled on an air-gapped network? Software and model updates are delivered through your own controlled, audited channels — for example approved removable media or a data diode — so the environment stays current without ever connecting to an external network. ### Do air-gapped deployments lose any capabilities? No. You get the same AI OS, ontology, agents, and insights as a connected deployment. Because the platform is model-agnostic and runs open-weight models on-premises, high-performance open models work without external services. ### Which organisations need air-gapped AI? Defence and intelligence agencies, classified programmes, and critical national infrastructure operators — anywhere data is too sensitive to expose to any outside network. --- ## Identity - Term: Sovereign Identity & Access - URL: https://scrydon.com/platform/sovereign-infra/identity/ **Definition.** Sovereign identity is the federated identity and access foundation of the AI OS: every human, AI agent, and workload is authenticated through your own identity provider and authorised per action under zero-trust policy, with complete, attributable audit trails — so AI agents act under the same governed identity model as people. Autonomous agents that act on real systems need identities just like people do. Sovereign identity gives every actor — human or AI — a verified identity, scoped permissions, and an audit trail, all anchored to your existing identity provider. Crucially, we federate authentication to your provider, but authorisation and enforcement stay with the platform inside your perimeter — federating identity never means surrendering control. ### FAQ ### What is sovereign identity? Sovereign identity is the federated identity and access foundation of the AI OS. Every human, AI agent, and workload is authenticated through your own identity provider and authorised per action under zero-trust policy, with complete, attributable audit trails. ### Which identity providers are supported? The platform integrates with your existing identity provider through standard protocols — SAML, OAuth 2.0, and OIDC — so access control stays unified with the rest of your organisation rather than siloed in a separate system. ### If identity is federated, who controls access? You do. We federate authentication to your existing identity provider, but the platform keeps control of authorisation: every access decision, policy, and enforcement point — for people and AI agents alike — stays within the platform and your perimeter. Federating identity never means surrendering control. ### How do AI agents get an identity? Each AI agent is issued its own scoped identity, so it can only access what it is explicitly authorised to and every action it takes is attributable. Agents are governed by the same identity and policy model as human users. ### Is every action audited? Yes. Every action by a user, workload, or agent is logged, attributable, and reviewable — providing the complete audit trail that regulated industries require. ### Does identity work in air-gapped deployments? Yes. The identity and zero-trust access model runs consistently from fully air-gapped on-premises environments through to hyperscale cloud, integrating with the identity providers available in your environment. --- ## AI Agent Identity - Term: AI Agent Identity & Authorization - URL: https://scrydon.com/platform/sovereign-infra/identity/agent-identity/ **Definition.** AI agent identity is the practice of issuing every autonomous AI agent its own distinct, verifiable identity — separate from any human user or shared service account — so its permissions can be scoped to least privilege, its calls to other agents and tools can be authenticated, and every action it takes is attributable to that identity and the authority under which it acted. A shared API key or service account cannot tell you which agent did what, or on whose behalf. As organisations move agents from pilot into production, that ambiguity becomes a liability: an unscoped credential that touches production systems is a standing risk, and an action nobody can attribute is not something you can audit or defend. On the AI OS, every agent — whether it runs one task or orchestrates a whole workflow — is issued its own identity, authorised per action under zero-trust policy, and authenticated when it calls other agents or tools. The result is agent autonomy your compliance team can actually sign off on: least privilege by default, and a full record of what happened, inside your perimeter. ### FAQ ### What is AI agent identity? AI agent identity is the practice of giving every autonomous AI agent its own distinct, verifiable identity — separate from human users and from any shared service account. It lets you scope an agent's permissions to least privilege, authenticate its calls to tools and other agents, and attribute every action it takes back to that identity. ### Why can't agents just share a service account? A shared service account collapses every agent behind it into one indistinguishable actor: permissions can't be scoped to a single agent's task, a log entry can't tell you which agent acted, and revoking access to contain one misbehaving agent takes down every other agent using the same credential. Distinct identities avoid all three problems. ### How are agent permissions scoped? Each agent identity carries least-privilege permissions granted per task and per tool, authorised under zero-trust policy at the point of action rather than as standing broad access. An agent can only reach the systems and data its specific job requires — not everything the platform is capable of touching. ### How does agent identity work with A2A and MCP? When an agent calls another agent over the Agent2Agent (A2A) protocol, or calls a tool over the Model Context Protocol (MCP), the call carries the calling agent's identity. That lets the receiving agent or tool authorise the request against a real, scoped identity — and lets the audit trail capture exactly which agent initiated which hop. ### Does agent identity help with EU AI Act compliance? Yes. Distinct, auditable agent identities give you the actor-level traceability that AI Act obligations expect — you can show which agent took which action, under what scope, and on whose authority. You can't produce that evidence if agents are indistinguishable behind a shared credential. ### Does this replace human identity and access management? No — it extends the same identity and zero-trust model that governs your people to your AI agents. Agent identities federate to your existing identity provider and are authorised by the same policy engine, so agents, workloads, and humans are governed consistently, inside your perimeter. --- ## Sovereign Cloud - Term: Sovereign Cloud - URL: https://scrydon.com/platform/sovereign-infra/cloud/ **Definition.** Sovereign cloud means running the AI OS on cloud infrastructure while keeping full control of your data, models, encryption keys, and jurisdiction. You choose the provider — a hyperscaler such as Microsoft Azure with sovereignty controls, or a fully sovereign national cloud such as Cloud Temple — and the platform runs identically on each, with confidential computing available so the cloud operator never sees your data in use. Sovereignty and cloud scale are not a trade-off. The AI OS runs on the cloud the same way it runs on-premises — the same agents, ontology, and insights — while your data, models, keys, and jurisdiction stay under your control. You pick where on the spectrum to sit: a hyperscaler like Azure that brings global capacity with EU data residency and customer-held keys, or a fully sovereign cloud like Cloud Temple, qualified SecNumCloud by France's ANSSI, whose criteria are designed to shield it from non-EU extraterritorial law. Either way, confidential computing keeps your workloads encrypted in use, and control never leaves you. ### FAQ ### What is a sovereign cloud? A sovereign cloud is cloud infrastructure run so that your data, models, encryption keys, and jurisdiction stay under your control rather than the provider's. The AI OS supports it across a spectrum — from hyperscalers such as Azure with sovereignty controls (EU data residency, customer-held keys, confidential computing) to fully sovereign national clouds such as Cloud Temple — so you keep cloud scale without surrendering control. ### Which cloud providers can I run the AI OS on? You choose. Microsoft Azure brings hyperscale capacity with EU data residency and confidential computing, while Cloud Temple is a French SecNumCloud-qualified sovereign cloud under French jurisdiction. The AI OS runs identically on each, so you can match the provider and jurisdiction to your sovereignty requirements. ### Does using the cloud mean giving up sovereignty? No. With data residency, customer-held keys, and confidential computing, your data and models stay under your control and encrypted in use, so the cloud operator cannot read them. For the highest assurance, a fully sovereign cloud such as Cloud Temple keeps everything under French jurisdiction, immune to extraterritorial law. ### What is confidential computing in the cloud? Confidential computing runs workloads inside hardware Trusted Execution Environments so data and models stay encrypted in memory while being processed — not only at rest and in transit. It means you can use cloud capacity, including hyperscale GPUs, while your data and models stay protected from the cloud platform itself. ### How is sovereign cloud different from on-premises? On-premises runs the platform inside your own datacentre or air-gapped sites; sovereign cloud runs it on a cloud provider while keeping data, models, keys, and jurisdiction under your control. Both run the same AI OS with the same zero-trust and confidential-computing controls, so you can place each workload where its sovereignty and scale needs are best met. --- ## AI on Azure - Term: Sovereign AI on Azure - URL: https://scrydon.com/platform/sovereign-infra/cloud/azure/ **Definition.** Sovereign AI on Azure means running the AI OS on Microsoft Azure as a cloud deployment target while keeping sovereignty controls in place: EU data residency aligned with the Microsoft EU Data Boundary, customer-held encryption keys (BYOK/HYOK), zero-trust access, and confidential computing available — so you reach hyperscale capacity while your data, models, and keys stay under your control. Azure brings global, hyperscale capacity and GPU availability that few sovereign clouds can match. Running the AI OS on Azure lets you use that scale while keeping sovereignty controls in place: choose EU regions for data residency, hold your own encryption keys, and enforce the same zero-trust perimeter the platform applies everywhere. For workloads that must stay encrypted even while in use, the AI OS runs on Azure confidential computing — covered in depth on the Confidential Compute on Azure page. ### FAQ ### What does running the AI OS on Azure mean? It means deploying the complete AI and data platform on Microsoft Azure as a cloud target, while keeping sovereignty controls in place: EU data residency, customer-held encryption keys (BYOK/HYOK), zero-trust access, and confidential computing available. You get hyperscale capacity and GPU availability without giving up control of your data, models, or jurisdiction. ### Can I keep data resident in the EU on Azure? Yes. You can deploy in EU regions and align with the Microsoft EU Data Boundary so that data stays resident where your rules require. Combined with customer-held keys and zero-trust access, this keeps your data under your control while using a global cloud. ### Who holds the encryption keys? You do. The AI OS supports customer-held keys (BYOK/HYOK) on Azure, so your data and models cannot be read without keys you control — even though the workload runs on Microsoft's infrastructure. ### How is this different from Confidential Compute on Azure? This page is about running the AI OS on Azure as a sovereign cloud deployment target — data residency, customer-held keys, and your perimeter. Confidential Compute on Azure goes deeper on keeping data encrypted while in use inside hardware Trusted Execution Environments. Use the two together: run on Azure with sovereignty controls, and add confidential computing where data must stay protected in use. ### Why run sovereign AI on a hyperscaler at all? Hyperscalers offer capacity and GPU availability that are hard to match elsewhere. With data residency, customer-held keys, and confidential computing, you can use that scale while keeping data and models under your control — and for the highest assurance, the AI OS also runs on fully sovereign clouds such as Cloud Temple and on-premises. --- ## Cloud Temple - Term: AI on Cloud Temple - URL: https://scrydon.com/platform/sovereign-infra/cloud/cloud-temple/ **Definition.** AI on Cloud Temple means deploying the AI OS on Cloud Temple, a French cloud provider whose cloud is qualified SecNumCloud by ANSSI — France's national cybersecurity agency. It is a fully sovereign, trusted cloud under French jurisdiction, designed to be immune to extraterritorial laws such as the US CLOUD Act, so your data, models, and keys stay within French and European control, with confidential computing available. For the highest level of cloud sovereignty, the AI OS runs on Cloud Temple, a French sovereign cloud. Cloud Temple's cloud is qualified SecNumCloud by ANSSI — France's national cybersecurity agency — the benchmark for trusted, sovereign cloud in France. It operates under French jurisdiction and is designed to be immune to extraterritorial laws such as the US CLOUD Act. Running the AI OS there gives you the same agents, ontology, and insights you would run anywhere else, while data, models, and keys stay within French and European control, with confidential computing for data-in-use protection. ### FAQ ### What is Cloud Temple? Cloud Temple is a French cloud provider whose cloud is qualified SecNumCloud by ANSSI — France's national cybersecurity agency. It is a fully sovereign, trusted cloud under French jurisdiction, designed to be immune to extraterritorial laws such as the US CLOUD Act. The AI OS runs on Cloud Temple as a supported sovereign-cloud deployment target. ### What is SecNumCloud? SecNumCloud is a qualification issued by ANSSI, France's national cybersecurity agency, for trusted, sovereign cloud services. It sets stringent security and sovereignty requirements and is widely regarded as the benchmark for sovereign cloud in France. Cloud Temple's cloud holds this qualification. ### Is Cloud Temple immune to the US CLOUD Act? Cloud Temple is a French sovereign cloud under French jurisdiction, designed to be immune to extraterritorial laws such as the US CLOUD Act. Keeping data, models, and keys within French and European control is precisely the sovereignty assurance SecNumCloud qualification is intended to provide. ### Can I use confidential computing on Cloud Temple? Yes. The AI OS supports confidential computing so workloads run encrypted in use inside hardware Trusted Execution Environments, protected even from the cloud operator. Combined with French jurisdiction and your own keys, this keeps your most sensitive data and models under sovereign control. ### How is Cloud Temple different from running on Azure? Azure is a hyperscaler that brings global capacity with sovereignty controls such as EU data residency and customer-held keys. Cloud Temple is a fully sovereign French cloud, qualified SecNumCloud, where jurisdiction itself is European and designed to be immune to extraterritorial law. Choose Azure for hyperscale capacity with sovereignty controls, or Cloud Temple for the highest tier of jurisdictional sovereignty. --- ## AI & Data on Azure Local - Term: AI & Data on Azure Local - URL: https://scrydon.com/platform/sovereign-infra/on-prem/azure-local/ **Definition.** AI & data on Azure Local means running AI and analytics workloads on Microsoft's Azure Local (formerly Azure Stack HCI) — Azure-consistent infrastructure deployed in your own datacentre or edge location — so data and models stay physically within your perimeter and under your control, with Trusted-launch VM integrity and boot attestation available on your own hardware. The AI OS can also serve models through Foundry Local on Azure Local, running on your own Arc-enabled cluster, in connected or fully disconnected mode. Hyperscale cloud is not always an option: data residency rules, sovereignty mandates, latency, or disconnected sites can require AI to run where the data lives. Azure Local brings Azure-consistent infrastructure into your own datacentre. Running the AI OS on Azure Local gives you the operational model of the cloud while data, models, and prompts stay physically inside your perimeter. ### FAQ ### How can I run AI and data on Azure Local? Deploy the AI OS onto Azure Local (formerly Azure Stack HCI): your AI and data workloads run on Azure-consistent infrastructure inside your own datacentre or edge site, so data, models, and prompts stay physically within your perimeter. You get a cloud-grade operating model with Trusted-launch VMs (Secure Boot, vTPM, VBS memory isolation) on hardware in your own datacentre, and you can connect to Foundry Local on Azure Local for in-cluster model inference in connected or fully disconnected mode. It is the same AI OS, ontology, agents, and analytics you would run in the cloud — just resident on your own hardware. ### What is Azure Local? Azure Local (formerly Azure Stack HCI) is Microsoft's Azure-consistent infrastructure that runs in your own datacentre or edge location rather than a public Azure region. It lets you operate Azure-aligned services and tooling on your own hardware, so data can stay physically within your perimeter. ### Can you run Foundry Local on Azure Local? Yes — the product for this is Foundry Local on Azure Local, which deploys as an Azure Arc extension onto an Arc-enabled Kubernetes cluster on your own hardware, inside your perimeter. Run it in connected mode (linked to Azure for management and updates) or fully disconnected mode (no outbound network at all, suitable for air-gapped sites). The AI OS orchestrates its models alongside your data, agents, and ontology. Note this is distinct from Foundry Local, which Microsoft scopes to inference on an end user's own device and does not design as a server inference stack. The Azure Local variant is currently in preview and enabled by request. See Microsoft's documentation for more detail. ### Do Microsoft Fabric, Databricks, and Azure AI Foundry run inside my datacentre? No. Microsoft Fabric and Azure AI Foundry are cloud services that process data in public Azure regions on standard, non-confidential compute, so your data leaves your perimeter and is decrypted in memory while in use. Azure Databricks can run classic compute clusters on confidential VMs, but only in a public Azure region in your own subscription — never in your datacentre — and its control plane runs in Databricks' account regardless. The AI OS is different: it runs the same class of analytics and AI workloads on Azure Local inside your own datacentre, on hardware you control, so data, models, and prompts stay physically within your perimeter. ### How is AI data kept secure on Azure Local? Azure Local VMs support Trusted launch — Secure Boot, a virtual TPM, VBS memory isolation, and boot-integrity attestation — and the hardware sits in your own datacentre, so AI inference and training run on infrastructure you physically control. Hardware Trusted Execution Environments (AMD SEV-SNP, Intel TDX confidential VMs) are an Azure public-region capability; on Azure Local the protection comes from your own perimeter plus Trusted-launch VM integrity. ### Is data protected from Microsoft and administrators on Azure Local? Yes — primarily because the hardware is in your own datacentre, under your own administrators, not Microsoft's. Trusted launch adds Secure Boot, a virtual TPM, VBS memory isolation, and boot-integrity attestation, and the VM guest state (including the vTPM) is protected by a key held in your own local key vault. Microsoft runs no infrastructure inside your datacentre, so the cloud-operator access question does not arise the way it does in a public region. Hardware Trusted Execution Environments that encrypt memory from the host (AMD SEV-SNP, Intel TDX confidential VMs) are an Azure public-region capability rather than an Azure Local one. ### How is Azure Local different from running in a public Azure region? Azure Local gives you Azure-consistent operations and tooling, but the infrastructure physically lives in your own datacentre or edge site rather than a Microsoft region. That keeps data resident and within your perimeter — important for sovereignty, data-residency rules, latency, and disconnected or edge locations — while you keep a cloud-grade operating model. ### Does the AI OS run the same way on Azure Local as in the cloud? Yes. The AI OS, its ontology, agents, and insights run consistently from fully air-gapped on-premises deployments, through Azure Local in your own datacentre, to hyperscale cloud. Sovereignty never depends on where you deploy — the same zero-trust controls apply everywhere. --- ## Confidential Compute on Azure - Term: AI on Confidential Compute on Azure - URL: https://scrydon.com/platform/sovereign-infra/confidential-compute/azure/ **Definition.** AI on confidential compute on Azure means running AI workloads inside hardware-based Trusted Execution Environments — Azure confidential VMs and GPUs built on AMD SEV-SNP and Intel TDX — so data and models stay encrypted in memory during processing, shielded even from Microsoft and privileged administrators, with remote attestation proving the environment's integrity. Cloud encryption usually protects data at rest and in transit but leaves it exposed in memory while it is being used. Sovereign confidential computing closes that gap. Running the AI OS on Azure's confidential VMs and GPUs lets you reach hyperscale capacity for AI without surrendering confidentiality of your most sensitive data and models. ### FAQ ### How can I run AI and data on Azure Confidential Compute? Deploy the AI OS onto Azure confidential computing: your AI and data workloads run inside hardware Trusted Execution Environments — confidential VMs and GPUs on AMD SEV-SNP and Intel TDX — so data, models, and prompts stay encrypted in memory while being processed. Remote attestation verifies the environment before any key, secret, or model is released, and you hold the keys, so neither Microsoft nor administrators can read your data in use. In practice you get hyperscale AI and analytics on Azure while keeping the same encrypted-in-use, sovereign posture the AI OS applies everywhere. ### Do Microsoft Fabric, Databricks, and Azure AI Foundry run on confidential compute? Not end to end. Microsoft Fabric and Azure AI Foundry process data in standard, non-confidential compute, so your data is decrypted in memory and exposed to the cloud operator while in use. Azure Databricks is a partial exception: since November 2023 it can run classic compute clusters on AMD SEV-SNP confidential VMs, so worker nodes keep data encrypted in memory. That option covers the compute plane in your own subscription only — the Databricks control plane runs in Databricks' account on standard compute, and serverless compute runs there too, so no configuration makes the whole path confidential. The AI OS is different: it runs the same class of analytics and AI workloads on Azure confidential VMs and GPUs end to end, keeping data, models, and prompts encrypted in use and out of reach of Microsoft and privileged administrators. ### What is confidential computing on Azure? Confidential computing on Azure runs workloads inside hardware Trusted Execution Environments — confidential VMs on AMD SEV-SNP and Intel TDX, plus confidential GPUs — so data stays encrypted in memory during processing and is protected even from Microsoft and privileged administrators. ### Can AI workloads use confidential GPUs on Azure? Yes. Azure offers confidential GPU VMs that extend the hardware trust boundary to the accelerator, so AI inference and training run with model weights and data protected in use — not only on the CPU. ### Is data protected from Microsoft and cloud administrators? Yes. With confidential computing, memory is encrypted by the CPU/GPU hardware and keys are controlled by you. Cloud operators and infrastructure administrators cannot read the data or models while they are being processed. ### What is remote attestation? Remote attestation is cryptographic proof that a workload is running in a genuine, unmodified Trusted Execution Environment. The AI OS uses it to ensure secrets, keys, and models are only released to an environment whose integrity has been verified. ### Why run sovereign AI on a hyperscaler at all? Confidential computing lets you use hyperscale capacity and GPU availability while keeping data and models cryptographically protected from the cloud platform — combining cloud scale with the confidentiality regulated and sovereignty-conscious organisations require. --- ## Analytics - Term: Analytics - URL: https://scrydon.com/platform/analytics/ **Definition.** Scrydon Analytics is the self-service analytics layer that lets business users and analysts get answers without waiting on a data team. They ask questions in plain language, explore governed dashboards and reports, and receive the right information proactively — without asking. Because every metric is anchored to the ontology, the answers are consistent and trustworthy across the whole organisation. In most organisations there is a bottleneck between people and their data: every question becomes a ticket, every report a wait. Scrydon Analytics removes that bottleneck. It puts trustworthy, self-service analytics directly in the hands of the people who make decisions — in natural language, in dashboards and reports they can explore themselves, and in proactive alerts pushed to them the moment something matters. Because everything is anchored to the ontology, what they see is governed, consistent, and dependable, whether they are technical or not. ### FAQ ### What is Scrydon Analytics? Scrydon Analytics is the self-service analytics layer of the platform. It lets business users and analysts get answers without waiting on a data team — by asking questions in plain language, exploring governed dashboards and reports, and receiving the right information proactively. Every metric is anchored to the ontology, so answers are consistent and trustworthy across the organisation. ### What can end users actually do with Analytics? They can ask questions in natural language and get sourced answers, build and explore self-service dashboards and reports, drill into the detail, receive proactive alerts when something changes, and export or share their findings — all without raising a ticket or writing code. ### Do I need to be technical to use Analytics? No. Analytics is built for business users and decision-makers, not just data engineers. You can ask questions in plain language and explore dashboards and reports without SQL or any technical skill, while the ontology keeps the underlying metrics governed and consistent. ### Where does the data come from? Analytics sits on top of the ontology based data platform and the lakehouse beneath it. Because every metric is defined once in the ontology and continuously refreshed from the lakehouse, the answers you see are current, governed, and reconcile across every report and dashboard. ### Can I ask questions in natural language? Yes. Through Cortex, Scrydon's conversational layer, you can ask questions the way you would to a colleague and get clear answers grounded in your business data — no query language required. --- ## Ontology Based Data Platform - Term: Ontology Based Data Platform - URL: https://scrydon.com/platform/analytics/ontology-based-data-platform/ **Definition.** An ontology based data platform is a semantic data platform that unifies an organisation's data into a living, queryable semantic model — a graph of entities, relationships, and rules layered over your existing data. Instead of disconnected tables and siloed systems, every analyst, dashboard, report, and AI agent works from one consistent, business-level source of truth, making data discoverable, trustworthy, and ready for both insight and AI. Most organisations have data they can't use — not because it doesn't exist, but because nothing connects it. Scrydon's sovereign ontology based data platform is the connective semantic layer: it models your real-world entities and the typed relationships between them, applies consistent definitions and governance, and keeps everything current as new data lands. The result is faster analytics, self-service insight, and metrics that mean the same thing everywhere — and a semantic foundation that grounds AI agents in your real business meaning, the essence of ontology AI. ### FAQ ### What is an ontology based data platform? An ontology based data platform unifies an organisation's data into a living, queryable semantic model — a graph of entities, relationships, and rules. It is the single source of truth that lets every analyst, dashboard, report, and application work from consistent, business-level meaning instead of disconnected tables. ### Is an ontology based data platform the same as a semantic data platform? Yes — an ontology based data platform is a semantic data platform. Both describe a system that layers a semantic model (entities, relationships, and shared definitions) over your raw data, so every analyst, dashboard, and AI agent works from consistent business meaning instead of disconnected tables. Scrydon's is sovereign and runs from air-gapped on-premises to cloud. ### What is ontology AI and how does an ontology improve AI? Ontology AI means grounding AI agents in an ontology — a governed semantic model — rather than raw tables. The ontology gives agents the same entities, relationships, and metric definitions your analysts use, so they retrieve the right data, answer in business terms, and stay auditable. Because every answer traces back to a defined concept, ontology AI sharply reduces hallucination and keeps AI reasoning explainable and consistent with your reporting. ### How is an ontology based data platform different from a data lake or data warehouse? A data lake or warehouse stores and queries data; it does not capture what the data means or how concepts relate. An ontology based data platform adds a semantic layer on top — modelling entities, relationships, and shared metric definitions — so analytics and reporting run on connected business meaning instead of raw, siloed tables. ### How does an ontology based data platform compare to Databricks, Microsoft Fabric, and Palantir Foundry? Databricks is a lakehouse focused on data engineering and ML; Microsoft Fabric is a cloud SaaS suite focused on BI through Power BI; Palantir Foundry is the closest, with a strong built-in ontology, but it is proprietary, high lock-in, and a US vendor. Scrydon's ontology based data platform pairs a first-class business ontology and consistent insight with European data sovereignty and air-gapped-to-cloud deployment. ### How does an ontology based data platform improve analytics and reporting? Because every metric and relationship is defined once in the ontology, dashboards and reports reconcile, analysts answer questions without re-joining raw tables, and business users get trustworthy self-service insight — turning weeks of data wrangling into minutes. ### How does an ontology based data platform relate to master data management (MDM)? Master data management (MDM) creates one authoritative version of key business entities — customers, products, suppliers — across systems. An ontology based data platform delivers that and more: the ontology models those entities and their typed relationships as a living single source of truth, continuously refreshed from the lakehouse and shared by analysts, dashboards, and AI agents alike. The result is AI MDM — master data that not only reconciles your reporting but also grounds AI in governed, consistent business meaning. ### How does an ontology based data platform stay up to date? It is continuously refreshed: data pipelines pull new data from the lakehouse into the relevant ontology entities, keeping the semantic model current without manual effort, so every report and dashboard always reflects the latest state of the business. --- ## Enterprise Knowledge Graph - Term: Enterprise Knowledge Graph - URL: https://scrydon.com/platform/analytics/enterprise-knowledge-graph/ **Definition.** An enterprise knowledge graph is a governed, queryable network of an organisation's entities — customers, products, assets, contracts — and the typed relationships between them, layered over existing systems and data. It turns disconnected tables and documents into one connected model of business meaning, so analysts, applications, and AI agents can traverse relationships, answer multi-hop questions, and reason on a shared single source of truth. Most organisations hold the facts they need but cannot connect them: a customer in one system, the contract in another, the support history in a third. An enterprise knowledge graph is the connective layer that links them — modelling real-world entities and the typed relationships between them over your existing data, and keeping it current as new data lands. Built on Scrydon's sovereign ontology, the knowledge graph gives both people and AI agents one explainable model to traverse: every metric defined once, every relationship navigable, and every answer traceable back to its source — entirely inside your perimeter. It is the substrate behind ontology AI, grounded enterprise RAG, and trustworthy multi-agent reasoning. ### FAQ ### What is an enterprise knowledge graph? An enterprise knowledge graph is a governed, queryable network of an organisation's entities — customers, products, assets, contracts — and the typed relationships between them, layered over existing data. It turns disconnected tables and documents into one connected model of business meaning that analysts, applications, and AI agents can traverse and reason on as a single source of truth. ### How is a knowledge graph different from a relational database? A relational database stores rows in tables and joins them on demand; relationships are implicit and expensive to traverse. A knowledge graph makes relationships first-class and navigable, so multi-hop questions — "which contracts touch this supplier through these products" — are a traversal, not a pile of joins. It adds a semantic layer of shared meaning over your data rather than replacing your systems. ### How does an enterprise knowledge graph relate to an ontology? The ontology is the schema — the definitions of entity types, relationship types, and rules. The knowledge graph is the populated, living instance of that ontology: the actual entities and relationships filled in from your data. Scrydon's Ontology Based Data Platform provides the ontology; the enterprise knowledge graph is the connected model it produces. ### What is knowledge graph RAG (GraphRAG)? Knowledge graph RAG — sometimes called GraphRAG — grounds retrieval-augmented generation in a knowledge graph rather than a flat vector store. Instead of fetching similar text chunks, the agent retrieves connected entities and relationships, so it can reason across multiple hops and cite the exact nodes behind every answer. It is what makes enterprise RAG accurate and explainable. ### How does a knowledge graph reduce AI hallucination? Because agents reason over defined entities and relationships with provenance, every answer traces back to a real node and its source data. Grounding in connected business meaning — instead of generic model memory or loose text — is what sharply reduces hallucination and keeps AI answers checkable. ### Is the enterprise knowledge graph sovereign and secure? Yes. The knowledge graph is built and queried inside your own perimeter — from air-gapped on-premises to cloud — with consistent definitions, full lineage, and access control scoped per identity. Your connected business meaning never leaves your control. --- ## Semantic Layer - Term: Semantic Layer - URL: https://scrydon.com/platform/analytics/semantic-layer/ **Definition.** A semantic layer is a governed layer of business meaning — metrics, dimensions, and entity definitions — placed on top of raw and lakehouse data, so every tool and person that queries it gets the same answer. Scrydon's semantic layer is grounded in the ontology rather than a standalone metrics config, so definitions stay consistent as the underlying graph of entities and relationships evolves. Ask three analysts what "active customer" means and you'll often get three different SQL queries — and three different numbers. A semantic layer closes that gap by defining metrics, dimensions, and entities once, centrally, so every dashboard, report, and query inherits the same definition instead of re-deriving it. Scrydon's semantic layer isn't a standalone YAML metrics file bolted onto the warehouse: it is grounded in the ontology, so a metric like "revenue" is defined in terms of the same entities and relationships your knowledge graph and AI agents already reason over — and it evolves with the graph rather than drifting out of sync with it. ### FAQ ### What is a semantic layer? A semantic layer is a governed layer of business meaning — metrics, dimensions, and entity definitions — placed on top of raw and lakehouse data. It lets BI tools, analysts, and applications query "revenue" or "active customer" once, consistently, instead of each team writing its own SQL and getting a different number. ### What is the difference between a semantic layer and an ontology? A semantic layer typically covers metrics, dimensions, and entity definitions — enough to make BI consistent. An ontology is broader: it includes the semantic layer plus the full graph of relationships between entities and the business rules that govern them. Put simply, Scrydon's ontology is a semantic layer plus relationships and rules — the semantic layer is what you query for consistent metrics; the ontology is the connected model underneath it. ### How is this different from dbt or Cube-style metrics layers? Tools like dbt Semantic Layer or Cube define metrics in a standalone YAML config that sits beside the warehouse and has to be maintained separately as the business changes. Scrydon's semantic layer is grounded in the ontology instead — metrics are defined against the same entities and relationships your knowledge graph already models, so definitions stay consistent as the graph evolves rather than drifting out of sync with it. ### Does a semantic layer replace my BI tool? No. A semantic layer sits between your data and the tools that query it — BI dashboards, notebooks, applications, and AI agents all connect to it rather than to raw tables. Your BI tool still renders the charts; the semantic layer guarantees the numbers behind them are correct and consistent everywhere. ### How does a semantic layer reduce metric drift? Metric drift happens when different teams independently derive the same figure — "revenue," "active customer" — with slightly different logic, so numbers disagree across reports. A semantic layer removes the re-derivation: the metric is defined once, centrally, and every dashboard, query, and AI agent inherits that single definition instead of writing its own. ### Why does the semantic layer matter for AI agents specifically? AI agents that compute figures directly from raw tables will happily produce a number that disagrees with your dashboards — with no way to tell why. When agents query the semantic layer instead, they use the same governed metric definitions as the rest of the business, so their answers are consistent, explainable, and traceable back to a defined figure rather than an improvised query. --- ## AI-Ready Data - Term: AI-Ready Data - URL: https://scrydon.com/platform/analytics/ai-ready-data/ **Definition.** AI-ready data is data that AI agents and retrieval systems can trust and act on without manual cleanup: entities defined once against a shared ontology, relationships made explicit, lineage and provenance tracked back to source, access governed per identity, and freshness maintained continuously rather than refreshed on a batch schedule. It is a governance and modelling standard, not a storage location. Being AI-ready is not the same as being present in a lakehouse. Most enterprise data is stored but not defined: the same customer exists under three different spellings, a "revenue" figure means five different things depending on the report, and nobody can say where a number came from six months later. Scrydon makes data AI-ready by grounding it in a governed ontology — entities defined once, relationships modelled explicitly, lineage tracked automatically, and access enforced per identity — then keeping it current as new data lands, inside your perimeter. That governed, connected, current data is what enterprise RAG and agentic AI actually retrieve and act on. ### FAQ ### What does 'AI-ready data' actually mean? It means data an AI agent or retrieval system can trust and act on without manual cleanup: entities defined once against a shared ontology, relationships made explicit, lineage tracked to source, access governed per identity, and kept current rather than refreshed on a batch schedule. It's a governance and modelling standard, not a place data is stored. ### Isn't data already AI-ready once it's in a lakehouse? No — a lakehouse gives you a place to store structured, unstructured, and vector data together, but presence isn't readiness. Data in a lakehouse can still have three spellings of the same customer, five definitions of "revenue," and no lineage. AI readiness requires the ontology layer on top: definitions, relationships, lineage, and governance. ### Why do AI pilots stall even when the model works fine? Most stalled pilots trace back to data, not models: retrieval surfaces duplicates or stale figures, nobody can explain where an answer came from, and compliance won't approve giving an agent real access without lineage and access control. Fixing the data foundation, not swapping models, is usually what unblocks production. ### How does Scrydon make data AI-ready? Scrydon maps raw tables and documents onto ontology-defined entities and relationships, stores everything — structured, unstructured, and vector — in one sovereign lakehouse, tracks lineage automatically, enforces access per identity, and keeps the whole model current as source systems change. ### How does AI-ready data relate to enterprise RAG and agentic AI? AI-ready data is the prerequisite layer beneath both. Enterprise RAG retrieves defined, connected, provenance-tracked data instead of loose text chunks; agentic AI acts on data it can verify and that's governed enough to be trusted with real permissions. Neither works reliably on data that is merely present rather than AI-ready. ### Is AI-ready data sovereign and secure? Yes. Modelling, lineage, and governance run entirely inside your own perimeter — from air-gapped on-premises to sovereign cloud — with access scoped per identity. Making data AI-ready never means sending it outside your control. --- ## Data Fusion - Term: Data Fusion - URL: https://scrydon.com/platform/analytics/data-fusion/ **Definition.** Data fusion is the real-time combination of multiple, heterogeneous data sources — sensor feeds, telemetry, documents, transactions — into a single, coherent, ontology-grounded picture, so agents and analysts reason over one consistent view instead of reconciling separate streams themselves. Most environments don't produce one tidy data stream — a mission produces SIGINT, GEOINT and OSINT; a trading desk produces market feeds, ledgers and behavioural signals; a grid produces SCADA telemetry and weather data. Treated separately, each source is a partial, sometimes contradictory view. Scrydon fuses them against a shared ontology, so every entity — a unit, a customer, an asset — means the same thing across every source, and the fused picture updates continuously rather than on a batch cycle. That grounded, current picture is what agentic AI reasons over and acts on. ### FAQ ### What is data fusion, and how is it different from just storing data together? Data fusion is the real-time combination of multiple sources — sensor feeds, documents, telemetry, transactions — into one coherent, [ontology](/platform/analytics/ontology-based-data-platform)-grounded picture where every entity means the same thing across sources. Storing data together in a [lakehouse](/platform/analytics/lakehouse) doesn't fuse it; fusion requires resolving entities, correlating streams continuously, and tracking provenance so the combined picture can be trusted and acted on. ### Can data fusion run in real time, not just on a batch schedule? Yes. Sources are correlated against the live picture as they arrive, so a new sensor reading, transaction or document updates the fused view immediately rather than waiting for a nightly batch job. This is what lets [agentic AI](/platform/ai-os/agentic-ai) and analysts act on the current state of an operation instead of a stale snapshot. ### How do you keep a fused picture explainable rather than a black-box output? Every fused data point keeps a lineage trail back to its originating source and timestamp, and the fusion itself runs against a governed [ontology](/platform/analytics/ontology-based-data-platform) rather than a statistical black box. That means any conclusion drawn from the fused picture can be traced back to the specific sources that produced it. ### What kinds of sources can be fused — is this only for sensor data? No. The same approach fuses sensor and telemetry feeds with documents, transaction records, and other structured or unstructured sources, as long as each can be mapped onto ontology-defined entities. [Defence sensor fusion](/industry/defence), financial transaction analysis, and OT/grid telemetry are all instances of the same underlying capability. ### Does data fusion require sending data outside our environment? No. Fusion runs entirely inside your own perimeter, on the same sovereign lakehouse and ontology used for every other workload — from fully [air-gapped, on-premises](/platform/sovereign-infra/air-gapped) deployments to [sovereign cloud](/platform/sovereign-infra/cloud). Combining sources never requires routing them through an external service. ### How does data fusion relate to enterprise RAG and agentic AI? Data fusion is what gives [agentic AI](/platform/ai-os/agentic-ai) and [enterprise RAG](/platform/ai-os/rag) one coherent picture to reason over instead of several partial, disconnected ones. An agent correlating a threat, a fraud pattern or a grid anomaly is really querying the fused, ontology-grounded picture — which is only reliable because the underlying fusion is continuous, resolved to real entities, and traceable. --- ## Notebooks - Term: Sovereign Notebooks - URL: https://scrydon.com/platform/analytics/notebooks/ **Definition.** Notebooks are interactive Python environments running inside the platform on per-session isolated compute, reading governed, ontology-grounded data through the same permissions as every other workload, with reproducible dependencies and no persistent runtime to compromise. Every organisation that takes analytics seriously ends up with notebooks, and every security team ends up uneasy about them: a shared Jupyter server that accumulates credentials, or worse, a copy of the data on someone's laptop. Scrydon's notebooks close both gaps. Each session gets its own isolated compute with a declared CPU, memory and storage envelope; the runtime is platform-managed and read-only; data is reached through the ontology and the same access policy the rest of the platform enforces; and when the session ends the environment is destroyed. Notebooks are reactive rather than run-the-cells-in-order, so a changed value updates everything that depends on it — which is what makes a notebook something you can hand to a colleague and trust. ### FAQ ### What is a sovereign notebook? A notebook environment that runs entirely inside your own perimeter — on your cluster, under your identity provider and your policies — rather than on a vendor's hosted service. Code and data never leave the environment you control, and the same notebook works on a [sovereign cloud](/platform/sovereign-infra/cloud), on-premises or on an [air-gapped](/platform/sovereign-infra/air-gapped) network. ### How is each notebook isolated? Every session starts its own microVM with a declared CPU, memory and temporary-storage envelope, and that environment is destroyed when the session ends. There is no shared kernel between users and no persistent runtime that accumulates credentials or state — the same isolation model the platform applies to [AI agents running code](/platform/ai-os/agentic-ai/ai-sandbox). ### Can notebooks reach any data in the lakehouse? Only what the person running them is already permitted to see. Notebooks read through the [ontology](/platform/analytics/ontology-based-data-platform) under the user's own identity, so [data governance](/platform/analytics/data-governance) policies, logging and data-loss-prevention apply exactly as they do to dashboards, applications and agents. A notebook is not a back door. ### Are results reproducible? Yes. Dependencies are declared with the notebook and the environment is rebuilt from that declaration each session, so the notebook behaves the same for the next person who opens it. Notebooks are also reactive: changing a value re-runs everything that depends on it, which removes the classic "cells were run out of order" class of wrong answers. ### Can a notebook become a production pipeline? That is the intended path. Exploration that proves something can be promoted to a scheduled pipeline on the same [lakehouse](/platform/analytics/lakehouse) rather than being rewritten by a different team in a different language, which is where most of the distance between "we showed it works" and "it runs every night" usually goes. ### Do notebooks work when the network is disconnected? Yes. Dependencies are served from within the perimeter, so a notebook starts and runs with no internet egress — the same constraint the rest of the platform is built for. See [air-gapped AI](/platform/sovereign-infra/air-gapped) for what changes when there is no network at all. ### How does this relate to Cortex? [Cortex](/platform/cortex) is the conversational way in — ask a question in natural language and get an answer grounded in the ontology. Notebooks are the code way in, for when you need to do something a conversation cannot express. Both read the same governed data through the same permissions. --- ## Data Governance - Term: Data Governance - URL: https://scrydon.com/platform/analytics/data-governance/ **Definition.** Data governance is the discipline of cataloging, classifying, tracing, and controlling access to an organisation's data so it can be trusted and safely used. On Scrydon's ontology based data platform, governance is native: because every entity and field is defined once with an owner, a sensitivity classification, and full lineage, the catalog, the lineage graph, and access controls exist by construction rather than as a bolt-on layer. Most data governance programmes arrive after the fact: a catalog tool scans warehouse tables, a lineage tool reverse-engineers pipeline metadata, and access rules are patched onto each application separately — three disconnected systems describing data they don't actually own. Scrydon takes a different route. Because every entity and field is modelled once in the ontology, with an owner, a sensitivity classification, and a source, the catalog and lineage graph are a direct consequence of how the data is structured, not an external index that drifts out of date. Access control is enforced at the same layer, so the same permissions and classifications that govern a dashboard also govern what an AI agent may retrieve — inside your perimeter, auditable end to end. ### FAQ ### What is data governance on the Scrydon platform? Data governance is the combination of cataloging, classification, lineage, and access control that makes an organisation's data trustworthy and safe to use. On Scrydon's ontology based data platform these aren't separate tools: because every entity and field is defined once with an owner, sensitivity label, and provenance, governance is a property of the data model itself, not a layer applied afterward. ### What is a data catalog, and do I need a separate tool for it? A data catalog is a searchable inventory of an organisation's data — what it is, who owns it, and what it means. Because Scrydon's ontology defines every entity and field once, with an owner and description attached at modelling time, the catalog is a live view of the ontology rather than a separate tool that has to be kept in sync with tables it doesn't control. ### What is data lineage, and how is it tracked? Data lineage is the traceable path a piece of data takes from its source system, through every transformation, to the reports, dashboards, and AI answers that use it. Lineage is captured automatically as data flows into the ontology, so you can trace any figure back to its origin without reverse-engineering pipeline metadata after the fact. ### How does the ontology make governance 'free'? Most governance programmes bolt a catalog, a lineage tool, and access rules onto data after it is already scattered across disconnected tables. Because Scrydon models every entity and field once — with an owner, sensitivity classification, and lineage captured as part of the ontology — the catalog, lineage graph, and access controls fall out of the model by construction, instead of requiring a separate system to describe data it doesn't own. ### How is data governance different from AI governance? Data governance governs the data itself — what exists, who owns it, where it came from, and who may access it. AI governance governs how AI agents and models act on that data — policy enforcement, guardrails, and human oversight at runtime. Data governance is the foundation: an agent can only be as governed as the data it reasons over. ### Is data governance sovereign and auditable? Yes. The catalog, lineage graph, and access control run inside your own perimeter — from air-gapped on-premises to cloud — and every access is captured in an immutable, queryable audit trail, so the evidence of governance never leaves your control either. --- ## Lakehouse - Term: Lakehouse - URL: https://scrydon.com/platform/analytics/lakehouse/ **Definition.** The Lakehouse is the high-performance data foundation of the platform. It merges the flexibility of a data lake with the speed of a data warehouse, unifying structured tables, unstructured AI knowledge, and vector embeddings in one sovereign store — so analytics and AI run on the same data without duplication. Built on StarRocks over open table formats such as Apache Iceberg, this sovereign data platform keeps your data yours: no proprietary lock-in, no copying data between a lake and a warehouse. StarRocks' vectorised MPP engine delivers sub-second, high-concurrency SQL — powering everything from dashboards to agent reasoning — and integrated vector search makes the same store instantly ready for AI workloads, all underpinning the Cognitive Enterprise. ### FAQ ### What is a lakehouse? A lakehouse is a data architecture that merges the flexibility of a data lake with the performance of a data warehouse. Scrydon's Lakehouse unifies structured tables, unstructured knowledge, and vector embeddings in one sovereign store, so analytics and AI run on the same data without duplication. ### What is it built on? The Lakehouse is built on StarRocks — a vectorised MPP engine delivering sub-second, high-concurrency SQL — over open table formats such as Apache Iceberg, so your data stays portable and free of proprietary lock-in. ### Does it support AI and vector search? Yes. Vector embeddings are stored and queried alongside traditional data, so the same store is immediately ready for retrieval, agent reasoning, and other AI workloads — no separate vector database required. ### How does the Lakehouse relate to the Cognitive Enterprise? The Lakehouse is the data foundation beneath the Cognitive Enterprise: it holds the raw, multi-modal data that the ontology gives meaning to, and continuously feeds fresh data into the model. --- ## Data Spaces - Term: Data Spaces - URL: https://scrydon.com/platform/analytics/data-spaces/ **Definition.** Data Spaces are governed, federated environments for sharing and exchanging data across organisational boundaries without surrendering ownership or control. Built on the principles of European data-sharing initiatives such as Gaia-X, they let organisations discover, contract for, and use each other's data products through policy-as-code agreements — so data is collaborated on in place, never centralised or copied out of your perimeter. Most data collaboration still means copying data out of one organisation and into another — losing control of it the moment it leaves. Sovereign Data Spaces invert that model: data stays with its owner, and access is granted through governed, self-enforcing agreements. Partners, suppliers, agencies, and allies can build on shared data products without anyone giving up sovereignty — true federated collaboration with provenance and compliance built in. ### FAQ ### What is a data space? A data space is a governed, federated environment for sharing and exchanging data across organisational boundaries without surrendering ownership or control. Participants expose compliant data products that others can discover and use in place, through policy-as-code agreements — so data is collaborated on rather than copied out of each owner's perimeter. ### How is a data space different from sharing files or a central data lake? Copying files or centralising data into a shared lake means losing control of it the moment it leaves your perimeter. A data space keeps data with its owner: access is granted through governed, self-enforcing contracts, and partners collaborate on insights and data products in place — no replication, no loss of sovereignty. ### Are Scrydon Data Spaces aligned with Gaia-X? Yes. Scrydon's Data Spaces follow the principles of European data-sharing initiatives such as Gaia-X — federated, sovereign, and interoperable — so organisations can share data across boundaries while keeping ownership, residency, and compliance under their own control. ### What are smart data contracts? Smart data contracts are sharing agreements expressed as policy-as-code. Instead of relying on manual review, every agreement enforces its own compliance, access, and usage rules automatically — so governance is built into the architecture of each data-sharing relationship rather than bolted on after the fact. ### Can data be shared without copying it? Yes. Data Spaces are built for federated sharing: data products are exposed and used in place rather than replicated or centralised. Partners collaborate on the insights and outputs without raw data ever leaving its owner's perimeter, with full lineage and provenance throughout. --- ## Cortex - Term: Cortex - URL: https://scrydon.com/platform/cortex/ **Definition.** Cortex is Scrydon's sovereign conversational intelligence platform: a natural-language interface to the AI OS. Speak to your data, build and trigger workflows, create analytical notebooks, and interrogate your ontology in plain language — grounded in your enterprise data rather than generic model knowledge. Most people can't get answers from their data without going through a technical team. Cortex removes that barrier. It understands your enterprise knowledge graph, so questions get precise, context-aware answers; and because it sits on top of the AI OS, a request in plain language can build a workflow, run analysis, or trigger a process — with every conversation logged and attributable. ### FAQ ### What is Cortex? Cortex is Scrydon's conversational intelligence platform — a natural-language interface to the AI OS. You can chat with your data, build and trigger workflows, create analytical notebooks, and interrogate your ontology, all in plain language. ### Can I chat with my lakehouse and data? Yes. Cortex lets you ask questions in plain language and returns answers grounded in your actual enterprise data and ontology, rather than generic model knowledge — so responses are accurate and explainable. ### Can Cortex build workflows and create notebooks? Yes. Describe what you want and Cortex routes the request to the right AI OS workflows, and it can generate analytical notebooks (Python and SQL) over your lakehouse straight from a prompt. ### Is Cortex grounded in our data or just an LLM? Cortex is ontology-aware: it understands the structure of your enterprise knowledge graph and grounds responses in your real data, so answers are precise and context-sensitive rather than generic. ### Is every conversation audited? Yes. Every Cortex conversation is logged, attributable, and reviewable — meeting the compliance requirements of regulated industries. --- ## Cognitive Enterprise - Term: Cognitive Enterprise - URL: https://scrydon.com/platform/cognitive-enterprise/ **Definition.** The Cognitive Enterprise is the layer that links an organisation's ontology, knowledge bases, and data lakes into a single connected model — the grounding foundation for enterprise AI. It turns disconnected stores into one queryable source of truth, so AI agents, analysts, and workflows all reason on the same, consistent understanding of the business rather than on raw tables or ungrounded models. Meaning, knowledge, and raw data usually live apart: the ontology defines what things are and how they relate, knowledge bases hold curated, retrievable expertise, and data lakes store the raw multi-modal data. Scrydon's sovereign Cognitive Enterprise links all three, so a question can traverse from a business concept, to the documents that describe it, to the underlying data — without anyone stitching it together by hand. This is what makes enterprise AI trustworthy: agents grounded in your ontology — ontology AI — instead of guessing from disconnected fragments. ### FAQ ### What is a Cognitive Enterprise? The Cognitive Enterprise is the layer that links an organisation's ontology, knowledge bases, and data lakes into one connected, queryable model — turning disconnected stores into a single source of truth that AI agents, analysts, and workflows can all reason on. ### How does it link ontology, knowledge bases, and data lakes? The ontology provides meaning (entities, relationships, rules); knowledge bases hold curated, retrievable expertise anchored to those entities; and the data lake holds the raw multi-modal data. The Cognitive Enterprise connects them, so a query can move from a concept to the documents and data behind it. ### How is this different from a data lake? A data lake stores raw data but doesn't capture what it means or how it connects. The Cognitive Enterprise adds the ontology and knowledge layer on top and links them to the lake, so data becomes connected, meaningful, and queryable as a whole. ### How does it relate to the Ontology Based Data Platform? The ontology is the meaning layer at the heart of the Cognitive Enterprise. The Ontology Based Data Platform focuses on that semantic model; the Cognitive Enterprise is the broader layer that links the ontology together with knowledge bases and data lakes. ### Why does AI need a Cognitive Enterprise? Without it, AI reasons on fragments — raw tables, isolated documents, or ungrounded models. Linking ontology, knowledge, and data gives agents one consistent, traceable model of the business, which is what makes their answers and actions accurate and explainable. ### Why does enterprise AI need grounding? Enterprise AI acts on how a business actually runs — automating processes, supporting decisions, and acting on business data — so its answers must be accurate, auditable, and explainable. Agents are only as reliable as the meaning and data they reason over: that is the grounding problem. The Cognitive Enterprise solves it by giving every agent one connected model of ontology, knowledge, and data, so enterprise AI reasons on the same truth as your analysts rather than on scattered fragments. ### How does the Cognitive Enterprise enable enterprise AI? It is the grounding layer for enterprise AI: instead of agents reasoning over raw tables and loose documents, they reason over one connected model of meaning, knowledge, and data. That makes enterprise-wide AI accurate, explainable, and governed — agents retrieve the right facts, answer in business terms, and every answer traces back to a defined concept and its source. ### What is ontology AI, and how does it relate to the Cognitive Enterprise? Ontology AI means grounding AI in your ontology — a governed semantic model — rather than raw data, so agents share the same entities, relationships, and definitions your analysts use and stay auditable with far less hallucination. The Cognitive Enterprise is ontology AI at organisation scale: it links that ontology together with knowledge bases and data lakes into the single grounded model agents reason on. The Ontology Based Data Platform focuses on the ontology itself; the Cognitive Enterprise is the broader layer that connects it to knowledge and data. ### How is the Cognitive Enterprise different from RAG (retrieval-augmented generation)? RAG retrieves text chunks by similarity from a vector store to ground a language model's answer. The Cognitive Enterprise goes further: it grounds AI in a connected, governed model of meaning, knowledge, and data — the ontology plus knowledge bases plus data lakes — so agents reason over typed entities, relationships, and provenance rather than loose, similarity-matched snippets. The two are complementary: the Cognitive Enterprise is the substrate that makes enterprise RAG accurate and explainable, because retrieval runs over the connected model rather than disconnected documents. This is the substrate for Scrydon's Enterprise RAG. ### How does the Cognitive Enterprise compare to Microsoft Work IQ? Microsoft Work IQ is a context and knowledge engine that grounds Microsoft 365 Copilot in your work data — such as your emails, chats, documents, and meetings — inside the Microsoft ecosystem and cloud. The Cognitive Enterprise is different in scope and control: it is a sovereign, model-agnostic connected model built on an explicit, governed ontology that spans all of your data and systems — not only Microsoft 365 — and it runs inside your own perimeter, from air-gapped on-premises to cloud, with you in control of the data and the models. The difference is sovereignty, ontology-based grounding, cross-system breadth, and model-agnosticism. --- ## Digital Twin - Term: Digital Twin - URL: https://scrydon.com/platform/cognitive-enterprise/digital-twin/ **Definition.** A digital twin of the business is a live, queryable model of an organisation's real-world entities, assets, and operations — built on the ontology and continuously synchronised with the systems that generate the underlying data. Unlike a static architecture diagram or a point-in-time export, it reflects the actual current state of the business, so it can be simulated, monitored, and acted on rather than merely viewed. Most "digital twins" are either a narrow industrial model wired to sensor feeds, or a static diagram that goes stale the day it's drawn. Scrydon takes a broader view: the ontology already models your entities, assets, and their relationships — the digital twin is that same model kept live, continuously synchronised with the systems of record that describe the real state of operations. It covers IoT and OT sensor data where that matters, but also people, processes, contracts, and assets that never emit a signal. The result is one model you can query for the current state, simulate for what-if scenarios, monitor for drift, and connect to the same agents that reason over the rest of the Cognitive Enterprise — entirely inside your perimeter. ### FAQ ### What is a digital twin of the business? A digital twin of the business is a live, queryable model of an organisation's real-world entities, assets, and operations, built on the ontology and kept continuously synchronised with the systems that generate the underlying data. It reflects the actual current state of operations rather than a static, point-in-time diagram. ### Is this the same as an industrial IoT digital twin? It covers that case but isn't limited to it. An industrial digital twin typically models physical equipment from sensor feeds. Scrydon's digital twin is built on the ontology, so it can model any real-world entity — assets and sensors, but also people, processes, contracts, and organisational structures — in one connected model. ### How does the digital twin stay in sync with source systems? The twin is populated and updated from the same pipelines that keep the rest of the ontology current — streaming and batch updates from the systems of record, IoT and OT feeds where relevant, and business applications. As source data changes, the twin changes with it, so it reflects the real state of operations rather than a stale copy. ### How is the digital twin different from a dashboard? A dashboard visualises data; it doesn't model the entities and relationships behind it. The digital twin is the underlying model — the entities, their state, and how they relate — that a dashboard can render, an agent can query, or a simulation can run against. Dashboards are one consumer of the twin, not the twin itself. ### Can the digital twin be used for simulation and what-if analysis? Yes. Because the twin holds a current, structured model of real-world entities and their relationships, you can run what-if scenarios against it — a failed asset, a delayed shipment, a capacity constraint — and see the downstream effect before acting in the real world. ### Where does a live digital twin matter most operationally? Anywhere operators need to know the real current state, not yesterday's snapshot: tracking asset and mission readiness in defence, monitoring grid resilience and OT systems in critical infrastructure, or watching any operation where conditions change faster than a manual report can keep up. ### Is the digital twin sovereign and secure? Yes. The digital twin is built and queried inside your own perimeter — from air-gapped on-premises to cloud — with the same governance, lineage, and access control as the rest of the ontology. The live model of your operations never leaves your control. --- ## Decision Intelligence - Term: Decision Intelligence - URL: https://scrydon.com/platform/cognitive-enterprise/decision-intelligence/ **Definition.** Decision intelligence is the governed layer that turns insight from your ontology and analytics into operational decisions, and connects those decisions to the agents and workflows that carry them out. It closes the loop from data to action — inside your perimeter — so every decision is traceable back to the data, logic, and system that executed it. Most enterprises can see what's happening in their business; far fewer can consistently act on it. The gap sits between insight and execution: a dashboard shows a metric crossing a threshold, but nothing connects that signal to whatever should happen next, so a person has to notice it, interpret it, and manually trigger the response. Decision intelligence closes that gap by modelling decisions as first-class, ontology-grounded objects — trigger, logic, permitted actions — that agents and workflows can call directly. It is the bridge between Scrydon's Analytics and Ontology Based Data Platform on one side, and the Agentic AI Platform on the other, so analytics stops being a report and starts being a decision that gets made. ### FAQ ### What is decision intelligence? Decision intelligence is the governed layer that connects insight from your ontology and analytics to the operational decisions your organisation makes, and links those decisions to the agents and workflows that execute them. It closes the loop from data to action, so a decision — not just a dashboard — is the output of your analytics. ### How is decision intelligence different from business intelligence (BI)? BI surfaces what happened — dashboards, reports, and metrics for people to read and interpret. Decision intelligence goes a step further: it models the decision itself as a governed object with a trigger, logic, and permitted actions, and connects it to the system that executes it. BI stops at insight; decision intelligence carries insight through to action. ### How does decision intelligence relate to the ontology? Decisions are modelled directly on Scrydon's ontology, using the same entities, relationships, and definitions your analysts and agents already reason on. That grounding is what lets a decision point pull current, consistent data and lets its outcome be written back to the ontology for the next decision to use. ### Can AI agents make decisions autonomously with this? Yes, within governed limits. Decision points define exactly what data an agent may use, what logic applies, and what actions are permitted — including where human approval is required before an action executes. Autonomy is scoped and auditable, not open-ended. ### Is decision intelligence auditable? Yes. Because every decision is a defined object rather than an implicit judgment call, each one traces back to the data that triggered it, the logic that was applied, and the agent, workflow, or person that acted on it — the full chain is inspectable after the fact. ### How does decision intelligence connect to Scrydon's Agentic AI Platform? Decision intelligence is the bridge between the Cognitive Enterprise's grounded insight and the Agentic AI Platform's execution layer. Decisions modelled on the ontology become callable actions that agents and orchestrated workflows can execute directly, so agentic AI moves from producing reports to closing the loop on real operational decisions. --- ## AI OS - Term: AI OS (AI Operating System) - URL: https://scrydon.com/platform/ai-os/ **Definition.** An AI OS (AI Operating System) — also called an Agentic OS — is the runtime that brings the right context to the right agent, system, or person at the right time. It starts from your business processes, maps each step to whoever should execute it — an existing system, an AI agent, or a human — and turns every interaction into new information linked to your ontology, so each run of the process is better informed than the last. Most automation fails because the actor — human or AI — doesn't have the context to act well. Scrydon's sovereign AI OS fixes this at the source. It begins with the business process, decides which steps are handled by existing systems, which by AI agents, and which by people, and delivers each one exactly the context it needs. If your teams have already run copilots and AI pilots and now need organisational AI — governed and running across the whole organisation rather than one user at a time — the AI OS is the runtime that takes those experiments from pilots to production. Every interaction becomes new information, linked back to the ontology — so the next time the process runs, the AI OS brings even better context to the right agent or human at the right time. ### FAQ ### What is an AI OS? An AI OS (AI Operating System) — also called an Agentic OS — is the runtime that brings the right context to the right agent, system, or person at the right time. It starts from your business processes, maps each step to whoever should execute it — an existing system, an AI agent, or a human — and turns every interaction into new information linked to your ontology, so each run of the process is better informed than the last. ### Is an AI OS the same as an Agentic OS? Yes. [Agentic OS](/platform/ai-os/agentic-os) is another name for an AI OS — the runtime that orchestrates AI agents, existing systems, and people across your business processes. We use the terms interchangeably: "agentic" emphasises that autonomous AI agents are first-class actors in the OS, alongside the systems and humans it coordinates and governs. ### How is an AI OS different from a single AI agent or chatbot? A single agent or chatbot executes isolated tasks without shared context or governance. An AI OS is the runtime that coordinates many agents, existing systems, and humans together — scheduling work, enforcing policy and identity, and grounding every action in a consistent model of the business so outcomes are accurate, explainable, and auditable. ### How does an AI OS work? It works process-first. The AI OS starts from a business process and breaks it into steps, decides which steps are handled by existing systems, which by AI agents, and which by humans, and delivers each actor exactly the context it needs from the ontology and live data. Every interaction is captured as new information linked to the ontology, so the next time the process runs the AI OS brings even better context to the right actor at the right time. ### Is an AI OS sovereign and secure? Scrydon's AI OS runs entirely within your own perimeter — from fully air-gapped on-premises deployments to hyperscale cloud — on a zero-trust foundation with federated identity and complete audit trails. No reliance on external hyperscalers or third-party API dependencies is required. ### What is organisational AI? Organisational AI is AI applied at the level of the whole organisation — across its processes, systems, and people — rather than as individual productivity tools or copilots that only make one person faster at one task. An AI OS is what makes organisational AI possible, providing the shared runtime where organisation-wide intelligence is orchestrated, grounded in a common ontology, and governed. ### How is organisational AI different from personal AI like Microsoft Copilot or Claude Cowork? Personal AI tools such as Microsoft Copilot and Claude Cowork are assistants that make an individual faster at a single task inside their own apps, with no shared context or organisation-wide governance. Organisational AI coordinates AI across teams, systems, and workflows from one consistent model of the business, automating whole processes end to end with identity, policy, and audit applied consistently — which is exactly what an AI OS delivers. ### We've already run AI pilots and copilots — what's the next step? The next step is moving from isolated pilots to an organisational AI OS that runs across the whole organisation. Instead of scattered copilots that each help one person, the AI OS gives every agent, system, and person a shared ontology, governed agents, federated identity, and a complete audit trail. That is how you take AI from pilots to production — scaling it organisation-wide on a sovereign deployment inside your own perimeter. ### How does an AI OS support an AI Centre of Excellence (CoE)? An AI Centre of Excellence (AI CoE) sets the strategy, standards, and governance for AI across an organisation — but it needs a runtime to put them into production. The AI OS is that runtime: it gives your CoE one place to deploy governed agents, enforce identity and policy, ground AI in a shared ontology, and audit every action — turning the centre of excellence's standards into organisation-wide AI that scales from pilots to production inside your own perimeter. ### What can you build on an AI OS? Organisations use an AI OS to automate end-to-end processes that span people and systems: back-office workflows, document and data processing, decision support, and cross-department coordination — all governed, observable, and grounded in the enterprise ontology. --- ## Agentic AI Platform - Term: Agentic AI Platform - URL: https://scrydon.com/platform/ai-os/agentic-ai/ **Definition.** An agentic AI platform is the software foundation for building, deploying, and governing autonomous AI agents that can reason, plan, and act on real enterprise systems. Unlike standalone chatbots, agents on the platform operate with identity, granular access control, and full auditability for every action they take, and are composed into governed AI workflows that combine deterministic steps with autonomous reasoning. Agentic AI moves beyond answering questions to getting work done. But autonomous agents acting on production systems need more than a model — they need a runtime that gives them context, enforces policy, and records what they do. Scrydon's sovereign agentic AI platform provides exactly that: agents grounded in your ontology, orchestrated as governed AI workflows by the AI OS, and contained by a zero-trust foundation. ### FAQ ### What is an agentic AI platform? An agentic AI platform is the software foundation for building, deploying, and governing autonomous AI agents that can reason, plan, and act on real enterprise systems — with identity, granular access control, and full auditability for every action they take. ### What is the difference between agentic AI and generative AI? Generative AI produces content — text, images, or code — in response to a prompt. Agentic AI goes further: agents plan and take multi-step actions on real systems to achieve a goal. An agentic AI platform provides the runtime, context, and governance those acting agents need to operate safely. ### How does an agentic AI platform keep agents safe and compliant? Each agent runs with its own identity and scoped permissions, so it can only access what it is authorised to. Policy is enforced on every action, all activity is logged in a complete audit trail, and agents are grounded in the enterprise ontology so they reason on verified business data rather than guesswork. ### How does an agentic AI platform relate to an AI OS? The AI OS — also called the Agentic OS — is the runtime that orchestrates work across agents, existing systems, and people. The agentic AI platform is the part of that stack focused on the agents themselves — how they are built, given tools and context, and governed. They are designed to work together within one sovereign platform. ### How do AI agents and AI workflows relate? Agents are composed into AI workflows — orchestrated sequences that combine deterministic steps with autonomous agent reasoning. The platform runs these AI workflows safely: grounded in your ontology, governed by policy, and fully audited, so automation is both adaptable and predictable. ### What is multi-agent orchestration? Multi-agent orchestration is coordinating several specialised AI agents — alongside existing systems and humans — to complete a process that no single agent handles alone. On Scrydon's platform, agents are composed into governed AI workflows and multi-agent systems orchestrated by the AI OS: each agent runs with its own identity and scoped permissions, work is routed between them with deterministic and autonomous steps combined, and every action is grounded in your ontology and captured in an audit trail — so multi-agent automation stays accountable and under control. ### Can agentic AI run on-premises or air-gapped? Yes. Scrydon's agentic AI platform deploys entirely within your perimeter — from fully air-gapped on-premises environments to hyperscale cloud — on a zero-trust foundation, with no dependency on external hyperscalers or third-party APIs. ### How do we take agents from pilot or POC to governed production across the organisation? Production-ready AI agents need more than a working demo — they need enterprise AI governance applied consistently as they scale. Each agent runs with its own identity and scoped permissions, every action is policy-checked and captured in an audit trail, and agents stay grounded in your ontology so they reason on verified business data. Deployed sovereignly inside your own perimeter, this is what lets you run AI agents at scale across the whole organisation rather than as one-off proofs of concept. --- ## SAP Joule Alternative - Term: SAP Joule Alternative - URL: https://scrydon.com/platform/compare/sap-joule-alternative/ **Definition.** Scrydon is a sovereign alternative to SAP Joule: where Joule is centred on SAP and runs on SAP-operated infrastructure, Scrydon is cross-system organisational AI that reasons over all your data — not just SAP — through a unified business ontology. It is model-agnostic and self-hosted, with governed agents that act across your whole estate, on infrastructure you run inside your own perimeter. SAP Joule is a capable copilot and set of agents centred on SAP, and it increasingly reaches outward via A2A, MCP and a Microsoft 365 Copilot integration. But SAP data and processes remain its centre of gravity, and it runs on SAP-operated infrastructure. Scrydon inverts that: a business ontology unifies data from across your whole estate — SAP and everything else — governed agents act on any connected system, and everything runs inside your own perimeter on infrastructure you operate, with your keys — so AI reasons over all your data, on foundations you control. ### FAQ ### What is the best alternative to SAP Joule? Scrydon is a sovereign alternative to SAP Joule for organisations that need AI across more than SAP. Instead of a copilot embedded in SAP applications, it is cross-system organisational AI that reasons over all your data through a unified ontology, with governed agents acting across your whole estate — sovereign, model-agnostic, and inside your own perimeter. ### How is Scrydon different from SAP Joule? SAP Joule is a generative-AI copilot and set of agents centred on SAP; it now interoperates outward via A2A, MCP and a Microsoft 365 Copilot integration, but SAP remains its centre of gravity and it runs on SAP-operated infrastructure. Scrydon unifies data from your whole estate — SAP and non-SAP — into one business ontology, lets governed agents act across any connected system, and runs self-hosted inside your own perimeter, so AI is grounded on foundations you control. ### Can Scrydon work with SAP data? Yes. Scrydon connects to SAP and non-SAP systems alike and unifies their data into a single business ontology. That means agents can reason over SAP data alongside everything else, rather than being limited to what sits inside the SAP ecosystem. ### Is Scrydon tied to one vendor's models or ecosystem? No. Scrydon is model-agnostic and cross-system: it serves open-weight models with vLLM inside your perimeter, can integrate others where policy allows, and acts across whichever systems you connect — so neither your model choice nor your AI is tied to a single vendor's ecosystem. ### Is Scrydon sovereign? Yes. Scrydon is European-native and runs entirely inside your own perimeter — from fully air-gapped on-premises to cloud — with your own encryption keys and governance built into the runtime, so data residency and control over cross-system AI stay with you. --- ## n8n Alternative - Term: n8n Alternative - URL: https://scrydon.com/platform/compare/n8n-alternative/ **Definition.** Scrydon is a sovereign alternative to n8n: rather than a general workflow-automation tool with AI nodes added, it is an agentic AI platform where workflows are grounded in your business ontology and governed by federated identity, policy-as-code, audit, and data loss prevention. Models are served sovereignly inside your perimeter, and agents reason over verified business meaning — so AI is the foundation of the workflow, not a bolt-on, at organisation-wide scale. n8n is a strong, flexible, self-hostable tool for integration and workflow automation, and it has added AI and agent nodes. But in n8n, AI is a step you wire into a flow — it is not grounded in a shared ontology, and enterprise AI governance, identity, and sovereign model serving are not the core of the product. Scrydon starts from governed agentic AI: workflows combine deterministic steps with autonomous agent reasoning, every action is grounded in your ontology and governed end to end, and models run inside your own perimeter — so AI workflows scale across the organisation with the controls regulated teams need. ### FAQ ### What is the best alternative to n8n for AI agents? Scrydon is a sovereign alternative to n8n for AI-centric automation. Instead of a general workflow tool with AI nodes, it is an agentic AI platform where workflows are grounded in your ontology and governed by identity, policy, audit, and DLP, with models served sovereignly inside your perimeter — so AI workflows scale across the whole organisation with enterprise controls. ### How is Scrydon different from n8n? n8n is a flexible, self-hostable workflow-automation tool that added AI and agent nodes, so AI is a step you wire into a flow. Scrydon is AI-first: agentic workflows combine deterministic steps with autonomous reasoning, grounded in your business ontology, governed end to end, and served by sovereign open-weight models — designed for governed AI automation at organisation-wide scale. ### Isn't n8n already self-hostable and flexible? Yes — n8n is genuinely flexible and self-hostable, which keeps integration automation close to your data, and for general workflow automation it is a fair choice. Scrydon differentiates where AI is central: ontology grounding so agents reason on verified meaning, organisation-wide AI governance, and sovereign model serving with vLLM — capabilities that a general automation tool with AI nodes does not make its core. ### Does Scrydon serve its own models? Yes. Scrydon is model-agnostic and serves open-weight models with vLLM inside your own perimeter, fully air-gapped to cloud, and can integrate frontier models where policy allows. You can switch the model behind a workflow without re-architecting, because the model is abstracted from the process. ### Is Scrydon more governed than n8n? For AI specifically, yes. Every agent runs with a scoped identity, every action is authorised by policy-as-code and recorded in an immutable audit trail, and a DLP engine screens outputs before they leave — enterprise AI governance built into the runtime rather than configured per flow. --- ## Microsoft Fabric Alternative - Term: Microsoft Fabric Alternative - URL: https://scrydon.com/platform/compare/microsoft-fabric-alternative/ **Definition.** Scrydon is a sovereign alternative to Microsoft Fabric: a first-class, organisation-wide business ontology you run inside your own perimeter. Fabric now offers its own ontology (Fabric IQ), but it is delivered as Azure-only SaaS on OneLake; Scrydon runs on open table formats inside your own perimeter, European-native, from air-gapped on-premises to cloud — so your semantics, data, and deployment are not tied to the Microsoft cloud. Microsoft Fabric unifies analytics well for Microsoft-centric teams, and whether you use Power BI semantic models or its newer Fabric IQ ontology, the whole suite runs as Azure-only SaaS on OneLake. That ties your data, your modelling, and your residency to a single hyperscaler. Scrydon takes a different path: one first-class business ontology you run inside your own perimeter, on open formats, European-native — so your semantics and sovereignty do not depend on Azure. ### FAQ ### What is the best alternative to Microsoft Fabric? Scrydon is a sovereign alternative to Microsoft Fabric for organisations that want to run their business ontology and analytics inside their own perimeter rather than in Azure-only SaaS. It runs on open formats, European-native, from air-gapped on-premises to cloud. ### How is Scrydon different from Microsoft Fabric? Fabric is Azure-only SaaS on OneLake; its semantics live in Power BI models and, more recently, the Fabric IQ ontology — but both run inside the Microsoft cloud. Scrydon provides one first-class business ontology you run inside your own perimeter, on open table formats, with your keys — so your semantics and residency are not tied to a single hyperscaler. ### Isn't a Power BI semantic model the same as an ontology? A Power BI semantic model is scoped per dataset and built for BI reporting. An ontology is an organisation-wide model of entities, relationships, and rules shared by every dashboard, report, and AI agent. Fabric has since added its own ontology (Fabric IQ), but it is hosted in the Microsoft cloud on OneLake; the difference with Scrydon is that you run your ontology inside your own sovereign perimeter. ### Is Scrydon more sovereign than Microsoft Fabric? Yes. Fabric is delivered as Azure cloud SaaS only. Scrydon is European-native and runs entirely inside your own perimeter — from fully air-gapped on-premises to cloud — on open formats with your own encryption keys, so data residency and control are not tied to a single hyperscaler. ### Does Scrydon work with AI and Copilot-style assistants? Yes, and it goes further. The same ontology that powers insight also grounds AI agents, so they answer from verified business meaning with citations rather than running over per-dataset BI models — accurate, explainable, and governed inside your perimeter. --- ## Palantir Foundry Alternative - Term: Palantir Foundry Alternative - URL: https://scrydon.com/platform/compare/palantir-foundry-alternative/ **Definition.** Scrydon is a sovereign alternative to Palantir Foundry: an ontology based data platform that unifies your data into a living, business-level semantic model and grounds AI agents in it — but runs inside your own perimeter on open table formats, from air-gapped on-premises to cloud. It delivers Foundry's core idea of an operational ontology without the US-vendor dependency. Palantir Foundry put the operational ontology on the map — a single semantic model that ties data, analytics, and action together. Both platforms now expose data in open table formats, so the real trade-off is not the file format: it is cost, and the fact that Foundry is operated by a US vendor subject to US jurisdiction. Scrydon gives you the same ontology-first foundation on a European-native footing: your keys and your perimeter, operated under EU law, with deployment from fully air-gapped on-premises through to hyperscale cloud. You keep the operational ontology — and the leverage stays with you. ### FAQ ### What is the best alternative to Palantir Foundry? Scrydon is a sovereign alternative to Palantir Foundry: an ontology based data platform that delivers Foundry's core operational ontology — unifying your data into a business-level semantic model and grounding AI in it — but European-native, operated by you under EU jurisdiction, with your own keys. ### How is Scrydon different from Palantir Foundry? Both centre on an operational ontology, and both can expose data in open table formats and run inside your perimeter — Foundry does air-gapped deployments too, so neither openness nor deployment locus separates them. What differs is who operates and answers for the platform: Foundry is a US vendor under US jurisdiction at enterprise pricing, while Scrydon is European-native, operated under EU law, with your own keys. ### Does Scrydon have an operational ontology like Foundry's? Yes. A native, first-class business ontology is at the heart of the platform: a living model of entities, relationships, and rules that analytics, insight, and AI agents all share — the same idea that makes Foundry's ontology valuable, delivered on open, sovereign foundations. ### Is Scrydon more sovereign than Palantir Foundry? On deployment alone, no: Foundry's Apollo also does multicloud, on-premises, air-gapped and edge, so "runs in your perimeter" is not a differentiator and we will not claim it as one. The difference is jurisdictional. Scrydon is European-native and operated under EU law, with your own encryption keys and no dependency on a US vendor — so the entity that holds and answers for your deployment is not subject to US jurisdiction. Whether that matters is a question for your own risk assessment. ### Will I be locked in like with Foundry? Not at the storage layer — though in fairness, nor are you with Foundry: it also supports Iceberg and Parquet, implements the Iceberg REST Catalog, and offers bring-your-own-bucket. Scrydon is built on the same open table formats, so your data stays portable and queryable in place. The switching costs that do matter are commercial and operational rather than format-level, and there you own the perimeter and the keys. --- ## Palantir AIP Alternative - Term: Palantir AIP Alternative - URL: https://scrydon.com/platform/compare/palantir-aip-alternative/ **Definition.** Scrydon is a sovereign alternative to Palantir AIP: a model-agnostic organisational AI OS that grounds agents in a first-class business ontology and runs inside your own perimeter, from air-gapped on-premises to cloud, EU-domiciled and operated under EU jurisdiction. Where AIP is the agent and LLM layer of Palantir Foundry, Scrydon delivers the ontology, the agents, and the governance as one European-native platform — with no dependency on a US vendor. Palantir AIP is a serious product: it brings language models and agents into Foundry and grounds them in the Foundry Ontology, so they act on business meaning rather than raw tables — and, like Foundry, it deploys from cloud to fully air-gapped environments through Apollo. Its constraint is structural rather than technical. AIP is the AI layer of Foundry, so adopting it means adopting Foundry as the description of your business, from a US vendor under US jurisdiction, at enterprise pricing. Scrydon offers the same architecture — an operational ontology that grounds governed agents — as a sovereign, model-agnostic AI OS: open-weight or other models of your choosing, inside your own perimeter, with your own keys, EU-domiciled and operated under EU law. The idea is shared; the leverage stays with you. ### FAQ ### What is the best alternative to Palantir AIP? Scrydon is a sovereign alternative to Palantir AIP: a model-agnostic organisational AI OS that grounds agents in a first-class business ontology and runs inside your own perimeter, from air-gapped on-premises to cloud — EU-domiciled and operated under EU jurisdiction, with your own keys. It delivers AIP's core idea, ontology-grounded agents, without requiring Foundry or a US vendor. ### How is Scrydon different from Palantir AIP? AIP is the AI layer of Palantir Foundry: it puts language models and agents on top of the Foundry Ontology. Scrydon is a full platform in its own right — ontology based data platform, AI OS, and governance — so you are not adopting a US vendor's data platform to get grounded agents. It is model-agnostic, runs inside your perimeter, and is EU-domiciled under EU jurisdiction. ### Do I need Foundry to use Scrydon? No. Scrydon includes its own ontology based data platform on open table formats, so the ontology that grounds your agents is one you build and own on the platform. That is the structural difference from AIP, which grounds on the Foundry Ontology and is adopted together with Foundry. ### Isn't AIP also model-agnostic? AIP offers a broad catalogue of models, so model choice alone is not the difference and we will not claim it as one. The difference is where the models run and who curates them: Scrydon serves open-weight models inside your own perimeter, or integrates others where your policy allows, on a platform you operate — rather than through a US vendor's catalogue and platform. ### Is Scrydon more sovereign than Palantir AIP? On deployment alone, no: through Apollo, AIP and Foundry deploy to cloud, on-premises, and fully air-gapped environments too. The difference is jurisdictional and commercial. Scrydon is EU-domiciled and operated under EU law, with your own encryption keys and no dependency on a US vendor — so the entity that answers for your deployment is not subject to US jurisdiction, and you are not committed to a US vendor's data platform. ### Can Scrydon's agents act on systems, not just answer questions? Yes. Agents in the AI OS take governed actions across your existing systems, with federated identity, policy-as-code, and an audit trail on every step — grounded in the ontology so they act on verified business meaning. What you get is agents that do work, inside a perimeter and under a jurisdiction you control. --- ## Snowflake Alternative - Term: Snowflake Alternative - URL: https://scrydon.com/platform/compare/snowflake-alternative/ **Definition.** Scrydon is a sovereign alternative to Snowflake: an ontology based data platform that pairs an open lakehouse with a first-class business ontology and a governed agentic layer — and runs inside your own perimeter, from air-gapped on-premises to cloud, EU-domiciled and operated under EU jurisdiction. Where Snowflake is a US-operated managed service available only in the public cloud, Scrydon puts data residency, keys, and operations in your hands. Snowflake is a very good cloud data warehouse — elastic, well-governed, increasingly open through Iceberg tables, and now marketed as an AI Data Cloud with AI features built in. But it is a fully managed service that runs only in public-cloud regions on AWS, Azure, and Google Cloud, operated by a US company subject to US jurisdiction and laws such as the CLOUD Act — even when the region is in Europe. Scrydon is not trying to be a better warehouse. It is a sovereign lakehouse on open table formats, with a native business ontology so metrics and entities mean one thing everywhere, and an AI OS that runs governed agents on that meaning — deployable from fully air-gapped on-premises through to hyperscale cloud, with your keys and your operators, under EU law. ### FAQ ### What is the best alternative to Snowflake? For organisations that need sovereignty, Scrydon is an alternative to Snowflake: an ontology based data platform that pairs an open lakehouse with a first-class business ontology and a governed agentic layer — run inside your own perimeter, from air-gapped on-premises to cloud, EU-domiciled and operated under EU jurisdiction. It is not a like-for-like warehouse; it is a different footing for data and AI. ### How is Scrydon different from Snowflake? Snowflake is a fully managed cloud data warehouse, available only in public-cloud regions and operated by a US company. Scrydon is a sovereign lakehouse you run yourself — from fully air-gapped on-premises to cloud — with a native business ontology on top and an AI OS running governed agents on that ontology, EU-domiciled and under EU jurisdiction, with your own keys. ### Snowflake has EU regions — isn't that data residency? Region controls where the bytes are stored; it does not change who operates the service or which law they answer to. Snowflake is a US company subject to US jurisdiction and extraterritorial laws such as the CLOUD Act regardless of region. Scrydon is EU-domiciled and operated under EU law, and runs inside your perimeter with your keys — so residency and jurisdiction line up. Whether that matters is a question for your own risk assessment. ### Can Scrydon run air-gapped, and does that limit the AI? Yes, and no. Scrydon runs from fully air-gapped on-premises through to hyperscale cloud with the same platform. The AI OS is model-agnostic and serves open-weight models inside your perimeter, so agents work without any call to an external service — Snowflake's AI features, by contrast, run in Snowflake's cloud. ### Is Scrydon a better data warehouse than Snowflake? That is not the claim. Snowflake is an excellent warehouse for elastic SQL in the public cloud, and if that is all you need and your data may live there, it may serve you well. Scrydon is for organisations that need the lakehouse, the ontology, and the agents inside their own perimeter and under EU jurisdiction — a different requirement, not a faster query. ### Will I be locked in? Not at the storage layer: Scrydon is built on open table formats such as Apache Iceberg, so your data stays portable and queryable in place — and Snowflake supports Iceberg too. The switching costs that matter are operational and commercial. There the difference is that with Scrydon you own the perimeter, the keys, and the operators. --- ## Dataiku Alternative - Term: Dataiku Alternative - URL: https://scrydon.com/platform/compare/dataiku-alternative/ **Definition.** Scrydon is a sovereign alternative to Dataiku: where Dataiku is a data science and machine-learning platform that has grown a generative-AI and agent toolkit, Scrydon is an organisational AI OS that runs governed agents on a first-class business ontology and an open lakehouse — model-agnostic, inside your own perimeter from air-gapped on-premises to cloud, EU-domiciled and operated under EU jurisdiction. Dataiku is a mature, well-liked platform for data preparation, machine learning, and MLOps, and it has extended into generative AI with a multi-model gateway and agent tools. It is project-shaped: teams build pipelines, models, and now agents in a workspace, and deploy them. Scrydon starts from the other end. It is an AI OS — a governed runtime that brings the right context to the right agent, system, or person — grounded in a native business ontology so agents act on verified meaning rather than per-project data preparation. It is model-agnostic, runs inside your own perimeter with your own keys, and is EU-domiciled and operated under EU jurisdiction. Where Dataiku equips the data team, Scrydon runs the organisation. ### FAQ ### What is the best alternative to Dataiku? For organisations that want AI running the business rather than a workbench for building it, Scrydon is an alternative to Dataiku: an organisational AI OS that runs governed agents on a first-class business ontology and open lakehouse — model-agnostic, inside your own perimeter from air-gapped on-premises to cloud, EU-domiciled and under EU jurisdiction. ### How is Scrydon different from Dataiku? Dataiku is a data science and machine-learning platform that has added generative-AI and agent tooling; its unit of work is the project. Scrydon is a runtime: an AI OS that brings the right context to the right agent, system, or person across the whole organisation, grounded in a business ontology, with identity, policy, and audit applied to every action — deployed sovereignly, under EU jurisdiction. ### Does Scrydon replace my data scientists' tools? It does not try to. Scrydon is where the organisation's agents run and where its data is described once; models and analyses built elsewhere can be served and grounded in that ontology. If your need is a notebook-and-pipeline workbench for a data team, Dataiku is good at that. If your need is governed AI acting across the business, that is what an AI OS is for. ### Can Scrydon and Dataiku run alongside each other? Yes, and for many organisations that is the sensible answer. Dataiku stays where your data scientists already work; Scrydon integrates with it, so flows and models built there read from the same governed [lakehouse](/platform/analytics/lakehouse) and the same [ontology](/platform/analytics/ontology-based-data-platform), and their outputs can be written back for agents and applications to act on. You get one definition of a customer or a contract across both, rather than two, and the agents acting on the business inherit the governance rather than each tool bringing its own. ### Isn't Dataiku also model-agnostic and self-hosted? Yes — Dataiku connects to many models through its gateway and can be installed on-premises or in your cloud, so neither point separates us and we will not claim it does. The difference is purpose and grounding: an organisational runtime with a native ontology and governance on every action, versus a project platform — and jurisdiction, since Scrydon is EU-domiciled and operated under EU law. ### Is Scrydon sovereign? Yes. Scrydon is EU-domiciled and operated under EU jurisdiction, and runs entirely inside your own perimeter — from fully air-gapped on-premises to cloud — with your own encryption keys and governance built into the runtime, so data residency, control, and the roadmap stay with you. ### Can business users work with it, or only data teams? Both. Because agents and analytics share one business ontology, analysts and business users work from agreed meaning rather than raw tables, and governed no-code agents can be built without a data-science background — while data teams keep full depth. That is the point of an organisational AI OS: the many, not only the few. --- ## C3 AI Alternative - Term: C3 AI Alternative - URL: https://scrydon.com/platform/compare/c3-ai-alternative/ **Definition.** Scrydon is a sovereign alternative to C3 AI: where C3 AI is a US enterprise-AI vendor offering a proprietary platform and a suite of prebuilt applications, Scrydon is a European, open, model-agnostic AI OS that runs governed agents on a first-class business ontology and open lakehouse — inside your own perimeter from air-gapped on-premises to cloud, EU-domiciled and operated under EU jurisdiction. C3 AI is an established enterprise-AI vendor: a platform with a model-driven architecture, a portfolio of prebuilt applications for reliability, supply chain, energy, financial services, and defence and intelligence, and deployment across the major clouds, on premises, and air-gapped networks — with a strong footprint in US federal and defence. Its model is the application suite: you buy the applications and the platform they run on, from a US vendor under US jurisdiction. Scrydon takes the opposite stance. It is an AI OS — a governed runtime that brings the right context to the right agent, system, or person — grounded in a native business ontology on open table formats, model-agnostic, and run inside your own perimeter with your own keys, EU-domiciled and operated under EU law. For European government, defence, and critical infrastructure, sovereignty is not a feature of the platform; it is the reason for it. ### FAQ ### What is the best alternative to C3 AI? For European organisations that need sovereignty, Scrydon is an alternative to C3 AI: an open, model-agnostic AI OS that runs governed agents on a first-class business ontology and open lakehouse — inside your own perimeter from air-gapped on-premises to cloud, EU-domiciled and operated under EU jurisdiction, with your own keys. ### How is Scrydon different from C3 AI? C3 AI is a US vendor selling a proprietary platform and a suite of prebuilt enterprise applications, with a strong US federal and defence footprint. Scrydon is a European AI operating system: open table formats, models you choose, a native business ontology, and a governed runtime for agents — operated by you, under EU law, so the leverage and the jurisdiction stay with you. ### Is Scrydon more sovereign than C3 AI? On deployment alone, no: C3 AI also deploys on premises and in air-gapped networks, so "runs in your perimeter" is not a differentiator and we will not claim it as one. The difference is jurisdictional and structural. Scrydon is EU-domiciled and operated under EU law, with your own encryption keys and no dependency on a US vendor — and it is an open platform rather than a proprietary application suite. Whether that matters is a question for your own risk assessment. ### Does Scrydon come with prebuilt applications like C3 AI? Scrydon is an operating system rather than an application catalogue: it provides the ontology, the governed agent runtime, analytics, and sovereign foundations, and applications are composed on top — by your teams, by partners, or with us — on your own description of the business. That is a deliberate trade: less packaged, more yours. ### Is Scrydon suitable for defence and critical infrastructure? Yes. It runs from fully air-gapped on-premises upward with the same platform, on zero-trust foundations with federated identity, confidential computing, and audit on every agent action — under EU jurisdiction with your own keys. That is the posture European government, defence, and critical-infrastructure operators increasingly require. ### Is Scrydon tied to a particular AI model? No. Scrydon is model-agnostic: it serves open-weight models inside your own perimeter and can integrate others where your policy allows. Because the model is abstracted from your processes, you can switch the model behind a workflow without re-architecting it. --- ## Microsoft 365 Copilot vs Organisational AI - Term: Microsoft 365 Copilot vs Organisational AI - URL: https://scrydon.com/platform/compare/microsoft-copilot-vs-organisational-ai/ **Definition.** Microsoft 365 Copilot is powerful AI hosted in the Microsoft cloud: it makes individuals faster and, through Copilot Studio and Agent 365, can automate tasks and govern agents within the Microsoft and Entra estate. Organisational AI applies AI across the whole organisation — its processes, systems, and people — coordinated by an AI OS from a single vendor-neutral ontology, identity model, and governed runtime that you run inside your own sovereign perimeter. The two are complementary; the difference is locus and independence, not whether automation is possible. AI assistants such as Microsoft 365 Copilot and ChatGPT are genuinely useful, and Microsoft 365 Copilot adds organisation-wide governance and cross-system connectors — but always inside the Microsoft cloud, governed within the Microsoft and Entra estate, on Microsoft’s stack. Organisational AI is a different locus: the AI OS gives every agent, system, and person a common vendor-neutral ontology, federated identity, and a complete audit trail, and runs whole processes end to end inside your own sovereign perimeter — so the leverage, the keys, and the roadmap stay with you. ### FAQ ### What is the difference between Microsoft 365 Copilot and organisational AI? Microsoft 365 Copilot is AI hosted in the Microsoft cloud; with Copilot Studio and Agent 365 it can automate tasks and govern agents within the Microsoft and Entra estate. Organisational AI coordinates AI across teams, systems, and workflows from one vendor-neutral model of the business, automating whole processes end to end with identity, policy, and audit applied consistently — run inside your own sovereign perimeter, which is exactly what an AI OS delivers. ### Is organisational AI a replacement for Copilot? No — they are complementary. Copilot can keep making individuals faster inside their apps, while organisational AI, delivered by the AI OS, coordinates agents, systems, and people across the whole organisation. The point is that copilots alone don't scale into organisational intelligence; the AI OS is what runs AI across the organisation under one ontology and governance model. ### Why don't copilots scale into organisational AI on their own? Rolling out copilots gives you many faster individuals, but the shared foundation and the governance live inside one vendor’s cloud. Organisational AI provides a vendor-neutral shared layer you run yourself — a common ontology, federated identity, governed agents, and a complete audit trail — so AI moves from isolated pilots to production across the organisation, on infrastructure you control. ### What does the AI OS provide that personal AI does not? A shared, governed ontology so every actor reasons on the same business meaning; orchestration across many agents and existing systems; federated identity and policy-as-code enforced on every action; an immutable audit trail; and sovereign deployment inside your own perimeter — from air-gapped on-premises to cloud. Personal AI tools assist one user; the AI OS coordinates the organisation. ### We've rolled out Copilot — what's the next step? The next step is moving from personal copilots to organisational AI on an AI OS that runs across the whole organisation. Instead of scattered copilots that each help one person, the AI OS gives every agent, system, and person a shared ontology, governed agents, federated identity, and a complete audit trail — taking AI from pilots to production on a sovereign deployment inside your own perimeter. --- ## Databricks Alternative - Term: Databricks Alternative - URL: https://scrydon.com/platform/compare/databricks-alternative/ **Definition.** Scrydon is a sovereign alternative to Databricks: an ontology based data platform that pairs an open lakehouse with a first-class business ontology and a semantic layer. Where Databricks targets data engineers and ML teams working over raw tables, Scrydon lets analysts, business users, and AI agents reason on consistent business meaning — all inside your own perimeter, European-native, from air-gapped on-premises to cloud. Databricks is an excellent lakehouse for data engineering and machine learning, but it leaves meaning to each team to re-derive: a catalogue and metric views, not a business ontology. Scrydon keeps the open-lakehouse foundation — built on open table formats such as Apache Iceberg — and layers a native ontology and semantic model over it, so metrics are defined once and every report, dashboard, and agent agrees on them. And it runs sovereign and European-native, with your keys and your perimeter, rather than as a vendor-managed service on a US hyperscaler. ### FAQ ### What is the best alternative to Databricks? Scrydon is a sovereign alternative to Databricks for organisations that need more than a lakehouse for engineers. It pairs an open lakehouse with a first-class business ontology and semantic layer, so analysts, business users, and AI agents work from consistent business meaning — all inside your own perimeter, European-native, from air-gapped on-premises to cloud. ### How is Scrydon different from Databricks? Databricks is a lakehouse focused on data engineering and machine learning over raw tables, with a catalogue and metric views rather than a business ontology. Scrydon keeps an open lakehouse but adds a native ontology and semantic layer on top, and runs sovereign and European-native with your own keys — so it serves the whole organisation, not just the data team. ### Does Scrydon replace the lakehouse? No — it includes one. Scrydon's lakehouse is built on open table formats such as Apache Iceberg with high-performance SQL and integrated vector search. The difference is the ontology and semantic layer above it, which turns the lakehouse into trusted, business-level meaning for insight and grounded AI. ### Is Scrydon more sovereign than Databricks? Yes. Where Databricks runs as a vendor-managed service on a US hyperscaler, Scrydon runs entirely inside your own perimeter — European-native, from fully air-gapped on-premises to cloud — with your own encryption keys, so data residency and control stay with you. ### Can business users and AI agents use it directly? Yes. Because every metric and relationship is defined once in the ontology, business users get trustworthy self-service insight without notebooks, and AI agents stay grounded in the same governed meaning — reducing hallucination and keeping answers consistent with your reporting. --- ## Cohere Alternative - Term: Cohere Alternative - URL: https://scrydon.com/platform/compare/cohere-alternative/ **Definition.** Scrydon is a sovereign alternative to Cohere: where Cohere runs its agentic workspace (North) and enterprise search (Compass) on its own models, Scrydon is a model-agnostic organisational AI OS grounded in a first-class business ontology. It runs open-weight models via vLLM or others inside your own perimeter, EU-domiciled and operated under EU jurisdiction — so you are not tied to one vendor's model family, and control stays with you. Cohere is a respected, privacy-focused AI company with strong models and a real enterprise platform — North (an agentic workspace) and Compass (enterprise search) — and it offers private, on-premises and air-gapped deployment. Its constraint is that it runs on its own model family, and it is a Canadian-headquartered vendor (now merging with Germany’s Aleph Alpha). Scrydon is model-agnostic — open-weight via vLLM or others inside your own perimeter — grounds agents in a first-class business ontology rather than retrieval alone, and is EU-domiciled and operated under EU jurisdiction, so model choice, data, and corporate control stay with you. ### FAQ ### What is the best alternative to Cohere? Scrydon is a sovereign alternative to Cohere for organisations that want model freedom and an ontology foundation. It is an organisational AI OS plus ontology data platform — model-agnostic, so you can run open-weight models via vLLM or others — and EU-domiciled under EU jurisdiction, running inside your own perimeter from air-gapped on-premises to cloud. ### How is Scrydon different from Cohere? Cohere is an enterprise AI platform — North (agentic workspace) and Compass (search) — built on its own model family. Scrydon differs in three ways: it is model-agnostic (open-weight or other models inside your perimeter), it grounds agents in a first-class business ontology rather than retrieval alone, and it is EU-domiciled under EU jurisdiction, with governance built into the runtime. ### Isn't Cohere already enterprise- and privacy-focused? Yes — Cohere is genuinely enterprise- and privacy-focused, and offers private and air-gapped deployment, so deployment alone does not separate us. Scrydon differentiates on model-agnosticism (you are not tied to one model family), an ontology foundation that grounds agents rather than retrieval alone, and EU domicile and jurisdiction. ### Is Scrydon tied to a particular model? No. Scrydon is model-agnostic: it serves open-weight models with vLLM inside your own perimeter and can integrate others where policy allows. Because the model is abstracted from your processes, you can switch the model behind a workflow without re-architecting it. ### Is Scrydon under EU jurisdiction and sovereign? Yes. Scrydon is EU-domiciled and operated under EU jurisdiction, and runs entirely inside your own perimeter — from fully air-gapped on-premises to cloud — with your own encryption keys and governance built into the runtime, so data residency, control, and the roadmap stay with you. --- ## Wonderful Alternative - Term: Wonderful Alternative - URL: https://scrydon.com/platform/compare/wonderful-alternative/ **Definition.** Scrydon is an alternative to Wonderful for organisations that want their agents grounded in a shared business ontology rather than assembled per use case. Where Wonderful is an enterprise AI-agent platform, Scrydon pairs governed agents with a first-class ontology and an ontology-based data platform, so analytics and agents work from the same model of the business — governed end to end with federated identity, audit, and DLP, EU-domiciled, and deployed inside your own perimeter. Wonderful is a capable enterprise AI-agent platform, deploying production agents across business functions with flexible deployment, including air-gapped on-premises. Scrydon's difference is not whether agents can run in your perimeter — both can — but what they are grounded in. Scrydon unifies your data into a first-class business ontology and runs governed agents on top of it, so meaning is modelled once and shared by every agent, report, and process. Automating a second and third process reuses that model rather than rebuilding context each time. It is EU-domiciled, governed by identity, policy, audit, and DLP, and runs inside your own perimeter with your own keys. ### FAQ ### What is the best alternative to Wonderful? Scrydon is an alternative to Wonderful for organisations that want their agents grounded in one shared business ontology rather than built per use case. Both run production enterprise agents; Scrydon adds a first-class ontology and an ontology-based data platform beneath the agents, governed end to end and EU-domiciled, deployed inside your own perimeter. ### How is Scrydon different from Wonderful? Both are enterprise AI-agent platforms, and both can deploy inside your perimeter, including air-gapped. The difference is the foundation: Scrydon unifies your data into a first-class business ontology and runs governed agents on top of it, so analytics and agents share one model of the business and each new process reuses it. Scrydon is also EU-domiciled, with identity, policy, audit, and DLP built into the runtime. ### Does Wonderful have an ontology or a data platform? Wonderful is an agent-centric enterprise platform: it builds and runs production agents across business functions. Scrydon's distinction is the layer beneath the agents — a first-class business ontology and an ontology-based data platform that grounds both analytics and agents in one model, so meaning is modelled once rather than rebuilt per use case. ### Can Scrydon deploy inside our own perimeter, like Wonderful? Yes — and this is not where the two differ, since Wonderful also offers single-tenant, bring-your-own-cloud, and air-gapped on-premises deployment. Scrydon runs inside your own perimeter from air-gapped on-premises to cloud, with your own keys; the distinction to weigh is the ontology foundation and EU domicile, not deployment topology alone. ### Are Scrydon's agents governed? Yes. Every agent runs with its own scoped identity, every action is authorised by policy-as-code and captured in an immutable audit trail, and a DLP engine screens outputs before they leave the platform — so agents acting on real systems stay accountable and compliant. --- ## LiteLLM Alternative - Term: LiteLLM Alternative - URL: https://scrydon.com/platform/compare/litellm-alternative/ **Definition.** The Scrydon AI Gateway is a sovereign alternative to LiteLLM: a single governed endpoint that speaks the standard model APIs — Anthropic Messages, OpenAI Chat Completions, OpenAI Responses and Gemini — so existing tools reach any model unchanged, but where every call runs under the caller's own federated identity rather than a virtual key, against a clearance-gated model allowlist, with data loss prevention, a spend cap and an immutable audit trail. It shares one policy and one audit chain with governed tool calls and sandbox egress, and runs air-gapped, on-premises or on a European sovereign cloud. LiteLLM is the most widely used open-source LLM proxy, and deservedly so: a Python proxy and SDK that puts a hundred providers behind one OpenAI-compatible API, with virtual keys, team budgets, spend tracking and routing, self-hostable in an afternoon. Its limits are the limits of the category. A virtual key stands for a team at best, so attribution stops at the key; governance ends where the model call ends, while an agent's afternoon is mostly tool calls against systems that hold your data; and the proxy sits in front of your credentials rather than being the system that holds them. The Scrydon AI Gateway keeps what LiteLLM gets right — the standard APIs, any model, developers who change nothing — and moves the control point: a gateway key is minted against a named person in your own identity provider, the model allowlist follows that person's clearance, data loss prevention screens what leaves, and the same identity governs the tools the agent calls next and the network its sandbox may reach. ### FAQ ### What is the best alternative to LiteLLM for a regulated organisation? The Scrydon AI Gateway, where the requirement is attribution to a person, audit that survives a real audit, and a security boundary that covers tool calls and egress rather than the model call alone. It speaks the same standard APIs, so the tools your developers use do not change, and it runs air-gapped, on-premises or on a European sovereign cloud. If the requirement is a proxy with budgets and a dashboard, LiteLLM is a fair choice. ### How is the Scrydon AI Gateway different from LiteLLM? Three ways. A call runs as the person who made it, resolved through your own identity provider, rather than as a virtual key; governance does not stop at the model call but covers the tools the agent calls and the network its sandbox may reach, under one policy and one audit chain; and the AI Gateway is the system that holds your credentials rather than a proxy in front of them. What is the same: the standard APIs, any model behind the endpoint, developers who change nothing. ### Does the AI Gateway support the same APIs as LiteLLM? It speaks Anthropic Messages, OpenAI Chat Completions, OpenAI Responses and Gemini natively, which covers Claude Code, Codex, Gemini CLI, Cursor, Aider and any application on a standard completions API. Prompt caching is preserved end to end. LiteLLM's breadth of provider adapters is larger; behind the AI Gateway, frontier APIs, models in your own cloud tenancy and open-weight models on your own hardware are reached by name and swapped by configuration. ### Is LiteLLM not already self-hostable and open source? Yes, and for many teams that is exactly right. Scrydon is built on open-source components and runs where your production runs, including disconnected networks, but it is not the same thing as a proxy you run yourself: identity, policy, audit, tool governance and sandbox egress are one system, and the fee is for that system, not for the model calls passing through it. ### Can we move from LiteLLM to the AI Gateway without disrupting developers? Yes. Developers sign in, mint a key, and change a base URL and an API key in their environment; the tools stay the same. The AI Gateway can be deployed on its own in a day, with the first spend report per developer a week after go-live, and the identity, policy and audit trail it puts in place are reused when you later govern agents, tools or retrieval. --- ## Bifrost Alternative - Term: Bifrost Alternative - URL: https://scrydon.com/platform/compare/bifrost-alternative/ **Definition.** The Scrydon AI Gateway is a sovereign alternative to Bifrost: a single governed endpoint that speaks the standard model APIs so existing tools reach any model unchanged, where every call runs under the caller's own federated identity rather than a virtual key, against a clearance-gated model allowlist, with data loss prevention, a spend cap and an immutable audit trail — at single-digit millisecond gateway overhead. It shares one policy and one audit chain with governed tool calls and sandbox egress, and runs air-gapped, on-premises or on a European sovereign cloud. Bifrost, from Maxim AI, is a well-engineered open-source gateway: written for throughput, with a unified OpenAI-compatible API across providers, virtual keys and budgets, semantic caching, observability and a governance layer, and a serious claim to the lowest per-request overhead in the category. On latency the two are not far apart — the Scrydon AI Gateway's own time to first byte is a few milliseconds at the median, less than a cold TLS handshake to a vendor — so the choice does not turn on speed. It turns on identity and scope. A model-only gateway attributes a call to a key; the AI Gateway attributes it to a person in your own identity provider, and the same identity governs the tools the agent calls over MCP and the network its sandbox may reach. That is the difference between a compliance story and a security boundary. ### FAQ ### What is the best alternative to Bifrost for a regulated organisation? The Scrydon AI Gateway, where the requirement is attribution to a person, audit that survives a real audit, and a boundary that covers tool calls and sandbox egress rather than the model call alone. It is comparably fast, speaks the same standard APIs, and runs air-gapped, on-premises or on a European sovereign cloud. If the requirement is the fastest possible gateway with budgets and caching, Bifrost is a fair choice. ### Is the Scrydon AI Gateway as fast as Bifrost? Close enough that latency should not decide it. The AI Gateway's own time to first byte is a few milliseconds at the median, measured against a real database with a committed benchmark, and prompt caching is preserved end to end. Bifrost advertises very low per-request overhead and we take that at face value. Either is less than the TCP and TLS handshake a direct vendor call pays when connections are not pooled. ### How is the AI Gateway different from Bifrost? A call runs as the person who made it, resolved through your own identity provider, rather than as a virtual key; governance covers the tools the agent calls and the network its sandbox may reach, under one policy and one audit chain, rather than stopping at the model call; and the AI Gateway is the system that holds your credentials rather than a gateway in front of them. What is the same: the standard APIs, any model behind the endpoint, developers who change nothing. ### Does the AI Gateway silently route to a cheaper model? No. If a request names a model, that model runs or the request fails with a typed error. Routing policies that escalate from a cheap model to a strong one are something an operator defines and a developer opts into, never a substitution behind their back. ### Can we start with just the AI Gateway? Yes. It stands alone, with no ontology or programme behind it, and can be deployed on its own in a day; the first spend report per developer follows a week after go-live. The identity, policy and audit trail it puts in place are reused when you later govern agents, tools or retrieval. --- ## Azure API Management Alternative - Term: Azure API Management Alternative - URL: https://scrydon.com/platform/compare/azure-api-management-alternative/ **Definition.** The Scrydon AI Gateway is a sovereign alternative to Azure API Management's AI gateway: a single governed endpoint that speaks the standard model APIs — Anthropic Messages, OpenAI Chat Completions, OpenAI Responses and Gemini — so existing tools reach any model unchanged, where every call runs under the caller's own federated identity, against a clearance-gated model allowlist, with data loss prevention, a spend cap and an immutable audit trail. It shares one policy and one audit chain with governed tool calls and sandbox egress, and runs air-gapped, on-premises, on a European sovereign cloud or on Azure and Azure Local. Azure API Management has grown a capable AI gateway: policies that cap tokens per subscription, emit token metrics to Azure Monitor, cache semantically similar prompts, balance load across Azure OpenAI deployments and apply content safety — with a self-hosted gateway for hybrid estates. For an organisation whose models are Azure OpenAI and whose developers hold Azure subscriptions, it is a sensible answer. Its limits are structural rather than technical. It is a hyperscaler's control plane, which a sovereignty test on jurisdiction, keys and disconnected operation does not pass; a consumer is an API subscription, so attribution stops at the subscription; models outside Azure are a configuration exercise rather than the point; and governance ends at the API boundary while an agent's day is mostly tool calls. The Scrydon AI Gateway keeps the same developer experience — the standard APIs, unchanged tools — and moves the control point into your perimeter: a gateway key minted against a named person in your identity provider, any model by name, one policy and one audit chain across the model call, the tools the agent calls and the network its sandbox may reach. It runs on Azure and Azure Local too, which is often where the comparison ends up. ### FAQ ### What is the best alternative to Azure API Management as an AI gateway? The Scrydon AI Gateway, where the requirement is a control point the organisation owns wherever it runs — air-gapped, on-premises, on a European sovereign cloud or on Azure — with every call attributed to a person and governance that covers tool calls and sandbox egress, not the model call alone. If your models are Azure OpenAI, your developers hold Azure subscriptions and the estate stays in Azure, API Management is a sensible gateway. ### How is the Scrydon AI Gateway different from Azure API Management's AI gateway? Three ways. The control point lives in your perimeter rather than in a hyperscaler's control plane, so it passes the sovereignty tests on jurisdiction, keys and disconnected operation that the workload has to pass; a call runs as the person who made it, resolved through your own identity provider, rather than as an API subscription; and governance does not stop at the API boundary but covers the tools the agent calls and the network its sandbox may reach. What is the same: a governed address, token metering, and developers whose tools do not change. ### Can the AI Gateway run on Azure? Yes, and on Azure Local for on-premises Azure estates. Many organisations that compare the two end up running the AI Gateway on Azure: the point is not leaving Azure but owning the control point, with Azure OpenAI as one of the models behind it rather than the only one. ### Does the AI Gateway support Azure OpenAI and Azure AI models? Yes. Models served through your Azure tenancy sit behind the same endpoint as frontier vendor APIs and open-weight models on your own hardware, reached by name and swapped by configuration. A model that is named is the model that runs; nothing is silently substituted. ### Can we start with just the AI Gateway? Yes. It stands alone, with no ontology or programme behind it, and can be deployed on its own in a day; the first spend report per developer follows a week after go-live. The identity, policy and audit trail it puts in place are reused when you later govern agents, tools or retrieval. --- ## Portkey Alternative - Term: Portkey Alternative - URL: https://scrydon.com/platform/compare/portkey-alternative/ **Definition.** The Scrydon AI Gateway is a sovereign alternative to Portkey: a single governed endpoint that speaks the standard model APIs so existing tools reach any model unchanged, where every call runs under the caller's own federated identity rather than a virtual key, against a clearance-gated model allowlist, with data loss prevention, a spend cap and an immutable audit trail. It shares one policy and one audit chain with governed tool calls and sandbox egress, and runs air-gapped, on-premises or on a European sovereign cloud. Portkey is one of the most complete products in the LLM gateway category: an open-source gateway and a hosted platform around it, with a unified API across hundreds of providers, virtual keys and budgets, configurable guardrails, semantic caching, routing with fallbacks, prompt management and a strong observability layer. For a product team building on models it is a lot of value in one place. Its limits are the category's: attribution stops at a virtual key or the metadata a caller chooses to send; governance ends at the model call, while an agent's day is mostly tool calls against systems that hold your data; and the control plane is the vendor's unless you take on the self-hosted edition. The Scrydon AI Gateway keeps the developer experience — the standard APIs, any model, unchanged tools — and moves the control point into your perimeter: a gateway key minted against a named person in your identity provider, the allowlist following that person's clearance, and the same identity governing the tools the agent calls over MCP and the network its sandbox may reach. ### FAQ ### What is the best alternative to Portkey for a regulated organisation? The Scrydon AI Gateway, where the requirement is a control point the organisation owns wherever it runs, attribution to a person rather than a key, and governance that covers tool calls and sandbox egress. It speaks the same standard APIs, so the tools your developers use do not change, and it runs air-gapped, on-premises or on a European sovereign cloud. If the requirement is the broadest feature set in a hosted gateway, Portkey is a fair choice. ### How is the AI Gateway different from Portkey? A call runs as the person who made it, resolved through your own identity provider, rather than as a virtual key with caller-supplied metadata; governance covers the tools the agent calls and the network its sandbox may reach under one policy and one audit chain, rather than stopping at the model call; and the control plane is yours, in your perimeter, rather than the vendor's. What is the same: the standard APIs, any model behind the endpoint, developers who change nothing. ### Does the AI Gateway do prompt management and observability like Portkey? The AI Gateway meters and audits every call and reports spend, calls, tokens and carbon per developer, model, capability and workflow, and the platform's observability covers traces and evaluations for agents and workflows. Prompt management as a product feature is Portkey's strength, not the AI Gateway's focus; the AI Gateway is a governed route, deliberately narrow. ### Can we run Portkey ourselves — why would we need the AI Gateway? Portkey's gateway can be self-hosted, and for some teams that is the right answer. The AI Gateway is not a model-only gateway you run yourself but the system that holds your credentials and identity: a call runs as a person, tool calls and sandbox egress share the same policy, and the whole of it runs disconnected if the sovereignty tests require it. ### Can we start with just the AI Gateway? Yes. It stands alone, with no ontology or programme behind it, and can be deployed on its own in a day; the first spend report per developer follows a week after go-live. --- ## Kong AI Gateway Alternative - Term: Kong AI Gateway Alternative - URL: https://scrydon.com/platform/compare/kong-ai-gateway-alternative/ **Definition.** The Scrydon AI Gateway is a sovereign alternative to Kong AI Gateway: a single governed endpoint that speaks the standard model APIs so existing tools reach any model unchanged, where every call runs under the caller's own federated identity rather than an API consumer credential, against a clearance-gated model allowlist, with data loss prevention, a spend cap and an immutable audit trail. It shares one policy and one audit chain with governed tool calls and sandbox egress, and runs air-gapped, on-premises or on a European sovereign cloud. Kong AI Gateway is a sensible extension of a widely deployed API gateway: AI proxy plugins that put many providers behind one route, token-based rate limiting, prompt guards and templates, semantic caching and, more recently, support for fronting MCP servers — all governed with the consumers, keys and OpenID Connect plugins a Kong estate already uses, and deployable wherever Kong runs, including on-premises. For a platform team that treats AI as one more API, it is a fair answer. The limits are the limits of treating it that way. A consumer is an application or a team, so attribution stops there; an API gateway governs requests that pass through it, while the agent's tool calls and the sandbox it runs in do not; and model policy expressed as API policy has no notion of a person's clearance. The Scrydon AI Gateway keeps the developer experience — the standard APIs, any model, unchanged tools — and changes the subject of the policy: a gateway key minted against a named person in your identity provider, the allowlist following that person's clearance, and the same identity governing the tools the agent calls over MCP and the network its sandbox may reach. ### FAQ ### What is the best alternative to Kong AI Gateway for a regulated organisation? The Scrydon AI Gateway, where the requirement is attribution to a person rather than an API consumer, model policy that follows clearance, and governance that covers tool calls and sandbox egress. It speaks the same standard APIs, so developers change nothing, and it runs air-gapped, on-premises or on a European sovereign cloud. If AI traffic is one more API on an estate that already runs Kong, Kong AI Gateway is a fair choice. ### How is the Scrydon AI Gateway different from Kong AI Gateway? A call runs as the person who made it, resolved through your own identity provider, rather than as a consumer credential; model policy is expressed in terms of that person's clearance rather than as route-level API policy; and governance covers the tools the agent calls and the network its sandbox may reach under one policy and one audit chain, rather than stopping at requests that pass through the API gateway. What is the same: a governed route, token metering, and developers whose tools do not change. ### We already run Kong. Do we have to replace it? No. Kong keeps governing your APIs; the AI Gateway becomes the address your coding agents and applications call for models, and can itself sit behind Kong where that is your standard. The point is not to replace the API gateway but to give AI traffic a control point that knows who the person is and what their agent does next. ### Can the AI Gateway front MCP servers like Kong can? The platform governs tools over MCP, but not as a gateway in front of them: an agent calls tools under its human's delegated grant through a scoped identity, inside a sandbox whose egress is enforced outside the workload, with the same audit chain as the model call. Fronting an MCP server with an API gateway governs the request; this governs the actor. ### Can we start with just the AI Gateway? Yes. It stands alone, with no ontology or programme behind it, and can be deployed on its own in a day; the first spend report per developer follows a week after go-live. --- ## OpenRouter Alternative - Term: OpenRouter Alternative - URL: https://scrydon.com/platform/compare/openrouter-alternative/ **Definition.** The Scrydon AI Gateway is a sovereign alternative to OpenRouter: a single governed endpoint that speaks the standard model APIs so existing tools reach any model unchanged, deployed inside the organisation's own perimeter rather than as a hosted service, where every call runs under the caller's own federated identity, against a clearance-gated model allowlist, with data loss prevention, a spend cap and an immutable audit trail, and where model spend stays on the organisation's own vendor contracts. OpenRouter solved a real problem for developers: one key, one OpenAI-compatible endpoint, hundreds of models from every vendor, routing and fallbacks, and a bill by the token with no accounts to open. That is why it is in your organisation already, usually on personal cards. Its limits are the limits of a hosted intermediary. Every prompt and every response pass through a third party's infrastructure under that party's terms; a key stands for whoever holds it; there is no data loss prevention, no model policy tied to a person's clearance, and no audit an auditor would accept; and the organisation pays a marked-up consumption line with no ceiling it controls. The Scrydon AI Gateway keeps what developers came for — one address, any model, their tools unchanged — and puts it where a regulated organisation can use it: deployed in your perimeter, a gateway key minted against a named person in your identity provider, models reached on your own vendor contracts or on your own hardware, every call screened, metered against a cap and audited. Shadow AI is demand; this is how you meet it. ### FAQ ### What is the best alternative to OpenRouter for an organisation? The Scrydon AI Gateway, where the requirement is the same one-address convenience inside your own perimeter: every model reachable through the standard APIs, every call running as a named person with data loss prevention, a spend cap and an audit trail, and model spend on your own vendor contracts rather than a marked-up consumption line. OpenRouter remains a fair choice for an individual developer or a prototype. ### Our developers already use OpenRouter. What changes for them? A sign-in, a key, and a base URL in the environment. The tools stay the same, the models are chosen by name from the catalog the organisation allows, and prompt caching is preserved. What changes is on the other side of the connection: the call runs as the developer rather than as a key, it never leaves through a third party, and finance sees the spend per person instead of a card statement. ### Does the AI Gateway route across vendors like OpenRouter? It reaches frontier vendor APIs, models in your own cloud tenancy and open-weight models on your own hardware through one endpoint, chosen by name. It does not silently substitute a cheaper model: if a request names a model, that model runs or the request fails with a typed error. Escalation routes are something an operator defines and a developer opts into. ### Is OpenRouter a sovereignty problem? For a public body or regulated enterprise, yes: every prompt and response pass through a third party under its terms and jurisdiction, and there is no disconnected mode. The AI Gateway runs where your production runs, including air-gapped, and reaches vendors on your own contracts, so the sovereignty tests that apply to the workload also pass for the control point that sees every prompt. ### Can we start with just the AI Gateway? Yes. It stands alone, with no ontology or programme behind it, and can be deployed on its own in a day; the first spend report per developer follows a week after go-live — which, for an organisation coming off personal OpenRouter accounts, is usually the first inventory of AI use it has ever had. --- ## Cloudflare AI Gateway Alternative - Term: Cloudflare AI Gateway Alternative - URL: https://scrydon.com/platform/compare/cloudflare-ai-gateway-alternative/ **Definition.** The Scrydon AI Gateway is a sovereign alternative to Cloudflare AI Gateway: a single governed endpoint that speaks the standard model APIs so existing tools reach any model unchanged, deployed inside the organisation's own perimeter rather than at a provider's edge, where every call runs under the caller's own federated identity, against a clearance-gated model allowlist, with data loss prevention, a spend cap and an immutable audit trail, sharing one policy and one audit chain with governed tool calls and sandbox egress. Cloudflare AI Gateway is a pragmatic product: change a base URL and your model calls gain caching, rate limiting, retries and fallbacks, request logs and analytics, and optionally the storage of provider keys so applications hold none — with Cloudflare's usual reach and price. For a consumer-facing application on Cloudflare it is a sensible layer. Its limits are the limits of an edge gateway. It is a hosted intermediary, so every prompt and response pass through a third party's network under its terms and jurisdiction; a gateway is an application-level object, so attribution stops at the application; there is no model policy tied to a person's clearance and no data loss prevention in the regulated sense; and it sees the model call only, while an agent's day is mostly tool calls. The Scrydon AI Gateway keeps the base-URL simplicity — the standard APIs, any model, unchanged tools — and moves the control point into your perimeter: a gateway key minted against a named person in your identity provider, the allowlist following that person's clearance, every call screened, metered against a cap and audited, and the same identity governing the tools the agent calls over MCP and the network its sandbox may reach. ### FAQ ### What is the best alternative to Cloudflare AI Gateway for a regulated organisation? The Scrydon AI Gateway, where the requirement is a control point inside your own perimeter that attributes every call to a person, applies model policy by clearance, screens and caps, and follows the call into the tools the agent uses next. It is adopted the same way, by changing a base URL, and runs air-gapped, on-premises or on a European sovereign cloud. For a consumer-facing application on Cloudflare that wants caching and logs, Cloudflare AI Gateway is a fair choice. ### How is the Scrydon AI Gateway different from Cloudflare AI Gateway? Where it runs, who a call runs as, and how far the governance reaches. The Scrydon AI Gateway is deployed in your perimeter rather than at a provider's edge; a call runs as the person who made it, resolved through your own identity provider, rather than as an application's gateway token; and one policy and one audit chain cover the model call, the tools the agent calls and the network its sandbox may reach. What is the same: a base URL, any model, developers who change nothing. ### Is an edge gateway a sovereignty problem? For a public body or regulated enterprise, usually yes: every prompt and response pass through a third party's network under its terms and jurisdiction, and there is no disconnected mode. The AI Gateway runs where your production runs, including air-gapped, so the sovereignty tests that apply to the workload also pass for the control point that sees every prompt. ### Does the Scrydon AI Gateway cache like Cloudflare AI Gateway? It preserves the vendors' prompt caching end to end, forwarding cache breakpoints and reporting cache-split tokens back, which is what matters for a coding agent that re-sends its whole context every turn. Response caching at the edge is Cloudflare's feature, aimed at repeated identical requests from applications; the AI Gateway's job is the governed route, not a cache. ### Can we start with just the AI Gateway? Yes. It stands alone, with no ontology or programme behind it, and can be deployed on its own in a day; the first spend report per developer follows a week after go-live. --- ## Helicone Alternative - Term: Helicone Alternative - URL: https://scrydon.com/platform/compare/helicone-alternative/ **Definition.** The Scrydon AI Gateway is a sovereign alternative to Helicone: a single governed endpoint that speaks the standard model APIs so existing tools reach any model unchanged, where every call runs under the caller's own federated identity rather than a key with caller-supplied properties, against a clearance-gated model allowlist, with data loss prevention, a spend cap and an immutable audit trail — and with spend, calls, tokens and carbon reported per person, model, capability and workflow. It shares one policy and one audit chain with governed tool calls and sandbox egress, and runs air-gapped, on-premises or on a European sovereign cloud. Helicone is a well-liked product with an honest origin: put a proxy in front of your model calls, log everything, price it, and show it. Around that it has added the things a gateway needs — caching, rate limits, routing across providers, prompt tooling — and it is open source with a self-hosted option. Its limits are the limits of an observability-first design. Attribution is by key and by whatever properties the caller chooses to attach, so a dashboard can be as honest as the headers; observation is not enforcement, so a spend chart is not a cap and a log is not a policy; governance ends at the model call, while an agent's day is mostly tool calls; and the control plane is the vendor's unless you self-host. The Scrydon AI Gateway keeps the visibility — spend, calls, tokens and carbon per developer, model, capability and workflow, with an on-pace projection — and makes it enforcement: a gateway key minted against a named person in your identity provider, the allowlist following that person's clearance, every call screened and metered against a cap before the answer lands, and the same identity governing the tools the agent calls over MCP and the network its sandbox may reach. ### FAQ ### What is the best alternative to Helicone for a regulated organisation? The Scrydon AI Gateway, where the requirement has moved from seeing spend to controlling it: every call attributed to a person by the platform rather than by headers, model policy by clearance, a cap enforced before the answer lands, and governance that follows the agent into its tool calls and sandbox. It is adopted the same way, by changing a base URL, and runs air-gapped, on-premises or on a European sovereign cloud. For observability alone, Helicone is a fair choice. ### How is the AI Gateway different from Helicone? Helicone observes; the AI Gateway decides. A call runs as the person who made it, resolved through your own identity provider, rather than as a key with properties the caller attaches; a spend cap and a model allowlist are enforced at dispatch rather than reported afterwards; and governance covers the tools the agent calls and the network its sandbox may reach under one audit chain. What is the same: a base URL, any model, developers who change nothing — and a clear view of what it all costs. ### Do we lose Helicone's dashboards? The AI Gateway reports spend, calls, tokens and carbon for the month, attributed per developer and broken down by model, capability and workflow, with an on-pace projection against the cap and an export for finance. The platform's observability adds traces and evaluations for agents and workflows. Prompt experimentation tooling is Helicone's strength rather than the AI Gateway's focus. ### Helicone is open source and self-hostable. Why the AI Gateway? Self-hosting an observability proxy answers where the logs live. It does not make attribution a property of the platform rather than of headers, a chart into a cap, or a model call into the whole of what an agent does. The AI Gateway is the system that holds your credentials and identity, and the whole of it runs disconnected if the sovereignty tests require it. ### Can we start with just the AI Gateway? Yes. It stands alone, with no ontology or programme behind it, and can be deployed on its own in a day; the first spend report per developer follows a week after go-live. # Industries ## NATO & Allied Interoperability (Defence) - Term: Sovereign AI for NATO and allied interoperability - URL: https://scrydon.com/industry/defence/nato-interoperability/ **Definition.** For NATO and allied forces, Scrydon is the sovereign AI and data platform that aligns national data to shared models, fuses it into a common operating picture with per-nation releasability, orchestrates agents across domains and nations, and turns exercises into structured, comparable lessons, all on infrastructure the host nation controls. It runs air-gapped for classified networks, on a nation's own infrastructure or in a sovereign cloud, and the same platform serves a national headquarters and a coalition cell, which is what makes a coalition deployment accreditable. ### FAQ ### How does the platform handle NATO and national releasability rules? Through a data space in which each nation publishes the layers it authorises, per partner and per classification level, and every release is logged. The common picture is built from released layers, never from a pooled copy of national data. ### Which standards does the shared data model align with? The platform's ontology is aligned with standard data models where they exist for tracks, orders and reports, and mapped from national systems without changing them. The ontology-based data platform page explains how such mappings are built and maintained. ### Can it run on a classified coalition network with no internet? Yes. The full platform runs air-gapped, including open-weight models, retrieval and agents, with updates through the accredited channel and clearance enforced at retrieval. ### How do agents work across domains and nations without breaking command authority? Agent orchestration routes tasks across domains under agent identities scoped to a nation and a system set, and every order or retasking passes a human approval step that is recorded. ### Can exercise data from several nations be analysed together? Yes. Exercise tracks, orders, messages and observer reports are fused with data fusion onto a shared model of the exercise, each nation controlling what it contributes, so the after-action review replays events and records findings that carry to the next exercise. ### Is the coalition deployment the same platform a nation runs at home? Yes, and that is deliberate: one platform from the national headquarters to the coalition cell means one accreditation model and no gap between what was tested at home and what runs in the coalition. ### Does this cover NATO's own headquarters, commands and agencies, not just operations? Yes. The Alliance is an organisation of tens of thousands of people across a headquarters, two strategic commands, agencies and centres of excellence, and its procurement, personnel, facility and policy work runs on the same classified networks as the operational picture. The same platform serves both: agents prepare approvals, procurement cases and reports, retrieval answers from the Alliance's own documents at the reader's clearance, and a person decides. The defence departments and organisations page covers that back-office pattern in depth. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. For European Defence Fund calls and other funded R&D, see R&D and grant collaboration. --- ## Defence Departments & Organisations (Defence) - Term: Sovereign AI for defence departments and organisations - URL: https://scrydon.com/industry/defence/defence-departments/ **Definition.** For defence departments and organisations, Scrydon is the sovereign AI and data platform that runs governed agents and analytics across the defence back office, grounded in one ontology of units, assets, personnel and contracts, on classified and air-gapped networks, with legacy systems wrapped rather than replaced and every action attributed to an accountable person. It runs identically in a national sovereign cloud, in the ministry's own data centres and on disconnected classified networks, so there is one accredited stack from the unclassified service desk to the enclave, and one governance model for every agent. ### FAQ ### Can AI automate the defence back office without replacing our legacy systems? Yes. The platform models what the HR, logistics, finance and estate systems hold in one ontology and wraps the legacy systems with governed interfaces, so agents read and act through them. The systems of record stay where they are. ### Does it run on the classified network? Yes. The complete platform runs air-gapped with open-weight models served locally and updates through the accredited channel, and the same stack runs connected on the unclassified side, so there is one platform to accredit. ### How do we get one view of personnel, readiness and assets? By modelling units, people, qualifications, equipment and readiness once and mapping the existing systems onto it. The single source of truth for personnel and assets use case describes the pattern. ### How do we share with other departments and allies without handing over data? Through data spaces: the ministry publishes governed data products under its own access policy, and partners query them for an authorised purpose without a central copy. ### How is an agent's action attributed for the auditor? Every agent acts under a scoped identity, every action is logged, and every decision is taken by an accountable officer whose approval is recorded with the reasoning. That record is what the court of audit and the EU AI Act expect. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. For European Defence Fund calls and other funded R&D, see R&D and grant collaboration. --- ## During Missions (Defence) - Term: Sovereign AI during missions - URL: https://scrydon.com/industry/defence/during-missions/ **Definition.** During missions, Scrydon is the sovereign AI and data platform that fuses sensor, intelligence, geospatial and logistics feeds into a common operational picture on a battlespace ontology, keeps a live digital twin of units, assets and terrain, and orchestrates ISR, cyber, fires and logistics agents into one deconflicted plan for command approval, on air-gapped networks at headquarters or deployed. It runs as a sovereign cluster inside the classified enclave, at headquarters or deployed close to operations, with open-weight models served locally, so the same agents that process feeds in an exercise run identically in a denied environment. ### FAQ ### Can the platform run at the tactical edge without any connectivity? Yes. The platform is designed to operate with no internet connectivity, including on disconnected or intermittently connected networks. Open-weight models are served locally, so inference happens entirely inside the enclave, and updates arrive through controlled offline transfer. ### How does AI-based data fusion work during a mission? An ontology unifies sensor feeds, intelligence reports, geospatial layers and logistics data into a shared semantic model that analysts and agents reason over. Data fusion then correlates signals across those sources in near real time to surface threats, track entities and recommend courses of action, with every output traceable to its origin. ### Can agents coordinate multiple domains into one plan without taking command? Yes. A governed orchestration layer sequences ISR, cyber, logistics and fires agents and resolves conflicting recommendations into a single deconflicted course of action for command review. Every tasking and effect stops at a person, and the approval is recorded. ### Is there a live digital twin of the battlespace? Yes. The shared ontology underpins a continuously updated digital twin of units, assets, sensors and terrain, so planning and simulation run against the current operational picture rather than a static snapshot. ### How are agent actions attributed during an operation? Every agent operates under its own identity within a zero-trust model, so its permissions, data access and actions are scoped and attributable. All activity is captured in a tamper-evident audit trail under the platform's AI governance controls. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. For European Defence Fund calls and other funded R&D, see R&D and grant collaboration. --- ## Defence Industrial Base (Defence) - Term: Sovereign AI for the defence industrial base - URL: https://scrydon.com/industry/defence/defence-industrial-base/ **Definition.** For the defence industrial base, Scrydon is the sovereign AI and data platform that runs export-control-aware knowledge assistants, programme digital threads and supply-chain knowledge graphs inside the company's own infrastructure, with classification and export markings enforced at every retrieval and every action logged. It runs on-premises, in a sovereign cloud or fully disconnected for classified programmes, with open-weight models served locally, so the assistant itself never becomes an export event and the platform is one the customer's security authority can accredit. ### FAQ ### How does the platform enforce ITAR and EU dual-use export controls on engineering documents? Classification and export markings are indexed as first-class metadata and enforced at retrieval: an engineer's clearance, nationality, site and programme decide which documents an answer may draw on, and a question that would need documents outside that entitlement returns nothing from them, with the attempt logged. See enterprise RAG and AI governance. ### Does using an AI assistant on controlled data create an export event? Not when the models and the index stay inside the company's own perimeter, which is how the platform runs: on-premises, in a sovereign cloud or air-gapped, with open-weight models served locally and no data sent to an external service. ### Can the platform give us a digital thread without replacing our engineering tools? Yes. The ontology-based data platform models what requirements, MBSE, test and document systems hold and links the records across them. The tools stay the systems of record; verification status becomes a query. ### How do we demonstrate security of supply below tier one? An enterprise knowledge graph resolves bills of material, purchase history, supplier declarations and open sources into one map of parts, suppliers, sites and materials, surfacing single points of failure and jurisdiction risks, and it is shared with the customer as an assessment rather than raw data. ### Can the customer's security authority accredit this? That is the design goal: one platform that runs identically connected and disconnected, with a documented control set mapped to ISO 27001 and the Cyber Resilience Act, and an audit log produced by running it rather than written afterwards. ### Is this only for primes, or also for smaller suppliers? Both. A supplier with one programme and one site has the same export-control and traceability obligations as a prime. The platform's deployment options scale from a single on-premises installation upwards. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. For European Defence Fund calls and other funded R&D, see R&D and grant collaboration. --- ## EU Institutions, Bodies & Agencies (Government) - Term: Sovereign AI for the institutions, bodies and agencies of the European Union - URL: https://scrydon.com/industry/government/eu-institutions/ **Definition.** For the institutions, bodies and agencies of the European Union, Scrydon is the European-native sovereign AI and data platform that runs multilingual models, agents and analytics on the Union's own infrastructure, including EU-classified networks, with policy, identity and audit built to the standard of the EU AI Act and the supervision of the European Data Protection Supervisor. It runs in the institution's own data centres, in a European sovereign cloud or fully disconnected for classified information, with open-weight models served locally and no dependency on a non-European provider in the loop. ### FAQ ### Does the platform work across all official languages of the Union? Yes. Retrieval and agents work on the institution's own documents across the official languages and cite the source text, and the platform is model-agnostic, so the strongest open-weight multilingual models can be served locally. ### How does the platform help an institution apply the AI Act to itself? With a model inventory, shadow AI discovery, policy enforcement, logging, human oversight and documentation built into the way it runs. The EU AI Act page maps the controls. ### Can it run on EU-classified networks? Yes. The complete platform runs air-gapped with open-weight models served locally, updates through the accredited channel and classification enforced at retrieval. ### How do we work with member-state data without a central copy? Through data spaces: each national administration publishes governed data products under its own access policy, and a policy question is a query across them under a named legal basis, logged. ### Is there any dependency on a non-European provider? No. The platform is European-native and runs on European infrastructure with open-weight models; an external model can be enabled only by explicit opt-in under policy. See sovereignty. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## National & Federal Government (Government) - Term: Sovereign AI for national and federal government - URL: https://scrydon.com/industry/government/national-government/ **Definition.** For national and federal government, Scrydon is the sovereign AI and data platform that runs models, agents and analytics on ministerial and agency data inside state-controlled infrastructure, including fully air-gapped classified networks, and lets ministries share governed data products without any of them giving up control. It runs identically in a national sovereign cloud, on government data centres and on disconnected classified networks, so there is one platform to accredit and one governance model from the unclassified service desk to the classified enclave. ### FAQ ### How do air-gapped AI deployments work for sensitive government data? The complete platform, including open-weight models, retrieval indexes, agents and analytics, runs inside the classified network with no outbound connection. Models and software updates arrive through the network's accredited import channel, such as approved media or a data diode, and every update is recorded. Retrieval enforces document clearance markings, so nothing is served above the reader's clearance. See air-gapped deployment and air-gapped AI. ### Can ministries analyse data together without a central data warehouse? Yes. In a data space each ministry keeps its data where it is and publishes governed data products under its own access policy. A cross-ministry question is a query over those products, executed under a named legal basis and logged, with aggregation or pseudonymisation enforced where the law requires. ### How does the platform help with EU AI Act readiness across a government? By making AI use visible and governed: shadow AI discovery finds what is already in use, the model inventory and policy engine classify and control it, and logging and human oversight meet the high-risk obligations. The EU AI Act page maps the controls. ### Is one platform enough for both the unclassified and the classified side? Yes, and that is the point for accreditation: the same stack, governance and audit on both sides means one assessment, one evidence set and no gap between the pilot environment and the network where the work is. ### What about a national sovereign cloud or a government data centre? The platform runs in a sovereign cloud that meets national requirements, on government data centres, or on-premises, and moves between them without re-architecting. ### How is agent access to ministerial systems controlled? Agents are first-class identities under a zero-trust identity model, with scoped permissions per system and per action. Every action is attributed and logged, so the auditor can see who or what did what. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Local & Municipal Government (Government) - Term: Sovereign AI for local and municipal government - URL: https://scrydon.com/industry/government/local-government/ **Definition.** For local and municipal government, Scrydon is the sovereign AI and data platform that runs citizen-facing assistants, case automation and infrastructure analytics on the municipality's own regulations and data, inside infrastructure it controls, with the human decision and the transparency record the EU AI Act asks of a public authority. It runs in a national or regional sovereign cloud, on shared public-sector infrastructure or on-premises, and the same platform can be operated by a region or an intermunicipal body for many municipalities at once. ### FAQ ### Can a municipal assistant answer in every language our residents speak? Yes. The assistant is grounded in the municipality's own regulations through enterprise RAG and answers in the languages the community speaks, citing the article or decision behind every statement. It hands over to a civil servant when a question becomes a request. ### Does the platform make permit or benefit decisions? No. Agents prepare the file, check it against the rule and draft the decision; a civil servant decides, and the decision is attributed and logged. Discretionary elements are flagged for a person rather than automated. See AI governance. ### What does the EU AI Act require from a municipality using AI? Transparency to residents when they interact with AI, and for uses that affect access to public services or benefits, the high-risk obligations: logging, human oversight and documentation. The EU AI Act page maps the controls. ### Can a region or intermunicipal body run this for many municipalities? Yes. One platform instance can serve many municipalities, each with its own regulations, data and access, on shared public-sector infrastructure or a sovereign cloud. ### Our asset data is spread across GIS, works and finance systems. Do we have to migrate it? No. The platform models what those systems hold in one ontology and connects the records, so a road, a sewer or a building has one representation while the systems of record stay where they are. ### We piloted a chatbot. Why did it not scale? Pilots usually lack the platform underneath: governed sources, a case model, agent identity, audit and a deployment the data protection officer accepts. Moving to organisational AI is putting that platform in place, and it is what this page describes. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Police & First Responders (Government) - Term: Sovereign AI for police and first responders - URL: https://scrydon.com/industry/government/police-and-first-responders/ **Definition.** For police and first responders, Scrydon is the sovereign AI and data platform that runs case analysis, dispatch support and multi-agency incident pictures inside the service's own infrastructure, with every AI action attributed, logged and subject to human decision, as the Law Enforcement Directive and the EU AI Act's high-risk rules require. It runs on the service's own infrastructure or a national sovereign cloud, disconnected where classification requires, with open-weight models served locally, so audio, case files and incident data never leave the organisation responsible for them. ### FAQ ### Is AI in policing allowed under the EU AI Act? Several law-enforcement uses are classified high-risk under the EU AI Act, which means they are permitted with obligations: risk management, logging, human oversight, documentation and accuracy. Some uses are prohibited outright. The platform is built to meet the high-risk obligations, and its governance controls let a service show which uses it runs and under which conditions. ### How does the Law Enforcement Directive change how the platform is deployed? Processing for law-enforcement purposes falls under the Law Enforcement Directive rather than GDPR, with the competent authority as controller. The platform runs on infrastructure that authority controls, applies its access model, and logs every processing step, so the data protection officer can demonstrate lawful processing. ### Can an investigator's question be traced back to the evidence? Yes. Every answer from the case graph cites the pages it came from, so a lead is checked by a person before it becomes an action and the trail can be shown to a court or to the defence. AI governance records prompts, sources and outputs. ### Does the platform dispatch units or make arrests decisions on its own? No. Dispatch proposals and case leads are suggestions. A dispatcher, investigator or commander confirms, changes or overrides them, and the override is recorded. The platform's orchestration is designed around that human step. ### How do partner agencies share an incident picture without handing over their systems? Through a data space: each agency publishes the layers it authorises, at the level each partner is entitled to see, and the fused picture runs on infrastructure the lead agency controls. ### Can it run disconnected for sensitive investigations? Yes. The complete platform runs air-gapped, with open-weight models served locally and the same audit as a connected deployment. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Utilities (Critical Infrastructure) - Term: Sovereign AI for utilities - URL: https://scrydon.com/industry/critical-infrastructure/utilities/ **Definition.** For utilities, Scrydon is the sovereign AI and data platform that brings SCADA, metering, GIS and asset data into one governed model, runs forecasting and agents on it inside the operator's own infrastructure, and produces the incident, activation and audit records NIS2 and the regulator expect. It runs identically on-premises, in a national sovereign cloud or fully disconnected, so the same platform serves the control room, the asset planners and the security team, and the operational-technology boundary stays where the operator drew it. ### FAQ ### How does the platform help a utility meet NIS2 incident-reporting deadlines? By making the first day shorter. The platform correlates SIEM alerts, OT alarms and change records against a model of your own services and assets, so an incident opens with the affected services identified and the evidence attached. Agents draft the 24-hour early warning and the 72-hour notification from that record; a named person reviews and sends. See NIS2 for the controls behind it. ### Can it run on the operational-technology network, disconnected from the internet? Yes. The complete platform, including open-weight models, runs air-gapped with no outbound connection, and updates arrive through the channel your OT security policy already approves. The same stack runs connected for the corporate side, so there is one platform to accredit. ### Does this replace our SCADA, historian or asset-management system? No. Those systems stay the systems of record. The platform models what they hold in one ontology and connects the records across them, so a substation, a feeder or a work order has one consistent representation without migrating anything. ### How do you keep an AI agent from acting on the grid without a human? Agents run under scoped identities with permissions per system and per action, and every operational action goes through your existing approval workflow. An agent can draft an activation or a work order; a person approves it, and both the draft and the approval are logged. ### Is smart-meter data safe to use for forecasting? Smart-meter data is personal data under GDPR and operationally sensitive under NIS2. On the platform it is processed on your own infrastructure, inside your jurisdiction, under access policies you set, and the activation record the regulator expects is produced as a by-product of running the forecast. ### We have run AI pilots on outage prediction. What is different here? The pilot proved the model; production needs the platform underneath it: a shared network model, governed data, agent identity, audit and the deployment your security team will accept. That is the move from a pilot to organisational AI, and it is what the platform provides. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Telecommunications (Critical Infrastructure) - Term: Sovereign AI for telecommunications operators - URL: https://scrydon.com/industry/critical-infrastructure/telecommunications/ **Definition.** For telecommunications operators, Scrydon is the sovereign AI and data platform that models the network and its services as one graph, correlates alarms and predicts faults on it, runs subscriber-facing agents inside the operator's own infrastructure, and produces the incident and audit records NIS2 requires. It runs on the operator's own infrastructure, in a national sovereign cloud or disconnected for the most sensitive network segments, with open-weight models served locally, so no alarm, topology or subscriber record is ever sent outside. ### FAQ ### How does the platform reduce alarm noise in the network operations centre? By treating correlation as a topology problem. The network is modelled as a graph of sites, elements, links and services, and alarms are grouped under the element whose failure explains them, with the affected services and customers listed. That is data fusion over an ontology, not another rules engine. ### Can AI agents handle customer cases without subscriber data leaving the operator? Yes. Agents on the Agentic AI Platform run on the operator's own infrastructure, read subscriber records inside the perimeter, act through the existing billing and provisioning systems under a scoped identity, and hand over to a person when a request leaves policy. No data is sent to a third-party model. ### How does this support NIS2 for a telecommunications operator? Incidents open with the affected services already identified from the network model, the evidence attached, and the early warning drafted for review. The reviews, approvals and policy decisions are logged, which is the evidence base NIS2 supervision expects. ### We run a multi-vendor network. Is the platform tied to any vendor's equipment or cloud? No. The platform is model-agnostic, integrates with inventory, OSS and BSS systems through their interfaces, and runs on the operator's own infrastructure or a sovereign cloud of the operator's choosing. ### Can the most sensitive network segments be kept disconnected? Yes. The full platform runs air-gapped for segments where connectivity itself is the risk, with the same models, agents and audit as the connected deployment. ### How is this different from the AI features our network vendors already sell? Vendor features see one vendor's domain. The platform models the whole network and the customer on top, across vendors and across OSS and BSS, and keeps that model and the AI on it under the operator's control. It is the layer for organisational AI rather than a feature in one console. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Transport (Critical Infrastructure) - Term: Sovereign AI for transport infrastructure - URL: https://scrydon.com/industry/critical-infrastructure/transport/ **Definition.** For transport, Scrydon is the sovereign AI and data platform that models the network's assets, systems and flows in one ontology, runs predictive maintenance, flow optimisation and incident-response agents on it inside the operator's own infrastructure, and produces the NIS2 incident and audit records the regulator expects. It runs on-premises, in a national sovereign cloud or air-gapped for the control network, with open-weight models served locally, so the same platform serves the control room, the asset planners and the security team. ### FAQ ### Can the platform run on the signalling or control network? Yes. The complete platform runs air-gapped with open-weight models served locally and updates through the channel the operator's OT security policy approves, and agents run under scoped identities that keep them away from controllers. ### How does predictive maintenance work across GIS, asset and control systems? The platform models what those systems hold in one ontology, fuses sensor and inspection history onto it, and forecasts failure risk per asset. See predictive infrastructure maintenance and the asset and network model. ### How does it help during a major disruption? Vehicle positions, sensor feeds, weather and partner data are fused into one incident picture with data fusion, shared with emergency services and the municipality through a data space at the level each is entitled to, and the NIS2 notification is drafted from the record. ### How does the platform support NIS2 for a transport operator? Incidents open with the affected services identified from the network model, the evidence attached and the early warning drafted for review; reviews and approvals are logged. See NIS2. ### Do we have to replace our asset-management or control systems? No. They stay the systems of record; the platform connects the records across them and runs the models and agents on top. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Banking (Financial Services) - Term: Sovereign AI for banks - URL: https://scrydon.com/industry/fsi/banking/ **Definition.** For banks, Scrydon is the sovereign AI and data platform that unifies core, card, onboarding and case data in one financial ontology, runs real-time fraud, financial crime and credit models and agents on it inside the bank's own infrastructure, and produces the model-governance and audit records DORA, GDPR and the EU AI Act require. It runs on-premises, in a sovereign cloud or in the bank's own tenancy, with open-weight models served locally and every model, dataset and agent action versioned, attributed and logged. ### FAQ ### Can we run real-time fraud and financial-crime detection on the platform? Yes. Models run on streaming and historical data on the bank's own infrastructure, with features from the financial ontology, and agents orchestrate detection, triage and response. See real-time fraud detection and financial crime network investigation. ### How does the platform support DORA? With resilient self-hosted deployment that reduces concentration risk on a single provider, detailed audit trails, access logging and policy enforcement, and the documentation and traceability ICT risk management requires. See DORA. ### How are model decisions explained to a customer or the supervisor? Every model, dataset and agent action is versioned, attributed and logged under AI governance, and the ontology links a decision to the data and business concepts behind it, so a declined payment or a filed report can be traced end to end. ### Does customer data stay protected from the cloud operator? Yes. Confidential computing keeps data encrypted in use, and the platform can also run fully on-premises. ### We have copilots in pilot. How do we move to bank-wide, governed AI? By putting the platform underneath them: shared model serving, a common data and ontology layer, federated identity and consistent policy controls. That is the move to organisational AI. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Insurance (Financial Services) - Term: Sovereign AI for insurers - URL: https://scrydon.com/industry/fsi/insurance/ **Definition.** For insurers, Scrydon is the sovereign AI and data platform that unifies policy, claims, actuarial and external data in one insurance ontology, runs underwriting, claims and fraud models and agents on it inside the insurer's own infrastructure, and produces the model-governance, fairness and audit records DORA, GDPR, Solvency II and the EU AI Act require. It runs on-premises, in a sovereign cloud or in the insurer's own tenancy, with open-weight models served locally and every model, dataset and agent action versioned, attributed and logged. ### FAQ ### Can AI decide on claims or pricing on its own? Where the law reserves a decision for a person, the platform routes it there: agents prepare the file, models score, and an underwriter or handler decides, with the decision and reasoning recorded. The Human+AI loan underwriting pattern applies to insurance underwriting as well. ### How are pricing and claims decisions kept fair and explainable? Every model is versioned, its inputs traced through the ontology and its outcomes monitored under AI governance, so a decision can be explained to the customer and the supervisor and drift or bias is visible. ### How does the platform support DORA and Solvency II? With resilient self-hosted deployment, audit trails, access logging and policy enforcement for DORA, and governed data and model lineage from which solvency and conduct reports are drafted. See regulatory reporting. ### Can we detect claims fraud before payment? Yes. Fraud and triage models run in real time on the insurer's own infrastructure and agents assemble the evidence for the handler, so suspicious claims are held and genuine ones move faster. ### Is health data protected from the cloud operator? Yes. Confidential computing keeps it encrypted in use, and the platform can run fully on-premises. See GDPR. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Capital Markets (Financial Services) - Term: Sovereign AI for capital markets - URL: https://scrydon.com/industry/fsi/capital-markets/ **Definition.** For capital markets, Scrydon is the sovereign AI and data platform that fuses positions, market data, flows and reference data into one live financial ontology, runs risk, surveillance and decision-intelligence models and agents on it inside the firm's own perimeter, and keeps the versioned, attributed record that MiFID II, DORA and the EU AI Act expect. It runs on-premises, in a sovereign cloud or in the firm's own tenancy, with open-weight models served locally, proprietary models and licensed data never leaving the perimeter, and every model and agent action logged. ### FAQ ### Can the platform turn a risk signal into an action rather than another dashboard? Yes. Decision intelligence connects the ontology to the next operational step, so a flagged exposure or credit signal becomes a recommended limit change, hedge or alert routed through the firm's approval workflow, with the reasoning preserved. See decision intelligence for credit and trading desks. ### Do our proprietary models and licensed data stay inside the firm? Yes. The platform runs on the firm's own infrastructure or a sovereign cloud, with open-weight models served locally; strategies, models and licensed data never leave in an inference call, and external models are opt-in under policy only. ### How does it support surveillance and market-abuse detection? Orders, executions, communications and market data are fused on the financial ontology in real time, so surveillance models and entity-linking agents see the trade in its context rather than in a batch the next day. ### What about MiFID II and DORA record-keeping? Every model version, data input, agent action and approval is versioned and logged under AI governance, and self-hosted deployment reduces the concentration risk DORA supervises. ### Can risk analytics run on the same platform as the desk's data? Yes. The platform's analytics layer runs high-throughput, low-latency analytics over streaming and historical data, so risk and compliance work on the live state the desk sees. See algorithmic risk management. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Hospitals & Care Providers (Healthcare) - Term: Sovereign AI for hospitals and care providers - URL: https://scrydon.com/industry/healthcare/hospitals/ **Definition.** For hospitals and care providers, Scrydon is the sovereign AI and data platform that runs clinical decision support, patient-flow optimisation and care-coordination agents on one clinical ontology of patients, encounters, resources and pathways, inside the institution's own infrastructure, with the clinician deciding and an audit trail that satisfies GDPR and the EU AI Act's rules for medical use. It runs on-premises, in a national sovereign cloud or on shared health-sector infrastructure, and one platform can serve a hospital group while each institution keeps its own data, access model and governance. ### FAQ ### Does the platform make clinical decisions? No. Decision support proposes and cites the record it drew on; a clinician decides. That human step is mandatory in the platform's orchestration, and the clinical decision support use case shows how it is set up. ### Can we use AI on patient records without sending them anywhere? Yes. The platform runs on the hospital's own infrastructure or a sovereign cloud, with open-weight models served locally, so no note, record or image is sent to an outside AI service. ### How does it help with patient flow and backlogs? Admissions, discharges, diagnostics, theatres and staffing are modelled together on the clinical ontology, so decision intelligence can recommend bed, theatre and backlog actions against the live state. See elective care backlog recovery. ### Do we have to replace our electronic patient record? No. The platform models what the record and the departmental systems hold in one ontology and connects the records; the systems of record stay where they are. ### What does the EU AI Act require for AI in clinical use? Human oversight, logging, documentation and risk management for high-risk use, on top of medical-device rules where they apply. The EU AI Act page maps the platform's controls; GDPR and NIS2 cover the data and the institution. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Life Sciences (Healthcare) - Term: Sovereign AI for secure life-sciences research - URL: https://scrydon.com/industry/healthcare/life-sciences/ **Definition.** For life sciences, Scrydon is the sovereign AI and data platform that runs models, retrieval and agents on research, clinical and manufacturing data inside the organisation's own perimeter, with data-loss prevention on every prompt and output, egress controls on every outbound connection, study-scoped access, and an immutable audit trail that satisfies GDPR, the EU AI Act and the organisation's own IP policy. It runs on-premises, in a sovereign cloud, or fully disconnected for the most sensitive programmes, with open-weight models served locally and external models available only by explicit, policy-gated opt-in, so the default is that nothing leaves. ### FAQ ### How do you stop researchers from leaking trial data or compound information through AI? With data-loss prevention in the loop and egress controls at the edge. A guardrails engine inspects every prompt, retrieved passage and model output for patient identifiers, structures, unpublished results and the patterns your policy names, and blocks or redacts them. Agents and models cannot reach the internet or an external model unless a policy explicitly allows it, and every block, override and outbound call is logged. See AI governance. ### Can we use a frontier model for some tasks without exposing our data? Yes, by opt-in. The platform is model-agnostic: the default is open-weight models served inside your perimeter, and an external model can be enabled for a defined purpose under policy, with data-loss prevention on what is sent and a record of what was. It is a decision, never a default. ### How do we run analysis across sponsors, sites and partners without pooling patient data? Through data spaces and federated analysis: each party keeps its data where it is, publishes governed data products under its own access policy, and the study computes across them. The federated clinical trials use case describes the pattern. ### Is trial data protected from the cloud operator? Yes. Confidential computing keeps data encrypted in use inside hardware-isolated enclaves, so even a privileged infrastructure operator cannot read it, and the most sensitive programmes can run air-gapped. ### How does this help with GDPR and the EU AI Act for research? Classification, study scope, purpose and retention are metadata enforced at access time, pseudonymisation is applied in the data product where required, and every processing step is in an immutable audit log. The GDPR and EU AI Act pages map the controls. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. --- ## Public Health (Healthcare) - Term: Sovereign AI for public health authorities - URL: https://scrydon.com/industry/healthcare/public-health/ **Definition.** For public health, Scrydon is the sovereign AI and data platform that lets authorities, agencies and insurers analyse population, claims and surveillance data across controllers through governed data spaces and federated analysis, run crisis and screening logistics on it, and report to regulators, all inside state-controlled infrastructure with a named legal basis on every query. It runs in a national sovereign cloud or on the authority's own infrastructure, and the same data-space model serves the hospitals, insurers and research bodies the authority works with, each keeping its own data. ### FAQ ### How can we analyse across registries, claims and hospitals without a central health data warehouse? Through data spaces: each controller keeps its data and publishes governed data products under its own access policy, and a public-health question is a query across them, executed under a named legal basis and logged, with aggregation or pseudonymisation enforced where the law requires. ### Can the platform support outbreak surveillance? Yes. Lab reports, syndromic feeds, wastewater signals and hospital data are fused with data fusion on a shared health ontology and modelled continuously, so signals surface before the weekly report and are traceable to their sources. ### How does it help allocate vaccines, equipment or screening capacity in a crisis? Decision intelligence turns a shortage forecast or an outbreak signal into a recommended allocation, routed to the official who approves it. The crisis supply allocation use case describes the pattern. ### How is GDPR respected when several controllers are involved? The legal basis, purpose and retention period are part of every query, and the data product enforces aggregation or pseudonymisation where required. Every access is logged against the basis that allowed it. See GDPR. ### Can insurers and research bodies take part on the same terms? Yes. The data-space model is the same for a hospital, an insurer or a health data access body: each publishes what it may, under its own policy, and computes on the rest under an authorised purpose. ### Do you partner on tenders and framework contracts? Yes, always. We are always looking to partner with primes, integrators and consortia on tenders, RFPs, framework contracts and European programmes, as the sovereign AI and data platform inside a larger bid or as a specialist subcontractor. If you are preparing a bid, talk to us early. # Insights - [Bun 1.4.3 at Scrydon: Our Type-Check Gate Moves to bun check](https://scrydon.com/insights/2026/10/12/bun-check-at-scrydon/): Bun 1.4.3 shipped bun check, a TypeScript type checker ported from typescript-go, on 10 October. - [Where OpenShell Fits in a Production Agent Platform](https://scrydon.com/insights/2026/09/29/where-openshell-fits-in-a-production-agent-platform/): Comparing NVIDIA OpenShell 0.1.2 to our own Agent Runtime, better in some points, worse in others. - [Dependency Is Not Dependence](https://scrydon.com/insights/2026/09/21/dependency-is-not-dependence/): Scrydon joined NVIDIA Inception this month. - [Scrydon position on the Cloud and AI Development Act](https://scrydon.com/insights/2026/09/10/sovereignty-is-a-trajectory-making-cada-work-for-progressive-independence/): Scrydon position on the Cloud and AI Development Act — COM(2026) 502 final, 2026/0138(COD). - [Enterprise AI Is Not a Bigger Copilot](https://scrydon.com/insights/2026/09/08/enterprise-ai-is-not-a-bigger-copilot/): The market defines enterprise AI as a scope. - [Your AI Gateway Governs One Protocol. Your Developers Use Three.](https://scrydon.com/insights/2026/09/02/your-ai-gateway-governs-one-protocol/): AI gateways solved keys, routing and spend visibility — and they were right to. - [Bun 1.4 at Scrydon: A Quiet Upgrade With Loud Early Numbers](https://scrydon.com/insights/2026/08/21/bun-1-4-at-scrydon/): Bun 1.4 — the first stable release after Bun's runtime was rewritten from Zig to Rust — shipped on 20 August. - [Why, How, Prove, Scale, Ground: The Sovereign AI Series — Five Webinars, and the Reasoning Behind Them](https://scrydon.com/insights/2026/08/17/the-sovereign-ai-series-why-how-prove/): Between 3 September and 29 October we are running five 45-minute sessions, each for a different person in the same building: the executive who has to decide, the engineer who has to run it, the security officer who has to sign it off, the leader who has to make it how the organisation works — and the data leader whose lakehouse it all has to stand on. - [The Harness Holds](https://scrydon.com/insights/2026/08/14/the-harness-holds/): This summer, frontier AI labs disclosed that models under evaluation escaped their sandboxes and reached real third-party infrastructure. - [What Palantir Got Right With Ontologies](https://scrydon.com/insights/2026/07/24/what-palantir-got-right-with-ontologies/): Palantir put the ontology — not the LLM — at the centre of enterprise AI, and that architectural bet is being proven right. - [Who Needs an AI OS?](https://scrydon.com/insights/2026/07/09/who-needs-an-aios/): Every organisation runs on processes. - [Scrydon at VivaTech: Reflections on Sovereignty and the Cognitive Enterprise](https://scrydon.com/insights/2026/06/22/reflections-from-vivatech-sovereignty-and-the-cognitive-enterprise/): Reflections from VivaTech 2026 in Paris, days after a US 'killswitch' cut Europe off from frontier AI models. - [Updated EU Cloud Sovereignty Calculator, aligning to the European Commission's scoring](https://scrydon.com/insights/2026/06/02/eu-cloud-sovereignty-calculator-updated/): Following the European Commission's publication of its Cloud Sovereignty Framework Implementation Guidance, we've updated our free sovereignty assessment calculator to reflect the full 48-criterion scoring model used in the Commission's own EUR 180 million cloud procurement. - [Building the AI Assembly Line: How Scrydon's Cognitive Enterprise turns McKinsey's vision into Reality](https://scrydon.com/insights/2026/05/30/mckinsey-building-the-ai-assembly-line-with-cognitive-enterprise/): How Scrydon's Cognitive Enterprise implements McKinsey's AI assembly line for sovereign, regulated organisations. - [The NSA Just Flagged MCP Security — Here's What It Means](https://scrydon.com/insights/2026/05/26/why-mcp-security-matters-agentic-workflows/): MCP's rapid adoption has outpaced its security model. - [Reflections from NATO TIDE Sprint 44 in Istanbul: Building the Cognitive Alliance](https://scrydon.com/insights/2026/05/09/reflections-from-nato-tide-sprint-44-istanbul/): Key takeaways from NATO TIDE Sprint 44 in Istanbul — how AI, data fusion, agentic orchestration, and sovereign platforms are shaping the future of multi-domain operations. - [Law & AI at UC Law SF: Governance, Power and the New Liability Map](https://scrydon.com/insights/2026/03/13/law-and-ai-at-uclaw-sf-governance-power-and-the-new-liability-map/): Law & AI at UC Law SF: Governance, Power and the New Liability Map - [AI sovereignty is won in the execution layer](https://scrydon.com/insights/2026/02/24/middle-power-ai-sovereignty/): Middle powers don’t have to choose between US and Chinese AI stacks. - [Hello World: Introducing Scrydon](https://scrydon.com/insights/2026/01/15/hello-world/): Welcome to Scrydon. # Key pages - [Scrydon home](https://scrydon.com/): Sovereign AI OS and data platform overview. - [Sovereignty](https://scrydon.com/sovereignty/): Why and how Scrydon delivers European data and AI sovereignty. - [Training](https://scrydon.com/training/): Training and enablement for the Scrydon platform. - [Contact us](https://scrydon.com/contact-us/): Get in touch with the Scrydon team.