Parley

Appearance

Lens ​

Models read text. Lens is a canonical, deterministic, compact text rendering of every Parley reply and of any JSON value. Clients show the model the Lens instead of raw JSON. It's specified to the byte, and both implementations must produce identical output for the same input (SPEC §9).

What it looks like ​

2 proposals — risk: low · undo: 2h · expires: 2026-09-24T02:22Z:
[p_71KbTFLA] 4 meals for 2026-09-26 — 53.95 USD
  + create order/o1001 — 2× Tofu Pad Thai (light), 2× Chickpea Shawarma (light)
  $ charge card ••4242 — 53.95 USD
  cost: 53.95 USD
[p_JU6-iYhB] 4 meals for 2026-09-26 (express, by noon) — 62.94 USD
  …
  • Effect lines use one-character operators: + create, ~ update, - delete, > send, $ charge, * other.
  • Uniform lists become tables that name their keys once: items[60]{sku,name,usd,cal,protein}: and then one row per item.
  • Strings are bare when that's unambiguous, and quoted otherwise.
  • Shared attributes of several proposals appear once, in the header.
  • Receipts are one line plus the result, because the model already read the effects in the proposal (unless the service auto-committed, in which case the effects are shown).
  • Errors carry their fixes: fix: rename dyatoday → params {"dya":null,"day":"2026-09-25"}.

Why specify it ​

  1. Compactness where it counts. The 60-item menu costs 1,095 tokens in Lens against 1,919 in minified JSON and 3,019 pretty-printed.
  2. Consistency across services. A model that has read one Parley receipt can read them all.
  3. Budgets that mean something. A budget constrains the text the model actually reads.

Lens is designed to be read cold. In a real session, a model with no Parley documentation read it correctly on the first try.