System Map¶

Bijux reads more clearly as a layered system than as a list of repositories. Shared governance and shared standards sit underneath the family, `bijux-core` acts as the project backbone, and the documentation hub keeps the whole surface readable.

Bijux is split this way because the work has to stay clear under real pressure: long-lived maintenance, reproducibility, public delivery, and evidence-heavy domain work. The easiest way to understand that shape is to start with the layers and then move into the repositories.

Layered View¶

graph TD
    foundations["Shared foundations<br/>bijux-iac + bijux-std"] --> hub["Documentation hub<br/>bijux.github.io"]
    foundations --> core["Shared runtime backbone<br/>bijux-core"]
    core --> projects["Project repositories"]
    foundations --> projects
    hub --> projects
    projects --> learning["Learning programs<br/>bijux-masterclass"]

Why The Family Is Split This Way¶

long-lived repositories need stable ownership boundaries
scientific and evidence-heavy work needs reproducibility and traceability
public delivery needs clear routes, release discipline, and visible contracts
learning works better when it grows from the same systems instead of detached notes

That is why governance, standards, runtime, projects, and learning stay separate instead of collapsing into one mixed repository surface.

What Each Layer Owns¶

Layer	What it owns	Why it stays separate
Shared foundations	GitHub governance and shared standards	keeps policy and shared behavior aligned before project-specific work begins
Hub	public orientation and documentation routing	keeps movement across the family clear without turning the hub into the source of the standards
Shared project backbone	runtime authority, CLI surfaces, DAG behavior, evidence, and release discipline	gives multiple repositories common execution behavior without forcing them into one codebase
Projects	knowledge systems, delivery interfaces, telecom services, genomics systems, and domain products	keeps implementation responsibility clear and local
Learning	course books, deep dives, capstones, and reusable technical explanation	turns the same engineering language into teachable material

Repository Roles At A Glance¶

Repository	Main job	Best first read
`bijux-iac`	GitHub control-plane governance	Bijux Infrastructure-as-Code
`bijux-std`	shared standards and shell continuity	Bijux Standards
`bijux.github.io`	public orientation and route design	Home
`bijux-core`	shared runtime backbone	Bijux Core
`bijux-canon`	knowledge-system orchestration	Bijux Canon
`bijux-atlas`	delivery interfaces and published surfaces	Bijux Atlas
`bijux-telecom` and `bijux-genomics`	service and Rust domain systems built on shared layers	Projects
`bijux-proteomics` and `bijux-pollenomics`	domain-heavy scientific product work	Applied domains
`bijux-masterclass`	learning programs and capstones	Learning

Where Pressure Shows Up¶

Pressure	What it changes
long-lived maintenance	repository ownership and change authority must stay explicit
scientific workflows	reproducibility and evidence lineage must remain visible
public delivery	docs, APIs, releases, and datasets must behave like maintained surfaces
cross-site documentation	navigation continuity has to stay shared while content stays local

How To Read The Map¶

start with the shared foundations
move to bijux-core for the shared runtime story
move to the project repositories for delivery, knowledge, service, or domain work
move to Masterclass for the program layer

What To Open Next¶

If you want to inspect...	Open
the project split at a glance	this system map
public delivery and operated outputs	Delivery surfaces
shared docs behavior across sites	Documentation network
domain-heavy work under scientific pressure	Applied domains
recurring engineering habits across the family	Work qualities