The guided way to write your thesis: question to compiled draft

A thesis is not one job. It's a dozen jobs that have to happen in the right order: find a question, read the field, make sense of it, design and run your study, draft, revise, verify, and compile. CiteDash AI has a tool for each of those, but knowing which to open next is its own kind of stress. The Question → Thesis flow removes that decision. It's a guided step rail that walks you through the whole thesis writing workflow end to end, opening the right tool at the right moment, so you always know what's next.

It isn't a thirteenth tool with its own outputs. It's a wrapper over the tools you'd use anyway. Everything you do inside the flow lives in the real tools and stays there. This guide walks all ten steps in plain language, the way a first-time thesis writer would meet them.

How the flow works: checkpoints and auto-run

Two ideas make the rail trustworthy. First, done-ness is derived live from your actual project, never a checkbox you tick and forget: if a step's real work exists, it shows as done; if you undo that work, it un-does. The rail and the individual tools can never disagree, because they read the same truth.

Second, there's an "Auto-run to next checkpoint" button. It runs the mechanical steps for you and then stops at the points where judgement is yours: pinning the question, screening the library, your own data and analysis, resolving flagged claims, and signing off the compile. It never makes those calls for you, and it never invents data. Auto-run saves you clicks; it never replaces a decision.

Step 1: Question

Everything hangs off your research question, so you pin it first. Describe your interest in plain language and pick from candidate questions carrying real evidence, novelty, and feasibility signals, or type and pin your own. This is a human checkpoint: auto-run won't choose a question for you. Once pinned, every downstream step frames its work around it.

Step 2: Concept Map

Next you get a grounded concept map: a diagram of the key concepts inside your question and how they relate. It's a fast way to see the shape of what you're about to study (the variables, the tensions, the sub-questions) before you drown in papers. It's drawn from your question, not from thin air.

Step 3: Library

Now you build the evidence base. Search 250M+ works across the major scholarly sources plus the indexed corpus, upload PDFs you have legal access to, and screen what's worth keeping. Open-access full text is fetched and indexed automatically. This step has a human checkpoint. Screening is yours, because only you know what truly fits your question. Full text matters here: only papers whose PDF is stored can later be cited and verified.

Step 4: Synthesis

With a library in place, you make sense of it. Synthesis builds an evidence matrix (one row per paper, columns for the questions you're asking the literature) and drafts a grounded narrative where every claim traces to a matrix cell with a verification verdict. A cell the AI can't ground from full text stays empty rather than guessed. If your field expects a formal systematic review, you can run the optional PRISMA screen with recorded decisions and a flow diagram here.

Step 5: Design & analyse

This step adapts to your method. For empirical work, you draft a study design and then (the important part) you upload your own data and run the analysis. CiteDash computes statistics with real code and never invents data or results; the AI's job is to interpret the numbers it was given, not to produce them. Your data and your analysis are a human checkpoint. If your thesis is a literature review with no primary data, this step simply doesn't apply and the flow skips it.

Step 6: Draft

Now the writing. The AI drafts each chapter from your own grounded work: Introduction from your pinned question, Literature Review from your synthesis, Methodology and Results from your design and analyses. These are starting drafts, not finished prose: every AI-drafted claim arrives with a citation that resolves to a real paper, and anything it can't ground is flagged in place rather than smoothed over. You edit from a defensible first pass instead of a blank page.

Step 7: Refine

With chapters drafted, Refine runs the Proof Reader over your manuscript for style and cross-chapter coherence, catching the drift, repetition, and register mismatches that creep in when chapters are written at different times. Citations are locked through every rewrite, and any cited claim whose wording changed is re-verified before it's applied.

Step 8: Verify

Before anything compiles, you resolve outstanding Fact-Checker flags. The trust invariant is simple and absolute: every citable claim must resolve to a real paper and be verified against that paper's full text. Verify is where you clear the partials and unsupported claims, usually by narrowing an overclaim, swapping a source, or promoting a held reference to full text so there's something to check against. This is a human checkpoint: the flow won't paper over an unresolved claim for you.

Step 9: Compile

Compile binds it all into one formatted document (title page, table of contents, numbered chapters, and a deduplicated bibliography in your citation style) exported as PDF, Word, or LaTeX. Nothing compiles over unverified claims silently: if any remain, you have to consciously acknowledge them, and that override is recorded in your audit trail. The compile sign-off is yours.

Step 10: Check & submit

The last step gets you out the door. An originality pre-check screens for verbatim overlap against the literature before your institution's plagiarism software does, you get the submission-ready file, and the flow tells you how to run your institution's own binding check. Green here means Fact-Checker-confirmed and originality-screened, an honest picture of what's ready, not a reassuring one.

Why the guided path helps

• You never wonder what to open next. The rail sequences the whole lifecycle for you.
• Auto-run clears the mechanical work and pauses where your judgement is required.
• Human checkpoints keep you the author: the question, screening, your data, flagged claims, and the compile sign-off are always yours.
• The trust invariant holds throughout: real papers, verified against full text, or the claim doesn't reach your final document unacknowledged.
• Done-ness reads your real work live, so the flow and the individual tools always agree.