Timeline & audit trail

Timeline states

1. ✓
   Completed: Submitted

   R. Vance · 2026-08-10 09:14
2. ●
   Cost-center approval

   waiting · 2 days
3. ✕
   Rejected: Finance release

   budget hold
4. 4
   Not started: Archive

<ol class="bo-timeline" role="list">
  <li class="bo-timeline__step" data-state="done">
    <span class="bo-timeline__marker" aria-hidden="true">✓</span>
    <div>
      <div class="bo-timeline__title"><span class="bo-visually-hidden">Completed: </span>Submitted</div>
      <div class="bo-timeline__meta">R. Vance · <time datetime="2026-08-10T09:14">2026-08-10 09:14</time></div>
    </div>
  </li>
  <li class="bo-timeline__step" data-state="current" aria-current="step">
    <span class="bo-timeline__marker" aria-hidden="true">●</span>
    <div><div class="bo-timeline__title">Cost-center approval</div></div>
  </li>
  <li class="bo-timeline__step" data-state="rejected">
    <span class="bo-timeline__marker" aria-hidden="true">✕</span>
    <div><div class="bo-timeline__title"><span class="bo-visually-hidden">Rejected: </span>Finance release</div></div>
  </li>
  <li class="bo-timeline__step" data-state="pending">
    <span class="bo-timeline__marker" aria-hidden="true">4</span>
    <div><div class="bo-timeline__title"><span class="bo-visually-hidden">Not started: </span>Archive</div></div>
  </li>
</ol>
<!-- Two-channel per state: the marker glyph + tint is one channel; the
     visually-hidden "Completed:/Rejected:/Not started:" prefix (and
     aria-current on the active step) is the announced one. -->

Audit trail

1. 08-10 09:14 R. Vance submitted PO-88213
2. 08-10 15:02 J. Kim approved "Within Q3 budget."

Rejected → resubmitted — the real approval loop

1. 08-11 10:20 M. Osei rejected "Wrong cost center — should be CC-2205, not CC-4021."
2. 08-11 11:05 R. Vance updated cost center and resubmitted
3. 08-11 14:41 M. Osei approved

The loop every ERP actually runs: rejection with a reason in __detail, a fix, a resubmit. In the paired timeline the step flips data-state="rejected" → back to current on resubmit — the audit trail keeps the full history while the timeline shows only the present.

--discussion — a comment thread

A discussion is the same list carrying a different kind of entry, so it is a setting, not a second component. An audit trail's __detail is small print about a record; a comment is the content itself. Composing a thread without this modifier rendered the message at 12px underneath a 13px byline — the metadata outranking the thing it introduces — so --discussion returns the detail to body size and primary ink. Everything else is already shared: the time column, Byline for the author, .bo-composer below to write one.

<!-- Same list, different kind of entry. --discussion says the
     detail IS the content, so it keeps body size and primary ink. -->
<ol class="bo-audit bo-audit--discussion" role="list">
  <li class="bo-audit__entry">
    <time class="bo-audit__time" datetime="2026-08-20T09:12">08-20 09:12</time>
    <div class="bo-audit__detail">
      <span class="bo-byline"><strong>M. Osei</strong> · Requester</span>
      <div class="bo-prose"><p>Vendor confirmed a 3-week lead time on the coupling.
      Asked whether we split the line and take 40 now.</p></div>
    </div>
  </li>
  <li class="bo-audit__entry">
    <time class="bo-audit__time" datetime="2026-08-20T11:40">08-20 11:40</time>
    <div class="bo-audit__detail">
      <span class="bo-byline"><strong>J. Kim</strong> · Cost-centre manager</span>
      <div class="bo-prose"><p>Split it — budget is committed either way and the
      line stoppage costs more than a second delivery.</p></div>
    </div>
  </li>
</ol>

Use it for approval notes, chasing history and handover threads. It is a flat thread on purpose — no nesting, no replies-to-replies, no left/right bubbles. Those are messaging-app shapes; an ERP discussion hangs off a record and reads in one order.

Collaborating — who can see this, and what is settled

A thread people act on needs two things a thread people only read does not. data-visibility="external" marks a comment that leaves the building, and data-state="resolved" marks a question that is settled.

<!-- Internal is the default: no attribute, no edge. -->
<ol class="bo-audit bo-audit--discussion" role="list">
  <li class="bo-audit__entry" data-state="resolved">
    <time class="bo-audit__time" datetime="2026-08-21T08:05">08-21 08:05</time>
    <div class="bo-audit__detail">
      <span class="bo-byline"><strong>M. Osei</strong> · Requester</span>
      <span class="bo-badge">Resolved</span>
      <div class="bo-prose"><p>Split raised as PO-88240 for the balance.</p></div>
    </div>
  </li>
  <li class="bo-audit__entry" data-visibility="external">
    <time class="bo-audit__time" datetime="2026-08-21T09:30">08-21 09:30</time>
    <div class="bo-audit__detail">
      <span class="bo-byline"><strong>M. Osei</strong> · Requester</span>
      <span class="bo-badge bo-badge--warning">External · sent to vendor</span>
      <div class="bo-prose"><p>Please confirm the revised delivery date for the
      40-unit first drop.</p></div>
    </div>
  </li>
</ol>

<!-- The COMPOSER carries it too, which is the point: you can see where the
     words go while you are writing them, not after. -->
<form class="bo-composer" data-visibility="external">
  <span class="bo-avatar bo-byline__avatar" aria-hidden="true">MO</span>
  <div class="bo-composer__body">
    <span class="bo-badge bo-badge--warning">External · goes to the vendor</span>
    <label class="bo-visually-hidden" for="c-ext">Message to vendor</label>
    <textarea class="bo-input" id="c-ext" rows="2"></textarea>
    <div class="bo-composer__actions">
      <button class="bo-btn bo-btn--sm" type="button">Send to vendor</button>
    </div>
  </div>
</form>

Internal is the default — no attribute, no edge. Getting the hook wrong then means a message that should have gone out stayed in, which someone chases; the reverse is unrecoverable, which is why the dangerous direction is the one you have to type.

The edge is geometry, and the badge is the other channel. The stripe survives forced-colors and a monochrome print, but a stripe alone tells a screen-reader user nothing — so name the audience in a badge, as above. That is your text to write: "External \u00b7 sent to vendor" is useful, "External" on its own is not.

Why the composer carries it as well. Every ERP we measured against puts this on a small tab pair above an otherwise identical box — so the surface you are looking at while you type is the one thing that never says where the words are going, and a mis-click is a broadcast. Marking the composer means the answer is in front of you at the moment it matters. Not a permission check: this is a signal, and the server still decides who may post what.

Resolved returns the comment to the audit trail's own treatment, because that is what it now is — history. Only a --discussion resolves; an audit entry is immutable by definition. A visible "Resolved" marker is required, not optional — measured under forced-colors: active, the UA repaints both inks to the same black, so the ink difference is the whole signal in normal use and no signal there. The external edge is geometry and survives; this state has no non-colour channel of its own, so the marker is it.

.bo-composer — writing a new entry

How a new .bo-audit entry gets written, not just read. Layout only: an avatar (.bo-byline__avatar, composed — not duplicated) + a plain .bo-input textarea + an actions row.

<form class="bo-composer">
  <span class="bo-avatar bo-byline__avatar" aria-hidden="true">RV</span>
  <div class="bo-composer__body">
    <textarea class="bo-input" rows="2"
              placeholder="Add a comment…" aria-label="Comment"></textarea>
    <div class="bo-composer__actions">
      <button class="bo-btn bo-btn--sm bo-btn--secondary" type="reset">Cancel</button>
      <button class="bo-btn bo-btn--sm" type="submit">Comment</button>
    </div>
  </div>
</form>
<!-- Submit posts a new .bo-audit__entry — your form handler's job, server or JS. -->

Markup — audit entry

<ol class="bo-audit" role="list">
  <li class="bo-audit__entry">
    <time class="bo-audit__time" datetime="2026-08-10T15:02">08-10 15:02</time>
    <span><span class="bo-audit__actor">J. Kim</span> approved</span>
    <span class="bo-audit__detail">"Within Q3 budget."</span>
  </li>
</ol>
<!-- Grid-aligned: the time column self-sizes; details land in the content
     column automatically — no width tuning when formats change. -->

Quick reference generated

State attributes: data-statedata-visibility

API generated from CSS

• State text pattern is mandatory: Completed: / Rejected: / Not started: visually-hidden in the title — done vs rejected must be distinguishable non-visually.
• Use <time datetime> for audit timestamps.
• Markers are fixed-size status graphics (not controls) — they deliberately ignore density.
• .bo-composer is layout only — the textarea is a plain .bo-input, the avatar is .bo-byline__avatar; submit handling (posting a new .bo-audit__entry) is your form handler.

Maturity generated

Introduced

v0.1.0

CSS floor

Chrome/Edge 99 · Firefox 97 · Safari 15.4

Alignment scored

2026-08-21

Assistive-tech evidence

None recorded

Pin this component's first release with npm i @busy-office/ui@0.1.0. The floor is derived from this component's stylesheet alone — set by @layer — so it sits at or below the whole framework's Chrome/Edge 119 · Firefox 129 · Safari 17.5. No assistive-technology runtime result is recorded for any component: it needs a human listening to VoiceOver and NVDA on owner hardware; no gate in this repo can simulate announcement behaviour. What automation covers instead is test:axe across every page at 1440 and 390, and check:forced-colors — see accessibility.

Design-system alignment generated

100% (15/15) — how closely this component follows the design language. Each rule is scored 0-3 against a checkable citation; rules that don't apply leave the denominator. Scored 2026-08-21.