Platform Boundary
What HELM OSS includes, what HELM Platform adds, and what remains long-horizon.
Platform Boundary
HELM has three different truths that must stay separate:
- what the OSS kernel already is
- what the commercial platform adds
- what the long-horizon organizational thesis points toward
Confusing these layers creates bad roadmaps and worse messaging.
HELM OSS
HELM OSS is the open execution kernel.
It includes:
- fail-closed execution
- policy enforcement
- ProofGraph and EvidencePacks
- replay and offline verification
- adapters, bridges, and local integrations
It does not include:
- managed federation
- Mission Control operations surfaces
- pack entitlement management
- compliance intelligence workflows
- full OrgDNA deployment lifecycle
HELM Platform
HELM Platform is the commercial control plane around the same kernel.
It adds:
- shared approvals and operator workflows
- workspaces and organizational bootstrap
- pack catalog, install plans, and distribution
- evidence operations and public verification surfaces
- jurisdiction-aware deployment controls
- Studio / Mission Control product surfaces
The commercial layer should feel like an extension of the same execution boundary, not a different ontology.
Long-horizon thesis
The end-state is larger than a control plane:
- OrgDNA / OrgGenome
- organizational compilation
- mixed human+AI execution authority
- public, research, and operational institutions
- eventually physical-world coordination
That thesis matters now because it determines what HELM must not become.
What HELM must not become
- a generic orchestration framework
- observability with better branding
- compliance SaaS without execution authority
- enterprise-only AI middleware
Working rule
If a feature strengthens the execution boundary, shared control, or organizational authority model, it fits.
If it only makes HELM look more like a generic agent platform, it probably does not.