Skip to content

ADR-021: Open-Core and Commercial Boundary

  • Decision status: Accepted
  • Implementation status: Not started
  • Applies to: Enterprise/BYOC, future
  • Date: 2026-06-16
  • Deciders: Grey Newell
  • Tags: open-core, commercial, packaging, enterprise, investability, byoc

Context

RAGhelm's architecture includes commercial packaging, open-core boundary, enterprise readiness, BYOC/private-cloud deployment, public proof artifacts, and design-partner pilots.

ADR-001 defines the product spine as private RAGOps and release-control infrastructure. ADR-002 makes scorecards and RAGRunManifests core product objects. ADR-020 defines Docker Compose now and BYOC/private-cloud as the enterprise deployment target.

The commercial boundary should preserve trust and adoption while creating a credible business model. Hiding the core schema or local release-control engine would weaken trust. Giving away all enterprise governance and deployment value would weaken investability.

This decision supports related implementation work without making issue numbers part of the durable architecture contract.

Decision

Use an open-core model:

  • The core local release-control engine is open source.
  • Enterprise governance, collaboration, advanced audit, advanced integrations, compliance packs, and managed/BYOC operations are commercial.
  • A future hosted scorecard/control plane may be considered only if the commercial roadmap demands it.

RAGhelm should not hide the core scorecard or RAGRunManifest schema. These artifacts are part of the trust and adoption story.

Open-Source Boundary

The open-source edition should include:

  • ReadinessScorecard schema and local evaluator
  • RAGRunManifest schema and artifact hashing helpers
  • local release policies and retrieval policies
  • local JSON artifact generation
  • local dashboard/demo surface
  • local SQLite persistence path
  • CLI and Python runtime needed for local release checks
  • reference RAG/agent target sufficient for demos and tests
  • basic external target adapter contract and at least one simple adapter
  • public benchmark/proof suite in local mode
  • documentation and ADRs

Commercial / Enterprise Boundary

Commercial or enterprise offerings may include:

  • team/user management
  • role-based review and approval workflows
  • enterprise audit trails and retention policies
  • advanced policy packs for regulated or high-risk workflows
  • private-cloud/BYOC deployment automation and support
  • advanced integrations with enterprise observability/security systems
  • managed persistence, backups, and operational dashboards
  • organization-level analytics and adoption/activation reporting
  • compliance readiness packs and evidence exports
  • premium support, design-partner implementation, and managed upgrades
  • future hosted scorecard/control plane, if commercial roadmap validates it

Consequences

Positive

  • Preserves developer trust by keeping core release-control artifacts open.
  • Creates an investable commercial boundary around enterprise governance and operations.
  • Aligns with private-compute/BYOC positioning.
  • Lets design partners adopt and inspect the core locally.
  • Keeps future hosted control plane optional instead of forcing a SaaS posture too early.

Negative

  • Requires discipline to avoid accidentally putting all enterprise value into OSS.
  • Requires clear docs so users understand what is open vs commercial.
  • Hosted SaaS monetization remains deferred until the commercial roadmap validates it.

Neutral / Trade-offs

  • OSS must be useful enough to earn trust; commercial must be valuable enough to support a business.
  • The public benchmark/proof story should remain open because it demonstrates credibility.
  • Enterprise deployment automation and team governance are stronger commercial boundaries than hiding schemas.

Alternatives Considered

  1. Everything open-source

Pros: - Maximizes trust, adoption, and community contribution.

Cons: - Weakens investability unless revenue comes entirely from services/support.

  1. Core engine OSS; enterprise controls commercial

Pros: - Strong open-core posture. - Preserves trust while creating a monetizable enterprise surface. - Aligns with private RAGOps/BYOC positioning.

Cons: - Requires ongoing boundary discipline.

This is the chosen option.

  1. OSS SDK/CLI; hosted scorecard/control plane commercial

Pros: - Stronger SaaS monetization story.

Cons: - Could conflict with private-compute/BYOC positioning if introduced too early. - Risks reducing trust if local scorecard/control functionality is too limited.

This remains a possible future direction only if commercial roadmap demands it.

  1. Dual-license

Pros: - Can support enterprise monetization.

Cons: - Adds legal/commercial complexity before product-market clarity.

Implementation Guidance

Initial docs should:

  • state that schemas, local scorecards, local manifests, and local release checks are open
  • distinguish local/OSS from enterprise/BYOC capabilities
  • avoid implying hosted SaaS exists before it does
  • align README, public demo, and design-partner materials with this boundary

Commercial roadmap work should:

  • validate which enterprise controls customers will pay for
  • identify which BYOC/private-cloud deployment automation belongs in commercial packaging
  • define pilot success metrics tied to release risk, launch velocity, cost, quality, and audit readiness
  • avoid closing source around the core trust artifacts

Non-goals:

  • deciding final pricing in this ADR
  • implementing hosted SaaS before the commercial roadmap demands it
  • hiding scorecard or manifest schemas
  • adding dual-license complexity now

References

  • ADR-001: Product Architecture Spine for Private RAGOps Release Control
  • ADR-002: Release Readiness Scorecard and RAGRunManifest as Core Product Objects
  • ADR-020: Deployment and Private-Cloud/BYOC Architecture