> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chance.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# Meow

> Venue-aware verification for Meow business banking — pass the exact ACH, wire, or book transfer body, get a verdict bound to those bytes before money moves.

Chance understands Meow natively. Submit the **exact payment-creation body** your agent is about to send — an ACH transfer, a wire, an internal book transfer, a stablecoin payout, or a withdrawal-limit change — and the harness will deterministically classify it, judge it against your mandate with Meow's own API documentation in the loop, and return a signed verdict whose `requestHash` binds to those exact bytes.

## What gets recognized

| Family       | Payloads                                                                                                    |
| ------------ | ----------------------------------------------------------------------------------------------------------- |
| `payment`    | ACH transfers, scheduled/recurring ACH (RRULE), wire transfers, crypto/stablecoin payouts to saved contacts |
| `transfer`   | Internal book transfers between bank accounts                                                               |
| `permission` | Daily withdrawal limit changes (the entity-wide outbound cap)                                               |

The classifier renders amounts as real dollars (Meow amounts are USD with two decimals — a 100x "cents" mistake is caught immediately), decodes the rail, memo and recurrence, and computes what the payload actually authorizes. The judge reasons over:

> *Meow PAYMENT: \$6,900.00 via WIRE to counterparty 3e1b2b0a…9c21 (memo: "INV-2044 — Acme Metals") — counterparty is an opaque saved-contact id; payee identity is UNVERIFIED unless the mandate pins this exact id; wire transfers are final once sent.*

That framing is what catches the classic banking failures: the wire that's final the moment it sends, the first-time payee nobody vetted, the ACH/wire ambiguity that turns a "small reversible payment" into an unrecoverable one, the WEEKLY recurrence that multiplies a within-cap amount into a five-figure monthly drain. Because a Meow payload identifies the payee only by an opaque counterparty id, the verdict leans ESCALATE whenever the mandate depends on *who* gets paid and the id isn't one your rules explicitly allow — fail closed, never allow on assumption.

## Use it from your bot

Wrap the payment you were already going to create:

```ts theme={null}
const payment = {
  type: "wire", // the rail (mirrors the endpoint: /accounts/{id}/wire)
  account_id: "acct_123456789",
  amount: "4800.00", // USD — Meow amounts are dollars, not cents
  counterparty_id: "8c2f6a1e-3d5b-4f7a-9e0c-2b4d6f8a1c3e",
  instructions: "INV-2044 Acme Metals",
  idempotency_key: "wire-20260702-inv2044",
};

const res = await fetch("https://harness.chance.cc/api/v1/intent", {
  method: "POST",
  headers: { "x-api-key": process.env.CHANCE_API_KEY!, "Content-Type": "application/json" },
  body: JSON.stringify({
    intent: "Pay approved vendors only (counterparty ids on file). Max $5,000 per payment, ACH preferred; wires only to vendors we have paid before.",
    venue: "meow",
    action: payment, // the exact payload — the verdict binds to these bytes
  }),
});

const { verdict, reasoning, mode } = await res.json();
if (verdict !== "ALLOW") throw new Error(`Blocked: ${reasoning}`);
// only now send the payment to the Meow API
```

`venue` is optional — Meow payment bodies are auto-detected — but because ACH and wire share the same body shape (the rail lives in the endpoint path), include the `type` field so the verdict covers the rail you'll actually hit. Freeform `action` descriptions still work (`mode: "semantic"`).

## Use it from Claude or ChatGPT

Add the hosted connector (`https://harness.chance.cc/api/mcp`, see [Connectors](/connectors)) and give your agent one standing instruction:

> Before creating any Meow transfer or payment, call `verify_intent` with my rules as the intent and the exact request body (including the rail) as the action, with `venue: "meow"`. Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.

Agents with Meow execution tools then get gated automatically; agents without them still give you provable pre-payment checks in chat.

## How the harness knows Meow

The judge works from a **versioned snapshot of Meow's own developer docs** — ACH, wire, book and crypto transfer schemas, contacts and counterparties, daily withdrawal limits, transfer statuses and the approval model, authentication and scopes, bill pay, error codes — plus a curated brief of the venue's footguns (dollars-not-cents amounts, ACH reversibility vs wire finality, opaque counterparty ids, first-time-payee risk, recurrence math, the asymmetric per-rail limits). Docs are never fetched at verdict time: the snapshot is reviewed like code, its version is hashed into every transcript, and each page the judge consults is chained with its content hash — the receipt proves exactly which knowledge, at which version, informed the decision. See [Architecture](/concepts/architecture).

## What the receipt adds for Meow

On top of the standard proof bundle (transcript root, judge signature, onchain anchor), venue-aware verdicts carry `venue: "meow"`, the `actionFamily`, the venue `actionType` (`ach`, `wire`, `book`, `crypto`, `ach_scheduled`, `set_daily_withdrawal_limit`), `mode: "structured"`, and the knowledge-snapshot version — all inside the hash-chained transcript. For payments, the transcript records the exact dollar amount, rail, counterparty id and memo the verdict was issued against — an audit trail you can hand to your controller.

<Note>
  **Roadmap:** escrowed execution — the same contract, but an ALLOW triggers submission by a Chance-held credential and a BLOCK physically never reaches the banking API. The payload-first contract above is forward-compatible with it.
</Note>