Governed models
Pinned release identities, serving configuration and immutable Bee releases.
The Bee Platform
The Bee Specialist Intelligence System.
BSIS combines governed reasoning models, continuously refreshed research, a governed 96-domain specialist taxonomy, tenant knowledge, tools, evaluations and deployment controls in one progressive system. Every shipped capability lands behind the eval harness, and every public claim links to verifiable evidence at /trust.
Specialist intelligence architecture
The model is one component. BSIS is the intelligence system.
BSIS keeps durable reasoning in governed model releases and current knowledge in an attributable Research Fabric. Domain Packs bind approved sources, retrieval, tools, policy and evaluations for each specialist field. This lets Bee update research without destabilising customer-serving weights.
Control plane establishedResearch Fabric in progressBee Ignite foundation research
Research Fabric
Rights-aware sources, provenance, citations, corrections and freshness.
96-domain taxonomy
Versioned Domain Packs will bind knowledge, tools, policy and evaluations across the governed taxonomy; the runtime is in progress.
Tenant knowledge
Customer documents remain isolated and retrieval-only without explicit contractual permission.
Evidence routing
Questions compose the permitted research and domain capabilities relevant to the task.
Release assurance
Evaluation, safety, canary and rollback evidence precede production promotion.
Foundation roadmap
Bee Ignite is the from-scratch foundation programme inside BSIS—not a transfer or adapter lane. It has no released checkpoint today and will enter serving only after reproducible pretraining, specialist evaluation, shadow serving, canary and rollback evidence.
Bee's hosted inference is operated by HEOSSI. Its serving configuration, governance, safety enforcement, routing, retrieval, tools, evaluations, and release controls are designed, implemented, and operated by HEOSSI through the Bee Specialist Intelligence System (BSIS).
Bee reference architecture
One specialist-intelligence system. Clear execution boundaries.
Bee Specialist Intelligence System (BSIS) is the architecture that turns a request into a governed specialist response. It coordinates domain intelligence, current knowledge, tenant retrieval, tools, model execution, safety, evaluation and release control—the model is one component, not the whole product.
Customer and integration layer
One governed entry point across every Bee surface
Bee Workspace
API & SDKs
MCP & tools
Enterprise systems
Bee Specialist Intelligence System
The governed intelligence and orchestration core
01
Understand the task
Resolve intent, user context, entitlements and policy before execution.
02
Compose specialist intelligence
Select across the governed 96-domain taxonomy, permitted research, tenant retrieval and tools.
03
Route the right execution
Choose an eligible Bee tier, model release, workflow and deployment boundary.
04
Evaluate and control
Apply safety, quality, release evidence, metering, telemetry and rollback controls.
Classical intelligence path
Specialist response and workflow execution
- Governed Bee model releases and tier routing
- Tenant-scoped retrieval, memory and citations
- Approved tools, structured workflows and streamed output
Explicit quantum-compute path
Governed access to real quantum hardware
- Local simulation before any hardware submission
- Entitlement, privacy, circuit and spend controls
- Reviewed real-QPU target with metered results and evidence
Security and evidence plane
Quantum-Native Security Infrastructure (QNSI)
HEOSSI’s security platform supplies post-quantum key, payload-protection and tamper-evident evidence paths using NIST-standardized cryptography, with the exact transport and deployment boundary fixed by the customer environment.
Ordinary AI requests stay on the classical inference path.
Quantum execution is explicit, bounded, entitled and budget-controlled.
Tenant knowledge is resolved inside the authenticated customer boundary.
Public transport uses TLS 1.3; post-quantum transport is separately scoped.
Knowledge stays governable
Current research and tenant material remain attributable and updateable without silently changing model weights.
Controls travel with the request
Identity, policy, data boundary, metering and evidence remain attached through routing and execution.
Quantum is a separate decision
A customer chooses a quantum workload explicitly; normal chat never incurs hardware execution or cost.
Request lifecycle
Controls are applied before intelligence runs.
Every request moves through an explicit identity, entitlement, context, routing, execution, and evidence path. The exact controls and retained records depend on the service, plan, and customer contract.
Review the evidence boundary- 1
Authenticate
Resolve the account, organisation, API credential, plan, and applicable policy boundary.
- 2
Authorise
Apply entitlement, rate, tool, data-access, and deployment-specific controls before work begins.
- 3
Assemble context
Combine the request with permitted conversation, memory, document, and tool context.
- 4
Route intelligence
Select an eligible Bee capability path according to tier, workload, policy, and availability.
- 5
Execute and stream
Run inference and approved tools, then return structured or streamed output through the API contract.
- 6
Record evidence
Capture the operational telemetry, usage, and audit events permitted by the applicable product boundary.
Capability register
Scope, status, boundary, and evidence.
“Enterprise-ready” is too broad to be useful. This register distinguishes what is live, what is scoped through a customer engagement, what remains in progress, and what is still roadmap.
Last reviewed: 22 July 2026
| Capability | Scope | Availability | Deployment | Data boundary | Evidence |
|---|---|---|---|---|---|
| OpenAI-compatible inference | Chat Completions, streaming, model selection, SDK and editor integration | Live | Bee hosted cloud | Authenticated account, organisation, and API tenant boundaries | API documentation → |
| Multimodal workspace | Text, image, video, voice, documents, tools, projects, and scheduled work | Live | Web, signed Android, and desktop preview | Account- and tenant-scoped product state | Client availability → |
| Document retrieval | Upload, chunk, embed, retrieve, and cite source passages | Live | Local or Bee-hosted according to plan | Tenant-isolated indexes; cross-member shared context remains in progress | Retrieval guide → |
| Bee Specialist Intelligence System | Governed reasoning models, source-rights controls, Research Fabric, a 96-domain governed taxonomy, tools, evaluations, and release evidence | In progress | BSIS control plane established; Research Fabric and Domain Pack runtime staged | Each source is independently classified for index, retrieval, display, evaluation, training, and redistribution | BSIS architecture → |
| MCP tools | Hosted OAuth plus local stdio and loopback transports | Live | Hosted and customer-local client paths | Tool calls inherit the authenticated Bee tenant and client boundary | MCP documentation → |
| Team administration | Seats, pooled usage, plan controls, and organisation administration | Live | Bee hosted cloud | Organisation-scoped administration | Plan comparison → |
| Shared team context | Cross-member projects, conversations, and document context | In progress | Bee hosted cloud | Not released until tenant-boundary validation is complete | Delivery roadmap → |
| Enterprise identity and audit controls | SSO/SAML, audit evidence, policy, and contracted operating controls | Customer-scoped | Enterprise and Enclave engagements | Exact controls are fixed in the Order Form and deployment manifest | TrustHub → |
| Post-quantum transport | NIST FIPS 203, 204, and 205 high-assurance transport path | Customer-scoped | Separately contracted Enclave Sovereign environments | Not claimed for public-tier transport, which uses TLS 1.3 | Security boundary → |
| Self-hosted and air-gapped operation | Customer-operated or disconnected deployment patterns | Roadmap | Prospective Enclave engagements | Architecture and availability must be confirmed before contracting | Delivery roadmap → |
Data Processing Addendum
Processing roles, transfers, security measures, assistance, and deletion terms.
Open evidenceSecurity Practices
Published operating assumptions, safeguards, response, and deployment controls.
Open evidenceEnclave deployment
Compare hosted, regulated, private, and sovereign deployment boundaries.
Open evidenceBSIS governed evolution
Improve specialist capability without weakening the system.
BSIS separates research updates, Domain Pack changes and model releases so each can be evaluated at its own boundary. A promoted model artefact must clear evaluation, safety, canary and rollback gates before serving. Capability evidence is published through Bee TrustHub; exact deployment controls remain governed by release and Enclave policy.
- 1
Train
Domain capability is trained against governed data sources.
- 2
Validate
Eval harness gates the artefact; it must clear the score gate to ship.
- 3
Publish
Released through the governed-release pipeline with a published validation record on /trust.
- 4
Deploy
Tier upgrades land in production routing tier by tier as each clears review.
Research and training infrastructure
Evidence before training. Evidence before release.
BSIS keeps live research retrieval separate from model-training eligibility. The managed candidate training, when enabled, runs in isolated workspaces with hard budget and promotion gates. Each released artefact carries lineage, dataset, evaluation, canary and rollback evidence; deployment placement is contractual for Enclave environments.
What customers see
- A single OpenAI-compatible endpoint at
/bee/chat/completions. - Per-tier capability gated by plan or contract.
- Public release notes at /changelog; live engine status at /status.
- Deployment options spanning shared cloud, private cloud, regulated, and sovereign — see the Intelligence Ladder.
In every editor you already use
An API key is the only integration step.
Bee speaks the OpenAI Chat Completions wire format. Anywhere you’d paste an OpenAI API key, paste a Bee API key instead — and switch the base URL.
// universal config — works in Cursor, Windsurf, Continue, Zed
base_url: "https://api.bee.heossi.com/bee" api_key: "$BEE_API_KEY" model: "bee-comb"
- VS CodeNative
Native extension: Bee by HEOSSI — The Progressive Quantum-Native Intelligence Engine.
- CursorOpenAI-compatible
Settings → Models → Override OpenAI base URL.
- WindsurfOpenAI-compatible
Custom provider — paste Bee base URL and API key.
- Continue.devOpenAI-compatible
Add Bee as a provider in `~/.continue/config.json`.
- ZedOpenAI-compatible
OpenAI-compatible LLM provider in the assistant config.
- JetBrains AI AssistantOpenAI-compatible
Connect via OpenAI-compatible custom endpoint.
- AiderCLI
Run `aider --openai-api-base ... --openai-api-key ...`
- Anything elseOpenAI-compatible
If it accepts an OpenAI API key, it works with Bee.
Build with the platform
Start public. Scale sovereign.
Begin with Bee Cell, scale through the Intelligence Ladder, and move into high-assurance deployment when your requirements demand stronger governance, security, and control.