Bijux¶
platform systems, delivery interfaces, scientific software, and technical programs
Bijux is a repository family for governed platform, data, and scientific systems.
bijux.io is the public hub for that family. It connects the shared foundations, the runtime backbone, the project systems, and the learning programs in one readable surface.
platform architecture
control-plane design
data-service design
bioinformatics software
documentation as delivery
teaching through systems
Start with the foundations, then follow the branch that matches your question.
The rest of the site stays organized around that same split.
What Bijux Is¶
Bijux is a repository family for platform engineering, data and service delivery, scientific software, and technical education.
It stays readable because ownership changes hands in named places:
- one branch explains the platform structure of the family
- one repository owns the live GitHub control plane
- one repository owns the shared standards layer
- one repository owns the public documentation hub
- one repository owns the shared runtime backbone used across projects
- other repositories own knowledge, delivery, domain, and learning work
At A Glance¶
| Layer | Owned in | What becomes visible |
|---|---|---|
| control plane | Bijux Infrastructure-as-Code | GitHub governance applied as code |
| shared standards | Bijux standard layer | shared docs shell, shared checks, shared repo contracts |
| documentation hub | Platform overview and this site | cross-repository orientation and route design |
| shared runtime backbone | Bijux Core | CLI, DAG, evidence, and release discipline used across projects |
| project systems | Projects | knowledge, APIs, datasets, packages, and domain systems |
| learning surface | Learning catalog | technical programs built from the same engineering language |
Core Ideas¶
- Separate repositories by operating responsibility so boundaries remain stable as systems grow.
- Treat documentation, contracts, and release behavior as owned delivery outputs.
- Make the control plane, standards layer, hub, and project layers visible as different kinds of work.
- Keep the same engineering language across platform, domain, and learning surfaces.
How It Is Organized¶
The site starts from repository ownership, then opens into reading routes. Shared documentation shell behavior and cross-repository standards checks live in Bijux Standards, while live GitHub policy is owned in Bijux Infrastructure-as-Code.
Reading Approach¶
Start with the family shape, then continue into the branch that matches your interest.
| Start here for... | Open this first | What you will find |
|---|---|---|
| how the repositories fit together | Platform overview -> System map | the split across shared foundations, runtime, knowledge, delivery, and domain work |
| how GitHub governance is applied across the family | Bijux Infrastructure-as-Code | the live control plane and the review model behind the repositories |
| how shared behavior stays aligned across repositories | Bijux standard layer | shared docs shell, shared make behavior, and standards promotion |
| how delivery appears in public | Delivery surfaces -> Bijux Atlas | documentation, published destinations, and operated service surfaces |
| how the work behaves under domain pressure | Applied domains -> Bijux Proteomics -> Bijux Pollenomics | scientific and evidence-heavy product systems |
| how the same technical style carries into teaching | Learning catalog | course books and programs built around the same technical language |
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"]
foundations --> canon["Knowledge system<br/>bijux-canon"]
core --> projects["Project systems<br/>atlas, telecom, genomics, proteomics, pollenomics"]
canon --> projects
hub --> projects
projects --> learning["Learning programs<br/>bijux-masterclass"]Reading Paths¶
New here? Start with
Home -> Platform ->
Bijux Infrastructure-as-Code ->
Bijux Standards. This is the shortest route into the shared foundations.
The map below summarizes the main route families at a glance.
graph LR
entry["Reader starts here"] --> split{"What do you want first?"}
split --> architecture["System architecture"]
split --> delivery["Delivery and service behavior"]
split --> domain["Scientific and evidence-heavy systems"]
split --> teaching["Transferable engineering practice"]
architecture --> platform["Platform"]
architecture --> map["System map"]
delivery --> surfaces["Delivery surfaces"]
delivery --> atlas["Bijux Atlas"]
domain --> applied["Applied domains"]
domain --> scientific["Proteomics and Pollenomics"]
teaching --> learning["Learning"]
teaching --> programs["Masterclass programs"]Choose a route below by intent or by time.
By Intent¶
| If you want to inspect... | Start here | Then continue into |
|---|---|---|
| system design and repository split | Platform overview | System map |
| control plane design and repository governance | Bijux Infrastructure-as-Code | Platform overview, System map |
| shared standards and cross-repository continuity | Bijux standard layer | Documentation Network |
| delivery and service interfaces | Delivery surfaces | Bijux Atlas |
| domain-heavy product work | Applied domains | Bijux Proteomics, Bijux Pollenomics |
| technical teaching built from the same system language | Learning catalog | Reproducible Research, Python Programming |
By Time¶
| If you have... | Read this route |
|---|---|
| 10 minutes | Home -> Platform -> Projects |
| 20 minutes | Platform -> Bijux Infrastructure-as-Code -> Bijux standard layer |
| 30 minutes | Platform -> Bijux Infrastructure-as-Code -> Bijux standard layer -> Bijux Core -> Bijux Atlas |
architecture route
Start with the system split
Open Platform and the System Map first, then Core and Canon, to see how runtime, knowledge, and governance divide cleanly.
delivery route
Start with delivery surfaces
Open Delivery Surfaces and then Atlas for the fastest route into service contracts, APIs, datasets, and publication.
domain route
Start where the work gets harder
Open Applied Domains, then Proteomics and Pollenomics, to see the same engineering posture under scientific constraints.
Browse the repositories
Read the platform branch
Open the control plane
Open the standards layer
Choose a reading path
Repository Family¶
| Repository | Role in the system family | Public entry point |
|---|---|---|
bijux-core |
execution and governance backbone | CLI, DAG, evidence, and release surfaces |
bijux-canon |
knowledge-system stack | ingest, indexing, reasoning, orchestration, and controlled runtime behavior |
bijux-atlas |
data and service delivery surface | APIs, datasets, reporting, and docs-aware operations |
bijux-proteomics |
scientific product system | proteomics-oriented packages and runtime surfaces |
bijux-pollenomics |
evidence mapping product system | Nordic atlas outputs, tracked data, and report publication |
bijux-masterclass |
public learning surface | course books and long-form technical programs |
bijux-std |
shared standards layer | shared docs shell, shared checks, and shared make modules |