Skip to content

Engines

Ten engines, five tiers

Each engine is a business component with its own boundary, control, and entity layers. One page per engine states its purpose, its scope traced to the requirement, the data it owns, and what it deliberately does not own.

Status key

Used consistently across every engine and specification page.

Marker Meaning
✅ Prototyped — visible in the design system or supervision prototype
🟡 Designed — specification written, no implementation
⬜ Not started

Nothing in Kovent is marked proven. There is no runtime yet.

The engines

Engine Tier Owns Status
Return Studio Configure Templates, fields, rules, calendars, weights 🟡
Registry Record Firms, licences, officers, mandates ⬜
Strata Record Submissions and their versions 🟡
Seal Record Hash-chained audit entries ⬜
Cadence Motion Obligations, due dates, reminders 🟡
Bench Motion Review assignments, checklists, queries ✅
Docket Motion Cases, findings, directives, penalties ⬜
Assay Judge Validation results, computed figures ✅
Prism Judge Risk scores and driver breakdowns ✅
Projections Read Denormalised read models ⬜

Why these boundaries

The tiers are explained in the platform overview, and the mapping to the requirement's own functional modules is tabulated there. Two boundaries are worth defending here because they are the ones a reviewer will question.

Why is validation separate from submission? Because the same rules run in three places: in the firm's portal before submission, on the write path at submission, and again on re-validation after a rule change. If validation lived inside the submission engine, the firm's pre-check would be a second implementation of it — and the two would drift. Assay is called by all three.

Why is audit an engine rather than a library? Because the chain has to be verifiable independently of the engines that wrote to it. A library that each engine calls produces a log; an engine that owns the chain produces evidence, and can be asked to prove its own integrity without trusting its callers.