Data model

The records the hub holds, their fields, how they relate, and which module is the single source of truth for each. This is the vocabulary for owners and developers alike.

Migration from Tutor LMSSee the data flows

How the records connect

Read left to right: from interest to money to proof
  1. Leadinterest from a Contact
  2. Dealand Proposal, for a Company
  3. Orderseats on a Batch
  4. Invoiceand Payment
  5. Enrolmenta Learner in a Batch
  6. Sessionattendance
  7. Certificatewith a public code

An individual engineer skips Deal and Proposal: the website creates the Order directly. A corporate client goes through all seven. In both cases the same Enrolment, Session and Certificate records are produced, which is why one learner record can serve the learner portal, the corporate portal and the back office.

Three separate things. Course.provider says whether a program is ASME or MALYOMAR. Instructor is always a human. The “Course Author” accounts in today's site become the provider value and disappear from the instructor directory.
Field lists are a starting point. Course, Instructor, Service and CaseStudy fields follow the content brief. Operational records list the fields the prototype screens use. The records added in revision 5 Oct 2026 list the fields the new prototype screens demonstrate. They are not an approved schema, and groups that depend on an open decision carry a provisional chip.

Organisations, people and the roles they hold

One person or organisation, several separate linked records

Organisation is a first-class record. MALYOMAR itself, a corporate customer, a delivery partner and a supplier are all organisations; what differs is the role record attached. A customer, a learner, an instructor, a supplier, an employee and a system user are distinct records that may relate to the same Person or organisation. None is created automatically from another, and none replaces another.

Role recordAttached toWhat it meansWhat it does not implyOwner

Rule: one learner identity with one consolidated history, however many organisations took part in the delivery. Access follows the role assignments and their record scope, described on roles and access and set on responsibility profiles. In the prototype, hiding by role is static and is not production authorization.

id keyType → reference to another record[] list

Relationships

FromRelationshipToCardinalityRule

Single source of truth

RecordOwning moduleCreated byOther modules that read itEdited on
Rule: only the owning module writes a record. Every other module, portal and bought tool reads it through the hub API or receives it as an event. See central hub principles.

Rules the data must enforce

Catalog

  • A course cannot be published without code, title, provider, academy, level, hours, price, currency and at least one outcome.
  • Course codes are unique. Draft and test items never appear on the public site.
  • A learning path lists courses in order; a course may sit on several paths.

Delivery

  • A batch of an ASME program needs an instructor whose authorization status is “ASME authorized”.
  • Confirmed enrolments cannot exceed batch seats; extra requests go to the waitlist.
  • A certificate needs a completed enrolment that meets the attendance and assessment rule of the course.

Money and proof

  • Every enrolment traces to an order line; every paid invoice traces to payments.
  • Invoices are numbered in sequence and never deleted, only credited.
  • A case study is public only when permission status is “approved by client”.

Identity and joint delivery

  • One learner identity and one consolidated history, across companies and partners.
  • A joint delivery is one batch with one enrolment per learner. It never duplicates an enrolment or revenue; partner shares are allocations of the same order.
  • A settlement is calculated from the agreement version selected on the joint delivery. No default split exists.
  • A partner user reads only records of their own organisation and the services it is authorised to deliver.

Commitments, plan and standing

  • Awards are recorded per tender line. An awarded line that becomes a batch moves its value from pipeline to contracted future revenue, so it is never counted twice.
  • A forecast never overwrites an approved plan version. Revisions are new versions; the original baseline is kept.
  • A recovery action states the part of its effect already in the forecast; only the remainder is added.
  • Customer reliability rating, loyalty status and AI lead score are three separate things with separate histories.
  • Rating and loyalty changes are new events. Corrections are reversals or adjustments, never silent overwrites.

Costs, cash and close

  • Requesting, ordering, receiving or accepting, recording the cost and paying are separate events with their own records and dates.
  • A bill links to its order and receipt, and a payment to its bill, so one cost is recorded once. A part payment reduces the payable; it is not a second expense.
  • An employee, a system user and an instructor are separate records. Instructor payouts are not payroll.
  • A locked period accepts no edits. A change needs an authorised adjustment or reopening, recorded with who, when and why.
  • A risk closes only on verified evidence. Completing its actions does not close it.

These rules are demonstrated with sample records in the prototype. They are not enforced by a database, and the policies behind them (recognition, approval limits, settlement terms, payroll) are open decisions listed on open decisions.