OpenKnowra CIO FAQ: 24 Questions Enterprise Leaders Ask

1. What is OpenKnowra?

Spire.AI OpenKnowra Enterprise AI Platform with Governed Context Engineering helps you build enterprise AI faster on live context, governed reasoning, and autonomous yet deterministic action. It compiles live context from your systems and documents, applies the business logic you approve, and runs agents that act only within the boundaries you set, with every decision traceable and replayable.

2. How does the platform work, end to end?

The platform works in three steps, connect, decide and act, with governance built into each. First, OpenKnowra connects to the systems and documents you already run and builds a live context of your business from them. It then applies your business rules (SOPs, approval limits, policies) to that context. AI agents carry out decisions only within the authority you give them, and every step is recorded, so you can always see why something happened. You build the logic once, govern autonomy once, and reuse both across every agent and use case.

These steps map to three platform layers. The Context Compiler connects enterprise systems, applications, documents, events and data, resolves them against an industry ontology, and continuously builds a live, evolving Enterprise Context Graph. The Logic Controller turns SOPs, process documents, policies, business rules and operating guidelines into governed decision logic, versioned and kept separate from the context. The Action Builder creates reusable AI agents, digital workers and workflows, with agent-to-agent orchestration, autonomy governance, observability and control built in.

3. How is OpenKnowra different from RAG, knowledge graphs and conventional agent platforms?

RAG, knowledge graphs and agent platforms each solve one part of the problem. OpenKnowra brings the full chain together in one platform, from live context to governed decisions to governed action:

RAG retrieves relevant passages to answer a question. OpenKnowra reasons over resolved entities, live state, permissions and policy to reach a decision, and uses retrieval only to find supporting evidence.

A knowledge graph gives you a static model of how things relate, as they were modeled. OpenKnowra’s Enterprise Context Graph is live: it is updated continuously from your systems, documents and events, records the source of every fact, and stores each decision with the evidence and rules behind it.

An agent platform makes agents easy to build, but leaves the context, business rules and control to you. OpenKnowra builds all three in, so agents act only within the boundaries you set, with every decision traceable and replayable.

4. Does it replace anything we already run?

OpenKnowra is designed to complement the technology you already have, not replace it. Your ERP, CRM and HR systems stay in charge of their data, and your data warehouse stays your analytics store. OpenKnowra reads from them and writes approved actions back, so you add governed AI decisions without migrating anything.

Context is served to applications and agents, including ones you have already built, through REST APIs and an MCP server, and agents collaborate over A2A. If you already operate an enterprise graph platform, the context graph can be built on top of it.

5. What technology sits underneath, and does it tie us to one vendor?

OpenKnowra is built on standard graph technology and does not tie you to a single vendor. The context graph runs on Neo4j by default and can run instead on Amazon Neptune or on a graph platform you already operate, reusing your existing licenses, infrastructure and skills.

The graph layer is storage-agnostic. Neo4j is the default persistence layer and production reference implementation; other openCypher-compatible stores such as Amazon Neptune are supported, with compatibility and performance validated during onboarding. RDF-based stores need additional integration effort, scoped and estimated upfront. The reasoning layer is proprietary and sits behind a storage abstraction designed to minimize dependence on vendor-specific graph features.

6. Which AI models does it use, and can we change them?

You can use the model of your choice, open or closed, and switch later without rewriting your business rules, because the rules and decisions do not live inside the model.

Language models work at the edges: translating natural-language questions into graph queries, and extracting entities and relationships from documents during ingestion. Extracted items are validated against the ontology before they are stored, and each keeps its source provenance.

7. Are OpenKnowra decisions consistent and repeatable?

Yes. Every decision in OpenKnowra is grounded in the context graph, not generated by an LLM, so it is deterministic rather than probabilistic. Given the same data and the same rules, it returns the same decision every time, so outcomes do not drift and every decision can be traced and defended in an audit.

8. Do you use embeddings or vector search?

OpenKnowra uses them only to find supporting evidence, never to make the decision itself. This keeps decisions consistent while still drawing on what is in your documents.

Embeddings and vector search are used in two places, both outside the reasoning path: semantic retrieval across unstructured documents to surface supporting evidence, always with a reference to the source document; and mapping terms in documents and questions to ontology concepts.

9. Where does our data live, and who owns it?

Your data stays where your policies require, and it remains yours. By default OpenKnowra runs as a hosted SaaS platform on AWS; deployment on Azure, GCP or on-premises is also supported. The context graph can also be hosted within your own environment, with the deployment approach agreed jointly with your team. Data residency, access controls and backups follow your existing security and governance standards. Your data remains your property and can be exported on request and at contract end.

10. Is our data used to train models?

Spire.AI does not use your data to train its models.

11. What kinds of data sources does OpenKnowra support?

OpenKnowra supports both structured and unstructured data. Structured data from your systems of record provides the core business information; unstructured content from documents, tickets, transcripts and conversations adds the context those systems never capture. Both go into one model of your business, so agents reason across them together.

Structured sources span ERP, finance, procurement, supply chain, CRM, customer service, CLM, ITSM, CMDB, identity and access, observability, data warehouses, MDM, HR systems, and industry systems such as core banking, EHR, MES and PLM.

Unstructured sources include contracts, SOPs and policies, regulatory and audit reports, support tickets, call and meeting transcripts, email and chat. All of it is validated against the ontology on the way in, and everything extracted from a document keeps a link to its source.

12. How much integration work does it take to connect our core systems?

Most of the work is configuration, not development. OpenKnowra comes with a standard library of more than 50 connectors covering HR, ERP, procurement, CRM, service management, databases, data warehouses, and security and IT systems, plus connectors to integration platforms such as MuleSoft and Boomi. Additional integrations are built on request. Some typical cases:

• A new custom field in your CRM or ERP is added by configuration, with no code change.
• A legacy system with no usable API feeds OpenKnowra through a scheduled file extract (SFTP) or a read-only database connection, set up with your approval.
• SharePoint and Google Drive content comes in through dedicated connectors that keep each file's access permissions.

Connectors cover standard and custom objects and fields, and sync runs as scheduled full or incremental loads, or event-driven where the source supports it.

13. How are data conflicts between sources handled?

By default, structured data from your systems of record is treated as the authoritative source, because it holds the core facts your business runs on, while documents and other unstructured content add context around it. Your team can override this default with precedence rules for any type of fact, and update those rules as your data governance policy evolves. When sources conflict, the precedence rules decide which value is used.

14. How does it handle change over time?

OpenKnowra keeps a full record. Every change is tracked with its source and time, and every recommendation is stored with the evidence behind it, so a decision made last quarter can still be explained after the data or rules have moved on.

The ontology is versioned through controlled releases. Every entity and relationship carries source provenance and timestamps, and an audit log records what changed, when and from which source. The active graph holds current state; point-in-time snapshots can be exported to your data platform, and full point-in-time querying inside the graph is available as an add-on.

15. Can we export the ontology and the graph, or are they locked in?

Neither is locked in. The ontology is built on W3C open standards, so the ontology, including your own extensions to it, and the context graph export in standard formats for use in other tools.

The ontology uses RDF and OWL 2. The base OpenKnowra ontology (its taxonomies, frameworks and relationships) remains Spire.AI intellectual property, and its use outside the platform is governed by the license terms.

16. What certifications can our security team review?

Spire.AI holds current SOC 2 Type II and ISO 27001 certifications and operates in line with GDPR. Data is encrypted with AES-256 at rest and TLS in transit, and the platform undergoes independent penetration testing. Our AI Governance Framework is aligned with ISO/IEC 42001 and the EU AI Act, and our recommendation engine undergoes bias audits. Security questionnaires, bias audit results, reports and supporting documents are available on request.

17. Do agents respect our access rights, and does each agent have its own identity?

Yes, at two levels.

Access to your systems is controlled by you. Your administrators decide which systems OpenKnowra connects to, approve each connector’s access and can revoke it at any time. Permissions stay managed in your own systems; OpenKnowra never changes them.

Access to context graph data is governed by the access rules you define, enforced on every agent request. Each agent runs under its own identity, and the platform supports SSO and role-based access control.

18. Can a malicious document or prompt make an agent misbehave?

Documents and prompts do not set the rules agents follow. Content from your documents is read as data, never as instructions: what is extracted is stored as data with its source. Prompts never instruct the platform directly. They stay at the edge, where an LLM only translates the prompt into a query over the context graph, and that query still runs within the user’s access rules. The rules and approval limits agents work within live in a separate, versioned layer, and agents act only inside the boundaries you define.

19. How do you stop an agent doing something it shouldn't?

By design, an agent’s decisions and actions are grounded in the context graph, not generated by an LLM. The LLM only interprets language; what the agent decides and does is resolved deterministically over the graph against your rules. An agent cannot act on information that does not exist in the graph, so a hallucinated answer cannot turn into an action. You decide, by type of decision, what an agent may decide on its own, what it may act on, and what it must escalate. These rules are defined in the Logic Controller, and proposed actions are checked against them before they run. For example, an agent can approve refunds up to a set amount, with anything above that escalated to a person along with the agent’s reasoning. Actions outside the defined boundaries are blocked and logged.

20. Can we trace why a decision was made?

Every decision is traced from the source facts to the outcome, including the policy and rule version that applied. That record helps reviewers understand why a decision was made and whether a wrong call came from bad data or from a rule that needs changing.

21. Do we need to implement the entire platform to get value?

You can start small. OpenKnowra can be engaged at any of its three platform layers and extended as your needs grow. For example, you can begin with the Context Compiler alone, building a live Enterprise Context Graph from your own systems and serving it to your existing applications and agents through APIs. From there, you can add the Logic Controller to turn your SOPs and policies into governed decision logic, and the Action Builder to run agents and workflows within that logic. Or you can move straight to the end-to-end platform and run a complete functional grid. Whichever path you choose, start with one use case and expand from there.

22. What do you need from my team to get started?

OpenKnowra is a low-code platform by design, so getting started does not demand a large effort from your team. It comes down to three steps:

• Identify the right first use case: one recurring, high-value decision with clear rules.
• Configure the data sources that decision needs, using the standard connectors (question 12).
• Build the solution: the context graph from those sources, the business rules in the Logic Controller, and the agents and workflows in the Action Builder.

Depending on the use case, an agent can go live in production in as little as 5 days. The success is measured against your own baseline, such as decision cycle time, exception rate and policy adherence.

23. What happens when something goes wrong?

OpenKnowra handles failures on two fronts. On the data side, every sync is monitored with automatic retries and failure alerts, so a failing source is flagged instead of silently going stale. On the agent side, you set each agent's scope, permissions, rate limits, spending limits and approval workflows before it goes live, and you can pause, stop, roll back or review its actions from the platform. Spire.AI can also suspend an agent that is malfunctioning or behaving anomalously and will notify you as soon as practicable. When a decision turns out to be wrong, replaying it shows whether the cause was bad data or a rule that needs changing (question 20).

24. What is OpenKnowra's pricing model?

OpenKnowra is priced to be predictable and tied to business outcomes, not to tokens. Depending on the components you use, pricing is consumption-based, outcome-based, or a combination of the two. Its architecture is designed to reduce cost per decision by reusing enterprise context and executing deterministic reasoning over the graph, rather than repeatedly calling AI models. Public pricing is published at pricing.openknowra.ai, and enterprise agreements include volume-based discounts.