Every claim cites the Handbook + the source.
The NASA SE Handbook (NASA SP-2016-6105) prescribes the structure; the source brief justifies the content. Blueprint cites both, on every claim. Students see the Handbook section reference next to the shall-statement they wrote, next to the trade-study rationale, next to the gate- readiness finding. The citation is the teaching.
Two layers of citation, every artifact.
Every Blueprint artifact carries two citation chains:
- Structural citation to the Handbook. The shall-statement is structured this way because Handbook §4.2 prescribes it. The Operational Scenario is structured this way because §4.1.2.2 prescribes it. The PDR readiness criteria are these because §6.7.4 prescribes them. The citation links to the Handbook section that makes the structure canonical. Students see why the artifact looks the way it does.
- Content citation to the source brief. The shall-statement’s value (mass ≤ 8 kg) is set this way because
[DC-7]said “Upper stage allocation of 12 kg dry mass leaves 4 kg propellant margin.” The risk register’s likelihood comes from[DC-12]“Components TRL 6 with limited flight heritage.” The citation links to the DocChunk in the source. Students see the reasoning chain from source to claim.
Both citations are click-throughable in the artifact viewer. §4.2 lands on a Handbook-cross-referenced explanation; DC-N renders the chunk text + the offset in the source document.
How students use this for learning.
The citations are a structural tool for office-hour debugging. When a student shows up with a confused requirements doc, the conversation moves from formatting to reasoning:
- “Why does Blueprint mark this shall as Performance, and I wrote it as Functional?” Open the Handbook §4.2 reference — it’s the definition.
- “Why does Blueprint cite DC-7 here, when I cited DC-3?” Read both chunks. One of them is closer to the source of the claim. That’s the lesson.
- “Why does Blueprint’s trade study consider criterion C2 when I didn’t?” Look at the citation chain. The brief mentioned a constraint the student missed.
The citations turn “why does Blueprint do that” into productive questions instead of mysteries.
The math.
The canonical reference. Every Blueprint artifact maps to a numbered section.
Each agent implements a Handbook section. The pipeline is a Handbook walkthrough.
Independent LLM judge over each Requirement → DocChunk link. Measured on ARCHIPELAGO.
Stable IDs for paragraphs / table cells / list items in the source brief. Click-through in the viewer renders the chunk.
Questions about citation discipline.
How is 'citation precision' measured?
The Citation Verifier is an independent LLM judge (different from the agent that emitted the claim) that scores each Requirement → DocChunk link as 'support / contradict / unsupported'. Precision is supports / total. Per-run telemetry shows the number under 'ICC precision'.
Can a student see what the agent thought when generating a claim?
The reasoning trace is not exposed by default — too much output for a typical run. The citation chain is the readable summary: which DocChunk justified the claim. For instructional debugging, that's usually enough; for deeper analysis, the run log carries the reasoning trace for the advisor to inspect.
What if the Handbook section reference is wrong?
Open a GitHub issue at the public design doc. Handbook references are part of the agent prompts; mismatches are bugs, not features. The product team maintains the section → artifact mapping as the Handbook updates.
Related.
- MBSE coursework tool →
Two-layer pedagogy — notation tools + Blueprint’s discipline view.
- Graduate systems capstone tools →
Two adoption patterns for capstone projects — reference solution + live debugging.
- ← Back to: Blueprint for SE education