Skip to content

How to contribute your building block#

This repository is the LDT Governance and Trust Framework — the governance scheme of the EUTwinLink pilot, and the source text of deliverable PD4 Governance Scheme (due 30 October 2026). PD4 acceptance is a payment condition, so a block left unwritten is a schedule risk, not a documentation gap.

You do not need to know the iSHARE Data Space Template to contribute. You need to know your own block.

1 · Find your work#

Start here: Open questions for partners — every question the scheme cannot answer without you, grouped by partner. It is generated from the scheme itself, so it is never out of date.

The Building-block register gives the same picture by block, with owner, due date and status.

What changed in October 2026#

The v0.5 deadline passed with no contributions, so all 125 answer slots were drafted ahead of the v0.9 review. That changes your job from writing to reviewing, which is faster — but it does not make the drafts true. Every answer carries its provenance:

Tag Means What you do
Decided already fixed by the Grant Agreement, the Consortium Agreement, or a recorded decision elsewhere in this scheme check it is accurately stated; change it only through the change procedure
Proposed a defensible default derived from the iSHARE framework, the DSSC Blueprint and decisions already taken. Not an agreed position. confirm, correct or reject it
Needs owner cannot be answered without you — a fact about your systems, your legal position or your commercial intent answer it; the text says what is needed and why

A Proposed answer you leave untouched is one nobody agreed to. If it is wrong, saying so is a contribution.

There are still two kinds of work on the pages themselves:

  • 🧩 Building blocks requested — marked blocks on a block page, stating what is needed, in which format, by when.
  • LDT answer slots — on the guiding-questions.md page of your block, under each theme.

2 · Write#

Ground rules, in order of how often they are forgotten:

  1. Reuse before drafting. iSHARE model agreements, Rulebook clauses, existing standards, existing registries. If you drafted something new, say what you could not reuse and why.
  2. Make it enforceable. State every operating condition as something a machine can check — an ODRL policy, a credential check, a registry entry. A condition that cannot be checked is a contract clause; write it as one and name it as such.
  3. Cross-reference, do not repeat. PD1 covers data management and ethics; PD3 covers architecture. Link them.
  4. Decisions, not intentions. "We will consider federated catalogues" is not an answer. "One catalogue, operated by Nunsys, federated queries out of scope for the pilot" is. If a decision is genuinely not yours to take, say who takes it and when.
  5. Write in the page's voice. Short prose, British spelling, no marketing. The page anatomy is in Scheme overview.

Filling an answer slot#

Replace the placeholder between the markers — keep the markers themselves:

**LDT answer** — `OPEN` · owner: iLabs · due 26 Sep 2026

<!-- ldt:answer:start -->
Onboarding is application-based. An applicant submits …
<!-- ldt:answer:end -->

The markers matter: tools/sync_template_questions.py re-syncs the question text from upstream and preserves everything between them. Text written outside the markers on a generated page will be lost on the next sync.

Keep the provenance tag honest when you edit: an answer you confirm as a partner is no longer Proposed, and one you have supplied the facts for is no longer Needs owner. Dropping a Needs owner tag removes that item from Open questions for partners the next time tools/collect_open_questions.py runs, which is how the list stays accurate.

3 · Submit#

One merge request per building block — not one per partner, and not one per sentence. Small, reviewable, attributable.

git switch -c block/T2-data-exchange
# edit
git commit -m "T2 data exchange: answer guiding questions 1-3 (iLabs)"
git push -u origin HEAD

Open the merge request against main using the Building block template, which asks for the block ID, what changed, and what is still open. The WP4 lead (iSHARE Foundation) reviews; the TIPS Committee approves.

4 · Status lifecycle#

OPEN → DRAFTED (you) → REVIEWED (WP4 lead) → APPROVED (TIPS). You set DRAFTED; do not set the later two yourself.

Timeline#

Date What
9 Sep 2026 TIPS Committee — owners confirmed
26 Sep 2026 v0.5 — building-block contributions due — passed with no contributions
8 Oct 2026 all 125 slots drafted, so the review has text to work from
3 Oct 2026 Integrated draft + legal review
17 Oct 2026 v0.9 review; late sign-off blocks due
27 Oct 2026 TIPS Committee — approval
30 Oct 2026 PD4 submission

Reading the docs locally#

The repository renders as a documentation site with Material for MkDocs, published to GitLab Pages by CI:

python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
.venv/bin/mkdocs serve      # live preview on http://localhost:8000

Questions#

Open an issue and tag the WP4 lead, or raise it at the monthly TIPS Committee. If your block depends on a decision someone else owes, say so in an issue rather than waiting — a blocked block should be visible.