F-06 planned Backlog · no target version
#
Ingest: Structure-Guided Document Chunking
Turns external documents (PDF, HTML, DOCX, Markdown) into indexed, searchable notes — preserving structural boundaries instead of splitting arbitrarily.
A skeleton tree parses the document hierarchy; each logical section becomes one atomic note, so a clause is never split across two chunks.
Table extraction converts tabular rows into indexable sentences (RowToSentence) so column relationships survive retrieval.
A noise filter discards non-informative nodes (table of contents, executive summaries, glossaries) that degrade retrieval quality.
Ingestion runs as a background Job::Ingest with progress tracking and automatic retry via the job queue.
For: Teams that need to import technical documentation, research papers, or meeting transcripts into the vault without losing the structural context that makes answers accurate.
Stable Wikilinks: Persistent Cross-Note Graph
Makes wikilink references between notes durable — links survive renames and deletions by anchoring to a stable ULID identifier rather than a file path.
A redirect_table maps every past title or path to the canonical ULID anchor, so [[old-title]] resolves correctly after the note is renamed.
Backlinks are indexed at write time, exposing links_in/links_out on every search result for graph-neighborhood traversal.
vault_search_multi merges results from multiple queries using Reciprocal Rank Fusion (RRF), so wikilink clusters surface naturally alongside keyword matches.
For: Knowledge engineers and developers who build interconnected notes and need cross-references to remain valid as the vault evolves over time.
Note History: Copy-on-Write Version Trail
Records a complete version history for every note write, so any previous state of a note can be retrieved or diffed without external tooling.
On each vault_write, the previous version is stored in a .history/<ulid>/ directory before the note is updated (Copy-on-Write semantics).
Dedicated history/* endpoints let callers inspect or restore any prior version by timestamp or sequence number.
Lifecycle configuration caps storage at max_versions=50 per note, pruning the oldest revisions automatically.
For: Developers and teams who need an audit trail of how knowledge evolved — including distillation drift detection and rollback of accidental overwrites.
Optimistic Locking: Safe Concurrent Writes
Prevents silent data loss when two processes write the same note concurrently, using a content-hash check instead of pessimistic locks.
vault_write accepts an optional write_if_match parameter containing the SHA-256 hash of the note version the caller last read.
If the stored note has changed since that read, the server returns 409 Conflict with a WriteConflict descriptor — the caller decides how to merge.
Writes without a hash succeed unconditionally, preserving backward compatibility for append-only workflows.
For: Developers building multi-agent pipelines or concurrent writer workflows where two agents may update the same note within the same time window.
Provenance Trust Score: Verifiable Note Lineage
Attaches a computed trust score to every note, derived from its origin and distillation history, so retrieved content carries verifiable lineage.
Trust is calculated from four sources: the writing agent, the distillation chain, the number of corroborating notes, and the confidence score at ingestion.
Distilled notes inherit a weighted mean of their source trust scores multiplied by the distillation confidence.
The trust field integrates with temporal decay (F-17): notes from less-trusted provenance decay faster in search ranking.
For: Teams running multi-agent pipelines who need to distinguish high-confidence knowledge from speculative or low-provenance notes before acting on retrieved content.
Temporal Decay: Recency-Weighted Search Ranking
Makes search results reflect how fresh and still-valid each note is — older or expired content scores lower without being deleted.
Each note carries a validity state (valid, temporal, or expired) and a document kind (static, versioned, or event), which together determine its decay profile.
A recency score computed relative to the current date is blended with the semantic score using a configurable temporal weight (default 0.40).
Event notes use a raw cosine relevance gate before decay is applied, preventing stale event records from surfacing on unrelated queries.
For: Agents and search clients that need results biased toward current knowledge — particularly useful for decision logs, meeting notes, and time-sensitive technical documentation.
Event-Log Vault: LLM Cost Attribution
Records every LLM call made by the vault with model, token count, estimated cost, latency, and the feature that triggered it — giving full budget visibility per feature.
A QaEvent struct is captured by the gateway intercept layer at each LLM completion: model identifier, prompt/completion token counts, cost estimate, latency, and a feature_id tag.
Events are stored in an append-only event_log table, queryable via the jobs introspection API for per-feature cost breakdowns.
The event log feeds the distillation learn job (F-22), which uses token patterns to identify cost-optimization candidates over time.
For: Operators who need to understand which vault features drive LLM spend, and developers building cost-attribution dashboards or budget-alert workflows on top of the vault.
Write Coherence Check: Title Category, Declared Section and Tags
Flags notes whose title claims one category while their declared section and tags say another, so an incoherent note is reported rather than silently stored.
On every vault write, a deterministic check compares the category announced by the title against the declared section hint and the tags, using a fixed table of 13 rules — bounded cardinality, so metric labels cannot explode.
The check is warn-only in the strictest sense: it adds no error path and cannot fail a write. An incoherence is recorded, never opposed.
A divergence is recorded three ways: a structured warning, a counter labelled by the rule that fired, and a dedicated audit entry — so it can be counted in aggregate or traced note by note.
For: Operators running persistent agents who need incoherent writes reported without ever risking a rejected write, and anyone auditing how consistently a vault is categorised.
Operator-Visible Write Warnings
Makes a write coherence warning reviewable by an operator without reading logs or querying an aggregate counter.
Each inconsistency is surfaced three ways: a structured log line, a counter, and an audit entry. The counter is read by scraping `GET /metrics` (aggregate, per rule); the audit entry is read from the daily audit file (one line per write). None of them is a stream an operator can watch as writes happen.
A job event stream already exists and carries job lifecycle events; the open question is whether it is the right transport, since a write warning belongs to no job and has no terminal state to close on.
Settled: the job event stream is not the transport — it is keyed by a job and closes at its terminal state, while a write warning belongs to no job and has no end. The check never holds a write, so no review-before-effect window exists; the two channels above are the way to read it.
For: Operators who want to notice an incoherent write as it happens rather than during a later audit.
VaultScope: Multi-Vault and Multi-Agent Addressing
Introduces a single addressing type that targets any locus across multiple vaults and agents with a single, unambiguous address — usable from any background job without per-job workarounds.
VaultScope encodes the vault identifier, the agent identifier, and the locus path as a single composable value, eliminating ambiguity when multiple vaults share a worker.
Every background job (distillation, purge, audit, migration, and others) carries a VaultScope, making cross-vault operations a first-class primitive rather than a per-job workaround.
All existing jobs are migrated to use VaultScope in a single coordinated change — no incremental per-job migration is needed.
For: Developers building multi-agent systems where several agents share or exchange knowledge across isolated vaults, and need deterministic addressing for background jobs.
Vault Lifecycle Management: State Machine, Retention and History Pruning
Adds an explicit note lifecycle state machine (Draft → PendingReview → Live → Deprecated → Garbage) and declarative retention rules — keeping the vault compact and high-quality automatically.
Each note carries a lifecycle_state field; transitions are explicit API calls with optional guard conditions so no note skips a required validation step. Draft notes are excluded from search by default; Deprecated notes are downweighted.
Operators define [[vault.lifecycle]] rules in TOML: conditions such as age, decay score, or locus pattern trigger a Job::Purge(Lifecycle). The purge job runs after distillation so no note is deleted before its value has been extracted.
Configurable history pruning caps per-note version history with max_versions and a TTL, preventing unbounded growth of the .history/ directories.
For: Operators who want the vault to self-regulate quality over time, and teams building multi-agent pipelines that need a formal quality gate between note production and retrieval.
Semantic Forget: Intentional Scoped Deletion
Lets operators explicitly remove a topic or locus from the vault — with a mandatory dry-run preview, double confirmation, and progressive decay instead of immediate deletion.
vault_forget(scope, dry_run: true) returns the full list of affected notes and any derived skills before any state change — the operator reviews and confirms explicitly.
On confirmed deletion, notes are marked forgotten=true and decay accelerates over a configurable window, removing them from search results progressively rather than immediately.
Cascade behavior is configurable: forgetting a knowledge/ topic can optionally propagate to linked skills/ and peers/ entries derived from it, with each cascade step listed in the dry-run preview.
For: Teams or individuals removing a project, topic, or person from the vault intentionally — with full visibility into what will be affected before committing, and a decay window to undo.
Temporal Index Foundation: Chronological Memory Queries
Lays the foundation for time-aware vault queries — a chronological index from note frontmatter lets agents ask what happened before, after, or around a date without a calendar or graph database.
A TemporalIndex is derived at write time from frontmatter fields (occurred_at, valid_from, event-date, created) — no LLM extraction, no separate store. This release ships the index and the vault_timeline API surface; higher-level temporal reasoning ships in v0.5.0.
The vault_timeline tool exposes before/after/around/upcoming queries; the index is fully reconstructible via a ReIndex job if frontmatter changes.
Job::Validate cross-checks temporal contradictions between notes (e.g., two notes asserting conflicting event orders) as part of the memory validation pipeline.
For: Agents and developers who need to reconstruct decision timelines, detect sequencing contradictions, or surface upcoming-deadline notes — without adding a calendar or graph infrastructure.
Distill: Scheduled Knowledge Compression
Automatically compresses accumulated raw notes into compact, reusable knowledge — running as scheduled background jobs while the vault is idle.
Four distillation modes run as Job::Distill: Semantic (synthesizes topic clusters into a single knowledge note), Learn (requires enough recorded LLM interactions (QaEvents) to extract meaningful cost and quality patterns), Peer (requires ≥5 sessions, builds a user behavior profile), and Rationale (preserves the reasoning chain behind decisions).
Distilled notes inherit a trust score computed from their source notes, and a Note History fingerprint is stored so drift from the validated version can be detected later.
DistillSource supports multi-vault targeting via VaultScope, allowing a distillation job to draw from notes across isolated vaults.
For: Developers running long-lived agent sessions who want raw notes compressed into searchable knowledge automatically — and teams building shared knowledge stores that grow in quality over time.
Lessons Recall: Dedicated Endpoint, MCP Tool, and Hook
Surfaces distilled lessons-learned notes on demand via a dedicated recall endpoint, a native MCP tool, and an agent hook — making accumulated lessons actionable at decision time.
A dedicated GET /api/v1/lessons/recall endpoint queries the lessons-learned corpus with semantic search and returns ranked results with source attribution.
A vault_lessons_recall MCP tool exposes the same surface directly to MCP clients, with optional role and tag filters so agents retrieve only domain-relevant lessons.
A pre-action hook fires automatically when the agent is about to start a new task, injecting the top-3 matching lessons into the context before the first response.
For: Developers and agents who want past mistakes and validated patterns surfaced automatically before acting — not just stored somewhere and manually searched.
Multimodal Gateway: OpenAI Content-Array and Vision Routing
Extends the gateway to accept the OpenAI content-array message format and route vision requests to an appropriate model — enabling multimodal inputs without changing the vault API.
The gateway parses ChatMessage::User as either a plain string or a Vec<ContentPart> (text + image_url), matching the OpenAI chat completions schema, so existing text-only clients are unaffected.
A vision routing gate inspects the content array at request time: messages containing image parts are forwarded to a configured vision-capable endpoint; text-only messages follow the standard routing path.
Configuration exposes a vision_endpoint field in the gateway TOML; if unset, image-bearing requests return a 422 with an explicit error rather than silently stripping the image.
For: Developers building agents that process screenshots, diagrams, or documents alongside text, and operators who want multimodal inputs handled at the gateway layer without routing logic in each client.
Code-Map: Multi-Language Source Indexing with Reverse-Dependency Graph
Extends code search to multiple languages with a reverse-dependency graph — find every call site instantly without regex scanning.
Language-specific parsers extract definitions and call sites from source files; a unified code graph stores both forward dependencies (what a function calls) and reverse dependencies (what calls this function).
The reverse-dependency index powers questions like "every place this function is used" — no regex scanning required, instant query results on any codebase.
Symbol resolution is deterministic and language-aware: method names, free functions, imports, and exports are properly disambiguated without semantic analysis.
For: Teams maintaining polyglot codebases needing call chain understanding across multiple languages.
VaultScope Patterns: Wildcard and Role-Filtered Agent Fan-Out
Extends F-31's addressing from one target to many: a single scope pattern with wildcards and role filters reaches a set of agents in parallel, and merged results still respect agent boundaries.
Query scoping extends beyond single-agent addressing to reach multiple agents in parallel: scope definitions support wildcards and role filters so a distillation job can consolidate knowledge across all agents matching a pattern.
Audit and compaction jobs can target a vault region or agent role rather than hard-coded addresses, making deployments flexible without custom per-agent coordination.
Result merging respects agent boundaries so data stays isolated; a unified result set optionally labels which agent each note came from.
For: Operators managing multi-agent deployments with distributed knowledge consolidation and querying.
F-64 planned Backlog · no target version
#
Compliance Forget: Retention Classes with Tamper-Evident Audit Trail
Adds a compliance layer over F-44: a tamper-evident audit trail of every forget, declarative retention classes, and a graduated decay window after which the note can no longer be recovered.
Compliance mode appends a record of each forget to an append-only audit log, cryptographically hashed against the previous entry, so the trail of what was forgotten, and when, is tamper-evident.
Retention policies are declarative: notes tagged with a retention_class are automatically forgotten when their retention window expires, without manual review.
Graduated decay supports GDPR right-to-be-forgotten: rather than erasing on request, a configurable window keeps the note recoverable; once that window expires the note can no longer be recovered, and the forget stays in the audit log.
For: Teams handling regulated data requiring audit-trail deletion compliance.
Bounded Chronological Queries: Time-Window Vault Search
Restricts vault search to a time window, so an agent can ask what was known before or after a given date instead of searching the whole history.
Search accepts an optional lower and upper time bound; either may be given alone, and an inverted range is rejected at the boundary rather than silently returning nothing.
The filter applies to both retrieval paths — lexical and semantic — so a bounded query cannot leak results through the path that skipped the filter.
Each result carries its temporal anchor, letting the caller order and reason about hits without a second lookup. Notes with no temporal entry are excluded when a bound is set, rather than assumed to match.
For: Agents and analysts reconstructing what was known at a point in time, and anyone narrowing a search to a specific period.
F-196 planned Backlog · no target version
#
Temporal Graph: Causal Chains, Concurrent Clusters and Contradictions
Models the relationships between events rather than their timestamps alone — which event caused which, which happened together, and which pairs contradict each other.
A temporal graph records relationships between events — not just individual timestamps, but causal chains (A caused B) and concurrent clusters (A, B, C happened at the same time).
Contradiction detection flags notes whose claimed ordering disagrees with their timestamps — event A claims to follow B, while the recorded times say B came later — and surfaces them to the validation pipeline.
Open design question, deliberately unresolved: whether a causal edge is declared by the writer or inferred from timing and links. A declared edge is data; an inferred one is a hypothesis, and mixing them would make the graph mean nothing in particular.
For: Researchers and analysts reconstructing event timelines and auditing them for internal contradictions.
F-197 planned Backlog · no target version
#
Historical Trends: How a Decision Evolved and What Triggered Each Change
Turns a point-in-time lookup into a trajectory: not only what the decision was on a given date, but how it changed and what drove each change.
A trend query returns the ordered series of states a note went through, rather than only its latest revision.
Each transition can be attributed to what triggered it — this part depends on the temporal graph, and is the only one of the three that does.
Scope still to be established: whether a trend is computed over a note body, its typed roles, or an extracted value. The vault already keeps note history, so the open question is what is missing between that history and a trend query — not whether to build one from scratch.
For: Analysts auditing how a decision or a value drifted over time, and agents that must explain a change rather than only report the current state.
LanceDB Vector Backend: Scalable Embedding Store
Replaces the default SQLite vector store with LanceDB for workloads where Approximate Nearest Neighbor (ANN) search on large embedding sets becomes a bottleneck.
The gradatum-db-lancedb crate implements the VectorStore trait backed by LanceDB, an embedded columnar vector database.
Switching is opt-in via configuration — IndexStore (full-text) stays on SQLite; only the vector path moves to LanceDB, keeping the deployment simple.
A Parquet-backed DocStore variant (planned for a later phase) will extend LanceDB to cover document storage as well for very large vaults.
For: Developers with vaults exceeding tens of thousands of notes who find SQLite ANN performance insufficient, and contributors who want to benchmark retrieval quality across storage backends.
gradatum-studio: Vault Management Interface
A local web interface for reading, searching, reviewing, and monitoring the vault — without exposing any API key or modifying the vault write path.
Five surfaces ship in the MVP: a dashboard (live vault metrics and recent activity), a note browser with inline markdown rendering, a search panel with score and section filters, a review queue (notes pending lifecycle validation), and a jobs monitor showing background task status.
Authentication is handled via a single API key injected at startup; no OAuth or user database is required for the single-user deployment.
A WHY scores panel surfaces the curator confidence and section classification for each note — making the reasoning behind search ranking visible and auditable.
The interface is read-only for vault content by design; writes still go through the standard API so the vault write path remains the sole source of truth.
For: Developers and operators who want to inspect and monitor their vault through a browser rather than raw API calls, without adding infrastructure or weakening data sovereignty.
gradatum-mcp: Native Model Context Protocol Server
Exposes the full vault API as a native MCP (Model Context Protocol) server — usable from any MCP-compatible client without an intermediary stub.
The gradatum-mcp crate publishes vault tools (vault_write, vault_search, vault_forget, vault_timeline, and others) as MCP capabilities with full JSON Schema definitions.
Authentication is handled MCP-side, decoupled from the HTTP API auth layer, so the MCP surface has its own access control.
The stdio transport (for local clients) and the Streamable HTTP transport (F-56, for remote clients) are both supported from the same crate.
For: Developers using MCP-compatible LLM clients (Claude Desktop, Cursor, custom agents) who want direct vault access without installing a local proxy stub.
Streamable HTTP Transport: Load-Balancer-Friendly MCP
Implements the MCP 2025-11-25 Streamable HTTP transport — a single /mcp endpoint that works with load balancers, serverless runtimes, and mobile clients.
A single POST+GET /mcp endpoint handles all MCP traffic; responses are either plain JSON or upgrade to Server-Sent Events (SSE) per-request, without maintaining a persistent connection.
This replaces the deprecated HTTP+SSE transport (spec 2024-11-05), which required a persistent SSE connection incompatible with most load balancers.
The local stdio transport is preserved for desktop clients; optional backward-compatible SSE mode allows a smooth migration for existing integrations.
For: Operators deploying gradatum behind a reverse proxy or in a containerized environment, and mobile MCP clients (Claude for iOS/Android) that require a stateless HTTP transport.
Memory Validation: Self-Healing Before Storage
Intercepts distilled notes before they enter long-term memory, corrects detectable errors automatically, and discards notes that cannot be repaired.
A background validation job computes a composite quality score; notes above a configurable threshold are accepted, notes with specific error patterns are routed to a repair strategy.
Three repair strategies: contradiction patch (corrects numeric contradictions against source notes), entity scrub (removes hallucinated entity claims), and grounding rewrite (reconstructs under-anchored text from source material). Internally: ContradictionPatch, EntityScrub, GroundingRewrite.
Repaired notes are stored with an audit flag (HEALED_ACCEPT) and a change log; notes that cannot be repaired are discarded cleanly — never silently stored.
For: Teams where distillation quality is critical — RAG pipelines, shared knowledge bases, long-running agents — who cannot afford hallucinated or contradictory notes accumulating in the vault.
Multi-Tenant Isolation: Enforced Scopes and Vault Boundaries
Enforces tenant-level isolation at the storage layer — scoped vault resolution and write-path guards that fail closed, not just decorative permission checks.
Write paths are gated by an explicit scope check, not a label that looks like access control without enforcing it.
A dedicated, fail-closed guard resolves the effective read vault, tenant, and write vault for every request.
The multi-tenant flag runs active in production, backed by a fuzzed no-leak-between-vaults test as a continuous integration guard.
For: Operators running gradatum for more than one tenant who need vault boundaries enforced at the storage layer rather than assumed by convention.
F-57 planned Backlog · no target version
#
OAuth MCP: Remote Access for Mobile and ChatGPT
Enables gradatum to be reached from mobile MCP clients and ChatGPT without weakening sovereignty — using a self-hosted OAuth 2.1 authorization server.
Gradatum acts as an OAuth 2.1 resource server: it validates tokens and publishes Protected Resource Metadata (RFC 9728) but delegates token issuance to a self-hosted identity provider using OIDC (OpenID Connect) — such as Kanidm.
The IdentityProvider trait decouples the identity provider from gradatum-auth (D-14), so the IdP is replaceable without modifying the authorization layer.
PKCE (Proof Key for Code Exchange) S256, Dynamic Client Registration, and explicit consent flows are required — bearer-static tokens are not accepted, matching what Claude for mobile and ChatGPT require.
For: Operators who want to reach their vault from a mobile MCP client or ChatGPT without a VPN, and who want token rotation, explicit consent, and centralized revocation instead of static bearer tokens.
Vault Audit and Deduplication: Scheduled Quality Pass
Runs a scheduled audit pass over the vault to detect duplicate notes, score the vault's overall knowledge quality, and produce a conflict report.
Job::Audit(AuditMode) supports three modes: Detect (identifies duplicates and near-duplicates by semantic similarity), Deduplicate (merges or flags them), and Both (full pass).
The audit produces a per-locus vault score reflecting coverage, freshness, and uniqueness — visible in the jobs introspection API.
Conflict reports list notes with contradictory claims so operators or distillation jobs can resolve them explicitly rather than leaving ambiguity in the search index.
Runs on a schedule in production today, regenerating a fresh audit report against the live vault.
For: Operators maintaining long-lived vaults where notes accumulate from multiple agents or ingestion pipelines, and who need a systematic quality baseline rather than ad-hoc manual review.
Gateway: Local LLM Proxy for Chat, Embeddings, and Reranking
Provides a single local HTTP gateway in front of the LLM and embedding backends, so gradatum components talk to one stable endpoint instead of many provider-specific ones.
The gradatum-gateway crate exposes OpenAI-compatible routes — chat completions, embeddings, reranking, and model listing — over a local HTTP port.
Requests are routed to the configured local backends, decoupling gradatum from any specific inference server and keeping all traffic on the host.
For: Operators running gradatum fully locally who want a single, stable inference endpoint that other components and tools can target without per-backend wiring.
Dead Letter Queue and Job Resilience
Captures jobs that exhaust their retries into a Dead Letter Queue instead of losing them, so failed background work is auditable and replayable.
Each job carries a retry budget; once exhausted, it is moved to a Dead Letter Queue (DLQ) rather than silently dropped.
Multiple workers coordinate through the shared queue with at-most-once execution per job, and a graceful 30-second drain on shutdown lets in-flight jobs finish before the process exits.
DLQ entries retain their failure context so operators can inspect the cause and requeue once the underlying issue is fixed.
For: Operators running gradatum with background ingestion or distillation jobs who need guarantees that transient failures never result in silently lost work.
Jobs Introspection API: Observable Background Work
Exposes the async job queue over HTTP so callers can submit, track, and stream the progress of background work in real time.
Five HTTP endpoints cover the job lifecycle — submit, list, fetch a single job, stream progress, and inspect queue state.
Server-Sent Events (SSE) push live progress updates to clients without polling, and an Idempotency-Key header makes job submission safe to retry.
Queue depth and per-status counters are exported in Prometheus format for dashboards and alerting.
For: Integrators who drive ingestion or maintenance jobs programmatically and need to observe their progress and outcome rather than firing blind.
Cross-Encoder Reranking for Precise Retrieval
Re-scores candidate search results with a cross-encoder model so the most relevant notes rise to the top, beyond first-pass keyword and vector ranking.
After the initial retrieval, the gradatum-gateway /v1/rerank endpoint scores each query-document pair with a BGE-reranker-v2-m3 cross-encoder running locally on ONNX Runtime.
The reranked order replaces the fused first-pass ranking, improving precision on the top results returned to the caller.
For: Developers whose retrieval quality depends on surfacing the single best note for a query, where first-pass ranking alone is not precise enough.
Secrets Dependency Injection: Provider-Backed Credentials
Decouples gradatum from any single secret source through a SecretsProvider trait, so credentials can come from the environment, a file, or a future vault backend without code changes.
A SecretsProvider trait abstracts secret resolution, with EnvSecretsProvider and FileSecretsProvider implementations shipped by default.
Resolved secrets are wrapped in a SecretBytes type that zeroizes on drop and masks its Debug output, so credentials never leak into logs or memory dumps.
For: Operators with strict credential-handling requirements who need secret sourcing to be configurable and auditable rather than hardcoded.
Curator Confidence Ladder: Graded Note Admission
Routes incoming notes through a confidence ladder so high-confidence content is admitted directly while uncertain content is held for review instead of polluting the index.
The curator classifies each note and assigns a confidence band; low-confidence notes are routed to a PendingReview state rather than going live immediately.
A dedicated curation kind (c_kind) column, added in migration 0008, records the classification decision so admission outcomes are queryable and auditable.
For: Vault maintainers ingesting content from heterogeneous or noisy sources who want automatic triage to protect overall index quality.
Reference-Language Memory: Pass-by-Reference Context
Lets agents pass note references instead of full note bodies into the LLM context, keeping prompts compact while preserving the ability to resolve content on demand.
Context assembly passes stable note references rather than inlined bodies, and the referenced content is resolved only when the model actually needs it.
This reduces token pressure on long agent sessions while keeping every reference traceable back to its canonical note.
For: Integrators building long-running agents that hit context-window limits and need to keep prompts lean without losing access to source notes.
Curator Threshold Tuning — continuation of F-42
Completes the curator confidence ladder by finalizing the admission and review thresholds left open after the initial F-42 delivery.
Builds on the released curator ladder (F-42) to settle the remaining confidence cut-offs that govern direct admission versus held-for-review routing.
The candidate threshold values are still under architectural review, so this continuation tracks the tuning work separately from the shipped baseline.
For: Vault maintainers who need the curator admission policy tuned to their own quality and noise profile rather than relying on the initial defaults.
Lessons Recall Pre-Action Hook — suite F-60
Completes lessons recall by adding an automatic pre-action hook that fires before the agent starts a new task, injecting relevant prior lessons into the context.
Builds on the released F-60 endpoint and MCP tool to add the remaining pre-action hook surface.
When the agent is about to start a new task, the hook automatically queries the lessons-learned corpus with semantic search, retrieves the top-3 matching lessons, and injects them into Zone A of the context before the first response.
Configuration allows operators to tune the hook sensitivity, lesson count, and filters (by domain, role, or tag) so lessons are contextually relevant and not overwhelming.
For: Developers building agents where automatic access to prior lessons before acting is critical — reducing repeated mistakes and accelerating decision quality.
F-69 planned Backlog · no target version
#
Distill Learn/Peer/Rationale Modes — suite F-22
Completes the distillation pipeline by shipping the Learn, Peer, and Rationale modes deferred from the F-22 Semantic-only release.
Builds on the released F-22 Semantic distillation mode to add three additional modes: Learn (extracts cost and quality patterns from QaEvents), Peer (builds user behavior profiles from session interactions), and Rationale (preserves the reasoning chain behind distilled decisions).
Each mode runs as a background Job::Distill variant with its own criteria, frequency, and output format.
All modes integrate with F-17 (trust scoring) and F-55 (temporal index) so distilled notes inherit verifiable lineage and can be queried by time.
For: Operators running multi-session vaults where automatic extraction of learning patterns and behavior profiles becomes valuable as the vault matures.
Code-Map Qualified Method-Call Resolution — suite F-62
Completes the code index by adding qualified method-call resolution, so "Type::method()" is correctly resolved to the specific implementation without ambiguity.
Builds on the released F-62 code-map reverse-dependency graph to handle the partial case: self.method() calls and qualified calls like Type::method() that require type inference.
Language-specific type resolution is added per language (Rust trait resolution, TypeScript class hierarchies, Python method resolution order).
Results include the resolved target implementation, qualified with its module and defining type, so call chains are fully traceable.
For: Code maintainers and refactoring tools where knowing the exact implementation that a method call targets is critical to safety and correctness.
Queue DAG: Job Dependency Chains
Lets background jobs depend on each other — a job can declare that it waits for one or more prior jobs, and the queue ensures the dependency chain is respected.
Each job carries an optional await_jobs list of ULID references to prior jobs that must complete before this one can run.
QueueStore::find_awaiting(job_id) queries for predecessors using LIKE-based locus prefix matching to avoid collision; QueueStore::set_pending(job_id) idempotently promotes a job from Waiting to Pending once all its dependencies are satisfied.
When a job completes, the queue runs a cascade promotion sweep to identify newly unblocked dependents; if promotion fails, a recovery sweep runs on the next worker cycle.
For: Operators running complex background pipelines where one job must wait for another to finish — ingestion triggering distillation, or distillation triggering validation.
Agent Action Tracing
Records every agent action — what ran, when, what it touched, and why — in an append-only log queryable for 90 days without external storage.
POST /api/v1/session-log/trace accepts agent action events (fire-and-forget, no update or delete) with fields: agent_id (stable server identifier from JWT sub), session_id, tenant_id, ts_ms (millisecond timestamp), action_type (enum), target (resource affected), intent (what the agent was trying to do), outcome (success/failure), marker (link to decision), and ref (pointer to related note).
Storage is append-only; retention is configurable via [session_trace] retention_days (default 90).
Queries via vault_timeline can reconstruct what an agent did in a session without storing personally identifiable data.
For: Operators who need an audit trail of agent activity without relying on external logging infrastructure, and teams building compliance or security workflows.
Proof-of-Absence Search Signal
Adds a signal to search results that distinguishes "the topic is truly absent from the vault" from "the topic is present but not ranked high enough".
vault_search now accepts an optional include_corpus_count parameter (opt-in, zero overhead by default).
When enabled, results include corpus_count: the total number of notes in the vault that matched the query at any score level (even below the ranking threshold).
A corpus_count of 0 proves the topic is absent; a corpus_count > len(results) proves the topic exists but was filtered or re-ranked below the top-K.
For: Developers building workflows where it is critical to know whether information is truly missing versus just not highly ranked.
Native TLS Termination
Adds native TLS 1.2+/1.3 support to the gradatum server, eliminating the need for a reverse proxy just to enable encryption.
The gradatum-server binary accepts [tls] configuration: cert_path (PKCS#8 certificate), key_path (private key), and optional min_tls_version (default 1.2).
TLS termination happens at the socket layer; the HTTP API and MCP surface both run over the same encrypted connection.
No external proxy, no sidecar — encryption is built in.
For: Operators deploying gradatum on private networks who need encryption without adding a reverse proxy or external gateway.
F-82 planned Backlog · no target version
#
Arbor HTR: Research Spike
An exploratory research track evaluating Arbor for handwritten-text recognition (HTR) as a possible future ingest path — framed as a spike, not a commitment.
A time-boxed research spike, not a planned deliverable: evaluates the Arbor approach to handwritten / document-image text recognition.
Probes the feasibility of turning handwritten or structured documents into vault-ingestible notes.
The outcome decides whether this graduates into a committed feature or is shelved.
For: Forward-looking users curious about gradatum ingesting handwritten or document-image sources; explicitly exploratory.
Router Dispatch: SmartRouter Capacity
Routes incoming requests to the appropriate local backend based on task type and available inference capacity.
SmartRouter evaluates the request type and current backend load, then forwards the request to the best-available local model or API endpoint.
Routing decisions are transparent to callers: the same endpoint handles all request types, and selection logic is configurable without application changes.
For: Backend operators running multiple local backends who need transparent routing without client-side dispatch logic.
Engine HTTP Supervisor: llama-server Lifecycle Manager
Manages the llama-server process lifecycle, exposing stable model inference over a local HTTP endpoint.
A supervisor process starts, monitors, and restarts llama-server on failure, presenting a stable HTTP endpoint regardless of engine restarts.
Health probes detect stalls and trigger a clean restart without dropping the listening socket from the caller's perspective.
For: Local deployments where stable inference availability across process restarts and crashes is required.
Job Enum and JobRecord: Five-Block Apalis Worker
Defines the structured job taxonomy and typed execution blocks for the Apalis background worker.
Five typed job blocks (Ingest, Distill, Validate, Embed, Expire) map to Apalis job workers, each with its own error handling and retry policy.
JobRecord persists job identity, status, and failure context so the queue is introspectable without external logging.
For: Backend operators who need to inspect, extend, or audit the background job processing pipeline.
F-83 planned Backlog · no target version
#
Doc-Map: Reference Documentation Index
Maintains a queryable index of reference documentation to reduce token cost and prevent stale content from degrading recall.
A scheduled job walks configured documentation sources, extracts structural headings, and persists a lightweight doc-map note per source.
Queries against the map surface the canonical section rather than re-ingesting entire documents, keeping token overhead low.
For: Teams importing large reference materials who want fast targeted retrieval without redundant full-text overhead.
On-Demand Delete: Reversible Archival with Retention GC
Removes a note from the live vault by moving it to an archive tree instead of erasing it — recoverable until a configurable retention deadline, after which it is physically destroyed.
A delete moves the note's Markdown file and its .history/ directory under .archive/ in mirror layout and records a row in the registry-driven archive_index table; a durable JSONL audit tombstone is written before the cascade.
A boot-and-interval GC selects archives past their 60-day (configurable) retention deadline from the registry — never a filesystem scan — and destroys them physically; destroyed and restored rows survive as history traces.
Restoring re-indexes the note as pending-review so it re-enters the curator pipeline rather than returning straight to live, with a 409 on ULID collision.
The gradatum-admin CLI drives delete, archive listing, purge, and restore (single ULID or a from/to range) dry-run by default over a loopback admin namespace; MCP exposes vault_archives_list read-only, so agents can see archives but never mutate them.
For: Operators who need to take notes out of the live vault without an irreversible step, and who want a review window plus an audit trail before anything is physically destroyed.
F-101 planned Backlog · no target version
#
Memory Self-Healing: LLM Drift Validation (F-43 child)
Extends the deterministic quality gate with an LLM-powered healing phase that rewrites low-quality summaries.
Notes tagged quality-low by the deterministic gate (F-43) are queued for a healing job that rewrites the summary against the source body using an LLM.
The healed note is re-scored; if the new score clears the threshold it is promoted to live status. Healing runs asynchronously and is fully auditable.
For: Vaults where automated ingestion produces many low-quality summaries and manual curation is not practical at scale.
Arrow Interchange Layer: Columnar Boundary for External Analytics
Adds an Apache Arrow export layer on top of existing storage traits, so the corpus can be read by analytical tools without depending on the shape of any specific storage engine.
A columnar export layer sits above the existing storage traits — the storage engine itself is unchanged; only calls that already return batches convert their output to Arrow's in-memory format.
Decouples the interchange boundary from any single database implementation, keeping the door open to a future storage engine change without touching business logic.
For: Developers and analysts who want to query the memory corpus with standard analytical tooling — bulk reads, not the point lookups the day-to-day API is built for.
Parquet Corpus Export: Analytics Without Touching the Live Database
Exports the memory corpus as Parquet files on object storage, so an external query engine or notebook can analyze it without ever touching the production database.
Converts the corpus through the Arrow interchange layer into Parquet, the columnar file format standard for analytical tooling, written to the existing object-storage backend.
Runs on demand or on a schedule; an explicit exclusion rule decides what never leaves the vault before any file is written, since an export widens the read surface by design.
For: Operators and analysts who want to study how the memory corpus evolves over time — which sections stay active, which go stale — without duplicating or exposing the live database.
Versions as Cards: The Project Map Drops Its Release Axis
Turns each version into a card of its own, so a work item states which version carries it instead of restating that version’s delivery status on every single card.
A version becomes a ROADMAP card holding the version number and whether that version is internal or public; one BACKLOG card per project holds whatever is not yet scheduled. Every work card carries exactly one link to one of them, and no longer carries a version or a release field of its own.
Delivery status is derived from that link and the target card’s status, which makes contradictory states unwritable rather than merely forbidden — a card can no longer announce itself as released while the version carrying it has not shipped. The public version a card ships under is frozen once, when that version ships, so a published changelog never rewrites itself afterwards.
This is a breaking change for existing project-map cards: the card kinds gain two values, and the validator stops requiring the version and release roles it enforces today. A staged migration keeps both forms readable until every consumer has moved.
For: Vault maintainers who track work in the project-map section and want the state of a release to be a fact they can query, rather than a pair of fields to keep in sync by hand on every card.
Remote Index Mode: Query the Index Database Over the Network
Lets the index database live on a remote server reached over its native network protocol, instead of only ever opening a local file.
A pure remote mode sends every index query over the network rather than opening a local database file — the local mode remains the unchanged default.
Vector-search acceleration is not available in remote mode since a standard remote database server does not load local extensions; the existing fallback path covers semantic search instead, at a cost that grows with corpus size.
For: Operators who want the index database to run on its own server — for centralization or easier operations — and who can accept that semantic search falls back to a slower path in that mode.
F-152 planned Backlog · no target version
#
Per-User Isolation Boundary: Distinct From Multi-Tenant Scoping
A planned isolation boundary between individual users sharing one tenant — distinct from the tenant-level scoping already enforced in production.
Tenant-level isolation is already live and enforced; this closes the remaining gap where multiple users inside the same tenant are not yet separated from each other.
Still at the scoping stage — what counts as a user relative to a tenant, and what isolation covers (read, write, search, proactive recall) are open questions to resolve before implementation.
For: Teams and households sharing a single gradatum deployment across several people, who need each person's private memory kept separate from the others, not just from other tenants.
Privacy Filter: On-Device Redaction of Personal Data
Redacts personal data from a note before it reaches the index — using an on-device recognition model, with no external API call or network dependency.
Runs before a note reaches the index, so redaction happens at write time rather than being bolted on afterward.
Uses an on-device recognition model covering common categories of personal data, with no data ever leaving the host.
For: Teams ingesting documents that may carry personal data — emails, transcripts, exported records — who need a compliance-friendly path with no third-party data processing.
Targeted Role Mutation: Patch a Card's Role Without Rewriting Its Body
Lets a client change one typed role (version, status, release, kind) on a project-map card and append a history line, without reading or resending the full body.
The current write surface only supports full-body replacement — a caller must hold and resend an entire note just to change one bracketed role, which on large cards means transferring kilobytes to alter a handful of characters.
A dedicated mutation changes a single typed role and appends a history entry server-side, atomically, under the same optimistic lock, and refuses any attempt to touch the card's identity.
Mutating the version role also updates the title's version suffix, so the title never drifts out of sync with the role it is supposed to reflect.
For: Vault maintainers and internal tooling that adjust a card's roadmap status regularly and want to avoid full-body rewrites on records that can never be deleted.
Legacy Queue Removal: Retiring jobs_v2 and Its Deleted-Note Remnants
Removes a legacy queue table that kept reappearing on every restart and retained the content of already-deleted notes outside the vault's normal lifecycle.
The legacy queue's schema is dropped from the startup migration path entirely by a dedicated idempotent migration, leaving the unrelated leader-election table in the same schema untouched.
All readers of the legacy queue module are removed from the server, worker, and admin CLI, with the affected public contracts documented in the changelog.
Verified on the deployed fleet after a full restart: the table no longer exists, no migration checksum drifts across binaries, and leader election continues to succeed.
For: Operators concerned about stale data retention — the removed table held content from deleted notes with no forensic value, including at least one note carrying infrastructure details.
F-181 planned Backlog · no target version
#
Curator Threshold Tuning: Acting on Instrumentation Already Shipped
Follows up on the curator's classification instrumentation by adjusting its admission thresholds once real verdict distributions are measured.
Builds on instrumentation already shipped that records curator verdicts — admit, reject, downgrade — broken down by section, making the classification path observable for the first time.
Thresholds are adjusted from that measured distribution rather than by guesswork, validated against a fixed query set compared before and after, since a recall regression is invisible at compile time.
For: Vault operators who want the curator's admission behavior tuned to their own corpus rather than left at defaults chosen before any real usage data existed.
Single-Query Card Projection: List Every Card of a Version at Once
Adds the version filter an earlier listing feature left out, and returns every axis of a card — id, status, type, release, version, title, dependency roles — in one call.
A single projection returns id, status, type, release, version, title, and dependency roles together, filterable on any of them including version — where today no single surface exposes all of them at once.
Resolving a card by its number becomes one call instead of walking the dependency graph node by node.
The result count is cross-checked against a direct index read, so a listing that silently omits entries is no longer indistinguishable from a complete one.
For: Anyone auditing what a given release milestone contains — previously only answerable by exporting everything and filtering by hand, or by reading the index directly.
Version Availability Check: Know If a Version Number Is Already Taken
Answers whether a given version number is already used by live cards, replacing a manual export-and-filter step with a real query.
Returns the list of cards already carrying a given version number along with their status, rather than a plain yes/no — because whether a number is 'free' depends on whether those cards belong to the release about to ship.
Consumed by the release gate in place of a hand-filtered export, closing a gap that previously let a version number get reused by mistake.
For: Release management tooling and operators cutting a new version, who today must export the whole registry and filter it by hand to confirm a version number is free.
Role Consistency Guard: Reject Incoherent Role Combinations at Write Time
Adds a write-time guard that refuses role combinations already known to be invalid, and rejects unknown roles instead of silently discarding them.
Enforces a coherence matrix at every write path — for example, a card cannot carry release=roadmap while also carrying a committed target version, a combination measured to affect over half of one registry milestone before this guard existed.
An unknown role name or an out-of-vocabulary value is refused rather than silently accepted as a generic, uncounted link, closing a gap where a misspelled role produced no error and no effect.
A role cited inside a code sample is explicitly not treated as a real role, so documentation about the role system itself remains writable.
For: Vault maintainers who write project-map cards directly and need bad data caught at write time instead of discovered later by a full manual audit.
Bounded Audit Report: Publish Capability Status Separately
Splits the unbounded capability-status block out of the operational audit report, so a consumer that only wants the status no longer loads the whole report.
The audit report grew roughly 76% after a capability-status block was added, and that block grows linearly with every capability the fleet exposes, while no existing read path can fetch a sub-section — only the whole report.
Publishing the status block as a separate note next to the anomaly report is estimated to cut the read cost by 75-85% for a consumer that only needs status, at the cost of having two notes to tell apart.
For: The periodic self-evaluation routine and any other consumer that reads the audit verdict on every pass and only needs the capability-status summary, not the full anomaly report.
Guaranteed Snapshot Capture: Vault-Backed Session Events
Moves session-event capture into a dedicated, retrievable vault section instead of a local buffer file that was never reliably converted into durable notes.
Captured events are vectorized at write time into a dedicated vault section, so they are retrievable by a later session's natural-language search even if no distillation pass has run yet — measured against a prior local-file buffer where only about 8-64% of captured lines were ever converted, depending on the day.
A capture-to-note pipeline treats capture as a filter, not an author: it distills mechanically, without judgment calls, while high-value notes continue to be written directly during the session.
A backlog gate fails the synthesis phase while unprocessed captures remain, proven in three states — backlog present, resolved, server down — never producing a false pass.
For: Anyone relying on cross-session memory continuity, where a decision or explanation established in one session previously risked never surviving past that session's transcript.
Canonical Title Derivation at Card Creation
Derives a project-map card's canonical title — category prefix, project name, version suffix — from its own role fields, instead of accepting any title passed in.
Card creation today accepts any title with no check or adjustment; measured across one registry milestone, only 17 of 32 live cards were fully conformant, and 11 titles registry-wide contradicted their own version role.
The title is derived from data the server already holds at creation — the destination section, the card's project role, and its version role — and reapplying the derivation to an already-conformant title changes nothing.
Because the version role changes more often than any other title element, the derivation also fires on role mutation, not only at creation, since that is the majority case.
For: Vault maintainers who rely on card titles for browsing, export, and lexical lookup, where an inconsistent title space degrades all three.
Distillation Consolidated Into a Single Dedicated Crate
Moves distillation logic scattered across the codebase into one dedicated crate, while keeping the existing job-queue vocabulary in the foundation crate to avoid inverting its dependency graph.
Only five source files actually defined distillation logic — the rest merely imported the job-queue vocabulary — so consolidation moved the logic while deliberately leaving the queue's data contracts, already persisted for thousands of jobs, untouched.
Exactly one symbol was removed from the foundation crate's public surface; the removal is named in the changelog with its migration path and recorded in the crate's breaking-change inventory, matched in both directions.
For: Contributors maintaining or extending the distillation pipeline, who previously had to know which of many files actually defined the logic versus merely importing shared vocabulary.
Public Migration Guide and Script: Upgrading From 2.0 to 2.1
Ships a public migration guide and script inventorying breaking changes in the 2.1 line, since a minor version is adopted automatically by any consumer pinned loosely.
The breaking-change inventory is derived from a public-surface comparison against the 2.0 baseline, not written from memory, with each entry linked to the card that introduced it.
The accompanying script automates the mechanical substitutions and explicitly lists, in its own header, the categories of change it does not detect, rather than silently skipping them.
The guide is linked from both the repository homepage and the changelog on the published repository, not only the local working tree.
For: Consumers of the gradatum crates who pin a loose version constraint and need to know, at upgrade time, exactly what changed and how to adapt.
Dedicated Internal-Card Axis, Independent of Card Type
Gives a registry card an explicit way to opt out of the public feature catalog, replacing a guarantee that used to be a side effect of its type field.
A dedicated exclusion axis marks a card as internal regardless of its type, read by the export in addition to today's filters rather than in place of them.
The default stays publishable — exclusion is a deliberate act on each card, not an omission, so a missing axis never silently hides a card that should be visible.
Cards that previously relied on their type to justify staying internal are reviewed individually and given either the new axis or an explicit publication decision.
For: Vault maintainers who need to keep certain internal registry cards out of the public feature catalog without repurposing an unrelated status field.
Provenance-Based Trust Scoring That Actually Varies
Derives a note's trust score from its section and document kind instead of a stored constant, so the ranking factor it feeds finally discriminates between notes.
Trust is derived at query time from a note's section (baseline value) and document kind (whether and how fast it decays), rather than stored and migrated — measured across the full corpus, every note previously carried the same trust value, making the factor a constant multiplier that could not reorder anything.
Four tiers were set from existing section documentation rather than by analogy: governance-grade sections carry the highest trust and are exempt from decay entirely, since an already-settled decision does not get less true with age.
The reference query set used to catch ranking regressions was recaptured after the change, since making trust vary necessarily reorders some results relative to a baseline that assumed a constant factor.
For: Anyone relying on search ranking quality, where a scoring factor that multiplies every result by the same amount looks like it works but silently contributes nothing to the ordering.
MCP Tooling Consolidation: Retiring the Duplicated Tool Catalog
Consolidates the native MCP tool surface — duplicated between the server and its published stdio proxy — into one dedicated crate, removing a permanently blocking CI parity gate.
A continuous-integration gate exists today solely to keep two copies of the MCP tool catalog in sync between the server (about 1,400 lines) and the published proxy (about 1,600 lines) — it detects drift on every integration without preventing the duplication that causes it.
Consolidation is preceded by an exhaustive measurement pass — genuine definitions versus imports, catalog data versus transport versus processing logic, and what already reaches a published crate's public surface — before any code moves.
Any break to the tool contract itself — a name, an input schema, a behavior — is invisible to Rust's own compatibility tooling and is inventoried by hand in a dedicated MCP migration guide.
For: MCP client integrators and contributors maintaining the native tool surface, who today must keep two hand-written catalogs of the same tools in sync.
Wire the FTS Integrity Guard Into Supervision
Wires the fts_integrity_check guard 2.1.1 ships into an actual caller, so silent FTS corruption is caught by monitoring instead of surfacing later as a user's search failing.
fts_integrity_check runs FTS5's ranked integrity form (INSERT INTO notes_fts(notes_fts, rank) VALUES('integrity-check', 1)), which compares postings against the content table — unlike a row-count comparison or an unranked integrity check, both of which stayed green on a base later found corrupted.
The guard exists today but has no caller outside its own test. This feature decides where its verdict surfaces — health endpoint, dedicated endpoint, or a periodic job — and what a red verdict triggers, deliberately not an automatic rebuild, since an automatic rebuild is what let the same class of corruption go undetected through three prior manual repairs.
The probe's cost on a production-sized index is measured before it is placed on any path called continuously.
For: Operators who want stale FTS postings caught by monitoring rather than by a user's search failing first.
Make the Release Gate Patch-Aware
Rewrites two release-gate tests that hard-code a MINOR-release assumption, so the SemVer deviations inventory can legitimately read empty on a patch release like 2.1.1.
Two tests assert against a populated deviations inventory — a minimum entry count, and one exact deviation triplet — instead of asserting the gate's behavior for a given release rank, so an empty inventory reads as a broken test fixture instead of the correct state for a patch release.
This feature rewrites both tests to assert behavior per release rank: under a MINOR release, an empty inventory means zero breaking changes are pre-authorized, and any measured break must then fail the gate rather than being silently waved through.
It also closes a latent false-PASS: the gate matches measured breaks against named authorizations, never the reverse, so a stale authorization whose symbol name later coincides with an unrelated future break would silently cover it — a risk that stays invisible because the gate keeps passing.
For: Maintainers of the release pipeline who need the deviations inventory to mean a reviewed allowance for a specific past break, not an artifact that can never return to zero.
Privacy Filter Rollout: Sidecar Mode, Masking, and Category Activation
Extends the on-device privacy filter with a sidecar deployment mode, an optional masking mode, and a measurement campaign that activates detection categories once validated.
A sidecar deployment mode runs the redaction filter as a separate process, an alternative to the default in-process path.
An optional masking mode replaces outright redaction with a reversible mask for cases where the original value must stay recoverable.
A measurement campaign validates detection accuracy per category before that category is turned on by default, instead of activating every category at once.
For: Operators who need the privacy filter tuned and measured against their own data before trusting every detection category by default.
F-316 planned Backlog · no target version
#
Reserved Naming Extended to Vault Names
Extends the reserved personal-data naming convention so it also applies to vault names, not just note titles and paths.
The existing reserved-name family that flags personal or classified content is extended to cover vault names themselves, not only note-level identifiers.
For: Operators who want personal-data naming conventions enforced consistently across every level of the vault, including the vault's own name.
F-320 planned Backlog · no target version
#
Configuration Drift Reporting Channel
Lets a running instance report a mismatch between its declared and actual configuration without requiring shell access to inspect it.
Each component compares its declared configuration against what it actually loaded at startup.
Any mismatch is reported through a queryable channel instead of only appearing in local logs.
Operators can check for configuration drift remotely, without opening a shell session on the host.
For: Operators managing multiple instances, who need to detect configuration drift without comparing files by hand on every host.