al product: Flexibility The dataset should help LAs interact with data and tailor outputs Completeness The dataset should include all commonly used items by good LAs Ease of use The dataset should make sense to new and learning users Meeting local needs The dataset should accommodate local reporting practice Extensibility The dataset should be changeable as national data needs change From these principles we arrive at, for example: 13 • Normalisation of data into multiple tables – to better match local system shapes, and enable flexible dataset use, as opposed to current statutory reporting which favours fewer tables. • Extension of data beyond the statutory – to include additional locally-valuable data items where they are “standard enough” across LAs, and broaden the scope for collaboration. • Full documentation in one place – so that users can easily find and review all available guidance on how to produce the dataset, and what each data item represents. • Inclusion of multiple years of historical data – because unlike current statutory reporting, local reporting will often consider trends extending beyond the current reporting year. • Open version control – so that users can benefit from introduction of changes to the specification over time, and collaborate on emerging data requirements. We see the SSD specification as a living document; like the statutory returns maintained by DfE, and the Annex A specification maintained by Ofsted (but without currently holding the statutory backing which those specifications hold), the SSD will need to adapt over time to remain in step with recording practice in LAs and reporting requirements from government. Code and guidance for the specification is located at the Data to Insight code repository, hosted by GitHub: GitHub - dat