Technical Deep Dive

How NORDON Works Under the Hood

A detailed look at the pipeline, scoring engine, memory types, retrieval ranking, and token budgeting that make NORDON work.

Section 1

The Pipeline

Every piece of knowledge flows through two pipelines: one for capturing memories, one for recalling them.

Capture Pipeline (during session)

Event Capture ──▶ Secret Scan ──▶ Importance Score ──▶ Memory Classification ──▶ Store
     │                  │                  │                       │                  │
  Hook fires       Strip API keys    Score 0.0-1.0         Tag as DECISION,      SQLite
  on tool use,     passwords,        based on signals      FAILURE, FACT,        with full
  session end,     tokens, PII       (see Section 2)       PATTERN, etc.         metadata
  errors, etc.

Recall Pipeline (at session start)

Session Start ──▶ Retrieval Query ──▶ Ranking ──▶ Token Budget ──▶ Injection
      │                    │                │              │              │
  Hook fires          Build query       Score & rank    Pack memories   Inject as
  PreToolUse          from current      using 6          within token   <nordon-context>
  on session          branch, files,    signals          limit          XML block
  init                recent context    (see Sec 4)      (see Sec 5)    into prompt

Event Sources

  • Tool use (file edits, terminal commands)
  • Session start and end
  • Error occurrences
  • Explicit user annotations
  • Git operations (commit, branch, merge)

Security Layer

  • Regex-based secret detection
  • API key pattern matching
  • PII scanning (emails, tokens)
  • Configurable allow/deny lists
  • Secrets never reach storage

Storage Format

  • SQLite database (single file)
  • Full-text search index
  • Embedding vectors for similarity
  • Metadata: branch, files, timestamps
  • Exportable JSON format

Section 2

Scoring Engine

Not everything is worth remembering. The scoring engine decides what matters and how much.

Signals Detected

Architecture decisions0.85 - 0.95
"We chose X because Y" patterns
Failure & debugging0.80 - 0.95
Errors, root causes, and fixes
Security constraints0.85 - 1.00
Auth rules, PCI, compliance requirements
Performance insights0.70 - 0.90
Benchmarks, optimizations, bottlenecks
Coding patterns0.60 - 0.80
Naming conventions, file structure rules
Project facts0.50 - 0.75
Stack info, config values, URLs

Score Ranges

0.90 - 1.00Critical
Security constraints, breaking change warnings, core architecture. Almost always injected.
0.70 - 0.89Important
Key decisions, significant failures, deployment procedures. Injected when relevant.
0.40 - 0.69Useful
Patterns, conventions, project facts. Injected when directly related to current work.
0.00 - 0.39Low Priority
Minor observations, one-time fixes. Rarely injected unless specifically relevant.

Feedback Learning

Scores aren't static. When an injected memory leads to a successful outcome (the AI's suggestion was accepted), the memory's score gets a small boost. Memories that get injected but ignored or contradicted get a small penalty. Over time, the system learns what actually helps.

Section 3

Memory Types Deep Dive

Seven structured memory types, each designed for a different kind of knowledge. Here's exactly what gets stored.

FACT

Facts

Concrete truths about your project that rarely change.

Stored memory example

<nordon-context>
  <memory type="fact" importance="0.75">
  ## Tech Stack
  - Backend: Node.js 20 + Express 4.18
  - Database: PostgreSQL 15, hosted on AWS RDS
  - Frontend: React 18 + Next.js 14 (App Router)
  - Auth: Clerk (migrated from Auth0 in Q3 2025)
  - API base URL: https://api.acme.com/v2
</memory>
</nordon-context>
DECISION

Decisions

Architectural and technical choices with reasoning and tradeoffs.

Stored memory example

<nordon-context>
  <memory type="decision" importance="0.9">
  ## REST over GraphQL
  Chose REST for API layer. Benchmarks showed 3x better
  performance on read-heavy workload with proper caching.
  GraphQL added complexity without clear benefit at our scale.
  Decision date: 2025-11-15. Approved by: entire backend team.
</memory>
</nordon-context>
PROCEDURE

Procedures

Step-by-step workflows for recurring tasks.

Stored memory example

<nordon-context>
  <memory type="procedure" importance="0.85">
  ## Database Migration Workflow
  1. Create migration: npx prisma migrate dev --name descriptive_name
  2. Review generated SQL in prisma/migrations/
  3. Test: npm run test:db
  4. PR must include migration file + updated schema.prisma
  5. On merge: CI auto-runs prisma migrate deploy
  IMPORTANT: Never modify an existing migration file.
</memory>
</nordon-context>
FAILURE

Failures

Past mistakes with root causes and fixes, so they never repeat.

Stored memory example

<nordon-context>
  <memory type="failure" importance="0.92">
  ## OOM crash in image processing pipeline
  Symptom: Worker pods killed after processing batch of 50+ images.
  Root cause: Sharp library loads full image into memory for resize.
  Fix: Stream-based processing with pipeline(), limit concurrency
  to 5 images. See PR #892.
  Trigger: Any code that processes images in bulk.
</memory>
</nordon-context>
PATTERN

Patterns

Coding conventions and architectural patterns your team follows.

Stored memory example

<nordon-context>
  <memory type="pattern" importance="0.78">
  ## API Error Response Format
  All API errors must follow this shape:
  { error: { code: "RESOURCE_NOT_FOUND", message: "...",
    details?: {...} } }
  HTTP status codes: 400 validation, 401 auth, 403 forbidden,
  404 not found, 409 conflict, 500 internal.
  Never expose stack traces in production responses.
</memory>
</nordon-context>
CONSTRAINT

Constraints

Hard rules that must never be violated.

Stored memory example

<nordon-context>
  <memory type="constraint" importance="0.95">
  ## PCI Compliance Requirements
  - Credit card numbers must NEVER be logged, even partially
  - All payment data encrypted at rest (AES-256)
  - Payment endpoints require mTLS
  - Audit log retention: minimum 7 years
  - Third-party payment SDKs must be on approved vendor list
  Violation = security incident. No exceptions.
</memory>
</nordon-context>
CONTEXT

Context Snapshots

Current project state -- what's happening right now.

Stored memory example

<nordon-context>
  <memory type="context" importance="0.80">
  ## Active Migration: Monolith to Microservices
  Status: Phase 2 of 4 (extracting UserService)
  - Phase 1 (done): Extracted AuthService
  - Phase 2 (in progress): Extracting UserService
  - Phase 3 (planned): Extracting OrderService
  - Phase 4 (planned): Decommission monolith
  All new code should target the service boundaries defined
  in docs/architecture/service-map.md
</memory>
</nordon-context>

Section 4

Retrieval Ranking

When a session starts, NORDON doesn't dump every memory into the prompt. It ranks them using six signals to find the most relevant ones.

Semantic Relevance

High

How closely the memory's content matches the current task. Uses embedding similarity to find memories about the same topic, even if different words are used.

File Proximity

High

Memories linked to the files you're currently editing get a boost. If you're working on auth.ts, memories about authentication are prioritized.

Recency

Medium

Recent memories score higher than old ones. Uses a 14-day half-life: a 2-week-old memory scores half as much as a brand new one. Pinned memories are exempt.

Importance Score

Medium

The original importance score assigned during capture. Architecture decisions (0.9) outrank minor observations (0.3).

Acceptance History

Medium

Memories that were injected and led to successful outcomes score higher over time. If your AI used a memory and the result was accepted, that memory's rank improves.

Branch Scope

Low

Memories created on your current branch score highest, followed by parent branch memories, then global memories. Keeps feature context separate.

Recency Decay: 14-Day Half-Life

Memory recency follows an exponential decay curve. A memory's recency score halves every 14 days. This means recent context is strongly preferred, but important old memories can still surface if their other signals (importance, relevance) are high enough.

recency_score = e^(-0.693 * days_old / 14)

Day 0:  1.000  (full score)
Day 7:  0.707  (~71%)
Day 14: 0.500  (50% — one half-life)
Day 28: 0.250  (25% — two half-lives)
Day 56: 0.063  (~6% — effectively aged out)

Pinned memories bypass recency decay entirely. If you pin a memory, it always gets its full score regardless of age.

Acceptance Learning

NORDON tracks whether injected memories actually help. After each session, it compares the injected memories against the session outcome. Memories that correlate with successful results (accepted suggestions, resolved issues) get a ranking boost. Memories that were injected but consistently ignored get a small penalty. Over hundreds of sessions, this creates a feedback loop: the system gets better at predicting which memories will actually be useful.

Section 5

Token Budgeting

AI models have limited context windows. NORDON packs the most valuable memories within your token budget, so nothing important gets cut.

How Budgeting Works

  1. 01Token limit is set per-project (default: 4,000 tokens, configurable up to 16,000).
  2. 02Ranked memories are added to the injection pack from highest score to lowest.
  3. 03Each memory's token count is estimated before inclusion.
  4. 04When the budget is nearly full, remaining memories are skipped.
  5. 05The final pack is wrapped in a <nordon-context> XML block and injected into the system prompt.

Priority Ordering

1st
Pinned memories

Always included, no matter the budget. Use sparingly.

2nd
Critical constraints

Security rules, compliance requirements. Score 0.90+.

3rd
Active context

Current sprint, ongoing work, recent decisions.

4th
Relevant memories

Ranked by the 6 retrieval signals. Best fit first.

5th
Background knowledge

General project facts, older patterns. Fills remaining space.

Pinned Memory Boost

Pinning a memory guarantees inclusion in every injection, regardless of score or recency. Use this for critical constraints or active project context that should always be present. Pinned memories consume budget first, so pin sparingly to leave room for dynamic retrieval.

See it in action

Install NORDON and watch your AI coding assistant get smarter with every session.