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.

SYSTEM documents are governance entries stored as Raindrop bookmarks inside the 00_SYSTEM collection. They are not links you found online — they are the rules, templates, and examples that guide the AI assistant’s behavior at runtime. Before the assistant reviews, tags, or promotes any link, it reads these entries first.

Why SYSTEM Documents Live in Raindrop

Storing governance inside Raindrop means the assistant can read the rules directly from the same backend it uses for bookmarks. There is no separate file to sync, no external URL to remember, and no risk of the assistant working from a stale cached version of your rules. Rules stored in 00_SYSTEM are:
  • Versioned — you can update a bookmark’s note field and the assistant reads the new version on its next access.
  • Correctable — if a rule needs changing, you edit the bookmark. The change takes effect immediately.
  • Accessible at runtime — the assistant can fetch them through the same Raindrop connector it uses for all other collections.
The alternative — keeping rules only in a README or connector description — means the assistant may work from outdated or incomplete guidance without either party noticing.

The Placeholder URL Pattern

Raindrop requires every bookmark to have a URL. For SYSTEM documents that contain governance text rather than real web pages, use stable placeholder URLs so the bookmarks remain addressable without pointing anywhere meaningful.
https://example.com/rdl-agent-contract
https://example.com/rdl-system-spec
https://example.com/rdl-tag-registry
https://example.com/rdl-decision-rules
https://example.com/rdl-note-template
https://example.com/rdl-examples-golden
https://example.com/rdl-usage-flow
The URL is not the source of truth. The bookmark’s excerpt or note field is the source of truth for SYSTEM content. When the assistant reads a SYSTEM entry, it reads the note — not the URL destination. If the assistant can only open the placeholder URL and cannot read the Raindrop excerpt, it must stop and ask for access to the SYSTEM content.
Copy the full text of each governance document from the docs/ folder in the repository into the corresponding bookmark’s note or excerpt field in Raindrop.

Required Read Order

The assistant must read SYSTEM documents in this order before serious classification, tagging, promotion, or normalization work:
1

00_AGENT_CONTRACT — Authority boundaries and stop conditions

Defines what the assistant may and may not do without operator approval. Read first because it establishes the authority boundary that governs every subsequent action.
2

01_SYSTEM_SPEC — Collection model and ingestion flow

Defines the five-collection lifecycle, the ingestion flow, and the required fields for a serious evaluated entry.
3

02_TAG_REGISTRY — Controlled tag grammar

Lists approved tag families and values. Must be read before assigning any tags — the assistant may only use approved values and must not invent new ones.
4

03_DECISION_RULES — Status, truth, authority, fit, and next rules

Defines how to choose status, truth confidence, authority type, StackFit judgment, and next-action tags. Required before writing a verdict or proposal.
5

04_NOTE_TEMPLATE — Canonical note format

The exact shape of an evaluated-entry note: Cataloged, Verdict, Next, Claim, Evidence, Authority, Truth, and StackFit. Required before writing any decision note.
6

05_EXAMPLES_GOLDEN — Drift-prevention examples

Worked examples of correctly classified entries. The assistant uses these to prevent taxonomy drift — gradually shifting tag usage away from the controlled vocabulary.
7

06_USAGE_FLOW — Day-to-day operating loop

The repeating daily loop: receive a signal, save to INBOX, inspect, propose, wait for operator. Read last because it assumes all prior rules are already loaded.
Order matters. 00_AGENT_CONTRACT must come first because it defines what the assistant is allowed to do before it touches anything. Tag registry and decision rules must come before any tagging action. Golden examples must come before classification proposals, so the assistant matches your controlled vocabulary rather than drifting toward whatever phrasing felt natural in a given session.

What Happens If SYSTEM Is Inaccessible

If the assistant cannot read SYSTEM entries from Raindrop, it must stop and report the access failure. It must not reconstruct rules from memory, README fragments, connector descriptions, or prior systems it has encountered. Reconstructed rules are not your rules — they are the assistant’s best guess, and that guess will drift from your controlled taxonomy without you knowing.When SYSTEM is inaccessible, the assistant should report: what it tried to access, what failed, and the minimum step needed to unblock it (for example, checking that the 00_SYSTEM bookmarks have governance text in their note fields).

Keeping SYSTEM Documents Up to Date

SYSTEM documents should change rarely and deliberately. Update them when:
  • Tag values change — a new tag family or value has been approved by the operator. Update 02_TAG_REGISTRY and any golden examples that reference the old value.
  • The note template changes — update 04_NOTE_TEMPLATE and add a golden example showing the new format.
  • New golden examples are added — append to 05_EXAMPLES_GOLDEN when a new recurring classification pattern needs an anchor.
  • Authority or decision rules are refined — update 03_DECISION_RULES and verify that existing golden examples still match.
Never update SYSTEM documents without operator approval. The assistant may propose a change — for example, flagging a gap in the tag registry — but it must wait for you to approve and make the edit. Unauthorized SYSTEM edits break the traceability guarantee the system is built on.

Build docs developers (and LLMs) love