AI writes code fast. HalaBrain is being built to make that speed safe to ship — it governs the delivery loop around a swappable AI executor and independently re-runs the tests and re-checks the rules against the real changed code. The core loop works today; the deeper governance is taking shape.
AI agents ship code in minutes. But left ungoverned they drift, over-engineer, duplicate, and work out of context — fast in the wrong direction.
HalaBrain's north star is to solve the LLM memory & context problem: keep agents anchored to the always-current ground truth — the code, the knowledge vault, the rulebook, and the gates — so what gets built is what was actually asked for, and provably so.
Plug in your code and your governing documents. AI turns both into a living, anti-drift knowledge base; every rule links to an approval gate routed to a responsible role; and when development runs, coordinated agents enforce every gate so nothing ships without the right approvals — while keeping concurrent users from colliding.
That's the destination. Today the engine, the governed loop, multi-tenant tenancy, and the governance spine already exist; the anti-drift, retrieval, and quality work around them is still ahead. This page shows exactly how far along each piece is — nothing more.
Read a codebase and produce the structured vault + the rules already embedded in the code. (Built.)
Upload regulations, governance, and strategy; they become the per-tenant rulebook and references. (Built — SP-3. Design files from Figma still planned.)
Every rule links to an approval gate assigned to a role — AI suggests, the admin confirms. (Built — SP-3.)
Aware agents enforce every gate and never collide on the same files. (Loop built; locking + tenancy ahead.)
AI writes code fast. HalaBrain makes that speed safe to ship. Step through the idea — from the problem, to the ideal, to the governed loop that proves it.
Left unchecked, agents over-engineer, duplicate, and work out of context — fast in the wrong direction.
Plug in your code and your governing documents. The Brain turns both into a living, anti-drift knowledge base; every rule links to an approval gate routed to a responsible role.
—
BrainIndependent verification re-runs the real tests, re-reads the real files, and re-checks the rules against the real code. Two human gates. Branches, never the trunk.
Speed comes from the AI; trust comes from the governance.
Shows the canonical happy path; opt-in clarification parks and off-path outcomes (rejected / needs-attention) are omitted for clarity. Stage names are the real lifecycle stages.
Governance grounds the Brain; the Brain decides and verifies; the plugged-in targets act — and every layer runs on a swappable LLM. Hover a component, or trace a change end‑to‑end.
Hover a component to see what it does — or trace a change end-to-end.
hover / focus a component · click a model provider to swap it · ▶ trace a change
The living truth + the rules the Brain is bound by.
Owns the decisions and the state — never edits code itself.
The real world the change lands in — swappable.
The Brain writes no code — it dispatches a gated work order. No code is written until the intake gate approves the intent; nothing merges until the acceptance gate re-verifies the real diff.
Every subsystem and the typed contracts that pass between them — grounded, gated, built, and on the roadmap. Pan, drag, click a component, or ▶ trace a change.
Two views from the system as it exists today — a governed change moving through the pipeline, and the code-synced Obsidian vault that keeps the agents grounded. Real stages, real checks, real notes.
The build is delegated to an AI executor that branches, codes, and opens a PR — minutes of work, not days.
Intent modes mean a question can stay a question — only real builds spin up the team, not every message.
Results are independently re-tested and re-checked against the real diff before they're accepted — the part that works today.
A single governed lifecycle from requirement to deployed baseline, with every state visible and persisted.
On doubt the gate blocks or asks for approval. The richer, dynamic, tenant-defined governance is still being built.
Honestly: the verified core loop delivers the first dimensions today. The deepest one — rich, dynamic governance — is a foundation we're still hardening, not a finished claim.
The acceptance gate is the heart of the system. It re-runs the project's real test suite and re-checks the governance rules against the real changed code — never trusting the executor's own word, including our own team's reviewer.
FR-19 · NFR-3 · fail-closedA code-synced Obsidian knowledge vault is the living ground truth: architecture, contracts, flows, and a requirement map. It's read before every task and reconciled after — when a note and the code disagree, the code wins and the note is fixed.
bidirectional · always-currentToday, governance rules live as editable config and drive the gates by keyword, path, and content. The richer, per-tenant tag-ontology rulebook with approval routing and an authoring UI is designed but not built yet — it's the next big piece, not a current capability.
today: rules-as-config · richer: plannedBehind the unchanged executor seam, a deterministic leader decomposes one work order across up to 11 specialist AI engineers, runs them in isolated git worktrees in parallel, and returns one build on one branch. Any role failure fails closed to an explicit decline.
11 roles · worktree-parallelThe data foundation is in place: row-level tenant isolation in three layers (application filters, Postgres RLS, an adversarial proof suite) and a capability-enum identity model. Auth (email + emailed-OTP) is built but not yet merged or switched on; the full tenant experience is still ahead.
SP-1 · foundation laid, auth landingVersion control, deploy target, LLM provider, and the executor itself sit behind swappable interfaces. The design intent is that new backends plug in behind the seam without touching the governed core — proven by the seams, not yet by a marketplace of integrations.
design intent · seam-isolatedA product lead decides who's needed from the analysis. Foundation roles go first, implementers build in parallel isolated worktrees, and the verification layer runs serialized to avoid conflicts. The leader's own reviewer is extra diff — never a gate. The independent acceptance gate still re-runs everything.
One work order in, one build on one branch out. The conversation is fully observable — every plan, instruction, and agent message is streamed live into a read-only timeline, with zero weight on the gate.
Version control, deploy, the LLM, and the executor each sit behind an adapter. Today the system is wired to a handful of backends through configuration — there is no connectors UI and no setup wizard. Everything in the second group below is a direction the architecture allows, not a shipped integration.
To be clear: only GitHub, Railway, Anthropic Claude, PostgreSQL, and the local non-prod runner are actually wired right now — and they're configured in code/env, not through any in-product connector flow. Codex, Gemini, GitLab, AWS, Oracle, Alibaba, MCP, and Figma (a planned design-source integration) are planned directions the adapter seam is meant to make easy later — none of them is built. We don't stub things as real: an adapter that can't do something declines explicitly.
The engine was built across seven phases — each runnable, tested, with a one-command demo and a review pause. On top of it, a series of sub-projects hardened execution and added the AI team and the comprehension vault. This part is real and merged; it's the ground the platform work below is being built on.
Knowledge base + baseline + impact analysis + report.
Approval gating with persisted work-item lifecycle.
Typed contract + the swappable executor interface.
Headless Claude Code → real diff + real PR.
Real tests + rule re-check + security/static on the real diff.
Deploy + close the loop with a baseline re-scan.
The Fastify API + the React dashboard.
Interrupted runs park & recover; deploy failures stay recoverable, never silently "done".
The governed AI engineering team behind the executor seam.
Ask / Plan / Build — a question can stay a question; clarify before building.
Polyglot scan → anti-drift Obsidian vault, generated & governed.
Read-only in-app vault browser + live team-conversation timeline.
The mission turns the single-tenant engine into a multi-tenant governance platform. It's decomposed into seven sub-projects (SP-1 → SP-7, the last being requirements-grounded conformance) and ~29 small phases — each one runnable, tested, and reviewed before the next. Statuses here are honest: SP-1, SP-2, and SP-3 are all merged; the rest are designed or planned, not built.
The foundation everything depends on: close the open app with auth; tenant / project / user / membership / role data; row-level tenant_id isolation across every table; a tenant-defined role registry over a capability enum.
Stop two people / agents building on overlapping files: path-level leases with an early predictive block and a hard backstop at the real git diff (conflicts prevented, not patched), plus per-project concurrency.
Replace today's regex rules with a real tag-ontology rule engine: a layered framework + an AI classifier, deterministic approval routing to accountable roles (SoD / maker-checker), the AI Development Contract, and an AI-suggest / admin-confirm authoring UI. This is the heaviest sub-project — and where "tight, dynamic governance" actually gets built.
Keep code + vault + rules mutually current in both directions: a code change that leaves a note stale — or a rule edit that diverges from the code — becomes a routed finding (warn + approve), and an accepted drift regenerates only the affected notes.
Keep agents grounded cheaply: a deterministic per-project manifest behind a retrieval adapter feeds a session only the few notes and files it actually needs. No vector store, no embeddings RAG — exact structured lookup, an optional adapter swap if ever needed.
Make it measurably good and improving — without any model fine-tuning: an evaluation harness that scores extraction / classification / routing accuracy, and a deterministic suggestion-feedback loop. The gate and independent verification are never an input or output of it.
Give the system's own reverse-engineered requirements and past gate decisions a governance role at intake: when a work order looks out of scope, a duplicate, or a contradiction of a grounded invariant, it escalates to a human — never auto-blocking, never touching the independent acceptance gate. Fail-closed and opt-in, so an area with no grounded requirement is never silently passed. Newest direction on the plan; nothing here is built yet.
The current interface is a web dashboard — submit a requirement and follow it through analysis, the gates, the build, independent acceptance, the deploy, and the baseline. It's early, but the loop runs end to end on the web today, showing real diffs and real output rather than status text.
Not built yet — a direction, not a release. Because the engine is a thin API behind a typed contract, a mobile client could become another front-end over the same governed core. That's the plan, once the web experience and the governance underneath it are solid.
AI suggests. The human confirms.
The system proposes; an authorized human disposes. Speed comes from the AI, trust from the governance — and getting that balance right, dependably, is exactly the work still in progress.
A working core loop with independent verification and an AI team, an honest roadmap for the governance, collaboration, and integrations still ahead — and a commitment to never claim more than is actually built.