helm-ai-enterprise

RFP Answers

After this page you should know what this surface is for, which source files own the behavior, which public route or adjacent page to use next, and which validation command to run before changing the claim. Public route:

PublicSource-ownedMarkdown export

Audience

Outcome

Source Truth

Public route: product/rfp-answers
Source document: helm-ai-enterprise/docs/public/product/rfp-answers.md
Public manifest: helm-ai-enterprise/docs/public-docs.manifest.json
Source inventory: helm-ai-enterprise/docs/source-inventory.manifest.json
Validation: corepack pnpm run docs:coverage, corepack pnpm run docs:truth, and npm run coverage:inventory from docs-platform

Do not expand this page with unsupported product, SDK, deployment, compliance, or integration claims unless the inventory manifest points to code, schemas, tests, examples, or an owner doc that proves the claim.

Troubleshooting

Symptom	First check
A link or route is missing from the docs website	Check `docs/public-docs.manifest.json`, `llms.txt`, search, and the per-page Markdown export before changing navigation.
A claim is not backed by code or tests	Remove the claim or add the missing code, example, schema, or validation command before publishing.

This document contains standard responses for Risk, Compliance, and Technical RFP sections.

1. Security & Compliance

Q: How does the system handle unauthorized agent actions? A: HELM uses a Policy Enforcement Point (PEP). Every side-effectful action must be authorized by a signed Kernel Verdict. Without this verdict, the Executor (SafeExecutor) cannot dispatch the action.

Q: Can logs be tampered with? A: HELM produces a ProofGraph (Merkle-DAG). Any attempt to alter history invalidates the subsequent node hashes and signatures, making tampering mathematically detectable during verification.

2. Technical Architecture

Q: What is the "7-Plane Model"? A: It is the HELM architectural standard that separates Identity, Policy, Truth, Record, Tools, Knowledge, and Surface into explicit trust boundaries.

Q: Does it support OPA? A: Yes, HELM includes a native OPA adapter (HELM_POLICY_BACKEND=opa) that delegates decisions to a central OPA server while maintaining local proof binding.

3. Reliability

Q: What happens if the policy engine is down? A: HELM implements fail-closed semantics. If the PDP is unreachable, all actions are denied until the connection is restored.

Diagram

Diagram1. Ingestion & Context Plane -> Standard RFP Answers: HELM -> 1. Security & Compliance -> 2. Technical Architecture -> 3. Reliability -> Reader outcome

flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        source["Standard RFP Answers: HELM"]
        s0["1. Security & Compliance"]
        s1["2. Technical Architecture"]
        s2["3. Reliability"]
        output["Reader outcome"]
    end

    %% Operational Flow Edges
    source --> s0
    s0 --> s1
    s1 --> s2
    s2 --> output

    %% Premium Styling Rules

Mermaid source

flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        source["Standard RFP Answers: HELM"]
        s0["1. Security & Compliance"]
        s1["2. Technical Architecture"]
        s2["3. Reliability"]
        output["Reader outcome"]
    end

    %% Operational Flow Edges
    source --> s0
    s0 --> s1
    s1 --> s2
    s2 --> output

    %% Premium Styling Rules

Operational Readiness

Use this page as the public operating layer for RFP Answers. The source of truth is helm-ai-enterprise/docs/public/product/rfp-answers.md; if this page and the implementation disagree, update the source-backed doc and rerun the validation command before publishing.

Before relying on this surface, confirm three things: the source path above still exists, the referenced commands or contracts are still present in the owning repo, and the docs-platform export surfaces still show this page in search, Markdown, llms-full.txt, and MCP without exposing protected routes.

Validation command: corepack pnpm run docs:coverage && corepack pnpm run docs:truth. For website parity, also run npm run exports:boundary and npm run thin-pages:check from docs-platform.

Expected Output

A reader should leave with a concrete next action, the source file or contract to inspect, the command that proves the claim, and a clear boundary for what is public versus protected. For reference pages, the expected output is a correctly scoped request, schema, command, or diagnostic path. For operations pages, the expected output is a reproducible readiness or failure signal that can be attached to an evaluation or support thread.

Failure Modes

If the validation command fails, do not patch this page in isolation. First identify whether the drift is in code, generated contracts, source-owner docs, or the docs manifest. If the public page needs a protected deep link, describe the protected document by name instead of exposing its route. Commercial operator details, tenant data, key ceremonies, and deployment-sensitive internals stay in protected customer or staff docs; this public page only exposes the safe developer contract.