Preparing the atlas
Atlas of Technological Capabilities
Loading the explorer surface, methods, and access views.
Opening the atlas.
Loading the explorer surface, methods, and access views.
The atlas is capabilities-led, but it stays interpretable: the public release keeps the underlying score logic, coverage context, and relatedness surfaces visible rather than hiding them behind a headline term.
For now, the capabilities score is intentionally simple: patent-family scale multiplied by complexity, with green, digital, AI, and twin-transition measures still exposed separately, and relatedness and knowledge-flow views kept in the same explorer.
The current public release derives a simple capability score from patent-family scale multiplied by the corresponding complexity score, so scale and sophistication stay linked in one headline measure.
The atlas still keeps the underlying dimensions visible: overall complexity, green, digital, AI, and twin-transition measures remain available alongside the aggregate capability view.
Network and knowledge-flow views are read as companion surfaces rather than separate products, so users can move from place capability to relatedness without changing interface logic.
Methods, access, legal terms, and DGMPD export routes stay attached to the atlas workflow instead of living in disconnected pages.
The public release uses a pragmatic capability score so the explorer can lead with a single headline measure. That score is currently derived from patent-family scale multiplied by the corresponding complexity score.
The important design choice is not the exact formula. It is that the headline measure stays attached to the underlying dimensions, so users can always inspect complexity, green, digital, AI, and twin structure directly.
The explorer now includes a flow surface that reads directional spillovers between visible places using the same capability context, colour logic, and place-selection behaviour as the rest of the atlas.
That keeps map exploration, relatedness, and flow interpretation inside one coherent interface rather than pushing users into separate products or unexplained side pages.
The atlas methods page now sits alongside coverage, access, and legal routes, so interpretability is part of the public product rather than something users have to request separately.
DGMPD then takes over when users need export-grade delivery, leaving the public atlas narrow while keeping methods and governance connected across the wider Ibsen Labs stack.
CSV, JSON, Parquet, and spatial delivery belong in DGMPD, where the export constructor can keep plan controls, geography choices, methods, and row limits explicit.
That leaves the capabilities atlas focused on interpretation and navigation, while still making it clear where governed, production-style delivery starts.