Repository for partnerships
Transparency impacts » Repository for partnerships

What should be included in a repository for a global partnership?

For the answer given by Copilot on February 27, 2026, see: Repository for a Global Partnership.

Below we describe some additional expectations and requirements.

The content that will be consulted and produced as local governments, companies and individuals engage in Collaborative Planning ( #pi9, or a collective regulative bundle) for the sustainable development goals (#SDGs) must have several qualities:

  • it must be accessible (see #DA2I),
  • it must be fit for use, even by poor stakeholders,
  • it must encourage content re-use,
  • it must support improved knowledge conversions, and
  • it must overcome hurdles to transparency.

Tactics for giving content the desirable properties "consultation, feedback, reference, and reuse" include:

As many of the deliverables listed here are typically work products in the collaborative planning and partnership recruitment, these deliverables will be constrained or altered to reflect progressive insights from:

The log maintained for each asset will further document the rationale for their contents and structure.

A Repository is a connected set of web-resources where worksystem stakeholders, including developers, store all documentation, knowledge, and artifacts for the decision or action initiative, and for the projects in which it is being further developed.

A CRB Node is a typical part of a repository.

The CRB for a given (case) business or livelihood is involved in the system development process of that action arena and is supported by a range of different nodes (e.g., Country Nodes, Language Nodes, Sector Nodes) that are particular to the theatre.

Each Node (workspace) provides access to specific content. Stakeholders, in particular the experts, the decision analysts and designers must guard cumulative consistency of the content in the nodes, and they must modify the content to reflect new requirements.

The content of each CRB Node is under local revision and version control.

  • A revision is described as a change to a previous version, of which a consolidated model exists. A revision needs not be integrated in a consolidated model.
  • A version requires the drawing of a new consolidated model, as a reference for the further system development projects.
  • Whenever the repository cell content (of version Y/ revision Z (Y.Z)) refers to content of other cells, it must include the version & revision of the content in the other cell.

The repeatability feature across the CRB nodes supports the alignment of the models (see Reference Models) of multiple systems at the different Architecture Levels and for the different Architecture Aspects.

An externally oriented CRB Node will contain the url's of Nodes with similar level and aspect (of other systems). It will indicate the version number of the Node contents that it requires.

An internally oriented CRB Node will contain the successive versions of the models and other content that have described the worksystem or livelihood in focus. These versions will be the deliverables of project activities (development, analysis and design tasks).

Reporting in the CRB Node includes activity reporting (which task, when, by whom, what, and why) and revision justification (on what basis was the revision decided).

As yet, the list of deliverables, and each deliverable is under construction. Browse the proposed deliverables and phase descriptions for getting a flavour of the approach, and pls. comment and help if it can accelerate the glocal partnering!

+ Add a PDM deliverable
Footnotes