Bijux Pollenomics

bijux-pollenomics is a checked-in Nordic evidence workspace. The repository collects source-backed records, normalizes them into tracked files, and publishes those files as country bundles plus one shared atlas that readers can inspect directly.

Right now the honest description is atlas-builder first. This repository publishes a reproducible evidence surface and can now emit heuristic candidate site outputs from that surface, but it is not yet the broader pollenomics analysis engine that combines aDNA, eDNA, pollen, and archaeological context in one scientific workflow.

The atlas is the fastest honest route into the repository. It shows what is actually published today: AADR sample points, LandClim pollen sequences and REVEALS grid cells, Neotoma pollen sites, SEAD sites, Swedish archaeology density from RAÄ, fieldwork media, and Nordic country boundaries.

Start with the atlas, then check the supporting surface that owns the next answer. The runtime handbook explains how the repository rebuilds outputs, the data handbook explains where layers come from, the fieldwork pages tie one mapped point to a real visit, and the maintainer handbook covers repository-health rules.

Open the Nordic Evidence Atlas Open the package handbook Open the engine roadmap Open the data reference Open the maintainer handbook

Phone view: Open the atlas in its own tab for panning, layer toggles, and map controls. The inline embed stays available on larger screens where the full layer stack fits.

Open the Nordic Evidence Atlas

Evidence Flow

flowchart TB
    sources["upstream evidence families"]
    runtime["runtime collect and normalize loop"]
    tree["tracked data tree"]
    reports["country report bundles"]
    atlas["nordic evidence atlas"]
    fieldwork["lyngsjon visit media"]
    maintainers["repository health checks"]
    reader["reader asks what is supportable"]

    sources --> runtime
    runtime --> tree
    tree --> reports
    tree --> atlas
    fieldwork --> atlas
    maintainers --> runtime
    reports --> reader
    atlas --> reader

Read the site as a chain of evidence, not as a table of contents. A visible map layer starts in an upstream family, becomes reviewable only after it lands in the tracked data tree, and becomes public through a report or atlas bundle. The fieldwork media is intentionally narrow: it gives one mapped point a direct visit record without pretending to cover the whole Nordic evidence landscape.

The landing page should make one thing immediately clear: visible atlas layers, country reports, and tracked files are different proof surfaces in one chain. If that chain feels decorative instead of operational, readers will assume the site is presentation first and evidence second.

Start Here

Open the route that matches the real question:

• visible map, layer, point, or polygon: open the Nordic Evidence Atlas
• runtime commands, rebuild logic, package boundaries, or tests: open bijux-pollenomics
• source provenance, normalized file families, or publication bundles: open bijux-pollenomics-data
• release, docs, CI, or shared command routing: open bijux-pollenomics-maintain

Fieldwork Record

The repository also carries checked-in field media from the Lyngsjön Lake sampling visit on 2026-02-26. That material anchors one atlas point to a real collection day on the lake ice rather than to a database row alone.

Open the fieldwork page Open the field video

Lyngsjön Lake, southwest of Kristianstad, during winter field collection on 2026-02-26.

What This Repository Publishes

• one shared Nordic atlas under docs/report/nordic-atlas/
• one checked-in country report bundle for each published country under docs/report/
• tracked normalized evidence files under data/
• one runtime package that rebuilds those outputs from stable commands
• one narrow fieldwork record that ties a mapped point to a real visit

What Comes Next

The next repository step is not to make the atlas prettier. It is to make the evidence loop stronger: candidate ranking must stay traceable to tracked layers, multi-evidence workflows must remain explicit about provenance, and the future pollenomics engine must grow from this checked-in evidence base rather than bypass it.

What This Repository Does Not Claim

• that map proximity alone establishes scientific weight
• that every visible layer has identical provenance quality
• that mutable upstream services will always replay identically
• that one field visit stands in for regional evidence coverage

Package Handbooks

• bijux-pollenomics
• bijux-pollenomics-data
• bijux-pollenomics-maintain

First Proof Check

• docs/report/nordic-atlas/nordic-atlas_map.html for the visible publication surface most readers will inspect first
• data/ for the tracked normalized evidence tree that feeds the atlas
• packages/bijux-pollenomics/src/bijux_pollenomics/ for the runtime code that collects, normalizes, and publishes
• packages/bijux-pollenomics-dev/src/bijux_pollenomics_dev/ and makes/ for the repository-health surfaces that protect release, docs, and verification

Boundary Test

If a claim about the atlas cannot be backed by tracked source provenance, runtime contracts, checked-in outputs, or maintainer proof, this site should state that limit directly instead of implying certainty it does not have.