Gating

This page documents MobKit v0.8.34 (mirrored from v0.8.34). Gating is a policy service owned by the MobKit runtime. A caller submits an action, actor, and risk tier. The runtime evaluates that request, records the result, and may create a pending approval entry.

Gating does not perform the proposed action. The caller must enforce the returned outcome before it invokes delivery, changes state, or performs another side effect.

There is no gating module or gating MCP tool. The runtime implements the evaluate, pending, decide, and audit contracts directly.

Risk tiers

GatingRiskTier is serialized in snake case as r0 through r3:

Tier	Default outcome	Runtime behavior
`r0`	`allowed`	Allow immediately and write an `evaluated` audit entry
`r1`	`allowed`	Allow immediately and write an `evaluated` audit entry
`r2`	`allowed_with_audit`	Allow with consequence-mode audit unless conflict handling falls back to `safe_draft`
`r3`	`pending_approval`	Create a pending entry unless conflict handling falls back to `safe_draft`

For r2 and r3, memory-conflict policy can override the default. It returns safe_draft when the referenced memory is conflicted, required conflict context is missing while conflicts exist, or the memory conflict lookup fails.

Evaluation contract

The evaluate request has this wire shape:

{
  "action": "send_customer_update",
  "actor_id": "agent-lead",
  "risk_tier": "r3",
  "rationale": "The customer requested an update",
  "requested_approver": "human-reviewer",
  "approval_recipient": "review-queue",
  "approval_channel": "notification",
  "approval_timeout_ms": 60000,
  "entity": "customer:42",
  "topic": "outbound_status"
}

Only action, actor_id, and risk_tier are required. MobKit mints the action_id. A GatingEvaluateResult returns:

action_id, action, actor_id, and the effective risk_tier
one of allowed, allowed_with_audit, pending_approval, or safe_draft in outcome
pending_id when approval is pending
fallback_reason when conflict policy forced safe_draft

When the stdio rpc_gateway loads an actions map from runtime_options.gating_config_path, the configured tier for a matching action is authoritative. It replaces a caller-supplied risk_tier before evaluation.

Pending approval

An r3 evaluation creates a GatingPendingEntry with the action and actor identity, optional requested approver and notification fields, and created_at_ms and deadline_at_ms timestamps. If both approval_recipient and approval_channel are present, the runtime attempts to route and send a gating_approval_request through the loaded router and delivery modules. A missing module or failed notification is recorded in the pending_created audit detail. It does not prevent the pending entry from being created. Approval timeouts default to 60 seconds and are clamped to the runtime limits. Expiry is refreshed lazily when another gating operation evaluates, lists pending entries, decides, or reads the audit log. An expired entry is removed and recorded as:

{
  "event_type": "timeout_fallback",
  "outcome": "safe_draft",
  "detail": {
    "fallback": "safe_draft",
    "reason": "approval_timeout"
  }
}

Decisions

Resolve a pending entry with:

{
  "pending_id": "gate-pending-000002",
  "approver_id": "human-reviewer",
  "decision": "approve",
  "reason": "Reviewed against the customer request"
}

Decision	Outcome	Audit event
`approve`	`allowed`	`approval_decided`
`reject`	`safe_draft`	`rejection_decided`
`escalate`	`pending_approval`	`escalation_decided` and a `pending_created` entry for the successor

Approval by the original actor_id is rejected. When requested_approver is set, every decision must come from that approver. Escalation creates a successor pending entry, clears the requested approver, preserves the original deadline, and returns its ID in next_pending_id.

Audit records

GatingAuditEntry contains:

pub struct GatingAuditEntry {
    pub audit_id: String,
    pub timestamp_ms: u64,
    pub event_type: String,
    pub action_id: String,
    pub pending_id: Option<String>,
    pub actor_id: String,
    pub risk_tier: GatingRiskTier,
    pub outcome: GatingOutcome,
    pub detail: serde_json::Value,
}

The current runtime writes these event types:

evaluated
conflict_blocked
memory_conflict_lookup_failed
pending_created
approval_decided
rejection_decided
escalation_decided
timeout_fallback

The audit log and pending queue are bounded runtime collections. They are not the unified event stream.

Memory conflict integration

For r2 and r3, the runtime checks the supplied entity and topic against memory conflicts. If the memory module is loaded, that core MCP boundary must provide the memory.conflict_read tool. Without a loaded memory module, the runtime uses its in-process conflict ledger.

API methods

The JSON-RPC methods are:

mobkit/gating/evaluate
mobkit/gating/pending
mobkit/gating/decide
mobkit/gating/audit

Getting started

Core concepts

Guides

Risk tiers

Evaluation contract

Pending approval

Decisions

Audit records

Memory conflict integration

API methods

See also

​Risk tiers

​Evaluation contract

​Pending approval

​Decisions

​Audit records

​Memory conflict integration

​API methods

​See also

Risk tiers

Evaluation contract

Pending approval

Decisions

Audit records

Memory conflict integration

API methods

See also