Sprint 001 triage
Sprint 001 starts the North Star operating plan by turning the verified-message goal into a private ledger, a public authority-path matrix, hosted-payload-first criteria, and a first go/no-go record. It is paper triage, not hardware, transmission, launch booking, or legal advice.
預設邊界: Go only for ledger, source review, receive-only evidence practice, and partner-path criteria. No-go for hardware, transmitting systems, launch booking, integration commitment, or public success claims.
North Star
One compliant, authenticated, logged, verifiable message from LEO, with authority, integration, disposal, and post-mission records attached.
First go/no-go: Go for Sprint 001 paper triage; no-go for hardware, transmission, launch booking, integration commitment, or public success claim.
The project has a North Star and operating protocol, but the candidate authority path, payload-minimum question, reviewer category, funding/team assumptions, and disposal evidence requirements are not yet resolved.
sprint-001-ledger-and-authority-triage
Identify the candidate authority path, payload-minimum question, funding/team assumptions, and first stop rules before treating any hardware or integration path as real.
Gate: Continue only if the private ledger identifies the candidate authority path, payload-minimum question, funding/team assumptions, and first stop rules.
預設邊界: A filled mission ledger has been initialized locally under an ignored private ledger path. Filled ledgers must not be committed to public git.
Authority-path matrix
| Focus | Candidate path | Gate question | Go signal | No-go signal | Next action | Nodes |
|---|---|---|---|---|---|---|
| scope-before-authority Scope gate before authority path | Not an authority path; this is the prerequisite gate. | Is the payload still only a verified-message objective, with no service, imaging, or launch-service claim? | Mission wording remains message-only and non-commercial, with public claims limited to evidence and no-go status. | The mission becomes a communications service, public connectivity product, remote-sensing payload, or launch-service effort. | Keep the not-goal list beside every authority-path review. | |
| amateur-satellite-service-question Amateur-satellite service question | Possible only if the mission remains compatible with amateur-satellite purpose and privilege limits. | Can the verified-message objective fit amateur-satellite constraints without becoming a service or shortcut? | A qualified review can explain why amateur-satellite service is appropriate and what responsibilities attach to it. | Any pecuniary, service, remote-sensing, or authorization-bypass purpose appears. | Preserve this as a candidate route only; identify reviewer category before any transmission planning. | |
| part-5-experimental-question FCC Part 5 experimental question | Possible research or experimental path, not selected. | Is the mission genuinely experimental, non-revenue, and reviewable without becoming a public service? | A qualified reviewer identifies Part 5 as the correct path and maps required filings, responsibilities, and stop conditions. | The purpose is operational service, commercial connectivity, or too mature for experimental treatment. | Compare Part 5 against amateur-satellite and Part 25 routes before any operational design. | |
| part-25-small-space-station-question FCC Part 25 small space station question | Possible heavier route for a space-station authorization or streamlined small-space-station process. | Does the mission need a space-station authorization path rather than amateur or experimental treatment? | A qualified reviewer identifies the Part 25 route and confirms the evidence package needed before commitment. | The mission assumes Part 25 applicability without resources, counsel, debris case, or integrator responsibility. | Treat this as an escalation path, not the starting assumption. | |
| faa-payload-review-question FAA payload review question | Payload review dependency, especially if access to orbit is pursued through launch or rideshare. | What information would a launch applicant, payload owner, or payload operator need to resolve before integration? | The payload function, owner/operator responsibility, disposal, and separate authorizations can be described without private or operational detail in public git. | The mission treats launch access as real before payload responsibility and other authorizations are mapped. | Keep payload review questions in the ledger; do not approach launch/integration as a booking task. | |
| remote-sensing-negative-check Remote-sensing negative check | Expected no-go for remote-sensing scope unless the mission is separately re-scoped. | Does any candidate payload sense Earth or produce private remote-sensing data? | Payload definition remains message-only and a negative remote-sensing note is recorded. | Earth-imaging, Earth observation, or remote-sensing capability enters the payload. | Keep remote sensing outside Sprint 001; if it appears, open a separate review before continuing. | |
| debris-disposal-evidence-gate Debris and disposal evidence gate | Required evidence gate before any orbit or integration commitment. | Can the mission explain disposal responsibility before selecting any orbit or integration path? | Disposal and debris-mitigation questions are mapped before orbit choice. | Orbit is selected only for contact convenience or schedule pressure. | Keep orbit selection blocked until disposal evidence requirements are understood. |
Hosted-payload criteria
Accept signal: A host or partner can carry the message objective while preserving authority, logs, identity, disposal, and post-mission evidence.
Reject signal: The verified-message objective requires operator control of a full spacecraft or cannot preserve evidence through a host.
Next action: Define the minimum evidence packet before listing candidates.
Accept signal: The partner path is compatible with non-commercial learning and can identify responsible reviewers.
Reject signal: The path requires a commercial service claim, opaque authority ownership, or private terms that cannot support public evidence.
Next action: List partner categories, not named outreach targets, until authority questions are cleaner.
Accept signal: The integrator path can document roles, evidence, payload review dependencies, and post-mission records before commitment.
Reject signal: The path treats rideshare price as total mission cost or leaves owner/operator responsibility implicit.
Next action: Map responsibilities and cost categories before any candidate outreach.
Accept signal: Hosted payload and partner routes are shown inadequate, and the ledger records resources, reviewers, responsibility, and no-go rules.
Reject signal: Full spacecraft ownership is chosen for ambition, aesthetics, or control before the minimum payload question is answered.
Next action: Keep full spacecraft ownership blocked until hosted-payload-first analysis is complete.
Allowed next actions
Blocked actions
來源