GuideSystem3 min read
Parts, modules & shared code
Reuse the exact tools and files a work needs while keeping each artwork’s own identity.
Select an underlined word to see what it means.
In this guide
- 01One shared Part
Publish and check a reusable drawing tool
- 02Many projects
Choose that exact version of the tool
- 03Creator files
Each work adds its own sketch and choices
- 04New versions
Existing works keep the version they chose
A Part is something the work uses.
A drawing library, decoder, model, or data file can be a reusable Part. In the SDK these are often called modules. A module is a named, versioned package of code or data.
An Inlay is an attached component contributing to another work, such as equipment shown on a character. Its own identity and the host work’s rules still matter.
Find by name; check by Mark.
Search names and tags to find a useful module, then select its exact version and file identity. A name such as “p5” tells you what it does; its MarkA file's computed fingerprint, also called a digest or hash. A reader recomputes it to check the bytes.For exampleChanging the sketch's background color changes its Mark. A filename alone would not reveal that change.Full glossary entry → tells you which bytes you selected.
Choose a Part whose exact stored files can be recovered from your selected chain. Its catalog record identifies the version and where to find it.
Prepare a new Part for reuse.
Build the module, try it with its real dependencies, and record its attribution and usage terms. A publication plan shows the new bytes and any shared PartsReusable components included in a work, with their own identities and permissions.For exampleSeveral artworks can share the same verified drawing library.Full glossary entry → it reuses.
The commands below prepare a local module. They do not publish it or establish that it exists on a chain.
Local module preparation in a configured KEEL checkout
keel module init ./my-module
keel module build ./my-module
keel module plan ./my-moduleKeep the selected version visible.
A work should say which Part it depends on and whether that choice is pinned or can change under a stated policy. Review new code before an allowed update.
Technical detail: module binding
A module ID and version are discovery labels. A publication binding needs exact stored object IDs, digests, byte lengths, selected-chain catalog records, and read-back evidence. Dependencies belong in the manifest and lock data; unresolved or ambiguous entries stop preparation.
The work has modules. The tools have plugins.
A drawing library, a game engine, or a data layer can become a Part in the artwork. It travels in the work’s declared set of dependencies.
An editor or SDK plugin extends your working tools. Think custom admin controls or a new inspection panel. That extension system is planned. It should not be presented as an installed artwork module.
A similar name in the contract source
KeelPluginRegistry and IKeelContractPlugin describe contract capability records, including marketplace capabilities. They are a separate contract interface, not evidence that a general editor or SDK plugin marketplace has shipped.