Which CoverageJSON fragments would make good "building blocks" for re-use

OGC has a policy for re-usable "building blocks" at various levels of granularity to improve interoperability.
@chris-little and @jonblower agreed that a first proposal would be to register the parameter object in the OGC register of building blocks.

The building blocks are organised in these folders:
• geo: geospatial building blocks
• ogc-utils: Utility building blocks that are used in OGC API's but are not inherently geospatial. They were created to ensure consistency within OGC API's where there was not a clear mainstream standard, and in line with best practices of the web and could be replaced, e.g. by building blocks specified in an IETF RFC or similar, if and when available. API's built with the geo building blocks do not need to use these, but they provide a nice default option that OGC-focused tools will understand.
• unstable: These building blocks are not yet stable or mature. They may be extracted from core OGC API standards that have not yet been fully approved, or they may also be new ideas that are not yet in a standard.

Each building block is an AsciiDoc document, whose name follows the convention: PREFIX-NAME.adoc. The prefix is parameter, in the case of parameters, header in the case of headers, and encoding (e.g.: JSON) in the case of data types or resources. This is an example of a building block
In addition, please register the building block in the register.json
This provides information about the item, using an extension of the ISO19135 schema.
All contributions welcomed, as pull requests to this repository

Read the linked OGC building-block register example and register.json in the opengeospatial/bblocks repository first. Then identify CoverageJSON fragments that fit the stated building-block categories and document a concrete proposal. Done means the proposal is recorded and, if accepted, submitted as a pull request with the required registration entry.