Library

The Library is SignStack's mechanism for sharing blueprints and templates across Namespace and even Organization boundaries. Namespaces (and orgs) are isolated by design — but real teams need to publish reusable building blocks: starter contracts, internal standards, white-label offerings. The Library is how that sharing happens, with explicit access control.

What Lives in the Library

Currently, the Library catalogs two kinds of resources:

• Blueprints — full signing workflows
• Templates — single document definitions

Each entry is a listing that points at a specific version (key@version) of a blueprint or template. Listings are immutable references — when you publish a listing for offer_letter@1.2.0, that exact version is what consumers see, even if you later cut 1.3.0 in your namespace.

Two Scopes

A listing is either public or org-scoped.

Scope	Who can see it
public	Any SignStack user. Useful for starter blueprints and open templates.
org	Only orgs (and optionally specific namespaces) you explicitly grant access to.

Org-scoped listings let you share with selected partners or sub-teams without publishing publicly. Each access grant names an orgId and either an explicit list of namespaceKeys within that org, or '*' for all namespaces.

Use Cases

• Starter blueprints — Publish a curated catalog of ready-to-fork agreements (NDA, consulting agreement, employment offer) so new orgs can get to a working contract in minutes.
• Internal distribution — Share a corporate standard (e.g., the legal team's approved NDA) across every tenant namespace in a multi-tenant product, while letting each tenant adapt the surrounding workflow.
• White-label offering — Distribute your domain-specific contracts to client orgs as ready-to-customize building blocks.

Try or Customize

Every listing exposes two actions:

• Try — Run a workflow directly against the listing. No fork, no copy in your namespace; the listing is the source of truth and the workflow runs against it as-is. Use this when the listing is exactly what you need and you just want to run it (once or many times).
• Customize — Use this when the listing is close to what you need but not quite. It opens as a draft in Studio that you can preview and iterate on without persisting. When you're happy, publish it as a versioned resource in your namespace and run workflows against it.

The Try action also has a programmatic equivalent: the create-workflow API accepts listingKey + listingVersion as one of its blueprint sources (alongside blueprintKey + blueprintVersion for in-namespace blueprints).

Versioning

Library listings reference immutable resource versions. Publishing a new version of a listing is how you ship updates — consumers who Try the listing run against the version they targeted, and consumers who Customize stay on the snapshot they forked until they choose to refork from a newer listing version. This is the same immutability story as the rest of SignStack's primitives, applied at the distribution layer.

Related

• Namespaces — Why isolation is the default and Library is the controlled escape hatch
• Blueprints and Templates — The units of what gets shared via the Library