Using the Knowledge Library

The Knowledge Library page is where Radiant lives as a document you can actually read and shape. Everything Upside knows about how your account buys, renews, and operates sits here as a brief, kept current by your team and the mining agent, and verified before it's published.

It reads like a document and works like a review queue. The left side is the brief itself. The right side is where changes are proposed, reviewed, and published as clean, numbered versions.

---

Start here: the three ideas

Almost everything on the page follows from three ideas. Get these and the rest is detail.

---

What you're looking at

The masthead is worth a second look, since it changes with your role. The Version N chip is a button for admins (it opens the full library history) and a plain label for members. The pending-changes line is worded for you too: "N changes awaiting review" for admins, "N suggestions of yours pending" for members.

---

How a change flows

Every change (an edit, a new fact, a new topic) travels the same path. Publishing is deliberate and batched, so each version is a coherent snapshot rather than a stream of one-off edits.

Not every proposal makes it to "published." All told, a proposal lands in one of five states:

---

Working in the document

This is what everyone can do, member or admin. It all happens on the left side, right in the brief.

Reading a fact

Facts are grouped into topics, each with a heading, an optional description, and its published facts as short paragraphs. Facts with no topic collect under an Uncategorized section.

Under each fact, a quiet provenance line carries the details without cluttering the read:

• a ✓ Verified marker,
• who proposed it (a teammate, the mining agent, or the system),
• the source citation, if one was given,
• and, for admins, a version(s) chip that opens the fact's history plus a Remove control.

Suggesting an edit

Hover any fact and a ✎ Suggest an edit badge appears. Click it to open an inline editor pre-filled with the current text, make your change, and choose Suggest change. The label is deliberate: you're proposing, not overwriting. Your edit is tracked and routed to review.

Adding a fact

At the bottom of every section is + Add a fact to [Topic]. Write the fact, add an optional source, and choose Propose fact. It stays pending until an admin reviews it.

Starting a new topic

Below the last section, Start a new topic opens a small composer for knowledge that doesn't fit the existing groups. Name the topic, add an optional description and a first fact, then Propose topic. Both the topic and its first fact enter review together.

Following your suggestions

Your own proposals appear in the right-hand rail under Your suggestions. Each card reads Awaiting admin review, with a Withdraw link to retract it before it's reviewed. Once an admin accepts it, the card shows it's approved and pending publish.

Spotting tracked changes

Pending changes render right in the document, so the brief and the review queue always tell the same story:

• Edits to an existing fact show a word-level redline (removed words struck through in red, added words underlined in green) inside an amber-ruled block.
• New facts appear as green-ruled blocks beneath a section's published facts, attributed to whoever proposed them.
• Hovering a change in the document highlights its card in the rail, and vice versa. Click a tracked change to jump straight to its review card.

---

Reviewing and publishing

This is the admin's job, and it all happens in the Review changes rail on the right.

Accepting and rejecting

Every pending suggestion across the account lands in the rail as a card showing the proposer, the timing, the topic, whether it's a New fact or an Edit, and the proposed text (edits with an inline redline).

• Accept stages a suggestion; Reject opens a dialog for a required reason the proposer will see.
• Select all plus Accept N / Reject N handle a batch in one move.
• Accepted items collect under Approved for the next version; Un-stage sends one back to pending.

Removing an outdated fact

Facts get outdated. On the provenance line, an admin can choose Remove to stage a published fact for deletion from the next version. The fact shows struck through, and the rail lists it under the facts to be removed. Keep in library un-stages it. Nothing actually leaves the brief until you publish.

Publishing a version

Publishing turns everything staged (accepted edits, new facts, and removals) into a single numbered version. It's the one moment changes go live, which keeps every version clean and reviewable.

---

Version history and rollback

Per-fact history

The version(s) chip under a fact opens its Version history: every published revision, newest first, each superseding the one below. The current revision is badged Current. Admins get Restore this version, which proposes that older text as a new pending edit; it doesn't change the live brief directly.

Library version history

The masthead Version N chip (admin) opens Library version history: every published snapshot, newest first, with its publish date and note. Any non-active version offers Roll back to this version, which re-points the active library to that snapshot.

---

Quick reference

Actions by role

Keyboard shortcuts