Reagents · bundles

Ship what you built,
not a screenshot of it.

Reactions need reagents. In Quadrazene the capability itself is one: a signed, portable bundle of the Skills, Formulas, Chains, dashboards and APIs you authored, installable into another tenant or another deployment without hand-rebuilding any of it.

Signed .qzrDependency walkDiff before importSource bindingProvenance
quadrazene.app/reagents/import
quadrazene v0.2.16
Quadrazene
ReactorReactionsReagentsRecipesRefineriesRegulationsResolverRecordsInbox
⌘K
claims-playbookv1.4.0signature validfrom tenant: northwind-prod
Plan · what this import will do
skillsummarize-claimcreate
formulatriage-claimnew version 3
chainclaim-escalationcreate
dashboardClaims throughputcreate
formulaclose-claimunchanged
Bind data sources
claims-warehouse→Snowflake · Claims (prod)
itsm→choose a Connection…

The lifecycle

Six verbs, from author to monitor.

Create, read, update and delete already existed for each entity. Reagents add the cross-entity half.

01

Export

Pick a root; the platform walks its dependencies and builds a manifest.

02

Sign

A tenant key or the platform key signs the content hash.

03

Import

Verify the signature and see exactly what would change.

04

Bind

Map each data-source slot to a real System or Connection here.

05

Provision

Commit through the platform’s normal versioning path.

06

Monitor

Every imported entity records which Reagent and version produced it.

What goes in

Everything you author, in one envelope.

References inside a bundle are by name and version, never by database id, so it moves cleanly between tenants.

AtomsFormulasChainsSkillsViewsDashboardsApplicationsAPI definitionsAPI endpointsLLM profilesModelsFine-tune jobs

Built to be trusted

Inspectable, verifiable, and safe to install.

Plain JSON, not a blob

A .qzr file is meant to be opened, diffed and reviewed like any other artifact, not treated as an opaque binary.

Two signing tiers

A tenant can sign its own bundles with its own key, or the platform can sign with a dedicated key that is separate from the license-signing key.

Content hash

The signature covers a hash of the contents, so a bundle that was edited after signing fails verification on import.

Credentials never travel

A bundle names the data source it needs as a slot. The secret is never in the file; you bind a real System or Connection on the way in.

Diff before you commit

The import shows every entity as create, new version or unchanged before anything is written.

Versioned, not clobbered

Where an entity already exists, provisioning rolls it to a new version through the same versioning path as an edit in the UI.

What it unlocks

Promotion, distribution, and a paper trail.

Dev to prod

Build and test in one tenant, then promote the exact tested capability into production rather than rebuilding it.

Partner and reseller kits

Hand a customer a signed starter pack of Skills, Chains and dashboards for their deployment.

Air-gapped installs

A bundle is a file, so it crosses an air gap the same way a license does.

Provenance

Every entity created by an import records the Reagent and version that produced it, so 'where did this Chain come from?' has an answer.

Bundles and Import in the nav

Export and browse under Reagents, install from the Import page. Mailbox and Intake sit alongside as the data-side reagents.

Licensed as authoring

Reagents ride with Automation Authoring, so they appear only where that is licensed.

Move a capability between environments.

We'll export a real Chain from one tenant and import it into another, diff and all.