How RO Atlas and Carpathian Atlas turn research into interactive experiences

At ICI Innolabs, RO Atlas and Carpathian Atlas explore a practical question: how far can an autonomous agent take a research and implementation task when a human sets the objective and the result must remain inspectable?

RO Atlas applies that question to Romania’s built heritage, combining documented places, reference photographs and interactive 3D models. Carpathian Atlas continues the experiment through wildlife research, species dossiers, illustrated galleries and maps of reported distributions. Their RO Atlas project account and Carpathian Atlas project account explain the workflows and the boundaries of their results.

In both experiments, agentic development describes how the project is researched, built and reviewed. The public atlas is the resulting application.

Together, they show how the subject changes the engineering. An architectural model needs checks on shape, proportions and rendering. A wildlife atlas needs checks on taxonomy, geographic scope, reporting periods and what a mapped area actually means.

RO Atlas from photographic references to 100 heritage models

RO Atlas currently brings together 100 heritage landmarks, 2,524 reference photographs and 100 GLB models, with a combined GLB footprint of 56.01 MiB. That last figure measures exported files on disk; decoded geometry and textures have their own memory costs.

The pipeline begins with a structured reference package for each landmark: identifying information, coordinates, image provenance, descriptions and observations tied to particular photographs. Multiple views help establish the arrangement of buildings, roof shapes, towers and characteristic details. Where the photographs leave a gap, the model’s assumptions document the inferred geometry.

The agent then builds the exterior in Blender, using Python scripts to generate geometry and materials. The deliverables include an editable Blender scene, a generation script, a GLB export, control renders and documented assumptions. Keeping those artifacts together lets a reviewer inspect how the model was constructed and return to the source scene when a correction is needed.

The models are photographic interpretations of exteriors. Where measurements are unavailable, scale is conventional and unseen areas are inferred. Those assumptions set the limits of the models’ accuracy.

The modelling instructions put recognisable geometry and physical coherence ahead of file size and decorative detail. A tower’s position or a roof’s silhouette matters more than adding polygons to a generic building. They also require a coherent historical reference state, so photographs taken before and after restoration do not automatically produce a building that never existed.

Parallel production needs a shared contract

After the initial Bran Castle example, the coordinator distributed distinct batches of landmarks to other agents. The documented expansion used six conversations for landmarks 02–30 and four for 31–100, in separate stages. Those figures describe the organisation of the work; they do not mean ten agents were active simultaneously.

The shared deliverable contract made the batches integrable. Each agent produced the same kinds of files and declared its assumptions, while the coordinator connected the exports to the catalogue and reviewed the combined gallery. Parallelism increased the amount of work that could proceed independently, but the atlas still needed a common integration and verification step.

The browser is part of model validation

SvelteKit provides the web interface, and Three.js loads the GLB assets through GLTFLoader and DRACOLoader. The Draco decoder is bundled with the application. The viewer loads its graphics modules when needed and provides orbiting, zooming and changes of perspective.

Draco reduces the bytes needed to transfer geometry. Reducing rendered triangle counts still requires decisions about the mesh itself. RO Atlas therefore combines compression with selective simplification, reusable materials and checks on the decoded export. A compact file must still preserve the landmark’s identity.

A useful example came from the Palace of Parliament. In the real gallery, thin roof surfaces showed depth fighting: nearby surfaces competed in the depth buffer. The camera’s near plane was changed from radius / 1000 to radius / 100, improving depth precision while preserving the framing. The verification account records the correction.

The 1 October 2026 validation report records 200 successful desktop and mobile scenarios across the 100 models. These exercised loading and exploration at desktop and emulated mobile sizes. The result applies to those tested versions and scenarios; mobile emulation does not establish performance on every physical phone.

Carpathian Atlas from species research to geographic evidence

Carpathian Atlas shifts the centre of the experiment towards evidence research. Its current collection covers 36 selected species from the Romanian Carpathians. Each dossier connects species identity and ecology with distribution findings, sources and unresolved questions. The collection is a selection, rather than a complete inventory of the region’s fauna.

This changes what the agent must preserve. A species name needs to match the taxon used by the source. A distribution claim needs a place, a reporting period and an explanation of its resolution. A field study’s survey boundary cannot automatically become the species’ entire range.

An illustrated gallery with a separate evidence layer

The public experience uses SvelteKit, Svelte 5 and TypeScript, with prerendered species URLs. Each animal has five illustrated views: portrait, full body, habitat, behaviour and detail. Across the collection, 180 source images become 540 responsive WebP assets at 160, 640 and 1254 pixels.

The gallery prepares neighbouring frames as people browse, while the rest of the collection loads on demand. Keyboard navigation, touch swiping, an expanded image view and support for reduced motion make the experience usable beyond a desktop pointer.

The gallery’s images are explicitly identified as AI-generated illustrations. Scientific and geographic claims come from the linked research and reporting datasets. The current public interface centres on galleries and range maps; the original Three.js lynx specimen remains in the project as a separate development artifact.

Packaging reported distributions without inventing coverage

The range atlas uses MapLibre GL JS and locally packaged GeoJSON. Its mapped collection draws on two European Environment Agency reporting services:

• 16 non-bird taxa use Romanian Habitats Directive Article 17 reported distributions for 2019–2024.
• Seven bird species use Romanian Birds Directive Article 12 reporting, specifically breeding distributions for 2013–2018.

That gives 23 species with verified public polygon data. Twelve others have research entries without verified comparable public national geometry, and the Apollo butterfly is identified separately through historical evidence.

The preparation script checks the source country, public sensitivity flags, species codes, geometry types and the meaning of bird records before packaging them. Taxonomic mappings handle source names such as Triturus montandoni and Bonasa bonasia, corresponding to the catalogue’s Carpathian newt and hazel grouse names. Each mapped entry retains its source, reporting period, resolution and source taxon.

The original reporting uses 10 × 10 km grids, displayed as dissolved outlines. The default map camera frames the Romanian Carpathians, while the source polygons retain their Romanian national extent. Moving the camera to a mountain region does not change the geographic scope of the underlying dataset.

Those choices affect interpretation. A reported grid cell does not establish occupation at every point inside it. A species without verified geometry has an evidence gap, which cannot be converted into a claim of absence. Breeding distributions and distributions from different reporting periods must keep their labels when compared.

Comparison and loading follow the data model

The map supports overlaid distributions and a swipe comparison. A lynx and wolf comparison can be reopened through a shared URL. The URL preserves species selection and display mode; camera and divider positions remain session controls.

The selection logic accepts comparisons only when both species have mapped evidence, preventing an unmapped entry from becoming an empty but apparently meaningful comparison layer.

Map components and the renderer load after the range view is opened. Country boundaries and distribution polygons are hosted locally, while hillshade uses external Mapterhorn elevation tiles. The application accounts for terrain-service failure with an explanation while keeping local distribution layers available. Automated checks cover evidence records, polygon provenance, taxonomic mappings, coordinates and shared URL selection; browser checks exercise the interactive map and its failure states.

Comparing the two implementations

Dimension	RO Atlas	Carpathian Atlas
Research subject	Romanian built heritage	Selected Romanian Carpathian wildlife
Current collection	100 landmarks and 100 3D models	36 species dossiers and 23 mapped species
Principal evidence	Reference photographs, metadata and architectural observations	Scientific reading, monitoring reports and public reporting datasets
Artifact pipeline	Blender Python → editable scenes → Draco-compressed GLB	Species records and image preparation → responsive WebP and verified GeoJSON
Interactive rendering	Three.js model exploration	Illustrated galleries and MapLibre distribution comparison
Web delivery	SvelteKit application served through Node	SvelteKit with prerendered static species pages
Main verification concern	Silhouette, proportions, geometric coherence and browser behaviour	Taxonomy, provenance, reporting scope and map interpretation
Important boundary	Photographic exterior interpretations with documented inferred areas	Reported distributions with dates, resolution and explicit evidence gaps

The strongest connection is the use of intermediate artifacts. In RO Atlas, photographs and observations lead to scripts, scenes and renders before becoming a public model. In Carpathian Atlas, research findings lead to dossiers and evidence records before becoming a public map. Each stage leaves something that the next stage—and a reviewer—can inspect.

The most consequential difference is how each project handles incomplete information. RO Atlas may complete an unseen surface through a documented architectural assumption. Carpathian Atlas leaves a distribution layer unavailable when comparable geometry has not been verified. The appropriate response depends on the claim the artifact will make.

What these experiments teach about agentic development

Both projects describe autonomy within a human-defined objective. Their documentation shows planning, execution and review, but does not measure every human intervention or establish that generated results are automatically correct.

The engineering lesson is practical: make research outputs usable by the implementation, preserve the assumptions that travel with them, and test the experience in which people will encounter the result. An exported model can reveal a rendering defect only after it reaches the browser. A technically valid polygon can mislead if its reporting period or resolution disappears from the interface.

RO Atlas offers an inspectable route from photographic references to explorable heritage. Carpathian Atlas carries that approach into a domain where preserving the meaning of evidence shapes the data model and the user experience.

Explore RO Atlas and its documented workflow, then visit Carpathian Atlas and its research and implementation account.