Lobbying transparency

[duncandewhurst]

Background

This issue relates to the following CoST IDS elements proposed in the CoST IDS/OC4IDS review:

Lobbying transparency

Lobbying transparency

Module: Institutional
Indicator: Access to information

Disclosure format

(Draft currently under discussion)

Disclose the occurrence of lobbying meetings regarding the project, including the meeting agenda and minutes, the number of the participants, dates and location of these meetings (E.g. Meeting 1 [date] [location] [number of participants] [Document], Meeting 2 [date] [location] [number of participants] [Document]). ​​

OC4IDS mapping

​​​Project Level:
For each meeting:

1. Publish the meeting agenda. Add a document, set its .documentType to ‘lobbyingMeetingAgenda’ and its .url to the URL at which the agenda is available.
2. Publish the meeting details. Add a Meeting object to the .lobbyingMeetings array and set:

• .id incrementally
• .date to the date of the meeting
• .beneficiary to the name of the organisation or interest group that ultimately benefits from the lobbying activity

3. Publish the meeting minutes. Add a document, set its .documentType to ‘lobbyingMeetingMinutes’ and its .url to the URL at which the meeting minutes are available.

Proposal

Add an array of lobbying meetings, a meeting beneficiary field, and documentType codes for lobbying meeting agendas and minutes.

Add the following fields:

Path	Title	Description	Type (format)	Codelist
lobbyingMeetings	Lobbying meetings	Information about lobbying meetings. That is, meetings with public officials that are made, managed or directed with the purpose of influencing public decision-making in relation to the project, whether for private, public or collective ends, whether for compensation or without. A public official is any individual with decision-making powers (and their advisors), who are elected, appointed or employed within the executive or legislative branches of power at national, sub-national, or supra-national levels; within private bodies performing public functions; and within public international organisations domiciled or operational in the country concerned. Public decision-making is the creation and amendment of legislation or any other regulatory measures; the development, modification and implementation of public policies, strategies and programmes; and the awarding of government contracts or grants, administrative decisions or any other public spending decisions.	Array of Meeting objects
Meeting.publicOfficial	Ultimate beneficiary	The name of the person, organization or other entity that ultimately benefits from the meeting.	String

See #409 for details of the Meeting object.

Add the following codes:

Codelist	Code	Title	Description
documentType	lobbyingMeetingAgenda	Lobbying meeting agenda	A list of the issues to be discussed at a lobbying meeting.
documentType	lobbyingMeetingMinutes	Lobbying meeting minutes	A record of the issues discussed, agreements reached and decisions taken at a lobbying meeting.

Example

{
  "lobbyingMeetings": [
    {
      "id": "1",
      "date": "2024-01-01T00:00:00Z",
      "beneficiary": "Arup Group"
    }
  ],
  "documents": [
    {
      "id": "1",
      "documentType": "lobbyingMeetingAgenda",
      "url": "http://example.com/lobbyingMeetingAgenda.pdf"
    },
    {
      "id": "2",
      "documentType": "lobbyingMeetingMinutes",
      "url": "http://example.com/lobbyingMeetingMinutes.pdf"
    }
  ]
}

Sources

• REGULATORY SCOPE - International standards for lobbying regulation - definition of lobbying.
• TRANSPARENCY - International standards for lobbying regulation - ultimate beneficiary term
• Lobbying Transparency via Right to Information Laws (Lobby Transparency Disclosure Standards) - Access Info Europe - definitions for documentType codes (page 2)

Whilst these sources are more about establishing national lobbying registers and regulations than they are about disclosures relating to individual projects, I think they are relevant because I figure that the intention of the lobbying transparency element is to encourage implementers of the institutional module to disclose similar information, even in the absence of a national register or regulations.

Discussion

• @jpmckinney, the description of the lobbyingMeetings field is very long because it reuses the definitions from the International Standards for Lobbying Regulation. I chose to provide a comprehensive definition of lobbying because many countries do not regulate lobbying activities so there might be no 'local' definition to defer to, which might lead to (deliberate or accidental) misinterpretation of the scope of the field. Should the description instead simply reference the standards? e.g.

Information about lobbying meetings as defined in the regulatory scope of the International Standards for Lobbying Regulation.

• @EvelynDinora, I've omitted the address of lobbying meetings and the number of participants (both of which are suggested in the draft disclosure format) from the proposal because they do not appear in either the international standards for lobbying regulation or the Access Info Europe disclosure standards. Please let me know if there is a specific use case for including those fields.

• @EvelynDinora, @jpmckinney, I've included the beneficiary field per lobbying register information disclosure section of the International Standards for Lobbying Regulation because, whilst not mentioned in the draft disclosure format, this seems like very important information. The standards also recommend disclosing: lobbyist identity, the subject matter of lobbying activities and outcomes sought, and the targeted institution and/or the public official concerned. Should any of those be included in the data model?

• @EvelynDinora, the proposal lacks a means to link meeting agendas and minutes to the items in the lobbyingMeetings array. Is that going to be a problem with respect to the use cases for this element?

[jpmckinney]

I don't mind a long description.

---

Lobbying transparency is typically its own, independent dataset – mainly because lobbying isn't solely about infrastructure projects and can cover just about everything. Our typical approach is to enable links between datasets.

From a government's standpoint, it is much more likely to manage information about lobbying and about infrastructure projects separately (many governments have lobbying registries, and they are not connected to projects in any way).

As such, I am not especially keen on adding a bunch of fields – without evidence that anyone will actually populate them in the context of an infrastructure project, and independently of a central lobbying registry.

---

For minutes/agenda codes in this and other issues, maybe start a pattern of 'minutes.scope', so we have 'minutes', 'minutes.lobbyingMeeting', 'minutesConsultationMeeting', etc. #409

[duncandewhurst]

Lobbying transparency is typically its own, independent dataset – mainly because lobbying isn't solely about infrastructure projects and can cover just about everything. Our typical approach is to enable links between datasets.

From a government's standpoint, it is much more likely to manage information about lobbying and about infrastructure projects separately (many governments have lobbying registries, and they are not connected to projects in any way).

As such, I am not especially keen on adding a bunch of fields – without evidence that anyone will actually populate them in the context of an infrastructure project, and independently of a central lobbying registry.

Yes, linking to an existing register would be ideal. However, my understanding is that more countries lack lobbying registers and regulations than have them so that won't be possible in many cases, and I understand that CoST proposed this element based on demand for data on project-specific lobbying (note that the proposed description for lobbyingMeetings adds "in relation to the project" - the intention isn't to publish all of a country or entity's lobbying disclosures in OC4IDS).

Anyway, is this an objection to the proposed lobbyingMeetings array or feedback on the discussion point about adding more fields to the Meeting object?

If it's the former, I'll defer to @EvelynDinora and Maria (Prado) on the use cases for structured data on lobbying meetings. If the latter, I'm happy not to add any of those fields - just flagging a possible disconnect with best practice.

Edit: the minutes/agenda codes suggestion sounds good.

[jpmckinney]

I think it's fine to go ahead with the data elements that were identified as part of the CoST IDS/OC4IDS review.

I'm responding to your question "Should any of those be included in the data model?"

The target of the International Standards for Lobbying Regulation is a lobbying registry. The data elements they describe are definitely appropriate for a lobbying registry. But, we're not dealing with a lobbying registry. We're dealing with disclosures about infrastructure projects. Our standard development should be led by user needs in our context of infrastructure projects – not those in the context of lobbying registries.

(In practice, I don't see how a country that is incapable of implementing lobbying registers and regulations would somehow have the capacity to follow best practice for lobbying in the specific case of infrastructure projects.)

[duncandewhurst]

My understanding is that lobbying transparency was identified as a need in CoST's research (although, looking at the report on findings, I see it was considered of low importance by survey respondents), but that the specifics of the proposed disclosure format were chosen out of a desire to align with the disclosure format for public consultation meetings.

I don't see anything specific about the use cases for lobbying data in CoST's report on findings. However, I think the use cases for data on public consultation meetings (e.g. checking that consultation happened, that meetings had a meaningful number of participants, that meetings did not take place in a different city to the location of the infrastructure etc.) are likely to differ from the use cases for data on lobbying meetings (e.g. identifying risks of undue influence and unfair competition) so I'm not sure the alignment of the disclosure formats necessarily makes sense.

I think that the use cases for data on lobbying meetings in the context of infrastructure projects are more likely to be similar to the use cases for lobbying registries. After all, many users would likely be looking at a lobbying registry to understand what lobbying has taken place in relation to a specific topic they are interested in (such as an infrastructure project). That is why I thought it would be useful to compare what is proposed here with the international standards on lobbying regulation. In doing so, I intentionally omitted transparency recommendations from the international standards which seemed relevant only to a lobbying register (e.g. lobbying expenditure, sources of funding, political contributions, etc.) rather than data on lobbying meetings.

To be clear, I'm not arguing that we should necessarily include the extra fields I mentioned in the issue description, just explaining why I think that the international standards might be more relevant than you suggest. Ultimately, I'm happy to defer to you and @EvelynDinora.

I share your concern about practical implementation, but I understand that CoST's desire is for the CoST IDS/OC4IDS review to take a prospective approach to proposing new data points.

[jpmckinney]

Thank you for the additional information.

Given the low importance in terms of user need, I think it is appropriate to keep the model minimal. We can always expand in future. It is much harder to reduce the scope of a standard later. An over-broad scope increases the complexity of learning and understanding the standard, and increases the cost and burden of developing and maintaining the standard. An overly prospective approach also risks adopting a model that is inappropriate for the unknown future needs (following best practices can mitigate but not eliminate this risk).

[duncandewhurst]

Okay, that all sounds good to me. Thanks!

[mgraca-prado]

Hi Duncan, James and Evelyn, let me try to contribute a bit to this already very rich discussion:

1. The inclusion of lobbying as a new data point was to respond to issues raised during the Key Informant Interviews. As Duncan pointed out, this was an item that scored low in comparison to others in the survey, but the survey results conflicted with the position in the interviews where experts raised the importance of opening the 'black box' of project selection and decision-making. Having more clarity on lobbying activities was our answer to bring more clarity around conflict of interests in decision-making and project selection. What we are trying to capture is the undue influence and conflicts of interests in the early stages of project development and we are using the word 'lobbying' also in reference to activities not formally regulated. I will make this more clear in the report to explain the rationale behind the data point and the importance of transparency around this topic.

2. Although lobbying registries are still very rare, many countries do publicly disclose information on the agenda of public officials. Brazil for example adopts this as a good practice and many officials in congress/parliament do disclose the meetings they will attend every day (including name of the individuals/companies attending those meetings). This is not the same as a lobbying registry (also because the lobbyist profession is not officially recognized/regulated in Brazil as in many countries), but it is a good starting point to gain more clarity on the opaque dynamics held behind closed doors, which we know involve infrastructure funds and projects.

3. I agree with Duncan that there is value in keeping the data point aligned with international standards on lobbying regulation. Even if lobbying activities are not formally recognized and regulated in many countries, and lobbying registries are not yet a worldwide reality, the data point embodies a 'forward looking approach' that will allow the OC4IDS to dialogue with future databases (such as lobbying registries). At the same time, because we are not using all data elements of the lobbying regulation, this can give some flexibility to the data point. In the end, the goal is to get entities to disclose meetings held with "the purpose of influencing public decision-making" related to projects even if they are not labelled formally as 'lobbying' due to the lack of regulation.

4. I also agree with James in the sense of keeping this data point minimal. The objective is not to create useless data points, but to provide a framework to allow the issue of conflict of interests and undue influence in project decision-making to be somehow objectively captured.

5. What I would propose is to limit the data point to two key aspects: the lobbyingMeetingMinutes (already included above and which hopefully will reveal the 'lobbying beneficiary') and the public official concerned/involved (because meetings could be led by assistants having transparency on the officials would be key for conflict of interests purposes). On balance, in my view these are at the heart of the issue and will provide critical information to help track issues and stakeholders that may be conflicted or could have been compromised.

6. What do you think? In the pilot stage of the new data points we could go back to this discussion and revaluate.

[jpmckinney]

Thank you, @mgraca-prado. I agree with your suggestion (point 5).

[duncandewhurst]

Thanks, both. Two follow-up questions:

1. Regarding the 'public official concerned', are you looking for only the name of a natural person or are the public official's job title and organization needed too?
2. Do you still envision this information being disclosed in the context of a meeting? e.g.

{
  "lobbyingMeetings": [
    {
      "id": "1",
      "publicOfficial": "John Smith"
    }
  ],
  "documents": [
    {
      "id": "1",
      "documentType": "lobbyingMeetingMinutes",
      "url": "http://example.com/lobbyingMeetingMinutes.pdf"
    }
  ]
}

[mgraca-prado]

Hi Duncan,
I think it would be important to add the role and affiliation. And the disclosure of the meeting minutes would still be included in my view yes.
@jpmckinney, what do you think?

[jpmckinney]

Sounds good to me to add the job title and organization.

[duncandewhurst]

Great. Thanks, both. I assume that you're both happy with my second question about the public official's details appearing in the context of the lobbyingMeetings array (sorry if the question wasn't clear).

@jpmckinney, I'm interested in your thoughts on how to model the public official. My initial thinking is to reuse the Person definition, which was added to model the 'Project officials and roles' element of the existing CoST IDS. However, the definition lacks a field for the person's organization, since it is usually used in the context of the Organization object's .people property.

Schema.org's Person type has a worksFor property, defined as "Organizations that the person works for", that would meet this need, e.g.

{
  "lobbyingMeetings": [
    {
      "id": "1",
      "publicOfficial": {
        "id": "1",
        "name": "Brett Gliddon",
        "jobTitle": "Group General Manager Transport Services",
        "worksFor": {
          "id": "1",
          "name": "Waka Kotahi NZ Transport Agency"
        }
      }
    }
  ],
  "documents": [
    {
      "id": "1",
      "documentType": "lobbyingMeetingMinutes",
      "url": "http://example.com/lobbyingMeetingMinutes.pdf"
    }
  ]
}

However, if we add worksFor to Person, then it would also appear in the context of organizations in the parties array, in which case we have two ways of representing the same fact and risk inconsistent data, e.g.

{
  "parties": [
    {
      "id": "1",
      "name": "Waka Kotahi NZ Transport Agency",
      "people": [
        {
          "id": "1",
          "name": "Nicole Rosie",
          "jobTitle": "Chief Executive",
          "worksFor": {
            "id": "2",
            "name": "Port of Auckland Ltd "
          }
        }
      ] 
    }
  ]
}

To address that risk, we could:

1. Add a rule to the description of worksFor along the lines of "this field must only be used in the context of the lobbyingMeetings array". I don't particularly like that approach as the rule isn't enforced by the schema.

2. Introduce a personReference definition, which would need to reference both the person and their organization, e.g.

{
  "parties": [
    {
      "id": "1",
      "name": "Waka Kotahi NZ Transport Agency",
      "people": [
        {
          "id": "1",
          "name": "Brett Gliddon",
          "jobTitle": "Group General Manager Transport Services"
        }
      ]
    }
  ],
  "lobbyingMeetings": [
    {
      "id": "1",
      "publicOfficial": {
        "organization": {
          "id": "1",
          "name": "Waka Kotahi NZ Transport Agency"
        },
        "person": {
          "id": "1",
          "name": "Brett Gliddon"
        }
      }
    }
  ],
  "documents": [
    {
      "id": "1",
      "documentType": "lobbyingMeetingMinutes",
      "url": "http://example.com/lobbyingMeetingMinutes.pdf"
    }
  ]
}

The downside of that approach is that users would need to do two sets of dereferencing to look up the person's job title.

3. Introduce a separate publicOfficial definition. However, we'd then have two definitions for the same concept (a natural person) and would need to keep them in sync, e.g. if we renamed 'jobTitle' on one definition we'd need to remember to rename it on the other definition.

If we were using a later version of JSON Schema, the publicOfficial property could reference the Person definition and add worksFor only in that context, but with draft 04, I think the options are as above. Option 2 seems like the least bad approach to me, but happy to hear if you think differently.

[jpmckinney]

Hmm, good questions. In the Organization Ontology, we distinguished more types:

• Person, the actual natural person
• Membership, a relationship between a person and an organization
• Post, a position that can be held, and that exists independently (e.g. the post of mayor exists even if vacant)
• Role, a descriptor of the membership or post
• Organization

For lobbying meetings, we can't assume that the public official in the meeting holds a post, so Post isn't an option. That leaves only the Membership as the thing we're describing (similar to your example with person and organization fields).

I prefer the Organization Ontology (ORG) to Schema.org in this case. Schema.org is designed to match how information generally appears on the web (e.g. a person is, in the context of a given website, typically identified with their currently held role and organization). However, more broadly, people and their memberships are distinct and change over time – the Organization Ontology matches that.

So, I think an object with these fields would work: person (more intuitive in our context than ORG's member), organization and jobTitle (avoiding role in case of confusion with party role, where the party role is with respect to the project, whereas the job title is with respect to the organization).

As for schema design: I think we simply don't reuse the Person definition for this field. We instead just create a similar object in place. It's not necessary for these people to appear under organizations in the parties array.

[duncandewhurst]

That sounds good to me. If I understood correctly, the model would look like this:

{
  "lobbyingMeetings": [
    {
      "id": "1",
      "publicOfficial": {
        "person": { // An in-place object, not the `Person` definition, nor a reference to a person in an organization's `.people` array
          "name": "Brett Gliddon"
        },
        "organization": { // An `OrganizationReference` to an organization listed in the `parties` array.
          "id": "1",
          "name": "Waka Kotahi NZ Transport Agency"
        },
        "jobTitle": "Group General Manager Transport Services"
      }
    }
  ]
}

If that looks good, I'll prepare a proposal with field titles and descriptions.

[jpmckinney]

That looks good. Is “public official” the term of art for this, in the references and standards?

[duncandewhurst]

Yep, the international standards define lobbying as (my emphasis):

the term should cover any direct or indirect communication with a public official that is made, managed or directed with the purpose of influencing public decision-making.

The standards also provide a definition for "public official", which I reused in the proposed description of lobbyingMeetings. I figure we can move that part to the new publicOfficial field.

Access Info Europe's Lobby Transparency Disclosure Standards use the same term.

[duncandewhurst]

Proposal

Add the following fields:

Path	Title	Description	Type (format)	Codelist
lobbyingMeetings	Lobbying meetings	Information about lobbying meetings in relation to the project. That is, meetings with public officials that are made, managed or directed with the purpose of influencing public decision-making in relation to the project, whether for private, public or collective ends, whether for compensation or without. Public decision-making is the creation and amendment of legislation or any other regulatory measures; the development, modification and implementation of public policies, strategies and programmes; and the awarding of government contracts or grants, administrative decisions or any other public spending decisions.	Array of Meeting objects
Meeting.publicOfficial	Public official	A person (or advisor to a person) with decision-making powers, who are elected, appointed or employed within the executive or legislative branches of power at national, sub-national, or supra-national levels; within private bodies performing public functions; and within public international organizations domiciled or operational in the country concerned.	Object
publicOfficial.person	Person	The person.	Object
publicOfficial.person.name	Name	The full name of the person.	String
publicOfficial.organization	Organization	The organization in respect of which the person is a public official.	OrganizationReference
publicOfficial.jobTitle	Job title	The job title of the person with respect to the organization.	String

See #409 for details of the Meeting object.

Add the following codes:

Codelist	Code	Title	Description
documentType	minutes.lobbyingMeeting	Lobbying meeting minutes	A record of the issues discussed, agreements reached and decisions taken at a lobbying meeting.

Example

{
  "lobbyingMeetings": [
    {
      "id": "1",
      "publicOfficial": {
        "person": {
          "name": "Brett Gliddon"
        },
        "organization": {
          "id": "1",
          "name": "Waka Kotahi NZ Transport Agency"
        },
        "jobTitle": "Group General Manager Transport Services"
      }
    }
  ],
  "documents": [
    {
      "id": "1",
      "documentType": "minutes.lobbyingMeeting",
      "url": "http://example.com/lobbyingMeetingMinutes.pdf"
    }
  ]
}

[jpmckinney]

Hmm, if publicOfficial is defined as "A person", then person.name should just be name.

The alternative is to redefine as "A position held by a person ..."

[duncandewhurst]

The alternative is to redefine as "A position held by a person ..."

I think that's a better solution:

A position held by a person (or advisor to a person) with decision-making powers, who is elected, appointed or employed within the executive or legislative branches of power at national, sub-national, or supra-national levels; within private bodies performing public functions; and within public international organizations domiciled or operational in the country concerned.