Skip to main content

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.

Ingestion is the moment a new signal enters the library. Every ingestion follows the same pattern — save first, inspect second, propose third. The assistant never skips INBOX, and never produces a full decision without operator validation. The INBOX save is a trace, not a classification; the classification comes later, after research is complete and you have reviewed the proposal.

​
The Ingestion Sequence

1

Provide the link to your assistant

Give the URL to your AI assistant in your normal working environment. No metadata is required at this stage — the link itself is enough to begin.
2

Assistant saves to 00_INBOX

The assistant saves the original URL to 00_INBOX with status/pending-review and one next/* tag. This happens before any research begins, to ensure the trace is preserved even if access to the target fails.
3

Assistant researches

The assistant inspects the item using all available tools — reading the page, repository, documentation, release notes, issues, or any other accessible sources. It gathers both official and community evidence before forming a view.
4

Assistant produces a note

The assistant writes the entry in the canonical template format, filling in all required fields: Cataloged, Verdict, Next, Claim, Evidence, Authority, Truth, and StackFit.
5

Assistant proposes tags and placement

Based on the note, the assistant proposes the full tag set, target collection, and any outstanding uncertainty. If evidence is conflicting or incomplete, this is noted explicitly in the proposal.
6

You review and validate

You read the proposal. If it is accurate, you approve and instruct the assistant where to move the entry. If any field is wrong, correct it before approving. The entry moves only after your explicit instruction.

​
The INBOX Save Is Not a Decision

Saving to 00_INBOX preserves the trace. It does not mean the item has been reviewed, classified, or decided. The entry sits pending until you validate the assistant’s proposal. No entry leaves 00_INBOX without operator instruction, and no entry is written directly to 20_LIBRARY without passing through operator validation first. This separation exists because analysis takes time, tools may fail, and your context for a decision may change. The INBOX ensures nothing is lost while still keeping unvalidated entries clearly separate from canonical library entries.

​
What the Assistant Proposes

After research is complete, the assistant produces a note in the following format. Every field is required for a serious entry. The note is a proposal until you validate it. 
Cataloged: YYYY-MM-DD
Verdict: practical judgment in one or two sentences.
Next: next action, such as use now, test, extract pattern, watch, reference only, archive.
Claim: what the link appears to provide or prove.
Evidence: what supports the claim.
Authority: what kind of authority supports it.
Truth: verified, plausible, claimed, conflicting, outdated, or unknown.
StackFit: practical judgment of how realistically you can get value from the item.
Verdict and Next appear within the first three lines so they remain visible even if Raindrop truncates the excerpt. Do not reorder the fields.

​
Access Failure Handling

Sometimes the assistant cannot inspect the target well enough to produce a complete proposal — the page may be behind authentication, the repository may be private, the documentation may be incomplete, or the tool may fail to retrieve the content. When this happens, the assistant stops. It reports:
  • what was saved to 00_INBOX
  • what evidence is currently available
  • what evidence is missing
  • what tool or access problem occurred
  • the minimum step needed to unblock the research
The assistant must not classify, promote, archive, or write a full decision note from insufficient evidence. It must not infer missing substance from the title, URL, stars, popularity, marketing copy, model memory, or similar projects.
The entry remains in 00_INBOX with status/pending-review until evidence is sufficient to propose a complete note.

​
StackFit Assessment

StackFit is the assistant’s practical judgment of how realistically you can get value from an item given your situation. It is not a checklist of tools you already use — it is an evaluation of adoption cost against realistic value. During ingestion, the assistant evaluates StackFit across three dimensions: Value type: direct use, assisted implementation, workflow integration, idea extraction, reference, or discovery. What is the most realistic way this item could benefit you? Adoption cost: dependencies, accounts, APIs, unfamiliar ecosystems, and billing risk. What would it actually take to get value from this item today? Friction threshold: documented and assistant-assisted setup is acceptable; real free tiers are acceptable. Card traps, unclear billing, fake freemium models, enterprise-only assumptions, or incompatible ecosystems all lower the StackFit assessment.
Poor implementation fit does not mean worthless. An item may be status/core-good with next/extract — meaning the idea is valuable even if the tool is not practical — or status/reference with next/revisit, meaning it is worth returning to when the context changes.

Build docs developers (and LLMs) love

Get started for freeTalk to us