A description of the component’s function, and as at product level, including any known limits. At component level, you may find references to specific aspects of persona, but components directly address a need. In most cases they have a 1-1 relationship with user-facing modules.
This is the country (or continent) map which describes the major cities and the laws of the land in that country. There may also be trade agreements and as such import/export can be detailed.
If there are important words to understand in this area, make them clear and obvious here.
Any key architecture or design decisions (more specific than those at the product level) surrounding this component.
One or more links, or inlined details, around the API that this component exposes to other components or directly to the outside world.
A list of the source repositories and subsystems (if they exist) of this component. This should include references to the
subsystem.md file of the subsystem, or the repository path (it should really be enough to
git clone from) as well as the nature of the repository or subsystem: host, 3rd party, adopted, custom, etc.
One or more lists of:
What test tools, what regression packs, what tests are important to this component. This may be delegated to subsystems.
Which team and/or people have ownership over this component and it’s subsystems. It would be wise to include a skills/competencies map to ensure it’s clear what is required to own a the component.
As at the product level, key decisions about the component are recorded chronologically, with enough context to be useful after the fact.