Skip to content

Reeflex — Open-Core Boundary

This document defines which components of Reeflex are open-source and which are commercial and closed. It is intended for contributors, adapter authors, and evaluators who need to know what they can build on, fork, and redistribute — and what they cannot see.

The boundary is absolute (see ADR-0001 §2): closed-tier material never appears in any public repository, in any form — no code, no configuration, no schema, no secrets.

The boundary at a glance

Component Tier License Status
reeflex-core engine (/v1/decide, OPA integration, audit JSONL) Open Apache 2.0 Available
reeflex-spec (Action Envelope + Adapter Contract + conformance suite + JSON schemas) Open Apache 2.0 Available
reeflex-claude reference adapter (Claude Code) Open Apache 2.0 Available
reeflex-wordpress reference adapter Open Apache 2.0 Available
reeflex-mcp reference adapter (MCP gateway — any MCP upstream) Open Apache 2.0 Available (pip install reeflex-mcp)
Community adapters (reeflex-postgres, reeflex-s3, etc.) Open Apache 2.0 Community-built against the spec
Base policy packs (Rego rules for the Action Envelope) Open Apache 2.0 Available
Mock adapter + demo Open Apache 2.0 Available
Attest — audit-ready control evidence (NIS2 · DORA · EU AI Act · SOC 2) Commercial / closed Proprietary Not in any public repo
Fleet — multi-site management Commercial / closed Proprietary [ROADMAP — not built, not available]
Cloud — hosted Reeflex (multi-tenancy, auth, billing) Commercial / closed Proprietary [ROADMAP — not built, not available]

The line, in one sentence

Everything that keeps you safe is free. What you pay for is help proving it.

The gate, the decisions, the adapters, the base policy packs, and the full audit trail are open — permanently. The commercial tier does not add safety; it adds attestation: Attest maps Reeflex decisions to specific control frameworks — NIS2 Article 21(2), already in force and under active audit across the EU; DORA; the EU AI Act Articles 12/14, whose high-risk obligations phase in 2 December 2027 (Digital Omnibus, Regulation (EU) 2026/1744); and SOC 2 — with auditor-ready reports and managed policy-pack updates as regulations change. Fleet manages policy and approvals across many sites; Cloud is a hosted engine for teams that don't want to operate one. Evidence is free; packaging that evidence in the language a regulator expects is the product.

For auditors: the open tier is already an evidence source

Every decision Reeflex makes — allowed, held, or denied — is written to an append-only JSONL audit log with the ability name, the computed impact axes, the rule that fired, the session, and the timestamp. Because the decision path is deterministic (same envelope in, same verdict out, every time — see ADR-0002), that record is not just a log of what happened: an auditor can take the same envelope and replay it against the same policy to reproduce the verdict, rather than having to trust the log's word for it. That gives an auditor something rare in AI-agent deployments: a pre-execution record of what an agent attempted, deterministic and replayable, not just a post-hoc log of what happened. You can answer "what could this agent have done, and what stopped it?" from the open tier alone, today. (Cryptographic tamper-evidence for audit records is on the roadmap; current records are append-only but not signed.)

Open tier — what it contains and what you can do with it

Everything in the open tier is Apache 2.0. You can use it, fork it, redistribute it, and build commercial products on top of it, subject to the Apache 2.0 terms.

reeflex-core

The governance engine. Exposes one endpoint:

POST /v1/decide   { ActionEnvelope }  ->  { Decision: allow | deny | require_approval }

Implemented in Python + OPA/Rego. Decision evaluation is deterministic: same envelope in, same decision out, every time. Zero LLM in this path (see ADR-0002). The engine stores an audit log in JSONL format; Postgres audit persistence is on the roadmap.

reeflex-spec

The portable contract that makes all adapters interoperable:

  • Action Envelope — the normalized JSON shape every adapter must produce (SPEC §2).
  • Adapter Contract — four responsibilities every compliant adapter must implement: intercept, normalize, enforce, audit (SPEC §6).
  • Conformance suite — deterministic input/output test cases that prove an adapter is compliant (SPEC §7).
  • JSON schemas — machine-readable envelope and decision schemas.

The spec is backend-agnostic. reeflex-core knows nothing about WordPress, Postgres, or S3. It evaluates envelopes. The spec defines what a valid envelope looks like.

reeflex-wordpress — reference adapter

The reference implementation of the Adapter Contract. It proves the contract is implementable, serves as the primary adoption surface (WordPress runs a large proportion of the web), and is the template from which community adapters are built.

reeflex-mcp — reference adapter (MCP gateway)

A transparent MCP proxy that governs any MCP upstream (stdio or streamable-HTTP): it intercepts tools/call, normalizes it into the Action Envelope via declarative per-server mappings or a conservative heuristic fallback, calls core, and enforces the verdict. It proves the contract is implementable at the network-boundary side — the third seam alongside source-side (reeflex-claude) and resource-side (reeflex-wordpress). Conformance-tested per SPEC §7. See docs/mcp-gateway.md.

Community adapters

Any adapter that passes the conformance suite can call itself Reeflex-compliant. reeflex-postgres, reeflex-s3, and others are open-source community projects built against the public spec. They carry their own licenses (Apache 2.0 recommended) and are not part of the commercial tier.

Base policy packs

Rego rule sets that govern the Action Envelope out of the box. Policies reason over the three universal axes (reversibility, blast_radius, externality) and cumulative session state (SPEC §4, §4.1). They are starting points; operators are expected to extend them for their context.

Mock adapter + demo

A minimal adapter implementation used for testing, demonstrations, and contributor onboarding. Synthetic data only — no real PII or client data in any example.

Commercial / closed tier — what it contains and why it is separate

The closed tier is never published to any public repository. Contributors will not find it here. If you believe you are looking at closed-tier material in a public Reeflex repository, that is a bug — report it.

Attest — audit-ready control evidence

Structured mappings between the Reeflex decision vocabulary and the specific obligations of NIS2 Article 21(2) — the current lead: transposed across the EU and already the subject of active audits, where documentation gaps are a common finding a decision register directly addresses — plus DORA, SOC 2, and the EU AI Act (Articles 12/14, whose high-risk obligations do not apply until 2 December 2027, per the Digital Omnibus). Pre-built reporting templates and evidence packages for teams that must prove control to an auditor. This is the commercial value-add; it is not part of the open-source governance engine.

Fleet — multi-site management

[ROADMAP — not built, not available today.]

A management surface for policy authoring, approval workflow, and audit review across many sites is planned as part of the commercial tier (Fleet). It is not available and is not part of the open-source repositories.

Cloud — hosted Reeflex

[ROADMAP — not built, not available today.]

When the hosted variant of Reeflex (Cloud) is built (see ADR-0001 §3, Variant B), it will require multi-tenancy isolation, authentication, and subscription billing. These components are part of the closed commercial tier. The open-source engine and adapters are identical in the hosted and on-prem variants; only the operational wrapper is closed.

No hosted engine is operated today. Do not present hosted availability as a current capability.

The boundary is absolute

The open-core boundary is absolute: open repositories are Apache 2.0 and public; the commercial/closed tier never enters any public repository. This is stated as an absolute project limit in ADR-0001 §2 and is repeated throughout the project documentation — it is not merely a preference.

Concretely this means:

  • No compliance-mapping code, schema, or configuration in reeflex-core, reeflex-spec, reeflex-wordpress, or any open community repository.
  • No Attest, Fleet, or Cloud (compliance-evidence, multi-site-management, or hosted-operations) code or configuration in any open repository.
  • No multi-tenancy, authentication, or billing code in any open repository.
  • No secrets, API keys, or credentials anywhere in any repository (open or closed) — secrets are referenced by name via Vault or environment variables only.

If you are contributing to the open-source layer and are unsure whether something belongs in an open repository, the default is: it does not. Ask before adding it.

Deployment model and this boundary

The deployment model is recorded in ADR-0001. In summary:

  • On-prem (available now): the client runs reeflex-core themselves. All open-source components, zero commercial dependency.
  • Hosted / subscription (ROADMAP): a thin adapter calls a Reeflex-operated engine over HTTPS. The engine is identical open-source code; the operational wrapper (multi-tenancy, auth, billing) is the closed commercial tier. This variant is not built and not available today.

The open-core boundary is the same in both variants. The engine code is open regardless of where it runs.

Frequently asked questions

Can I fork reeflex-core and run it commercially? Yes. Apache 2.0 permits commercial use. You are running the open-source engine; you are not accessing the closed commercial tier.

Can I build a managed/hosted Reeflex service myself? Yes, using the open-source components. The "hosted" tier in the table above refers to Reeflex's own operated service, which is roadmap. You may build your own using the open-source engine.

Can I contribute a compliance-mapping policy pack under Apache 2.0? Contributions that map the Reeflex Rego vocabulary to regulatory frameworks (as open, generic policy packs) are welcome in the open tier. The closed tier refers specifically to Reeflex's commercial, opinionated, supported compliance product — not to open community policy authoring.

Where is the line between a base policy pack (open) and the compliance product (closed)? A base policy pack is a generic Rego rule set that any operator can read, modify, and extend. The commercial compliance product adds structured evidence mapping, reporting templates, and supported maintenance against specific regulatory texts. The Rego rules themselves are open; the commercial reporting layer is closed.

Reeflex — a seatbelt for the AI acting on your systems.