What is arka.norn?

arka.norn is a local-first governance and delivery framework for coding agents.

You keep working in Claude Code or Codex through their normal interfaces. Norn does not replace the coding agent or add another chat. A skill connects the agent to the framework, while Norn keeps the governed project state outside the conversation.

That state is shared across a local Web cockpit, TUI and CLI.

The goal is to separate two things that are often mixed together: what the model is free to reason about, and what the system is allowed to accept as project reality.

Why I built it

I started building products with coding agents about two years ago.

As the projects became larger, I kept running into the same class of problems.

An agent could accept a rule, then reinterpret it a few turns later. It could know that a document existed without actually reading it. It could inspect a README and a few directories, then describe an unfamiliar repository with enough confidence to make an incomplete exploration look exhaustive.

Even simple instructions could produce valid but unwanted interpretations.

"Fix the bugs" could become disabling what caused the errors.

"Ship the feature" could become finishing the implementation and calling it shipped.

"Simplify the homepage" could become removing almost everything except the main CTA and footer.

The agent had followed the instruction. The problem was that the instruction did not enforce its interpretation, its boundaries, or the evidence required to satisfy it.

I first tried solving this with more documentation, profiles, procedures, Markdown files and skills.

Eventually I reached the idea behind Norn:

A skill carries the method. The system carries the authority.

Live framing and durable project state

Norn turns the work discussed with the agent into a resumable local plan.

The human remains responsible for the important boundaries. Framing has two explicit stabilization points: repository grounding, then publication and delivery-route binding.

Before publication, the framing state stays outside the repository.

After publication, an immutable fingerprinted plan revision becomes the durable recovery source.

The chat remains useful for working with the model, but it is no longer the only place where the project state exists.

This also makes the state provider-portable. A later session, or another supported provider, can recover from the published plan instead of reconstructing the project from a previous conversation.

Repository discovery is governed too

The same principle applies before code is changed.

For an unfamiliar repository, Norn can prepare a read-only Project audit.

The human first selects the decision they are trying to support, the scope and the domains to inspect. Norn prepares the audit plan, and collection starts only after the human reviews and approves it.

The audit can collect evidence and findings, but it cannot modify Project files or control Agents.

The model therefore does not get to decide by itself that reading a README and a few directories is sufficient discovery.

Product documents also retain their provenance, dependencies and history, so legacy documentation can remain accessible without silently becoming the current source of truth again.

Web, TUI and CLI

Norn exposes the same durable state through three surfaces.

The Web UI is a local control cockpit for framing, Features, documents, decisions, audits, registered Agents and orchestration state.

The TUI provides an interactive terminal cockpit.

The CLI provides exact commands and stable machine-readable output for automation.

The Web interface is not another AI chat. The agent remains in the provider you already use.

Interactive work and automatic orchestration

There is an important distinction between the two modes.

When working interactively in Claude Code or Codex, Norn governs project state but does not pretend to sandbox the provider itself. If Claude Code gives the agent Bash, Bash is still available.

Automatic orchestration is a separate mode, and that execution is sandboxed.

Mastra orchestrates the task DAG. Tasks use isolated Git worktrees and bounded read/write scopes, and their effects pass through the Norn broker.

Agents propose changes. Norn checks whether those changes stay inside the declared scope and whether the required mechanical evidence exists.

For example, the model can say that the tests pass. Norn can verify that the configured test recipe actually passed and that the resulting diff stayed inside the allowed write scope.

When the operation is authorized, Norn creates the commit.

This is the distinction at the center of the project:

A rule in a skill influences the model.

A capability that is absent or refused by the system actually constrains it.

Built with Norn

The first usable version of arka.norn was formalized quickly, but the approach behind it comes from roughly two years of experimenting with coding agents, discarded architectures and real project failures.

arka.norn is being built with arka.norn.