Skip to content

bijux-gnss-infra

bijux-gnss-infra owns the repository-facing infrastructure around GNSS runs. This crate is where datasets become typed registry entries, where runs gain a stable identity on disk, and where experiment overrides, provenance hashing, and artifact inspection stay explicit instead of leaking into the runtime or the CLI.

This package matters because reproducibility is not only a receiver concern. Some of the hardest repository questions are not about whether the signal math worked, but about whether the run can be reconstructed, explained, and trusted later.

flowchart LR
    gnss["bijux-gnss<br/>commands"]
    infra["bijux-gnss-infra<br/>datasets and run layout"]
    receiver["bijux-gnss-receiver<br/>runtime artifacts"]
    nav["bijux-gnss-nav<br/>validation references"]
    core["bijux-gnss-core<br/>shared contracts"]

    gnss --> infra
    infra --> receiver
    infra --> nav
    infra --> core

Read These First

  • open Foundation when the question is why infrastructure owns this repository-facing behavior at all
  • open Interfaces when the dispute is already about datasets, manifests, reports, overrides, or validation-facing contracts
  • open Architecture when the question is structural: where datasets, run layout, artifact inspection, and hashing live in code
  • open Quality when ownership is clear and the question becomes whether the proofs and limits are honest enough

Why This Package Exists

  • repository runs need a durable owner for datasets, manifests, reports, and artifact inspection
  • experiment sweeps and profile overrides should be typed and reviewable rather than ad hoc shell logic
  • provenance hashing and run identity need one infrastructure owner instead of being reimplemented in commands and tests

What It Owns

  • dataset registry parsing and raw-IQ metadata resolution
  • run directory identity, naming, records, manifests, and history persistence
  • experiment sweeps, profile overrides, and provenance hashing
  • repository-facing artifact inspection and validation helpers
  • infrastructure-level API composition over lower GNSS crates

What It Refuses

  • receiver scheduling and stage execution owned by bijux-gnss-receiver
  • low-level signal and sample primitives owned by bijux-gnss-signal
  • standalone navigation science owned by bijux-gnss-nav
  • public command vocabulary owned by bijux-gnss
  • cross-package semantic contracts owned by bijux-gnss-core

Strongest Proof Surfaces

Support Crates That Matter Here

  • bijux-gnss-policies guards infra-facing repository layout and public-surface discipline; inspect it when an infrastructure change also changes how the workspace structure is validated.
  • bijux-gnss-testkit does not own repository persistence, but it can provide the truth data that infra validation workflows consume; inspect it when persisted evidence is being judged against shared scientific fixtures.

Sections In This Handbook

  • Foundation for role, scope, ownership, repository fit, and infrastructure vocabulary
  • Architecture for datasets, run layout, artifact inspection, overrides, hashing, and dependency direction
  • Interfaces for public API, dataset contracts, run footprint contracts, override and sweep contracts, and validation adapters
  • Operations for safe change sequence, verification, fixture care, and review scope
  • Quality for trust boundaries, invariants, limitations, risk, and change validation
  • Infrastructure ownership boundaries for deciding whether a capability owns repository state or product behavior

Start Here When

  • the question is about registered datasets, sidecars, or raw-IQ metadata
  • the issue is where a run directory, manifest, or history record comes from
  • the reader needs to understand how sweeps or profile overrides are expanded
  • a reviewer wants to know whether an artifact on disk is being validated at the right boundary

Reader Questions This Package Can Answer

  • how repository runs get stable identity and persisted structure
  • why dataset and metadata resolution are infrastructure concerns rather than command or signal concerns
  • how experiment overrides stay typed and provenance-aware
  • where artifact inspection belongs after execution has finished

Leave This Handbook When

  • the question becomes about the command that invokes the workflow: Command handbook
  • the question becomes about receiver artifacts produced in memory before persistence: Receiver handbook
  • the question becomes about the shared artifact schema or observation meaning: Core handbook
  • the question becomes about navigation reference truth or estimation logic: Navigation handbook

First Proof Check

Design Pressure

If bijux-gnss-infra starts carrying receiver scheduling, navigation policy, or command UX because those surfaces need repository context nearby, the infrastructure boundary becomes a catch-all instead of a durable owner.