As of 10 July 2026, our learning platform is listed on NCVER’s AVETMISS Compliant Software Register — the National Centre for Vocational Education Research’s public list of systems that can produce correctly-formatted AVETMISS files. We appear on it as Lattice Learn, by Lattice Labs Pty Ltd. That is worth announcing. It is also worth being precise about, because this register is one of the most casually misrepresented credentials in Australian VET software.
Here is the part almost no vendor puts in the announcement: NCVER states plainly that being on the register does not constitute endorsement, sponsorship or approval of the software, gives no warranty as to its quality, and that registration is entirely optional. Listing says one thing and one thing only — the system can output files in the shape the standard requires. It says nothing about whether the data inside those files is correct. We think stating that clearly is the credential. A vendor who blurs the line between “produces valid file formats” and “approved by the regulator” is telling you how they will handle the next ambiguous compliance claim too.
What the register actually confirms — and what it doesn’t
The register is a formatting outcome, not a regulator sign-off — and not a verdict on the data inside the files. Passing the check means a system can emit the fixed-width records the standard defines, with the right fields in the right positions. It does not mean a regulator has audited how the software works, blessed its design, or vouched for the accuracy of any particular return. Being AVETMISS-compliant on formatting does not guarantee the underlying data is right — a file can be structurally perfect and still describe the wrong outcome for the wrong learner. So the honest framing is narrow on purpose: we are listed on the register, not “NCVER-approved,” “NCVER-certified,” or “endorsed.” Those words would be doing work the register never does.
What AVETMISS actually is
AVETMISS — the Australian Vocational Education and Training Management Information Statistical Standard — is the national data standard Registered Training Organisations use to report VET activity to NCVER. It is not a friendly CSV you design yourself; it is a published specification down to the character.
The detail most summaries get wrong is that there is no single “AVETMISS version.” The current VET Provider Collection standard is Release 8.0, which applies to all training activity since 1 January 2018, and it is defined across two separate documents: the collection specifications and the Data Element Definitions, which carry their own edition. The Apprentice and Trainee Collection is a different collection again, with its own release number. Collapsing all of that into one label is exactly the kind of imprecision that produces a bounced return, so we build against the actual documents rather than a marketing shorthand.
The ten files, and why they have to agree with each other
Our platform generates the ten core VET Provider Collection NAT files: NAT00010 (training organisation) and NAT00020 (delivery location); NAT00030 (program/qualification) and NAT00060 (subject/unit of competency); the client-side files NAT00080 (client), NAT00085 (client contact), NAT00090 (disability) and NAT00100 (prior educational achievement); and the activity files NAT00120 (training activity/enrolment) and NAT00130 (program completed). Of these, NAT00010 and NAT00080 are the always-mandatory files.
Each NAT file is a set of fixed-width text records, built field-for-field to the published specification. But the harder requirement is not per-file formatting — it is referential integrity across the files. The records are relationally linked: only the delivery locations, subjects, programs and learners actually referenced by the activity and completion files carry through into the others. An enrolment that points at a subject the subject file never declares is not a valid return, however clean each file looks in isolation. Because our learning layer lives inside the same compliance schema as the enrolment and outcome data that drives it, the export is a view over the source of truth rather than a nightly reconciliation between two systems that can quietly drift apart.
Validation before export, not fabrication
Before anything is exported, a built-in validation step reads the data and sorts what it finds into two piles. Blocking errors are the omissions that make a return invalid — a missing USI, date of birth, outcome, nominal hours, field of education, or delivery location and state — and they stop the export until they are fixed. “Not stated” warnings are different: they cover the demographic fields where NCVER accepts a documented “not stated” value, so the return can proceed without inventing a fact nobody recorded.
The rule underneath both is the one that matters most: missing values are surfaced to the administrator for correction, never silently filled with a plausible-looking guess. A system that quietly fabricates a nominal-hours figure to make an export succeed has produced a correctly-formatted lie, which is precisely the failure the register cannot catch for you. To be clear about our own claim, too — these files are built to the Release 8.0 specification and pass our pre-export validation. We do not claim they have passed NCVER’s own tooling, because that step belongs to the RTO, for reasons that follow.
The USI is protected information, not a spare key
Under the Student Identifiers Act 2014 (Cth), the Unique Student Identifier (USI) is protected information — not a general-purpose key you get to scatter through a system because a form had a box for it. We treat it that way by design. The USI is kept contained to the single NAT file that lawfully carries it, the client file NAT00080; it is kept out of application logs and audit trails; and it is never printed on the testamur — the qualification or statement-of-attainment document — which the Act requires. Verifying a USI before a qualification is issued is part of the design: a verify-before-issue posture rather than an afterthought.
Two honest boundaries on that. This is a description of design principles and protected-information handling, not a claim of a live registry integration operating today. And the reason the number can stay off the printed credential without weakening it is that authenticity is proven elsewhere — in the ledger behind a certificate you can’t fake, not on the face of the document. It is one more piece of what separates a course tracker from a platform an RTO can actually run on.
Where our job ends and the RTO’s begins
The same honesty applies at the other end of the process. RTOs validate and lodge their NAT files through NCVER’s free web-based AVETMISS Validation Software (AVS); files that contain errors cannot be submitted and must be corrected first. Total VET Activity (TVA) must be reported to NCVER at least annually — a nil return if there was no activity in the period.
The software prepares compliant files. It does not discharge the legal obligation. Lodgement and reporting remain the RTO’s responsibility, and no register listing, ours included, moves that line. What we can do is prepare the return carefully and surface every gap we can catch, so that the return the RTO puts through AVS is as clean as the records behind it. That is the whole point of treating training records as evidence you can defend rather than data you happen to store: the return is only ever as trustworthy as the recordkeeping underneath it, and formatting was never the hard part.