Closing an organization

Open Administration → Lifecycle to see whether the selected organization is Active, Closing or Closed. The owner closes it from the same page. Closing is permanent: nothing reopens a closed organization, in the portal or through the API.

What closing does

The close is recorded in one step, and from that moment the organization accepts no new members, invitations, invitation acceptances, grants, runs, environment work or environment warm-up. An invitation issued earlier stops working. So do existing grants: no action is proposed under one, a pending action takes no more votes, and an approved action that has not started is not executed.

Every run that has not ended is then asked to cancel through the ordinary cancellation path:

The run was	It ends as
Queued and never started	cancelled, at once
Between steps, or waiting	cancelled
In the middle of an external effect whose outcome nobody can confirm	reconciliation_required
Already reconciliation_required	unchanged, awaiting a resolution

No run is abandoned while it can still act. The organization’s execution environments are removed only after every run has ended or is awaiting reconciliation, and a run whose cancellation cannot be delivered stops the closure and is escalated rather than skipped.

A run’s recovery checkpoint holds what the run was working on. It is kept only while a person still needs it: while its run awaits reconciliation, or while a hold names it. Every other checkpoint is deleted, and a checkpoint is never kept for a fixed period. The organization reads Closed once every execution environment, checkpoint, template and network policy is gone.

Close an organization

Only the owner closes an organization, signed in as a person. API keys, service accounts and workloads cannot, and neither can an admin. The portal lists what will happen, asks for a one-line reason and asks you to type the organization’s name. The server checks the owner’s authority and session again when the request arrives.

Closing under the same idempotency key returns the same closure. Closing an organization that is already closing or closed changes nothing.

Follow the closure

While the organization is closing, the page shows the current stage and what is left:

Stage	What is happening
fencing	The close is recorded and new work is refused
cancelling_runs	Runs are asked to cancel; the closure waits until each has ended or awaits reconciliation
cleaning_environments	Active execution environments and their network policies are removed
releasing_checkpoints	Checkpoints nothing needs are deleted
awaiting_reconciliation	A run awaits a resolution, and its checkpoint is kept for it
awaiting_hold_release	A hold keeps a checkpoint
removing_templates	Environment templates are removed and the removal is verified
deleting_namespace	The organization’s execution space is deleted
complete	Nothing is left; the organization is closed

The counts are active runs, runs awaiting reconciliation, retained checkpoints, holds in force, and the environments, checkpoints, templates and policies still to be removed.

Each step is recorded in an audit record of event kinds, counts and times. It never holds run content, environment contents, command output, credentials or checkpoint contents. It is kept for a set term after the closure completes, 365 days unless your installation sets another, and the closure reports that term as audit_term_days. When the term ends the audit record is deleted. Who closed the organization, when, and when it closed stay on the closure itself.

Resolve a run awaiting reconciliation

A run ends as reconciliation_required when an external effect may or may not have happened, during a closure or at any other time. Administration → Lifecycle lists these runs for anyone who reads runs: the run, its agent, the step whose outcome is unknown, when it ended, why, and whether its recovery checkpoint is still kept. A role that reads billing also sees the reservation behind that step.

The owner or an admin resolves one, signed in as a person, by recording what they found:

Outcome	Meaning
effect_completed	The effect happened
effect_not_completed	It did not happen
corrective_action	It was put right by hand
cancellation_finalized	The run stays cancelled and nothing more follows

Each resolution carries a reference to the evidence (a ticket, a provider receipt, a case number) and a note. It is written once and cannot be changed or deleted. Repeating the request under the same idempotency key returns the same result; a second resolution of the same run is refused with 409. Recording an outcome does not charge, refund or retry anything.

Once a run is resolved, its checkpoint is deleted unless a hold names it, and a closure waiting on it continues by itself. The run keeps its status; reading it returns the outcome and when it was recorded in its reconciliation field.

Holds

A legal or security hold keeps one run’s recovery checkpoint from being deleted, by the regular cleanup or by a closure. The owner or an admin places one as a person, with a reason and the case, matter or incident it is placed under. A closure stays Closing while any hold is in force.

Holds cannot be hidden or edited. The lifecycle page lists every hold, in force and released, with who placed it and when. Releasing a hold needs a person’s signed-in session, not an API key; the released hold stays listed with who released it and when, and its checkpoint is deleted once nothing else needs it. A checkpoint that is already deleted cannot be held. Holds keep checkpoints only; they do not extend the audit record.

HTTP and SDKs

Method and path	Who	Result
POST /katara/v1/orgs/{org_id}/close	Owner, as a person	The closure
GET /katara/v1/orgs/{org_id}/closure	Anyone who reads the organization	The closure
GET /katara/v1/orgs/{org_id}/reconciliations	Anyone who reads runs	Up to 500 runs, outstanding first, and in actions the actions from your own runtime whose outcome was unknown
GET …/environments/{environment_id}/runs/{run_id}/reconciliation	Anyone who reads runs	One run
POST …/environments/{environment_id}/runs/{run_id}/reconciliation	Owner or admin, as a person	The run with its resolution
GET /katara/v1/orgs/{org_id}/sandbox-holds	Owner or admin, as a person	Up to 500 holds, in force first
POST …/environments/{environment_id}/sandbox-holds	Owner or admin, as a person	The hold, 201
POST …/environments/{environment_id}/sandbox-holds/{hold_id}/release	Owner or admin, as a person	The released hold

An API key can read the closure, and the reconciliations of its own environment; it cannot close, resolve or hold. The permissions are org:close for closing, synapse:runs:reconcile for resolving and org:holds:write for holds.

const closure = await client.organizationLifecycle.closure(org_id);
for (const run of await client.organizationLifecycle.reconciliations(org_id)) {
  if (run.resolution) continue;
  // Only after a person has checked the evidence:
  await client.organizationLifecycle.resolve(
    { org_id, environment_id: run.environment_id }, run.run_id,
    { outcome: 'effect_not_completed', reference: ticket, note: finding }, originalRequestKey);
}

TypeScript exposes organizationLifecycle.close, closure, reconciliations, reconciliation, resolve, holds, placeHold and releaseHold. Python exposes organization_lifecycle.close, closure, reconciliations, reconciliation, resolve, holds, place_hold and release_hold. Both refuse an API key for the calls that need a person before sending anything, and neither retries a decision automatically.