Proof
Claims you can re-run.
Every number on this page comes from a checked-in, machine-readable report with fixtures and commands in the repo. If a claim can't be re-run, we don't make it.
01 — Benchmarks
The workflow you feel every day: extract & update.
The end-to-end benchmark measures what a developer actually waits for: scan sources, extract messages, update catalogs, write files. Same generated message inventory, rendered into each tool's idiomatic source shape, semantically validated after every run.
Realistic corpus — 1,500 files across ~400k lines, 6,000 messages (median of 7 runs)
Machine-local run (darwin/arm64, Node v24.18.0, 2026-07-06), median of 7 runs — not a marketing average. Methodology →
Honest note
These are machine-local numbers from the checked-in report, not a marketing average. Your hardware will differ; the ratios are the signal. Commands to reproduce: pnpm benchmark:e2e-workflow.
02 — Verification
24 apps, verified in a real browser, on every change.
01
Build
All 24 example apps build against the workspace packages — no mocked integrations.
02
Drive
A Playwright flow loads each app, checks SSR output, switches locales, and exercises localized server actions.
03
Capture
Screenshots are versioned in the repo, so 'works across frameworks' is a diffable artifact, not a slide.
03 — Catalog quality
Fast would be worthless if the catalogs were wrong.
Catalog semantics live in one dedicated engine (ferrocat): parsing, merging, structured audits, and ICU authoring diagnostics. The benchmark harness validates every tool run semantically — message inventories are compared, not just timed.
Structured audits
Machine-readable catalog audits catch missing translations, stale entries, and metadata drift in CI.
ICU diagnostics
Authoring mistakes in plural/select syntax are flagged at extract time, not at runtime in production.
Semantic merging
A Git merge driver resolves catalog conflicts by meaning, not by line — no more broken .po files after rebases.
04 — Decision trail
16 decisions, written down before you depend on them.
The ADRs cover message identity, the native boundary, adapter architecture — and, just as deliberately, what Palamedes refuses to own. Reading them is the fastest way to know if our tradeoffs match yours.