Documentation · Getting started

Create your first project

A CogniForge project starts with a plain-language idea and becomes an approved technical plan before any code is written. This guide covers the greenfield flow — building something new.

1Describe your idea

Click New project, choose Greenfield, and write your idea summary. This becomes the User Brief — the first page of your project's documentation, kept verbatim forever. A good brief mentions:

Who the users are and what roles they play.
The main things each role needs to do.
What problem it replaces (spreadsheets? WhatsApp groups? paper?).

Don't worry about completeness — the next step exists precisely to find the gaps in your brief and ask you about them.

2Review the Understanding Document

The platform expands your brief into a full product understanding: personas, capabilities, user journeys, a proposed architecture shape, data model, and — most importantly — an Assumptions & Open Questions section. Read that section first.

Answer open questions by typing into the Refine box (e.g. "Payments use RazorPay; content is organized by class, not curriculum"). Your answers become recorded, confirmed decisions.
Repeat until the document matches what's in your head, then Approve.

Refining is cheap — the AI rewrites only the sections your feedback touches, not the whole document. Editing a document always resets it to draft so approval refers to exact content.

3Approve the Constitution

Next comes the engineering Constitution: the non-negotiable rules every future ticket must respect (data isolation, security boundaries, audit requirements, review discipline). It is derived from your Understanding — check that its rules match your intent, refine if needed, approve.

4Review the Solution Architecture Document (SAD)

This is the real technical design and the most consequential review. The SAD chooses concretely — never "TBD":

Technology choices: languages, frameworks, database. If you have a preference (say Python over TypeScript), say so in a refine before approving.
Testing Bar: the exact install/build/test commands per component that every ticket must pass, plus the end-to-end test configuration. This literally drives the delivery pipeline.
UI/UX & Design System: component library, real color tokens, landing page and dashboard anatomy — this is what makes generated screens look professional instead of placeholder.
Milestones: Milestone 1 is always the "Foundation & Walking Skeleton" — real scaffolds, real database, real authentication, and one thin working vertical slice. Everything is real from the first ticket; no mock phase.

5Approve — and the board appears

Approving the SAD triggers decomposition: milestones, epics, and stories land on your Board, sized as complete deliverable slices with dependencies enforced. From here, continue with connecting a repository and setting up a build VM — then deliver manually ticket by ticket, or switch on auto-deliver.

Approval gates are enforced: no ticket can be dispatched while any required document is unapproved — and regenerating or editing an approved document resets it to draft, which pauses dispatching until you re-approve.