Open Source Execution, Commercial Evidence

AKIOUD AI maintains three product lines: RADAR (commercial compliance evidence), AKIOS OSS (open-source execution cage), and EnforceCore (open-source enforcement primitives). Each serves a different job for a different buyer. Understanding which one fits your use case starts with knowing what each product is designed to do — and what it is explicitly designed not to do.

This post explains the product boundaries, the rationale behind them, and how they work together as separate products from the same company.

The three products, one pattern

All three products share a common architectural pattern: independent observation of a system without owning its execution. But each applies the pattern to a different domain:

Why separate products, not a platform

The natural question is: why not build one platform that does everything — execution safety, compliance evidence, and infrastructure monitoring? The answer is that combining them would make each product worse.

Auditor trust requires independence

A product that both executes agent workflows and certifies their compliance has a fundamental conflict of interest. An auditor reviewing evidence from a system that also ran the workflow cannot distinguish between operational decisions and governance records. The evidence layer must be independent from the execution layer — not just architecturally separate, but organizationally separate.

This is not a hypothetical concern. The EU AI Act explicitly requires that record-keeping and monitoring functions be independent from system operation (Article 12, Article 14). A combined product would require the buyer to audit the vendor's internal separation of duties — a burden most regulated enterprises will not accept.

Different buyers, different purchase processes

RADAR sells to legal, risk, and compliance teams. These buyers evaluate products based on regulatory coverage, evidence quality, and auditor acceptance. They do not evaluate kernel sandboxing performance or system call interception latency.

AKIOS OSS and EnforceCore sell to developers and security engineers. These buyers evaluate based on sandbox robustness, performance overhead, and integration flexibility. They do not evaluate regulatory framework mapping or evidence pack formats.

A single product marketed to both audiences would satisfy neither. The compliance buyer would see execution features they do not need. The developer would see compliance features they do not need. Separate products allow each buyer to focus on what matters to them.

Independent codebases, independent roadmaps

RADAR has zero shared code with AKIOS OSS or EnforceCore. There is no shared dependency, no shared library, no shared infrastructure. Each product can evolve independently based on its own market needs. A vulnerability in AKIOS OSS does not affect RADAR. A regulatory update to RADAR does not affect AKIOS OSS or EnforceCore.

This separation also prevents the "open-core trap" where the open-source version is intentionally crippled to drive commercial upgrades. AKIOS OSS is a genuinely useful execution cage for developers. EnforceCore is a genuinely useful enforcement framework. Neither is a free tier of RADAR. They are independent products that happen to share a company and a design philosophy.

How to choose

The decision framework for buyers is straightforward:

• You need compliance evidence for regulated AI workflows. You want RADAR. The product captures LLM calls, tool invocations, policy decisions, and PII events — and produces regulator-ready evidence packs. Start with the self-hosted trial.
• You need to constrain what an agent can do at the kernel level. You want AKIOS OSS or EnforceCore. These are open-source projects that provide execution safety for developers. They are not RADAR and do not produce compliance evidence.
• You need both. You deploy RADAR for compliance evidence and AKIOS OSS for execution safety. They are separate products that complement each other without shared dependencies. Each does its job independently.

The brand relationship

RADAR, AKIOS OSS, and EnforceCore share the AKIOUD AI brand because they share a company and a design philosophy about AI safety. But that is the extent of the relationship. The brand signals engineering credibility: the same company that builds kernel-level execution safety tools also builds the compliance evidence layer. For a buyer evaluating RADAR, knowing that the company has deep technical expertise in agent safety adds confidence — even though the products themselves are independent.

This is why the website keeps AKIOS OSS and EnforceCore visible as separate open-source projects. Not as a free tier, not as an upgrade path, not as a loss leader. As credibility proof that the company building the compliance product has real technical depth in the agent infrastructure space.

Getting started with each product

Each product has its own installation path, designed for its specific buyer. No shared dependencies, no prerequisite chain — pick the product that matches your use case and start there:

$ pip install akios-oss
  Collecting akios-oss
  Successfully installed akios-oss-1.0.0

  $ python -c "from akios import Sandbox; print('Ready')"
  Ready

$ pip install enforcecore
  Collecting enforcecore
  Successfully installed enforcecore-1.0.0

  $ python -c "from enforcecore import PolicyEngine; p = PolicyEngine.from_yaml('policy.yaml'); print('Policy loaded')"
  Policy loaded

$ docker compose up radar
  Creating radar_collector ... done
  Creating radar_store     ... done
  Radar ready.

  $ radar sources add --type gateway --name my-agents
  Source connected: my-agents

Three products, three installation paths, three different buyers. The command line tells the story: AKIOS OSS and EnforceCore are developer tools you import. RADAR is infrastructure you deploy.