Operational domain truth
Engines own the business rules. Screens follow.
An engine-backed business is not a generic application with industry-themed tables. An engine defines entities, roles, capabilities, legal transitions, required evidence, approval gates, audit requirements, and sealed proofs.
CRUD vs engine
Generic status updates are not operational software.
Generic CRUD
- Inventory table
- Orders page
- Dashboard
- Status dropdown
- Manual state changes
- No proof requirements
Engine-backed
- Explicit operational entities
- Authorized roles
- Legal transitions only
- Evidence before advance
- Audit records
- ShipGate checks on invariants
Example
A deal cannot become Won because the UI sent status = won.
An engine-backed CRM can require:
- Authorized sales role
- Required customer identity
- Signed contract evidence
- Commercial amount and effective date
- Approval record
- Audit event
ShipGate tests that bypasses are rejected. Generated UIs reflect engine truth — no invented modules from industry stereotypes.
ISL provenance
Executable intent connects approval to verification.
ISL is the machine-readable contract connecting approved business intent to generated software and verification. Engines derive from ISL — handwritten TypeScript descriptors must not silently replace ISL as the authoritative source.
Nontechnical users see the value: intent becomes enforceable, requirements stay traceable, business rules survive implementation, and verification knows what must remain true.
Composition
Businesses point to composed engines.
Routes, navigation, commands, workflows, roles, screens, evidence capture, operational states, and verification obligations should derive from selected engine capabilities — not hardcoded domain boards the user never requested.
Available engine catalog and composition APIs are expanding. Marketing claims track shipped engines only; planned engines are labeled as such.