Report metadata
Identify a report’s audience, publication details, editorial status and distribution intent.
On this page
Code
import type { ReactElement } from "react";
import { CalendarDays, CalendarRange, Code, History, LockKeyhole, Pencil, UserRound, Users } from "lucide-react";
import { ReportMetadata } from "@bosunkit/components/report-metadata";
export const description: string =
"Illustrative publication details with a reporting window, ownership and expandable source evidence.";
export default function PublicationDetails(): ReactElement {
return (
<ReportMetadata
label="Example report details"
category="Technical report"
reference="Engineering notebook · Example 014"
icon={<Code />}
accent="01"
status="Draft"
statusIcon={<Pencil />}
confidentiality="Confidential"
confidentialityIcon={<LockKeyhole />}
audience={{
term: "Prepared for",
icon: <Users />,
value: "Engineering and product reviewers",
hint: "Decision context, implementation evidence and open questions.",
}}
details={[
{ term: "Date", icon: <CalendarDays />, value: <time dateTime="2026-10-14">14 October 2026</time> },
{ term: "Updated", icon: <History />, value: <time dateTime="2026-10-14">14 October 2026</time> },
{ term: "Author", icon: <UserRound />, value: "Example engineering team" },
{ term: "Period", icon: <CalendarRange />, value: "October 2026" },
]}
tags={[
{ value: "architecture", label: "Architecture" },
{ value: "offline", label: "Offline systems" },
{ value: "example", label: "Illustrative" },
]}
>
<details>
<summary>Source evidence and distribution</summary>
<p>
Illustrative metadata only. In a real report, link the reviewed source revision and supporting records here.
</p>
<p>Confidential describes the intended audience. Access control belongs to the report host.</p>
</details>
</ReportMetadata>
);
}
Use
The document shell supplies the title and description. Metadata follows them once, before the report body. Use an audience description, a publication date, optional updated date and author, then useful topic tags. The reports site maps its validated frontmatter into this component; the kit has no report-schema dependency.
Classification states intended distribution. It does not enforce access. Unknown classification remains explicit;
a draft is not automatically public. Put revision and source disclosures in children when available.
Reading order
The category and optional reference identify the document at a glance. A reference can be an issue, reporting
window or stable document identifier. The category icon and accent provide a recognizable editorial identity;
keep the same accent for the same report category. The accent does not signal approval or confidentiality.
Audience has its own leading column. Publication details form a wrapping grid: date and updated date, author,
reporting period, or other useful context. Supply machine-readable dates with <time dateTime="…">; the host
owns the visible date format. Tags describe the subject rather than repeating the category or status.
Status and distribution remain separate badges. statusIcon and confidentialityIcon reinforce their visible
labels. Icons are decorative; “Draft”, “Confidential” and “Distribution unreviewed” remain readable without color.
Source evidence
Code
import type { ReactElement } from "react";
import { CalendarDays, CalendarRange, Code, History, LockKeyhole, Pencil, UserRound, Users } from "lucide-react";
import { ReportMetadata } from "@bosunkit/components/report-metadata";
export const description: string =
"Illustrative publication details with a reporting window, ownership and expandable source evidence.";
export default function PublicationDetails(): ReactElement {
return (
<ReportMetadata
label="Example report details"
category="Technical report"
reference="Engineering notebook · Example 014"
icon={<Code />}
accent="01"
status="Draft"
statusIcon={<Pencil />}
confidentiality="Confidential"
confidentialityIcon={<LockKeyhole />}
audience={{
term: "Prepared for",
icon: <Users />,
value: "Engineering and product reviewers",
hint: "Decision context, implementation evidence and open questions.",
}}
details={[
{ term: "Date", icon: <CalendarDays />, value: <time dateTime="2026-10-14">14 October 2026</time> },
{ term: "Updated", icon: <History />, value: <time dateTime="2026-10-14">14 October 2026</time> },
{ term: "Author", icon: <UserRound />, value: "Example engineering team" },
{ term: "Period", icon: <CalendarRange />, value: "October 2026" },
]}
tags={[
{ value: "architecture", label: "Architecture" },
{ value: "offline", label: "Offline systems" },
{ value: "example", label: "Illustrative" },
]}
>
<details>
<summary>Source evidence and distribution</summary>
<p>
Illustrative metadata only. In a real report, link the reviewed source revision and supporting records here.
</p>
<p>Confidential describes the intended audience. Access control belongs to the report host.</p>
</details>
</ReportMetadata>
);
}
Put optional provenance in the footer through children. A native <details> keeps a long source list compact
and supports keyboard disclosure. Use descriptive links to verified sources, and show a revision only when it is
known. The footer can also explain a distribution boundary; the badge itself does not enforce one.
Incomplete historical records
Code
import type { ReactElement } from "react";
import { Archive, CircleHelp, GitCommitHorizontal, Users } from "lucide-react";
import { ReportMetadata } from "@bosunkit/components/report-metadata";
export const description: string = "A historical record keeps missing dates and unreviewed distribution explicit.";
export default function HistoricalDetails(): ReactElement {
return (
<ReportMetadata
label="Historical example details"
category="Daily commits"
icon={<GitCommitHorizontal />}
accent="03"
status="Historical record"
statusIcon={<Archive />}
confidentiality="Distribution unreviewed"
confidentialityIcon={<CircleHelp />}
audience={{ term: "Audience", icon: <Users />, value: "Engineering" }}
details={[{ term: "Date", value: "Not recorded" }]}
/>
);
}
Unknown dates stay “Not recorded” and unknown distribution stays “Distribution unreviewed”. Omit unknown authors, issue identifiers and source links. A sparse record uses the same layout without empty placeholders or invented data.
Desktop composition and print behavior
On larger displays, the category and state badges share one header row, while the audience sits beside a grid of publication details. The inline example fits the documentation column; Desktop preview shows it at laptop and monitor sizes. At narrower widths the summary wraps, the audience and detail columns stack, and tags wrap. Long names and identifiers wrap without truncation. Keep the title and description in the page header once. Print keeps the metadata panel together when it fits; expand source evidence before printing when it is needed.
Props
| Prop | Type | Default | Description |
|---|---|---|---|
| labelrequired | string | – | Accessible name for the report details region. |
| categoryrequired | ReactNode | – | Display category; schema values and translations belong to the caller. |
| icon | ReactNode | – | Optional category icon. |
| reference | string | – | Optional issue, reporting window or document identifier, formatted by the caller. |
| accent | ReportAccent | "accent" | Editorial category color; it does not encode status or confidentiality. |
| status | string | undefined | – | Editorial status, independent of distribution. |
| statusIcon | ReactNode | – | Decorative status icon; the status text remains visible. |
| confidentialityrequired | string | – | Distribution intent; this label does not enforce access. |
| confidentialityIcon | ReactNode | – | Decorative distribution icon, distinct from editorial status. |
| audiencerequired | DescriptionListItem | – | Audience label, icon and description. |
| detailsrequired | readonly DescriptionListItem[] | – | Caller-formatted dates, author or other publication details. |
| tags | readonly ChipEntry[] | – | Optional display tags. |
| children | ReactNode | – | Supporting evidence, such as a source disclosure. |
Identify the source, audience and measurement boundary.
A polished report needs supported claims and explicit uncertainty.
Related
- Report blocks: facts and conclusions inside the report.
- Report types: required metadata and editorial forms.
- Description list: aligned terms, values and hints.