← All EDITUA outputs
EKA
Eesti Kunstiakadeemia
Workshop Report
Internal — for project records
EDITUA Consortium · Workshop №3 · Poznań

Alignment
in Poznań.

A report on the third consortium workshop of EDITUA – an innovative interactive incubator of socio-spatial change fostering green urban regeneration, employing AI in gain of the public democracy. Held over three days at Poznań University of Technology to break a methodological deadlock and align all four partners.

Dates
4–6 March 2026
Three working days
Location
Poznań University of Technology
Faculty of Architecture, Poznań, PL
Attendance
13 participants
All four partners represented
Document
Ref. EKA/EDITUA/WS3-2026
Submitted by EKA team
01
Kokkuvõte

Workshop Summary

Over three days in Poznań, the four EDITUA partners worked through fundamental disagreements about what the project is actually building — and emerged with a shared glossary, six locked decisions, an aligned roadmap, and ten binding working rules for the remaining 21 months.
Partners present
🇵🇱
Poznań University of Technology
Coordinator
4 attendees · HOST
🇸🇮
University of Ljubljana
Theory & comparative research
3 attendees
🇬🇷
University of Thessaly
Pilots & heritage
3 attendees
🇪🇪
Estonian Academy of Arts
Digital tool & ecology
3 attendees

Headline outcomes

8
glossary terms
with binding definitions agreed by all partners
6
key decisions
previously contested questions now locked
10
working rules
adopted as consortium agreement
7
next actions
with named owners and deadlines
"We came to Poznań agreeing on the destination but disagreeing on the route. We left agreeing on both — and on how to handle the next disagreement when it arises."
02
Konteksti

Why We Met

Twelve months into EDITUA, the consortium had reached a productive deadlock. Four partners across five countries — spanning architecture, urban planning, digital design, ecology, participatory governance, and heritage studies — were each working hard, but not necessarily in the same direction. The Poznań workshop was called to surface and resolve five recurring problems.

01

Same words, different meanings

When partners said 'tool,' the Estonian team heard 'software.' Ljubljana heard 'methodology.' Thessaly heard 'participatory process.' Poznań heard 'all of the above.' Nobody was wrong, but nobody was building the same thing.

02

Unclear hierarchy of deliverables

The project promises a digital tool, a theoretical model, three pilots, a handbook, and policy recommendations. Without a clear dependency chain, each partner was optimising for their own deliverable in isolation.

03

Theory vs. practice tension

Some partners wanted to complete the theoretical framework before any tool development. Others wanted to start coding and iterate. Both approaches are valid, but the project cannot afford to oscillate between them.

04

Context mismatch across pilot sites

What works in a dense Poznań courtyard does not translate directly to Tallinn's post-Soviet housing blocks or Volos's Mediterranean mixed-use fabric. Each site team reported feeling that the framework didn't quite fit their reality.

05

The politeness trap

In transnational consortia, partners often avoid direct disagreement out of courtesy. Fundamental misalignments had been papered over with vague consensus language ('we all agree it should be participatory') that hid real divergence on what that meant in practice.

Workshop premise
The disagreements that had been quietly accumulating were not problems to be papered over — they were the actual work. The workshop's structure forced each partner to state their assumptions explicitly and resolve them in the room.
03
Ühine keel

Shared Glossary

The first day was devoted to establishing precise, agreed meanings for eight terms that had been causing repeated misunderstanding. Each definition was contested, debated, and ratified by all four partners. The glossary is now binding for all consortium communications.

"EcoUrban Composer"
Does not mean
A finished software product we ship to cities
In EDITUA, means
An evolving, open-source digital platform combining simulation (what-if scenarios) and evaluation (real measurement) in a game-like interface that residents can actually use
"Indicator"
Does not mean
A checkbox or yes/no compliance item
In EDITUA, means
A measurable variable with a defined formula, data source, unit, and scoring threshold (0–5) that tracks environmental change over time
"Community-led"
Does not mean
We consult residents and then experts decide
In EDITUA, means
Residents have real decision-making power: they co-design interventions, can audit 60% of indicators themselves, and their verification carries the same weight as professional assessment
"Pilot"
Does not mean
A demonstration project we showcase at the end
In EDITUA, means
An iterative test site where the tool and methodology are developed, broken, fixed, and validated through real use — the learning matters more than the showcase
"Intervention"
Does not mean
A large construction project
In EDITUA, means
Any deliberate change to urban space, from planting a hedge (50 m²) to depaving a courtyard (500 m²) to redesigning a street block (5,000 m²) — the framework must work at all these scales
"Handbook"
Does not mean
An academic publication at the end of the project
In EDITUA, means
A living, practical guide with templates, metrics, and replicable protocols that a municipality or community group could pick up and use without any EDITUA partner present
"Evaluation"
Does not mean
Judging whether the project succeeded or failed
In EDITUA, means
Continuous measurement against baseline to track improvement — even small gains count, and honest data about what didn't work is as valuable as success stories
"Anti-greenwashing"
Does not mean
We criticise LEED / BREEAM in our publications
In EDITUA, means
We build structural safeguards: open scoring, community verification, self-report caps at 3/5, and free access — so the system cannot be captured by commercial interests
04
Otsused

Decisions Reached

Six previously contested questions were brought to a decision. For each, the workshop considered the principal alternatives and landed on a position by partner consensus. The chosen option for each is marked, with a brief note explaining the rationale.

Decision 01

Who is the primary user of the EcoUrban Composer?

Residents / community groups
Municipal planners
✓ AGREEDBoth equally — layered interface
Researchers
Rationale: The tool will use a layered interface architecture: a public-facing layer for residents (simplified, game-like) and a planner layer with deeper data access. Both layers draw on the same indicator set.
Decision 02

What does 'success' look like at the end of the project (Dec 2027)?

Working tool + 3 documented pilots
✓ AGREEDValidated methodology
Policy impact in one municipality
Community empowerment
Rationale: Primary success metric is methodological — a proven indicator framework others can replicate. The tool and pilots are vehicles for this validation, not ends in themselves. Policy adoption is a stretch goal.
Decision 03

How sophisticated should the digital tool be by project end?

✓ AGREEDFunctional prototype
Production-ready platform
Research instrument
Game-like MVP
Rationale: Scope locked to functional prototype with strong UX. Production-grade hardening explicitly deferred to a possible follow-on project. Prevents scope creep and keeps EKA's development team focused.
Decision 04

Which partner leads indicator development?

PUT (coordinator)
✓ AGREEDCo-developed by all partners
UL (theory lead)
EKA (tool lead)
Rationale: Each partner proposes indicators for their domain (ecology — EKA; participatory — UTH; theory — UL; cross-cutting — PUT). All indicators reviewed in joint workshops. EKA leads the ecological cluster (8 of 25 indicators).
Decision 05

What if a pilot site cannot collect data for certain indicators?

Indicator marked N/A
Simplified low-data proxy version
All indicators mandatory
✓ AGREEDCore + optional split
Rationale: Framework split into 15 mandatory core indicators (applicable everywhere) and 10 context-specific optional indicators. Sites can choose which optionals fit their context, ensuring comparability without forcing artificial uniformity.
Decision 06

How do we handle language and disciplinary barriers in consortium work?

Shared glossary
Visual prototypes over text
Monthly alignment checks
✓ AGREEDAll of the above
Rationale: All three mechanisms adopted in parallel. The glossary in Section 03 is the binding reference. Two-week integration cycles formalised. Visual artefacts mandatory in every meeting.
05
Ajakava

Roadmap, Aligned

The decisions above translate into a six-phase roadmap, with deliverables now mapped to partner ownership. The consortium is currently in the Build & Test phase.

Q1–Q2 2025
Foundation
Theoretical framework drafted, indicator library v1, pilot site selection, community mapping across all three sites
Done
Q3–Q4 2025
Design
Tool architecture finalised, indicator validation workshop, baseline environmental data collection begins at all pilot sites
Done
Q1–Q2 2026
Build & Test
EcoUrban Composer alpha release, first pilot interventions, community auditor training programme launched
Now
Q3–Q4 2026
Iterate
Tool beta with real-world data, cross-site comparative analysis v1, indicator refinement based on pilot learnings
Planned
Q1–Q2 2027
Scale
Full pilots operational, handbook drafting begins, structured policy dialogues with municipalities
Planned
Q3–Q4 2027
Deliver
Comparative study published, final handbook released, tool v1.0 launch, policy recommendations submitted to participating municipalities
Planned

Who owns what

PUT 🇵🇱
Indicator framework, Polish pilot, overall coordination, comparative analysis, handbook editing
UL 🇸🇮
Theoretical EDITUA model, comparative research framework, cross-site analysis methodology
UTH 🇬🇷
Greek pilot (Volos / Larisa), participatory methods, heritage integration, Mediterranean context adaptation
EKA 🇪🇪
EcoUrban Composer development, ecological guidance, Estonian pilot (Tallinn), UX / UI design, data architecture
06
Töökord

Consortium Working Rules

On the final day, the consortium adopted ten working rules as a binding agreement for the remainder of the project. These rules were drafted collaboratively to address the failure modes identified on day one.

01

Show, don't describe

Every meeting must include a visual artefact — a mock-up, diagram, map, prototype screen, or sample data. Abstract discussion without something to point at is no longer permitted.

02

Name your assumption

Before any debate, each partner states: 'I am assuming that X means Y.' If assumptions differ, that is the discussion. Not 'who is right,' but 'which assumption better serves the project goals.'

03

The coordinator decides ties

If consensus cannot be reached within 15 minutes, PUT as coordinator makes the call. Partners may register dissent, but work proceeds. Decisions are revisited at the next milestone.

04

Two-week integration cycles

Every two weeks, each partner shares what they have built, written, or designed. The integration question is: 'Does this connect to what the other partners built?' If not, adjustments are made before the next cycle.

05

Prototype over proposal

A working prototype that is 60% right beats a proposal document that is 100% theoretical. Build the simplest version, test it with a real user, then improve.

06

The glossary is binding

The shared glossary (Section 03) is a binding reference. If a term is causing confusion and is not in the glossary, it is added immediately. Every partner commits to using these definitions in all communications.

07

One pilot leads, others follow

Poznań goes first on most things — tool testing, indicator validation, community auditor training. Tallinn and Volos learn from Poznań's mistakes rather than starting from scratch. Adaptation, not reinvention.

08

Monthly alignment temperature check

Five-minute survey at the end of each monthly meeting: 'On a scale of 1–5, how aligned do you feel with the overall project direction?' If average drops below 3, normal work stops and a realignment session is convened.

09

Deliverables have owners, not committees

Every deliverable has exactly one partner who owns it. Others contribute, review, and provide input — but one partner is responsible for quality, deadline, and integration.

10

Celebrate small wins publicly

Every meeting starts with three minutes of 'what worked since last time.' This builds momentum and trust, and reminds everyone that progress is happening even when it feels stuck.

07
Järgmised sammud

Next Steps

Seven action items with named owners and dated deadlines. Progress will be reviewed at the next bi-weekly integration call on 18 March 2026.

Owner
Action
Deadline
PUT
Circulate workshop minutes and signed working agreement
21 March 2026
EKA
Deliver EcoUrban Composer alpha build for internal partner testing
30 April 2026
All partners
Submit ecological indicator proposals (3 per partner) to shared repository
15 April 2026
UTH
Volos pilot site MoU signed with municipality
31 May 2026
UL
Theoretical framework v2 draft circulated for partner review
30 May 2026
EKA
Tallinn community auditor recruitment opens (target: 12 auditors)
15 May 2026
All partners
Next consortium workshop hosted by EKA in Tallinn
16–18 September 2026
Closing note from the EKA delegation

Poznań delivered exactly what the project needed: not more meetings, but forced alignment. The shared glossary, locked decisions, and working rules are now reference documents we expect to consult for the remaining 21 months.

The next workshop will be hosted by EKA in Tallinn (16–18 September 2026), co-located with the Tallinn pilot site visit in Kalamaja. Preparation begins immediately.