Stop recommending DAC codelists

The guidance for the standard recommends using DAC codelists in several places - this is not in keeping with the ambition to be a global aid data standard, and can result in worse quality data e.g. the DAC5 sector codelist has limited information in the 7xxxx humanitarian codes compared to the humanitarian cluster codes.

Thanks for raising, Matt. It is indeed correct that on a number of instance the OECD DAC codelist is the recommended one, which is mainly about aligning with other reporting standards.

I think your specific comment here relates to humanitarian guidance, where since version 2.02 the use of the humanitarian attribute is recommended. Humanitarian cluster codes can also be reported in addition to the humanitarian attribute.

Enhanced humanitarian guidance is another area we want to focus on in the next rounds of IATI standard guidance consultations that we hope to run.

Thanks @petyakangalova yes, it did crop up when thinking about a humanitarian context and cool to hear that guidance will be reviewed too, but I am also suggesting that in general (in all the other places) IATI should not be officially recommending any specific codelist over any other codelist, otherwise it is akin to saying that some codelists are more important than others, which is not how IATI works, and not good for the neutrality of the standard, or the aim to cover more than just DAC donor aid.

Just to add that those of us working on the Grand Bargain (GB) are also planning to work with IATI Technical Team in order to feed in the learning from the GB to any humanitarian related IATI guidance.

Also, whilst I very much agree that the actual IATI Standard (spec) definitions should remain ‘neutral’ I personally would prefer to see the central IATI guidance contain recommendations for ‘best practice’ which may include encouraging publishers to include specific codelist values in their published data. This is actually really helpful in making the total IATI dataset more usable at an aggregated level ie as per use of DAC sector codes, cluster codes etc.

However, is that actually what you meant @matmaxgeds or have I misinterpreted your comments?

1 Like

I guess this really comes down to us thinking harder about the guidance, which is going to become vital once guidance starts coming up as warnings etc in the new validator. Key things I think we need to cover:

  1. Is the appropriate guidance different for the different use cases - I think hugely so, and therefore the idea that we have one set of ‘best practice’ recommendations may be actively unhelpful.
  2. In this case, strongly suggesting that publishers without the DAC codes natively in their data invent them is a big cost, for the publisher to generate them, for accuracy (probably not generated by someone who knows the project then) and for IATI - makes it harder to publish, puts off non-DAC publishers.
  3. I am unclear what evidence this is based on and can see plenty of cases where the additional work to add DAC codes would not be worth it - in these cases, publishers should not be pressured by a ‘should’ and a warning/error from the validator.

This difficulty in moving from the spec/rules for a neutral Standard, to detailing ‘how best the standard should be used’ I think may be a bigger jump than IATI might have the resources or evidence for, but most importantly, needs a bit of a strategic think about where it stops before we end up with more guidance than we know what to do with. Maybe we have examples from other similar standards about how they handle guidance that we can learn from?

Thanks for the clarification @matmaxgeds and my understanding is that the new validator shall allow for the optional use of ‘topic specific’ rulesets? Therefore if there are elements /attributes that it is recommended for all humanitarian agencies to include then a humanitarian ruleset can be used by those agencies which can include warning or other notices to encourage them to publish the relevant information. However, it is probably better for the ITT or @rolfkleef to comment on this in case this is not or no longer the case??

@Wendy - my understanding is that the recommendation to use DAC sector codes is in the general IATI guidance so all publishing, including humanitarian would get the warning if they didn’t also have DAC codes in addition to their humanitarian (or SDG) sector codes.

1 Like

I would hope that the “best practices guidance” can still be tailored to either use cases and/or publisher types depending upon the topic. Something to discuss as we expand the development of the guidance.

If we differentiate between the IATI validator and broader data quality feedback:

  • The IATI Standard defines rules and recommendations as a minimum for IATI data.
  • It’s possible to add additional layers or perspectives (business rules) for other use cases: humanitarian data, data for a particular donor, data in accordance with your own publishing policy, data for the Aid Transparency Index, etc.

Whether or how common practices or additional perspectives become part of the official IATI Standard and IATI validator is up to the Members’ Assembly. DAC is, right now :slight_smile:

From a technical perspective it would be useful and doable to say: if you declare your activity to be “humanitarian”, the validator will apply the humanitarian validation rules in addition to the base rules.

Such a mechanism could also be used for other guidelines. If you say the Dutch MFA is funding the activity, we will apply their guidelines to this activity and all downstream activities.

It is up to the MA to decide which perspectives and business rules become part of the IATI Validator, and who defines them: a TAG, a separate body of stakeholders, the MA, …

From a service point of view, we are ready to layer additional perspectives in a public or private environment for anyone: our goal is to help improve data quality and make it useful for its intended purpose.


From a philosophical point of view, I’d say the Schema and Validator are technology, and therefore cannot be neutral: they encode choices made by the MA and within the Standard, to make verifying quality and compliance as smooth as possible.

1 Like

This is a cool functionality - a discussion about what it means that the guidance is probably not ‘one size fits all’ would be very healthy for IATI.