Skip to content

Architecture

A high-level map of how Dezycro is structured. For deeper dives, follow the links into the per-area pages.

Entity model

Tenant (organization)
├── Members (users with tenant-level roles)
├── PATs (Personal Access Tokens)
├── Billing (plan, seats, AI token cap)
└── Workspaces
    └── Projects
        ├── Ingested Documents (RAG knowledge base)
        └── Features  ← the unit of behavior
            ├── PRD (product requirements)
            ├── TRD (technical design)
            └── Workbook
                ├── Journeys (test scenarios)
                ├── Tasks (units of work)
                ├── Decisions (committed choices)
                ├── Issues (current blockers)
                ├── Assumptions (unverified beliefs)
                └── Verifier runs (execution history)

See Auth & access for the tenant-vs-workspace distinction, and The Workbook for the inner workbook structure.

Core workflow

Upload Documents ──→ Author Feature  ──→ Generate Tests   ──→ Run Verifier   ──→ Released
   (RAG)              PRD + TRD            LogicStudio          locally/CI         (locked)
                      via AI / chat /
                      /dezycro:author
  1. Upload Documents — feed existing specs and designs as RAG context.
  2. Author Feature — create the feature, then write its PRD + TRD via AI chat, the editor, or the /dezycro:author state machine.
  3. Generate Tests — open LogicStudio to generate journeys from the TRD.
  4. Run Verifier — the verifier binary is built per-feature from the OpenAPI spec; run it locally or in CI to validate journeys against your real service.
  5. Released — when all enforced journeys pass and all journey-linked tasks are pushed, the feature auto-transitions to VERIFIED. RELEASED is a deliberate user action.

The two product surfaces

Web app — app.dezycro.ai

  • Mission Control — landing page; workspace switcher, recent activity, quick links
  • AI Chat — conversational PRD/TRD authoring
  • LogicStudio — test generation + review grid
  • Feature page — workbook tabs (journeys, tasks, decisions, issues, runs, coverage)
  • Settings — tenant (billing, members, SSO, BYOK, audit logs) + workspace (members, defaults)

Claude Code plugin

  • 8 /dezycro:* slash commands
  • Companion V2 background hooks — verify gate, spec-publish nudge, trigger-based workbook sweep, coverage nudges, TRD quality gate

Both surfaces talk to the same backend, the same workbook, and the same verifier.

Behind the scenes

These pieces are visible only via the MCP server and the Public API, but they're worth knowing about:

Identity (Zitadel)

OIDC under the hood. Default login is Google; Enterprise tenants can wire their own IdP for SSO.

Document chat & RAG

docs-chat service handles PRD/TRD chat. Backed by a per-project Qdrant vector index with hybrid (dense + sparse) retrieval and Cohere rerank-v3 reordering. See Document ingestion.

Doc & test generation

docs-generation service runs the LLM workflows (test case generation). All workflows run on Temporal so they survive pod restarts and can be polled via generation_status.

Verifier pipeline

test-generator service produces the per-feature verifier binary (Kaniko-built Docker images for the IVS pipeline). test-manager records runs and computes coverage projections.

MCP & Public API

mcp-server exposes the MCP tools. The same backend services power the Public REST API (under api.dezycro.ai/api/v1/...).

Auth runtime

auth service handles PAT validation + per-request tenant/workspace permission resolution. Sits between every external request and the per-service backends.

Where data lives

Data Store
Tenants, users, workspaces, billing, PATs PostgreSQL (identitydb)
Features, documents, workbook, journeys, tasks, decisions PostgreSQL (docsdb, testmanagerdb)
Verifier run results, coverage projections PostgreSQL + ClickHouse (analytics)
Document chunks + embeddings Qdrant (per-project collection)
Uploaded files (PDF/DOCX/etc) GCS (Google Cloud Storage)
Logs, traces, metrics SigNoz (OTLP)

All customer data is multi-tenant-isolated at the tenant_id level; every query is scoped on the way in. Enterprise tenants can request single-tenant deployment as a paid add-on.