ritsu

English | 日本語 | 简体中文

Write the rules a system must follow in small languages, and check that every input gets exactly one answer and that no two rules disagree. From the checked rules, ritsu generates code, pages for people to read, and the inputs, answers and scenarios to test with.

Coding agents now write code faster, and more of it, than anyone can read line by line. That makes one question sharper: what is the code there to carry out, whoever — or whatever — writes it? The contracts between services and inside them. The business rules. The calendars and the deadlines. The ledgers and the bounds on them. The skeleton of a workflow. Who may do what. Where each requirement came from, and what still satisfies it.

ritsu gives each of those a small language of its own, in a file people can read. Each language checks what it says as far as it can be checked — over every input, every day, every path, not a sample — generates code where code is needed, and draws pages for whoever needs to understand it. Because the nine share one toolchain, a proof does not stop at a language's edge: a workflow knows the preconditions of the rules it calls, a rule knows the days a calendar can come to, a ledger knows the amounts a rule can return.

Agents write the glue. ritsu holds what it all has to carry out.

The nine languages

	File	What it is for	What it generates
rulec	.rule	business rules: tariffs, fees, eligibility, tax	functions in twelve languages
dandori	.flow	the skeleton of a workflow	Temporal, Step Functions, Argo and more
koyomi	.cal	dates: closing and payment days, business days, legal periods	TypeScript, Python, Go, Rust, SQL, Wasm
chobo	.book	ledgers: accounts, their bounds, transfers, holds	clients for PostgreSQL, TigerBeetle, MySQL, TiDB and Vitess
geas	.geas	claims about the code an agent wrote	—
yuen	.req	where requirements come from, and what satisfies them	ReqIF, W3C PROV
sakai	.ctx	the map of bounded contexts	settings for import linters; Context Mapper
sekisho	.gate	who may do what: roles, attributes, relations, with rules and dates as conditions	Cedar, and the TypeScript, Python and Go that ask it
kaname	.kn	a functional core: general code with no input or output, which can call rules, dates and books in their types	TypeScript, Python, Go and Rust, in the package ritsu gen writes, and Wasm from the Rust

Each language stands on its own: you can use rulec without writing a .flow. A file never mixes two languages, because a tariff, a calendar, a ledger and a workflow are read by different people.

rulec — business rules

A rule is a set of tables, with the calculations, the exceptions and the provisos around them. rulec check proves that every input in the declared domain gets exactly one answer, checks units and money, and writes a certificate that a proof in Lean rechecks. A figure can be pinned to the published source it was copied from, so that a change in the source stops the check. Only a rule that passes compiles, into plain functions in Python, NumPy, TypeScript, JavaScript, Rust, Ruby, PHP, Go, Swift, Java, SQL and Wasm.

A claim that passes does not mean the table is decided by its claims. A possible line says what is to happen, and rulec check --show-possible prints the shortest calls that make it happen (a table that cancels every order passes never, and stops with E146 once possible delivered is added). rulec strength changes the table one place at a time and says who notices, the claims, only a scenario or an example, or nothing, with a call that shows each unnoticed change and, with --other, another table that keeps everything the file says. Both are in rulec's README.

rule paypal_fee v1
description "The PayPal Checkout fee on one payment in the United States. Transcribed from PayPal's published merchant fees"

source paypal = file "sources/paypal-us-fees.md" sha256:0318950a982c3c7d  # PayPal's own published figures
  table1 sha256:5e481ef40e570eeb

inputs
  amount        : money[USDc]  range >=1USDc <=100000000USDc
  international : bool

# The fee has fractions of a cent in it, and the page does not say which way they settle, so
# the direction here is a placeholder — the thing a person has to decide before this ships.
outputs
  fee : money[USDc]  round half_up(1USDc)

# The page prints the domestic rate and, separately, what an international transaction adds.
# It does not print the sum, so neither does this: the row for a domestic payment adds
# nothing, and that row carries no citation because `0%` is not a figure the copy shows.
table surcharge
policy unique
| international | -> extra : rate[step 0.01%] |
| false         | 0%                          |
| true          | 1.5%                        |  @paypal table1

define fee : money[USDc] = amount × 3.49% + amount × extra + 49USDc  @paypal table1

examples
| amount    | international | -> fee  |
| 10000USDc | false         | 398USDc |
| 10000USDc | true          | 548USDc |

A rule can also leave places for other files to add to: a value its terms put together, an enum, a table. A contribution file adds to them — a campaign a discount, a product line a kind of product and its markup — and pins the shape of what it relies on, so that a change to that shape stops it. There is no list of what to load: ritsu check and ritsu gen merge a project's contributions into the rules they reach, check each rule alone and merged, and ask every table that reads an enum for a row of the value a contribution adds to it.

This is the beginning of the README. Read the rest at the original. Read the full README ↗