A decision library that is never reviewed becomes stale. Entries accumulate in INBOX without being decided,Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/decision-rain-library-project/llms.txt
Use this file to discover all available pages before exploring further.
next/* actions go unacted upon, and tags drift away from the canonical registry. Decision Rain Library Project recommends periodic maintenance to keep INBOX clear, validate pending entries, act on decided items, and prevent taxonomy drift in SYSTEM documents. Maintenance is not a special event — it is a short, recurring check that keeps the library usable.
Periodic Review Checklist
Run through each collection during your review. The goal is not to process everything at once, but to ensure nothing is silently forgotten.-
00_INBOX: Check for unprocessed items. For any entry with
status/pending-review, ask the assistant to research and propose if it has not already done so. Move or validate any entries that have an outstanding proposal waiting for your approval. -
10_REVIEW: Check for entries whose operator validation is overdue. These are items you found worth keeping visible but have not yet fully decided. Review the verdict and tags, make your decision, and move them to
20_LIBRARYor90_ARCHIVE— or deliberately leave them in10_REVIEWif you need more context. -
20_LIBRARY: Scan for entries whose
next/*tag implies an action you should take now. An entry taggednext/testornext/deployis a pending commitment, not just a record. Act on it, update the tag, or consciously defer it with a revisednext/*. - 90_ARCHIVE: Periodically confirm that archived entries are truly obsolete. This collection rarely requires attention, but an occasional scan ensures historical entries remain meaningful and that nothing was archived by mistake.
-
SYSTEM documents: Check for taxonomy drift — tag values being used across the library that are not present in the registry, or entries classified inconsistently with the golden examples in
/reference/examples. Drift is easier to correct early.
Batch Normalization
Batch normalization is the process of updating or standardizing a set of entries at once — for example, applying a new tag to a group of entries or migrating entries from a deprecated status value to a current one. It is a powerful but high-risk operation that should be rare, explicit, and fully traceable. Before any batch normalization work begins, the assistant must complete all of the following preparatory steps:- Read the current SYSTEM documents to confirm the target state.
- Define the exact target collections that will be touched.
- Define exactly which fields will change and which fields must be preserved.
- Produce a sample transformation showing a before-and-after for at least one representative entry.
- Assess rollback risk — what happens if the transformation needs to be undone.
Managing Taxonomy Drift
Taxonomy drift happens when the tag values in use across the library diverge from the values defined in the registry. This can occur gradually — a slightly different spelling here, a convenience tag invented there — and it quietly breaks the consistency that makes the library queryable and meaningful. Golden examples in/reference/examples are the primary guard against drift. Each golden example demonstrates a complete, correctly classified entry for a common item type. When the assistant is uncertain about how to classify an entry, it checks the golden examples before proposing tags.
If the assistant encounters a situation where no approved tag value fits:
- It reports the gap explicitly — describing what the entry needs and why no existing tag covers it.
- It proposes the smallest addition that would cover the gap — a single new value, not a new family.
- It waits for operator approval before using the proposed new value.
Extension and Maintenance Rules
The library template is designed to be extended carefully over time. Extensions that make the system clearer and more precise are welcome; extensions that add complexity without adding clarity are not. Good extensions:- Additional golden examples that cover new item types or edge cases
- Small tag additions that fill genuine gaps in the registry
- Clearer failure rules — more specific guidance on when the assistant must stop
- Improved note templates that make decisions easier to read and compare
- Migration notes when changing SYSTEM behavior
- Broad placeholder documentation with no concrete guidance
- Generic community files — contributing guides, issue templates, or code of conduct files that have no governance relevance
- Automation that bypasses operator validation for any field in the gate list
- Uncontrolled tag additions made without updating the registry
Privacy and Publication Boundary
Decision Rain Library Project is a public template. The repository contains the schema, rules, blank templates, synthetic examples, and placeholder SYSTEM document URLs. These are the reusable skeleton of the system. The live library — your actual Raindrop corpus — is private. It must remain separate from the public repository. When maintaining the template or contributing improvements, ensure that the repository never contains:- Private Raindrop exports or bookmark data
- Personal saved links with notes attached
- AI assistant conversation transcripts
- API keys, tokens, or credentials of any kind
- Operator-specific taxonomy that exposes private workflows or intent
The repository is the skeleton; the live library is your private Raindrop corpus. The public template describes how the system works. Your personal decisions, evaluations, and saved links never belong in the public repository.