# Credit and Being Credited

> How a pack's listing page credits what it uses, how the reverse "Used by" listing works, and why credit is derived from dependencies rather than typed in.

- Source: https://diceytable.com/docs/mods/publishing/attribution
- Last verified: 2026-09-29

Every pack's listing page shows two things you never write yourself: **Uses** — the packs this
one is built on, each with its creator, its licence and a link — and **Used by** — everything
built on this one.

## The Uses list is never typed in, on purpose

Nothing in the **Uses** and **Used by** lists is typed in by an author, and there is no
free-text box for them anywhere in the publish flow. (Credit for your *own files* is a separate
record, [`credits`](https://diceytable.com/docs/mods/manifest/reference#credits), collected when you import each file;
see [Credits locked to a library item](https://diceytable.com/docs/mods/publishing/attribution#credits-locked-to-a-library-item) below.)

The Uses list is **derived from the dependency graph**. When you add a dependency on a published pack —
importing an Asset pack *by reference*, or assigning somebody else's Room or Table — the pin lands
in your manifest's `dependencies`, and the platform loads that pack in order to run yours. The
listing simply reads that. Which means:

- You cannot forget to credit something you depend on.
- You cannot credit something you do not actually use.
- A reader can check the claim, because the pin names an exact version and commit.

That is the whole reason the **Uses** list is worth reading, and it is why adding a field an
author fills in would make it worse rather than better.

## What the list shows

| Column | Where it comes from |
|---|---|
| Pack name and link | The registry entry for the pinned pack id |
| Creator | The DiceyTable account that published it, falling back to the GitHub owner |
| Licence | `license` in that pack's manifest, exactly as published |
| Version | The **exact pin** your manifest declares — never a range |
| Commit | The commit that version resolved to, when the registry recorded one |

If a pack you depend on has since been unpublished, deleted or taken down, the row **stays** and
says so. A credit does not stop being owed because the upstream vanished.

## Licences are shown, never checked

DiceyTable displays each pack's licence string as its creator published it, and does nothing else
with it. There is no compatibility check, no SPDX validation and no green tick — a machine verdict
derived from two strings would be false confidence, and the files are public on GitHub regardless.

**Read the licence of anything you build on.** It is shown on the pack's card when you add it, on
its own listing page, and on yours once you depend on it.

## Copied content: the "Also credits" section

Importing an Asset pack **vendored** ("Copy in"), or lifting a room, a table or a prefab out of a
published pack, deliberately does *not* create a dependency. The bytes become part of your pack,
and there is no pin for the graph to read — which is exactly what that mode is for.

Because the graph cannot see it, the editor writes a record instead: a file at
`attribution/lift-outs.json` in your repo, naming the pack, the exact version and commit, its
licence, and the specific items you took. It is committed and published with everything else, and
it appears on your listing page under **Also credits**.

Two things are worth being plain about:

1. **It is not verified.** DiceyTable does not check that the recorded credit is accurate or
   complete, and nothing refuses a publish whose ledger has been edited or deleted. The listing
   says so, and shows recorded credits in their own section rather than mixed in with derived
   ones.
2. **But it cannot be quietly withdrawn.** The record is read at the commit your version was
   published from, and a published version can never be repointed at a different commit. So a
   credit you published stays published — deleting the file changes only what your *next* version
   records. That is tamper-evident, which is a weaker guarantee than verified and a much stronger
   one than nothing.
3. **It is still the right thing to publish.** A vendored copy with no record is indistinguishable
   from original work. Leave the file alone, and it does its job.

If you want a credit that *is* verified, import by reference instead of copying. See
[Importing an Asset Pack](https://diceytable.com/docs/editor/workflows/import-an-asset-pack) and
[Lifting Content Out of a Pack](https://diceytable.com/docs/editor/workflows/lift-out-of-a-pack) for what each mode
does to your project.

## Credits locked to a library item

Some entries in `manifest.credits` are not yours to write. A file copied from a library item (a
DiceyTable preset, or a resource a plugin ships) carries **the source's own credit**, marked
[`locked`](https://diceytable.com/docs/mods/manifest/reference#credits) and naming its
[`source`](https://diceytable.com/docs/mods/manifest/reference#credits):

- **Read-only.** The credits editor shows a locked credit with a **Locked** badge and where it
  came from — *Preset: Oak planks*, or *Plugin: swtcg-deckdb @ 1a2b3c4* — and no way to edit,
  re-sign, merge, split or delete it. Files can't be moved into or out of it either.
- **Not asked about.** The import credit question is for files whose credit nobody knows yet.
  A locked credit is already known, so its files are not put to you.
- **Follows its files.** Moving or renaming a file moves its credit. Copying a file within the
  project adds the copy to the same credit. Deleting the file drops the credit once it credits
  nothing.

**Changing the bytes detaches it.** Replacing a linked file by importing over it, optimizing the
image or splitting the model **asks first**, because the new bytes are no longer the library's.
Confirm, and the file becomes a plain project file: its credit is no longer locked, and it keeps
a [`derivedFrom`](https://diceytable.com/docs/mods/manifest/reference#credits) note naming the source, so
attribution survives. From then on it is an ordinary credit you can edit, under the normal
re-signing rule. If the locked credit also covered other files that are still linked, only the
changed file is split out; the others stay locked.

## Credits an AI agent attested

An AI agent working in the editor may answer the import credit question itself, for the files it
imports. It sees the same three choices you do (your own work, somebody else's, or the
indemnity) and is sent the full wording of the one it picks. The record it writes says so: in
place of your signature it carries an
[`aiAttestation`](https://diceytable.com/docs/mods/manifest/reference#credits), which records:

- the version of the wording the agent was given;
- the agent session and the client that answered (the client's name is as it reported it, and
  nothing verifies it);
- when it answered;
- for a file fetched from a web address, the address the download ended on after redirects, the
  file's sha256 digest and size, and when it was fetched. The address that was asked for is the
  record's ordinary `sourceUrl`.

### A person reviews it before anything is published

Until somebody signs it, an AI-attested record is **unreviewed**, and **no publish goes through
while one exists** — by you, by a collaborator, or by any other route:

- The editor's publish is refused before `main` moves, with `409 ai-credits-unreviewed` and the
  ids of the records still waiting. See
  [The publish flow](https://diceytable.com/docs/mods/publishing/publish-flow#credits-an-ai-agent-attested-must-be-reviewed).
- The scanner refuses the same manifest with
  [`ai-credit-unreviewed`](https://diceytable.com/docs/mods/scanner/what-gets-rejected#ai-credit-unreviewed), so pushing
  it to GitHub some other way and registering it does not get round the review.

Reviewing is ticking each record you have checked and typing your name once. Each ticked record
gains a `review` **and** an ordinary signature with the same name, time and wording version. The
agent's record stays, so a reader can still see that an agent answered and a person checked. You
sign the wording shown at review time, which may be newer than the version the agent was given.
An agent cannot review anything, including its own records, and it cannot write a signature by
editing the manifest directly: its manifest edits refuse the `credits` field, and every credit it
records or changes is stamped as an agent record. See
[Mod Details: the Credits tab](https://diceytable.com/docs/editor/interface/topbar#mod-details-the-credits-tab).

**Check what you sign.** Your name on the record makes the claim yours, exactly as if you had
answered the question at import. For a fetched file, compare where the download ended up with
where it was supposed to come from. For the indemnity, read the wording again: you are the one
accepting responsibility.

### Re-signing: who made the edit decides

The credits editor's usual rule still decides *whether* an edit needs a fresh signature: changing
a record's origin or details, adding files to it (including by moving them in), or creating a
record does; removing files or deleting a record does not. What is new is *who* signs:

| Edit that needs a signature, made by | Result |
|---|---|
| An agent | Your signature and any review are dropped and a new agent record is stamped. A record you had signed becomes **unreviewed** again. |
| You, in the credits editor | You sign it. That counts as the review, and the record no longer blocks publishing. |

Edits that need no signature leave the record exactly as reviewed or unreviewed as it was,
whoever makes them.

### Older clients refuse these records

Nothing is migrated: the field is optional and an existing manifest is untouched. An editor tab or
server from before AI-attested credits existed does not know the field, drops it, and then sees an
unreviewed record with **no signature at all**, which it refuses. That is deliberate: an older
client fails closed rather than treating an agent's answer as yours. A **reviewed** record also
carries your ordinary signature, so older clients accept it. If an old tab refuses your manifest,
reload it.

## "Used by" — who is building on you

The reverse listing on your pack's page shows every published pack that pins yours, newest first
and paginated. It is derived from *their* published manifests, so it is exactly as complete as
what has been registered: a pack that depends on you but has never been published does not appear,
and neither does one whose own publish was refused.

Two consequences worth knowing:

- **An entry names a version.** A dependent pins one immutable version of your pack, so the list
  tells you which of your releases people actually build on.
- **Publishing a new version does not move anybody.** Dependents resolve the version they pinned
  until their author explicitly bumps it. See
  [Registration & Multiplayer Play](https://diceytable.com/docs/mods/publishing/registration-and-play) for how a pinned
  version is served.

## Browsing by type

Packs are browsable by what they are — Games, Rooms, Tables and Asset packs — at `/packs`. A
pack's type is fixed at first publish and cannot be changed afterwards, which is what makes that
listing trustworthy; see [Manifest Reference](https://diceytable.com/docs/mods/manifest/reference) for the `type` field.