Skip to content

Bijux Atlas

bijux-atlas is a release-shaped genomics delivery product. It validates raw domain inputs, builds immutable artifacts, publishes serving state, and then exposes that state through product, operations, and maintainer surfaces.

The shortest accurate reading path is: validate inputs -> build artifacts -> publish serving state -> serve and operate with evidence.

License: Apache-2.0 CI Docs Crates Publish GHCR Publish GitHub Release Release GHCR packages Published packages

bijux-atlas bijux-atlas-api bijux-atlas-cli bijux-atlas-core bijux-atlas-ingest bijux-atlas-model bijux-atlas-ops bijux-atlas-query bijux-atlas-runtime bijux-atlas-server bijux-atlas-store ghcr-bijux--atlas ghcr-api ghcr-cli ghcr-core ghcr-ingest ghcr-model ghcr-ops ghcr-query ghcr-runtime ghcr-server ghcr-store Repository docs bijux-atlas docs bijux-atlas rust-docs Operations docs Maintainer docs

What Atlas Actually Is

Atlas is not a single executable with some supporting docs around it. It is a product model with three linked handbooks: - product truth for datasets, contracts, and runtime behavior - operator truth for stack, rollout, observability, and release evidence - maintainer truth for governance, automation, and repository law

flowchart LR
    source[Governed GFF3 and FASTA inputs] --> validate[Validation and normalization]
    validate --> build[Deterministic artifact build]
    build --> release[Immutable release artifacts]
    release --> publish[Catalog and store publish]
    publish --> serve[CLI and HTTP runtime surfaces]
    serve --> observe[Observability and release evidence]

Why That Split Matters

Atlas exists to avoid a common failure mode in data systems: mixing raw inputs, intermediate files, and mutable serving state into one opaque process.

Atlas keeps those boundaries explicit so teams can answer high-stakes questions without guessing:

  • what was actually built
  • what was actually published
  • what is currently served
  • what evidence supports promotion, rollback, or incident decisions

Atlas is strongest when teams need trusted serving of governed release data rather than a convenient but opaque runtime that quietly mutates its own truth.

flowchart LR
    subgraph avoid[What Atlas avoids]
        raw[Raw inputs]
        intermediate[Intermediate files]
        mutable[Mutable runtime truth]
        opaque[Opaque operational decisions]
        raw --- intermediate
        intermediate --- mutable
        mutable --- opaque
    end

    avoid --> boundary

    subgraph boundary[What Atlas enforces]
        governed[Governed inputs]
        validated[Validated build boundary]
        immutable[Immutable release artifacts]
        serving[Published serving state]
        evidence[Operational and release evidence]
        governed --> validated --> immutable --> serving --> evidence
    end

What It Guarantees

  • deterministic build behavior from governed inputs
  • immutable release artifacts as the delivery unit
  • explicit runtime, API, and configuration contracts
  • release and operations evidence that can be reviewed and repeated

What Atlas Does Not Pretend To Be

Atlas is not a generic mutable runtime that rewrites release truth in place. It is not a replacement for source governance, and it is not a shortcut around validation, publication, and release evidence.

Atlas Has Four Linked Concerns

Atlas is easier to trust when its major concerns stay explicit instead of being collapsed into one generic idea of "the runtime".

flowchart TB
    atlas[Bijux Atlas]

    atlas --> runtime[Runtime and product]
    atlas --> maintainer[Maintainer control plane]
    atlas --> ops[Operations]
    atlas --> trust[Security and trust]

    runtime --> runtime_a[Datasets and releases]
    runtime --> runtime_b[CLI, HTTP, and OpenAPI surfaces]
    runtime --> runtime_c[Runtime contracts]

    maintainer --> maintainer_a[Ownership and workflow control]
    maintainer --> maintainer_b[Automation and governance]
    maintainer --> maintainer_c[Delivery and compatibility]

    ops --> ops_a[Deployment and stack]
    ops --> ops_b[Rollout safety and recovery]
    ops --> ops_c[Observability and load]

    trust --> trust_a[Provenance and reproducibility]
    trust --> trust_b[Policy enforcement and drift control]
    trust --> trust_c[Release confidence and safe change]

Runtime and Product

This is the product face readers usually mean when they say "Atlas": datasets, releases, queries, interfaces, and contracts.

Maintainer Control Plane

Atlas is not meant to be changed through informal repository habits. The maintainer surface exists so ownership, workflow control, automation, and compatibility policy stay explicit instead of tribal.

Operations

Atlas is a real deployed system, not just a local Rust binary. Deployment, rollout safety, observability, load, recovery, and release evidence are part of the product model.

Security and Trust

Trust is not only vulnerability scanning. It covers provenance, reproducibility, drift detection, controlled exceptions, and whether a release can actually be believed.

Operations and Trust Are Part of the Product

bijux-atlas-ops is where deployment, rollout safety, observability, load budgets, and release trust are explained.

If your question is about running Atlas safely in real environments, operations is the primary handbook.

The same is true of trust. Security and release assurance are not side checks after the runtime is done. They are part of how Atlas proves what was built, what was promoted, and what should be rolled back.

Release Confidence Signals

Primary publication and confidence lanes:

  • repo/ci
  • deploy-docs
  • release-crates
  • release-ghcr
  • release-github

These lanes are represented in the badges above, but the important point is not the badges themselves. Atlas uses them to decide whether a release is ready to promote, hold, or roll back. 

flowchart TB
    source[Source changes] --> ci[repo and ci]
    ci --> docs[Docs and contract visibility]
    docs --> package[Release packaging]
    package --> crates[release-crates]
    package --> ghcr[release-ghcr]
    package --> github[release-github]
    crates --> confidence[Confidence signals]
    ghcr --> confidence
    github --> confidence
    confidence --> decisions[Promotion, rollback, and incident decisions]

Atlas is not complete when it merely builds. It is complete when build, docs, contracts, publication channels, and operational evidence line up tightly enough that release decisions are reviewable instead of improvised.

Published and Repository-Only Crates

Atlas 0.2.2 publishes eleven Rust crates and keeps one maintainer crate repository-only.

Published crates: bijux-atlas, bijux-atlas-api, bijux-atlas-cli, bijux-atlas-core, bijux-atlas-ingest, bijux-atlas-model, bijux-atlas-ops, bijux-atlas-query, bijux-atlas-runtime, bijux-atlas-server, and bijux-atlas-store.

Repository-only crate: bijux-atlas-dev.

Use this split when deciding where to start: - product runtime and release behavior: bijux-atlas, bijux-atlas-runtime, bijux-atlas-cli, bijux-atlas-server, bijux-atlas-api - leaf implementation contracts: bijux-atlas-core, bijux-atlas-model, bijux-atlas-query, bijux-atlas-ingest, bijux-atlas-store - operational surfaces: bijux-atlas-ops - repository governance and maintainer workflows: bijux-atlas-dev

Start From the Right Handbook

The three handbook surfaces are separated on purpose because they answer different classes of questions.

If you want one rule for reading the docs: start from the handbook that owns the decision you need to make, not from the directory that happens to look closest.

Repository

Use Repository when the question is about the Atlas product itself: datasets, releases, workflows, interfaces, runtime architecture, and compatibility contracts.

Operations

Use Operations when the question is about how Atlas runs safely: deployment, rollout safety, observability, load, recovery, and release operations.

Maintainer

Use Maintainer when the question is about how Atlas changes safely: ownership, automation, workflow control, delivery, and governance.

  • product model and core boundaries: What Atlas Is
  • runtime architecture, interfaces, workflows, and contracts: Repository
  • deployment, rollout, observability, load, and release operations: Operations
  • governance, control-plane automation, and maintainer ownership: Maintainer

Purpose

This page explains Atlas as a whole system before readers dive into the repository, operations, or maintainer handbooks. It is the high-level contract for what Atlas is for, why its boundaries exist, and how the major handbook surfaces fit together.

Stability

This page is part of the canonical docs spine. Keep it aligned with the current Atlas release model, runtime surfaces, operations surface, and maintainer control plane.

Reference Surfaces