Skip to article
/ docs

Search documentation

Popular starting points. Search all 37 articles.

  • Get startedProduct availability and preview limitationsUnderstand what works in the frontend and which product capabilities are not connected yet.
  • Get startedBuild your first RAG pipelineBuild and inspect your first seven-node Basic RAG graph and learn what validation means.
  • Build pipelinesBasic RAG and Hybrid Search templatesCompare Ragify's two starting graphs and decide which pattern to explore.
  • Node referenceUnderstand the node libraryBrowse the ten registered node types by role in the workflow.

↑ ↓ to navigate · Enter to open · Esc to close

Back to Ragify ↗
On this page

Documentation

Documentation policy

Reading availability labels

Understand how the Ragify docs mark active, illustrative, and future functionality.

Every public-facing page about capabilities should carry an explicit, readable availability indicator near the top. This is a documentation-content convention; implementation colors and visual design are left to the coding agent.

Available in frontend #

The feature is present and interactive in the reviewed frontend. This does not imply backend services exist.

Frontend preview #

The UI demonstrates an interaction or concept using local or sample state.

Metadata-only preview #

The interface represents files or documents as metadata without processing actual content.

Planned #

The capability is part of the intended platform but is not operational in the reviewed implementation.

Non-operational example #

A sample request, endpoint, result, or code block exists to explain a future concept. It must not be presented as executable or as a stable public contract.

Concept guide #

The page explains general technical concepts rather than promising that Ragify has implemented them.

Editorial quality rules #

  • Use task-first headings and short opening paragraphs.
  • Include a status label before any instructions that might be mistaken for a live workflow.
  • Give prerequisites, explicit steps, expected outcomes, and related links in tutorials.
  • Use node-page templates consistently: purpose, graph position, guidance, limitations, related pages.
  • Do not invent screenshots, model/provider support, configuration field names, secret-handling behavior, or performance guarantees.
  • Update content only after verifying a feature in the current application.