Examples
One page per integration point, each quoting and linking the example code in the repository that CI builds and runs.
Every example below is taken from files in the repository. All of them use the same payments contract, so a rule can be followed from the OpenAPI description to the form, the API, a batch job and an agent.
| Integration point | What it shows | Code |
|---|---|---|
| OpenAPI contract | Entities as OpenAPI schemas, operations bound with x-rule-cascade, rules derived from schema constraints | examples/contracts, examples/derived |
| UI form | A React form driven entirely by the client manifest | examples/frontend-react |
| API endpoint | Evaluate, refuse with 422, persist, run commands | examples/backend-spring-boot |
| Batch | Many records against one bundle | conformance/bundles, examples/engine-clients |
| AI agent | Strict function tools and a drafting format | bindings/ |
| Level cascade | An organisation baseline and a feature ruleset that tightens it | examples/contracts |
| Post-save commands | An action rule that emits an event once, after the save | examples/contracts, examples/backend-spring-boot |
| Other languages | The engine from nine languages and from WebAssembly | examples/engine-clients |
What CI proves about them: the rulesets pass check with their golden tests on every push; the
Spring Boot example is built and tested; the React example is built; the engine clients run on
Linux and their output is compared byte for byte.
The rule catalog has one rule for every common data type and severity; the cookbook walks through it recipe by recipe.
Rule server (HTTP)
@yarlisaisolutions/rule-cascade-server: a stateless HTTP service that serves manifests and bundles and evaluates operations.
OpenAPI contract
The payments API description and its ruleset bound to each other - entities reference schemas, operations carry x-rule-cascade, and baseline rules are derived from schema constraints.