Operator guidance for capability approvals, lifecycle blocked actions, and quarantine behavior

Runtime Membrane Operations

Phases 7.3 and 7.4 introduce governed runtime membrane and lifecycle controls for package execution. This playbook covers how to interpret and handle approvals, blocked actions, lifecycle outcomes, and quarantine states.

Capability Approvals

When approvals are required

Approvals are required when:

requires_approval is true for the requested capability/action
install or update introduces capability expansion (PKG-002-CAP_EXPANSION_PENDING)
import posture requires receiving-instance re-verification/re-approval (PKG-008-*)

Approval flow

Package request enters membrane admission.
Runtime checks trust/signature/policy compatibility.
Lifecycle gate checks transition validity and current package state.
Capability grant is validated (scope, status, expiry, replay state).
Membrane/lifecycle emits allow, deny, quarantine, rolled_back, or disabled with a reason code.

Scope and anti-replay

Capability grants are constrained by:

package_id
project_id
capability
action surface/action name scope
expires_at validity window
nonce replay protection (single nonce cannot be reused)

Replay attempts are denied with PKG-002-CAPABILITY_REPLAY_DETECTED. Expired grants are denied with PKG-002-CAPABILITY_GRANT_EXPIRED.

Blocked Actions (Deny)

deny means the requested action is blocked for this request and does not execute.

Common deny reason codes

Reason code	Meaning	Operator interpretation
`PKG-002-CAPABILITY_NOT_GRANTED`	Capability not declared or approved	Package lacks required permission for this action
`PKG-002-CAPABILITY_SCOPE_MISMATCH`	Grant scope does not match requested action	Grant is valid but not for this surface/action
`PKG-002-CAPABILITY_GRANT_EXPIRED`	Approval grant expired	Re-approval required
`PKG-002-CAPABILITY_REPLAY_DETECTED`	Grant nonce replay detected	Security protection triggered; investigate duplicate/replayed request
`PKG-002-CAP_EXPANSION_PENDING`	Update/install adds capability scope	Explicit re-approval required before transition can continue
`PKG-003-DIRECT_ACCESS_DENIED`	Direct host access attempted	Package attempted forbidden direct access outside membrane
`PKG-003-POLICY_INCOMPATIBLE`	Policy/control-state incompatible	Project/runtime policy currently blocks this request
`PKG-003-API_RANGE_MISMATCH`	Package API contract incompatible with runtime	Update/import/install cannot proceed until compatible package/runtime version is used
`PKG-004-UPDATE_STAGE_CHECK_FAILED`	Staged update checks did not pass	Review compatibility, migration, and health check evidence before retry
`PKG-004-ROLLBACK_TRUST_CHECK_FAILED`	Rollback target failed trust/verification checks	Package is forced to safe disabled posture until trusted rollback target exists
`PKG-005-INVALID_TRANSITION`	Lifecycle transition is not allowed from current state	Request sequencing is invalid; run required prior transition first
`PKG-005-REMOVE_RETENTION_DECISION_REQUIRED`	Remove requested without retention decision	Supply explicit `export_then_remove` or `delete_confirmed` decision
`PKG-007-RE_TRUST_REQUIRED`	Cross-instance trust cannot be auto-transferred	Complete receiving-instance trust workflow
`PKG-008-IMPORT_VERIFICATION_PENDING`	Imported package not yet re-verified/re-approved	Keep blocked until verification and approval complete

Lifecycle Outcomes (Phase 7.4)

Lifecycle orchestration now enforces deterministic transitions for:

ingest -> install -> enable
enable -> stage_update -> commit_update
stage_update -> rollback_update (or forced disabled on trust failure)
export/remove with explicit retention posture
import -> import_verified -> enable

Update and rollback handling

stage_update records a previous safe version snapshot.
Compatibility, migration, and health checks run before commit.
If commit checks fail, lifecycle transitions to deterministic rollback behavior.
If rollback target trust checks fail, package transitions to disabled (fail-closed).

Remove handling

Remove is blocked until one of:

export_then_remove
delete_confirmed

is explicitly provided and evidence-linked.

Quarantine Behavior

quarantine is stronger than deny. It indicates package runtime posture is unsafe or untrusted and execution must remain blocked until remediation.

Typical quarantine triggers

Invalid signature posture
Unknown or revoked signer state
Import/re-verification posture not satisfied

Deny vs Quarantine

deny: Request-level block for the specific action.
quarantine: Package/runtime-level safety state requiring remediation before further execution.

Remediation guidance

Verify signer/trust evidence and package provenance.
Complete required re-verification/re-approval workflow for imported or changed package state.
Confirm lifecycle transition ordering is valid for the requested action.
Confirm policy/control-state allows execution.
Retry only after posture is restored and a valid scoped approval grant exists.

Runtime Membrane Operations

On this page