What is a Context Tree?
A context tree is your project’s hierarchically organized knowledge base stored in.brv/context-tree/. It captures patterns, best practices, and learnings in a structured format that’s both human-readable and intelligently searchable.
Structure
The context tree organizes knowledge into a three-level hierarchy. ByteRover also automatically maintains several system-generated files alongside your curated content — described in detail in the sections below.1. Domains
Top-level folders that group related knowledge areas. ByteRover automatically detects and creates domains on-demand as you curate, letting your context tree structure emerge naturally from your project.2. Topics
Specific subjects within each domain:3. Subtopics (Optional)
Deeper organization within topics (maximum one level):Auto-Generated Overview Files
ByteRover creates acontext.md file at each hierarchy level when you first curate into a domain, topic, or subtopic. These overviews document the scope and purpose of each node, making the tree self-describing and easier to navigate.
Domain-level context.md — describes what the domain covers and its boundaries:
context.md — summarizes the topic’s focus and connections:
context.md — narrows focus within a parent topic:
Hierarchical Summaries (_index.md)
After each curation, ByteRover automatically generates an _index.md file inside every directory that received new or updated content. The summary propagates upward through the hierarchy — a change to a subtopic file triggers regeneration at the subtopic, topic, domain, and root levels.
Each _index.md contains a system-generated condensed summary of the directory’s knowledge with YAML frontmatter:
condensation_order indicates depth relative to the context tree root:
_index.md files are not synced with vc push/vc pull — they are regenerated locally after each curate. They are also excluded from BM25 search indexing, but injected as structural context when ByteRover uses an LLM to answer a query (Tier 3/4).
Knowledge Abstracts
ByteRover generates two companion files for each knowledge file, providing compressed representations at different levels of detail:
For example,
jwt_token_generation.md produces two siblings:
jwt_token_generation.abstract.mdjwt_token_generation.overview.md
.abstract.md siblings when injecting context for LLM queries, falling back to the full knowledge file if the abstract hasn’t been generated yet. This reduces token usage while preserving the key information the agent needs.
Manifest (_manifest.json)
ByteRover maintains a _manifest.json at the root of the context tree. It provides a token-budgeted registry of all context entries, organized into three lanes:
For LLM-based queries (Tier 3/4), ByteRover reads the manifest to determine which files to inject as structural context without scanning the full tree on every request. The manifest is rebuilt opportunistically after each curation (if summaries changed) and lazily on query if stale. It is not synced with
vc push/vc pull.
Archive System
Knowledge files that fall below an importance threshold are eligible for archiving. A file qualifies when it meets both criteria:- Maturity:
draft(has not yet been promoted tovalidatedorcore) - Decayed importance: below 35 after applying the recency decay function
_archived/, mirroring the original path:
Archive Stub (.stub.md)
A compact ghost cue (~220 tokens) that remains BM25 searchable. It contains a system-generated summary of the original content and frontmatter with lineage metadata:
vc push/vc pull.
Full Archive (.full.md)
A lossless copy of the original file. It is not searchable and not synced. Its sole purpose is to be readable on demand when you need the complete original content.
Full Structure Example
With all components in place, a mature context tree looks like this:Knowledge Files
Each topic (and subtopic) contains markdown knowledge files with descriptive names. These files use YAML frontmatter for semantic metadata (title, summary, tags, related, keywords, timestamps) alongside the knowledge content. File format:Frontmatter Fields
Since 3.8.0,
brv curate and brv dream always write all seven fields. Files written by earlier versions without summary still load fine — the field is optional on read.Content Sections
Knowledge files can contain up to three optional sections:- Raw Concept — Technical metadata: task description, relevant files, execution flow, patterns
- Narrative — Descriptive context: structure, dependencies, rules, examples, diagrams (Mermaid, PlantUML)
- Facts — Structured factual statements extracted during curation, each with an optional subject, value, and category (
personal,project,preference,convention,team,environment,other)
Scoring Metadata
Every knowledge file carries scoring signals that determine how it ranks in search results and where it sits in the maturity lifecycle. These signals live in a per-project sidecar outside the context tree, sobrv vc status and brv vc diff stay clean even as search and curation update them in the background.
Importance (0–100) — Reflects how valuable this knowledge is. Starts at 50 for new files:
- +3 each time the file appears in search results (batch-flushed during index rebuild)
- +5 each time the file is updated via curation
- Decays by
0.995^dayswhen idle (~78% remaining after 50 days of non-use)
- Resets to 1.0 whenever the file is updated
- Halves roughly every 21 days (
e^(-days/30))
Context trees created before 3.7.1 may carry these signals in markdown frontmatter. They continue to parse — stale fields are ignored on read, so no migration is needed.
Maturity Lifecycle
Knowledge files progress through three maturity tiers based on their importance score. Promotion and demotion thresholds are offset (hysteresis) to prevent rapid oscillation when a score hovers near a boundary.
Hysteresis means a file must drop significantly below its promotion threshold before being demoted — a
core file promoted at importance 85 won’t demote until it falls below 60.
draft files whose decayed importance falls below 35 become eligible for archiving — replaced by a searchable stub and a lossless full archive (see Archive System above).
Relations
Relations create explicit connections between topics using path notation in the frontmatterrelated field:
- Enable graph-like navigation between related knowledge
- Not based on similarity scores — these are explicit, intentional links
- Help find comprehensive context by following connections
- Prevent knowledge silos
Why This Matters
Human-readable and git-friendly:- Browse the context tree in your file explorer
- Edit markdown files with any text editor
- Track changes with git
- Review in pull requests
- Knowledge is categorized by domain and topic
- Self-documenting via auto-generated
context.mdat every level _index.mdsummaries give instant high-level overviews without reading individual files- Clear structure vs flat document storage
- Frequently used knowledge ranks higher in search
- Stale knowledge naturally fades without manual cleanup
- Core knowledge gets priority when results are tight
- Low-importance drafts are archived automatically, keeping the active tree lean
- ByteRover follows connections between topics
- More reliable than similarity-based search
- Intentional knowledge graph vs automatic clustering