Skip to content

Knowledge Base: reference documents

The Knowledge Base is the reference material Dezycro's AI reads before it writes anything for you — design docs, internal specs, existing product docs. Documents are processed, chunked, embedded, and indexed so that PRD authoring, TRD authoring, chat, and test generation retrieve from your product context instead of generic patterns, and cite what they used.

It fills up three ways:

  • Upload files to a project's Documents tab — this page.
  • Import from Confluence or Linear at the workspace level under Workspace settings → Knowledge Base — see Knowledge Base connectors. Imported documents stay in sync with their source.
  • Ship a feature. Its PRD and TRD are in from the start; promoting it to SHIPPED adds its workbook decisions and assumptions — see below.

Not the Agent Playbook

Knowledge Base documents are read-only grounding material. The workspace's Agent Playbook (formerly also called "Knowledge Base") is different: living pages of team rules that humans and agents read and write, and that reach your coding agents as team rules. Runbooks, environment notes, and agent lessons belong there or in another notebook.

Supported formats

  • PDF
  • Word documents (.docx)
  • Markdown (.md)
  • Plain text (.txt)

Max file size: 50 MB. Larger files should be split before upload.

Uploading

  1. Navigate to your project.
  2. Open the Documents tab → Upload.
  3. Drop the file. Ingestion runs as a background workflow.

Info

Processing takes 10–60 seconds depending on file size. Status: processing → ingested or failed. You can navigate away — status is preserved server-side.

You can also upload via the MCP server (mcp__dezycro__upload_document / upload_document_content) if you're scripting bulk ingestion.

What happens at ingestion time

  1. Parse — extract text from the source format
  2. Chunk — split into semantically meaningful pieces (~512 tokens each, with overlap)
  3. Embed — run each chunk through an embedding model
  4. Index — write to your project's vector index
  5. Done — document available for retrieval

Embedding calls run on shared infrastructure and do not count against your token allowance — see What does NOT count.

How retrieved chunks are used

When the AI generates a PRD or test case, it issues a hybrid retrieval query (dense embeddings + sparse keyword) against your project's vector collection, retrieves the top-K most-relevant chunks, and includes them in the LLM prompt as grounding context.

This means generated content:

  • Cites your actual product terminology, not generic patterns
  • Reuses your existing user-flow patterns where they apply
  • Identifies features, user journeys, and acceptance criteria already in your docs
  • Provides accurate per-feature context without you having to paste anything

Shipped features' decisions and assumptions

When a feature is promoted to SHIPPED, on the normal path or with Ship anyway, Dezycro adds what its workbook recorded about how it was built:

  • Decisions. A decision linked to the PRD counts as product material, and one marked as an approved deviation reads Supersedes PRD §n …. A decision about enabling work (INFRA, or no link) counts as technical material.
  • Assumptions, each labelled Assumed at ship, not verified, so nobody mistakes them for checked facts.

Left out on purpose:

  • tasks;
  • invalidated decisions and assumptions;
  • decisions under an open or acknowledged PRD alignment Drift finding (one the agent justified is included).

Each decision or assumption is its own citable entry. A citation names the item's short id (D-012), whether it quotes the summary or the reason, the exact passage, and a link straight to the item in the workbook. Long items are split into parts, each cited separately.

Un-shipping the feature removes its decisions and assumptions; promoting it again replaces them with the current ones. Deleting the feature removes them too.

Citations

Answers in chat and the MCP search tool list where each piece came from: the document or workbook item, the feature it belongs to, and whether that feature is still a draft or already shipped. Use the stage to judge how settled a source is: a shipped feature's decision is what was built, a draft PRD is what's planned.

Managing ingested documents

The Documents tab shows:

Field Description
Name Document filename
Status processing / ingested / failed
Chunk count Number of indexed chunks
Source type How the doc was uploaded (UI / MCP / API)
Ingested at Timestamp

Importing as a PRD

Click Import as PRD on any ingested doc to load it into the PRD editor as an editable starting point. Useful when an existing spec is close to what you want.

Re-indexing

If you edit an ingested doc (re-upload the same filename), Dezycro deletes the old chunks and re-indexes the new content. Vector collection stays consistent.

Deleting

Delete from the Documents tab. Removes the doc + its chunks + any embeddings. Generated PRDs and tests that referenced it stay (the retrieval was at generation time; the output is independent of the source after generation).

Deleting a whole workspace or organization removes all of its Knowledge Base content, including every embedding, along with it.

Document-test traceability

Every test case generated from a PRD captures the source chunk references that grounded it. From the test case detail panel, expand Sources to see which document and which paragraph drove the test.

This is how you spot coverage gaps: if a critical paragraph in your spec has no test referencing it, that's a missing journey.

How retrieval works

Documents are chunked, embedded, and stored in a per-project vector index. At generation time, retrieval combines semantic and keyword matching, then re-ranks the top candidates to select the most relevant chunks as grounding context.

Embedding calls always run on Dezycro's shared infrastructure — they're free of charge and unaffected by BYOK.