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 promptEvent 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
Score Ranges
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.
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>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>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>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>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>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 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
HighHow 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
HighMemories linked to the files you're currently editing get a boost. If you're working on auth.ts, memories about authentication are prioritized.
Recency
MediumRecent 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
MediumThe original importance score assigned during capture. Architecture decisions (0.9) outrank minor observations (0.3).
Acceptance History
MediumMemories 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
LowMemories 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
- 01Token limit is set per-project (default: 4,000 tokens, configurable up to 16,000).
- 02Ranked memories are added to the injection pack from highest score to lowest.
- 03Each memory's token count is estimated before inclusion.
- 04When the budget is nearly full, remaining memories are skipped.
- 05The final pack is wrapped in a <nordon-context> XML block and injected into the system prompt.
Priority Ordering
Always included, no matter the budget. Use sparingly.
Security rules, compliance requirements. Score 0.90+.
Current sprint, ongoing work, recent decisions.
Ranked by the 6 retrieval signals. Best fit first.
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.