Accepts one of:

• string — Name or alias of the owning team, role, or group (e.g., 'Design Systems', '@acme/design-system').
• object — Full owner form: the owning party's name plus a contact route.
Name or alias of the owning team, role, or group (e.g., 'Design Systems'). SHOULD name a team or role, not an individual. How to reach the owner: a URL, email address, or channel reference (e.g., 'https://github.com/orgs/acme/teams/design-system', 'design-system@acme.com', '#design-system'). Freeform; tools SHOULD render it as a link when it parses as a URL or email.

Accepts one of:

• isoDate
• object — Full lastReviewed form: the date plus who reviewed, what version it was verified against, and an optional note on the outcome.
ISO 8601 date (YYYY-MM-DD) of the most recent review of this entity's documentation. Who performed the review — a team, role, or individual (e.g., 'Design Systems', 'jane.doe'). Unlike owner, naming an individual here is fine: it records a historical fact, not a standing responsibility. Plain-text note on the review outcome (e.g., 'Verified against v3.1; prop table still accurate', 'Guidelines section needs a rewrite — tracked in DS-412'). MUST NOT contain markup. The implementation version the documentation was verified against in this review, as a package version or release identifier (e.g., '@acme/ui@3.1.0', '3.1.0'). Lets tools detect drift: if the implementation has moved past this version, the documentation MAY be out of date even if recently reviewed. Nested inside the review record so it structurally cannot exist without one.