Consortium project sharing

What it does

When several organizations run the same project as a consortium, this layer shares the budget structure and the actual execution (imputations, documents) among partners through the Futuh Hub, with the data-protection safeguards required by the joint-controller arrangement of GDPR art. 26.

Before you start

• Role: your instance’s federation administrator (Administrador de federación Futuh group). The consortium tab and buttons are visible only to that role.
• The coop_shared_projects module installed on your instance, and the project already linked to a consortium share.
• The Futuh Hub operated by Asamblea de Cooperación Por la Paz running the futuh_federation_consortium module.
• Interface labels in this guide are shown in Spanish, as they appear in the instance.

Available from these versions

The consortium data-protection layer (GDPR art. 26) requires both sides updated:

• Hub — futuh_federation_consortium 19.0.0.3.0.
• Client — coop_shared_projects: agreement acceptance and reveal marking from 19.0.0.3.0; archival, purge, and the stale-data signal from 19.0.0.4.0; the display of revealed PII in the mirror and the access log from 19.0.0.5.0.

Deployment order: update the client before or together with the Hub. An old client against a Hub with the agreement in force gets a controlled (fail-closed) error on sync, not a silent failure.

How a consortium is organized

Each shared project has a lead (the organization that creates the share and publishes the structure) and one or more partners. For execution purposes the lead is just another partner: any member pushes and sees the execution of the lines assigned to it.

Where each thing lives in your instance:

• Federación Futuh → Compartidos conmigo: the tray of shares the Hub holds for your active connections. Actualizar (Refresh) pulls them; from a row, Vincular a un proyecto local ties the share to one of your projects.
• On the linked project, the Consorcio tab: the operations hub. From here you push structure and execution, accept the agreement, mark PII reveal, view the access log, and manage retention and purge.

Ownership is enforced by the Hub

When you push execution (Enviar ejecución al consorcio), only the imputations of the lines assigned to your organization travel. Origin ownership is enforced by the Hub server-side, not by your instance: no one can federate execution over someone else’s lines.

Accepting the joint-controller agreement (GDPR art. 26)

Sharing a project’s execution means several organizations process common personal data (beneficiaries, staff, suppliers). GDPR art. 26 requires the joint controllers to agree on how they split their obligations. Futuh embodies this as an agreement whose acceptance is mandatory before any execution is exchanged.

The agreement is a hard gate for every member, the lead included: until you accept the version in force, the Hub withholds that share’s execution data. The project structure still syncs; the consortium imputations and documents do not.

How the blocked state looks and how to accept:

1. Open the project and go to the Consorcio tab. If the agreement is pending, you’ll see a warning: “Datos de ejecución retenidos. Debes aceptar el acuerdo de consorcio vigente (corresponsabilidad RGPD art. 26)…”.
2. The Acuerdo de consorcio (RGPD art. 26) group shows the required version (Versión del acuerdo requerida) and the agreement link (URL del acuerdo, its public text). Read it before accepting.
3. Click Aceptar el acuerdo de consorcio. The confirmation dialog reminds you that, once you accept, execution data will start being exchanged with the partners.
4. On confirm, your instance records the acceptance of that version on the Hub and re-syncs. The warning disappears and the consortium execution becomes available. You’ll see a notification: “Acuerdo de consorcio aceptado (versión …). Los datos de ejecución ya están disponibles.”.

If you try to push execution without accepting

The Enviar ejecución al consorcio and Enviar documentos buttons fail explicitly while the agreement is pending, and Actualizar ejecución del consorcio warns you: “La ejecución queda retenida hasta que aceptes el acuerdo de consorcio vigente (RGPD art. 26). Versión vigente: …”. There is no silent degradation: either you accept, or no execution flows.

Each agreement version is re-accepted

If the Hub administrator publishes a new version of the agreement, the share is blocked again until you accept the new version. Acceptance is per exact version, not a one-off blanket consent.

Revealing PII in a controlled way

By default, the execution you push to the consortium is pseudonymized: a payslip’s concept and third party travel as pseudonymized values, and only supplier invoices keep the supplier name (B2B commercial data). This is the behavior inherited from the previous layer.

When a funder justification or an audit requires an imputation to travel in clear, the origin owner can reveal it, marking imputations one by one:

1. On the project’s Consorcio tab, click Revelar PII en las imputaciones. The editable list of the imputations of the consortium-coded lines opens.
2. Turn on Revelar PII al consorcio on the specific imputations you need.
3. Choose the Finalidad de la revelación (mandatory as soon as you turn reveal on): Justificación al financiador (funder justification) or Auditoría (audit). If you turn reveal off, the purpose is cleared automatically.
4. Save and click Enviar ejecución al consorcio again. The marked imputations travel with concept and third party in clear; the rest stay pseudonymized.

Control always stays with the origin

The decision to reveal is always the partner’s who originated the imputation. There is no “reveal request” workflow and no server-side de-pseudonymization: revealing later is a fresh push from the origin. Reveal marks are persistent and survive later pushes.

In the execution mirror the other partners see (Consorcio → Ejecución del consorcio tab), each row shows whether its PII is revealed and for what purpose (a purpose badge); with no reveal, those cells stay empty. That makes it plain at a glance what is in clear and why. (Display requires client 19.0.0.5.0.)

Retention and archival

When the lead closes a share, the Hub moves it to a terminal state and starts its 4-year retention clock: after that window, the Hub hard-purges the execution data. The Hub administrator can extend retention with a legal hold when a legal obligation requires it.

On your instance, when a sync detects that the share has entered a terminal state:

• The project is marked archived and a red banner appears on the Consorcio tab: “Compartición de consorcio archivada. El Hub notificó esta compartición en un estado terminal y purgará definitivamente sus datos de ejecución cuando venza la ventana de retención…”.
• The local execution and document mirrors are frozen and kept only for traceability. They are never deleted automatically.

To remove the local copy once you no longer need it:

1. In the Retención del consorcio (archivado) group, click Purgar espejos archivados.
2. Confirm. Only the local mirror copies (archived foreign execution and documents) are deleted. Your own project data (budget, own documents) is not touched.

Stale-data signal on a failed sync

If a consortium refresh fails (for example, a 404 because the share was closed or your access was revoked), your instance does not archive automatically —a 404 is ambiguous— but it does warn you: “La última actualización del consorcio falló… la ejecución y los documentos mostrados pueden estar obsoletos.”. Retry the refresh; if it keeps failing, the share is likely gone from the Hub.

Access log

Consortium transparency is symmetric: any member of a share can see who accessed that share’s data. It does not depend on role.

1. On the project’s Consorcio tab, click Ver el registro de accesos.
2. A read-only list opens with the entries: Marca de tiempo (timestamp), Operación (operation), Organización solicitante (caller org), and Referencia del recurso (resource reference).

Log details

• The log records the disclosure events: structure and execution pushes, document downloads, agreement acceptances, closures and purges. Structure reads (pulling the share without execution being served) are not logged — minimization of the log itself.
• The Hub serves the log even when execution is withheld by the agreement: the log only requires being a member of the share, not having accepted. A non-member gets a uniform 404.
• The list pulls the entries paginated up to a cap. If the log is longer, the window title says so —“(primeras N entradas — hay más en el Hub)”— instead of truncating silently.

Learn more

• Futuh Federation: overview to place the consortium within the federation.
• Connect your instance to the Hub Central if you still have to configure the endpoint and token.
• Consortium agreement draft (art. 26) to read the essence of the agreement accepted at the gate.