Operator
Map recurring work, exception paths, and the proof needed when an action closes.
MINDBURN LABS
Request Company AI OS ReviewHELM AI Enterprise
Governed action for company AI workflows.
Company context helps AI suggest the right work. It does not give the model permission to act. HELM still checks policy, approval, action, and proof.
Architecture review
The first conversation maps one governed action end to end.
First governed actionreview intake
| Step | What gets decided |
|---|---|
| Name the action | Example: an agent wants to publish a customer-facing release update. |
| Map authority | Who can approve it, which policy applies, and which systems are touched. |
| Set the boundary | When HELM should allow, deny, or escalate before a connector runs. |
| Define proof | Which receipt, approval, and source evidence must exist after the decision. |
Evaluation paths
Start from the boundary your team owns.
Founder
Name which actions AI may suggest, which need human approval, and which must never run.
Security
Trace connector scope, sandbox grants, prompt-injection paths, and deny/escalate receipts.
Compliance
Define which receipts, policy snapshots, approvals, and evidence bundles must be reviewable.
Company action boundary demo
AI proposes a company action. HELM decides whether it may run. The receipt makes the decision checkable later.
ALLOWT1 / dispatched
ProposeDecideReceipt
Send customer message
ALLOW · customer_message.low_risk.v1 · rcpt-demo-d82c6ec7Tamper detectable: changing the verdict produces a different receipt.
Company AI OS
Company context can guide work. HELM still checks action.
The loop is simple: read company work, compare the plan with reality, draft specs for review, run approved action through HELM, and write proof back.
- 01 Understand
Company artifacts, policies, tickets, approvals, PRs, code indexes, receipts, and customer promises become source-backed context.
- 02 Compare
HELM compares what should be true with what the evidence, code graph, deployments, receipts, and customer state say is true.
- 03 Propose
HELM emits ActionProposals, TruthConflicts, DriftSignals, and GeneratedSpecs with risk, approval, rollback, and proof needs.
- 04 Gate
Plans cross CPI and PEP before any connector, production system, payment, customer action, or command gateway runs.
- 05 Prove
ALLOW, DENY, and ESCALATE decisions leave receipts, ProofGraph records, EvidencePack slices, and closure evidence for review.
Operational runtime
Recurring company work is governed, not self-authorizing.
The operating layer can detect drift, generate reviewed work, and close evidence. It cannot skip Kernel authority.
Night Shift
A recurring governed loop ingests signals, emits TruthConflicts, DriftSignals, ActionProposals, and GeneratedSpecs, and cites receipts in the morning report.
Business-function packs
Strategy, Engineering, Support, Growth, and Finance/Admin packs define reads, writes, forbidden actions, approvals, P0 constraints, rollback, and postconditions.
Serious SaaS Mode
Production engineering closure is blocked without staging, passing CI, migration dry-run, rollback, postcondition checks, and transactional email/auth checks where configured.
Code Intelligence Graph
Engineering specs can require pinned commits, CodeIndexReceipts, CodeImpact, affected tests, write_set, route/API review, and closure diff checks.
Morning reports
Morning reports summarize work for operators. Receipts, ProofGraph records, and EvidencePacks remain the source truth.
Closure evidence
Completed work writes execution runs, receipts, EvidencePacks, test results, deployment refs, and confidence back into company state.
Role views
Every team sees the same boundary in its own work.
The hierarchy changes by role, but the product story stays consistent: proposal, authority, action, proof.
Can AI move company work without moving company authority?
A clear path from company goal to checked action, with escalation when risk is high.
- Proof view
- Receipt timelines and ProofGraph records show what changed, who approved it, and why.
Where does the model stop and deterministic execution begin?
GeneratedSpec, Code Intelligence Graph, CPI, PEP, connector grants, and SDK boundaries are separate from model output.
- Proof view
- Policy checks, signed intent, CodeIndexReceipt, CodeImpact, and receipts make the action path checkable.
What prevents prompt-injected work from becoming a side effect?
HELM checks the proposed action, actor, tenant, policy, connector scope, approval state, taint labels, and quarantine state.
- Proof view
- DENY, ESCALATE, and quarantine receipts record the blocked path without running the action.
Which company facts support this decision?
CompanyArtifactGraph organizes source-backed evidence without becoming action authority.
- Proof view
- EvidencePacks bind approvals, policies, and receipts for later review.
Can payment and vendor work be controlled before money moves?
Amount, destination, approval, role, and policy checks happen before connector dispatch.
- Proof view
- Receipts record the proposed effect, verdict, approval reference, and proof pointer.
Can routine work move faster without removing controls?
Night Shift can run low-risk allowlisted work while unclear or risky work escalates.
- Proof view
- Operational history stays visible through receipt-backed timelines, EvidencePacks, and morning-summary references.
What do I integrate with?
Use the Kernel for fail-closed execution and Code Intelligence Graph evidence for scoped engineering proposals.
- Proof view
- Local verification, CodeIndexReceipt, CodeImpact, affected tests, and docs routes explain the contract.
Can the company explain an AI-assisted action after the fact?
The model is not "trust the agent." It is verdict, receipt, replay, and evidence.
- Proof view
- ProofGraph and EvidencePacks provide the review path without making raw context authoritative.
Scenarios
Useful examples show the action boundary.
Vendor payment
- Proposal
- An agent drafts a payment request from invoice and vendor context.
- Gate
- HELM checks amount, payee, role, approval, tenant, policy, and risk before dispatch.
- Proof
- The final decision records ALLOW, DENY, or ESCALATE with receipt and approval links.
Release change
- Proposal
- An agent proposes a release action based on a merged PR, CodeImpact, affected tests, and release note.
- Gate
- Serious SaaS Mode checks staging, CI, migration dry-run, rollback, public route/API impact, and approval before PEP dispatch.
- Proof
- Release intent, policy verdict, CodeIndexReceipt, test receipt, and closure evidence stay tied to release evidence.
Cloud access
- Proposal
- A teammate or agent asks for temporary access to a sensitive environment.
- Gate
- HELM evaluates actor, tenant, duration, resource scope, and approval requirements.
- Proof
- The access grant or denial is reviewable as a bounded receipt-backed event.
Customer promise gap
- Proposal
- Company context suggests a mismatch between a roadmap promise and shipped behavior.
- Gate
- The graph can flag the gap; execution still requires reviewed spec and HELM-gated action.
- Proof
- The conflict, decision, and follow-up work can reference source artifacts and receipts.
Compliance export
- Proposal
- An agent prepares an export for a review, audit, or customer evidence request.
- Gate
- HELM checks data class, requester, purpose, retention, and approval before export.
- Proof
- EvidencePack references preserve what was exported and why without implying public disclosure.
HR workflow
- Proposal
- An agent drafts onboarding or offboarding steps from company policy.
- Gate
- Identity, privacy, approval, and system-specific connector scope decide what can run.
- Proof
- Sensitive actions produce reviewable decisions without making raw HR context an authority source.
Analog or kinetic gateway action
- Proposal
- A digital workflow would ship goods, dispatch people, or trigger a device.
- Gate
- HELM treats analog or kinetic effects as higher-risk work that often needs escalation, telemetry, safety profiles, and emergency-halt evidence.
- Proof
- Receipts and evidence show the contract, route, approval, safety artifacts, and gateway boundary before action.
Code-scope closure
- Proposal
- An engineering agent proposes a code change based on an issue and code graph context.
- Gate
- HELM checks pinned commit, fresh index, read_set, write_set, affected tests, route/API review, and rollback.
- Proof
- Closure requires CodeIndexReceipt, CodeImpact, test receipts, PR or commit refs, and EvidencePack evidence.
Control path
Control the path from context to action.
Company artifacts
Policies, approvals, decisions, and work context stay tied to the execution boundary.
Decision inboxes
Unclear or risky actions go to humans before a connector runs.
Receipt timelines
Allowed, denied, and escalated actions stay reviewable through receipts.
Reviewed access
Mechanism first, packaging later.
This page does not publish pricing, customer names, traction metrics, deployment guarantees, or private roadmap detail.
The next step is architecture review: which actions need checks, which systems are involved, what proof is needed, and when humans must approve.
FAQ
HELM AI Enterprise FAQ
Is HELM AI Enterprise generally available?
No. HELM AI Enterprise is reviewed access. It uses the same fail-closed boundary as HELM AI Kernel and is evaluated through architecture review.
Does HELM AI Enterprise replace HELM AI Kernel?
No. HELM AI Kernel remains public. HELM AI Enterprise adds company workflows, review inboxes, and integrations around the boundary.
Why is pricing not listed?
The public path starts with architecture review. Pricing will not be listed until packaging and legal terms are real.
Next step
Discuss governed execution with real action boundaries.
Bring the systems an agent may touch, the actions that need approval, and the proof you need after each decision.