Home
An experimental implementation of the minimal stateless event-condition-action rule engine defined in the accompanying mathematical technical note. The product combines a completed Java reference implementation with a browser-local model laboratory whose M7 authoring and experiment workflow is in active development.
The repository has completed milestones M0 through M6: foundation, contracts, pure Java engine, command line, HTTP
reference, zero-cost architecture, and the client/browser-engine foundation. Version 1 schemas, OpenAPI, positive and
negative fixtures, canonical traces, and generated mathematical property checks pass the executable contract gate. The
Java core, model compiler, CLI, packaged HTTP adapter, and pinned non-root container image are reproducible reference
artifacts; the current image revision passes local build and runtime endpoint verification. The Java artifacts are
currently versioned 0.1.0-SNAPSHOT, the client package is 0.1.0, and both implement model contract 1.0; application
and contract versions are intentionally independent.
The current client provides structured editing for global parameters, reusable payload definitions, events, conditions, actions, and rules; validated local JSON/YAML/CSV interchange; and worker-backed event evaluation with immediate cancellation/recovery. It starts with no document open, then presents a model tree, central Model/Graph/Simulator/Code tabs, and a right-hand contextual User Guide. Accessible tree context commands, component/axe checks, and an initial Playwright smoke test are in place, together with a typed, navigable React Flow rule projection, revision-aware document diagnostics, and bounded experiment history with explicit replay. Broader accessibility coverage and the complete browser journey remain M7 work. The public demonstration will consist only of static React and TypeScript assets on Cloudflare Pages Free, with no hosted API, Pages Function, Worker, database, service credential, or active cloud billing account.
- The mathematical note remains independent of implementation technology.
- Evaluation depends only on a fixed model and the current event occurrence.
- Model-level payload definitions are reusable parameter templates; a runtime occurrence payload is a separate optional JSON object, and a missing parameter required by a condition makes that condition false.
- Evaluation queries the fixed rule set for zero or one symbolic action with inert parameter data and never performs
external side effects; version 1 actions have no
typeproperty. Distinct simultaneously matching actions are an explicit ambiguity error, never an implicit priority decision. - Java and TypeScript consume shared schemas and conformance fixtures.
- The Java application is the reference implementation; the browser application is the public interactive implementation.
- The public architecture requires static hosting only and sends no model or event data to a project API.
repository/
├─ README.md Product overview and combined quick start
├─ docs/ System-wide documentation
│ ├─ architecture.md End-to-end architecture and deployment boundary
│ ├─ spec.md Shared semantics and product requirements
│ ├─ development-plan.md Integrated roadmap and cross-implementation milestones
│ ├─ glossary.md Shared mathematical and product terminology
│ ├─ adr/ Architecture decision records
│ └─ technical-note/ Mathematical paper and LaTeX source
│
├─ apps/ Independently buildable implementations
│ ├─ server/ Local Java reference implementation
│ │ ├─ README.md Reference quick start and command guide
│ │ ├─ docs/ Reference architecture, specification, and plan
│ │ ├─ core/ Pure mathematical evaluator
│ │ ├─ model/ Model parsing and validation
│ │ ├─ cli/ Validate, evaluate, and start commands
│ │ └─ service/ Optional Quarkus HTTP adapter
│ │
│ └─ client/ Browser-local React model laboratory
│ ├─ README.md Client quick start and scripts
│ ├─ docs/ Client architecture, specification, and plan
│ ├─ src/ React, TypeScript, and worker source
│ └─ public/ Static hosting files when present
│
├─ contracts/ Language-neutral contract source of truth
│ ├─ README.md Contract ownership and compatibility rules
│ ├─ schemas/ JSON Schemas
│ ├─ openapi/ Optional HTTP adapter contract
│ ├─ conformance/ Shared semantic test fixtures
│ └─ examples/ Browser-loadable demonstration models
│
├─ deployment/ Static hosting documentation
│ └─ cloudflare-pages/ Cloudflare Pages Free runbook
│
└─ assets/ Public project assets
└─ images/ Documentation and application images
| Area | Architecture | Specification | Development plan |
|---|---|---|---|
| Product | Architecture | Specification | Plan |
| Java reference | Architecture | Specification | Plan |
| Client | Architecture | Specification | Plan |
Supporting material:
- Mathematical technical note
- Glossary
- Architecture decision records
- Shared contracts
- Deployment overview
The technical note is authoritative for the mathematical model. The product specification defines its implementation- neutral interpretation. Machine-readable contracts encode document shapes and conformance cases. Application specifications define how Java and TypeScript satisfy them. If two documents conflict, the document higher in that order takes precedence until an explicit decision record changes the design.
Run the contract gate from the repository root with contracts\verify.bat after installing
contracts\requirements.txt into contracts\.venv. Build and test the Java reference with
apps\server\mvnw.cmd -f apps\server\pom.xml clean verify. Install, test, and build the client from apps/client with
npm ci, npm test, and npm run build. Adjustable client compile-time defaults are indexed in
apps/client/src/config/README.md; executable schema-limit mirrors are centralized in
apps/client/src/contracts/contract-limits.ts, while contracts/ remains authoritative. Manually maintained contextual
User Guide articles live in apps/client/src/ui/user-guide/user-guide-content.ts. The remaining workflow is:
- Expand the component/axe and Playwright smoke checks into the complete accessibility and browser journey.
- Promote the reviewed static client and deploy it to Cloudflare Pages Free.
- Verify the hosted journey and confirm that user model and event data never leave the browser.
The published GitHub Wiki is generated from tracked, reviewed
Markdown documentation rather than edited separately. Run tools\wiki.bat to refresh wiki/,
tools\wiki.bat --check as the documentation drift gate, and tools\wiki.bat --publish to update the repository's
separate Wiki Git repository.
Exact Java build, run, and container commands are in the server README. Cloudflare account and Pages setup are in the Cloudflare Pages runbook.