---
title: "Backend & Protocols"
canonical: "https://helm.docs.mindburn.org/backend"
source: "helm-ai-enterprise/docs/public/backend-landing.md"
edit: "https://github.com/Mindburn-Labs/helm-ai-enterprise/edit/main/docs/public/backend-landing.md"
section: "backend"
access: "public"
sensitivity: "public"
last_reviewed: "2026-05-13"
checksum_sha256: "sha256:fb2013dc17cfece1a4f9c9ce631bc0a38d3e62fd33db53692b4233ad3754232f"
build_timestamp: "2026-05-24T13:40:27.882Z"
---
# Backend & Protocols

This page gives the authoritative backend integration map: which APIs, schemas, and protocol pages exist, which are OSS-owned contracts, and which are HELM AI Enterprise operational extensions. It is the source-backed entrypoint for implementing clients, connectors, and audits that depend on backend contracts.

## Audience

- Protocol engineers implementing or consuming HELM API surfaces
- SDK authors and integrators building against the platform
- Compliance, security, and platform teams consuming Evidence and governance contracts
- Evaluators verifying conformance against public contract pages
- Operators validating backend behavior through versioned API and protocol documentation

## Outcome

After using this page, readers should be able to:

- route to the canonical API, schema, and protocol source pages before coding,
- distinguish OSS-standardized contracts from Commercial-hosted operational contract pages,
- understand where CLI, SDK, and adapter guidance lives,
- validate evidence and governance workflows using the correct backend references,
- and troubleshoot documentation or source-coverage mismatches when integrations fail.

## Mermaid

```mermaid
flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        OpenAPI["OpenAPI Spec"]
        Contracts["Schemas and Protocols"]
        OSS["HELM AI Kernel Source Layers"]
        Commercial["HELM AI Enterprise Source Layers"]
        SDKs["SDKs"]
        Clients["Client Integrations"]
    end

    subgraph Execution["3. Execution & Verdict Plane"]
        Runtime["Kernel + Runtime Surfaces"]
    end

    subgraph Ledger["4. Tamper-Evident Ledger Plane"]
        Evidence["EvidencePacks / Receipts"]
    end

    %% Operational Flow Edges
    OpenAPI --> Contracts
    Contracts --> Runtime
    Runtime --> Evidence
    OSS --> Runtime
    Commercial --> Runtime
    SDKs --> Clients
    Contracts --> SDKs

    %% Premium Styling Rules
    style Runtime fill:#3182ce,stroke:#2b6cb0,stroke-width:2px,color:#fff
    style Evidence fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
```


## Source Truth

This landing page is derived from:

- `api/**`
- `protocols/**`
- `schemas/**`
- `core/**`
- `sdk/**`
- `docs/public/reference/**`
- `docs/reference/**`

If a page is added or removed in these paths, update the destination links here first to keep the public route index accurate.

## API Surface and Reference

- [API Reference](/reference) — OpenAPI catalog and endpoint index for HELM backend services.
- CLI reference source: `docs/public/reference/cli-v3/format.md` — CLI operations model and command contracts.
- Schema reference source: `docs/12_SCHEMA_REFERENCE.md` — JSON schema and contract formats.
- API lifecycle source: `docs/api/API_LIFECYCLE.md` — versioning, deprecation, and migration policies.
- [SDK Reference](/reference/sdks) — TypeScript, Python, Go, and Rust SDK guidance.

## Protocol Specifications

- [Spec Overview](/backend) — map of all HELM protocol docs in one index.
- Evidence Merkle source: `docs/specs/protocols/EVIDENCE_MERKLE.md` — evidence tree and inclusion proof semantics.
- Governance spec source: `docs/specs/protocols/GOVERNANCE_SPEC.md` — governance protocol behavior and decision flow.
- Budget spec source: `docs/specs/protocols/BUDGET_SPEC.md` — budget enforcement and policy logic.
- Connector adapter source: `docs/specs/protocols/CONNECTOR_ADAPTER_SPEC.md` — connector design and adapter patterns.
- Contracts spec source: `docs/specs/protocols/CONTRACTS_SPEC.md` — canonical contract definitions and enforcement rules.
- Ingestion engine source: `docs/specs/protocols/INGESTION_ENGINE_SPEC.md` — ingestion process and transport expectations.
- Kernel integration source: `docs/specs/protocols/KERNEL_INTEGRATION.md` — integration patterns with kernel services.
- Registry spec source: `docs/specs/protocols/REGISTRY_SPEC.md` — registry, identity, and policy service model.
- Security spec source: `docs/specs/protocols/SECURITY_SPEC.md` — security enforcement points and threat-relevant expectations.
- Metering spec source: `docs/specs/protocols/METERING_SPEC.md` — usage and metering behavior.

## Core Internals and Verification

- VPL source: `docs/specs/runtime/VPL_SPEC.md` — Verification Pipeline Language contract model.
- Pack ABI source: `docs/specs/packs/PACK_ABI.md` — Evidence pack binary interface and interoperability constraints.
- Kernel TCB source: `docs/public/security-and-trust/tcb-policy.md` — trusted computing base and runtime security assumptions.
- Product contract source: `docs/specs/product/PRODUCT_CONTRACT.md` — higher-level product contract abstractions.

## Integration Guides

- [LangChain](/integrations/langchain) — connector behavior and runtime expectations.
- [OpenAI BaseURL](/integrations/openai-baseurl) — proxy and interoperability reference.
- [MCP](/integrations/mcp) — Model Context Protocol integration surfaces.

## Kernel vs HELM AI Enterprise boundaries (explicit)

- OSS pages define canonical protocol and interface documents and should be treated as baseline truth for contract meaning.
- HELM AI Enterprise pages are where operational packaging, tenant-specific controls, enterprise-grade deployment policies, and commercial support pathways are documented.
- If a protocol claim affects data integrity, contract semantics, or interoperability, keep it on an OSS-owned source unless a specific Commercial ADR relocates that behavior.
- If a page describes contractual terms, paid operational guarantees, or enterprise deployment behavior that does not alter protocol semantics, route it to Commercial documentation with a pointer back to the OSS contract source.

## Troubleshooting

- If a client implementation breaks after an API version bump, first verify route and version docs in `docs/api/API_LIFECYCLE.md` before patching generated SDKs.
- If an integration cannot find a schema, check whether it is in `schemas/**` but not yet linked by `docs/public/reference/specs-research-and-source-families.md`, then add the missing source mapping.
- If a page claims to be source truth but does not describe runtime behavior, confirm whether it is only a migration artifact (source-only) and mark it as such in source coverage.
- If endpoint behavior differs from docs, align with the matching source path under `api/**` and request a docs update on the owning PR.
- If conformance questions appear, cross-check `api`, `protocols`, and `core` pages against conformance expectations in architecture references before changing backend behavior.

## Adoption and change checklist

1. Identify the affected source path (`api`, `protocols`, `schemas`, or `sdk`).
2. Verify the canonical route in this page or add a new source route when first introducing the item.
3. Confirm boundary: if behavior is protocol-level, keep it on OSS pages; if it is enterprise policy packaging, keep it under Commercial-owned pages.
4. Update this landing page only when the public route graph changes.