Docs / Guides

Govern invocation

Make authorization, approval, audit, timeout, and denial behavior visible before execution.

Plain English

Governed invocation means the host checks whether the call is allowed before doing the work.

Why it exists

Sensitive hosted abilities should not look like ordinary functions to agents or applications.

Formal definition

Governed invocation is host-side evaluation of caller, permission, policy state, lifecycle, payload, timeout, and context before capability execution.

Concrete example

Ground the concept before the schema.

manager_approval returns approval_required instead of silently scheduling a technician.

schedule_technicianRestricted

Finds an available qualified technician and reserves a service window.

host: ServiceOpsHostpolicy: approval_requiredv1.0.0

Policy boundary

Approval required

manager_approval

A manager must approve technician scheduling before the host returns a confirmed appointment.

Invocation trace

  1. 01 Actor

    Planning Agent

  2. 02 Capability

    schedule_technician

  3. 03 Host

    ServiceOpsHost

  4. 04 Policy

    manager_approval

  5. 05 Context

    job_context

  6. 06 Result

    Confirmed Appointment

outcome.json
json
{  "invocation_id": "inv_session_abc_001",  "capability_id": "schedule_technician",  "capability_version": "1.0.0",  "correlation": { "correlation_id": "session-abc" },  "outcome": "denied",  "success": false,  "data": null,  "error": null,  "denial": {    "code": "approval_required",    "message": "manager_approval must approve before execution.",    "retryable": true,    "details": { "policy": "manager_approval" }  },  "evidence_ids": ["evt_8f3a1c"],  "started_at": null,  "completed_at": "2026-06-16T15:14:22.104Z"}

Relationships

Where this sits in the protocol.

Each concept should explain its neighbors so implementation teams can preserve the boundary across manifests, invocation, evidence, and tests.

Policy is declared in the manifest.

Invocation carries caller and context.

Evidence records the decision and outcome.

Visual model

  1. 01Caller requests capability.
  2. 02Host validates policy and lifecycle.
  3. 03Host executes, pauses, denies, or fails with structured output.

Implementation notes

  • Return denials as data with stable codes.
  • Keep timeouts explicit in the invocation envelope.
  • Record policy outcomes in evidence.

Common mistakes

  • Throwing framework exceptions for expected denials.
  • Letting policy checks happen after side effects.
  • Recording only successful policy decisions.

Related concepts

Keep reading through the boundary.

Policy →Evidence →Conformance →