Shine Harvest

SPACE-BASED SOLAR POWER

Controlled Digital Engineering Program

---

Persistent clean energy from space,delivered through controlled orbital infrastructure.

Shine Harvest is a space-based solar power (SBSP) system architecture designed to collect solar energy in orbit, transmit it as a directed beam to terrestrial receiving stations, and deliver electricity to energy markets through secure, evidence-governed coordination.

This GitHub organization is the private digital engineering backbone of the program. It is not a public showcase. It follows Tier-1 aerospace configuration-control practices: baselined requirements, controlled interfaces, traceable verification evidence, and explicit state semantics across every subsystem boundary.

The architecture distinguishes five layers of physical truth and three cross-cutting governance functions, each managed in a dedicated repository with explicit ownership, interface contracts, and verification linkage.

Design principle: Each layer publishes its own truth. Downstream layers consume that truth — they do not invent it or silently widen its meaning.

These repositories define meaning, control, evidence, and trust before any operational system is built.

These repositories own the upstream physical state of the system: what power is generated and what platform context surrounds it.

These repositories implement transmission, reception, and coordination — all consuming upstream physical truth.

The program maintains 35 controlled interfaces (SH-IF-001 through SH-IF-035) across 5 interface types. The full matrix is governed in sh-architecture/icd/cross-repo-interface-dependency-matrix-v0.2.md.

Interface priority after the solar-generation split:

Non-negotiable rules:

1. A producer repo defines what it publishes. Consumer repos must not silently widen that meaning.
2. If SOL says output is eclipsed, degraded, or constrained — downstream repos must not treat it as normal.
3. If GND is not ready, BMC and MKT must not behave as though valid delivery exists.
4. AUT recommendations do not override safety, authorization, or trust-boundary baselines.

Demo Readiness — Conditional Pass rationale: 22 requirements defined, all critical ICDs drafted, XRV-001 through XRV-007 closed with actions, risk register and threat model in place. Open items: SH-SIM-001 results pending, 9 XRV actions unresolved, branch protection awaiting Team plan upgrade.

 Phase A Phase B Phase C Phase D
Foundations Physical Truth Operations Value Realization
───────────────── ───────────────── ───────────────── ─────────────────
ARCH SIM SOL ORB BMC GND AUT MKT
VNV SEC
───────────────── ───────────────── ───────────────── ─────────────────
[ CURRENT ] [ CURRENT ] [ NEXT ] [ PLANNED ]

Phase exit criteria are enforced. No repo may advance to a later phase until its dependencies in the current phase are baselined. This sequencing is non-negotiable.

The system follows a strict top-down state flow. Downstream layers interpret upstream truth — they do not contradict it.

 Layer 0 Generation Truth SOL Generation state, output confidence, eclipse
│
Layer 1 Platform Operations ORB Platform health, availability (consuming SOL)
│
Layer 2 Transmission Control BMC Beam state, safety interlocks, mode
│
Layer 3 Reception GND Site readiness, telemetry, grid
│
Layer 4 Coordination AUT Scheduling, anomaly response, dispatch
│
Layer 5 Value MKT Allocation, settlement, delivery evidence
│
Layer 6 Assurance SEC + VNV Trust, evidence, readiness

All state terms are defined in sh-architecture/docs/state-dictionary-v0.1.md. When Layer 2 says the beam is DEGRADED, that word has a specific, controlled meaning — and it is the same meaning for every layer that reads it.