> A read-only wiki of the entities and topics a publication covers, with weekly trends, sparklines and emerging clusters, built from the publication's own items. Beta; running on shipped.anth.us. The weekly run, the snapshot command, the blocks and how a site adopts it.

Canonical: https://p.apyr.us/public-knowledge-base.html

# A public knowledge base for a Papyrus publication

A Papyrus publication can show its readers what it knows. The items it has published are analysed once a week, and the result appears on the site as a read-only wiki of the things the publication covers, a page for each topic, and small trend figures: what is being mentioned more, what is new, and which themes are emerging.

This is Beta. It is released in Papyrus 5.22.0 and running on [Shipped](https://shipped.anth.us/), our own publication about AI models. Where this page says "an editor", that can be a person; today an AI agent does the reviewing on Shipped, and every page says so.

## What readers get

- **A wiki.** One page for each entity the publication has accepted: a maker, a model, a licence, a task. A page has a short description, a trend chart, the entities it is mentioned with, and links to the items that mention it. Pages are ordinary published pages with a Markdown twin and an entry in `llms.txt`. Readers cannot edit them; they can suggest an edit.
- **Topics.** A page for each topic the site has chosen as a beat, with its trend and the entities and themes that belong to it.
- **Weekly trends.** A trending strip and list of the entities that are being mentioned more, each with a sparkline and a change figure. The figure is always printed as text beside the mark, never shown by colour alone.
- **Emerging clusters.** Themes the weekly analysis found in the items, marked New, Growing or Cooling.
- **A concept of the week.** One entity with an accepted description, chosen by how much it appeared in the last four weeks.
- **A topic count.** "All 2 topics", linking to the topic pages.

Nothing is generated by a language model when a reader loads a page, and nothing is fetched in the browser. The pages are static HTML, drawn from small JSON files the weekly run writes.

## The weekly run

The heavy work runs on a workstation. The site's backend receives only small rows.

1. **Export the corpus.** `papyrus knowledge corpus export` writes the publication's published items to a [Biblicus](https://github.com/AnthusAI/Biblicus) corpus, with each item's id, URL, publication date, tags and entities.
2. **Topic model.** Biblicus runs a BERTopic topic model over the items with fixed settings, so one week can be compared with the next.
3. **Weekly bins.** `biblicus analyze topic-trends --bin weekly` counts the items per topic per ISO week.
4. **Cluster identity.** `biblicus analyze topic-identity` matches this week's clusters to last week's, so a cluster keeps the same id from run to run and is reported as new, continued, merged or split.
5. **Typed entities.** `biblicus extract typed-entities` finds entities and relations using a closed vocabulary the publication supplies: its own kinds such as maker, model, licence and task. It uses a small span model on the CPU, a registry of the entities already accepted, and no language model. Its own evaluation on Shipped's items found it good enough to propose entities for review and not good enough to publish without review, so everything it finds starts as a proposal.
6. **Publish the run.** `papyrus knowledge publish-run` imports the clusters, proposed entities and relations into the backend. It is a dry run until you add `--apply`.
7. **Review.** Someone accepts, renames, describes or rejects entities, clusters and relations with `papyrus knowledge entities`, `clusters` and `relations`. Each command requires `--actor ai` or `--actor human`, so the record says who.
8. **Snapshot.** `papyrus knowledge snapshot` writes the public data.

The same procedure, command by command, is in `docs/knowledge-workstation-run.md` in the Papyrus repository. The topic-identity and typed-entity commands are documented in Biblicus; at the time of writing they are in Biblicus's development branch and not yet in a numbered Biblicus release.

## The snapshot

```bash
papyrus knowledge snapshot --site-bucket <bucket> --entity-href '/wiki/{slug}/' --reproject
papyrus knowledge snapshot --out ./site-out
```

It reads the backend and writes JSON under `_data/knowledge/` in the site store, or in a local directory with `--out`. `--as-of` sets the date (default: the Monday of the current ISO week, UTC). `--reproject` then re-renders the pages that use the data. A file whose content has not changed is not rewritten, and the output has no timestamps, so two runs on the same records give the same files.

| File | Holds |
| --- | --- |
| `_data/knowledge/index.json` | Entity and topic counts, the kinds, the topics (beats) with their eight-week series, every accepted entity with its eight-week series and change, the trending order, and the concept of the week. |
| `_data/knowledge/clusters.json` | The latest run's clusters: name, who accepted it, item count, top terms, eight-week series, and its state. |
| `_data/knowledge/entities/<key>.json` | One entity: description and who edited it, eight- and 26-week series, change, neighbours and related items. |

Each file carries `schemaVersion: 1`. A file the site reads with another version, or invalid JSON, stops the build with a message that names the file.

## Blocks

Place a block in a page file with `::include`. Attribute values may be quoted or bare. An unknown attribute is a build error that names the file. The page's Markdown twin keeps the line as written, and a block whose data is absent draws nothing.

```markdown
::band{size="bare"}
## Moving this month
::include{kind="block" name="knowledge-trending-strip" limit=5}
::include{kind="block" name="knowledge-trending-list" limit=6 entityKind=""}
::include{kind="block" name="knowledge-clusters" limit=3}
::include{kind="block" name="knowledge-concept-of-the-week"}
::include{kind="block" name="knowledge-topic-count" count="beats" href="/topics/" label="All {n} topics"}
::include{kind="block" name="knowledge-beat" key="weaving" part="trend"}
::include{kind="block" name="knowledge-entity" key="acme-loom" part="trend" annotate="2026-09-24" annotateLabel="Launch"}
```

| Block | Attributes | Shows |
| --- | --- | --- |
| `knowledge-trending-strip` | `limit` (5) | A chip and trend for each trending entity. |
| `knowledge-trending-list` | `limit` (6), `entityKind`, `filter` (`true`) | A ranked list with the trend and item counts. Entities that are new are left out. With more than one kind, a filter of links by kind, with no script. |
| `knowledge-clusters` | `limit` (3), `terms` (5) | Named clusters with item count, top terms, sparkline, a New, Growing or Cooling label, and who accepted the name. |
| `knowledge-concept-of-the-week` | none | The entity, its description, who edited it, and its item and maker counts. |
| `knowledge-topic-count` | `count` (`beats` or `entities`), `href`, `label` | The count, optionally as a link. Nothing when the count is 0. |
| `knowledge-beat` | `key`, `part` (`trend`, `entities` or `clusters`), `limit` | One topic's trend, its top entities, or the clusters that overlap it. |
| `knowledge-entity` | `key`, `part` (`trend`, `neighbourhood`, `related` or `provenance`), `annotate`, `annotateLabel` | One entity's trend and chart, what it is mentioned with, its related items, or who accepted it and who edited its description. |
| `knowledge-score` | `value`, `n`, `threshold`, `label` | A score readout for a value the author gives. |

The blocks are server-rendered HTML with inline SVG sparklines. They are themed with `--papyrus-knowledge-*` custom properties, each with a fallback.

## How a trend is worked out

The snapshot holds the figure and the page shows it. The page never recalculates it, so the strip, the list and the entity page cannot disagree.

- **Weeks.** ISO weeks, Monday to Sunday, UTC. The series run oldest to newest and end with the week that contains the snapshot date.
- **Counts.** Items per week that have a confirmed link to the entity.
- **Change.** The items of the last four weeks against the four weeks before them: `round(100 * (last4 - prior4) / prior4)`. It is empty when the prior four weeks hold fewer than 5 items, or when the entity has fewer than 8 weeks of history. Twelve items against six is +100 percent for an entity with eight weeks of history, and no percent for one with six.
- **Trending.** Entities that are not new, ordered by the percent, largest first. Those with no percent come after, ordered by the change in item count.
- **Cluster state.** Growing at +20 percent or more, Cooling at -20 percent or less. New means the analysis reported the cluster as new and its earliest item is within four weeks.

A young entity or cluster does not get a dramatic figure from a handful of items:

| Weeks of history | Sparkline | Percent | Chart |
| --- | --- | --- | --- |
| under 4 | none; marked "new" | none | none |
| 4 to 7 | yes | none | none |
| 8 or more | yes | yes, when the base is large enough | none |
| 12 or more | yes | as above | the weekly chart |

## What is public, and who stands behind it

- **Only reviewed, published material.** The snapshot holds accepted entities only, published items only, and confirmed links and relations only. It reads no reference text, private note or message, and a name, alias, title or description that contains an email address is dropped. An entity with no confirmed link has no file.
- **Nothing is public until it is published.** `papyrus knowledge wiki sync` writes draft pages and never publishes them. `papyrus knowledge wiki publish` publishes them. A publish is refused for a wiki page that has no review stamp.
- **Every page says who.** The stamp sits above the text, with a mark as well as words. Today an AI agent accepts entities and publishes pages, so a page says "Accepted by AI" for an entity or cluster and "Edited by AI on 2026-10-22" for its description. A page a person has reviewed says "Reviewed by Ada on 2026-10-22" (or "Reviewed by an editor on 2026-10-22" with no name). A published page that somehow has no valid stamp says "Draft, not yet reviewed". Changed text loses the stamp of the text it replaced.
- **The record is the source.** Page text comes from the accepted entity. To change a page, change the entity and publish a revision; the live page stays as it is until then. A superseded page says so and links its replacement.
- **No names beyond what is needed.** A reviewer's name is optional and is never an email address.

## Adopt it on a site

The site needs the knowledge data and a few settings in `projection.json`. This is the wiki part, with a placeholder endpoint:

```json
{
  "urls": { "sections": { "wiki": { "label": "Wiki" }, "topics": { "label": "Topics" } } },
  "listings": { "types": ["article", "wiki_page"] },
  "components": { "itemPagesDependOn": ["posts"] },
  "forms": {
    "suggest-edit": {
      "title": "Suggest an edit",
      "endpoint": "https://<id>.lambda-url.us-east-1.on.aws/",
      "submitLabel": "Send suggestion",
      "fields": [
        { "name": "message", "label": "What should change?", "type": "textarea", "required": true },
        { "name": "email", "label": "Your email (optional)", "type": "email" }
      ]
    }
  },
  "wiki": { "suggestForm": "suggest-edit" }
}
```

1. Run the weekly run above, and accept some entities.
2. Add the settings above to `projection.json`. `itemPagesDependOn` names the sections that topic pages list from.
3. `papyrus knowledge wiki sync --apply` writes a draft page for each accepted entity, and for each topic when you give it a beat source (`--beats-config` or `--beats-category-set`).
4. `papyrus knowledge wiki publish --all-drafts --actor ai --apply` publishes them with a stamp.
5. Run `papyrus knowledge snapshot` with `--entity-href '/wiki/{slug}/'` so entity chips link to the pages.
6. Put the blocks on the pages where you want them.

With `wiki.suggestForm` set, the footer of every wiki page offers a "Suggest an edit" form. It posts to the site's public form endpoint and is stored as a private message for an editor to triage. The public page does not change when a suggestion is sent; an editor changes the entity and publishes a revision. Without an endpoint the form says it is not open yet and cannot be sent.

## The pilot: Shipped

[Shipped](https://shipped.anth.us/) shows a trending strip, trending topics, emerging clusters and a concept of the week on its front page, a [wiki](https://shipped.anth.us/wiki/), and topic pages such as [decision models](https://shipped.anth.us/topics/decision-models/). Read from its published data on 2026-10-22, for the week of 2026-10-19: 282 accepted entities in 9 kinds, 2 topics, 4 named clusters, and Hugging Face as the concept of the week. Those are one publication's figures, not a promise about yours; they depend on what a publication publishes.

What is not built yet: public editing, edit history, discussion and contributor counts. A reader can suggest an edit and nothing more.

The details for the people who run a publication are in the Papyrus repository: `docs/knowledge-snapshot.md`, `docs/knowledge-components.md`, `docs/public-wiki.md` and `docs/knowledge-workstation-run.md`. See also [Readable by agents and people alike](/agent-accessible.html) and [Built with Papyrus](/built-with/).