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. Spine prototypes exist for Registry and Cadence; most engines remain designed or not started.

The engines

Engine Tier Owns Status
Return Studio Configure Templates, sections, line items, formulas, calendars, weights 🟨 Line-item spine
Registry Record Parties, identities, contacts, addresses, roles, licences, mandates ✅ Prototyped
Strata Record Submissions and their versions 🟡
Seal Record Hash-chained audit entries ⬜
Cadence Motion Obligations, due dates, reminders ✅ Prototyped (spine)
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 ⬜

Adjacent and platform

Module Owns Status
Licensing Licence grant, application, fit-and-proper, required-doc criteria ⬜ Parked
Vault Document bytes, classes, storage repositories, document links ✅ Prototyped (spine)
Reference Coded value sets the engines validate against and the UI renders as selects 🟡 Served from code, flagged provisional where unconfirmed

Licensing writes grant outcomes into Registry. Vault is shared storage used by Registry, Strata, Docket, and Licensing.

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.