Credit and Being Credited

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, collected when you import each file; see 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#

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 and Lifting Content 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 and naming its source:

• 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 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, 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.
• The scanner refuses the same manifest with 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.

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:

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 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 for the type field.