A Blueprint is your project’s set of design documents — the shared picture of what the project is built on and how its pieces fit together. DIJJI.ai generates it for you, you review and correct it, and then you write it into your repository so every run works from the same reference. It lives under the project’s Plan section, at Plan > Blueprint.
The four documents
A Blueprint is always the same four documents, in this order:
- Tech Stack — the languages, frameworks, and tools the project is built with.
- Architecture — how the system is structured and how its parts connect.
- Design — how the product is meant to look and behave.
- QA — how the work is tested and what “done” looks like.
Together they’re the design reference your AI engineer reads before it plans or writes code.
How a Blueprint is made
You start by generating one. DIJJI.ai asks which kind of project this is:
- Greenfield — starting from scratch, an empty repository with no existing code.
- Brownfield — an existing project with code the Blueprint can read from.
You can add notes and upload files or screenshots to steer the result. DIJJI.ai then drafts the four documents (you’ll see Generating blueprint… while it works).
Reviewing what it drafted
A Blueprint isn’t meant to be taken on faith — it tells you how sure it is of each part. Every field carries a status:
- Filled (green) — DIJJI.ai had enough to fill this in.
- Assumption — confirm/change (amber) — it made a reasonable guess; check it and adjust if it’s wrong.
- Question — answer (blue) — it needs you to decide something before the Blueprint is complete.
Each field has a plain-language explanation, with a Technical detail disclosure if you want the specifics. Your job is to clear the assumptions and answer the questions until the picture is right. You can add input and regenerate as you go, and earlier versions can be restored.
Writing it to the repository
When the Blueprint looks right, you Write to repo. This renders the four documents to your repository’s /docs folder and opens a pull request — you review and merge it like any other. From then on, the design docs live in your repo alongside the code, and you can write again to update them as the project evolves.
Blueprint vs. Requests
Blueprint and Requests both turn your input into something structured, but they produce different things:
- A Blueprint produces design documents, written to your repository as a pull request.
- A Request produces tasks — work items saved to your task list, with no pull request.
Use a Blueprint to establish what the project is; use Requests to describe work you want done.
To create and write one step by step, see Generate and write a Blueprint.