Platform Boundary

HELM has three different truths that must stay separate:

1. what the OSS kernel already is
2. what the commercial platform adds
3. 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.