---
id: ch5-ecosystem
type: spine
title: "The PoliRural+ platform: a modular Beta, not one app"
readingTime: 3
standalone: true
core: true
teaser: "Eleven components, each with its own maturity: what the PoliRural+ Beta platform contains, and what holds it together."
voice: universal
parent: null
diagram: diagram-tool-ecosystem
recallQ: "Why is the PoliRural+ platform built as separate components rather than one application, and what connects them?"
recallA: "Because authorities, advisors and developers usually need selected functions, not a full stack. The components connect through APIs, standardised metadata profiles and MCP-based integration, and metadata managed by Raven is what holds them together."
highlights:
  - "D4.2 describes eleven components, and each has its own Beta status"
  - "Raven's metadata decides which data and tools JackDaw can use"
  - "Each pilot picks the services it needs in five onboarding steps"
  - "Before the final release the priority is consolidation and a documented TRL per tool, not new features"
status: accepted
concept: tool-ecosystem
conceptTitle: "The PoliRural+ tool ecosystem"
lang: en
lens: generic
depth: standard
formalism: none
visuality: balanced
lengthBand: standard
genre: explainer
state: core
carriers: prose|table|diagram
---

Deliverable D4.2 (*PoliRuralPlus Platform Beta*) describes the platform as **a set of interoperable components** that can be combined for different users, pilots and themes, not as one monolithic application. The reason it gives is practical: public authorities, advisors and external developers usually need a few selected functions, not a full deployment.

## What the Beta contains

| Component | What it does | Status in D4.2 |
|---|---|---|
| **Hub4Everybody** | The front door: documents, publications, service links. Its library feeds JackDaw's retrieval layer | In operational use; growth is mainly in content |
| **Raven** | Ingests data and metadata, selects datasets and sets up tools on top of them | Central module; to be consolidated |
| **JackDaw** | GeoAI layer that turns plain-language questions into spatial queries ([details](#c/jackdaw)) | Tested in pilots; a consolidation priority |
| **Magpie** | Natural-language search over metadata catalogues | Largely stable; its function now runs inside Raven |
| **Vulture** | Sandbox for AI productivity experiments | Less central than expected; selective maintenance |
| **Boxes & Arrows Agent Builder** | Visual builder for multi-step agents inside JackDaw | New module in the Beta |
| **Advisor and RAG services** | Answers grounded in the project's own corpus | Runs as a private RAG; a Knowledge Graph link is planned |
| **MapWhiteboard** | Shared map with live cursors and features | Simplified instance developed and deployed |
| **Multi-Actor Approach tool** | Stakeholders, objectives and inputs per pilot | Configured; 300+ users, 40 work entities |
| **Innovation potential tool** | Attractiveness on a 1×1 km grid, Czech-Bavarian border | Segment analyses still being populated |
| **Atlas of Best Practices** | Repository of transferable practices | Content has grown a lot; links to e-market tools still to be defined |

## How the parts connect

The components communicate through **APIs, standardised metadata profiles and MCP-based integration**, so external tools and agents can attach without hard-wired dependencies. Metadata does the connecting: D4.2 concludes that metadata quality directly affects how reliable JackDaw, the dashboards and the analytical tools are.

Each pilot puts its own bundle together. Onboarding has five steps: name the regional planning challenge, select the Beta services, configure workspaces and user roles, prepare or ingest data and metadata, then test in meetings, workshops and real planning tasks (D4.2 §6.1).

## What the Beta does not yet do

D4.2 is open about the gaps. The components still feel like separate applications. Interfaces are inconsistent. Multilingual and place-name handling needs work. Outputs must show their sources, data validity and limits more clearly. The roadmap to the final release (D4.3, due at the end of the project) is about **consolidation**: tighter integration, continuous testing, training material, demos for model builders, and progress towards higher Technology Readiness Levels, with a clearly documented status for each major tool.

The [MAA tool](#c/maa-tool) comes next, because it shows in numbers what "in pilot use" means.

**How-to:** [Which tool when](#ch5-which-tool-when) · [Using Hub4Everybody](#ch5-guide-hub) · [Finding and publishing data with Magpie and Raven](#ch5-guide-raven-magpie).

**Sources:**
- D4.2 PoliRuralPlus Platform Beta, Executive Summary; §3 Platform components; §6.1 Testing methodology and pilot onboarding; §6.4 Issues, limitations and corrective actions; §11.1 Remaining development priorities; §12 Conclusions. [PDF](https://www.poliruralplus.eu/docs/421/D4.2_PoliRuralPlus_Platform_Beta.pdf)