Docs · Ops

Ops

Pillars are what you author. Ops is how the product lives and how you ship it.

The four pillars — Experiences, Workflows, Knowledge, Integrations — are the atoms of a Semantic Application. Around them, Closure runs Ops:

Concept	Role	Promote?
Runs	Durable workflow executions	No — per environment
Events	Organizational memory on the graph	No — per environment
Issues	Judgments from analysis / drift scans	No — per environment
Goals	Declared product intent	No — per environment
Versions	Org Releases (snapshots + Dev → Test → Prod pins)	Yes — application pillars only

Dev (live) ──snapshot──► Org Release ──promote──► Test / Prod pins
                              │
                         Experiences · Workflows · Knowledge · Integration config
                              │
                         Secrets / seals stay per-env (never in the Release)

In the console header: Dev | Test | Prod switches org context; the Ops icon opens Runs · Events · Issues · Goals · Versions.

Versions (Releases)

An org Release is an immutable snapshot of application pillars. Promote pins that Release to Test or Prod. Experience-only promote still works and dual-writes a Release. See Ops → Versions in Closure.

Runs · Events · Issues · Goals

Unchanged runtime loop — now scoped by the header environment. Webhooks require ?env=dev|test|prod.

Why this split

Pillars	Ops
Authored atoms you compose into a product	Runtime loop + release control plane
Experiences · Workflows · Knowledge · Integrations	Runs · Events · Issues · Goals · Versions
“What is the product?”	“How is it running, and what is shipped where?”