ensures

ensures

Declare governance rules for a machine. The ensures section is where a machine specifies its permissions (what it can and cannot do), guards (input/output validation rules), external requirements (secrets, services), and authority delegation. These declarations are enforced at runtime by the governance interpreter. Nothing in this section is advisory; every rule is checked before the corresponding step executes.

When to use

Use ensures when a machine performs governed operations:

• Any machine with ask ... using steps (needs LLM permission)
• Any machine with action steps (needs effect permissions)
• Any machine with remember/recall steps (needs memory permission)
• Any machine that handles sensitive data (needs guards)

Pure compute-only machines do not need an ensures section.

Syntax

ensures
  permissions
    allowed to
      <capability>, <capability>, ...
    not allowed to
      <capability>, <capability>, ...
    requires approval for
      <capability>, <capability>, ...
    authority
      requires: <role>, delegates: <role>
  guards
    <guard_name>
      on_violation: "<action>"
  needs
    <requirement>: required

Subsections

permissions

Declare what capabilities a machine is allowed or denied. The governance interpreter checks these before every governed step.

allowed to

Grant capabilities. The machine can perform these operations:

permissions
  allowed to
    http, db_read, llm_call

not allowed to

Explicitly deny capabilities. Overrides any inherited or default permissions:

permissions
  not allowed to
    db_write, delete_records

requires approval for

Capabilities that need explicit human approval at runtime (consent gate):

permissions
  requires approval for
    external_api_calls

authority

Role-based authority for the machine:

permissions
  authority
    requires: researcher, delegates: team_lead

Capability names

Capability	Description	Required for
llm_call	Make LLM API calls	ask ... using steps
http / http_request	Make HTTP requests	action ... http steps
db_read	Read from database	action ... db (SELECT)
db_write	Write to database	action ... db (INSERT/UPDATE/DELETE)
file_access	Read/write files	action ... file steps
memory / memory_write	Semantic memory operations	remember and recall steps
call_machine / machine.call	Call other machines	ask ... from, action ... call, launch
execute_shell_commands / compute.exec	Run shell commands	action ... exec steps
external_effect / effect.external	User-defined external effects	Custom effect machines

guards

Guards validate inputs, outputs, or intermediate data. Each guard has a name and an action to take on violation:

guards
  pii_detection
    on_violation: "redact"
  max_tokens: 8192
  no_pii: true

Action	Description
"block"	Halt execution, return error
"redact"	Redact the violating content and continue
"warn"	Log a warning and continue
"retry"	Re-run the step (with guardrail feedback)

needs

Declare external requirements that must be satisfied before the machine can run:

needs
  api_key: required
  database_url: required

If a declared requirement is not available at runtime, the machine fails fast with a clear error before any steps execute.

Examples

Basic permissions

machine api_caller
  ensures
    permissions
      allowed to
        http
      not allowed to
        db_write, file_access

Full governance declaration

machine research_agent
  ensures
    permissions
      allowed to
        llm_call, http, memory
      not allowed to
        db_write, execute_shell_commands
      requires approval for
        external_api_calls
      authority
        requires: researcher, delegates: team_lead
    guards
      max_tokens: 8192
      no_pii: true
      pii_detection
        on_violation: "redact"
    needs
      api_key: required

Minimal governance (LLM only)

machine classifier
  ensures
    permissions
      allowed to
        llm_call

Guards with multiple rules

ensures
  guards
    content_safety
      on_violation: "block"
    pii_detection
      on_violation: "redact"
    prompt_injection
      on_violation: "block"
    max_tokens: 4096

How governance enforcement works

1. Before execution: needs requirements are checked. Missing requirements cause immediate failure.
2. Before each governed step: the governance interpreter checks permissions against the step type. If the capability is in not allowed to, the step is denied. If in requires approval for, a consent gate is presented.
3. Before/after effect steps: guards run on inputs (before) and outputs (after). Violations trigger the configured action.
4. Recording: every governance decision (allow, deny, redact, warn) is recorded in the behavioral ledger as a PolicyDecision event (Inv 4: Decision Completeness).

Governance invariants

The ensures section directly implements several runtime invariants:

• Inv 1 (No Ambient Effects): permissions make effect capabilities explicit, not ambient
• Inv 3 (Governance Mediation): every declared capability goes through the governance interpreter
• Inv 4 (Decision Completeness): every permission check is recorded with stage, rule, inputs, decision, and reason

Translations

Language	Keyword
English	ensures
Spanish	asegura
French	assure
German	gewährleistet
Japanese	保証
Chinese	确保
Korean	보장

Sub-keywords

English	Spanish	French	German	Japanese	Chinese	Korean
permissions	permisos	permissions	Berechtigungen	権限	权限	권한
allowed to	permitido	autorise a	erlaubt	許可	允许	허용
not allowed to	no permitido	interdit de	nicht erlaubt	禁止	不允许	불허
guards	guardias	gardes	Wachen	ガード	守卫	가드
needs	necesita	a besoin de	braucht	必要	需要	필요

See also

• achieves - Goal constraints that feed into guardrails
• implements - Where governed steps execute
• ask … using - Requires llm_call permission
• action - Requires effect-specific permissions
• remember - Requires memory permission