Moreq2010 (Especificaciones) PDF

1212 1911 2989
12JC UH 1H1
"ºº
6122
l1U 31U 190!'1
' ( 1,
1 t V!UO !'1416
o 41U' 350l
IJU Sllt IH3
s,,, ocso ,,as S061
2U7 1122 lllt 11ll2
1212 1,11 299t ''ºº

123' '675 1H7 6822
• Jl,._!'I no 01u 1905

JotncTy "h:sc o,u :n5c 613•
5411 o,Jt ,toe 512C
02311 ,ns 427t 5c,,
.,_ 123C U1S 101 H22
nu JHt 01'5 no5
USf. 0tU 315C 613C
!'ltll Ollt 190C !'112C

n1"u;/•l'
431!1 nn "'" 5U6

0020 20l0 4U2 l!'lfl
• __'1.1, l!IJC IJCI !'llSC 16'l

.. r a1...,.:w,w:o..�•w11�
2121 1122 111' 1912
,,,. 1212 1'11 2Ht U00
123' C615 11'1 0&22
�11'1'15 310 01U 7'05
,,�,u 315, 613'
0631 "º' 512,

0231 1415 4271 !'1476
)t 4'75 1197 6822
,._, 074' 1905
U )15' ,134
"º' 5124
11 1 5416
'"'
MoReq2010® Modular Requirements for Records Systems
Volume 1
Core Services & Plug-in Modules
Version 1.1
•
MoReq2010
1;nz ltlll 2Hlil HOO
•
,. 4675 '11 • '822
84S 07H 7,0S
2J5t O!Hf 37!it 67lt
5UI oni H 4 112,

• 02lt 147 t27 9476
1 • � r
DLMFORUM
F O U N D A T I O N
MoReq2010
Volume 1
Core Services
Version 1.1 & Plug-in Modules
Copyright © 2010 & 2011 DLM Forum Foundation, all rights reserved
Contents
Figures .............................................................................................. 7
Part One – Core Services .............................................. 11

1. Fundamentals .................................................................................. 13
1.1 Important information ........................................................... 13
1.2 Purpose .................................................................................. 14
1.3 Background ............................................................................ 16
1.4 Primer .................................................................................... 20
2. System services ............................................................................... 31

2.1 Service information ................................................................ 31
2.2 Key concepts .......................................................................... 31
2.4 Functional requirements ....................................................... 39
3. User and group service ................................................................... 51

3.2 Key concepts .......................................................................... 51
4. Model role service ........................................................................... 57

4.2 Complying with the model role service ................................. 57
4.3 Key concepts .......................................................................... 59
•
5. Classification service ...................................................................... 69 MoReq2010

5.2 Key concepts .......................................................................... 69 Modular Requirements
for Records Systems
6. Record service ................................................................................. 77

6.2 Key concepts .......................................................................... 77
6.3 Aggregation and classification examples ............................. 88
7. Model metadata service .................................................................. 99 Volume 1

7.1 Service information ................................................................ 99 Core Services
7.2 Complying with the model metadata service........................ 99 & Plug-in Modules
7.3 Key concepts ........................................................................ 102
7.5 Functional requirements ..................................................... 106 Version 1.1
1
Contents
8. Disposal scheduling service ......................................................... 115
8.1 Service information .............................................................. 115
8.2 Key concepts ........................................................................ 115
8.4 Functional requirements ..................................................... 126
9. Disposal holding service ............................................................... 137

9.2 Key concepts ........................................................................ 137
10. Searching and reporting service .................................................. 141

10.2 Key concepts ........................................................................ 141
11. Export service ................................................................................ 151

11.2 Key concepts ........................................................................ 151
12. Non-functional requirements....................................................... 169

12.1 Key concepts ........................................................................ 169
12.2 The non‑functional aspects of a records system ............... 173
12.3 Non‑functional requirements for performance.................. 180
12.4 Non‑functional requirements for scalability ...................... 181
12.5 Non‑functional requirements for manageability ................ 183
12.6 Non‑functional requirements for portability ...................... 184
12.7 Non‑functional requirements for security .......................... 185
12.8 Non‑functional requirements for privacy ........................... 186
12.9 Non‑functional requirements for usability ......................... 187
•
MoReq2010 12.10 Non‑functional requirements for accessibility ................... 187
12.11 Non‑functional requirements for availability...................... 187
Modular Requirements 12.12 Non‑functional requirements for reliability ........................ 188
for Records Systems 12.13 Non‑functional requirements for recoverability ................. 189
12.14 Non‑functional requirements for maintainability............... 190
12.15 Non‑functional requirements for support .......................... 191
12.16 Non‑functional requirements for warranty ........................ 192
12.17 Non‑functional requirements for compliance .................... 193
13. Glossary .......................................................................................... 195
14. Information model ......................................................................... 241

Volume 1
14.1 Index to the information model ........................................... 241
Core Services 14.2 Entity types ........................................................................... 249
& Plug-in Modules 14.3 Data structures .................................................................... 265
14.4 System metadata element definitions ................................ 267
Version 1.1 14.5 Function Definitions ............................................................. 321
1
Contents
15. Acknowledgements ....................................................................... 459
15.1 Project team ......................................................................... 459
15.2 Experts Review Group .......................................................... 459
15.3 Consultees ........................................................................... 460
Part Two – Plug-in Modules..................................... 463

100. INtERFACE SERIES ....................................................................... 465
101. Graphical User Interface (GUI) ..................................................... 467

101.1 Module information.............................................................. 467
101.2 Key concepts ........................................................................ 467
101.5 Non‑functional requirements.............................................. 475
101.6 Glossary ................................................................................ 478
102. Application Programming Interface (API) ................................... 483

102.2 Key concepts ........................................................................ 483
102.6 Glossary ................................................................................ 487
200. ClASSIFICAtIoN SERIES.............................................................. 489
201. Hierarchical classification ............................................................ 491

201.2 Key concepts ........................................................................ 491
201.5 Non‑functional requirements.............................................. 499 •
MoReq2010
201.6 Glossary ................................................................................ 500
201.7 Information model ............................................................... 500
Modular Requirements
300. CoMPoNENt SERIES .................................................................... 507 for Records Systems
301. Electronic components.................................................................. 509

301.2 Key concepts ........................................................................ 509
301.6 Glossary ................................................................................ 520
301.7 Information Model ................................................................ 522 Volume 1
Core Services
& Plug-in Modules
Version 1.1
1
Figures
Part One – Core Services
Figure 1a — The MoReq Governance Board’s Roadmap (circa 2009)................................ 17
Figure 1b — The ‘traditional’ architecture of a records system includes capture of

records from other business systems and centralised management in a repository
controlled by the records system ........................................................................................ 18
Figure 1c — An alternative architecture is to manage records in place by allowing the

records system to apply controls and processes to records that have been declared in
situ ........................................................................................................................................ 18
Figure 1d — As records management controls and processes become simple, flexible

and better understood, it is increasingly possible that business systems will ‘become’
records systems, at least for the business records they themselves produce .................. 19
Figure 1e — One of these is probably not a record … the other may be ............................ 21
Figure 1f — Records are a subset of all information held by a person or organisation ... 21
Figure 1g — Records may be transferred multiple times between records systems

during their lifespan ............................................................................................................. 23
Figure 1h — In the future, multiple records systems may be able to share a single
centralised classification service ........................................................................................ 25
Figure 1i — A traditional hierarchical model of classification and aggregation where

both classes and aggregations are joined together into a single structure (this
approach can be implemented by an MCRS, but MoReq2010® also allows for greater
• flexibility)............................................................................................................................... 26
MoReq2010
Figure 1j — The structure of the MoReq2010® specification ............................................. 29
for Records Systems Figure 2a — A MoReq2010® compliant records system (MCRS) seen as a grouping of
interrelated services with a service‑based architecture (each core service has its own
numbered section of the specification) ............................................................................... 32
Figure 2b — User directly interacting with a records system through a GUI .................... 33
Figure 2c — User indirectly interacting with a records system through an API ............... 33
Figure 2d — Each entity has associated metadata, an event history and an access
control list ............................................................................................................................. 35
Volume 1
Core Services Figure 2e — A service contains entities with their own metadata, event history and
access control lists but is itself considered an entity with metadata, event history and
& Plug-in Modules an access control list ........................................................................................................... 36
Version 1.1 Figure 2f — The same event entity can appear in more than one event history ............... 38
1
Figures
Figure 2g — Each entity in an MCRS follows a similar life cycle ....................................... 39
Figure 3a — In an MCRS, users and groups have a many‑to‑many relationship ............. 52
Figure 4a — Functions are associated with roles (all functions should be included in
at least one role) ................................................................................................................... 60
Figure 4b — An access control list is made up of access control entries that link a
user or group to a role ......................................................................................................... 61
Figure 4c — Administrative roles override the operation of the Include Inherited Roles
Flag and are always inherited from parent entities ............................................................ 62
Figure 4d — Sometimes access control lists may be inherited from more than one
source ................................................................................................................................... 63
Figure 5a — Explanatory note: For illustrative purposes, each of the classes

appearing in diagrams in this module are depicted using a different shape and colour
(all are labelled as ‘Class’); in diagrams accompanying other modules, such as in
Figure 1i, all entities of the same type, such as classes, are given a uniform shape
and colour ............................................................................................................................. 70
Figure 5b — By default, all child aggregations and records will inherit their class
from their parent aggregation ............................................................................................. 70
Figure 5c — Classifying a child aggregation overrides the default class it inherits

from its parent aggregation ................................................................................................. 71
Figure 5d — Individually classifying a record overrides the default class it inherits

from its parent aggregation ................................................................................................. 71
Figure 5e — An example of a classification service that adopts a hierarchical

classification scheme........................................................................................................... 72
•
Figure 6a — Showing different levels of aggregation within a record service where MoReq2010
there is no single root aggregation...................................................................................... 78
Figure 6b — A record cannot be stored at the same level as an aggregation................... 79 Modular Requirements
for Records Systems
Figure 6c — By ordering on originated date and time, the records in an aggregation
can be browsed in a logical historical sequence ................................................................ 80
Figure 6d — An aggregation cannot retain its linear narrative if it contains both

records and aggregations at different levels....................................................................... 81
Figure 6e — When a copy is made of a record, it loses part of its event history and
does not have parity with the original ................................................................................. 81
Volume 1
Figure 6f — When a record is duplicated, the result is the equivalent of having two Core Services
original records with the same history up to the moment of duplication .......................... 82
& Plug-in Modules
Figure 6g — Each record has one or more components, each of which refers to a
single item of content of a particular type .......................................................................... 83 Version 1.1
1
Figures
Figure 6h — The principle of discreteness means that each component must belong
to only one record and its content must be separate and distinct ..................................... 84
Figure 6i — The principle of completeness means that each record must be fully
self‑contained and manage all dependent content within its own components ............... 85
Figure 6j — Under the principle of immutability, the content of a component must not
be able to be altered after record creation.......................................................................... 86
Figure 6k — Before records can be destroyed, under the principle of destructibility,

the corresponding component content must be erased from all content stores .............. 87
Figure 7a — Entity relationships in the model metadata service .................................... 103
Figure 7b — Each entity has an entity type ....................................................................... 104
Figure 7c — Each entity has system metadata elements and may also be given
contextual metadata elements .......................................................................................... 104
Figure 7d — All metadata elements are associated with a metadata element

definition ............................................................................................................................. 105
Figure 7e — System metadata element definitions are associated with an entity type . 105
Figure 7f — Contextual metadata element definitions are associated with templates,

which are in turn associated with an entity type ............................................................... 106
Figure 8a — Simple view of a record’s life cycle ............................................................... 116
Figure 8b — If its disposal schedule specifies permanent retention, no retention start

date will be set for a record and, without its disposal schedule being changed, it will
remain active for the life of the MCRS............................................................................... 119
• Figure 8c — If its disposal schedule specifies that a record be reviewed, a new disposal
MoReq2010
schedule must be applied to the record as part of completing and implementing the
review decision ................................................................................................................... 120
for Records Systems Figure 8d — If its disposal schedule specifies the transfer of a record then it is
destroyed by the MCRS, but only after the transfer is confirmed as completed ............. 120
Figure 8e — If its disposal schedule specifies the destruction of a record, there is

usually a confirmation period following the disposal due date ........................................ 121
Figure 8f — According to the principle of bottom‑up destruction, when the last record
in an aggregation is destroyed, the aggregation will be automatically destroyed, but
only when it has been closed ............................................................................................. 122
Volume 1
Figure 8g — A closed aggregation will be automatically destroyed when all of its child
Core Services entities, either records or other aggregations, have been destroyed: this may trigger
the destruction of its parent aggregation, etc................................................................... 123
& Plug-in Modules
Figure 8h — The integrated disposal process illustrating all the disposal choices
Version 1.1 provided within MoReq2010® ............................................................................................. 125
1
Figures
Figure 10a — However they are presented, a set of search results may be conceptually
pictured as a list of entities and their selected metadata in a user‑defined order ......... 143
Figure 11a — Significant entities, such as the class, disposal schedule and ancestor
aggregations for a record must be exported as placeholders. ........................................ 157
Figure 11b — An example of included entities are the components of a record: when
the record is exported in full, the components are also exported in full ......................... 158
Figure 11c — Another example of included entities are the children of aggregations:
all included entities are exported in full, so the included entities of included entities
will be exported in full ........................................................................................................ 159
Figure 11d — Showing both included entities which are exported in full and significant
entities which are exported as placeholders .................................................................... 159
Figure 11e — A typical access control list: each access control entry associates a
user or group with one or more roles ............................................................................... 160
Figure 11f — All of the entities referred to by the access control list must be exported
as placeholders .................................................................................................................. 161
Part Two – Plug-in Modules
Figure 201a — The main features of hierarchical classification are top‑level classes,
parent classes and child classes; the hierarchy can extend to any depth but most
traditional hierarchical classification schemes adopt a three‑level hierarchy ............... 492
Figure 201b — Hierarchical classification when applied to a root aggregation is

inherited as the default classification for all descendants of that aggregation; this
mirrors the traditional approach of combined classification/aggregation hierarchies .. 493
Figure 201c — Hierarchical classification can also be used in non‑traditional ways;

to override default classification at any level by applying it to child aggregations or
directly to records............................................................................................................... 494 •
MoReq2010
Figure 201d — The descendant classes of hierarchical classes that are exported
must be exported in full, while the ancestor classes of hierarchical classes must be Modular Requirements
exported as placeholders................................................................................................... 495
for Records Systems
Figure 201e — Placeholders must be exported for all hierarchical classes up to

the top‑level class that are ancestors of the class used to classify aggregations and
records that are being exported in full .............................................................................. 496
Figure 301a — While records and components are entities in the MCRS, the content
of electronic components may be stored, by design, in any of a number of different
data stores in different locations ....................................................................................... 510
Figure 301b — Electronic content must be transportable; the originating system must Volume 1
be able to output it in a format that allows it to be transmitted to a receiving system
that can input and understand it (neither system need necessarily be an MCRS).......... 511 Core Services
& Plug-in Modules
Figure 301c — An example of a record (in red) of the invoice numbered 09356 which is
stored in a relational database: individual rows from three different tables collectively
make up the complete record ............................................................................................ 513 Version 1.1
1
1212 l!Hl 2989 8400
chai:set•utf-SH>
1234 4675 7897 6822
1
3785 3849 0745 7905
2354 0946 3754 6734
5438 0638 5724
0239 8'75
P A R T I – C o R E S E R V I C E S 0745 7905
2354 0946 3754 6734

-,� "" "" '438 0638 6904 5724
4389 67&9 6756 506
0020 2030 4892 3593
Fundamentals
11934 8348 5384 16113
◄5444 0450 6 85 go,8
2127 8122 1119 1982
1212 1911 2989 8400
1234 4675 7897 6822
0745 7905
,;-� -1.PJtUfti-ka Jo1.nery"> ◄ 3715 3949
. 2J54 094' 3754 6734
543l 0638 6904 5724
0239 8'75 4218 5476
� 1234 4675 7197 6822
37115 31149 0745 7905
2354 0946 3754 6734
su, 0638 6904 5724
4 389 67119 6756 5486
0020 2030 4892 3593
1934 8341 5384 8683
al9111i"' 5 44 4 0450 6485 9068 >

:
u :n 11122 8119 1982
1212 1911
2989 "ºº
1234 4675 71197 6822
3785 3849 0745 7905
2354 0946 3754 6734
5438 0638 6904 5724
0239 1475 4278 5476
1234 4675 7897 6822
785 3849 0745 7905
54 046 3754 6734
U 0631 6904 5724
,189 6756 5416
4892 3593
38( U83
U 9068
1 1
..
982
MoReq2010 ®
Modular Requirements for Records Systems for Records Systems
Part one
Core Services
Volume 1
Core Services
& Plug-in Modules
Version 1.1
•
MoReq2010 11
1
Fundamentals
1.1 IMPoRtANt INFoRMAtIoN

1.1.1 Intellectual property rights
The MoReq2010® specification is copyright © DLM Forum Foundation,
2010 & 2011, all rights reserved, including all text and original illustrations
included with the work.
Some illustrations make use of royalty‑free clip art sourced from Microsoft q
8 4
Corporation (http://www.microsoft.com/). •
i;.444 Q4 90 8
•
Reproduction of this work is authorised, except for commercial purposes, 1 81 119 ll8
provided the source is acknowledged. All acknowledgements should be to �,d.2 .a. Jl.1. "'"
4.,
the DLM Forum Foundation (http://www.dlmforum.eu/).
l'i, )1 bd22
' ., o l '
'
o¡
1.1.2 Authenticity <
,,
4 6 714
J O 38 b 04 • 24
The latest updated version of this document is only available online 84 76
• •
(http://moreq2010.eu/ or http://www.dlmforum.eu/).
< "
4 7 ea 2
• •
The DLM Forum Foundation does not update, support or endorse the
<
MoReq2010® specification on any other websites, services or distribution

mechanisms.
1.1.3 Citation
This publication should be formally cited as:
DLM Forum Foundation, MoReq2010®: Modular Requirements for Records
Systems — Volume 1: Core Services & Plug-in Modules, 2011, published online
(http://moreq2010.eu/).
•
1.1.4 translations MoReq2010
Permission must be obtained before any translation of MoReq2010® is
published or otherwise distributed for any purpose. Translators should Modular Requirements
apply by e‑mail to the DLM Forum Foundation secretariat for permission for Records Systems
([email protected]).
Permission to make a translation of MoReq2010® is subject to allowing the
DLM Forum Foundation and its members to freely copy, use and distribute
the translation for non‑commercial purposes and to host the translation on
the MoReq2010® website.
1.1.5 logos and trademarks

The DLM Forum Foundation logo, the MoReq Governance Board logo and
Volume 1
the MoReq2010® logo are copyright © DLM Forum Foundation, 1996 to
present. Core Services
The terms ‘DLM Forum’, ‘MoReq’, ‘MoReq2’ and ‘MoReq2010’ are regis‑ & Plug-in Modules
tered community trademarks of the DLM Forum Foundation.
The symbol of the European Commission is used with permission. Version 1.1
13
1
1 P A R T I – C o R E S E R V I C E S
Fundamentals
1.1.6 Conventions used in this publication
Throughout this specification all formal requirements and all datatype defi‑
nitions are prefixed for easy identification:
• D: Data structure,
• E: Entity type,
• F: Function definition,
• M: Metadata element definition,
• N: Non‑functional requirement, and
• R: Requirement (functional).
Note that any reference numbers prefixed in this way are for document
look‑up purposes only, are relative to a specific minor version of MoReq2010®
and may be subject to change in any future major or minor version as
requirements and definitions are added or changed.
Records systems and other applications implementing MoReq2010® should
always use the universally unique identifiers provided by the information
model.
Both functional and non‑functional requirements in this specifica‑
tion may be accompanied by an explanatory rationale in italics. Where
provided, the rationale is intended to provide clarity and amplification to the
requirement.
1.2 PURPoSE
1.2.1 objective
MoReq2010® aims to provide a comprehensive but simple and easily
understood set of requirements for a records system that is intended to
be adaptable and applicable to divergent information and business activi‑
ties, industry sectors and types of organisation. It avoids a ‘one size fits all’
approach to implementing a records management solution by establishing
instead a definition of a common set of core services that are shared by
many different types of records system, but which are also modular and
flexible, allowing them to be incorporated into highly specialised and dedi‑
• cated applications that might not previously have been acknowledged as
MoReq2010 records systems.
The purpose of this document is to describe the minimum functionality
Modular Requirements required of a MoReq2010® compliant records system, to define common
for Records Systems processes, such as export and disposal, and to establish and standardise
on an underlying information model that includes entity types, data struc‑
tures, metadata element definitions, and function definitions. Where they
are fully implemented, these will reliably support and underpin records
system interoperability, including the successful transfer and migration of
records in mid‑life cycle, between differently implemented but compliant
solutions from the same and different suppliers.
The functionality described by the MoReq2010® specification is purposefully
intended to be built on and extended through a series of modules covering
both generic and specific topics that will be developed in the coming months
Volume 1 and years, overseen by the DLM Forum Foundation’s MoReq Governance
Board, to meet the needs and demands of different markets, industries,
Core Services countries and regions.
& Plug-in Modules
Separate guidance will be issued by the MoReq Governance Board covering
backwards compatibility for those consumers wishing to upgrade from
Version 1.1 MoReq2® to MoReq2010®.
14
1
P A R T I – C o R E S E R V I C E S 1
Fundamentals
1.2.2 Audience
This specification may be used in many different ways, including:
By businesses:
• as an aid for the procurement of a records system;
• as a practical tool in helping organisations configure records systems
to meet their business and legal obligations; and
• as a guide to the audit of an existing records system implementation.
By experts:
• as a reference document for training courses and the preparation of
course material;
• as a teaching resource for academic institutions; and
• as an example of how traditional records management approaches and
archival science can be applied to modern systems requirements.
By industry:
• to guide the development of records systems by suppliers;
• to integrate records systems with other business systems; and
• as the authoritative source when undertaking the testing and certifica‑
tion of compliant solutions by accredited test centres.
By users:
• as a user‑centric and easily understandable resource and primer on
implementing records systems;
• as the original for all translations; and
• as a reference glossary for guidance on records management terms
and their meanings.
1.2.3 Best practice

MoReq2010® is best used within consumer organisations as part of an
overarching records management policy within a well‑developed strategic
framework. Educating users, encouraging adoption, fostering a corporate
culture of good practice around records and information, raising awareness •
of information governance requirements, highlighting and briefing staff at MoReq2010
all levels on important considerations such as security, privacy, data sensi‑
tivity, freedom of information and open data initiatives as well as putting in
place clear, practical manual procedures accompanied by quality assurance Modular Requirements
checks are all equally as important as automation and the integration of a for Records Systems
records system into the business environment.
Implementing good records management requires forward planning, antici‑
pation of the issues that will arise and the development and implementation
of organisational policies and procedures that cover what records should be
kept, how records are created and captured, how records are held, managed
and accessed throughout their active life cycle and all aspects of their even‑
tual disposal. This forward planning needs to reach beyond the limited
lifespan of any one technology or system solution and consider the question
of how records will be migrated to the next corporate records system with Volume 1
the same weight as is given to how to ensure their capture into the current
records system. Core Services
Within such an environment, the adoption and use of MoReq2010® compat‑
& Plug-in Modules
ible records and business systems can make a sound organisational
investment. Version 1.1
15
1
Fundamentals
1.3 BACkGRoUND
1.3.1 MoReq®
The first MoReq® specification was published in 2001 as a result of close
cooperation between the DLM Forum® and the European Commission.
MoReq® provided a new pan‑European specification for computer systems
that manage electronic records. Prior to its publication, there were only
a few countries in Europe with their own national standards for records
management.
Even from its earliest publication, MoReq® has always had the following
characteristics.
• Universal in scope and application: MoReq® is an international speci‑
fication and has been used and adopted across a large number of
countries, including many outside Europe.
• Available in many languages: MoReq® and its successor MoReq2®
have been translated in full into over a dozen European languages,
and some non‑European languages.
• De facto standardisation: Although originally conceived as a specifi‑
cation and not a de jure standard, MoReq® is today widely recognised
as a de facto industry standard because of its universal appeal, availa‑
bility and adoption.
‘MoReq’ was first used as an abbreviation for ‘Model Requirements’ and it
was originally envisaged that the specification would provide a template set
of requirements that would then be further modifiable to meet local needs.
The first edition, therefore, contained guidance on how to add, edit and
delete chapters and requirements, and to manage issues such as cross‑
referencing within the specification while doing this.
1.3.2 MoReq®
In 2005, the DLM Forum® completed a scoping study aimed at updating and
extending the original MoReq® specification. The result of this review was
the development of MoReq2® and its publication in early 2008.
A key feature of MoReq2® was the inclusion, for the first time, of a testing
• and certification regime. Suppliers could now have their solutions tested at
MoReq2010 a MoReq2® testing centre and receive independent certification that their
products were compliant with the specification. In order to support testing
and certification, MoReq2® introduced a metadata model into the specifi‑
Modular Requirements cation, as well as an XML schema that was intended to define a common
for Records Systems import/export format across different products and implementations.
The introduction of the testing and certification programme in MoReq2® was
an extremely important and progressive step that introduced a necessary
element of rigour and quality assurance into the adoption of the specifi‑
cation. Suppliers with high quality products could now obtain independent
verification and evidence of conformance, while consumers could choose
from a set of products which all met recognised quality standards.
There was also, however, an unintended consequence brought about by the
testing regime and this lay with the very concept of ‘model’ requirements. If
Volume 1 products were to be pretested and certified against MoReq2®, it became more
difficult for consumer organisations to then take the specification and alter it
Core Services at the local level. How could the supplier of a common off‑the‑shelf software
& Plug-in Modules product, which had already been tested and certified as compliant, antici‑
pate within the application later additions, changes or deletions to individual
requirements at the organisational level? Another related issue was that as
Version 1.1 the complexity of the specification increased, how could organisations be sure
16
1
Fundamentals
of the subtle ramifications of adding, altering and deleting requirements, in
their total effect on the integrity of the specification as a whole?
In December 2008, at its triennial conference in Toulouse, the DLM Forum®
appointed a permanent subcommittee to be called the MoReq Governance
Board. The role of the MoReq Governance Board was, and remains, to
manage all aspects of the MoReq® specification including to:
• provide for its ongoing maintenance, publish a roadmap for MoReq®
and plan for future upgrades of the specification;
• manage the translation programme, arrange for the validation of
accepted translations and give guidance to MoReq® translators;
• grant accreditation to recognised test centres to undertake software
testing against the specification;
• oversee the testing and certification of software products against
MoReq® by accredited test centres;
• run a parallel education programme including providing workshops
and training, issuing supplementary guidance and educational mate‑
rials; and
• actively market the specification, collect case studies and encourage
its adoption while simultaneously protecting the MoReq® brand.
1.3.3 MoReq® roadmap

In 2009, the MoReq Governance Board produced a roadmap for MoReq®,
which was subsequently adopted by a DLM Forum® resolution at a members’
meeting in Härnösand, Sweden, in November that year.
The roadmap (Figure 1a) identified that while the MoReq® specification was
widely viewed by industry as addressing the requirements for mainstream
records management in traditional, often office‑based or clerical, domains
such as Electronic Document and Records Management Systems (EDRMS)
and Enterprise Content Management (ECM), it was also seen as less appli‑
cable for adoption in areas such as medical, pharmaceutical, legal and finan‑
cial services where specialised applications that solved domain‑specific
problems were the norm. These industry sectors were typically governed by
sector‑specific legislation and regulation and, as a result, tended to invent
and adopt their own set of records management criteria.
MoReq2010º
for Records Systems
_,.,.
(M,R,q,
Q
1
�
Volume 1
MoReq MoAe<¡l MoReq20l0 Fulure
Core Services
•
tfm�
& Plug-in Modules
' "
Figure 1a — The MoReq Governance Board’s Roadmap (circa 2009)
Version 1.1
17
1
Fundamentals
Another trend the MoReq Governance Board identified was the increasing
heterogeneity within records system design. Conceptually, MoReq® was
originally based on a single centralised repository model where an organi‑
sation’s stand‑alone records system would capture records into its own data
store from a variety of external sources, including users and other business
systems. This traditional architecture is shown in Figure 1b.
Business Records
System System
capture
..
ond
manage
-
records
•
central/y
(tioReq2010'
�º
Figure 1b — The ‘traditional’ architecture of a records system includes capture of records
from other business systems and centralised management in a repository controlled by
the records system
The MoReq Governance Board’s roadmap recognised an expanding adop‑

tion of alternative architectures. One emerging model (Figure 1c) is that
of the storage‑less records system that manages records in situ within the
business systems in which they originate, rather than duplicating them into
its own centralised repository.
Business Records
System System
•
MoReq2010 .,,
.,,
.,
.,,
Modular Requirements .,,
for Records Systems .-�,�.,, .,, "in place" records
management
•
MoReq2010
Figure 1c — An alternative architecture is to manage records in place by allowing the

records system to apply controls and processes to records that have been declared in
situ
Another possible architecture is the adoption of records controls by the

Volume 1
business system itself. Such a business system is, in effect, simultaneously
Core Services a records system albeit one that manages only the specific set of records
captured or generated by that particular business system. This approach
& Plug-in Modules
where the application is its own records system can also be described as ‘in
app’ records management. The business system as a records system model
Version 1.1 is shown in Figure 1d.
18
1
Fundamentals
Business
System
Hin appH records
I monagement
D MoReq2010'
Figure 1d — As records management controls and processes become simple, flexible and
better understood, it is increasingly possible that business systems will ‘become’ records
systems, at least for the business records they themselves produce
The MoReq® roadmap also identified the need for flexible and scalable require‑
ments that were equally applicable to both large and small records manage‑
ment solutions. MoReq2® had more than doubled the number of functional
requirements and nearly tripled the number of pages of its predecessor. It was
clear that each successive edition of MoReq® could not continue to similarly
grow in size and complexity and remain primarily a single block of require‑
ments, or it would eventually, in itself, provide an insurmountable barrier to
adoption, particularly by smaller, local and niche suppliers. For these reasons,
the 2009 roadmap called for two future phases of MoReq® evolution.
• In the short term, starting in 2010, the launch of a refactoring project
that would reorganise the specification along modular lines, simpli‑
fying it where possible, and introduce support for alternative records
systems architectures.
• In the longer term, from 2012, with the assistance of specialised
industry experts, and based on the flexibility afforded by a more
modular approach, to broaden the applicability of MoReq® into all •
MoReq2010
fields of human endeavour where the sound management of records
is an essential prerequisite.
The first of these objectives was realised by the DLM Forum Foundation Modular Requirements
AGM in Madrid, May 2010, where the MoReq2010® work programme was for Records Systems
officially launched.
1.3.4 MoReq2010®
In addition to innovation within the specification itself, the DLM Forum
Foundation decided to incorporate two phases of public consultation into
the development of the new specification, while the European Commission
appointed the MoReq2010® Experts Review Group comprising a cross‑
section of world‑renowned industry experts to advise on the project. By
opening up the consultation phases to the public, an increased aspect
of collegial and social networking was introduced to the development Volume 1
programme. The resulting specification has thereby benefited from having
Core Services
been developed and discussed in an open way, with an unexpectedly high
quantity and quality of collaborative input. & Plug-in Modules
Records management today can be a complex undertaking and MoReq2010®,
with its flexible and extensible architecture, provides one possible approach Version 1.1
19
1
Fundamentals
to navigating the pitfalls of specifying a records system implementation that
is attractive and suitable for suppliers, practitioners and consumers alike.
With MoReq2010® the concept of ‘model’ requirements has been replaced
by that of ‘modular’ requirements. The now established programme
of pretesting and certification of software products and the increased
emphasis on interoperability negates the value of modifying and custom‑
ising individual requirements. Appropriately, there is no longer any need
for this as the new modular approach allows consumers to easily specify a
flexible yet comprehensive and cohesive set of organisational requirements
simply by choosing a suitable combination from a selection of modules that
correspond to their organisational needs. Over time, the number and variety
of modules that build on the platform of the MoReq2010® core services
will steadily increase and extend coverage into more and more industries,
sectors and jurisdictions.
Suppliers will also benefit from the refactoring of MoReq2010®. While the
set of additional extension modules will continue to grow and embody more
and more specialised applications, the core set of requirements is corre‑
spondingly reduced by comparison. The core services are the only require‑
ments that all records systems must have in common and with which they
must show compliance. The implementation of, and certification against,
other modules then depends on the particular focus of a given product, its
target sector and its degree of specialisation or generalisation: suppliers
are, therefore, free to pick and choose which functionality to implement to
meet their target markets, in the same way as consumers may pick and
choose the modular requirements that are significant to them.
The third group that will benefit directly from the approach taken by
MoReq2010® is records management experts and practitioners. MoReq2010®
seeks in every aspect to directly tie leading records management theory and
best practice into the specification. Professionals will find that concepts,
terms and models adopted by MoReq2010® are closely linked to those used
in other international standards and propounded by leading experts. In addi‑
tion to its practical application, the specification, therefore, forms a sound
learning and educational platform.
The year 2011 marks the 15th anniversary of the DLM Forum® and the
10th anniversary of MoReq®. Launched alongside these significant anni‑
•
MoReq2010 versaries, MoReq2010®, the next generation version of the ‘model require‑
ments’, points squarely to the future as both catalyst and springboard for
the improved recognition, understanding and adoption of good records
Modular Requirements management throughout Europe and internationally.
for Records Systems
1.4 PRIMER
1.4.1 Records and information
Every organisation and every citizen has and uses records.
Records are those pieces of information that have an intrinsic worth which
makes them important enough to save and keep secure for their evidential
value.
Most people, for example, have several records in their possession which
Volume 1 they keep as proof of their identity. These may include:
Core Services • a birth certificate,
& Plug-in Modules • a passport,
• a driver’s licence, and/or
Version 1.1 • an identity card.
20
1
Fundamentals
In each of these examples, the importance of the record, and its evidential
nature, is obvious. However, this may not always be the case. People do not
usually regard all of the pieces of information they have in their possession
necessarily as records.
For example, a shopping list might not be regarded as a record but the
receipt from the shop where the goods on the shopping list were bought
provides proof of purchase and may be considered a record if it is important
to an individual or a business. Such a receipt could be used to claim back
expenses from an employer or to receive a refund when returning damaged
or spoilt goods. This example is illustrated by Figure 1e.
MoR.q2010
Figure 1e — One of these is probably not a record … the other may be
The distinction between information and records is the same for organisa‑
tions as for individuals: for any organisation, it can be stated that the set of •
all its records is a subset of the set of all its information assets, as shown in MoReq2010
the Venn diagram Figure 1f.
MoReq2010' for Records Systems
lnformation
Records
Volume 1
Core Services
& Plug-in Modules
Figure 1f — Records are a subset of all information held by a person or organisation

Version 1.1
21
1
Fundamentals
In order to decide whether a piece of information is a record or not, its busi‑
ness context must be understood as well as its relevance and significance to
the organisation. An important task for any organisation, therefore, is to gain
an understanding of its business and to be able to use this understanding
to evaluate what information it requires to be retained and managed as its
records.
Information assets that belong to an organisation, but are not regarded as
records, such as the early drafts of a document, or an incomplete trans‑
action, must be considered transient and should be routinely excised. For
example, intermediate drafts might be erased when a document is published
and partial transactional information might be erased when the transaction
is completed or cancelled.
Failure to excise transient information may, at best, waste the organisation’s
data storage capacity with redundant or incomplete copies, and waste staff
time sorting out which information is complete and correct and which is
partial. At worst, it may be in breach of privacy or other regulations or lead
to costly exercises compiling the information if it is called for as part of a
legal action or freedom of information request, or similar.
1.4.2 Records management processes and systems

Published in 2001, perhaps the most influential standard in records manage‑
ment internationally is ISO 15489 (ISO 15489‑1:2001: Information and docu‑
mentation — Records management — Part 1: General).
Determining the information that must be managed as records is only
the first of the records management processes it identifies. The full list of
records management processes identified by ISO 15489 includes:
• determining how long to retain records;
• creating and registering records;
• classification of records;
• storage and handling of records;
• controlling access to records;
• tracking records;
• disposing of records; and
•
MoReq2010 • documenting records management processes.
ISO 15489 proposes that an organisation should use a records system to
Modular Requirements implement these processes. It defines a records system as an ‘information
system which captures, manages and provides access to records through
for Records Systems
time’ (ISO 15489‑1:2001, 3.17).
MoReq2010® is a specification for defining a records system expressed as a
modular set of requirements. It goes beyond the broad description offered by
ISO 15489 and adds a far greater level of specificity in how these processes
should be carried out. Achieving Moreq2010® compliance requires a greater
degree of rigour than can be achieved by simply building a records system
that handles the records management processes described by ISO 15489 in
its own proprietary way.
One of the advantages of this, and a design goal of MoReq2010®, is the
Volume 1 potential for interoperability between MoReq2010® compliant records
systems (MCRS). An MCRS does not only understand its own entities and
Core Services
its own processes, it can export them to a standardised format that can be
& Plug-in Modules understood by another MCRS.
Interoperability is essential to the management of records using a records
Version 1.1 system. Today’s organisations typically refresh their technology every three
22
1
Fundamentals
to five years. Records are often held for much longer than that. If an organi‑
sation is required to keep a particular record for 75 years then, at the end of
that period, it will typically have been transferred from one records system
to another between 15 and 25 times. This is shown in Figure 1g. If each
transfer results in some loss of contextual information about the record,
then this number of transfers may have a severe impact on the record’s
integrity.
MoReq;!.010'
record record record record
creoted trons/erred trons/erred trans/erred
etc.
Records Records Records
System System System
Figure 1g — Records may be transferred multiple times between records systems during
their lifespan
It should be noted that import is not part of the core services of an MCRS,
but every MCRS must be able to export its information to the MoReq2010®
common XML export format. Import requires a far higher level of application
sophistication than export and mandating it for all records systems would
preclude many dedicated business systems from adopting MoReq2010®.
1.4.3 the nature of records

Almost anything that has informational of evidential value can be managed
as a record. ISO 15489 formally defines a record as ‘information created,
received and maintained as evidence and information by an organisation or
person, in pursuance of legal obligations or in the transaction of business’
(ISO 15489‑1:2001, 3.15). •
In the past, records were mainly paper‑based but in the 21st century this MoReq2010
is relentlessly being replaced by the exponential increase in electronic
information. However, the need for systems that perform physical records
management will always remain, both for paper records and for other phys‑
ical records, for example to keep track of biomedical or forensic samples. for Records Systems
All records, whether physical or electronic, have certain characteristics and

ISO 15489 lists these essential characteristics as follows.
• Authenticity: the record is what it purports to be and was created by
the person purported to have created it.
• Reliability: the information in the record is accurate and can be
depended on.
• Integrity: the record is complete and unaltered.
• Usability: the record can be located, retrieved, presented and Volume 1
interpreted.
Core Services
An MCRS can only ensure these characteristics from the point at which the
& Plug-in Modules
record is created in the records system. As stated in ISO 15489, ‘Records
should be created at the time of the transaction or incident to which they
relate, or soon afterwards, by individuals who have direct knowledge of the Version 1.1
23
1
Fundamentals
facts or by instruments routinely used within the business to conduct the
transaction’ (ISO 15489‑1:2001, 7.2.3).
The statement indicates two ways in which records may be created, either:
• they are created by an individual; or
• they are created by an instrument.
In MoReq2010®, both humans and business systems are regarded as possible
‘users’ of a records system and may be authorised to create records. An
MCRS may be developed to interface only with human users, or with other
business systems, or both.
In addition to the characteristics listed previously, all records in a records
system must also have metadata associated with them. Metadata is defined
by ISO 15489 as ‘data describing context, content and structure of records
and their management through time’ (ISO 15489‑1:2001, 3.12).
1.4.4 Entities and services

A MoReq2010® compliant records system manages records as entities.
Records are only one of the entity types defined by the specification. In
addition to records, MoReq2010® also defines a number of other entities of
different types. For example, MoReq2010® defines a ‘user entity type’ that
represents the users that access the records system and a ‘class entity type’
for each entry in the records system’s classification scheme etc. A full list of
entity types may be found in 14.2 Entity types.
Even though the entities managed by an MCRS are of different types,
MoReq2010® attempts to make them as uniform as possible in the way that
their metadata is represented and their event history is managed, and in
their access controls and entity life cycle. Unlike the entities in other infor‑
mation systems, entities in an MCRS are destroyed, rather than deleted,
leaving a residual entity that remains in the MCRS. Residual entities are
an important concept in records systems as they indicate entities that were
once present in the system: without them, it would not be possible to recon‑
struct the full context of an historic record.
Within an MCRS, entities of different types are nominally described as being
managed by different services according to a ‘service‑based architecture’
• (see 2. System services):
MoReq2010 • a user and group service manages user entities and group entities
(see 3. User and group service);
Modular Requirements • a role service manages roles (see 4. Model role service);
for Records Systems • a classification service manages classes (see 5. Classification
service);
• a record service manages records and aggregations of records (see
6. Record service);
• a metadata service manages metadata and metadata templates (see
7. Model metadata service);
• a disposal scheduling service manages disposal schedules (see
8. Disposal scheduling service); and
• a disposal holding service manages disposal holds (see 9. Disposal
Volume 1 holding service).
Other services are purely process‑based and do not manage entities,
Core Services including:
& Plug-in Modules • a searching and reporting service (see 10. Searching and reporting
service), and
Version 1.1 • an export service (see 11. Export service).
24
1
Fundamentals
While it uses the language and promotes the adoption of a service‑based
architecture, MoReq2010® acknowledges that, historically, records systems
have not necessarily delivered functionality using a discrete service model.
For this reason, MoReq2010® does no more than merely bundle its functional
requirements into logical services and test against each ‘service’ (bundle)
of functional requirements individually. An MCRS that does not provide
discrete services in its implementation will still be certified as compliant to
the MoReq2010® specification.
Nonetheless, the approach taken by MoReq2010® is deliberate and antici‑
pates a future where interoperability is not confined to the transfer of records
from one MCRS to another, but where different records systems can share
the same services in common. Within an organisation of the future, it might
be possible for all records systems to make use of a single user and group
service, a single role service, a single classification service, a single meta‑
data service, a single disposal scheduling service, a single disposal holding
service and/or a single searching and reporting service.
Such an approach would allow, for example, a business classification
scheme to be defined once across the whole organisation and managed
centrally using a shared classification service (Figure 1h). The same applies
equally to other services.
Records MoReq2010°
System
Central
Records Records
System System
•
MoReq2010
Figure 1h — In the future, multiple records systems may be able to share a single centra‑ Modular Requirements
lised classification service for Records Systems
Shared service utilisation will not necessarily be confined to the boundaries

of a single organisation. For example, a regulator could issue and maintain
a standardised set of disposal schedules to be used by all organisations in
a particular sector by hosting them as a widely accessible disposal sched‑
uling service, or a disposal holding service shared between litigants might
manage the disposal holds issued by a particular legal court.
1.4.5 Classification and aggregation

Volume 1
There are several other new concepts in MoReq2010®, such as the distinc‑
tion made between classification and aggregation. ISO 15489 defines clas‑ Core Services
sification as the ‘systematic identification and arrangement of business & Plug-in Modules
activities and/or records into categories according to logically structured
conventions, methods and procedural rules represented in a classification
system’ (ISO 15489‑1:2001, 3.5). Version 1.1
25
1
Fundamentals
While classification is concerned with providing the business context for a
record and establishing the relationship between a record and the trans‑
actional activity by which it was created, aggregation describes the activity
of assembling related records together. Unlike classification, aggregation
may be based on any organisational requirement or criteria, not business
context alone. Aggregation is layered, with higher level aggregations made
up of an assembly of lower level aggregations. A whole record service might
arguably be considered to represent one high level aggregation.
Historically, some records management specifications conjoin a hier‑
archical classification scheme above a layer of aggregation so that each
record always inherits its class via its aggregation. This approach, shown
in Figure 1i, uses classes in place of higher level aggregations. Such an
arrangement, while desirable for its simplicity if it can be achieved, is also
inflexible and does not always lend itself to real‑world usage. The restric‑
tions this approach imposes have led, in many cases, to organisational and
subject‑based elements being mixed into a functional business classifica‑
tion scheme to create a localised hybrid.
'
�oReq2010°
Class • Aggregation
MoReq2010•
, Relatlonship 8 Record
Modular Requirements Figure 1i — A traditional hierarchical model of classification and aggregation where both
for Records Systems classes and aggregations are joined together into a single structure (this approach can be
implemented by an MCRS, but MoReq2010® also allows for greater flexibility)
Many organisations undertake collaborative teamwork, casework or

project‑based work. Where these activities occur, the natural tendency
within organisations is to aggregate records based on the main topic, such
as the particular project, and not based purely on the business activity or
process that creates the record.
For example, a small association may keep records about each of its
Volume 1 members in a single aggregation per member. Within each member aggre‑
gation there might be found:
Core Services • the member’s original registration form, assessment and approval;
& Plug-in Modules • identification, banking and contact details including various change
notifications;
Version 1.1 • annual subscription and membership renewals;
26
1
Fundamentals
• applications, appointments and offices held within the association;
• correspondence and other information on various association activi‑
ties undertaken by the member;
• expenses and reimbursement claims;
• contracts, certificates, legal documents and waivers;
• etc.
In this example, the records in the member aggregation relate to different
functions, activities and transactions and should, therefore, attract different
business classifications. There may be legal, regulatory or good practice
reasons based on these classifications why some records in each member
aggregation must be retained for a relatively long statutory period, while
other records in the aggregation should only be kept for a short time and
then destroyed.
An arrangement like this, even though it is commonly found across organi‑
sations, is difficult to squeeze into a traditional hierarchical classifica‑
tion‑based structure as shown in Figure 1i. This is because in the traditional
arrangement, the whole member aggregation must fit under a single class
in the classification scheme.
As a result, there is inevitably a tension created between practical and oper‑
ational efficiency and records management needs. Either the classification
scheme is hybridised, for example by introducing omnibus classifications
such as ‘casework’, ‘clients’, ‘projects’, ‘staff’ and ‘events’ or naturally occur‑
ring aggregations are split up so that, for example, the registration records
for all members are to be found together under a single classification/
aggregation such as ‘membership applications’, while annual subscription
records for all members are collected in an entirely separate classification/
aggregation, such as ‘membership renewals 2011’. Neither compromise is
likely to be viewed as entirely satisfactory.
By providing a clear distinction between the related concepts of classifica‑
tion and aggregation, MoReq2010® allows for greater flexibility in making
planning decisions about what records to keep together, combined with
what classification scheme to use and how to apply it. This, in turn, makes
MoReq2010® more adaptable to real‑world situations. The specification
allows aggregation to be based on operational criteria while classification •
MoReq2010
can be applied at any layer of aggregation, including even associating classes
with records individually if required (this is shown in Figure 5d and discussed
further in 5. Classification service). At the same time, backwards compat‑ Modular Requirements
ibility with the traditional approach shown in Figure 1i is maintained. for Records Systems
1.4.6 Retention and disposal
MoReq2010® closely associates business classification with retention and
disposal so that each class has an associated disposal schedule and each
record inherits its disposal schedule, by default, from its class (adopting the
principle that ‘classification determines destiny’). This is different to some
approaches where disposal schedules are inherited from a record’s aggre‑
gation and only indirectly from its classification.
A significant feature of disposal scheduling is that MoReq2010® does not Volume 1
allow a record to be subject to more than one disposal schedule simulta‑
neously. The specification permits the default disposal schedule, inherited Core Services
from the record’s class, to be overridden but, at any point in time, only one
& Plug-in Modules
disposal schedule can apply to a particular record. There is, therefore, no
opportunity for a disposal conflict to occur that requires direct user inter‑
vention to resolve. Version 1.1
27
1
Fundamentals
As each record in an aggregation may have a different classification to the
other records and each record also has its own disposal schedule inherited
from its class, it is possible that individual records within an aggregation will be
due for disposal at different times. This is determined by the disposal sched‑
ules that the organisation uses and what disposal triggers are specified.
MoReq2010® uses the principle of bottom‑up destruction to dispose of an
aggregation only when all of its contents have been destroyed and the aggre‑
gation is closed. Bottom‑up destruction is described in greater detail in
8.2.9 Bottom-up destruction. One of the advantages of bottom‑up destruc‑
tion is that it does not require that aggregations have disposal schedules.
There is only one type of disposal schedule in MoReq2010®, which is related
to the record.
Even though MoReq2010® applies disposal individually to each record, it is
possible to apply the same disposal action to many records simultaneously.
For example, MoReq2010® enables a user to authorise the same disposal
action once for an aggregation as a whole. This allows for ease of use while
maintaining a simple, yet flexible, approach to retention and disposal.
1.4.7 Event histories and audit

ISO 15489 requires the use of either metadata or, alternatively, audit trails
should be kept as ‘complete and accurate representations of all transac‑
tions that occur in relation to a particular record’ (ISO 15489‑1:2001, 8.3.2).
MoReq2010® adopts this approach but extends it by adopting the concept
of an event history for each record from ISO 23081 (ISO 23081‑1:2006:
Information and documentation — Records management processes —
Metadata for records — Part 1: Principles).
ISO 23081, an international standard on metadata for records, describes
an event history as follows: ‘The event history metadata group documents
past records events and other management events on both the entity and
its metadata. For each event, it specifies the type of event, what happened,
when it took place, why it occurred, and who carried it out. The metadata in
this element are a sequence documenting a specific event.’
In MoReq2010®, every entity has an event history associated with it. This
is particularly important in supporting interoperability, where entities are
• transferred from one records system to another. Each entity is transferred
MoReq2010 as a whole, including its metadata, event history, access controls, etc. The
event history is an integral part of the entity and this approach allows all
MCRSs to import and fully understand events that occurred to an entity
while it was part of a previous records system.
for Records Systems
Even though event histories are tied to entities, MoReq2010® still allows a
‘system audit trail’ view across an MCRS by allowing users to search across
all events for all entities and sort them by when they occurred. In this way, the
cumulative events from all event histories make up the audit trail for an MCRS.
Under MoReq2010®, event histories and metadata for entities are pruned
when entities are destroyed in line with ISO 15489 which states that ‘audit
trails should be kept at least as long as the document (i.e. record content) to
which they relate is retained’ (ISO 15489‑1:2001, 8.3.2).
Volume 1 1.4.8 Modular architecture

Core Services Figure 1j shows the modular architecture of MoReq2010®. Each box in
& Plug-in Modules the diagram represents a bundle of requirements representing either a
service or a module. The core services are defined in Volume 1 of the speci‑
fication and provide the minimum set of functionality for compliance with
Version 1.1 MoReq2010®: in other words, they define the simplest possible MCRS.
28
1
Fundamentals
M0Rcq2010·
ii '
•
�
E1ttenslon
PLUS PLUS
e
Modules >
t
n ii ii "
PLUS PLUS PLUS PLUS
Core Services
iiiil liii iiiil �. - ',
��
liiiiil liii
Plug-lo Modules □ □ OR
Series
Figure 1j — The structure of the MoReq2010 specification

®
Some of the functionality described by the core services can be implemented

in alternative but equally valid ways. Where this occurs, MoReq2010® makes
use of plug‑in modules. Each plug‑in module represents exactly the equiva‑
lent functionality as any of the other plug‑in modules in the same series.
An MCRS must implement the functionality described by at least one of the
plug‑in modules in a series and may choose to implement more than one
plug‑in module.
Plug‑in modules are used by the core services to allow flexibility around the
following areas of functionality.
• type of interface: including whether the MCRS is managed directly by
users through a human/computer interface or as a business support
system through a machine interface.
• type of classification: allowing an MCRS to adopt different approaches
to classification, for example a hierarchical classification scheme.
• type of record components: allowing an MCRS to support different •
types of records, such as electronic components rather than physical MoReq2010
components.
The core services and plug‑in modules described in Volume 1 of the Modular Requirements
MoReq2010® specification form the essential platform on which different for Records Systems
extension modules can be hosted. The range and variety of extension
modules to MoReq2010® will be extensive and will cover:
• additional services such as import;
• further concepts such as vital records;
• specific technologies such as e‑mail; and
• requirements for records systems for particular industries and
jurisdictions.
As shown in Figure 1j, extension modules can build on to each other as well
as extending the core services. The preface to each module contains a list of
Volume 1
its prerequisites and co‑requisites. Core Services
Prerequisites define a dependency where the MCRS must implement the & Plug-in Modules
prerequisite module as well as the extension module. Co‑requisites are
modules which attract additional functional requirements, if they are imple‑
mented simultaneously with the extension module. Version 1.1
29
1
Fundamentals
1.4.9 Model services
The development of MoReq2010® has required compromise between the
state of the records management industry today and the vision of the future
promoted by the specification and the MoReq Governance Board. This compro‑
mise is particularly apparent across two services: roles and metadata.
In the interest of interoperability, MoReq2010® seeks to codify both an entity’s
access controls and its metadata elements so that they can be transferred to
a new records system where they will be successfully imported, understood
and used. Metadata can describe valuable contextual information about the
original entity, while access controls, even when they are superseded in the
receiving system, provide important knowledge about who had access to
which records in the original records system.
Because no preceding specification has sought to address these issues
through standardisation, suppliers have, by necessity, implemented their
own individual and proprietary methods of applying metadata and access
controls within their records system software. As a consequence, an unrea‑
sonably large amount of refactoring would be required within these existing
records systems to adopt a metadata model or an access control model that
was common to all MCRSs.
For this reason, MoReq2010® specifies these two services as model serv‑
ices. A model service is an exemplar service: it is intended to be adopted as
the appropriate way to develop new records management software in the
future, without impeding existing products from seeking compliance with,
and certification against, MoReq2010®.
MoReq2010® accepts either of two different methods for proving compliance
with a model service. Method A is to implement the functional requirements
for the model service and be tested against them. Method B, intended mainly
for pre‑existing software, is to demonstrate a proprietary solution that is as
rich in functionality as the model service and where the constructs and data
are able to be converted and exported as if they had originated in a records
system that implements the model service. This requirement is essential
for compliance with any model service: the entities, their metadata and their
access controls must be able to be meaningfully exported to the standard
MoReq2010® XML export format. If this can be achieved, then another MCRS
•
MoReq2010 can import the entities and use them in conjunction with a model service.
1.4.10 testing and certification

The DLM Forum Foundation has initiated a testing and certification programme
for Records Systems for MoReq2010®. The programme allows suppliers of common‑off‑the‑shelf
(COTS) records systems, as well as in house records systems, to be tested by
a DLM Forum Foundation accredited MoReq2010® test centre.
Suppliers must have their products tested against the core services and
may optionally have any of the additional extension modules tested as well.
Following the successful completion of testing using the MoReq2010® test
framework, a product or installation may become certified by the DLM
Forum Foundation as MoReq2010® compliant.
Suppliers will be able to show that their products are fully certified as
Volume 1 MoReq2010® compliant while members of the DLM Forum Foundation will
benefit by having access to the test reports, allowing them to undertake a
Core Services preliminary analysis of different MoReq2010®compliant records systems.
& Plug-in Modules
The DLM Forum Foundation will publish lists of accredited MoReq2010® test
centres and certified MoReq2010® compliant records systems on its website
Version 1.1 (http://www.dlmforum.eu).
30
1
2
System services
2.1 SERVICE INFoRMAtIoN

Each of the core services of MoReq2010® is defined by its service name (e.g.
user and group service), its service version (e.g. 1.0) and its Implements
Service Identifier (e.g. cd532472‑85b0‑4c1c‑82b4‑5c8370b7d0e6), or
Implements Module Identifier for plug‑in and extension modules.
These details can be found in the service information block (see 3.1 Service
q
information). The Implements Service Identifier is a universally unique iden‑ 4
tifier used internally by an MCRS to show which services it implements.

i;.444 Q4 90 8
•
1 81 119 ll8
This section, 2. System Services, contains functionality common to all �,d.2 .a. Jl.1. "'"
MoReq2010® core services and, as such, does not have separate service 4., l'i, )1 bd22
information. Refer instead to the service information block for each service ' ., o l '
individually. <
o¡
'
4 6 714
,,
J O 38 b 04 • 24
2.2 kEy CoNCEPtS < "

84
4
• •
7 ea
76
2
• •
2.2.1 Service-based architecture <
The functional requirements of the MoReq2010® core are bundled into

nine service definitions, shown in Figure 2a. Taken together these services
describe the functionality required by an MCRS. This initial module, entitled
2. System services, describes the common functionality required by every
MoReq2010® core service.
The service‑based architecture of MoReq2010® is not intended to constrain
software suppliers from developing fully compliant solutions that combine
the functionality of many or even all core services together and deliver
them from within a single application. However, by dividing the architec‑
•
ture of MoReq2010® into separate services, future consideration may also MoReq2010
be given by suppliers to developing records systems where each of the
services is decoupled from the others and can then be shared between
more than one MCRS. Modular Requirements
for Records Systems
For example, in the future, each records system within an organisation
might be capable of sharing the same classification service or the same
disposal holding service. It may also be possible, in the future, to build
an MCRS by sourcing different services from different suppliers and inte‑
grating them together.
Whether provided as a single application, a tightly integrated or a loosely
integrated collection of services, all MCRS solutions must be tested against
the same compliance criteria.
At the heart of the service‑based architecture of an MCRS is its record Volume 1
service. The record service is the only core service that cannot be shared Core Services
with another MCRS. Indeed, it is literally only the record service that distin‑
guishes one MCRS from another. All other services that support the record
& Plug-in Modules
service may simultaneously support other record services and may, there‑
fore, be a part of several MCRS solutions simultaneously. Version 1.1
31
1
System services
_.. .... ------- .... �oReq2010'
, '
, '
, '
., " 4. Model ',
" R�e ,
" Servlee 5. '-
,' 3 User Classlfication ',
, and Group Servic:e \
\
,' ServiCe �
\
1 1
1
1 1
1
1
Interfaces
6. Record
___
Service
..___
7. Modol
Motadata
Servlee
1
1 Component 1
1 Stotage 1
1
1
1
8. Oisposal
1
11. Export
1 � Schedullng
-
I
SeMCO
1 I
\ I
\
I
\ 10.Search 9. Olsposal
I
\ and Reportlng Holdlng I
-
\ I
Servlee ,
' ,
' ,
'
'
• Coreservice � Features (nol sorvlces)
Model service ..... Suppons plug-ln modules
Figure 2a — A MoReq2010® compliant records system (MCRS) seen as a grouping of

interrelated services with a service‑based architecture (each core service has its own
numbered section of the specification)
•
MoReq2010
2.2.2 Model services and plug-in modules

Two of the core services of MoReq2010® are model services (these are
for Records Systems
4. Model role service and 7. Model metadata service). This means that
while the specification provides a default set of functional requirements
for each of these services, MoReq2010® does not require suppliers to
implement these services exactly as they are specified, except where
the supplier wishes to support advanced modules, such as the import
module.
There are also three areas within the core services where plug‑in
functionality is specified. Plug‑in modules represent alternative, but
equally valid, sets of functionality that achieve the same goal but in
Volume 1
different ways. Suppliers may choose which approach they adopt. Each
Core Services MCRS must provide support for, and be certified against, at least one
implementation of the functionality. It may also support, and be certified
& Plug-in Modules against, other alternative plug‑in modules in the same series as well.
The interface to the MCRS is an example of one area where plug‑in
Version 1.1 functionality is specified.
32
1
System services
2.2.3 Interfacing with users
MoReq2010® does not require that users always interface with records
systems directly.
In traditional records system implementations, users interact directly with
the records system through a graphical user interface (GUI) (Figure 2b).
MoReq2010•
n-�)nCRS
/V\ G�phlal user
L_J Interface
Figure 2b — User directly interacting with a records system through a GUI
Increasingly, records systems are being developed that support one

or several different business systems. These records systems do not
provide a graphical user interface but interact directly with the busi‑
ness systems using an application programming interface (API). In
this scenario, depicted in Figure 2c, the user performs functions in the
records system only indirectly as a result of the user’s actions in the
business system: the user may not even realise the existence of a sepa‑
rate records system.
MoReq2010'
)
Business
----:)� nCSR
• System
Appllcation
Programming
lnt,rf¡1c;t
Figure 2c — User indirectly interacting with a records system through an API

•
MoReq2010
MoReq2010® provides support for both these types of records systems
by allowing an MCRS to specify which type of interface it supports. An Modular Requirements
MCRS may also support more than one type of interface simultaneously.
for Records Systems
Similarly, each of the core services of MoReq2010® may support a different
interface option. For example, the user and group system may provide an
API while the searching and reporting system offers a GUI.
Throughout MoReq2010®, it is important to keep in mind that the user of an
MCRS is not necessarily a person: the authorised user could be a business
system instead.
2.2.4 Entity types and subtypes

Each MoReq2010® core service manages entities belonging to a specified
Volume 1
number of entity types. The MoReq2010® core services refer to the following
entity types. Core Services
• Access control lists, defined in 4. Model role service & Plug-in Modules
• Aggregations, defined in 6. Record service
• Classes, defined in 5. Classification service Version 1.1
33
1
System services
• Components, defined in 6. Record service
• Disposal holds, defined in 9. Disposal holding service
• Disposal schedules, defined in 8. Disposal scheduling service
• Entity types, defined in 2. System services
• Events, defined in 2. System services
• Function definitions, defined in 2. System services
• Groups, defined in 3. User and group service
• Metadata element definitions, defined in 7. Model metadata service
• Records, defined in 6. Record service
• Roles, defined in 4. Model role service
• Services, defined in 2. System services
• Users, defined in 3. User and group service
Tables giving the attributes of each of these entity types can be found in
14.2 Entity types.
Although access control lists and events are listed with the other entity
types, these are not independent entities. All entities, except access control
lists and events, will have an associated event history consisting of a series
of events and an access control list consisting of a series of access control
entries.
The entity types managed by each service can be found in 1.4.4 Entities
and services and in the rationale to R2.4.9. For example, the record service
manages aggregations, records and components, while the disposal sched‑
uling service manages disposal schedules. Where services are not logically
separated within an MCRS, then it must manage entities belonging to all of
the MoReq2010® entity types collectively.
MoReq2010® allows for specialised subtypes of each entity type. For
example, Metadata element definitions are divided into:
• system metadata element definitions, and
•
MoReq2010 • contextual metadata element definitions.
Each of these is a subtype of the base entity type metadata element defi‑
Modular Requirements nition. Subtypes are usually characterised by having extra system meta‑
for Records Systems data elements, compared to the base entity type, and by additional rules of
behaviour specified by the requirements.
Some entity types within the MoReq2010® core services are intentionally
designed to be a base type for entity subtypes; in addition to metadata
element definitions, these are:
• Classes: class subtypes are defined by different plug‑in modules in
the MoReq2010®, 200. Classification series
• Components: component subtypes are defined by different plug‑in
modules in the MoReq2010®, 300. Component series.
Volume 1
A Hierarchical class, defined in the 201. Hierarchical classification plug‑in
Core Services module, is an example of a subtype of the Class entity type. An electronic
& Plug-in Modules component, defined in the 301. Electronic Components plug‑in module, is
an example of a subtype of the Component entity type.
Version 1.1 Extension modules to MoReq2010® may add new entity types and subtypes.
34
1
System services
2.2.5 Anatomy of an entity
Most entities have three sets of information associated with them
(Figure 2d).
• Metadata: information that describes the entity, contained in meta‑
data element definitions and divided into system metadata (defined by
MoReq2010®), and contextual metadata (defined by the supplier and/
or the user).
• Event history a set of events associated with the entity that stores
information about the different functions that have been performed on
the entity.•
• Access control list: a list of access control entries specifying which
users and groups can perform functions on the entity, where specific
sets of functionality are collectively defined as roles.
•
MoReq2010
Entity
Meta data Event Access
History Control
list
Figure 2d — Each entity has associated metadata, an event history and an access control
list •
MoReq2010
Further information on how metadata is managed in MoReq2010® can be

found in 7. Model metadata service while event histories are discussed Modular Requirements
now. Information on access control can be found in 4. Model role service. for Records Systems
Events and access control entries share the event history and access control
list of the entity to which they belong. Components share the access control
list of the record entity to which they belong.
Each MoReq2010® core service is not just a container for entities of partic‑
ular entity types, but is itself regarded as an entity with its own metadata,
event history and access control list inherited by all the entities in that
service. The composition of entities and their relationship with services is
shown in Figure 2e.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
35
1
System services
�oRoq_2010°
Entity
Entity
MeUdaU [�t Aeoess

Entity
Htsto,y Conllol
Un
Entity Service
Mtlada� Evtnl A.t

u»
..
Hlllo,y COl'ltrol
Figure 2e — A service contains entities with their own metadata, event history and access
control lists but is itself considered an entity with metadata, event history and an access
control list
2.2.6 Identifying entities

Perhaps the most important metadata element for any entity is its System
Identifier. MoReq2010® requires universally unique identifiers (UUID) for
each entity and each service within an MCRS. The use of a UUID is manda‑
tory for compliance with the specification: this means that any entity can
be exported from one MCRS and imported into another MCRS and will
continue to be uniquely identified. The importing MCRS can even match
up different copies of the original entity that were exported at different
•
MoReq2010 times or were transferred to it via an intermediate MCRS. All entities can
be traced back to the specific instance of their originating service where
they were created.
for Records Systems 2.2.7 Performing functions
Users manipulate the entities in an MCRS by performing functions on them.
Sometimes, it is the MCRS itself that performs the function such as when it
generates a new System Identifier for a service at installation.
MoReq2010® is a requirements specification and each function that can be
performed to an entity in an MCRS can be traced back to one or more of the
functional requirements.
Users may only perform functions for entities where they have sufficient
Volume 1 authority to do so.
Core Services In accordance with 4. Model role service, the authority to perform a func‑
tion comes from associating a role with a user or a group to which the user
& Plug-in Modules belongs. Roles are then assigned to an individual user or group using an
access control entry which becomes part of either a service or an entity’s
Version 1.1 access control list (ACL).
36
1
System services
As discussed previously in 2.2.2 Model services and plug-in modules,
some MCRS solutions may deviate from the specific requirements of the
model role service, but all MCRS solutions must be able to provide a similar
and compatible degree of functionality. The meaning of a model role service
is discussed further in 4. Model role service.
2.2.8 Event histories

Each entity in an MCRS has an event history, made up of a series of events
that have occurred to that entity. Whenever a function is performed, whether
by a user or the system, in which the entity is a participating entity, an event
is generated and added to that entity’s event history. Each event in an event
history, therefore, correlates to a single function that has been performed
in the MCRS.
So as to avoid event histories growing too big, or being filled with trivial
events, MoReq2010® includes the provision for an authorised user to turn
off event generation for selected functions.
The metadata for an event is always set by the MCRS and must not be able
to be altered by a user. Events do not have an event history.
Different events will have different metadata depending on the function that
has been performed to generate the event. This makes it possible for an
event to appear in the event history of more than one participating entity:
some examples follow.
• If an authorised user changes the name of an aggregation, under
R6.5.3, then there is only one participating entity (the aggregation).
The event (F14.5.17 Aggregation — Modify Metadata) will appear only
in the event history of the aggregation.
• If an authorised user creates a record in an aggregation, under R6.5.10,
then there are two participating entities (both the aggregation and the
record) and the same event (F14.5.121 Record — Create) will appear
in the event histories of both.
• If an authorised user moves a record from one aggregation to another,
under R6.5.13, then there are three participating entities (the previous
parent aggregation, the new parent aggregation and the record). The
event (F14.5.3 Aggregation — Add Record) will have three participa‑ •
MoReq2010
ting entities and the single event will appear in three event histories
simultaneously.
• Under R6.5.21, a record is always a participating entity in functions Modular Requirements
that are performed on its components so that the events generated for Records Systems
always appear in the event histories of both the component and the
record to which it belongs.
Figure 2f shows how an event may belong to more than one entity’s event
history.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
37
1
System services
¡MoRcq2010
Participating Participating
Entity Entity
Event
Figure 2f — The same event entity can appear in more than one event history
A traditional audit trail may be conceptualised as a view of all events from

the event histories of all entities across the whole MCRS (in timestamp
order).
2.2.9 timestamps
MoReq2010® has particular features that allow records systems to interop‑
erate at a universal level. One of these is the use of timestamps.
The specification requires that timestamps must be applied by the MCRS as
metadata to accompany every event it generates. For example, each entity
has a created timestamp that indicates when the entity was created.
• Timestamps must contain complete and accurate date and time data,
MoReq2010
including time zone information, which allows events to be ordered in the
sequence in which they occurred. If an MCRS is capable of performing many
Modular Requirements events in a second, then the MCRS should provide millisecond or better
for Records Systems precision so that events remain in order when sorted by timestamp.
Timestamps support interoperability by allowing entities to be successfully
transferred to another MCRS in another time zone.
2.2.10 Universal language support

Another universal feature of MoReq2010® is its support for Unicode. All
textual metadata elements must be in Unicode format and must be accom‑
panied by a language identifier. An MCRS may support only one or a limited
Volume 1 number of languages. Nevertheless, so as to support interoperability, a
language identifier must be captured for all textual metadata.
Core Services
& Plug-in Modules 2.2.11 life cycle of an entity
Regardless of its entity type, all entities in an MCRS have a similar life cycle.
Version 1.1 An outline of an entity’s life cycle is shown in Figure 2g.
38
1
System services
MoReq2010
Creatlon event Destruction event
maybe Flrst used
deleted
RESIDUAL
ACTIVE
Timo
Figure 2g — Each entity in an MCRS follows a similar life cycle
Each entity will be created in the MCRS so that its first event is always its
creation event. The entity will then remain active until it is destroyed, gener‑
ating a destruction event. Following its destruction, the MCRS will retain a
residual entity to indicate that the entity previously existed in the MCRS.
All MCRS solutions must retain residual entities. Destruction is different to
deletion, where all trace of the entity is erased. It is not possible to delete
entities from an MCRS as if they had never been created unless they are
deleted before they are used: entities that have been used may not be
deleted.
Some entities, most importantly records and their components, but also enti‑
ties such as events, access control entries, system metadata element defi‑
nitions, etc., do not have a first used timestamp and may never be deleted.
Once they have been created, entities of these entity types may never be
erased without trace from an MCRS. The life cycle of a record is explained in
more detail in 6. Record service and 8. Disposal scheduling service.
2.4 FUNCtIoNAl REqUIREMENtS

•
MoReq2010
R2.4.1 An MCRS must implement the functionality of:
• a user and group service,
• a role service,
for Records Systems
• a classification service,
• a record service,
• a metadata service,
• a disposal scheduling service,
• a disposal holding service,
• a searching and reporting service, and
• an export service. Volume 1
Each service may be implemented individually or several services may be
bundled together. Core Services
Functional requirements for each of these services may be found in the
& Plug-in Modules
MoReq2010® core services. The MCRS may also implement additional function-
ality as defined in the extension modules to MoReq2010®. Version 1.1
39
1
System services
The MCRS may share any of its services, except its record service, with other
records systems. MoReq2010® does not specify how services are shared
between records systems.
The MCRS must implement the functionality described by these services;
however, there is no requirement to implement them as discrete services. The
MCRS may create each service separately or it may combine the functionality
of several services together into a bundle of services. The whole MCRS may
represent a single bundle of services.
R2.4.2 On installation, the MCRS must initialise the following metadata for each
service (E14.2.14), or bundle of services under R2.4.1:
• System Identifier (M14.4.100),
• Implements Service Identifier (M14.4.42),
• Implements Module Identifier (M14.4.41),
• MCRS Certification Identifier (M14.4.54),
• Supplier Information (M14.4.99),
• Default Language Identifier (M14.4.12),
• Title (M14.4.104),
• Description (M14.4.16), and
• Owner Information (M14.4.62).
Each service, or bundle of services, also has:
• entity types for each entity managed by the service or bundle;
• entities that are managed by the service or bundle;
• an event history for the service or bundle;
• an access control list (or equivalent, see 4. Model role service),
and may have:
• contextual metadata (or equivalent, see 7. Model metadata service).
Each service or bundle of services has its own metadata, event history, and
access control list. Each value of the metadata element Implements Service
Identifier must match a service published with the MoReq2010® specification
• (the value of the identifier is given in the service information block at the head
MoReq2010 of each section from 3. User and group service onwards). Each Implements
Module Identifier must match a module published with the MoReq2010® speci-
fication. Each MCRS Certification Identifier must match a certificate issued by
Modular Requirements the DLM Forum Foundation to an MCRS that has passed compatibility testing
for Records Systems with an accredited test centre and been certified.
Supplier Information should describe the supplier, the product and the version
of the product installed. It may also contain other useful information about the
supplier such as contact information and the URI for the product’s support site.
Depending on the approach taken by the MCRS in implementing 4. Model role
service, a MoReq2010® access control list may not be present during system
operation and may only be added to a service at export.
Depending on the approach taken by the MCRS in implementing 7. Model meta‑
data service, the mechanism by which contextual metadata is added to services
Volume 1 may vary.
Core Services R2.4.3 The MCRS must allow an authorised user to browse across its services, or
& Plug-in Modules bundles of services under R2.4.1, and inspect the metadata of each as listed
under R2.4.2.
Version 1.1 The terms ‘browse’ and ‘inspect’ are defined in 13. Glossary.
40
1
System services
The user may browse each service or bundle of services. If the MCRS combines
all functionality into a single bundle, then there will be only one set of metadata
to inspect for the system as a whole.
Function reference: F14.5.158
R2.4.4 The MCRS must allow an authorised user to modify the metadata for each
service, or bundle of services under R2.4.1, including:
• Title,
• Description,
• Owner Information, and
• Contextual metadata (if any).
The Owner Information gives information about the organisation or organisa-

tions using the MCRS and may include help desk or contact information. The
Title and Description should provide the local name of the MCRS and additional
descriptive information.
R2.4.5 The MCRS must allow an authorised user to generate a MoReq2010®

compliance report listing each of its active services, or bundles of services
under R2.4.1, and for each service or bundle listing the metadata for that
service or bundle under R2.4.2.
The report should indicate which services are implemented individually and
where several services are bundled together.
This requirement is intended to provide authorised users with assurance that
an installed MCRS is MoReq2010® compliant when implemented at a particular
site for a particular organisation. For this reason, the values of the Implements
Service Identifier, the Implements Module Identifier and the MCRS Certification
Identifier metadata elements listed against each service, must accurately report
the compliance status of the particular MCRS installation.
The report must do more than indicate whether the MCRS has historically
passed MoReq2010® compliance testing, the report must also indicate if the
MCRS has been installed and configured correctly and is compliant with these
services and modules at the time when the report is generated. MoReq2010®
does not specify how each individual MCRS should check its internal consist-
ency and configuration after installation; however, this is an important require- •
ment for operating an MCRS in a regulatory compliance environment. MoReq2010
R2.4.6 The MCRS must ensure that each service, or bundle of services under R2.4.1,
has an interface that implements one of the modules of the MoReq2010® for Records Systems
100. Interface series.
An MCRS, or different services within the MCRS, may implement more than one
of the 100. Interface series modules but each service, or bundle of services,
must be fully compliant with, and tested against, at least one interface module
in the 100 series.
R2.4.7 Whenever the MCRS fails to complete a function requested by itself or an

authorised user, the MCRS must write at least the following error informa‑
tion to an external log:
Volume 1
• the date/time of the failure;
• the System Identifier of the function that was attempted; Core Services
• the System Identifier of the authorised user that initiated the function; & Plug-in Modules
• the System Identifier(s) of any participating entities; and
• extended error information explaining the failure. Version 1.1
41
1
System services
This requirement refers to an error log that is not maintained within the MCRS
itself. The purpose of keeping a log external to the system is to make it acces-
sible even when the MCRS is not available.
Extended error information may generally be defined as diagnostic information
including error codes, details about the state of the system at the time the error
occurred, and software exceptions that were encountered. MoReq2010® does
not specify what extended error information should be provided by an MCRS.
Note that functions must be performed atomically. MoReq2010® does not
permit functions to be partially successful as this would leave the MCRS in an
undefined state. If a function fails at any point, then the MCRS must roll back all
changes to its internal state made by the function before they were committed.
MoReq2010® does not specify how this is done.
R2.4.8 Following the failure of a function requested by a user, under R2.4.7, the
MCRS must provide a means by which the user can retrieve extended error
information about the failed function without accessing the external log.
MoReq2010® does not specify the mechanism by which an MCRS should provide
extended error information following a failed function by a user. (This function-
ality is not included in the function definitions in 14.5 Function definitions.)
The way in which the MCRS communicates a failed function back to the user will
be dependent on the type of interface the MCRS provides (see R2.4.6).
R2.4.9 The MCRS must allow an authorised user to browse the entity types associ‑
ated with each service, or bundle of services under R2.4.1, and inspect their
metadata.
The following entity types are associated with each service:
• the user and group service manages user entities and groups;
• the role service manages roles;
• the classification service manages classes;
• the record service manages aggregations, records and components;
• the metadata service manages metadata element definitions and
templates;
•
MoReq2010 • the disposal scheduling service manages disposal schedules; and
• the disposal holding service manages disposal holds.
Modular Requirements Function definitions and events may be found in all the services that manage
for Records Systems one or more entity types.
For more information on each of these entity types, see 14.2 Entity types.
R2.4.10 Each entity type (E14.2.7) under R2.4.9, must have the following metadata:
• Title (M14.4.104), and
• Description (M14.4.16).
Volume 1 Each entity type also has:
Core Services • system metadata element definitions for that entity type,
& Plug-in Modules • function definitions for that entity type,
• an event history, and
Version 1.1 • an access control list (or equivalent, see 4. Model Role Service).
42
1
System services
System Identifiers for every entity type in MoReq2010®, along with default Titles
and Descriptions can be found in 14.2 Entity types.
The MCRS must always use the System Identifiers provided by MoReq2010®
and must not generate its own System Identifiers for entity types. However, the
default Titles and Descriptions may be replaced by the MCRS with localised
values.
R2.4.11 For each entity type, under R2.4.10, the MCRS must allow an authorised
user to browse the function definition entities associated with that entity
type and inspect their metadata.
For comprehensive lists of the function definitions associated with each entity
type, see 14.5 Function definitions.
R2.4.12 Each function definition (E14.2.9), under R2.4.11, must have the following
metadata:
• Title (M14.4.104),
• Description (M14.4.16),
• Generate Event Flag (M14.4.34), and
• Retain On Destruction Flag (M14.4.88).
Each function definition also has:
• system metadata elements to be added to events,
• an event history, and
• an access control list (or equivalent, see 4. Model role service).
System Identifiers for every function definition in MoReq2010®, along with
default titles, descriptions and the entity types to which they apply, can be found
in 14.5 Function definitions.
•
The MCRS must always use the System Identifiers provided by MoReq2010® and MoReq2010
must not generate its own System Identifiers for function definitions. However,
the default titles and descriptions of function definitions may be replaced by the
MCRS with localised values.
for Records Systems
R2.4.13 For each function definition, under R2.4.11, the MCRS must allow an
authorised user to specify whether or not an event should be generated by
the MCRS when the function is performed.
The value is stored in the Generate Event Flag (see R2.4.12).
Performing the function described by this requirement and changing the value
of the Generate Event Flag must always result in an event being generated, as
explained in R2.4.14. Events are generated and added to event histories under
Volume 1
R2.4.15.
In addition, performing the functions described in R2.4.21, R3.4.4 and R7.5.7 Core Services
will always result in an event being generated, regardless of the value of the & Plug-in Modules
Generate Event Flag.
Function reference: F14.5.91 Version 1.1
43
1
System services
R2.4.14 An event must always be generated by the MCRS when the function described
by R2.4.13 is performed.
This requirement is an exception to R2.4.13 as the generation of an event for
this function must not be able to be suppressed.
The purpose of this requirement is to ensure that a history is kept by the MCRS of
all changes to the settings for whether or not particular functions are captured
as events and the authorised users that made those changes.
R2.4.15 Whenever a function described in MoReq2010® is performed for any entity in

the MCRS, and subject to the Generate Event Flag described under R2.4.13,
the MCRS must automatically create a new event that describes the func‑
tion that was performed and include it in the event history of all participating
entities.
The MCRS must maintain an event history as part of the metadata of every entity
in the MCRS.
R2.4.16 For each event (E14.2.8) created under R2.4.15 by a function being
performed, the MCRS must include the following metadata:
• Created Timestamp (M14.4.9),
• Event Occurred Timestamp (M14.4.27), and
• Event Function Identifier (M14.4.26).
Where the function is performed by a user and not the MCRS itself, the
event will also include:
• Performed By User Identifier (M14.4.83),
and may include, under R2.4.18:
• Event Comment (M14.4.25).
Where the event has been duplicated, under R6.5.16, it will also include:
• Duplicate Identifier (M14.4.23).
Where the event modifies the metadata of the entity, under R2.4.17, it will
include:
•
MoReq2010 • Metadata Change Entry (D14.3.3).
Events must also have one or more of the following additional system meta‑
data elements depending on the function that they represent, as specified
Modular Requirements by the description of each function in 14.5 Function definitions:
for Records Systems
• Applied Template Identifier (M14.4.2),
• Deleted Event Function Definition Identifier (M14.4.14),
• Deleted Metadata Function Definition Identifier (M14.4.15),
• Export Commencing Timestamp (M14.4.28),
• Export Completed Timestamp (M14.4.29),
• Export Identifier (M14.4.30),
• Exported In Full Flag (M14.4.31),
Volume 1 • Granted Role Identifier (M14.4.35),
Core Services • Historical Date/Time (M14.4.40),
& Plug-in Modules • Overdue Disposal Action Code (M14.4.58),
• Overdue Disposal Action Due Date (M14.4.59),
Version 1.1 • Overdue Disposal Confirmation Due Date (M14.4.60),
44
1
System services
• Participating Aggregation Identifier (M14.4.64),
• Participating Class Identifier (M14.4.65),
• Participating Component Identifier (M14.4.66),
• Participating Disposal Hold Identifier (M14.4.67),
• Participating Disposal Schedule Identifier (M14.4.68),
• Participating Duplicate Identifier (M14.4.69),
• Participating Entity Type Identifier (M14.4.70),
• Participating Event Identifier (M14.4.71),
• Participating Function Definition Identifier (M14.4.72),
• Participating Group Identifier (M14.4.73),
• Participating Metadata Element Definition Identifier (M14.4.74),
• Participating New Parent Identifier (M14.4.75),
• Participating Previous Parent Identifier (M14.4.76),
• Participating Record Identifier (M14.4.77),
• Participating Role Identifier (M14.4.78),
• Participating Service Identifier (M14.4.79),
• Participating Template Identifier (M14.4.80),
• Participating User Identifier (M14.4.81),
• Participating User Or Group Identifier (M14.4.82),
• Rescinded Role Identifier (M14.4.87),
• Search Query (M14.4.98), and
• Total Entities (M14.4.105).
The Event Function Identifier must be a reference to the function definition of
the function which was performed by the user, referenced by the Performed By
User Identifier. The Event Occurred Timestamp reflects when the function was
performed: this will be set by the MCRS and will usually be the same as the
Created Timestamp, unless the event has been imported from another MCRS.
The additional metadata elements to be added to an event depend on the func-
•
tion that was performed and are listed as part of the function definition (see MoReq2010
R2.4.12) and are provided in full in 14.5 Function definitions. Depending on the
function that was performed, the event may require additional metadata. For
example, if the function was to export the entity, then the MCRS must include Modular Requirements
the Export Identifier and the Exported In Full Flag in the event, under R11.4.8. for Records Systems
Any entity referenced by an identifier that takes the form ‘Participating …
Identifier’ is a participating entity in the event. All functions have at least one
participating entity and some functions have several participating entities. The
event must appear in the event history of all participating entities.
R2.4.17 Whenever the metadata of an entity is modified as a result of performing

a function and an event is generated for the function, under R2.4.15, the
MCRS must include a metadata change entry (D14.3.3) in the event for each
metadata value that is modified, with the following metadata:
Volume 1
• Metadata Element Definition Identifier (M14.4.55),
• Previous Value (M14.4.85), and Core Services
• New Value (M14.4.57). & Plug-in Modules
A metadata change entry is a data structure defined in D14.3.3 and captures
the before and after states of a metadata element belonging to the entity. The Version 1.1
45
1
System services
Metadata Element Definition Identifier contains a reference to the metadata
element that was modified. The Previous Value contains the value of the meta-
data element before the function was performed. The New Value contains the
value of the metadata element after the function was performed. There will be
no Previous Value if the value is newly applied to the entity and no New Value if
the previous value is deleted.
For example, if a user changes the title of an entity, the corresponding event
would have a metadata change entry that referenced the Title metadata element
definition (M14.4.104), its old value before the function was performed, and the
new value it was given by the user.
Every metadata element that is changed by a function will result in a metadata
change entry included in the event. If multiple metadata elements are changed
simultaneously by one function then the event will include a metadata change
entry for every metadata element that is changed.
R2.4.18 Whenever the MCRS performs a function requested by a user, and not by
itself, which changes the metadata of an entity, the MCRS must allow the
user to provide a comment explaining why the function was performed. If
provided, the comment must be included in the event as the Event Comment,
under R2.4.16.
The MCRS is not required to make provision for the user to enter an Event
Comment for functions which do not change the metadata of the entity, such as
browsing the entity and inspecting its metadata. Note that changing the meta-
data of an entity will result in the generation of one or more metadata change
entries, under R2.4.17.
Providing a comment is optional in most cases. However, some functions
require a comment by the user (e.g. R2.4.21, R2.4.26, R8.4.17, R8.4.18, R7.5.7
and R11.4.10).
While the MCRS is not required to provide an Event Comment for functions it
performs itself, under R2.4.16, the MCRS may be implemented in such a way
that it automatically generates an Event Comment while performing such func-
tions and includes it in the event.
• R2.4.19 The MCRS must allow an authorised user to browse the event history of an
MoReq2010
entity in order of Event Occurred Timestamp and inspect the metadata of
each event.
Modular Requirements The terms ‘browse’ and ‘inspect’ are defined in 13. Glossary. Event histories
for Records Systems are most usually browsed from the most recent events to the earliest events in
descending order of Event Occurred Timestamp. The MCRS may also provide
other ways of browsing the event history.
Function references: F14.5.14, F14.5.32, F14.5.45, F14.5.65, F14.5.79,
F14.5.85, F14.5.89, F14.5.103, F14.5.111, F14.5.133, F14.5.151, F14.5.160,
F14.5.173, F14.5.189
R2.4.20 For each function definition, under R2.4.11, the MCRS must allow an author‑
ised user to specify whether or not an event generated by the MCRS, when
Volume 1 the function was performed, should be retained when the entity it belongs
to is destroyed.
Core Services The value is stored in the Retain On Destruction Flag (see R2.4.12).
& Plug-in Modules Events for functions where the Retain On Destruction Flag is not set will be
pruned from an entity’s event history when the entity is destroyed. They will not
Version 1.1 be part of the event history of the residual entity.
46
1
System services
Automatic pruning of events for residual entities may be done for a number of
reasons, including but not limited to:
• ensuring destruction — to remove events containing metadata, especially
as a result of the information stored in metadata change entries under
R2.4.17, which may make it possible to partially or fully reconstitute the
entity;
• privacy — to remove events that may potentially store personal informa-
tion; and
• storage — to reduce the footprint of a residual entity.
Note that it must not be possible to make a residual entity active once it has
been destroyed.
Events are only automatically pruned on the destruction of the participating
entity against which the function for the event was originally run (see the
rationale to R2.4.21). This is only applicable for events where there is more than
one participating entity, see 14.5 Function definitions.
R2.4.21 The MCRS must allow an authorised user to delete an event from the event
history of a residual entity, provided the user gives a reason for the deletion
and an event is generated.
This requirement describes a special circumstance where it becomes neces-
sary to remove metadata or events from individual entities where, for example,
this has been ordered by a court of law. It should not be necessary to exercise
this requirement as part of routine records management processes.
This requirement may only be applied to a residual entity which has already
been destroyed and is in addition to the automatic pruning of metadata and
events which occurs on destruction.
Note that a new event must always be generated for this function, superseding
requirement R2.4.13. The authorised user must give a reason for deleting the
deleted event which is stored as the Event Comment in the new event.
The new event must also contain a Deleted Event Function Definition Identifier
(see M14.4.14) which indicates the function identifier of the deleted event. This
gives an indication of which type of event was deleted without retaining any of •
MoReq2010
the metadata of the deleted event.
Where the event to be deleted has more than one participating entity, the
event must be deleted from the entity against which the function was originally Modular Requirements
performed. This is also the participating entity for the event notification of the for Records Systems
deletion. For example, to delete the event where a record is moved from one
aggregation to another, it must be deleted from the record’s new parent aggre-
gation, because this is the entity against which the function was performed and
the event generated (see F14.4.3 Aggregation — New record).
See also R7.5.7.
Function references: F14.5.7, F14.5.26, F14.5.39, F14.5.50, F14.5.59, F14.5.73,
F14.5.97, F14.5.122, F14.5.145, F14.5.167, F14.5.181
R2.4.22 When an authorised user is browsing a set of entities, the MCRS must, Volume 1
by default, limit the set to active entities only, unless the user specifically
chooses to browse both active and residual entities. Core Services
The term ‘browse’ is defined in 13. Glossary. & Plug-in Modules
By default, entities that have been destroyed will not be browsed (see also
R10.4.17 and R11.4.2). Version 1.1
47
1
System services
R2.4.23 The MCRS must always use the System Identifiers that accompany the
MoReq2010® specification, where provided.
MoReq2010® provides System Identifiers that have been previously generated
for:
• services and modules (see 2.1 Service information);
• entity types (see R2.4.10 and 14.2 Entity types);
• function definitions (see R2.4.12 and 14.5 Function definitions); and
• system metadata element definitions (see R7.5.1 and 14.4 System meta‑
data element definitions).
The System Identifiers provided with MoReq2010® must be used to ensure inter-
operability with other records systems.
R2.4.24 The MCRS must generate System Identifiers for new entities as univer‑
sally unique identifiers (UUID) and must not allow these identifiers to be
modified.
MoReq2010® does not specify which algorithm the MCRS should use to generate
System Identifiers. The approaches listed in RFC4122 are recommended and
can support ‘high allocation rates of up to 10 million per second per machine’
(RFC4122:2005, 2.).
R2.4.25 The MCRS must automatically set the Created Timestamp and, where it
exists, the Originated Date/Time for all new entities on creation.
By default, both the Created Timestamp and the Originated Date/Time will
reflect the date and time of creation of the entity.
F14.5.95, F14.5.121, F14.5.143, F14.5.165, F14.5.179
R2.4.26 Where it exists, the MCRS must allow an authorised user to change the
Originated Date/Time for an active entity to an earlier date and time than the
Created Timestamp, provided a the user gives a reason for the change.
By default the Originated Date/Time is set to the same date and time as the
MoReq2010
• Created Timestamp, under R2.4.25. An authorised user can subsequently
change this value for an active entity to reflect an earlier date and time, but
never a later date and time. Whenever a user changes the Originated Date/Time
Modular Requirements to an earlier date and time, a comment must be provided which is stored in the
for Records Systems event generated for the function.
Note that the Originated Date/Time is a possible retention trigger, under R8.4.4,
and resetting it for an aggregation or record may affect the calculation of one or
more retention start dates.
F14.5.106, F14.5.136, F14.5.154, F14.5.176, F14.5.192
R2.4.27 The MCRS must generate timestamps that are compatible with W3C XML
dateTimeStamp formats and must always include time zone information in
Volume 1 timestamps.
Core Services The required format is defined in W3C XML Schema Definition Language (XSD)
1.1 Part 2: Datatypes. The dateTimeStamp format is a variant of the XML date/
& Plug-in Modules time format which is in turn a subset of ISO 8601 that does not allow truncated
or reduced formats (ISO 8601:2004: Data elements and interchange formats —
Version 1.1 Information exchange — Representation of dates and times).
48
1
System services
Time zone information is a necessary inclusion in all timestamps to determine
when events occur relative to other events and to ensure interoperability with
records systems in different time zones.
R2.4.28 The MCRS must store all textual metadata elements in Unicode accompa‑
nied by a language identifier that is compliant with RFC5646 and the IANA
Language Subtag Registry.
A metadata element is considered textual if the Is Textual Flag is set in the
corresponding metadata element definition (see R7.5.1).
MoReq2010® does not specify how an MCRS will identify the language used for
textual metadata. Options may include:
• in monolingual contexts, it may be derived from the Default Language
Identifier for the service or bundle of services (see R2.4.2);
• it may be specified in operational procedures or by the nature of the
metadata;
• it may be derived from a user’s client operating system or session settings;
or
• it may be supplied as additional information by the user.
The use of Unicode ensures that all character sets can be represented and is
necessary for interoperability. The latest version of the Unicode Standard is 6.0.
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
49
1
3
User and group service

Service name User and group service
Service version 1.0
Implements Service cd532472‑85b0‑4c1c‑82b4‑5c8370b7d0e6
Identifier (see M14.4.42)
00 4 .59
q
8
3.2 kEy CoNCEPtS i;.444 Q4

•
1 81
3.2.1 MoReq2010 approach to user and group management
®
�,d.2 .a. Jl.1.
,,
Good management of users and groups is essential to the successful oper‑ 4 J7 bd22
ation of a records system. All business systems share this same need. As ' ., o l '
a consequence, there are many system tools available that manage users <
o¡
'
4 6 134
and groups; this functionality is often built directly into computer operating ,,
J O 38 b 04 • 24
systems. There are also well‑established standards for the management of 84 76
users and groups and related directory services such as X.500 and, for user <
•
"
4 4
• •
7 ea 2
authentication, OpenID. <
For this reason, MoReq2010® does not mandate the protocols that MCRS
solutions should use for user authentication and user and group manage‑
ment. The user and group service in MoReq2010® is a set of requirements
that act as a wrapper allowing the use of either an external corporate direc‑
tory service or a custom directory service built into the MCRS. Other than
the basic concepts of a user and a group, MoReq2010® is not prescriptive
about how users and groups are managed.
3.2.2 Requirements for records management

Traditional directory services do not, by themselves, provide all the function‑
ality required for the discipline of records management. The data held within •
a directory service is often transient in nature. There is usually little or no MoReq2010
capability to trace past users of a system. The system identifiers for users and
groups may not be universal or they may be subject to change, for example
if an external directory service is duplicated or rebuilt. Importantly, the data Modular Requirements
in a proprietary directory service may not be in a common format that can be for Records Systems
easily understood by another records system when records are transferred.
These factors may make it difficult from an historical perspective to determine
which users performed particular actions and what groups they belonged to.
MoReq2010®, therefore, requires that the MCRS keeps additional and stable
data about users and groups, including historical information. This includes
creating entities to represent all users and groups within the MCRS, using
universal MoReq2010® system identifiers, tracking changes to the meta‑
data of entities, and retaining information by destroying users and groups
to leave residual entities rather than deleting them entirely from the system
when they are no longer active.
Volume 1
If the MCRS uses an external directory for user and group management, it Core Services
will need to synchronise, or otherwise integrate, with that directory to ensure & Plug-in Modules
that this information is captured, updated regularly and retained following
its removal from the external system. MoReq2010® does not specify how
this should be done. Version 1.1
51
1
User and group

service 3.2.3 How users and groups work
Figure 3a shows the many‑to‑many relationship between users and groups
in an MCRS. Each user may belong to many groups and many users may
belong to the same group.
Users Groups M0Req2010'
¡a,. belongto . .
� /AIM� .. g¡
7 1
� / I M • i l
" ' l &i � � i B I

él · z�
B � l • i B I
Figure 3a — In an MCRS, users and groups have a many‑to‑many relationship
This flattened structure represents the extent of the information that

MoReq2010® requires about the relationship between users and groups.
• There is no requirement to track the relationships between groups even
MoReq2010 though, for example, several of the groups shown in Figure 3a may, in prac‑
tice, be subgroups of another group.
for Records Systems 3.2.4 Destroying users and groups
The user and group service must adopt the approach common throughout
the MoReq2010® specification of destroying entities to leave a residual
entity. This is so that a record is kept of these entities even when they are no
longer functioning. MoReq2010® requires that user and group entities must
not be deleted from the MCRS once they have been used but must instead
be retained to provide context to the records managed by the system (see
the previous discussion in 2.2.10 life cycle of an entity).
A residual entity does not exercise the same functionality as an active entity.
Volume 1 In the case of a user entity that has been destroyed, a residual user must
not be allowed to access the MCRS. In the case of residual group entities,
Core Services
any roles they had been granted no longer apply to the members of that
& Plug-in Modules group. Therefore, an active user that is a member of the residual group, will
no longer benefit by inheriting any roles allocated to that group (for further
Version 1.1 details, see 3. Model role service).
52
• 1
User and group
3.4 FUNCtIoNAl REqUIREMENtS service
R3.4.1 The MCRS must only be accessed by users that have been authenticated
and for whom there exists an active user entity (E14.2.16) with at least the
following system metadata:
• Originated Date/Time (M14.4.61),
• First Used Timestamp (M14.4.32),
• Group Identifier (M14.4.36),
• Title (M14.4.104),
• Destroyed Timestamp (M14.4.17).
Each user entity also has:
• an event history (see 2. System services),
and may have:
Authentication describes the process of establishing the identity of the user so
that the MCRS can allow an appropriate level of access to perform functions and
can associate every function performed with a particular user entity. MoReq2010®
does not define how authentication should occur. A simple form of authentica-
tion requires users to provide a name and password; this may be suitable for
many records systems but other, more complex, methods include two-factor
authentications where more than one item of identification is required.
operation and may only be added to a user entity at export.
data service, the mechanism by which contextual metadata is added to user •
entities may vary. MoReq2010
R3.4.2 The MCRS must support a process for creating new user entities in the Modular Requirements
MCRS with the metadata and other properties listed under R3.4.1. for Records Systems
MoReq2010® does not define how this process should operate and, depending
on the specific implementation, new user entities may not be created by MCRS
users. Organisations must assess whether the supplier’s process meets their
security and operational needs.
R3.4.3 The MCRS must support a process for updating the Title and Description of
an active user entity, and any contextual metadata, to reflect changes to the
user’s details. Volume 1
MoReq2010 does not define how this mechanism should be implemented; it
®
may be performed externally to the MCRS and synchronised to it later. However,

Core Services
changes to user metadata must generate an event in the event history of the & Plug-in Modules
user, under R2.4.15, subject to R2.4.13.
53
1
User and group

service R3.4.4 The MCRS must support a process for adding and removing active users
to and from active groups and whenever this occurs, an event must be
generated.
MoReq2010® does not define how this mechanism should be implemented; it
may be performed externally to the MCRS and synchronised to it later. Only
active users may change their group membership; they may only be removed
from, or added to, active groups. In this way, a residual user will retain their
group membership as it was at destruction and a residual group will retain its
user membership as it was when the group was destroyed.
requirement R2.4.13. Events are always generated so as to provide accurate
data for reporting under R3.4.7 and R3.4.13.
Function references: F14.5.94, F14.5.107
R3.4.5 The MCRS must support a process for deleting a user that has never used
the MCRS to perform any function.
may be performed externally to the MCRS and synchronised to it later. When a
user first uses the MCRS and performs a function, the MCRS must set the First
Used Timestamp.
R3.4.6 The MCRS must support a process for destroying a user that has used the
MCRS to perform functions.
may be performed externally to the MCRS and synchronised to it later. Once a
user has used the MCRS, the corresponding user entity may not be deleted, it
may only be destroyed. Destroying a user will set the Destroyed Timestamp and
will leave a residual user entity.
R3.4.7 The MCRS must be able to generate a report for an authorised user listing
• the active groups to which a nominated user entity belonged at a specified
MoReq2010 historical date and time.
The report must not include groups that the user requesting the report is not
Modular Requirements authorised to inspect.
for Records Systems The report must indicate if the date and time provided were before the user
entity was created or after it was destroyed.
R3.4.8 The MCRS must be able to maintain groups (E14.2.10) with at least the
following system metadata:
Volume 1 • Originated Date/Time (M14.4.61),
Core Services • First Used Timestamp (M14.4.32),
& Plug-in Modules • Title (M14.4.104),

Version 1.1 • Destroyed Timestamp (M14.4.17).
54
1
User and group
Each group also has: service
• users that belong to the group,
• an event history (see 2. System Services),
and may have:
operation and may only be added to a group entity at export.
Depending on the approach taken by the MCRS in implementing 7. Model
Metadata Service, the mechanism by which contextual metadata is added to
group entities may vary.
R3.4.9 The MCRS must support a process for creating new groups in the MCRS
with the metadata and other properties listed under R3.4.8.
MoReq2010® does not define how this process should operate and, depending
on the specific implementation, new group entities may not be created by MCRS
users.
R3.4.10 The MCRS must support a process for updating the Title and Description
of an active group, and any contextual metadata, to reflect changes to the
group’s details.
MoReq2010® does not define how this mechanism should be implemented;
it may be performed externally to the MCRS and be synchronised to it later.
However, changes to group metadata must generate an event in the event
history of the group, under R2.4.15, subject to R2.4.13.
•
MoReq2010
R3.4.11 The MCRS must support a process for deleting a group that has never had
users added to it.
for Records Systems
may be performed externally to the MCRS and synchronised to it later. Users
are added to groups under R3.4.4.
R3.4.12 The MCRS must support a process for destroying a group that has had users
as members.
MoReq2010® does not define how this mechanism should be implemented;
it may be performed externally to the MCRS and synchronised to it later. Any
group to which users belong, or have previously belonged, may not be deleted, it Volume 1
may only be destroyed. Destroying a group will leave a residual group entity. Core Services
Under the model role service, a user may not inherit roles granted to a residual & Plug-in Modules
group to which that user belongs even if the user is active (see R4.5.10).
55
1
User and group

service R3.4.13 The MCRS must be able to generate a report for an authorised user listing
the users that were active and belonged to a nominated group at a specified
historical date and time.
The report must not include user entities that the user requesting the report is
not authorised to inspect. The users must have been active on the date and time
specified, but do not need to be active users when the report is generated.
The report must indicate if the date and time provided were before the group
R3.4.14 Subject to R2.4.22, the MCRS must allow an authorised user to browse and
inspect users and groups, in at least the following ways:
• browse across the users in the user and group service and inspect
their metadata;
• browse across the groups in the user and group service and inspect
their metadata;
• browse from a user to the groups to which that user belongs and
inspect their metadata; and
• browse from a group to the users that belong to that group and inspect
their metadata.
The terms ‘browse’ and ‘inspect’ are defined in 13. Glossary.
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
56
1
4
Model role service

Service name Model role service
Service version 1.0
Implements Service For an MCRS that implements the MoReq2010®

Identifier (see M14.4.42) model role service use: 00 4 .59
2f6d05c6‑51e6‑4a32‑a7fc‑c0a6883eb85b
q
8
For an MCRS that implements its own native

i;.444 Q4
•
permissions model use: 1 81
d945dcd9‑dc2d‑491d‑965a‑11ce936d044b �,d.2 .a. Jl.1.

,,
4 J7 bd22
' ., o
4.2 CoMPlyING wItH tHE MoDEl RolE SERVICE
l '
'
<
o¡ 4 6 134
,,
4.2.1 lack of an industry standard for roles and permissions
J O 38 b 04 • 24
84 76
• •
This module of MoReq2010® contains a definition of a model role service
< "
• 4 4 7 ea 2
with functional requirements covering how users are authorised to perform <
functions in the MCRS.

At the time of publication of MoReq2010®, there is no industry‑wide standard
for applying a permissions model to entities in an information system. Basic
permissions models based on create, read, update and delete (CRUD) are
too simple for direct application to records systems. For example, CRUD
makes no distinction between deletion and destruction and no allowance for
retaining the residual entities, necessary in records systems.
Because there is no industry standard, suppliers have, understandably,
developed their own approaches to controlling user access to records
systems. These proprietary methods, while often highly effective, are almost
always application‑specific and do not lend themselves to interoperability •
between records systems, as one supplier’s permissions model may not MoReq2010
readily map to another’s.
4.2.2 A model role service
for Records Systems
The MoReq2010® model role service is a simple standardised model that
addresses the specific requirements of records systems within the context
of the specification. Care has been taken to ensure that the model role
service outlined here is both neutral and based around common concepts to
be found across many modern information systems, such as access control
lists and role definitions.
Nevertheless, the MoReq2010® model role service can only represent one
possible approach to access control and it is recognised that it may vary
sufficiently from the approach taken by some pre‑existing records systems
to render them unable to be tested for compliance against MoReq2010® Volume 1
without major redevelopment to their own embedded access control
Core Services
methods.
& Plug-in Modules
This introduces a dichotomy: while new records systems have the oppor‑
tunity to adopt the model role service, it may not prove cost effective for
established products in the market. Version 1.1
57
1
Model role
service 4.2.3 Approaches to testing and certification against the model role service
For the reasons given previously, the DLM Forum Foundation allows two
possible approaches to the testing and certification of a records system for
compliance with the MoReq2010® model role service.
EItHER
A. The records system implements the MoReq2010® model role service
in full and is tested and certified against the requirements in this
module.
oR
B. The records system implements its own native permissions model,
in which case the application must satisfy the following criteria.
• It must demonstrate that its native permissions model is equiva‑
lent in flexibility and functionality to the MoReq2010® model role
service.
• It must support interoperability by being able, on export, to convert
its native permissions into the XML format used by the model role
service, so that users and groups retain equivalent levels of access
to entities and the same authority to perform functions when the
data is subsequently transferred to another MCRS.
4.2.4 How to meet the alternative (type B) requirements

To show that the MCRS’s native permissions model is equivalent in flexibility
and functionality to the MoReq2010® model role service, the records system
must be able to demonstrate all of the following.
• That a user cannot access any entity in the MCRS until that user has
been granted the authority to access the entity, either individually or as
a member of a group.
• That there exists multiple, user‑configurable levels of access to enti‑
ties, including discretionary ability to set the permissions of users so
that they can:
• discover some entities and not others, and
• • perform some functions and not others.
MoReq2010
• That the authority to access entities and perform functions may be set
at the level of an individual entity or once across a whole collection of
Modular Requirements entities, such as an aggregation of records.
for Records Systems • That the authority to access entities and perform functions may be
set differently in different parts of the MCRS: for example, it must be
possible to set a user’s authority to perform functions to some classes
at a different level from that same user’s authority over other classes
within the same classification service.
• That when a new entity is created, it is given an appropriate set of
default permissions: for example, a new record captured into an aggre‑
gation should automatically receive a similar level of permissions as
the other records in the aggregation.
Volume 1 • There exist some types of roles or permissions that may not be blocked
by the owners of particular entities, so that users with those permis‑
Core Services sions can properly administer all, or part, of an MCRS.
& Plug-in Modules
When converting metadata for export from the records system’s native
permissions model to the MoReq2010® model role service metadata format,
Version 1.1 the following must be observed.
58
1
Model role
• No user may be granted authority to access more entities than the service
user was able to in the original environment.
• No user may be granted authority to perform functions to entities
that that user was unable perform to the same entities in the original
environment.
• Authority granted through group membership must not be converted
into multiple instances of authority granted to individual users.
• The records system must utilise the inheritance features of the
MoReq2010® model role service where possible and avoid adding
repetitive sets of access control entries to the access control list of
every child entity it exports if it is possible to attribute a single set of
access control entries to the child’s parent entity instead.
• The supplier must describe the conversion algorithm used by the
records system and provide information and examples of how the
exported data for roles and access control lists has been made to
imitate the model role service as accurately as possible.
• The supplier must make its permissions mapping schema available
for inclusion in the full test report of its product.
Further advice and guidance to suppliers can be requested from the MoReq
Governance Board through the DLM Forum Foundation secretariat.
The remainder of this module describes the concepts and requirements of
the MoReq2010® model role service.
4.3 kEy CoNCEPtS

4.3.1 Defining roles
Before performing any function on any entity, the MCRS must always conduct
a preliminary check to determine whether the user requesting the function
has the authority to carry it out. The authority to perform functions is given
to users when they are granted roles.
A properly authenticated user (see R3.4.1) that is accessing the MCRS with MoReq2010
•
the authority to perform a function is defined throughout this specification
as an ‘authorised user’.
Because the same role may be granted for any entity in the MCRS, or utilised Modular Requirements
across several records systems, all role definitions are managed by a role for Records Systems
service. A role definition represents a set of function definitions, as shown
in Figure 4a.
Role definitions and function definitions have a many‑to‑many relationship:
any role may have many function definitions associated with it and the same
function definition may be associated with more than one role.
The term ‘role’ indicates that the set of functions it defines are selected
logically so as to collectively describe the authority required by a particular
member of staff or a particular position within an organisation, for example Volume 1
a ‘Local Records Officer’.
Core Services
Constructing roles in this way, based on coherent sets of functionality is
integral to managing a records system. There are many functions defined & Plug-in Modules
by the MoReq2010® specification and it would be impractical to assign them
to users and groups individually. Version 1.1
59
1
Model role
service
MoReq2010°
'
Role 1
Role2 Role 3
Function Function Function
Function Function
Function Function
Role4
Figure 4a — Functions are associated with roles (all functions should be included in at
least one role)
4.3.2 Granting roles

A role may be granted to either a user or to a group in relation to any entity
in the MCRS, including a service. When a role is granted, an access control
entry nominating the user or group and listing the roles to be granted is
created and added to the entity’s access control list.
Granting a role to a user in relation to an entity allows that user to perform
any of the functions listed in the role definition applicable to that entity.
Granting a role to a group in relation to an entity has the effect of granting
the role to every user that is a member of that group (see 3. User and
• group service). New users joining the group will automatically inherit the
MoReq2010 role, while users that leave the group automatically lose their access to
that role, without the role having to be granted or rescinded individually
for each user.
for Records Systems Granting roles to groups rather than to individual users is recommended
good practice as it makes it easy to manage users’ access to entities
when they join or leave the organisation, or change jobs, without having to
update access control lists for entities in the MCRS. Group management
is invariably simpler and less error prone that the micromanagement of
continually granting and rescinding roles to individual users.
Figure 4b shows how a user or group is granted one or more roles in rela‑
tion to an entity by adding a new access control entry to the access control
list for that entity. All entities in the MCRS, as well as services, have an
access control list.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
60
1
Model role
service
MoReq2010'
Entity contains
r::c=�.
Access
Conlro1
llst
Access Control Entry
Role 2
User or group is p-anted
Figure 4b — An access control list is made up of access control entries that link a user or
group to a role
4.3.3 Inheriting roles

In addition to the access control entries in its own access control list, an
entity may also inherit the roles granted to users and groups from other
entities. MoReq2010® indicates, in specific functional requirements, where
such inheritance applies. As a general rule, throughout the specification,
if a parent/child relationship exists between entities then the child entity
will inherit its parent’s access control list. For example, a child aggregation
inherits from its parent aggregation, as does a record. There are also some
circumstances under which entities can inherit from multiple sources, as
described in 4.3.5 Multiple inheritance.
Inheritance is a very important mechanism for managing large records
systems where granting roles against single entities is impractical. •
MoReq2010
The usual pattern of inheritance of access control entries can also be broken
for some roles if required. MoReq2010® makes provision within each access
control list for an Include Inherited Roles Flag that specifies whether roles Modular Requirements
assigned to parent entities are inherited by the child entity or not. for Records Systems
If the Include Inherited Roles Flag is switched off in an entity’s access control
list, then only administrative roles will be automatically inherited from the
parent entity.
4.3.4 Administrative roles

There are two different types of role in MoReq2010®:
• administrative roles, and
• non‑administrative roles. Volume 1
The type of role is specified as part of the role definition.
Core Services
An administrative role, once granted across a service as a whole, or for any
& Plug-in Modules
parent entity, always applies to all the entities that inherit from that service
or entity. In this way, administrative roles override the setting of the Include
Inherited Roles Flag for child entities. Version 1.1
61
1
Model role
service By comparison, non‑administrative roles will only be inherited by a child
entity if the child’s access control list is set to include inherited roles.
An example of this is shown in Figure 4c. In this example, Role 2 is an
administrative role, while Role 4 is set as a non‑administrative role. The
entity Child 1 is set to include inherited roles and duly inherits both Role 2
and Role 4. However, the entity Child 2 does not include inherited roles and
will, therefore, only inherit the administrative Role 2.
MoReq2010
1 RoleZ 1
�dmin!strative Role,.�
Parent
Entity Role4
IS Admlnistrahve Role= NO
Chlld 1 fnherits
Chlld 2 lnherirs only
oll roles
odmlnlsttotlve roles
Role2
R�
Child 1 Child 2
Access Access
Control Control
Llst Llst
1,,..-
lnclude lnhedtcd Roles: VES j lnclude lnhedted Roles • NO j
Figure 4c — Administrative roles override the operation of the Include Inherited Roles Flag
and are always inherited from parent entities
•
MoReq2010
4.3.5 Multiple inheritance

for Records Systems As mentioned previously, there are some parts of the MoReq1010® specifi‑
cation where an entity may inherit roles from more than one entity.
For example, aggregations and records maintained by the record service
will inherit access control settings from both their parent aggregation and
classification. This is shown in Figure 4d. Where this occurs, the entity will
inherit the roles from both its parent and class. Of course, if the Inherit All
Roles Flag is turned off, the child entity will inherit only the administrative
roles from these entities.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
62
1
Model role
service
MoReq2010
Service or
aggregation
---.:.
Class Parent
Access Access
Control Control
List Ust
Aggregation Child
"'""'� Access
Control
list
Figure 4d — Sometimes access control lists may be inherited from more than one
source
This arrangement allows different organisations to configure access to

records at both classification and aggregation levels.
4.3.6 Preconfigured roles

It is common practice for records systems to be installed with a default
set of roles that have been preconfigured by the supplier for the conven‑
•
ience of the consumer organisation and to allow immediate use of the MoReq2010
system. Where this occurs, some of these preconfigured roles may be
able to be modified and even deleted (if they have not been used) or
destroyed by an authorised user, while other preconfigured roles may Modular Requirements
be fixed by the supplier and rendered unalterable within that particular for Records Systems
MCRS solution.
MoReq2010® permits suppliers to provide one or more preconfigured roles
within their products, including fixed roles, provided they are documented as
part of the test verification report and the MCRS also includes functionality
for users to create, modify and destroy their own custom role definitions in
accordance with the requirements following and the records management
policies of the consumer organisation.
Note that while some preconfigured roles may be fixed by a supplier within
its own MCRS solution, such roles will not necessarily continue to be fixed
Volume 1
when entities and their associated roles are transferred to another MCRS
solution. Core Services
& Plug-in Modules
Version 1.1
63
1
Model role
service 4.5 FUNCtIoNAl REqUIREMENtS
R4.5.1 The MCRS must allow an authorised user to create roles (E14.2.13) with the
following metadata:
• Is Administrative Role Flag (M14.4.44),
• Title (M14.4.104),
• Scope Notes (M14.4.97),
• Function Definition Identifier (M14.4.33), and
Each role also has:
• an access control list for the role,
and may have:
data service, the mechanism by which contextual metadata is added to user
entities may vary.
Note that fixed roles are provided as part of an MCRS solution and are not
created by users; however, they have the same metadata as created roles (see
4.3.6 Preconfigured roles).
•
MoReq2010
R4.5.2 The MCRS must allow an authorised user to modify the Title, Description
and Scope Notes of an active role, and any of its contextual metadata.
Modular Requirements Note that this function does not apply to fixed roles provided in an MCRS solu-
for Records Systems tion (see 4.3.6 Preconfigured roles).
R4.5.3 The MCRS must allow an authorised user to make a role an administrative
role or a non‑administrative role, but only if the role has never been included
in any access control entries.
Once the role has been used, it cannot be changed from an administrative role
to a non-administrative role, or vice versa, as this may have unintended conse-
Volume 1 quences for entities where the role has been granted, and their descendants.
Core Services The value is stored in the Is Administrative Role Flag (see R4.5.1).
& Plug-in Modules Note that this function does not apply to fixed roles provided in an MCRS solu-
tion (see 4.3.6 Preconfigured roles).
Version 1.1 Function reference: F14.5.153
64
1
Model role
R4.5.4 The MCRS must allow function definitions to be added to, and removed from, service
active roles, ensuring that every function definition is at all times associated
with at least one active role.
Otherwise, there will be functions that can never be performed. Function defini-
tions can be added and removed while active roles are in use.
Function definitions cannot be added to, or removed from, residual roles.
Residual roles retain their references to the function definitions that belonged
to them at the moment they were destroyed.
Note that this function does not apply to fixed roles provided in an MCRS solution
where the function definitions are already assigned (see 4.3.6 Preconfigured
roles).
R4.5.5 The MCRS must allow an authorised user to delete a role that has never
been included in any access control entries, provided every function defini‑
tion is at all times associated with at least one active role.
When a role is first included in an access control entry, the MCRS must set the
First Used Timestamp.
Note that this function does not apply to fixed roles provided in an MCRS solu-
R4.5.6 The MCRS must allow an authorised user to destroy a role that has previ‑
ously been included in an access control entry, provided every function defi‑
nition is at all times associated with at least one active role.
Once a role has been used, it may no longer be deleted under R4.5.5, it may only
be destroyed. Destroying a role will leave a residual role. Residual roles must
never provide users of the MCRS with the authority to perform functions.
Note that this function does not apply to fixed roles provided in an MCRS solu-
R4.5.7 Subject to R2.4.22 and in addition to R2.4.11, the MCRS must allow an •
authorised user to browse and inspect roles and function definitions, in at MoReq2010
least the following ways:
• browse across the roles in the role service and inspect their metadata;
• browse across the function definitions in the role service and inspect
for Records Systems
their metadata;
• browse from a role to the function definitions included in that role and
inspect their metadata; and
• browse from a function definition to all the roles that include that func‑
tion definition and inspect their metadata.
R4.5.8 The MCRS must automatically create an access control list (D14.3.2) for Volume 1
each service or bundle of services under R2.4.1, and for each entity in the
MCRS where so specified, with the following metadata: Core Services
• Include Inherited Roles Flag (M14.4.43). & Plug-in Modules
Each access control list also has:
• access control entries for that entity. Version 1.1
65
1
Model role
service An access control list is a data structure defined in D14.3.2 that contains the
access control entities that determine which users and groups may access an
entity and using which roles. Each access control list is an integral part of the
entity to which it belongs and each entity has a single access control list.
Access control lists are applied to services in MoReq2010® as well as entities,
so that they may be inherited by all entities in the service. The access control
list for the record service is only inherited by root aggregations. This provides an
easy way to give a group, for example, managerial access to the classification
scheme within the classification service. If the organisation uses two different
classification services, then different groups may manage each service inde-
pendently, as each service will have its own access control list.
Access control lists are mandated for most types of entities by other require-
ments. For example, within the system services module by R2.4.2 (for services),
R2.4.10 (for entity types), and R2.4.12 (for function definitions); similarly within
the user and group service by R3.4.1 (for users) and R3.4.8 (for groups) etc.
Within the MoReq2010® core services, only access control lists, access control
entries, events and components do not have an access control list. Note that the
metadata of an access control list does not include a separate System Identifier
because the access control list belongs to, and is inseparable from, an entity.
The Include Inherited Roles Flag is, therefore, included in the metadata of every
entity with an access control list.
The value of the Include Inherited Roles Flag is not relevant to a service because
services do not inherit their access control lists.
R4.5.9 The MCRS must allow an authorised user to browse an entity’s access
control list and inspect the access control entries it contains.
This is a separate function to inspecting the general metadata of an entity.
F14.5.102, F14.5.110, F14.5.132, F14.5.150, F14.5.159, F14.5.172, F14.5.188
R4.5.10 The MCRS must allow an authorised user to modify an entity’s access control
list to change the value of the Include Inherited Roles Flag and to add, delete
and modify access control entries (D14.3.1) with the following metadata:
•
• User Or Group Identifier (M14.4.107), and
MoReq2010 • Role Identifier (M14.4.96).
An access control entry is a data structure defined in D14.3.1 that is contained
Modular Requirements by an access control list. Access control entries are always part of an access
for Records Systems control list.
Each entity can have only one access control entry for each identified user or
group. Each access control entry must have a User Or Group Identifier and at
least one Role Identifier. By adding an access control entry to an entity’s access
control list, the authorised user is granting the specified user or group the
authority to perform functions on the entity and its descendants. By removing an
access control entry from an entity’s access control list, the authorised user is
rescinding this authority from the user or group. By modifying an access control
entry, the authorised user can increase or decrease the number of roles and,
as a result, the amount of functionality the user or group can exercise over the
Volume 1 entity and its descendants.
Under R2.4.15, subject to R2.4.13, whenever an access control entry is added,
Core Services
modified or deleted an event will be generated in the entity’s event history.
& Plug-in Modules
Setting the Include Inherited Roles Flag will mean that the entity inherits
the full access control list of its parent entity or service in conjunction with
Version 1.1 any access control entries in its own access control list. Clearing the Include
66
1
Model role
Inherited Roles Flag will mean that the entity will only inherit access control service
entries for administrative roles. It is not possible to block the inheritance of
administrative roles.
F14.5.104, F14.5.112, F14.5.134, F14.5.152, F14.5.161, F14.5.174, F14.5.190
R4.5.11 The MCRS must authorise any active user to perform any function on any
entity provided the function to be performed is included in an active role
that has been granted to that user or to any active groups to which the user
belongs, specifically in relation to that entity, including those roles it inherits
from its service, parent entity or class (if any).
The specific rules of inheritance used by the model role service are as follows.
• Root aggregations inherit from the record service and their class.
• Child aggregations inherit from their parent aggregation and their class.
• Components use the access control list of the record to which they belong
(they do not have their own access control lists).
• Disposal holds inherit from the disposal holding service.
• Disposal schedules inherit from the disposal scheduling service.
• Entity types inherit from their respective service.
• Function definitions inherit from the service of their entity type.
• Groups inherit from the user and group service.
• Metadata element definitions inherit from the metadata service.
• Records inherit from their parent aggregation and their class.
• Roles inherit from the role service.
• Templates inherit from the metadata service.
• Users inherit from the user and group service.
The roles an entity inherits from its service, parent entity or class will be
influenced by the setting of the Include Inherited Roles Flag, under R4.5.10.
Administrative roles will always be inherited, while non-administrative roles
will only be inherited if the Include Inherited Roles Flag is set.
•
When a group entity is granted a role, all of the active users that are members of MoReq2010
that group will inherit that role while they remain group members and provided
the group is an active group. Users do not inherit the roles granted to residual
groups. Modular Requirements
for Records Systems
This requirement explains the meaning of the term ‘authorised user’. It does not
matter by which path a user becomes authorised or by how many alternative
paths a user may be authorised.
R4.5.12 The MCRS must allow an active user to discover which functions that user
is authorised to perform in relation to any entity.
The method by which the MCRS provides this feedback to the user will be
dependent on the type of interface implemented by the MCRS (see R2.4.6).
R4.5.13 The MCRS must allow an authorised user to generate a report showing Volume 1
which functions a nominated user is authorised to perform in relation to any
entity and how they have been determined.
Core Services
& Plug-in Modules
In addition to requiring authorisation to perform the function for the nominated
user entity, the user generating the report must also have authorisation to
inspect the entity and its access control list. Version 1.1
67
1
Model role
service The report should include:
• all the functions the user is authorised to perform on the entity;
• for each function, the active roles that include that function that the user
may exercise; and
• for each active role, the different paths by which that role has been granted
to the user, including by membership of an active group and roles inhe-
rited from the entity’s parent.
R4.5.14 The MCRS must allow an authorised user to generate a report listing the
function definitions that belonged to a nominated role at a specified histor‑
ical date and time.
The report must indicate if the date and time provided were before the role
R4.5.15 The MCRS must allow an authorised user to search for and find:
• entities for which an access control entry contains a nominated role;
and
• entities for which an access control entry contains a nominated user
or group.
Users may only search for, and find, entities for which they are authorised to
browse and inspect the access control list under R4.5.9. An authorised user may
either search entities in the MCRS, where a particular role has been assigned
or, alternatively, in the MCRS where a particular user or group is assigned a
role. Though explicitly specified here, these search options should be part of
general searching and reporting in 10. Searching and reporting service.
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
68
1
5
Classification service

Service name Classification service
Service version 1.0
Implements Service 10fea10e‑9c2f‑4760‑9095‑f4f9295f4b19

Identifier (see M14.4.42) 00 4 .59
q
8
5.2 kEy CoNCEPtS

i;.444 Q4
•
1 81
5.2.1 Classifying records

�,d.2 .a. Jl.1.
,,
4 J7 bd22
Every record in an MCRS must be classified. In MoReq2010 , this means

® ' ., o l '
that, from its creation, every record must always be associated with a class <
o¡
'
4 6 134
entity. Classes represent business functions, activities and transactions, ,,

J O 38 b 04 • 24
and associating a class with a record provides it with a definitive business 84 76
•
context that continues to link the record with the business process that •
< "
• 4 4 7 ea 2
generated it. <
In MoReq2010 , records are also placed within aggregations. Unlike classes,

®
aggregations may be created for many different purposes. For example,

an aggregation may represent a traditional ‘file’ or folder of records. Or, it
might represent an ‘online library’ of records made available for viewing on a
particular website. Records can be arranged in aggregations for operational
convenience, to allow them to be managed as a single entity or to allow
them to share the same set of access controls. Aggregations are described
in 6. Record service.
Where the records in an aggregation share the same business context,
they may inherit their class directly from their parent aggregation. So as
•
to facilitate this, MoReq2010® requires that aggregations, like records, are MoReq2010
classified. This approach to classification by inheritance is recommended
for managing large numbers of records as it avoids the need to individually
classify each record. However, it is only possible where the records contained Modular Requirements
within a particular aggregation are homogenous. for Records Systems
MoReq2010® also allows for heterogeneous aggregations that contain
records falling under different business classifications. These may be
aggregated together for operational reasons, for example because they all
relate to a particular person, place, project, event, case, client or incident
(see 6.2.1 Purposeful aggregation). In the example given previously, the
records in the online library may not have all been generated by the same
business process. In this case, each of the aggregated records would be
classified individually, overriding the default class they inherit from their
parent aggregation. Volume 1
Classifying a record gives it a business context, which in turn gives it a Core Services
default disposal schedule. Disposal schedules manage the retention and
eventual disposal of a record. Initially, this always comes from the record’s
& Plug-in Modules
class. More information on disposal schedules is given in 8. Disposal
scheduling service. Version 1.1
69
1
Classification
service 5.2.2 Inheriting classification
All root‑level aggregations (see 6.2.2 Root aggregations) must be classi‑
fied. By default, each child aggregation and each record will then inherit its
parent aggregation’s class. The inherited classification can be overridden by
directly assigning a class to an aggregation or record.
MoReq2010
O♦
Class Class Class Class Class Class
Figure 5a — Explanatory note: For illustrative purposes, each of the classes appearing in
diagrams in this module are depicted using a different shape and colour (all are labelled
as ‘Class’); in diagrams accompanying other modules, such as in Figure 1i, all entities of
the same type, such as classes, are given a uniform shape and colour
Figure 5b shows how a class, from the classification service, is used to

classify an aggregation. The same class is then automatically inherited by
all the descendants of the aggregation, including both child aggregations
and records.
MoReq2010•
Service
clossify
Clau
Agregatlon
•
inheritance
MoReq2010
Aa&•eaation ) L Aa&••a•tion J
for Records Systems
4
ooo oe
Record Record Record Record Record
Figure 5b — By default, all child aggregations and records will inherit their class from
their parent aggregation
Volume 1
Core Services
& Plug-in Modules
Version 1.1
70
1
Classification
Figure 5c shows how class inheritance can be overridden by classifying service
a child aggregation. In this example, the class inherited from the parent
aggregation is replaced by a class directly assigned to the child aggregation.
This replacement class will then be the class that is inherited by the child
aggregation’s descendants.
MoReq2010
Service
a.u
AgrepUon
overridden
Record Record R«ord

O tJ
Record Record
Figure 5c — Classifying a child aggregation overrides the default class it inherits from its
parent aggregation
MoReq2010'
Class •
MoReq2010
Class
) Agregalion
J
for Records Systems
r
{
indlvlduat
classificarion
L Agregation 1
Record Record Record

o
Record
Volume 1
Figure 5d — Individually classifying a record overrides the default class it inherits from its
parent aggregation
Core Services
& Plug-in Modules
Figure 5d shows how inheritance from a record’s parent aggregation can be
overridden by directly classifying individual records. Version 1.1
71
1
Classification
service 5.2.3 Reclassification
From time to time, it becomes necessary to reclassify records in a records
system. This may happen in any records system as business classifications
change over time and are updated. However, it is particularly true when
bringing records from different sources together, such as when two different
business units merge.
MoReq2010® requires that each MCRS provides at least minimal support
for reclassification by allowing an authorised user to replace one nominated
class with another, wherever it is applied within the MCRS.
5.2.4 Classification services and classification schemes

Many organisations create their own, or use industry‑wide, classifica‑
tion schemes that are applicable across the whole of their business. The
service‑based architecture of MoReq2010® makes it possible for different
records systems across the enterprise to share a common centralised clas‑
sification service. A single MCRS may also have more than one classification
service.
Whether centralised or built into an MCRS, each classification service must
support a particular classification scheme. Classification schemes repre‑
sent different ways of arranging the classes within a classification service.
For example, one of the simplest and most popular classification schemes
is hierarchical classification where classes are arranged in a simple tree
structure, as shown in Figure 5e.
MoReq2010°
Hierarchical
Classification
Service
•
MoReq2010 Agregation
1 l
for Records Systems Aa;rqatlon
L,- Acgregation J
Record
ó
Record Record
00
Record Record
Figure 5e — An example of a classification service that adopts a hierarchical classification

scheme
Volume 1 Figure 5e shows an example of a classification service that implements

hierarchical classification. Under this type of classification scheme, only
Core Services the classes at the bottom of the hierarchical structure are used to classify
& Plug-in Modules aggregations and records.
Other types of business classification are also possible, such as Keyword
Version 1.1 AAA, a widely used functional classification scheme expressed in a
72
1
Classification
poly‑hierarchical structure derived from an ISO 2788 compliant monolin‑ service
gual thesaurus (ISO 2788:1986: Documentation — Guidelines for the estab‑
lishment and development of monolingual thesauri). Keyword AAA makes
use of additional inter‑class linkages such as related terms.
So as to facilitate the adoption of different classification schemes by different
industries and organisations in different market sectors, MoReq2010®
allows suppliers the choice over the particular classification scheme or
schemes that their MCRS solutions implement. Requirements specific to
each type of classification scheme are defined in the different classification
modules. Each MCRS must therefore implement the requirements in the
next section as well as at least one of the MoReq2010® 200. Classification
series plug‑in modules.
While, for internal consistency, each classification service must implement
the structure of only one classification scheme, MoReq2010® does not
prevent an MCRS from having more than one classification service, each
having its own distinct classification scheme.

R5.4.1 The MCRS must incorporate the functionality of a classification service that
manages classes within a classification scheme in accordance with one of
the modules in the MoReq2010® 200. Classification series.
The MCRS may implement and be tested against more than one of the
200. Classification series modules, but each separate classification module
must be implemented in its own separate classification service.
R5.4.2 The MCRS must allow an authorised user to create new classes (E14.2.2)
with at least the following system metadata:
•
• Title (M14.4.104), MoReq2010
• Scope Notes (M14.4.97), Modular Requirements
• Default Disposal Schedule Identifier (M14.4.11), and for Records Systems
Each class also has:
• disposal holds associated with the class (see 9. Disposal holding
service),
and may have:
Volume 1
Note that additional class metadata may be specified by the 200. Classification
Core Services
series module that the MCRS implements. & Plug-in Modules
The mandatory disposal schedule that must be associated with a new class on
creation must be an active disposal schedule. Version 1.1
73
1
Classification
service Depending on the approach taken by the MCRS in implementing 4. Model role
operation and may only be added to a class at export.
metadata service, the mechanism by which contextual metadata are added to
classes may vary.
R5.4.3 The MCRS must allow an authorised user to modify the Title, Description
and Scope Notes of an active class, and any of its contextual metadata.
R5.4.4 The MCRS must allow an authorised user to change the default disposal
schedule for an active class, provided the new disposal schedule is active,
and subject to R8.4.4. Whenever this occurs, the MCRS must replace the
previous default disposal schedule with the new default disposal schedule
for all active records classified by that class.
The disposal schedule must only be changed for active records that inherit their
disposal schedule from their class. If the default disposal schedule has been
overridden, for example under R6.5.15, then this function has no effect on the
record. Note that the disposal schedule is never changed on residual records as
these have already been destroyed under the previous schedule.
R5.4.5 The MCRS must allow an authorised user to delete any class that has never
been used for classification.
The Last Used Timestamp should be updated automatically by the MCRS once
the class has been used to classify an aggregation or a record. A class cannot
be deleted once it has been used as it has then become part of the history of
aggregations and records in the MCRS. However, the class can be destroyed
and made residual, under R5.4.6, to prevent it being used again.
•
MoReq2010
R5.4.6 The MCRS must allow an authorised user to destroy any active class,
provided it is not associated with any active aggregation or record.
Modular Requirements All active classes must have an active disposal schedule associated with them
for Records Systems and cannot be destroyed if they are being used to classify active aggregations
or records.
R5.4.7 Subject to R2.4.22, the MCRS must allow an authorised user to browse
classes and their associated entities in the following ways:
• browse across the classes in the classification service and inspect
their metadata;
• browse from a class to its default disposal schedule and inspect its
Volume 1
metadata; and
Core Services • browse from a class to any associated disposal holds and inspect their
& Plug-in Modules metadata.
Version 1.1 Function references: F14.5.30, F14.5.63, F14.5.77
74
1
Classification
R5.4.8 The MCRS must allow an authorised user to replace a nominated class service
with another active class, for all aggregations and records classified by the
class.
All aggregations and records classified by the original class will now be clas-
sified by the replacement class. The default disposal schedule associated with
the original class will be replaced by the default disposal schedule associated
with the replacement class, similar to R5.4.4, for all active records that are
reclassified under this requirement.
This function may result in a large amount of processing, depending on the
number of records to be reclassified. For this reason, it should be used sparingly
and only to support necessary changes to the business classification scheme.
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
75
1
6
Record service

Service name Record service
Service version 1.0
Implements Service ced3d0df‑3f9f‑4807‑9e96‑b5b790adad4a

6.2 kEy CoNCEPtS 1 81

• •
.,,
6.2.1 Purposeful aggregation .a. Jl.1.
46 l'i, bd22
A record service manages records within an MCRS under different levels ' ., o
of aggregation. Each aggregation represents a grouping of records or a
l '
'
0 ¡
grouping of aggregations. Records are placed into aggregations for all or < 4 6 714
,,
some of the following reasons. J O 38 04 • 24
•
84 8 476
They relate to the same business transaction or process. •

< "
• 4 7 b13 2
• •
• They have the same business classification.
• They share the same subject area or topic.
• They relate to the same person, place, project, case, client, event or
incident.
• They share common metadata.
• They have the same source or format.
• They are managed by the same business unit.
• They are intended for the same audience.
• They have the same level of security access control. •
MoReq2010
• They are held under the same retention and disposal conditions.
Aggregation often enhances the semantic understanding of records by
purposefully placing them into a meaningful context alongside other like
records. The aggregation as a whole may, thereby, collectively provide a vivid for Records Systems
descriptive narrative of its subject.
Aggregations may also be gathered into higher levels of aggregation for
similar reasons to those given previously. An aggregation containing records
may belong to a parent aggregation which represents a grouping of like
aggregations.
The highest level of aggregation available to any MCRS is the record service
itself, which, taken as a whole, represents a single aggregation of all of the
records it contains. ISO 23081 envisages a tiered model of aggregation that
goes beyond a single records system or archive, such that, taken collec‑ Volume 1
tively, all of the records systems within an organisation might abstractly be
considered as a further level of aggregation even beyond that.
Core Services
& Plug-in Modules
There is also a practical side to aggregation. Aggregations may be deter‑
mined by operational considerations or by the technical limitations of the
records being managed. This is particularly so if the records are being Version 1.1
77
1
Record service
managed in place in another business system. Where this occurs, the nature
of an aggregation may be determined by the nature of the business system.
If the business system offers, for example, workspaces for collaborative
teamwork, then these workspaces will by necessity form the basis of the
aggregations to be managed by the records system. Similarly, if the records
system is designed to be carried on a mobile device for personal use, it
may have a flatter structure than a cloud‑based records system intended
for sharing across multiple government departments. System specialisa‑
tion, storage location, capacity and volume, secure access restrictions and
other considerations may all play a part in shaping how aggregations are
implemented, sized and managed.
6.2.2 Root aggregations
Within a record service, aggregations that are not the children of other
aggregations are called root aggregations. There is no limit to the number
of root aggregations in a record service. This allows an MCRS to be multi‑
tenanted, if necessary, where different organisations or different parts of an
organisation manage different aggregations and records without reference
to other aggregations and records in the same record service.
Figure 6a shows a typical arrangement of aggregations and records within
a record service where multiple aggregations can be at the root level.
' e
MoReq2010• - MoReq2010�
Figure 6a — Showing different levels of aggregation within a record service where there is
Modular Requirements no single root aggregation
for Records Systems
6.2.3 Restrictions on aggregation
In an MCRS, records and aggregations cannot be placed together at the

same level of aggregation as one another. This is shown in Figure 6b. This
arrangement preserves the integrity and separate identity of each level
of aggregation; it allows consistent management policies to be uniformly
applied to each level of aggregation and ensures that there is no ambiguity
Volume 1 over where records should be created.
Core Services A necessary consequence of this restriction is that records cannot be

created outside an aggregation. This is also shown in Figure 6b. Creating
& Plug-in Modules records directly within the record service would place them at the same
level of aggregation as any existing root aggregations or block the creation
Version 1.1 of any future root aggregations in the MCRS.
78
1
Record service
RKord Servke
�,.;;.----•,•...
-•...
-,•...
-,•Ion------,, 0 Rtt0tds COlltlOI bf'
• , • ploc� ouuldr
, �Ogl}ftgOI/On
º"
L Aare,�lion
0,.____ ·--- .
'
---- '
RrcordJ connor bf' \
'
e••
Record Rerord Record Rec�
ploctd ot thr so�
/,:yr/ os on 09grtt¡otfori
\. _
Record
Rrcouh muJt br p!ocrd or

MoReq2010°
111r �.st �vti o/ 099rtpollon
Figure 6b — A record cannot be stored at the same level as an aggregation
6.2.4 Aggregation and inheritance

One of the primary advantages of aggregation is to support inheritance.
Some of the characteristics that child entities can inherit from their parent
aggregations include:
1. Classification — an aggregation or record can inherit its class from its
parent aggregation;
2. Access controls — an aggregation or record can inherit its parent aggre‑
gation’s access control list (or equivalent, see 4. Model role service); and
3. Metadata — a user can search for aggregations and records based on
metadata assigned to their parent aggregations.
6.2.5 Aggregation and classification

Classification can be applied at different levels of aggregation. By default,
each child aggregation or record inherits its class from its parent aggre‑
gation. However, this may be overridden by applying a separate classifica‑ •
tion to each level of aggregation, and even directly to individual records, as MoReq2010
described in 5.2.2 Inheriting classification.
Aggregation and classification may interact together in different ways. So as Modular Requirements
to provide insight into how this may occur, various scenarios are described for Records Systems
under 6.3 Aggregation and classification examples. It should be noted that
these scenarios do not necessarily reflect the recommended best practice
in records management; however, they are intended to represent commonly
encountered real‑world situations.
6.2.6 Constraining sprawl

The aggregation feature of MoReq2010® is powerful, allowing multiple levels
of aggregation within a record service. While this is extremely useful in
particular circumstances, it is important that this feature is not overused; in
particular, it is desirable to avoid deep structures consisting of many levels Volume 1
of aggregation.
Core Services
As a general rule, flatter structures of only one, or sometimes two, levels
& Plug-in Modules
of aggregation are preferable, as these are easier to manage and the
aggregation feature must not be employed to create pseudo‑classification
hierarchies. Version 1.1
79
1
Record service
For this reason, MoReq2010® allows users to set, for any root aggregation,
the maximum number of levels of aggregation that may be added below it.
By setting this value, users can set limits over the depth to which any aggre‑
gation can grow.
Planned extensions to MoReq2010® will also introduce specialised types of
aggregation which feature a fixed number of levels of aggregation.
6.2.7 original order

One of the important benefits of aggregating records is that the process of
adding records over time places them in a linear sequence that supports
browsing. This natural sequencing provides an historical timeline and adds
an important narrative dimension to the aggregation, shown in Figure 6c.
Aggregation
First
Record
�
\ ,
O�� \ , \ ,
Last
Record
Record Record Record Record
Time •
MoReq2010'
Figure 6c — By ordering on originated date and time, the records in an aggregation can be
browsed in a logical historical sequence
By default, the originated date and time will reflect the timestamp applied
when the record is created in the MCRS. However, where records are created
out of order or the record is not immediately added to the MCRS, the speci‑
fication supports reordering, allowing the originated date and time to be
modified by a user to indicate an earlier moment of origin.
• Time‑based ordering within aggregations is particularly useful when
MoReq2010 capturing records generated by dynamic processes such as workflow. As a
workflow progresses, each major stage or transition can produce a snap‑
shot of the current workflow status that can be sequentially captured into
the aggregation. The aggregation can then reveal how, historically, the end‑
for Records Systems to‑end process was conducted.
Preservation of the original order within an aggregation is another reason
why MoReq2010® does not allow the same level of aggregation to contain
both records and child aggregations (see 6.2.3 Restrictions on aggre-
gation). Placing records at different levels of the aggregation breaks the
natural linear sequence of records within the aggregation and thus inter‑
rupts its narrative. This conundrum is shown in Figure 6d.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
80
1
Record service
Aggregation
L _]
First
Record?
Last
Record?
MoReq2010'
Figure 6d — An aggregation cannot retain its linear narrative if it contains both records
and aggregations at different levels
6.2.8 Record atomicity and duplication

Each entity in MoReq2010® is considered to be self‑contained or atomic. This
characteristic supports interoperability and allows the transfer of entities
between different records systems. This is particularly true of records. Each
record is made up of its metadata, event history, components and access
control list (or equivalent). In particular, a record’s event history confirms
the key events that have occurred since the record was first created in the
MCRS. This provides the provenance of the record, an important ingredient
in establishing its authenticity.
If, within the MCRS, one record is copied from another without also dupli‑
cating the event history of the first record, then the second record cannot
represent a complete record. Even though they are identical copies of one
another, there will be a gap in the event history of the second record up to
the point at which the copy was created. This is shown in Figure 6e. •
MoReq2010
Creation event Copy event lM0Req2010·

for Records Systems
__ ,Llrev��;que\S:ts
7 ORIGINAL
Copy loses this history

1 COPY
.
··.·
.·.·
.·.·
.·.·.·
.·.·
.·.·
.·.·
.·.·.·
.·.·.·
.·.·.l
-....
, ·
- t
I
Time Different events
Volume 1
Core Services
Figure 6e — When a copy is made of a record, it loses part of its event history and does not
have parity with the original & Plug-in Modules
Version 1.1
81
1
Record service
For this reason, MoReq2010® makes no provision for the copying of records
but instead requires a process of duplication. Duplication does not simply
create a new record with the same metadata as the source but also appends
to it a copy of the source record’s event history. Following the duplication
process, neither record can, or should, be regarded as the original and the
other as the copy. Both records are original, as shown in Figure 6f.
Crealion event Duplication event M0Req_2010•
Subsequent events
Other events
LJ �
:::J DUPLICATE
1-----"--'·----
Shared history DUPLICATE
\ f
Time Different events
Figure 6f — When a record is duplicated, the result is the equivalent of having two original
records with the same history up to the moment of duplication
The primary purpose for duplicating a record in an MCRS is to allow the

same record to be present in more than one aggregation. Where this occurs,
each separate appearance of the record must be represented by a duplicate,
each a record in its own right, with its own classification, disposal schedule,
parent aggregation, component entities, access controls, event history, title,
description, and other metadata.
When a record is duplicated, the MCRS may choose to duplicate the content
of the record or it may maintain a system of pointers that utilise the same
content for each duplicate. If the MCRS does make two separate instances
of the content of the record, the content is said to be ‘physically discrete’.
If the MCRS uses pointers, the content is said to be ‘logically discrete’
• (see the principle of discreteness in 6.2.10 Principles of managing
MoReq2010
component content).
In either circumstance, irrespective of whether the content is physically or
Modular Requirements logically discrete, when one record is destroyed, the remaining duplicates
for Records Systems and their content, must be entirely unaffected. If the MCRS only logically
separates content through the use of pointers, the pointers linking the
destroyed record to the content should be deleted but the content itself
should not be deleted until the last duplicate record is destroyed.
6.2.9 Record components

What MoReq2010® refers to as a ‘record’ is really an ‘entity’ (i.e. a set of
metadata stored by the MCRS that describes the record content). The term
‘record’ is, therefore, an abstraction. The actual content or data of the record
is separate to the record entity in the MCRS and may also be stored in a
Volume 1 different database or location.
Core Services The content of each record may take many forms and MoReq2010® makes
& Plug-in Modules provision for plug‑in modules that describe different types of record content.
These forms will usually fall into one of two categories. They will either be
electronic, referring to a digital resource such as a datafile, or physical,
Version 1.1 referring to a real‑world object.
82
1
Record service
The following examples show the different types of content that might
comprise a record managed by an MCRS — this list is not exhaustive.
Electronic examples
• A digital datafile, such as an electronic document produced by a word
processing application.
• Several digital datafiles, collectively, such as the various types of data‑
files required to render a web page in a web browser (e.g. HTML, CSS,
JavaScript, JPEG/GIF/PNG, etc.).
• A row in a database table or, more likely, a set of interrelated rows
across different tables in a database.
• A reference to an entity in a business system (e.g. a link to a customer
entity in a CRM system).
Physical examples
• A paper document.
• A physical object (e.g. a CD, DVD, microfilm, etc.).
• A biomedical sample.
In MoReq2010®, a record can have more than one discrete resource making
up its content. These different resources may even be stored in different loca‑
tions. The association between a record and its content is provided by compo‑
nent entities. Each record can have one or more components. Each component
is a reference to a single item of content. This is shown in Figure 6g.
•
MoReq2010
Component Entity Modular Requirements

for Records Systems
MoReq2010°
[J Component Content
Figure 6g — Each record has one or more components, each of which refers to a single
item of content of a particular type
Note that in Figure 6g, each record is shown as inclusive of its components.
Component entities are an integral part of the record to which they belong.
They do not, for example, have separate access controls, but have the same Volume 1
level of access as the record and its metadata.
Core Services
The types of record components which an MCRS can support are determined
& Plug-in Modules
by which of the MoReq2010® 300. Component series component plug‑in
modules they implement. Each of these modules refers to a different type of
component content, such as an ‘electronic component’. Version 1.1
83
1
Record service
An MCRS may provide support for more than one type of component. Where
this occurs, records with different component types may be freely mixed
together, for example, within the same aggregation.
6.2.10 Principles of managing component content

Not every resource is necessarily suitable for consideration as the content of
a component. MoReq2010® defines specific characteristics that distinguish
component content from other general information. These characteristics
apply regardless of whether the content is electronic or physical, or what
particular form it takes.
In order to be considered as compliant with the specification, the content
referred to by components managed by the records system must have these
characteristics:
• discreteness,
• completeness,
• immutability, and
• destructibility.
The principle of discreteness states that the content of each component

must be separate and distinguishable from the content of other compo‑
nents. Records cannot share components and components cannot share
their content.
Where a component is created that refers to a shared resource, the records
system must ensure that the resource is managed as discrete content
belonging only to that component. MoReq2010® does not specify how this
is done but it may mean physically separating the content, for example by
taking and keeping a separate copy of the resource, or it may mean logically
separating the content, for example by the use of pointers. The principle of
discreteness is illustrated in Figure 6h.
MoReq2010'
Record Componcnt Record
•
MoReq2010
Not c o m p l i a n t
Modular Requirements Aecords are not discrete
for Records Systems Contcnt
Record Record
Compliant
Volume 1
Core Services Coot•ot � Mu$! b• p/,Y'l<ally a,
& Plug-in Modules l._) lagi<a//y diWtlt
Figure 6h — The principle of discreteness means that each component must belong to
only one record and its content must be separate and distinct
Version 1.1
84
1
Record service
It is important for MCRS solutions to be able to manage the process of
duplication of a record, described in 6.2.8 Record atomicity and dupli-
cation, while observing the principle of discreteness. When a record is
duplicated, the record entity and its metadata and access controls are all
duplicated, the events in its event history are duplicated, its components
are duplicated and, most importantly, the content of its components must
be duplicated (as explained previously, either physically or logically).
The principle of completeness states that, taken together, the content
referred to by the components of a record make up the entire record
and there is no dependency on any other resource. The components
and their content must not be reliant on components or content stored
outside the record and not contained within the record and its compo‑
nents. Components within the same record may have interdependencies
between each other but must not have external dependencies. The prin‑
ciple of completeness is shown in Figure 6i.
MoReq2010°
Not compliant
Record is not complete

Record
Content
Compliant
Record Componen!
•
MoReq2010
Content Content
for Records Systems
Figure 6i — The principle of completeness means that each record must be fully
self‑contained and manage all dependent content within its own components
The principle of immutability states that the content of a record cannot be

altered once the record has been created. The metadata of a record or its
components may be modified but not their content. The content must be
secure from alteration, replacement and deletion.
Achieving compliance with the principle of immutability is the reason why Volume 1
many records systems manage content within their own content store.
However, it may be neither possible nor practical to capture all of an organi‑ Core Services
sation’s records into a single content store. Therefore, under MoReq2010®, & Plug-in Modules
it is possible for a compliant records system to manage content in external
content stores provided appropriate measures are taken to ensure immuta‑
bility. The principle of immutability is shown in Figure 6j. Version 1.1
85
1
Record service
MoReq2010"
Not compliant
Record
Compliant
Record
Com�"7--1) @
'º"""' �
Figure 6j — Under the principle of immutability, the content of a component must not be
able to be altered after record creation
The principle of destructibility states that a record cannot be destroyed in

the records system, unless the content of its components is previously or
simultaneously deleted from the content store(s) in which it is managed.
In secure environments, the principle of destructibility extends to such
activities as, for example, shredding or incinerating paper records and, in
electronic environments, overwriting magnetic or other storage media to
ensure it cannot be read. The principle of destructibility is illustrated in
Figure 6k.
Implementing the principle of destructibility and ensuring properly planned
destruction of records is very important to good records management prac‑
tice and ensures that records really are destroyed in accordance with their
disposal schedule and at the appropriate time.
•
MoReq2010 Depending on the type of content belonging to a component, the MCRS may
not be able to automatically initiate its destruction. Particularly for physical
components, but also on occasion for electronic components, some manual
Modular Requirements intervention is required to perform the destruction.
for Records Systems
For this reason, MoReq2010® allows for components where either:
• the content of the component can be deleted automatically by the
records system; or
• the content of the components requires user confirmation that it has
been deleted before destruction of the record and its component enti‑
ties can continue.
This information must be kept as part of the metadata of each component
individually.
Volume 1 Section 8. Disposal scheduling service describes how the disposal sched‑
uling service must respond to each of these types of component content
Core Services when records are scheduled for destruction.
& Plug-in Modules
Version 1.1
86
1
Record service
MoReq20t0'
Not c o m p l i a n t
Content has not been
de-stroyed before the
Record record and components
ts
X'-x Compliant
Record Component
Content
Figure 6k — Before records can be destroyed, under the principle of destructibility, the
corresponding component content must be erased from all content stores
6.2.11 Design approaches to managing component content

The way content is managed and the different types of content that can be
managed by an MCRS will vary depending on the purpose of the records
system and its intended usage. When developing a records system, suppliers
must give consideration to the following factors.
• The number of components each record will have — one, several or
variable.
• The type of content belonging to each component.
• Where the content will be stored — in an internal or external content •
store, or across many content stores. MoReq2010
• How the records system will ensure that the content it manages is
made immutable — especially if records are managed in place or in an Modular Requirements
external content store.
for Records Systems
• How the records system will allow users to access the content of
components.
• Whether the records system will automatically delete the content
when records are destroyed or whether confirmation of deletion will
be required, and for which component content types.
MoReq2010® compatible records systems may be specialised and dedicated
systems and are not required, necessarily, to be able to manage all forms
of component content. However, irrespective of its other design goals, each
MCRS must be able to manage at least one type of component content, be Volume 1
it electronic or physical, in either an internal or external content store as an
integral part of the record service it provides. Core Services
& Plug-in Modules
Version 1.1
87
1
Record service
6.3 AGGREGAtIoN AND ClASSIFICAtIoN ExAMPlES
6.3.1 Casework
Casework and other related activities, such as project work, are common‑
place and particularly prevalent in service industries, such as health, insur‑
ance, banking and legal work. (A previous example related to casework was
given in the discussion of 1.4.5 Classification and aggregation.)
The aggregations used for casework focus on keeping all records germane
to the main subject of the case together. For example, hospital records will
invariably be organised by patient, with records from each subsequent visit
by the same patient being captured into the same patient aggregation, even
though they occur at different times and are for different ailments, check‑
ups or treatments by different medical staff from different departments
within the hospital.
Under these circumstances, it is common to find records within the same
casework aggregation that were created by separate business functions,
activities and transactions and should, therefore, have separate classifica‑
tions. Sometimes casework aggregations will be subdivided into several
secondary aggregations allowing different default classifications to be applied
at the level of these secondary aggregations. For example, within a patient
aggregation, the patient’s medical insurance claims might be separated from
the patient’s treatment records by placing them into different aggregations
within a secondary level of aggregation. On other occasions, it may not be
desirable to subdivide casework aggregations and records within the same
aggregation must be individually classified to reflect their different contexts.
6.3.2 Parallel business activities

Many large organisations have different divisions or business units that
work in parallel, performing the same business functions. For example, a
large corporation may divide its sales activities between three regional sales
teams, the Americas, Asia and EMEA (Europe, the Middle East and Africa):
each of these sales teams performs the same functions and activities but
within their own designated area of operations.
Where this occurs, organisations will often create root aggregations for
MoReq2010
• each of their teams. So, in the example in the last paragraph, there would
be three root aggregations. Each team would then create its records within
its own separate root aggregation. The arrangement of aggregations within
Modular Requirements each root aggregation would be mirrored. Classification of records would
for Records Systems also be applied identically within each root aggregation, using the same
classification service.
Note how, in this example, the classification scheme is not altered to accom‑
modate the organisational structure. The distinction between the Americas,
Asia and EMEA is not introduced as an element of the classification structure
or used to differentiate between different classes, instead it is provided inde‑
pendently of the classification service by means of separate aggregation.
6.3.3 Security considerations
Volume 1 The example given in Section 6.3.2 Parallel business activities was of three
business units that managed their records independently under different
Core Services root aggregations. It may be that the organisation also requires that users
from one business unit be restricted from accessing the records of another
& Plug-in Modules
business unit. For example, users might be only able to create records
under their own team’s aggregation and be granted only browse and inspect
Version 1.1 access to aggregations and records in the other teams’ aggregations. Or, it
88
1
Record service
may be a requirement that users cannot access the aggregations of other
business units at all — this is more akin to a multi‑tenancy arrangement
where the different business units share the same records system but their
users do not interact together.
As aggregations are managed separately from the classification structure,
MoReq2010® allows access controls to be more easily applied to sensitive
aggregations. Each business unit may set the level of access by users to its
records while continuing to share classification in common with other busi‑
ness units. Most organisations have secure or sensitive aggregations where
a different level of access permission is needed; MoReq2010® provides the
capability to secure these aggregations, within one or several secure areas
formed by higher level aggregations, with access controls set at that level of
aggregation without compromise to the classification scheme.
6.3.4 Managing records in place

An MCRS may manage records created and stored on other business
systems. This is also known as managing records in place. Where this
occurs, the MCRS will usually construct aggregations that mirror the natu‑
rally occurring aggregations of the other business system.
The business system will usually create its own form of aggregation suited
to its specialised purpose. For example, the business system may be
organised as a wiki or it may take the form of a database, content manage‑
ment system, e‑mail archiving system, or it may support the setting up of
areas for collaborative teamwork on documents. There are many different
possibilities.
A business system will rarely be organised so as to directly support a busi‑
ness classification scheme; however, depending on the specific nature of
the business system and the level of integration with the MCRS, it may be
possible to classify records automatically based on their type and other
attributes held by the business system.
In this scenario, it is likely that each record will need to be classified individ‑
ually while being placed in an aggregation that mirrors its equivalent loca‑
tion within the business system. The other records in the same aggregation
may well have different classifications depending on how this is determined
from the attributes held in the business system. •
MoReq2010

R6.5.1 The MCRS must allow an authorised user to create active aggregations for Records Systems
(E14.2.1) with the following system metadata:
• Last Addition Timestamp (M14.4.48),
• Class Identifier (M14.4.4),
• Title (M14.4.104), Volume 1
• Description (M14.4.16), Core Services
• Scope Notes (M14.4.97), & Plug-in Modules
• Closed Timestamp (M14.4.5), and
• Destroyed Timestamp (M14.4.17). Version 1.1
89
1
Record service
Each root aggregation also has the following system metadata:
• Max Levels Of Aggregation (M14.4.52).
Each child aggregation also has the following system metadata:
• Parent Aggregation Identifier (M14.4.63), and
• Aggregated Timestamp (M14.4.1).
All aggregations also have:
• child entities (either aggregations or records),
• disposal holds associated with the aggregation (see 9. Disposal
holding service),
• an event history (see 2. System services), and
and may have:
• contextual metadata (from a template or equivalent, see 7. Model
Metadata Service).
Aggregations must always be created as active aggregations; however, they
may be created in either the open or closed state.
operation and may only be added to an aggregation at export.
data service, the mechanism by which contextual metadata is added to aggre-
gations may vary and may not utilise templates.
R6.5.2 The MCRS must allow aggregations to be created under R6.5.1 that are
either:
• root aggregations, without a parent aggregation, provided they are
also assigned an active class on creation; or
• child aggregations, under a parent aggregation, provided they are
• placed into an open aggregation that does not already contain records
MoReq2010
(either active or residual), are either assigned an active class or inherit
their parent aggregation’s class and do not exceed the Max Levels Of
Modular Requirements Aggregation set for the root aggregation under which they are placed.
for Records Systems An aggregation without a parent is a root aggregation. A record service may
manage many root aggregations. Each root aggregation must be directly classi-
fied within an active class. Each root aggregation also has a maximum number
of levels of aggregation which limits the depth of the tree of child aggregations
that can be placed under the root aggregation.
Child aggregations may only be placed into parent aggregations that do not
contain records of any kind. Child aggregations may be directly classified within
an active class or inherit their parent’s classification. Child aggregations cannot
be created in contravention of the depth limitation imposed by Max Levels Of
Volume 1 Aggregation for the root aggregation that is their ancestor.
Core Services
& Plug-in Modules R6.5.3 The MCRS must allow an authorised user to modify the Title, Description and
Scope Notes of an active aggregation, and any of its contextual metadata.
90
1
Record service
R6.5.4 The MCRS must allow an authorised user to reclassify an aggregation by:
• removing the class directly assigned to any child aggregation inheri‑
ting the class assigned to the aggregation’s parent; or
• assigning an active class directly to an aggregation replacing its
previous classification and overriding any inherited class.
Whenever an aggregation is reclassified, the MCRS must ensure its chil‑
dren and descendants are also reclassified if they inherit their class from
their parent and the disposal schedule for records must also be updated in
accordance with R6.5.15.
Reclassifying an aggregation will have a recursively cascading impact on any
children of that aggregation that inherit their parent’s class and their descend-
ants etc.
R6.5.5 The MCRS must allow an authorised user to add, modify and remove a value
for Max Levels Of Aggregation allowed under a root aggregation, provided
the value is not set lower that the number of levels of aggregation that
already exist under the root aggregation.
The maximum number of levels of aggregation allowed under a root aggregation
is not a mandatory metadata element. Where the value is not set, it indicates
that the root aggregation can have an unlimited number of levels of aggregation
under it.
Where Max Levels Of Aggregation is set, it must contain a positive number
or zero. If the root aggregation already has one or more levels of aggregation
below it and a user modifies Max Levels Of Aggregation, the MCRS must ensure
that its value is set to a value equal to, or greater than, the number of existing
levels of aggregation.
R6.5.6 The MCRS must allow authorised users to close and open active aggrega‑
tions, ensuring that an aggregation cannot be closed unless all of its child
aggregations are closed, and that aggregations that are closed are immedi‑
ately destroyed if the following conditions apply: •
MoReq2010
• the aggregation has been used for aggregating records or aggrega‑
tions; and
• all of the child entities of the aggregation (either child aggregations or Modular Requirements
records) have already been destroyed. for Records Systems
Closing an aggregation prevents users from placing any more entities into the
aggregation. It does not prevent users from removing entities from a closed
aggregation.
Closing an aggregation that contains aggregations must not be possible unless
all child aggregations are closed beforehand or simultaneously as part of the
same operation.
Aggregations that are closed can be reopened to accept additional entities,
provided they are still active.
Volume 1
An aggregation with only residual child entities is automatically destroyed when
it is closed (see R8.4.22). Core Services
Note that closing an aggregation will update the Closed Timestamp and opening & Plug-in Modules
an aggregation will clear it.
Function references: F14.5.4, F14.5.9, F14.5.19 Version 1.1
91
1
Record service
R6.5.7 The MCRS must allow an authorised user to delete any aggregation that has
never been used for aggregating entities.
This is the purpose of the First Used Timestamp, listed under R6.5.1.
R6.5.8 For any aggregation, including a root aggregation, the MCRS must allow an
authorised user to move it:
• to a new parent aggregation so that it retains its original classifica‑
tion, provided the parent aggregation is active, open, does not already
contain records, either active or residual, and adding the aggregation
will not exceed the maximum number of levels of aggregation set for
the root aggregation under which it is being placed;
• to a new parent aggregation so that it adopts the classification of its
new parent, provided the parent aggregation is active, open, does
not already contain records, either active or residual, and adding the
aggregation will not exceed the maximum number of levels of aggre‑
gation set for the root aggregation under which it is being placed; or
• so that it becomes a root aggregation while retaining its original
classification.
To retain the aggregation’s classification, the MCRS must change the metadata
of the aggregation during the move operation to indicate that it does not inherit
its parent’s class.
To adopt the classification of its new parent, the MCRS must change the meta-
data of the aggregation during the move operation to indicate that it does inherit
its parent aggregation’s class. This will have a recursively cascading impact on
the descendants of the class, similar to that described in R6.5.4.
Note that when an aggregation is moved to a new parent, its Aggregated
Timestamp and the new parent aggregation’s Last Addition Timestamp will be
updated. When a root aggregation is moved to a parent, the metadata element
Max Levels Of Aggregation will be deleted, if it exists, for the aggregation.
The user requires two forms of authorisation to move a child aggregation. The
user must be authorised to remove the child aggregation from its previous
• parent as well as being authorised to add the child aggregation to its new
MoReq2010 parent. Although there are two functions, F14.5.21 Aggregation — Remove
Aggregation for removing the child aggregation from its previous parent and
F14.5.1 Aggregation — Add Aggregation for adding the child aggregation to
its new aggregation, these functions must be performed together and a single
for Records Systems
event is generated, under R2.5.15, subject to R2.5.13.
When moving a child aggregation to become a root aggregation or moving a root
aggregation to become a child aggregation, the user must be authorised to add
or remove the aggregation at the level of the record service.
inspect aggregations in at least the following ways:
Volume 1 • browse across all root aggregations in the record service and inspect
their metadata;
Core Services • browse from a parent aggregation to its children and inspect their
& Plug-in Modules metadata;
• browse from a child aggregation to its parent aggregation and inspect
Version 1.1 its metadata;
92
1
Record service
• browse from an aggregation to its class in the classification service
and inspect its metadata; and
• browse from an aggregation to any associated disposal holds and
inspect their metadata.
Function references: F14.5.12, F14.5.30, F14.5.63, F14.5.131
R6.5.10 The MCRS must allow an authorised user to create active records (E14.2.12)
in an active and open aggregation, which does not contain any aggregations,
either active or residual, with the following system metadata:
• Title (M14.4.104),
• Duplicate Identifier (M14.4.23),
• Parent Aggregation Identifier (M14.4.63),
• Aggregated Timestamp (M14.4.1),
• Class Identifier (M14.4.4),
• Disposal Schedule Identifier (M14.4.22),
• Retention Start Date (M14.4.93),
• Disposal Action Code (M14.4.18),
• Disposal Action Due Date (M14.4.19),
• Disposal Confirmation Due Date (M14.4.20),
• Disposal Overdue Alert Timestamp (M14.4.21),
• Last Review Comment (M14.4.49),
• Last Reviewed Timestamp (M14.4.50),
• Transferred Timestamp (M14.4.106), and
Each record also has: •
• one or more components, MoReq2010
• disposal holds associated with the record (see 9. Disposal holding

service), Modular Requirements
• an event history (see 2. System services), for Records Systems
and may have:
• contextual metadata (from a template or equivalent, see 7. Model
metadata service).
Records may only be placed into aggregations that do not contain child aggre-
gations of any kind.
service, a MoReq2010® access control list may not be present during system Volume 1
operation and may only be added to a record at export.
Core Services
data service, the mechanism by which contextual metadata is added to records & Plug-in Modules
may vary and may not utilise templates.
93
1
Record service
R6.5.11 The MCRS must allow an authorised user to modify the Title and Description
of an active record, and any of its contextual metadata.
R6.5.12 The MCRS must ensure that each record created under R6.5.10 inherits
its parent aggregation’s class and allow an authorised user to reclassify a
record at creation or at any other time by:
• assigning an active class directly to a record replacing its previous
classification and overriding inheritance from its parent aggregation;
or
• removing the class directly assigned to a record so that the record
inherits its parent aggregation’s class instead.
All records must be classified. Records that inherit their parent aggregation’s
classification may also be reclassified indirectly under R6.5.4 and R6.5.8.
R6.5.13 The MCRS must allow an authorised user to move a record from its parent
aggregation to any active and open aggregation that does not contain any
aggregations, either active or residual, and either:
• retain the record’s previous classification by applying its class directly
to the record; or
• replace the record’s previous classification with the classification of
its new parent aggregation by removing any class directly applied to
the record.
Records may be moved between aggregations so that they retain their previous
classification or their previous classification is replaced by the classification
of the new parent aggregation. Both types of move must be supported by the
MCRS.
Records must not be moved into an aggregation that contains any child aggre-
gations, even residual child aggregations.
Note that the record’s Aggregated Timestamp and the new parent aggregation’s
Last Addition Timestamp will be updated.
•
MoReq2010 Function references: F14.5.3, F14.5.22
R6.5.14 Whenever an active record is first created and classified, or whenever it

Modular Requirements is reclassified under R6.5.4, R6.5.8, R6.5.12 or R6.5.13, the MCRS must
for Records Systems ensure that the record always inherits the disposal schedule associated
with its class, unless that disposal schedule has been overridden, under
R6.5.15.
By default, an active record will always inherit its disposal schedule from its
associated class.
F14.5.137
R6.5.15 The MCRS must allow an authorised user to change the disposal schedule
Volume 1 for an active record, either by:
• applying an active disposal schedule directly to the record and overri‑
Core Services ding the default disposal schedule it inherits from its class; or
& Plug-in Modules
• removing a disposal schedule that has been directly applied to the
record and inheriting instead the default disposal schedule of the
Version 1.1 class.
94
1
Record service
If a disposal schedule is not directly applied to a record, it must always use the
default disposal schedule it inherits from its class.
Note that the disposal schedule of a residual record cannot be changed as it
represents the disposal schedule under which the record was destroyed.
R6.5.16 The MCRS must allow an authorised user to make a duplicate of a record
including its:
• system metadata,
• contextual metadata (or equivalent, see R6.5.10),
• access control list (or equivalent, see R6.5.10),
• event history,
• components, and
• component content.
Whenever events are duplicated, the MCRS must update the Duplicate Identifier
for each event record (see R2.4.16) to allow them to be seen as a single shared
event.
Whenever components are duplicated, the MCRS must update the Duplicate
Identifier for each component (see R6.5.19). Depending on the nature of a
record’s components, the MCRS may duplicate the whole of the content of the
components or only appear to duplicate the content of the components by using
pointers.
inspect records in at least the following ways:
• browse the records in an aggregation in order of their Originated Date/
Time;
• browse from a record to its parent aggregation and inspect its
metadata;
• browse from a record to its class, whether inherited or directly applied,
and inspect its metadata; •
MoReq2010
• browse from a record to its disposal schedule, whether inherited or
directly applied, and inspect its metadata;
• browse from a record to any associated disposal holds and inspect Modular Requirements
their metadata; for Records Systems
• browse from a record to its component(s) and inspect the component
metadata; and
• browse from any component to the record it belongs to and inspect its
metadata.
F14.5.131
Volume 1
R6.5.18 The MCRS must allow an authorised user to search for and find:
• aggregations and/or records classified by a nominated class; and Core Services
• records with a nominated disposal schedule. & Plug-in Modules
The MCRS must find an aggregation or record with the nominated class regard-
less of whether the class is inherited from a parent aggregation or directly Version 1.1
95
1
Record service
applied to the entity. Similarly, the MCRS must find a record with the nominated
disposal schedule regardless of whether the disposal schedule is inherited from
the record’s class or directly applied to the record. Though explicitly specified
here, these search options should be a part of general searching and reporting
in 10. Searching and reporting service.
R6.5.19 The MCRS must ensure that all records are created, under R6.5.10, with
one or more components (E14.2.3) that implement the functionality of one
of the MoReq2010® 300. Component series modules, and are created with
at least the following system metadata:
• Record Identifier (M14.4.86),
• Title (M14.4.104),
• Duplicate Identifier (M14.4.23),
• Automatic Deletion Flag (M14.4.3), and
Each component also has:
• content (held in a content store),
• an event history,
and may have:
Components must always be created as active components within the active
record specified by the record identifier: they are destroyed as part of the
destruction of the record to which they belong (see 8. Disposal scheduling
service).
• The Originated Date/Time of a component may be used to indicate when a

MoReq2010 particular component was created in an external system — for example, the
operating system date/time for a datafile.
The Duplicate Identifier is used to indicate other components containing content
that is a duplicate of the content of the component. This value is automatically
for Records Systems populated when records and their components are duplicated, as described in
R6.5.16.
The Automatic Deletion Flag indicates whether or not components are automat-
ically destroyed by the MCRS or whether their destruction must be requested
and later confirmed (see 8.2.8 Destruction life cycle).
Note that under MoReq2010®, components do not have their own access control
lists but are accessible under the same access control list as the record. It is
important that individual components are not conceptualised as independent
entities that can be separated from the whole of the record to which they
Volume 1 belong.
Core Services It is possible that components will have their own individual contextual meta-
data. Where this occurs, it is often metadata extracted from the content of the
& Plug-in Modules
component by the MCRS on capture. For example, if the managed content is
a digital photograph then the MCRS may extract EXIF (Exchange Image File
Version 1.1 Format) metadata from the photograph and store it with the component entity
96
1
Record service
as contextual metadata to enable better searching and discovery of the record.
MoReq2010® does not include requirements for this in the core specification.
data service, the mechanism by which contextual metadata is added to compo-
nents may vary.
R6.5.20 The MCRS must allow an authorised user to modify the title and description
of an active component, and any of its contextual metadata.
R6.5.21 Whenever the MCRS generates an event for the component, under R2.4.15,
it must include a record identifier in the metadata of the event, so that the
event also appears in the event history of the component’s record as well as
in the event history of the component.
Each component has its own event history; however, all events for the compo-
nent will also appear in the event history of the record to which the component
belongs. In this way, a user can browse the event history of the record and see
any events that have occurred for any of its components.
F14.5.42, F14.5.43, F14.5.44, F14.5.45, F14.5.46, F14.5.47
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
97
1
7
Model metadata service

Service name Model metadata service
Service version 1.0
Implements Service For an MCRS implementing the MoReq2010®

Identifier (see M14.4.42) model metadata service use:
a600f8d0‑2d58‑418e‑bb41‑211d1fd42350
For an MCRS implementing its own native • •
contextual metadata model use: 1 81
.,,
66bf4419‑d92f‑4358‑8506‑7ee9c06abdcd .a. Jl.1.
46 l'i, bd22
' ., o
7.2 CoMPlyING wItH tHE MoDEl MEtADAtA
l '
'
0 ¡ 4 6 714
<
SERVICE
,,
J O 38 04 • 24
•
84 8 476
7.2.1 Interoperability and metadata •

< "
4 7 b13 2
• •
A significant objective of MoReq2010® is to facilitate interoperability between
compliant records systems. Interoperability means that entities can be
exported from one MCRS and imported directly into another. The transmis‑
sion of data between the two records systems must preserve the integrity
and the context of the entities that are transferred.
This goal of interoperability can only be achieved if each entity, and each
metadata element belonging to an entity, is recognisable and able to be
interpreted universally. It must mean the same thing everywhere. The World
Wide Web is a good example of interoperability between different applica‑
tions and systems. There are many different web browser software products
from different suppliers in use today and each has its own features and
benefits. However, web pages, which hold the data that web browsers inter‑ •
pret and visually present, are formatted according to a well‑known industry MoReq2010
standard called HTML. All compliant web browsers can read, interpret and
render standardised HTML.
In the same way, in the future, there may be many different MCRS solutions, for Records Systems
with different features from different suppliers, but they will all be able to
exchange records, and other entities related to records management, using
the standardised MoReq2010® metadata model and schema.
To achieve this, MoReq2010® is more prescriptive than previous specifica‑
tions, especially concerning the metadata elements each compliant records
system must keep as well as how particular processes, such as disposal,
should be implemented. This standardisation allows MoReq2010® to specify
a universally understood metadata schema for use by all MCRS solutions.
7.2.2 A model metadata service Volume 1

Throughout MoReq2010®, the metadata required by each entity and each Core Services
service is specified as part of the functional requirements and expanded in & Plug-in Modules
detail in 14. Information model. This required metadata is called ‘system
metadata’. MoReq2010® takes the same technique for defining system
metadata and allows it to be used to create additional metadata elements Version 1.1
99
1
Model metadata
service specific to a particular implementation. These are called ‘contextual meta‑
data’. So as to allow a predefined set of contextual metadata elements to
be simultaneously added to an entity, MoReq2010® allows the definition of
metadata templates which contain a list of metadata element definitions.
Metadata templates can be applied to entities on creation as a result of their
being created under a particular service or classification.
The MoReq2010® approach to managing metadata is therefore simple, easily
understood and able to be expressed with a handful of different entity types. It
builds on the same approach used to define system metadata and should fit well
with most existing records systems, many of which take far more sophisticated
approaches to metadata management than is required by MoReq2010®.
At the same time, MoReq2010® recognises that some existing records
systems may manage metadata using techniques that are internally incom‑
patible with the model metadata service as specified: it may be that they do
not use metadata templates to enable contextual metadata to be applied
to entities, for example, but some other method. It is important, in the
interests of increasing interoperability, that these records systems are still
able to transfer entities to other records systems that do implement the
model metadata service and that they are, therefore, able to be certified as
MoReq2010® compliant records systems.
In the future, new records systems may fully incorporate the MoReq2010®
model metadata service while the suppliers of existing records systems may
gradually adopt and progressively support aspects of the model metadata
service in newer versions of their software.
7.2.3 Approaches to testing and certification against the model metadata service
The DLM Forum Foundation allows two possible approaches to the testing
and certification of a records system for compliance with the MoReq2010®
model metadata service.
EItHER
A. The records system implements the MoReq2010® model metadata
service in full and is tested and certified against the requirements in
this module.
oR
•
MoReq2010 B. The records system implements its own native metadata model, in
which case the application must satisfy the following criteria.
Modular Requirements • It must demonstrate that its native metadata model is equivalent
in flexibility, functionality and the consistency of information it
for Records Systems
captures to the MoReq2010® model metadata service.
• It must support interoperability by being able, on export, to convert
its native metadata into the same XML format used by the model
metadata service, so that metadata elements are populated with
the same data, with the same semantic interpretation, and using
the same standardised identifiers and codes, when the data is
subsequently transferred to another MCRS.
7.2.4 How to meet the alternative (type B) requirements

Volume 1 To show that the MCRS’s native metadata service is equivalent in flexibility, func‑
tionality and the information it captures to the MoReq2010® model metadata
Core Services
service, the records system must be able to demonstrate all of the following.
& Plug-in Modules
• That it has the equivalent of each of the entity types defined by
MoReq2010®: these must be represented within the records system
Version 1.1 with the same purpose as given by the specification.
100
1
Model metadata
That, for each entity type, it has the equivalent of the system metadata service
elements defined by MoReq2010®: these must have the same datatypes,
meaning and range of values as defined by the specification.
• It must be possible to create instance‑specific or contextual metadata
elements, including both contextual metadata elements that store
data values and contextual metadata elements that store references
to entities.
• Different entity types, especially aggregations and records, must be
able to include contextual metadata in their definitions, in addition to
the system metadata defined by MoReq2010®.
• The supplier must be able to demonstrate how contextual metadata
elements are defined and applied;
• The supplier must be able to demonstrate how values for contextual
metadata elements are entered, modified and deleted.
• The metadata service must be able to support a theoretically unlimited
number of additional contextual metadata element definitions.
• Contextual metadata elements must be able to be applied collecti‑
vely (rather than individually) to entities in ordered sets (MoReq2010®
describes these as templates) when those entities are first created
and, possibly, later.
• The records system must allow these sets of contextual metadata
elements to be selectively applied to entities for different business
reasons but at least one reason for applying a set of contextual meta‑
data elements to an aggregation or a record must be as a consequence
of its classification (i.e. different records or aggregations created with
different classifications must be allowed to have different sets of meta‑
data associated with them depending on their class).
• Each metadata element should only ever be applied to an entity once.
• When a metadata element is applied to an entity and requires a
mandatory value to be supplied, the entity must not be created in the
MCRS until a valid value has been provided by one or a combination of
a default value for the element, a value automatically calculated by the
records system and/or a user supplied value.
• Textual metadata elements must always be accompanied by a language
•
identifier indicating the language of the metadata element. MoReq2010
• The record service must have provision for metadata elements to be
selectively deleted from an entity when it is destroyed, this to be speci‑
fied universally for each metadata element and able to be reconfigured Modular Requirements
by an authorised user. for Records Systems
When converting its native metadata for export in accordance with the
MoReq2010® model metadata service format, the following must be observed.
• The records system must use UUIDs for the system identifiers of all
entities and services.
• The records system must always use the MoReq2010® standard iden‑
tifiers and codes where they are provided.
• The records system must not add additional entity types and services
that are not defined by the MoReq2010® specification.
Volume 1
• MoReq2010® system metadata elements may not be used to store
data values that are not in accordance with the stated purpose of the Core Services
metadata element.
& Plug-in Modules
• The supplier must not expand on the system metadata of MoReq2010®
but may add additional information to entities and services using
MoReq2010® contextual metadata elements where required. Version 1.1
101
1
Model metadata
service • These contextual metadata elements may be added at export, so as to
provide additional information about the internal state of the records
system (e.g. if the records system has its own internal identifier for
each entity).
• All contextual metadata elements added to entities and services must
have associated MoReq2010® compliant metadata element definitions
included in the same export so that entities with contextual metadata
elements can be imported and interpreted by the receiving system.
• The records system must not alter either the meaning or the value of
the contents of a metadata element during export.
• The supplier must describe the metadata and template mapping used
by its product and provide a complete mapping table showing which
internal elements correspond to which MoReq2010® elements and
showing how the exported metadata has been made to imitate the
model metadata service as accurately as possible.
• The supplier must make its metadata mapping schema available for
inclusion in the full test report of its product.
Further advice and guidance to suppliers can be requested from the MoReq
Governance Board through the DLM Forum Foundation secretariat.
The remainder of this module describes the concepts and requirements of
the MoReq2010® model metadata service.
7.3 kEy CoNCEPtS

7.3.1 System metadata and contextual metadata
The MoReq2010® core requirements specify a simple set of metadata
elements, arguably a minimal set, required to successfully manage records
within an MCRS and to transfer them, using the MoReq2010® export data
format, to other records systems. This essential working set of metadata
specified by MoReq2010®, is referred to throughout the specification as
‘system metadata’ and must be supported by every MoReq2010® compliant
records system. System metadata represents only those metadata elements
required to perform the functional requirements of MoReq2010®.
•
MoReq2010 In addition to implementing the required records management functionality
described by MoReq2010® using system metadata, records systems can
also add metadata elements to records and related entities that enrich the
Modular Requirements historical and operational context of these entities.
for Records Systems Metadata that can provide this additional benefit when managing records,
include but are not limited to:
• additional descriptive information not conveyed by the Title or Description
of an entity — for example GPS coordinates for records referring to parti‑
cular geographic features or locations;
• external identifiers or reference numbers — for example an accession
number for an archive or a court reference number for a legal summons;
• encoded information extracted from the contents of a record — for example
the name and address of a supplier for a purchase order formatted so that
Volume 1 it can be used by an address verification application;
Core Services • markings used privately by an organisation or within a specific legal or
regulatory context — for example a marking indicating whether a record
& Plug-in Modules
has been assessed for release to the public according to Directive 2003/4/
EC (Directive 2003/4/EC of the European Parliament and of the Council of
Version 1.1 28 January 2003 on public access to environmental information);
102
1
Model metadata
• workflow status — for example, if a record has been reviewed, the service
reviewer’s name, review outcomes and date of review;
• metadata captured from other business systems — for example, for e‑mail
records, the contents of the From, To, CC, Subject and other metadata in
the e‑mail header;
• metadata extracted from the components of a record — for example,
for images, details such as their dimensions, pixel density, numbers of
colours used and compression format; and
• for users and groups — additional information extracted from the corpo‑
rate directory, such as a person’s position in the organisation, physical
office location, e‑mail address and telephone number.
Throughout MoReq2010®, this additional metadata is referred to as ‘contex‑
tual metadata’ because it is applied within a particular localised context, in
an individual records system, and not for all records systems universally.
7.3.2 the MoReq2010® model metadata service
MoReq2010® provides for a metadata service that manages entity types and
their related metadata element definitions. The metadata service may be
shared and used by several records systems, or even business systems, or
it may be entirely built into a specific records system so that it is not distin‑
guishable from the MCRS as a whole.
7.3.3 Metadata entity relationships
The relationships between the main entities in the model metadata service
are shown in Figure 7a. This illustration captures all the relationships
between entities. This is further broken down into the individual relationships
between entities, which are explained in the simpler diagrams following.
System
Metadata EntltyType Template •

Element MoReq2010
Definttlon
- Modular Requirements
for Records Systems
Contextual
MoReq2010.
Metadata
Element
Deflnltlon
System Contertual
Volume 1
Core Services
Entlty
Metad.ata Metadata
& Plug-in Modules

Element Element
-
Figure 7a — Entity relationships in the model metadata service
Version 1.1
103
1
Model metadata
service At the centre of this diagram is the relationship between entities and entity
types. Each entity must belong to one, and only one, of the entity types spec‑
ified by MoReq2010®: this is shown in Figure 7b. Entities and entity types are
managed under their appropriate service (see R2.4.9).
M0Req7010•
Entity Type
Entlty
- .
Figure 7b — Each entity has an entity type
Each entity is comprised of metadata elements. The metadata elements

mandated by MoReq2010® are the entity’s system metadata elements, while
additional descriptive metadata elements not referred to by MoReq2010®
may also be added to the entity, either at creation or later. The relationship
between an entity and its metadata elements is shown in Figure 7c. The
entity has many metadata elements, each of which belongs exclusively to
that entity.
M0Req2010'
•
MoReq2010
System contextual
(ntity
Metadata Metadata
Modular Requirements Element Element

for Records Systems
- - .
Figure 7c — Each entity has system metadata elements and may also be given contextual
metadata elements
In the same way as an entity is defined by an entity type definition, meta‑

data elements are always linked to a metadata element definition. There
must be either a system metadata element definition or a contextual meta‑
data element definition that corresponds to every metadata element that is
included in an entity: this is shown in Figure 7d.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
104
1
Model metadata
service
MoReq2010
System Contextual
Metadata Metadata
Element Element
Deflnltlon Deflnltlon
System Contextual
Metadata Metadata
Element Element
Figure 7d — All metadata elements are associated with a metadata element definition
System metadata element definitions are defined and provided by

MoReq2010® and are listed in 14.4 System metadata element definitions.
These are associated with different entity types, as shown in Figure 7e,
strictly in accordance with the functional requirements of MoReq2010®.
Records systems are not able to define additional system metadata elements
or additional entity types.
Contextual metadata element definitions are created by authorised users
to meet local needs. These locally defined metadata element definitions are
added to entities by being included in templates that are then applied to
entities of a particular entity type.
MoReq2010
System
Metadata •
Entity Type MoReq2010
Element
Deflnltlon
for Records Systems
Figure 7e — System metadata element definitions are associated with an entity type
Each template contains a collection of contextual metadata element defini‑

tions and may be applied to one or more entity types. If the template is spec‑
ified as a service template for an entity type, it will be automatically applied
by the MCRS whenever an entity of that type is created in that service.
Otherwise, templates are applied to entities selectively by an authorised
user or, for records and aggregations only, by classifying them with a partic‑
ular class that is associated with a record type.
The relationship between templates and entity types, and templates and Volume 1
contextual metadata element definitions is shown in Figure 7f.
Core Services
& Plug-in Modules
Version 1.1
105
1
Model metadata
service
EntityType Template
..
Contextual
MoReq2010'
Metadata
Element
Deflnltlon
Figure 7f — Contextual metadata element definitions are associated with templates,

which are in turn associated with an entity type
Note that, taken collectively, Figures 7b to 7f make up the entity relationship

diagram in Figure 7a.

R7.5.1 Each metadata service must manage metadata element definitions
• Title (M14.4.104),
• Presentation Order (M14.4.84),
• Min Occurs (M14.4.56),
• • Max Occurs (M14.4.53),
MoReq2010 • Is Modifiable Flag (M14.4.46),
• Is Entity Reference Flag (M14.4.45),
Modular Requirements • Entity Reference Type Identifier (M14.4.24),
for Records Systems
• Datatype (M14.4.10),
• Is Textual Flag (M14.4.47),
• Default Value (M14.4.13),
• Default Language Identifier (M14.4.12), and
• Retain On Destruction Flag (M14.4.88).
Metadata element definitions also have:
Volume 1 • an access control list (or equivalent, see 4. Model role service).
These metadata apply to both system and contextual metadata element
Core Services
definitions.
& Plug-in Modules
System Identifiers for every system metadata element definition in MoReq2010®,
along with default titles, descriptions and the entity types they apply to, can be
Version 1.1 found in 14.4 System metadata element definitions. The MCRS must always
106
1
Model metadata
use the MoReq2010® System Identifiers and must not generate its own system service
identifiers for system metadata element definitions.
System metadata element definitions are specified by MoReq2010® and are
not created by users and can never be destroyed. However, their default Title,
Description and Scope Notes may be replaced by the MCRS with localised values.
operation and may only be added to a metadata element definition at export.
R7.5.2 The MCRS must allow an authorised user to create contextual metadata
element definitions (E14.2.4) with the metadata specified under R7.5.1,
which includes the following additional system metadata:
• First Used Timestamp (M14.4.32), and
System metadata element definitions use only the base metadata element
definition given in R7.5.1. Contextual metadata element definitions have addi-
tional metadata and more functions may be performed on them. Unlike system
metadata element definitions, contextual metadata element definitions may be
created, exported and destroyed. They are also included in templates.
R7.5.3 The MCRS must ensure that for each new contextual metadata element
definition created under R7.5.2, the authorised user indicates whether the
intent of the metadata element is to:
• hold a reference to an entity by storing its System Identifier; or
• hold a valid data value specified by a W3C XML datatype.
Whether the contextual metadata element contains a System Identifier or a data
value is determined by whether or not the Is Entity Reference Flag is set.
If the contextual metadata element definition is for an element that will hold
a reference to an entity, the allowable entity types for the reference must be •
included in the Entity Reference Type Identifier element. MoReq2010
If the contextual metadata element definition is for an element that will hold
a data value, the Datatype element must contain a value that conforms to Modular Requirements
the W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. The
for Records Systems
datatype definition must be self-contained within the element definition held
by the MCRS, or long-term preservation of the metadata cannot be assured.
MoReq2010® does not allow XML definitions for datatypes containing a URI to
an external XSD schema.
Where relevant, the Is Textual Flag must also be set to show that the metadata
element will contain textual information. To set this value, it is necessary to
know the purpose of the field. Some datatypes may contain text but are not
themselves textual elements: metadata with these datatypes do not require an
indicator of the language in which they are written. When a value is added to a
textual metadata element, it must have an accompanying language identifier Volume 1
under R2.4.28. For example, the datatype definition for a UUID is text-based but
not written in any particular language. Core Services
These values may be changed until the metadata element definition is first & Plug-in Modules
used, under R7.5.9.
107
1
Model metadata
service R7.5.4 The MCRS must ensure that for each new contextual metadata element
definition created under R7.5.2, the authorised user specifies the minimum
number of occurrences of the metadata element as well as the maximum
number of occurrences of the metadata element, if required.
These values are stored in the Min Occurs and Max Occurs metadata elements
(see R7.5.1). These settings may only be specified for new contextual metadata
element definitions. For system metadata element definitions and for contex-
tual metadata element definitions after they have been used, the values of Min
Occurs and Max Occurs may not be changed (see R7.5.9).
Min Occurs may be set to ‘0’, denoting that having a value is optional, or it may
be set to ‘1’, indicating that a value is mandatory, or higher.
Max Occurs cannot be set to a number lower than the minimum number of
values and may be set to ‘1’, meaning that only one value may be associated
with the entity, any number higher than ‘1’ indicates a list of values.
If Max Occurs is not set, an unlimited number of values can be stored in the
element, representing a list of any length.
R7.5.5 The MCRS must ensure that each metadata element definition is given a
unique Presentation Order, under R7.5.1.
The Presentation Order value provides a simple way of listing the metadata
elements for any given entity in a chosen order that is neither random nor sorted on
one particular attribute, such as title. Metadata is often presented in a list with the
most significant elements towards the top and related elements grouped together.
For example, the desired order of metadata elements within an address might be:
• Addressee
• Street Address 1
• Street Address 2
• City
• Region
• Postal Code
• Country.
• This order would be observed if the contextual metadata element definition
MoReq2010 for ‘Addressee’ had the lowest value for Presentation Order and ‘Country’ had
the highest value for Presentation Order, with the various metadata elements
arranged in sequence. The actual value of the Presentation Order element is not
Modular Requirements significant — the relative difference to other elements’ values is more important.
for Records Systems An authorised user may change the Presentation Order of a metadata element
definition, including for both system and contextual metadata elements, under
R7.5.8, provided it remains unique.
Although records systems may also implement more sophisticated approaches
to presenting metadata within their interfaces, Presentation Order remains
valuable because it supports interoperability and gives a records system that
imports entities important clues as to how those entities were presented in
their original environment.
R7.5.6 For each active metadata element definition, under R7.5.1, except for system
Volume 1
metadata elements that hold System Identifiers or timestamps, the MCRS
Core Services must allow an authorised user to specify whether or not metadata elements
with that metadata element definition should be retained when the entity
& Plug-in Modules they belong to is destroyed.
This is the value stored in the Retain On Destruction Flag and may only be
Version 1.1 changed while the metadata element definition remains active.
108
1
Model metadata
If this flag is not set, the corresponding metadata element will be pruned from service
an entity when it is destroyed and will not be part of the resulting residual entity.
Once it is pruned from a residual entity, the value of this element cannot be
recovered. Note that changing the value of this flag will not have the effect of
pruning the elements for entities that have already been destroyed, but only for
entities that are destroyed in the future.
Pruning of some metadata on destruction is required to ensure that the residual
entity is destroyed and remaining metadata cannot be used to reconstruct the
original entity. Metadata values may also hold personal or sensitive information
that should not be retained once the entity is destroyed.
System metadata elements that hold System Identifiers (references to the
entity and other entities) and timestamps are necessary to the integrity of the
entity and must not be deleted from any entity. For example, the presence of the
Destroyed Timestamp indicates that an entity is a residual entity.
R7.5.7 The MCRS must allow an authorised user to delete any metadata element,
except a system metadata element that holds a System Identifier or a times‑
tamp, from any residual entity, provided the user gives a reason for the dele‑
tion and an event is generated.
This requirement describes a special circumstance where it becomes neces-
sary to remove metadata or events from individual entities where, for example,
this has been ordered by a court of law. It should not be necessary to exercise
this requirement as part of routine records management processes.
This requirement may only be applied to a residual entity which has already
been destroyed and is in addition to the automatic pruning of metadata and
events which occur on destruction.
requirement R2.4.13. The authorised user must give a reason for deleting the deleted
metadata elements which must be stored as the Comment in the new event.
The new event must also contain a Deleted Metadata Element Definition
Identifier (see M14.4.15) which indicates the System Identifiers of the defini-
tions of the deleted metadata elements. This shows that metadata elements
were deleted from the entity without retaining their values.
•
See also R2.4.21. MoReq2010

F14.5.123, F14.5.146, F14.5.168, F14.5.182 Modular Requirements
for Records Systems
R7.5.8 The MCRS must allow an authorised user to modify the following meta‑
data for any active metadata element definition, including system metadata
element definitions:
• Title,
• Description,
• Scope Notes,
• Presentation Order,
• Default Value, and Volume 1
• Default Language Identifier.
Core Services
The MCRS must ensure that the default value, if modified, is always
consistent with the datatype of the metadata element definition. & Plug-in Modules
These values may be replaced for any system metadata element definition,
including replacing the English titles and descriptions for system metadata Version 1.1
109
1
Model metadata
service definitions, provided by MoReq2010®, with alternatives in any language in
accordance with the organisation’s operational and business needs.
As described in the rationale to R7.5.5, the meaning of Presentation Order may
be interpreted differently by different MCRS solutions. Each MCRS may make its
own provision for how Presentation Order is determined and maintained. It may
not be possible for authorised users to directly modify the Presentation Order
numeric value if, instead, for example, the MCRS allows them to manipulate the
positioning of elements on a display which has the equivalent effect of changing
the underlying presentation order.
R7.5.9 In addition to R7.5.8, the MCRS must allow an authorised user to modify the
following metadata for any active contextual metadata element definition
that has never been applied to an entity:
• Min Occurs,
• Max Occurs,
• Is Modifiable Flag,
• Is Entity Reference Flag,
• Entity Reference Type Identifier,
• Datatype, and
• Is Textual Flag.
Once the contextual metadata element definition has been used, these values
may no longer be changed (see R7.5.3 and R7.5.4).
R7.5.10 The MCRS must allow an authorised user to delete a contextual metadata
element definition that has never been applied to an entity.
When a contextual metadata element definition is first applied to an entity, the
MCRS must set the First Used Timestamp.
Note that this function does not apply to system metadata element definitions
that may never be deleted or destroyed.
•
MoReq2010 Function reference: F14.5.49
R7.5.11 The MCRS must allow an authorised user to destroy a contextual metadata
Modular Requirements element definition once it has been applied to an entity. The MCRS must ensure
for Records Systems that when a contextual metadata element definition is destroyed, then:
• new metadata elements with this contextual metadata element defini‑
tion are no longer created and applied to entities; and
• existing metadata elements with this contextual metadata element
definition remain associated with entities, but their values may no
longer be modified.
Once a contextual metadata element definition has been used, it may no longer
be deleted under R7.5.10: it may only be destroyed. Destroying a contextual
metadata element definition will leave a residual entity. New metadata elements
Volume 1 cannot be created from residual contextual metadata elements, but existing
metadata elements remain as ‘read-only’ elements (note that this is the same
Core Services effect as clearing the Is Modifiable Flag in the metadata element definition).
& Plug-in Modules Note that this function does not apply to fixed roles provided in an MCRS solu-
110
1
Model metadata
R7.5.12 Subject to R2.4.22, the MCRS must allow an authorised user to browse service
the metadata element definitions and templates in the metadata service,
and entity types in their respective services under R2.4.9, and inspect their
metadata in the following ways:
• browse across all metadata element definitions in the metadata
service in presentation order and inspect their metadata;
• browse across all templates in the metadata service and inspect their
metadata;
• browse from a system metadata element definition to any of the entity
types that contain that system metadata element definition and inspect
their metadata;
• for each entity type, under R2.4.10, browse from the entity type to the
system metadata element definitions associated with that entity type;
• browse from a contextual metadata element definition to any of the
templates that contain that contextual metadata element definition;
• browse from a template to any of the contextual metadata element
definitions associated with that template;
• browse from a template to any of the entity types associated with that
template; and
• for each entity type, under R2.4.10, browse from the entity type to the
templates associated with that entity type.
The terms ‘browse’ and ‘inspect’ are defined in 13. Glossary. Further informa-
tion on the MoReq2010® entity types and system metadata element definitions
is provided in 14. Information model.
Function references: F14.5.83, F14.5.109, F14.5.171
R7.5.13 Whenever metadata elements are added to entities on the creation of the
entity, when a template is applied to an existing entity, or at any other time
and, subsequently, whenever the value of a metadata element is modified,
the MCRS must ensure that the following rules are observed.
• The metadata element must be initialised with the Default Value in its
metadata element definition, if one has been provided.
•
• The metadata element must never be given a value that is inconsistent MoReq2010
with the Datatype of its metadata element definition.
• If the metadata element contains a reference to an entity, as indicated
by the Is Entity Reference Flag in its metadata element definition, then Modular Requirements
its value must represent a valid System Identifier belonging to an entity for Records Systems
of the type indicated by the Entity Reference Type Identifier.
• If the metadata element is textual, as indicated by the Is Textual Flag
in its metadata element definition, it must always have an accompa‑
nying language identifier which, by default, will be derived from the
Default Language Identifier for the metadata element definition (if one
has been provided).
• The metadata element must never have fewer values provided for it than
allowed by the value of Min Occurs in its metadata element definition.
• The metadata element must never have more values provided for it than Volume 1
allowed by the value of Max Occurs in its metadata element definition.
Core Services
• Once the metadata element has been created and given a value, if it is & Plug-in Modules
not modifiable under its metadata element definition as indicated by
the Is Modifiable Flag, the MCRS must prevent the value of the meta‑
data element from being altered by a user. Version 1.1
111
1
Model metadata
service • If the metadata element definition for the metadata element has been
destroyed, the MCRS must prevent the value of the metadata element
from being altered by a user, under R7.5.11.
R7.5.14 The MCRS must allow an authorised user to create active templates
(E14.2.15) with at least the following system metadata:
• Title (M14.4.104),
• Template Entity Type Identifier (M14.4.102),
• Template Service Identifier (M14.4.103),
• Template Class Identifier (M14.4.101),
• Contextual Metadata Element Definition Identifier (M14.4.8), and
Each template must also have:
• an event history (see 2. System Services),
and may have:
• contextual metadata.
operation and may only be added to a template at export.
R7.5.15 The MCRS must allow an authorised user to modify the following metadata
for any active template:
• • Title,
MoReq2010
• Description,
• Template Entity Type Identifier,
• Template Service Identifier,
for Records Systems
• Template Class Identifier,
• Contextual Metadata Element Definition Identifier, and
• Any contextual metadata elements.
Note that changes to metadata will not affect or reverse any previous applica-
tions of the template.
The Template Entity Type Identifier indicates to which types of entities the
template can be applied. If the template is a service template, as indicated by
the presence of a Template Service Identifier, then it will be applied automati-
Volume 1 cally to all new entities of these types that are created by the service, or bundle
of services under R2.4.1, when its System Identifier matches the Template
Core Services
Service Identifier, under R7.5.18.
& Plug-in Modules
The Template Class Identifier indicates whether the template is associated with
one or more classes in the classification service. If this is the case, the template
Version 1.1 will be automatically applied to all new records or aggregations (depending on
112
1
Model metadata
the Template Entity Type Identifier) created with this classification, or changed service
to this classification.
The Contextual Metadata Element Definition Identifier is used to include contex-
tual metadata element definitions in the template. Each template may include
multiple contextual metadata element definitions, each specifying a contextual
metadata element which is added to the metadata of the target entity when-
ever the template is applied. System Metadata Element Definitions cannot be
included in templates.
R7.5.16 The MCRS must allow an authorised user to delete any template that has
never been applied to an entity.
This is the purpose of the First Used Timestamp, listed under R7.5.15.
R7.5.17 The MCRS must allow an authorised user to destroy an active template,
preventing it from being applied to entities, provided the template has previ‑
ously been applied to an entity.
This will leave a residual template. If the template has never been used, it
should be deleted, under R7.5.16.
R7.5.18 The MCRS must automatically apply an active template to an entity on its
creation in all cases when:
• the entity is created in a service, or bundle of services under R2.4.1, for
which there are one or more service templates of the same entity type,
indicated by a combination of the Template Service Identifier and the
Template Entity Type Identifier;
• the entity is an aggregation and is created and classified with a class
for which there are one or more aggregation templates, indicated by a
combination of the Template Class Identifier and the Template Entity Type
Identifier; or
• the entity is a record and is created and classified with a class for which •
there are one or more record templates, indicated by a combination of the MoReq2010
Template Class Identifier and the Template Entity Type Identifier.
Applying a template to an entity means that the MCRS adds contextual meta-
data elements to the entity for all active metadata element definitions included
for Records Systems
in the template that have not previously been applied to the entity.
New metadata elements are only added to the entity when it does not already
have an existing metadata element with the same contextual metadata element
definition. Each entity may only have one metadata element corresponding to a
particular contextual metadata element definition (although the one metadata
element may have multiple values under R7.5.4).
F14.5.121, F14.5.143, F14.5.165, F14.5.179
R7.5.19 The MCRS must allow an authorised user to apply an active template to an Volume 1
active entity at any time, provided the entity’s type matches the Template
Core Services
Entity Type Identifier.
& Plug-in Modules
See the rationale to R7.5.18. The MCRS may also automatically apply additional
contextual metadata element definitions and values to an entity at any time,
including on export, in accordance with its own design purpose and internal Version 1.1
113
1
Model metadata
service logic. For example, the MCRS may be capable of extracting additional metadata
automatically from certain types of electronic content, such as the properties
of a Microsoft Word document. As new records with these types of content are
created, the MCRS might analyse the content of each component, automatically
extract any properties it identifies and then add them, as additional metadata
elements, to the component.
F14.5.115, F14.5.141, F14.5.157, F14.5.164, F14.5.177
R7.5.20 The MCRS must ensure that once metadata elements have been added to
an entity under either R7.5.18 or R7.5.19, they are never deleted while the
entity remains active.
Note that the metadata elements may be automatically pruned from the entity
on its destruction, depending on the setting of the Retain On Destruction Flag in
the metadata element definition under R7.5.6, or deleted from a residual entity,
under R7.5.7.
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
114
1
8
Disposal scheduling service

Service name Disposal scheduling service
Service version 1.0
Implements Service fd05e284‑181f‑4f5d‑bd8c‑4bed835c8931

q
8
i;.444 Q4
•
8.2 kEy CoNCEPtS 1 81
�,d.2 .a. Jl.1.

8.2.1 the MoReq2010® record life cycle 4
,,
J7 bd22
Disposal schedules are used to manage the life cycles of records in all ' ., o l '
MCRS solutions.
'
<
o¡ 4 6 134
,,
A record, once it has been created in an MCRS, can never be deleted in J O 38 b 04 • 24
full, as if it had never existed. This concept of accountability is impor‑ < "
84
• •
76
tant to good records management: although the complete record and its • 4 4 7 ea 2
content no longer exist, there remains a residual record to show that it <
was once held by the MCRS. The residual record, which remains with the
MCRS for the life of the system, proves not only that a record was once
active but also, and possibly more importantly, that the record was prop‑
erly disposed of under an appropriate disposal schedule.
The transition from an active entity with complete metadata, entity history
and content to a residual entity is termed ‘destruction’ to distinguish it
from ‘deletion’ (where all trace of an entity is removed). MoReq2010®
also applies this concept to entities other than records, such as aggre‑
gations, classes, disposal schedules, etc. Destruction is an irrevers‑
ible process because parts of the entity are erased so that the entity
cannot be returned to an active state. Figure 8a gives a simple overview •
of the MoReq2010® record life cycle which considers only two events: MoReq2010
the record’s creation in the MCRS as an active entity and its subsequent
destruction.
Note that unlike the generic entity life cycle shown previously in Figure 2g, for Records Systems
with records in particular there is no concept of ‘first use’ and no period
immediately after creation where the record may be deleted. The simple
view shown in Figure 8a will be expanded on later where more detailed
record life cycles show how each disposal action has its own variation of
the record life cycle.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
115
1
Disposal
scheduling
service
MoReq2010.
Creation event Oestruction event
ACTIVE RESIDUAL
Component(s) crealed Component(s) destroyed
Event history starts Event history pruned
Metadata captured Meladata pruned
Time
Figure 8a — Simple view of a record’s life cycle
As Figure 8a shows, when an active record is created its components and

their component content are simultaneously created, metadata is captured
for the record and its components, and the record’s event history begins
with the creation event. When an active record is subsequently destroyed, its
metadata and event history are pruned, along with the metadata and event
histories of its components and, most importantly, the record’s component
content is deleted.
The events and the metadata elements to be automatically pruned on destruc‑
tion of an entity are configurable by an authorised user (see R2.4.20 and
R7.5.6). The remaining metadata of the record, along with their remaining
event history, make up the residual record and its residual components.
Pruning is an important process in ensuring the proper destruction of the
content of records, especially in sensitive environments where these events
and metadata may reveal information about the original content of the record
and may be able to be used to partially (or fully) reconstruct the destroyed
content. For example, the metadata or event history of a hospital record
may include the name of a patient, or a particular incident in that patient’s
• medical history, in perpetuity, in breach of privacy considerations.
MoReq2010 Pruning of events and metadata from a residual record that has previously
been destroyed may also be done by an authorised user, usually in response
to a court order or judgment (see R2.4.21 and R7.5.7). From time to time,
a particular record, including its metadata and events, must be expunged
for Records Systems because a court feels their continued existence is problematic or unjust.
A secondary consideration in pruning metadata and event histories on
destruction is storage capacity, since residual records are retained for the
life of the MCRS.
8.2.2 Disposal schedules and disposal actions

Disposal schedules are critical to managing records because MoReq2010®
specifies that a record in an MCRS may only be destroyed as part of a disposal
process governed by the disposal schedule assigned to that record. It is the
Volume 1 record’s disposal schedule that determines how long a record is retained
and how it is subsequently disposed of at the end of its retention period. For
Core Services
this reason, all records must have a disposal schedule.
& Plug-in Modules
While all disposal schedules must conform to the MoReq2010® disposal
process, they may specify very different behaviours. The disposal schedule
Version 1.1 for one record may state that it is to be retained permanently and must
116
1
Disposal
never be destroyed. A different disposal schedule may state that a record is scheduling
to be destroyed immediately. Yet another disposal schedule may state that a service
record is to be reviewed at the end of its retention period, etc.
Each of these examples results in a different disposal action. MoReq2010®
requires that all disposal schedules must specify one of four different
possible outcomes:
• retain permanently;
• review at the end of the retention period;
• transfer at the end of the retention period;
• destroy at the end of the retention period.
8.2.3 Calculating the retention period

Each disposal schedule will have a retention period defined as a number of
days, weeks, months or years. The retention period begins on a particular
retention start date, which is defined by a retention trigger event. Retention
trigger events can relate to the individual record or to the record’s parent
aggregation.
Organisations that prefer to manage whole aggregations and dispose of
them collectively, should specify aggregation‑related retention triggers for
their disposal schedules. They should also avoid classifying records indi‑
vidually within aggregations. The following retention triggers relate to a
record’s parent aggregation:
• from the aggregation’s originated date;
• from the date of the most recent addition to the aggregation;
• from the date when the aggregation was closed; and
• from a date specified by a contextual metadata element associated
with the aggregation.
By contrast, the following retention triggers relate to individual records.
When these retention triggers are used, records will be selectively disposed
of at different times from within their parent aggregations, while other
records in the same aggregations remain active:
• from the record’s Originated Date/Time;
•
• from the date the record was added to its parent aggregation; and MoReq2010
• from a date specified by a contextual metadata element associated

with the record. Modular Requirements
The following retention triggers can be applied equally to both individual for Records Systems
records or to aggregations:
• retain permanently (there is no retention trigger);
• from now (meaning with immediate effect); and
• from the date of the last review.
The retention start date for a record must be recalculated by the MCRS if the
record’s disposal schedule changes or if the value referred to by the reten‑
tion trigger is updated, for example, whenever:
• a record’s default disposal schedule is replaced through change (see Volume 1
R5.4.4) or reclassifying the record (see R5.4.8, R6.5.4 and R6.5.12);
• a record’s default disposal schedule is replaced by moving it, or its
Core Services
parent, to a new aggregation (see R6.5.8 and R6.5.13); or & Plug-in Modules
• a record’s default disposal schedule is overridden by one directly
applied to the record (see R6.5.15). Version 1.1
117
1
Disposal
scheduling In addition to these schedules, the following are all possible retention trig‑
service gers and changes to them may also result in the recalculation of retention
start dates:
• a record’s Originated Date/Time is changed (see R2.4.26);
• a record’s parent aggregation is closed (see R6.3.7); or
• a contextual metadata element associated with an aggregation is
modified (see R8.4.4).
It should be noted that MoReq2010® views disposal as most likely to be a
scheduled activity and, therefore, it does not require that retention triggers
be checked and retention start dates be recalculated more than once per day.
It is assumed that new batches of records will become due for disposal on a
daily basis and records management routines will be planned around this.
However, under R8.4.14, it is possible for an authorised user to individually
request the immediate update of a record’s disposal status by the MCRS.
It should also be noted that MoReq2010® requires that the Originated Date/
Time for records and aggregations be used for calculating retention start
dates, and not the Created Timestamp, for these entities. This allows inter‑
operability between records systems while retaining continuity over the
record life cycle. Each time a record or aggregation is imported into a new
records system, it will be created again in that system. It will have a different
Created Timestamp reflecting when it was imported into the new MCRS but,
by comparison, the value set in the previous MCRS for the Originated Date/
Time will not be updated when the record or aggregation is imported.
One consequence of this is that the retention start date for a record may
pre‑date the record’s creation event. For example, if a new record is created
in an aggregation and given a disposal schedule with the retention trigger
based on its parent aggregation’s Originated Date/Time, the retention period
for the record will already have effectively commenced before the record is
created. This case is not shown in any of the accompanying illustrations,
such as Figures 8c, 8d or 8e, which, for ease of understanding, show the
retention start date occurring after the record creation date.
8.2.4 Confirming a record’s disposal

In addition to the disposal action, the retention trigger and the retention period,
•
a disposal schedule must also specify a confirmation period. The confirma‑
MoReq2010 tion period represents the allowed period of time for carrying out the disposal
action. The length of the confirmation period will vary from organisation to
organisation and may also vary on different disposal schedules.
Modular Requirements The precise meaning of the confirmation period depends on the disposal
for Records Systems action chosen. For review actions, the confirmation period represents the
time allocated for completing the review and applying the review decision.
For destroy actions, the confirmation period represents the time allocated for
deleting the content of the record and confirming that it has been deleted.
Transfer actions have two confirmation periods. First, the records must be
transferred to their new location outside the management of the MCRS.
This will usually involve exporting the records from the MCRS. On confirma‑
tion that the transfer is complete, the disposal action changes from transfer
to destroy, and the disposal process enters a second confirmation period to
ensure that the content of the record held by the MCRS is destroyed.
Volume 1
If any confirmation period is exceeded without the MCRS receiving the neces‑
Core Services sary confirmation that the disposal action has been completed, the MCRS
& Plug-in Modules raises an alert that is sent to authorised users indicating that the relevant
records are overdue for disposal. This measure is intended to ensure that
records are disposed of in a timely manner in the shortest possible period
Version 1.1 following the disposal due date.
118
1
Disposal
8.2.5 Permanent retention life cycle scheduling
An important aspect of records management is the preservation of impor‑ service
tant records for very long periods of time, including the ability to designate
some records that are never to be discarded. In MoReq2010®, this is done by
applying a disposal schedule with a retention trigger that specifies permanent
retention. This type of disposal schedule, with no retention trigger, has the
effect of preventing the calculation of a retention start date and a subsequent
retention period. The effect of permanent retention is shown in Figure 8b,
which may be contrasted with the simple life cycle illustrated by Figure 8a.
Creation event
MoReq2010.
RETAIN PERMANENTLY
Time ACTIVE
Figure 8b — If its disposal schedule specifies permanent retention, no retention start date
will be set for a record and, without its disposal schedule being changed, it will remain
active for the life of the MCRS
8.2.6 Review life cycle

MoReq2010® encourages disposal to follow, and be determined by, clas‑
sification wherever possible. This means that the period of time a record is
kept and its method of disposal is based on its business classification. This
principle of good management practice with records is sometimes referred
to ‘sentencing on creation’.
There may be some occasions, however, when the importance of a record
and the length of time it should be retained are not known at the time the
•
record is created, and cannot be calculated simply from subsequent events, MoReq2010
such as the closing of the aggregation in which the record is placed. It may
also be that, in some jurisdictions, the retention period is so long that it
is felt that the guidance for their retention may change in the intervening Modular Requirements
period. For example, if it is required that a particular class of record be for Records Systems
destroyed after 40 years, a records manager may argue that there is some
likelihood that in 40 years’ time the 40‑year disposal rule may have been
updated. Under these circumstances, where there is a reasonable doubt
about their final destiny, records can be scheduled for later review, rather
than for permanent retention, transfer or destruction.
When a record’s disposal action is set to review, it is not immediately subject
to transfer or destruction. Instead, the outcome of the review must include
the application of a disposal schedule to the record based on the review
decision. The new disposal schedule will replace the previous disposal
schedule associated with the record and will then specify the ultimate fate Volume 1
of the record, or it may be used to schedule another later review, or to retain
Core Services
the record permanently.
& Plug-in Modules
Figure 8c shows how the completion of a review results in the application of
a new disposal schedule to the record, which will in turn force the calcula‑
tion of a new retention start date, disposal action and confirmation period. Version 1.1
119
1
Disposal
scheduling The disposal process will, therefore, keep going and may even result in
service further review periods. Note that disposal holds do not interrupt the review
process: they only prevent the eventual destruction of a record.
lMoReq20TO.
Oisposal due date {REVIEW)
Retentioo star1
Creatlon event
date (new)
Revlew completed /
Retention slart date
Relention pariod Review \ Rotention period
confinnation� ,___,.___
ACTIVE New dlsposal
D schedule eppl!ed
Figure 8c — If its disposal schedule specifies that a record be reviewed, a new disposal
•
schedule must be applied to the record as part of completing and implementing the review
decision
8.2.7 transfer life cycle

A disposal schedule may state that a record is to be transferred to the control
of another records system, for example a more centralised corporate records
system, a secondary storage facility, or an archive. Transfer occurs in two
phases. The record must firstly be exported from the MCRS and imported
into the other records system. On confirmation that the transfer has taken
place and the destination system has successfully received the record, the
MCRS changes the record’s disposal action from transfer to destruction and
it is subsequently destroyed.
Figure 8d shows the record life cycle as it applies to a transfer disposal
action. The record is not destroyed until the successful transfer has been
• confirmed by an authorised user. Where the record is under a disposal hold,
MoReq2010 the first phase of transfer may continue; however, the disposal process must
be halted prior to the second phase destruction of the record.
for Records Systems
MoR�2010'
Disposal due date (TRANSFER) Oesuuction

.,,.,..,..,.
Creatlon eveni Transfer confirmed
Oisposa1 due (OESTROY)

Retentlon llart date
Retention ¡,6riod Transler Destroction

confitmatioll confirmarion
RESIDUAL
Volume 1 ACTIVE
s¡,osal holds wil
Di
Core Services lnterrupl /he p1oce:ss here
& Plug-in Modules

Figure 8d — If its disposal schedule specifies the transfer of a record then it is destroyed
by the MCRS, but only after the transfer is confirmed as completed
Version 1.1
120
1
Disposal
MoReq2010® allows for transfers to be cancelled. If a transfer is cancelled, scheduling
the record must be given a new disposal schedule; the outcome will there‑ service
fore be similar to the review shown in Figure 8c.
8.2.8 Destruction life cycle

Figure 8e shows the record life cycle as it applies to a disposal action
of destroy. The destruction of records, either in response to a destroy
disposal action, or as the second phase of a transfer, is subject to particular
constraints. If a disposal hold is in place for the record, the MCRS must
mark the record as being held and prevent it from being destroyed. In this
case, the destruction confirmation schedule period must not begin until the
disposal hold has been lifted. More information about disposal holds can be
found in 9. Disposal holding service.
It is important to note that once a disposal process has entered the confir‑
mation period, it is no longer possible for the imposition of a disposal hold
to prevent the destruction of a record. This is because the instruction to
destroy the content is assumed to have already been given and it is only
awaiting confirmation that this has occurred. Once the instruction is issued,
MoReq2010® does not make any provision for a recall and preventing the
destruction of the record is, therefore, outside the control of the MCRS.
MoReq2010.
Crcation event Olsposal due dale (DESTROY) Destruc1ion
complete
Re1en1ion etan date
Retantlon perfod Dosfruction
co11firmatlon
RESIDUAL
ACTIVE
Disposal holds will
lntenvpt the process her&

Time
•
MoReq2010
Figure 8e — If its disposal schedule specifies the destruction of a record, there is usually
a confirmation period following the disposal due date
How records are destroyed in an MCRS will depend on the nature of the for Records Systems
content of their components. This, in turn, may depend on the design and
the purpose of the MCRS. When records are created in the MCRS, their
components will be created with content that the MCRS is either able to
automatically delete or with content that requires confirmation of deletion.
This is determined by the Automatic Deletion Flag included in the metadata
of a component, under R6.5.19.
An MCRS that directly manages its own content repository is more likely
to be capable of automatically deleting the content of components when
records are destroyed. An MCRS that manages records in place, in other
business systems, or records with physical rather than digital content is Volume 1
more likely to require that separate confirmation be received of the destruc‑
Core Services
tion of the content of records scheduled for destruction.
& Plug-in Modules
MoReq2010® does not constrain the architecture of MCRS solutions such
that they must be able to automatically destroy record content. Nor does
MoReq2010® specify that all MCRS solutions must be able to support record Version 1.1
121
1
Disposal
scheduling components that require confirmation. Many MCRS solutions will support
service both types of content or allow different content types to be configurable.
Suppliers may build and support any of these options in their products.
For this reason, the MoReq2010® disposal process specifies that when a
record is due to be destroyed, the MCRS must check its components to deter‑
mine whether they can be automatically destroyed or must be destroyed after
confirmation. The MCRS will then wait for confirmation of the destruction of
the content of any components that cannot be automatically destroyed, before
destroying the remaining components and the record itself.
Note that this approach, where automatic destruction is not specified as an
attribute of the disposal schedule but is, instead, a function of the nature of
the content of the record, as well as the design and implementation of the
MCRS, differs from previous versions of MoReq®.
8.2.9 Bottom-up destruction

Under MoReq2010®, disposal schedules are only ever applied to records:
they are not applied to aggregations. This is different to previous versions
of the specification. Aggregations have classes but do not have disposal
schedules: instead, the destruction of aggregations is managed automati‑
cally by the MCRS using the principle of ‘bottom‑up’ destruction.
Under this principle, individual records in an aggregation may be destroyed
at different times. When this occurs, the destroyed record becomes a
residual record but there is no impact on the other records, whether active
or residual, in the same aggregation. There is also no impact on the aggre‑
gation itself, until the last active record in the aggregation is destroyed.
Bottom‑up destruction means that when the last active record in an aggre‑
gation is destroyed, the aggregation itself will be destroyed automatically
by the MCRS. However, automatic destruction of an aggregation only takes
place when the aggregation is closed. An open aggregation cannot be
destroyed. If the aggregation is already closed at the time of destruction
of the last active record, or later if the aggregation is subsequently closed,
the aggregation will be destroyed automatically, provided no more active
records have been added to it.
It is also worth noting that an aggregation, whether open or closed, cannot
• be automatically destroyed if it has never been used, although an aggrega‑
MoReq2010
tion that has never been used can be deleted instead.
Figure 8f shows how bottom‑up destruction applies to both open and closed
Modular Requirements aggregations when the last record in the aggregation is destroyed.
for Records Systems
MoReq2010.
Volume 1
Core Services
Record Record Record Record Record Record Record Record
& Plug-in Modules Figure 8f — According to the principle of bottom‑up destruction, when the last record in an
aggregation is destroyed, the aggregation will be automatically destroyed, but only when
it has been closed
Version 1.1
122
1
Disposal
Bottom‑up destruction not only affects aggregations that contain records scheduling
but also aggregations that contain other aggregations. A parent aggregation service
will be automatically destroyed by an MCRS when all of its child aggrega‑
tions have been destroyed. The same rule that the parent aggregation must
be closed also applies.
This cumulative effect of the destruction of aggregations cascading upwards
is shown in Figure 8g.
M0Re92010
porenr
aggregatJon Is
flllllj
d
when lost
oggregotion
Aggregation
.-----... •-----. -----i,..,.is destroyed
X
destroy
Aggregation Aggreg;uion Aeeregation
/0s1
record
Record Record Record Record
Figure 8g — A closed aggregation will be automatically destroyed when all of its child
entities, either records or other aggregations, have been destroyed: this may trigger the
destruction of its parent aggregation, etc.
8.2.10 Disposal conflicts

Some specifications for records systems, including previous versions of
MoReq®, allow disposal conflicts to occur where two or more disposal
schedules are applied simultaneously to the same record. The resulting
disposal conflict must then be managed, either by manual user interven‑ •
tion to resolve the ambiguity or by the implementation of an algorithm that MoReq2010
determines which of the conflicting disposal schedules is the more impor‑
tant and should, therefore, take precedence.
MoReq2010® has been deliberately designed to avoid disposal conflicts of for Records Systems
this nature by ensuring that each record has one, and only one, disposal
schedule applied to it at any time. The disposal schedule initially applied to
each record is the default disposal schedule associated with the record’s
class. This default disposal schedule may then be overridden by an author‑
ised user applying a different disposal schedule directly to the record itself.
The new disposal schedule can itself be overridden again and again, provided
the record only ever has a single disposal schedule.
The most common reason why a record’s default disposal schedule will
be overridden is to apply a new disposal schedule as a result of a review
Volume 1
decision.
The following is an example of the life cycle of a record. Core Services
• A record is created with a default disposal schedule inherited from its & Plug-in Modules
class of ‘Review 2 years after aggregation closed’.
• The record’s aggregation is subsequently closed. Version 1.1
123
1
Disposal
scheduling • After two years the record is reviewed and, as a result, a new disposal
service schedule is applied, ‘Review 1 year after last review’.
• One year later, the record is reviewed again and a third disposal sche‑
dule is applied, ‘Destroy in 6 months’.
• Six months later, or three and a half years in total after the record’s
aggregation was closed, the record is destroyed by the MCRS.
In this example, the record is created with a default disposal schedule which
is then overridden twice during the active life of the record. At any point
in time, however, the record will be subject to only one disposal schedule
and will be following only one corresponding disposal process. In this way,
MoReq2010® ensures that an MCRS never has to manage disposal conflicts
or ambiguities.
8.2.11 the disposal process

An MCRS must ensure that the disposal process is carried out regularly for
each of its active records. This may be done in real‑time or it may be done as
a scheduled activity but MoReq2010® specifies that it should take place on
a daily basis so that each day authorised users are able to carry out records
management activities on records due for disposal.
The flowchart in Figure 8h gives a logical view of the disposal process for
each record, showing the various decision points and processing required.
This diagram is intended to visually represent the functional requirements
contained in this section and is considered to be a logical view. It is not opti‑
mised in any way, and it is not intended to be reproduced in code, so long
as MCRS solutions provide the same logical outcomes as described by the
process for the same input data.
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
124
1
Disposal
scheduling
i2 ti !! service
J; ·
•
MoReq2010
Figure 8h — The integrated disposal process illustrating all the disposal choices provided for Records Systems
within MoReq2010®
Volume 1
Core Services
& Plug-in Modules
Version 1.1
125
1
Disposal
scheduling 8.2.12 Disposal scheduling as a service
service MoReq2010® describes disposal scheduling as a service used by an MCRS.
Most MCRS software will have a built‑in disposal scheduling service; however,
it is also possible that, in the future, stand‑alone disposal scheduling serv‑
ices will be created that allow centralised management of an organisation’s
disposal schedules across multiple MCRS solutions. One possible use of
such a service would be for an authority to issue and maintain an industry‑
wide set of disposal schedules in the form of a disposal scheduling service,
available on the Internet, to be used across a particular sector.

R8.4.1 The MCRS must allow an authorised user to create new disposal schedules
• Title (M14.4.104),
• Mandate (M14.4.51),
• Disposal Action Code (M14.4.18),
• Retention Trigger Code (M14.4.94),
• Retention Trigger Element Identifier (M14.4.95, or equivalent),
• Retention Period Interval Code (M14.4.90),
• Retention Period Duration Number (M14.4.89),
• Retention Period Offset Code (M14.4.91),
• Retention Period Offset Month Code (M14.4.92),
• Confirmation Period Interval Code (M14.4.7),
• Confirmation Period Duration Number (M14.4.6), and
•
MoReq2010 • Destroyed Timestamp (M14.4.17).
Each disposal schedule also has:
Modular Requirements • an event history (see 2. System services),
for Records Systems • an access control list (or equivalent, see 4. Model role service),
and may have:
Note that many of the system metadata elements listed refer to codes, inter-
vals, offsets or durations. These may be unfamiliar terms. The purpose of these
disposal controls is explained in detail in 14.4 System metadata element defi‑
nitions and in requirements R8.4.2 through R8.4.7 following.
Depending on the approach taken by the MCRS in implementing 4. Model Role
Volume 1 Service, a MoReq2010® access control list may not be present during system
operation and may only be added to a disposal schedule at export.
Core Services Depending on the approach taken by the MCRS in implementing 7. Model
& Plug-in Modules metadata service, the mechanism by which contextual metadata are added to
disposal schedules may vary.
126
1
Disposal
R8.4.2 The MCRS must allow the Disposal Action Code, under R8.4.1, to be set to scheduling
one of the following values: service
• RETAIN PERMANENTLY,
• REVIEW,
• TRANSFER, or
• DESTROY.
Whenever the Disposal Action Code is set to RETAIN PERMANENTLY, the
MCRS must ensure that none of the following metadata elements are
included in the disposal schedule:
• Retention Trigger Code,
• Retention Trigger Element Identifier,
• Retention Period Interval Code,
• Retention Period Duration Number,
• Retention Period Offset Code,
• Retention Period Offset Month Code,
• Confirmation Period Interval Code, or
• Confirmation Period Duration Number.
Whenever the Disposal Action Code is not set to RETAIN PERMANENTLY, the
MCRS must ensure that at least the following system metadata elements
are also included in the disposal schedule:
• Confirmation Period Interval Code, and
A Disposal Action Code of RETAIN PERMANENTLY is used to ensure that records
are never destroyed. The metadata elements listed are not applicable to records
that are to be retained permanently. •
MoReq2010
Another additional Disposal Action Code, RETAIN ON HOLD, is automatically
applied to records by the MCRS, under R8.4.21, but may not be used in disposal
schedules. Modular Requirements
for Records Systems
R8.4.3 Where it is included in a disposal schedule, under R8.4.2, the MCRS must
allow the Retention Trigger Code, under R8.4.1, to be set to one of the
following values:
• FROM NOW,
• FROM DATE OF LAST REVIEW,
• FROM RECORD ORIGINATED DATE,
• FROM AGGREGATION ORIGINATED DATE,
• FROM DATE ADDED TO AGGREGATION, Volume 1
• FROM DATE OF LAST ADDITION TO AGGREGATION, Core Services
• FROM AGGREGATION CLOSED DATE, & Plug-in Modules
• FROM RECORD METADATA DATE, or
• FROM AGGREGATION METADATA DATE. Version 1.1
127
1
Disposal
scheduling Whenever the Retention Trigger Code is set to FROM RECORD METADATA
service DATE or FROM AGGREGATION METADATA DATE, the MCRS must ensure
that a Retention Trigger Element Identifier is always included in the meta‑
data of the disposal schedule. The Retention Trigger Element Identifier
must not be included in the metadata of the disposal schedule for any other
value of the Retention Trigger Code.
The Retention Trigger Element Identifier indicates which metadata element
associated with the record or with the record’s parent aggregation is to be used
to obtain its Retention Start Date.
A Retention Trigger Code value of FROM NOW is used as a means of initiating the
retention period for a record immediately without waiting for a specific trigger.
Other retention triggers relate to specific metadata elements, specified under
either R6.5.10, for records, or R6.5.1 for aggregations, as follows:
• FROM DATE OF LAST REVIEW uses a record’s Last Reviewed Timestamp;
• FROM RECORD ORIGINATED DATE uses a record’s Originated Date/
Time;
• FROM AGGREGATION ORIGINATED DATE uses the Originated Date/Time
from a record’s parent aggregation;
• FROM DATE ADDED TO AGGREGATION uses a record’s Aggregated
Timestamp;
• FROM DATE OF LAST ADDITION TO AGGREGATION uses the Last Addition
Timestamp from a record’s parent aggregation; and
• FROM AGGREGATION CLOSED DATE uses the Closed Timestamp from a
record’s parent aggregation.
The retention triggers FROM RECORD METADATA DATE and FROM AGGRE-
GATION METADATA DATE use a contextual metadata element associated with
either the record or its aggregation.
metadata service, an equivalent method for identifying the appropriate
•
MoReq2010 system or contextual metadata element to use as the retention trigger may be
substituted.
Modular Requirements However, regardless of whether the model metadata service or an equivalent is
for Records Systems used, the MCRS must ensure that the metadata element indicated always:
• has a Datatype (see R7.5.3) of date, date/time or timestamp;
• has a Max Occurs set to ‘1’ (see R7.5.4), to ensure the metadata element
has only a single unambiguous value;
• is associated with the record or its aggregation (e.g. by inclusion in a
template, or equivalent under R7.5.17 and R7.5.18); and
• may be meaningfully converted and exported as part of a MoReq2010®
compliant disposal schedule regardless of how it is implemented in the
Volume 1 MCRS (see 7.2 Complying with the model metadata service).
Core Services
R8.4.4 The MCRS must not allow a disposal schedule with a Retention Trigger
& Plug-in Modules Code of FROM DATE OF LAST REVIEW, under R8.4.3, to be associated with
a class as the default disposal schedule of the class. Likewise, the MCRS
Version 1.1 must not allow such a disposal schedule to be applied directly to any record
128
1
Disposal
that has not previously been reviewed, except during the confirmation of a scheduling
review decision, under R8.4.16. service
A default disposal schedule is associated with each class, under R5.4.2 and
R5.4.4. This default disposal schedule is inherited and adopted by all records
under R6.5.14, unless it is overridden under R6.5.15.
Retention schedules with a Retention Trigger Code of FROM DATE OF LAST
REVIEW are only applicable when used in conjunction with a current or previous
review of the record. The MCRS must prevent them from being associated with
records that have never been reviewed. For this reason, they may not be associ-
ated with a class because they cannot become the default disposal schedule for
newly created records.
allow the Retention Period Interval Code, under R8.4.1, to be set to one of
the following values:
• NO RETENTION PERIOD,
• DAYS,
• WEEKS,
• MONTHS, or
• YEARS.
Whenever the Retention Period Interval Code is set to NO RETENTION
PERIOD, the MCRS must ensure that none of the following metadata
elements are included in the disposal schedule:
• Retention Period Offset Code, and
• Retention Period Offset Month Code.
Whenever the Retention Period Interval Code is not set to NO RETENTION
PERIOD, the MCRS must ensure that at least the following system metadata
elements are also included in the disposal schedule:
• Retention Period Duration Number, and
•
• Retention Period Offset Code. MoReq2010
If the Retention Period Interval Code is set to NO RETENTION PERIOD, a record’s
Disposal Action Due Date will be set to the same date as the Retention Start
Date. In other words, the retention period is zero days in length and the disposal Modular Requirements
action immediately falls due as soon as the retention period is triggered. for Records Systems
Where the Retention Period Interval Duration is included in the disposal
schedule, it must be a whole number greater than zero. It is then interpreted in
combination with the Retention Period Interval Code as either a number of days,
weeks, months or years. Consequently, the shortest retention period after NO
RETENTION PERIOD is one day.
allow the Retention Period Offset Code, under R8.4.1, to be set to one of the
following values: Volume 1
• NO OFFSET, Core Services
• START OF NEXT MONTH, & Plug-in Modules
• START OF NEXT QUARTER, or
• START OF SPECIFIED MONTH. Version 1.1
129
1
Disposal
scheduling Where the Retention Period Offset Code is set to NO OFFSET or START
service OF NEXT MONTH, the MCRS must ensure that a Retention Period Offset
Month Code is not included in the disposal schedule. Otherwise, if the
Retention Period Offset Code is set to START OF NEXT QUARTER or START
OF SPECIFIED MONTH, the Retention Period Offset Month Code must be
included and must be given a value corresponding to a month of the year.
An offset period of NO OFFSET means that the retention period will end exactly
on the calculated Disposal Action Due Date. An offset period of START OF NEXT
MONTH means that the MCRS should extend the retention period to the end of
the month in which it falls.
An offset period of START OF NEXT QUARTER will extend the retention period to the
end of the quarter of the year in which it falls. For this option, the Retention Period
Offset Month Code is interpreted as referring to the first month of the first quarter
of the year. For example, if the month were set to APRIL then the quarters would
run April to June, July to September, October to December and January to March.
An offset period of START OF SPECIFIED MONTH will extend the retention period
to the end of the month before the start of the retention period offset month.
For example, to extend the retention period to the end of the calendar year in
which it falls, the authorised user would set the Retention Period Offset Month
Code to JANUARY.
allow the Confirmation Period Interval Code, under R8.4.1, to be set to one
of the following values:
• DAYS, or
• WEEKS.
The Confirmation Period Duration Number must also be set to a whole
number greater than zero.
The confirmation period refers to the maximum time allocated to complete the
disposal action nominated under R8.4.2. The shortest possible confirmation
period for a disposal schedule is one day.
If the confirmation period is exceeded, the MCRS will raise an alert under
R8.4.14.
Note that records with a Disposal Action Code of TRANSFER, under R8.4.2,
•
MoReq2010 have two confirmation periods. The first confirmation period covers the transfer
of the records to another records system or location. The second confirmation
period covers the destruction of the records. For simplicity, these two confirma-
Modular Requirements tion periods are calculated using the same values for the Confirmation Period
for Records Systems Interval Code and the Confirmation Period Duration Number. In other words,
both confirmation periods will always be the same length.
R8.4.8 The MCRS must allow an authorised user to modify the following metadata
for any active disposal schedule:
• Title,
• Description,
• Mandate
• Scope Notes, and
Volume 1 • Any contextual metadata elements.
Core Services The mandate describes the authority for the disposal schedule. Different reten-
tion periods and disposal rules for records belonging to particular business
& Plug-in Modules classifications may be mandated by government legislation, industry regula-
tions, national or international standards, etc.
130
1
Disposal
R8.4.9 In addition to R8.4.8, the MCRS must allow an authorised user to modify the scheduling
following metadata for any disposal schedule that has never been applied to service
a record:
• Disposal Action Code,
• Retention Trigger Element Identifier (or equivalent),
• Retention Period Offset Month Code,
• Confirmation Period Interval Code, and
Once a disposal schedule has been used, by applying it to a record, the meta-
data values used to calculate the retention period and disposal process become
fixed and can no longer be changed. Note that these are referred to as ‘disposal
controls’ in the rationale to R8.4.13.
R8.4.10 The MCRS must allow an authorised user to delete a disposal schedule that
has never been applied to a record, provided it is not associated with any
active class as its default disposal schedule.
A disposal schedule can no longer be deleted once it has been used; however, it
can be destroyed under R8.4.11. Before deleting a disposal schedule, it must be
replaced as the default disposal schedule for any active classes it is associated
with (see R5.4.4).
R8.4.11 The MCRS must allow an authorised user to destroy any active disposal
schedule, provided it is not applied to any active records and it is not the
default disposal schedule of any active class.
When a disposal schedule is destroyed, the MCRS retains a residual disposal
schedule. A disposal schedule cannot be destroyed while it is applied as the •
disposal schedule for any active records, but it can be destroyed if the only MoReq2010
records it is associated with are residual records. Before destroying a disposal
schedule, it must be replaced as the default disposal schedule for any active
classes with which it is associated (see R5.4.4): this is because only active Modular Requirements
disposal schedules may be associated with active classes. for Records Systems
R8.4.12 Subject to R2.4.22, the MCRS must allow an authorised user to browse
across the disposal schedules in the disposal scheduling service and inspect
their metadata.
R8.4.13 The MCRS must allow an authorised user to replace an active disposal Volume 1
schedule with another active disposal schedule, for all active records to
Core Services
which it is applied, and for all active classes where it is associated as the
default disposal schedule. & Plug-in Modules
This function allows the authorised user to replace one active disposal schedule
with another, throughout the MCRS. Version 1.1
131
1
Disposal
scheduling Note that, under R8.4.9, the controls in a disposal schedule, such as the deter-
service minants for the length of the retention period, cannot be modified once they
have been applied to records. To change these disposal controls, an authorised
user must create a new disposal schedule defining different disposal controls
and replace the previous disposal schedule where it occurs.
R8.4.14 The MCRS must update the disposal status of any record when requested by
an authorised user and, either immediately or periodically but at least daily,
the MCRS must update the disposal status of all active records.
The disposal status of all records must be updated in real time or as a sched-
uled activity at least once a day. The MCRS must also be able to update the
disposal status of individual records on request.
Updating the disposal status of an active record includes:
• checking whether the disposal schedule for the record has changed (see
R6.5.14 and R6.5.15) and, if so, clearing the previous disposal metadata;
• checking whether the value of the retention trigger metadata element
defined by the disposal schedule has changed and if the retention trigger
conditions have been met (see R8.4.3);
• calculating and setting the Retention Start Date, Disposal Action Code,
Disposal Action Due Date and Disposal Confirmation Due Date for a record
based on the disposal controls in its disposal schedule;
• checking if there is a disposal hold in place for the record and, where
necessary, generating events and applying the Disposal Action Code
RETAIN ON HOLD to the record (see R8.4.21);
• checking whether the disposal action has been cancelled (see R8.4.18) or
confirmed (see R8.4.17, R8.4.19 and R8.4.20);
• raising a disposal overdue alert where the disposal action has not been
confirmed by the Disposal Confirmation Due Date (see R8.4.15);
• • implementing the results of a review, including applying a new disposal
MoReq2010 schedule to the record (see R8.4.17);
• changing the Disposal Action Code to DESTROY once a transfer has been
Modular Requirements confirmed (see R8.4.19);
for Records Systems
• destroying the content of records for components where the MCRS is able
to do so (see R8.4.20);
• destroying records and their components by pruning their metadata and
event histories to leave a residual entity (see R8.4.20); and
• destroying closed parent aggregations once their last child has been
destroyed (see R8.4.22 and R8.4.23).
See the disposal process flowchart, Figure 8h, Section 8.2.11 The disposal
process, for further explanation.
Volume 1
Note that while MoReq2010® does specify what an MCRS must do to be compliant
Core Services with the specification, it does not specify how the MCRS should implement this
& Plug-in Modules functionality or whether it should be done in real time or as a scheduled process.
The level of specificity given here is necessary to support interoperability.
132
1
Disposal
R8.4.15 The MCRS must alert all users authorised to receive alerts for an aggrega‑ scheduling
tion or record whenever the Disposal Confirmation Due Date has elapsed service
without the disposal action being carried out and confirmed.
service, the mechanism by which users are authorised to receive alerts will
vary. When the model role service is implemented, receiving alerts can be
allocated to a role, like any other function. Users are, therefore, authorised to
receive alerts when they are allocated to that role via an access control list.
For example, a particular organisation defines a new role called ‘local records
officer’ (LRO). The function receive alerts is included in the LRO role. A user is
then granted an LRO role for a particular aggregation. This user will now be
sent alerts by the MCRS for any records that belong to that aggregation when
confirmation is overdue.
MoReq2010® does not specify what alert mechanism must be implemented by
an MCRS. Many different technologies are available and may be supported. As
a rule of thumb, an alert mechanism must be proactive and traceable to show
that alerts have been sent and received.
Acceptable mechanisms for raising alerts may include:
• e-mail;
• push notification, for example SMS messaging;
• publication as an RSS/Atom feed;
• via a subscription service, for example http://twitter.com/
Mechanisms that are not acceptable without additional supporting infrastruc-
ture include:
• writing alerts to an error log (this is not proactive in distributing the alert
to authorised users); and
• instant messaging (instant messaging does not leave an easily traceable
conversation to show that the message was sent and received).
When an alert is sent, the MCRS must add a Disposal Overdue Alert Timestamp
to the record. This ensures, among other things, that alerts do not continue to
be sent for the same records.
Depending on how the MCRS implements the disposal process, under R8.4.14,
•
the MCRS may consolidate the alerts for multiple overdue records into a single MoReq2010
alert to each authorised user if they are due to be raised at the same time.
MoReq2010® does not specify how different alerts should be consolidated.
Function reference: F14.5.125 Modular Requirements
for Records Systems
R8.4.16 The MCRS must allow an authorised user to browse and inspect all active
records that are due for disposal and to order and group them variously by:
• Class,
• Aggregation, including both parent and higher level aggregations,
• Disposal schedule,
• Disposal Action Code,
• Disposal Action Due Date, and
• Disposal Confirmation Due Date. Volume 1
The MCRS must allow an authorised user to perform this function without Core Services
having to construct individual search queries under 12. Searching and reporting & Plug-in Modules
service and in such a way that it facilitates the cancellation or confirmation of
disposal actions simultaneously for groups of records, under R8.4.17, R8.4.18,
R8.4.19 and R8.4.19. Version 1.1
133
1
Disposal
scheduling Note that the MCRS must not allow any user to browse or inspect entities
service through this requirement that the user is not normally able to inspect, or to find
records due for destruction but subject to a disposal hold (see R8.4.21).
R8.4.17 The MCRS must allow an authorised user to complete a review for any
record or records with a Disposal Action Code of REVIEW that have reached
their Disposal Action Due Date, by applying a new disposal schedule and
providing a review comment describing the outcome of the review of:
• a single record due for review, individually;
• any nominated set of records that are all due for review;
• all records due for review under a nominated disposal schedule;
• all records due for review within a nominated aggregation, including
both parent and higher level aggregations; or
• all records due for review within a nominated class.
The review comment must be stored as the Event Comment in the corresponding
event generated for the review. The MCRS must also apply a Last Review
Comment and a Last Reviewed Timestamp to each record (see R6.5.10).
The ability to review records within nominated aggregations and classes is to
ensure that records may be reviewed in context and the authorised user is able
to unambiguously apply the same outcome simultaneously to the whole of the
aggregation or class.
R8.4.18 The MCRS must allow an authorised user to cancel the transfer of any
record or records with a Disposal Action Code of TRANSFER that have
reached their Disposal Action Due Date, or to cancel the destruction of
any record or records with a Disposal Action Code of DESTROY that require
confirmation, for:
• a single record due for transfer or destruction, individually;
• any nominated group of records that are all due for transfer;
•
MoReq2010 • any nominated group of records that are all due for destruction;
• all records due for transfer under a nominated disposal schedule;
Modular Requirements • all records due for destruction under a nominated disposal schedule;
for Records Systems • all records due for transfer within a nominated aggregation, including
both parent and higher level aggregations;
• all records due for destruction within a nominated aggregation, inclu‑
ding both parent and higher level aggregations;
• all records due for transfer within a nominated class; or
• all records due for destruction within a nominated class.
The MCRS must allow transfers or destruction requiring confirmation to be
cancelled at any time after the Disposal Action Due Date and prior to the
Volume 1 confirmation of these actions under R8.4.19 and R8.4.20.
To cancel the transfer or destruction, the authorised user must apply a new
Core Services disposal schedule and provide a mandatory cancellation comment, similar to a
& Plug-in Modules review in R8.4.17. The MCRS must not proceed with the previous disposal action
and the new disposal schedule must take effect immediately.
Version 1.1 Function references: F14.5.116, F14.5.117
134
1
Disposal
R8.4.19 The MCRS must allow an authorised user to confirm that a transfer has been scheduling
completed for any record or records with a disposal action of TRANSFER service
that have reached their disposal due date, for:
• a single record due for transfer, individually;
• any nominated group of records that are all due for transfer;
• all records due for transfer under a nominated disposal schedule;
• all records due for transfer within a nominated aggregation, including
both parent and higher level aggregations; or
• all records due for transfer within a nominated class.
In response to confirmation that a transfer has been completed, the MCRS must
set the Transferred Timestamp for a record, change its Disposal Action Code to
DESTROY, set the record’s Disposal Action Due Date to the date of confirmation,
clear the record’s Disposal Overdue Alert Timestamp (if set) and calculate a new
Disposal Confirmation Due Date. Note that the disposal schedule for the record
is not changed.
The ability to confirm the transfer of records by their nominated aggregations
and classes is to ensure that the confirmation can be made more easily and in
the context where whole aggregations and classes have been exported to effect
the transfer.
R8.4.20 Subject to R8.4.21, whenever an active record has a disposal action of

DESTROY and reaches its due date, under R8.4.14, the MCRS must check
whether all of its components are to be automatically deleted. If one or
more components are not marked to be automatically deleted, the MCRS
must set a confirmation period and allow an authorised user to confirm that
destruction has been completed. The MCRS must allow the authorised user
to confirm the deletion of components for:
• a single record due for destruction, individually;
• any nominated group of records that are all due for destruction;
• all records due for destruction under a nominated disposal schedule;
• all records due for destruction within a nominated aggregation, inclu‑
ding both parent and higher level aggregations; or
•
• all records due for destruction within a nominated class. MoReq2010
If the MCRS is able to automatically delete all of the content of the components
of a record, or on confirmation of the deletion of all of the components of the
record, the MCRS must ensure that it destroys the active record and its compo‑ Modular Requirements
nents, in their entirety, leaving a residual record with residual components. for Records Systems
Destroying the record includes pruning metadata elements and their values
from the metadata of the record and its components, pruning events from the
event history of the record and its components, and deleting the content of the
record’s components where the MCRS is responsible for doing this.
The ability to confirm the destruction of records within their nominated aggre-
gations and classes is to ensure that destruction can be carried out in context.
Function references: F14.5.41, F14.5.119, F14.5.124
R8.4.21 As part of the disposal process, under R8.4.14, the MCRS must determine Volume 1
if a disposal hold applies to any active record with a Disposal Action Code
of DESTROY that has not yet reached its Disposal Action Due Date. Where Core Services
this occurs, the MCRS must change the record’s Disposal Action Code to & Plug-in Modules
RETAIN ON HOLD and delete its Disposal Action Due Date and Disposal
Confirmation Due Date, until the record is no longer subject to any disposal
holds, or its disposal schedule is replaced. Version 1.1
135
1
Disposal
scheduling In accordance with R9.4.4, the MCRS must never allow the destruction of any
service record, under R8.4.20, that is subject to an active disposal hold. Furthermore, the
MCRS must never indicate that any record is due for destruction if it is subject to
an active disposal hold, for example, by including it in the results of R8.4.16.
Where the disposal action has already become due before the disposal hold was
applied and is awaiting confirmation, the MCRS must allow it to be confirmed.
Note that disposal holds prevent the destruction of a record, including its
destruction following a successful transfer, but do not prevent authorised users
from reviewing the record or completing the transfer of the record to another
records system prior to destroying it.
Whenever the MCRS changes a record’s Disposal Action Code to RETAIN ON
HOLD, or when all disposal holds are lifted from the record, as specified by
this requirement, the MCRS must generate appropriate events (see F14.5.128
Record — Held and F14.5.139 Record — Released).
For more information on disposal holds see the key concepts in 9. Disposal
holding service.
R8.4.22 Following the destruction of records, under R8.4.20, the MCRS must auto‑
matically destroy any aggregations that no longer contain any active records,
provided they are closed.
Open aggregations are not destroyed until they are closed, under R6.5.6.
Aggregations may be closed as part of confirming the destruction of the records
they contain, under R8.4.23.
Note that the destruction of aggregations under this requirement cascades
upwards so that any parent aggregation containing child aggregations will be
destroyed when its last remaining active child aggregation is destroyed, provided
the parent aggregation is not open.
R8.4.23 Whenever an authorised user confirms the destruction of records due for
destruction within a nominated aggregation or aggregations, under R8.4.20,
the MCRS must allow the user to close the aggregation, including all of its
descendant aggregations, as part of the same operation.
•
MoReq2010 Closing an aggregation ensures that the aggregation itself will be destroyed,
under R8.4.22, if it no longer contains any active records. Under this require-
ment, a user authorised to close an aggregation (see R6.5.6) may choose to
Modular Requirements close it while confirming the destruction of records in that aggregation so
for Records Systems ensuring the simultaneous destruction of the aggregation under R8.4.22.
R8.4.24 The MCRS must not allow any change to the disposal schedule applied to a
residual record.
Disposal schedules may be applied individually to active records or are inher-
ited from their classification. However, once a record has been destroyed, the
MCRS must then preserve its relationship to the specific disposal schedule
under which it was destroyed and no longer allow that disposal schedule to be
Volume 1 replaced by another.
It is essential for maintaining trust in the integrity of the MCRS that an auditor,
Core Services
at a later date, can, with confidence, confirm when a record was destroyed, the
& Plug-in Modules disposal rules and controls that were applied at the time, and all other relevant
contextual metadata surrounding its disposal.
136
1
9
Disposal holding service

Service name Disposal holding service
Service version 1.0
Implements Service 2e4a8618‑c4b3‑470f‑8ccb‑03e2d5e07026

q
8
9.2 kEy CoNCEPtS

i;.444 Q4
•
1 81
9.2.1 Imposing disposal holds �,d.2 .a. Jl.1.

,,
4 J7 bd22
Disposal holds are an important and necessary part of modern records ' ., o
management. A disposal hold is a legal or other administrative order that
l '
'
o¡
interrupts the normal disposal process and prevents the destruction of < 4 6 134
,,
some of an organisation’s records while the disposal hold is in place. J O 38 b 04 • 24
84 76
Under MoReq2010®, a disposal hold is created within an MCRS, as part of <
•
"
4 4
• •
7 ea 2
a disposal holding service, and the active disposal hold is then associated <
with entities such as records, aggregations and classes.
Where the disposal hold is associated with an individual record, it prevents
the destruction of that record while the disposal hold remains active. Once
the disposal hold is destroyed, the record’s disposal process continues.
Where the disposal hold is associated with an aggregation as a whole, it prevents
any record in the aggregation, or that is a descendant of the aggregation, from
being destroyed. This applies equally to new records that are added to the
aggregation after the hold has already been associated with the aggregation.
However, records that are moved out of the held aggregation will not remain
subject to the disposal hold, unless it is also applied to them individually.
Where the disposal hold is associated with a class, it prevents any record •
classified by that class from being destroyed. The disposal hold does not MoReq2010
prevent a held record from being reclassified to a different class that is not
subject to the disposal hold.
9.2.2 Impact of disposal holds for Records Systems
The impact of a disposal hold on the disposal scheduling service is described

in detail in 8. Disposal scheduling service. A disposal hold will prevent the
destruction of a record by halting the disposal process at the point immedi‑
ately before it is destroyed. Disposal holds do not prevent review decisions,
changes in a record’s disposal schedule, or the ability to transfer a record
right up to the point when the record is destroyed by the MCRS.
A record or aggregation may be subject to more than one disposal hold
simultaneously. All associated disposal holds must be lifted before the
record or aggregation can be destroyed. Volume 1
9.2.3 lifting disposal holds

Core Services
& Plug-in Modules
A disposal hold will remain in place, blocking the destruction of any records
and aggregations it is associated with, until it is destroyed. This is some‑
times described as ‘lifting’ the disposal hold. Version 1.1
137
1
Disposal
holding service An authorised user can also disassociate held records, aggregations and
classes from a disposal hold. However, this operation is intended only to
correct associations between these entities, disposal holds that have been
applied by mistake or where the parties to a dispute agree to narrow the
scope of the disposal hold. The usual process for lifting the disposal hold
from the entities that it affects is by destroying the disposal hold. Where
this occurs, it is not necessary to individually disassociate entities from the
disposal hold when it is lifted: indeed, the continued association will provide
useful historical information.
Once lifted, the disposal hold is destroyed and becomes a residual disposal
hold: it is not possible to reverse this process. If the disposal hold is lifted
in error, a new disposal hold must be created and the new disposal hold
must then be associated with the same entities that were previously associ‑
ated with the residual disposal hold. Note that until this occurs, any records
previously held by the old disposal schedule will not be prevented from being
destroyed through the disposal process.
9.2.4 Disposal holding service

Disposal holds are usually institution‑wide in their scope and often carry
legal and financial penalties and liability. They may be relevant to informa‑
tion stored in several different business systems within an organisation.
The service‑based architecture of MoReq2010® permits the implementation
of a centralised disposal holding service shared by several records systems
in an organisation, thus allowing disposal holds to be created, managed
and lifted centrally, while being simultaneously applied across multiple
MoReq2010® compliant systems.

R9.4.1 The MCRS must allow an authorised user to create active disposal holds
•
MoReq2010 • Originated Date/Time (M14.4.61),
Modular Requirements • Held Record Identifier (M14.4.39),
for Records Systems • Held Aggregation Identifier (M14.4.37),
• Held Class Identifier (M14.4.38),
• Title (M14.4.104),
• Mandate (M14.4.51),
• Scope Notes (M14.4.97), and
Volume 1 Each disposal hold also has:
Core Services • an event history (see 2. System services),

& Plug-in Modules • an access control list (or equivalent, see 4. Model role service),
and may have:
Version 1.1 • contextual metadata (or equivalent, see 7. Model metadata service).
138
1
Disposal
The Originated Date/Time may be used to record the date on which the legal or holding service
administrative order was issued, rather than the timestamp that marks when
the disposal hold was created in the MCRS (see R2.4.26).
operation and may only be added to a disposal hold at export.
data service, the mechanism by which contextual metadata is added to disposal
holds may vary.
R9.4.2 The MCRS must allow an authorised user to change the metadata of an
active disposal hold, including its Title, Description, Mandate, Scope Notes
and any contextual metadata.
Disposal holds usually represent a legal or an administrative order. The Mandate
describes the authority and jurisdiction under which the disposal hold operates.
The Scope Notes provide additional information to users on how the disposal
hold should be interpreted and applied.
R9.4.3 The MCRS must allow an authorised user to associate and disassociate an
active disposal hold with active records, aggregations and classes.
For example, it should be possible to search for records, aggregations and
classes that fall under the scope of the legal or administrative order repre-
sented by the disposal hold, and associate the disposal hold with the entities in
the search results.
Disassociating a disposal hold from a record, aggregation or class is intended
only for those occasions when records, aggregations and classes have been
added to the disposal hold by mistake. Records, aggregations and classes that
have been properly included in the disposal hold will be released for destruc-
tion when the disposal hold is lifted under R9.4.6, and should not be individually
disassociated from the disposal hold.
•
MoReq2010
R9.4.4 The MCRS must prevent the destruction of any record, under R8.4.21, that:
• is directly associated with the disposal hold; Modular Requirements
• is a child or descendent of any aggregation that is associated with the for Records Systems
disposal hold; or
• has been classified with a class that is associated with the disposal
hold.
See 8. Disposal scheduling service for further details of how disposal holds
interrupt the disposal process and prevent the destruction of aggregations and
records.
R9.4.5 The MCRS must allow an authorised user to delete a disposal hold provided
it has never been associated with any records, aggregations or classes. Volume 1
Once a disposal hold has been used, it becomes important to the history of
Core Services
those records, aggregations and classes that is has been associated with and
can no longer be deleted from the MCRS. However, the disposal hold can be & Plug-in Modules
destroyed under R9.4.6.
139
1
Disposal
holding service R9.4.6 The MCRS must allow an authorised user to lift a disposal hold by destroying
it, thereby allowing the destruction of any records directly or indirectly
subject to the disposal hold.
When a disposal hold is lifted, any records subject to the disposal hold will
resume the disposal process described in 8. Disposal scheduling service and
may be destroyed, provided they are not subject to any other disposal holds.
Note that, under R9.4.4, records can be held under a disposal hold in a number
of ways. The disposal hold may be directly associated with them, or they may be
part of an aggregation that the disposal hold is associated with, or the disposal
hold may be associated with the record’s class. As a consequence, it is possible
that records that are disassociated from a disposal hold may still be subject to
the disposal hold by another means, for example because their parent aggrega-
tion or their class remains associated with the disposal hold.
When records are no longer associated with a disposal hold, they resume the
disposal process described in 8. Disposal scheduling service and may be
destroyed, provided they are not subject to any other disposal holds.
R9.4.7 Subject to R2.4.22, the MCRS must allow an authorised user to browse the
disposal holds in the disposal holding service, and associated entities in
other services, and inspect their metadata in the following ways:
• browse across all the disposal holds in the disposal holding service
and inspect their metadata; and
• browse from a disposal hold to any associated records, aggregations
or classes and inspect their metadata.
Function references: F14.5.12, F14.5.30, F14.5.63, F14.5.131
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
140
1
10
Searching and reporting service

Service name Searching and reporting service
Service version 1.0
Implements Service f09984a5‑dd31‑44d8‑9607‑22521667c78a

q
8
•
10.2 kEy CoNCEPtS
i;.444, Q4
1 81
10.2.1 Discovery �,d.2 .a. Jl.1.
4., l'i,
bd22
There are two methods by which users can discover entities in an MCRS: ' ., o
a user may browse from one entity to its related entities (e.g. from parent
l '
'
0 ¡ 6 714
entities to their children, from aggregations to their classes, from users to
¿ 4
their groups, from records to their components) or, alternatively, a user may '4 J O 38 04 • 24
•
search for entities that match a particular search query. 84 4 8 76
¿ "
• 4 4 7 ea 2
Experience shows that searching is a far more scalable option for discovery
in records systems with large numbers of entities. In some records systems,
it is also possible to find entities by searching that a user may not be able
to access by browsing because of access control settings. This occurs, for
example, when a user is able to inspect a child entity but not its parent.
In this case, the inaccessible parent may block the ability of the user to
discover the child entity by browsing.
Often, users will combine both methods: first by searching for those enti‑
ties that meet their general search criteria and then refining those search
results by further browsing once the number of entities in the results is
reduced to a manageable number.
MoReq2010® requires that all records systems must have a search engine •
for finding entities based on the values in their metadata elements. The MoReq2010
core requirements do not specify that an MCRS must provide users with the
ability to search within the content of records; however, many suppliers will
provide this capability for certain types of record content. Modular Requirements
An important non‑functional requirement for searching an MCRS is consist‑ for Records Systems
ency and completeness of results. This is particularly important in a records
management environment. If the same user performs the same search
multiple times, assuming no changes to its underlying data, the MCRS
should reliably provide the same set of search results back to the user in
the same order.
10.2.2 Methods of searching

MoReq2010® does not specify how suppliers should implement searching
in their MCRS solutions; however, the specification does require a minimum Volume 1
level of support for various methods of searching and the MCRS must:
Core Services
• be able to search for any entity type by any of its system or contextual
metadata, including events; & Plug-in Modules
• be able to define search criteria to match the datatype of any metadata
element definition, including both system and contextual metadata; Version 1.1
141
1
Searching
and reporting • be able to support full‑text searching using the same search term, entered
service once, across all textual metadata elements simultaneously;
• be able to search on a combination of separate search criteria for nomi‑
nated metadata elements; and
• be able to combine the results of searches together to perform complex
searches.
10.2.3 Searching text
MoReq2010® makes a distinction between two types of text‑based meta‑

data element. ‘Textual’ metadata elements are those which are intended to
hold informative or explanatory text expressed as natural language, such as
Title, Description and Comment. Under R2.4.28, textual metadata elements
must always be accompanied by a language identifier.
Other metadata elements may be text‑based but are not intended to hold
words or sentences in the context of a particular language. They may instead
hold identifiers, or codes, etc.
MoReq2010® requires that textual metadata elements be able to be searched
by full‑text searching. Full‑text searching means searching by whole words,
rather than by a sequence of characters within the value of the metadata
element. Using a modern Internet search engine such as Google is an
example of full‑text searching.
Full‑text searching techniques can be very complex, for example finding the
word based on alternative spellings, different tenses, or a variety of suffixes
and prefixes based on the known language of the text. MoReq2010® does
not specify the level of sophistication required for full‑text searching, but
it does require that the language of the metadata element be stored with
its contents, to enable these types of techniques to be applied by a suitably
equipped search engine.
The MCRS must also provide the means to search on metadata elements
•
MoReq2010 that are not textual. These may be text‑based or they may be numbers,
timestamps, references to other entities, etc.
10.2.4 Search results
for Records Systems
Users search an MCRS in order to find entities that match their search
query. Search results are, therefore, always expressed as a list of entities.
MoReq2010® specifies that search results be user‑configurable so that the
user may specify how the entities in the list of search results are ordered
and which of the metadata elements belonging to the entities in the list are
returned.
Although MoReq2010® does not specify any particular layout for search
Volume 1 results they can be logically conceptualised as adhering to a tabular format
where each entity occupies a row of the table and the columns represent
Core Services the values of the different metadata elements belonging to each entity.
& Plug-in Modules This conceptual layout is shown in Figure 10a, but it must be reiterated
that MoReq2010® does not specify that this layout be used by an MCRS for
Version 1.1 presenting search results back to the user.
142
1
Searching
and reporting
service
Metadata elemenu MoReq2O10"
Entitles
�----
ldcntiflcr Crcated TitJc 0cscription lnactivc
637a9Sc9- 2005-09-
827bbf02-
93557a51- 2006-07-1 2010•07-3
8c6c8157• 2009-12- see atse
alc7cb06-
c92bfcad- 2010-01-
Figure 10a — However they are presented, a set of search results may be conceptually
pictured as a list of entities and their selected metadata in a user‑defined order
When searching an MCRS, the total count of search results that match the
original query may be a high number, thus MoReq2010® specifies that an
MCRS must provide pagination, or other division, of large sets of search
results, so that the user is presented with only a subset of the total results
at a time, and can then request each subsequent page of results from the
MCRS in turn.
10.2.5 Security
The results returned by searches will be user‑specific and related to the
user’s access control settings. Users that search an MCRS will only ever
find entities that they have been granted access to inspect. MoReq2010®
does not permit an MCRS to provide search results that include entities that •
a user has not been granted access to inspect. MoReq2010
From time to time, it may happen that a user, searching and browsing an
entity to which they have full access, inspects the entity and finds that there Modular Requirements
is an identifier to another entity to which the user does not have the right of
for Records Systems
access. This could be a parent, child, or any other related entity, such as a
disposal hold associated with a record. Where this occurs, the MCRS must
prevent the user from accessing the second entity, or any of its metadata, by
browsing to it, searching for it or inspecting it.
Where possible, the entity should simply not appear in search results or
browsing lists. Where the inaccessible entity would normally appear, say,
in a column of a table of metadata such as that shown in Figure 10a, or in
the metadata of an entity under inspection, the MCRS must anonymise its
presence by leaving a blank space or replacing its title with a suitable token
such as ‘Unknown entity’. Volume 1
10.2.6 Saved searches Core Services

& Plug-in Modules
Users are able to save their search queries so that they may reuse them later.
This enables a user to run the same search again, or to use the previous
search criteria as the starting point for building a new set of search criteria. Version 1.1
143
1
Searching
and reporting A saved search is not regarded by MoReq2010® as a managed entity: it is
service specific to a particular MCRS. There is no entity type definition or list of
metadata elements associated with a saved search and no requirement that
a saved search be exported or transferred to another records system.
10.2.7 Reports
MoReq2010® requires that an MCRS support two different types of report:
detailed reports and summary reports. Both types of report are related to
searching, as described previously.
Detailed reports imitate normal searches and are based around a single
search query returning a subset of the metadata for each entity in the results.
Detailed reports will usually adopt a tabular layout, similar to Figure 10a.
Detailed reports differ from searches by delivering all results together as a
single document in a common report format, although MoReq2010® does
not specify the format the report should be in.
By comparison, summary reports are based on multiple search queries:
they do not return the set of results for each search query but rather the
total number of entities found that meet each search query. As with detailed
reports, MoReq2010® does not specify any particular report format for
summary reports.
10.2.8 Saved reports

Like saved searches, report definitions, once constructed, can also be
saved so that they may be rerun at a later date or used as the basis for
constructing a subsequent report. Also, like saved searches, saved reports
are not required to conform to an entity type definition or be transferrable to
other records systems.

R10.4.1 The MCRS must allow users to find, using a search query, any entities that
they have been granted authorisation to browse or inspect.
•
MoReq2010 To find entities by searching, a user constructs a search query. The MCRS then
finds the entities that match that query, provided they are also entities that the
user is authorised to inspect (see 4. Model role service). The list of all entities
Modular Requirements that match the search query comprises the set of search results.
for Records Systems
MoReq2010® does not specify any particular format for search queries; they may
be scripted, such as SQL statements, or visual, such as query by form, etc.
R10.4.2 The MCRS must allow users to restrict the results of searching, under
R10.4.1, to entities of a particular entity type or types.
For example, a user might search only among events or only for users, groups
and roles that match the search query.
Volume 1
R10.4.3 The MCRS must allow a user to specify a search query, under R10.4.1, that
Core Services comprises a single full‑text search carried out across all textual metadata
& Plug-in Modules elements.
Full-text searching involves searching for one or more whole words or phrases.
Version 1.1 All textual metadata elements must be included in a full-text search.
144
1
Searching
R10.4.4 When performing full‑text searching, under R10.4.3, the MCRS must calcu‑ and reporting
late a relevancy score for each entity found. service
The relevancy score should rank the search results along a continuum of best fit
to worst fit against the search query. MoReq2010® does not specify the algorithm
to be used by the MCRS’ search engine for calculating the relevancy score.
R10.4.5 The MCRS must allow a user to specify a search query, under R10.4.1, that
consists of one or a combination of search criteria, where each search crite‑
rion compares a particular system or contextual metadata element against
a value provided by the user.
For example, a user may search for group entities, based on the value of their
Title.
R10.4.6 The MCRS must allow a user to specify a search criterion, under R10.4.5,
that returns a match for any value of the specified metadata element.
For example, a user must be able to find only closed aggregations based on
search criteria that specify that the Closed Timestamp exists and has a value
or, conversely, find only open aggregations by searching for aggregations where
the Closed Timestamp does not have a value.
that returns a match for textual metadata based on full‑text searching.
This is similar to R10.4.3 except that this requirement narrows the full-text
search to a single specified textual metadata element rather than across all
textual metadata elements simultaneously.
that returns a match for date, date/time and timestamp metadata based on
any of the following:
• values occurring before a particular date, date/time or timestamp;
• values occurring after a particular date, date/time or timestamp;
• values occurring on a particular date;
• values occurring today;
•
• values occurring yesterday; MoReq2010
• values occurring tomorrow;
• values occurring this week;
• values occurring last week;
for Records Systems
• values occurring next week;
• values occurring this calendar month;
• values occurring last calendar month;
• values occurring next calendar month;
• values occurring this organisational quarter;
• values occurring last organisational quarter;
• values occurring next organisational quarter;
• values occurring this organisational year;
Volume 1
• values occurring last organisational year;
• values occurring next organisational year; Core Services
• values occurring this calendar year; & Plug-in Modules
• values occurring last calendar year; or
• values occurring next calendar year. Version 1.1
145
1
Searching
and reporting See the example in the rationale to R10.4.5 — being able to define a date/time
service range in a relative sense, such as ‘this calendar month’ is particularly important
for saved searches and reporting.
R10.4.9 The MCRS must allow an authorised user to set, for the searching and
reporting service, the first day of the week and the first month of the first
quarter of the organisational year.
These values are required when searching under R10.4.8 to determine criteria
such as ‘last week’, ‘this organisational quarter’ and ‘next organisational year’.
For many organisations, the organisational year does not match the calendar
year running from January to December. An organisational year may, for
example, run from April to March.
R10.4.10 When searching using timestamp‑based criteria under R10.4.8, the MCRS
must be able to factor in the user’s local time zone to accurately find meta‑
data values that fall into the specified period or on the specified day.
For example, the following may all represent exactly the same time during the
northern hemisphere summer months:
• 0030, Wednesday, Central European Summer Time (UTC + 0300);
• 0130, Wednesday, Eastern European Summer Time (UTC + 0200);
• 2330, Tuesday, Western European Summer Time (UTC + 0100);and
• 2230, Tuesday, Universal Coordinated Time (UTC).
Note that this requirement applies only to timestamps (which include time zone
information) and does not apply to date and date/time-metadata elements.
For example, it would not be appropriate to factor in a relative time zone differ-
ence when searching for a personnel aggregation using the employee’s date of
birth as a criterion.
for numeric metadata that matches the user provided value based on any of
the following:
•
MoReq2010 • equality,
• greater than, or
Modular Requirements • less than.

for Records Systems Note that by combining search criteria, under R10.4.15, it is possible to achieve
further numeric comparisons than just those listed — for example, ‘greater
than OR equal to’, ‘less than OR equal to’, ‘greater than [min] AND less than
[max]’, etc.
for Boolean metadata flags that check whether the value of the element is
true (set) or false (cleared).
Boolean metadata elements are referred to as flags in MoReq2010®.
Volume 1
Core Services for metadata elements that contain System Identifiers, based on a match
& Plug-in Modules with the user‑provided entity.
For example, find all the entities that have been classified under a specified
Version 1.1 class.
146
1
Searching
R10.4.14 The MCRS must allow a user to specify a search criterion, under R10.4.5, and reporting
for records, aggregations and components that are descendants of any service
aggregation.
Descendants do not have to be the immediate children of the aggregation.
R10.4.15 The MCRS must allow users to combine different search criteria, under
R10.4.5, using the Boolean operators AND, OR and NOT in any combination,
and to change the order of precedence by which search criteria are evalu‑
ated by using parentheses or an equivalent method.
These operators come from Boolean algebra: AND refers to the intersection of
two sets, OR to the union of two sets and NOT to the complement of a set. Under
the conventions of Boolean logic, NOT has the highest precedence, followed
by AND, with OR having the lowest precedence. Parentheses can be used to
change the precedence of operators (operations inside parentheses are always
performed first).
Note that MoReq2010® does not specify that the MCRS must explicitly use the
terms ‘AND’, ‘OR’ and ‘NOT’, nor must it explicitly use parentheses to change
the order of operations. Instead, the MCRS may use any logically equivalent
means of representing the same operators and concepts.
R10.4.16 The MCRS must allow a user to combine, chain, or join the results of several
search queries so as to answer complex search enquiries.
MoReq2010® does not specify how different sets of search results should be
combined by an MCRS to provide a complex search capability. This may, for
example, be by the equivalent of an SQL join between two database tables or it
may be by using a different technique.
The following are typical examples of the types of complex search results that
users will expect an MCRS to provide.
• Find all the open aggregations that do not contain any active records.
• Construct an ‘activity history’ for an aggregation by finding and combi-
ning together all events for the aggregation and for each of its descendant
entities.
•
• Find all the aggregations or all the records that have a particular class, MoReq2010
regardless of whether they inherit their classification from their parent
aggregation or it is directly applied to them.
• Find all the records that have a particular disposal schedule, regardless of
whether they inherit it from their class or it is directly applied to them. for Records Systems
• Find all the records that are subject to a disposal hold, regardless of
whether they have been added to the disposal hold individually or because
they belong to a particular class or aggregation that has been added to
the disposal hold.
• Monitor the activities of a particular group by finding all the events gene-
rated by users of that group over a specified time period.
• Find all the entities which have a particular contextual metadata element
definition associated with them where the metadata element contains a Volume 1
specific value or range of values.
• Find all the entities which were created by a particular user in the last
Core Services
week, by tracing the creation function through the creation event. & Plug-in Modules
• Find all the records that were transferred by members of a particular
group in the last month. Version 1.1
147
1
Searching
and reporting R10.4.17 The MCRS must, by default, return only active entities in search results,
service under R10.4.1, unless the user performing the search specifies the inclu‑
sion of both active and residual entities in the search results.
By default, residual entities will not be included in search results. Where both
active and residual entities are specified by the user, then their status should be
clearly indicated in the search results.
R10.4.18 The MCRS must allow a user that initiates a search, under R10.4.1, to
specify:
• which metadata elements to include in the search results;
• whether to include the entity type of each entity in the search results;
• whether to include the relevancy score, calculated under R10.4.4;
• whether to include both active and residual entities, under R10.4.17;
• whether to order the search results by the relevancy score (if included);
and, if not,
• which metadata element(s) to use to order the search results.
The user may elect to include, for example, the Title and Description of each
entity, its entity type and its Created Timestamp in the search results, and to
order the results by the Created Timestamp.
Note that when ordering search results using a timestamp, the MCRS should
factor in the time zone when determining the order of entities (see also
R10.4.10).
R10.4.19 For large sets of search results, the MCRS must implement a method of
pagination, or alternative, such that only a subset of the total search results
is provided back to the user and additional subsets are provided when
required.
MoReq2010® does not define a ‘large’ set of search results or how the MCRS
should implement pagination or any other method of providing subsets of the
full search results sequentially to the user; however, pagination (or alternative)
should be demonstrable in the MCRS during testing. Page sizes in different
implementations typically vary between 10 and 100 items per page.
•
MoReq2010
R10.4.20 The MCRS must provide the total number of entities that match the search
query as part of the search results: this total must not include entities that
Modular Requirements are excluded from the search results under R10.4.21.
for Records Systems
Where large sets of search results are paginated, under R10.4.19, the total
number of matching search results must be returned with the first and all
subsequent subsets.
The total number of search results is a valuable indication, both immediately
to the user and later statistically when stored in a matching event, of search
activity and usage patterns across the MCRS. Depending on the search engine
used by the MCRS, this number may be an approximation.
R10.4.21 The MCRS must never allow a user by searching, browsing or any other
Volume 1 method to access entities or their metadata that the user does not have
authorisation to inspect. All such entities should be excluded from search
Core Services results.
& Plug-in Modules
See also R10.4.1. Search results must not include any inaccessible entities
that the user is not authorised to access. Also, inaccessible entities must be
Version 1.1 excluded from totals of search results, under R10.4.20.
148
1
Searching
R10.4.22 Whenever a user performs a search under R10.4.1, the MCRS must generate and reporting
an event and include it in the event history of the user’s user entity. The service
event must include a description of the search query performed and the
total number of entities found (see R10.4.20).
MoReq2010® does not specify how search queries should be described in
the search query. It may be in a structured expression language or in natural
language.
Note that MoReq2010® does not require that the generated search event should
link to each of the search results as participating entities, but the event should
contain the total number of search results returned.
R10.4.23 The MCRS must allow authorised users to save, modify, delete and share
search queries.
Note that although these are commonly referred to as ‘saved searches’, it is only
the search query that is saved, not the search results.
MoReq2010® does not specify how search queries are to be saved or in what
format. This detail is specific to the individual MCRS and its search engine. For
this reason, saved searches cannot be exported from the MCRS and imported
into another records system, under 11. Export service, and this functionality is
not included in the function definitions in 14.5 Function definitions.
R10.4.24 The MCRS must allow authorised users to generate detailed reports based
on any search query, in a common reporting format, with the following
configurable items:
• a report header provided by the user;
• the date and time the report was generated;
• page numbering;
• details of the MCRS and the searching and reporting service genera‑
ting the report (see R2.4.2);
• details of the user generating the report (see R3.4.1);
• a description of the search query used for the report (see R10.4.22); •
MoReq2010
• the total number of search results in the report (see R10.4.20); and
• columns and column headings based on the metadata elements
selected for the report (see R10.4.18). Modular Requirements
for Records Systems
Suppliers must provide a list of the reporting formats they support when their
product is certified. Common reporting formats include:
• comma or tab separated values;
• spreadsheet formats, such as OOXML and ODF;
• XML and HTML-based formats; and
• PDF or other document formats.
Volume 1
R10.4.25 The MCRS must allow authorised users to generate summary reports
based on multiple search queries, in a common reporting format, with the Core Services
following configurable items: & Plug-in Modules
• a report header provided by the user;
• the date and time the report was generated; Version 1.1
149
1
Searching
and reporting • page numbering;
service • details of the MCRS and the searching and reporting service genera‑
ting the report (see R2.4.2);
• details of the user generating the report (see R3.4.1);
• a description of each of the search queries used by the report (see
R10.4.22); and
• the total number of search results found for each search query (see
R10.4.20).
A summary report gives only the totals for the number of entities that meet
each of the specified set of search queries. Only the total number of matching
entities is given. Unlike a detailed report, there is no body to a summary report
that lists the entities or their metadata.
Common reporting formats are listed in the rationale to R10.4.24.
R10.4.26 Whenever a user generates a detailed report under R10.4.24, or a summary

report under R10.4.25, the MCRS must generate an event and include it in
the event history of the user’s user entity. The Event Comment must include
a description of the search(es) performed in generating the report and the
total number of entities found.
See also R10.4.22.
R10.4.27 The MCRS must allow authorised users to save, modify, delete and share
report definitions for both detailed and summary reports.
See also R10.4.23.
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
150
1
11
Export service

Service name Export service
Service version 1.0
Implements Service 2777ab81‑057e‑4aa4‑9595‑69459ec2dc1e

q
8
11.2 kEy CoNCEPtS

i;.444 Q4
•
1 81
11.2.1 Purpose of export �,d.2 .a. Jl.1.

,,
4 J7 bd22
Export in MoReq2010® is the operation by which entities in an MCRS can be ' ., o
described in sufficient detail in a common XML data format, belonging to the
l '
'
o¡ 4 6 134
specification, so that their metadata values, event histories, access controls
<
,,
and content can be preserved and transferred to another MCRS.
J O 38 b 04 • 24
84 76
•
The complementary operation to export is import. The purpose of import is <
•
"
4 4
•
7 ea 2
to take MoReq2010®‑formatted XML data that has been exported from one <
MCRS and use it to create new entities in a different MCRS, so that they can
be accessed and managed in the same way as they were previously.
Ideally, both export and import should be ‘lossless’ operations: they should
not divest the entity of any of its significance, content or context. The ability
to export entities from one MCRS and usefully import them into another
MCRS, without loss of business context, is referred to by MoReq2010® as
achieving ‘interoperability’.
Some common reasons for exporting entities from an MCRS include the
following.
• transfer — where entities are relocated to the management of a diffe‑
rent system, organisation or archive. Transfer is mostly performed as •
MoReq2010
a consequence of following a disposal schedule as part of the disposal
process described in 8. Disposal scheduling service.
• Migration — where entities are moved from the management of one Modular Requirements
MCRS to another MCRS within an organisation. This may be done as for Records Systems
part of replacing, upgrading or decommissioning the original MCRS.
• Secondary hosting — where entities are regularly copied to one or more
secondary and possibly read‑only systems. If the secondary host is regu‑
larly updated in this way, then only the differences between the entities it
holds and those in the source system will need to be imported.
• Replication — so as to provide a copy for reference or safekeeping of
the contents of an MCRS in a non‑proprietary and easily understood
format that is transportable to other compliant records systems. Note
that the MoReq2010® export service is neither intended, nor optimised, Volume 1
to provide routine operational backups as part of the general provi‑
sion of disaster recovery services. However, unlike a system backup Core Services
of data which is made in the supplier’s own data format and can only
& Plug-in Modules
be used for restoring the system it was made from, the export service
does allow a copy of all or part of an MCRS to be made into the widely
understood MoReq2010® XML format. Version 1.1
151
1
Export service
11.2.2 Partial export
The MoReq2010® export service is intended for the export of complete entities
with their metadata, event histories, access controls and content intact. When
entities are exported from the MoReq2010® export service, other related enti‑
ties that provide context for the entity, must also be exported with them, some
as placeholders (see 11.2.7 Export content and placeholders). This ensures
that the full context of entities is transferred from system to system. However,
it also requires the export of sufficient data to ensure this.
Some records systems may additionally allow for other variations of export
where only some of the requirements of the MoReq2010® export service are
supported. These variations may include:
• only some of the metadata;
• only some of the events in the event history;
• only some of the access control information; and/or
• only some of the related entities.
MoReq2010® describes these approaches as implementing ‘partial export’
because of the incomplete integrity of the data that is exported. A partial
export is, by definition, ‘lossy’ rather than lossless.
While partial export may have some applicability in certain business situa‑
tions, for example as a means of providing a temporary copy, or a summary
set of records, to an external authority, it is generally unsuitable for the
practice of good records management. Lossy transfers of entities may
result in the unintended stripping away of important attributes and busi‑
ness contexts that are found to be required later. Internal consistency within
a records system cannot be guaranteed, especially in the longer term.
For this reason, partial export is not required and not tested for compli‑
ance with the MoReq2010® specification, although a supplier may offer
some form, or forms, of partial export as an additional product feature.
Note also that because the export data format provided by MoReq2010® is
XML‑based, it should be equally possible, for an organisation to generate
any partial export from a complete export by subsequently applying XML
transformation.
• Implementation of the full MoReq2010® export service, as defined by these
MoReq2010 requirements, is an essential quality mandated for compliance with the core
services.
11.2.3 Use of xMl
for Records Systems
MoReq2010® is accompanied by an XML schema published and maintained
by the DLM Forum Foundation that defines how data should be described as
a post‑condition of export and a precondition of import. Every MCRS must
provide a full implementation of this schema, which is extensible to allow for
the definition and capture of contextual metadata elements and variations
introduced by MoReq2010® extension modules and plug‑ins.
MoReq2010® currently defines the export service as writing the exported
entities to an XML datafile. However, it recognises that writing exported
data to XML datafiles, while practical for small amounts of data, cannot
Volume 1 be considered a scalable solution for medium to large MCRS environments
because of the following restrictions.
Core Services
Operating systems place limits on datafile sizes and there are also
& Plug-in Modules •
practical limits imposed by storage media. For this reason, large
amounts of data cannot be written to a single datafile but must be split
Version 1.1 across many datafiles. There is no industry standard for this.
152
1
Export service
• Often XML datafiles are compressed for more efficient storage: while
XML itself is standardised, different compression algorithms are not.
• XML datafiles must be stored somewhere, even temporarily, leaving
them vulnerable to security threats, such as unauthorised access,
accidental deletion and even tampering.
In the future, larger MCRS solutions will need to transfer thousands, tens of
thousands, hundreds of thousands and even millions of records and related
entities, as part of a single secure export/import operation.
11.2.4 xMl data streaming

For the reasons given previously, exporting to XML datafiles is seen as a
temporary solution to the problem of exporting and importing data from an
MCRS. The DLM Forum Foundation’s MoReq Governance Board intends to
investigate and explore options for streaming support for exported data in a
future version of MoReq2010®.
XML data streams have the following advantages over XML datafiles.
• Streams are not limited by fixed datafile size limits or the storage
capacity of physical media, although streams may be captured into
one or more datafiles if required.
• A stream may be interrupted at any point during transfer and resumed
later: streams are, therefore, a robust means of transfer.
• Streams may be sent across encrypted channels, allowing secure
system to system communication.
• During transfer, streams do not require any intermediate physical
storage, such as DVDs, which might be lost, damaged or unlawfully
copied in transit.
• Streaming allows the direct transfer of data in real time.
As a consequence, it can be harder to intercept or interfere with streamed
data and this, combined with the immediacy of real‑time communica‑
tion will, in the future, contribute to enhancing the authenticity of the
transferred records. One possible standard that may be introduced to the
MoReq2010® export service in the future is the use of the W3C EXI (Efficient
XML Interchange) standard. At the time of publication of MoReq2010®, EXI is
•
not a ‘recommendation’ of the World Wide Web Consortium (W3C), but it has MoReq2010
been a candidate recommendation since December 2009.
11.2.5 Importing entities Modular Requirements

for Records Systems
MoReq2010® is intended to be suitable for use by both large‑scale multi‑
purpose records systems implementations and small‑scale single‑purpose
implementations. While export is a necessary part of the core services
provided by an MCRS, the complementary import is not a core require‑
ment of the specification. This reflects the complexity of the import process.
Implementing an import service that can successfully import data from
every other MCRS necessarily requires a more sophisticated solution than
one which is only required to export data. The result of building more sophis‑
ticated solutions is longer development time with potentially higher costs
to the end consumer, at least until such systems are commonplace, and a
corresponding fall in the number of compliant records systems. Volume 1
Therefore, while MoReq2010® specifies that every MCRS must support Core Services
export so that no records system can become a trap for data which, having & Plug-in Modules
been put into the system, cannot be retrieved from it, it does not specify that
every MCRS must necessarily make provision for an import service. Some
dedicated front‑line business systems may never support import, while Version 1.1
153
1
Export service
other MCRS suppliers will only include import in their second generation
MoReq2010® compliant products. Generally, it will be the larger and more
generic records systems implemented as enterprise middleware with the
capacity to integrate with and support multiple front‑line business systems
that will require import functionality sooner than other types of MCRSs.
The import service will be provided as an extension module to MoReq2010®
and consumer organisations can specify this functionality, should they
require it.
11.2.6 Exporting from non-compliant systems

As MoReq2010® compliant systems become more commonplace, it is antic‑
ipated that suppliers will want to build adaptors that enable the records
and other entities in legacy information systems to be exported to the
MoReq2010® XML format. These older, non‑compliant systems may never
be updated to new versions that can achieve MoReq2010® compliance.
However, organisations will want either the original supplier, or a third‑party
supplier, to provide a migration solution so that the contents of these records
systems may be transferred to an MCRS.
Once records and entities have been successfully migrated to, or recreated
in, an MCRS they may be held indefinitely as all MCRS solutions support
an export service and can, therefore, transfer them on to the next records
system.
Other than providing an XML data format, MoReq2010® does not define any
requirements for the transfer of records and entities from non‑compliant
records systems. Each consumer organisation must be independently satis‑
fied of the completeness and correctness of any migration tool it licenses or
develops for extracting records and entities from legacy systems.
11.2.7 Export context and placeholders

The entities in an MCRS are richly interrelated and MoReq2010® requires
each entity to be exported in context. This means that when one entity is
exported, information about the entity and other related entities are exported
with it.
• For the purpose of export, the full context of each entity is made up of the
MoReq2010 following.
1. System metadata elements and their values.
Modular Requirements 2. Contextual metadata elements and their values.
for Records Systems 3. Related entities referred to by System Identifiers held in these meta‑
data elements.
4. Significant entities, such as a record’s disposal schedule, whether
or not they are referred to directly by a System Identifier held in a
metadata element.
5. Included entities, such as the components of a record, the users in a
group or the records in an aggregation.
6. The entity’s access control list and its access control entries.
Volume 1 7. The access control lists of related and significant entities and their
access control entries.
Core Services 8. The users, groups and roles referred by these access control entries.
& Plug-in Modules 9. The events in the entity’s event history.
10. The entities referred to by System Identifiers held in the metadata
Version 1.1 elements belonging to each event.
154
1
Export service
To export an entity complete with its context from the MCRS, all of the items
in this list must be exported with it. Note, however, that some items, notably
3, 4, 6, 7 and 8 call for additional entities to be exported. If these related
entities are likewise exported under the same rules as before, this might
potentially result in an ever‑increasing pool of entities to export.
Instead of this, any related entities not directly included in the set of entities
to export, are exported with a reduced context. Specifically, these entities
have only the following items from the previous list.
1. System metadata elements and their values.
4. Significant entities, such as a record’s disposal schedule, whether
or not they are referred to directly by a System Identifier held in a
metadata element.
6. The entity’s access control list and its access control entries.
7. The access control lists of related and significant entities and their
access control entries.
8. The users, groups and roles referred by these access control entries.
Entities exported with their full context are described as being ‘exported
in full’. Entities exported with a reduced context are described as being
‘exported as placeholders’. Placeholders do not include contextual meta‑
data, related entities, other than significant entities, or any event history.
While export placeholders are useful for providing context for other enti‑
ties they are not considered to be complete entities, as some of their own
context is missing. They represent a two dimensional snapshot taken at a
particular moment in time rather than a ‘living’ entity.
Entities that have been exported in full can be imported by another MCRS
and managed as active entities. By comparison, when an MCRS imports a
placeholder it creates from it an ‘inactive’ entity, which is neither active nor
residual. Inactive entities are only relevant in the context of the MoReq2010®
501. Import service, they are not part of the MoReq2010® core services,
nor is it necessary to implement them to achieve compliance with the core
requirements.
11.2.8 Exporting metadata

•
Each entity has a set of metadata elements associated with it, some are MoReq2010
system metadata elements and some may be contextual metadata elements.
Each metadata element has two important parts to it:
• its related metadata element definition, and
for Records Systems
• its value (or values).
When exporting metadata elements, system metadata element definitions
are not included in the exported data. It can be safely assumed that the
importing MCRS already knows these definitions, as they are specified by
MoReq2010®. System metadata elements are, therefore, exported as a
value only.
When contextual metadata elements are exported, it is necessary to export
the corresponding contextual metadata element definition along with the
value. This allows the importing MCRS to ‘recognise’ the metadata element.
Relevant contextual metadata element definitions must be exported as Volume 1
placeholders, where necessary.
Core Services
When an entity is exported in full, both its system metadata values and its & Plug-in Modules
contextual metadata values, and any corresponding contextual metadata
element definitions, are exported with it. When an entity is exported as a
placeholder, only its system metadata values are exported. Version 1.1
155
1
Export service
Each metadata element, including system and contextual metadata, is either:
• a value of a particular datatype, such as a text value, a number or a
flag, or
• a System Identifier that refers to another entity in the MCRS.
If a metadata element contains a datatype, its value is simply exported.
However, if a metadata element contains a System Identifier, the entity it
refers to is described as a ‘related entity’. It is the relationships between
related entities that give them context.
When an entity is exported in full, any related entities referred to by either its
system metadata or its contextual metadata are exported as placeholders.
When an entity is exported as a placeholder, only its system metadata values
are exported and not any related entities to which these values may refer.
11.2.9 Exporting significant entities

Some entities are more significant in providing the context of an entity than
others. In MoReq2010®, not all related entities are significant entities and
not all significant entities are related entities. For example, the disposal
schedule of a record is very significant. However, the record may inherit its
class from its parent aggregation and its disposal schedule from its class.
The disposal schedule is, therefore, not an immediately related entity to the
record even though it is a highly significant one.
For classes, the following entities are significant:
• the class’s disposal schedule; and
• any disposal holds associated with the class.
For aggregations, the following entities are significant:
• the aggregation’s class, whether inherited or directly applied to the
aggregation;
• the aggregation’s parent aggregation, and any ancestor aggregations,
up to and including the root aggregation; and
• any disposal holds associated with the aggregation.
For records, the following entities are significant:
• • the record’s class, whether inherited or directly applied to the record;
MoReq2010
• the record’s disposal schedule, whether inherited from its class or
directly applied to the record;
Modular Requirements • the record’s parent aggregation, and any ancestor aggregations, up to
for Records Systems and including the root aggregation; and
• any disposal holds associated with the record.
For users, the following entities are significant:
• the groups to which the users belong.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
156
1
Export service
Figure 11a shows some of the significant entities for a record.
M0Req2010'
Disposal
schedule
aggreganon
Aggregation Aggregation
ºd��Qd
\\.
ªªª
:�portas Export targel

�aceholder
Figure 11a — Significant entities, such as the class, disposal schedule and ancestor
aggregations for a record must be exported as placeholders.
•
MoReq2010
Significant entities are so significant that even when an entity is exported
as a placeholder, its significant entities must also be exported with it as
placeholders. Modular Requirements
for Records Systems
11.2.10 Exporting included entities
Some entities may be regarded as containing other entities: these are their
‘included’ entities. The following identifies included entities.
• The included entities of records are components.
• The included entities of aggregations are child aggregations and
records.
• The included entities of groups are users.
Volume 1
• The included entities of templates are contextual metadata element
definitions. Core Services
When entities with included entities are exported in full, their included enti‑ & Plug-in Modules
ties are also exported in full. This is shown in Figures 11b and 11c. Included
entities are never exported as placeholders. Version 1.1
157
1
Export service
When entities are exported as placeholders, their included entities are not
exported.
'MoReq20tO .
Root
aggregation
Aurcgation
800 Q
Record Record Record Recor
Export target
� ::tortas
�ceholder
a E>cport In full
Figure 11b — An example of included entities are the components of a record: when the
record is exported in full, the components are also exported in full
•
MoReq2010
All included entities must be exported in full, cascading down to any depth.
For example, if a root aggregation is exported in full, any child aggregations
Modular Requirements are exported in full, any records in those child aggregations are exported in
for Records Systems full and the components of those records are exported in full, etc.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
158
1
Export service
MoReq2010'
Agregation
QQO
� h'°""
�aceholdcr
a Expon in full
Figure 11c — Another example of included entities are the children of aggregations: all
included entities are exported in full, so the included entities of included entities will be
exported in full
When an entity is exported in full because it is an included entity, it has the

same effect as if the included entity was one of the entities originally nomi‑
nated for export. All entities are exported in full and any significant entities
related to any of the included entities are also exported as placeholders, as
shown in Figure 11d.
MoReq2010'
•
MoReq2010
for Records Systems
Auregatlon
888
� ''.'°""
Volume 1
�accholdu
a b:port in full
Core Services
& Plug-in Modules
Figure 11d — Showing both included entities which are exported in full and significant
entities which are exported as placeholders
Version 1.1
159
1
Export service
11.2.11 Exporting access control lists
Access control lists contain access control entries that each associate a
particular user or group with one or more roles. Figure 11e shows a typical
access control list for an entity.
When entities are exported as placeholders, it is still important that access
to the information they contain is controlled. For this reason, the MCRS
must export the access control lists of both entities that are exported in full
and entities that are exported as placeholders.
As the model role service supports the inheritance of access control lists
from services, parents and classes, under R4.5.11, the MCRS must also
export the access control lists of services relevant to the entities and place‑
holders being exported. In this way, the full access control list for an entity
can be assembled on import from a combination of the service, significant
entities such as parents and classes exported as placeholders, and the
exported entity itself.
When an access control list is exported, whether for an entity that is exported
in full or for a placeholder entity, each of the entities referred to by the access
control list must also be exported as placeholders, including users, groups
and roles. This is shown in Figure 11f.
-- Access control entrv MoReq2010'
M . o ñ l • n o j
UserX
Role 2
MoReq2010
• eM :
Group A '-------' �----
Modular Requirements Role3 Role4

for Records Systems
()
�
Group B
Access Control List
Figure 11e — A typical access control list: each access control entry associates a user or
group with one or more roles
Volume 1
Core Services
& Plug-in Modules
Version 1.1
160
1
Export service
MoReq2010•
Role4�
Role 2
Role3 �
Figure 11f — All of the entities referred to by the access control list must be exported as
placeholders
11.2.12 Exporting events

Each entity’s event history consists of a set of events in which the entity
participated. For each of these events, there may have been other partici‑
pating entities and the metadata associated with the event will refer to
various related entities.
When an entity is exported in full, its event history is exported with it. This
means all of the events in which the entity was a participating entity. In addi‑
tion to exporting the metadata of the events, all of the related entities to the
events should also be exported as placeholder entities.
When an entity is exported as a placeholder, its event history is not exported.
None of the events in which the entity participated are exported with a place‑
holder entity.
•
11.2.13 Export summary table MoReq2010
The descriptions given in 11.2.7 through 11.2.12 indicate what an MCRS

must do to compile a set of data for export. Starting with the entities nomi‑ Modular Requirements
nated by the user, the MCRS must trace all of their related entities and for Records Systems
decide which entities to export in full and which to export as placeholders.
The MCRS must then compile this data by service, de‑duplicate it, and
export is as a coherent set of data. The following table summarises these
export decisions of the MCRS.
what to export For entities exported For placeholders

in full
System metadata Export values Export values

elements Volume 1
Contextual metadata Export values Do not export Core Services

elements
& Plug-in Modules
Contextual metadata Export as placeholders Do not export
element definitions
Version 1.1
161
1
Export service
Related entities Export as placeholders Do not export
(referred to by
metadata elements)
Significant entities (e.g. Export as placeholders Export as placeholders

a record’s class)
Included entities (e.g. Export in full Do not export

the child entities of an
aggregation)
Access control lists Export values Export values
Entities referred to by Export as placeholders Export as placeholders

access control entries
Events and their Export values Do not export

metadata
Entities related to Export as placeholders Do not export

events (referred to by
metadata)
11.2.14 Entities that are not exported

By default, only active entities are exported from an MCRS. Residual entities
are usually excluded from export, but may be optionally included by the user
performing the export.
Note that saved searches and reports, referred to in 10. Searching and
reporting service, are considered to be application‑specific objects rather
than MoReq2010® entities and the specification makes no provision for their
export.
11.2.15 Export security

A user cannot export in full or as a placeholder, any entity which the user
is not authorised to inspect and the MCRS must not allow entities to be
exported by that user if they are normally inaccessible.
• An export must not be carried out by the MCRS if the user does not have full
MoReq2010
access to export the requested entities and their placeholders.
Modular Requirements 11.2.16 Export completeness

for Records Systems MCRS solutions may be built around different architectures. The specifica‑
tion allows different products to implement their own access controls (see
4. Model role service) and their own contextual metadata definitions (see
7. Model metadata service). MoReq2010® also presents a service‑based
approach where entities of different types are managed by discrete services;
however, MoReq2010® does not enforce the use of this approach, allowing
each supplier to choose their own method of implementing an MCRS,
including as a single non‑modular application.
These freedoms must be balanced by the necessity for exporting all data
Volume 1 to a common format that can be understood and used by any MCRS that
implements the import service requirements. This means the following
Core Services post‑conditions must be true when any data is exported.
& Plug-in Modules • At least in the data that is exported, MCRS solutions must export
access controls as MoReq2010® access control lists, access control
Version 1.1 entities and roles.
162
1
Export service
• At least in the data that is exported, MCRS solutions must export
system and contextual metadata as MoReq2010® metadata element
definitions and templates.
• At least in the data that is exported, MCRS solutions must not export
any custom or proprietary entities or metadata that is not described by
a contextual metadata element definition that is also exported.
• At least in the data that is exported, MCRS solutions must export enti‑
ties grouped together by type into their discrete services.
The last of these requirements, that entities of the same type are grouped
together and exported as services, is necessary because MCRS solutions
that support the import service must also be able to support multiple serv‑
ices of the same type. For example, an MCRS with its own classification
service may then import a classification service from another MCRS. The
imported classification service may even represent a different classification
scheme structure (see the 200. Classification series modules).
When an MCRS imports a service, such as classification, from another
records system, the classes in that classification service may either be
mapped across to classes in its own classification service, or they may be
imported and managed by the MCRS as inactive classes that mirror the
structure under which they were held in the originating records system. The
ability to choose either of these import methods implies that the data being
imported identifies entities as belonging to discrete services, even if they
were not arranged in this way in the original records system.
11.2.17 the export process

Each time an MCRS performs an export, it must create an Export Identifier
for that export. This Export Identifier is included in the XML data as well as
the export event generated for each entity (see R2.4.16). The same Export
Identifier is used for all entities and placeholders exported together as part
of a single export operation. The Export Identifier allows a user to find, by
searching, which entities were exported together for any given export event.
It also allows the import service to track which entities came from a single
MCRS source as a snapshot of a particular moment in time.
•
When exporting entities, all MCRS solutions must follow the same export MoReq2010
process. The following gives an overview of the export process.
1. Create an Export Identifier, as just described. Modular Requirements
2. For each entity to be exported in full, build lists of related entities for Records Systems
to be exported in full, and related placeholders be exported as
placeholders.
3. Initiate the export and write out header information including infor‑
mation about the MCRS and which services it complies with, the
Export Identifier, etc.
4. Export each relevant service in turn and, within each service, perform
the export of each entity in turn, exporting a block of placeholders
followed by a block of entities in full for each entity type.
Volume 1
5. As each entity is exported, generate an export event and add it to that
entity’s event history. Core Services
6. Complete the export. & Plug-in Modules
7. In the event of any failure or interruption to the export, write any
errors to the external error log (see R2.4.7). Version 1.1
163
1
Export service
The data format to export to and the order in which entities and their
metadata elements are exported, are determined by the schema for the
MoReq2010® XML format.
11.2.18 De-duplication
When exporting entities, the MCRS must ensure that it includes each rele‑
vant entity once in any export. If an entity is exported in full, it should not
also be exported as a placeholder in the same export. If many entities refer
to the same entity, that same entity should be exported only once regardless
of how many times it is referenced.
11.2.19 limiting access to data once it has been exported

When entities are exported from an MCRS, the exported entities are trans‑
lated into a stream of XML data with none of the usual controls present that
are implemented by an MCRS. This raises a number of security considera‑
tions that must be taken into account by any organisation using the export
service.
• Care must be taken that the user undertaking the export has access to
all of the entities that are to be included in the export — users cannot
export entities that they are not themselves able to access and inspect
in the MCRS.
• Operational procedures must be put into place to protect the export
and its informational content — once it has been exported from the
MCRS, the data described by the export is no longer protected by the
system and is in a simple XML format: organisations should consider
encrypting and otherwise protecting it.
• If the XML data is in a readable form, it must be stored securely and
access should be limited to those users that would be authorised to
access it inside the MCRS.
• Where the data is sensitive, it must be imported into the destination
records system in such a way that the MCRS importing it simulta‑
neously makes it secure so that other users of the destination records
system cannot automatically access it. This is particularly impor‑
tant as access control lists including users, groups and roles from
•
MoReq2010 the source records system may not be respected in the destination
records system.
Further measures may be required if data is stored outside an MCRS for an
Modular Requirements extended period of time. By preference, and especially for sensitive data,
for Records Systems an XML export should only be retained temporarily and deleted as soon as
possible after its successful transfer is confirmed.

R11.4.1 The MCRS must allow an authorised user to export entities to an XML data‑
file that can be validated using the MoReq2010® XML schema.
The MCRS must allow the user to export any of the following.
• All users and groups collectively from a user and group service.
Volume 1
• Any nominated groups individually with the user entities that belong
Core Services to those groups.
& Plug-in Modules • Any nominated users individually.
• All roles collectively from a role service.
Version 1.1 • Any nominated roles individually.
164
1
Export service
• All classes collectively from a classification service.
• Any nominated classes individually.
• All aggregations and records, with their components, from a record
service.
• Any nominated aggregations individually and the records, with their
components, they contain.
• Any nominated records individually, with their components.
• All element definitions and templates collectively from a metadata
service.
• Any nominated templates individually with the contextual metadata
element definitions that form part of the template.
• Any nominated contextual metadata element definitions individually.
• All disposal schedules collectively from a disposal scheduling
service.
• Any nominated disposal schedules individually.
• All disposal holds collectively from a disposal holding service.
• Any nominated disposal holds individually.
See 11.2.4 XML data streaming, the MoReq Governance Board is investigating
replacing the export of entities in a datafile with the export of entities to a stand-
ardised data stream instead.
This future initiative is intended to resolve current technical and proprietary
limitations on export such as how to provide a standardised mechanism for
breaking large exports across multiple datafiles and what compression tech-
nologies an MCRS must support.
R11.4.2 Whenever an MCRS exports entities, under R11.4.1 or R11.4.3, the MCRS
must not, by default, export residual entities unless the authorised user
specifically includes them. However, where the user so chooses, the MCRS
must export all entities, including both active and residual. •
MoReq2010
For example, if the user exports an aggregation, only the active records in the
aggregation would normally be included in the export. However, the MCRS must
also provide the user with an option to export the aggregation and include both Modular Requirements
its active and residual entities. for Records Systems
R11.4.3 When preparing to export under R11.4.1, the MCRS must first determine
which entities to export in full, that is, the following:
• the entities nominated by the authorised user under R11.4.1;
• the included entities of any entities to be exported in full (see
11.2.10 Exporting included entities for a definition of inclusion); and
• the events of any entities to be exported in full.
The MCRS must then determine which entities to export as placeholders, Volume 1
that is, the following:
• all entities referred to by the metadata elements of entities to be Core Services
exported in full, including their events; & Plug-in Modules
• the contextual metadata element definitions for all the contextual
metadata elements of entities to be exported in full; Version 1.1
165
1
Export service
• all entities that are significant to entities to be exported in full or as
placeholders (see 11.2.9 Exporting significant entities for a definition
of significance); and
• all entities that are referred to by the access control lists of entities to
be exported in full or as placeholders.
These rules must be applied iteratively until all entities to be exported in
full and all entities to be exported as placeholders are identified, subject
to R11.4.2, meaning that, by default, only active entities are to be included
unless the user also includes residual entities. No entity should be included
twice and no entity should be exported as a placeholder if it is simultaneously
being exported in full.
R11.4.4 When an authorised user exports one or more entities under R11.4.1, then
the MCRS must generate a universally unique identifier for the export.
See R2.4.24. Each separate export from an MCRS represents a snapshot in
time of a part of the MCRS. Clearly and uniquely identifying each export as it is
made allows another MCRS to import a series of exports over time and to more
easily and precisely piece the information back together.
The Export Identifier is stored as part of the export event for each entity included
in the export (see R11.4.7).
R11.4.5 When an authorised user exports entities under R11.4.1, the MCRS must
allow the user to provide a text comment to be included in the export data
under R11.4.6, and the export event under R11.4.9.
The export comment is an explanation, by the user initiating the export, of why
the export was performed and what it contains.
R11.4.6 Once an export has been initiated under R11.4.1, the MCRS must export the
following:
• an Export Commencing Timestamp;
• the Export Identifier generated under R11.4.4;
• • the export comment included under R11.4.5;
MoReq2010
• an export header containing full identification and information on the
services supported by the MCRS (see R2.4.5);
Modular Requirements • metadata and access control lists for each service (see 11.2.11 Export-
for Records Systems ing access control lists);
• for each service the entities to be exported, grouped into placeholders
or entities exported in full (see R11.4.3); and
• an Export Completed Timestamp.
The MoReq2010® XML schema specifies the complete and detailed export
format that must be met.
R11.4.7 For each entity to be exported in full, under R11.4.3, the MCRS must export
Volume 1 the values of each of its metadata elements, including both system and
contextual metadata elements, and its access control list.
Core Services
The MCRS must export both system metadata elements and the contextual
& Plug-in Modules metadata elements for entities to be exported in full, including events. All the
metadata in the entity’s access control list and its access control entries must
Version 1.1 also be exported.
166
1
Export service
R11.4.8 For each component to be exported in full, under R11.4.7, the MCRS must
export the content of the component, subject to the separate provisions
specified by the applicable MoReq2010®, 300. Component series module
for the component’s entity subtype.
The content of different types of components will be exported in different
ways, as specified by the plug-in module for the appropriate component type.
Generally, the content of components will either be included in the export XML,
or exported separately but referenced by the export XML, or exported separately
and not referenced by the export XML.
R11.4.9 For each entity exported as a placeholder, under R11.4.3, the MCRS must
export the values of each of its system metadata elements, and its access
control list.
The values of contextual metadata elements are not exported for placeholder
entities. All the metadata in the placeholder’s access control list and its access
control entries must be exported.
R11.4.10 For each entity exported in full, under R11.4.7, and for each entity exported
as a placeholder, under R11.4.9, the MCRS must add to the event history of
the entity an event that includes:
• the Export Identifier (see R11.4.4);
• an Exported In Full Flag; and
• the export comment, as the Event Comment (see R11.4.5).
If an export is only partially completed, either because it is cancelled or fails
or for any reason, events should only be generated for those entities that were
exported successfully prior to the termination of the export process.
The Exported In Full Flag indicates whether the entity was exported in full or
otherwise as a placeholder.
Note that as service information is exported with every export, under R11.4.6,
and services are not exported as entities, an exported event is not generated
when a service is exported.
Function reference: F14.5.10, F14.5.29, F14.5.43, F14.5.52, F14.5.62, F14.5.76,
F14.5.100, F14.5.127, F14.5.148, F14.5.170, F14.5.185, F14.5.186
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
167
1
12
Non-functional requirements
12.1 kEy CoNCEPtS

12.1.1 Non-functional requirements in MoReq®
Non‑functional requirements have always been an important part of the
MoReq® specification since the publication of the original MoReq® in 2001.
They specify those qualitative aspects of the records system which are not
necessarily made explicit by the functional requirements alone. Functional
requirements tend to focus on the specific behaviour required from the q
8
system, without focusing on these closely related environmental, opera‑ •
i;.444, Q4
tional, infrastructural and comfort factors. 1 81
By their very nature, non‑functional requirements are less definitive and �,d.2 .a. Jl.1.
more subjective than functional requirements. They are more difficult to 4., l'i,
bd22
specify in a universally applicable way, are more open to interpretation, and ' ., o l '
are more difficult to quantify, measure and test. ¿ 0 ¡
'
4 6 714
Nevertheless, experience with previous versions of MoReq® has shown that '4 J O 38
•
04 • 24
both suppliers and consumer organisations often draw important and prac‑ 84 4 8 76
tical information from the specification’s non‑functional requirements. This

¿ "
• 4 4 7 ea 2
has helped suppliers to enhance the quality of their products and consumer
organisations to select records systems that are well suited to their business
needs and environments. It is interesting to note that during the consultative
phases leading up to the development of MoReq2010®, contributors showed
a clear preference for retaining and augmenting the part of the specification
covering non‑functional requirements.
12.1.2 Functional and non-functional requirements in MoReq2010®

Within any statement of requirements, the boundary between the purely func‑
tional and the non‑functional aspects of the specification is often subjective
and difficult to define with clarity. MoReq2010® has been purposely designed
so that its non‑functional requirements can fulfil a different and separate •
capacity to that of its functional requirements. MoReq2010
The characteristics of the two different types of requirements within
MoReq2010® may be expressed as follows.
for Records Systems
Functional requirements
• Functional requirements in MoReq2010® are expressed as closed state‑
ments, for example ‘The MCRS must …’ or ‘The MCRS must not …’.
• Each functional requirement relates directly to one (or, sometimes,
more than one) explicit function that must be performed by an MCRS.
• Most functional requirements in MoReq2010® are accompanied by a
rationale providing additional clarification of the requirement.
• The explicit functions described by the functional requirements are
each individually identifiable, are listed under 14.5 Function definitions,
Volume 1
and are utilised and referred to by the architecture of MoReq2010®,
both within the access control model (see 4. Model role service) and Core Services
the event model (see 2. System services).
& Plug-in Modules
• The functional requirements of MoReq2010® are verifiable by test
cases and scripts within the test framework that accompanies the
specification. Testing of a product or installation by an accredited test Version 1.1
169
1
Non-functional
requirements centre against these functional requirements can lead to the award of
a certificate of compliance by the DLM Forum Foundation.
Non-functional requirements
• A non‑functional requirement in MoReq2010® relates to a desirable
characteristic or quality of the MCRS.
• For each non‑functional requirement in MoReq2010® the rationale,
reason, or premise is listed first and is then followed by the non‑func‑
tional requirement.
• Each non‑functional requirement is expressed as an open or closed
question that is addressed to the supplier of an MCRS solution, for
example ‘How does the records system ensure …’ or ‘What provision
does the records system make for …’.
• MoReq2010® does not require that products or installations be tested
for compliance against non‑functional requirements and makes
no provision for this in the MoReq2010® test framework, although
non‑functional requirements may be assessed by individual organisa‑
tions outside of the test framework.
• However, to be certified against MoReq2010®, each supplier must
document and submit, as part of the pre‑qualification phase of testing
and certification, its responses to the non‑functional requirements,
as they relate specifically to the product or service being put forward
for testing (this process is described under 12.2.4 Addressing the
non-functional requirements).
12.1.3 what the non-functional requirements cover

The non‑functional requirements take into consideration the following
aspects of an MCRS and are described in greater detail in 12.3 the
non-functional aspects of a records system. Each records system must
have the qualities of:
• performance,
• scalability,
• manageability,
• • portability,
MoReq2010
• security,
• privacy,
• usability,
for Records Systems
• accessibility,
• availability,
• reliability,
• recoverability,
• maintainability,
• supported,
• warranted, and
• compliance.
Volume 1
MoReq2010® does not necessarily provide a comprehensive, nor exhaustive,
Core Services list of non‑functional requirements for records systems, covering all these
& Plug-in Modules aspects. In many cases, these will be specific to a particular organisation,
industry, type of system, environment or legislative or regulatory regime.
The importance placed on particular non‑functional requirements will also
Version 1.1 be different for different stakeholders.
170
1
Non-functional
12.1.4 Addressing the non-functional requirements requirements
The DLM Forum Foundation’s procedures for certifying products and instal‑
lations against the MoReq2010® specification require a number of steps.
Before formal testing of a product or installation can begin, the supplier
must complete a pre‑qualification process. As part of this process, the
supplier must describe the product or installation that is being put forward
for certification. This includes providing detailed written responses to each
of the requirements, both functional and non‑functional, for the core serv‑
ices and modules of MoReq2010® being tested.
For this reason, the non‑functional requirements of MoReq2010® are
expressed as questions and suppliers must document their answers to each
of these questions in respect to their particular product or installation. The
accredited test centre will then test the product or installation against the
functional (only) requirements of MoReq2010® using the test framework.
On the successful completion of the functional testing phase, and following
any necessary corrections to the supplier’s original responses, the suppli‑
er’s responses to both the functional and non‑functional requirements will
then be incorporated into the full test verification report along with the test
results and the test centre’s recommendation. Under various legal terms
and conditions, separately specified and managed by the MoReq Governance
Board, test verification reports for certified products will be made available
to be accessed and viewed by members of the DLM Forum Foundation.
Therefore, while the supplier’s product or installation is never formally
tested against the non‑functional requirements, by their inclusion in the test
verification report, the supplier’s responses to the questions raised by the
non‑functional requirements does become an important reference resource.
The supplier’s responses can be instrumental in helping consumer organi‑
sations find the best fit between their own local, organisational needs and
the range of MoReq2010® certified solutions available on the market.
This inclusion of non‑functional requirements in the certification process,
even though they are not formally tested, underlines their importance and
lends additional weight to their consideration under MoReq2010® than they
received in previous versions of the specification.
12.1.5 testing the non-functional requirements •

MoReq2010
While the MoReq2010 test framework does not make provision for formal
®
testing against the non‑functional aspects of records systems, this should

not be interpreted as meaning that non‑functional requirements can never Modular Requirements
be empirically tested or measured. Many organisations may wish to do this for Records Systems
as part of their own evaluation processes against their own local assess‑
ment criteria.
Unlike the testing of functional requirements, where a records system is
likely to be passed or failed on each individual criterion, evaluating compli‑
ance or non‑compliance against non‑functional requirements is a more
subjective exercise. Often this will result in the records system receiving a
score against a scale or continuum.
For example, a non‑functional requirement may state that a records system
must be provided with adequate user documentation. How is this to be eval‑
uated? What is the meaning of the word ‘adequate’? Each organisation must Volume 1
judge this for itself.
Core Services
One way to assess the quality of user documentation may be to give it to a & Plug-in Modules
sample group of users drawn from the organisation, ask them to evaluate
and use it under various simulated test conditions and then rate it against
various criteria such as the following. Version 1.1
171
1
Non-functional
requirements • Was it indexed and organised logically?
• How long did it take to find the relevant section?
• How much assistance did it provide in a carrying out the task?
• Were there any areas where insufficient documentation was provided?
• Did it use suitable language and could you understand any jargon?
The users may subsequently be asked to rate their experiences with the user
documentation on a five‑point Likert scale such as the following example.
1. Unusable, unintelligible or missing.
2. Poor or patchy documentation.
3. Acceptable and understandable, once the section was found.
4. Good quality, well laid out and indexed.
5. Excellent, relevant, easy to find and extremely helpful in use.
This process of trialling a system with a pilot group of users from the organ‑
isation and collating their responses is usually described as ‘user accept‑
ance testing’ of a records system and is one of a number of evaluation
approaches that include, but are not limited to:
• user acceptance testing;
• security/penetration testing;
• load testing;
• stress testing;
• installation and configuration testing;
• disaster recovery testing;
• interoperability testing; and
• environmental testing.
The non‑functional aspects of records systems may also be evaluated
against external standards and specifications where these are applicable:
for example, assessment against the ISO/IEC 27000 series on information
security standards (ISO/IEC 27000:2009: Information Technology — Security
techniques — Information security management systems — Overview and
•
MoReq2010 vocabulary). There may also be localised requirements applicable to a
particular jurisdiction. For example, within the United Kingdom, the British
Standard BSI DISC PD0008 relating to the Legal Admissibility and Evidential
Modular Requirements Weight of Information Stored Electronically (2009) is accompanied by a
for Records Systems workbook that allows an organisation to carry out an independent assess‑
ment in relation to a particular installation.
Where there are relevant standards, such as those already described, they
often provide a benchmark against which individual products and installa‑
tions can be judged. Otherwise, the assessment of non‑functional require‑
ments may need to be relative rather than absolute, requiring the evaluation
of two or more records systems against each other, to discover, by direct
side‑by‑side comparison, which is the more suitable when judged against a
particular non‑functional requirement.
Volume 1 Apart from direct observation and evaluation, organisations may also
usefully verify and adjudicate suppliers’ responses to the non‑functional
Core Services requirements for MCRS solutions, as contained in the test verification
report, by undertaking reference checks and site visits to existing installa‑
& Plug-in Modules
tions that have already been deployed and are already using the supplier’s
solution. Other comparable organisations can often supply useful empirical
Version 1.1 data against the non‑functional requirements, such as:
172
1
Non-functional
• the number of support issues which have been raised; requirements
• the supplier’s responsiveness to critical issues;
• the amount of user training required;
• the percentage of system uptime over a particular period;
• the frequency of product upgrades;
• the general level of satisfaction amongst the user community;
• etc.
It is important when assessing and evaluating non‑functional requirements
that the needs of all the various stakeholders within the organisation are
taken into account. Organisations may wish to formalise the acceptable level
of performance against the non‑functional requirements of MoReq2010® by
entering into a service level agreement (SLA) with the supplier.
12.2 tHE NoN‑FUNCtIoNAl ASPECtS oF A RECoRDS

SyStEM
12.2.1 Performance
Performance relates to the responsiveness, efficiency and throughput of the
records system under load. It is difficult to properly evaluate on a demon‑
stration system or in a pilot study or model office and may change consider‑
ably when the whole organisation is using the records system. Performance
is often also highly dependent on hardware, such as network bandwidth,
CPU cores and cycles, memory capacity, available storage space on hard
drives, etc. One bottleneck may cause the whole installation to slow down.
The organisation and the supplier may put in place a service level agree‑
ment over performance that stipulates how long it should take to create a
record, how long it should take to find and retrieve a record, etc.
12.2.2 Scalability
Scalability relates to the performance and capacity of the system over time and
under increasing load. As the number of records grows along with the number
of users and the consequent load on the system, how easy is it for the records
system to maintain the same level of performance stipulated under N12.3.1? •
MoReq2010
Suppliers often seek to make provision for scalability by either:
• scaling up — increasing the size and capacity of the records system; or
• scaling out — balancing the increased load between several records Modular Requirements
systems, or across multiple services. for Records Systems
Organisations may wish to stress test new records systems before they
deploy them to assess both their performance and their scalability.
12.2.3 Manageability
A records system must make provision for its own management and admin‑
istration. There are two aspects to this.
Technical administration of the records system includes:
• installation and configuration;
Volume 1
• monitoring the utilisation of system resources;
• adding additional storage and other capacities as required; Core Services
• accessing and managing the error log; & Plug-in Modules
• upgrading the records system; and
• troubleshooting and resolving technical issues. Version 1.1
173
1
Non-functional
requirements Management of the records system from the perspective of the records
manager includes:
• administrative reporting;
• usage statistics on usage of the system by users, for example the
number and types of searches performed;
• collation and monitoring of statistics on the number of records and
related entities of various types under management;
• provision of facilities to allow auditing of the records system;
• etc.
12.2.4 Portability
Portability refers to the ability of the records system to operate successfully
within different environments. A records system may be designed to execute
only within a single technology stack provided by a single operating system
vendor, such as within Microsoft’s Windows server and client environments,
or a records system may be cross‑platform.
Some records systems have a server component, which is tied to a partic‑
ular operating environment, and support a client component that is not.
In the interests of portability, a supplier may choose to provide a range of
different clients for the web and for particular platforms, operating systems
and mobile devices.
For records systems that are intended to interface directly to other business
systems, portability is dependent on the solution’s support for a range of
different interfacing standards and technologies, for example a Java inter‑
face, web services or REST‑based APIs.
Where a records system is only a specialised component of a wider business
system, there may be little choice about which technology or technologies it
supports. For example, a records system may be developed to support and be
a part of a particular customer relationship management (CRM) solution.
Portability also extends to the degree with which a solution can be custom‑
ised for different environments, although customisation and installation
options, while useful, can also be problematic for records systems as
explained under 12.2.15 Compliance.
•
MoReq2010 12.2.5 Security
Security relates to the external integrity of the records system and its ability
Modular Requirements to withstand unauthorised access, hacking or tampering, computer viruses,
for Records Systems and other forms of accidental or malicious damage. Penetration testing and
security assessments under the ISO 27000 information security standards
are recommended.
Ideally a records system should be:
• physically secure — with restricted access to hardware, equipment
and installed software integral to its operation;
• secure in its data — ensuring that the information stored on server and
client devices is not accessible except through the application itself;
• secure from unauthorised access — requiring one or more factors of
authentication;
Volume 1
• secure in its communications — utilising digital certificates and
Core Services encryption where possible to ensure that information is exchanged
only with the intended recipient; and
& Plug-in Modules
• internally secure — enforcing access controls that do not allow diffe‑
rent users to perform functions and access entities where they are not
Version 1.1 explicitly granted permission to do so.
174
1
Non-functional
12.2.6 Privacy requirements
Closely related to security, it is important that any records system respect
the privacy of personal information and data. This is particularly important
for records systems intended to hold sensitive information such as medical
records.
Many countries, both in and outside Europe, observe provisions about the
privacy of personal information. Each records system must comply with
these regulations and protect the rights of citizens in the local jurisdiction
where it is deployed.
For example, the Data Protection Directive (Directive 95/46/EC of the
European Parliament and of the Council of 24 October 1995 on the protec‑
tion of individuals with regard to the processing of personal data and on the
free movement of data) regulates the processing of personal data, makes
provision for notifying subjects when their personal data is held, including
the guarantee of a right of access and a right to object, and places restric‑
tions on the transfer of personal data to third countries. This has direct
relevance to records systems — for example where the entities in a records
system are stored, particularly in relation to an international or cloud‑based
storage service provided by an MCRS.
12.2.7 Usability
Ease of use is an important consideration in records systems, especially for
user acceptance. Experience shows that users will bypass a system that is
overly complex or time consuming to use. This has serious consequences
for records systems in organisations if important records are not being
captured or employees are not taking advantage of the accumulated corpo‑
rate knowledge they contain.
Some of the features of a records system that contribute most to usability
include:
• clean, uncluttered and familiar interfaces;
• consistency throughout the application and with the operating
environment;
• system responsiveness;
•
• informative error messages and dialogues; MoReq2010
• automated processing, providing useful defaults, and other ways of
minimising the number of decisions users must make;
• minimising the number of user actions required to perform an
for Records Systems
operation;
• providing alternative ways of executing common functions, such as
through keyboard key combinations, toolbar buttons, etc.;
• enabling bulk processing;
• support for internationalisation;
• support for personalisation and localisation;
• context‑sensitive help facilities;
• high quality user documentation; Volume 1
• frequently asked questions; and
Core Services
• online videos and tutorials.
& Plug-in Modules
Training and education programmes are often essential to the uptake and
acceptance of new systems and records systems are no different in this
respect. Version 1.1
175
1
Non-functional
requirements 12.2.8 Accessibility
Closely related to usability, records system should, ideally, be accessible
to all types of users with different capabilities, including those users with
specific disabilities. Such users have an important part to play in all areas
of human activity where they will regularly interact with records systems.
Many exemplar business organisations protect the rights of their employees
to access any of their technical systems and, as a consequence, will only
purchase solutions that incorporate a wide provision for accessibility.
A leading proponent of the active evaluation of non‑functional requirements
for accessibility is the World Wide Web Consortium’s (W3C) Web Accessibility
Initiative (WAI). The W3C’s WAI issues the Web Content Accessibility
Guidelines (WCAG) which cover recommendations for making web content
more accessible.
‘Following these guidelines will make content accessible to a wider range
of people with disabilities, including blindness and low vision, deafness and
hearing loss, learning disabilities, cognitive limitations, limited movement,
speech disabilities, photosensitivity and combinations of these. Following
these guidelines will also often make your web content more usable to
users in general’ (WCAG 2.0:2008, Abstract).
Against each guideline, the WCAG provide success criteria which may
be tested and evaluated. These test criteria allow for three levels of
conformance:
• A — the solution meets the mandatory checkpoints;
• AA — the solution meets the mandatory and the highly desirable
checkpoints; and
• AAA — the solution meets the mandatory, highly desirable and desi‑
rable checkpoints within the WCAG specification.
Although the WCAG specification is intended for web applications, accessi‑
bility is an important consideration for all records systems, and these same
principles should be adopted across all platforms.
12.2.9 Availability
• Availability requirements are important considerations for assessing which
MoReq2010
records systems’ implementations will be suitable for an organisation’s
business practices and is often expressed as a percentage or a ratio of
Modular Requirements system uptime compared to down time.
for Records Systems Depending on the nature of the organisation, some organisations require
access to the records system during business hours on weekdays, whereas
other organisations require 24/7 access and support. Not all records
systems are capable of running indefinitely without requiring regularly
planned maintenance, upgrade and backup windows when they must be
taken offline. However, every business also has certain critical periods
where system availability is essential.
The level of availability that a particular solution can provide should be clearly
stated by the supplier in response to the non‑functional requirements. This
Volume 1 should also be included in any service level agreements between the supplier
and the organisation. Where the records system is hosted by a third‑party
Core Services provider, a separate service level agreement covering the provision of the
hosting service may also be necessary. Likewise, the organisation should
& Plug-in Modules
be realistic about its need for utilising the records system at all times of the
day or night, as 24‑hour service and support from the supplier or service
Version 1.1 integrator will necessarily come at a higher cost to the organisation.
176
1
Non-functional
If an organisation has agreed to a particular level of records system avail‑ requirements
ability in a service level agreement, system availability should be closely
monitored to see whether the agreed service targets are being met, or
exceeded. Aside from any penalty clauses included in the service level agree‑
ment, monitoring system uptime, especially against system utilisation, will
provide useful feedback to both the supplier and to setting the expectations
of the organisation around the availability of its records systems.
12.2.10 Reliability
Reliability describes the internal integrity of a system, the precision and
accuracy of its software, and its resilience to defects, malfunctions and
unexpected operating conditions. It is possible to apply proof of correct‑
ness algorithms to records systems, as well as assessing their tolerance
of invalid data and other unexpected occurrences, such as a sudden loss of
communication. Truly robust records systems will be able to handle error
conditions gracefully, without crashing or sudden failure.
Reliability is also closely related to system availability and reliability is often
measured as the ‘mean time between failures’. More reliable systems will,
therefore, have more system uptime and far less unplanned down time, making
them more available. Equally, a more reliable records system will generally be
one that is easier to maintain and actively supported by the supplier.
The MoReq2010® test framework can be used by accredited test centres to
check the functional requirements of a compliant records system and this
provides one measure of the reliability of a records system in performing the
essential tasks of records management. However, the test framework does
not, by itself, test all the possible inputs and outputs of a records system
and an organisation may not wish to rely solely on this single measure when
comparing the quality and reliability of different records systems.
12.2.11 Recoverability
Should a records system fail for any reason, it is important that the organi‑
sation is able to recover it with its data largely intact. Operations that
were occurring at the moment of failure may not be able to be recovered;
however, the organisation must be equally sure that it is not dependent on
backed‑up information that is more than a day old, especially in high volume •
MoReq2010
environments.
Not only must the records system be recovered or rebuilt, but this must also
be done in a timely manner to avoid any unnecessary impact on the critical Modular Requirements
business of the organisation. A disaster recovery process that means that for Records Systems
the records system is offline for several days or weeks may not be suitable
for many businesses. For other businesses, unscheduled down time of even
a few hours may be too long.
As with other non‑functional requirements, requirements around disaster
recovery will vary substantially between different organisations. It is essen‑
tial that the needs of the organisation are assessed prior to any disaster
occurring and that a full and comprehensive business continuity plan be put
in place across the organisation.
Experience shows that business continuity requirements must be planned Volume 1
across all business‑critical systems and not just for individual systems, such
as the records system. This is because the records system forms only part Core Services
of the corporate infrastructure. If the records system, for example, depends
& Plug-in Modules
on particular hardware, then the organisation must have access to replace‑
ment hardware in a time frame that meets the targets set for recovery of
the records system. Version 1.1
177
1
Non-functional
requirements It is also good practice to regularly perform disaster recovery testing so that
staff know the process and procedures for restoring the records system after
any system failure and realistic timings for full system recovery are known.
As the amount of data managed by the records system grows over time, the
organisation’s expectations over the period of time required to recover the
records system may not keep pace with the actual period required to physi‑
cally transfer the organisation’s data into a newly rebuilt system.
Some mission‑critical organisations cannot allow for hours, or even
minutes, of down time for disaster recovery. These organisations must
consider running multiple parallel systems with mirrored data that enable
them to switch between their live and reserve records systems on hot
standby, warm standby or cold standby. Or alternatively, an organisation
may run a single system but with many layers of built‑in redundancy that
allows, for example, the hot swapping of individual hardware and software
components such as computers, routers and hard drives while the system,
as a whole, remains operational.
Recoverability, like availability, will cost the organisation more for each
higher degree of redundancy and immediacy specified. Organisations must
be careful, therefore, to understand their own disaster recovery needs and
to specify realistic targets within their business continuity plans. Where
meeting these targets is mission‑critical, the organisation should seek to
test recoverability and to put in place a service level agreement with the
supplier to ensure that the records system will comply with the organisa‑
tion’s operational requirements.
12.2.12 Maintainability
A records system must be maintainable, meaning that it must be relatively
easy to repair and upgrade. Most suppliers will have a system of major,
minor and maintenance versions, which might variously be called some‑
thing like: new versions, service packs and patches.
Each of these will have a cost associated with its deployment in terms of the
resources and time taken to deploy across the organisation and, where they
incorporate new features and functions, there may also be a retraining and
•
MoReq2010 educational cost for users. As a general rule, the more major the release, the
more likely it is that there will be an impact on the organisation, including,
possibly, migrating data from the earlier version.
Records systems are not always built from components from a single
for Records Systems
supplier. Often suppliers licence (or ‘OEM’) components such as search
engines and databases from other suppliers, or deploy open source equiv‑
alents within their applications. Reuse, or bringing different technologies
together can be far more efficient that a single supplier reinventing every
records system component. However, organisations should be aware of
the underlying patchwork of different technologies within their records
systems as these may individually need upgrading at different times and
for different reasons.
For example, a records system may use a well‑known database engine made
Volume 1
by an independent database supplier. Whenever that supplier upgrades or
Core Services patches the database software, these changes must be retested for compat‑
ibility with the records system solution. Upgrades to the records system
& Plug-in Modules must, therefore, keep pace with upgrades to its database engine. This same
situation may equally apply to the search engine, the storage solution, and
Version 1.1 other parts of the records system.
178
1
Non-functional
12.2.13 Supported requirements
Regardless of how maintainable the records system is, the supplier must
actively support it. Experience shows that many organisations have legacy
systems where the supplier is no longer in business, or has decided to
maintain but not to upgrade a particular records system solution.
Therefore, before purchasing a records system, an organisation should
request details of the level of support given to the product, how often it
is upgraded, when the last version was released, and what the supplier’s
roadmap is for the records system.
Organisations should understand that the modern information technology
marketplace is highly volatile and even these precautions may not prevent a
particular records system from failing to be supported in the future, even by
the biggest of suppliers. Fortunately, MoReq2010® provides some consola‑
tion through its support for interoperability. At worst, the organisation may
have to migrate its records from its old MCRS to a new MCRS solution.
Support also refers to the level of day‑to‑day support provided by the
supplier organisation or a third‑party on behalf of the supplier organisation.
Organisations should seek to learn how to request assistance from the supplier,
how to report errors and software bugs, and what level of on‑site support and
assistance to expect. Many suppliers have active user groups where different
organisations come together to share experiences, hints and tips, and other
information about how best to utilise a particular records system.
12.2.14 warranty
Organisations should be fully aware of the licensing and other terms and
conditions related to installing and using a particular records system from
a particular supplier. Even open source solutions have intellectual property
rights and usage conditions associated with them.
In agreeing to the supplier’s terms and conditions in implementing a records
system, an organisation must also ensure that it receives a warrant from
the supplier covering the use of the records system and agreeing to fix any
issues encountered in its deployment and use by the organisation.
Many organisations require that the source code of a records system be
placed into escrow so that should anything happen to the supplier, the •
records system remains supportable. Again, as in the previous section, MoReq2010
MoReq2010® actively seeks to remove the possibility that data will be lost
from an unsupported records system by ensuring that every MCRS includes
the basic functionality of full‑system export, to enable the lossless migra‑ Modular Requirements
tion of records and entities to another MCRS. for Records Systems
12.2.15 Compliance
The final non‑functional aspect of a records system is its level of compliance.
This has already been mentioned within other criteria. Records systems
may need to be compliant with industry standards and local regulations in
the following ways.
• They must be compliant with the MoReq2010® specification.
• They must comply with all legislative and regulatory standards that
apply to the organisation, in the industry and under the jurisdiction Volume 1
where they are deployed, such as health and safety regulations or
Core Services
freedom of information.
& Plug-in Modules
• They should comply with widely used and accepted industry standards
in technology and on the platforms where they are deployed, such as
HTML and HTML5 for web browser‑based applications. Version 1.1
179
1
Non-functional
requirements • As required by the organisation, they should seek to be compliant with
popular document formats, such as PDF, enabling the records system
to examine the structure of these documents, extract their metadata,
and index their content for searching, especially within organisations
where the purpose of the records system is to manage and maintain
records in these formats.
As the compliance requirements of records systems can be so broad and
can vary depending on local conditions, many suppliers build a degree of
configurability into their solutions. While configurability is often a very posi‑
tive feature of an application, it can also be a threat to compliance when
applied to a records system. This is especially true if the configuration and
installation options allow essential records management functionality to be
manipulated or turned off.
The non‑functional requirements of MoReq2010® require that suppliers indi‑
cate if their systems allow customisation options which may invalidate the
functional requirements of MoReq2010®. Where this occurs, it is essential
that the organisation checks that the records system remains MoReq2010®
compliant after it has been installed and become operational. This can be
done using the compliance reporting features of MoReq2010® (see func‑
tional requirement R2.4.5).
12.3 NoN‑FUNCtIoNAl REqUIREMENtS

FoR PERFoRMANCE
N12.3.1 In assessing the performance of a records system, it is important to understand
the purpose of the records system and the nature of the records that can be
created and stored.
What is the records system designed for and what types of records can it
manage?
N12.3.2 It is also necessary to understand the size and complexity of the average deploy-
ment. Often this is described in terms of the:
• number of simultaneous users;
•
MoReq2010 • system utilisation percentage per user;
• number of records under management;
Modular Requirements • space occupied by an average record;
for Records Systems • amount and type of storage space required, including search indices and
other system requirements; and
• number of servers and types of server required.
What is a typical small deployment, medium deployment and large deploy‑
ment of the records system?
(Give examples where possible.)
N12.3.3 Records systems have different cycles of usage. It is important to understand

Volume 1 whether a particular records system will suit the sustained workload of the
organisation.
Core Services For each of the typical deployments described in N12.3.2, describe their
& Plug-in Modules typical usage of the records system during normal operations and indicate
what might be considered periods of peak load?
Version 1.1 (Give examples where possible.)
180
1
Non-functional
N12.3.4 Throughput can be measured by the number of records that can be captured requirements
into the records system.
For each of the typical deployments described in N12.3.2, how many records
can be captured and simultaneously retrieved per hour on average, during
normal operation and in periods of peak load, as described in N12.3.3?
N12.3.5 An important measure of system performance is how long users spend

searching on average.
For each of the typical deployments described in N12.3.2, how long, on
average, is a search across three metadata elements, such as Title, Class
and Created Timestamp, that returns 100 records, during normal operation
and in periods of peak load, as described in N12.3.3?
N12.3.6 Some records systems implement a timeout interval if searches take too long.
What is the longest possible search time for any search and can it be
configured?
N12.3.7 Another measure of system performance is how regularly each record is

assessed for disposal. Some records systems may do this in real time, or peri-
odically at scheduled intervals.
MoReq2010® allows the disposal process described in R8.4.14 to occur
periodically and it must be performed at least daily; how regularly should
the records system perform this process for each of the typical deployments
described in N12.3.2?
(Where the records system adopts an alternative design approach, provide
an explanation of its effects, both beneficial and detrimental, on perform‑
ance, scalability and other factors.)

FoR SCAlABIlIty
N12.4.1 Some systems are restricted by technical or other limitations such as database
size, file system segmentation, single server utilisation, etc. These limitations •
MoReq2010
may apply to:
• the maximum number of simultaneous users;
• the maximum number of concurrent users;
for Records Systems
• the maximum number of entities, including records;
• the storage space used by the records system; and
• the hardware that can be deployed to support the records system.
In particular, organisations want to achieve scalability while still protecting their
investment in hardware and other resources. Records systems should, there-
fore, provide means by which additional capacity can be added to an existing
system without migrating it to a new environment.
What are the upper limits of scalability for each of the typical deployments
Volume 1
described in N12.3.2, without replacing existing hardware?
Core Services
N12.4.2 The MoReq2010® specification imposes no theoretical upper limit on how
& Plug-in Modules
many entities, how much metadata, how many users and how much content
an MCRS can hold. There may, however, be practical considerations with any
records system. Version 1.1
181
1
Non-functional
requirements For each response to N12.4.1, what strategies should an organisation
put in place to expand its deployment of the records system beyond these
technical limits, assuming the number of users doubles and the number
of records increases fivefold over a period of three years?
N12.4.3 As a records system is scaled up and out, the performance of each of the func-
tions performed by the system may be affected.
For each response to N12.4.2, what will the impact be on the following?
• The throughput of the system described in N12.3.3
• The average search time described in N12.3.4
• The search timeout described in N12.3.5
• The regularity of the periodic disposal process described in N12.3.6
N12.4.4 Records systems may also impose internal limitations on the numbers, types
and relationships between entities. For example, the classification service
may have an upper limit on the number of classes it may contain.
What are the technical limits in the records system of each of the
following?
• The number of entities that can be managed by any service, or bundle
of services under R2.4.1
• The number of root aggregations that can be added to the record
service
• The number of entities, either child aggregations or records that can
be added to an aggregation
• The depth or number of levels of aggregation under a root
aggregation
• The number of components in a record
N12.4.6 As the number of entities in a records system grows, not just search times
but the number of results returned by a search will also grow. Some search
engines approximate the total number of entities rather than calculate it for
searches that return a large number of entities. Search engines also have
•
MoReq2010 different ways of determining the relevance of searches.
What is the maximum number of search results that the records system
will find and return and what mitigating strategies does the search engine
Modular Requirements use to make the first few search results more relevant?
for Records Systems
N12.4.7 Requirement R10.4.16 requires that an MCRS allow users to chain or join
several search queries so as to answer complex search enquiries.
What limits the number of chains or joins the records system can include
in a search under R10.4.16 and what is the impact of chaining or joining
searches on the following?
• The search response time
• The relevance of search results
Volume 1
Core Services
& Plug-in Modules
Version 1.1
182
1
Non-functional
12.5 NoN‑FUNCtIoNAl REqUIREMENtS requirements
FoR MANAGEABIlIty
N12.5.1 It is important to understand how the organisation should go about installing and
configuring the records system: this is often done as part of a wider project.
How is a new instance of the records system installed and configured and
who should undertake this work?
N12.5.2 While the records system is in operation, its resource usage should be moni-
tored to ensure that the system has adequate reserves. Measuring of resource
usage can extend to the:
• number of users accessing the system and at what times and on what days;
• amount of storage being used and rate of increase;
• average search time and rate of increase or decrease;
• traffic, in terms of functions performed, and rate of increase or decrease;
• average response time to all functions; and
• CPU and memory utilisation.
What means are employed by the records system for measuring resource
usage?
N12.5.3 Resource usage may reach a critical point where more resources must be given
to the system. It is important that technical administrative staff anticipate this
and add more resources as required, for example by increasing the storage
space available before the existing storage space is exhausted.
How does the records system, while monitoring resource usage under
N12.5.2, warn technical administrators of anticipated resource shortages,
and can resource thresholds be preset?
N12.5.4 It may be possible to increase the resources available to the records system but
this may be a difficult task and, for some records systems, require a mainte-
nance window of system down time.
What capacity exists for increasing the resources available to the records
system and how is this done? •
MoReq2010
N12.5.5 In addition to monitoring and warnings for resource usage, it is useful to collate
reports and statistics over time so that trends emerge.
What long‑term statistical reporting facilities exist for the records system for Records Systems
for the analysis of resource utilisation under N12.5.2?
N12.5.6 Requirement R2.4.7 stipulates the use of an external error log. Different types
of records system use different error logs.
Describe the error log used by the records system under R2.4.7. How is it
accessed and used? What mechanisms exist for warning technical adminis‑
trators when the records system fails to perform a function?
N12.5.7 Requirement R8.4.15 requires that users authorised to receive alerts for an
aggregation or record whenever a disposal action has not been carried out Volume 1
and confirmed by the due date. Different types of records system use different
Core Services
alerting mechanisms.
& Plug-in Modules
Describe the alert mechanism used by the records system under R8.4.15.
How do authorised users receive the alert and what mechanisms exist for
consolidating alerts, as described in the rationale to R8.4.15? Version 1.1
183
1
Non-functional
requirements N12.5.8 From time to time, the records system may be audited. The following list is
non-exhaustive, but auditors may wish to check that:
• only appropriate users and groups have access to the records system;
• all appropriate users and groups have access to the records system;
• appropriate security controls and access controls have been set;
• users are not accessing records and other entities they are not permitted
to access;
• the classification service configuration is appropriate for the business;
• the disposal scheduling service configuration is appropriate for the
business;
• all relevant records are being captured by the records system;
• records are being placed into the appropriate aggregations;
• records are being classified correctly;
• users are not inappropriately overriding the default disposal schedules of
records;
• no records or other entities are being deleted from the records system,
outside the disposal process;
• disposal periods are being monitored and disposal due dates are being
met;
• confirmations occur within the disposal due date and records are not
overdue for disposal;
• record content is being disposed of correctly; and
• copies of record content are being deleted from secondary sources within
the organisation immediately following, or in concert with, the formal
disposal of the record.
What facilities exist for auditing the records system and how should this be
carried out?

FoR PoRtABIlIty
• N12.6.1 The records system may operate on many platforms or just one. It may have a
MoReq2010 limited number of server configurations but support several different clients.
What operating systems and platforms does the records system use and
Modular Requirements which parts of the records system, including server and client‑based system
modules, are deployed on to which technologies?
for Records Systems
N12.6.2 As described in 3. User and group service, an MCRS may utilise a popular direc-
tory service, such as an LDAP directory, and provide a wrapper for capturing
historical data about users and groups, or it may provide its own user and group
management service.
Which directory services does the records system interface to, if any, and
how is historical information about users and groups preserved as entities
within the user and group service?
Volume 1 N12.6.3 Many records systems utilise third-party software components such as database
technologies and search engines. Where these are integrated into the product,
Core Services they have the advantage of reuse but the issues associated with managing inde-
& Plug-in Modules pendent development cycles.
What OEM, third‑party or open source system services does the records
Version 1.1 system incorporate?
184
1
Non-functional
N12.6.4 Many records systems provide interfaces and API sets to other applications. requirements
What other business systems can the records system integrate to, if any?
What API sets are available and what technologies do they support?
N12.6.5 Platform support may place limitations on metadata and templates. For
example, MoReq2010® does not restrict the maximum length of a text field;
however, this may be restricted by database table sizes.
The records system may adopt the model metadata service (see 7. Model meta‑
data service) or it may implement its own approach to metadata.
What approach is used by the records system to managing metadata and
what is the impact of this approach on the following?
• The number of contextual metadata elements that can be applied to
an entity of any entity type
• The number of contextual metadata element definitions that can be
included in a template
• The use of templates
• The maximum length of a metadata field
• The datatypes supported by the records system

FoR SECURIty
N12.7.1 R3.4.1 specifies that the MCRS must only by accessed by authenticated users.
The MCRS may support one or a number of commercial or proprietary authen-
tication services, or the authentication service may be built in.
On each of the platforms listed under N12.6.1, and for each of the directory
implementations listed under N12.6.2, which authentication technologies
does the records system support?
N12.7.2 Depending on the records system’s implementation of the model role service,
there may be particular restrictions that apply to roles and access control. •
MoReq2010
The records system may adopt the model role service (see 4. Model role service)
or it may implement its own approach to access control. If the records system
uses its own approach to access control, it might not have the same level of Modular Requirements
granularity as the MoReq2010® model role service. for Records Systems
How does the records system implement internal access control and what
constraints does it impose on the following?
• The roles predefined and fixed by the records system
• The number of additional roles that may be defined
• The function definitions that may be included in roles
• The entities that have access control lists
• Inheritance and other features of access control entries Volume 1
N12.7.3 Authentication and access control are of little value if the information stored by Core Services
the records system can be accessed directly. & Plug-in Modules
What mechanisms does the records system rely on for restricting access to
its stored data? Version 1.1
185
1
Non-functional
requirements N12.7.4 Similarly, when the different components of the records system communicate
with one another either internally, for example between client and server, or
externally, for example with another business system, their communications
should be secured to avoid snooping and man-in-the-middle attacks.
What technologies are used to ensure that communication between the

components listed in N12.6.1, N12.6.2, N12.6.3 and external systems listed
in N12.6.4 is secured?
N12.7.5 Suitable controls should be embedded into the records system and/or its oper-
ating environment to prevent it being exploited by viruses, Trojan horses, and
other malicious code. For example, a records system may be vulnerable to SQL
injection attack through the metadata elements of entities.
What antivirus and other security strategies are integrated into the records
system or are recommended as part of the records system’s normal opera‑
tional environment?
N12.7.6 The records system may have been designed and implemented to meet various
well-known security standards and penetration tests. Standards such as
ISO 27000 do not assess individual products alone but are made in relation to an
organisation’s whole security strategy and practice.
What types of secure environments is the records system designed for? Which
national or international regulations does it cover and which jurisdictions?
(The product or an existing site installation may have received an inde‑
pendent security assessment or rating.)
12.8 NoN‑FUNCtIoNAl REqUIREMENtS FoR PRIVACy

N12.8.1 The records system may incorporate mechanisms for addressing important
issues for privacy, such as the protection of personal data, but also, and especially
in government contexts, the individual’s right to access public information.
•
MoReq2010 Where applicable, how does the records system address the following?
• Data protection
• Freedom of information
for Records Systems
(Indicate the jurisdictions under which individual responses apply.)
N12.8.2 The records system may have been assessed for its relevance to particular
privacy laws, such as the Data Protection Directive (Directive 95/46/EC). Where
this has occurred, the records system may incorporate special features such as
restrictions on which data is moved between different internal data stores. This
is particularly relevant if the deployment of the records system crosses interna-
tional boundaries.
Volume 1
Has the records system been specifically designed for conformance with any
Core Services national, international or good practice privacy guidelines or regulations?
& Plug-in Modules (The product or an existing site installation may have received an inde‑
pendent assessment or rating against specific regulations in a particular
Version 1.1 jurisdiction.)
186
1
Non-functional
12.9 NoN‑FUNCtIoNAl REqUIREMENtS requirements
FoR USABIlIty
N12.9.1 The records system must be accompanied by user and technical documentation
to facilitate its assessment by a MoReq2010® accredited test centre.
What user and technical documentation is available to users and technical
administrators of the records system?
N12.9.2 Users generally need training and education to utilise a records system effec-
tively. This is especially true of specialised users such as technical administra-
tors, security managers, auditors and, most importantly, records managers.
What training do users with different degrees of specialisation require to
use the records system effectively? What training courses, tutorials and
other educational and learning resources are available for general and
specialised users?
Other non‑functional requirements for usability are addressed by the

non‑functional requirements for plug‑in modules in the MoReq2010® 100.
Interface series.

FoR ACCESSIBIlIty
N12.10.1 The records system may have been assessed under the W3C WAI Web Content
Accessibility Guidelines (WCAG). These guidelines provide a rating of A (lowest),
AA or AAA (highest).
Has the records system been independently assessed and rated against
WCAG?
(Include details of the assessment, who undertook it and the ratings
achieved.)
Other non‑functional requirements for accessibility are addressed by the

non‑functional requirements for plug‑in modules in the MoReq2010® 100.
Interface series. •
MoReq2010

FoR AVAIlABIlIty Modular Requirements
for Records Systems
N12.11.1 Records system availability is dependent on whether the records system and other
necessary support systems are running. Sometimes, these systems must be taken
offline for planned maintenance and upgrade. On other occasions, they fail.
For each of the typical deployments described in N12.3.2, what is the antici‑
pated records system availability as a percentage or ratio of records system
uptime against down time over the course of a calendar year?
N12.11.2 Where a service level agreement covering records system availability exists, some
mechanism must also be provided or suggested to allow this to be measured.
Volume 1
Where recommended for inclusion in a service level agreement, how should
the percentages or ratios given under N12.11.1 be measured and calculated Core Services
for the records system? What tools should be used and are these tools avail‑
able in the records system or from a third party? & Plug-in Modules
(Provide a description where a different form of service level agreement is
recommended to ensure a minimum level of records system availability.) Version 1.1
187
1
Non-functional
requirements N12.11.3 Some administrative operations, such as backup, require that the records
system be taken offline.
What administrative operations require that the records system be taken
offline?
N12.11.4 As systems grow, they take longer to perform certain functions, such as
backup.
How long would a typical backup take for each of the available technologies
(see N12.13.1), given the typical deployments described in N12.3.2? How
will this vary given the growth scenarios in N12.4.2?
(Take into consideration full backups and incremental backups.)
N12.11.5 Organisations must work to a schedule when administering their records

systems (see also N12.14.4).
For each of the responses to N12.11.1, what are the recommended planned
backup, maintenance or upgrade windows that should be reserved per day,
week and month throughout the year?
N12.11.6 Hosted records systems require additional consideration as they are limited by
their host’s availability.
If the records system is a hosted system, what additional availability
constraints and guarantees should be provided by the host system?

FoR RElIABIlIty
N12.12.1 R2.4.7 requires that functions be performed atomically and that no function
should be only partially successful. Atomic functions are required to ensure the
integrity of the data if the MCRS fails during an operation. If the function is not
successful, it should be rolled back.
How does the records system support atomic operations and how is the
integrity of the records system ensured if a transaction fails or the records
• system fails prior to its completion?
MoReq2010
N12.12.2 The design of the records system plays a significant role in its reliability and its
Modular Requirements ability to withstand error conditions.
for Records Systems How does the architecture of the records system affect its reliability?
N12.12.3 In addition to its architecture under N12.12.2, the methodology used to develop
the records system, including designing, checking and unit testing, plays a part
in the resulting quality of the final product.
What quality assurance controls are used in the manufacture of the records
system to ensure its correctness?
N12.12.4 The records system may have been previously assessed and given a rating for
Volume 1 the mean time between failures or measured against some other reliability or
availability instrument.
Core Services
Has the records system been independently verified, benchmarked, or rated
& Plug-in Modules in a previous installation for its reliability or availability?
(Include details of the assessment, who undertook it, and the ratings
Version 1.1 achieved.)
188
1
Non-functional
N12.12.5 Many records systems are built using a service-oriented architecture (or other requirements
resilient architecture) and some parts of the records system may be redundant
allowing individual services to fail and be restarted while the records system
remains operational.
What parts of the system, listed in the responses to N12.6.1 and N12.6.3,
can fail or be stopped and restarted while the rest of the records system
remains operational?
N12.12.6 Gracefully handling system failure means that all processes are shut down in
the right order to preserve the integrity of the system and allow it to be restarted
and continue operation once normal operating conditions have been achieved.
What hardware, software and systems support is required within the operating
environment of the records system to allow it to shut itself down gracefully in
the event of a power outage or in response to another external threat?

FoR RECoVERABIlIty
N12.13.1 Different records systems adopt different backup strategies for redundancy of
data to ensure business continuity in the event of data loss or hardware, soft-
ware or system failure. Different strategies may have different advantages,
such as speed, or disadvantages, such as cost. Backup strategies may also be
partially dependent on the backup media used. There are many different types
of backup media available, for example magnetic discs, magnetic tapes, optical
media, cloud storage, etc.
What backup strategies does the records system support? What are their
relative advantages and disadvantages and which are recommended for the
usage scenarios in N12.11.4?
N12.13.2 All organisations should develop a business continuity plan. This should include
the time required to restore systems including the records system, in the event
of a system failure.
For each of the strategies listed under N12.13.1 and for each of the usage
scenarios in N12.11.4, what is the recommended time required to restore •
the records system in the following cases? MoReq2010
• When only the data needs to be recovered

• When the records system needs to be rebuilt and the data recovered Modular Requirements
for Records Systems
N12.13.3 The business continuity plan should contain step-by-step instructions on how to
recover the records system and at least one copy should be stored outside the
records system.
For recovering the data of a records system under N12.13.2, what approaches
are required for each of the backup strategies listed under N12.13.1? What
critical considerations do they raise or address?
N12.13.4 N12.12.1 indicates that the records system should support atomic transactions.
Where these are supported and stored in a transaction log, it may be possible to Volume 1
restore a system up to the point where it failed.
Core Services
When restoring from backup under N12.13.2, does the records system
support incremental backup? During data recovery, is it able to roll forward & Plug-in Modules
to the transaction immediately before the failure?
(Describe any alternative design approach adopted.) Version 1.1
189
1
Non-functional
requirements N12.13.5 Not all records systems rely on backup and recovery to provide redundancy.
Some can be set up to mirror data and to failover to a standby system or site.
Others rely on redundancy at the level of individual drives which can be ‘hot
swapped’ while the records system stays online.
Other than backup and recovery, what other mechanisms does the records
system employ to ensure business continuity?
(Describe the mechanisms available.)
N12.13.6 Where records systems are built from many different integrated system compo-
nents, some provided by different suppliers, this may have an effect on how
the records system is managed and how it is backed up and recovered. For
example, the database may be backed up using one technology while a content
store is backed up using a different technique. They may even be backed up at
different times, which can create a synchronisation issue in putting them back
together if they both need to be restored on system failure.
What is the impact of the OEM, third‑party and open source system services,
listed under N12.6.3, on backing up and restoring the records system or on
otherwise providing for data and system redundancy and failover?
(Explain in particular how any synchronisation issues are managed if different
parts of the records system are backed up and restored separately.)

FoR MAINtAINABIlIty
N12.14.1 Most records systems support major versions, minor versions and maintenance
versions (otherwise called new versions, service packs and patches or builds).
New features are usually introduced with major releases, enhancements with
minor releases and bug fixes with maintenance releases.
How are the different versions of the records system denoted? What types
of upgrade do the different types of version cover? What is the supplier’s
release cycle for each type of version?
N12.14.2 Even when the upgrade is free, there will be costs associated with moving
• from one version of a product to the next. Using the information from N12.14.1
MoReq2010
and N12.11.5, it should be possible for an organisation to schedule planned
upgrades to its records system.
Modular Requirements For each of the releases listed under N12.14.1, what recommended upgrade
for Records Systems planning should be undertaken by the organisation using the records system?
N12.14.3 From time to time, it is necessary to fix bugs and other issues outside the
scheduled maintenance and upgrade windows: for example, if an immediate
security issue is discovered and publicised which causes a serious threat to the
organisation’s records system, or if the system becomes unstable in operation
for any reason.
What is the supplier’s policy for emergency product support and issuing hot
fixes or patches for critical errors?
Volume 1
N12.14.4 Where records systems incorporate different parts sourced from different
Core Services suppliers, this may have an impact on how product releases are made. This is
& Plug-in Modules especially true if the third-party system components are independently sourced
by the organisation and do not come directly from the supplier of the records
system. Even records systems that are substantially build by a single supplier
Version 1.1 may be dependent on different operating environments from different sources.
190
1
Non-functional
How are different OEM, third‑party and open source system services, listed requirements
under N12.6.3, managed in terms of the different releases of the records
system listed under N12.14.1 and their own separate product development
and release cycles?
N12.14.5 Not all records systems are maintained by the organisation, some are hosted by the
supplier or a third party. Where this occurs, regular updates may be made to the
records system at scheduled times over which the organisation has little control,
especially where the organisation shares a multi-tenanted hosting system.
If the records system is hosted, what are the typical arrangements for
upgrading the hosted records system? How and when are customers noti‑
fied? What is the potential impact on customer organisations for each of the
different types of upgrade listed under N12.14.1?
N12.14.6 Upgrading records systems and adding additional features also requires addi-
tional user education, to learn the new features included in the release and to
change old habits.
What release notes are issued with each release and what are the retraining
and educational requirements usually associated with the different releases
of the records system listed under N12.14.1?

FoR SUPPoRt
N12.15.1 A records system must be maintainable but it must also be currently supported
by the supplier.
When were the last releases of each of the versions of the records system
noted under N12.14.1 and what were the versions and release dates?
(Include the date the list was compiled as the latest releases will change
over time.)
N12.15.2 It is also important to know as much as possible about the supplier’s future
plans for the records system, although some of these may be trade secrets and
may also be subject to change in response to new technologies and priorities. •
MoReq2010
Is there a product roadmap for the records system? What period does it cover
(e.g. the next 18 months, three years or five years)? How often is it updated
and how is the product roadmap shared with customers and prospective Modular Requirements
customers? for Records Systems
N12.15.3 The organisation may also wish to know how it can request new product features
and influence their priority and development in the records system.
How are customers involved in requesting and prioritising new features?
(Provide an example of a feature developed as a result of a customer
request.)
N12.15.4 It should be possible to report issues of all types to the supplier and for them to
be fixed within an agreed time frame. The supplier’s policy on issuing patches Volume 1
for emergency support has already been mentioned under N12.14.3.
Core Services
What levels of support are available for the records system, can it include a
& Plug-in Modules
24/7 live support line for reporting critical issues? How do customers and
prospective customers learn about the support processes available and how
to use them? Version 1.1
191
1
Non-functional
requirements N12.15.5 The supplier should make provision for issue ticketing and tracking, especially
when issues are raised by organisations through the support process.
Are organisations able to monitor progress of the issues they raise through
the supplier’s service desk?
N12.15.6 Organisations should seek to understand how quickly they may expect an issue
to be resolved.
Are the categories of issues used, under N12.15.5, and the average resolu‑
tion times across each category over the last year available to customers
and prospective customers?
N12.15.7 Many suppliers now support active user groups, online forums, support forums,
and conferences.
Apart from the information already listed in this section, what other oppor‑
tunities exist for organisations to engage with each other and with the
supplier of the records system?

FoR wARRANty
N12.16.1 It is important to understand what assurance the supplier provides in terms of
quality and performance in relation to the records system.
Does the supplier warrant the records system and, if so, what parts of the
records system are covered for what types of issues?
N12.16.2 The organisation may also wish to agree on a service level agreement covering
the records system and aspects such as performance, availability, etc.
Does the supplier enter into service level agreements with its customers? If
so, what aspects of the non‑functional requirements of the records systems
are covered? Are the service level agreements the same for each customer
or tailored individually?
• N12.16.3 The supplier may have standard terms and conditions for customers of
MoReq2010
its records systems. It should be noted that even open source software has
licensing conditions associated with it.
Modular Requirements Are there standard terms and conditions available to customers or prospec‑
for Records Systems tive customers, or are they negotiated individually for each contract?
N12.16.4 It must be possible for the organisation to obtain access to the source code for
the records system should the supplier ever go out of business.
Is the records system an open source software application? If not, what
other means may be used to protect the customer’s access (e.g. lodging a
copy of the source code in escrow with a neutral third‑party)?
N12.16.5 It is also possible to place data in escrow, especially for hosted services.
Volume 1
Does the records system support data escrow?
Core Services
N12.16.6 Where a records system is hosted or different parts of the system are
& Plug-in Modules
provided by different suppliers, this can have unexpected consequences on
the main supplier’s terms and conditions, licence agreement, service level
Version 1.1 agreements, etc.
192
1
Non-functional
What is the impact of different parts of the system being provided by different requirements
suppliers, under N12.6.3, or hosted under N12.11.6 and N12.14.5, to the
responses to N12.16.1, N12.16.2, N12.16.3, N12.16.4 and N12.16.5?

FoR CoMPlIANCE
N12.17.1 The records system may already comply with national or international stand-
ards on records management, or related disciplines such as content manage-
ment, document management, etc.
Apart from MoReq2010®, what other records management, or related,
standards and specifications does the records system comply with and has
this been independently verified?
(For each such independent verification, include details of the assessment,
who undertook it, and the grade achieved.)
N12.17.2 The records system may comply with other regulatory and legislative frame-
works outside the immediate field of records management, at either the national
or international level. For example, the records system may be compliant with
the European Markets in Financial Instruments Directive, also known as MiFID
(Directive 2004/39/EC of the European Parliament and of the Council of 21 April
2004 on markets in financial instruments).
Apart from those standards listed under N12.17.1, what other national or
international standards or regulations does the records system comply with
and has this been independently verified?
(For each such independent verification, include details of the assessment,
who undertook it, and the grade achieved.)
N12.17.3 The records system may comply with particular technical standards, such as
HTTPS, HTML5, MD5, XML, etc.
What technical standards does the records system comply with and use?
N12.17.4 It is useful for an MCRS to provide a high level of precision for timestamps •
MoReq2010
generated under R2.4.27. Millisecond or better precision is useful for main-
taining the exact order in which events occur in high throughput systems.
What precision does the records system use for timestamps? Modular Requirements
for Records Systems
N12.17.5 It is important that, under R2.4.24, an MCRS does not generate the same system
identifiers for entities as other MCRS solutions. The algorithm used to generate
universally unique identifiers must be suitable for creating large numbers of
UUIDs without repetition, pattern or overlap with other systems.
What algorithm does the records system use for generating UUIDs?
N12.17.6 Some records systems have configuration options that allow some or all of
their MoReq2010® compliant functionality to be switched off or replaced by
non-compliant functionality. Volume 1
Where provision for this is included in the configuration options of the records Core Services
system, especially for a MoReq2010® certified product, it is important that
& Plug-in Modules
safeguards are put in place to ensure that it does not happen inadvertently.
Even though the consequences of particular installation options may be clearly
explained in technical documentation and when the records system is installed, Version 1.1
193
1
Non-functional
requirements a different technical administrator may unknowingly change the configuration
of the records system at a later time with unintended consequences.
For this reason, MoReq2010® includes an option for compliance reporting under
R2.4.5 that allows users to check the current MoReq2010® compliance status of
the records system at any time during routine operation.
How does the records system support MoReq2010® compliance reporting
under R2.4.5 and how does it check the current status of the records
system when reporting to ensure that it has not been reconfigured in a
non‑compliant way?
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
194
1
13
Glossary
term Explanation and relationship to general concepts
Access (verb) To interact with an information system so as

to perform functions and to browse and inspect
its entities.
(noun) The degree of functionality a user is
permitted to have within an information system,
described as a ‘level of access’.
00 4 .59
q
8
Access control (concept) The concept of managing users’ access i;.444 Q4

•
to entities and to functions in an information 1 81
system. �,d.2 .a. Jl.1.
,,
Access control entry (data structure) An individual entry within an access 4 J7 bd22
control list that grants one or more roles to a ' ., o l '

single user or a group. <
o¡
'
4 6 134
,,
See also access control list. J O 38 b 04 • 24
76
Access control list (data structure) A list of access control entries
84
< " • •
ea
associated with an entity that defines which users • 4 4 2
7
may perform functions on the entity by assigning <
roles to users and groups.

See also access control entry.
Accessibility, (concept) A non-functional aspect of an

Principle of information system that describes the extent to
which it supports users with different capabilities
and learning rates, including those with specific
disabilities.
(disambiguation) The term ‘accessibility’ is derived
from a broader meaning of the word ‘access’ than
that used by MoReq2010®.
•
ACE (acronym) An access control entry. MoReq2010
ACl (acronym) An access control list.
Active entity (noun) An entity that has been created in an MCRS Modular Requirements
and has never been deleted or destroyed. for Records Systems
See also residual entity.
Activity (noun) An organised process designed to achieve

an outcome. Both human and computer activities
are common within information systems.
See business activity and scheduled activity.
Add (operation) The function of including an entity

within a set of entities, usually by moving it from
somewhere else. For example, adding a record to
an aggregation.
Volume 1
See also move and remove. Core Services
& Plug-in Modules
Version 1.1
195
1
Glossary
Administrative role (noun) A role that applies uniformly, through

inheritance, to all the descendants of an entity
or, if applied to a service, to all the entities in
the service. By comparison, the inheritance of
non-administrative roles is selective.
See also non-administrative role.
Administrator (noun) A technical administrator of an MCRS is a

person charged with managing the infrastructure
and technical environment that support its
operation. The technical administrator will have
access and influence over the external aspects of
the MCRS such as its physical data storage areas
and the error log, but is not necessarily a user of
the MCRS.
(disambiguation) The term ‘administrator’ may
also be used in a non‑specific way (though not
in MoReq2010®) to describe a user of the MCRS
with:
• a generally high level of access to entities
and functions;
• the task of configuring such entities as
classes, metadata element definitions,
templates or roles;
• specific records management
responsibilities such as the transfer or
destruction of records; or
• one or more administrative roles that the
user has been granted.
See also administrative role.
Aggregate (verb) The activity of bringing together entities

with shared characteristics. Specifically within
MoReq2010®, to create or move records into
aggregations.
• See also add.
MoReq2010
Aggregation (entity) Aggregations of records are accumulations
of related record entities that, when combined,
Modular Requirements may exist at a level above that of a single record.
for Records Systems Aggregations of records may reflect relationships
such as shared characteristics or attributes, or
the existence of sequential relationships between
related records.
(Adapted from ISO 16175‑3:2010: Information
and documentation — Principles and functional
requirements for records in electronic office
environments — Part 3: Guidelines and functional
requirements for records in business systems,
2.3.1.)
Volume 1 See also child aggregation, parent aggregation
and root aggregation.
Core Services
& Plug-in Modules
Version 1.1
196
1
Glossary
Alert (noun) A disposal alert is raised automatically

by an MCRS, and sent to users authorised to
receive it, whenever a record has become due
for disposal and has exceeded its subsequent
confirmation period without receiving the
necessary confirmation of disposal. MoReq2010®
allows each MCRS to implement its own alert
technologies and solutions.
(verb) The act of raising an alert and sending it to
users authorised to receive it.
Ancestor (noun) In a hierarchical structure, starting with a

given entity, every other entity that can be reached
by tracing only a unidirectional path from child
entities to their parents.
See also child, descendant and parent.
Anonymise (verb) A process of obscuring or concealing

sensitive information so that the source cannot be
determined.
See also secure.
Application (noun) Applications are any computer software.

They may include, but are not restricted to,
products or information systems.
Architecture (noun) The layout and structure of an information

system, particularly highlighting the design intent
of each part, their different constructions, and the
relationships between them.
See also service-based architecture.
Assign (operation) Giving a value to a metadata element,

particularly by using it to associate one entity with
another.
See also associate and modify.
Associate (operation) Form a relationship between two •

entities, for example, associating a record with an MoReq2010
aggregation, usually by modifying the metadata of
one or both to hold a reference to the other.
See also assign, modify and remove.
for Records Systems
Atomic (concept) The concept that a particular unit of
information should be managed holistically. For
example, a record is considered to be atomic even
though it is made up of different entities, such as
components. The record is either wholly active
or destroyed in its entirety, it cannot be partially
destroyed.
Atomicity in MoReq2010® also extends to the way
an MCRS performs functions. Functions must be
wholly performed, never partially performed. This Volume 1
is important for maintaining internal consistency
and stability, and when the MCRS is restored from Core Services
backup.
& Plug-in Modules
Version 1.1
197
1
Glossary
Audit trail (noun) In a traditional business system, a

centralised log of all, or significant, system
activity. An MCRS keeps a trail of its activities as a
sequence of events, which may be viewed across
the system as a whole, but are more commonly
accessed as an event history for an individual
entity.
See also event history.
Authenticate (operation) Operation to check the identity of a user

usually by asking the user for a previously agreed
password.
Authenticity, (concept) Along with integrity, reliability and

Principle of usability, one of the central characteristics of a
record according to ISO 15489.
An authentic record is one that can be proven to be
what it purports to be.
(Adapted from ISO 15489‑1:2001, 7.2.2.)
See also integrity, reliability and usability.
Authorised user (noun) An authenticated user with the authority to

perform a function.
Authority (concept) Having the ability to perform a particular

function, especially with respect to a particular
entity. Authority is given to users by granting
them roles in different parts of the system or
in respect to different entities using an access
control list.
Automatic (adjective) An operation or function performed by

the system in accordance with its own internal
processing rules. There is no user or manual
intervention.
See also manual.
• Automatic (operation) The content of a component of a record
MoReq2010 destruction may be destroyed automatically when the record
reaches its disposal action due date. Whether
or not the content is destroyed automatically or
Modular Requirements destroyed following disposal confirmation is
for Records Systems determined by the nature of the content and the
design of the MCRS. All components have a flag
indicating whether or not their content is to be
destroyed automatically.
Availability, (concept) A non-functional aspect of an

Principle of information system that describes the period
during which the system is fully operational and
stable, especially by contrast with how long the
system spends partially operational or offline. This
is sometimes expressed as a ratio or percentage.
Volume 1
BCS (acronym) A business classification scheme.
Core Services
& Plug-in Modules
Version 1.1
198
1
Glossary
Backup (verb) To take a redundant copy of the data of an

information system so that it may be restored
following a system failure or disaster.
(noun) A redundant copy of the data of an
information system held in secure storage so
that it may be later used to restore the system, if
required.
See also restore and recover.
Boolean (concept) A value with only two possible states:

true or false.
See also flag.
Boolean operator (concept) An operator used to logically combine

Boolean values so as to calculate a single result.
There are only three basic Boolean operators —
AND, OR and NOT — from which all other Boolean
operations can be derived.
See also Boolean.
Bottom-up (concept) An approach to managing disposal where

destruction the retention period of each record is assessed
individually and where records may be separately
disposed of. The disposal of aggregations of
records is then tied by processing rules to their
contents, so that when all the records have been
destroyed, the aggregation is automatically
destroyed.
Browse (operation) Discover entities by exploring their

relationships with other entities. For example,
starting from a record, discovering its parent
aggregation using the parent/child relationship,
or by using other relationships discovering its
components, class, disposal schedule, associated
disposal holds, etc.
(disambiguation) Browsing in an MCRS should not •
be confused with using a web browser. MoReq2010
Business (verb) See classification.

classification Modular Requirements
Business (noun) See classification scheme. for Records Systems
classification scheme
Business activity (noun) Activity carried out by a business so as

to constitute or fulfil an overarching business
function; this can include any of the areas of
activity that an organisation might engage in, or
be required to undertake by external regulatory or
other controls.
‘An analysis of business activity and processes
will provide an understanding of the relationship
Volume 1
between the organisation’s business and its
records’ (ISO 15489‑2:2001, 3.2.3).
Core Services
& Plug-in Modules
Version 1.1
199
1
Glossary
Business function (noun) An area of business activity pursued by

an organisation, usually related to the purpose
or mission of the organisation and the execution
of its business strategy and policies. ISo 15489
describes business functions as supporting the
pursuit of an organisation’s goals and strategies
(ISO 15489‑2:2001, 4.2.2.2).
(disambiguation) A business function used in
classification should not be confused with
performing a function.
Business transaction (noun) A discrete stage or ‘constituent step’

(ISO 15489‑2:2001, 4.2.2.2) in a business activity
for which an evidential record is kept. The record
might include information related to:
• the business transaction that was
undertaken;
• when it occurred; and
• who participated.
Business system (noun) Any information system used as part of

conducting business. For example, a financial
management system.
Cancellation (operation) See disposal cancellation.
Capture (concept) An activity leading up to the creation of a

record in an MCRS. Other terms may also be used
for this, such as declaring a record. Often this is
dependent on the user’s perception as to whether
the content of the record must be moved into a
new storage facility (capture), or it can be made a
record in place (declare).
See also declare.
Cascade (concept) The concept that a change to an entity

will have an impact on its descendants. For
•
MoReq2010 example, if the descendants of a root aggregation,
both child aggregations and records, inherit their
classification from their parent aggregation, then
Modular Requirements changing the root aggregation’s class will have a
cascading effect from parent to child, resulting in
for Records Systems
all the descendants of the root aggregation being
reclassified.
See also hierarchical.
Certification (adjective) The act of formally acknowledging that

a records system fully meets the requirements
of MoReq2010® in respect to the core services
and nominated modules. Only the DlM Forum
Foundation may certify a records system, subject
to testing by an accredited MoReq2010® test
Volume 1 centre.
See also testing.
Core Services
& Plug-in Modules
Version 1.1
200
1
Glossary
Child (noun) An entity that is part of a set of entities that

belong and are subordinate to another parent
entity. A parent entity may have multiple children,
but each child entity has only one parent. The link
between parent and child entities is known as a
parent/child relationship.
See also ancestor, descendant, parent and
parent/child relationship.
Child aggregation (noun) Any aggregation that is not a root

aggregation.
See also parent aggregation and root
aggregation.
Class (entity) A unit of classification that may be

associated with an aggregation or a record.
In MoReq2010®, classes always have a default
disposal schedule, which is inherited by any
record they classify, in accordance with the
principle in ISo 15489 that ‘Classification of
business activities acts as a powerful tool to
assist the conduct of business and in many of the
processes involved in the management of records
including … determining appropriate retention
periods and disposition [i.e. disposal] actions for
records’ (ISO 15489‑1:2001, 9.5.1).
See also classification.
Classification (operation) The act of associating a class from

a classification scheme to an aggregation or
record.
(noun) A class applied to an aggregation or record.
See also class, default classification and
reclassification.
Classification (noun) Representation of the business functions,

scheme business activities and business transactions of •
the organisation as a set of discrete classes that MoReq2010
can be associated with records and aggregations
of records.
‘Classification systems may be derived from
analysis of business processes to ensure that the for Records Systems
records and their metadata descriptions accurately
represent the business processes that created
them’ (ISO 15489‑2:2001, 4.2.2.2).
Classification service (service) A logically separate service within an

MCRS operationally responsible for maintaining
class entities within a classification scheme.
Clear (operation) When used in conjunction with a flag

or Boolean value, meaning to assign it the value
‘false’. Volume 1
See also flag.
Core Services
& Plug-in Modules
Version 1.1
201
1
Glossary
Close (operation) The function of closing an aggregation

so that it can no longer accept additional
children that may be moved or created in it.
A user cannot close an aggregation unless all
of its child aggregations are also previously, or
simultaneously, closed.
See also open.
Closed (noun) For aggregations, the state of having

been closed. A child aggregation or record may
be moved out of a closed aggregation but no
additional child aggregations or records may be
moved or created in it.
Code (datatype) A metadata element that can only hold

one of a limited set of predefined values.
See also datatype and value.
Column (noun) Where the metadata elements or properties

of entities are arranged into tables, each row of
the table usually contains the metadata of a single
entity, while each column contains the values for
each entity of a single metadata element.
See also row and table.
Comment (metadata) An additional notation, usually

provided by a user but sometimes constructed
automatically, that provides explanatory and,
later, historical detail to the purpose, motivation or
outcome of taking a significant action.
See also event comment, export comment and
last review comment.
Common (adjective) A product that can be installed and

off-the-shelf run in a variety of different environments with
minimum reconfiguration. COTS products may
be differentiated from other custom applications
• that are purpose built for a specific environment
MoReq2010
or situation. MoReq2010® applies equally to both
COTS products and individual site installations.
Modular Requirements Also referred to as CotS.
for Records Systems Completeness, (concept) When applied to the component of a
Principle of record, ensures that, collectively, the content of
the record comprises a whole record, ensuring the
integrity of the record.
See also destructibility, discreteness and
immutability.
Complex search (noun) A search that is made by chaining together

several search queries into a compound search
query. Complex searches are necessary because
entities are related to one another with sometimes
Volume 1
complex relationships.
Core Services See also search.
& Plug-in Modules
Version 1.1
202
1
Glossary
Compliance, (concept) Compliance is a non-functional aspect of

Principle of a records system that assesses its suitability within
a particular industry, or legislative jurisdiction,
by assessing its support for, and adoption of,
various standards and regulations. Standards and
regulations may apply to technologies, obligations,
policies, rights, communication instruments,
information formats and the processing rules
implemented by a records system.
Compliant (adjective) A statement of the compliance status

of a system or process used especially to
indicate that a records system complies with the
MoReq2010® specification.
See also certified and MoReq2010® compliant
records system.
Component (entity) A part of a record that represents a discrete

item of content. For completeness, a record,
including all its components and their content,
must be managed atomically.
Component content (noun) The actual item of record, whether it be a

physical object or a digital sequence. All the other
entities in an MCRS are purely representational,
holding metadata related to, or extracted from, the
content.
Confirmation (operation) See disposal confirmation.
Confirmation period (noun) The period between the disposal action due
date and the disposal confirmation due date, in
which a user must ensure that the disposal of a
record has been carried out and confirm it with the
MCRS. The disposal of a record is frozen pending
either its confirmation or cancellation.
See also disposal cancellation, disposal
confirmation and disposal confirmation due date. •
MoReq2010
Content (noun) See component content.
Contextual metadata (noun) Metadata that is not mandated by

MoReq2010® but is created within an MCRS in a Modular Requirements
local context to support the local business needs for Records Systems
and operations of an organisation.
Contextual metadata (entity) The definition of a contextual metadata

element definition element. Contextual metadata element definitions
must be exported whenever contextual metadata
is exported to ensure that an MCRS that imports
the export data can interpret the metadata
element and represent it correctly.
Core service (noun) One of the nine services that is fundamental

and necessary to an MCRS solution. Volume 1
Co-requisite (noun) A module for which additional requirements
and consideration is necessary if it is implemented
Core Services
alongside another module. & Plug-in Modules
See also module, prerequisite and service.
Version 1.1
203
1
Glossary
CotS (acronym) Common off-the-shelf, especially in

relation to software products.
Create (operation) The function of adding a new entity to

an MCRS.
CRUD (acronym) Create, read, update and delete. Often

considered to be the four essential operations of a
system in relation to its data.
(disambiguation) MoReq2010® has a different and
more specialised definition of the terms ‘create’,
‘update’ and ‘delete’.
Data (noun) Any information stored in an electronic

format or communicated electronically.
See also export data.
Data streaming (verb) See xMl data streaming.
Data structure (data structure) Compound metadata consisting

of more than one interrelated metadata element
bound together into a structure to preserve their
relationship to one another. Data structures
are part of entities in the same way as simple
metadata elements.
All data structures are provided as part of the
MoReq2010® information model including the
unique System Identifier for each data structure.
For example, the System Identifier for the data
structure Access Control list is 60124baa‑2625‑
4795‑bf14‑7e67f2224ccf.
Database (noun) A dataset usually divided into tables of

entities of the same entity types. The tables are
often related to each other by storing identifiers in
one column that refer to entities in another table.
See also column, row and table.
•
MoReq2010 Datafile (noun) A machine‑readable computer file
containing data in any digital format. The term
‘datafile’ has been coined specifically for use in
Modular Requirements MoReq2010® to avoid any ambiguities with other
for Records Systems terms used in records management.
(disambiguation) The word ‘file’ used in this context
does not refer to an aggregation.
Datatype (noun) An xMl datatype used to define the

characteristics of metadata elements. XML
datatypes are used throughout MoReq2010®
as this standardisation allows different MCRS
solutions to share metadata element definitions.
Date (datatype) A metadata element based on a day,

Volume 1 month and year. A date does not include time
or time zone information and is therefore only
Core Services accurate to within 24 hours.
& Plug-in Modules
Version 1.1
204
1
Glossary
Date/time (datatype) A metadata value based on a date and

a time of day that can be modified by users and
is therefore not as precise as an automatically
generated timestamp. A date/time value does not
include a time zone.
See also originated date/time and timestamp.
Declare (concept) A related term to capture that describes

the user action that may precede the creation of a
record in an MCRS.
See also capture.
De-duplication (concept) The practice of not storing or

transmitting the same data more than once.
De‑duplication is of most importance to the
MoReq2010® export process. When a number
of entities are exported, they may share data in
common (e.g. the class of a record). If several
records with the same class are exported together,
the class information will only be exported once.
Definition (entity) See function definition and metadata

element definition.
Default (concept) An entity or value that is used whenever

a replacement is not explicitly specified. For
example, a record has a default class (inherited
from its parent aggregation) unless it is
overridden by applying a different classification
directly to the record itself.
See also default classification, default disposal
schedule, Default language Identifier and
default value.
Default classification (noun) The class of a child aggregation or record

that it automatically inherits from its parent,
unless it is overridden.
See also class, default and classification. •
MoReq2010
Default disposal (noun) The disposal schedule of a record that it
schedule automatically inherits from its class, unless it is
overridden. Modular Requirements
See also default and disposal schedule. for Records Systems
Default language (metadata) The language Identifier that is used

Identifier for a textual metadata element unless a different
language is specified when the metadata element
is given a value.
See also default and language identifier.
Default value (metadata) The value of a metadata element that

is it is given automatically whenever the metadata
element is instantiated. The default value is stored
in the metadata element definition. Volume 1
See also default and value.
Core Services
& Plug-in Modules
Version 1.1
205
1
Glossary
Delete (operation) Erase data, especially an entity, from an

MCRS so that no trace remains. MoReq2010® only
permits entities to be deleted if they have not been
used. Once an entity has been used, it cannot be
deleted and must be destroyed, leaving a residual
entity.
There is an important distinction between deleting
an entity and destroying an entity.
Descendant (noun) In a hierarchical structure, starting with a

given entity, every other entity that can be reached
by tracing all possible unidirectional paths from
parent entities to their children.
See also ancestor, child and parent.
Description (metadata) Optional extended information

describing an entity.
See also title.
Destroy (operation) A managed process where active

entities are made into a residual entities through
the controlled deletion of:
• some of their metadata;
• some of the events from their event
histories; and
• for records, their content.
There is an important distinction between
destroying an entity and deleting an entity.
See also bottom-up destruction.
Destructibility, (concept) When applied to the component of a

Principle of record, ensures that the content of the record
can be permanently destroyed as a result of
undertaking the disposal process in response to
the record’s disposal schedule.
• See also completeness, discreteness and
MoReq2010 immutability.
Detailed report (noun) A report based on a search query that lists

Modular Requirements entities and their metadata, usually as a table.
for Records Systems See also report and summary report.
Directory (noun) An external business system common

to modern organisational environments that
maintains lists of users and groups and related
metadata. Directories are intended to be deployed
as a central resource allowing other business
systems, including records systems, to interface
with them and reuse this information. Common
protocols include X.500 and LDAP. Directories do
not typically keep good historical information about
Volume 1 users and their group memberships: an MCRS
has additional responsibilities to ensure that
Core Services this information is preserved where an external
directory is used.
& Plug-in Modules
Directory service (noun) See directory.
Version 1.1
206
1
Glossary
Discovery (concept) In relation to a user, finding entities,

their metadata and their relationships to other
entities by searching and browsing.
Discrete (concept) Individual, clearly discernable as being

logically or physically separated from other
entities or units of information.
Discreteness, (concept) When applied to the component of a

Principle of record, ensures that the content of the component
is a single item that is separately identifiable from
the content of other components and records.
See also completeness, destructibility and
immutability.
Dispose (operation) To execute a scheduled disposal

action on a record which will result in either
destroying it or passing it on to a new phase of its
life cycle. Records can only be disposed of in strict
accordance with their disposal schedule.
Disposal action (noun) An action that is taken to dispose of a

record in response to the record’s disposal
schedule. Where a record is not retained
permanently there are only three possible
disposal actions:
• Review,
• transfer, or
• Destroy.
Disposal action due (metadata) The date, marking the end of the
date retention period, when a disposal action should
be carried out on a record in accordance with its
disposal schedule.
See also disposal confirmation due date.
Disposal cancellation (operation) Where a disposal action of transfer or

destroy requires confirmation, it may be cancelled •
rather than being confirmed. Cancelling a disposal MoReq2010
action involves assigning a new disposal schedule
to the record.
Disposal completion (operation) A disposal action of review must be for Records Systems
completed. Reviewing a record involves assigning
it a new disposal schedule as part of a review
decision.
Disposal (operation) The disposal actions of transferring

confirmation and destroying records must be confirmed by a
user, except where records have components that
are subject to automatic destruction. The user
is confirming that the transfer was successful or
that the content of the records has actually been
destroyed. Volume 1
See also automatic destruction.
Core Services
& Plug-in Modules
Version 1.1
207
1
Glossary
Disposal (metadata) The date, marking the end of the

confirmation due confirmation period, by which a disposal action
date requiring confirmation should have been carried
out and confirmed by a user. If the disposal action
is not confirmed by this date, the MCRS will raise
an alert.
See also alert and confirmation period.
Disposal hold (entity) A legal or other administrative order

preventing the destruction of records. Despite
their name, disposal holds do not prevent the
review or transfer of records; however, they
do prevent them being destroyed by changing
their disposal action to retain on hold. Disposal
holds may be applied to whole classes and whole
aggregations, as well as to individual records.
Disposal holding (service) A logically separate service within an

service MCRS operationally responsible for managing
disposal holds.
Disposal process (noun) The process by which a record is updated

and managed, by checking for changes to
its disposal schedule and retention trigger,
calculating its retention period, and applying
disposal actions when they are due.
Disposal schedule (entity) A schedule detailing the life cycle of a

record and detailing:
• the retention trigger (used to determine the
retention start date);
• the retention period;
• the disposal action; and
• the confirmation period.
See also default disposal schedule.
• Disposal scheduling (service) A logically separate service within an

MoReq2010 service MCRS operationally responsible for managing
disposal schedules.
Modular Requirements Disposition (noun) In MoReq2010®, the term ‘disposal’ is used

instead of ‘disposition’.
for Records Systems
See dispose.
DlM (acronym) Document Life cycle Management

(formerly ‘Données Lisibles par Machine’).
See also DlM Forum®.
DlM Forum® (noun) A community of public archives and

interested parties in archive, records, document
and information life cycle management throughout
the European Union and beyond. In February
Volume 1 2010, the DLM Forum® became a not‑for‑profit
foundation and is now officially the DLM Forum
Core Services Foundation.
& Plug-in Modules See also MoReq Governance Board.
Version 1.1
208
1
Glossary
Due date (noun) See disposal action due date and disposal
confirmation due date.
Duplicate (noun) An entity that is an exact copy of another

entity. MoReq2010® allows records, and their
events and components, to be duplicated so as to
allow, for example, a duplicate of the same record
to be placed into two different aggregations. Each
duplicate will then follow its own separate life
cycle.
(operation) The function of duplicating a record.
Electronic (adjective) Having a purely digital representation

that is stored and transmitted electronically.
See also physical.
Element (noun) See metadata element.
Entity (noun) Entities represent individual and discrete

units of information within an information system.
In an MCRS, each entity must be of a particular
entity type and have some, or all, of the following:
• system metadata,
• contextual metadata,
• access control list,
• event history.
The system metadata, and sometimes the
contextual metadata, link the entity to other
entities, forming relationships.
Entity relationship (noun) A technique for modelling relationships

diagram between units of data when describing an
information system.
(disambiguation) The ‘entities’ and ‘relationships’ in
an entity relationship diagram are not necessarily
the same as entities and relationships as defined
by MoReq2010®. •
MoReq2010
Entity subtype (entity) A specialised derivation of an entity type
that may exhibit different behaviours and have
additional metadata elements and functions. Modular Requirements
For example, a contextual metadata element for Records Systems
definition is a subtype of a metadata element
definition. MoReq2010® is fully extensible,
allowing for additional entity types and entity
subtypes to be introduced, as required.
See also entity type.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
209
1
Glossary
Entity type (entity) A definition of an entity. The following entity

types appear in the MoReq2010® core services:
• Aggregations,
• Classes,
• Components,
• Disposal Holds,
• Disposal Schedules,
• Entity types,
• Events,
• Function Definitions,
• Groups,
• Metadata Element Definitions,
• Records,
• Roles,
• templates, and
• Users.
All entity types and subtypes are provided as
part of the MoReq2010® information model
including the unique System Identifier for
each. For example, the System Identifier for the
entity type Record is 3ac228ef‑c008‑4524‑9e41‑
5c4564eaa7f0.
See also entity subtype.
Entry (data structure) See access control entry and

metadata change entry.
Error (noun) A fault in a computer program or application

which prevents the successful completion of a
function.
See also error log and extended error
information.
• Error log (noun) A log of errors that have occurred within
MoReq2010
the MCRS. The error log is maintained externally
to the MCRS and contains details and extended
error information for every error. The error log is
Modular Requirements held externally for diagnostic reasons — to allow it
for Records Systems to be accessed even when the MCRS has crashed
or fails to start.
Also called an external log.
Event (entity) An entity that is generated by performing a

function. The event preserves metadata about:
• the function that was performed;
• when it was performed;
• who performed it;
Volume 1 • the participating entities;
• what metadata was changed; and may
Core Services include
& Plug-in Modules • an Event Comment.
See also function and metadata change entry.
Version 1.1
210
1
Glossary
Event Comment (metadata) A comment that is included in an event

to provide more detail about the event.
See also comment.
Event history (noun) All of the events in which a particular

entity has participated. An MCRS maintains an
event history for all entities in accordance with the
principle expressed in ISo 15489 that ‘Records
systems should contain complete and accurate
representations of all transactions that occur in
relation to a particular record. These include the
processes associated with individual records’
(ISO 15489‑1:2001, 8.3.2).
Evidential (concept) Having weight as evidence, especially

in a legal sense. Part of the reason for using an
MCRS is to enhance the evidential value of an
organisation’s records because of the manner in
which they can be shown to have been managed.
Export (operation) A function performed by a user where

one or more entities, and their related entities, are
output as xMl data, either exported in full or as
placeholders.
(noun) The export data produced as a result of
exporting entities in the MoReq2010® export data
format.
See also import, lossless, lossy and transfer.
Export comment (metadata) A comment provided by the user

that performs an export, which is subsequently
included in the export data and in the Event
Comment generated by the export.
See also comment and event comment.
Export data (noun) A datafile output from an MCRS containing

an export and in the MoReq2010® export data
format. •
MoReq2010
See also export data format and xMl data.
Export data format (noun) A specific xMl data format designed to

accompany MoReq2010® which provides a valid Modular Requirements
schema for the export of all entities. for Records Systems
See also export data and xMl data.
Export Identifier (metadata) An MCRS must generate a unique

identifier, called the Export Identifier, for each
export. This is included in the export data and in
the events generated by the export, to show which
entities were exported in full or as placeholders.
See also UUID.
Export placeholder (noun) When an entity is exported as an export

placeholder, its system metadata, access control
Volume 1
list and significant entities are all exported with it,
but not its contextual metadata, included entities
Core Services
or event history. & Plug-in Modules
Version 1.1
211
1
Glossary
Export process (noun) The process by which entities are exported

from an MCRS. The export process involves:
• assembling the entities to export;
• determining whether they are to be exported
in full or as placeholders;
• de-duplication; and
• performing the export operation.
Export service (service) A logically separate service within an

MCRS operationally responsible for undertaking
the export process and managing exports.
Exported in full (verb) When an entity is exported in full, its system

metadata, contextual metadata, access control
list, included entities, significant entities and
event history are all exported with it.
Extended error (noun) Detailed diagnostic information about why a

information particular error occurred.
Extension module (noun) An extension to the requirements of

MoReq2010® developed by the MoReq Governance
Board and issued by the DlM Forum Foundation.
An extension module may contain:
• key concepts,
• functional requirements,
• non-functional requirements,
• new glossary terms, and
• extensions to the information model.
Each extension module also has its own test cases
and can be tested and certified independently of
the core services, provided the MCRS has already
been certified as MoReq2010® compliant.
Extension modules are used to flexibly add
additional capabilities to the core services in
• relation to particular technologies, industries and
MoReq2010
compliance standards.
External (concept) Operating autonomously outside the

Modular Requirements control of the MCRS with separate data storage
for Records Systems that is not managed by the MCRS.
External log (noun) See error log.
Fail (verb) See error.
First day of the week (noun) The day on which a week is considered to
begin, used when searching and reporting. For
example, the search query, ‘Find records with a
disposal action due date next week’ could have
different results depending on when ‘next week’
nominally begins and ends. Traditionally, the first
Volume 1
day of the week is Sunday, but many organisations
use Monday since it usually represents the first day
Core Services of a working week.
& Plug-in Modules
Version 1.1
212
1
Glossary
First used (concept) The life cycle concept used throughout

the specification that an entity can be created,
modified and deleted up until the moment when
it is first associated with another entity. After
first use, some metadata will become permanent
and the entity must be destroyed, rather than
being deleted, leaving a residual entity. The
concept of first use is not applicable to certain
specified entities, such as records, components,
and events, as well as the entity types, system
metadata element definitions and function
definitions defined by MoReq2010®.
See also first used timestamp.
First Used (metadata) A timestamp applied to an entity when

timestamp it is first used.
See also timestamp.
Fixed role (noun) A built‑in role that is part of the design

of an MCRS and cannot be modified, deleted
or destroyed. Some products are supplied with
certain roles predefined by the supplier.
See also preconfigured role.
Flag (datatype) A metadata element based on a Boolean

value that can only be ‘true’ or ‘false’. Changing
the value to ‘true’ is described as setting the flag,
while changing the value to ‘false’ is described as
clearing the flag.
See also Boolean, clear and set.
Flowchart (noun) A technique for modelling processes in an

information system.
Format (noun) See export data format and reporting

format.
Full-text searching (concept) A technique of searching on text using •

whole words, rather than pattern matching. MoReq2010
Full‑text searching is particularly relevant to
textual information and is enhanced by knowledge
of the particular language in which the text is Modular Requirements
composed. This, for example, enables the search for Records Systems
engine to ignore prefixes and suffixes (known as
‘word stemming’) to search for synonyms and to
place a relative importance on different words in
a phrase. Full‑text searching is ‘fuzzy’ and most
search engines place a weighting on different
results that orders them by best fit to the search
criteria. This weighting is called a relevancy score.
See also relevancy score and textual.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
213
1
Glossary
Function (operation) A predefined operation involving one or

more participating entities that a user performs.
Each function has an expected outcome that is
specified by MoReq2010®. Functions are closely
related to the functional requirements which
specify the functionality required of an MCRS.
(disambiguation) A function should not be confused
with a business function used in classification.
Function definition (entity) A definition of a function that is

represented as an entity. Function definitions are
used for both access control and in events that
are generated by performing functions. For access
control, function definitions are included in roles
which are then granted to users and groups. To
perform a function, a user must have been granted
a role that includes its function definition. When
events are generated, the function definition of
the function that was performed is included in the
event.
All function definitions are provided as part of the
MoReq2010® information model including the
unique System Identifier for each function. For
example, the System Identifier for the function
Group — Remove User is c3713f12‑feb6‑459e‑
a21a‑7e63aaeeea6c.
Functional (noun) A requirement stating what an MCRS must

requirement do. Functional requirements may be tested to
determine whether a particular MCRS is compliant
with MoReq2010®.
See also non-functional requirement.
Generate (verb) Automatic creation of entities, such as

events, and other information by an MCRS.
Good practice (concept) Accepted ways of working that experience

• shows will produce above average outcomes,
MoReq2010
especially in relation to a discipline such as
records management.
Modular Requirements Grant (operation) Award a role to a user or group.
for Records Systems Granting a role will update the access control
list belonging to an entity or service and add or
modify an access control entry.
See also rescind and role.
Group (entity) An entity that usually represents a team

or business unit within the organisation and has
various user entities as members.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
214
1
Glossary
Hierarchical (concept) Structured using parent/child

relationships so that each entity may be a parent
entity, a child entity, or both.
Hierarchies are connected, so that every entity
must be included by having at least one parent/
child relationship with another entity, and
non‑cyclical so that no entity may be the ancestor
(or descendant) of itself.
See also inherit.
Heterogeneous (concept) Comprising entities that are different

according to some fundamental characteristic.
MoReq2010® uses this term to refer to
aggregations that contain records where the
records are classified using different classes.
See also homogenous.
Homogenous (concept) Comprising entities that are the same

or similar according to some fundamental
characteristic. MoReq2010® uses this term to
refer to aggregations that contain records where
the records all have the same class, which is
inherited from their parent aggregation.
See also heterogeneous.
Identifier (metadata) See language identifier, MCRS

certification identifier, module compatibility
identifier, service type identifier and system
identifier.
Immutability, (concept) When applied to the component of a

Principle of record, ensures that the content of the component
remains unaltered. Once the record has been
created, the content of its components must not
change over time.
See also completeness, discreteness and
destructibility. •
MoReq2010
Implement (verb) Interpreting and encoding the requirements
of MoReq2010® into an application. To implement
the specification, suppliers must build the Modular Requirements
requirements into an implementation.
for Records Systems
Implementation (noun) An application that implements the
requirements of MoReq2010®.
Also referred to as a solution.
Implements module (metadata) See module identifier.

identifier
Implements service (metadata) See service identifier.

identifier
Import (operation) Reconstitution of the facsimiles of the Volume 1

entities that have been exported from one MCRS
to another different MCRS by input of xMl data in Core Services
the MoReq2010® export data format.
& Plug-in Modules
See also export, lossless, lossy and transfer.
Version 1.1
215
1
Glossary
In full (qualifier) See exported in full.
In place (qualifier) See manage in place.
Inaccessible (adjective) Unable to be inspected because the

user does not have access to the entity.
See also access and access control.
Included entity (concept) Some entities include other entities.

When they are exported in full, their included
entities must also be exported in full. For
example, an aggregation includes its child
aggregations and records, and a record includes
its components. If an aggregation is exported in
full, all of its descendants will be exported in full
as well, and the components of any records that
are descendants of the aggregation will also be
exported.
Information (noun) Facts known to a person or organisation.

Where information provides evidence of an
organisation’s business activities or transactions
it should be captured as a record. An
organisation’s records may, therefore, be described
as a subset of the information available to that
organisation.
Information may be managed by an information
system and records may be managed by a
specialised type of information system known as
a records system. A records system implements
particular functionality that makes it suitable for
records management.
Information model (noun) A structured functional and metadata

model that underlies all of MoReq2010® and maps
every entity, metadata element and function to
one another. Strict observance of the information
• model is critical to ensuring that the export data
MoReq2010 from different MCRS solutions is fully compatible.
Information system (noun) An integrated set of components for

collecting, storing, processing and communicating
information.
for Records Systems
The main components of information systems
are computer hardware and software, databases,
telecommunications systems, human resources
and procedures.
From information system (2011), Encyclopaedia
Britannica, retrieved from http://www.britannica.
com/EBchecked/topic/ 287895/information‑system
Inherit (verb) See inheritance.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
216
1
Glossary
Inheritance (concept) The adoption by one entity of the

characteristics or properties of another entity by
association with it. Inheritance usually takes place
through the parent/child relationship, but not in
all cases: for example, a record inherits its default
disposal schedule from its class.
The principle of inheritance is used in MoReq2010®
in the following main areas:
• access control,
• classification,
• disposal schedules,
• disposal holds, and
• export.
Inspect (operation) Examine an entity and its metadata.

Access to the inspect function is fundamental for
discovery. If a user is not able to inspect an entity,
it is considered inaccessible and there must not be
any indication of the entity provided by the MCRS
to the user while browsing or searching, or in any
other way.
Install (verb) Initialise an instance of an MCRS by setting

up and configuring the necessary hardware and
software.
Integration (concept) Interfacing to and interoperating with

another business system. Tight integration
implies close cooperation.
Integrity, Principle of (concept) Along with authenticity, reliability and

usability, one of the central characteristics of a
record according to ISo 15489.
‘The integrity of a record refers to its being
complete and unaltered’ (ISO 15489‑1:2001, 7.2.4).
See also authenticity, reliability and usability.
•
MoReq2010
Interface (noun) The part of an information system that
offers up its functionality to users and/or other
systems. By interacting with the interface of an
MCRS, a user is able to perform functions.
for Records Systems
Interoperability (concept) The ability of one system to be able to
operate using the data and information provided
by another system. Specifically in MoReq2010®,
interoperability between records systems is
defined as the ability of a source system to
export its entities and of a destination system to
import and represent them as complete and fully
functional entities alongside its own.
language (noun) A human language. Languages are specified

in MoReq2010® using language identifiers. Volume 1
See also default language and language
identifier. Core Services
& Plug-in Modules
Version 1.1
217
1
Glossary
language Identifier (datatype) MoReq2010® language identifiers

must be compliant with RFC5646 and the IANA
Language Subtag Registry.
See also textual and default language identifier.
last Review (metadata) The comment made by the user that

Comment last reviewed the record. The last review comment
is applied as metadata to the record to allow users
to understand what considerations went into the
previous review.
See also comment, last reviewed timestamp and
review.
last Reviewed (metadata) System set date and time of the last
timestamp review. The last reviewed timestamp is useful
when considering the last Review Comment to
see how long ago the assessment was made.
See also last review comment, review and
timestamp.
level (noun) The depth of a hierarchical structure as

measured by counting the number of entities
from the common ancestor of all entities in
the hierarchy, tracing from parent to child to
its furthest descendant, where the furthest
descendant has the most intervening parent/child
relationships.
See also hierarchical and max levels of
aggregation.
life cycle (concept) Every entity in an MCRS has a

predetermined life cycle which begins with the
creation of the entity and has various phases
depending on its entity type. An entity is initially
active until it is destroyed, when it becomes a
residual entity.
• lift (operation) Term used to describe the removal
MoReq2010
of a disposal hold from a class, aggregation or
record. When a disposal hold is destroyed, it is
immediately lifted.
for Records Systems litigation hold (noun) In MoReq2010®, the term disposal hold is
used instead of ‘litigation hold’.
See also disposal hold.
localisation (concept) Customising an individual instance of

an MCRS to meet local requirements. This can
be done in many different ways. Using different
languages, creating specific roles, constructing
an organisational classification scheme, defining
contextual metadata elements, using different
titles and descriptions for entity types and
Volume 1 function definitions are all aspects of localisation.
Core Services log (noun) See error log.

& Plug-in Modules
Version 1.1
218
1
Glossary
logical (concept) Conceptually different. For an example,

a service may be logically differentiated within
an MCRS from other services, while, in reality,
they all remain part of the same codebase, or two
different components may have the same content
but use pointers to make it appear as if they have
different content, thereby satisfying the principle of
discreteness.
lossless (concept) When used in the context of

interoperability, or export and import, refers to
the idea that important contextual information is
not lost during transfer.
See also export, import, lossy and transfer.
lossy (concept) When used in the context of

interoperability, or export and import, indicates
that some contextual information, such as
metadata, events, access control lists or
relationships with other entities is lost during
transfer.
See also export, import, lossless and transfer.
Maintainability, (concept) A non-functional aspect of a records

Principle of system that describes how relatively easy a given
application or site installation is to maintain and
upgrade. A system is considered less maintainable
if it is difficult to service, must be taken offline for
a significant period to apply upgrades and patches,
or requires costly expenditure on third‑party
support or maintenance contracts.
Major version (noun) See version.
Manage in place (concept) The management of records with

components having content located in another
external information system.
Manageability, (concept) A non-functional aspect of a records •

MoReq2010
Principle of system that refers to how it is managed and
administered. The technical administrator’s
task is to ensure the records system remains
operational, while the records manager is
charged with ensuring the records system is used for Records Systems
effectively.
Mandate (metadata) The legal or other instrument that

provides the procedural authority for a disposal
schedule or disposal hold.
Manual (adjective) An operation or function performed

by a user, especially when contrasted with
one performed automatically by the MCRS in
accordance with its own processing rules. It is
important to note that a user may be another Volume 1
business system. As a result a ‘manual’ function
or operation may not necessarily be performed by Core Services
a human. & Plug-in Modules
See also automatic.
Version 1.1
219
1
Glossary
Max levels of (metadata) The number of levels of aggregation

aggregation allowed below a given root aggregation. If Max
Levels Of Aggregation is assigned a value of zero,
no child aggregations can be added below the
root.
See also level.
MCRS (acronym) A MoReq2010® compliant records

system.
MCRS certification (metadata) A universally unique identifier issued

identifier by the DlM Forum Foundation on award of a
MoReq2010® certificate of compliance. The
MCRS certification identifier is used to report the
compliance status of an MCRS.
See also certify and system identifier.
Metadata (noun) Information about an entity made up of

several metadata elements.
See also metadata element.
Metadata change (data structure) A data structure included in an

entry event whenever one or more metadata elements
were modified by the event. Each metadata change
entry contains the value of a metadata element
both before and after it was modified.
Metadata element (noun) An item of metadata described by a

metadata element definition that has zero or
more values given to it by users and by the MCRS.
Metadata element (entity) A definition of a metadata element that

definition indicates, among other properties, its:
• title — the name of the metadata element;
• datatype — what type of metadata it may
contain;
• cardinality — how many values it may have;
•
MoReq2010 as well as
• whether these values may be changed by a
user.
Modular Requirements See also contextual metadata element definition
for Records Systems and system metadata element definition.
Metadata service (service) A logically separate service within an

MCRS operationally responsible for managing
metadata element definitions and metadata
templates.
See also model metadata service.
Metadata template (entity) A template.
Metadata value (noun) See value.

Volume 1 MGB (acronym) The MoReq Governance Board.
Core Services
& Plug-in Modules
Version 1.1
220
1
Glossary
Migration (operation) A variant of transfer where the

intention is to move all or a substantial number
of often active entities from one records system
to a new MCRS, allowing them to be managed by
a new owner, in a new environment, or by a new
technology or solution.
Usually, the purpose of migration is to
decommission the previous records system.
Sometimes, the source is not a MoReq2010®
compliant records system and the migration is
a singular exercise intended to rearrange the
older records into the export data format used by
MoReq2010®. Once they have been migrated into
an MCRS, the entities can be transferred on again
in the future, losslessly.
Minor version (noun) See version.
Model metadata (service) The MoReq2010®‑preferred

service implementation of the metadata service.
See also metadata service.
Model role service (service) The MoReq2010®‑preferred

implementation of the role service.
See also role service.
Model service (concept) A service defined by the MoReq2010®

specification, which may be replaced in operation
by a functionally similar service with a different
set of processing rules, that has been defined for
a particular MCRS solution. To use a replacement
service for a model service, an MCRS must have
been tested to ensure a close match in overall
functionality and it must be able to export its own
proprietary data structures to the MoReq2010®
export data format.
See also model metadata service and model role
•
service. MoReq2010
Modify (operation) Assign a new value to a metadata
element, or change or delete a previous value.
See also assign and associate.
for Records Systems
Modifiable (adjective) Indication of whether or not a user
may modify a particular metadata element. A
metadata element that cannot be modified is said
to be ‘read-only’.
Module (noun) See extension module and plug-in module.
Module identifier (metadata) A universally unique identifier provided

by the DlM Forum Foundation that is used in
compliance reporting by an MCRS to indicate that
it implements a particular major version of a Volume 1
module of MoReq2010®.
See also module, system identifier and version. Core Services
& Plug-in Modules
Version 1.1
221
1
Glossary
MoReq ®
(acronym) Modular Requirements for Records
Systems (formerly ‘Model Requirements for the
Management of Electronic Records’).
(noun) As a generic term, used to refer to any
of the various specifications published under
the acronym MoReq®, including MoReq® (2001),
MoReq2® (2008) and MoReq2010®.
(disambiguation) As a specific term, used to refer
to the original MoReq® specification published in
2001.
Can also be used informally to imply the most
recent version of the MoReq® specification, which
is MoReq2010®.
MoReq Governance (noun) A subcommittee of the DlM Forum

Board Foundation appointed by the executive committee
to manage the MoReq® specification and related
activities, including all:
• future development, extension, localisation
and adaption through sponsorship and joint
working groups;
• translation of the specification into different
languages;
• issuing guidance notes and supplementary
resources;
• maintenance, clarification and update;
• education, workshops and training
programmes;
• marketing and publicity;
• brand protection; and
• managing the accompanying testing and
certification programme through a network
of accredited test centres.
The MoReq Governance Board is commonly
•
MoReq2010 referred to as the MGB.
MoReq2® (noun) The immediate successor to the original

MoReq® specification developed by the European
Modular Requirements Commission in cooperation with the DlM Forum®
for Records Systems following a scoping study in 2005 and launched in
March 2008.
MoReq2® (2008) superseded MoReq® (2001) and
was itself superseded by MoReq2010® in May
2011.
MoReq2010® (noun) The most recent version of the MoReq®

specification, developed under the MoReq2010®
work programme, following the MGB’s 2009
roadmap.
Volume 1 The MoReq2010® work programme was initiated by
the DlM Forum Foundation at its AGM in Madrid,
Core Services May 2010. MoReq2010® was launched, after a
year’s development, at the DLM Forum Foundation
& Plug-in Modules AGM in Budapest, May 2011.
MoReq2010® supersedes MoReq2® (2008).
Version 1.1
222
1
Glossary
MoReq2010 ®
(noun) A records system which is fully compliant
compliant records with the core services of MoReq2010® and may
system also be fully compliant with one or more modules.
A MoReq2010® compliant records system is
usually referred to as an MCRS. To provide surety
that an MCRS is fully compliant with MoReq2010®,
it should be tested and certified by the DlM
Forum Foundation.
Move (operation) Used in the context of an aggregation

to indicate the removal of a child entity or record
from one aggregation and its addition to another
aggregation. An aggregation can be moved to
become a root aggregation or moved from a
root aggregation to become a child aggregation.
Records must always belong to an aggregation.
See also add and remove.
Multi-tenanted (concept) In respect of a records system, one that

is shared by a number of different organisations
such that each organisation has its own part of
the records system and does not have access to
the records and other entities belonging to other
organisations.
Native metadata (noun) The metadata model of an MCRS that does

model not use the model metadata service. A native
metadata model will usually not be compatible
with the metadata model of an MCRS from a
different supplier.
See also proprietary.
Native permissions (noun) The role model of an MCRS that does not
model use the model role service. A native permissions
model will usually not be compatible with the role
model, or native permissions model, of an MCRS
from a different supplier.
See also proprietary. •
MoReq2010
Nominated (adjective) In relation to entities, the entity or
entities that have been chosen or selected by the
user. Modular Requirements
for Records Systems
Non-administrative (noun) A role that is only inherited when it
role is included by the access control list of a
child entity. Non‑administrative roles may be
specifically excluded from being inherited.
Administrative roles may never be blocked.
See also administrative role.
Non-compliant (noun) A records system that is not MoReq2010®

system compliant, specifically one that has not been
certified by the DlM Forum Foundation.
Volume 1
See also information system and MoReq2010®
compliant records system.
Core Services
& Plug-in Modules
Version 1.1
223
1
Glossary
Non-functional (adjective) A qualitative aspect or assessment,

as distinct from taking a purely functional
perspective.
See also non-functional requirement.
Non-functional (noun) An important requirement of a system

requirement that is not expressed as a particular function
that the system must perform. Non‑functional
requirements assess not what a system does
but how well it does it. This includes a qualitative
assessment of the following properties:
• performance,
• scalability,
• manageability,
• portability,
• security,
• privacy,
• usability,
• accessibility,
• availability,
• reliability,
• recoverability,
• maintainability,
• supported,
• warranted, and
• compliance.
See also functional requirement.
open (noun) For aggregations, a state allowing new

child aggregations or records to be created in the
aggregation, or existing aggregations and records
to be moved to it.
See also closed.
(operation) The function of opening a closed
• aggregation so that it can accept additional
MoReq2010 children that may be moved or created in it.
See also close.
Modular Requirements operation (noun) Any action generally taken by an MCRS
for Records Systems in response to an internal processing rule or an
external stimulus. A function is a specialised
form of operation which is usually (though not
exclusively) initiated by a user, involves one or
more participating entities, and may result in an
event being generated.
See also function.
organisational (noun) A quarter, consisting of a three‑month

quarter period, in an organisational year.
Volume 1 See also organisational year.
organisational year (noun) Many organisations have a financial or

Core Services administrative year consisting of four quarters,
& Plug-in Modules each of three months, which is not aligned with the
calendar year.
See also organisational quarter.
Version 1.1
224
1
Glossary
originated Date/time (metadata) The date and time from which an entity
originates. By default, MoReq2010® uses the date
and time on which the entity was created in the
MCRS: however, the entity’s actual originated date/
time may be earlier than this.
See also date/time.
override (verb) Provide an explicit replacement for a

default entity or value, especially with respect
to overriding the inherited classification of an
aggregation or record, or overriding the default
disposal schedule for a record, derived from its
class.
See also default and inherit.
Pagination (concept) Specifically with respect to search

results, to divide a large set of search results into
smaller subsets that are returned individually to
the user performing the search.
See also search results.
Parent (noun) An entity in a hierarchical structure that

has one or more child entities. The link between
parent and child entities is known as a parent/
child relationship.
See also ancestor, child and descendant.
Parent aggregation (noun) An aggregation that contains either child

aggregations or records.
See also child aggregation and root aggregation.
Parent/child (noun) The relationship between a parent and a

relationship child in a hierarchical structure. In MoReq2010®,
this relationship is established by storing a
reference to the parent as part of the metadata of
the child entity.
•
Participating entity (noun) An entity that is considered to have MoReq2010
participated in an event, or for which the event
is important. The event forms a part of the event
history of every participating entity. Modular Requirements
See also event. for Records Systems
Perform (verb) To carry out or execute a function in relation
to one or more entities.
See also error and function.
Performance, (concept) A non-functional aspect of a records

Principle of system concerned with the speed and efficiency of
processing.
Physical (adjective) Having a physical or real‑world

presence. For example, a record that has content Volume 1
consisting of paper with writing on it compared to
a record with electronic content. Core Services
(disambiguation) The term ‘physical’ is also used as & Plug-in Modules
the opposite of logical.
See also electronic and logical.
Version 1.1
225
1
Glossary
Placeholder (noun) See export placeholder.
Plug-in module (noun) A module of MoReq2010® that plugs into the

core services and provides specialised functionality
in a particular area. Plug‑in modules are organised
into series and, to be compliant, each MCRS must
implement at least one plug‑in module from each
series. An MCRS may implement more than one
plug‑in module from the same series.
Pointer (concept) A technique for implementing the principle

of discreteness in a logical, rather than a physical,
way. For example, assuming two different records
have components that both contain the same
content. Rather than keep two copies of the content,
the MCRS keeps two pointers to the content and
a counter of the number of components that point
to the same content. When the first component is
destroyed, its pointer is deleted and the pointer
counter is decremented from two to one. When the
second component is destroyed, its pointer is also
deleted, and as the pointer counter decrements to
zero, the content is also deleted.
Portability, Principle (concept) A non-functional aspect of a records

of system that assesses the extent to which the
system can be deployed on to different platforms,
devices and operating environments.
Preconfigured role (noun) A role that has been predefined by the

supplier of an MCRS solution to allow its
configuration. Unlike a fixed role, a preconfigured
role may be later modified or destroyed.
See also fixed role.
Prerequisite (noun) A module which must be implemented

before the nominated module is able to be
implemented. Used to indicate that one module
• of MoReq2010® is reliant on the functionality of
MoReq2010 another also being implemented by the MCRS.
See also co-requisite, module and service.
Modular Requirements Presentation order (metadata) A user‑specified order in which items
for Records Systems should appear: specifically, the order in which
metadata elements should be presented when an
entity is inspected.
Privacy, Principle of (concept) A non-functional aspect of a records

system, privacy is concerned with the degree to
which the system supports the principles of data
protection as well as the broader issue of handling
any form of sensitive information.
Process (noun) A step‑by‑step workflow described by

Volume 1 MoReq2010® that should be implemented by all
MCRS solutions in the same way, so that it will
Core Services reliably produce the same outcomes each time
it is performed. The most important processes
& Plug-in Modules described by MoReq2010® are the disposal
process and the export process.
Version 1.1
226
1
Glossary
Product (noun) CotS software, usually licensed from a

supplier, that can be installed as a stand‑alone
application to provide an implementation of an
MCRS.
Proprietary (concept) An implementation that is specific to

a particular product from a particular supplier
and is incompatible with other records system
implementations from other suppliers. One of the
primary design goals of MoReq2010® is to avoid
incompatible proprietary records systems that are
not fully interoperable.
See also native metadata model and native
permissions model.
Prune (verb) When entities are destroyed, to

automatically and selectively delete
predetermined metadata elements, as well as to
delete events from their event histories, based on
which functions they represent.
Read-only (concept) See modifiable.
Reclassification (operation) To change the classification of an

aggregation or record. Reclassification may occur
as a result of overriding the default classification
or, where the aggregation or record inherits its
class, it may occur as a result of reclassifying a
parent or ancestor entity.
See also classification.
Record (entity) Any ‘information created, received and

maintained as evidence and information by an
organisation or person, in pursuance of legal
obligations or in the transaction of business’
(ISO 15489‑1:2001, 3.15).
In MoReq2010®, a record may be further •
characterised as follows. MoReq2010
• It has an extensible set of metadata that
describe it.
• It has one or more components that
for Records Systems
represent its content.
• It is classified with a business classification.
• It has a disposal schedule that describes
explicitly if, how and when it will be disposed
of or destroyed.
• It belongs to an aggregation of records.
• Access to it is controlled and limited to
authorised users.
• Its destruction may be prevented by a
Volume 1
disposal hold.
• It may be exported to another MCRS while Core Services
retaining all of the characteristics listed
above.
& Plug-in Modules
Record content (noun) See component content.
Version 1.1
227
1
Glossary
Record service (service) A logically separate service within an

aggregations, records and their components.
Records (concept) The ‘field of management responsible for

management the efficient and systematic control of the creation,
receipt, maintenance, use and disposal of records,
including processes for capturing and maintaining
evidence of, and information about, business
activities and transactions in the form of records’
(adapted from ISO 15489‑1:2001, 3.16).
Records system (noun) An ‘information system which captures,

manages and provides access to records through
time’ (ISO 15489‑1:2001, 3.17).
A MoReq2010® compliant records system
delivers the functionality of a records system in a
standardised way through its implementation of a
set of core services, defined by the MoReq2010®
specification, which may be further extended,
adapted and localised through additional modules.
Recover (verb) To cope with a system failure or disaster by

replacing damaged hardware and software and
restoring the system’s data to bring it back to a
previously known and stable state.
See also backup and recover.
Recoverability, (concept) Non‑functional aspect of a records

Principle of system that assesses its ability to recover from a
system failure or disaster. Also known as ‘disaster
recovery’ or ‘business continuity’.
Reference (noun) Specifically in the context of relationships

between entities and the metadata of an entity, a
metadata element is said to contain a reference
• when its whole purpose is to store the unique
MoReq2010 system identifier of another entity. Relationships
between entities are realised by one entity
referencing the other. If a user is authorised to
Modular Requirements inspect both entities, the MCRS must allow the
for Records Systems user to browse the relationship, from one to the
other, in either direction.
(disambiguation) MoReq2010® also uses the
term ‘reference’ in its more general sense. For
example, most functional requirements have
a ‘function reference’ which is simply an index
to the information model that allows the reader
to look up the function definition matching the
requirement.
Relationship (noun) See entity relationship diagram, parent/

Volume 1
child relationship and especially reference.
Core Services Relevancy score (metadata) The, usually proprietary, weighting
& Plug-in Modules given to a full-text search that allows more
relevant results to be returned first.
See also full-text searching.
Version 1.1
228
1
Glossary
Reliability, (concept) Along with authenticity, integrity and

Principle of usability, one of the central characteristics of a
‘A reliable record is one whose contents can be
trusted as a full and accurate representation of the
transactions, activities or facts to which they attest
…’ (ISO 15489‑1:2001, 7.2.3).
(alternative usage) Reliability is also a
non-functional aspect of a records system and,
when used in this sense, it refers to the resilience
of the system as a whole: it is often measured as
the ‘mean time between failures’.
See also authenticity, integrity and usability.
Remove (operation) The function of disassociating an entity

from a set of entities, usually for the purpose of
moving it elsewhere. For example, removing a
record from its parent aggregation so as to move
it to a new parent aggregation.
See also add, associate and move.
Report (noun) The structured assembly of information,

using a preconfigured outline, in response to a
specific enquiry or a more general enquiry, such
as a search query. Searching and reporting are
closely related activities and often overlap. A
search that is subsequently made into a report is
sometimes called an ad hoc report. Traditionally,
a report has a report format that enables it to
be stored as electronic content and potentially
to be declared as a record itself. MoReq2010®
requires an MCRS to be able to provide both
specific reports, in response to some functional
requirements, and two types of general report: a
detailed report and a summary report.
•
See also detailed report and summary report. MoReq2010
(operation) The function of generating a report.
Reporting format (noun) A common and widely recognised format for Modular Requirements
a report, such as: for Records Systems
• comma or tab separated values;
• spreadsheet formats, such as OOXML and ODF;
• XML and HTML‑based formats; and
• PDF or other document formats.
See also format and report.
Requirement (noun) See functional requirement and

non-functional requirement.
Rescind (operation) To prevent the further use of a role Volume 1

that was previously granted to a user or group.
Rescinding a role will update the access control Core Services
list belonging to an entity or service and delete or & Plug-in Modules
modify an access control entry.
See also grant and role.
Version 1.1
229
1
Glossary
Residual entity (noun) An entity that has been destroyed. A

residual entity is no longer active and on its
destruction, it may have been pruned of some
of its metadata and some of the events from its
event history.
See also active entity.
Restore (verb) To recover an information system to a

previously known and stable state using a backup
following a system failure or disaster.
See also backup and recover.
Retain (verb) Keep a record in the MCRS and ensure that

it is not deleted or destroyed.
See also dispose.
Retain on hold (verb) Retain a record and prevent its destruction

for the duration of a disposal hold.
See also disposal hold.
Retain permanently (verb) Retain a record indefinitely and prevent its

destruction unless or until it is given a different
disposal schedule.
See also disposal action.
Retention period (noun) The period of time that a record is retained

from its retention start date, initiated by its
retention trigger, until its disposal due date,
marking the end of the retention period.
Retention start date (metadata) The date on which the conditions of

the retention trigger in the record’s disposal
schedule are met and the retention period begins.
Retention trigger (noun) One of a number of possible conditions

that may cause a record’s retention period
to commence. Each disposal schedule lists
• a retention trigger. For example, a record’s
MoReq2010 retention trigger may be the date it was added to
its parent aggregation.
Modular Requirements Review (operation) The function of assessing a record that

is due for review and determining what disposal
for Records Systems
schedule to apply to it. An authorised user may
complete a review by applying a new disposal
schedule to the record and entering a review
comment describing the review decision.
See also last review comment and last reviewed
timestamp.
Review decision (noun) The decision made by the reviewer of a

record when completing a review.
See also disposal completion and review.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
230
1
Glossary
Role (entity) An entity representing a set of function

definitions. Granting a role to a user or group
in relation to an entity enables that user, or any
member of that group, to perform that role on the
entity and its descendants. Roles are generally
constructed to mirror the tasks of a staff member
filling a particular position within the organisation.
For example, different roles may be constructed
around each of the following usage types:
• office clerk,
• local records officer,
• senior records manager,
• personnel manager,
• sales representative,
• auditor,
• external contractor,
• guest or office temp,
• executive personal assistant,
• senior executive officer,
• etc.
See also fixed role, grant, preconfigured role and
rescind.
Role service (service) A logically separate service within an

roles.
See also model role service.
Root aggregation (noun) An aggregation that is not a child of

another aggregation. Each root aggregation is
created directly under the record service.
See also child aggregation and parent
aggregation.
Row (noun) Where the metadata elements or properties •

of entities are arranged into tables, each row of MoReq2010
the table usually contains the metadata of a single
entity, while each column contains the values for
each entity of a single metadata element. Modular Requirements
See also column and table. for Records Systems
Saved report (noun) A report where the report format and

search query used are saved by the MCRS and
stored so that the report can be shared with other
users and generated again, as required. A saved
report is not an entity.
(disambiguation) A ‘saved report’ refers to the
saving of the report definition, not the report
results.
Saved search (noun) A search query which is saved so that Volume 1

it can be shared with other users, run again
when required, and used as the basis of further Core Services
searches. A saved search is not an entity. & Plug-in Modules
(disambiguation) A saved ‘search refers’ to the
saving of the search query, not the search results.
Version 1.1
231
1
Glossary
Scalability, (concept) A non-functional aspect of a records

Principle of system that assesses the extent to which
it can grow to support increased capacity
without requiring replacement or extensive
reconfiguration. Systems typically need to be
scaled as a result of organisational expansion,
increased workload, peak usage and/or the regular
accumulation of records and related entities over
time.
Scheduled activity (noun) A planned process or routine carried out

by an information system at regular intervals,
particularly a resource‑intensive operation that
is scheduled for a time of the day or week when
usage of the system is low.
See also activity.
Scope notes (metadata) Guidance notes indicating how best

to apply a particular entity and stating any
organisational policies or constraints on its use.
For example, a class may have scope notes
indicating which aggregations and records the
class should be applied to and which aggregations
and records are unsuited for classification
under that class. Scope notes can be given to
aggregations, classes, disposal holds, disposal
schedules and contextual metadata elements.
Search (operation) Discover entities by specifying search

criteria that partially or fully match the values of
their metadata elements.
See also complex search and full-text searching.
Search engine (noun) The heart of the MCRS solution’s searching

and reporting service. A search engine will
typically index the metadata in the MCRS, apply
the search criteria, execute and evaluate the
• search, and assemble and sort the search results.
MoReq2010 Different search engines may be more or less
sophisticated in the functionality they offer. As
search engines are often highly specialised, like
Modular Requirements databases, some suppliers will make use of third‑
for Records Systems party search engines in their MCRS solutions.
Search criteria (noun) Individual conditions included in a search

query. Each search query will be made up of one
or more search criteria. Each search criterion
is made up of metadata elements to search on,
search operators and search terms.
Search description (metadata) A description of a search query that

is included in an event so as to retain evidence
of the search that was performed. The search
Volume 1 description may be in natural language or in a
structured expression language.
Core Services See also event comment.
& Plug-in Modules
Version 1.1
232
1
Glossary
Search query (noun) An enquiry made up of one or more search

criteria that a user constructs so as to perform a
search.
Search results (noun) The results of a search expressed as an

ordered list of entities and their metadata.
See also pagination.
Search term (noun) A part of a search criterion that holds a

value that can be compared or searched on.
Searching and (service) A logically separate service within an

reporting service MCRS that is, or is integrated with, a search
engine and performs searches and generates
reports for authorised users.
See also model role service.
Secure (concept) A unit of information is secure when only

authorised users may access it and manipulate it.
In an MCRS, internal security is provided by access
controls while external security is assessed under
the non-functional principle of security.
See also anonymise.
Security, Principle of (concept) A non-functional aspect of a records

system referring to, and measuring, its integrity
and ability to withstand unauthorised access.
Sentencing (concept) The general principle that the context of

on creation a record is best captured when the record is first
created and that this context should be used to
govern the record’s disposal. In MoReq2010®, the
principle of ‘sentencing on creation’ is embodied
by the functionality required of the MCRS where
every record created must be classified and every
class has a default disposal schedule associated
with it.
Service (noun) A logical subset of the total functionality •

MoReq2010
of an MCRS that focuses on managing only one
or a small group of entity types. For example,
the disposal scheduling service only manages
disposal schedules.
for Records Systems
See also classification service, disposal holding
service, disposal scheduling service, metadata
service, model metadata service, model role
service, searching and reporting service,
service-based architecture, role service and user
and group service.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
233
1
Glossary
Service-based (concept) An architecture adopted within the

architecture specification where functional requirements
within the core of MoReq2010® are separated
into discrete services. Each service represents a
bundle of functionality that could theoretically be
undertaken by a separate application. Dividing
the core in this way helps to introduce the key
concepts in a logical order, but it also points
towards the future where one MCRS may have two
services of the same type, such as two different
classification services for different types of record
or aggregation, or may share a service, such as its
metadata service, with another MCRS.
Service identifier (metadata) A universally unique identifier provided

by the DlM Forum Foundation that is used in
compliance reporting by an MCRS to indicate that
it implements a particular major version of a core
service of MoReq2010®.
See also module, system identifier and version.
Set (operation) When used in conjunction with a flag

or Boolean value, meaning to assign it the value
‘true’.
(disambiguation) MoReq2010® also uses the term
‘set’ as a collective noun to refer to groupings of
entities.
See also flag.
Significant entity (concept) An entity that is particularly important

to another entity and must therefore always be
exported with it as a placeholder, whenever it
is exported. For example, a record’s class is a
significant entity to the record. The record cannot
be exported in full or as a placeholder without its
class also being exported as a placeholder.
• Snapshot (noun) A representation of any data or unit of
MoReq2010
information, but especially an active entity and its
metadata, frozen at a particular moment in time.
Modular Requirements Solution (noun) See implementation.
for Records Systems
Stream (verb) See xMl data streaming.
Subtype (noun) See entity subtype.
Summary report (noun) A report based on statistics rather than

individual line items.
See also report and detailed report.
Supplier (noun) The manufacturer or developer of a

records system, or a body that holds some or all
of the intellectual property rights, or a supplier’s
Volume 1 representative, such as a reseller or service
integrator.
Core Services
& Plug-in Modules
Version 1.1
234
1
Glossary
Supported, Principle (concept) A non-functional aspect of a records

of a system being system, a supported system is one that is
being actively maintained and upgraded by the
supplier and for which there exists an operational
support facility for reporting issues and receiving
information about new releases and software fixes.
System (noun) See information system.
System Identifier (metadata) A universally unique identifier

generated by the system for an entity or other
purpose, such as an Export Identifier. Some
system identifiers are provided by MoReq2010®,
including service identifiers, module identifiers,
entity type identifiers, data structure identifiers,
system metadata element definition identifiers
and function definition identifiers.
System metadata (noun) Metadata that is mandated by MoReq2010®

and is predefined by the specification which
includes the system metadata element definitions
and their System Identifiers. Each entity type has
its own set of system metadata associated with it.
System metadata (entity) A metadata element definition for a

element definition system metadata element.
All system metadata element definitions are
provided as part of the MoReq2010® information
model including the unique System Identifier for
each. For example, the System Identifier for the
system metadata element title is 077fc367‑48ba‑
44a8‑8afb‑012d05ed1a16.
table (noun) An actual or conceptual laying out of the

metadata of entities into rows and columns. This
layout is most successful when all of the entities
in a table have the same metadata elements or
properties, which usually means that they are of
•
the same entity type. MoReq2010
See also column, database and row.
technical (concept) See administrator.

administration
for Records Systems
template (entity) A representation of a set of contextual
metadata element definitions that can be applied
to an entity. Whenever a template is applied,
each of the contextual metadata elements is
instantiated and associated with the entity.
See also default template and contextual
metadata element definition.
testing (verb) The activity of proving the correctness of

software by performing functions and comparing
the results to expected outcomes. Specifically for Volume 1
MoReq2010®, formally testing a records system
against the functional requirements using the
Core Services
MoReq2010® test framework. & Plug-in Modules
See also certification.
Version 1.1
235
1
Glossary
text (datatype) Information transmitted using

characters and typically expressed using words
delineated by spaces and punctuation. All text in
an MCRS must use the Unicode character set.
See also Unicode.
textual (adjective) Descriptor for a text‑based metadata

element that is expected to contain a value
expressed in a particular language. The
information may not be accessible to a user that
does not understand that language. Additionally,
the language of a textual value may alter how it
is automatically processed. For example, it may
be indexed differently by a search engine, sorted
into a different order in a list, or rendered using
different styles or fonts.
See also language identifier.
title (metadata) Mandatory name or identifying text for

an entity. Usually shorter than a full description.
In MoReq2010®, the titles of entities do not need
to be unique, even for records within the same
aggregation, although this is considered good
practice.
See also description.
time zone (metadata) The offset between a time measured

locally and UTC (Universal Coordinated Time).
Time zone information must be incorporated into
all timestamps generated by an MCRS to avoid
events appearing to occur out of sequence. This is
particularly necessary to support interoperability.
See also timestamp.
timestamp (noun) A highly precise system‑generated value

for the moment in time at which an event or other
significant operation occurred. timestamps
•
MoReq2010 must include the full date, time and time zone,
and should be precise at least to the second
and should seek to be even more precise (e.g.
Modular Requirements millisecond precision).
for Records Systems See also first used timestamp, last reviewed
timestamp and time zone.
transaction (noun) An operation performed by a business

system that is stored in a transaction log so that
it can be repeated should the system need to be
recovered from a disaster. Use of transactions
ensures that less data is lost if a system fails as
the transaction log can be used to roll forward
from the last backup to the moment immediately
prior to the disaster.
Volume 1 (disambiguation) The type of transaction just
described should not be confused with a business
Core Services transaction.
& Plug-in Modules See also business transaction.
Version 1.1
236
1
Glossary
transfer (operation) A disposal action where records are

moved to a secondary storage or archival facility.
Transfer will therefore usually involve export and
import, followed by the destruction of the records
in the originating system. Successful transfer must
be confirmed before the records in the originating
MCRS are destroyed. Transfer can also be
referred to as migration, especially where all, or a
substantial number, of the entities in an MCRS, or
a service, are being transferred.
See also disposal action, disposal confirmation,
export, import and migration.
tree (noun) A hierarchical structure.

See also hierarchical.
Unicode (noun) The Unicode standard provides standardised

character encodings and processing rules for text
in all European languages and nearly all spoken
languages.
Uniform resource (noun) A uniform resource identifier, or URI, is

identifier used to identify and locate a resource, such as
a datafile, on the Internet. Uniform resource
identifiers can be extended to identify resources
in other locations, such as in the local operating
system.
Universally unique (noun) An identification number made up of

identifier 128 bits and commonly described as a UUID. If
generated using a suitable algorithm, there is
only a tiny probability that any two UUID values
will ever be the same, even among billions of
entities. UUIDs are invaluable in their support for
interoperability as they allow System Identifiers
to be exchanged between different generating
information systems.
Suitable algorithms for generating UUIDs can be •
MoReq2010
found in RFC4122 and these can even support
‘high allocation rates of up to 10 million per
second per machine’ (RFC4122:2005, 2.).
Usability, Principle of (concept) Along with authenticity, integrity and for Records Systems
reliability, one of the central characteristics of a
‘A usable record is one that can be located,
retrieved, presented and interpreted’ (ISO 15489‑
1:2001, 7.2.5).
(alternative usage) Usability is also a
non-functional aspect of a records system and,
when used in this sense, it refers to the system
as a whole and the quality of the user experience,
including how difficult it is to learn and its ease of Volume 1
operation in day‑to‑day use.
See also authenticity, integrity and reliability. Core Services
& Plug-in Modules
Version 1.1
237
1
Glossary
User (entity) A person or system with an account that

enables access to and use of an MCRS. A user
does not have to be a human and could be another
business system. Users must be authenticated
before they can use an MCRS.
User and group (entity) A logically separate service within an

service MCRS operationally responsible for managing
users and groups. The user and group service may
integrate with or provide a wrapper for a directory.
UUID (acronym) A universally unique identifier.
URI (acronym) A uniform resource identifier.
Value (noun) The data that is placed into a metadata

element. Values must adhere to a strict datatype
described by the equivalent metadata element
definition.
See also code, datatype and default value.
Version (noun) Each service and each module of

MoReq2010® has a version number made up of
a major version and a minor version. A minor
version represents a change to the service or
module that introduces a clarification, correction
or additional non-functional requirement
without changing the underlying information
model. All implementations with the same major
version number should therefore be compatible
with one another even if their minor versions
are different. A major version represents a
change to the information model such as the
addition of new functions or system metadata
elements: this makes an MCRS that only
implements one major version incompatible with
an MCRS that only implements another version.
• MoReq2010®‑provided service identifiers and
MoReq2010 module identifiers are only replaced when major
version numbers change.
See also major version and minor version.
for Records Systems warranted, Principle (concept) A non-functional aspect of a records
of a system being system, a warranted system is one which is issued
with a warrant from the supplier covering its use.
web browser (noun) An application used to visit a website and

load and view web pages.
(disambiguation) The terms browse and inspect
have a special meaning in MoReq2010® that
should not be confused with using a web browser.
xMl (acronym) Extensible Markup Language, a

Volume 1 document format for expressing data in machine
readable text where elements and entities are
Core Services identified by markup inserted into the text.
& Plug-in Modules xMl data (noun) Data representing entities that are
formatted in the export data format used by
MoReq2010® for transfers, including migration.
Version 1.1
238
1
Glossary
xMl data streaming (verb) xMl data transmitted electronically as a

stream or a series of data packets.
xMl transformation (verb) Manipulation of xMl data so as to represent

it in an alternative xMl format or as other types of
data.
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
239
1
14
Information model
14.1 INDEx to tHE INFoRMAtIoN MoDEl ..................241
14.2 ENtIty tyPES .......................................................................249

E14.2.1 Aggregation ......................................................................................249
E14.2.2 Class ................................................................................................250
E14.2.3 Component .......................................................................................251 q
8
E14.2.4 Contextual Metadata Element Definition ..........................................252 i;.444, Q4
E14.2.5 Disposal Hold ...................................................................................253 1 81
E14.2.6 Disposal Schedule ............................................................................254 �,d.2 .a. Jl.1. "

4.,
E14.2.7 Entity type........................................................................................255
7'i, )1 bd22
' ., o
E14.2.8 Event ................................................................................................256
l '
'
< O> 5 4 6 134
E14.2.9 Function Definition ...........................................................................257 ,,
O 38 b 04 • 24
E14.2.10 Group................................................................................................258 84 4 76
< " •
E14.2.11 Metadata Element Definition ............................................................259 • 4 4 7 ea 2
E14.2.12 Record ..............................................................................................260 <
E14.2.13 Role ..................................................................................................261

E14.2.14 Service .............................................................................................262
E14.2.15 template ..........................................................................................263
E14.2.16 User..................................................................................................264
14.3 DAtA StRUCtURES ...........................................................265

D14.3.1 Access Control Entry ........................................................................265
D14.3.2 Access Control list ...........................................................................265
D14.3.3 Metadata Change Entry ....................................................................266 •
MoReq2010
14.4 SyStEM MEtADAtA ElEMENt DEFINItIoNS ...267

M14.4.1 Aggregated timestamp ....................................................................267
for Records Systems
M14.4.2 Applied template Identifier ..............................................................267
M14.4.3 Automatic Deletion Flag ...................................................................268
M14.4.4 Class Identifier .................................................................................268
M14.4.5 Closed timestamp ............................................................................269
M14.4.6 Confirmation Period Duration Number ............................................269
M14.4.7 Confirmation Period Interval Code ...................................................270
M14.4.8 Contextual Metadata Element Definition Identifier ..........................270
M14.4.9 Created timestamp ..........................................................................271
Volume 1
M14.4.10 Datatype ...........................................................................................271
M14.4.11 Default Disposal Schedule Identifier ................................................272 Core Services
M14.4.12 Default language Identifier .............................................................272 & Plug-in Modules
M14.4.13 Default Value ....................................................................................273
M14.4.14 Deleted Event Function Definition Identifier.....................................273 Version 1.1
241
1
Information
model M14.4.15 Deleted Metadata Element Definition Identifier ...............................274
M14.4.16 Description .......................................................................................274
M14.4.17 Destroyed timestamp ......................................................................275
M14.4.18 Disposal Action Code ........................................................................276
M14.4.19 Disposal Action Due Date .................................................................276
M14.4.20 Disposal Confirmation Due Date.......................................................277
M14.4.21 Disposal overdue Alert timestamp ..................................................277
M14.4.22 Disposal Schedule Identifier ............................................................278
M14.4.23 Duplicate Identifier ..........................................................................278
M14.4.24 Entity Reference type Identifier .......................................................279
M14.4.25 Event Comment ................................................................................279
M14.4.26 Event Function Identifier ..................................................................280
M14.4.27 Event occurred timestamp ..............................................................280
M14.4.28 Export Commencing timestamp ......................................................280
M14.4.29 Export Completed timestamp ..........................................................281
M14.4.30 Export Identifier ...............................................................................281
M14.4.31 Exported In Full Flag ........................................................................281
M14.4.32 First Used timestamp ......................................................................282
M14.4.33 Function Definition Identifier............................................................282
M14.4.34 Generate Event Flag .........................................................................283
M14.4.35 Granted Role Identifier .....................................................................283
M14.4.36 Group Identifier ................................................................................283
M14.4.37 Held Aggregation Identifier ..............................................................284
M14.4.38 Held Class Identifier.........................................................................284
M14.4.39 Held Record Identifier ......................................................................285
M14.4.40 Historical Date/time ........................................................................285
M14.4.41 Implements Module Identifier ..........................................................286
M14.4.42 Implements Service Identifier ..........................................................286
M14.4.43 Include Inherited Roles Flag ............................................................287
M14.4.44 Is Administrative Role Flag ..............................................................287
•
MoReq2010 M14.4.45 Is Entity Reference Flag ...................................................................288
M14.4.46 Is Modifiable Flag .............................................................................288
Modular Requirements M14.4.47 Is textual Flag ..................................................................................289
for Records Systems M14.4.48 last Addition timestamp..................................................................289
M14.4.49 last Review Comment ......................................................................290
M14.4.50 last Reviewed timestamp................................................................290
M14.4.51 Mandate ...........................................................................................291
M14.4.52 Max levels of Aggregation ...............................................................291
M14.4.53 Max occurs .......................................................................................292
M14.4.54 MCRS Certification Identifier ............................................................292
M14.4.55 Metadata Element Definition Identifier ............................................293
Volume 1 M14.4.56 Min occurs........................................................................................293
M14.4.57 New Value ........................................................................................294
Core Services M14.4.58 overdue Disposal Action Code ..........................................................294
& Plug-in Modules M14.4.59 overdue Disposal Action Due Date ...................................................295
M14.4.60 overdue Disposal Confirmation Due Date.........................................295
Version 1.1 M14.4.61 originated Date/time .......................................................................296
242
1
Information
M14.4.62 owner Information ...........................................................................296 model
M14.4.63 Parent Aggregation Identifier...........................................................297
M14.4.64 Participating Aggregation Identifier .................................................297
M14.4.65 Participating Class Identifier............................................................298
M14.4.66 Participating Component Identifier ..................................................298
M14.4.67 Participating Disposal Hold Identifier ..............................................299
M14.4.68 Participating Disposal Schedule Identifier .......................................299
M14.4.69 Participating Duplicate Identifier .....................................................300
M14.4.70 Participating Entity type Identifier ...................................................300
M14.4.71 Participating Event Identifier ...........................................................301
M14.4.72 Participating Function Definition Identifier ......................................301
M14.4.73 Participating Group Identifier ...........................................................302
M14.4.74 Participating Metadata Element Definition Identifier .......................302
M14.4.75 Participating New Parent Identifier ..................................................303
M14.4.76 Participating Previous Parent Identifier ...........................................303
M14.4.77 Participating Record Identifier .........................................................304
M14.4.78 Participating Role Identifier .............................................................304
M14.4.79 Participating Service Identifier ........................................................305
M14.4.80 Participating template Identifier .....................................................305
M14.4.81 Participating User Identifier.............................................................306
M14.4.82 Participating User or Group Identifier..............................................306
M14.4.83 Performed By User Identifier ...........................................................307
M14.4.84 Presentation order...........................................................................307
M14.4.85 Previous Value..................................................................................308
M14.4.86 Record Identifier ..............................................................................308
M14.4.87 Rescinded Role Identifier .................................................................309
M14.4.88 Retain on Destruction Flag...............................................................309
M14.4.89 Retention Period Duration Number ..................................................310
M14.4.90 Retention Period Interval Code ........................................................310
M14.4.91 Retention Period offset Code ...........................................................311 •
MoReq2010
M14.4.92 Retention Period offset Month Code ................................................312
M14.4.93 Retention Start Date .........................................................................312
M14.4.94 Retention trigger Code ....................................................................313
for Records Systems
M14.4.95 Retention trigger Element Identifier ...............................................314
M14.4.96 Role Identifier ..................................................................................314
M14.4.97 Scope Notes......................................................................................315
M14.4.98 Search query ....................................................................................315
M14.4.99 Supplier Information ........................................................................316
M14.4.100 System Identifier ..............................................................................316
M14.4.101 template Class Identifier .................................................................317
M14.4.102 template Entity type Identifier ........................................................317
Volume 1
M14.4.103 template Service Identifier ..............................................................318
M14.4.104 title ..................................................................................................319 Core Services
M14.4.105 total Entities ....................................................................................319 & Plug-in Modules
M14.4.106 transferred timestamp ...................................................................320
M14.4.107 User or Group Identifier ...................................................................320 Version 1.1
243
1
Information
model 14.5 FUNCtIoN DEFINItIoNS ...............................................321
F14.5.1 Aggregation — Add Aggregation ......................................................321
F14.5.2 Aggregation — Add Contextual Metadata.........................................322
F14.5.3 Aggregation — Add Record ..............................................................323
F14.5.4 Aggregation — Close........................................................................324
F14.5.5 Aggregation — Create ......................................................................324
F14.5.6 Aggregation — Delete ......................................................................326
F14.5.7 Aggregation — Delete Residual Event..............................................326
F14.5.8 Aggregation — Delete Residual Metadata ........................................327
F14.5.9 Aggregation — Destroy ....................................................................328
F14.5.10 Aggregation — Exported ..................................................................329
F14.5.11 Aggregation — Inherit Default Class ................................................330
F14.5.12 Aggregation — Inspect .....................................................................330
F14.5.13 Aggregation — Inspect ACl..............................................................331
F14.5.14 Aggregation — Inspect Event ...........................................................331
F14.5.15 Aggregation — Modify ACl...............................................................332
F14.5.16 Aggregation — Modify Max levels of Aggregation ...........................333
F14.5.17 Aggregation — Modify Metadata ......................................................333
F14.5.18 Aggregation — Modify originated Date/time ...................................334
F14.5.19 Aggregation — open ........................................................................334
F14.5.20 Aggregation — override Class .........................................................335
F14.5.21 Aggregation — Remove Aggregation ...............................................335
F14.5.22 Aggregation — Remove Record ........................................................336
F14.5.23 Class — Add Contextual Metadata ...................................................336
F14.5.24 Class — Create .................................................................................337
F14.5.25 Class — Delete .................................................................................338
F14.5.26 Class — Delete Residual Event ........................................................338
F14.5.27 Class — Delete Residual Metadata...................................................339
F14.5.28 Class — Destroy ...............................................................................339
•
MoReq2010 F14.5.29 Class — Exported .............................................................................340
F14.5.30 Class — Inspect................................................................................341
F14.5.31 Class — Inspect ACl ........................................................................341
F14.5.32 Class — Inspect Event ......................................................................342
for Records Systems
F14.5.33 Class — Modify ACl .........................................................................343
F14.5.34 Class — Modify Default Disposal Schedule ......................................344
F14.5.35 Class — Modify Metadata .................................................................344
F14.5.36 Class — Modify originated Date/time..............................................345
F14.5.37 Component — Add Contextual Metadata ..........................................346
F14.5.38 Component — Create .......................................................................347
F14.5.39 Component — Delete Residual Event ...............................................348
F14.5.40 Component — Delete Residual Metadata .........................................349
Volume 1
F14.5.41 Component — Destroy .....................................................................350
Core Services F14.5.42 Component — Duplicate ...................................................................351
& Plug-in Modules F14.5.43 Component — Exported ...................................................................352
F14.5.44 Component — Inspect ......................................................................353
Version 1.1 F14.5.45 Component — Inspect Event ............................................................353
244
1
Information
F14.5.46 Component — Modify Metadata .......................................................354 model
F14.5.47 Component — Modify originated Date/time ....................................355
F14.5.48 Contextual Metadata Element Definition — Create ..........................356
F14.5.49 Contextual Metadata Element Definition — Delete ..........................357
F14.5.50 Contextual Metadata Element Definition — Delete Residual Event ....357
F14.5.51 Contextual Metadata Element Definition — Destroy ........................358
F14.5.52 Contextual Metadata Element Definition — Exported ......................359
F14.5.53 Contextual Metadata Element Definition — Modify Before Use........360
F14.5.54 Contextual Metadata Element Definition — Modify originated
Date/time ........................................................................................361
F14.5.55 Disposal Hold — Add Contextual Metadata ......................................361
F14.5.56 Disposal Hold — Add Entity ..............................................................362
F14.5.57 Disposal Hold — Create ...................................................................363
F14.5.58 Disposal Hold — Delete ....................................................................364
F14.5.59 Disposal Hold — Delete Residual Event ...........................................364
F14.5.60 Disposal Hold — Delete Residual Metadata .....................................365
F14.5.61 Disposal Hold — Destroy ..................................................................365
F14.5.62 Disposal Hold — Exported ...............................................................366
F14.5.63 Disposal Hold — Inspect ..................................................................367
F14.5.64 Disposal Hold — Inspect ACl ...........................................................367
F14.5.65 Disposal Hold — Inspect Event.........................................................368
F14.5.66 Disposal Hold — Modify ACl ............................................................369
F14.5.67 Disposal Hold — Modify Metadata ....................................................370
F14.5.68 Disposal Hold — Modify originated Date/time ................................370
F14.5.69 Disposal Hold — Remove Entity .......................................................371
F14.5.70 Disposal Schedule — Add Contextual Metadata ...............................371
F14.5.71 Disposal Schedule — Create ............................................................372
F14.5.72 Disposal Schedule — Delete ............................................................373
F14.5.73 Disposal Schedule — Delete Residual Event ....................................373
F14.5.74 Disposal Schedule — Delete Residual Metadata ..............................374 •
MoReq2010
F14.5.75 Disposal Schedule — Destroy...........................................................374
F14.5.76 Disposal Schedule — Exported ........................................................375
F14.5.77 Disposal Schedule — Inspect ...........................................................376
for Records Systems
F14.5.78 Disposal Schedule — Inspect ACl ....................................................376
F14.5.79 Disposal Schedule — Inspect Event .................................................377
F14.5.80 Disposal Schedule — Modify ACl .....................................................378
F14.5.81 Disposal Schedule — Modify Metadata.............................................379
F14.5.82 Disposal Schedule — Modify originated Date/time .........................380
F14.5.83 Entity type — Inspect .......................................................................380
F14.5.84 Entity type — Inspect ACl ...............................................................381
F14.5.85 Entity type — Inspect Event .............................................................381
Volume 1
F14.5.86 Entity type — Modify ACl.................................................................382
F14.5.87 Function Definition — Inspect ..........................................................383 Core Services
F14.5.88 Function Definition — Inspect ACl ...................................................383 & Plug-in Modules
F14.5.89 Function Definition — Inspect Event ................................................384
F14.5.90 Function Definition — Modify ACl ....................................................385 Version 1.1
245
1
Information
model F14.5.91 Function Definition — Modify Event Generation ...............................386
F14.5.92 Function Definition — Modify Retain Event on Destruction ..............386
F14.5.93 Group — Add Contextual Metadata ..................................................387
F14.5.94 Group — Add User ............................................................................388
F14.5.95 Group — Create ................................................................................389
F14.5.96 Group — Delete ................................................................................390
F14.5.97 Group — Delete Residual Event .......................................................390
F14.5.98 Group — Delete Residual Metadata..................................................391
F14.5.99 Group — Destroy ..............................................................................391
F14.5.100 Group — Exported ............................................................................392
F14.5.101 Group — Inspect ...............................................................................393
F14.5.102 Group — Inspect ACl .......................................................................393
F14.5.103 Group — Inspect Event .....................................................................394
F14.5.104 Group — Modify ACl.........................................................................395
F14.5.105 Group — Modify Metadata ................................................................396
F14.5.106 Group — Modify originated Date/time.............................................396
F14.5.107 Group — Remove User .....................................................................397
F14.5.108 Group — Report User Membership ..................................................397
F14.5.109 Metadata Element Definition — Inspect ...........................................398
F14.5.110 Metadata Element Definition — Inspect ACl ....................................398
F14.5.111 Metadata Element Definition — Inspect Event .................................399
F14.5.112 Metadata Element Definition — Modify ACl .....................................400
F14.5.113 Metadata Element Definition — Modify Metadata ............................401
F14.5.114 Metadata Element Definition — Modify Retain on Destruction ........401
F14.5.115 Record — Add Contextual Metadata .................................................402
F14.5.116 Record — Cancel Destruction...........................................................403
F14.5.117 Record — Cancel transfer ...............................................................404
F14.5.118 Record — Complete Review .............................................................404
F14.5.119 Record — Confirm Destruction ........................................................405
• F14.5.120 Record — Confirm transfer .............................................................405
MoReq2010
F14.5.121 Record — Create ..............................................................................406
F14.5.122 Record — Delete Residual Event ......................................................407
F14.5.123 Record — Delete Residual Metadata ................................................408
for Records Systems
F14.5.124 Record — Destroy ............................................................................409
F14.5.125 Record — Disposal Alert ..................................................................410
F14.5.126 Record — Duplicate ..........................................................................411
F14.5.127 Record — Exported ..........................................................................412
F14.5.128 Record — Held .................................................................................413
F14.5.129 Record — Inherit Default Class ........................................................413
F14.5.130 Record — Inherit Default Disposal Schedule....................................414
F14.5.131 Record — Inspect .............................................................................414
Volume 1
F14.5.132 Record — Inspect ACl ......................................................................415
Core Services F14.5.133 Record — Inspect Event ...................................................................415
& Plug-in Modules F14.5.134 Record — Modify ACl .......................................................................416
F14.5.135 Record — Modify Metadata ..............................................................417
Version 1.1 F14.5.136 Record — Modify originated Date/time ...........................................417
246
1
Information
F14.5.137 Record — override Class .................................................................418 model
F14.5.138 Record — override Disposal Schedule .............................................418
F14.5.139 Record — Released ..........................................................................419
F14.5.140 Record — Update Disposal ...............................................................420
F14.5.141 Role — Add Contextual Metadata .....................................................421
F14.5.142 Role — Add Function Definition ........................................................421
F14.5.143 Role — Create ..................................................................................422
F14.5.144 Role — Delete ..................................................................................423
F14.5.145 Role — Delete Residual Event ..........................................................423
F14.5.146 Role — Delete Residual Metadata ....................................................424
F14.5.147 Role — Destroy ................................................................................424
F14.5.148 Role — Exported ..............................................................................425
F14.5.149 Role — Inspect .................................................................................426
F14.5.150 Role — Inspect ACl ..........................................................................426
F14.5.151 Role — Inspect Event .......................................................................427
F14.5.152 Role — Modify ACl ...........................................................................428
F14.5.153 Role — Modify Metadata...................................................................429
F14.5.154 Role — Modify originated Date/time ...............................................429
F14.5.155 Role — Remove Function Definition .................................................430
F14.5.156 Role — Report Function Definitions .................................................430
F14.5.157 Service — Add Contextual Metadata ................................................431
F14.5.158 Service — Inspect ............................................................................431
F14.5.159 Service — Inspect ACl .....................................................................432
F14.5.160 Service — Inspect Event ...................................................................432
F14.5.161 Service — Modify ACl ......................................................................433
F14.5.162 Service — Modify Metadata ..............................................................434
F14.5.163 Service — Report Compliance ..........................................................434
F14.5.164 template — Add Contextual Metadata .............................................435
F14.5.165 template — Create ..........................................................................436
F14.5.166 template — Delete ...........................................................................437 •
MoReq2010
F14.5.167 template — Delete Residual Event ..................................................437
F14.5.168 template — Delete Residual Metadata ............................................438
F14.5.169 template — Destroy .........................................................................438
for Records Systems
F14.5.170 template — Exported ......................................................................439
F14.5.171 template — Inspect .........................................................................440
F14.5.172 template — Inspect ACl ..................................................................440
F14.5.173 template — Inspect Event................................................................441
F14.5.174 template — Modify ACl ...................................................................442
F14.5.175 template — Modify Metadata ...........................................................443
F14.5.176 template — Modify originated Date/time .......................................443
F14.5.177 User — Add Contextual Metadata ....................................................444
Volume 1
F14.5.178 User — Browse Records Due For Disposal .......................................444
F14.5.179 User — Create ..................................................................................445 Core Services
F14.5.180 User — Delete ..................................................................................446 & Plug-in Modules
F14.5.181 User — Delete Residual Event .........................................................446
F14.5.182 User — Delete Residual Metadata....................................................447 Version 1.1
247
1
Information
model F14.5.183 User — Destroy ................................................................................447
F14.5.184 User — Detailed Report ...................................................................448
F14.5.185 User — Export..................................................................................449
F14.5.186 User — Exported ..............................................................................450
F14.5.187 User — Inspect .................................................................................451
F14.5.188 User — Inspect ACl .........................................................................451
F14.5.189 User — Inspect Event .......................................................................452
F14.5.190 User — Modify ACl ..........................................................................453
F14.5.191 User — Modify Metadata ..................................................................454
F14.5.192 User — Modify originated Date/time...............................................454
F14.5.193 User — Report Authorisation ...........................................................455
F14.5.194 User — Report Group Membership ..................................................456
F14.5.195 User — Search .................................................................................456
F14.5.196 User — Summary Report .................................................................457
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
248
1
Information
14.2 ENtIty tyPES model
E14.2.1 Aggregation
System Identifier c4bd4f18‑e3f5‑4dba‑819d‑8d58cbd0aed4
title Aggregation
Description Aggregation of individual records or higher level

aggregation of aggregations of records
Service Record service
System metadata • System Identifier (M14.4.100)

• Created Timestamp (M14.4.9)
• Originated Date/Time (M14.4.61)
• First Used Timestamp (M14.4.32)
• Last Addition Timestamp (M14.4.48)
• Class Identifier (M14.4.4)
• Title (M14.4.104)
• Description (M14.4.16)
• Scope Notes (M14.4.97)
• Closed Timestamp (M14.4.5)
• Destroyed Timestamp (M14.4.17)
• Max Levels Of Aggregation (M14.4.52)
• Parent Aggregation Identifier (M14.4.63)
• Aggregated Timestamp (M14.4.1)
Functions • Aggregation — Add Aggregation (F14.5.1)

• Aggregation — Add Contextual Metadata
(F14.5.2)
• Aggregation — Add Record (F14.5.3)
• Aggregation — Close (F14.5.4)
• Aggregation — Create (F14.5.5)
• Aggregation — Delete (F14.5.6)
• Aggregation — Delete Residual Event
(F14.5.7)
• Aggregation — Delete Residual Metadata •
MoReq2010
(F14.5.8)
• Aggregation — Destroy (F14.5.9)
• Aggregation — Exported (F14.5.10) Modular Requirements
• Aggregation — Inherit Default Class for Records Systems
(F14.5.11)
• Aggregation — Inspect (F14.5.12)
• Aggregation — Inspect ACL (F14.5.13)
• Aggregation — Inspect Event (F14.5.14)
• Aggregation — Modify ACL (F14.5.15)
• Aggregation — Modify Max Levels Of
Aggregation (F14.5.16)
• Aggregation — Modify Metadata (F14.5.17)
• Aggregation — Modify Originated Date/Time
(F14.5.18) Volume 1
• Aggregation — Open (F14.5.19)
• Aggregation — Override Class (F14.5.20) Core Services
• Aggregation — Remove Aggregation & Plug-in Modules
(F14.5.21)
• Aggregation — Remove Record (F14.5.22)
Version 1.1
249
1
Information
model E14.2.2 Class
System Identifier 5a5240e2‑939b‑43dd‑a50b‑2d3284d81735
title Class
Description Business classification applied to records and

aggregations of records
Service Classification service

• Title (M14.4.104)
• Default Disposal Schedule Identifier
(M14.4.11)
Functions • Class — Add Contextual Metadata (F14.5.23)

• Class — Create (F14.5.24)
• Class — Delete (F14.5.25)
• Class — Delete Residual Event (F14.5.26)
• Class — Delete Residual Metadata (F14.5.27)
• Class — Destroy (F14.5.28)
• Class — Exported (F14.5.29)
• Class — Inspect (F14.5.30)
• Class — Inspect ACL (F14.5.31)
• Class — Inspect Event (F14.5.32)
• Class — Modify ACL (F14.5.33)
• Class — Modify Default Disposal Schedule
•
MoReq2010 (F14.5.34)
• Class — Modify Metadata (F14.5.35)
• Class — Modify Originated Date/Time
Modular Requirements (F14.5.36)
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
250
1
Information
E14.2.3 Component model
System Identifier 7af81a86‑c6d4‑43f7‑b62d‑6c7b905231dd
title Component
Description Individual component of a record representing its content

• Record Identifier (M14.4.86)
• Title (M14.4.104)
• Duplicate Identifier (M14.4.23)
• Automatic Deletion Flag (M14.4.3)
Functions • Component — Add Contextual Metadata (F14.5.37)

• Component — Create (F14.5.38)
• Component — Delete Residual Event (F14.5.39)
• Component — Delete Residual (F14.5.40)
• Component — Destroy (F14.5.41)
• Component — Duplicate (F14.5.42)
• Component — Exported (F14.5.43)
• Component — Inspect (F14.5.44)
• Component — Inspect Event (F14.5.45)
• Component — Modify Metadata (F14.5.46)
• Component — Modify Originated Date/Time (F14.5.47)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
251
1
Information
model E14.2.4 Contextual Metadata Element Definition
System Identifier 5effc721‑2184‑4014‑a4f0‑5e399b41be57
title Contextual Metadata Element Definition
Description Definition of the properties of a contextual

metadata element
Subtype of Metadata Element Definition (E14.2.11)
Service Metadata service
Additional system As for Metadata Element Definition (E14.2.11) plus

metadata the following additional system metadata.
Additional functions As for Metadata Element Definition (E14.2.11) plus

the following additional functions.
• Contextual Metadata Element Definition —
Create (F14.5.48)
Delete (F14.5.49)
Delete Residual Event (F14.5.50)
Destroy (F14.5.51)
Exported (F14.5.52)
Modify Before Use (F14.5.53)
Modify Originated Date/Time (F14.5.54)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
252
1
Information
E14.2.5 Disposal Hold model
System Identifier 93645ca5‑29c2‑428b‑9adc‑b61b56d2c8bb
title Disposal Hold
Description Legal or other hold preventing the scheduled

destruction of records
Service Disposal holding service

• Held Record Identifier (M14.4.39)
• Held Aggregation Identifier (M14.4.37)
• Held Class Identifier (M14.4.38)
• Title (M14.4.104)
• Mandate (M14.4.51)
Functions • Disposal Hold — Add Contextual Metadata

(F14.5.55)
• Disposal Hold — Add Entity (F14.5.56)
• Disposal Hold — Create (F14.5.57)
• Disposal Hold — Delete (F14.5.58)
• Disposal Hold — Delete Residual Event
(F14.5.59)
• Disposal Hold — Delete Residual Metadata
(F14.5.60)
• Disposal Hold — Destroy (F14.5.61)
• Disposal Hold — Exported (F14.5.62) •
MoReq2010
• Disposal Hold — Inspect (F14.5.63)
• Disposal Hold — Inspect ACL (F14.5.64)
• Disposal Hold — Inspect Event (F14.5.65) Modular Requirements
• Disposal Hold — Modify ACL (F14.5.66) for Records Systems
• Disposal Hold — Modify Metadata (F14.5.67)
• Disposal Hold — Modify Originated Date/
Time (F14.5.68)
• Disposal Hold — Remove Entity (F14.5.69)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
253
1
Information
model E14.2.6 Disposal Schedule
System Identifier 00b35d5d‑301e‑4000‑ad18‑211de45edb32
title Disposal Schedule
Description Schedule by which records are retained for a

specified period of time followed by their planned
disposal
Service Disposal scheduling service

• Title (M14.4.104)
• Disposal Action Code (M14.4.18)
• Retention Trigger Code (M14.4.94)
• Retention Trigger Element Identifier
(M14.4.95)
• Retention Period Interval Code (M14.4.90)
• Retention Period Duration Number
(M14.4.89)
• Retention Period Offset Code (M14.4.91)
• Retention Period Offset Month Code
(M14.4.92)
• Confirmation Period Interval Code (M14.4.7)
• Confirmation Period Duration Number
(M14.4.6)
• Functions • Disposal Schedule — Add Contextual

MoReq2010 Metadata (F14.5.70)
• Disposal Schedule — Create (F14.5.71)
Modular Requirements • Disposal Schedule — Delete (F14.5.72)
for Records Systems • Disposal Schedule — Delete Residual Record
(F14.5.73)
• Disposal Schedule — Delete Residual
Metadata (F14.5.74)
• Disposal Schedule — Destroy (F14.5.75)
• Disposal Schedule — Exported (F14.5.76)
• Disposal Schedule — Inspect (F14.5.77)
• Disposal Schedule — Inspect ACL (F14.5.78)
• Disposal Schedule — Inspect Event
Volume 1 (F14.5.79)
• Disposal Schedule — Modify ACL (F14.5.80)
Core Services • Disposal Schedule — Modify Metadata
& Plug-in Modules (F14.5.81)
• Disposal Schedule — Modify Originated Date/
Time (F14.5.82)
Version 1.1
254
1
Information
E14.2.7 Entity type model
System Identifier 5f423557‑6130‑43dc‑930f‑f95c6700e630
title Entity type
Description Definition of an entity, including a list of its system

metadata and the functions that can be performed
on it

• Title (M14.4.104)
Functions • Entity Type — Inspect (F14.5.83)

• Entity Type — Inspect ACL (F14.5.84)
• Entity Type — Inspect Event (F14.5.85)
• Entity Type — Modify ACL (F14.5.86)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
255
1
Information
model E14.2.8 Event
System Identifier 97ff1eaa‑30cd‑4ea1‑8ec2‑2cbc50732d56

title Event
Description Description of the outcome of a function that was
performed previously and is retained to show the
history of an entity
• Event Occurred Timestamp (M14.4.27)
• Event Function Identifier (M14.4.26)
• Performed By User Identifier (M14.4.83)
• Event Comment (M14.4.25)
• Metadata Change Entry (D14.3.3)
• Applied Template Identifier (M14.4.2)
• Deleted Event Function Definition Identifier
(M14.4.14)
• Deleted Metadata Function Definition Identifier
(M14.4.15)
• Export Commencing Timestamp (M14.4.28)
• Export Completed Timestamp (M14.4.29)
• Export Identifier (M14.4.30)
• Exported In Full Flag (M14.4.31)
• Granted Role Identifier (M14.4.35)
• Historical Date/Time (M14.4.40)
• Overdue Disposal Action Code (M14.4.58)
• Overdue Disposal Action Due Date (M14.4.59)
• Overdue Disposal Confirmation Due Date
(M14.4.60)
• Participating Aggregation Identifier (M14.4.64)
• Participating Class Identifier (M14.4.65)
• Participating Component Identifier (M14.4.66)
• Participating Disposal Hold Identifier (M14.4.67)
• Participating Disposal Schedule Identifier
(M14.4.68)
• Participating Duplicate Identifier (M14.4.69)
• Participating Entity Type Identifier (M14.4.70)
• • Participating Event Identifier (M14.4.71)
MoReq2010
• Participating Function Definition Identifier
(M14.4.72)
• Participating Group Identifier (M14.4.73)
Modular Requirements • Participating Metadata Element Definition
for Records Systems Identifier (M14.4.74)
• Participating New Parent Identifier (M14.4.75)
• Participating Previous Parent Identifier
(M14.4.76)
• Participating Record Identifier (M14.4.77)
• Participating Role Identifier (M14.4.78)
• Participating Service Identifier (M14.4.79)
• Participating Template Identifier (M14.4.80)
• Participating User Identifier (M14.4.81)
• Participating User or Group Identifier
(M14.4.82)
Volume 1 • Rescinded Role Identifier (M14.4.87)
• Search Query (M14.4.98)
Core Services • Total Entities (M14.4.105)
& Plug-in Modules Functions See the other entity types — once generated, an event
is part of the event history of an entity and accessed
Version 1.1 through that entity
256
1
Information
E14.2.9 Function Definition model
System Identifier 5c433e4e‑f926‑4206‑ba3f‑998b14b8dabb
title Function Definition
Description Definition of function that can be performed with

an entity by a user

• Title (M14.4.104)
• Generate Event Flag (M14.4.34)
• Retain On Destruction Flag (M14.4.88)
Functions • Function Definition — Inspect (F14.5.87)

• Function Definition — Inspect ACL (F14.5.88)
• Function Definition — Inspect Event
(F14.5.89)
• Function Definition — Modify ACL (F14.5.90)
• Function Definition — Modify Event
Generation (F14.5.91)
• Function Definition — Modify Retain Event On
Destruction (F14.5.92)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
257
1
Information
model E14.2.10 Group
System Identifier 9cac7661‑62c9‑4a9d‑8c64‑d000210674ee
title Group
Description Group of users
Service User and group service

• Title (M14.4.104)
Functions • Group — Add Contextual Metadata (F14.5.93)

• Group — Add User (F14.5.94)
• Group — Create (F14.5.95)
• Group — Delete (F14.5.96)
• Group — Delete Residual Event (F14.5.97)
• Group — Delete Residual Metadata
(F14.5.98)
• Group — Destroy (F14.5.99)
• Group — Exported (F14.5.100)
• Group — Inspect (F14.5.101)
• Group — Inspect ACL (F14.5.102)
• Group — Inspect Event (F14.5.103)
• Group — Modify ACL (F14.5.104)
• Group — Modify Metadata (F14.5.105)
• Group — Modify Originated Date/Time
(F14.5.106)
•
MoReq2010 • Group — Remove User (F14.5.107)
• Group — Report User Membership
(F14.5.108)
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
258
1
Information
E14.2.11 Metadata Element Definition model
System Identifier e6682264‑1902‑434c‑beb3‑18a29795aaf4
title Metadata Element Definition
Description Definition of the properties of a system metadata

element
Service Metadata service

• Title (M14.4.104)
• Presentation Order (M14.4.84)
• Min Occurs (M14.4.56)
• Max Occurs (M14.4.53)
• Is Modifiable Flag (M14.4.46)
• Is Entity Reference Flag (M14.4.45)
• Entity Reference Type Identifier (M14.4.24)
• Datatype (M14.4.10)
• Is Textual Flag (M14.4.47)
• Default Value (M14.4.13)
• Default Language Identifier (M14.4.12)
Functions • Metadata Element Definition — Inspect

(F14.5.109)
• Metadata Element Definition — Inspect ACL
(F14.5.110)
• Metadata Element Definition — Inspect Event
(F14.5.111)
• Metadata Element Definition — Modify ACL
(F14.5.112) •
• Metadata Element Definition — Modify MoReq2010
Metadata (F14.5.113)
• Metadata Element Definition — Modify Retain Modular Requirements
On Destruction (F14.5.114)
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
259
1
Information
model E14.2.12 Record
System Identifier 3ac228ef‑c008‑4524‑9e41‑5c4564eaa7f0
title Record
Description Record of a business transaction made up of one

or more components that are managed atomically

• Title (M14.4.104)
• Disposal Schedule Identifier (M14.4.22)
• Retention Start Date (M14.4.93)
• Disposal Action Due Date (M14.4.19)
• Disposal Confirmation Due Date (M14.4.20)
• Disposal Overdue Alert Timestamp
(M14.4.21)
• Last Review Comment (M14.4.49)
• Last Reviewed Timestamp (M14.4.50)
• Transferred Timestamp (M14.4.106)
Functions • Record — Add Contextual Metadata

(F14.5.115)
• Record — Cancel Destruction (F14.5.116)
• Record — Cancel Transfer (F14.5.117)
• Record — Complete Review (F14.5.118)
• Record — Confirm Destruction (F14.5.119)
• Record — Confirm Transfer (F14.5.120)
• Record — Create (F14.5.121)
• • Record — Delete Residual Event (F14.5.122)
MoReq2010 • Record — Delete Residual Metadata
(F14.5.123)
• Record — Destroy (F14.5.124)
Modular Requirements • Record — Disposal Alert (F14.5.125)
• Record — Duplicate (F14.5.126)
for Records Systems
• Record — Exported (F14.5.127)
• Record — Held (F14.5.128)
• Record — Inherit Default Class (F14.5.129)
• Record — Inherit Default Disposal Schedule
(F14.5.130)
• Record — Inspect (F14.5.131)
• Record — Inspect ACL(F14.5.132)
• Record — Inspect Event (F14.5.133)
• Record — Modify ACL (F14.5.134)
• Record — Modify Metadata (F14.5.135)
Volume 1 • Record — Modify Originated Date/Time
(F14.5.136)
Core Services • Record — Override Class (F14.5.137)
• Record — Override Disposal Schedule
& Plug-in Modules (F14.5.138)
• Record — Released (F14.5.139)
• Record — Update Disposal (F14.5.140)
Version 1.1
260
1
Information
E14.2.13 Role model
System Identifier fc9f9333‑097f‑4a84‑96f2‑11ad6b444ebf
title Role
Description Function definitions that have been arranged into

a role that may be granted to a user or a group to
allow them access to entities
Service Role service

• Is Administrative Role Flag (M14.4.44)
• Title (M14.4.104)
• Function Definition Identifier (M14.4.33)
Functions • Role — Add Contextual Metadata (F14.5.141)

• Role — Add Function Definition (F14.5.142)
• Role — Create (F14.5.143)
• Role — Delete (F14.5.144)
• Role — Delete Residual Event (F14.5.145)
• Role — Delete Residual Metadata (F14.5.146)
• Role — Destroy (F14.5.147)
• Role — Exported (F14.5.148)
• Role — Inspect (F14.5.149)
• Role — Inspect ACL (F14.5.150)
• Role — Inspect Event (F14.5.151)
•
• Role — Modify ACL (F14.5.152) MoReq2010
• Role — Modify Metadata (F14.5.153)
• Role — Modify Originated Date/Time
(F14.5.154)
for Records Systems
• Role — Remove Function Definition
(F14.5.155)
• Role — Report Function Definitions
(F14.5.156)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
261
1
Information
model E14.2.14 Service
System Identifier 363d5464‑db6c‑464b‑980a‑1851464cab45
title Service
Description Specific service within an MCRS that manages

particular entity types

• Implements Service Identifier (M14.4.42)
• Implements Module Identifier (M14.4.41)
• MCRS Certification Identifier (M14.4.54)
• Supplier Information (M14.4.99)
• Title (M14.4.104)
• Owner Information (M14.4.62)
Functions • Service — Add Contextual Metadata

(F14.5.157)
• Service — Inspect (F14.5.158)
• Service — Inspect ACL (F14.5.159)
• Service — Inspect Event (F14.5.160)
• Service — Modify ACL (F14.5.161)
• Service — Modify Metadata (F14.5.162)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
262
1
Information
E14.2.15 template model
System Identifier 92596e33‑da23‑4c9f‑8de6‑e585f027157a
title template
Description Template set of contextual metadata element

definitions that can be used to add contextual
metadata elements to entities at creation or later

• Title (M14.4.104)
• Template Entity Type Identifier (M14.4.102)
• Template Service Identifier (M14.4.103)
• Template Class Identifier (M14.4.101)
• Contextual Metadata Element Definition
Identifier (M14.4.8)
Functions • Template — Add Contextual Metadata

(F14.5.164)
• Template — Create (F14.5.165)
• Template — Delete (F14.5.166)
• Template — Delete Residual Event
(F14.5.167)
• Template — Delete Residual Metadata
(F14.5.168)
• Template — Destroy (F14.5.169)
• Template — Exported (F14.5.170)
• Template — Inspect (F14.5.171)
•
• Template — Inspect ACL (F14.5.172) MoReq2010
• Template — Inspect Event (F14.5.173)
• Template — Modify ACL (F14.5.174)
• Template — Modify Metadata (F14.5.175)
for Records Systems
• Template — Modify Originated Date/Time
(F14.5.176)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
263
1
Information
model E14.2.16 User
System Identifier 19c91384‑1dfb‑470a‑bf1e‑c1574ea4ba51
title User
Description Entity representing a user of the MCRS

• Group Identifier (M14.4.36)
• Title (M14.4.104)
Functions • User — Add Contextual Metadata (F14.5.177)

• User — Browse Records Due For Disposal
(F14.5.178)
• User — Create (F14.5.179)
• User — Delete (F14.5.180)
• User — Delete Residual Event (F14.5.181)
• User — Delete Residual Metadata
(F14.5.182)
• User — Destroy (F14.5.183)
• User — Detailed Report (F14.5.184)
• User — Export (F14.5.185)
• User — Exported (F14.5.186)
• User — Inspect (F14.5.187)
• User — Inspect ACL (F14.5.188)
• User — Inspect Event (F14.5.189)
• User — Modify ACL (F14.5.190)
• • User — Modify Metadata (F14.5.191)
MoReq2010
• User — Modify Originated Date/Time
(F14.5.192)
Modular Requirements • User — Report Authorisation (F14.5.193)
for Records Systems • User — Report Group Membership
(F14.5.194)
• User — Search (F14.5.195)
• User — Summary Report (F14.5.196)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
264
1
Information
14.3 DAtA StRUCtURES model
D14.3.1 Access Control Entry
System Identifier 60124baa‑2625‑4795‑bf14‑7e67f2224ccf
title Access Control Entry
Description Compound metadata structure within the access

control list of an entity which associates a user or
a group with one or more roles
Entity type Access Control List (D14.3.2)
System metadata • User Or Group Identifier (M14.4.107)

• Role Identifier (M14.4.96)
Min occurs 0
Max occurs Unlimited
D14.3.2 Access Control list
System Identifier 082da683‑1a04‑4cf3‑9096‑98837a711cbe
title Access Control list
Description Compound metadata structure within an entity

used for determining access control and which
maintains a list of access control entries
Entity type • Aggregation (E14.2.1)

• Class (E14.2.2)
(E14.2.4)
• Disposal Hold (E14.2.5)
• Disposal Schedule (E14.2.6)
• Entity Type (E14.2.7) •
• Function Definition (E14.2.9) MoReq2010
• Group (E14.2.10)
• Metadata Element Definition (E14.2.11) Modular Requirements
• Record (E14.2.12) for Records Systems
• Role (E14.2.13)
• Service (E14.2.14)
• Template (E14.2.15)
• User (E14.2.16)
System metadata • Include Inherited Roles Flag (M14.4.43)

• Access Control Entry (D14.3.1)
Min occurs 1
Volume 1
Max occurs 1
Core Services
& Plug-in Modules
Version 1.1
265
1
Information
model D14.3.3 Metadata Change Entry
System Identifier 7e32c9c9‑e00a‑4dbe‑8c5f‑c05421e632c2
title Metadata Change Entry
Description Compound metadata structure used by events

to track the changes made to metadata when
functions are performed
Entity type Event (E14.2.8)
System metadata • Metadata Element Definition Identifier

(M14.4.55)
• Previous Value (M14.4.85)
• New Value (M14.4.57)
Min occurs 0
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
266
1
Information
14.4 SyStEM MEtADAtA ElEMENt DEFINItIoNS model
M14.4.1 Aggregated timestamp
System Identifier 05fd550b‑ff6c‑4fd0‑b1f6‑b27df905076f
title Aggregated timestamp
Description System set date and time when the child

aggregation or record was created in, or added to,
its current aggregation

• Record (E14.2.12)
Min occurs 0 (for root aggregations)

1 (for child aggregations and records)
Max occurs 0 (for root aggregations)

Modifiable? No
Entity reference? No
Datatype Timestamp
M14.4.2 Applied template Identifier
System Identifier 65a2d42c‑dfe3‑4fbf‑a894‑8db373ac2d45
title Applied template Identifier
Description Template that was applied when the function was

performed to add contextual metadata elements to
entities
Min occurs 0 •
MoReq2010
Modifiable? No
Entity reference? Yes for Records Systems
Refers to type Template (E14.2.15)
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
267
1
Information
model M14.4.3 Automatic Deletion Flag
System Identifier 4a9c44df‑a9ac‑4b06‑8c87‑d5940cd76046
title Automatic Deletion Flag
Description Flag that indicates whether the content of the

component can be automatically deleted by the
system when its record is destroyed
Entity type Component (E14.2.3)
Min occurs 1
Max occurs 1
Modifiable? No
Datatype Boolean
M14.4.4 Class Identifier
System Identifier 7d935531‑e7e6‑4a28‑a474‑431c68522cfa
title Class Identifier
Description The classification of the entity, used by child

aggregations and records to override the class
they inherit from their parent aggregation

• Record (E14.2.12)
Min occurs 0 (for child aggregations and records)

1 (for root aggregations)
Max occurs 1
• Modifiable? Yes (by reclassifying the aggregation or record)

MoReq2010
Entity reference? Yes
Reference type Class (E14.2.2)

for Records Systems Datatype UUID
Usage notes For child aggregations and records only — used when
the default disposal schedule is overridden
Volume 1
Core Services
& Plug-in Modules
Version 1.1
268
1
Information
M14.4.5 Closed timestamp model
System Identifier b0194c04‑bd20‑4582‑af83‑5da3d55c258a
title Closed timestamp
Description System set date and time when the aggregation

was closed
Entity type Aggregation (E14.2.1)
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Timestamp
M14.4.6 Confirmation Period Duration Number
System Identifier 64d99feb‑2654‑4c09‑accd‑a00417f78596
title Confirmation Period Duration Number
Description Number of days or weeks allowed for confirming

the disposal of the record
Entity type Disposal Schedule (E14.2.6)
Min occurs 0
Max occurs 1
Modifiable? Yes (until disposal schedule is first used)

No (once disposal schedule has been used)
Datatype Positive integer •

MoReq2010
Usage notes Used with Confirmation Period Interval Code
(M14.4.7)
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
269
1
Information
model M14.4.7 Confirmation Period Interval Code
System Identifier 30cd2d6f‑9957‑4904‑b0a7‑ade8f181cb68
title Confirmation Period Interval Code
Description Unit of measurement of time as either days or

weeks
Min occurs 0
Max occurs 1

Refers to type Code
Valid values 1 = DAYS

2 = WEEKS
3 = MONTHS
Usage notes Used with Confirmation Period Duration Number

(M14.4.6)
M14.4.8 Contextual Metadata Element Definition Identifier
System Identifier 1b4ee523‑d46d‑4614‑a3a6‑edad609f46ab
title Contextual Metadata Element Definition

Identifier
Description Contextual metadata element included in a

template that can be applied to entities as
additional contextual metadata
• Entity type Template (E14.2.15)
MoReq2010
Min occurs 0
Modular Requirements Max occurs Unlimited

for Records Systems Modifiable? Yes
Refers to type Contextual Metadata Element Definition (E14.2.4)
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
270
1
Information
M14.4.9 Created timestamp model
System Identifier 466a4378‑db7d‑4b2c‑b35e‑696722f58c6b
title Created timestamp
Description System set date and time when the entity was
created

• Class (E14.2.2)
• Component (E14.2.3)
(E14.2.4)
• Event (E14.2.8)
• Group (E14.2.10)
• Record (E14.2.12)
• Role (E14.2.13)
• User (E14.2.16)
Min occurs 1
Max occurs 1
Modifiable? No
Datatype Timestamp
M14.4.10 Datatype
System Identifier e7f28bcc‑0857‑4361‑b6e4‑1bebffdd7578

•
MoReq2010
title Datatype
Description XML datatype definition giving the precise format

required for the value of a system or contextual Modular Requirements
metadata element for Records Systems
Entity type Metadata Element Definition (E14.2.11)
Min occurs 1
Max occurs 1
Modifiable? Yes (for contextual metadata prior to their first use)

No (for system metadata and after the definition
has been applied)
Entity reference? No Volume 1

Datatype XML Datatype Definition Core Services
Usage notes The W3C XML namespace under which the datatype & Plug-in Modules
is defined is included with the datatype definition on
export
Version 1.1
271
1
Information
model M14.4.11 Default Disposal Schedule Identifier
System Identifier b5a0997f‑3285‑4606‑a20b‑1d938b1415c7
title Default Disposal Schedule Identifier
Description Disposal schedule for the class which is inherited

by default by records with this classification
Entity type Class (E14.2.2)
Min occurs 1
Max occurs 1
Modifiable? Yes
Refers to type Disposal Schedule (E14.2.6)
Datatype UUID
M14.4.12 Default language Identifier
System Identifier ad13c98d‑6ff4‑4e0d‑9ccd‑a7d7238591f8
title Default language Identifier
Description Default language for a service or a metadata

element definition, used as a default by textual
metadata elements (only)
Entity type • Metadata Element Definition (E14.2.11)

Min occurs 0
Max occurs 1
Modifiable? No
•
MoReq2010
Datatype Valid language identifier
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
272
1
Information
M14.4.13 Default Value model
System Identifier ae0b3b8e‑f6fa‑49e7‑b411‑d03bda7013f4
title Default Value
Description The default value for a metadata element when it

is first applied to an entity
Min occurs 0
Max occurs Limited to the maximum number of occurrences

allowed for the metadata element in the metadata
element definition
Modifiable? Yes
Entity reference? Dependent on the settings in the metadata

element definition
Refers to type Dependent on the settings in the metadata

element definition
Datatype Dependent on the settings in the metadata

element definition
textual? Dependent on the settings in the metadata

element definition
M14.4.14 Deleted Event Function Definition Identifier
System Identifier eec57404‑3539‑4c24‑b3f5‑bf55f1a8f99e
title Deleted Event Function Definition Identifier
Description Function or functions indicating the type or types

of event that have been deleted from the event
history of the entity
•
Entity type Event (E14.2.8) MoReq2010
Min occurs 0
Max occurs Unlimited (depends on the number and types of Modular Requirements
events that were deleted) for Records Systems
Modifiable? No
Refers to type Function Definition (E14.2.9)
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
273
1
Information
model M14.4.15 Deleted Metadata Element Definition Identifier
System Identifier bb2a7c80‑a367‑4734‑9676‑a2bb2fab2e26
title Deleted Metadata Element Definition Identifier
Description Metadata element definition or definitions

indicating the type or types of metadata elements
that have been deleted from the entity
Min occurs 0
Max occurs Unlimited (depends on the number and types of

metadata elements that were deleted)
Modifiable? No
Refers to type Metadata Element Definition (E14.2.11)
Datatype UUID
M14.4.16 Description
System Identifier c7e6aad5‑27dd‑47a4‑97a6‑ab541b47b37f
title Description
Description Description of the entity

• Class (E14.2.2)
• Entity Type (E14.2.7)
•
MoReq2010 • Function Definition (E14.2.9)
• Group (E14.2.10)
• Metadata Element Definition (E14.2.11)
for Records Systems • Record (E14.2.12)
• Role (E14.2.13)
• User (E14.2.16)
Min occurs 0
Max occurs 1
Modifiable? Yes
Volume 1
Core Services
Datatype Text
& Plug-in Modules
textual? Yes (must be accompanied by a language identifier)
Version 1.1
274
1
Information
M14.4.17 Destroyed timestamp model
System Identifier dbcf3076‑c193‑41fb‑8043‑635c8bc299b2
title Destroyed timestamp
Description System set date and time when the entity was
destroyed

• Class (E14.2.2)
(E14.2.4)
• Group (E14.2.10)
• Record (E14.2.12)
• Role (E14.2.13)
• User (E14.2.16)
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Timestamp
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
275
1
Information
model M14.4.18 Disposal Action Code
System Identifier 83de3514‑3888‑4eff‑88bd‑d58cfb043cc7
title Disposal Action Code
Description Code describing the action to be taken on disposal

of the record
Entity type • Disposal Schedule (E14.2.6)

• Record (E14.2.12)
Min occurs 1
Max occurs 1
Modifiable? Yes (for disposal schedules prior to their first use)

No (for records and disposal schedules after their
use)
Datatype Code
Valid values 0 = RETAIN ON HOLD (not valid for disposal

schedules)
1 = RETAIN PERMANENTLY
2 = REVIEW
3 = TRANSFER
4 = DESTROY
Usage notes For records, this value is updated automatically by

the system
M14.4.19 Disposal Action Due Date
System Identifier 90
title Disposal Action Due Date
• Description The calculated date that the record is due for

MoReq2010 disposal
Entity type Record (E14.2.12)

Min occurs 0
for Records Systems
Max occurs 1
Modifiable? No (updated automatically)
Datatype Date
Volume 1
Core Services
& Plug-in Modules
Version 1.1
276
1
Information
M14.4.20 Disposal Confirmation Due Date model
System Identifier 39971796‑dfd3‑47b4‑b36c‑b2d5d0d770c7
title Disposal Confirmation Due Date
Description The calculated date by which confirmation of

carrying out the disposal action is due
Min occurs 0
Max occurs 1
Modifiable? No (updated automatically)
Datatype Date
M14.4.21 Disposal overdue Alert timestamp
System Identifier df4d965b‑6e65‑4131‑b58b‑0840c0bfd69d
title Disposal overdue Alert timestamp
Description System set date and time when an alert was sent
because the record was overdue for disposal
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Date
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
277
1
Information
model M14.4.22 Disposal Schedule Identifier
System Identifier aee900e0‑bb8b‑4b9b‑b714‑738ed3bc14a3
title Disposal Schedule Identifier
Description The disposal schedule for the record when the

inherited disposal schedule from the record’s
classification has been overridden
Min occurs 1
Max occurs 1
Modifiable? Yes
Datatype UUID
Usage notes Only used when the default disposal schedule is

overridden
M14.4.23 Duplicate Identifier
System Identifier b887bda3‑f34d‑4ddd‑8069‑630567d949d2
title Duplicate Identifier
Description Reference to another entity that has been created

by duplicating the record, component or event, and
is an exact copy up to the event of duplication, with
an identical provenance
Entity type • Component (E14.2.3)

• Event (E14.2.8)
• • Record (E14.2.12)
MoReq2010
Min occurs 0
Modular Requirements Max occurs Unlimited

for Records Systems Modifiable? No
Refers to type • Component (E14.2.3)

• Event (E14.2.8)
• Record (E14.2.12)
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
278
1
Information
M14.4.24 Entity Reference type Identifier model
System Identifier 04ad1126‑6673‑4a73‑a0c3‑34871bb49905
title Entity Reference type Identifier
Description Restricts the values of a metadata element that

refers to another entity to entities of a particular
type, or types
Min occurs 0 (not present if the metadata element definition is

not an entity reference or there are no restrictions
on the types of entities that the element can refer
to)

has been applied)
Refers to type Entity Type (E14.2.7)
Datatype UUID
Usage notes Used when the Is Entity Reference Flag (M14.4.45)

is set
M14.4.25 Event Comment
System Identifier 1f82121e‑dcb9‑475b‑814e‑6719031ca30b
title Event Comment
Description Comment giving additional detailed information

about an event, or the reason for an event
•
Entity type Event (E14.2.8) MoReq2010
Min occurs 0
Max occurs 1 Modular Requirements

for Records Systems
Modifiable? No
Datatype Text
Volume 1
Core Services
& Plug-in Modules
Version 1.1
279
1
Information
model M14.4.26 Event Function Identifier
System Identifier ea21de8f‑1a0c‑4bc5‑939a‑dc06dcff44c1
title Event Function Identifier
Description The function that was performed to generate the event
Min occurs 1
Max occurs 1
Modifiable? No
Datatype UUID
M14.4.27 Event occurred timestamp
System Identifier b51c08ed‑d332‑4bb5‑974c‑7cee3cb5c753
title Event occurred timestamp
Description System set date and time for when a function was
performed
Min occurs 1
Max occurs 1
Modifiable? No
Datatype Timestamp
•
MoReq2010
M14.4.28 Export Commencing timestamp

for Records Systems System Identifier a252f442‑6ab5‑4325‑94e5‑00adaf908614
title Export Commencing timestamp
Description System set date and time for when an export

commenced
Min occurs 0
Max occurs 1
Volume 1 Modifiable? No
Core Services Entity reference? No
& Plug-in Modules Datatype Timestamp
Usage notes See R11.4.6

Version 1.1
280
1
Information
M14.4.29 Export Completed timestamp model
System Identifier 4220eaa9‑fc78‑4e33‑ae94‑0394824d4616
title Export Completed timestamp
Description System set date and time for when an export

completed
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Timestamp
M14.4.30 Export Identifier
System Identifier 885f5945‑e724‑466b‑a84f‑6ae3c603768b

title Export Identifier
Description The system generated identifier for an individual
export operation, used in the event history of all
entities that are successfully exported
Min occurs 0
Max occurs 1
Modifiable? No
Datatype UUID •
MoReq2010
M14.4.31 Exported In Full Flag
for Records Systems
System Identifier 633bd60f‑50df‑4709‑ab22‑32cf63790598
title Exported In Full Flag
Description Flag indicating whether an entity was exported in

full or as a placeholder
Min occurs 0
Volume 1
Max occurs 1
Modifiable? No Core Services

& Plug-in Modules
Datatype Boolean
Version 1.1
281
1
Information
model M14.4.32 First Used timestamp
System Identifier a937d097‑856d‑472f‑836b‑a2fae1811550
title First Used timestamp
Description System generated date and time indicating when

an entity was first used; generally taken as the last
time it can be modified or deleted without formally
destroying it

• Class (E14.2.2)
(E14.2.4)
• Group (E14.2.10)
• Role (E14.2.13)
• User (E14.2.16)
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Timestamp
M14.4.33 Function Definition Identifier
System Identifier 55fcb00b‑1d7a‑4b6b‑899c‑3a9a9762dbf8
title Function Definition Identifier

•
MoReq2010 Description A function that is included in a role to allow users
and groups assigned that role to perform the
function
for Records Systems Entity type Role (E14.2.13)
Min occurs 0
Modifiable? Yes
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
282
1
Information
M14.4.34 Generate Event Flag model
System Identifier 50a7cd32‑ed4f‑47b6‑bcbb‑bc1112e06eb9
title Generate Event Flag
Description Flag indicating whether an event should be generated

by the system when a function is performed
Entity type Function Definition (E14.2.9)
Min occurs 1
Max occurs 1
Modifiable? Yes
Datatype Boolean
M14.4.35 Granted Role Identifier
System Identifier 1f50d91a‑dac6‑42ec‑bb6e‑d5dd5c0f4770
title Granted Role Identifier
Description Indicator in an event of a role that was awarded to

the participating user or group
Min occurs 0
Modifiable? No
Refers to type Role (E14.2.13)
Datatype UUID •
MoReq2010
M14.4.36 Group Identifier Modular Requirements

for Records Systems
System Identifier 1d32086d‑3855‑4815‑a294‑f7d1977ce03a
title Group Identifier
Description Group of which the user is a member
Entity type User (E14.2.16)
Min occurs 0
Modifiable? Yes Volume 1
Entity reference? Yes Core Services

Refers to type Group (E14.2.10) & Plug-in Modules
Datatype UUID
Version 1.1
283
1
Information
model M14.4.37 Held Aggregation Identifier
System Identifier 93856ba9‑a0dd‑4cfa‑b8a9‑edf031774076
title Held Aggregation Identifier
Description Aggregation which is associated with a

disposal hold and, as a result, no records in the
aggregation, or its descendant aggregations, may
be destroyed
Entity type Disposal Hold (E14.2.5)
Min occurs 0
Modifiable? Yes
Refers to type Aggregation (E14.2.1)
Datatype UUID
M14.4.38 Held Class Identifier
System Identifier 29abe491‑0c58‑4816‑97c2‑8f60be62d9fa
title Held Class Identifier
Description Class which is associated with a disposal hold and

as a result no records which have been classified
with the class, may be destroyed
Min occurs 0
• Modifiable? Yes
MoReq2010
Refers to type Class (E14.2.2)

Volume 1
Core Services
& Plug-in Modules
Version 1.1
284
1
Information
M14.4.39 Held Record Identifier model
System Identifier 374957cb‑23ce‑4987‑81e9‑5ccc00cfe9e3
title Held Record Identifier
Description Record which has been associated with a disposal

hold and, as a result, may not be destroyed
Min occurs 0
Modifiable? Yes
Refers to type Record (E14.2.12)
Datatype UUID
M14.4.40 Historical Date/time
System Identifier 8274fbf7‑3145‑4c23‑a748‑6c4682d6b7ed
title Historical Date/time
Description Date and time for which a report was run to obtain
historical information about a user, group or role
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Date/Time •
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
285
1
Information
model M14.4.41 Implements Module Identifier
System Identifier 92bddc26‑aae5‑493d‑9278‑94fbb00a2e44
title Implements Module Identifier
Description Compliance indicator providing assurance that

the system implements the identified module of
MoReq2010®
Entity type Service (E14.2.14)
Min occurs 0
Modifiable? No
Datatype UUID
Usage notes Each major version of a MoReq2010® module has a

different unique identifier
M14.4.42 Implements Service Identifier
System Identifier 3960b7a5‑624e‑41e1‑9976‑248895b9352e
title Implements Service Identifier
Description Compliance indicator providing assurance that

the system implements the core service of
MoReq2010® that is identified
Min occurs 1
• Modifiable? No
MoReq2010
Datatype UUID
for Records Systems Usage notes Each major version of a MoReq2010® core service
has a different unique identifier
Volume 1
Core Services
& Plug-in Modules
Version 1.1
286
1
Information
M14.4.43 Include Inherited Roles Flag model
System Identifier 4ad73ab1‑4df8‑40b7‑b863‑f8d63a584037
title Include Inherited Roles Flag
Description Flag indicating whether administrative and/

or non‑administrative roles are inherited by an
access control list
Entity type Access Control List (D14.3.2)
Min occurs 1
Max occurs 1
Modifiable? Yes
Datatype Boolean
Usage notes • When the flag is set, both administrative and

non-administrative roles will be inherited from
the parent’s access control list
• When the flag is cleared, only administrative
roles will be inherited (administrative roles may
not be overridden)
• The specific rules of inheritance are given in
the rationale to R4.5.11
M14.4.44 Is Administrative Role Flag
System Identifier d2e3b3da‑a109‑4ec0‑ab26‑5e6f53ad3673
title Is Administrative Role Flag
Description Flag indicating that a role is an administrative role

and will, as a result, always be inherited
Entity type Role (E14.2.13) •

MoReq2010
Min occurs 1
Max occurs 1 Modular Requirements

for Records Systems
Modifiable? Yes (for roles prior to their first use)
No (once a role has been granted)
Datatype Boolean
Usage notes See also Include Inherited Roles Flag (M14.4.43)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
287
1
Information
model M14.4.45 Is Entity Reference Flag
System Identifier b52c2bbf‑f27b‑41c9‑8885‑3d906b4bd275
title Is Entity Reference Flag
Description Flag indicating whether a metadata element

contains a reference to an entity or a different
datatype value
Min occurs 1
Max occurs 1

has been applied)
Datatype Boolean
Usage notes See also Entity Reference Type Identifier (M14.4.24)

and Datatype (M14.4.10)
M14.4.46 Is Modifiable Flag
System Identifier 7ff6a66e‑b137‑417c‑aab0‑aa327a0b119b
title Is Modifiable Flag
Description Flag indicating whether a metadata element is

modifiable by users
Min occurs 1
Max occurs 1
•
MoReq2010 Modifiable? Yes (for contextual metadata prior to their first use)
has been applied)
for Records Systems Entity reference? No
Datatype Boolean
Volume 1
Core Services
& Plug-in Modules
Version 1.1
288
1
Information
M14.4.47 Is textual Flag model
System Identifier 7e5ec95d‑423c‑4ac9‑ac94‑a835d3713e91
title Is textual Flag
Description Flag indicating whether a text‑based metadata

element should be accompanied by a language
identifier
Min occurs 0
Max occurs 1

has been applied)
Datatype Boolean
Usage notes Should be set for metadata elements where

descriptive text is stored in the user’s own language
M14.4.48 last Addition timestamp
System Identifier 71a6cf2d‑c039‑4b27‑bd31‑dcba471081ac
title last Addition timestamp
Description System set date and time indicating when the most
recent record or child aggregation was added to
the parent aggregation
Min occurs 0
Max occurs 1 •
MoReq2010
Modifiable? No
Entity reference? No Modular Requirements

Datatype Timestamp
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
289
1
Information
model M14.4.49 last Review Comment
System Identifier 7036ec2e‑644a‑4309‑9690‑178690a6bc4f
title last Review Comment
Description Comment made by the user that last reviewed the

record explaining the disposal decision made by
that review
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Text
Usage notes Used with Last Reviewed Timestamp (M14.4.50)
M14.4.50 last Reviewed timestamp
System Identifier dbbeb8a5‑b019‑46e1‑983e‑5f728f1dcc3a
title last Reviewed timestamp
Description System set date and time of when the last review
was completed
Min occurs 0
Max occurs 1
Modifiable? No
•
MoReq2010
Datatype Timestamp
Usage notes Used with Last Review Comment (M14.4.49)
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
290
1
Information
M14.4.51 Mandate model
System Identifier a6986d60‑1257‑4046‑bafe‑fef680d5dc6c
title Mandate
Description Textual reference to a legal or other instrument

that provides the authority for a disposal schedule
or a disposal hold
Entity type • Disposal Hold (E14.2.5)

Min occurs 0
Max occurs 1
Modifiable? Yes
Datatype Text
M14.4.52 Max levels of Aggregation
System Identifier d0da657f‑9345‑4965‑b2a8‑17a0c300a896
title Max levels of Aggregation
Description The maximum number of levels of aggregation

allowed below a root aggregation
Min occurs 0
Max occurs 1
Modifiable? Yes
•
Entity reference? No MoReq2010
Datatype Positive Integer

for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
291
1
Information
model M14.4.53 Max occurs
System Identifier 4a69e008‑50df‑4506‑b9a7‑d6279b0c21d5
title Max occurs
Description The maximum number of values that can be

assigned to a metadata element for a single entity
Min occurs 0
Max occurs 1

has been applied)
Usage notes • Used with Min Occurs (M14.4.56)

• Where this value is not set, it indicates that the
metadata element is a list with an unlimited
number of values
M14.4.54 MCRS Certification Identifier
System Identifier bf8efec0‑e182‑47ec‑bdfa‑a83a24c602c8
title MCRS Certification Identifier
Description Compliance indicator giving the DLM Forum

Foundation issued identifier for a certificate of
compliance against MoReq2010®

• Min occurs 0
MoReq2010
Modular Requirements Modifiable? No

for Records Systems Entity reference? No
Datatype UUID
Usage notes Only the DLM Forum Foundation may issue a

certificate of compliance against MoReq2010®
Volume 1
Core Services
& Plug-in Modules
Version 1.1
292
1
Information
M14.4.55 Metadata Element Definition Identifier model
System Identifier 8afb23cd‑a741‑4be0‑97fd‑f76aef411503
title Metadata Element Definition Identifier
Description Reference in an event to the metadata element of

an entity that was changed when a function was
performed
Entity type Metadata Change Entry (D14.3.3)
Min occurs 1
Max occurs 1
Modifiable? No
Datatype UUID
Usage notes Used in a metadata change entry in combination with

New Value (M14.4.57) and Previous Value (M14.4.85)
M14.4.56 Min occurs
System Identifier 6e182700‑4679‑4ebf‑938a‑ef110828cba6
title Min occurs
Description Minimum number of values that can be assigned

to a metadata element for a single entity
Entity type Metadata Element Definition (E14.2.11) •

MoReq2010
Min occurs 1
Max occurs 1
Modifiable? Yes (for contextual metadata prior to their first use) for Records Systems
has been applied)
Usage notes • Used with Max Occurs (M14.4.53)

• Where this value is set to zero, it indicates an
optional metadata element; where it is set to
one, a value is mandatory Volume 1
Core Services
& Plug-in Modules
Version 1.1
293
1
Information
model M14.4.57 New Value
System Identifier d3d4f2ae‑43f0‑4567‑99ae‑ddd58e6cf2dd
title New Value
Description Value of a metadata element after a function was

performed
Min occurs 0
Max occurs 1
Modifiable? No

element definition

element definition

element definition

element definition
Usage notes • Used in a metadata change entry with Previous

Value (M14.4.85) in conjunction with Metadata
Element Definition Identifier (M14.4.55)
• Where New Value does not occur, it indicates
that the value of the metadata element was
deleted
M14.4.58 overdue Disposal Action Code
System Identifier 60027dfb‑2e3d‑4456‑b341‑54737e83243c

• title overdue Disposal Action Code
MoReq2010
Description Disposal action that was overdue on the record at
the time an alert was raised
for Records Systems
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Code
Valid values Same as for Disposal Action Code (M14.4.18)

Volume 1
Usage notes Used with Overdue Disposal Action Due Date
Core Services (M14.4.59) and Overdue Disposal Confirmation Due
Date (M14.4.60)
& Plug-in Modules
Version 1.1
294
1
Information
M14.4.59 overdue Disposal Action Due Date model
System Identifier 75491c12‑0c90‑4f99‑85ad‑b583df082b45
title overdue Disposal Action Due Date
Description Due date that was set for the disposal action that
was overdue on a record at the time an alert was
raised
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Date
Usage notes Used with Overdue Disposal Action Code (M14.4.58)

and Overdue Disposal Confirmation Due Date
(M14.4.60)
M14.4.60 overdue Disposal Confirmation Due Date
System Identifier 1ac9514a‑7e0e‑4fd8‑a543‑4956c22f4089
title overdue Disposal Confirmation Due Date
Description Due date that was set for confirmation of a

disposal action that was overdue, causing an alert
to be raised
Min occurs 0
Max occurs 1
•
Modifiable? No MoReq2010
Datatype Date Modular Requirements

for Records Systems
Usage notes Used with Overdue Disposal Action Code (M14.4.58)
and Overdue Disposal Action Due Date (M14.4.59)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
295
1
Information
model M14.4.61 originated Date/time
System Identifier 50864023‑dc92‑4b1e‑8e8a‑66c284d40942
title originated Date/time
Description Date and time of origin of a record or other entity

which may vary from the creation date of the entity
in the system

• Class (E14.2.2)
(E14.2.4)
• Group (E14.2.10)
• Record (E14.2.12)
• Role (E14.2.13)
• User (E14.2.16)
Min occurs 1
Max occurs 1
Modifiable? Yes
Datatype Date/Time
M14.4.62 owner Information
System Identifier ae99f4f8‑3edf‑4874‑aea2‑ea50fa7a73f9

•
MoReq2010 title owner Information
Description Information provided by the owner of a system

Modular Requirements that may be used to identify the originating system
for Records Systems when entities are later exported to another system
Min occurs 0
Max occurs 1
Modifiable? Yes
Datatype Text
Volume 1
Core Services
& Plug-in Modules
Version 1.1
296
1
Information
M14.4.63 Parent Aggregation Identifier model
System Identifier a74597a5‑190a‑4874‑a350‑083ac030aa55
title Parent Aggregation Identifier
Description Parent aggregation for a child aggregation or

record

• Record (E14.2.12)
Min occurs 0 (for root aggregations)

Max occurs 0 (for root aggregations)

Modifiable? Yes (by moving the child aggregation or record)
Refers to type Aggregation (E14.2.1)
Datatype UUID
M14.4.64 Participating Aggregation Identifier
System Identifier daafbb4c‑3183‑40bd‑9eff‑759e88c725fc
title Participating Aggregation Identifier
Description Aggregation that is a participating entity in the

function that was performed that generated an
event
Min occurs 0
Max occurs Unlimited •

MoReq2010
Modifiable? No

Refers to type Aggregation (E14.2.1) for Records Systems
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
297
1
Information
model M14.4.65 Participating Class Identifier
System Identifier f046bdfa‑5ef5‑4217‑9c4f‑e24d0f15ea9a
title Participating Class Identifier
Description Class that is a participating entity in the function

that was performed that generated an event
Min occurs 0
Max occurs Unlimited (depending on the function that was

performed)
Modifiable? No
Datatype UUID
M14.4.66 Participating Component Identifier
System Identifier 0686271b‑b41f‑40db‑be27‑9e6626b9ee54
title Participating Component Identifier
Description Component that is a participating entity in the

event
Min occurs 0

performed)
• Modifiable? No
MoReq2010
Refers to type Component (E14.2.3)

Volume 1
Core Services
& Plug-in Modules
Version 1.1
298
1
Information
M14.4.67 Participating Disposal Hold Identifier model
System Identifier f9553093‑24cb‑4bd4‑920e‑c1341572b6f5
title Participating Disposal Hold Identifier
Description Disposal hold that is a participating entity in the

event
Min occurs 0
Modifiable? No
Refers to type Disposal Hold (E14.2.5)
Datatype UUID
M14.4.68 Participating Disposal Schedule Identifier
System Identifier dfaf8f03‑b7eb‑49c0‑b889‑2c9b61ce1e3c
title Participating Disposal Schedule Identifier
Description Disposal schedule that is a participating entity in

the function that was performed that generated an
event
Min occurs 0

performed)
Modifiable? No •
MoReq2010

Datatype UUID for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
299
1
Information
model M14.4.69 Participating Duplicate Identifier
System Identifier 51afb74e‑8729‑46be‑aac2‑761c56e1b7d1
title Participating Duplicate Identifier
Description Duplicate entity that was created by duplicating a

record or a component
Entity type • Event (E14.2.8)
Min occurs 0
Max occurs Unlimited (normally only one duplicate will be

made at a time but this allows for two or more
duplicates to be created simultaneously)
Modifiable? No
Refers to type • Component (E14.2.3)

• Record (E14.2.12)
Datatype UUID
M14.4.70 Participating Entity type Identifier
System Identifier 7acf7c1d‑d537‑4548‑a24d‑ce92cf7cd68b
title Participating Entity type Identifier
Description Entity type that is a participating entity in the

event
Min occurs 0

•
MoReq2010 performed)
Modifiable? No
Modular Requirements Entity reference? Yes
for Records Systems
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
300
1
Information
M14.4.71 Participating Event Identifier model
System Identifier b41e6d9c‑c19d‑41c1‑8969‑3090306b987f
title Participating Event Identifier
Description Event that is a participating entity in the function

Min occurs 0

performed)
Modifiable? No
Refers to type Event (E14.2.8)
Datatype UUID
M14.4.72 Participating Function Definition Identifier
System Identifier 56ee4c6d‑ad65‑468f‑9de2‑b9d5cf8b0557
title Participating Function Definition Identifier
Description Function definition that is a participating entity in

the function that was performed that generated an
event
Min occurs 0

performed)
Modifiable? No •
MoReq2010

Volume 1
Core Services
& Plug-in Modules
Version 1.1
301
1
Information
model M14.4.73 Participating Group Identifier
System Identifier a6bf28b7‑334b‑465f‑837b‑34d8d09c7f2d
title Participating Group Identifier
Description Group that is a participating entity in the function

Min occurs 0

performed)
Modifiable? No
Refers to type Group (E14.2.10)
Datatype UUID
M14.4.74 Participating Metadata Element Definition Identifier
System Identifier bbbef444‑bf3c‑49ba‑8560‑0b5dfaeb8a88
title Participating Metadata Element Definition

Identifier
Description Metadata element definition that is a participating

entity in the function that was performed that
generated an event
Min occurs 0

performed)
•
MoReq2010 Modifiable? No

Modular Requirements Refers to type Metadata Element Definition (E14.2.11)
for Records Systems
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
302
1
Information
M14.4.75 Participating New Parent Identifier model
System Identifier 236e52dd‑b117‑4b6a‑b60b‑286d5dc5acd0
title Participating New Parent Identifier
Description New parent for a child entity that has been created
or moved into it
Min occurs 0
Max occurs 1
Modifiable? No
Refers to type Aggregation (E14.2.1) or other (as specified by the

function definition)
Datatype UUID
Usage notes In the core services, this metadata element is used

exclusively for aggregations; however, it may be
reused by other modules for functions related to
different hierarchical structures
M14.4.76 Participating Previous Parent Identifier
System Identifier 736b0697‑2078‑4e50‑b740‑a52d4f16f18d
title Participating Previous Parent Identifier
Description Parent entity from which a child entity was moved
Min occurs 0
Max occurs 1 •
MoReq2010
Modifiable? No

Refers to type Aggregation (E14.2.1) or other (as specified by the for Records Systems
function definition)
Datatype UUID
Usage notes In the core services, this metadata element is used

exclusively for aggregations; however, it may be
reused by other modules for functions related to
different hierarchical structures
Volume 1
Core Services
& Plug-in Modules
Version 1.1
303
1
Information
model M14.4.77 Participating Record Identifier
System Identifier 74f1568c‑bde8‑45aa‑895a‑ac600c2de1c7
title Participating Record Identifier
Description Record that is a participating entity in the function

Min occurs 0

performed)
Modifiable? No
Refers to type Record (E14.2.)
Datatype UUID
M14.4.78 Participating Role Identifier
System Identifier a55947ec‑b23e‑413a‑a840‑21566aae0b4b
title Participating Role Identifier
Description Role that is a participating entity in the function

Min occurs 0

performed)
Modifiable? No
•
MoReq2010 Entity reference? Yes

Modular Requirements Datatype UUID
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
304
1
Information
M14.4.79 Participating Service Identifier model
System Identifier a5d104c2‑e343‑4c2b‑82a3‑8a30046e0e07
title Participating Service Identifier
Description Service that is a participating entity in the function

Min occurs 0

performed)
Modifiable? No
Refers to type Service (E14.2.14)
Datatype UUID
M14.4.80 Participating template Identifier
System Identifier 01afa124‑8a2b‑422b‑888a‑db7829564b4f
title Participating template Identifier
Description Template that is a participating entity in the

event
Min occurs 0

performed)
Modifiable? No •
MoReq2010
Refers to type Template (E14.2.15)

Volume 1
Core Services
& Plug-in Modules
Version 1.1
305
1
Information
model M14.4.81 Participating User Identifier
System Identifier 35d1c4e2‑4821‑4e23‑add8‑fa14b9e38ca5
title Participating User Identifier
Description User that is a participating entity in the function

Min occurs 0

performed)
Modifiable? No
Refers to type User (E14.2.16)
Datatype UUID
M14.4.82 Participating User or Group Identifier
System Identifier 2c159083‑3b5b‑4119‑8bbd‑ae39b2577ca2
title Participating User or Group Identifier
Description User or group that is a participating entity in an

event generated by granting or rescinding roles
Min occurs 0
Max occurs 1
Modifiable? No

•
MoReq2010
Refers to type • Group (E14.2.10)
• User (E14.2.16)
Modular Requirements Datatype UUID
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
306
1
Information
M14.4.83 Performed By User Identifier model
System Identifier ee568750‑32b5‑4441‑b67b‑d01ae9df5820
title Performed By User Identifier
Description User that performed the function that generated

the event
Min occurs 0 (if no user is specified then the function was

performed by the system)
Max occurs 1
Modifiable? No
Refers to type User (E14.2.16)
Datatype UUID
M14.4.84 Presentation order
System Identifier 92c9459d‑aa29‑4784‑8646‑6fc663d08c87
title Presentation order
Description Value used for determining the order in which

items, such as metadata elements, should be
logically presented, particularly by systems that
are not the originating system
Min occurs 1
Max occurs 1
Modifiable? Yes •
MoReq2010

Usage notes • The values given for Presentation Order do not for Records Systems
have to be contiguous, but they must be unique
so that no two entities have the same value
• An entity with a lower Presentation Order value
will be presented before an entity with a higher
Presentation Order
Volume 1
Core Services
& Plug-in Modules
Version 1.1
307
1
Information
model M14.4.85 Previous Value
System Identifier ce3ec75a‑7193‑4fd2‑9811‑1c70419c7185
title Previous Value
Description Value of a metadata element prior to a function

being performed
Min occurs 0
Max occurs 1
Modifiable? No

element definition

element definition

element definition

element definition
Usage notes • Used in a metadata change entry with New

Value (M14.4.57) in conjunction with Metadata
Element Definition Identifier (M14.4.55)
• Where Previous Value does not occur, it
indicates that the metadata element value was
added to the entity
M14.4.86 Record Identifier
System Identifier 87daefe3‑b429‑4b7d‑96ea‑5dc9eabd8f56

• title Record Identifier
MoReq2010
Description Record that the component belongs to
Modular Requirements Entity type Component (E14.2.3)

for Records Systems Min occurs 1
Max occurs 1
Modifiable? No
Refers to type Record (E14.2.12)
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
308
1
Information
M14.4.87 Rescinded Role Identifier model
System Identifier 6c20a22d‑0ca8‑4dbb‑a932‑c950a1fce1e5
title Rescinded Role Identifier
Description Indicator in an event of a role that was rescinded

from the participating user or group
Min occurs 0
Modifiable? No
Datatype UUID
M14.4.88 Retain on Destruction Flag
System Identifier 222811d2‑8c74‑4f47‑ae3f‑c68698f55e2c
title Retain on Destruction Flag
Description Flag that indicates whether an event generated by

performing a particular function, or a metadata
element belonging to a particular metadata
element definition, should be deleted when the
entity it belongs to is destroyed
Entity type • Function Definition (E14.2.9)

Min occurs 1
Max occurs 1
•
Modifiable? Yes MoReq2010
Datatype Boolean
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
309
1
Information
model M14.4.89 Retention Period Duration Number
System Identifier 1cf79293‑5818‑4141‑876e‑761448ae465b
title Retention Period Duration Number
Description Number of days, weeks, months or years specified

for retaining a record after the retention period is
triggered
Min occurs 0
Max occurs 1

Usage notes Used with Retention Period Interval Code (M14.4.90)
M14.4.90 Retention Period Interval Code
System Identifier 47aa0949‑37a9‑4f4f‑ab0e‑f33b0dd7d5fb
title Retention Period Interval Code
Description Unit of measurement of time as either days,

weeks, months or years
Min occurs 0
Max occurs 1

• No (once disposal schedule has been used)
MoReq2010
Modular Requirements Datatype Code

for Records Systems Valid values 0 = NO RETENTION PERIOD
1 = DAYS
2 = WEEKS
3 = MONTHS
4 = YEARS
Usage notes Used with Retention Period Duration Number

(M14.4.89)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
310
1
Information
M14.4.91 Retention Period offset Code model
System Identifier 3882b1a6‑48d7‑45a2‑a539‑5871856a1b95
title Retention Period offset Code
Description Offset for the disposal of records if they fall due for
disposal in a particular period
Min occurs 0

Datatype Code
Valid values 0 = NO OFFSET

1 = START OF NEXT MONTH
2 = START OF NEXT QUARTER
3 = START OF SPECIFIED MONTH
Usage notes START OF SPECIFIED MONTH is used with Retention

Period Offset Month Code (M14.4.92)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
311
1
Information
model M14.4.92 Retention Period offset Month Code
System Identifier 557d941f‑4be7‑4dad‑8113‑39757547530a
title Retention Period offset Month Code
Description Month to offset the disposal of records to if they

fall due for disposal in a particular period
Min occurs 0
Max occurs 1

Datatype Code
Valid values 1 = JANUARY

2 = FEBRUARY
3 = MARCH
4 = APRIL
5 = MAY
6 = JUNE
7 = JULY
8 = AUGUST
9 = SEPTEMBER
10 = OCTOBER
11 = NOVEMBER
12 = DECEMBER
Usage notes Used with Retention Period Offset Code (M14.4.91)

when START OF SPECIFIED MONTH is specified
•
MoReq2010
M14.4.93 Retention Start Date
Modular Requirements System Identifier 199494ea‑0ca4‑47ef‑883a‑4bcc5ccdcc02

for Records Systems title Retention Start Date
Description System generated date calculated from the

record’s disposal schedule indicating the start of
its retention period
Min occurs 0 (not used for records with a Disposal Action Code
(M14.4.18) of RETAIN PERMANENTLY)
Max occurs 1
Volume 1
Modifiable? No (automatically updated)
Core Services
& Plug-in Modules
Datatype Date
Version 1.1
312
1
Information
M14.4.94 Retention trigger Code model
System Identifier 30891ecb‑5b36‑453d‑baf0‑9aaa19eba4a6
title Retention trigger Code
Description Specific conditions required for triggering the start

of the retention period for a record
Min occurs 0
Max occurs 1

Datatype Code
Valid values 0 = FROM NOW

1 = FROM DATE OF LAST REVIEW
2 = FROM RECORD ORIGINATED DATE
3 = FROM AGGREGATION ORIGINATED DATE
4 = FROM DATE ADDED TO AGGREGATION
5 = FROM DATE OF LAST ADDITION TO
AGGREGATION
6 = FROM AGGREGATION CLOSED DATE
7 = FROM RECORD METADATA DATE
8 = FROM AGGREGATION METADATA DATE
Usage notes FROM RECORD METADATA DATE and FROM

AGGREGATION METADATA DATE are used in
combination with Retention Trigger Element Identifier
(M14.4.95)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
313
1
Information
model M14.4.95 Retention trigger Element Identifier
System Identifier 72fc68f0‑5437‑4d8e‑a719‑b4c4ecd1b649
title Retention trigger Element Identifier
Description Metadata element associated with a record, or

its parent aggregation, which contains the trigger
date for a record’s retention period
Min occurs 0

Datatype UUID
Usage notes • Used with Retention Trigger Code (M14.4.94)

when FROM RECORD METADATA DATE and
FROM AGGREGATION METADATA DATE are
specified
• Must be a reference to a metadata element
definition of date, date/time or timestamp
M14.4.96 Role Identifier
System Identifier 0394b604‑5865‑42e2‑ab23‑2e983ecdf454
title Role Identifier
Description Role included in an access control entry so that it

is granted to a user or a group
•
MoReq2010 Entity type Access Control Entry (D14.3.1)
Min occurs 1
Max occurs Unlimited (more than one role may be granted to
for Records Systems the user or group in a single access control entry)
Modifiable? Yes
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
314
1
Information
M14.4.97 Scope Notes model
System Identifier c5c12c32‑d263‑44a3‑91ae‑26f80cb75a3c
title Scope Notes
Description Guidance to authorised users indicating how

best to apply a particular entity and stating any
organisational policies or constraints on its use

• Class (E14.2.2)
• Role (E14.2.13)
Min occurs 0
Max occurs 1
Modifiable? Yes
Datatype Text
M14.4.98 Search query
System Identifier e7f82f8c‑80de‑4cb5‑a28e‑6761abca27b0
title Search query
Description Description in an event of the search query used to

search for, or report on, entities in the system

•
Min occurs 0 MoReq2010
Max occurs 1
Modifiable? No
for Records Systems
Datatype Text
Usage notes There is no specified style for how the Search Query
should be described; it may be using a structured
expression language or using natural language (see
R10.4.22)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
315
1
Information
model M14.4.99 Supplier Information
System Identifier 8276d84b‑a3fe‑4b49‑82a4‑a8a58de14a7e
title Supplier Information
Description Information provided by the supplier of a system

that may be used to identify the type of the
originating system, including its particular hardware
and software versions and configuration, especially
when entities are exported to another system
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Text
M14.4.100 System Identifier
System Identifier 01806231‑2c8c‑4482‑9bb1‑8e47e747784f
title System Identifier
Description Universally unique identifier for an entity that is

generated automatically by the system and stays
with the entity forever

• Class (E14.2.2)
•
MoReq2010 • Disposal Schedule (E14.2.6)
• Event (E14.2.8)
• Function Definition (E14.2.9)
for Records Systems
• Group (E14.2.10)
• Record (E14.2.12)
• Role (E14.2.13)
• User (E14.2.16)
Min occurs 1
Volume 1
Max occurs 1
Core Services Modifiable? No
& Plug-in Modules Entity reference? No
Datatype UUID
Version 1.1
316
1
Information
M14.4.101 template Class Identifier model
System Identifier ee03c826‑39ee‑4cdf‑b2c7‑6cc0c2782967
title template Class Identifier
Description Class associated with the template such that when

new entities, such as aggregations or records, are
created with that classification, the template will
be automatically applied to them by the system,
giving them additional contextual metadata
elements
Entity type Template (E14.2.15)
Min occurs 0
Modifiable? Yes
Datatype UUID
Usage notes Subject to the entity being of the appropriate entity

type (see Template Entity Type Identifier (M14.4.102))
M14.4.102 template Entity type Identifier
System Identifier caaaf2e6‑2ed4‑4a53‑adba‑9363385127ac
title template Entity type Identifier
Description Specifies the types of entities to which the

template may be applied
Entity type • Template (E14.2.15)
Min occurs 1 •
MoReq2010
Max occurs Unlimited (the template may apply to more than
one entity type)
Modifiable? Yes
for Records Systems
Datatype UUID
Volume 1
Core Services
& Plug-in Modules
Version 1.1
317
1
Information
model M14.4.103 template Service Identifier
System Identifier 2dd54e70‑5b60‑4d5a‑89be‑5f967735d515
title template Service Identifier
Description Service associated with the template such that

when new entities are created in that service, the
template will be automatically applied to them
by the system, giving them additional contextual
metadata elements
Min occurs 0
Modifiable? Yes
Refers to type Service (E14.2.14)
Datatype UUID
Usage notes Subject to the entity being of the appropriate entity

type (see Template Entity Type Identifier (M14.4.102))
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
318
1
Information
M14.4.104 title model
System Identifier 077fc367‑48ba‑44a8‑8afb‑012d05ed1a16
title title
Description The identifying name or title of the entity

• Class (E14.2.2)
• Function Definition (E14.2.9)
• Group (E14.2.10)
• Record (E14.2.12)
• Role (E14.2.13)
• User (E14.2.16)
Min occurs 1
Max occurs 1
Modifiable? Yes
Datatype Text
Usage notes MoReq2010® does not require that titles be unique

for, for example, two records within the same
aggregation — however, this is generally good •
practice MoReq2010
M14.4.105 total Entities Modular Requirements

for Records Systems
System Identifier 2131929b‑7c06‑471d‑a96c‑19b3560069d8
title total Entities
Description Total number of entities returned by a search or

included in a report
Min occurs 0
Max occurs 1 Volume 1
Modifiable? No Core Services

Entity reference? No & Plug-in Modules
Version 1.1
319
1
Information
model M14.4.106 transferred timestamp
System Identifier 09c440b3‑b040‑465f‑a79f‑9dae3243cce6
title transferred timestamp
Description System set date and time indicating when the

transfer of the record was confirmed
Min occurs 0
Max occurs 1
Modifiable? No
Datatype Timestamp
M14.4.107 User or Group Identifier
System Identifier 2b1820f7‑97ef‑4010‑8de8‑f0745e0855c0
title User or Group Identifier
Description Identifier for a user or group granted one or more

roles in an access control entry
Entity type Access Control Entry (D14.3.1)
Min occurs 1
Max occurs 1
Modifiable? Yes (by modifying the access control list)
Refers to type • Group (E14.2.10)

• • User (E14.2.16)
MoReq2010
Datatype UUID
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
320
1
Information
14.5 FUNCtIoN DEFINItIoNS model
F14.5.1 Aggregation — Add Aggregation
System Identifier f6c7d6a4‑c69e‑4d33‑9d4a‑4137274b68da
title Aggregation — Add Aggregation
Description Add a child aggregation to the open aggregation by

moving it from the root or its previous parent
Entity metadata The following metadata element belonging to the

aggregation will be modified:
The following metadata element belonging to the
aggregation may also be modified (if it has not been
set previously):
The following metadata elements belonging to the
participating child aggregation will be modified:
participating child aggregation will be removed (if it
exists):
From functional R6.5.8, R6.5.14

requirement(s)
Purpose • Access control

• Event generation
Additional event • Participating Previous Parent Identifier

metadata (see (M14.4.76)
R2.4.16) • Participating New Parent Identifier
(M14.4.75) •
• Participating Aggregation Identifier MoReq2010
(M14.4.64)
Usage notes • This function is always performed in conjunc- for Records Systems
tion with F14.5.22 Aggregation — Remove
Aggregation
• Before a user can move an aggregation, the
user must have the authority to perform this
function on its new parent, as well as the
authority to remove the aggregation from its
previous parent or root
• To move an aggregation so that it becomes
a root aggregation, the user must have the
authority to perform this function for the record
service as a whole Volume 1
This function only applies to adding child
•
aggregations by moving them from elsewhere:
Core Services
it does not apply to adding child aggregations & Plug-in Modules
by creating them in the aggregation (see
F14.5.5 Aggregation — Create)
Version 1.1
321
1
Information
model F14.5.2 Aggregation — Add Contextual Metadata
System Identifier 746b7ffc‑d9a4‑43d9‑9dfa‑01f6d1e8f671
title Aggregation — Add Contextual Metadata
Description Add one or more contextual metadata element

definitions to the aggregation
Entity metadata • Additional contextual metadata elements, as

modified specified
Applying contextual metadata elements from a
template may also modify the following template
metadata element (if it has not already been set):
From functional R7.5.19

requirement(s)

Additional event • Participating Aggregation Identifier

R2.4.16) • Event Comment (M14.4.25)
Usage notes If contextual metadata elements are added from a

template, the Applied Template Identifier must be
included in the event metadata (the template is not
considered a participating entity)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
322
1
Information
F14.5.3 Aggregation — Add Record model
System Identifier 0ef1d20b‑a65f‑4b0a‑b2a0‑e7b3a9a665f4
title Aggregation — Add Record
Description Add a record to the open aggregation by moving it

from its previous aggregation

aggregation will be modified:
aggregation may also be modified (if it has not been
set previously):
The following metadata elements belonging to the
record will be modified:
record may be modified depending on whether the
authorised user chooses to retain or to replace the
record’s previous classification, under R6.5.13:

requirement(s)


(M14.4.75) •
• Participating Record Identifier (M14.4.77) MoReq2010

• Metadata Change Entry (D14.3.3) Modular Requirements
Usage notes • This function is always performed in conjunc-
for Records Systems
tion with F14.5.22 Aggregation — Remove
Record
• Before a user can move a record, the user
must have the authority to perform this
function on its new parent aggregation as well
as the authority to remove the record from its
previous parent aggregation
• This function only applies to adding records to
a new parent aggregation by moving them from
a previous parent aggregation: it does not apply
Volume 1
to adding records to the aggregation by crea-
ting them in the aggregation (see F14.5.121
Core Services
Record — Create) & Plug-in Modules
Version 1.1
323
1
Information
model F14.5.4 Aggregation — Close
System Identifier 09fb9edc‑d179‑49dc‑b069‑a435f162e6fd
title Aggregation — Close
Description Close the active aggregation
Entity metadata • Closed Timestamp (M14.4.5)

modified

requirement(s)


metadata (see R2.4.16) (M14.4.64)
Usage notes Closing an aggregation may result in its automatic

destruction if all of its contents have previously been
destroyed (see R8.4.21 and F14.5.9 Aggregation —
Destroy)
F14.5.5 Aggregation — Create
System Identifier 6054ae16‑2036‑424e‑9bb7‑aedb6e8229cc
title Aggregation — Create
Description Create an aggregation
Entity metadata • System Identifier (M14.4.100)

modified • Created Timestamp (M14.4.9)
• • Originated Date/Time (M14.4.61)
MoReq2010
• Title (M14.4.104)
Modular Requirements • Description (M14.4.16)
for Records Systems • Scope Notes (M14.4.97)
• Closed Timestamp (M14.4.5)
• Contextual metadata elements
If the aggregation is created in a parent aggregation,
the following metadata element belonging to the
parent aggregation will be modified:
Volume 1
Core Services The following metadata element belonging to the
& Plug-in Modules parent aggregation may also be modified (if it has not
been set previously):
Version 1.1
324
1
Information
model
If contextual metadata elements are applied from a
template, the following template metadata element
may be modified (if it has not already been set):
From functional R2.4.25, R6.5.1, R6.5.2, R7.5.18

requirement(s)


(M14.4.75)
Usage notes • The aggregation may be created closed with a

Closed Timestamp
• Root aggregations (with no parent) must have a
Class Identifier
• Only root aggregations can have Max Levels Of
Aggregation
• Only child aggregations have a Parent
Aggregation Identifier and an Aggregated
Timestamp: the event generated will also
include a Participating Parent Aggregation
Identifier and appear in the event histories
of both the aggregation being created and its
parent aggregation
• The aggregation may be created with contex-
tual metadata elements as well as the system
metadata elements listed
• If contextual metadata elements are added
from a template, the Applied Template •
MoReq2010
Identifier must be included in the event
metadata
• For each metadata element set on crea- Modular Requirements
tion, except System Identifier and Created for Records Systems
Timestamp, a Metadata Change Entry must be
added to the corresponding event
Volume 1
Core Services
& Plug-in Modules
Version 1.1
325
1
Information
model F14.5.6 Aggregation — Delete
System Identifier ae8dd3fe‑3e02‑4aa5‑b9d0‑840e0ea5b68b
title Aggregation — Delete
Description Delete the unused aggregation
Entity metadata The unused aggregation is deleted along with its

modified metadata and event history

requirement(s)
Purpose Access control only
Usage notes No event is generated
F14.5.7 Aggregation — Delete Residual Event
System Identifier bff0f6be‑8b87‑454e‑b4a9‑a8ca584e574b
title Aggregation — Delete Residual Event
Description Delete the event from the event history of the

residual aggregation
Entity metadata • No metadata elements are modified

modified • The event entity is deleted

requirement(s)

• Additional event • Participating Aggregation Identifier

MoReq2010 metadata (see (M14.4.64)
R2.4.16) • Deleted Event Function Definition Identifier
(M14.4.14)
for Records Systems
Usage notes This function always generates an event (see R2.4.14)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
326
1
Information
F14.5.8 Aggregation — Delete Residual Metadata model
System Identifier 8e6f41c0‑fe66‑4147‑865b‑7c3fd0d3b3aa
title Aggregation — Delete Residual Metadata
Description Delete the element from the metadata of the

residual aggregation
Entity metadata Any metadata element may be deleted, including both

modified system and contextual metadata elements, except a
system identifier or a timestamp

requirement(s)


R2.4.16) • Deleted Metadata Element Definition
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
327
1
Information
model F14.5.9 Aggregation — Destroy
System Identifier 60aa99a4‑cf98‑4e03‑b64d‑1fd137e90296
title Aggregation — Destroy
Description Destroy the aggregation
Entity metadata • Destroyed Timestamp (M14.4.17)

modified

requirement(s)
Purpose Event generation only

(M14.4.14)
Usage notes • This function is performed automatically by the

MCRS when the aggregation is closed, under
R6.5.6, and all of its children have previously
been destroyed, under R8.4.22
• The Deleted Metadata Element Definition
Identifier and Deleted Event Function Definition
Identifier are used to show what metadata
elements and which types of events were
pruned from the event history of the aggre-
gation on its destruction, under R2.4.20 and
R7.5.6
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
328
1
Information
F14.5.10 Aggregation — Exported model
System Identifier 3f124e3f‑64e8‑4627‑ac32‑d1aa7b95ffa9
title Aggregation — Exported
Description The aggregation has been exported in full or as a

placeholder
Entity metadata No metadata elements are modified

modified

requirement(s)

R2.4.16) • Export Identifier (M14.4.30)

MCRS as a result of the export process (see
F14.5.185 User — Export) for all entities which
are exported whenever a user conducts an
export under R11.4.1
• The Export Identifier is the system identifier
generated by the MCRS for the export under
R11.4.4
• The Exported In Full Flag should be set if the
entity was exported in full and cleared if the
entity was exported as a placeholder
• The Event Comment contains the export
comment under R11.4.5
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
329
1
Information
model F14.5.11 Aggregation — Inherit Default Class
System Identifier d54f1e11‑36c9‑451e‑abff‑9cfa6b7b28e7
title Aggregation — Inherit Default Class
Description Inherit the default classification of the parent

aggregation
Entity metadata • Class Identifier (M14.4.4)

requirement(s)


Usage notes • This function may only be performed for child

aggregations where the default class has
been overridden (see F14.5.20 Aggregation —
Override Class)
• Performing this function removes the Class
Identifier from the child aggregation ensuring it
inherits its parent’s classification
F14.5.12 Aggregation — Inspect
System Identifier f607266f‑e7fd‑4bba‑bbd3‑462772c1d653
title Aggregation — Inspect
• Description Browse to the aggregation, or discover it by

MoReq2010 searching, and inspect its metadata

Modular Requirements Entity metadata No metadata elements are modified
for Records Systems modified
From functional R6.5.9, R6.5.17, R9.4.7

requirement(s)


R2.4.16)
Volume 1
Usage notes An event should only be generated for this function
Core Services when the user examines the metadata of the
aggregation and not when it is identified while
& Plug-in Modules browsing or included in search results
Version 1.1
330
1
Information
F14.5.13 Aggregation — Inspect ACl model
System Identifier c1de7c62‑b4be‑4622‑99f5‑f78ee88f41da
title Aggregation — Inspect ACl
Description Inspect the access control list of the aggregation

modified

requirement(s)


R2.4.16)
F14.5.14 Aggregation — Inspect Event
System Identifier db9c7774‑0799‑45e0‑999e‑0018cbd71e97
title Aggregation — Inspect Event
Description Browse the event history of the aggregation and

inspect its events

modified

requirement(s)
Purpose • Access control •

• Event generation MoReq2010

metadata (see (M14.4.64) Modular Requirements
R2.4.16) • Participating Event Identifier (M14.4.71) for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
331
1
Information
model F14.5.15 Aggregation — Modify ACl
System Identifier 2b8f6950‑8dce‑41ba‑aec3‑a3b8181a4739
title Aggregation — Modify ACl
Description Modify the access control list for the aggregation
Entity metadata • Include Inherited Roles Flag (M14.4.43)

modified • Access Control Entry (D14.3.1)

requirement(s)


R2.4.16) • Participating User Or Group Identifier
(M14.4.82)
• Rescinded Role Identifier (M14.4.87)
Usage notes • If the value of the Include Inherited Roles Flag

is modified, a Metadata Change Entry must be
• The Participating User Or Group Identifier
refers to the user or group which is associated
with the access control entry
• If more than one access control entry belon-
ging to the aggregation is modified simulta-
neously, an event must be generated for each
access control entry that is added, removed or
• modified
MoReq2010
• The event metadata shows which new roles
were granted to the participating user or
Modular Requirements group and which existing roles were rescinded
for Records Systems through the adding, modifying and deleting of
Volume 1
Core Services
& Plug-in Modules
Version 1.1
332
1
Information
F14.5.16 Aggregation — Modify Max levels of Aggregation model
System Identifier 148427cb‑6e55‑498d‑8352‑c13729ad09c5
title Aggregation — Modify Max levels of Aggregation
Description Modify the maximum number of levels of

aggregation that are allowed under a root
aggregation
Entity metadata • Max Levels Of Aggregation (M14.4.52)

requirement(s)


Usage notes Only root aggregations may have Max Levels Of

Aggregation
F14.5.17 Aggregation — Modify Metadata
System Identifier d4104970‑759a‑45fc‑aa83‑43ca632a2307
title Aggregation — Modify Metadata
Description Modify the metadata of the active aggregation
Entity metadata • Title (M14.4.104)

• Description (M14.4.16) •
• Scope Notes (M14.4.97) MoReq2010
From functional R6.5.3 Modular Requirements

requirement(s) for Records Systems

Usage notes • Any of the system metadata elements listed

may be modified and any modifiable contex- Volume 1
tual metadata elements belonging to the
aggregation Core Services
• For each metadata element modified, a & Plug-in Modules
Metadata Change Entry must be added to the
event generated by performing the function
Version 1.1
333
1
Information
model F14.5.18 Aggregation — Modify originated Date/time
System Identifier 3ed4bcd1‑ae2f‑4c34‑a0e1‑5ddde22d1453
title Aggregation — Modify originated Date/time
Description Modify the Originated Date/Time of the active

aggregation
Entity metadata • Originated Date/Time (M14.4.61)

modified

requirement(s)


Usage notes The event for this function must always have an Event
Comment (see R2.4.26)
F14.5.19 Aggregation — open
System Identifier 7c533508‑1967‑401c‑9aa4‑a6ad85fb63d5
title Aggregation — open
Description Open the active aggregation that has previously

been closed
• Entity metadata • Closed Timestamp (M14.4.5)

MoReq2010 modified

Modular Requirements requirement(s)
for Records Systems Purpose • Access control

Usage notes Opening an aggregation removes the Closed

Timestamp
Volume 1
Core Services
& Plug-in Modules
Version 1.1
334
1
Information
F14.5.20 Aggregation — override Class model
System Identifier a938c62a‑6dff‑4f7f‑9490‑9780cfc74f8b
title Aggregation — override Class
Description Override the previous classification of the aggregation

requirement(s)


Usage notes Performing this function adds a Class Identifier

directly to the aggregation or replaces it if the
aggregation already has a Class Identifier
F14.5.21 Aggregation — Remove Aggregation
System Identifier 41388b8a‑b380‑4997‑8925‑9f678c1655fc
title Aggregation — Remove Aggregation
Description Remove a child aggregation from the aggregation

by moving it to the root or another parent
Entity metadata See related function F14.5.1 Aggregation — Add

Aggregation •
MoReq2010
requirement(s)
Purpose Access control only Modular Requirements

for Records Systems
Usage notes • Before a user can move a child aggregation
out of the aggregation, the user must have the
authority to perform this function, as well as
the authority to add an aggregation to the new
parent or root
• To remove a root aggregation and give it a
parent, the user must have the authority to
perform this function for the record service as
a whole
• This function is always performed in conjunc- Volume 1
tion with F14.5.1 Aggregation — Add
Aggregation, which describes the metadata Core Services
that is modified and the event that is generated
& Plug-in Modules
• This function does not separately modify meta-
data or generate an event
Version 1.1
335
1
Information
model F14.5.22 Aggregation — Remove Record
System Identifier d7d6dc0f‑3d13‑4f98‑8fd5‑b2ad9163d2cc
title Aggregation — Remove Record
Description Remove a record from the aggregation by moving it

to a different parent aggregation
Entity metadata See related function F14.5.3 Aggregation — Add

Record

requirement(s)
Usage notes • Before a user can move a record out of the

aggregation, the user must have the authority to
perform this function, as well as the authority to
add a record to the new parent aggregation
• This function is always performed in conjunc-
tion with F14.5.3 Aggregation — Add Record,
which describes the metadata that is modified
and the event that is generated
F14.5.23 Class — Add Contextual Metadata
System Identifier 5e4be488‑5911‑4fee‑bb5b‑bbc1e76bf8d4
title Class — Add Contextual Metadata

definitions to the class

• Entity metadata • Additional contextual metadata elements, as
MoReq2010 modified specified
for Records Systems

requirement(s)

Additional event • Participating Class Identifier (M14.4.65)

metadata (see • Event Comment (M14.4.25)
R2.4.16) • Metadata Change Entry (D14.3.3)
Volume 1
Core Services Usage notes If contextual metadata elements are added from a
& Plug-in Modules template, the Applied Template Identifier must be
Version 1.1
336
1
Information
F14.5.24 Class — Create model
System Identifier c4285bfb‑b62b‑403c‑9078‑49522d881a85
title Class — Create
Description Create a class

• Title (M14.4.104)
(M14.4.11)

requirement(s)


R2.4.16)
Usage notes • The class entity may be created with contex-

•
metadata elements listed MoReq2010
from a template, the Applied Template
Identifier must be included in the event Modular Requirements
metadata for Records Systems
• For each metadata element set on crea-
tion, except System Identifier and Created
• Where the class’s inherited access controls are
modified on creation then separate F14.5.33
Class — Modify ACL events must be generated
for each change made to the access control list
Volume 1
Core Services
& Plug-in Modules
Version 1.1
337
1
Information
model F14.5.25 Class — Delete
System Identifier f6134d1a‑649d‑4b0a‑9da4‑ce9e4b713d6f
title Class — Delete
Description Delete the unused class
Entity metadata The unused class is deleted along with its metadata
modified and event history

requirement(s)
F14.5.26 Class — Delete Residual Event
System Identifier e8adbb3a‑6e5d‑49d2‑989f‑dabbcc384133
title Class — Delete Residual Event

residual class


requirement(s)

• Additional event • Participating Class Identifier (M14.4.65)

MoReq2010 metadata (see • Deleted Event Function Definition Identifier
R2.4.16) (M14.4.14)
Modular Requirements • Event Comment (M14.4.25)
for Records Systems Usage notes This function always generates an event (see R2.4.14)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
338
1
Information
F14.5.27 Class — Delete Residual Metadata model
System Identifier 145d6256‑0974‑46b1‑b698‑bc0d0ecadb57
title Class — Delete Residual Metadata
Description Delete the element from the metadata of the class


requirement(s)


metadata (see • Deleted Metadata Element Definition
R2.4.16) Identifier (M14.4.15)
F14.5.28 Class — Destroy
System Identifier fed36daf‑26ce‑4d44‑8452‑b0cc3607ab75
title Class — Destroy
Description Destroy the active class

modified
•
From functional R5.4.6 MoReq2010
requirement(s)

for Records Systems
R2.4.16)
• Deleted Metadata Element Definition
(M14.4.14)
Usage notes The Deleted Metadata Element Definition Identifier

and Deleted Event Function Definition Identifier are
used to show what metadata elements and which Volume 1
types of events were pruned from the event history
of the class on its destruction, under R2.4.20 and Core Services
R7.5.6 & Plug-in Modules
Version 1.1
339
1
Information
model F14.5.29 Class — Exported
System Identifier 476a72fd‑0d53‑470c‑b962‑afe9b1780759
title Class — Exported
Description The class has been exported in full or as a

placeholder

modified

requirement(s)

metadata (see • Export Identifier (M14.4.30)
R2.4.16)

R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
340
1
Information
F14.5.30 Class — Inspect model
System Identifier 1ce37d0a‑be50‑410b‑9518‑a4919921255f
title Class — Inspect
Description Browse to the class, or discover it by searching,

and inspect its metadata

modified

requirement(s)


metadata (see
R2.4.16)

when the user examines the metadata of the class
and not when it is identified while browsing or
included in search results
F14.5.31 Class — Inspect ACl
System Identifier 1107cc8a‑798c‑4d6f‑8d95‑55c9f87b43bc
title Class — Inspect ACl
Description Inspect the access control list of the class

modified
•
requirement(s)

for Records Systems
metadata (see
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
341
1
Information
model F14.5.32 Class — Inspect Event
System Identifier 8753d035‑a402‑4346‑be10‑5010e1f278b3
title Class — Inspect Event
Description Browse the event history of the class and inspect

its events

modified

requirement(s)


metadata (see • Participating Event Identifier (M14.4.71)
R2.4.16)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
342
1
Information
F14.5.33 Class — Modify ACl model
System Identifier caced2b7‑3496‑4f0c‑b679‑6a8abc692c4a
title Class — Modify ACl
Description Modify the access control list for the class


requirement(s)


metadata (see • Participating User Or Group Identifier
R2.4.16) (M14.4.82)

ging to the class is modified simultaneously,
an event must be generated for each access
control entry that is added, removed or
modified
•
• The event metadata shows which new roles MoReq2010
group and which existing roles were rescinded
through the adding, modifying and deleting of Modular Requirements
access control entries for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
343
1
Information
model F14.5.34 Class — Modify Default Disposal Schedule
System Identifier 7308ee79‑510a‑4738‑bf79‑07fd0e85f4af
title Class — Modify Default Disposal Schedule
Description Modify the Default Disposal Schedule Identifier of

the active class
Entity metadata • Default Disposal Schedule Identifier

modified (M14.4.11)

requirement(s)


R2.4.16)
F14.5.35 Class — Modify Metadata
System Identifier aa06e05a‑2d32‑4a08‑9902‑bf1628ce506e
title Class — Modify Metadata
Description Modify the metadata of the active class

•
MoReq2010 From functional R5.4.3
requirement(s)
Modular Requirements Purpose • Access control

for Records Systems • Event generation

R2.4.16)

may be modified and any modifiable contextual
metadata elements belonging to the class
• For each metadata element modified, a
Volume 1 Metadata Change Entry must be added to the
Core Services
& Plug-in Modules
Version 1.1
344
1
Information
F14.5.36 Class — Modify originated Date/time model
System Identifier db27260a‑e681‑42b9‑ad2f‑64c5929b4f33
title Class — Modify originated Date/time
Description Modify the Originated Date/Time of the active class

modified

requirement(s)


R2.4.16)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
345
1
Information
model F14.5.37 Component — Add Contextual Metadata
System Identifier 4c36756b‑c66d‑4469‑9379‑c3d979a777dc
title Component — Add Contextual Metadata

definitions to the component

modified specified

requirement(s)
Additional event • Participating Component Identifier (M14.4.66)

metadata (see • Participating Record Identifier (M14.4.77)
R2.4.16)
Usage notes • This function may be performed by any user

authorised to perform F15.5.115 Record —
Add Contextual Metadata
Identifier must be included in the event meta-
data (the template is not considered a partici-
pating entity)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
346
1
Information
F14.5.38 Component — Create model
System Identifier 0d6d5d46‑4bab‑4e92‑8311‑7d93ea476fd1
title Component — Create
Description Create the component of a record

• Title (M14.4.104)

requirement(s)
Additional event • Participating Component Identifier

R2.4.16) • Participating Record Identifier (M14.4.77)
Usage notes • The component is created simultaneously with

its record (see F14.5.121 Record — Create)
•
• The component may be created with contex- MoReq2010
• If contextual metadata elements are added Modular Requirements
from a template, the Applied Template for Records Systems
metadata
Volume 1
Core Services
& Plug-in Modules
Version 1.1
347
1
Information
model F14.5.39 Component — Delete Residual Event
System Identifier a0efddae‑9c93‑4bd4‑bca1‑11e4e12086d4
title Component — Delete Residual Event

residual component


requirement(s)

(M14.4.14)

Delete Residual Event
• This function always generates an event (see
R2.4.14)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
348
1
Information
F14.5.40 Component — Delete Residual Metadata model
System Identifier 18378b4a‑db17‑4309‑9c04‑a88e15888e1e
title Component — Delete Residual Metadata

residual component


requirement(s)


Delete Residual Metadata
• This function always generates an event (see
R7.5.7)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
349
1
Information
model F14.5.41 Component — Destroy
System Identifier 4bc532be‑b33b‑407b‑9c59‑28bb6c65e1ff
title Component — Destroy
Description Destroy the component as part of the destruction

of a record

modified

requirement(s)

(M14.4.14)
Usage notes • This function is performed automatically by

the MCRS as part of destroying a record (see
F14.5.124 Record — Destroy)
Identifier and Deleted Event Function Definition
elements and which types of events were
pruned from the event history of the component
on its destruction, under R2.4.20 and R7.5.6
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
350
1
Information
F14.5.42 Component — Duplicate model
System Identifier 9cd765ac‑a511‑4da1‑9bee‑90b40f769d60
title Component — Duplicate
Description Duplicate a component
Entity metadata • Duplicate Identifier (M14.4.23)

modified

requirement(s)

• Participating Duplicate Identifier (M14.4.69)

the MCRS as part of duplicating a record (see
F14.5.126 Record — Duplicate)
• Two duplicate events will be generated: one
for the first component that identifies the
second component as the duplicate using
the Participating Duplicate Identifier and one
for the second component that identifies the
first component as the duplicate using the
Participating Duplicate Identifier
• The duplicate events will be linked by the
Duplicate Identifier in the event entity
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
351
1
Information
model F14.5.43 Component — Exported
System Identifier cad7c66b‑50ef‑479c‑9403‑f61af0cffea4
title Component — Exported
Description The component has been exported in full or as a

placeholder

modified

requirement(s)

• Export Identifier (M14.4.30)

R11.4.4
• comment under R11.4.5
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
352
1
Information
F14.5.44 Component — Inspect model
System Identifier 31b1b287‑7de3‑4f67‑a637‑c0f7063d19ac
title Component — Inspect
Description Browse to the component, or discover it by

searching, and inspect its metadata

modified

requirement(s)


authorised to perform F15.5.131 Record
— Inspect
• An event should only be generated for this
function when the user examines the metadata
of the component and not when it is identified
while browsing or included in search results
F14.5.45 Component — Inspect Event
System Identifier 351ea1cf‑87e0‑4499‑a397‑f608ad3033c3
title Component — Inspect Event
Description Browse the event history of the component and

inspect its events
•
Entity type Component (E14.2.3) MoReq2010

modified Modular Requirements
From functional R2.4.19, R6.5.21 for Records Systems
requirement(s)

• Participating Event Identifier (M14.4.71)
Usage notes This function may be performed by any user

authorised to perform F15.5.133 Record — Inspect Volume 1
Event
Core Services
& Plug-in Modules
Version 1.1
353
1
Information
model F14.5.46 Component — Modify Metadata
System Identifier fbc13347‑7576‑4aaa‑9109‑d5ff69a43021
title Component — Modify Metadata
Description Modify the metadata of the active component


requirement(s)


Modify Metadata
• Any of the system metadata elements listed
may be modified and any modifiable contex-
tual metadata elements belonging to the
component
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
354
1
Information
F14.5.47 Component — Modify originated Date/time model
System Identifier 94480ab5‑c230‑4c54‑b0a4‑4980441bde4c
title Component — Modify originated Date/time

component

modified

requirement(s)


Modify Originated Date/Time
• The event for this function must always have an
Event Comment (see R2.4.26)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
355
1
Information
model F14.5.48 Contextual Metadata Element Definition — Create
System Identifier e12e910b‑8a2e‑4939‑a34b‑1f0eb06a9697
title Contextual Metadata Element Definition —

Create
Description Create a contextual metadata element definition
Entity type Contextual Metadata Element Definition (E14.2.4)

• Title (M14.4.104)
• Min Occurs (M14.4.56)

requirement(s)

• Additional event • Participating Metadata Element Definition
MoReq2010 metadata (see Identifier (M14.4.74)
Modular Requirements • Metadata Change Entry (D14.3.3)
for Records Systems
Usage notes • For each metadata element set on crea-
• Where the contextual metadata element defi-
nition’s inherited access controls are modified
on creation, separate F14.5.112 Metadata
Element Definition — Modify ACL events must
be generated for each change made to the
access control list
Volume 1
Core Services
& Plug-in Modules
Version 1.1
356
1
Information
F14.5.49 Contextual Metadata Element Definition — Delete model
System Identifier be1eadc6‑d5a2‑4d39‑9a79‑43c501b70cdb

Delete
Description Delete the unused contextual metadata element

definition
Entity metadata The unused contextual metadata element definition is

modified deleted along with its metadata and event history

requirement(s)
F14.5.50 Contextual Metadata Element Definition — Delete Residual Event
System Identifier f791a9a7‑2470‑491c‑b5e5‑31cc04a90788

Delete Residual Event

residual contextual metadata element definition


requirement(s)

Additional event • Participating Metadata Element Definition

metadata (see Identifier (M14.4.74) Modular Requirements
R2.4.16) • Deleted Event Function Definition Identifier for Records Systems
(M14.4.14)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
357
1
Information
model F14.5.51 Contextual Metadata Element Definition — Destroy
System Identifier 59e9e6a6‑b87a‑4ca2‑a615‑36d04518e064

Destroy
Description Destroy the active contextual metadata element

definition

modified

requirement(s)


metadata (see Identifier (M14.4.74)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
358
1
Information
F14.5.52 Contextual Metadata Element Definition — Exported model
System Identifier c1a541d1‑d68a‑4dc4‑93d0‑ae5596263d73

Exported
Description The contextual metadata element definition has

been exported in full or as a placeholder

modified

requirement(s)


R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
359
1
Information
model F14.5.53 Contextual Metadata Element Definition — Modify Before Use
System Identifier 31e98553‑840c‑48ab‑8514‑df2a77e9ae87

Modify Before Use
Description Modify the metadata of the contextual metadata

element definition that has never been used
previously
Entity metadata • Min Occurs (M14.4.56)


requirement(s)


Usage notes • This function may only be performed for

contextual metadata element definitions that
have never been applied to an entity
• event generated by performing the function
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
360
1
Information
F14.5.54 Contextual Metadata Element Definition — Modify originated Date/time model
System Identifier 23ab0db8‑2a0a‑495b‑b7a2‑211d577b2e00

Modify originated Date/time

contextual metadata element definition

modified

requirement(s)


F14.5.55 Disposal Hold — Add Contextual Metadata
System Identifier d3110710‑a391‑4b15‑b6c2‑8e3f904549e2
title Disposal Hold — Add Contextual Metadata

definitions to the disposal hold

modified specified •
MoReq2010
for Records Systems
requirement(s)

Additional event • Participating Disposal Hold Identifier

• Metadata Change Entry (D14.3.3) Volume 1

Core Services
template, the Applied Template Identifier must be & Plug-in Modules
Version 1.1
361
1
Information
model F14.5.56 Disposal Hold — Add Entity
System Identifier 3fa1c42b‑1d1a‑4888‑8e26‑f57a8d76df27
title Disposal Hold — Add Entity
Description Add an active class, aggregation or record to the

active disposal hold
Entity metadata • Held Record Identifier (M14.4.39)

Performing this function may also modify the
following metadata element (if it has not already been
set):

requirement(s)


•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
362
1
Information
F14.5.57 Disposal Hold — Create model
System Identifier 45e638b2‑3eda‑4a2d‑b320‑3b156ed82897
title Disposal Hold — Create
Description Create a disposal hold

• Title (M14.4.104)

requirement(s)


Usage notes • The disposal hold may be created with contex-

•
metadata elements listed MoReq2010
Identifier must be included in the event Modular Requirements
metadata for Records Systems
• Where the disposal hold’s inherited access
controls are modified on creation then separate
F14.5.66 Disposal Hold — Modify ACL events
must be generated for each change made to
the access control list
Volume 1
Core Services
& Plug-in Modules
Version 1.1
363
1
Information
model F14.5.58 Disposal Hold — Delete
System Identifier 52e2be2e‑3aa6‑4854‑8b7d‑d58141cec8a5
title Disposal Hold — Delete
Description Delete the unused disposal hold
Entity metadata The unused disposal hold is deleted along with its

requirement(s)
F14.5.59 Disposal Hold — Delete Residual Event
System Identifier e6b9b61f‑7b7e‑4a30‑84bc‑0908b44d21af
title Disposal Hold — Delete Residual Event

residual disposal hold


requirement(s)

• Additional event • Participating Disposal Hold Identifier

MoReq2010 metadata (see (M14.4.67)
(M14.4.14)
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
364
1
Information
F14.5.60 Disposal Hold — Delete Residual Metadata model
System Identifier 462a20ad‑18d6‑4875‑b47e‑b2ec992c612a
title Disposal Hold — Delete Residual Metadata

residual disposal hold


requirement(s)


F14.5.61 Disposal Hold — Destroy
System Identifier 4b02e580‑7fdb‑4780‑85ce‑fdaa88fff88d
title Disposal Hold — Destroy
Description Destroy the active disposal hold

modified •
MoReq2010
requirement(s)
Purpose • Access control for Records Systems

(M14.4.14)
Volume 1
and Deleted Event Function Definition Identifier are
Core Services
used to show what metadata elements and which
types of events were pruned from the event history & Plug-in Modules
of the disposal hold on its destruction, under R2.4.20
and R7.5.6
Version 1.1
365
1
Information
model F14.5.62 Disposal Hold — Exported
System Identifier 1b60af30‑8fb7‑44af‑8441‑425004fc2780
title Disposal Hold — Exported
Description The disposal hold has been exported in full or as a

placeholder

modified

requirement(s)


R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
366
1
Information
F14.5.63 Disposal Hold — Inspect model
System Identifier cc102e9a‑953f‑410f‑9cf2‑e527ba70e49b
title Disposal Hold — Inspect
Description Browse to the disposal hold, or discover it by


modified

requirement(s)


R2.4.16)

when the user examines the metadata of the disposal
hold and not when it is identified while browsing or
F14.5.64 Disposal Hold — Inspect ACl
System Identifier 971b7480‑cb7e‑43de‑9a37‑41c65cd65c7a
title Disposal Hold — Inspect ACl
Description Inspect the access control list of the disposal hold

modified
From functional R4.5.9 •

requirement(s) MoReq2010

• Event generation Modular Requirements
for Records Systems
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
367
1
Information
model F14.5.65 Disposal Hold — Inspect Event
System Identifier a729cbb2‑ae32‑46ca‑a31b‑de9a1b010100
title Disposal Hold — Inspect Event
Description Browse the event history of the disposal hold and

inspect its events

modified

requirement(s)


R2.4.16) • Participating Event Identifier (M14.4.71)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
368
1
Information
F14.5.66 Disposal Hold — Modify ACl model
System Identifier f308349e‑fd2a‑46ed‑a3bc‑abfd458f30bd
title Disposal Hold — Modify ACl
Description Modify the access control list for the disposal hold


requirement(s)


(M14.4.82)

ging to the disposal hold is modified simulta-
modified •
MoReq2010
group and which existing roles were rescinded Modular Requirements
through the adding, modifying and deleting of for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
369
1
Information
model F14.5.67 Disposal Hold — Modify Metadata
System Identifier 1ff0d40d‑2a88‑4b31‑88f9‑c1efc135c618
title Disposal Hold — Modify Metadata
Description Modify the metadata of the active disposal hold


requirement(s)



metadata elements belonging to the record
F14.5.68 Disposal Hold — Modify originated Date/time
System Identifier 812a29d1‑a7ad‑44d8‑a7aa‑4bab741e1e5b

•
MoReq2010 title Disposal Hold — Modify originated Date/time

disposal hold
for Records Systems Entity type Disposal Hold (E14.2.5)

modified

requirement(s)


Volume 1 metadata (see (M14.4.67)
R2.4.16) Event Comment (M14.4.25)
Core Services •
& Plug-in Modules
Version 1.1
370
1
Information
F14.5.69 Disposal Hold — Remove Entity model
System Identifier dcde1a11‑f6e8‑44f6‑b48b‑d3e61e53b9e2
title Disposal Hold — Remove Entity
Description Remove a class, aggregation or record from the

active disposal hold
Entity metadata • Held Record Identifier (M14.4.39)


requirement(s)


F14.5.70 Disposal Schedule — Add Contextual Metadata
System Identifier 88fed471‑3f1a‑4171‑8099‑b35304d9aee5
title Disposal Schedule — Add Contextual Metadata

definitions to the disposal schedule

modified specified
•
Applying contextual metadata elements from a MoReq2010
• First Used Timestamp (M14.4.32) Modular Requirements
for Records Systems
requirement(s)

Additional event • Participating Disposal Schedule Identifier

Volume 1
Core Services
template, the Applied Template Identifier must be & Plug-in Modules
Version 1.1
371
1
Information
model F14.5.71 Disposal Schedule — Create
System Identifier 25556d43‑6aa9‑41e5‑b146‑e98473e14024
title Disposal Schedule — Create
Description Create a disposal schedule

• Title (M14.4.104)
(M14.4.95)
(M14.4.89)
(M14.4.92)
(M14.4.6)
•
MoReq2010 • First Used Timestamp (M14.4.32)

requirement(s)

Usage notes • The disposal schedule may be created with

Volume 1 contextual metadata elements as well as the
system metadata elements listed
Core Services • If contextual metadata elements are added
& Plug-in Modules from a template, the Applied Template
metadata
Version 1.1
372
1
Information
model
• Where the disposal schedule’s inherited access
controls are modified on creation then separate
F14.5.80 Disposal Schedule — Modify ACL
events must be generated for each change
made to the access control list
F14.5.72 Disposal Schedule — Delete
System Identifier bac5ebc1‑c4c3‑4ec0‑ba97‑7421d17ca968
title Disposal Schedule — Delete
Description Delete the unused disposal schedule
Entity metadata The unused disposal schedule is deleted along with

modified its metadata and event history

requirement(s)
F14.5.73 Disposal Schedule — Delete Residual Event
System Identifier 8b26a551‑b2c9‑4940‑ade6‑ddf9ce771e62
title Disposal Schedule — Delete Residual Event

residual disposal schedule •
MoReq2010

modified
• The event entity is deleted for Records Systems
requirement(s)


(M14.4.14) Volume 1
Core Services
& Plug-in Modules
Version 1.1
373
1
Information
model F14.5.74 Disposal Schedule — Delete Residual Metadata
System Identifier 2ef9758c‑9143‑4859‑bf7f‑f7e3384c8750
title Disposal Schedule — Delete Residual Metadata

residual disposal schedule


requirement(s)


F14.5.75 Disposal Schedule — Destroy
System Identifier 20f4d0e0‑98c7‑45b5‑81d2‑a14e67325f8e
title Disposal Schedule — Destroy
Description Destroy the active disposal schedule
• Entity metadata • Destroyed Timestamp (M14.4.17)

MoReq2010 modified


Volume 1 (M14.4.14)

Core Services and Deleted Event Function Definition Identifier are
& Plug-in Modules used to show what metadata elements and which
types of events were pruned from the event history of
the entity on its destruction, under R2.4.20 and R7.5.6
Version 1.1
374
1
Information
F14.5.76 Disposal Schedule — Exported model
System Identifier 48f27df0‑580a‑4804‑ab94‑425dda402347
title Disposal Schedule — Exported
Description The disposal schedule has been exported in full or

as a placeholder

modified

requirement(s)


R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
375
1
Information
model F14.5.77 Disposal Schedule — Inspect
System Identifier a87eaf88‑b537‑4061‑b57a‑2d50e6fb5f9d
title Disposal Schedule — Inspect
Description Browse to the disposal schedule, or discover it by


modified

requirement(s)


metadata (see R2.4.16) (M14.4.68)

when the user examines the metadata of the disposal
schedule and not when it is identified while browsing
or included in search results
F14.5.78 Disposal Schedule — Inspect ACl
System Identifier 624f62eb‑7e01‑4e98‑b886‑291a1166698d
title Disposal Schedule — Inspect ACl
Description Inspect the access control list of the disposal

schedule

modified
•
MoReq2010 From functional R4.5.9
requirement(s)

for Records Systems
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
376
1
Information
F14.5.79 Disposal Schedule — Inspect Event model
System Identifier 028167e8‑309a‑458f‑8ae3‑5dfbab73451d
title Disposal Schedule — Inspect Event
Description Browse the event history of the disposal schedule

and inspect its events

modified

requirement(s)


•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
377
1
Information
model F14.5.80 Disposal Schedule — Modify ACl
System Identifier 31b963f1‑392c‑4bd6‑a696‑934a53142632
title Disposal Schedule — Modify ACl
Description Modify the access control list for the disposal

schedule


requirement(s)


(M14.4.82)

• If more than one access control entry belonging
to the disposal schedule is modified simulta-
• access control entry that is added, removed or
MoReq2010
modified
Modular Requirements were granted to the participating user or
for Records Systems group and which existing roles were rescinded
through the adding, modifying and deleting of
Volume 1
Core Services
& Plug-in Modules
Version 1.1
378
1
Information
F14.5.81 Disposal Schedule — Modify Metadata model
System Identifier 8ec42472‑e351‑4c7e‑8c02‑9da97677d9ac
title Disposal Schedule — Modify Metadata
Description Modify the metadata of the active disposal

schedule

In accordance with R8.4.9, the following metadata
may only be modified prior to the disposal schedule
being applied to a record:
(M14.4.95)
(M14.4.89)
(M14.4.92)
(M14.4.6)

requirement(s)
•
Purpose • Access control MoReq2010
Additional event • Participating Disposal Schedule Identifier Modular Requirements

for Records Systems

Volume 1
Core Services
& Plug-in Modules
Version 1.1
379
1
Information
model F14.5.82 Disposal Schedule — Modify originated Date/time
System Identifier d98a38e4‑8a18‑4141‑a245‑58043ada13c1
title Disposal Schedule — Modify originated Date/

time

disposal schedule

modified

requirement(s)


F14.5.83 Entity type — Inspect
System Identifier e9975a09‑acdf‑4ef7‑8ae8‑eae72c66cb03
title Entity type — Inspect
Description Browse to the entity type, or discover it by

Entity type Entity Type (E14.2.7)

•
MoReq2010 Entity metadata No metadata elements are modified
modified
Modular Requirements From functional R2.4.9, R7.5.12

requirement(s)
for Records Systems
Additional event • Participating Entity Type Identifier (M14.4.70)

metadata (see
R2.4.16)

when the user examines the metadata of the entity
type and not when it is identified while browsing or
Volume 1 included in search results
Core Services
& Plug-in Modules
Version 1.1
380
1
Information
F14.5.84 Entity type — Inspect ACl model
System Identifier a500ff2b‑0518‑459e‑94d6‑1f2f281b30d8
title Entity type — Inspect ACl
Description Inspect the access control list of the entity type

modified

requirement(s)


metadata (see
R2.4.16)
F14.5.85 Entity type — Inspect Event
System Identifier e6d3f367‑ec8f‑4cac‑b65b‑7285dd4b3358
title Entity type — Inspect Event
Description Browse the event history of the entity type and

inspect its events

modified

requirement(s)


metadata (see • Participating Event Identifier (M14.4.71) Modular Requirements
R2.4.16) for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
381
1
Information
model F14.5.86 Entity type — Modify ACl
System Identifier 0704069a‑0129‑4978‑9e69‑401da1dbdc0a
title Entity type — Modify ACl
Description Modify the access control list for the entity type


requirement(s)


R2.4.16) (M14.4.82)

ging to the entity type is modified simulta-
modified
•
MoReq2010 • The event metadata shows which new roles
Modular Requirements through the adding, modifying and deleting of
for Records Systems access control entries
Volume 1
Core Services
& Plug-in Modules
Version 1.1
382
1
Information
F14.5.87 Function Definition — Inspect model
System Identifier eedac611‑18b3‑46ab‑9f78‑ce5d105343f3
title Function Definition — Inspect
Description Browse to the function definition, or discover it by


modified

requirement(s)

Additional event • Participating Function Definition Identifier

R2.4.16)

when the user examines the metadata of the function
definition and not when it is identified while browsing
F14.5.88 Function Definition — Inspect ACl
System Identifier eceb7200‑db40‑40cd‑8140‑a8a2fb2adfea
title Function Definition — Inspect ACl
Description Inspect the access control list of the function

definition
Entity metadata No metadata elements are modified •

modified MoReq2010

requirement(s) Modular Requirements
for Records Systems

R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
383
1
Information
model F14.5.89 Function Definition — Inspect Event
System Identifier 4ba33648‑4e99‑421a‑acc3‑92f1579839e4
title Function Definition — Inspect Event
Description Browse the event history of the function definition

and inspect its events

modified

requirement(s)


•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
384
1
Information
F14.5.90 Function Definition — Modify ACl model
System Identifier c1c23be7‑1bfe‑49bb‑a9e6‑648a947926af
title Function Definition — Modify ACl
Description Modify the access control list for the function

definition


requirement(s)


(M14.4.82)

to the function definition is modified simulta-
access control entry that is added, removed or •
MoReq2010
modified
were granted to the participating user or Modular Requirements
group and which existing roles were rescinded for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
385
1
Information
model F14.5.91 Function Definition — Modify Event Generation
System Identifier e2cf111d‑faa8‑4dd4‑ad4c‑36e15ad603f7
title Function Definition — Modify Event Generation
Description Change whether an event is generated when the

function is performed
Entity metadata • Generate Event Flag (M14.4.34)

modified

requirement(s)


F14.5.92 Function Definition — Modify Retain Event on Destruction
System Identifier 712df19b‑80e1‑4dda‑b3a4‑1971b8ebcf67
title Function Definition — Modify Retain Event on

Destruction
Description Change whether an event is retained or deleted

when the participating entity is destroyed
• Entity metadata • Retain On Destruction Flag (M14.4.88)

MoReq2010 modified


Volume 1
Core Services
& Plug-in Modules
Version 1.1
386
1
Information
F14.5.93 Group — Add Contextual Metadata model
System Identifier 60d37b06‑55e5‑44d9‑998b‑8b866afbecb9
title Group — Add Contextual Metadata

definitions to the group
Entity type Group (E14.2.10)

modified specified

requirement(s)

Additional event • Participating Group Identifier (M14.4.73)

R2.4.16)

•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
387
1
Information
model F14.5.94 Group — Add User
System Identifier 5327775f‑2899‑4268‑aa59‑92f5f6ee2f4f
title Group — Add User
Description Add the active user to the active group

participating group may be modified (if it has not
been set previously):
Performing this group function adds the following
metadata element to the participating user entity:

requirement(s)


metadata (see • Participating User Identifier (M14.4.81)
R2.4.16)
Usage notes • This function may occur in another system

external to the MCRS and be synchronised to it
• Although this function (and the corresponding
authority to perform it) is associated with the
group, performing it has the effect of modifying
the Group Identifier for the user entity
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
388
1
Information
F14.5.95 Group — Create model
System Identifier 97039415‑a9c2‑4cf7‑999d‑f4135304d97a
title Group — Create
Description Create a group

• Title (M14.4.104)

requirement(s)


R2.4.16)

• The group entity may be created with contex-
•
• If contextual metadata elements are added MoReq2010
metadata Modular Requirements
• For each metadata element set on crea- for Records Systems
• Where the group’s inherited access controls
are modified on creation then separate
F14.5.104 Group — Modify ACL events must
access control list
Volume 1
Core Services
& Plug-in Modules
Version 1.1
389
1
Information
model F14.5.96 Group — Delete
System Identifier 30e6e15b‑f889‑4ff7‑8a66‑a695498b5565
title Group — Delete
Description Delete the unused group
Entity metadata The unused group entity is deleted along with its

requirement(s)
F14.5.97 Group — Delete Residual Event
System Identifier ac82726d‑804e‑491d‑a5ec‑a27ffb986a91
title Group — Delete Residual Event

residual group


requirement(s)

• Additional event • Participating Group Identifier (M14.4.73)

R2.4.16) (M14.4.14)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
390
1
Information
F14.5.98 Group — Delete Residual Metadata model
System Identifier 41d00f75‑2403‑4d16‑b825‑f85acf6ee746
title Group — Delete Residual Metadata

residual group


requirement(s)


F14.5.99 Group — Destroy
System Identifier 0201d5d3‑e201‑4c5a‑90b1‑1a98913ba09a
title Group — Destroy
Description Destroy the active group

modified •
MoReq2010
requirement(s)
Purpose • Access control Modular Requirements

for Records Systems

R2.4.16)
(M14.4.14)

and Deleted Event Function Definition Identifier are Volume 1
types of events were pruned from the event history Core Services
of the group on its destruction, under R2.4.20 and & Plug-in Modules
R7.5.6
Version 1.1
391
1
Information
model F14.5.100 Group — Exported
System Identifier 6978b25b‑0036‑44f9‑ae99‑b80e10027fe6
title Group — Exported
Description The group has been exported in full or as a

placeholder

modified

requirement(s)

R2.4.16)

R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
392
1
Information
F14.5.101 Group — Inspect model
System Identifier 642ce23c‑542f‑40c1‑912d‑07897a1415de
title Group — Inspect
Description Browse to the group, or discover it by searching,


modified

requirement(s)


metadata (see
R2.4.16)

when the user examines the metadata of the group
F14.5.102 Group — Inspect ACl
System Identifier d52f4721‑d55b‑4eee‑aaab‑f77d83e0dd55
title Group — Inspect ACl
Description Inspect the access control list of the group

modified
•
requirement(s)

for Records Systems
metadata (see
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
393
1
Information
model F14.5.103 Group — Inspect Event
System Identifier bcadb823‑13a1‑4ba5‑ae36‑62b106132c7a
title Group — Inspect Event
Description Browse the event history of the group and inspect

its events

modified

requirement(s)


R2.4.16)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
394
1
Information
F14.5.104 Group — Modify ACl model
System Identifier f48f825f‑2afb‑427e‑bdaa‑056bb025521c
title Group — Modify ACl
Description Modify the access control list for the group


requirement(s)


R2.4.16) (M14.4.82)

with the access control entry and should not be
confused with the Participating Group Identifier
which indicates the group entity that has the
access control list
ging to the group is modified simultaneously,
an event must be generated for each access •
MoReq2010
modified
• The event metadata shows which new roles Modular Requirements
were granted to the participating user or for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
395
1
Information
model F14.5.105 Group — Modify Metadata
System Identifier b6d7687f‑d94e‑4281‑8575‑1302556ca6ba
title Group — Modify Metadata
Description Modify the metadata of the active group


requirement(s)


R2.4.16)

metadata elements belonging to the group
F14.5.106 Group — Modify originated Date/time
System Identifier b5ed9497‑7ac2‑4f95‑8728‑fd23d30d3b86

• title Group — Modify originated Date/time
MoReq2010
group
for Records Systems
modified

requirement(s)


Volume 1 metadata (see • Event Comment (M14.4.25)
R2.4.16)
Core Services • Metadata Change Entry (D14.3.3)
& Plug-in Modules Usage notes The event for this function must always have an Event
Version 1.1
396
1
Information
F14.5.107 Group — Remove User model
System Identifier c3713f12‑feb6‑459e‑a21a‑7e63aaeeea6c
title Group — Remove User
Description Remove the active user from the active group
Entity metadata Performing this group function removes the following

metadata element belonging to the participating user
entity:

requirement(s)


R2.4.16)

• This function (and the corresponding authority
to perform it) is associated with the group, not
the participating user entity
F14.5.108 Group — Report User Membership
System Identifier 8b8c09d4‑30aa‑41c4‑b0fc‑1a0ecf4f9d88
title Group — Report User Membership
Description Report the active users that belonged to the group

at a specified historical date and time •
MoReq2010
Entity metadata No metadata elements are modified Modular Requirements

modified
for Records Systems
requirement(s)


metadata (see • Historical Date/Time (M14.4.40)
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
397
1
Information
model F14.5.109 Metadata Element Definition — Inspect
System Identifier a5423f4d‑0f15‑4376‑8d22‑b10affe3ae3a
title Metadata Element Definition — Inspect
Description Browse to the metadata element definition, or

discover it by searching, and inspect its metadata

modified

requirement(s)


R2.4.16)

when the user examines the metadata of the
metadata element definition and not when it is
identified while browsing or included in search
results
F14.5.110 Metadata Element Definition — Inspect ACl
System Identifier 35f8d31b‑9db2‑4d37‑96a2‑d0ad36533a92
title Metadata Element Definition — Inspect ACl
Description Inspect the access control list of the metadata

element definition

•
modified
Modular Requirements From functional R4.5.9

for Records Systems requirement(s)


R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
398
1
Information
F14.5.111 Metadata Element Definition — Inspect Event model
System Identifier 72459e48‑ea29‑4b05‑a125‑75a36a0ea74f
title Metadata Element Definition — Inspect Event
Description Browse the event history of the metadata element

definition and inspect its events

modified

requirement(s)


•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
399
1
Information
model F14.5.112 Metadata Element Definition — Modify ACl
System Identifier 2f04f823‑c37a‑4c68‑b6fa‑76be4a76cf7d
title Metadata Element Definition — Modify ACl
Description Modify the access control list for the metadata

element definition


requirement(s)


(M14.4.82)

to the metadata element definition is modified
simultaneously, an event must be generated
• for each access control entry that is added,
MoReq2010
removed or modified
Modular Requirements were granted to the participating user or
for Records Systems group and which existing roles were rescinded
Volume 1
Core Services
& Plug-in Modules
Version 1.1
400
1
Information
F14.5.113 Metadata Element Definition — Modify Metadata model
System Identifier 2a70d3d6‑4f38‑4666‑82ac‑82d0ceb5e608
title Metadata Element Definition — Modify Metadata
Description Modify the metadata of the active metadata

element definition


requirement(s)


Usage notes For each metadata element modified, a Metadata

Change Entry must be added to the event generated
by performing the function
F14.5.114 Metadata Element Definition — Modify Retain on Destruction
System Identifier f8f0cbb3‑8f9e‑4dc9‑807e‑36e351b85960
title Metadata Element Definition — Modify Retain on •

MoReq2010
Destruction
Description Change whether the value of a metadata element

is retained or deleted when the entity it belongs to Modular Requirements
is destroyed for Records Systems
Entity metadata • Retain On Destruction Flag (M14.4.88)

modified

requirement(s)

Volume 1
metadata (see Identifier (M14.4.74) Core Services
R2.4.16) • Event Comment (M14.4.25) & Plug-in Modules
Version 1.1
401
1
Information
model F14.5.115 Record — Add Contextual Metadata
System Identifier 83fa3a37‑8bee‑494e‑af7a‑8c23e56bb106
title Record — Add Contextual Metadata

definitions to the record

modified specified

requirement(s)

Additional event • Participating Record Identifier (M14.4.77)

R2.4.16)

•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
402
1
Information
F14.5.116 Record — Cancel Destruction model
System Identifier 09cb99bb‑bcd8‑45cd‑b0a3‑436aab6a46b5
title Record — Cancel Destruction
Description Cancel the pending destruction of the record
Entity metadata • Disposal Schedule Identifier (M14.4.22)

modified • Retention Start Date (M14.4.93)
(M14.4.21)

requirement(s)


metadata (see • Metadata Change Entry (D14.3.3)
R2.4.16)
Usage notes • A new disposal schedule must be applied to the

record to replace the disposal schedule in force
• The cancellation comment is stored as the
Event Comment and is required under R8.4.18
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
403
1
Information
model F14.5.117 Record — Cancel transfer
System Identifier 19e3483a‑dded‑4e5f‑a812‑15b5a06da197
title Record — Cancel transfer
Description Cancel the pending transfer of the record

modified • Retention Start Date (M14.4.93)
(M14.4.21)

requirement(s)


R2.4.16)
Usage notes • A new disposal schedule must be applied to the

record to replace the disposal schedule in force
• The cancellation comment is stored as the
Event Comment and is required under R8.4.18
F14.5.118 Record — Complete Review
System Identifier 339c50b5‑3e06‑4507‑80e5‑946cfa9b3ba5

•
MoReq2010 title Record — Complete Review
Description Complete a review of the record

Modular Requirements Entity type Record (E14.2.12)
for Records Systems
modified • Last Review Comment (M14.4.49)
• Last Reviewed Timestamp (M14.4.50)

requirement(s)

Volume 1 Additional event • Participating Record Identifier (M14.4.77)
metadata (see Metadata Change Entry (D14.3.3)
Core Services R2.4.16)
•

& Plug-in Modules
Usage notes The review comment is stored as the Event Comment
(see R8.4.17)
Version 1.1
404
1
Information
F14.5.119 Record — Confirm Destruction model
System Identifier a221b6c3‑4b3e‑4737‑a4f6‑def8bded9af2
title Record — Confirm Destruction
Description Confirm the destruction of the record

modified

requirement(s)


R2.4.16)
Usage notes • Where the user closes aggregations as part of

confirming the destruction of the record, under
R8.4.23, separate F14.5.4 Aggregation —
Close events should be generated
On confirmation, the MCRS must immediately
perform the following automatic functions: F14.5.124
Record — Destroy, F14.5.41 Component — Destroy
and, possibly, F14.5.9 Aggregation — Destroy (under
R8.4.21)
F14.5.120 Record — Confirm transfer
System Identifier 601253a3‑723e‑458b‑be7d‑2f4659c88eae
title Record — Confirm transfer
Description Confirm the transfer of the record •

MoReq2010
Entity metadata • Transferred Timestamp (M14.4.106) Modular Requirements

modified Disposal Action Code (M14.4.18)
• for Records Systems
(M14.4.21)

requirement(s)

• Event generation Volume 1
Additional event Participating Record Identifier (M14.4.77)
metadata (see
•
Core Services
R2.4.16) & Plug-in Modules
Version 1.1
405
1
Information
model F14.5.121 Record — Create
System Identifier 13d444bf‑3ba2‑4c38‑adc5‑b57ec9e86f74
title Record — Create
Description Create a record

• Title (M14.4.104)
• Disposal Schedule Identifier (M14.4.22)
record’s parent aggregation will be modified:
record’s parent aggregation may also be modified (if
it has not been set previously):

requirement(s)

• • Event generation
MoReq2010
metadata (see • Participating New Parent Identifier
Modular Requirements R2.4.16) (M14.4.75)
for Records Systems • Event Comment (M14.4.25)
Usage notes • One or more components must be created

simultaneously with the record (see F14.5.38
Component — Create)
• The Class Identifier applies only when overri-
ding the record’s inherited classification (from
its parent aggregation) on creation
Volume 1 • The Disposal Schedule Identifier applies only
when immediately overriding the record’s
Core Services default disposal schedule (inherited from its
& Plug-in Modules classification) on creation
• All records must have a Parent Aggregation
Identifier and an Aggregated Timestamp
Version 1.1
406
1
Information
model
• The record may be created with contextual
metadata elements as well as the system

metadata
• Where the record’s inherited access controls
F14.5.134 Record — Modify ACL events must
access control list
F14.5.122 Record — Delete Residual Event
System Identifier 9a91e950‑48cd‑4270‑a592‑dd41f4248ecc
title Record — Delete Residual Event

residual record


requirement(s)

•
Additional event • Participating Record Identifier (M14.4.77) MoReq2010
metadata (see • Deleted Event Function Definition Identifier
R2.4.16) (M14.4.14)
• Event Comment (M14.4.25) Modular Requirements
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
407
1
Information
model F14.5.123 Record — Delete Residual Metadata
System Identifier 5812baba‑fd3f‑49c0‑8560‑2068d3f8c994
title Record — Delete Residual Metadata

residual record


requirement(s)


•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
408
1
Information
F14.5.124 Record — Destroy model
System Identifier 508e5ad6‑0c8a‑4ece‑9b46‑b8b39b53c857
title Record — Destroy
Description Destroy the record

modified • Disposal Schedule Identifier (M14.4.22)

requirement(s)

(M14.4.14)

the MCRS as a result of the update process
(see F14.5.140 Record — Update Disposal) for
records with components subject to automatic
destruction, or otherwise by user confir-
mation (see F14.5.119 Record — Confirm
Destruction)
• The Disposal Schedule Identifier is updated to
ensure that the disposal schedule, under which
the record was destroyed, stays with the resi-
dual record even if it was previously inherited
• The components of the record must be
simultaneously automatically destroyed (see
F14.5.41 Component — Destroy) and the
record’s aggregation may also be destroyed
under R8.4.22 (see F14.5.9 Aggregation •
— Destroy) MoReq2010

Identifier and Deleted Event Function Definition Modular Requirements
elements and which types of events were for Records Systems
pruned from the event history of the record on
its destruction, under R2.4.20 and R7.5.6
Volume 1
Core Services
& Plug-in Modules
Version 1.1
409
1
Information
model F14.5.125 Record — Disposal Alert
System Identifier fdb351ed‑d8eb‑41e9‑9e15‑8b1bf32a3798
title Record — Disposal Alert
Description Alert for the record sent when the disposal

confirmation due date has elapsed
Entity metadata • Disposal Overdue Alert Timestamp

modified (M14.4.21)

requirement(s)


R2.4.16)
• Overdue Disposal Action Code (M14.4.58)
• Overdue Disposal Action Due Date (M14.4.59)
• Overdue Disposal Confirmation Due Date
(M14.4.60)
Usage notes • Users receive alerts by being granted roles that

include this function
• The function itself is always automatically
performed by the MCRS as part of the disposal
process (see F14.5.140 Record — Update
Disposal)
• The event should include a Participating User
Identifier for each user that was sent the alert
• The Overdue Disposal Action Code should
indicate the disposal action that was due on the
• record when the alert was sent
MoReq2010
• The Overdue Disposal Confirmation Due Date
should indicate the confirmation due date for
Modular Requirements the record when the alert was sent
for Records Systems • The Event Comment may be used by the MCRS
to give additional details of the alert (alerts may
be sent using many different mechanisms and
technologies (see R8.4.15))
Volume 1
Core Services
& Plug-in Modules
Version 1.1
410
1
Information
F14.5.126 Record — Duplicate model
System Identifier e6f97ac3‑c9cc‑4036‑a471‑a00c865db8a6
title Record — Duplicate
Description Duplicate a record
Entity metadata The following entities will be duplicated:

modified • the record and all its metadata;
• every event and all its metadata, in the event
history of the record; and
• every component of the record and all its
metadata.
For each record, component and event, including
both the original and the duplicates, the following
metadata will be added to identify the corresponding
record, component or event in the MCRS:

requirement(s)


metadata (see • Participating Duplicate Identifier (M14.4.69)
R2.4.16)
Usage notes • Two duplicate events will be generated: one

for the first record that identifies the second
record as the duplicate using the Participating
Duplicate Identifier and one for the second
record that identifies the first record as the
duplicate using the Participating Duplicate •
MoReq2010
Identifier
• The duplicate events will be linked by the
Duplicate Identifier in the event entity Modular Requirements
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
411
1
Information
model F14.5.127 Record — Exported
System Identifier 1140f9cc‑99e9‑40e3‑b3dd‑be485170f718
title Record — Exported
Description The record has been exported in full or as a

placeholder

modified

requirement(s)

R2.4.16)

R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
412
1
Information
F14.5.128 Record — Held model
System Identifier 38f887ed‑7021‑460d‑8820‑d26af5ce63a1
title Record — Held
Description Indicate that the record is subject to a disposal hold
Entity metadata • Disposal Action Code (M14.4.18)

modified • Disposal Action Due Date (M14.4.19)

requirement(s)
Purpose • Event generation only

metadata (see
R2.4.16)

MCRS as a result of the update process (see
F14.5.140 Record — Update Disposal)
• The purpose of the function is to generate an
event in the event history of the record
• The Disposal Action Code must be changed
from DESTROY to RETAIN ON HOLD
• The Disposal Action Due Date and Disposal
Confirmation Due Date must be deleted
• See also F14.5.139 Record — Released
F14.5.129 Record — Inherit Default Class
System Identifier e62728b4‑13d7‑4ef4‑9833‑7d8931c748e2
title Record — Inherit Default Class •

MoReq2010
Description Inherit the default classification of the record’s
parent aggregation
for Records Systems

requirement(s)


R2.4.16) Volume 1
Usage notes Performing this function removes the Class Identifier

Core Services
from the record (see F14.5.137 Record — Override & Plug-in Modules
Class) ensuring the record inherits its classification
from its parent aggregation
Version 1.1
413
1
Information
model F14.5.130 Record — Inherit Default Disposal Schedule
System Identifier eb4f94b8‑9c0d‑4f44‑8d7c‑b73c45735e49
title Record — Inherit Default Disposal Schedule
Description Inherit the default disposal schedule from the

active record’s class

requirement(s)


R2.4.16)
Usage notes Performing this function removes the Disposal

Schedule Identifier from the record (see F14.5.138
Record — Override Disposal Schedule) ensuring the
record inherits the default disposal schedule from its
classification
F14.5.131 Record — Inspect
System Identifier 4f5f638f‑f6ef‑4917‑adc0‑82f90d065ef6
title Record — Inspect
Description Browse to the record, or discover it by searching,


•
modified
Modular Requirements From functional R6.5.9, R6.5.17, R9.4.7, R8.4.16

requirement(s)
for Records Systems

metadata (see
R2.4.16)

when the user examines the metadata of the record
Volume 1 included in search results
Core Services
& Plug-in Modules
Version 1.1
414
1
Information
F14.5.132 Record — Inspect ACl model
System Identifier 7e4d0e6b‑e726‑4e3b‑87a4‑d1f6df60137e
title Record — Inspect ACl
Description Inspect the access control list of the record

modified

requirement(s)


metadata (see
R2.4.16)
F14.5.133 Record — Inspect Event
System Identifier 29ee9ad5‑6f9d‑4663‑9f99‑99dca188c70e
title Record — Inspect Event
Description Browse the event history of the record and inspect

its events

modified

requirement(s)


metadata (see • Participating Event Identifier (M14.4.71) Modular Requirements
R2.4.16) for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
415
1
Information
model F14.5.134 Record — Modify ACl
System Identifier 5e3380b4‑da4a‑4e1c‑9387‑5b83934ff1c2
title Record — Modify ACl
Description Modify the access control list for the record


requirement(s)


R2.4.16) (M14.4.82)

ging to the record is modified simultaneously,
modified
•
Volume 1
Core Services
& Plug-in Modules
Version 1.1
416
1
Information
F14.5.135 Record — Modify Metadata model
System Identifier b793efb9‑fa12‑41e9‑9327‑784324368bad
title Record — Modify Metadata
Description Modify the metadata of the active record


requirement(s)


R2.4.16)

F14.5.136 Record — Modify originated Date/time
System Identifier 2249c5a3‑e760‑4a82‑89b5‑47b804ff4c32
title Record — Modify originated Date/time

•
record MoReq2010
Entity metadata • Originated Date/Time (M14.4.61) Modular Requirements

modified for Records Systems
requirement(s)


R2.4.16)
Volume 1
Comment (see R2.4.26) Core Services
& Plug-in Modules
Version 1.1
417
1
Information
model F14.5.137 Record — override Class
System Identifier 069c29c9‑15d9‑42d8‑8de4‑a46b0405552a
title Record — override Class
Description Override the previous classification of the record

requirement(s)


R2.4.16)
Usage notes Performing this function adds a Class Identifier

directly to the record or replaces it if the record
already has a Class Identifier
F14.5.138 Record — override Disposal Schedule
System Identifier c53ebf62‑c69f‑4e3d‑b728‑33252f4faa01
title Record — override Disposal Schedule
Description Override the previous disposal schedule of the

active record

•
MoReq2010 requirement(s)

Modular Requirements • Event generation
for Records Systems Additional event • Participating Record Identifier (M14.4.77)
R2.4.16)
Usage notes Performing this function adds a Disposal Schedule

Identifier directly to the record or replaces it if the
record already has a Disposal Schedule Identifier
Volume 1
Core Services
& Plug-in Modules
Version 1.1
418
1
Information
F14.5.139 Record — Released model
System Identifier 185d46fa‑22c8‑4a65‑904b‑c51604df1189
title Record — Released
Description Indicate that the record is no longer subject to any

disposal hold
Entity metadata • Disposal Action Code (M14.4.18)

modified • Disposal Action Due Date (M14.4.19)

requirement(s)
Purpose • Event generation only

metadata (see
R2.4.16)

MCRS as a result of the update process (see
F14.5.140 Record — Update Disposal)
• The purpose of the function is to generate an
event in the event history of the record
• The Disposal Action Code must be changed
from RETAIN ON HOLD back to DESTROY
• The Disposal Action Due Date and Disposal
Confirmation Due Date must be calculated and
applied to the record
• See also F14.5.128 Record — Held
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
419
1
Information
model F14.5.140 Record — Update Disposal
System Identifier 08f23ade‑4023‑46af‑add7‑39e6d399a5c3
title Record — Update Disposal
Description Update the disposal progress of the record
Entity metadata • Retention Start Date (M14.4.93)

modified • Disposal Action Code (M14.4.18)
(M14.4.21)

requirement(s)


R2.4.16)
Usage notes • This function may be performed by a user and

is also performed automatically by the MCRS in
real time or at regular intervals
• When the metadata of the record is updated, a
event for each change
• An outcome of this function may be to trigger
an alert (see F14.5.125 Record — Disposal
Alert), the destruction of the record (see
F14.5.124 Record — Destroy), to indicate a
disposal schedule is in place (see F14.5.128
• Record — Held) or has been lifted (see
MoReq2010 F14.5.139 Record — Released)
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
420
1
Information
F14.5.141 Role — Add Contextual Metadata model
System Identifier c10b0afa‑87b6‑42be‑a45d‑55a663f2df54
title Role — Add Contextual Metadata

definitions to the role
Entity type Role (E14.2.13)

modified specified

requirement(s)

Additional event • Participating Role Identifier (M14.4.78)

R2.4.16)

F14.5.142 Role — Add Function Definition
System Identifier b5782d06‑9597‑4c2b‑aa18‑1845e650ce05

•
title Role — Add Function Definition MoReq2010
Description Add the function definition to the active role
Entity type Role (E14.2.13) Modular Requirements

for Records Systems
Entity metadata • Function Definition Identifier (M14.4.33)

requirement(s)


metadata (see • Participating Function Definition Identifier
R2.4.16) (M14.4.72) Volume 1
Core Services
& Plug-in Modules
Version 1.1
421
1
Information
model F14.5.143 Role — Create
System Identifier 246af58d‑72a1‑4e03‑9a1d‑3fe7094e00af
title Role — Create
Description Create a role

• Title (M14.4.104)

requirement(s)


R2.4.16)
Usage notes • The role may be created with contextual meta-

data elements as well as the system metadata
elements listed
•
MoReq2010 • If contextual metadata elements are added
from a template, Applied Template Identifier
must be included in the event metadata
Modular Requirements • For each metadata element set on crea-
for Records Systems tion, except System Identifier and Created
• Where the role is created with one or more
active function definitions associated with it
then separate F14.5.142 Role — Add Function
Definition events must be generated for each
function definition added to it on creation
• Where the role’s inherited access controls are
modified on creation then separate F14.5.152
Volume 1 Role — Modify ACL events must be generated
for each change made to the access control list
Core Services
& Plug-in Modules
Version 1.1
422
1
Information
F14.5.144 Role — Delete model
System Identifier 451fda23‑8a3a‑4a80‑976f‑9dd45a7eb1a5
title Role — Delete
Description Delete the unused role
Entity metadata The unused role is deleted along with its metadata
modified and event history

requirement(s)
F14.5.145 Role — Delete Residual Event
System Identifier 8eec771e‑6441‑4b58‑b771‑cccbaa94c55f
title Role — Delete Residual Event

residual role


requirement(s)

Additional event • Participating Role Identifier (M14.4.78) •

metadata (see • Deleted Event Function Definition Identifier MoReq2010
R2.4.16) (M14.4.14)
Usage notes This function always generates an event (see R2.4.14) for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
423
1
Information
model F14.5.146 Role — Delete Residual Metadata
System Identifier 55e02943‑a58f‑4f31‑8207‑dc44a390bd03
title Role — Delete Residual Metadata

residual role


requirement(s)


F14.5.147 Role — Destroy
System Identifier b969e173‑ec5f‑4046‑95b5‑f8e903d1e77b
title Role — Destroy
Description Destroy the active role

• modified
MoReq2010
requirement(s)
for Records Systems

R2.4.16)
(M14.4.14)

Volume 1 and Deleted Event Function Definition Identifier are
Core Services types of events were pruned from the event history of
& Plug-in Modules the role on its destruction, under R2.4.20 and R7.5.6
Version 1.1
424
1
Information
F14.5.148 Role — Exported model
System Identifier 32673385‑e87a‑410c‑ad54‑0556ae1ed332
title Role — Exported
Description The role has been exported in full or as a

placeholder

modified

requirement(s)

R2.4.16)

R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
425
1
Information
model F14.5.149 Role — Inspect
System Identifier f5833cf6‑4d4a‑43f9‑bea8‑77f768ba4e72
title Role — Inspect
Description Browse to the role, or discover it by searching, and

inspect its metadata

modified

requirement(s)


metadata (see R2.4.16)

when the user examines the metadata of the role and
not when it is identified while browsing or included in
search results
F14.5.150 Role — Inspect ACl
System Identifier 5a336626‑eab8‑451e‑8e7c‑547b8933f5f4
title Role — Inspect ACl
Description Inspect the access control list of the role

modified

•

for Records Systems Additional event • Participating Role Identifier (M14.4.78)
metadata (see
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
426
1
Information
F14.5.151 Role — Inspect Event model
System Identifier bd6c020f‑9ef6‑4263‑880f‑99f28b75ac13
title Role — Inspect Event
Description Browse the event history of the role and inspect its
events

modified

requirement(s)


R2.4.16)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
427
1
Information
model F14.5.152 Role — Modify ACl
System Identifier 2803e039‑8e4c‑44a3‑9e50‑aebf5c2649e7
title Role — Modify ACl
Description Modify the access control list for the role


requirement(s)


R2.4.16) (M14.4.82)

to the role is modified simultaneously, an event
must be generated for each access control
entry that is added, removed or modified
• • The event metadata shows which new roles
MoReq2010 were granted to the participating user or
Modular Requirements access control entries
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
428
1
Information
F14.5.153 Role — Modify Metadata model
System Identifier 59c2b665‑aa89‑4e87‑8666‑3d294f35a9e8
title Role — Modify Metadata
Description Modify the metadata of the active role

In accordance with R4.5.3, the following metadata
may only be modified prior to the role being used:

requirement(s)


R2.4.16)
Usage notes • Any of the system metadata elements listed, and

any modifiable contextual metadata elements
belonging to the role, may be modified
F14.5.154 Role — Modify originated Date/time
•
System Identifier 4cd52e0d‑7972‑499a‑bc32‑d7c81540094c MoReq2010
title Role — Modify originated Date/time
Description Modify the Originated Date/Time of the active role Modular Requirements
for Records Systems

modified

requirement(s)

Additional event • Participating Role Identifier (M14.4.78) Volume 1

metadata (see Event Comment (M14.4.25)
R2.4.16)
•
Core Services
& Plug-in Modules
Version 1.1
429
1
Information
model F14.5.155 Role — Remove Function Definition
System Identifier d0df9562‑d560‑4374‑8ed8‑07e4c3572d2a
title Role — Remove Function Definition
Description Remove the function definition from the active role
Entity metadata • Function Definition Identifier (M14.4.33)

requirement(s)


metadata (see • Participating Function Definition Identifier
R2.4.16) (M14.4.72)
F14.5.156 Role — Report Function Definitions
System Identifier 00a53f17‑9866‑4f0f‑a387‑16b549249284
title Role — Report Function Definitions
Description Report the function definitions that belonged to the

role at a specified historical date and time

modified

requirement(s)
•
MoReq2010 Purpose • Access control
Modular Requirements Additional event • Participating Role Identifier (M14.4.78)

metadata (see Historical Date/Time (M14.4.40)
for Records Systems •
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
430
1
Information
F14.5.157 Service — Add Contextual Metadata model
System Identifier e2a1ab27‑0a63‑4abe‑a2c7‑a08c8027824c
title Service — Add Contextual Metadata

definitions to the service

modified specified

requirement(s)

Additional event • Participating Service Identifier (M14.4.79)

R2.4.16)

F14.5.158 Service — Inspect
System Identifier e9a0bfa5‑6292‑4ba2‑80c4‑eeab1a4c9a7f
title Service — Inspect •

MoReq2010
Description Browse to the service, or discover it by searching,
for Records Systems
modified

requirement(s)


metadata (see Volume 1
R2.4.16)

Core Services
when the user examines the metadata of the service & Plug-in Modules
Version 1.1
431
1
Information
model F14.5.159 Service — Inspect ACl
System Identifier ad683cd9‑9f6a‑45f7‑a00d‑a34550196b27
title Service — Inspect ACl
Description Inspect the access control list of the service

modified

requirement(s)


metadata (see
R2.4.16)
F14.5.160 Service — Inspect Event
System Identifier 40015ae8‑17d7‑4be4‑a381‑ae79066351ac
title Service — Inspect Event
Description Browse the event history of the service and inspect

its events

modified

requirement(s)
• Purpose • Access control

MoReq2010 • Event generation

Modular Requirements metadata (see • Participating Event Identifier (M14.4.71)
for Records Systems R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
432
1
Information
F14.5.161 Service — Modify ACl model
System Identifier 537292ac‑e4c4‑45c0‑8188‑5597ffa58997
title Service — Modify ACl
Description Modify the access control list for the service
Entity metadata • Access Control Entry (D14.3.1)

modified

requirement(s)


R2.4.16) (M14.4.82)

ging to the service is modified simultaneously,
modified
were granted to the participating user or •
group and which existing roles were rescinded MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
433
1
Information
model F14.5.162 Service — Modify Metadata
System Identifier d5be380f‑b172‑402a‑898b‑117d968c0ce3
title Service — Modify Metadata
Description Modify the metadata of the service

• Owner Information (M14.4.62)

requirement(s)


R2.4.16)

metadata elements belonging to the service
F14.5.163 Service — Report Compliance
System Identifier 8dbe7172‑8919‑4c42‑a989‑3d114a0812d4
title Service — Report Compliance

•
MoReq2010 Description Report the compliance status of the service

Modular Requirements Entity metadata No metadata elements are modified
for Records Systems modified

requirement(s)


metadata (see
R2.4.16)
Volume 1
Usage notes The report should list only those services, or service
Core Services bundles under R2.4.1, for which the user has a role
that includes this function
& Plug-in Modules
Version 1.1
434
1
Information
F14.5.164 template — Add Contextual Metadata model
System Identifier 9540ba23‑531f‑45cf‑9d9c‑99150890bd2f
title template — Add Contextual Metadata

definitions to the template

modified specified

requirement(s)

Additional event • Participating Template Identifier (M14.4.80)

R2.4.16)

•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
435
1
Information
model F14.5.165 template — Create
System Identifier 92634d40‑ac65‑4f87‑ae90‑fbe914dfe318
title template — Create
Description Create a template

• Title (M14.4.104)
template, the following metadata element may be
modified belonging to the template from which the
contextual metadata elements were applied (if it has
not already been set):

requirement(s)


R2.4.16)
• • Metadata Change Entry (D14.3.3)
MoReq2010
Usage notes • The template may be created with contextual

Modular Requirements metadata elements as well as the system
for Records Systems metadata elements listed
metadata
• Where the template’s inherited access controls
Volume 1
Core Services F14.5.174 Template — Modify ACL events
must be generated for each change made to
& Plug-in Modules the access control list
Version 1.1
436
1
Information
F14.5.166 template — Delete model
System Identifier 5643fb8d‑380b‑4b0a‑a30c‑e0f09d3c2b0e
title template — Delete
Description Delete the unused template
Entity metadata The unused template is deleted along with its


requirement(s)
F14.5.167 template — Delete Residual Event
System Identifier 5a95ef31‑8881‑424e‑adfa‑e6a4bfd3456e
title template — Delete Residual Event

residual template


requirement(s)

Additional event • Participating Template Identifier (M14.4.80) •

metadata (see • Deleted Event Function Definition Identifier MoReq2010
R2.4.16) (M14.4.14)
Usage notes This function always generates an event (see R2.4.14) for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
437
1
Information
model F14.5.168 template — Delete Residual Metadata
System Identifier aa439637‑6d4f‑43e0‑a63f‑90b96f6be54f
title template — Delete Residual Metadata

residual template


requirement(s)


F14.5.169 template — Destroy
System Identifier 37ff38c4‑e14e‑442c‑aca6‑1f1ad94ed41f
title template — Destroy
Description Destroy the active template

• modified
MoReq2010
requirement(s)
for Records Systems

R2.4.16)
(M14.4.14)

Volume 1 and Deleted Event Function Definition Identifier are
Core Services types of events were pruned from the event history
& Plug-in Modules of the template on its destruction, under R2.4.20 and
R7.5.6
Version 1.1
438
1
Information
F14.5.170 template — Exported model
System Identifier 376e669e‑9c7a‑455c‑bc2c‑a46f344ad6da
title template — Exported
Description The template has been exported in full or as a

placeholder

modified

requirement(s)

R2.4.16)

R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
439
1
Information
model F14.5.171 template — Inspect
System Identifier 1d699116‑21ca‑4318‑8b2c‑5a72851de157
title template — Inspect
Description Browse to the template, or discover it by


modified

requirement(s)


metadata (see R2.4.16)

when the user examines the metadata of the
template and not when it is identified while browsing
F14.5.172 template — Inspect ACl
System Identifier 9c75f837‑16aa‑4e1c‑b8d7‑705376cd800b
title template — Inspect ACl
Description Inspect the access control list of the template

modified

•

for Records Systems Additional event • Participating Template Identifier (M14.4.80)
metadata (see
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
440
1
Information
F14.5.173 template — Inspect Event model
System Identifier 142ba8e5‑1cdf‑4ca7‑a6d6‑2f8db1e4b08a
title template — Inspect Event
Description Browse the event history of the template and

inspect its events

modified

requirement(s)


R2.4.16)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
441
1
Information
model F14.5.174 template — Modify ACl
System Identifier f5b7c65a‑9b73‑4769‑969a‑fde91d197381
title template — Modify ACl
Description Modify the access control list for the template


requirement(s)


R2.4.16) (M14.4.82)

ging to the template is modified simulta-
modified
•
Volume 1
Core Services
& Plug-in Modules
Version 1.1
442
1
Information
F14.5.175 template — Modify Metadata model
System Identifier d49046d1‑984a‑4ff0‑b676‑8598c2577466
title template — Modify Metadata
Description Modify the metadata of the template


requirement(s)



metadata elements belonging to the template
F14.5.176 template — Modify originated Date/time
System Identifier acf69ef4‑7c80‑48de‑a11a‑896c09d58b05 •

MoReq2010
title template — Modify originated Date/time

template
for Records Systems

modified

requirement(s)

Additional event • Participating Template Identifier (M14.4.80) Volume 1

metadata (see Event Comment (M14.4.25)
R2.4.16)
•
Core Services
& Plug-in Modules
Version 1.1
443
1
Information
model F14.5.177 User — Add Contextual Metadata
System Identifier 2601f4d6‑79df‑4978‑b860‑b8e17b6520ce
title User — Add Contextual Metadata

definitions to the user

modified specified

requirement(s)

Additional event • Participating User Identifier (M14.4.81)

R2.4.16)

F14.5.178 User — Browse Records Due For Disposal
System Identifier 2c3722d2‑bc17‑4008‑9c60‑58d3d7d72f83
• title User — Browse Records Due For Disposal

MoReq2010
Description Access the records currently due for disposal by
review, transfer and destruction
Modular Requirements Entity type User (E14.2.16)
for Records Systems
modified

requirement(s)


Volume 1 metadata (see
R2.4.16)
Core Services Usage notes This function enables the user to browse the records
& Plug-in Modules currently due for disposal, to inspect any of these
records individually requires F14.5.131 Record —
Inspect
Version 1.1
444
1
Information
F14.5.179 User — Create model
System Identifier 2cde7448‑6c71‑4cff‑988a‑973e0701a824
title User — Create
Description Create a user

• Title (M14.4.104)

requirement(s)


R2.4.16)

• The user entity may be created with contex-
•
• If contextual metadata elements are added MoReq2010
metadata Modular Requirements
• For each metadata element set on crea- for Records Systems
• Where the user is created as a member of one
or more active groups then separate events for
F14.5.94 Group — Add User must be automa-
tically for each group the user is created in, on
creation
• Where the user’s inherited access controls are
modified on creation then separate F14.5.190 Volume 1
User — Modify ACL events must be generated
for each change made to the access control list Core Services
& Plug-in Modules
Version 1.1
445
1
Information
model F14.5.180 User — Delete
System Identifier 3be51e0b‑efd1‑49e9‑be3d‑419ef6a60660
title User — Delete
Description Delete the unused user
Entity metadata The unused user entity is deleted along with its

requirement(s)
F14.5.181 User — Delete Residual Event
System Identifier b2593eb6‑a542‑4d20‑8942‑3f2cd0218edf
title User — Delete Residual Event

residual user


requirement(s)

• Additional event • Participating User Identifier (M14.4.81)

R2.4.16) (M14.4.14)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
446
1
Information
F14.5.182 User — Delete Residual Metadata model
System Identifier a8783b53‑6557‑4885‑88c5‑3781508809cd
title User — Delete Residual Metadata

residual user


requirement(s)


F14.5.183 User — Destroy
System Identifier c33e48b3‑2bc6‑4851‑b2e7‑a40d602bfe1c
title User — Destroy
Description Destroy the active user

modified •
MoReq2010
requirement(s)
Purpose • Access control Modular Requirements

for Records Systems

R2.4.16)
(M14.4.14)

and Deleted Event Function Definition Identifier are Volume 1
types of events were pruned from the event history of Core Services
the user entity on its destruction, under R2.4.20 and & Plug-in Modules
R7.5.6
Version 1.1
447
1
Information
model F14.5.184 User — Detailed Report
System Identifier 428eb316‑5eb8‑4bda‑87d6‑fa4cc42331a3
title User — Detailed Report
Description Generate a detailed report based on a search

query

modified

requirement(s)


metadata (see • Search Query (M14.4.98)
R2.4.16)
• Total Entities (M14.4.105)
Usage notes • The detailed report is based on performing

a search which should be described by the
Search Query (see R10.4.22 and R10.4.24)
• The Total Entities should indicate the number
of entities included in the detailed report (see
R10.4.20 and R10.4.24), this number may be an
approximation
• Further supplementary information can be
placed into the Event Comment, as required
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
448
1
Information
F14.5.185 User — Export model
System Identifier 1262769d‑024d‑430f‑a917‑48b6a8e58d21
title User — Export
Description Export entities from the MCRS

modified

requirement(s)


R2.4.16)
• Export Commencing Timestamp (M14.4.28)
• Export Completed Timestamp (M14.4.29)
Usage notes • This function is performed whenever a user

conducts an export under R11.4.1
R11.4.4
• The Total Entities should indicate the total
number of entities that were exported, inclu-
ding entities that were exported in full, entities
that were exported as placeholders, and events
• This is not the event which is appended to the •
event history of the entity following its export MoReq2010
under R11.4.10, the event for this function
becomes part of the event history of the user
• See also F14.5.10, F14.5.29, F14.5.43, Modular Requirements
F14.5.52, F14.5.62, F14.5.76, F14.5.100, for Records Systems
F14.5.127, F14.5.148, F14.5.170, and
F14.5.186
Volume 1
Core Services
& Plug-in Modules
Version 1.1
449
1
Information
model F14.5.186 User — Exported
System Identifier 6da05d24‑5cbb‑4b2b‑9eb8‑45d75564c6ab
title User — Exported
Description The user has been exported in full or as a

placeholder

modified

requirement(s)

R2.4.16)

R11.4.4
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
450
1
Information
F14.5.187 User — Inspect model
System Identifier 246c3b2f‑66cb‑4585‑8b6f‑d38162ddaf99
title User — Inspect
Description Browse to the user, or discover it by searching, and

inspect its metadata

modified

requirement(s)


metadata (see
R2.4.16)

when the user examines the metadata of the user
F14.5.188 User — Inspect ACl
System Identifier 93dde507‑4b84‑4231‑9641‑8572f7b14c13
title User — Inspect ACl
Description Inspect the access control list of the user

modified
•
requirement(s)

for Records Systems
metadata (see
R2.4.16)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
451
1
Information
model F14.5.189 User — Inspect Event
System Identifier 8fe366ae‑0e72‑4042‑8a8a‑57e296927ee5
title User — Inspect Event
Description Browse the event history of the user and inspect

its events

modified

requirement(s)


R2.4.16)
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
452
1
Information
F14.5.190 User — Modify ACl model
System Identifier ef1deffd‑68a5‑4f19‑ac54‑ae3184d991d3
title User — Modify ACl
Description Modify the access control list for the user


requirement(s)


R2.4.16) (M14.4.82)

with the access control entry and should not be
confused with the Participating User Identifier
which indicates the user entity that has the
access control list
to the user is modified simultaneously, an
event must be generated for each access •
MoReq2010
modified
• The event metadata shows which new roles Modular Requirements
were granted to the participating user or for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
453
1
Information
model F14.5.191 User — Modify Metadata
System Identifier 53b191b5‑def2‑4ab3‑a110‑3959c52784dc
title User — Modify Metadata
Description Modify the metadata of the active user


requirement(s)


R2.4.16)

metadata elements belonging to the user entity
F14.5.192 User — Modify originated Date/time
System Identifier e3e88cce‑a4b1‑4860‑9868‑d9561f7417b3

• title User — Modify originated Date/time
MoReq2010
Description Modify the Originated Date/Time of the active user
Modular Requirements Entity type User (E14.2.16)

for Records Systems Entity metadata • Originated Date/Time (M14.4.61)
modified

requirement(s)


Volume 1 R2.4.16)
Core Services Usage notes The event for this function must always have an Event
& Plug-in Modules Comment (see R2.4.26)
Version 1.1
454
1
Information
F14.5.193 User — Report Authorisation model
System Identifier 25315f00‑835e‑4dfb‑9894‑80688eadbf2b
title User — Report Authorisation
Description Report the functions and the active roles

containing those functions that the user may
perform on a nominated entity

modified

requirement(s)


metadata (see And one of:
R2.4.16)
• Participating Aggregation Identifier
(M14.4.64)
• Participating Component Identifier
(M14.4.66)
• Participating Disposal Hold Identifier
(M14.4.67)
• Participating Disposal Schedule Identifier
(M14.4.68)
• Participating Entity Type Identifier (M14.4.70)
• Participating Function Definition Identifier
(M14.4.72)
• Participating Group Identifier (M14.4.73)
• Participating Metadata Element Definition
Identifier (M14.4.74) •
MoReq2010
• Participating Record Identifier (M14.4.77)
• Participating Role Identifier (M14.4.78)
• Participating Service Identifier (M14.4.79) Modular Requirements
for Records Systems
• Participating Template Identifier (M14.4.80)
Usage notes • This function is run against the user entity

nominated by the authorised user
• Therefore, the Participating User Identifier
refers to the nominated user entity
• A maximum of one other participating entity,
representing the nominated entity, should
be included in the event in addition to the
Participating User Identifier
Volume 1
• If no other participating entities are included in
the event, the nominated user’s own user entity
Core Services
is also the nominated entity
& Plug-in Modules
Version 1.1
455
1
Information
model F14.5.194 User — Report Group Membership
System Identifier 868fd38a‑74d4‑4534‑b3ec‑37b0ec4d65aa
title User — Report Group Membership
Description Report the active groups that a nominated user

belonged to at a specified historical date/time

modified

requirement(s)


metadata (see • Historical Date/Time (M14.4.40)
R2.4.16)
Usage notes • This function is run against the user entity

nominated by the authorised user
• Therefore, the Participating User Identifier
refers to the nominated user entity
F14.5.195 User — Search
System Identifier 34dcf951‑8608‑46b5‑808f‑84fe8c378e7a
title User — Search
Description Search for entities

•
MoReq2010 modified

requirement(s)
for Records Systems Purpose Event generation only

R2.4.16)
Usage notes • The Search Query should contain a description

of the search query performed (see R10.4.22)
• The Total Entities should indicate the number
Volume 1 of entities found by the search (see R10.4.20),
this number may be an approximation
Core Services • Further supplementary information can be
& Plug-in Modules placed into the Event Comment, as required
Version 1.1
456
1
Information
F14.5.196 User — Summary Report model
System Identifier aafece46‑99dd‑4e55‑b0b2‑81e5c0f1cf23
title User — Summary Report
Description Generate a summary report based on multiple

search queries

modified

requirement(s)


R2.4.16)
Usage notes • One Search Query should be added to the

event for each search included in the summary
report (see R10.4.25)
• The Total Entities should indicate the grand
total of all entities found across all search
queries (see R10.4.20 and R10.4.25), this
number may be an approximation
• Further supplementary information can be
placed into the Event Comment, as required
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
457
1
15
Acknowledgements
Developing a specification like MoReq2010® requires a large amount of

energy and commitment from a great many people: as records manage‑
ment is a technical and highly specialised field, contributors are usually
leading national and international experts in the discipline who volunteer
their time and effort on an unpaid basis.
The DLM Forum Foundation would like to thank everyone who contributed
to the development of MoReq2010®. 00 59
q
15.1 PRojECt tEAM i;.444
1
04
81
The MoReq2010® work programme took a year and was launched at the �,d.2 .a. Jl.1. "-
DLM Forum Foundation AGM in Madrid, May 2010: MoReq2010® was officially 4., 7'i,
J7 bd22
launched at the DLM Forum Foundation AGM in Budapest, May 2011. ' ., o l '
'
¿ o¡ ,4 6 134
15.1.1 Author '4 J O 38 04 • 24

•
Jon Garde, Journal IT 84
•
76
¿ "'
• 4 4 ' 7 b13 2
15.1.2 Editor
Richard Blake, The National Archives, United Kingdom
15.1.3 Programme management

Simon Cole, Automated Intelligence
Martin Waldron, Weathervane Consult
15.1.4 technical team

Hans Fredrik Berg, National Archives of Norway
•
Richard Jeffrey‑Cook, InForm Consult MoReq2010
15.1.5 Proofreaders
Mattias Hallin, European Commission
for Records Systems
Paul Sutcliffe, Consultant
15.2 ExPERtS REVIEw GRoUP

The DLM Forum Foundation acknowledges the generous assistance of the
European Commission in sponsoring the MoReq2010® Experts Review Group,
facilitating communications and coordinating meetings.
15.2.1 Chair
Volume 1
Malcolm Todd, The National Archives, United Kingdom
Core Services
15.2.2 European Commission & Plug-in Modules
Jef Schram, European Commission
Version 1.1
459
1
Acknowledgements
15.2.2 Experts
Francisco Barbedo, National Archives of Portugal
Diane Carlisle, ARMA International
Tracy Caughell, OpenText Corporation
Marie‑Anne Chabin, Archive 17
Elena Cortés Ruiz, National Archives of Spain
Andrew Ewing, Hewlett Packard Software
Maria Guercio, University of Urbino
Andrea Hänger, Bundesarchiv
Hans Hofman, National Archives of the Netherlands/International Council
on Archives
Toivo Jullinen, National Archives of Estonia
Julie McLeod, University of Northumbria
Bogdan‑Florin Popovici, National Archives of Romania
Barbara Reed, Recordkeeping Innovation
Jože Škofljanec, National Archives of Slovenia
15.3 CoNSUltEES
The following people contributed to the formal public review of the specifica-
tion during the MoReq2010® concept consultation (summer 2010) and the
MoReq2010® draft consultation (winter 2010/11).
Ray Auchterlounie, 2e2
Malcolm Beach, In‑Form Consult
Steve Bertone, OpenText Corporation
Kris Brown, HP
Stephen Clarke, ISO Committee TC46/SC11 Archives & Records
Management
• Lucas Colet, Public Research Centre Henri Tudor
MoReq2010
Julian Croker, Steria
Christian Dubourg, Ever‑Team Software
Modular Requirements Laznik Dušan, Mentis d.o.o.
for Records Systems
Marc Fresko, Inforesight
Rita Gago, Arquivo Municipal de Lisboa (Lisbon Municipal Archive)
Kirsten Glenwright, Objective Corporation
Mariella Guercio, University of Urbino
Paul Hampton, Alfresco
Katrina Hinton, Objective Corporation
Vincent Caper Hoolt, European Central Bank
Volume 1 Gabor Hornyak, MATRIX Auditing Evaluating and Certification
Core Services Gregor Joeris, SER Software Technology
& Plug-in Modules Ben Johnson, Objective Corporation
Ulrich Kampffmeyer, PROJECT CONSULT Unternehmensberatung GmbH
Version 1.1 Natasha Khramtsovsky, Electronic Office Systems LLP
460
1
Acknowledgements
Hanns Köhler‑Krüner, HKK Consulting
Robert Lentz, cBrain A/S
Marko Lukičić, Ericsson Nikola Tesla
Karl Mayrhofer, Fabasoft
Leo Merman, Celt Consultancy
Christoph Mueller, HTW Chur
Giovanni Michetti, Sapienza — Università di Roma
Tony Ogilvie, Automated Intelligence
Maria Palma, AedocDigital
Osmo Polonenn, Finnish MoReq® Working Group
Bogdan‑Florin Popovici, National Archives of Romania
Professor Roberta Raimondi, Bocconi School of Management Milan
Shaheen Ramdiane, OpenText Corporation
Susana B. Rodriguez, Ministry of Defence, Spain
John Seeley, IKM Solutions
Deirdre Sharp, Norfolk County Council, United Kingdom
María José Aldaz Sola, Archivistica.Net
Lucia Stefan, Archiva
Ricardo Vieira, INESC‑ID
Naina Visani, IKM Solutions
Chris Walker
Robert Whiter, Oracle
Anthony Woodward, Record Point Software
Sherry Xie, University of British Columbia
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
461
1
1212 1911 2989 8400
1234 4675 7897 6822
3785 3849 0745 7905
2354 0946 3754 6734
5438 0638 6904 5724
0239 847S 4278 5476
,
- --�H -�7�'->J..Ml.'n
Part two
Plug-in Modules
1212 19li 2989 9400
1234 4675 79!17 6822
�78.5 3
' at9 0745 '1905
2354 094f 3754 6734
5438" 063Í 6904 5?24
0239 941S 12713 5476

, '1'1� ,4,1;;7� 7Rll7 ,;R,>,>
100
INTERFACE SERIES
101
Graphical User Interface (GUI)
101.1 MoDUlE INFoRMAtIoN

Module name Graphical User Interface (GUI)
Module version 1.0
Implements Module 0f9584e5‑552a‑4a79‑a8ea‑3c2801765255

Prerequisites MoReq2010® Core services
Co-requisites none
101.2 kEy CoNCEPtS

101.2.1 Main features of a graphical user interface
A graphical user interface or GUI is the most common way for users to
interact with modern computer technologies. A graphical user interface
may be provided on any information system that has a screen and one or
more input devices. Information is typically transmitted to a GUI through
input devices such as keyboards, mice, tablets, pens/styli, touch screens
and microphones that transmit voice commands. Feedback from a GUI is
primarily visual through a screen or display; however, some audio and other
supplementary feedback is sometimes provided.
The key features of most graphical user interfaces are:
• they allow users to run more than one application at a time and to follow
links and to switch between applications (e.g. a user reading an e‑mail
in an e‑mail client may click on a link that opens in a web browser);
• they allow users to see more than one item or piece of information at
a time and to see some information as text and other information as •
MoReq2.010
images, icons or graphics;
• they allow users to manipulate and perform actions on items by clic‑
king with a mouse, tapping with a finger or typing on a keyboard; Modular Requirements
• they allow users to navigate visually between items by providing for Records Systems
multiple item displays such as list views and tree views;
• they allow users to see the relationships between items;
• they allow users to select multiple items at once by lassoing them (or
a similar technique) and then perform the same actions on more than
one item simultaneously;
• they allow users to manipulate items by dragging and dropping them
on to other items;
• they allow users to switch between views, or windows, of the same Volume 1
dataset;
• they allow users to magnify entities, or see an alternative view, by
Core Services
zooming in and out; & Plug-in Modules
• they are able to display information sorted in different ways and to
indicate the status of items with various visual effects; Version 1.1
467
1
101 P A R T I I – P l U G - I N M o D U l E S
Graphical User
Interface (GUI) • they are able to overlay different information from parts of a system in
a single coherent display;
• they can provide pop‑up notifications and dialogue boxes for the user
to interact with;
• they can simulate a form for the entry of metadata about an item;
• they can guide the user through complex processes through techni‑
ques such as a wizard;
• they can limit the operations that a user can choose from through
pick‑lists and menus;
• they can disable functions that are not appropriate for a particular
item;
• they can display search results, reports and the content of items
directly to the screen or display; and
• they can be tailored and arranged to suit individual users and parti‑
cular roles.
This module contains requirements for MCRS solutions that implement a
GUI.
101.2.2 Graphical user interfaces and records systems

Where a records system has a GUI, all of the disparate functionality of the
records system is brought together into that interface so that users may
interact with it. The processes themselves may be running in different
places, both locally and on remote servers and web servers. The different
parts of the records system may connect with one another over local area
networks, wide area networks, private intranets, or the public Internet. The
GUI, however, should seek to give a unified and coherent view of the records
system that hides the technical complexity of its underlying infrastructure.
For most records systems, the GUI will either belong to a native application
or to a web application hosted by a web browser. Where the GUI belongs to a
native application, it should seek, as much as possible, to follow the conven‑
tions and user interface guidelines for the operating system on which the
• application is being hosted. Where the GUI is part of a web application, it
M0Re92010
should seek, as much as possible, to follow the conventions and accessi‑
bility guidelines of the World Wide Web Consortium (W3C). In both cases, the
Modular Requirements GUI should seek to be easy to use and consistent with users’ expectations,
for Records Systems so as to afford users the greatest chance of being able to interact with, and
operate, the records system with minimal previous experience, training and
ergonomic effort.
In particular, an MCRS must use its graphical user interface to:
• allow users to interact with the contents of the records system by
presenting entities grouped into logical structures such as list views,
tree views and network maps;
• represent the status of entities through graphical means;
Volume 1 • by default, show only active entities but allow switching of the display
to show residual entities as well;
Core Services • facilitate browsing as defined by MoReq2010® (e.g. being able to easily
& Plug-in Modules access and inspect children from a parent aggregation);
• allow users to inspect and, where they have authorisation, modify the
Version 1.1 metadata of entities (e.g. through a form view);
468
1
P A R T I I – P l U G - I N M o D U l E S 101
Graphical User
• facilitate the completion of tasks such as the population of metadata Interface (GUI)
elements, by providing aids such as default values, selection lists,
spellcheckers, look‑up panels;
• allow users to easily create entities in the records system (e.g. possibly
by initiating the creation a record by dragging and dropping a docu‑
ment or link from the operating system or another application);
• enable users to build search queries and specify search criteria visually
rather than through a scripted search expression language;
• display the results of searches in a way that allows users to directly
interact with and inspect the entities returned;
• allow graphical interaction with search results such as reordering
columns etc.;
• possibly allow users to directly view the content of records through the
graphical user interface, or to access and download record content;
• show users only those operations that they are authorised to perform
on an entity before they attempt them;
• provide role‑specific views for users with those responsibilities (e.g.
to allow records managers to monitor and carry out the disposal
process);
• enable users to perform operations on entities easily with the fewest
possible number of steps by providing aids such as contextual and
application menus, toolbars, keyboard key combinations;
• provide feedback when operations take longer than a second or so
(e.g. through the use of busy icons and progress bars);
• provide visual and, possibly, auditory feedback on the results of all
operations, clearly indicating where they are successful and where
they have failed;
• where operations fail, provide meaningful messages to the user that
indicate what has failed, preferably why it failed, and what to do about it;
• cater for users with special needs by adhering to accessibility guide‑
lines (e.g. by supporting screen magnification, presenting the same
information in different ways, such as by using a colour, using under‑
line for hyperlinks);
•
• allow users to personalise their own experience of the GUI (e.g. by MoReq2010
selecting the default colours, fonts and sizes, and arranging elements
of the GUI in different places); and
• provide immediately available assistance to users such as
for Records Systems
context‑sensitive help, online user guides, frequently asked questions
(FAQ), wizards, tutorials, access to help desk support.
An MCRS may also use its graphical user interface to facilitate collaborative
working by:
• showing which users are currently accessing the records system;
• facilitating communication, chats, screen‑sharing and electronic
whiteboards, or their equivalent, between users who are using the
records system simultaneously;
• allowing users to post messages to individuals or groups of other Volume 1
users;
Core Services
• allowing users to place additional notes against entities in the records
system for the benefit of other users; & Plug-in Modules
• promoting the use of and, possibly, hosting blogs and online
discussions; Version 1.1
469
1
Graphical User
Interface (GUI) • allowing users to create task lists that refer to entities in the records
system;
• extending the use of task lists to whole groups rather than just indivi‑
dual users;
• promoting the use of and, possibly, hosting individual and group calen‑
dars that show upcoming events and tasks;
• allowing users to refer important tasks, such as complex disposal
review decisions to other, more expert users; and
• the provision of dashboards to monitor records system usage and
status, such as a summary of records due and overdue for disposal
action.
An MCRS must not allow its graphical user interface to:
• give users access to the records system if they are not authorised to
access it;
• show users that entities exist that they are not authorised to inspect;
• allow users to perform operations that they are not authorised to
perform.
101.2.3 organisational considerations

An organisation using an MCRS with a graphical user interface may wish to
brand it in particular ways, for example, so that it:
• displays a corporate logo;
• uses corporate colour schemes and fonts;
• uses corporate defaults;
• incorporates the organisation’s own terms and conditions for access
and use;
• refers support enquirys to a corporate help desk rather than
• supplier‑level support;
M0Re92010
• has customised user guides, FAQ, tutorials and wizards; and
• has a default layout and presentation decided at organisational level.
The organisation must also be aware of the security implications of having
for Records Systems
some or part of the records system installed on its users’ personal computers
and workstations by asking, for example, the following questions.
• Does it cache records, record content or other elements locally?
• Is the cache encrypted?
• How easy is it to bypass or hijack its security controls?
• How secure is the communication between the client application and
other server‑based parts of the records system?
Volume 1
• Is this communication encrypted?
Core Services • Is the records system remotely accessible, for example, through
& Plug-in Modules third‑party or computers in Internet cafés?
These considerations may also be necessary for other types of user inter‑
Version 1.1 face, other than graphical user interfaces.
470
1
Graphical User
101.4 FUNCtIoNAl REqUIREMENtS Interface (GUI)
R101.4.1 In accordance with core services requirement R2.4.6, the MCRS must imple‑
ment a graphical user interface (GUI) that allows authorised users access to
the full functionality specified by the service or bundle of services.
The term ‘GUI’ describes any primarily visual interface that is controlled by a human
operator. GUIs may be contrasted with earlier command line interfaces where
systems are controlled by typing instructions or commands into a terminal.
To be certified as MoReq2010® compliant, the GUI must implement all of the
functionality specified by MoReq2010® for the service or bundle of services
covered.
R101.4.2 The MCRS must display entities in a consistent manner that enables users
to recognise them by entity type, to identify them by title or other metadata,
and to immediately see their status.
For example, a user should be able to immediately recognise a class from an
aggregation or a disposal schedule.
R101.4.3 The MCRS must show, by default, only active entities, but must allow users
to display both active and residual entities.
By default, residual entities should not be visible in the GUI. Where a user elects
to display both active and residual entities, their status should be clearly indi-
cated, under R101.4.2.
See also R2.4.22 and R10.4.17.
R101.4.4 The MCRS must allow authorised users to create new entities and add
them to the records system, specifying values for their metadata, including
contextual metadata.
For example, authorised users must be able to add new classes to the classifi-
cation service, new aggregations to the record service, new disposal schedules
to the disposal scheduling service, new disposal holds to the disposal holding
service, etc.
Depending on the nature of the MCRS, it may also allow users to create new
records on an ad hoc basis, by dragging and dropping documents and links from •
MoReq2010
the operating system or other applications. For other types of MCRS, the crea-
tion of records will be more structured.
Metadata values may be provided by the user, or the MCRS may generate values Modular Requirements
(e.g. the System Identifier), or provide default values, or the MCRS may be able for Records Systems
to automatically extract metadata values from the content of new records. In all
cases, all mandatory metadata values must be present before the new entity is
created in the MCRS.
R101.4.5 The MCRS must facilitate the inspection of entities by displaying their
metadata, including any contextual metadata, on request and allowing their
values to be modified by an authorised user in accordance with the other
requirements of MoReq2010®.
MoReq2010® does not specify how a user might request a view of an entity’s Volume 1
metadata through a GUI.
Core Services
R101.4.6 The MCRS must provide an authorised user creating an entity, under & Plug-in Modules
R101.4.4, or adding or modifying metadata, under R101.4.5, with automated
assistance in completing the task, as appropriate, and must allow the user
to search for and find entities to add to the metadata while modifying it. Version 1.1
471
1
Graphical User
Interface (GUI) Assistance may be provided by pop-up selection lists, auto-completion, spell-
checkers, formatting masks, context-sensitive help, etc. Searching and adding
entities is necessary for many different tasks, for example specifying the clas-
sification of an aggregation, or overriding the default disposal schedule of a
record.
R101.4.7 The MCRS must ensure that authorised users cannot modify read‑only
metadata values and cannot enter values for metadata contrary to the
datatype of the element.
The MCRS must enforce and support the entry of correct formatted metadata
including any constraints specified by the metadata element definition and its
specified datatype.
R101.4.8 In addition to metadata, under R101.4.5 the MCRS must also allow an
authorised user to view and, if authorised, modify the access control list
(or equivalent) for an entity.
The MoReq2010® model role service does not specify any particular way in
which the access to entities should be controlled and managed, provided it
meets the general principles of access control specified by MoReq2010® and is
able to be exported as a MoReq2010® compliant access control list.
R101.4.9 The MCRS must visually show the relationships between entities and allow
authorised users to browse these relationships.
For example, the MCRS must allow a user to inspect an aggregation, browse to
and inspect its classification, browse to and inspect its event history, browse to
and inspect its child records, browse to and inspect their disposal schedules,
browse to and inspect their components, etc.
MoReq2010® does not specify how relationships between entities in a GUI
should be shown, or the type of view required.
R101.4.10 The MCRS must guide the user by showing what operations are available to
• perform on an entity and allowing the user to choose from the operations
MoRe.92.010
available.
The GUI must adapt its display responsively to the authorisation available to
the current user. It must not show the same palette of operations available to
for Records Systems all users without providing some visual guidance as to which subset of opera-
tions is available to the current user.
For example, a context menu contains a full list of operations that can be
performed on an entity of a particular type. If the current user does not have
the relevant access controls to perform one of these operations for the selected
entity, that option should be greyed out or removed from the menu. It should
not be necessary for a user to initiate an operation before being informed that
it is not available because the user does not have sufficient access control.
Volume 1
R101.4.11 The MCRS must make the search function available to users from any
Core Services view or screen, with the exception of configuration screens and modal
& Plug-in Modules dialogues.
The user should not have to navigate to a special screen or view in order to
Version 1.1 conduct a search.
472
1
Graphical User
R101.4.12 The MCRS must allow users to graphically construct search queries and Interface (GUI)
complex search criteria, by selecting search terms and looking up entities,
as required.
Users of records systems with a GUI should not be required to enter search
scripts using the keyboard or to use a search expression language.
For example, to build the search criterion ‘Originated Date/Time is earlier
than 1 April 2010’, the GUI might allow a user to choose the metadata element
definition ‘Originated Date/Time’ from a list, select the search term ‘is earlier
than’ from another context sensitive control, and then enter ‘1 April 2010’ by
finding and picking it from a pop-up calendar.
R101.4.13 The MCRS must allow users to graphically configure search results,
including the metadata elements to be displayed, in what order they are to
be displayed, and how the results are to be sorted.
See also R10.4.18. Graphically configuring search results may include drag-
ging and dropping columns to reorder them or clicking on column headings
to sort by that metadata element. The GUI should also graphically support
pagination (or the equivalent) of search results under R10.4.19.
R101.4.14 The MCRS must allow authorised users to save sets of search results into
different document formats and potentially capture them as records.
The documentary form of search results should be similar to a detailed report,
under R10.4.24: for example, saving the results to a CSV datafile or a PDF
datafile. The MCRS may also be able to directly capture the search results as
a record, but this level of functionality is not included in the MoReq2010® core
services.
R101.4.15 The MCRS must allow authorised users to inspect and perform operations
on entities directly from search results.
When the GUI displays the results of a search, the entities shown in the list
must have the same level of functionality as they do in other parts of the inter-
face. In other words, the user should be able to inspect their metadata, browse
them, perform operations, etc., all without having to switch out of the search
•
results to a different view (see also R101.4.17). MoReq2.010
R101.4.16 The MCRS must allow users to make shortcuts to entities that can be
shared with other users. Modular Requirements
for Records Systems
A shortcut is an external reference to an entity in the MCRS that can be used to
initiate opening the GUI at a particular view and displaying the entity referred
to by the shortcut.
An example of a shortcut is a URI hyperlink. Users should be able to save
shortcuts to their local environment and share them with other GUI users, for
example by sending them in e-mails.
R101.4.17 The MCRS must allow a user to select a set of entities of the same type
both from the display generally, and from search results, under R101.4.13,
so as to collectively: Volume 1
• reclassify them with the same class, under R6.5.4 or R6.5.12; Core Services
• move them to the same parent, under R6.5.8 or R6.5.13; & Plug-in Modules
• change their disposal schedule to the same disposal schedule, under
R6.5.15; Version 1.1
473
1
Graphical User
Interface (GUI) • carry out a review of them, under R8.4.17, cancel their transfer or
destruction, under R8.4.18, or confirm their transfer or destruction,
under R8.4.19 and R8.4.20;
• associate them with the same disposal hold, under R9.4.3;
• export them, under R11.4.3 and R101.4.19; or
• create a single shortcut to a set of multiple entities rather than to an
individual entity, under R101.4.16.
MoReq2010® does not specify how multiple entities should be selected from
search results.
R101.4.18 The MCRS must provide a specialised interface for authorised users to
engage with and complete the disposal process described in 8. Disposal
scheduling service.
In particular, the interface must allow users to browse and inspect all active
records that are due for disposal, without having to conduct a search query,
under R8.4.16, including allowing them to be grouped in various ways as
described. The interface must also facilitate the various disposal actions
described in R8.4.17, R8.4.18, R8.4.19 and R8.4.20, especially allowing them
to be carried out across nominated groupings of records.
Desirable behaviour for this interface, which is not required for compliance
with MoReq2010®, includes:
• being able to plan ahead and anticipate records coming due for disposal
by calendar day, week and month;
• collect, display and chart graphically statistics on disposal action through-
put and average time taken to carry out various disposal actions; and
• manage disposal holds, including which records are currently being held
and determine how long overdue for destruction they are.
R101.4.19 The MCRS must provide a specialised interface for authorised users to
perform the export process described in 11. Export Service.
In particular, the interface should facilitate the following:
• enable a user to put together a list of entities for exporting, under R11.4.3,
possibly by selecting them and moving them to a list, under R101.4.17;
• • enable a user to select options for exporting, such as R11.4.2;
M0Re92010 • enable the user to initiate the export, to monitor its progress and to pause
and resume it, under R11.4.7; and
Modular Requirements • give the user immediate feedback on any errors encountered and the
success or failure of the export.
for Records Systems
R101.4.20 The MCRS must provide feedback to users that have initiated lengthy oper‑
ations and make provision for users to interrupt and cancel lengthy opera‑
tions before they have completed.
Specifically, the interface must provide the following:
• provide feedback to the user that the command has been received in
under a second, preferably around 0.1 second, to make the user feel that
the interface is responsive;
• provide feedback that the application is processing the command if it has
Volume 1 not been completed in less than 2 seconds, such as a spinning ball or
hourglass cursor; and
Core Services
• show a progress indicator and allow the user to cancel the command if it
& Plug-in Modules has not been completed in less than 10 seconds.
An example of an operation that might be lengthy and require these measures
Version 1.1 is when the user initiates a search.
474
1
Graphical User
R101.4.21 Where operations are not successful, the MCRS must provide useful error Interface (GUI)
messages that explain to the user the nature of the error, what happened
and how to proceed.
The MCRS must not allow user-initiated operations to fail without informing the
user. Similarly, error messages must be worded so as to be clearly understood
by users with little or no technical background and they must indicate to the
user what to do about the error so that the user can carry on in confidence.
Note that messages that are purely informational or that are warnings but
not errors should be clearly differentiated from error messages so as not to
inadvertently alarm users.
Error messages must be provided in a GUI in addition to logging failed opera-
tions, under R2.4.8, and are not a substitute for this requirement.
R101.4.22 The MCRS must provide easily accessible help from its screens and views,
including from its modal dialogues, for users who:
• do not know how to navigate its graphical user interface;
• do not understand the consequence of a particular operation;
• do not know how to create entities;
• do not know how to modify metadata;
• do not know how to construct search queries and search criteria,
particularly complex ones;
• do not know where to find the controls for actions and operations;
• do not know what to do about system errors; and
• want to learn more about the system.
Help may be provided in many forms, including instructions, manuals, FAQ,
wizards and tutorials. The help must be relevant to the process the user is
performing. Further detail is provided in the non-functional requirement
N101.5.11.

•
N101.5.1 The type of graphical user interface used will depend on the operating environ- MoReq2010
ment and platform.
Further to the responses to N12.3.1 and N12.6.1, what types of GUI does Modular Requirements
the records system support and on which interfaces and operating systems for Records Systems
are they available?
N101.5.2 Good GUIs have an underlying rationale that provides consistency across the
interface. The user learns to expect the GUI to respond in certain ways. The
GUI may use icons consistently to represent different entity types and states.
The GUI will also make it easy to see the difference between active and inactive
entities, or functions that can be performed and those that cannot.
For each of the GUIs listed under N101.5.1, what is the design approach
taken by the GUI? Consider the answers to the following.
Volume 1
• How does it make use of graphical elements such as icons and
images? Core Services
• How does it maintain consistency across the interface? & Plug-in Modules
• How does it assist the user to perform functions?
Provide examples where necessary. Version 1.1
475
1
Graphical User
Interface (GUI) N101.5.3 Ergonomics is an important, albeit subjective, judgement of all GUIs. For
example, how many mouse clicks and movements does it take to perform a
commonly used function? The best GUIs are often described as user-friendly
and intuitive to use.
What is the average and the most number of user actions (e.g. mouse clicks
or finger touches) required to access any screen or dialogue in the records
system interface, or to complete any of the following MoReq2010® functions
from the default view or home screen of the application?
• Create a record in an aggregation
• Search for an entity by its entity type using a single search criterion
• Inspect the metadata of an entity in a set of search results
• Browse from the first record to the last record in an aggregation of
100 records
(The answer should outline the default view or home screen, indicate which
of the user actions are required to perform a typical function and describe a
function that takes an average number of user actions, as well as the func‑
tion which takes the most user actions.)
N101.5.4 A GUI may use common gestures appropriate to the interface to allow the user
to perform functions. For example, it may allow records to be captured by drag-
ging and dropping datafiles from the user’s desktop.
How does the GUI use common gestures, such as scrolling and zooming, in
appropriate ways to help make the records system more usable and useful?
N101.5.5 A GUI will often support user personalisation. Alternative GUI elements, such as
colours, layout, fonts and font sizes may also be available on different devices,
such as desktops, notebooks, tablets and smartphones. The user may wish to
set these personalisation options differently for each form factor. Personalisation
requires that these elements, once changed, are saved and stay with the particular
user from session to session and from device to device, as the user so selects.
• There are many ways in which users may personalise a GUI involving some or
MoRe.92.010 all of the following:
• inclusion in the interface of lists of recently used entities (see N101.5.8);
Modular Requirements • inclusion in the interface of a list of favourite entities (see N101.5.9);
for Records Systems
• ability to set display colours, fonts and font sizes;
• ability to rearrange screen elements, views, and columns;
• ability to set a personal default sort order for lists and views;
• ability to specify the view where the application will open or have the appli-
cation always open at the most recent view;
• keep track of the user’s location in the application using a breadcrumb
trail or equivalent;
• allow users to browse back to previous screens and views (see N101.5.8);
Volume 1
and
Core Services • provide the ability to create personal saved searches and saved report
& Plug-in Modules definitions (see R10.4.23 and R10.4.27).
In what ways can the GUI be personalised to suit individual users and can
Version 1.1 these settings be saved as a user’s personal default?
476
1
Graphical User
N101.5.6 Audio alerts and notifications may also be configurable. Interface (GUI)
Does the GUI make use of audio alerts and notifications and can audio
alerts, notifications, and volume settings be individually adjusted and
personalised under N101.5.5?
N101.5.7 It may be possible to navigate the GUI and perform functions using voice
commands only.
Does the GUI respond to voice commands and, if so, how comprehensive
is the coverage of voice commands compared to the functionality required
by MoReq2010®?
N101.5.8 Many GUIs store the places that a user visits and the entities that a user
accesses. This list then provides a means for users to return to the entities they
created, inspected or modified recently without having to search or browse to
find them.
Does the records system provide easy access to recently accessed enti‑
ties through the GUI so that the user can find them and access them later
without searching?
N101.5.9 Some GUIs allow users to add entities to a list of favourites. This allows users to
find and access these favourite entities more easily without having to browse or
search to find them. This is a potentially important feature because users may
often need to have access to only a small number of aggregations to do most of
their daily work capturing, declaring and referring to records. Many users will
wish to keep these aggregations close at hand, rather than constantly search
for them. Another good use of the favourites list is to keep saved searches and
reports that are regularly performed by the user (see R10.4.23 and R10.4.27).
Does the records system allow users to keep a list of favourite entities and
access them easily through the GUI?
N101.5.10 It is important that informational notifications and error messages to users be

intelligible, informative and friendly. Each notification, message or dialogue
should also indicate the actions available to users and, where possible, suggest
what to do next.
•
How does the GUI handle user notification, error conditions and failed MoReq2.010
functions and are the messages to users helpful in suggesting a remedy
or course of action?
N101.5.11 The degree of help and assistance provided by the GUI under R101.4.22 is for Records Systems
extremely important. Wherever possible, help should be context-sensitive.
Help is not necessarily restricted to text-based information: it may contain
images and diagrams, embedded videos, online tutorials, and other e-learning
techniques.
Further to R101.4.22, what types of online help are available through the
GUI, and in different parts of the GUI, and how is this useful in assisting the
users to perform functions and learn about the records system?
Volume 1
Core Services
& Plug-in Modules
Version 1.1
477
1
Graphical User
Interface (GUI) 101.6 GloSSARy
Configuration screen (noun) A ‘settings’ screen or view intended

primarily to help configure the MCRS, but not
used in day‑to‑day operations. This might include
options that users do not regularly encounter.
See also screen.
Dialogue (noun) See modal dialogue.
Display (verb) To show to a user of a GUI, especially by

presenting information on a screen. A GUI may
display various entities as text, images or icons,
or a combination of any of these. Relationships
between entities may be displayed using graphical
elements such as lines and arrows, or they may be
evident by their arrangement and proximity.
Error message (noun) A graphical indicator to a user that a

particular function or operation has been
unsuccessful, typically a function or operation
that has been initiated by the user. There are
many different ways to provide an error message
to the user of a GUI, including a modal dialogue.
Feedback (noun) See visual feedback.
Graphical (adjective) Primarily visually, using the natural

attributes and advantages of a graphical user
interface.
Graphical user (noun) An interface to an information system,

interface usually abbreviated to GUI that presents entities
and their relationships as images, icons and
visual indicators as well as using text. A GUI
may present information in different windows
or screens. Users are able to manipulate the
various objects that are displayed in the GUI using
• a variety of input methods including keyboards,
M0Re92010
mice and other pointing devices, as well as
through touch and gestures. A GUI typically
allows users to select an entity, or entities, and
perform functions on it.
for Records Systems
GUI (acronym) A graphical user interface.
Home screen (noun) The landing page or standard view of

the MCRS that a non‑specialised user sees by
default. From the home screen, a user might
expect to immediately browse, search and
inspect the entities in the MCRS. Depending
on the purpose of the MCRS, the user may also
expect to create records and access the content
of records from this view.
Volume 1 See also screen.
Core Services Modal dialogue (noun) A notification, usually in the form of a

& Plug-in Modules pop‑up window, that must be acknowledged
or dismissed or for which some action must be
taken before the user can continue using the GUI.
Version 1.1
478
1
Graphical User
Interface (GUI)
Navigate (verb) To change screens or views, browse the

relationships between entities, inspect entities,
and change the entity that is the focus of the GUI
by direct manipulation of screen objects.
Personalisation (concept) Changing the character and experience

of a standard user interface and customising it
to the user’s personal taste. Many applications
provide options for rearranging a screen in a GUI
to reflect personal preference, for example by
changing the size, colour, position and fonts used
by screen objects. Where the user invests time and
effort in personalisation, it is important that the
MCRS should ‘remember’ these changes so that
they can be reused in the next session.
Screen (noun) A screen, a view, a window or an interface,

depending on the nature of the GUI. Each GUI
application is typically made up of several
different screens with different functions. In the
functional and non-functional requirements at
least four different types of screen or interface are
envisaged:
• configuration screen,
• home screen,
• specialised disposal interface, and
• specialised export interface.
It should be noted that these are design
assumptions based on grouping the different types
of functionality the GUI should support. They are
not intended to place unnecessary restrictions
on the GUI designer nor on the MCRS supplier,
provided the application does, in some way,
coherently facilitate these different aspects to
managing and using a records system.
Shortcut (noun) A URI hyperlink or other external reference MoReq2010

•
to an entity or entities in an MCRS that can be
shared with other users. For example, a user
may send an e‑mail to another user, containing
a shortcut to a record, instead of sending the
content of the record as an attachment. When for Records Systems
initiated, a shortcut accesses the MCRS and allows
the user to immediately discover the entity.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
479
1
Graphical User
Interface (GUI)
Specialised disposal (noun) An interface that facilitates the disposal

interface process. Typically, records managers need to
engage with this process to do the following
activities on a regular basis:
• anticipate, monitor and manage the records
coming due for disposal;
• conduct reviews and enter review decisions;
• ensure transfers are completed successfully
and confirmed;
• execute and confirm the destruction of
record content where manual confirmation
is required;
• close aggregations where appropriate; and
• respond to alerts.
There are many other peripheral activities that
could also be included in this specialised activity,
such as raising and lifting disposal holds,
managing disposal schedules, etc.
See also screen.
Specialised export (noun) An interface that facilitates the export

interface process. Typically, authorised users will need to
do the following:
• select records and other entities for export,
possibly based on previous exports or on
whether entities have been updated since
they were last exported;
• provide an export comment explaining the
export and, possibly, a name for the export
datafile and other details;
• determine where to export the datafile to,
this could be a network storage location,
another business system, across an
• encrypted Internet channel, or similar;
MoRe.92.010 • initiate and monitor the export;
• following successful completion, possibly
Modular Requirements continue to manage the export, and any
previous exports, in a secure location.
for Records Systems
The exact tasks and the nature of the interface will
depend on the individual MCRS solution.
See also screen.
View (noun) See screen.

(verb) Visually inspect.
See also inspect.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
480
1
Graphical User
Interface (GUI)
Visual feedback (noun) One of the attractions of a GUI is that

users feel that they are actually manipulating
real objects rather than simply two dimensional
graphical representations of logical entities. As
a result, it is important that the GUI is responsive
and visual feedback is essential to the user
experience. If users perform a function and
nothing appears to happen, even if it is only for
a few seconds, then the user experience can be
seriously degraded.
window (noun) See screen.
•
MoReq2.010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
481
1
102
Application Programming Interface (API)

Module name Application Programming Interface (API)
Module version 1.0
Implements Module 654633ec‑8b17‑4a3c‑a483‑436ee2bd506a

Prerequisites MoReq2010® Core Services
Co-requisites none
1
102.2 kEy CoNCEPtS

102.2.1 About application programming interfaces
An application programming interface or API is a published and standard‑
ised interface to an information system, such as a records system, that
allows other software to interact with it. There are many different types of
APIs for different programming languages, platforms and frameworks. An
example of an API is a set of one or more web service definitions.
The provision of an API obviates the need for a records system to directly
provide for any human user. The ‘user’ of the MCRS is effectively the external
system. A human user may interact with the MCRS indirectly through the
external system or the interaction may be entirely automated. For example,
a warehousing system may interface with a records system through an
API so as to automatically store invoices, delivery dockets and purchase
orders as they are raised or received. In this example, aggregations may
be automatically created whenever new customer accounts are entered in
the warehousing system and closed when customer accounts are deleted, •
classes and disposal schedules may be preconfigured and automatically MoReq2010
applied, and there may be little or no direct interaction with the records
system, except by or through the warehousing system.
This module contains requirements for an MCRS which implements an for Records Systems
API.
102.2.2 technical compliance

MoReq2010® defines an API set as consisting of a collection of ‘methods’
which can be evoked by an external application. For an MCRS, these
methods then implement the functionality described by the MoReq2010®
specification. It is important that an MCRS has a complete API set if it is to
be certified as compliant under this module.
Usually, each MoReq2010® function will correspond to a single method call Volume 1
in the API set and it should not be necessary through the API to call more
than one method to perform a single function defined by the specification.
Core Services
Sufficient API methods must be included in the API set to provide a full
& Plug-in Modules
suite of functionality for at least one service of MoReq2010®, or a bundle of
services (see R2.4.6). Version 1.1
483
1
Application
Programming Some records systems may provide only partial API sets which include only
Interface (API) some of the functionality specified by MoReq2010®. Where this occurs, the
requirements listed in this module may provide a useful guide to the expec‑
tations of MoReq2010® around the provision of an API, but a records system
that is partially reliant for a given service, or bundle of services, on another
type of interface in addition to its API, cannot be certified for compliance
under the provisions of this module.
In order to evaluate the quality and completeness of an API set, the supplier
must provide an accredited test centre with a manual to its API describing:
• how third‑party applications discover and connect to the API; and
• the methods of the API set including their pre‑ and post‑conditions.
In addition, suppliers wishing to have their API sets tested for compliance
must provide the test centre with a test harness or shell to enable testing
to take place. Accredited test centres are not expected to write their own
third‑party applications so as to facilitate testing of an API set.
102.2.3 API set considerations

API sets are written for different purposes. Sometimes suppliers intend them
to be general‑purpose interfaces and encourage third‑party applications
to be written which support them. On other occasions, they are intended
to provide tight integration with a single third‑party product, perhaps one
that does not have its own built‑in records management functionality. In the
latter case, the API is generally proprietary in nature and third‑party access
is not encouraged by suppliers.
In either case, the presence of interaction via an API must not exempt an
MCRS from its responsibility to ensure that:
• records are given an appropriate business context through proper
classification;
• event histories are populated with appropriate audit information about
which user performed a particular function;
• access controls are set and maintained, and unauthorised users are
prevented from accessing and manipulating the entities in the MCRS;
•
MoRe.92.010 • the disposal process described in 8. Disposal scheduling service is
properly managed and that considered disposal decisions are made at
appropriate times; and
Modular Requirements • records and other entities can be exported in full from the MCRS, as
for Records Systems specified in 11. Export service.
In particular, API sets can be problematic in attributing actions in the records
system to particular users. For this reason, although the external applica‑
tion is technically the user of the records system, care must be taken that
the external system provides information via the API related to who the real
user was that initiated the action that led to the API call being initiated.

Volume 1 R102.4.1 In accordance with core services requirement R2.4.6, the MCRS must
implement an application programming interface (API) containing a set of
Core Services methods that allow authorised users access to the full functionality speci‑
& Plug-in Modules fied by the service or bundle of services, under R2.4.1.
The term ‘API’ describes any interface that is accessed by a client application
Version 1.1 or another business system, rather than a human operator. A human operator
484
1
Application
may interface with the business system and indirectly manipulate entities in the Programming
MCRS, but there is no direct interaction with people. Interface (API)
To be certified as MoReq2010® compliant, the API must implement all of the
functionality specified by MoReq2010® for the service or bundle of services
covered.
R102.4.2 The MCRS must support multi‑user, asynchronous calls to the methods in
its API set.
One user, application or thread accessing the MCRS via a method call must not
block other users, applications or threads from simultaneously accessing the
MCRS and making method calls.
R102.4.3 The MCRS must ensure that each method call, under R102.4.1, is made by
an authenticated user and that all functions and events are attributed to
an individual user of the MCRS authorised to perform that function for the
entity on which it is performed.
It is not sufficient for all functions performed in an MCRS to be attributed to a
single user, that user being the external service that calls the API. This does not
provide sufficient context for effective accountability when constructing, or later
interpreting, event histories.
R102.4.4 The MCRS must ensure that every method call, under R102.4.1, returns an
error code that indicates the success or failure of the call.
The calling process, application or system should not have to make a second
method call to discover the outcome of a previous method call.
MoReq2010® does not specify what method calls or error codes should be used
by an API.
R102.4.5 The MCRS must provide a method that returns extended error information
for the error code returned under R102.4.4.
The extended error information should be the same, or equivalent, as that
retrieved under R2.4.8. Note that this does not replace the requirement for an •
MCRS to maintain an error log under R2.4.7. MoReq2.010
R102.4.6 The MCRS must provide a method or methods that return, for any given Modular Requirements
entity, the current user’s allowable operations in respect of that entity.
for Records Systems
MoReq2010® does not specify how such a method or methods must be imple-
mented. Finding out about allowable operations for any given entity enables the
current API user to discover what methods can be called for the entity without
specifically having to call each operation.

N102.5.1 The records system may support a number of different types of API and archi-
tectures. For example, web services, REST, programming languages (Java, C++, Volume 1
Python, etc.), Microsoft.NET framework, SOA, etc.
Core Services
What type(s) of API does the records system support?
& Plug-in Modules
N102.5.2 The records system may run on different platforms as listed under N12.6.1.
The records system API, however, may be made available on the same platforms Version 1.1
485
1
Application
Programming or it may be supported on separate platforms. For example, the records system
Interface (API) may run on a Linux server but provide a Windows API set.
Examples of different API platforms include, Google App Engine, Amazon EC2,
Microsoft Windows Azure, Microsoft Windows, Linux, Mac OS X, Google Android,
Apple iOS, etc.
What platforms does the records system provide API sets for?
N102.5.3 The API set may use a specific protocol, such as, HTML, SOAP, RPC, TCP/IP,
XML, etc.
What industry standard protocols does the API use?
N102.5.4 There is generally a learning curve associated with using an API set.
Documentation must be provided and a development environment acquired.
The skills necessary to develop to the API may be obtained from the supplier
or a third-party organisation providing API training, education and support.
Alternatively, the organisation may choose to have API-based applications
specifically developed for it by a third-party.
Further to N12.9.1 and N12.9.2, what skills, training and education are
required to become an API developer for the records system and where can
these be obtained from?
N102.5.5 It may not necessarily be possible for any developer to license and use the API
to freely develop new API-based applications — not even the organisation that
purchases the records system.
Is it possible for any developer to develop for the records system API or must
developers be curated in some way?
N102.5.6 The records system API set may have different versioning to the main product
versioning, or it may even be a different product set, and may be managed semi-
independently.
Separate to N12.14.1, what versioning is used by the records system API
• set?
M0Re92010
N102.5.7 Each version of the records system API may add new methods and deprecate
older methods. This must be managed to ensure that API applications are no
longer able to execute successfully.
for Records Systems
For each of the release types under N102.5.6, how are new method calls
introduced into the records system API set and old ones deprecated? How
are developers notified of these changes?
N102.5.8 An important aspect of any API set is backwards compatibility.

In relation to N102.5.6 and N102.5.7, can code written to interface with
one version of the API set run against previous versions, and under what
compatibility constraints?
Volume 1
N102.5.9 In addition to the support programme for users, API developers may be given
Core Services additional assistance and separate support provision by the supplier.
& Plug-in Modules In addition to N12.15.3, N12.15.4, N12.15.5, N12.15.6 and N12.15.7, how
is the API set supported and is there a separate provision for the support
Version 1.1 programme?
486
1
Application
N102.5.10 Use of the API set may require additional warranties and may be subject to Programming
additional terms and conditions. Interface (API)
What additional warranties under N12.16.1, additional service level agree‑
ments under N12.16.2, or additional terms and conditions under N12.16.3
apply to the records system API set?
102.6 GloSSARy
Allowable operation (noun) A method that can be called in respect

to a particular entity by the user. MoReq2010®
does not require that there be a direct one‑to‑one
mapping between a method in the API and a
function that may be performed on an entity
by an authorised user. For this reason, the
term ‘allowable operation’ is used as a broader
and more inclusive description of the methods
that may be invoked by a particular user, on a
particular entity, at a particular moment in time.
The reason for requiring that allowable operations
be discoverable is to enable the user of an API to
learn which methods may be called without having
to call each one.
API (acronym) Application programming interface.
Application (noun) A software interface that may be used

programming by an application. An API may be described as
interface a ‘computer‑computer interface’ in contrast to
a ‘human‑computer interface’. Each API has a
number of methods which an application may
call. The complete set of methods included in an
API is sometimes referred to as an ‘API set’. There
are many different technologies and protocols
that may be used to provide an API for an MCRS.
MoReq2010® does not require any particular
technology or protocol, provided the API includes
full coverage of the functionality of the service, or •
MoReq2010
bundle of services, to which it is applied.
Asynchronous (concept) The principle that a call to an API

will not block other calls from being received Modular Requirements
and processed simultaneously. Synchronous for Records Systems
use of an API forces applications to wait for
each call to complete before the next call can
be made. Asynchronous use of an API means
that applications cannot predict which of two
overlapping calls will complete first.
Call (verb) Invoke a method which sends input data to

an API which is then processed by the MCRS. Each
call to an API will typically return an error code
and may also return other output data.
See also method.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
487
1
Application
Programming
Interface (API)
Error code (noun) An indication of the success or failure of
a call to a method. In the event of failure or only
partial success, the error code may also be a
value that indicates the reason the call was not
successful. Following an unsuccessful call, and
the return of an error code, an API must provide
extended error information if requested.
Method (noun) A routine or subroutine in the API which can

be discovered programmatically and subsequently
invoked by a call. Each method called will, if
successful, execute an action, input or retrieve
data, or change some property or value within the
MCRS.
See also call.
Multi-user (concept) Support for multiple simultaneous users.

An MCRS should not allow access by only one user
at a time.
•
MoRe.92.010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
488
1
1212 1911. 2989 9400
1234 467!1 78!17 6822
�78.5 '3a49 0745 7905
23!1• 094f 3754 6734
5438' 063Í 6904 5724
0239 8475 4278 5476

, ,,.� Jl1':7Ji .,,.,n JiRsn
200
ClASSIFICATION SERIES
201
Hierarchical classification

Module name Hierarchical classification
Module version 1.0
Implements Module 5c772478‑0a49‑4391‑a1d4‑a5cd142a72d1

Co-requisites None
1
201.2 kEy CoNCEPtS

201.2.1 Hierarchical classification structure
Many organisations use hierarchical classification as a simple yet powerful
way of developing a classification scheme for their business. Hierarchical
structures are easy to navigate making the classes they contain easy to
browse to.
In a hierarchical classification scheme, classes are organised into a multi‑
tiered tree structure as shown in Figure 201a.
A typical three‑tiered classification scheme might be organised by business
function and then, within each function, by business activity and, finally, within
each activity by transaction. Although three levels are commonly used for
functional classification, MoReq2010® does not limit the maximum depth of
a hierarchical classification scheme: MoReq2010® also allows the number
of levels to vary across a single hierarchical classification structure.
As Figure 201a shows, a hierarchical classification scheme has one or
more top‑level classes representing the broadest, or most general, clas‑ •
sifications, such as organisational functions. A class, such as a top‑level MoReq2.010
class, may be the parent of several lower‑level child classes. Lower‑level
classes represent narrower and more specific classifications, such as the
particular business activities and individual transactions carried out within Modular Requirements
each organisational function. A child class must have only one parent class for Records Systems
and every class, except a top‑level class, must have a parent. In this way, the
hierarchical structure can fan out and grow to the required depth.
A parent class in a hierarchical classification scheme is not used for clas‑
sifying aggregations or records. Only a class with no child classes beneath
it, representing the most specific available classification may be associated
with a record or aggregation. Once a class has been used in this way, for
classifying aggregations or records, it can no longer be made a parent class
by adding child classes to it.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
491
1
Hierarchical
classification
MoReq2010' Top-level classes
/ "-.
Multi-tier Parent/child
(typícally ✓relationships '\..
function/
activity/
transaction) \
Classification series
/ Hierarchical
classification
A Class
A Parent class
Number Only classes that
of levels are not parent

/\ Top-level class
(depth) classes may be
"'-... Parent/child may vary used to classify
relationship aggregations and
records
Figure 201a — The main features of hierarchical classification are top‑level classes,
parent classes and child classes; the hierarchy can extend to any depth but most tradi‑
tional hierarchical classification schemes adopt a three‑level hierarchy
201.2.2 Inheritance
One of the primary advantages of hierarchical classification is that it allows
child classes to inherit the attributes of their parents. MoReq2010® takes
advantage of this, allowing the inheritance of a parent class’s:
• default disposal schedule, and
•
M0Re92010 • associated disposal holds.
If the MCRS implements the model role service, child classes also inherit:
Modular Requirements • access control lists.
for Records Systems If the MCRS implements the model metadata service, child classes inherit:
• aggregation templates, and
• record templates associated with the parent class (if any).
201.2.3 traditional practice with hierarchical classification

According to previous specifications, such as MoReq2®, classification was
always hierarchical and was always applied to root aggregations only. This
approach requires that every child aggregation and every record carry the
Volume 1 same classification as their root aggregation. This traditional approach is
shown in Figure 201b.
Core Services
The traditional approach implies that, throughout a record service, aggrega‑
& Plug-in Modules tions of records will always be homogenous or, in other words, every record
in a particular aggregation will always have been generated by the same
Version 1.1 business function, activity and transaction.
492
1
Hierarchical
As Figure 201b shows, MoReq2010® continues to support this approach for classification
those organisations that require it.
MoReq2D10'"
A, Class
A, Parent class
rcp-íevel class
......._ Parenr/chlld
relalionship
11 Aggreg.ll1on
e Record
Oefaull
"-t. classification
Figure 201b — Hierarchical classification when applied to a root aggregation is inherited

as the default classification for all descendants of that aggregation; this mirrors the tradi‑
tional approach of combined classification/aggregation hierarchies
Where hierarchical classification is applied only at the level of the root aggre‑
gation, the whole structure combining classes, aggregations and records
can be conceptualised as a single hierarchy. In this way, the structure
described in Figure 201b is logically identical to that illustrated in Figure 1i
(see 1.4.5 Classification and aggregation in the MoReq2010® core services)
and shows how MoReq2010® can be used for the hierarchical conjoining of
classification and aggregation, if desired.
•
201.2.4 Alternative uses of hierarchical classification MoReq2010
Hierarchical classification in MoReq2010® is not restricted, however, to

representing traditional classification/aggregation approaches. In common Modular Requirements
with other types of classification, hierarchical classes can be used to over‑ for Records Systems
ride the default classification inherited from the parent aggregation of a
child aggregation, or record.
This happens when a class is applied directly to a particular child aggrega‑
tion or record, thereby breaking the default chain of inheritance of the root
aggregation’s classification. This is illustrated in Figure 201c.
By allowing the overriding of the default classification of a child aggrega‑
tion or individual record, MoReq2010® supports heterogeneous aggrega‑
Volume 1
tions containing records with different classes, such as those generated as
a result of separate business transactions, activities or even functions. Core Services
This allows, for example, the creation of project aggregations, where all the & Plug-in Modules
records relating to a particular project undertaken by an organisation are
aggregated together, regardless of which transaction produces them. Version 1.1
493
1
Hierarchical
classification
MoReq2010'
,A Class
A Parent class
.1\ Top-lcvel class
, Parent/child
rclationship
liJ Aggregatlon
9
Record
/ Hierarchical
Dcfilult
classification
dasslflcatlon
� Overridden
� dassiflcatlon
Figure 201c — Hierarchical classification can also be used in non‑traditional ways; to

override default classification at any level by applying it to child aggregations or directly
to records
Taken together, Figures 201b and 201c demonstrate the utility of hierar‑
chical classification and show how it can be adopted and used within both
traditional and non‑traditional record services.
201.2.5 Hierarchical class entities

Class entities and their attributes are defined in 5. Classification service.
Classification services that use a hierarchical classification scheme imple‑
ment a special type of class entity called a ‘hierarchical class’. Hierarchical
class entities are considered to be the same in all respects as other class
entities except that they have additional system metadata and are constrained
by additional rules of behaviour to which other classes are not subject.
For example, hierarchical classes, other than top‑level classes, have parent
classes. This means that a hierarchical class entity will include its parent
• class identifier as part of its system metadata. Classes belonging to other
MoRe.92.010
types of classification scheme do not have parent class identifiers. The addi‑
tional rules of behaviour for hierarchical classes are defined by the func‑
Modular Requirements tional requirements contained in this module.
for Records Systems
201.2.6 Exporting hierarchical classification schemes
When classes are organised into a hierarchy, each class represents a
more specialised classification than its parent class. The parent class also
provides the broader context for the child class. The full context is only
provided by maintaining the relationships between the levels of hierarchy
stemming from the top‑level class. These relationships must be preserved
when hierarchical classes are exported.
The export rules described in 11. Export service must be extended when
Volume 1 applied to hierarchical classes. Specifically, hierarchical classes extend
the definitions of which entities are significant to other entities under
Core Services 11.2.9 Exporting significant entities and which entities are included enti‑
& Plug-in Modules ties under 11.2.10 Exporting included entities.
For hierarchical classes, the following entities are significant:
Version 1.1 • the hierarchical class’s disposal schedule;
494
1
Hierarchical
• any disposal holds associated with the hierarchical class; and classification
• the hierarchical class’s parent class, and any ancestor classes, up to
and including the top‑level class.
In addition, for hierarchical classes:
• the included entities of hierarchical classes are child classes.
These extended export rules mean that when a hierarchical class is exported
in full, its descendant classes must be exported with it in full. Equally, the
hierarchical class’s ancestor classes, from its parent up to the top‑level
class above it, must also be exported as placeholders to provide it with the
necessary context. This is shown in Figure 201d.
•
MoReg2010
A Class
A Parent class
/\ Top-level class
......_ Parent/child
relationship
� Exportas
�laceholder
a Export in full
Figure 201d — The descendant classes of hierarchical classes that are exported must be
exported in full, while the ancestor classes of hierarchical classes must be exported as
placeholders
•
MoReq2.010
These extended export rules apply also when an aggregation or record is
exported in full and it is classified with a hierarchical class. In accordance
with 11. Export service, the hierarchical class is a significant entity and will Modular Requirements
be exported along with the aggregation or record as a placeholder. However,
for Records Systems
exporting a single hierarchical class as a placeholder is not sufficient to
provide the full context for the classification of the aggregation or record.
It is necessary to export all levels of the hierarchy that support that hierar‑
chical class, from its parent up to the top‑level class.
Figure 201e gives an example of this: a child aggregation is exported
from the MCRS and its parent aggregation is exported as a placeholder.
As required by 11. Export service, the aggregation’s class must also be
exported as a placeholder, regardless of whether it is inherited or directly
applied to the aggregation being exported.
Volume 1
However, as Figure 201e shows, the class used to classify the aggregation
is a hierarchical class with its own parent class under a top‑level class. Core Services
These are all significant classes. Instead of simply exporting the aggrega‑
& Plug-in Modules
tion’s class, it is necessary, in this example, to export all of the levels of
classification, including the class, its parent class and the top‑level class,
as placeholders, to ensure the full context of the aggregation is provided. Version 1.1
495
1
Hierarchical
classification
MoReq2010°
' A Class
A Pi!rcnt ctass
�
/\ Top-level class
Hierarchica\ cl.iH
placcholdcrs
........_ Parent/chíld
relationship Aggregat,on
placeholder
- Aggrcgation
/
Classification
4it series
Record
/ Hierarchical
'-y Classifieation
classification
•
� Exportas '
�laceholder
A Export in full
Figure 201e — Placeholders must be exported for all hierarchical classes up to the
top‑level class that are ancestors of the class used to classify aggregations and records
that are being exported in full

R201.4.1 A classification service that implements hierarchical classes must not imple‑
ment any of the other MoReq2010® 200. Classification series modules.
Note that an MCRS may utilise more than one classification service, but each
separate classification service must contain entities belonging to only one clas-
sification entity subtype.
R201.4.2 The MCRS must ensure that in addition to the metadata listed under R5.4.2,
hierarchical classes (E201.7.1) are also created with the following system
• metadata:
M0Re92010
• Hierarchical Parent Class Identifier (M201.7.2).
Only top-level hierarchical classes will not have a Parent Class Identifier. Child
Modular Requirements classes may inherit their disposal schedule and templates from their parent
for Records Systems classes.
Hierarchical classification schemes should support any number of levels of
hierarchy and any number of child classes belonging to a single parent class.
R201.4.3 The MCRS must ensure that all hierarchical classes created under R5.4.2
and R201.4.2, are either:
• created with no parent class as a top‑level class, provided they are
Volume 1 associated with an active default disposal schedule; or
• created within an active parent class that has never been used for
Core Services classification.
& Plug-in Modules
Hierarchical classes that are used for classifying aggregations and records may
not become parent classes. The First Used Timestamp determines whether a
Version 1.1 class has been used for classification.
496
1
Hierarchical
A hierarchical class created within a parent class may inherit its parent’s Default classification
Disposal Schedule Identifier and templates. All top-level classes must have a
Default Disposal Schedule Identifier.
R201.4.4 Further to R5.4.4, the MCRS must allow a hierarchical class, except a
top‑level class, to inherit its default disposal schedule from its parent class,
instead of requiring an authorised user to provide it.
The metadata element, Default Disposal Schedule Identifier is not required for
hierarchical classes, apart from top-level classes with no parent class (see also
R201.4.3 and R201.4.5).
R201.4.5 For any active hierarchical class, including a top‑level class, the MCRS must
allow an authorised user to move it:
• to an active parent class that has never been used for classification so
that it retains its original disposal schedule;
• to an active parent class that has never been used for classification so
that it inherits the disposal schedule of its new parent; or
• so that it becomes a top‑level class while retaining its previous disposal
schedule and templates.
To retain the hierarchical class’s previous disposal schedule, the MCRS must
ensure that a Default Disposal Schedule Identifier is added to the metadata of
the class during the move operation.
To inherit the disposal schedule of its new parent, the MCRS must remove any
Default Disposal Schedule Identifier from the class during the move operation.
Note that changing the disposal schedule of a class will have a cascading effect
on all active records classified by that class, as described in R5.4.4.
R201.4.6 The MCRS must only allow a hierarchical class with no child classes to be
used for classifying aggregations or records.
A parent class, which has one or more child classes, may not be applied to an
•
aggregation or record. MoReq2010
Whenever a hierarchical class is first applied to any aggregation or record, its
First Used Timestamp (see R5.4.2) must be set by the MCRS and it may no
longer become a parent class under R201.4.3 or R201.4.5.
for Records Systems
R201.4.7 The MCRS must not allow a hierarchical class to be deleted under R5.4.5 if
it is a parent class with one or more child classes.
The children of the hierarchical class must first be deleted or moved before the
hierarchical class can be deleted.
R201.4.8 The MCRS must not allow a hierarchical class to be destroyed under R5.4.6 Volume 1
if it has one or more active child classes.
Core Services
An active hierarchical class cannot be the child or descendant of a residual
class. The child classes must either be destroyed first, or concurrently, with the & Plug-in Modules
hierarchical class.
497
1
Hierarchical
classification R201.4.9 Subject to R2.4.22 and further to R5.4.7, the MCRS must allow an author‑
ised user to browse and inspect hierarchical classes in at least the following
ways:
• browse from a parent class to its child classes and inspect their
metadata; and
• browse from a child class to its parent class and inspect its
metadata.
R201.4.10 Where the MCRS implements the model role service (see 4. Model role
/service)
Hierarchical
then, further to R4.5.11 and subject to R4.5.10, the MCRS must
classification
allow a child hierarchical class to inherit active roles that have been granted
to active users and groups from its parent class.
The specific rules of inheritance used by the model role service, listed in the
rationale to R4.5.11, should be extended as follows:
• child hierarchical classes inherit from their parent classes.
Where the MCRS does not implement the model role service, it must demon-
strate similar or equivalent functionality under 4.2.4 How to meet the alterna‑
tive (Type B) requirements.
R201.4.11 Where the MCRS implements the model metadata service (see 7. Model
metadata service) and a template has been associated with a hierarchical
class using the Template Class Identifier, under R7.5.14 or R7.5.15, the
template must be applied automatically, under R7.5.18, to any aggrega‑
tion or record created with that hierarchical class or with any of its child
classes or descendants.
An aggregation or record template may be associated with a top-level class, or
a parent class, and will then be automatically applied to all aggregations and
records classified by any descendant of that class.
Where the MCRS does not implement the model metadata service, it must
•
MoRe.92.010 demonstrate similar or equivalent functionality under 7.2.4 How to meet the
alternative (Type B) requirements.
for Records Systems
R201.4.12 The MCRS must allow an authorised user to group active records under
R8.4.16 and perform disposal related functions under R8.4.17, R8.4.18,
R8.4.19 and R8.4.20 for any hierarchical class.
Where the hierarchical class is a parent class, the function should apply to all
of the records that are classified by any of the descendants of the hierarchical
class.
F14.5.120, F14.5.124, F14.5.131, F14.5.177
Volume 1
R201.4.13 When an active disposal hold is associated with a hierarchical class, under
Core Services R9.4.3, the MCRS must, in addition to the other clauses of R9.4.4, prevent
& Plug-in Modules the destruction of any record that:
• has been classified with a hierarchical class that is a child or descen‑
Version 1.1 dant of a hierarchical class associated with the disposal schedule.
498
1
Hierarchical
The association of a disposal hold with a hierarchical class that is a top-level classification
class, or a parent class, should have the same effect as associating the disposal
hold individually with each child class or descendant of that class.
R201.4.14 The MCRS must allow an authorised user to search for and find aggrega‑
tions and/or records that are classified by any descendant of a nominated
hierarchical class.
This requirement extends R6.5.18 to allow a search by a nominated class to
find an aggregation or record where the nominated class is a hierarchical class
that is not the entity’s class but is the ancestor of the entity’s class.
R201.4.15 When hierarchical classes are exported in full under R11.4.3, then the
MCRS must also export their child and descendant classes in full, as
included entities.
See 11.2.10 Exporting included entities and 201.2.6 Exporting hierarchical
classification schemes for an explanation of included entities in export and
their relationship to hierarchical classification.
R201.4.16 When hierarchical classes are exported in full, or as placeholders, under

R11.4.3, then the MCRS must also export placeholders for their parent and
ancestor classes, as significant entities.
See 11.2.9 Exporting significant entities and 201.2.6 Exporting hierarchical
classification schemes for an explanation of significant entities in export and
their relationship to hierarchical classification.

N201.5.1 Hierarchical classification schemes may impose internal limitations on the
number of hierarchical classes or levels of hierarchy supported.
What are the technical limits in the classification service to each of the
following? MoReq2.010
•
• The number of hierarchical classes that can be managed

• The number of top‑level classes that can be added to the classifica‑
tion service
for Records Systems
• The number of child classes that can be added to a parent class
• The depth or number of levels of classes under a top‑level class
Volume 1
Core Services
& Plug-in Modules
Version 1.1
499
1
Hierarchical
classification 201.6 GloSSARy
Child class (noun) Any hierarchical class that is not a

top-level class.
See also child, hierarchical class, parent, parent/
child relationship, parent class and top-level
class.
Hierarchical class
(entity) A subtype of class that allows a
classification scheme to be arranged in a
hierarchical structure. Each class, except a
/ Hierarchical top-level class, has a parent class and may have
child classes.
classification See also class and hierarchical.
Multi-tiered (concept) Especially in relation to a hierarchical

classification scheme, a hierarchical structure
where each tier, or level, under a top-level class
represents a particular concept. For example,
in a typical three‑tiered classification scheme,
the top‑level classes might represent business
functions, the child classes of the top‑level
classes would then represent business activities,
while the grandchild classes of the top‑level
classes represent business transactions. This
arrangement of classes is also sometimes known
as a ‘functional classification scheme’.
See also level.
Parent class (noun) Any hierarchical class that contains child

classes. In MoReq2010®, a parent class cannot be
used to classify aggregations or records.
See also child, child class, hierarchical class,
parent and parent/child relationship.
top-level class (noun) A hierarchical class that is not a child of

• another hierarchical class. Each top‑level class is
M0Re92010 created directly under the classification service.
See also hierarchical class.
for Records Systems
201.7 INFoRMAtIoN MoDEl
E201.7.1 Hierarchical Class ................................................................501
M201.7.2 Hierarchical Parent Class Identifier .....................................502
F201.7.3 Hierarchical Class – Add Class .............................................503
F201.7.4 Hierarchical Class – Create ..................................................504
F201.7.5 Hierarchical Class – Remove Class ......................................505
Volume 1
Core Services
& Plug-in Modules
Version 1.1
500
1
Hierarchical
E201.7.1 Hierarchical Class classification
System Identifier 8e98092d‑e20b‑48ea‑b3d6‑ca75375590ee
title Hierarchical Class
Description Definition of a hierarchical class, as a subtype

of class used in hierarchically structured
classification schemes
Subtype of Class (E14.2.2)
Service Classification service
Additional system As for Class (E14.2.2) plus the following additional

metadata system metadata:
• Hierarchical Parent Class Identifier
(M201.7.2)
The following metadata element becomes optional,
except for top‑level classes, under R201.4.4:
(M14.4.11)
Additional functions As for Class (E14.2.2) plus the following additional

functions:
• Hierarchical Class — Add Class (F201.7.3)
• Hierarchical Class — Remove Class
(F201.7.5)
The following function replaces Class — Create
(F14.5.24):
• Hierarchical Class — Create (F201.7.4)
Usage notes • The new function Hierarchical Class — Create

(F201.7.4) replaces the function Class — Create
(F14.5.24) for hierarchical classes
• The Default Disposal Schedule Identifier
(M14.4.11) is inherited from the parent class
unless overridden and mandatory for top-level
classes
•
• A classification service for hierarchical classes MoReq2010
may not simultaneously support other types of
classes, under R201.4.1
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
501
1
Hierarchical
classification M201.7.2 Hierarchical Parent Class Identifier
System Identifier caa1ff78‑8cf9‑40ac‑9e2f‑6ca75b87637e
title Hierarchical Parent Class Identifier
Description The parent class for a hierarchical class
Entity type Hierarchical Class (E201.7.1)
Min occurs 0 (for top‑level classes)

1 (for child classes)
Classification
Max occurs series
0 (for top‑level classes)
/ Hierarchical 1 (for child classes)

classification
Modifiable? Yes (by moving the class)
Refers to type Hierarchical Class (E201.7.1)
Datatype UUID
•
MoRe.92.010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
502
1
Hierarchical
F201.7.3 Hierarchical Class — Add Class classification
System Identifier 9ccb3ff0‑b225‑42bc‑9edc‑e05ed74547a5
title Hierarchical Class — Add Class
Description Add a child class to the hierarchical class by

moving it from a top‑level class or its previous
parent

participating child class will be modified:
• Hierarchical Parent Class Identifier
(M201.7.2)

requirement(s)


(M14.4.75)
Usage notes • This function is always performed in

conjunction with F201.7.5 Hierarchical Class
— Remove Class
• Before a user can move a class, the user must
have the authority to perform this function
on its new parent, as well as the authority to
remove the class from its previous parent or
from being a top-level class
• To move a hierarchical class so that it becomes
a top-level class, the user must have the •
authority to perform this function for the MoReq2.010
classification service as a whole
• This function only applies to adding child
classes by moving them from elsewhere: Modular Requirements
it does not apply to adding child classes by for Records Systems
creating them in the hierarchical class (see
F201.4.4 Hierarchical Class — Create)
Volume 1
Core Services
& Plug-in Modules
Version 1.1
503
1
Hierarchical
classification F201.7.4 Hierarchical Class — Create
System Identifier a148a5ee‑58ab‑4b7b‑a925‑bb6f426b0d7a

title Hierarchical Class — Create
Description Create a hierarchical class
Entity metadata System Identifier (M14.4.100)
•
modified Created Timestamp (M14.4.9)
•
Classification series • Title (M14.4.104)
/ Hierarchical • Scope Notes (M14.4.97)
classification • Default Disposal Schedule Identifier
(M14.4.11)
• Hierarchical Parent Class Identifier (M201.7.2)

requirement(s)
metadata (see • Participating New Parent Identifier (M14.4.75)
Usage notes • The hierarchical class may be created as a
top-level class: in which case, the Hierarchical
Parent Class Identifier is omitted and the
•
M0Re92010 Default Disposal Schedule Identifier becomes
mandatory
• If the hierarchical class is created as a child
Modular Requirements class, the Hierarchical Parent Class Identifier is
for Records Systems mandatory and the Default Disposal Schedule
Identifier becomes optional
• The hierarchical class may be created with
contextual metadata elements as well as the
• If contextual metadata elements are added from
a template, the Applied Template Identifier must
be included in the event metadata
• For each metadata element set on creation,
except System Identifier and Created
Volume 1 added to the corresponding event
Core Services • Where the class’s inherited access controls are
modified on creation, separate F14.5.33 Class
& Plug-in Modules — Modify ACL events must be generated for
each change made to the access control list
Version 1.1
504
1
Hierarchical
F201.7.5 Hierarchical Class — Remove Class classification
System Identifier 2b0c7c88‑ee72‑4e83‑87dd‑ad9d98567789
title Hierarchical Class — Remove Class
Description Remove a child class from the hierarchical class

by moving it to a top‑level class or to another par‑
ent class
Entity metadata See related function F201.7.3 Hierarchical Class —

Add Class

requirement(s)
Usage notes • Before a user can move a child class out of

the hierarchical class, the user must have the
authority to perform this function, as well as
the authority to add a class to the new parent
or to make it a top-level class
• To move a top-level class into a parent class,
the user must have the authority to perform
this function for the classification service as a
whole
• This function is always performed in conjunc-
tion with F201.7.3 Hierarchical Class — Add
Class, which describes the metadata that is
modified and the event that is generated
•
MoReq2010
for Records Systems
Volume 1
Core Services
& Plug-in Modules
Version 1.1
505
1
1212 un 2989 8400
1234 46'7S 7897 6822
3785 3149 0745 7905
2354 Q94� 3154 6734
5438 0638 6904 5'1,24
0239 8475 4278 5416

1 7''4 .,_�,._ ">•<>� ISII?'>
300
COMPONENT SERIES
301
Electronic components

Module name Electronic components
Module version 1.0
Implements Module 13b6976c‑2409‑48ff‑a576‑a6f6662c5044

Co-requisites None
301.2 kEy CoNCEPtS

301.2.1 Features of an electronic component
As described in 6.2.9 Record components, records can have physical or
electronic components. The terms ‘physical’ and ‘electronic’ in each case
refer to the content of the component.
The term ‘electronic component’ refers to a component of a record with
content that:
• is entirely digital and contained in a series of binary digits or ‘bits’;
• is not tied to any physical object or medium, although it may require
particular hardware and/or specialised software in order to be
accessed or viewed;
• may be copied any number of times, where each copy will be indistin‑
guishable from the original and other copies;
• may be transmitted electronically, including in a series of datagrams
or packages that can be reassembled into an identical copy of the
•
original content; and MoReq2.010
• may be stored in a datafile on an electronic medium, such as a
magnetic drive.
A distinction should be drawn between the component, which is an entity
for Records Systems
in the MCRS, and the content referenced by the component, which can be
held in the records system’s own data store (if it has an internal data store),
but may equally be held externally in the system of origin or in a third‑party
repository. This distinction between component and content is shown in
Figure 301a.
Some records may have electronic content that is discontinuous and natu‑
rally divided into discrete datafiles or chunks. In an MCRS, these records
will be made up of several electronic components where each separate
component will be associated with a single contiguous item of electronic
content. The content of each component, belonging to the same record, may Volume 1
be stored in different data stores, as Figure 301a shows.
Core Services
& Plug-in Modules
Version 1.1
509
1
Electronic
components
Extemal
Records
dota
..... System
/ Hierarchical
lntemal
dota
classification sto,w
Component (entity)
Originating system D Content (electronic)
Figure 301a — While records and components are entities in the MCRS, the content of
electronic components may be stored, by design, in any of a number of different data
stores in different locations
301.2.2 Revisiting the principles of managed components

The principles common to all forms of component, including electronic
components, are detailed in 6.2.10 Principles of managing component
content. These principles include:
• Discreteness — the electronic component must have its own separa‑
tely identifiable content;
• Completeness — the electronic component, in combination with the
other components of the record, must comprise a whole atomic record
• which is not dependent for its evidential worth on external resources;
MoR:_92010
• Immutability — once created, the content of the electronic component
must not change over time, or be able to be erased, until it is destroyed
Modular Requirements by the MCRS; and
for Records Systems • Destructibility — the content of the electronic component must be able
to be deleted, either automatically or with confirmation, in response to
its destruction in the MCRS.
In addition to these general principles, all electronic components must
also be transportable so that they may be transferred from their originating
system to another receiving system for interoperability and long‑term pres‑
ervation. This principle of transportability is discussed next.
301.2.3 transporting electronic content

Volume 1
All electronic content is data that originates within a business applica‑
Core Services tion or system as a whole or partial representation of its internal state at
a particular moment in time. The information represented by an electronic
& Plug-in Modules
component must be transportable, as content, to allow another separate
application that implements the same processing rules as the system of
Version 1.1 origin, to read, interpret and process it correctly.
510
1
Electronic
Information that is locked into its system of origin cannot be managed as components
a record as it cannot be independently captured, preserved, duplicated,
secured, verified or accessed and it cannot survive the physical longevity or
technological obsolescence of its host.
Provided electronic content meets the criterion of transportability, shown
in Figure 301b, as well as the principles of discreteness, completeness,
immutability and destructibility previously described, it is suitable as content
for an electronic component of a record managed by an MCRS.
MoReq;2010'
-=... - -- Output Input

--=,
,.,,.¡
content content
Originating Receiving
system tronsmit system
Figure 301b — Electronic content must be transportable; the originating system must be
able to output it in a format that allows it to be transmitted to a receiving system that can
input and understand it (neither system need necessarily be an MCRS)
Although the MCRS must store the media type of the transportable form
of the electronic content in the metadata of the component, MoReq2010®
does not require that it be in any particular format. The transportable form
may be a commonly used document format, such as Rich Text Format, or a
standardised format like PDF/A, or a markup language such as XML. These
well‑known media are generally preferred for the long‑term preservation of
records with electronic components and may, therefore, be part of the oper‑
ational procedures of the organisation. However, MoReq2010® also allows
electronic components to have content that is in a proprietary document
format, or even compressed and/or encrypted.
•
It is also unnecessary for the originating system to keep the electronic MoReq2010
content of a component internally in its transportable format, provided the
transportable form of the content generated by the originating system on
demand (and, if requested, multiple times) is identical each time it is regen‑
erated (to meet the requirement of immutability).
for Records Systems
301.2.4 the function of the records system

An MCRS may fulfil many different functions in relation to the applications
and business systems that produce electronic content.
• The MCRS may have its own data store and may only allow records to
be created with electronic components where it receives the content of
those components in transportable form, and stores them internally.
• The MCRS may manage records in their originating system without Volume 1
requiring them to be generated, except when they are accessed or
eventually exported to another system. Core Services
• The MCRS may manage content generated by the originating applica‑
& Plug-in Modules
tion in an external third‑party repository that is also accessed by other
systems. Version 1.1
511
1
Electronic
components • The system of origin may itself be a dedicated MCRS, with built‑in
records management capabilities that allow it to manage its own
records, generating the transportable form as required and for
export.
One notable outcome of this flexibility within MoReq2010® is that for an
MCRS to manage records, it is not necessary for it to directly handle the
content of the components it manages. For example, apart from main‑
taining an external reference to the component content in the originating
system, the MCRS may never be directly involved in the process depicted in
Figure 301b.
The MCRS must be able to export its own entities as data but, when it
Classification
exports seriestheir content may be exported either as data
electronic components,
/ Hierarchical
included in the export XML, under R11.4.8, or the content may be exported
as an external URI reference that can subsequently be used to separately
classification
retrieve the content from its data store. For example, an MCRS may manage,
as records, web pages on a web server (or in a content management system)
for each separate component (or web resource) storing only a URI that then
gives the actual location of the datafile.
Note that URI syntax is flexible enough to equally indicate datafiles in an
operating system or web pages on a web server.
Most importantly, a records system does not need to be a general‑purpose
system to be compliant with MoReq2010®. It does not have to be integrated
with many different business systems or to manage many different content
formats. It may be a small records system with a dedicated purpose and still
be fully compliant with MoReq2010® provided it can successfully manage at
least one type of record containing at least one form of electronic content.
301.2.5 Examples of different approaches to managing electronic components

The following are all examples of compliant records systems that manage
electronic components differently. They are indicative of the diverse possi‑
bilities allowed by MoReq2010®.
None of the following examples support all possible combinations and
permutations of electronic component, yet they are all potentially compliant
with the specification.
•
MoRe.92.010
• An MCRS captures e‑mail messages from an e‑mail application as
records into its own internal data store — records may be made up of
one or several components representing the original e‑mail and its
Modular Requirements attachments (if any).
for Records Systems • An MCRS manages office documents as ‘in place’ records: their content
is held in an external document management system — records are
made up of only one component (the office document) with content in
one of a handful of well‑known document formats.
• An MCRS manages web pages on a web server as records where each
record can have a varying number of electronic components, including
HTML, CSS, JavaScript and images in different web formats — many
of the CSS and JavaScript datafiles are common resources shared by
different records and the MCRS uses a system of pointers to enable
the same content to be included in the logically discrete electronic
Volume 1 components of different records.
Core Services • An MCRS manages call centre records made up of two components:
firstly, an audio recording of a call that is captured into the records
& Plug-in Modules
system’s internal data store and, secondly, a snapshot of a customer
contact that is held externally in a dedicated customer relationship
Version 1.1 management system.
512
1
Electronic
• An MCRS manages financial transactions as records held externally components
in a dedicated finance system — records are always made up of three
components that each represents a row in (respectively) the invoice
database table, the purchase order database table and the supplier
database table.
The final scenario outlined is of a database record drawn from rows held
in different relational tables: a possible example of this is depicted in
Figure 301c.
I.._MoReq2010°
INVOIC(S TABLE
lnvokeNo. lnvoke lhote !Sunnll.rJD Order ID
05266 2011JAN02 / 5003452 P0017035

·-·
Cl.98,16
5001636 (99,99
.....
R15523 2011 ffB 15 1 P002477l
2011 FEB 21 SOOKSZ P00197S2 <636300

1
KSU-0234-L 2011 MAR 16 5002850 P00094S6 1 (1900,02
PUR04ASE ORDERS TABLE
OrdfflD Order Date SUwllerlD

••m Qu.intltv Estim.ite
P0009456 2010 OCT03 5002850 Sprockcts 1 only (1900,00
P0017035 2010 DEC 26 5003452 Widgeu 3 off

,....,.. 2011JAN16 ,.!9Y4&. .......... 000,��
..'
d"' �
P0024773 2011 FEB 14 5001636 Gadgets 1 only uoo,i>
SUPPUERS TABLE
Su....aMr ID l SunnUtr Name Cont><t e Coun•N
S001636 1 Parafusos e Porca,s +351.210497985 Portugal
secaaso Mtunlsme Tech. +32.23843331 """"'

Bnnsels Bel ium
....,
- .."'72.S790l92•
Figure 301c — An example of a record (in red) of the invoice numbered 09356 which is
stored in a relational database: individual rows from three different tables collectively
make up the complete record
While an electronic component remains stored in its system of origin, it •

need not be in a transportable format. In this example, the internal state MoReq2.010
of the originating system is as a relational database.
However, the originating system must be capable of outputting the content Modular Requirements
of the record as one or several components that can be transmitted to and
for Records Systems
stored by another system (principle of transportability) and represent the
complete content of the record (principle of completeness). Furthermore,
each time the content is requested, it must be outputted in the same way.
This means that once a record has been created in the MCRS, the system
of origin must keep the rows of the database locked, or keep a copy of the
rows, to ensure that the data they contain is not overwritten or updated
(principle of immutability). For example, in Figure 301c, the entry in the
suppliers table for Supplier S003452 cannot be later updated, to change
a detail such the supplier’s name or contact number, after the record has
been created. Volume 1
Core Services
& Plug-in Modules
Version 1.1
513
1
Electronic
components It also means that the system of origin must provide a method for output‑
ting the data of an individual record that does not require the export of
the whole relational database (principle of discreteness). Transportable
formats for records from database tables may include:
• XML datafiles,
• comma or tab separated values,
• spreadsheet formats,
• proprietary portable database formats, or even
•unstructured document formats, such as PDF or HTML that might be
generated, for example, when printing or viewing an invoice from a
financial transaction system.
/ Hierarchical
Regardless of the transportable format supported, the complete data
classification
relating to the record, stored in the original database table rows, and their
relationship to one another must be included in the electronic content.
Finally, when the record is destroyed by the MCRS in accordance with the
disposal schedule applied to the record, it must be possible for the appro‑
priate rows to be blanked or deleted from their respective tables in the data‑
base (principle of destructibility). If, for example, the row of the suppliers
table containing Supplier S003452 is also referenced by another record, such
as Invoice 05266 in the example, then the database must ensure its deletion
in response to the MCRS is managed so that neither record is compromised,
for example by using a system of pointers.
301.2.6 Ensuring electronic components are really gone

Good business systems, including MoReq2010® compliant records systems,
are designed with many levels of built‑in redundancy to ensure that the
organisation’s data can survive critical disasters such as hardware failures.
For example, most organisations will regularly place system backups in
remote offsite storage for extended periods of time.
The presence of these safeguards can make it difficult for an organisation
to be finally rid of electronic content even when the disposal process has
been followed. Ensuring that a record has been destroyed and its electronic
content erased from the MCRS and/or the system of origin, does not neces‑
•
MoRe.92.010 sarily mean that the same content cannot still be found within the organisa‑
tion, on backups, in the e‑mail system, on shared file drives and with staff
who have made personal copies for their own use.
Modular Requirements The extent of this issue stretches beyond the records system and the scope
for Records Systems of MoReq2010®, to the heart of the organisation’s corporate policies and
procedures around information governance. Each organisation must assess
its own risk and put into place appropriate mitigation strategies.
Some of the measures that an organisation can put into place to mitigate
the risk of retaining electronic content after it has been destroyed, include:
• regularly recycling backups, so that no backup is older than (say) three
months, this then sets a fixed time window from when records are
destroyed in the MCRS to when their content is no longer recoverable
from backup;
Volume 1 • implementing a method for staff to send references to records in
e‑mails (see, e.g. R101.4.16), rather than sending the record itself as
Core Services
an attachment (this will also reduce the amount of storage required
& Plug-in Modules for the corporate e‑mail system);
• regularly capturing e‑mail into the records system, or purchasing an
Version 1.1 e‑mail archiving system that is also an MCRS;
514
1
Electronic
• locking down shared file drives and requesting that employees do not components
store records outside the records system;
• automatically removing content stored outside the corporate business
and records systems that has not been accessed for a period of (say)
three months;
• training and educating staff, raising awareness of the issues, and provi‑
ding incentives around the proper use of corporate records systems;
and
• conducting regular information audits and compliance health checks.
This list reinforces the knowledge that implementation of MoReq2010®,
while an important contributing factor to good records management prac‑
tice, is not in itself sufficient for ensuring that an organisation complies
with its regulatory obligations, or puts into place a sound corporate‑wide
information governance framework.

R301.4.1 In accordance with core services requirement R6.5.19, the MCRS must
allow records to be created, under R6.5.10, with electronic components that
have immutable content held securely in either the originating system or a
separate data store.
The content of an electronic component must be immutable and secure,
meaning it must be unchanging and unchangeable. The content must be iden-
tical each time it is accessed.
R301.4.2 The MCRS must ensure that all electronic components (E301.7.1) are
created with the metadata listed under R6.5.19, as well as the following
additional system metadata:
• Content Media Type (M301.7.2).
If the record has more than one electronic component, each electronic
component belonging to the record must also have a: •
MoReq2.010
• Presentation Order (M14.4.84).
Each electronic component will also have electronic content that is either:
• directly available to an authorised user as electronic content, or for Records Systems
• indirectly available to an authorised user as a URI.
As explained in the rationale to R301.4.3, the MCRS may provide a URI to the
content in either the originating system or data store. Whether directly or indi-
rectly accessible, the Content Media Type represents the format of the elec-
tronic content of the component in its transportable form.
Note that an MCRS that keeps component content internally in its own data
store may make it accessible as a URI while, equally, an MCRS that manages
component content in an external data store may well provide users with direct Volume 1
access to the content. Some MCRS solutions may support both methods: this
is dependent on their design and their degree of integration with the data store Core Services
or originating system. Importantly, MoReq2010® does not require that an MCRS & Plug-in Modules
provide support for both approaches.
515
1
Electronic
components R301.4.3 The MCRS must allow an authorised user to access the content of an elec‑
tronic component as a datafile, either directly from the MCRS or by providing
the user with a URI.
While held in the originating system or data store, the content of an electronic
component must be accessible as a datafile of a specified media type, stored in
the Content Media Type metadata element. This is known as the content’s ‘trans-
portable form’. The MCRS must allow users to either access the datafile directly
or must provide a URI to the datafile to allow the user to access it indirectly.
Note that where the MCRS provides access via a URI, there may be additional
external access controls to the datafile that are imposed and managed by the
originating system or data store and not by the MCRS. This is outside the scope
ofClassification
MoReq2010®. series
/ Hierarchical
classification
R301.4.4 Where there is more than one component in a record, the MCRS must
generate a unique Presentation Order for each component.
The Presentation Order provides a simple way of logically ordering the compo-
nents of a record, when there is more than one, so they may be listed in a rele-
vant way. The Presentation Order of each component must be unique: no two
components of the same record may have the same Presentation Order.
For example, when capturing the contents of a web page as a series of compo-
nents, the main HTML script may be listed first in presentation order, before the
other components (CSS, JavaScript, images, etc.). Similarly, multi-part data-
files may have an intrinsic order: an e-mail message may be presented before
its attachments, etc.
MoReq2010® does not give specific guidance on the presentation order of
components within a record for different content types.
R301.4.5 The MCRS must provide a Content Media Type for the datafile for each elec‑
tronic component created under R301.4.1.
The Content Media Type for an electronic component must be the MIME media
type for the datafile generated when the component is exported from the origi-
nating system. MIME media types are managed by IANA (see RFC 4288, RFC
4855 and http://www.iana.org/assignments/media-types/index.html).
• The content of an electronic component may, or may not, be stored in the origi-
MoRe.92.010 nating system or in a data store associated with the MCRS in the format indi-
cated by the Content Media Type, but must be converted into that media type on
export. The Content Media Type, therefore, represents the transportable format
of the content.
for Records Systems
For example, a record of a web page may have three components:
• an HTML script with the media type, ‘text/html’;
• a cascading style sheet with the media type, ‘text/css’; and
• an image with the media type, ‘image/jpeg’.
R301.4.6 The MCRS must set a flag in the metadata of an electronic component when
it is created, under R6.5.19, that describes whether the MCRS must wait
for confirmation of the destruction of the content of a component when the
component is destroyed.
Volume 1
Under R301.4.8, following the decision to destroy a record under a disposal
Core Services schedule, the content of all electronic components of a record must be deleted
& Plug-in Modules from the originating system or the appropriate data store(s). Depending on
the implementation of the data store and the degree of its integration to the
MCRS, this deletion operation may require confirmation if it cannot be carried
Version 1.1 out automatically.
516
1
Electronic
R301.4.7 Subject to R2.4.22 and further to R6.5.17, the MCRS must allow an author‑ components
ised user to browse and inspect electronic components in at least the
following ways:
• browse the electronic components of a record, in presentation order,
and inspect their metadata; and
• browse from an electronic component to its content, subject to the
content being accessible, under R301.4.3.
See R6.5.17. The terms ‘browse’ and ‘inspect’ are defined in 13. Glossary.
R301.4.8 When the MCRS exports an electronic component, under R11.4.8, it must
either include a URI to the content in the export data or embed the datafile
representing the content, under R301.4.3, in the export data.
A URI to the content will always be exported whenever the MCRS does not
embed the full content of the electronic component directly into the XML data
generated on export. When the Component Content is embedded in the XML
data generated on export, it is included as Base64 encoded binary data.
Some more sophisticated MCRS solutions may relegate this choice to the user.
In other words, an authorised user may be able to choose, as part of an export
operation, either to export component content embedded in the exported XML
data or to export components with embedded URIs that enable the importing
service to separately download the content for each component.
R301.4.9 When a record containing electronic components is destroyed, under

R8.4.20, the MCRS must ensure that the managed content belonging to
each electronic component is deleted from the originating system and any
data stores, under R301.4.1.
If the MCRS cannot automatically delete the managed content, the MCRS
must wait for confirmation of its deletion, under R8.4.20, before the compo‑
nent is destroyed.
This is determined by the metadata flag referred to in R301.4.6. Note that the •
record cannot be destroyed until all of its components have been destroyed and MoReq2.010
electronic components cannot be destroyed until their content has been either
automatically deleted, or manually confirmed as having been deleted, by an
authorised user, under R8.4.20. Modular Requirements
for Records Systems
Function reference: F14.5.41, F14.5.119

N301.5.1 Each MCRS may come in a different form. Some MCRS solutions are
general-purpose applications, but others have a dedicated purpose, intended
for a particular vertical market, and support integration with only specific types
of business system. The MCRS may even be built into a particular business
system and be indistinguishable from it.
Volume 1
Is the records system part of a business system, or tightly integrated with a
business system, or is it a stand‑alone records system? Core Services
& Plug-in Modules
N301.5.2 The purpose of the MCRS informs the types of component content it manages as
well as how this content is managed. As a consequence, the MCRS may provide
wide-ranging support for a number of different component content types, or it Version 1.1
517
1
Electronic
components may support only a few content types. The content of electronic components can
vary from traditional office documents to a number of rows in a database.
In combination with N301.5.1, what types of electronic component content
does the records system support?
N301.5.3 Records may have one component or many components — this, too, is a result of
the types of record and their electronic components that the MCRS is designed
to support.
Further to N301.5.2, do the records with electronic components supported
by the records system have one or more than one component and is the
Classification
number of componentsseries
fixed or variable?
/ Hierarchical
N301.5.4 Integral to the design of an MCRS is the location of the content that is managed.
classification
This may be in the system of origin, in an internal data store controlled by the
MCRS or in an external data store.
In relation to N301.5.1, where is the content of electronic components stored
for records in the records system?
N301.5.5 An important characteristic of a component is immutability which means that

the content of the component does not change once the record has been created.
The content of record components must therefore be unalterable. If electronic
components are located externally to the MCRS, the organisation must employ
safeguards to ensure the integrity of the component content is preserved in its
environment.
How does the records system ensure the immutability of content in its
storage location under N301.5.4?
N301.5.6 N12.13.6 describes synchronisation issues that may occur when the MCRS and
the content of components is backed up and restored separately or at different
times. Records systems which manage records in the system of origin or in
external data stores can be particularly vulnerable.
For example, if the MCRS is restored from a backup, then it may contain, as
• active records, records that were previously destroyed, prior to the discontinuity,
MoR:_92010
and for which the electronic content was deleted and is no longer in the external
data store or system. Alternatively, there may be content in the external data
Modular Requirements store or system which belongs to records that do not exist in the MCRS, because
for Records Systems they were created after the last backup but before the discontinuity occurred.
The design of the MCRS must overcome these potential synchronisation issues,
especially when it manages records in place.
How does the records system ensure that it re‑synchronises with the content
location specified in N301.5.4 if one or the other has to be restored from
backup as part of disaster recovery?
N301.5.7 In MoReq2010®, the content of some components can support automatic dele-
tion by the MCRS. This is a property of the component itself. The content of
Volume 1 other components cannot be automatically deleted by the MCRS in response to
a disposal schedule.
Core Services
Further to R301.4.6, does the records system manage components that
& Plug-in Modules can be automatically or manually deleted or does it allow both and, if so,
how? What characterises these different types of component content in the
Version 1.1 records system?
518
1
Electronic
N301.5.8 Where the record content managed by the MCRS cannot be deleted automati- components
cally, it must either be manually deleted or by some external process and then
confirmed, so that the MCRS can continue with the destruction of the record.
If, under N301.5.7, the content of electronic components must be manually
deleted from its location in N301.5.4 then, further to R301.4.9, what is the
process for doing this and how is it confirmed in the records system?
N301.5.9 When managing records with electronic components, the MCRS also has
design choice about how users access the content of these components. The
MCRS may be able to deliver the content to the user, or it may provide the user
with a URI to the content and require the user to access the content directly
from the data store. Some solutions may provide both options.
Further to R301.4.3, does the records system allow authorised users to
access the content of electronic components as datafiles or using a URI
or both?
N301.5.10 Export of electronic components is similar to user access described under

N301.5.9. The MCRS may include the content in the export directly, or it may
export a URI that points to the location of the content, which the importing
system must then retrieve.
Further to R301.4.8, does the records system allow authorised users to
export the content of electronic components as datafiles or using a URI or
both?
N301.5.11 As described in the rationale to R301.4.3, where the MCRS provides a URI
to the content of an electronic component, the user may require additional
access controls to inspect the content.
Further to N301.5.9 and N301.5.10, what further authorisation does the
user require when retrieving content using a URI provided by the records
system and how is this managed?
N301.5.12 Where the content of the electronic component is stored externally and
accessed using a URI, additional security measures may need to be put in place
to ensure that unauthorised users do not access the content from outside the •
MoReq2010
MCRS.
How does the MCRS or supporting system prevent unauthorised access to
the URI retrieved under N301.5.11? Modular Requirements
for Records Systems
N301.5.13 R301.4.5 requires that each electronic component have a Content Media Type.
The Content Media Type relates to the content of the component in its transport-
able form. Depending on the nature and purpose of the MCRS under N301.5.1,
and the types of electronic component content supported under N301.5.2, the
MCRS may provide in-depth support for component content types based on
particular document formats, such as the Microsoft Office or ODF.
The degree of support provided for components based on particular content
formats may vary. For example, the MCRS may be able to index and search
over the content of these components when they are captured as records and Volume 1
the MCRS may also be able to capture some or all of the properties of these
document types as additional component metadata.
Core Services
& Plug-in Modules
Further to the types of component content supported under N301.5.2, what
common content types and formats does the records system support and
in which of the following ways? Version 1.1
519
1
Electronic
components • Identify the document type and index and search over the document
content
• Identify the document type and extract additional metadata from the
document
(Include the date the list was compiled as additional document formats
may be added over time.)
N301.5.14 A records system is designed to manage records and their components;

however, the content of record components, especially electronic content,
can proliferate in an organisation and copies may exist outside an MCRS as
explained in 301.2.6 Ensuring electronic components are really gone.
While the records system by itself cannot necessarily remove this prolifera-
/tion,
Hierarchical
it should do as much as it can to assist in resolving it. For example, when
records are captured from a system, such as an e-mail system or a shared
classification
drive and placed into a data store, the records system may be able to simulta-
neously delete the source content of the new record so that there remains only
one copy of the content (now in the data store) and not two.
In what ways does the records system assist in controlling unmanaged
record content within the organisation?
N301.5.15 Many operating systems do not overwrite the binary data of a datafile when it
is deleted from storage media. In sensitive and secure environments, the foot-
print previously occupied by the datafile in the repository of the MCRS should
be overwritten to ensure the datafile cannot be wholly or substantially recov-
ered by, for example, the close analysis of magnetic disc surfaces.
Does the records system provide a mechanism for overwriting the content
of electronic record components when they have been destroyed and are
deleted under R301.4.9?
301.6 GloSSARy
Content media type (noun) See media type.
• Data store (concept) A secure location for storing electronic

MoRe.92.010 data or content so that it is accessible by an MCRS
or other business system.
See also internal data store and external data
Modular Requirements store.
for Records Systems
Electronic (entity) A subtype of component having content
component that is electronic.
External data store (concept) A data store that is not under the direct
control of the MCRS. An external data store may
be managed by another business system or it
may even be an integral part of the other business
system, similar to an internal data store. The
external data store may be shared and used by
several different business systems.
Volume 1
Internal data store (concept) A data store that is fully controlled and
managed by the MCRS. All access to an internal
Core Services data store will be through the MCRS which can
& Plug-in Modules then use its normal access control methods to
ensure that the content remains immutable (is not
modified or deleted).
Version 1.1
520
1
Electronic
components
Media type (noun) The datafile format of the content of an

electronic component in its transportable form.
MoReq2010® specifies the use of MIME media
types. For example, a video that uses MPEG‑4
Part 14 (otherwise known as MP4) has a MIME
media type of ‘video/mp4’, while a Microsoft Excel
spreadsheet has the MIME media type ‘application/
vnd.ms‑excel’.
See also datafile and transportable form.
originating system (concept) The application or business system

where the electronic content that is made into a
record is generated. The content generated by the
originating system must be transportable so that
either on creation of the record, or later, it can be
transmitted to a receiving system or captured by
the MCRS and placed into a data store.
See also information system, receiving system
and transportability.
Receiving system (concept) Any application or business system

that receives and stores or uses electronic record
content. For electronic content to be transmitted
and received, it must have a transportable form.
See also information system, originating system
and transportability.
transportability, (concept) The principle that electronic content

Principle of cannot be made into a record in an MCRS
unless it can be retrieved or transmitted from
its originating system in a transportable form.
Without transportability, records cannot be
transferred or migrated and interoperability
requirements cannot be met. A specialised
business system may keep records in tables
in a database or other proprietary internal
format. However, according to the principle of
•
transportability, there must be some provision MoReq2.010
made for exporting the content from the business
system or it is not sufficient for a record.
See also completeness, destructibility, Modular Requirements
discreteness and immutability. for Records Systems
transportable form (noun) The content of an electronic component
as a datafile that can be described by a media
format, allowing it to be stored in a data store,
transmitted or received by applications and other
business systems, and retrieved by the authorised
users of the MCRS.
See also datafile.
Volume 1
Core Services
& Plug-in Modules
Version 1.1
521
1
Electronic
components 301.7 INFoRMAtIoN MoDEl
E301.7.1 Electronic Component 522
M301.7.2 Content Media type 522
F301.7.3 Electronic Component – Create 523
F301.7.4 Electronic Component – Get Content 524
F301.7.5 Electronic Component – Get Content URI 524
E301.7.1 Electronic Component
System Identifier a2374646‑3b29‑4a30‑93a8‑96e369dc150c

/title
Hierarchical Electronic Component
classification
Description Definition of an electronic component, as a subtype
of component, used in MCRS solutions that
manage electronic content
Subtype of Component (E14.2.3)
Additional system As for Component (E14.2.3) plus the following
metadata additional system metadata:
• Media Type (M301.7.2)
The following metadata element is necessary for
records with more than one electronic component,
under R301.4.2 and R301.4.4:
Additional functions As for Component (E14.2.3) plus the following

additional functions:
• Electronic Component — Get Content
(F301.7.4)
• Electronic Component — Get Content URI
(F301.7.5)
The following function replaces Component —
Create (F14.5.38):
• • Electronic Component — Create (F301.7.3)
MoRe.92.010
Usage notes The new function Electronic Component — Create
(F301.7.3) replaces the function Component —
Modular Requirements Create (F14.5.37) for electronic components
for Records Systems
M301.7.2 Content Media type
System Identifier 277c94bc‑9cc8‑4018‑8cd9‑dc2aa3b189b5

title Content Media type
Description The media type of the content of the electronic
component
Entity type Electronic Component (E301.7.1)
Min occurs 1
Volume 1
Max occurs 1
Core Services Modifiable? No
& Plug-in Modules
Entity Reference? No
Datatype Valid MIME media type
Version 1.1
522
1
Electronic
F301.7.3 Electronic Component — Create components
System Identifier ea33d749‑92aa‑421b‑9eba‑6fb90786d4b9
title Electronic Component — Create
Description Create the electronic component of a record

• Title (M14.4.104)
• Content Media Type (M301.7.2)
If the record has more than one electronic
component, it will also have:

requirement(s)

•
• Applied Template Identifier (M14.4.2) MoReq2.010
Usage notes • The electronic component is created

simultaneously with its record (see F14.5.121
Record — Create)
for Records Systems
• The Content Media Type must include a valid
MIME media type for the transportable form of
the electronic content
• The electronic component may be created with
contextual metadata elements as well as the
metadata
Volume 1
• For each metadata element set on creation,
except System Identifier and Created Core Services
added to the corresponding event & Plug-in Modules
Version 1.1
523
1
Electronic
components F301.7.4 Electronic Component — Get Content
System Identifier c1a3d38b‑72ee‑48c2‑983b‑b028db002d7f
title Electronic Component — Get Content
Description Retrieve the content of an electronic component

from the system

Classification
requirement(s)
series
/Purpose
Hierarchical • Access control
classification • Event generation

Usage notes • The system must implement this function as

well as, or instead of, the function Electronic
Component — Get Content URI (F301.7.5)
• This function should generate an event, subject
to R2.4.13, whenever the user retrieves the
content of the electronic component directly
from the system
F301.7.5 Electronic Component — Get Content URI
System Identifier 1f0784ee‑3825‑4422‑ad45‑46c3dee59c74
title Electronic Component — Get Content URI
Description Retrieve a URI to the content of an electronic

component from the system
•
MoRe.92.010 Entity type Electronic Component (E301.7.1)

Modular Requirements From functional R301.4.3
for Records Systems requirement(s)


Usage notes • The system must implement this function as

well as, or instead of, the function Electronic
Volume 1 Component — Get Content (F301.7.4)
• This function should generate an event, subject
Core Services to R2.4.13, whenever the user retrieves
& Plug-in Modules from the system a URI to the content of the
electronic component
Version 1.1
524

Moreq2010 (Especificaciones) PDF

Uploaded by

Copyright:

Available Formats

Moreq2010 (Especificaciones) PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Moreq2010 (Especificaciones) PDF

Uploaded by

Copyright:

Available Formats

1212 1911 2989

l1U 31U 190!'1

IJU Sllt IH3

s,,, ocso ,,as S061

2U7 1122 lllt 11ll2

1212 1,11 299t ''ºº

• Jl,._!'I no 01u 1905

5411 o,Jt ,toe 512C

02311 ,ns 427t 5c,,

.,_ 123C U1S 101 H22

nu JHt 01'5 no5

USf. 0tU 315C 613C

!'ltll Ollt 190C !'112C

431!1 nn "'" 5U6

• __'1.1, l!IJC IJCI !'llSC 16'l

,,,. 1212 1'11 2Ht U00

123' C615 11'1 0&22

�11'1'15 310 01U 7'05

,,�,u 315, 613'

0631 "º' 512,

)t 4'75 1197 6822

,._, 074' 1905

MoReq2010® Modular Requirements for Records Systems

84S 07H 7,0S

2J5t O!Hf 37!it 67lt

5UI oni H 4 112,

MoReq2010® Modular Requirements for Records Systems

Part One – Core Services .............................................. 11

2. System services ............................................................................... 31

3. User and group service ................................................................... 51

4. Model role service ........................................................................... 57

5.1 Service information ................................................................ 69

6. Record service ................................................................................. 77

7. Model metadata service .................................................................. 99 Volume 1

9. Disposal holding service ............................................................... 137

10. Searching and reporting service .................................................. 141

11. Export service ................................................................................ 151

12. Non-functional requirements....................................................... 169

13. Glossary .......................................................................................... 195

14. Information model ......................................................................... 241

Part Two – Plug-in Modules..................................... 463

101. Graphical User Interface (GUI) ..................................................... 467

102. Application Programming Interface (API) ................................... 483

200. ClASSIFICAtIoN SERIES.............................................................. 489

201. Hierarchical classification ............................................................ 491

301. Electronic components.................................................................. 509

Part One – Core Services

Figure 1a — The MoReq Governance Board’s Roadmap (circa 2009)................................ 17

Figure 1b — The ‘traditional’ architecture of a records system includes capture of

Figure 1c — An alternative architecture is to manage records in place by allowing the

Figure 1d — As records management controls and processes become simple, flexible

Figure 1g — Records may be transferred multiple times between records systems

Figure 1i — A traditional hierarchical model of classification and aggregation where

Figure 3a — In an MCRS, users and groups have a many‑to‑many relationship ............. 52

Figure 5a — Explanatory note: For illustrative purposes, each of the classes

Figure 5c — Classifying a child aggregation overrides the default class it inherits

Figure 5d — Individually classifying a record overrides the default class it inherits

Figure 5e — An example of a classification service that adopts a hierarchical

Figure 6d — An aggregation cannot retain its linear narrative if it contains both