← Blueprint for solo SE consultants

AI shall-statement writer

A deep look at the shall, the rationale, the verification, the citation.

The NASA SE Handbook §4.2 prescribes the shape of a requirement statement. Most LLM output gets the shall right and gets everything around it wrong. Blueprint emits the full shape — every field grounded — because the underlying data model is the Handbook’s data model.

Start free →See the full pack

Anatomy of a Blueprint shall.

REQ-014: The vehicle shall maintain a dry mass of less
than or equal to 8 kg.

  Type:           Performance
  Verification:   Analysis (T / A / I / D — Handbook Table 4.2-2)
  Level:          system (back-filled from Allocated Baseline)
  Rationale:      Launch-vehicle 12 kg upper-stage allocation
                  with 4 kg propellant margin per source brief.
  Traces to:      NGO-3 (mass budget)
  Cited from:     [DC-7] "Upper stage allocation of 12 kg dry
                  mass leaves 4 kg propellant margin..."
  • The shall. Subject + modal verb (“shall”) + action + constraint. Single sentence. One thought.
  • Type. Functional, Performance, Interface, or Constraint — the four NASA categories.
  • Verification. One of T / A / I / D per Handbook Table 4.2-2. Blueprint picks based on the shall’s testability profile.
  • Level. system / subsystem / element — back-filled after the Decomposition Worker runs, so verification level reflects the actual depth in the PBS.
  • Rationale. The “why this number, why this constraint” statement. Extracted from the brief; cited.
  • Traces to. Parent NGO — the Need / Goal / Objective the shall addresses. Forward link to Component allocation lives in the DTR doc.
  • Cited from. The DocChunk ID + extracted text from the source brief. Click-through in the artifact viewer shows the full chunk.

How to read a Blueprint citation.

[DC-7] is a DocChunk ID — a stable, addressable reference to a paragraph (or table cell, or list item) in your uploaded source brief. When a reviewer challenges a shall, point at the bracketed ID. Click-through in the artifact viewer renders the chunk text alongside the chunk’s offset in the original document.

The Citation Verifier — an independent LLM judge running as its own agent — scores each Requirement → DocChunk link. Failures show up in the run telemetry under ICC precision. On the ARCHIPELAGO smoke this measured 80%. Failures are published not buried; you see them before the reviewer does.

The math.

§4.2
Handbook reference

Requirements Definition canonical section. Blueprint's data model mirrors §4.2's structure one-for-one.

4
requirement types

Functional, Performance, Interface, Constraint — every Blueprint requirement carries one.

80%
ICC precision

Independent LLM-judged Requirement → DocChunk link precision, ARCHIPELAGO smoke.

DC-NNN
citation IDs

Stable addresses to source-brief chunks. Click-through in the viewer renders the chunk.

Questions about shall-statements.

Why 'Analysis' for the verification method in your example?

A mass constraint with a numerical bound is verifiable by analysis (modeled mass budget summed against the limit) before flight hardware exists. Blueprint picks T/A/I/D based on the testability profile of the shall — performance bounds tend toward A or T, functional behaviors toward T or D, interface declarations toward I, constraints toward A.

Can a shall trace to multiple NGOs?

Yes. The graph schema supports many-to-many between Requirement and NGO. The artifact renders the multi-trace as a comma-separated list under 'Traces to'; the bundle's structured outputs (ReqIF, SysML 2 JSON) carry all parent IDs explicitly.

What if a citation is wrong?

Citation Verifier judgments are published in the run telemetry as ICC precision per requirement. Failed links surface as warnings — you fix them by editing the markdown or re-running with a sharper brief. The citation chain failing is itself a signal that the brief was thin in that area.

Related.

See the shall-statements Blueprint writes for your brief.

Free tier · no card · 3 runs / month.

Start free →