VPRamon · Oct 4, 2026 · Oct 4, 2026 · Oct 4, 2026 · Oct 4, 2026 · Oct 4, 2026
diff --git a/README.md b/README.md
@@ -46,6 +46,12 @@ cd spod
 cargo test
 ```
 
+## Product wiki
+
+The product definition, commercial positioning, capability ownership, feature-parity policy, roadmap, and detailed operational use cases live in the [product wiki](docs/product/README.md).
+
+The product North Star is **onboard GNSS observations -> automated precise LEO orbit + QC + standard products + full provenance**.
+
 ## Relationship with the Siderust ecosystem
 
 Foundational astrodynamics, typed quantities, time scales, frames, and reusable numerical mechanics live in the released Siderust ecosystem crates. `spod` is built on top of `siderust::pod`; it does not expose a scientific compatibility facade. Callers needing reusable force, observation, estimation, QC, or product APIs should import Siderust directly.

diff --git a/docs/product/README.md b/docs/product/README.md
@@ -0,0 +1,122 @@
+# spod Product Wiki
+
+This wiki defines what `spod` is as a product, who it is for, which workflows it should provide, and how those capabilities relate to Siderust.
+
+> **spod is operational Precise Orbit Determination infrastructure built on Siderust.**
+
+Siderust owns reusable scientific and numerical primitives. `spod` turns those primitives, external datasets, mission configuration, and operational policy into reproducible POD jobs, products, quality reports, and service interfaces.
+
+## North Star
+
+```text
+onboard GNSS observations
+        +
+precise supporting products
+        +
+mission configuration
+        |
+        v
+      spod
+        |
+        +-- resolve and validate inputs
+        +-- construct the POD problem
+        +-- orchestrate Siderust science
+        +-- estimate and assess convergence
+        +-- apply operational QC policy
+        +-- write standard products
+        +-- record full provenance
+        |
+        v
+precise orbit + QC + artifacts + manifest
+```
+
+The North Star milestone is tracked in [#20](https://github.com/VPRamon/spod/issues/20).
+
+## Product boundary
+
+### Siderust owns
+
+- physical and astrodynamics models;
+- propagation and numerical algorithms;
+- estimators;
+- observation models;
+- coordinate/time/unit primitives;
+- standard file-format parsers and writers;
+- reusable scientific QC primitives;
+- reusable product serialization.
+
+### spod owns
+
+- job and workflow definitions;
+- mission configuration;
+- input resolution and acquisition policy;
+- orchestration of Siderust components;
+- artifact layout and publication;
+- operational QC policy and human-readable reporting;
+- provenance and reproducibility;
+- CLI and REST interfaces;
+- fleet/reprocessing orchestration;
+- observability;
+- deployment and operational behavior.
+
+The rule is not `if Siderust implements it, spod stops supporting it`.
+
+> **If Siderust implements the science, spod should consume it instead of duplicating it while preserving the product capability.**
+
+See [Feature parity policy](feature-parity-policy.md).
+
+## Wiki map
+
+- [Product vision and positioning](product-vision.md)
+- [Personas and buyers](personas-and-buyers.md)
+- [Capability map](capability-map.md)
+- [Feature parity policy](feature-parity-policy.md)
+- [Commercial model and packaging](commercial-model.md)
+- [Commercial/product roadmap](commercial-roadmap.md)
+- [Use cases](use-cases/README.md)
+
+## Primary use cases
+
+| Use case | Primary customer | Product value | Tracking |
+|---|---|---|---|
+| Operational onboard-GNSS POD | LEO/EO operator | Precise orbit products without building a POD stack | [#20](https://github.com/VPRamon/spod/issues/20) |
+| Fleet / constellation POD | Constellation operator | Repeatable processing across many spacecraft | [#31](https://github.com/VPRamon/spod/issues/31) |
+| Independent orbit validation | Operator / integrator | Independent confidence and quality gate | [#24](https://github.com/VPRamon/spod/issues/24) |
+| Mission commissioning | Mission operations | Validate GNSS tracking and POD readiness | [#30](https://github.com/VPRamon/spod/issues/30) |
+| Historical reprocessing | Science / operations | Reproduce historical products under new baselines | [#25](https://github.com/VPRamon/spod/issues/25) |
+| Multi-latency operations | Operational ground segment | Rapid vs final processing policy | [#26](https://github.com/VPRamon/spod/issues/26) |
+
+## Product enablers and recovery work
+
+- product capability parity and migration discipline - [#19](https://github.com/VPRamon/spod/issues/19)
+- dataset resolution and acquisition - [#21](https://github.com/VPRamon/spod/issues/21)
+- mission profiles - [#22](https://github.com/VPRamon/spod/issues/22)
+- operational QC / run health - [#23](https://github.com/VPRamon/spod/issues/23)
+- restore human-readable QC artifact - [#33](https://github.com/VPRamon/spod/issues/33)
+- observability - [#27](https://github.com/VPRamon/spod/issues/27)
+- stable product/artifact API - [#28](https://github.com/VPRamon/spod/issues/28)
+- SGP4/SDP4 parity preservation - [#29](https://github.com/VPRamon/spod/issues/29)
+- LISA reference example rather than core feature - [#34](https://github.com/VPRamon/spod/issues/34)
+
+## Product principles
+
+1. **Capabilities are more important than module paths.**
+2. **No silent scientific downgrade.**
+3. **Every run is auditable.**
+4. **CLI and REST are interfaces to the same product.**
+5. **Operational policy belongs in spod; reusable science belongs in Siderust.**
+6. **Automation is a feature, not an external shell script.**
+7. **Quality is an output.** A generated orbit is not enough; the service must explain whether it is fit for its configured operational purpose.
+8. **Mission-specific demonstrations are examples unless they earn a core product use case.**
+
+## Current status
+
+`spod` is an engineering preview. The deterministic synthetic workflow proves the service boundary and artifact/provenance model, but the product is not commercially complete until a real-data workflow is operational.
+
+The key transition is:
+
+```text
+synthetic reference workflow
+        ->
+real onboard GNSS data -> operational precise orbit product
+```
diff --git a/docs/product/capability-map.md b/docs/product/capability-map.md
@@ -0,0 +1,87 @@
+# Capability map
+
+This document maps product capabilities to their intended long-term owner. The detailed parity inventory is tracked by [#19](https://github.com/VPRamon/spod/issues/19).
+
+## Disposition vocabulary
+
+- **KEEP IN SPOD** - service/application capability.
+- **MIGRATE TO SIDERUST** - product capability remains, implementation becomes canonical upstream.
+- **UPSTREAM GAP FIRST** - capability must not be deleted until upstream has required semantics.
+- **INTENTIONALLY RETIRE** - capability is deliberately not part of the core product.
+- **REFERENCE EXAMPLE** - mission-specific capability demonstrated outside the core product surface.
+- **ADD TO SPOD** - missing product/application capability.
+
+## Existing capabilities
+
+| Capability | Product relevance | Intended owner | Disposition |
+|---|---|---|---|
+| Run configuration | core | spod | KEEP IN SPOD |
+| Job execution | core | spod | KEEP IN SPOD |
+| Artifact layout | core | spod | KEEP IN SPOD |
+| Run provenance/manifests | operational policy around reusable primitives | spod + Siderust | KEEP IN SPOD |
+| CLI | core interface | spod | KEEP IN SPOD |
+| REST API | core interface | spod | KEEP IN SPOD |
+| Docker/deployment | operations | spod | KEEP IN SPOD |
+| Synthetic reference workflow | integration/reference | spod + Siderust | KEEP IN SPOD |
+| Human-readable QC report | product presentation/artifact | spod | KEEP IN SPOD / RESTORE - [#33](https://github.com/VPRamon/spod/issues/33) |
+| Force models | scientific primitive | Siderust | MIGRATE TO SIDERUST |
+| Propagation / STM | scientific primitive | Siderust | MIGRATE TO SIDERUST |
+| WLS / nonlinear / sequential estimation | scientific primitive | Siderust | MIGRATE TO SIDERUST |
+| Observation models | scientific primitive | Siderust | MIGRATE TO SIDERUST |
+| Generic QC statistics, orbit comparison, SLR validation | scientific primitive | Siderust | MIGRATE TO SIDERUST; expose through spod workflows |
+| SP3/OEM serialization | standard product primitive | Siderust | MIGRATE TO SIDERUST |
+| Run-manifest JSON schema | reusable run contract | Siderust | MIGRATE TO SIDERUST; canonical schema already exists upstream |
+| TLE / 3LE / OMM | standard formats | Siderust | MIGRATE TO SIDERUST |
+| SP3 / RINEX / ANTEX / SINEX / ORBEX | standard formats | Siderust | MIGRATE TO SIDERUST |
+| EOP / CRD / CPF / OEM / OPM / TDM | standard formats | Siderust | MIGRATE TO SIDERUST |
+| SPICE / SPK | scientific/format primitive | Siderust | MIGRATE TO SIDERUST |
+| Full Vallado SGP4/SDP4 | useful operational capability | canonical Siderust ecosystem backend | UPSTREAM GAP FIRST - [#29](https://github.com/VPRamon/spod/issues/29) |
+| Lambert solver | generic mission-design function | ecosystem | INTENTIONALLY RETIRE from core spod unless a concrete operational workflow is justified |
+| LISA-specific functionality | mission-specific reference | example/reference layer | REFERENCE EXAMPLE - [#34](https://github.com/VPRamon/spod/issues/34) |
+| DORIS parser | standard format | Siderust | MIGRATE TO SIDERUST; not a spod feature by itself |
+| DORIS POD workflow | mission/product workflow | spod + Siderust | future product decision |
+| de440 feature | validation/development mechanism | tests/upstream | not a product capability |
+| Parquet export | optional artifact format | Siderust serializer + spod policy | KEEP only when exposed by a supported workflow |
+
+## Missing product capabilities
+
+| Capability | Why it belongs in spod | Tracking |
+|---|---|---|
+| Real onboard-GNSS POD | core commercial workflow | [#20](https://github.com/VPRamon/spod/issues/20) |
+| Dataset resolution/acquisition | operational orchestration | [#21](https://github.com/VPRamon/spod/issues/21) |
+| Versioned mission profiles | application configuration | [#22](https://github.com/VPRamon/spod/issues/22) |
+| Operational QC / run health | service policy | [#23](https://github.com/VPRamon/spod/issues/23) |
+| Independent orbit/SLR validation | product workflow | [#24](https://github.com/VPRamon/spod/issues/24) |
+| Human-readable QC artifact | application/reporting | [#33](https://github.com/VPRamon/spod/issues/33) |
+| Reprocessing campaigns | orchestration | [#25](https://github.com/VPRamon/spod/issues/25) |
+| Latency/processing classes | operational policy | [#26](https://github.com/VPRamon/spod/issues/26) |
+| Metrics / observability | operations | [#27](https://github.com/VPRamon/spod/issues/27) |
+| Stable product/artifact API | service interface | [#28](https://github.com/VPRamon/spod/issues/28) |
+| Mission commissioning | product workflow | [#30](https://github.com/VPRamon/spod/issues/30) |
+| Fleet/constellation orchestration | scale/operations | [#31](https://github.com/VPRamon/spod/issues/31) |
+| LISA reference example | extension/reference use case | [#34](https://github.com/VPRamon/spod/issues/34) |
+
+## Target public concept model
+
+Long-term `spod` concepts should look more like:
+
+```text
+MissionProfile
+RunConfig
+Job
+JobStatus
+Workflow
+ResolvedInputs
+RunResult
+Artifact
+QcReport
+RunManifest
+Campaign
+Fleet
+```
+
+and less like a second namespace of generic force models, estimators, standard-format parsers, SPICE internals, or mission-design algorithms.
+
+## Important distinction
+
+Removing an old Rust API such as a local TLE parser does not imply removing the ability for a supported `spod` workflow to accept TLE data. The workflow should call the canonical Siderust implementation directly while preserving the product capability.
diff --git a/docs/product/commercial-model.md b/docs/product/commercial-model.md
@@ -0,0 +1,111 @@
+# Commercial model and packaging
+
+This page describes plausible ways to package `spod`. It is directional, not a pricing commitment.
+
+## Product thesis
+
+The commercial object is not the scientific algorithm itself. The value is supported POD workflows, operational reliability, integration, reproducibility, quality reporting, deployment, and controlled upgrades.
+
+## spod Engine
+
+Self-hosted operational POD service for customers who need to run inside their own infrastructure.
+
+Expected surfaces:
+
+- container image;
+- CLI;
+- REST API;
+- mission profiles;
+- artifact integration;
+- metrics/logging;
+- supported releases and onboarding.
+
+Likely customers include satellite operators, ground-segment integrators, institutional missions, and organizations with data-residency requirements.
+
+## spod Validate
+
+Independent orbit-quality and processing-validation product that can be used even when `spod` is not the primary POD engine.
+
+Core capabilities:
+
+- orbit-vs-reference comparison;
+- RTN/RAC statistics;
+- residual assessment when available;
+- SLR validation when available;
+- processing-baseline comparison;
+- machine-readable quality status;
+- audit report.
+
+Tracked by [#24](https://github.com/VPRamon/spod/issues/24).
+
+This may have lower adoption friction because the customer does not need to replace its operational POD chain.
+
+## spod Cloud
+
+Managed POD execution where a customer submits or streams tracking data and obtains products through an API.
+
+Additional requirements beyond Engine include durable storage, tenancy, auth, usage accounting, durable queues, SLOs, and security/compliance. These are not immediate repository goals.
+
+## Deployment modes
+
+```text
+local CLI
+   |
+container
+   |
+customer REST service
+   |
+managed cloud service
+```
+
+Scientific behavior should not fork by deployment mode.
+
+## Commercial readiness gates
+
+### Gate 1 - Engineering reference
+
+- deterministic synthetic workflow;
+- provenance;
+- CI;
+- CLI/REST/container.
+
+### Gate 2 - Real-data product proof
+
+- onboard GNSS workflow;
+- real standard datasets;
+- standard orbit products;
+- operational QC;
+- documented validation case.
+
+This is the critical transition represented by [#20](https://github.com/VPRamon/spod/issues/20).
+
+### Gate 3 - Operational pilot
+
+- mission profiles;
+- dataset resolution;
+- stable API;
+- structured errors;
+- observability;
+- repeated daily operation on a representative mission.
+
+### Gate 4 - Production deployment
+
+- controlled upgrades;
+- run/campaign recovery;
+- resource sizing;
+- support procedures;
+- security review;
+- sufficient external validation for the target accuracy class.
+
+### Gate 5 - Scale
+
+- fleet orchestration;
+- reprocessing campaigns;
+- multiple latency classes;
+- operational dashboards/alerts.
+
+## Possible charging models
+
+Potential packaging could support annual self-hosted license/support, managed service per spacecraft/run, mission onboarding, and validation/commissioning packages.
+
+Commercial value should come from operational product quality rather than duplicating scientific code that belongs in Siderust.