← Back to Blog

Inside the Nora Dashboard: Where AI Sessions Become Engineering Intelligence

Every AI-assisted coding session produces decisions, patterns, and lessons. Most of it evaporates the moment you close the terminal. Nora catches it all — and the dashboard is where raw session data turns into something you can actually act on.

The Problem with AI Session Transcripts

You finished a four-hour coding session with Claude. You refactored a state machine, caught a race condition, established a naming convention, and decided against a library after weighing three alternatives. Tomorrow, you'll remember maybe two of those things. Your teammate will remember zero.

The session transcript exists, technically. Thousands of lines of back-and-forth buried in a log file. Nobody is going back to read that. The decisions, the reasoning, the hard-won patterns — they're functionally lost.

Nora solves this by running every captured session through an analysis pipeline. Claws capture transcripts from your AI tools — Claude Code, Claude Chat, Claude Desktop, Kiro, Cursor, Cline — and send them to the Nora Engine via a local Unix socket. The engine extracts structure from chaos: playbooks (reusable approaches that worked), anti-patterns (mistakes worth remembering), CLAUDE.md rules (conventions that should be codified), and bugs discovered along the way.

The dashboard is where all of that becomes visible.

KIQ: A Single Number for Engineering Knowledge

The first thing you see when you open the Nora dashboard is a number inside a ring. This is your Knowledge Intelligence Quotient (KIQ) — a composite score from 0-100 that represents how much reusable engineering intelligence your sessions have produced.

localhost:2742 — Nora Dashboard
73
Knowledge Intelligence Quotient
142
Sessions
89
Playbooks
34
Anti-Patterns

KIQ isn't a vanity metric. It's computed from four weighted factors: the density of reusable patterns extracted per session, the ratio of novel insights to repeated observations, the severity distribution of bugs discovered, and the decay rate of your knowledge base (more on that shortly). A KIQ of 73 means your recent sessions are producing a strong volume of actionable intelligence with moderate novelty — you're refining established patterns rather than breaking new ground, which is exactly what you'd expect mid-sprint.

Below the ring, three counters show the raw inventory: total sessions analyzed, playbooks extracted, and anti-patterns flagged. These are the building blocks. The KIQ synthesizes them into a signal.

Session Detail: What Actually Happened

Click into any session and you get the full decomposition. This is where Nora's analysis engine earns its keep.

Each session is broken into three extraction categories:

localhost:2742/sessions/a3f7c...
SESSION
Refactor upload state machine to use explicit enum
Claude Code · 47 min · KIQ 81
Playbook State Machine Migration Pattern
Replace multiple @State booleans with a single enum. Map each boolean combination to an enum case. Update switch statements exhaustively — compiler catches missing cases. Apply to upload, chat, and report generation flows.
Anti-Pattern Boolean State Explosion
Using isUploading + isExtracting + hasError + hasResult creates 16 state combinations, only 5 of which are valid. Invalid states cause blank screens and impossible-to-debug UI glitches.
CLAUDE.md Rule Rule #64: Explicit State Enums
Use explicit state machine enums for multi-state UI flows — NEVER multiple @State booleans. Upload, chat, and report generation flows have 4-6 states. Use one enum.

Playbooks are the positive extractions — approaches that worked and should be repeated. The state machine migration pattern above is a textbook example: specific enough to be actionable, general enough to apply across multiple features.

Anti-patterns are the inverse — mistakes identified during the session that should be avoided in future work. Nora doesn't just flag that something went wrong; it captures the failure mode specifically enough that you'd recognize it if you saw it again.

CLAUDE.md rules are the most concrete extraction. These are conventions precise enough to be committed to your project's CLAUDE.md file — instructions that future AI sessions will follow automatically. The engine detects when a session produces a decision that should be codified as a rule, drafts it, and stages it for your review.

The Activity Feed: Patterns Across Tools

The Activity tab is a chronological feed of every analyzed session. What makes it interesting is the cross-tool correlation. When you use Claude Code for backend work in the morning and Cursor for frontend work in the afternoon, Nora sees both. It can identify when a decision made in one tool contradicts a convention established in another — or when the same anti-pattern appears across tools, suggesting a systemic gap rather than a one-off mistake.

localhost:2742/activity
Refactor upload state machine
Claude Code
KIQ 81
Fix CoreData migration crash
Kiro
KIQ 67
Add API response validation
Claude Desktop
KIQ 74
Dashboard component refactor
Cursor
KIQ 52
Debug WebSocket reconnection
Cline
KIQ 69

Each session shows which tool captured it, its individual KIQ score, and a one-line summary auto-generated from the transcript. The scores vary — a routine refactoring session might score 52 (low novelty, few new patterns), while a deep debugging session that uncovers a systemic issue might hit 81. That variance is the signal. It tells you which sessions are worth revisiting and which were maintenance work.

The Issue Tracker: Bugs That Surfaced During AI Work

Nora doesn't just track what you built. It tracks what broke, and what you discovered was already broken.

The Issues tab pulls every bug, crash, and defect that surfaced during analyzed sessions. Each issue is tagged with severity (Critical, High, Medium, Low), the session where it was found, and the file path. What Nora adds is recurrence tracking — if the same class of bug appears across multiple sessions, it escalates the severity and flags it as a systemic issue rather than a one-off.

This is especially valuable for teams. A solo developer might remember that they've seen a particular crash pattern before. Across a team of five, where the same bug surfaces in three different developers' sessions over two weeks, that institutional memory doesn't exist without tooling.

Sprint Metrics: The Engineering Heartbeat

The Sprint tab aggregates session data into weekly engineering metrics. It's the view you'd pull up during a retrospective or a standup.

localhost:2742/sprint
23
Sessions This Week
18h
AI-Assisted Time
12
New Playbooks
7
Bugs Found
4
Rules Generated
+6
KIQ Delta

The numbers tell a story. Twenty-three sessions totaling eighteen hours of AI-assisted work. Twelve new playbooks extracted — patterns that didn't exist in the knowledge base before this week. Seven bugs surfaced. Four rules generated. And a KIQ delta of +6, meaning the project's engineering intelligence grew by six points over the week.

The KIQ delta is the metric that matters most at the sprint level. A positive delta means the team is learning — accumulating reusable knowledge faster than it's decaying. A negative delta means the team is operating on stale patterns, or doing routine work that doesn't produce new insights. Neither is inherently bad. But knowing which regime you're in changes how you allocate time.

Intelligence Half-Life: Knowledge Decays

This is the concept that makes Nora more than a session logger. Every extracted pattern has a half-life — a measure of how long it remains relevant.

A playbook about iOS 17's onChange modifier deprecation has a long half-life. The API won't change again for a year. A playbook about working around a specific Xcode beta bug has a half-life of weeks — the next beta will likely fix it. Nora models this decay and adjusts KIQ accordingly. Patterns that haven't been reinforced by recent sessions gradually lose weight in the score.

The practical effect: your KIQ slowly drops if you stop learning. Not because you're getting worse, but because the landscape is changing and your captured knowledge is aging. It's a nudge. A signal that the patterns you're relying on may need revisiting.

Local-First, Zero-Cloud

Every screenshot, every data point, every extracted pattern in this article comes from a dashboard running on localhost:2742. That's not a development convenience — it's the architecture. Nora runs entirely on your machine. Your session transcripts never leave your device. Your SQLite database (echo.db) is yours.

You bring your own LLM API key for analysis. The analysis calls go from your machine to your LLM provider. Kernora never sees your code, your sessions, or your patterns. The dashboard is a local web server that reads your local database. When you close it, nothing persists anywhere else.

If you work on a team, the optional Team mode syncs sanitized data to your own S3 bucket. Still not our servers. Still your data. We designed it this way because developer session transcripts contain proprietary code, architectural decisions, and security-sensitive reasoning. That data should never touch a third-party server.

Getting Started

Nora installs in one command and starts capturing immediately. Install the engine, add a Claw for your preferred AI tool, and the dashboard populates as you work.

# Install the Nora Engine + every adapter
curl -fsSL https://kernora.ai/install | bash

# The installer registers the Claude Code, Kiro, VS Code, and Cursor adapters
# automatically. See github.com/kernora-ai/nora#install for the full list.

# Open the dashboard
nora dashboard

The dashboard is useful from session one. But it becomes indispensable around session twenty, when the cross-session patterns start emerging — when Nora shows you that you've encountered the same state management issue four times in two weeks, or that your most productive sessions consistently follow a particular structure.

That's the shift. From treating each AI session as disposable, to treating them as a compounding knowledge asset.

Try Nora

One command. Local-first. Your API key. Your data.

Install Nora