Rules and logic for when LPAs should be notified about updating their brownfield land data

[MJFaucherFolie]

Context

• The team have decided to implement a new feature which visually notifies users when they need to submit their BfL data
• This required an investigation into when the banner should or should not be shown

Acceptance criteria

• Proposal describing rules of when the notification banner should or should not be shown

Tasks

• [x] Get an update from Charlie
• [x] Get an update from the Data Management team
• [x] Draft a proposal describing the rules for the notification banner
• [x] Share with team
• [ ] Address follow up questions raised by team
• [ ] Share update with team

[MJFaucherFolie]

Charlie shared a series of questions which will help identify the requirements for displaying the banner.

The Data Management team have shared a response to these questions:

Which year are LPAs submitting atm? I’d assumed that they’re submitting the previous year’s worth of data - i.e. 2023 - is that correct?

Not sure, sorry! I assume from the policy answers you shared earlier if they’re required to review their register once per year, any time they submit should cover any changes within the previous year (or since they previously updated)

Is there an endpoint created/added date? Is this the right field for us to be looking at? What if they submit the same endpoint URL but just change the file on that endpoint?

Yes, all endpoints have an entry-date and a start-date. They normally get set the same when we add new endpoints but I think we could use them to handle situations like you describe below, e.g. a delay between submitting and data being added, in which case entry-date would be before.

If we’re expecting them to update the same endpoint, we’d want to look at the start-date of the most recent resource (where the resource has a 200 status so that we don’t count endpoints breaking as an update)

What if they submit an updated endpoint right at the end of the year when we’re on holiday, and we don’t process it till January? That then might be considered as them having submitted something for this year rather than last. Similarly, what if they submit after the deadline?

We could use the start-date to manage this

But I think it also depends on what you want the banner to show (which might depend on the policy). Should it be “you haven’t provided BFL data for year 2023” or “you haven’t updated your BFL data within the last year”. If it’s the last one then the date falling within a particular annual range isn’t a bit issue.

When in the year should we start displaying the notification? Also depends on the policy answer.!

Have the Data Management folks been discussing whether to add in a new data quality measure around this? i.e. an issue/error that the pipeline would pick up Yes, we monitor stale endpoints using a datasette query, but it is something we might be able to get built into the pipeline

[MJFaucherFolie]

Drafted proposal for BfL Banner and shared with Charlie

[MJFaucherFolie]

Shared the proposal with Alex and George. We need clarity on the following:

Approach:

The current model we are using is everyone having the same deadline of 31st December. The other options could be:

• The first date they informed us about the dataset (entry date)
• 12 months from the last time they submitted their BfL (entry date, but dynamic)

We need to get clarity on this.

What is being submitted:

We are aware that the register is reviewing BfL activity on the register, but:

• Is it the register from that point in time (I.E - I submit on 06/11/2024, so it's up to date at that point), or
• Is it a register for the previous calendar year (I.E - in 2024, I submitted my BfL that covered changes which occurred in 2023)

[MJFaucherFolie]

Messaged Policy for insight on questions raised by the team. Will update when we get a response

[MJFaucherFolie]

Followed up with Policy, will update on the response