What is a Brief

The input format, length guidance, and what makes a good Brief.

A Brief is the document you give Blueprint that describes the system you want designed. The pipeline reads it, builds an internal graph, and produces the artifact bundle.

Format

You can submit a Brief as:

Paste-in text — pasted into the form (Markdown is fine)
PDF upload — the pipeline extracts text via pymupdf, falling back to pdftotext on layout-difficult files
Multiple support documents — additional PDFs / Markdown that get added to the retrieval index but don't drive the primary structure

Length guidance

Length	What works	What doesn't
< 500 words	Stakeholder + a few requirements; thin downstream	Can't anchor a full Phase-1.4 run
500–3,000 words	Sweet spot — enough signal, fast to run, clean artifacts	—
3,000–10,000 words	Detailed Briefs; richer artifacts; ~10-15 CU more	—
> 10,000 words	Works, but consider whether everything is really primary; you may benefit from putting some content in support documents	Diminishing returns

What makes a good Brief

A good Brief has these qualities:

1. Names the stakeholders

Don't write "the user" or "we" — name the actual parties: prime contractor, end customer, regulatory bodies, internal teams. Each named stakeholder becomes a node in the stakeholder analysis.

2. States the mission in one paragraph

Up front, in a single paragraph: what the system does, who it does it for, what success looks like. The Brief Parser uses this to seed the project metadata.

Numbers, not adjectives. "≤ 8 kg launch mass" beats "lightweight"; "24-hour uplink within 5 minutes of trigger" beats "responsive communications". Quantified constraints flow through to requirements, trade studies, and verification activities.

4. Includes at least one MOE candidate

A Measure of Effectiveness (MOE) is what the customer cares about at mission level — "% of objects detected with 95% confidence", "time-from-launch to first orbit insertion", etc. Including one or more in the Brief anchors the downstream design decisions.

5. Calls out known risks

If you know a particular subsystem is risky, say so. The Risk Assessor will weight identified risks higher than ones it has to infer.

What to leave out

TIP

Skip the marketing fluff. Blueprint is parsing for structure, not
audience appeal. "Revolutionary new approach" doesn't help; "uses a
two-stage decomposition with cold-gas thrusters for terminal
maneuvers" does.

Marketing language
Vague aspirations ("world class", "best in class")
Boilerplate intro/outro paragraphs from a proposal template
Information that's not about the system itself (team bios, company history)

Versioning

Each Brief submission creates a new project version. If you revise your Brief and resubmit, that's a separate project — the prior run is preserved unchanged.

Sensitivity tier

When you submit a Brief, you also pick a sensitivity tier (Unrestricted / Confidential / Controlled). This routes the run to different LLM providers. Pick conservatively; the Acceptable Use Policy prohibits uploading ITAR/EAR or CUI at any tier.

Pipeline stages overview →