Minimal unit record
A minimal unit record (MUR) is the smallest valid set of data that can be submitted to STARS for the first time which:
complies with the VET Information Standard (VET IS)
results in no blocking validation failures
The MUR exists to provide SMS suppliers and RTOs with a stable, minimal validation baseline that can be used to verify initial integration and testing with STARS.
The MUR applies to the first time a resource (such as a student, enrolment, offering, etc.) is submitted to STARS. It defines the minimum data required to pass blocking validation on first submission and does not prescribe or limit the data attributes that may be submitted if additional information is available.
In the current release, the MUR can be used to validate end‑to‑end integration flows are behaving as expected against the implemented validation rules. Additional validation rules will be introduced in the next release. Technical scenarios that don't call out an explicit payload assume the MUR as the starting point.
Why the first submission matters
Once data has been successfully submitted, it becomes available for reference by subsequent submissions. This means later submissions can be incremental rather than foundational. As a result, the minimal unit record (MUR) applies only to first submission, where referenced data does not yet exist in STARS. It defines the minimum data required to pass blocking validation and does not restrict or limit additional attributes that may be included when they are available.
For example:
First submission: A Subject Enrolment must include the Student, Subject, and Subject Offering because none of those exist yet in STARS.
Subsequent submission: The same Subject Enrolment (or an update to it) can be submitted by itself, referencing previously submitted entities by UID.
What defines the minimal unit record
The minimal unit record is defined by the following constraints:
Blocking VET IS validation rules: Only validation rules that block submission are considered. Conditional rules apply only when their conditions are met.
Blocking STARS system rules: For first submission, all referenced resources must already exist in STARS or be included within the same transaction batch.
API structural requirements: The OpenAPI specification defines which attributes are structurally required and which attributes may be null.
What the minimal unit record is not
The minimal unit record is not:
a complete representation of a student’s training history
a full end‑to‑end lifecycle submission
a template for ongoing reporting or a recommended shape for live submissions
a demonstration of all supported business scenarios
STARS will allow you to validate and submit the MUR - that doesn't mean a system that can do so is capable of meeting reporting requirements or providing the best user experience.
Minimal unit record anchors
There are two MUR anchors, corresponding to the two enrolments supported by STARS:
Minimal unit record - Subject Enrolment (MUR‑SE)
Minimal unit record - Program Enrolment (MUR‑PE)
All minimal unit records are built around one of these enrolment anchors.
MUR-SE (Registered, not VET in school, TGA subject)
Student
studentUID
studentIdentifier
either firstGivenName or familyName
deceasedIndicator (False)
surveyAvailability (Available)
emailAddressPrimary
Subject
subjectUID
programOrSubjectReferenceNumber
nominalHours
Subject Offering
subjectOfferingUID
subjectUID
Subject Enrolment
subjectEnrolmentUID
studentUID
subjectOfferingUID
scheduledStartDate
scheduledCompletionDate
lifecycleStates containing at least studentStatus (Registered) and studentActivityDate
vetInSchoolIndicator (False)
Some attributes are often assumed to be required but do not form part of the MUR:
Delivery Location is not included because it is required only when a subject enrolment is Commenced/Concluded or a locations child object is explicitly reported.
Commencement and Completion Data. Lifecycle states beyond Registered trigger additional mandatory attributes (learning delivery, assessment type, locations, status reasons).
Program Linkage. Unless the enrolment is VET in Schools, a Subject Enrolment does not require a Program Enrolment on first submission.
MUR-SE golden payload
Create transaction batch
Upload Student
Upload Subject
Upload Subject Offering
Upload Subject Enrolment
MUR-PE (Registered, TGA program and subject)
Student
studentUID
studentIdentifier
either firstGivenName or familyName
deceasedIndicator (False)
surveyAvailability (Available)
emailAddressPrimary
Program
programUID
programOrSubjectReferenceNumber
nominalHours
Program Offering
programOfferingUID
programUID
Program Enrolment
programEnrolmentUID
studentUID
programOfferingUID
scheduledCompletionDate
lifecycleStates containing at least studentStatus (Registered) and studentActivityDate
Subject
subjectUID
programOrSubjectReferenceNumber
nominalHours
Subject Offering
subjectOfferingUID
subjectUID
parentProgramOfferingUID
Subject Enrolment
subjectEnrolmentUID
studentUID
subjectOfferingUID
parentProgramEnrolmentUID
scheduledStartDate
scheduledCompletionDate
lifecycleStates containing at least studentStatus (Registered) and studentActivityDate
vetInSchoolIndicator (False)
Minimal unit record - Program Enrolment
The MUR-PE is the smallest first‑time submission payload that establishes a student, a program, at least one subject within that program, and a registered enrolment relationship between them, without triggering any conditional lifecycle, delivery, funding, or completion rules.
MUR-PE golden payload
Create transaction batch
Upload Student
Upload Program
Upload Program Offering
Upload Program Enrolment
Upload Subject
Upload Subject Offering (linked to Program Offering)
Upload Subject Enrolment (linked to Program Enrolment)
Rules tagged as being in scope for MUR-SE and MUR-PE
Rules which are in scope when validating the golden MUR payloads are identified in the business rules catalogue. This is not a complete list of all rules which reference attributes in the MURs. Rules which are conditionally out of scope (for example, age‑based, lifecycle‑based, or scenario‑specific rules), or rules that are guaranteed to pass by construction, are intentionally excluded. This provides SMS suppliers with a stable and predictable baseline to confirm that core integrations are working as expected, including:
Transaction batch creation
Upload endpoints
Validation services
Submission workflows
By limiting scope to this baseline, SMS suppliers can confidently verify their technical integration is sound without being impacted by conditional or future‑state validations.
Please note, these rules are not intended to describe how validation behaviour may change if data values, structures, or reporting scenarios are modified. They do not answer questions such as “What additional rules might apply if I change X?” or “What validations will apply in other lifecycle states or scenarios?”. Those rules may still apply in broader or more complex submissions but are intentionally excluded to preserve clarity and stability for initial integration.