Skip to content

Guiding questions — Organisational form & governance authority#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Organisational form & governance authority → Guiding questions — © iSHARE Foundation, used under the EUTwinLink Consortium Agreement (see Legal notices). The template's question text is carried over unchanged so this fork stays comparable to its upstream.

Everything between the LDT answer markers is the EUTwinLink instantiation — that is what partners fill in. Decisions already taken live on the block page: Organisational form & governance authority.

Building block G2 · owner(s) iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register) · block status DRAFTED · see the Building-block register.

Answer provenance. Every answer below is tagged with where it comes from, because a governance scheme that cannot be traced is not a governance scheme:

  • Decided — already fixed by the Grant Agreement, the Consortium Agreement or a recorded decision elsewhere in this scheme. Change it only through the change procedure.
  • Proposed — a defensible default, derived from the iSHARE Trust Framework, the DSSC Blueprint and the decisions this scheme has already taken. Drafted for the owner to confirm, correct or reject at TIPS. It is not an agreed position until TIPS approves it.
  • Needs owner — cannot be answered without the named owner: a fact about their systems, their legal position or their commercial intent. The text states what is needed and why.

Open points across the whole scheme are collected in Open questions for partners.

Purpose: The Organisational Form and Governance Authority building block defines the structural foundation and decision-making mechanisms crucial for the effective governance and operation of the data space. Drawing inspiration from established governance models such as the iSHARE Trust Framework and guided by the DSSC Blueprint, it establishes a governance authority that is responsive, transparent, and representative of its participants.

1. Determining the Organisational Form#

Purpose: Clearly define the purpose, structure, and legal characteristics of the data space.

1.1 Permanence & Stability#

  • Should the initiative be established as a permanent entity or as a temporary (multi-year) collaboration?
  • What is the anticipated lifetime and scale of the initiative
  • How should the organisational form balance flexibility and stability?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided For the pilot the LDT is a temporary, multi-year collaboration, not a permanent entity. Its existence, membership and termination follow the EUTwinLink Consortium Agreement; it ends with the project unless a decision is taken to continue it.

Proposed Anticipated lifetime and scale: 11 consortium partners and 4 interconnected twins to M18, with the Hamburg Port supporter as the first interconnection beyond the funded core. Scale beyond that is a function of the post-M18 decision, not of the pilot.

Flexibility and stability are balanced by splitting them: the scheme (this repository) is designed to outlive the pilot and is versioned and changed through a defined procedure, while the organisation carrying it stays deliberately light. That way a change of carrier after M18 does not invalidate the rules.

  • Should the initiative have a distinct legal personality?
  • What are the advantages or constraints of becoming an incorporated entity (e.g., association, foundation, limited liability company)?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided No distinct legal personality during the pilot. The LDT cannot contract in its own name, hold property or bear liability; the consortium partners do, individually, under the Consortium Agreement. iSHARE Foundation holds the scheme as Scheme Owner.

Proposed The constraint this creates is concrete and should be stated in PD4 rather than discovered later: a new participant joining after the pilot cannot sign an agreement with the LDT, only with an existing party. That is workable for a pilot and is the main argument for incorporating later.

Advantages of incorporating after M18: a single counterparty for accession, the ability to hold the registries and the contract for the Marketplace of the EU LDT Toolbox, and continuity independent of any one partner. Constraints: set-up and running cost, a governance body that must be staffed, and the question of who capitalises it — all of which belong to the sustainability case in Business model.

1.3 Profit vs Non-Profit Orientation#

  • Is the initiative designed to generate profit, or is it primarily aimed at non-profit sustainability outcomes?
  • How will generated revenue (if any) be managed and reinvested?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Proposed Two layers, deliberately separated:

  • The scheme layer — trust framework, registries, conformance, governance — is non-profit. It is infrastructure the participants rely on, and charging for trust decisions would compromise the neutrality required of operators (see Intermediaries & operators).
  • The service layer — marketplace, tokenisation, analytics, value-creation services — is openly commercial, operated by Nunsys, LogiNex and others under scheme rules.

Revenue during the pilot is grant funding plus each partner's ≥50% co-financing; no revenue is generated by the scheme itself. Post-pilot, any surplus from scheme-layer fees should be reinvested in running the scheme rather than distributed — but that is a decision for the sustainability case, not a settled position.

Needs owner ERTICO + iSHARE: confirm this split survives contact with the exploitation plan, and say whether any partner intends to commercialise a scheme-layer function.

1.4 Country and Jurisdiction#

  • In which EU country should the initiative be legally established?
  • What regulatory, tax, or operational benefits does this jurisdiction provide?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Proposed If the LDT incorporates, the Netherlands is the obvious candidate: iSHARE Foundation is established in Rotterdam and already operates the Trusted List, certification and the canonical framework, so the scheme's custodian and its legal seat would coincide.

Two facts complicate this and must not be glossed over in PD4:

  • Cartagena (ES) is the Financial Support Recipient towards the funder, so the money and the accountability for the pilot sit in Spain while the scheme custody sits in the Netherlands.
  • Aruba is outside the EU entirely, which makes the jurisdiction question a live operational one rather than a formality — see Regulatory compliance.

Needs owner iSHARE legal, with Cartagena and Almelo: regulatory, tax and operational consequences per candidate jurisdiction. This answer names a likely choice; it does not evaluate alternatives, and nobody has yet done that analysis.

1.5 Level of Participant Involvement#

  • How much direct involvement do the initial consortium members want in the daily governance and operational management?
  • What degree of autonomy should the governance authority have from its founding members?
  • How can participant involvement in governance be maximized without slowing decision-making?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided Involvement is high by design: the TIPS Committee is all-partner and meets monthly, and it is the body that approves this scheme. There is no delegated board taking scheme decisions on the partners' behalf.

Proposed The governance authority's autonomy is correspondingly low during the pilot, and that is the right trade-off while the rules are being written — the people who have to implement the scheme are the people approving it. It becomes the wrong trade-off at scale, when monthly all-partner consensus stops being feasible.

Involvement is kept from slowing decisions by moving the work off the meeting: changes arrive as merge requests with the proposed text, reviewed asynchronously by the WP4 lead, so TIPS decides on prepared items rather than drafting in the room. Items nobody reviewed are deferred, not debated.

1.6 Options for Organisational Form#

Unincorporated data space Incorporated data space
Temporal existence Data space is a temporary establishment, although it may exist for several years. The termination is pre-determined by the founding agreement. Data space is a permanent establishment, its termination is not pre-determined by the founding agreement.
Legal personality Data space is not a legal person. Data space is a legal person, separate from its members.
Ability to enter into contracts Data space cannot conclude contracts with third parties in its own name. Only members can conclude contracts. Data space can conclude contracts in its own name with third parties.
Ownership of property All property is owned and disposed of by members, individually or jointly. Data space owns (intellectual) property and disposes of it.
Liability Members are liable for their actions. Data space cannot bear any liability. Data space bears liability for the actions of its governance bodies.
Complexity of the founding agreement The founding agreement is a highly complex document regulating various aspects of relationships between members. The founding agreement is fairly simple document establishing the data space and regulating only certain monetary relationships between the data space and its members.
Control over the data space Members are in complete control of the data space. Data space is in control of itself through its governance bodies.
Addition of new members The process requires consent of all existing members and re-negotiation of the founding agreement. The process varies depending on the legal form, but usually does not require re-negotiation of the founding agreement.

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided Against the template's table, the LDT today sits squarely in the unincorporated column on every row: temporary existence pre-determined by the founding agreement, no legal personality, no contracts in its own name, property owned by the members, liability borne by members, a complex founding agreement (the Consortium Agreement), members in complete control, and new members requiring the consent of existing ones.

Proposed The last row is the one that will bite first. Admitting a participant after the pilot — the Hamburg Port supporter is the near-term case — currently requires the consent of all consortium members and, strictly read, a re-negotiation of the founding agreement. The accession agreement in the Contractual framework is designed to absorb this, by binding a newcomer to the scheme without making them a party to the Consortium Agreement. PD4 should state that mechanism explicitly, because it is what makes an unincorporated data space workable beyond its founding members.

2. Establishing the Governance Authority#

Define the roles, structure, and operation of the governance authority clearly.

2.1 Governance Bodies#

  • What governance bodies are necessary (e.g., Council of Participants, Supervisory Board, Change Advisory Board)?
  • How will these bodies be structured, and what are their specific roles?
  • Which processes ensure continuous improvement of governance structures?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided Three bodies, none of them new:

  • TIPS Committee — Trust, Interoperability, Privacy & Security. Monthly, all partners. Approves this scheme and every change to it.
  • Steering Committee — handles escalations under the Consortium Agreement.
  • iSHARE Foundation as Scheme Owner — custodian of the framework, WP4 lead, and the only party performing Trusted List and certification functions.

Proposed The template asks after a Change Advisory Board. The LDT does not create one: TIPS acts as the Change Advisory Group, because at 11 partners a separate advisory layer would duplicate the same people. This should be revisited if participation grows beyond the consortium — the reason to split the roles is volume, and the volume is not there yet.

Continuous improvement of the structures themselves runs through the change procedure in Co-creation & change management, which is reviewed at the TIPS following each implemented change.

2.2 Decision-making Processes#

  • How will decisions be taken within governance bodies (consensus, majority voting, etc.)?
  • How will transparency and accountability in decision-making be ensured?
  • How can rules and procedures remain transparent and accessible to participants?
  • How can governance updates be effectively communicated and enforced?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Proposed Consensus-seeking, with a fallback. TIPS decides by consensus of the partners present; where consensus fails, the chair records the dissent and the item escalates to the Steering Committee rather than being carried by a narrow majority. A governance rule adopted over a partner's objection is a rule that partner will not implement, so forcing it through buys nothing.

Transparency and accountability are structural rather than promised: every scheme change exists as a merge request with the proposed text, a named author and a review trail, and the approved result is a versioned page in this repository. The minutes say what was decided; the repository shows what it changed. Where those disagree, the repository is authoritative.

Rules stay accessible because the scheme is the published site (GitLab Pages) rather than a document circulated by mail. Updates are communicated at TIPS and visible as a diff; they are enforced through the mechanisms the scheme itself defines — credential, registry entry or ODRL policy — not through reminders.

Decided It is recorded, in the signed Consortium Agreement, section 6.2.3 — this page simply had not carried it across. Quorum: a Consortium Body cannot decide unless two-thirds of its members are present or represented; if quorum fails twice, the next extraordinary meeting decides regardless. Votes: every member present or represented has one vote, and decisions carry on a two-thirds majority of votes cast; a party declared a Defaulting Party may not vote. Chair: the Coordinator chairs both the General Assembly and the Steering Committee, unless the General Assembly decides otherwise. A member whose work, costs, liabilities or IP would be severely affected may veto the decision, except on its own breach, its own default, or its own withdrawal. Notice is 45 calendar days for an ordinary General Assembly and 15 for an extraordinary one. (Source: LDT4SSC–EUTwinLink pilot Consortium Agreement, signed by all eleven parties.)

2.3 Operational Management#

  • Who is responsible for the day-to-day management and operational activities?
  • What reporting or accountability mechanisms are required for operational oversight?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided Day-to-day management of the scheme is the WP4 lead, iSHARE Foundation. Day-to-day operation of the infrastructure is distributed and already assigned: iSHARE Foundation (Satellite and iSHARE Participant Registry, as part of its standing scheme operations), iLabs (ITB-S conformance lab, development sandbox, reference trust gateway, and trust-registry interconnection with Ayra Association as subcontractor), Nunsys (Marketplace of the EU LDT Toolbox), the accredited issuers for their own credential types, and each site owner for its own twin. The separation of governance from operations is a principle of the scheme, not an accident of staffing — TIPS governs, operators operate, and no party does both for the same function.

Proposed Reporting: operators report to TIPS monthly on availability, onboarding throughput and incidents, drawing on the trust signals defined in Provenance, traceability & observability rather than on separately-written status reports. The reporting obligation itself belongs in the service agreements, not here.

Needs owner iLabs and Nunsys: confirm what you can actually report monthly, and at what granularity. The specification above assumes capability nobody has confirmed.

2.4 Dispute Resolution & Compliance#

  • How will conflicts between participants be addressed and resolved?
  • Who ensures compliance with internal and external regulations (GDPR, CSRD, EPBD, etc.)?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided Conflicts follow the Consortium Agreement ladder: amicable resolution first, then the Steering Committee, then the jurisdiction named in the CA. The scheme does not create a parallel dispute mechanism, and the Contractual framework routes accession-agreement disputes into the same ladder so that participants who are not CA parties still have a defined path.

Proposed Compliance responsibility is split along the line the scheme can actually enforce. The participant is responsible for complying with the law applicable to its own data and processing — the scheme cannot assess a municipality's administrative law position for it. The scheme is responsible for not making compliance impossible: the baseline policies, credential requirements and audit trail exist so a participant can demonstrate compliance. GDPR specifics are handled in PD1 and cross-referenced, not restated.

Needs owner iSHARE legal: the template names CSRD and EPBD. Neither appears in this scheme's framework table. Confirm whether they apply to the LDT — EPBD plausibly does via the Aadorp PED — or strike them.

2.5 Continuous Improvement and Adaptation#

  • How will the governance authority adapt to changing requirements or scaling of the data space
  • What procedures are in place for updating governance structures or policies?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided Scheme changes are proposed as merge requests, discussed and minuted at TIPS, and approved there. That procedure is already in force for this repository.

Proposed From PD4 v1.0 onwards the fuller seven-step change process applies — identify, propose, plan, analyse impact, decide, implement, assess — as set out in Co-creation & change management. The step that matters most is analyse impact: a change to one block routinely moves a credential, a policy or a contract clause elsewhere, which is why TIPS reviews rather than the block owner alone.

Adaptation to upstream change is mechanised rather than left to vigilance. tools/sync_template_questions.py and tools/check_parity.py detect drift against the iSHARE Data Space Template and report it in CI, so an iSHARE release becomes a visible agenda item instead of surfacing years later. See Alignment with the iSHARE Trust Framework.

Scaling is the known weak point: the procedure above assumes a monthly all-partner meeting and does not survive a membership of fifty. Revisiting it is part of the post-M18 decision, not of PD4.

3. Creation of the Governance Framework#

Define internal rules, policies, and guidelines that govern participant interactions within the data space.

3.1 Founding Agreements#

  • What fundamental agreements underpin the governance structure?
  • How detailed are founding agreements regarding roles, responsibilities, liabilities, and rights?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided Three instruments underpin the structure, in this order of precedence:

  1. LDT4SSC Pilot Grant Agreement (Cartagena ↔ the third-party grant body) — the funding relationship and the deliverable obligations, including PD4 acceptance as a payment condition.
  2. EUTwinLink Consortium Agreement — the relationship between the 11 partners: roles, background IP (Attachment 1, under which the iSHARE framework is used royalty-free), liability, dispute ladder and termination.
  3. This scheme, once TIPS-approved — the rules of data-space participation, binding through the accession agreement.

Proposed The division of labour to state in PD4: the first two are detailed on liabilities and rights between the funded parties; this scheme is detailed on operating conditions for participation. The gap between them — a participant that is not a consortium partner — is closed by the accession agreement and by nothing else, which is why that document carries more weight than its length suggests.

3.2 Terms and Conditions for Participants#

  • What specific terms must participants agree to for engaging with the data space?
  • How do these terms reflect compliance with EU regulations?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided One signature binds a participant to the whole scheme: the accession agreement, derived from the iSHARE accession model, covering all layers rather than requiring separate signatures per building block. Data-sharing terms attach per offering, composed of a licence from the iSHARE Licence Catalog plus an ODRL policy plus, where genuinely needed, a bilateral annex. Service terms (ITB-S, marketplace, observer/AI services) attach as annex modules.

Proposed How the terms reflect EU regulation: the accession agreement carries the obligations that apply to every participant regardless of role — lawful basis for what they contribute, honouring the policies attached to data they receive, maintaining valid credentials, and accepting the audit trail. Regulation that is role- or data-specific (GDPR for citizen data, DGA for intermediation, AI Act for agent services, non-EU transfer for Aruba) attaches through the annex that covers that activity, so that a participant signs the obligations it actually incurs.

Needs owner iSHARE legal: confirm the accession model can carry this structure, and that the cities can sign it under municipal contracting rules — the open sign-off 🧩 in Contractual framework.

3.3 Internal Policies and Procedures#

  • What internal operational policies and procedures are necessary?
  • How will these policies be created, reviewed, and approved?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Proposed The scheme needs a small set of internal policies that do not belong to any single building block, and currently has none of them written:

  • Change procedure — exists in draft; see Co-creation & change management.
  • Incident and breach handling — who is told, in what order, within what time, when a credential is compromised, a policy fails open, or data is disclosed in error. The audit trail exists; the procedure around it does not.
  • Registry operations policy — availability expectations, correction of erroneous entries, and who may change participant status.
  • Conformance and re-testing policy — how often ITB-S evidence must be refreshed, and what happens to a listing when it lapses.

All are created the same way as any other scheme text: drafted by the responsible owner, reviewed by the WP4 lead, approved at TIPS, versioned here.

Needs owner iSHARE + iLabs: incident handling is the gap with real consequences and no owner in the register. It should be assigned.

3.4 Technical Specifications & Requirements#

  • Which technical standards and specifications (APIs, semantic models, connectors, security protocols) are adopted and enforced?
  • How will technical standards evolve over time?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided The scheme adopts and enforces, per the Grant Agreement and the technical blocks:

  • Semantics — DCAT-AP (v3) for descriptions, NGSI-LD with OASC MIM2 for city data, JSON-LD serialisation, SHACL validation; schemas.ishare.eu/vocab# as the canonical namespace, extended and never forked.
  • Exchange — Eclipse Dataspace Components with the EDC iSHARE extension; iSHARE-compliant authorisation APIs (openapi.ishare.eu); OGC services for geo layers, with non-ESRI interoperability explicitly required.
  • Identity — W3C Verifiable Credentials over OpenID4VC, aligned with eIDAS 2.0; iSHARE credential schemas; eIDAS trust lists and PKI profiles for transport security.
  • Policy — the iSHARE ODRL profile, bound to licences from licenses.ishare.eu.

Enforcement is through the ITB-S: an exchange path is validated there before production use, and conformance evidence feeds the registry.

Proposed Evolution follows the same change procedure as any other scheme rule, with one addition: where a standard the LDT adopted is itself versioned upstream (DCAT-AP, NGSI-LD, OpenID4VC), the owning block states which version is normative, so "we follow the standard" never becomes ambiguous during an audit.

3.5 Documentation and Accessibility#

  • How will all internal rules and guidelines be documented?
  • In what formats (human-readable, machine-readable) will these documents be accessible?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Decided All scheme rules are documented in this repository and published as a site (Material for MkDocs on GitLab Pages). The repository is authoritative; the published site is a rendering of it. Every rule therefore has a version, an author and a change history, which is what makes the audit trail in PD4 chapter 9 possible at all.

Proposed Formats, deliberately both:

  • Human-readable — Markdown here, rendered to the site, exported to PD4 for submission.
  • Machine-readable — and this is where the scheme's real enforceability lives: ODRL policies, credential schemas, DCAT-AP descriptions, SHACL shapes and registry entries are the executable form of the same rules. A rule that exists only in prose is, by this scheme's own ground rule, a contract clause rather than an operating condition.

Decided Access, as a statement of fact rather than of intent: the repository and the published site are public. The GitLab project is set to visibility: public, the repository and its API answer unauthenticated, and the Pages site serves the scheme to anyone with the link — checked 29 October 2026. Earlier drafts of this page and of the PD4 merge request said the opposite; they were wrong.

Needs owner TIPS: ratify that, or correct it. The decision is no longer "should the scheme become publicly readable" but "is it right that it already is", and it carries a contractual edge. PD4's Document information contradicts the live state: it classifies the deliverable as Sensitive (SEN) and says reviewer access is on request, with the tagged snapshot attached as a PDF annex. That classification is not cosmetic — Pilot Grant Agreement article 12.1 binds the recipient to keep confidential anything identified in writing as sensitive information, for five years after final payment. Marking PD4 "Sensitive" in writing while publishing the repository it is a snapshot of is therefore a tension in the contract, not only in the paperwork. The argument for public stands either way — a data space whose rulebook cannot be read by prospective participants cannot recruit them — but the classification and the visibility have to agree. (Sources: Pilot Grant Agreement article 12.1; GitLab project visibility checked 29 October 2026.)

4. Additional Strategic Questions for Co-Creation#

These questions facilitate active stakeholder engagement in the governance design process.

  • Do stakeholders prefer an incorporated or unincorporated organisational form, and why?
  • What legal or operational constraints exist that might influence the choice of organisational form?
  • How will the governance structure ensure representation and accountability of all participant groups?
  • What processes will be used for onboarding new members or adjusting roles and responsibilities?
  • What governance mechanisms will ensure ongoing compliance with evolving regulatory requirements?
  • How will decisions within the governance authority be made, monitored, and reviewed over time?

LDT answer DRAFTED · owner: iSHARE (sign-off: City of Almelo, Ayuntamiento de Cartagena) · due 26 Sep 2026 (block page says 17 Oct — see register)

Needs owner These are the co-creation questions for the 🧩 contribution on the block page — City of Almelo and Ayuntamiento de Cartagena, from the public-authority perspective. They are the questions this scheme most needs answered by someone other than its drafter, and the draft below is a starting position to react to, not an answer.

  • Incorporated or unincorporated? The pilot is unincorporated by decision. The drafting position is that incorporation becomes necessary when the LDT admits participants who are not consortium partners on a continuing basis — but whether the municipalities can participate in an incorporated body, and under what conditions, is a question only they can answer.
  • Legal or operational constraints. Municipal contracting rules, public procurement, and the limits of what a city may delegate to a governance authority. Unknown to this scheme today.
  • Representation and accountability. The pilot gives every partner a seat at TIPS. That does not scale, and it does not address citizens, who are data-rights holders without a seat. The Commons controls are the intended bridge; whether they constitute accountability toward residents is a judgement for the cities.
  • Onboarding new members and adjusting roles. Covered operationally in Participation management; the question here is who decides, and whether a municipality can be outvoted on admitting a participant that will hold its citizens' data.
  • Evolving regulatory requirements. See 2.4 and 2.5.
  • Decisions monitored and reviewed. See 2.2 and 2.5.