The rule is the document
Validation, applicability, derived values, locale and accessibility live in one file that diffs in review and can be read by legal.
Specification 1.0 · level 3 of 5
The rules belong to the form, not to the screen.
A regulated form has one data model and several presentations: web, phone, API, PDF, email. In practice they drift. FormScript puts the rule in one document, so every conforming runtime returns the same values, the same validity, the same error codes and the same output.
loan_application.forms
form loan_application version = "1.0" {
text {
"applicant.first": "First name"
"applicant.last": "Last name"
"applicant.income": "Annual income"
"applicant.amount": "Loan amount"
"applicant.term": "Term in months"
"applicant.monthly": "Monthly payment"
"applicant.guarantor": "Guarantor name"
"applicant.consent": "The applicant agrees to a credit check"
}
group applicant {
field first_name {
type = string
label = t("applicant.first")
required = true
}
field last_name {
type = string
label = t("applicant.last")
required = true
}
21 packages
312 normative statements
776 tests
One document. Watch the guarantor leave.
Change the income. The live form, the output JSON, and a second evaluation of the same engine move together.
Document
Live form
Output
Second execution: the same TypeScript engine. Level 4 needs an independent runtime — not claimed yet.
What FormScript gives the team
Three things stop being duplicated the moment the rule lives in the document.
Two runtimes, one answer
The browser and the server evaluate the same document. Same values, same validity, same error codes — so a disagreement is a bug, not a design.
Errors that mean something
Stable diagnostic codes, a fixed catalogue, typed values with honest absence, and decimal arithmetic that does not drift by a cent.
How it fits in
Three steps from a blank repository to a form two runtimes agree on.
Write the document
A form, its fields, its types, its rules and its output block. Plain text, reviewed like code.
Render it anywhere
The document emits render intents; a renderer turns them into controls. The same intents drive web, phone and PDF.
Prove it
The conformance suite runs the document against every normative statement and reports the level it reaches.
21packages
312statements
776tests
101conformance rows
3 / 5level claimed
21 packages · 312 statements · 776 tests · 776 over 21 files · 101 conformance rows · level 3 of 5
Start from a pain
Every page below starts with a failure you already know, then shows the promise and the boundary.
Duplication
One rule on the web and the API
The same eligibility rule means something different on web, mobile and the API. That disagreement is a compliance incident.
Read the page Contract The payload is the contractOmitted means not asked. null means asked and left blank. A missing field is never ambiguous.
Read the page Arithmetic Money that matchesA repayment is wrong by a fraction of a cent because 0.1 + 0.2 is not 0.3 in binary floating point.
Read the page Toolchain Stop maintaining the form stackOne document instead of a client schema, a server schema, show/hide code, calculated hooks and a private label file.
Read the page Accessibility Accessible by constructionError summary, labels, focus and the placeholder ban are normative — not a library’s optional add-on.
Read the page Audit Legal can read the ruleThe eligibility rule is buried in three codebases, and support cannot tell which rule was live when an application was decided.
Read the pageRun the real engine in your browser
The playground is the same lexer, parser, analyser and engine the conformance suite runs — with a live form beside it.