---
title: "Individual Governance"
canonical: "https://helm.docs.mindburn.org/helm-ai-enterprise/individual"
source: "helm-ai-enterprise/docs/public/product/individual-governance.md"
edit: "https://github.com/Mindburn-Labs/helm-ai-enterprise/edit/main/docs/public/product/individual-governance.md"
section: "helm-ai-enterprise"
access: "public"
sensitivity: "public"
last_reviewed: "2026-05-20"
checksum_sha256: "sha256:f43b424949525438ad0420405e4af49d7bdd7c80b282fe5d98ffee9ebd7efd02"
build_timestamp: "2026-05-24T13:40:27.882Z"
---
# Individual Governance

HELM AI Enterprise Individual is the team-scale control plane around HELM AI Kernel. It gives developers and small platform teams shared workspaces, scoped keys, approvals, policy bundles, audit trails, and receipt search without changing the kernel's execution semantics.

## Audience

Use this page if you are evaluating the Individual route for a small team, setting up shared governance for local or CI agents, or comparing Individual and Enterprise operating responsibilities.

## Outcome

After reading this page, you should know what the Individual route adds, which source files own the implementation, and where to verify the API and receipt behavior before a rollout.

## Governance Flow

```mermaid
flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        workspace["Workspace"]
        roles["Roles and keys"]
        review["Review and refine"]
    end

    subgraph Evaluation["2. Evaluation & Policy Plane"]
        policy["Policy bundle"]
    end

    subgraph Execution["3. Execution & Verdict Plane"]
        runtime["Governed runtime"]
        decision{"ALLOW, DENY, or ESCALATE"}
    end

    subgraph Ledger["4. Tamper-Evident Ledger Plane"]
        receipt["Receipt and audit trail"]
    end

    %% Operational Flow Edges
    workspace --> roles
    roles --> policy
    policy --> runtime
    runtime --> decision
    decision --> receipt
    receipt --> review
    review --> policy

    %% Premium Styling Rules
    style policy fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style runtime fill:#3182ce,stroke:#2b6cb0,stroke-width:2px,color:#fff
    style decision fill:#e53e3e,stroke:#9b2c2c,stroke-width:2px,color:#fff
    style receipt fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
```


## What Individual Adds

- Shared workspaces for product teams and internal platforms.
- Role models for developers, approvers, auditors, and admins.
- Scoped API keys for local development, CI, staging, and production.
- Policy bundles that define allowed, denied, and escalated actions.
- Audit trails that connect actions to receipts.
- Review practices for denied and escalated receipts during rollout.

The implementation route family is mounted at `/api/basic/` for compatibility. Public docs should refer to the product route as Individual while keeping exact implementation paths visible where operators need them.

## Rollout Shape

Start with one workspace and one narrow policy bundle. Bind a local-development key to that workspace, route one non-production agent through the HELM boundary, and require a denied-action receipt before expanding the rollout. Once the team can find allowed, denied, and escalated receipts without reading application logs, add a staging key and a stricter policy bundle for higher-risk effects.

Production use should split developer, approver, auditor, and admin roles. Developers can request governed actions and inspect their own receipts. Approvers review escalations and record decisions. Auditors export evidence and verify receipts. Admins manage workspace membership, keys, retention, and policy attachment. The same person can hold multiple roles in a small team, but production policies should still prevent self-approval for consequential effects.

## Boundary

Individual does not change the HELM AI Kernel decision model. It adds shared administration around the same receipts, policy bundles, and evidence paths. Hosted Enterprise deployments add broader tenant, directory, retention, SIEM, and upgrade controls; Individual is the smaller team route for getting shared governance in place before those organization-wide controls are required.

## Source Truth

- Implementation router: `commercial/basic/server.go`
- Workspace model: `commercial/basic/workspace.go`
- RBAC model: `commercial/basic/rbac.go`
- API key model: `commercial/basic/apikey.go`
- Approval model: `commercial/basic/approval.go`
- Evidence index: `commercial/basic/evidence_index.go`
- Runtime bridge: `commercial/basic/runtime_bridge.go`
- API reference: `docs/11_API_REFERENCE.md`
- Team governance guide: `docs/public/product/agent-skills-governance.md`

## Troubleshooting

| Symptom | First check |
| --- | --- |
| Individual route behavior is unclear | Check `commercial/basic/server.go` and `docs/11_API_REFERENCE.md`. |
| A team cannot find its receipts | Confirm the workspace ID, active policy bundle, and evidence index route. |
| A developer can approve their own production action | Split developer and approver roles before production rollout. |
| Public route names and implementation paths look different | Treat Individual as the product route and `/api/basic/` as the compatibility implementation path. |