Governance Settings

Runway is installed once per enterprise workspace. Inside that installation, a tenant means an internal business unit, team, or other isolation boundary—not a separate Runway customer.

Event-sourced configuration

Every mutation requires a reason and records the actor, tenant, invocation, correlation ID, and resulting event. The Settings screen previews current and proposed policy values before submission. Policy saves carry the current event revision; a stale browser tab or agent plan is rejected instead of overwriting a newer administrator's change.

Bootstrap and authorization

RUNWAY_TENANTS_JSON is the installation bootstrap so the first administrator can enter the App. Runway replays every seeded member through runway.membership_set (administrators first) before the App starts serving requests. Once replayed, the event projection—not the environment variable—is authorization truth. Databricks user aliases and SCIM group IDs are resolved at authentication time, so a membership can target a workspace group without trusting a caller-supplied group header.

The platform-admin tenant is selected by RUNWAY_PLATFORM_ADMIN_TENANT_ID (or the first install seed for compatibility). Its administrators can invoke runway.tenant_provision; the trusted worker then runs runway.tenant_bootstrap inside the target boundary and records completion back in the platform-admin stream. New-tenant state is never written by a controller.

Retirement follows the same cross-ledger pattern: the platform administrator requests it, the trusted worker records it inside the target tenant, and the worker attests completion in the platform stream. The tenant then disappears from direct authorization and the org switcher, while its immutable event history remains available for audit. Retirement does not silently delete external workspace resources.

Until the first RunwayPolicySet event, Runway uses the deployment-provided App service-principal identity. After that event, the event-sourced worker allowlist is authoritative. A policy change that would remove every currently active App worker is rejected. Rotate deliberately:

1. add the replacement while retaining the active worker;
2. deploy both identities and verify a lease plus a harmless governed action;
3. switch execution and confirm the replacement claims work;
4. remove the retired identity using the latest policy revision.

If validation fails, keep the original worker authorized and roll back the runtime.

Pinned approval cycles

The first endorsement freezes the approval/evidence policy for that cycle: required gates, freshness, provenance, total and human thresholds, and agent eligibility. A later policy update cannot weaken—or unexpectedly tighten—the pending decision. The Approvals page shows both the pinned and current revisions when they differ.

To adopt current policy, a reviewer or authorized agent invokes runway.promotion_reopen with a reason. Runway discards every endorsement, returns the release to gate_passed, and records the old and new revisions. Each reopen mints a new cycle identity; approval and finalizer idempotency keys are scoped to it so a retry from an earlier cycle cannot suppress valid work in the new one. The next approval opens a new pinned cycle. Worker identities are intentionally not pinned, so removing a compromised worker takes effect immediately.

Retention fields are intentionally precise: audit retention is carried into exported evidence manifests, while the immutable Platform event ledger remains the source of truth; analytics retention controls the query/backfill window rather than deleting audit history.