Documentation
Publishing
The registry accepts only artifacts that carry their own provenance — so publishing is CLI-only, never an upload form. Gemara artifacts go through grcli; evaluators through pvtr.
Publishing artifacts (grcli)
After signing in, validate the bundle locally against a checkout of the Gemara spec, then publish it:
$grcli validate -f <bundle>.yaml --spec <path-to-gemara-checkout> $grcli publish <bundle>.yaml
grcli reads the version from metadata.version, signs and publishes the bundle,
and the hub indexes it. You may publish if either you hold the
write:<Type> role for that artifact type, or you are a member
of the publishing organization (organization membership grants publish authority to that namespace). A member
of finos-ccc can publish controls under finos-ccc
either way.
Versions are immutable: re-publishing the same body at the same version is idempotent, but a different
body at an existing version is rejected — bump metadata.version per release.
Every artifact page links to a per-artifact publish helper with the exact commands.
Publishing evaluators (pvtr)
Evaluator plugins are published with Privateer's
pvtr publish. Publishing is authorized by namespace ownership —
you can publish to <namespace>/plugins/<id> only for a namespace
you own — and the plugin index must be cosign-signed; the hub verifies that signature at ingest.
Trusted publishing from CI
From GitHub Actions, no sign-in is needed — the workflow's own OIDC token does secret-less trusted publishing, once an organization admin has registered the repository as a trusted publisher. This is the recommended path for both artifacts and evaluators.
📖 The full publish contract for evaluators (index shape, signing, the/sync step) lives with Privateer at
privateerproj.com.