Module Map

Use this map when deciding where shared GNSS meaning belongs. Start from the contract a downstream package needs to exchange, not from a source filename or the package that first requested it.

Choose A Contract Family

question	owning family	boundary
How is a constellation, satellite, signal, or component identified?	Identity contracts	identity only; catalog and signal behavior stay in signal
Which time scale or physical quantity does a value use?	Time contracts and unit contracts	shared representation and conversion, not runtime clock policy
Which coordinate frame or shared sanity law applies?	Geometry helpers and scientific conventions	reusable pure meaning, not estimator policy
What crosses acquisition, tracking, observation, or differencing boundaries?	Observation contracts	exchanged records, not stage implementation
How is measurement quality described across packages?	Observation quality	evidence records, not receiver lock policy
What does a navigation result say independent of its solver?	Navigation solution contracts	result, residual, lifecycle, and refusal records, not navigation algorithms
How is a record versioned and validated after serialization?	Artifact contracts	envelope and payload meaning, not repository placement
How do packages exchange failures and diagnostics?	Diagnostic contracts and error taxonomy	structured shared meaning, not command wording
How is shared configuration or support declared?	Configuration contracts and support matrix	cross-package schema and inventory, not local defaults

Placement Decision

flowchart TD
    type["proposed type or helper"]
    shared{"same meaning needed by<br/>multiple packages?"}
    pure{"independent of runtime,<br/>solver, storage, and CLI policy?"}
    family{"existing contract<br/>family owns it?"}
    core["extend that core family"]
    owner["keep with product owner"]
    review["justify a new durable family"]

    type --> shared
    shared -- no --> owner
    shared -- yes --> pure
    pure -- no --> owner
    pure -- yes --> family
    family -- yes --> core
    family -- no --> review

Do not create a new top-level family merely because a type feels "shared." A new family needs distinct semantics, multiple real consumers, and a boundary that will remain understandable after the requesting workflow changes.

Public Boundary

The curated core API is the only downstream import route. The crate architecture guide explains dependency and persistence boundaries, while the contract map carries the crate-local placement rules.

Use State and Serialization before changing a persisted record and Dependency Direction before adding any package relationship.