Open Source and Enterprise Boundary

HSM-II should be easy for developers to inspect, run, extend, and integrate with. It should also be credible for companies that need private deployments, governed API access, support, and clear IP boundaries.

The product posture is open core with enterprise controls:

• Public enough that builders can understand the architecture, run the core runtime, read API contracts, and build integrations.
• Private enough that customer data, hosted operations, paid deployment playbooks, credentials, and proprietary company packs are not exposed by default.

What is open

These surfaces are intended to be public, documented, and useful without a sales call:

Surface	Public intent
Core runtime	Rust multi-agent runtime, Company OS control plane, task loop, memory model, governance primitives, eval harnesses, and local console paths
API contracts	HTTP routes, request/response shapes, auth model, examples, and integration guides for building against HSM-II
Connector model	Tool schemas, MCP bridge patterns, connector/session/trigger docs, and examples that let developers add their own tools
Docs and guides	Operator handbook, action-layer guide, eval guides, launch docs, architecture notes, and LLM-readable /llm/*.md exports
Templates and examples	Starter company packs, sample skills, demo workflows, and non-sensitive reference configurations
Contribution path	Issues, pull requests, bug reports, docs fixes, connector examples, tests, and reproducible benchmark improvements

What stays private

Open-source does not mean every operating artifact becomes public. These surfaces should remain private unless explicitly released:

Surface	Why it stays private
Customer workspaces and tenant data	Contains private goals, tasks, agent memory, governance events, costs, credentials, and operator decisions
Hosted production infrastructure	Includes deployment topology, cloud accounts, observability backends, incident procedures, and operational secrets
Proprietary company packs	Some packs may include paid strategy, domain-specific SOPs, partner data, or customer-specific agent rosters
Credential and billing systems	API keys, OAuth secrets, vault backends, billing details, and abuse-prevention controls must not be exposed
Internal roadmaps and commercial playbooks	Pricing, enterprise negotiation notes, private partner integrations, and unreleased product strategy
Security-sensitive exploit detail	Public advisories should describe impact and remediation without publishing weaponized instructions

API access model

HSM-II should feel open the way modern developer platforms do: developers can self-host, read the docs, and call the API, while production usage remains governed.

Recommended tiers:

Tier	Access
Local developer	Run HSM-II locally, use local API keys, inspect routes, test connectors, and build against documented endpoints
Self-hosted team	Deploy the open core in a private environment with tenant isolation, audit logs, budget controls, and explicit origin/auth policy
Hosted API preview	Request API credentials for a managed endpoint with rate limits, scoped permissions, and revocable keys
Enterprise	Private deployment or managed tenant with SSO/SAML, audit export, support SLA, data residency, custom connector review, and governance controls

Public docs should make the local and self-hosted paths obvious. Hosted API access should be presented as controlled access, not an implicit promise that every internal endpoint is public.

Enterprise requirements

Enterprise buyers usually need more than source code. Public material should make these capabilities visible:

• Security: API keys, JWTs, rate limiting, permission scopes, secret scanning, least-privilege connector auth, and hardened CORS defaults.
• Isolation: Company/tenant boundaries, per-workspace memory, scoped credentials, and audit trails.
• Governance: Human approvals, verifier gates, escalation logs, spend hard-stops, and policy-enforced execution.
• Observability: Task trail, run traces, harness JSONL logs, governance events, spend events, and eval artifacts.
• Agent quality: Friendly quality packs, run stories, agent health reporting, failure explanations, and promotion gates for enterprise AI agent observability/evaluation. See docs/company-os/agent-quality-observability-product.md.
• Deployment: Local dev, self-hosted Postgres-backed runtime, Docker paths, and hosted/private deployment options.
• Supportability: Reproducible smoke tests, health checks, exportable diagnostics, and clear versioned docs.

Contribution boundaries

Good open-source participation needs a bright line between community work and private operations:

• Accept public contributions for docs, examples, tests, tool schemas, connector recipes, bug fixes, local developer experience, and benchmark harnesses.
• Review runtime changes through normal code review and verification before merging.
• Do not accept secrets, customer data, proprietary packs, private traces, or production incident logs in issues or pull requests.
• Keep paid enterprise configuration in private repos, private package registries, or customer-specific deployment overlays.
• Prefer public API and extension contracts over exposing internal implementation details that are likely to change.

Messaging guidelines

Use language like:

HSM-II is an open-core Company OS for durable agents. Developers can self-host the core runtime, inspect the architecture, build against documented APIs, and extend the tool plane. Enterprise teams get governed API access, private deployments, tenant isolation, audit trails, and support without exposing customer data or proprietary operating packs.

Avoid language like:

• "Everything is open source."
• "All company packs are public."
• "All internal APIs are available."
• "Hosted API access is unrestricted."
• "Enterprise customers share one global memory."

Public checklist

Before publishing a new page, demo, or release artifact, check:

• Does it clearly explain how a developer can run or integrate with HSM-II?
• Does it link to API, connector, or launch docs where useful?
• Does it avoid exposing secrets, customer data, private traces, and proprietary packs?
• Does it distinguish local/self-hosted access from managed hosted API access?
• Does it make enterprise controls visible without turning the page into sales-only copy?