---
title: "Simulate gateway evaluation against the alignment card"
method: POST
path: "/alignment/agent/{agent_id}/simulate"
tags: ["Alignment"]
---

# Simulate gateway evaluation against the alignment card

`POST /alignment/agent/{agent_id}/simulate`

## Request

- Base URL: `https://api.mnemom.ai/v1`
- URL: `https://api.mnemom.ai/v1/alignment/agent/{agent_id}/simulate`
- Auth: one of:
  - HTTP bearer
  - API key in header `X-Mnemom-Api-Key`
  - API key in cookie `mnemom_session`

Pure-sync simulation: calls @mnemom/policy-engine twice (once with `context: "gateway"`, once with `context: "observer"`) using `dryRun: true` against the agent's current composed alignment card. Returns `{allowed, conditions, suggestions, gateway_decision, observer_assessment}`. Never crosses worker boundaries — no real gateway / observer state change.

The tools evaluated are the CALLER-supplied identifiers only — the union of `candidate_tool_call.tool_name` and every `candidate_input.messages[].toolUses[].name`, deduped. They are never read off the card (MNE-5820).

If that union is EMPTY, the request still returns **200** (unlike `explain`, which 400s), but it FAILS CLOSED: `allowed` is `"false"` with a `no_tool_named:` entry in `conditions`. The engine emits findings per tool, so a zero-length tool list would otherwise produce verdict `pass` with no violations — a green that checked nothing.

Note that `gateway_decision.verdict` and `observer_assessment.verdict` are the RAW engine output. On the zero-tool path they read `"pass"` with no violations, because the engine evaluated nothing. `allowed` — not the sub-verdicts — is this endpoint's decision field; read it.

## Path parameters

- `agent_id` string, required

## Request body

- object
  - `candidate_input` object: Hypothetical conversation snippet. Any `messages[].toolUses[].name` here is a caller-supplied tool identifier and IS evaluated — unioned with `candidate_tool_call.tool_name` (MNE-5820).
    - `messages` object[]
  - `candidate_tool_call` object: Hypothetical tool invocation. Synthesized into an assistant message with a toolUses block when `candidate_input.messages` is absent.
    - `tool_name` string: A TOOL IDENTIFIER — the name a runtime invokes (`Read`, `Grep`, `Bash`), matched against `capabilities.<name>.tools[]`. NOT a card action (`code_read`, `inference`); those live in `autonomy.bounded_actions` and never match here (MNE-5820). Optional when `candidate_input.messages[].toolUses[]` names a tool instead; if NEITHER does, the response is still 200 but fails closed with `allowed: "false"`.
    - `tool_args` object

## Response `200`

Simulation result.

- object
  - `ok` true, required
  - `resource` 'alignment', required
  - `allowed` 'true' | 'false' | 'conditional', required
  - `conditions` string[], required
  - `suggestions` string[], required
  - `gateway_decision` object, required
    - `verdict` 'pass' | 'warn' | 'fail'
    - `violations` object[]
    - `warnings` object[]
    - `missing_receipts` string[]
  - `observer_assessment` object, required
    - `verdict` 'pass' | 'warn' | 'fail'
    - `violations` object[]
    - `warnings` object[]
  - `evaluated_at` string, date-time, required

## Other responses

- `400`: Bad request
- `401`: Authentication required
- `403`: Forbidden
- `404`: Resource not found
- `429`: Rate-limit exceeded. The global per-IP limiter (100 requests/minute, applied to every `/v1/*` route) rejected this request. Back off until the window resets — `Retry-After` carries the cooldown in seconds and `X-RateLimit-Reset` the absolute reset time.
- `500`: Server error — request was well-formed but the server failed to fulfill it. Typically a downstream dependency (DB / RPC / external API) returned an unexpected error.

---

[API](https://skmtc.dev/mnemom/apis/mnemom-api.md) · [All operations](https://skmtc.dev/mnemom/apis/mnemom-api/llms.txt) · [OpenAPI document](https://skmtc.dev/mnemom/apis/mnemom-api/revisions/274b7a6ea182?raw)