Seal

Seal

A commitment is sealed when every money operation has confirmed. The seal is the signed summary of what happened, and it does not change afterwards.

not sealedcmt_example

Sealedno — sealing is not built

Payload fields9

Part 1

#status

Status

What this page is today, stated before anything else on it.

Not sealed

Sealing is specified in the Rulebook and reserved in the workspace as packages/records; it is not built. No commitment on this deployment is sealed, so no seal exists at this address — and the page will not draw one in wax until one does. When sealing ships, a seal that fails its own check will be shown as broken, not hidden.

Part 2

#impression

The die

Wax marks a seal that exists and nothing else, so an unsealed commitment gets the die without an impression: the geometry in hairlines, the fields empty.

Seal impressionnot struck · 0 sealed commitments

A struck seal is the same geometry in wax, carrying the sealed date and the unit tally in place of the empty lines. The badge a vendor will embed renders from the same payload as this page, so the badge and the seal cannot disagree.

Part 3

#payload

The payload

Everything a seal will carry, per the technical specification. A ruling is cited by reason code, the terms by their hash, and the whole payload is signed — a seal claims nothing it cannot show.

Seal payload9 fields · signed as one document

Field	Form	What it is
commitment_id	cmt_<ulid>	The commitment this seal closes.
standard	id · version	The outcome standard and version the terms cited.
verified_units	count	Units that met the standard.
disputed_units	count	Units either party disputed.
rulings_summary	list	Each ruling, with its reason code and the rule it cited.
rulebook_version	version	The rulebook version in force when the terms were accepted.
terms_hash	sha256:<hex>	SHA-256 of the canonical terms both parties signed.
sealed_at	ISO 8601 UTC	When the last money operation confirmed.
signature	ed25519:<hex>	Over the whole payload, with the key id to verify it against.

Part 4

#check

The check

A seal is a claim, and a claim here comes with the way to check it. The check needs no Recourse dependency: canonical JSON, SHA-256, and an Ed25519 verify.

1 · RecomputeCanonicalize the payload (RFC 8785) and take the SHA-256.

2 · VerifyCheck the signature over that hash against the key named by key_id.

3 · CompareThe terms behind terms_hash are the terms the parties signed. Same hash, same document.

The public keys are published at /.well-known/recourse-keys.json on the API origin. This page will run the same check on the payload it renders, and say so either way.

Document	Origin	What
/llms.txt	recourse-mu.vercel.app	This site in one short document: what Recourse is and where everything else is.
/llms-full.txt	recourse-mu.vercel.app	The whole protocol in one fetch: steps, states, standards, reason codes, errors, endpoints.
/.well-known/recourse.json	api.recourse.dev	Machine discovery: the API base, the scopes, the rulebook version, and the standards in force.
/.well-known/recourse-keys.json	api.recourse.dev	The Ed25519 public keys events and record snapshots are signed with. Verify without asking Recourse.
/openapi.json	api.recourse.dev	OpenAPI 3.1, generated from the live route table. Every client is generated from it.
/repr/md/{page}	text/markdown	The Markdown of /, /docs, /standards, /rulebook. The same bytes those URLs serve under Accept: text/markdown.
/repr/json/{page}	application/json	The JSON of the same four pages. Every negotiated response carries Vary: Accept.