Artifact and vendor governance separates source-controlled project intent from transient local build state. The standard gives packages a way to identify committed binaries, release bundles, vendored source, generated source, public reference assets, private fixture sets, and release channels without treating every local compiler output as a durable artifact.
dev-std.toml remains the package policy switchboard. Detailed
inventories live in authored governance catalogs under
docs/governance/.
artifacts.toml governs committed or otherwise intentional artifacts.vendors.toml governs committed vendored source and vendor drops.release.toml governs release channels and publishing processes.Artifact governance distinguishes transient build output, package distribution output, committed runtime artifacts, application/plugin bundles, fixture data, public reference assets, vendored runtime artifacts, generated source, oracle outputs, and release evidence.
Default audit is tracked-file-first. Ignored local paths such as
build/, output/, temp/,
rack_results/, and local staging under dist/ do
not fail the default audit. Explicit release or evidence modes may inspect
produced outputs, checksums, licenses, and channel inclusion.
Vendored source under roots such as vendor/ or
third_party/ requires a machine-readable vendor entry. Vendor
entries identify upstream name, version or commit, source URL or archive,
checksum when available, license file, local patches or pruning, consumers,
update command, and owner.
The shared governance catalog for new work is
docs/governance/vendors.toml. Each [[vendors]]
entry identifies an id, kind, name,
upstream_url, version, license,
owner, update_command, covered
paths, and consumers. The catalog is the package
source of truth for committed vendored source, minified JavaScript, WASM,
fonts, generated support bundles, and similar retained third-party drops.
Package-local JSON files such as vendor_manifest.a0.json are
compatibility inputs when an existing tool already consumes them. They may
continue to use a root schema field, but they do not replace
the shared vendor catalog unless the package explicitly documents an
adapter or compatibility path that maps the local manifest into
docs/governance/vendors.toml.
Committed generated source is an artifact class. Its catalog entry records the source of truth, regeneration command, retention policy, and verification refs. This keeps generated code visible without asking normal source-domain audits to treat it as hand-owned implementation.
A configured package distribution such as pypi requires a
release catalog. Release channels describe the publication process for
PyPI, GitHub releases, native or WASM bundles, app/plugin packages, object
store uploads, and future package-manager automation.
Each release channel must identify both a process_doc and a
build_doc. The process document explains how the channel is
published. The build document explains required tools, setup, invocation,
packaging outputs, and the distinction between local build output and
promoted release artifacts. A package may use the same document for both
fields when the setup and release process are intentionally combined.
Canonical package build documentation is audited by docs.build
and should normally live at docs/build.html or
docs/build.md.
Native and WASM paths such as dist/native/windows-x64/ and
dist/wasm/browser/ are useful conventions when a package
promotes those outputs. They are not mandatory for every mixed/native
package.
docs.artifacts validates artifact catalog coverage.docs.vendors validates vendored-code catalog coverage.docs.release validates release-channel governance.