The minimum metadata set is a simplified application of the Australian Government Recordkeeping Metadata Standard 2.2 (AGRkMS), which:

  • is focused only on the Record entity of the AGRkMS
  • identifies metadata properties essential for agency management of business information or transfer to the Archives and other agencies
  • facilitates metadata implementation and information use in agencies
  • supports interoperability and information sharing across government via standardised metadata.

Using the minimum metadata set

The minimum metadata set can be used:

  • to identify the metadata your systems need to allow easy and accountable capture, retrieval and disposal of records
  • to describe records at the item or aggregate level in systems
  • with the Archives' Business System Assessment Framework to assess information management functionality requirements for business systems
  • when it is impractical to meet the full requirements of the AGRkMS
  • with other metadata standards, including the AGRkMS, when additional metadata is required to suit your business needs.

The minimum metadata set can be implemented through system configuration or governance measures, or a combination of the two. For example, if all of the information in a business system can have the same disposal class, format, or rights metadata applied at aggregate level, this could be recorded in system governance documentation or information asset register, rather than being recorded against individual records within the system.

Using the minimum metadata set can help meet requirements of the Building trust in the public record policy by:

  • ensuring business systems meet functional and minimum metadata requirements for information management (action 10)
  • assessing interoperability maturity, identifying gaps and planning to address them (action 11).


The minimum metadata set is cumulative and arranged in three levels: Core, Additional and Transfer. Each level has corresponding metadata properties. The value and expected longevity of information determines the amount of metadata that must be kept about it. You must use at least the properties of the Core level to meet minimum requirements to manage all your information, and then use other levels for information of higher value.

Level Applicable record type Property
Core All records in systems, including high-volume, low value information in transactional systems. Identifier
Date Created
Additional Higher value and long-term records. Title
Protective Marking
Disposal Class
Transfer Business information of archival value, or records to be transferred between systems or agencies. Rights
Integrity Check

However, you should also use Additional or Transfer properties for lower value information if there is a business need or other requirement. For example, it is a requirement of the Protective Security Policy Framework that agencies apply protective markings for sensitive or security-classified information, regardless of its value or length of use. For high-volume, low value information that could otherwise be managed with the Core properties alone, meeting this other requirement can be done using the Protective Marking property from the Additional level properties.

Property reference tables

Below are the reference tables for each level. These include essential information to help you understand each property and how they can be used. 

Core properties


Derived from AGRkMS 2.1, Identifier String.  
Purpose The Identifier is a string of characters, numbers or letters, or a combination thereof, that uniquely identifies a record within a given domain. It acts as an access point to find an information asset within a system.  
Value Unique character string.  
Conditional sub-property AGRkMS 2.2, Identifier Scheme. If the Identifier is assigned according to a defined scheme, you must also include the Identifier Scheme property. See AGRkMS Appendix D3 (pdf, 1850KB) for an extensible list of schemes.  
Examples Identifier B22-0156222
  Identifier 883252015
  Identifier Scheme Sys ID [Agency System B22]

Getting the most out of the Identifier property

While recording a single Identifier value satisfies the requirements of the minimum metadata set, it is important to note that a record may have more than one Identifier. For example, records that have been migrated between systems. Recording all Identifiers assigned to a record over time is preferred, particularly for long-term or high-value records. This can help preserve the relationships between records where past identifiers have been used for cross-referencing purposes. In a table format you can record additional identifiers by adding extra columns with different names, for example:

  • Identifier 1
  • Identifier 1 Scheme
  • Identifier 2
  • Identifier 2 Scheme

The Identifier property can also be used to capture relationships between records. In a table format this can be achieved by including additional columns with different names to record the identifier of an aggregate of which the individual record belongs, such as:

  • Parent Identifier
  • Parent Identifier Scheme


Derived from AGRkMS 3.1, Name Words.  

The Creator is the individual, work group or agency that created a record. It is essential to:

  • show ownership for evidence and context purposes
  • identify the creator of the record
  • support user searching, allowing information to be filtered.
Value Name of the individual, work group and/or agency that created the record (free text). If only one Creator value is recorded, it is preferable to record the name of the individual author.  
Conditional sub-property AGRkMS 3.2, Name Scheme. If the Creator is assigned according to a defined scheme, you must also include the Name Scheme property.  
Examples Creator Individual Peter Davison
  Creator Work Group IT Help Desk
  Creator Agency National Archives of Australia
  Creator Agency Name Scheme Australian Government Organisations Register

Getting the most out of the Creator property

While recording a single Creator value satisfies the requirements of the minimum metadata set, it is preferable to record all relevant Creators. Recognising contributors other than the Creator, such as authorising officers in a workflow process, can also provide valuable contextual information, particularly if you also record their role or position. It will not only enrich the record, it will also streamline searching, sentencing, and identifying authorisers for destruction or transfer. You can add other contributors in a table format by adding extra columns with different names, for example:

  • Creator Agency
  • Creator Agency Name Scheme
  • Creator Individual
  • Creator Individual Name Scheme
  • Creator Individual Role
  • Approver Individual
  • Approver Individual Role.

Use of the Agent and Relationship entities from the AGRkMS would enable the capture of more robust hierarchical and approval metadata if required.

Date Created

Derived from AGRkMS 4.1, Start Date.  
Purpose The Date Created property records the date a record first came into existence. It does not represent the date on which the content was finalised, or the date of digitisation. It provides evidence that the record is authentic, and is required for applying disposal actions, sentencing, and transfer to the National Archives of Australia.  
Value Date the record was created. Dates should be entered in accordance with AS/NZS ISO 8601.1:2021 (YYYY-MM-DD) and may optionally include time (YYYY-MM-DDThh:mm:ss).  
Conditional sub-properties If a record is closed for further action, you must use the Contents End Date sub-property to record the date of last action (derived from AGRkMS appendix D4.2, Recordkeeping Event Relationship Name Scheme, "Closes"). This sub-property is essential for sentencing, disposal and transfer to the National Archives of Australia. If a record has been destroyed, you must also use the Disposal Date sub-property (derived from AGRkMS 4.2, End Date).  
Examples Date Created 2013-10-06
  Date Created 2008-05-11T15:30:00
  Contents End Date 2020-02-15

Getting the most out of the Date Created property

It is also helpful to record the date of migration if a record is moved between systems or agencies, or the date last modified. Care must be taken not to overwrite the original creation date when a record is closed, migrated or modified. Audit metadata captured by a system may also include important dates related to recordkeeping events.

Sensitive information

It is a requirement of the Protective Security Policy Framework that agencies protectively mark information on systems that store, process or communicate sensitive or classified information. This can be achieved by using the Protective Marking property from the Additional set for all such records regardless of their value.

Additional properties


Derived from AGRkMS 3.1, Name Words; and 5, Description.  

The Title of a record describes its content. Its purpose is to:

  • enable information search and discovery
  • facilitate user choice
  • provide additional context.
Value A name or an account of the content of a record. The value can be free text or assigned wholly or in part by a name scheme. A record’s Title must be as meaningful and specific as possible to enable discoverability.  
Conditional sub-property AGRkMS 3.2, Name Scheme. If the Title is assigned according to a defined scheme rather than free text, you must also include the Name Scheme property.  
Examples Title Staff meeting minutes 20 April 2012
  Title Poster set of procedures for fire safety
  Title ACCESS MANAGEMENT - ADVICE - Procedures and updates for Examiners – 2009
  Name Scheme Agency B Business Glossary

Getting the most out of the Title property

While a single Title value is all that is required to comply with the minimum metadata set, adding separate Description fields is sometimes beneficial. In a table format this can be achieved by adding extra columns with different names, for example:

  • Title
  • Title Naming Scheme
  • Description.

Another way of improving the discoverability of records is by adding tags or keywords (as per AGRkMS properties 17.1, Keyword Term and 17.3 Keyword Scheme).

Care should be taken to ensure the Title is not overwritten when a record is modified or migrated.

For guidance on managing the quality of titles and descriptions, see Describing Information and What's in a Name?

Protective Marking

Derived from AGRkMS 9, Security Classification; 10.1, Caveat Text; and 26, Dissemination Limiting Markers (DLMs).  
Purpose The Protective Marking property denotes the security status of a record.  
Value Must include a security classification/marker (AGRkMS property 9, e.g. "OFFICIAL: Sensitive"), but may also include an information management marker (similar to AGRkMS property 26, e.g. "Personal Privacy") and caveat text (AGRkMS property 10.1, e.g. "NATIONAL CABINET") as required. These elements can be concatenated into a single field as per the examples below, or may be presented in separate columns. Values must be applied in accordance with the Protective Security Policy Framework (PSPF). See also AGRkMS and security classification of information.  
Examples Protective Marking OFFICIAL
  Protective Marking OFFICIAL: Sensitive – Personal Privacy

Getting the most out of the Protective Marking property

A record should only have one Protective Marking property assigned to it (or a combination of one security classification/marker, one information management marker, and one caveat text). It is acceptable to record more than one property if the current/valid property is clearly marked. This could be achieved in a table format by renaming any columns to show which are valid and which are not, e.g. 'Current Protective Marking', 'Superseded Protective Marking'.

Disposal Class

Derived from AGRkMS 18.2, Disposal Class ID.  
Purpose The Disposal Class is a number string that identifies the specific disposal class authorising the retention or destruction of a record. It can also indicate its function or subject.  
Value A number string known as 'class number' is used in records authorities issued by the National Archives of Australia. It may be drawn from agency-specific records authorities, general records authorities or the Administrative Functions Disposal Authority (AFDA).  
Examples Disposal Class 61755
  Disposal Class 20443

Getting the most out of the Disposal Class property

While a single Disposal Class value is all that is required to comply with the minimum metadata set, recording the name of the relevant records authority (AGRkMS property 18.1, Records Authority) and disposal action (AGRkMS property 18.3, Disposal Action) can assist with sentencing. This will ensure your agency makes accountable retention and destruction decisions. In a table format this can be achieved by adding extra columns with different names, for example:

  • Disposal Class
  • Disposal Records Authority
  • Disposal Action.


Derived from AGRkMS 19.1, Format Name; or 19.3, Creating Application Name.  
Purpose The Format property provides information about the format of a record to determine preservation, storage, migration, and other management actions. It only applies to digital records.  
Value Either the format name, extension or creating application name.  
Examples Format DOCX
  Format Portable Network Graphics
  Format Windows Media Video 9
  Format Oracle 9i (

Getting the most out of the Format property

Providing additional information about the format is recommended for unusual, complex, or very large records where that information will assist with its ongoing management. This might include the version of the format or the creating application, but can include other more specialised properties from sources other than the AGRkMS, such as the PREMIS Data Dictionary for Preservation Metadata. Recording the size and quantity of the record(s) (as per AGRkMS 20, Extent) is also advisable. In a table format this can be achieved by adding extra columns with different names. For example, it may be useful to record the following information about an RNA digital audio file using additional properties adapted from the AudioMD schema, and the AGRkMS Extent property:

  • Format (e.g. WAV)
  • Sampling Frequency (e.g. 48 kHz)
  • Bits per Sample (the bit depth, e.g. 24 bits)
  • Channels (e.g. 2, stereo).
  • File Size (e.g. 1036800)
  • File Size Units (e.g. KB)
  • Duration (e.g. 01:00:00).

If your system describes records stored on portable carriers such as external drives or DVDs, please also refer to the AGRkMS property 21, Medium. While the minimum metadata set was designed primarily for electronic records management, the Extent, Medium and Document Form properties from the AGRkMS can be used to describe paper and mixed media records as required.

Contact the Agency Service Centre for advice on the format metadata best suited to unusual or high value records.

Transfer properties


Derived from AGRkMS 12.1, Rights Statement.  
Purpose The Rights property must be used if there are non-security related restrictions or policies affecting the access to or use of a record.  
Value The Rights property is free text. For suggested values, please refer the AGRkMS appendices D12.1 (Rights Type Scheme) and D12.2 (Rights Status Scheme). You should note anything that affects a record’s access, either now or in the open period, regardless of whether it is listed in the above schemes.  
Examples Rights Authorised Public Access
  Rights Archival Access - Open
  Rights Embargo

Getting the most out of the Rights property

The Rights property may be repeated if more than one restriction or policy applies to a record. In a table format, this can be achieved by adding extra columns with different names, for example:

  • Rights Type 1
  • Rights Type 2.

Integrity Check

Derived from AGRkMS 22.1 Hash Function Name; 22.2 Message Digest.  

The purpose of the Integrity Check property is to prove the authenticity of records by:

  • verifying if a record has been altered in an undocumented or unauthorised way
  • ensuring the integrity of the original record over time.

An integrity check works by generating a message digest (AGRkMS 22.2) commonly referred to as a 'checksum' using an integrity algorithm (AGRkMS 22.1, Hash Function), based on the unique sequence of bits within a digital record. Comparing this value over time can determine whether the bits that make up a record have been changed in the course of transmission or storage. This process helps to check whether the integrity or 'fixity' of the record remains intact. Preservation strategies may be required to restore the record if an issue is identified.

This property only applies to digital records.

Value A record's unique message digest (a fixed length string) and the algorithm which created it.  
Example Integrity Check SHA512:d47270ba96511 de26995254b6757129b1 fc794a2d7374c04e1fcb 8c53051aa72fe7d4c75e 6a0fa7c0a8ad3b44db35 5ffc63d708881256407 c2609d5a00419fd

Getting the most out of the Integrity Check property

It is important that the message digest value is generated and recorded before a record is migrated or transferred to another agency, including the National Archives of Australia. It can then be regenerated after the record is moved or copied to assess its integrity.

In a table format, 'Message Digest' and 'Message Digest Algorithm' (Hash Function Name) can be entered in separate columns. Alternatively, the values can be concatenated, as in the example above, which is the SHA512 message digest for the PDF copy of AGRkMS version 2.2 available on the National Archives’ website. As per the National Archives’ transfer advice, message digests should be generated using an ASD (Australian Signals Directorate) approved hash algorithm.

Recording the file path of the record is advisable, so that you know where to run the integrity check. The date that the message digest was generated can also be very helpful, as recommended in preservation metadata schemes such as the PREMIS Data Dictionary. In table format, this can be achieved by adding a columns with names like:

  • Message Digest Date Generated
  • File Path.

Adding more properties

The minimum metadata set is extensible. Properties from other metadata schemas can and should be added to meet any additional business needs of your agency.

The property descriptions above provide some examples of how the minimum metadata set can be extended to meet specific information management needs, mostly with reference to the AGRkMS. You should also look to any industry-specific standards that may be relevant to your agency’s business beyond those issued by the National Archives.