transactions.dev by visibility.cloud

What ships today,
and what does not.

This page exists so the rest of this site can be read as a description rather than as marketing. Everywhere else is written in the release tense; the delta lives here, dated, and this page is authoritative over any sentence on the site that disagrees with it.

Ledger date: 2026-08-05. The engine is the npm package: npx transactions.dev at 0.1.0, whose verbs are parse, emit, validate, ack, intake, pins, version and mcp. No engine door answers on this origin — POST /parse, /validate, /translate, /tap and /reconcile return 405. Everything this origin serves is free, and /pricing publishes exactly that — {"model":"free","binding":false}. The price is published; the binding is not — binding: false tells an agent that free is our stated intent and not terms it may contract on. No price for the paid line is published anywhere (P0-T27).

Shipped

  • The engine as an npm package — npx transactions.dev, at 0.1.0, the only version on the registry
  • parse — X12 bytes to canonical JSON, delimiters and segment order preserved
  • emit — canonical JSON back to wire bytes; emit --verify reports class=byte-exact on the round trip, so the inverse is checked rather than asserted
  • validate — structural validation against a pinned grammar: valid true envelope=true grammar=856/004010
  • ack — a 997 generated from a validate result and printed as wire bytes
  • intake, version, and pins, which prints the grammar and canonical-schema digests
  • The MCP door, as an npm stdio server: npx -y transactions.dev mcp answers tools/list with parse, validate, ack, intake
  • The AXP machine faces on this origin: /.well-known/agents.json, /openapi.json, /pricing, /documents, /family.json, /icp.json, /index.json, /llms.txt
  • The AXP conformance gate, in the build: the vendored generator must stay byte-identical with the shared package, and the worker must pass all 21 pinned requirements of apis-ax-axp@2.2.0 mounted in-process — the build fails closed otherwise
  • The access list at /get-access/ — email first, one branching question per step, the final step locks the row
  • The disclosure statement at /what-we-log, in three faces — HTML, JSON and Markdown — with /privacy redirecting onto it
  • The blog, and a Markdown twin on every route on this origin

Open in the launch ledger

  • No engine door answers on this origin. POST /parse, /validate, /translate, /tap and /reconcile all return 405; the worker mounts no engine route (P0-T1)
  • translate and join — recognised verbs that answer NOT_IMPLEMENTED (P0-T1)
  • reconcile, enrich and tap — not verbs at all; the CLI answers unknown verb (P0-T1, P0-T10, P0-T26)
  • tap, the passive read-only flow copy: no routing registration, no consent ceremony, no credential custody, no revocation (P0-T26)
  • Rung zero — the transaction graph rebuilt from a photograph of the paperwork, and the hard-fact / interpreted-fact grading under it (P0-T26)
  • Published prices for the paid line. One price is published for this door and it is zero, carried machine-readably at /pricing and declared binding: false — stated intent, not terms. No number is published for the paid line anywhere, and none may be until the metering unit per verb is settled — per document, per segment, per delivered route, per reconciled period (P0-T27)
  • The paid side itself — termination, the digest-pinned partner maps, chargeback-defence operations. None of it exists (P0-T27, P0-T21)
  • Self-serve entry. The only door in on this origin is the access list: no signup, no key issue, no checkout (P0-T27)
  • Access provisioning — the list stores, but no sender inbox and no provisioning run stands behind it yet (P0-T8)
  • A hosted MCP endpoint on this origin — the capability card declares the npx stdio door and only that door (P0-T3)
  • The differential conformance harness and the license-tagged corpus at the depth the posts describe (P0-T4, P0-T6)
  • The canonical JSON Schema served at its own $id (P0-T12), duplicate interchange detection (P0-T14), and the open EDIFACT/EANCOM reference section (P0-T15)
  • Connectors to the systems of record named in the landing page's segments (P0-T7)
  • The X12 licensing posture required before the engine serves third parties in production (P0-T5)
  • Users. There are none, and there are no logos, quotes, customers or metrics on this site

How to read the two columns.

The left column is checkable from your own terminal, and every engine row on it was checked from one before it was written here: npx -y transactions.dev@0.1.0 against a fixture, and this origin's machine faces over HTTP. Nothing on it is an adjective.

The right column is the open half of the launch ledger. Each entry names its P0 number in docs/P0-LAUNCH-BLOCKERS.md, closes by shipping the mechanism, and is dated when it closes. Opening an entry records a gap; it does not license a present-tense sentence somewhere else on the site, and where a page describes an open entry it is written in the future tense.

The offer, exactly.

The landing page names the shape the free/paid line will take when it publishes. That shape is a decision, not a product: none of the paid side is built, no number is published, and there is nothing on this origin to buy. The one offer that is live is the one /pricing states — everything this origin serves is free — and the human page and the machine face say that same thing on purpose, so a reader and an agent are never handed two different offers.

The standard.

transactions.dev conforms to EPCIS 2.0 and CBV 2.0 and claims nothing above them. GS1 is the standards body and has not reviewed, certified or endorsed this project. X12 is a registered trademark of X12 Incorporated; element detail is linked at its canonical public reference and never republished here.

← The landing page