If there was one word I would use to describe what is generally missing in strata records it is:
I’ll wait a minute while you check out that definition, it serves quite well for what I’m wanting to discuss.
Straight from that definition, the two primary attributes of strata records I’m looking for are:
- The state […] of being clear
- The ability to be easily understood
Which then, critically, gives a person looking at strata records:
- The ability to think clearly and rationally
When definitions 1 and 2 are missing in strata records, owners, prospective owners, committee members, building and strata managers…anyone, in fact, who comes into contact with an owners corporation, will not achieve definition 3.
So, given its primary role in the usefulness of strata records, I decided “clarity” would be the theme of this first blog post on the Select Strata Reports website.
Unlike my posts over at Strata, Meet Data, these posts will generally be shorter, and delve into one or two key points on a theme, all with the aim of lifting the shroud often obscuring strata records, and how I aim to hold that shroud back for potential strata owners.
In the matter of clarity of strata records, I’ll start with a key feature of all digital records:
filenames
When it comes to data, filenames are a form of metadata – i.e. data about the data.
As a side note, you’ll notice the word “metadata” in the prior paragraph has a dotted underline – hover over words on this site with such underlines and a “tooltip” with information about the term is shown. Try it out if you haven’t already.
A simple way to envisage data vs metadata is to consider a book on a shelf at the library and the entry for that book in the library’s catalog (those of us above a “certain age” would remember the catalog being stored on small cards).
The book is an object, the data, about which its catalog entry stores metadata: the title, author/s, ISBN, Dewey Decimal System number, number of pages, if the book is in the Reference section or not, etc.
Let’s bring things back to the topic of this post, clarity in strata records, and how filenames aid that.
Some strata filing systems do not use a descriptive title for a file record. I used the example of “lqeuotvr.pdf” in my post on Strata, Meet Data when announcing the launch of Select Strata Reports in reference to a management fees invoice I downloaded from my strata manager’s portal.
I won’t call out the software system by name – it’s not the only one to name files in that way, and I’m just trying to illustrate the general point.
Such strata management systems do store more useful information about the files within their database. For example, in the case of invoices, the creditor, date of invoice, etc. are stored in the database entry for the invoice (think library catalog record) for the PDF file data.
If it’s the case that information is available, a filename may seem superfluous – you could look up the entry in the database to view it, after all.
However, in the case of strata records, we want to not only view files in a custom database running on a strata management agency’s servers – we want to download them, e-mail them, keep copies of them for later reference or printing, provide them to prospective owners in a strata report, attach them to meeting agendas and minutes, and countless other uses.
And so, we extract/export/download the file from the database – we may even extract several files in one export while inspecting the records – and we get:
- lqeuotvr.pdf
- tu5z4ttj.pdf
- and so on
For my own use in my own strata scheme, when managing schemes as a strata manager, and also just generally in my day-to-day computer use, I always name (or, if needed, rename) files if I’m going to keep, use, or share them.
Over the last 45+ years of using computers, and especially over the last 30 years since I started my computer consultancy, I have slowly refined what my “ideal” filename looks like, and its simplest form (excluding file extensions like “.pdf” and “.docx”) boils down to:
[Unifier] [Subject] [Date]
A Unifier can be one or two pieces of information which describe the file at the highest level for grouping with similar files, for example:
- ATO SM for personal records of my dealings with the Australian Taxation Office
- SP735328 SCM for a scheme’s strata committee meetings
- SP735328 NSyd for the same scheme’s dealings with North Sydney Council
Subject is one or more pieces of data to further divide the file amongst its Unifier siblings, for example, for the above Unifiers I might then add:
- FY26 Assessment to distinguish from FY26 lodgements, as well as assessments from other financial years
- Minutes as opposed to the agenda, or a received proxy form
- AFSS Invoice X25367 to distinguish from pool certifications, or an AFSS lodgement form
You will see I do use abbreviations (sensible, I hope) where it seems appropriate.
Lastly, the Date – but not just “any” date. I always enter dates in filenames in ISO 8601 format: “yyyy-mm-dd”. So this post’s publish date in a filename would be shown as 2026-08-20.
I also include the date because a computer file’s date created and modified attributes may be based on the data creation date, or the file download date, or when I added an annotation, etc. and I want quick access to the most relevant date for that file (the date of the meeting, not the date the agenda was prepared).
I use this format because two filenames which are the same up to the date will then sort chronologically when displayed normally on a computer – consider “25/6/2025” and “21/6/2026” (and especially their counterparts “25 June 2025” and “21 June 2026”).
All else being the same in a filename, the 2026 file with such dates will be listed first in a standard listing on a computer (by name, alphabetically). Using the ISO 8601 format avoids such disordering – it has the added benefit of not being misinterpreted by computer systems (or people) as US vs Australian standard date formats may be (“m/d/y” vs “d/m/y”).
All of those pieces of metadata in my “ideal” name format are available in the systems which export files with names like “lqeuotvr.pdf”, and they should be used when exporting files in whatever fashion is available, but they aren’t.
As a strata inspector creating strata reports (and reviewing which files are and aren’t available), getting a bird’s eye view of all the strata records is obviously going to be difficult. However, it’s my job, above all else, to provide clarity on the strata records to my clients. But I can’t provide clarity without first achieving it for myself.
Hence, any files I have which are forming part of a strata report are renamed in the above fashion so I can determine, at a glance, if the capital works fund plan is out of date, or if AGMs are held consistently within the financial year, or if there’s a missing annual fire safety statement.
In the first instance, I am aiming to achieve clarity for myself. Then, and only then, am I in a position to write my report, where I aim to transfer that clarity to my clients…but that next step is the subject of my next post.
Strata Report Giveaway!
For reading this far, and to celebrate this first post, I will prepare a free strata report (valued at $385!) for a strata scheme in NSW (remote inspection for management agencies outside Sydney metro area) to the first commenter or contact via the details below who can correctly identify why I use the dummy strata scheme SP735328 (other than its unlikelihood to ever be issued!).
This prize is transferable, so if you or someone you know is looking to buy in strata and needs an independent, professional, and thorough strata report, get solving, get in touch, and maybe get some brownie points!
PS I publish this as I attend the first day of the Strata Impact Conference 2026. This is the third holding of this conference on the Gold Coast, and my third attendance. It’s a great opportunity to hear about new research in strata and community management, the psychology of managing communities, built environment trends, and other strata industry insights. Be sure to say “Hi!” if you’re attending as well!


Leave a Reply