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

This page answers where HELM's frontend, console, and UI design truth pages live, and which of them are OSS-owned versus HELM AI Enterprise-owned product surfaces. It consolidates the accepted source targets for console development, design-system work, and UX architecture.

## Audience

- Frontend engineers implementing or modifying Console surfaces
- Design-system contributors adding components and interaction states
- Product teams validating UX alignment for evidence workflows
- Security and SRE engineers reviewing auth and session behavior in frontend context
- Technical writers creating product-facing frontend documentation

## Outcome

After reading this page you should be able to:

- locate the source-backed page for every major frontend and console topic before changing implementation,
- avoid duplicating design decisions across OSS and Commercial docs,
- identify the correct public route for a given UI domain,
- and apply the same boundary criteria used by architecture when classifying future console content.

## Mermaid

```mermaid
flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        Console["apps/console"]
        Design["Design System"]
        Control["Control Plane API Consumer"]
        OSS["HELM AI Kernel"]
        Commercial["HELM AI Enterprise"]
        ProductConsole["Product Console Surface"]
        Accessibility["Accessibility & a11y"]
    end

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

    %% Operational Flow Edges
    Console --> Design
    Console --> Control
    Control --> Evidence
    OSS --> Design
    Commercial --> ProductConsole
    Design --> Accessibility
    Control --> ProductConsole

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


## Source Truth

- `apps/console/**`
- `apps/controlplane/**`
- `docs/console/**`
- `docs/ui/**`
- `docs/public/product/console.md`
- `docs/public/frontend/**`

## Console and product pages

- [Console Overview](/product/console) — consolidated product introduction and capabilities.
- Console deployment source: `docs/console/DEPLOYMENT.md` — deployment architecture for console operations.
- Console security source: `docs/console/SECURITY_MODEL.md` — auth and session behavior for user-facing interfaces.
- Console product boundary source: `docs/OSS_VS_COMMERCIAL.md` — explicit OSS vs hosted Console ownership rules.
- Console replay source: `docs/console/REPLAY_AND_RECEIPTS.md` — receipt inspection and replay flows.
- Console lifecycle source: `docs/console/RUN_LIFECYCLE.md` — run states and transitions during execution.
- Console scenarios source: `docs/console/SCENARIOS.md` — scenario-based usage patterns and behavior expectations.

## Design system and component architecture

- Design system source: `docs/public/product/design-system.md` — overall design principles and primitives.
- Design-system package source: `packages/helm-ai-enterprise-design-system/` — package reference.
- Accessibility source: `docs/ui/ACCESSIBILITY.md` — accessibility guidance and validation posture.
- Components and states source: `docs/ui/COMPONENT_STATES.md` — component behavior and documented interaction states.
- Flows source: `docs/ui/FLOWS.md` — user flow and interaction mapping for Console operations.

## UX architecture references

- UX specification source: `docs/ui/UX_SPEC.md` — source spec for UX decisions.
- Information architecture source: `docs/ui/IA_MAP.md` — navigation model and information hierarchy.
- Evidence UX source: `docs/ui/EVIDENCE_UX.md` — design treatment for trust and proof artifacts.
- Agents UX source: `docs/ui/AGENTS_UX.md` — UX patterns for agent-centered interfaces.

## Kernel vs HELM AI Enterprise boundaries (explicit)

For frontend content, OSS ownership typically covers reusable primitives, conventions, and open standards:

- component behavior and accessibility expectations that are intended to be generally reusable,
- route conventions and navigation standards with no commercial operational assumptions,
- and design-system contracts that are expected to apply across deployment contexts.

HELM AI Enterprise ownership typically covers:

- hosted Console operational experience, including enterprise UX policy and product support workflow,
- customer-specific orchestration surfaces where entitlement or tenant policy changes behavior,
- and product packaging where deployment model changes semantics outside shared OSS conventions.

When a page crosses both areas, keep protocol semantics on OSS pages and keep policy packaging or entitlement behaviors on Commercial pages, with explicit links between the two.

## Troubleshooting

- If Console behavior appears inconsistent with docs, verify the implementation path under `apps/console/**` and compare it with `/product/console` or the source paths listed above.
- If component behavior is undocumented, add or update component state docs before adding production changes to reduce drift.
- If accessibility guidance is missing for a change, route that update through `docs/ui/ACCESSIBILITY.md`.
- If a page was moved between OSS and Commercial, update both this page and the boundary page used for that classification.
- If evidence visualizations differ from implementation, check `docs/console/REPLAY_AND_RECEIPTS.md` and `docs/ui/EVIDENCE_UX.md` together; both should reference the same contract assumptions.

## Adoption notes for frontend changes

1. Confirm whether your change is a public UI primitive (OSS) or a Commercial product surface.
2. If primitive: update `docs/ui/**` and/or relevant `docs/console/**` page first, then reflect via this landing page.
3. If Commercial surface: validate that user-facing behavior still links back to OSS baseline contracts, and do not duplicate those contracts in the Commercial page.
4. Keep this page updated whenever new frontend routes are added or ownership changes.