Pale Red Dot Dev Log #1
Translating a project vision into a structured description is harder than it looks. The ideas exist, but they’re tangled—technical ambitions mixed with unstated assumptions, emotional motivations sitting next to architectural decisions.
For Pale Red Dot, a browser-based Mars exploration viewer, the requirements capture started with a rough notes document and a different kind of prompt:
Ask me any number of questions to make sure that you absolutely understand what I want to achieve. Then create a markdown document that shall be the project description for further prompts on this journey.
What came back wasn’t a document. It was fifteen questions across seven dimensions: vision, audience, technical scope, tooling, constraints, data, licensing.
Questions That Surfaced Assumptions
Some felt obvious in retrospect. Others exposed decisions hiding in plain sight:
- “Are these two separate audiences?” — Space enthusiasts using the viewer and MBSE practitioners reading the blog had been conflated. They need different things.
- “What’s the minimum viable ‘wow’ moment?” — A grand vision existed, but no definition of success at the smallest scale.
- “Per-pixel coordinates: precomputed, real-time, or hybrid?” — Geographic traceability was a goal. The implementation approach wasn’t.
- “SysML v1 or open to v2?” — A tooling decision with long-term architectural implications.
None of these questions were difficult to answer. But they hadn’t been asked.
Managing Scope in Real Time
When new requirements emerged mid-conversation—interactive Jupyter notebooks, documenting the AI collaboration itself—they risked inflating scope. The useful reframe: treat them as byproducts of core work rather than separate workstreams.
Content emerges from building and documenting; it doesn’t compete with it.
The Resulting Artifact
After about an hour of back-and-forth, the output was a 1,500-word project description covering:
- Vision and design philosophy
- Three distinct audiences (one discovered during the conversation)
- Technical architecture across browser, server, and coordinate systems
- MBSE methodology and tooling strategy
- Phased implementation plan
- Licensing approach
- Success criteria
- Open research questions
The document works as context for future sessions, onboarding material for collaborators, and a reference for scope decisions. That reusability was the goal.
Patterns Worth Noting
For requirements capture with AI assistance:
- Prompt for questions, not answers. “Ask until you understand” surfaces more than “write me a plan.”
- Work at your own pace. Answer in batches. The conversation tracks what’s resolved and what’s open.
- Flag scope creep early. When requirements grow mid-stream, decide: core work or byproduct?
- Aim for reusable artifacts. A project description serves the present session and every future one.
- Not everything needs rationalization. Including Spirit and Opportunity “for melancholic reasons” is a valid input. It got noted and preserved without debate.
Part of an ongoing series on building Pale Red Dot, a browser-based Mars surface viewer.