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

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

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 — 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 — TypeScript, Python, Go, and Rust SDK guidance.

Protocol Specifications

• Spec Overview — 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 — connector behavior and runtime expectations.
• OpenAI BaseURL — proxy and interoperability reference.
• 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.