EDGAR XBRL Guide

Prepared by SEC Staff

March 2024
Disclaimer
The Securities and Exchange Commission (“SEC” or “Commission”) staff is making available to the
public this EDGAR Extensible Business Reporting Language (“XBRL”) Guide to assist filers with
preparing submissions on EDGAR using XBRL. This guide should not be relied upon for any other
purpose.
Filers may consult the separate EDGAR XBRL Guide (Filing Fee Extract) for references in connection
with preparing fee-related submissions on EDGAR using XBRL.
The SEC has not approved, may approve or disapprove, and may revise any of the content of this
EDGAR XBRL Guide. SEC staff’s provision of this guide does not indicate Commission approval or
disapproval of any changes relating to the EDGAR system or the rules and regulations related to EDGAR,
including but not limited to the EDGAR Filer Manual. Filers are reminded that they must comply with the
requirements of the EDGAR Filer Manual.
EDGAR® and EDGARLink® are registered trademarks of the Securities and Exchange Commission. All
other product brand names mentioned herein are trademarks or registered trademarks of their respective
holders.

2
Contents
1 FUNDAMENTALS ............................................................................................................... 8
2 XBRL SPECIFICATIONS ................................................................................................ 10
3 INSTANCE CONTENT ..................................................................................................... 11
3.1 Expected Facts in the Required Context ........................................................................................ 12
3.1.1 Notation and Terminology ............................................................................................................. 12
3.1.2 Required Context validation .......................................................................................................... 13
3.1.3 Central Index Key .......................................................................................................................... 14
3.1.4 Registrant Name ............................................................................................................................ 14
3.1.5 Form or Exhibit Type..................................................................................................................... 15
3.1.6 Amendment Flag and Description ................................................................................................. 16
3.1.7 Document Period End Date ........................................................................................................... 17
3.1.8 Document Fiscal Year and Period Focus ....................................................................................... 18
3.1.9 Current Reporting Status and Interactive Data Current ................................................................. 19
3.1.10 Voluntary Filers, Shell Companies, and Well-known Seasoned Issuers ................................... 19
3.1.11 Small Business, Emerging Growth Company ........................................................................... 21
3.1.12 Current Fiscal Year End Date .................................................................................................... 22
3.1.13 Filer Category (Accelerated / Non-Accelerated) ....................................................................... 23
3.1.14 ICFR Auditor Attestation Flag .................................................................................................. 24
3.1.15 Public Float................................................................................................................................ 25
3.1.16 Auditor Name, Location, and Firm ID ...................................................................................... 25
3.1.17 Investment Company Type........................................................................................................ 27
3.1.18 File Number (Securities Act File Number) ............................................................................... 28
3.1.19 Incorporation State / Country Code ........................................................................................... 28
3.1.20 Tax Identification Number ........................................................................................................ 28
3.1.21 Primary SIC (Standard Industrial Code) Number ..................................................................... 29
3.1.22 Principal Office Address ........................................................................................................... 29
3.1.23 Submission Flags ....................................................................................................................... 32
3.1.24 Closed-end fund registration ..................................................................................................... 37
3.2 Expected Facts with Dimensions ................................................................................................... 43
3.2.1 Business contact ............................................................................................................................. 45
3.2.2 Former address ............................................................................................................................... 48
3.2.3 Common Stock Shares Outstanding .............................................................................................. 50
3.2.4 Registered Securities...................................................................................................................... 51
3.2.5 Open-end Fund Series .................................................................................................................... 54
3.2.6 Open-end Fund Shareholder Reports ............................................................................................. 54
3.3 Resource Extraction Payments Disclosure .................................................................................... 56
3.3.1 Currency and Total Payments ........................................................................................................ 56
3.3.2 Payments Axis ............................................................................................................................... 56
3.3.3 Boolean, Numeric and String Valued Facts ................................................................................... 56
3.3.4 Member-valued Facts..................................................................................................................... 57
3.3.5 Payment Contexts .......................................................................................................................... 58

3
3.3.6 Government Aggregate Contexts ................................................................................................... 60
3.3.7 Project Aggregate Contexts ........................................................................................................... 61
4 FILING FEE EXHIBITS ................................................................................................... 61
4.1 Filing Fee Inline XBRL Attachments ............................................................................................ 61
4.1.1 Security Types Based on Rule ....................................................................................................... 62
4.1.2 Offering & Transaction Valuation Rules Applicable for Submission Types ................................ 62
4.1.3 Offset Table & Combined Prospectus Rules Applicable for Submission Types ........................... 64
4.2 Submission Table ........................................................................................................................... 66
4.3 Fees Summary Table...................................................................................................................... 67
4.4 Offering Table................................................................................................................................ 69
4.5 Offering Table Rule Flags ............................................................................................................. 69
4.5.1 Rule 457(a) Lines........................................................................................................................... 69
4.5.2 Rule 457(o) Lines .......................................................................................................................... 70
4.5.3 Rule 457(r) Lines ........................................................................................................................... 71
4.5.4 Rule 457(s) Lines ........................................................................................................................... 72
4.5.5 Rule 457(u) Lines .......................................................................................................................... 73
4.5.6 Rule “Other” Lines ........................................................................................................................ 74
4.5.7 Rule 415(a)(6) Lines ...................................................................................................................... 75
4.5.8 Rule 0-11 Lines .............................................................................................................................. 76
4.5.9 Rule 457(f) Lines ........................................................................................................................... 77
4.5.10 General Instructions II.H (Exchange Offers) and II.I (Business Combinations)....................... 78
4.6 Offset Table ................................................................................................................................... 78
4.6.1 Offset Table Rule Flags ................................................................................................................. 78
4.6.2 Rule 457(b) or 0-11(a)(2)) Lines ................................................................................................... 78
4.6.3 Rule 457(p) Lines .......................................................................................................................... 79
4.7 Combined Prospectus Table .......................................................................................................... 80
4.7.1 Combined Prospectus Table Rule Flags ........................................................................................ 80
4.7.2 Combined Prospectus Lines Specifying Rule 429 ......................................................................... 80
4.8 Securities, 424I .............................................................................................................................. 81
4.8.1 Securities, 424I Table Rule Flags .................................................................................................. 81
4.8.2 Submission Type 424I Table Lines ............................................................................................... 81
4.8.3 Submission Type 424I Entries in the Submission Table ............................................................... 82
5 CUSTOM TAXONOMIES ................................................................................................ 82
5.1 Custom presentation and label relationships for standard concepts............................................... 83
5.2 File attachments for custom relationships...................................................................................... 83
5.3 Custom presentation and label relationships.................................................................................. 83
5.4 Custom relationships for standard concepts, with dimensions ...................................................... 84
5.4.1 File attachments for custom members ........................................................................................... 84
5.4.2 Dimensional relationships.............................................................................................................. 85
5.4.3 Presentation and label relationships ............................................................................................... 87
5.5 Validation of custom relationships ................................................................................................ 87
5.5.1 Validations resulting in Errors ....................................................................................................... 87
5.5.2 Validations resulting in Warnings ................................................................................................. 88
4
5.6 Custom Concept Declarations in General ...................................................................................... 88
5.6.1 Do not duplicate pre-existing concept declarations ....................................................................... 88
5.6.2 Avoid changes in declarations from period to period .................................................................... 89
5.6.3 Custom concept naming................................................................................................................. 89
5.6.4 Custom concept declarations ......................................................................................................... 89
5.7 Custom Domain Member Declarations.......................................................................................... 89
5.8 Custom Presentation and Label Relationships ............................................................................... 91
5.8.1 Instance type 8K.A example – custom members ........................................................................... 91
5.9 Custom Calculation Relationships for Standard Concepts ............................................................ 91
5.9.1 When calculation relationships are required .................................................................................. 93
5.9.2 Avoid calculation relationship redundancy.................................................................................... 93
5.9.3 A single concept may have alternate calculations ......................................................................... 94
5.10 Custom Numeric Concepts ............................................................................................................ 94
5.10.1 Do not duplicate numeric concepts ........................................................................................... 94
5.10.2 Monetary concepts..................................................................................................................... 94
5.10.3 Share (unit of ownership) type concepts ................................................................................... 95
5.10.4 Per-share type concepts ............................................................................................................. 95
5.10.5 Pure number type concepts ........................................................................................................ 96
5.10.6 Percent type concepts ................................................................................................................ 96
5.11 Custom Non-Numeric Concepts .................................................................................................... 96
5.11.1 Custom Non-member Abstract concepts ................................................................................... 96
5.11.2 Custom text block type concepts ............................................................................................... 96
5.11.3 Custom dimensional concepts ................................................................................................... 97
5.11.4 Other custom non-numeric types............................................................................................... 97
5.12 Other custom taxonomy components............................................................................................. 98
6 INSTANCE RENDERING ................................................................................................ 98
6.1 Motivation for Standardized Rendering......................................................................................... 98
6.2 Presentation groups ........................................................................................................................ 99
6.3 Fact selection ................................................................................................................................. 99
6.3.1 Period Selection ........................................................................................................................... 100
6.3.2 Unit Selection .............................................................................................................................. 100
6.3.3 The Primary Axis ......................................................................................................................... 100
6.4 Basic Layout using Core and Taxonomy-Defined Dimensions ................................................... 100
6.5 Ordering members along a dimension ......................................................................................... 101
6.6 Merged columns .......................................................................................................................... 102
6.7 Period Start labels ........................................................................................................................ 102
6.8 Column Headings and Promotion ................................................................................................ 103
6.9 Row Headings and Promotion ..................................................................................................... 103
6.10 Footnotes and Merging ................................................................................................................ 103
6.11 Flow Through Suppression on Statements................................................................................... 104
6.12 Cash Flow Statements .................................................................................................................. 104
6.13 Statements of Changes in Shareholder Equity ............................................................................. 104
6.14 Layout Qualifiers ......................................................................................................................... 105
6.15 Uncategorized Facts ..................................................................................................................... 106
5
6.16 Numeric Formatting ..................................................................................................................... 106
6.17 Non-numeric Formatting ............................................................................................................. 106
6.18 The Filing Summary .................................................................................................................... 107
6.19 Multiple Instances ........................................................................................................................ 108
6.20 Workbook Output ........................................................................................................................ 108
6.21 Resource Extraction Payment Rendering .................................................................................... 108
6.22 Rendering of Mutual Fund Risk/Return Summary Interactive Data ........................................... 109
6.22.1 Embedding Commands............................................................................................................ 109
6.22.2 Bar Charts ................................................................................................................................ 109
7 VALIDATION DETAILS ON ALL XBRL ATTACHMENTS ................................... 110
7.1 File names and character encodings............................................................................................. 110
7.2 Standard namespace prefixes ....................................................................................................... 111
7.3 Standard locations ........................................................................................................................ 112
7.4 Compatible Taxonomies .............................................................................................................. 112
7.5 Elements....................................................................................................................................... 113
7.6 Element attributes ........................................................................................................................ 113
7.7 Element attribute values............................................................................................................... 114
7.8 Attribute value lengths ................................................................................................................. 114
8 VALIDATION DETAILS ON XBRL INSTANCES ..................................................... 114
8.1 XHTML Validations .................................................................................................................... 115
8.1.1 HTML restrictions on Text Block facts ....................................................................................... 115
8.1.2 HTML restrictions on XBRL footnotes ....................................................................................... 116
8.1.3 HTML restrictions on Inline XBRL ............................................................................................ 116
8.2 Labels ........................................................................................................................................... 116
8.3 Presentation .................................................................................................................................. 116
8.4 Footnote Links ............................................................................................................................. 116
8.5 Decimals ...................................................................................................................................... 117
8.6 Contexts ....................................................................................................................................... 117
8.7 Periods ......................................................................................................................................... 118
8.8 Units ............................................................................................................................................. 118
8.9 Non-US English Facts.................................................................................................................. 119
8.10 Duplicate facts ............................................................................................................................. 119
9 VALIDATION DETAILS ON CUSTOM TAXONOMIES.......................................... 120
9.1 Custom namespace and role URIs ............................................................................................... 120
9.2 Roles ............................................................................................................................................ 121
9.3 Concepts....................................................................................................................................... 122
9.4 Relationships ................................................................................................................................ 123
9.5 Concept types and relationships................................................................................................... 125
9.6 Concept labels and roles .............................................................................................................. 125
9.7 Rendering validations .................................................................................................................. 126
9.7.1 Each axis that is presented requires at least one child element. ................................................... 126
9.7.2 Matching instant and duration facts ............................................................................................. 127
9.7.3 Changes in Equity presentation instant and duration type facts. ................................................. 127
6
9.7.4 Text blocks containing embedding commands. ........................................................................... 127
9.7.5 Rows and columns both required. ................................................................................................ 128
9.7.6 Completeness of axes in an embedding command. ..................................................................... 128
9.7.7 Bar Chart selected Annual Return facts ....................................................................................... 129
9.7.8 The {Elements} token implies "column primary" embedding. ................................................... 129
9.8 Namespace-specific Customizations............................................................................................ 129
9.8.1 CEF Customization ...................................................................................................................... 130
9.8.2 ECD Customization ..................................................................................................................... 130
9.8.3 FFD Customization ...................................................................................................................... 130
9.8.4 OEF Customization...................................................................................................................... 130
9.8.5 RXP Customization ..................................................................................................................... 131
9.8.6 VIP Customization ....................................................................................................................... 131
9.8.7 SRO Customization ..................................................................................................................... 132
10 INLINE XBRL RESTRICTIONS ................................................................................... 132
11 TABLES FROM FILER MANUAL VOLUME II CHAPTER 6................................. 132

Figure 1. Dimension figures color-coding legend ........................................................................ 43

Figure 2. Example showing nine facts with a single taxonomy-defined dimension ................... 43
Figure 3. Example showing different presentation of the same nine facts .................................. 44
Figure 4. Example showing the nine individual facts .................................................................. 44
Figure 5. Custom presentation and label relationships, no dimensions ........................................ 84
Figure 6. Dimensional relationships example 1............................................................................ 86
Figure 7. Dimensional relationships example 2............................................................................ 86
Figure 8. Presentation example ..................................................................................................... 87
Figure 9. Definition relationships with a custom member ............................................................ 90
Figure 10. Examples of custom domain members ....................................................................... 90
Figure 11. Custom presentation and label relationships with a custom member.......................... 91
Figure 12. Standard calculation relationships example ................................................................ 92
Figure 13. Custom calculation relationships with standard concepts. ......................................... 93

Introduc�on
This EDGAR XBRL Guide provides detailed technical specifications of XBRL formatting and validation
for use in connection with making submissions on EDGAR.
For all submissions, filers should refer to and must comply with the requirements in the EDGAR Filer
Manual (“EFM”).
Chapter 6, Volume II of the EFM, Interactive Data, contains requirements for Interactive Data
submissions in EDGAR using XBRL. That chapter also explains the use of taxonomies and instances that
comprise the XBRL model. Chapter 3, Volume II of the EFM, Index to Forms, contains a discussion of
different XBRL formatted documents associated with relevant EDGAR form and submission types.

7
1 Fundamentals
Interactive Data submissions in EDGAR use the Extensible Business Reporting Language (XBRL)
information model. To understand the preparation and processing of Interactive Data in EDGAR it is
important to be familiar with XBRL’s key ideas and terminology, as well how XBRL differs from other
formats.
Facts and Concepts. XBRL defines computer-readable facts for business reporting. A fact represents a
single numeric item, or an arbitrarily sized section of text (a non-numeric fact). In EDGAR, a fact that
appears in a submission is an assertion being made by a filer to satisfy an SEC disclosure requirement.
Each fact is characterized by a set of core standard dimensions:
• the period for which the fact is asserted,
• the business entity that it is about,
• the human language in which the text is written (US English, in EDGAR),
• for numeric facts, the unit of measure and number of decimal places that are not significant.
Each fact is an occurrence of a concept that makes it comparable to other facts. For example, “Public
Float” could be an SEC-defined concept for which a fact “10 billion US dollars, with nine digits (zeroes)
not shown” has the same meaning whether it is a fact about entity ABC as of February 14, 2030, or a fact
about entity XYZ as of January 12, 2025. Concepts have a data type and validations that constrain their
possible values. Continuing the example, facts of the Public Float concept value should not be negative
and must be expressed in US Dollars.
Instances and Formats. A set of XBRL facts is called an XBRL instance. An instance is computer-
readable data that may be stored or transmitted written out in its original XML-based file format
(“xBRL-XML”) or embedded into HTML documents (“Inline XBRL”). In XBRL formats currently used
in EDGAR, the location of facts within a file has no impact on their meaning. Also, an instance is not
necessarily one EDGAR file attachment; Inline XBRL allows instances to be distributed across, and
embedded into, more than one file attachment within a submission. XBRL defines the facts of an instance
– its information model, not just file formats – and this is a unique defining characteristic of XBRL
specifically intended to support technology changes.
Taxonomies and Dimensions. Another defining characteristic of XBRL is how concepts are defined via
XBRL taxonomies. A taxonomy consists of concepts, along with relationships among concepts and with
other computer-readable data. Relationships can be thought of as arcs in a graph, each with a source (or
parent) concept and target (or child). The type of relationship is called role of the arc, i.e., its arc role.
Some of these relationships describe the various dimensions along which a fact may be characterized. A
fact may have any number of taxonomy-defined dimensions, conventionally called axes, each of which
has a domain of possible values. As a mnemonic for axes and dimensions, it may be helpful to visualize a
physical object such as a book. It has three axes: height, width, and depth. The dimensions of the book
might be seven inches high, five inches wide, and one inch deep. Each of the book’s axes has the same
domain: positive numbers.
Domains may be infinite, like the number of inches, or may have a set of explicit members. For example,
a taxonomy might define a “Country” axis, whose explicit members are countries. In this way, the facts
“ABC Inc’s Bermuda 2025 Revenue is $10m” and “ABC Inc’s Bonaire 2025 revenue is $10m” are
distinct. Their “dimensions” are “country Bermuda” and “country Bonaire”, respectively. For a fact that
does not specify an explicit member of an axis, there may be an unstated default member that represents
all members of that axis collectively. The fact “ABC Inc’s 2025 Revenue is $20m” therefore refers to its
global revenue. A taxonomy specifies for every concept what dimensions are required, permitted, or
forbidden for facts of every concept. EDGAR validates each XBRL instance against the relevant
taxonomies to ensure that every fact has all the required dimensions and none of those dimensions are
forbidden.
8
Modularity and Documentation. EDGAR taxonomies that support specific SEC rule releases are
accompanied by technical documents called taxonomy guides that detail the concepts and other aspects of
how the taxonomy is used. Since their introduction in 2009, new EDGAR taxonomies have been
introduced and have evolved, resulting in differences in naming conventions, organization of files, and
other matters. All EDGAR taxonomies are currently updated at least annually, for the most part via an
EDGAR release occurring in the first quarter of each calendar year and removed from use after two years.
All taxonomies used in an instance must be from the same calendar year but are otherwise technically
independent and can be mixed and matched to suit the regulatory disclosures present in a submission.
This organization of taxonomies is a different approach than EDGAR’s technical guides for online forms.
Meta data. Taxonomies contain several computer-readable relationships other than the dimension-
defining relationships outlined above. A concept in a taxonomy will be annotated with text labels,
authoritative references, data quality validations, simple arithmetic calculations, and ordering and nesting
relationships among concepts that that detail how software should create a tabular presentation of facts
extracted from an instance. These relationships are ideally independent of which SEC Form, EDGAR
Submission Type, or Exhibit the concepts will be used for.
For example, the concept “Entity Filer Category” has an authoritative reference to the Exchange Act
240.12b-2 which contains definitions of the terms. The Entity Filer Category concept also appears in a
presentation link that provides a conventional order of presentation with respect to related concepts such
as “Entity Voluntary Filers” and “Entity Well Known Seasoned Issuers” that may appear on the cover
page of several different Forms in the same relative positions. In XBRL taxonomies, these relationships
are stored in linkbases and may be embedded in XML Schemas; informally, these additional relationships
and annotations are taxonomy metadata. They are often first created, reviewed, and used in various
tabular styles, leaving the details of the technical syntax to software. Many submission types and exhibits
require a filer-constructed custom taxonomy as part of the submission.
Validation. An EDGAR submission with XBRL attachments proceeds through multiple validation steps
prior to acceptance. The validations are defined at several levels:
(a) file format syntax, be that defined by the syntax of XML, XML Schema, XHTML, or XBRL
specifications;
(b) syntax restrictions that are specific to EDGAR – for example, limitation on the XHTML tags that may
appear in Inline XBRL;
(c) semantic consistency of the instance – for example, ABC Inc’s Bonaire 2025 cannot be $10m one
location in an instance and $11m in another;
(d) semantic consistency of the facts and the meta data – for example, if country Barbados is not a
dimension, there can be no fact “ABC Inc’s Barbados Inventory”, and if it is present, Inventory should not
be a negative number; and
(e) submission-, form- and exhibit-specific checks – for example, instance type QF.US should have a
reporting period consistent with the 1st, 2nd or 3rd quarter of the company’s fiscal year.
All levels contribute to data quality although the term is mainly associated with levels (c), (d) and (e).
Generally, the consequences of failed validations are either XBRL Errors, which may cause suspension,
or XBRL Warnings, which do not cause suspension.
XBRL Submissions. Disclosure requirements that detail which entities are required to make what
disclosures at what times and under what circumstances are ultimately to be found in the SEC rules and/or
Form instructions. This document covers the steps for making those disclosures, and it details the
relevant validations. In that way this document supplements the EDGAR Filer Manual and XBRL
specifications, while providing a background for each individual Taxonomy Guide. The high-level steps
for an EDGAR submission with XBRL attachments are listed below:
9
1. Identify the correct Form type, submission type, and exhibits; this determines the instance type
[§ 6.1].
2. The relevant taxonomy entry points for that instance type [§ 6.3].
3. Identify the permitted formats for the instance attachments [§ 6.4]; choose valid mnemonic file
names.
4. Identify the facts that are expected; their absence could result in EDGAR suspending the submission.
5. Identify the facts required for the disclosure, especially those with EDGAR validation warnings.
6. Determine where there will be concepts reported for more than one event, asset class, business
segment or any disaggregation represented in the taxonomy and required in the disclosure.
7. Determine any non-standard (“custom”) concepts needed and their supporting properties.
8. Create the custom taxonomy (if needed) and files for the instance.
9. Validate the instance, interpret errors and warnings, and correct them.
10. Preview the submission as it will be rendered on the SEC.gov web site.
11. Validate the entire submission and all its attachments, usually as a TEST submission.
12. Resolve the errors and warnings, repeat 11 as needed, then submit as a LIVE submission.

2 XBRL Specifica�ons
XBRL International Inc. (XII) defines and updates the technical specifications, primers, test cases, and
other resources for XBRL syntax, via committees and working groups whose draft publications are open
to the public. EDGAR processes XBRL formatted files in submissions to create instances and validates
that they conform to specifications.
New versions of specifications are published at https://specifications.xbrl.org from time to time. EDGAR
does not use all parts nor the latest of all XII specifications. New specifications are not permitted in
EDGAR submissions until finalized. New specifications are permitted only through the periodic EDGAR
release and the filer manual update processes. The specifications currently governing the technical syntax
of all EDGAR instances are:
• XBRL version 2.1
• XBRL Calculations version 1.1
• XBRL Dimensions version 1.1
• XBRL Extensible Enumerations version 1.0
• XBRL Extensible Enumerations version 2.0
• XBRL Open Information Model (OIM) 1.0 Common
• xBRL-XML Mapping for OIM 1.0
Additionally, the current XII specification governing the Inline XBRL format of instances is:
• Inline XBRL version 1.1
XII publishes widely shared enhancements that do not require new specifications via registries. EDGAR
currently permits use of entries in these registries:
• XBRL Data Types Registry (DTR), versions 2020-01-21 and 2022-03-31 – all entries
• XBRL Unit Types Registry (UTR), versions 2022-07-20 – all entries
• Transformation Registries (TR) versions 2015-02-26, 2020-02-12, and 2022 – all entries

10
 • XBRL Link Role Registry (LRR) version 2022-09-28 – only those URIs starting
http://www.xbrl.org/lrr/

XII also creates and publishes taxonomies. Currently none of the XII taxonomies are EDGAR standard
taxonomies.

3 Instance Content
The content of an instance is illustrated here using Form 6-K.
EFM § 3 shows that Form 6-K may be submitted either as submission type 6-K or, if an amendment of a
prior 6-K, submission type 6-K/A. The tables in EFM v68 § 6 (duplicated in this document in section 11
below), show that:
• Submission types 6-K and 6-K/A are in submission set 6K [§ 6.1.1];
• Submission set 6K is paired only with entity set FPI and maps to instance type 6K.A [§ 6.1.3];
• Instance type 6K.A requires entry point dei and may use us-gaap or ifrs and any of the other
entry points on the row labeled ALL [§ 6.3];
• Instance type 6K.A is not one of the exceptions to the general requirement that the format be
Inline XBRL, so it is an Inline XBRL attachment. [§ 6.4].
The first few lines of the file shown below have a root html element and a namespace prefix ix that
establish it is an Inline XBRL file; see [§ 5.2.5] for more detail. The link:schemaRef attribute
xlink:href means that it uses the dei-sub entry point that contains labels, presentation, and definition
links of the 2024 version of the dei taxonomy:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:ix="http://www.xbrl.org/2013/inlineXBRL"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:dei="http://xbrl.sec.gov/dei/2024">
<head><title></title><meta http-equiv="Content-Type" content="text/html"/>
<body style="width: 7in"><div style="display: none">
<ix:header>
<ix:references>
<link:schemaRef xlink:type="simple"
xlink:href="https://xbrl.sec.gov/dei/2024/dei-sub-2024.xsd" />
</ix:references>
…

Regarding the Inline XBRL markup, the preparer of a 6K.A instance needs to know the following data
points:
• The form type, as distinct from the submission type;
• The company CIK and its EDGAR conformed name;
• The month and day of the current fiscal year end;
• For current reports in submission sets 8K and 6K, the date of the earliest event reported;
• In an amending submission (a submission type in submission set AM), whether the content of any
XBRL facts have changed; and
• If the content of any XBRL facts changed, how.
Each of these data points is represented in an instance as a fact in the same context.
11
3.1 Expected Facts in the Required Context
Every instance type has some facts that are expected to be present and have specific values in the
instance. Each such fact has a concept from a standard taxonomy as defined in EFM v68 § 6.2.2. The
context of the fact will have:
1. an entity identifier matching the filing CIK, and
2. either
a. no taxonomy-defined dimensions, or
b. a dimension from a standard taxonomy, and
3. either a period whose end date matches the reporting period end, which may be
a. an instant, or
b. a duration matching the quarter or year of the submission reporting period, or
c. a duration of one day.
Conditions 1, 2.a, and either 3b or 3c jointly define the required context. There may be more than one
context that matches all four conditions, in which case 3.c takes precedence over 3.b.
Every instance type has expected facts in a required context. For example, every instance must have a
fact in the required context having concept dei:EntityCentralIndexKey whose value is the 10-digit
CIK matching the CIK described in condition 1. One CIK must be chosen even when there are multiple
co-registrants in the submission.
Other contexts meeting conditions 1.b, 2, and 3 are defined below in relation to certain expected facts.
For example, some expected facts for multi-series filers expect a context with an explicit member of
dei:LegalEntityAxis and otherwise identical to the Required Context.

Expected facts may also be subject to additional conditions:

4. The fact may be required to be either present or absent (attribute xsi:nil = true is normally the
same as being absent).
5. The fact value may be expected to have a value that is consistent with
a. EDGAR’s existing data for a company, or
b. data from the EDGAR submission header, or
c. other facts in the same instance.
6. The fact may be expected outside of element ix:header of an Inline XBRL file [§ 5.2.5.14].
Inline XBRL permits the same concept to appear more than once in the same context, possibly
inside and outside of ix:header; in that case the condition of one occurrence appearing outside
ix:header is sufficient.

Symmetrically, there are also validations for unexpected facts. Facts that are expected for one instance
type may be unexpected (resulting in an XBRL warning or error) or optional (no warning or error is
produced) or for other instance types. These conditions vary by instance type.
3.1.1 Nota�on and Terminology
This guide describes each fragment of expected content in two tables, a Concepts table and a Validations
table.
The Concepts table shows:
• The concept with its standard namespace prefix (sometimes, an EDGAR header field);
• A concept # in the style {1}, {2} etc. to be referenced in the Validations table;
• An XML or XBRL data type, or a POSIX regular expression (regex) of possible string values;

12
 • A short indication of the concept meaning, which is often apparent from the concept name, along
with any detail notes such as related Inline XBRL transformations (in some tables the cell is
blank because the concept has been defined in a previous Concepts table).
An example Concepts table is shown below.
Concept # Type or regex Meaning
dei:EntityCentralIndexKey {1} \d{10}
EDGAR CIK
The Validations table shows:
• Included submission sets (prefixed by “s: ”) and included instance types (prefixed by “i: ”)
• Excluded submission sets (prefixed by “s: ”) and excluded instance types (prefixed by “i: ”)
• c - a code indicating the contexts to which it applies (r: required; a: all; etc.)
• Check - the condition to be tested
• f - a footnote indication for special cases, exceptions, or additional detail notes,
• On failure – the condition raised when the check fails,
• s - the severity of the violation (E: Error, W: Warning),
• and (in this version of the guide) a reference to version 68 of the EDGAR Filer Manual (for
example, “§ 6.5.21 X” refers to the code X appearing in the table of section 6.5.21; “§ 6.5.46 []”
refers to a blank cell in the table of section 6.5.46).
An example validations table is shown below.
Incl Excl c Check f On failure s EFM v68 Ref
i: ALL r A {1} fact is present. {1} Missing E § 6.5.21 X*
The consequences of an XBRL Error may vary depending on the instance type, as discussed in [§ 6.6].
However, an XML syntax error (such as a five-digit number where a ten-digit number is required or an
unknown country code) always results in an XBRL Error. Failed validations of expected facts may be
Errors or Warnings.
XBRL Warnings indicate that facts found in the instance are in some way incomplete, inconsistent with
each other, misleading, ambiguous, or unreliable and this will have undesirable downstream consequences
for users of the data. Filers should avoid XBRL warnings by correcting the data prior to live submission.
Within the validations table, a fact is visible in an Inline XBRL file if it is not located within the
ix:hidden element. If the fact has duplicates, at least one must be located outside of ix:hidden. A fact
is present in a context if it has a non-nil value; a fact is deemed to be absent if it either does not exist or
exists only with a nil value.
Each validations table is followed by notes or special cases from the footnote column.
3.1.2 Required Context valida�on
There is a check for the existence of a required context applying to all instances:
Concept # Type or regex Meaning
The CIK of any one company {1} \d{1,10} EDGAR CIK
in the submission header
The period of the submission {2} \d{1,2}-\d{1,2}-\d{4} Reporting period if present
header
13
 Filing date, which may be
The filing date of the {3} \d{1,2}-\d{1,2}-\d{4} the same or later than the
submission
acceptance date.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
Non
All contexts have an identifier element value Matching
i:ALL § 6.5.3
equal to {1}. Cik
There is a context having endDate value
Required
i:ALL matching either {2} or {3}, and no segment Context E § 6.5.19
element.
Notes and special cases: none.
3.1.3 Central Index Key
Concept # Type or regex Meaning
dei:EntityCentralIndexKey {1} \d{10} EDGAR CIK
Validations:
Incl Excl c Assertion f On failure s EFM v68 Ref
{1}
i: ALL r A {1} fact is present. Missing E § 6.5.21 X*
A {1} fact with value a full
ten-digit CIK from among
i: K.SDR, {1}
r the co-registrants in the Value E § 6.5.23
L.SDR
submission header or equal
to 0000000000.
A {1} fact with value a full
ten-digit CIK other than
i: K.SDR, {1}
i: ALL r 0000000000 from among 1 Value E § 6.5.23
L.SDR
the co-registrants in the
submission header.
Notes and special cases:
1. Instance types K.SDR and L.SDR permit a CIK value of 0000000000 that could not appear in the
submission header. 00000000000 represents an entity that is not an EDGAR registrant.
3.1.4 Registrant Name
Concept # Type or regex Meaning
dei:EntityRegistrantName {1} xs:normalizedString EDGAR registrant conformed name,
with some differences permitted
Validations:

14
 Incl Excl c Check f On failure s EFM v68 Ref
{1}
i: ALL r A {1} fact is present. Missing E § 6.5.21 X, X*
A value of {1} matches the
EDGAR conformed name 1, {1}
Submission E
i: ALL r § 6.5.24 X
of the company whose CIK 2 Value
is.
{1} in
If {1} facts are present, Facts Not
s: FAST r W § 6.5.21 X*, 6.5.45 X
then at least one is visible. Visible
If no {1} fact with
i: AF.CA, xml:lang value en-US
AF.FPI, matches, then a matching -
r 3 E § 6.5.24
R33.FPI, {1} fact with a language
R34.FPI not starting with en- is
present.
i: AF.CA,
{1}
AF.FPI, The matching {1} fact has Submission
i:ALL r E § 6.5.24 X
R33.FPI, xml:lang value en-US. Value
R34.FPI
Notes and special cases:
1. The conformed name must be a case-insensitive prefix of the fact value. For example, conformed name
"SMITH" would match fact text "Smith, John". These differences are ignored:
a. Differences in whitespace or punctuation; hyphen characters (-, -) may either match whitespace or
nothing. For example, "ABC Real-time" will match both "A.B.C. RealTime" and "ABC, Real
Time".
b. Single-character words are ignored; "A. B. SMITH" will match "SMITH A".
c. Text entered between "//", such as "ABC CO /DE/", matches "ABC CO".
d. Matching abbreviations that EDGAR imposes, such as truncating CORPORATION to CORP,
shortening "and" to ampersand "&", and dropping the word "The" at the beginning. For
example, "The Smith and Jones Corporation" matches "SMITH & JONES CORP".
2. When the required context CIK is 00000000000, the name match is waived.
3. The cover pages of certain forms distinguish the "Exact name of Registrant as specified in its
charter" from the "Translation of Registrant’s name into English". If either differs from the
conformed name, then an additional dei:EntityRegistrantName fact with an xml:lang attribute
value not starting with en is expected.
3.1.5 Form or Exhibit Type
Concept # Type or regex Meaning
[A-Z0-9]+([/A-Z0-9 \.\-
dei:DocumentType {1} ]*[A-Z0-9])?|Other Form or Exhibit Type (often differs
(Up to 20 characters) from the submission type).

Validations:

15
 Incl Excl c Check f On failure s EFM v68 Ref
{1}
i:ALL FE r A {1} fact is present. Missing E § 6.5.20 X*
The {1} fact value is among the Form 1,
i:ALL FE r types permitted for the submission type as 2, {1} Value E § 6.5.20
shown in EFM § 3. 3
{1}
i:FE r A {1} fact is absent. Unexpected W § 6.5.20 []

Notes and special cases:

1. For compatibility with earlier EDGAR releases, dei:DocumentType may match the submission type
without a warning, but this usage is discouraged and may soon be deprecated and result in a warning or
error.
2. In some cases, there may be an inferred entity set and inferred submission set based on the combination
of submission type, the value of DocumentType, and the value of submission header field investment-
CompanyType, with or without a warning (previously § 6.5.56).

Value of Inferred
Value of investment- Inferred submission Severity
Submission types dei:DocumentType CompanyType entity sets sets
485APOS, 485BPOS N-3 V3 [§ 6.1] W
485APOS, 485BPOS N-4 V4 [§ 6.1] W
485APOS, 485BPOS N-6 V6 [§ 6.1] W
485APOS, Not N-3, not N-4
OEF [§ 6.1] W
485BPOS, 485BXT and not N-6
POS AM, POS EX Matches POS.* S-1 or S-3 US RD W
POS AM, POS EX Matches POS.* N-1A OEF RD W
POS AM, POS EX Matches POS.* N-2 CEF RD W
POS AM, POS EX Matches POS.* N-3 V3 RD W
POS AM, POS EX Matches POS.* N-4 V4 RD W
POS AM, POS EX Matches POS.* N-6 V6 RD W
POS AM, POS EX Matches POS.* (absent) US R33 W
All other cases [§ 6.1]
3. Note that the entity and/or submission set, when inferred from dei:DocumentType, may not be what
the filer intended; this can lead to other warnings or errors; therefore, using the value of the underlying
form type (without /A) for dei:DocumentType is always preferred.
3.1.6 Amendment Flag and Descrip�on
Concept # Type or regex Meaning
Value is true if the content of an instance changed from
a previous submission that this amends, and false
dei:AmendmentFlag {1} xs:boolean otherwise. This is not the same as the “/A” indicator on
an EDGAR submission type; it is possible for an “/A”
submission to amend only material that was not XBRL
tagged content.
dei:Amendment-
{2} xs:string
Description A description of the changes in the amendment.

Validations:

16
 Incl Excl c Check f On failure s EFM v68 Ref
i: ALL i: FE.A r A {1} fact is present. {1} Missing W § 6.5.20 R*
i: FE.A r A {1} fact is absent. {1} Unexpected W § 6.5.20 []
If a {1} fact with value true is
r present, then a {2} fact is {1} {2} Value
i: ALL Dependency W § 6.5.20 A
present.
i: ALL r If a {1} fact with value false is {1} {2} Value
W § 6.5.20 A
present, then a {2} fact is absent. Dependency
i: FE.A,
r {2} in Facts
i: ALL OA.RXP, If {2} is present, it is visible. Not Visible W § 6.5.20 A
OA.SDR
Notes and special cases: none.
3.1.7 Document Period End Date
Concept # Type or regex Meaning
Many EDGAR submission types have a header field
dei:Document- periodOfReport. For most of these, it represents the end
{1} xs:date
PeriodEndDate date of a reporting or transition period. For current reports
(8K, 6K submission types) it represents the date of the
earliest event reported.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
{1}
s: 8K r A {1} fact is present. 1 Missing W § 6.5.20 R
s: FAST,
{1}
AF.OEF, s: 8K r A {1} fact is present. 2 Missing W § 6.5.20 R
HF.OEF
s: FAST, If {1} facts are present, {1} in
AF.OEF, r then at least one is Facts Not W § 6.5.45 R
HF.OEF visible. Visible
s: 6K, {1}
r A {1} fact is present. 3 Missing W § 6.5.20 R*
i: OA.SDR
s: RD, R33, R34, 4, {1} § 6.5.20 R*,
A {1} fact is present. Missing W
R40 5 O*

17
 Incl Excl c Check f On failure s EFM v68 Ref
s: FAST,
AF.OEF, If the submission header
HF.OEF, 6K, field periodOfReport is
{1} Value
§ 6.5.40 Case
R33, R34, R40, r present, then its date W
(2)
6K, RD, R33, matches the value of
R34, R40, {1}.
i: OA.SDR
s: FAST,
AF.OEF,
HF.OEF,
6K, R33,
{1} § 6.5.20 [],
s: ALL R34, R40, r A {1} fact is absent. 5 Unexpected W
O*
6K, RD,
R33, R34,
R40,
i: OA.SDR
Notes and special cases:
1. Use the date of earliest event reported.
2. Use the end of the reporting or transition period.
3. Use the end of the period reported.
4. Use the filing date.
5. Check is waived when the submission type matches POS*
3.1.8 Document Fiscal Year and Period Focus
Concept # Type or regex Meaning
dei:DocumentFiscalYearFocus {1} xs:gYear (matches YYYY) Filer’s fiscal year.
dei:DocumentFiscalPeriodFocus {2} Q1|Q2|Q3|FY
Fiscal period of the report.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: AF i: AF.OEF r A {1} fact is present. {1} Missing W § 6.5.20 R*
Neither or both {1} and {1} {2} Mutual
s: ALL r 1 Dependency W § 6.5.20 Op*
{2} are present.

s: FAST, R33, § 6.5.20 [],

s: ALL r A {1} fact is absent. 1 {1} Unexpected W
R34 Op*
A {2} fact is {2} Missing
s: AF i: AF.OEF r W § 6.5.20 R*
present.
s: FAST, R33, § 6.5.20 [],
s: ALL r A {2} fact is absent. 1 {2} Unexpected W
R34 Op*

Notes and special cases:

1. Waived for submission types matching POS.*.

18
3.1.9 Current Repor�ng Status and Interac�ve Data Current
Both dei:EntityCurrentReportingStatus and dei:EntityInteractiveDataCurrent facts in the
required context are expected for most financial statements and optional for certain FPI instances.
Concept # Type or regex Meaning
Registrant has (1) filed all reports required to be filed by
Section 13 or 15(d) of the Securities Exchange Act of 1934
dei:Entity-
Current- {1} Yes|No
during the preceding 12 months (or for such shorter period
ReportingStatus that registrants were required to file such reports), and (2)
have been subject to such filing requirements for the past
90 days.
The registrant has submitted electronically every Interactive
dei:Entity- Data File required to be submitted pursuant to Rule 405 of
Interactive- {2} Yes|No Regulation S-T during the preceding 12 months (or for such
DataCurrent shorter period that the registrant was required to submit
such files).

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: AF i: AF.OEF r A {1} fact is present. {1} Missing W § 6.5.21 R
If {1} facts are present,
{1} in Facts
s: AF i: AF.OEF r then at least one is Not Visible W § 6.5.21 R
visible.
i: R34.CA, {1} Unexpected
§ 6.5.21 [],
s: ALL r A {1} fact is absent. W
R34.FPI O*
s: AF i: AF.OEF r A {2} fact is present. {2} Missing W § 6.5.21 R
If {2} facts are present,
{2} in Facts
s: AF i: AF.OEF r then at least one is Not Visible W § 6.5.21 R
visible.
i: R34.CA, {2} Unexpected
§ 6.5.21 [],
s: ALL r A {2} fact is absent. W
R34.FPI O*
Notes and special cases: none
3.1.10 Voluntary Filers, Shell Companies, and Well-known Seasoned Issuers
Concept # Type or regex Meaning
dei:EntityVoluntaryFilers {1} Yes|No
Registrant is “not required to file”.
Registrant is a well-known
dei:EntityWellKnownSeasonedIssuer {2} Yes|No seasoned issuer, as defined in Rule
405 of the Securities Act
Registrant is a shell company as
dei:EntityShellCompany {3} xs:boolean defined in Rule 12b-2 of the
Exchange Act

Validations:

19
 Incl Excl c Check f On failure s EFM v68 Ref
i: AF.US,
AF.BDC, r A {1} fact is present. {1} Missing W § 6.5.21 R
AF.FPI
i: AF.US, If {1} facts are present, then at {1} in Facts
r Not Visible W § 6.5.45 R
AF.FPI least one is visible.
If header element
i: AF.US,
voluntaryFilerFlag has a value, § 6.5.40
AF.BDC, r {1} Value W
then it is equivalent to the {1} fact Item 3
AF.FPI
value.
i: AF.US,
{1}
s: ALL AF.BDC, r A {1} fact is absent. Unexpected W § 6.5.21 []
AF.FPI
i: AF.US,
AF.BDC, r A {2} fact is present. {2} Missing W § 6.5.21 R
AF.FPI
i: AF.US,
If {2} facts are present, then at {2} in Facts
AF.BDC, r Not Visible W § 6.5.45 R
least one is visible.
AF.FPI
If header element wellKnown-
i: AF.US,
SeasonedIssuerFlag has a value, § 6.5.40
AF.BDC, r {2} Value W
then it is equivalent to the {2} fact Item 4
AF.FPI
value.
i: AF.US,
{2}
s: ALL AF.BDC, r A {2} fact is absent. Unexpected W § 6.5.21 []
AF.FPI
i: AF.US,
AF.BDC, r A {3} fact is present. {3} Missing W § 6.5.21 R
AF.FPI
i: AF.US, If {3} facts are present, then at {3} in Facts
AF.BDC, r least one is visible. Not Visible W § 6.5.45 R
AF.FPI
i: AF.US, If header element
AF.BDC, shellCompanyFlag has a value, {3} Value
§ 6.5.40
r W
AF.FPI then it is equivalent to the {3} fact Item 5
value.
i: AF.US,
{3}
s: ALL AF.BDC, r A {3} fact is absent. Unexpected W § 6.5.21 []
AF.FPI
{1} {2}
At most one of {1} and {2} has the Exclusive
s: ALL a W § 6.5.21 WV
value Yes or true. Value
{2} {3}
At most one of {2} and {3} has the Exclusive
s: ALL a W § 6.5.21 WS
value Yes or true. Value

Notes and special cases: none.

20
3.1.11 Small Business, Emerging Growth Company
Concept # Type or regex Meaning
dei:EntitySmall-
{1} xs:boolean
Indicates that the company is a Smaller Reporting
Business Company (SRC).
dei:Entity-
EmergingGrowth- {2} xs:boolean
Indicates a registrant that meets the emerging growth
Company company criteria.
Indicates an emerging growth company has elected not
dei:Entity-
{3} xs:boolean to use the extended transition period for complying with
ExTransitionPeriod
any new or revised financial accounting standards.

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.US,
AF.BDC,
AF.OEF, {1} § 6.5.40 R,
r A {1} fact is present. 1 Missing W
QF.US, R*
R33.US,
R34.US
A {1} fact with value true is {1} Value
i: AF.BDC r W § 6.5.40 SB
absent.
i: AF.US, If header element
AF.BDC, smallBusinessFlag for the
AF.OEF, filer with the CIK of the {1} Value
§ 6.5.40
r 1 W
QF.US, required context, then a {1} Item 9
R33.US, fact is present with that fact
R34.US value.
i: AF.US, {1} in
If {1} facts are present, then Facts Not
§ 6.5.40 R
AF.BDC, r W
at least one is visible. Visible § 6.5.45
QF.US
i: AF.US,
AF.BDC,
AF.OEF, {1}
s: ALL r A {1} fact is absent. 1 Unexpected W § 6.5.40 []
QF.US,
R33.US,
R34.US
s: FAST,
i: R33.US, {2} § 6.5.40 R,
r A {2} fact is present. 1 Missing W
R33.FPI, R*
R34
If there is a value for
emergingGrowthCompany-
Flag in the header for the {2}
filer with the CIK of the Submission
§ 6.5.40
s: ALL r 1 W
required context, then a {2} Value Item 6
fact is present with that
value.

21
 Incl Excl c Check f On failure s EFM v68 Ref
{1} in
If {2} facts are present, then Facts Not
s: FAST r W § 6.5.40 R
at least one is visible. Visible

s: FAST,
R34, {2}
s: ALL r A {2} fact is absent. 1 Unexpected W § 6.5.40 []
i: R33.US,
R33.FPI,

s: FAST,
If a {2} fact valued true is
i: R33.US, 1, {2} {3}
Value
a present, then a {3} fact is E § 6.5.40 ET
R33.FPI, 2 Dependency
present.
R34
s: FAST, If a {2} fact does not have
i: R33.US, 1, {2} {3}
§ 6.5.40 ET,
a value true, then a {3} fact is Value W
R33.FPI, absent. 2 Dependency ET*
R34
If {3} facts are present, then {3} § 6.5.40 ET,
s: FAST r Unexpected W
at least one is visible. § 6.5.45
s: FAST,
R34, {3}
s: ALL r A {3} fact is absent. 1 Unexpected W § 6.5.40 []
i: R33.US,
R33.FPI
If there is a value for
exTransitionPeriodFlag
in the header for the filer {3}
Submission
§ 6.5.40
s: ALL r with the CIK of the required 1 W
Value Item 7
context, then a {3} fact is
present with that value.
Notes and special cases:
1. Check is waived when the submission type matches POS.*.
2. Check does not apply to instance type RD.CEF; see 3.1.24.7 below.
3.1.12 Current Fiscal Year End Date
Concept # Type or regex Meaning
{1} Month and day marking the end of the
dei:CurrentFiscalYear- xs:gMonthDay
EndDate (matches --MM-DD) company’s fiscal year; it normally does
not change from year to year.

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: AF, QF,
6K, i: AF.OEF, 1 {1}
r A {1} fact is present. Missing W § 6.5.21 R, R*
i: K.SDR, AF.CEF
L.SDR
i: AF.OEF, If {1} facts are present, then {1} in § 6.5.21 R
s: AF r Facts Not W
AF.CEF at least one is visible. Visible § 6.5.45

22
 Incl Excl c Check f On failure s EFM v68 Ref
If {1} is present, and there is
s: 8K, AF, a value for fiscalYearEnd
QF, 6K, in the header for the filer {1}
2, Submission § 6.5.21 [], O*,
r W
i: K.SDR, with the CIK of the required 3 Value § 6.5.40 Item 1
L.SDR context, then the {1} fact is
present with that value.
s: AF, QF,
6K,
i: R34.FPI, {1}
s: ALL r A {1} fact is absent. Unexpected W § 6.5.21 [], O*
R34.CA,
K.SDR,
L.SDR
If Item 5.03 is indicated in {1}
1, Submission
s: 8K r the header, then {1} is W § 6.5.21 E503
2 Value
present.
If Item 5.03 is not indicated
{1}
s: 8K r in the header, then {1} is Unexpected W § 6.5.21 E503
absent.
Notes and special cases:
1. Co-registrants in the header may have different fiscal year ends; only one is relevant to value tests.
2. The header field fiscalYearEnd is in format MM/DD, and in XBRL data type gMonthDay as --MM-
DD.
3. L.SDR instances with CIK of 0000000000 are exempt from the fiscal year end date value check.
3.1.13 Filer Category (Accelerated / Non-Accelerated)
Concept # Type or regex Meaning

(Large Accelerated Filer Status.

dei:EntityFiler- Note that the possible values
{1} Accelerated|Accelerated|Non-
Category
accelerated) Filer are case-sensitive, have
spaces and a dash.

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.US,
AF.BDC,
QF.US, 1
{1} § 6.5.21 R,
r A {1} fact is present. Missing W
AF.FPI, R*
R33.US,
R34.US
i: AF.US,
{1} in
AF.BDC, If {1} facts are present, then at least Facts Not
§ 6.5.21 R
r W
QF.US, one is visible. Visible § 6.5.45
AF.FPI

23
 Incl Excl c Check f On failure s EFM v68 Ref
i: AF.US,
AF.BDC,
QF.US, An {1} fact is absent. 1
{1}
s: ALL r Unexpected W § 6.5.21 []
AF.FPI,
R33.US,
R34.US
If the value of accelerated-
i: AF.US,
FilerStatus in the header for the
AF.BDC,
filer with the CIK of the required {1}
QF.US, § 6.5.40 Item
r context is Large Accelerated 1 Submission W
AF.FPI, Value 10
Filer, then a {1} fact value
R33.US,
starting with Large Accelerated
R34.US
Filer is present.
i: AF.US, If the value of accelerated-
AF.BDC, FilerStatus in the header for the
{1}
QF.US, filer with the CIK of the required § 6.5.40 Item
r 1 Submission W
AF.FPI, context is Accelerated Filer, Value 11
R33.US, then a {1} fact value starting with
R34.US Accelerated Filer is present.
If the value of accelerated-
FilerStatus in the header for the
i: AF.US, filer with the CIK of the required
AF.BDC, context is neither Large
{1}
QF.US, Accelerated Filer nor § 6.5.40 Item
r 1 Submission W
AF.FPI, Accelerated Filer, then a {1} Value 12
R33.US, fact is present in the required
R34.US context with a value that starts with
neither Large Accelerated Filer
nor Accelerated Filer.
i: AF.US,
AF.BDC, If there is no accelerated-
QF.US, FilerStatus in the header for the {1} § 6.5.40 Item
r 1 W
AF.FPI, filer with the CIK of the required Unexpected 13
R33.US, context, then a {1} fact is absent.
R34.US
Notes and special cases:
1. Checks waived when the submission type matches POS.*.
3.1.14 ICFR Auditor Atesta�on Flag
A dei:IcfrAuditorAttestationFlag fact is expected for US and FPI financial statements of
accelerated and large accelerated filers, but optional for Canadian and Non-accelerated filers.
Concept # Type or regex Meaning
Note that the
(Large
dei:EntityFilerCategory {1} Accelerated|Accelerated|Non-
possible values
accelerated) Filer have spaces and
a dash.

24
 dei:IcfrAuditorAttestationFlag {2} xs:boolean

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If the value of {1} is “Large
i: AF.US,
Accelerated Filer” or {2}
AF.BDC, r Missing W § 6.5.21 Ra
AF.FPI
“Accelerated Filer”, then a
{2} fact is present.
i: AF.US,
If {2} facts are present in the {2} in
AF.BDC, Facts Not
r required context, then at least W § 6.5.45 Ra
AF.FPI, Visible
one is visible.
AF.CA
i: AF.US,
AF.BDC, {2}
s: ALL a A {2} fact is absent. Unexpected W § 6.5.21 [], O
AF.FPI,
AF.CA
Notes and special cases: none.
3.1.15 Public Float
A dei:EntityPublicFloat fact is expected for certain instance types in an instant (not duration) context.
Concept # Type or regex Meaning
A filer having no common shares outstanding will have
dei:EntityPublic-
{1} xs:decimal a $0 public float fact, not nil; debt and other tiers of
Float
equity are not measured in the public float.

A context that has period type instant, no taxonomy-defined dimensions, and a date equal to or after the
end date of the period of the required context is called a Subsequent Event (se) context.
Validations:
Incl Excl c Assertion f On failure s EFM v68 Ref
i: AF.US, {1} Missing
se A {1} fact is present. W § 6.5.21 R
AF.BDC
If {1} facts are
i: AF.US, {1} in Facts § 6.5.21 R
se present, then at least Not Visible W
AF.BDC § 6.5.45
one is visible.
i: AF.US, {1}
s: ALL se A {1} fact is absent. Unexpected W § 6.5.21 []
AF.BDC
Notes and special cases: none.
3.1.16 Auditor Name, Loca�on, and Firm ID
Three facts must appear together for annual financial statements for periods ending after 12/31/2020.
Concept # Type or regex Meaning
[\p{L}\p{N}].* up to 150 characters;
The plain text (not logo
dei:AuditorName \p{L} matches a single letter and \p{N}
{1} nor signature) name of
matches any kind of numeric character in
the auditor
any language.

25
 City along with either or
dei:AuditorLocation {2}
both of country, US
[\p{L}\p{N}].* up to 150 characters. state, or Canadian
province
The auditor’s Firm ID
dei:AuditorFirmId {3} [1-9]\d* an integer with no leading sign or as assigned by the US
zeroes. PCAOB.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.US,
AF.BDC, {1} Missing
§ 6.5.21 H
s: AM r A {1} fact is present. 1 E
AF.FPI, § 6.5.54
AF.CA
i: AF.US, If {1} facts are present
AF.BDC, in the required context, {1} in Facts § 6.5.21 H
r 2 Not Visible W
AF.FPI, then at least one is § 6.5.54
AF.CA visible.
i: AF.US,
AF.BDC, {1}
s: ALL r A {1} fact is absent. 1 Unexpected E § 6.5.21 []
AF.FPI,
AF.CA
i: AF.US,
AF.BDC, {2} Missing
§ 6.5.21 H
s: AM r A {2} fact is present. 1 E
AF.FPI, § 6.5.54
AF.CA
i: AF.US, If {2} facts are present
AF.BDC, in the required context, {2} in Facts § 6.5.21 H
r 2 Not Visible W
AF.FPI, then at least one is § 6.5.54
AF.CA visible.
i: AF.US,
AF.BDC, {2}
s: ALL r A {2} fact is absent. 1 Unexpected E § 6.5.21 []
AF.FPI,
AF.CA
i: AF.US,
AF.BDC, {3} Missing
§ 6.5.21 H
s: AM r A {3} fact is present. 1 E
AF.FPI, § 6.5.54
AF.CA
i: AF.US, If {3} facts are present
AF.BDC, in the required context, {3} in Facts § 6.5.21 H
r 2 Not Visible W
AF.FPI, then at least one is § 6.5.54
AF.CA visible.

26
 Incl Excl c Check f On failure s EFM v68 Ref
i: AF.US,
AF.BDC, {3}
s: ALL r A {3} fact is absent. 1 Unexpected E § 6.5.21 []
AF.FPI,
AF.CA
If any of {1}, {2}, or
1, {1} {2} {3}
Mutual
s: ALL a {3}, are present, then all E § 6.5.54
3 Dependency
three are present.

Notes and special cases:

1. Absence (or unexpected presence) has severity Error, not Warning as it is for most expected facts.
2. The code {_} in Facts Not Visible does not mean that auditor information must literally appear
on a cover page. These facts should appear in an Inline XBRL file where they normally appear,
adjacent to the auditors’ opinions.
3. In addition to the primary auditor in the required context, additional auditor names, locations and firm
IDs should be tagged in other contexts distinguished by the relevant reporting period of that audit
opinion, and/or a distinct member of one of the following axes in a standard namespace:
a. ConsolidatedEntitiesAxis for subsidiaries,
b. ScheduleOfEquityMethodInvestmentEquityMethodInvesteeNameAxis for investments,
c. LegalEntityAxis for branches,
d. OwnershipAxis for components,
e. CounterpartyNameAxis for all others.
3.1.17 Investment Company Type
Concept # Type or regex Meaning
Investment Company Type. Note that
N-1A|N-1|N-2|N-
dei:EntityInvCompanyType {1} 3|N-4|N-6|S-1 or
one of the possible values is the literal
S-3|S-6 token S-1 or S-3, these are not
alternative values.

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: RD r A {1} fact is present. 1 {1} Missing W § 6.5.40 R*
s: ALL s: RD r A {1} fact is absent. 1 {1} Value W § 6.5.40 []
If header element invCompanyType
for the filer with the CIK of the {1} Value
§ 6.5.40
s: RD r 1 W
required context, then a {1} fact is Item 8
present with that fact value.
Notes and special cases:
1. Checks waived for submission types matching POS.*.

27
3.1.18 File Number (Securi�es Act File Number)
Concept # Type or regex Meaning
dei:EntityFile- Securities (“33”) Act file
{1} \d{1,3}-\d{1,8}(-.{1,4})?
Number number.

Validations:
Incl Excl c Assertion f On failure s EFM v68 Ref
s: FAST r A {1} fact is present. {1} Missing W § 6.5.47 Ri
s: FAST, 6K, {1} § 6.5.47 [], O*
s: ALL r A {1} fact is absent. Unexpected W
i: R34.FPI, R34.CA § 6.5.55 n2sn
Notes and special cases: none.
3.1.19 Incorpora�on State / Country Code
Concept # Type or regex
Meaning
Two-character EDGAR code. US States and Canadian
provinces are represented by their postal code (e.g., WA,
dei:Entity-
BC); other countries by a code matching [A-Z]\d.
Incorporation- {1} [A-Z][A-Z0-9]
StateCountryCode Transformation ixt-sec:edgarprovcountry (EFM §
5.2.5.12) transforms the full names of countries and
Canadian provinces to their EDGAR codes.

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: FAST r A {1} fact is present. {1} Missing W § 6.5.47 Ri
If {1} facts are present, {1} in Facts Not
s: FAST r Visible W § 6.5.47 Ri
then at least one is visible.
s: FAST, {1} Unexpected
§ 6.5.47 [],
s: ALL r A {1} fact is absent. W
R33, R34 O*
Notes and special cases: none.
3.1.20 Tax Iden�fica�on Number
Concept # Type or regex Meaning
dei:EntityTaxIdentification-
{1} \d{2}-\d{7}
Shown on forms as “IRS Employer
Number ID”.
Validations:
Types Excl c Assertion f On failure s EFM v68 Ref
{1} Missing
§ 6.5.47 Ri,
s: FAST i: AF.CA r A {1} fact is present. W
O
If {1} facts are present, {1} in Facts § 6.5.47 Ri,
s: FAST r Not Visible W
then at least one is visible. O
s: FAST, R34, {1} Unexpected
§ 6.5.47 [],
s: ALL r A {1} fact is absent. W
i: AF.CA O*
Notes and special cases: none.

28
3.1.21 Primary SIC (Standard Industrial Code) Number
Concept # Type or regex Meaning
dei:EntityPrimarySicNumber {1} \d{4} SEC-assigned Standard Industrial Code
Validations:
Incl Excl c Assertion f On failure s EFM v68 Ref
If {1} are present, then {1} in Facts
AF.CA r Not Visible W § 6.5.47 O
at least one is visible.
{1} Unexpected
§ 6.5.47 [],
s: ALL s: R34, i: AF.CA r A {1} fact is absent. W
O*
Notes and special cases: none
3.1.22 Principal Office Address
The facts expected for the principal office address vary across instance types.
3.1.22.1 Street, City and Zip
Concept # Type or regex Meaning
dei:EntityAddressAddressLine1 {1} xs:normalizedString
dei:EntityAddressCityOrTown {2} xs:normalizedString
dei:EntityAddressPostalZipCode {3} xs:normalizedString

The first line of the address, the city or town, and postal or zip code, share identical checks.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: FAST r A {1} fact is present. {1} Missing W § 6.5.48 Ri
If {1} facts are present in {1} in
s: FAST r the required context, then Facts Not W § 6.5.48 Ri
at least one is visible. Visible
s: FAST, 6K, R34, {1} § 6.5.48 [],
s: ALL r A {1} fact is absent. Unexpected W
R33 O*
s: FAST r A {2} fact is present. {2} Missing W § 6.5.48 Ri
If {2} facts are present in {2} in
s: FAST r the required context, then Facts Not W § 6.5.48 Ri
at least one is visible. Visible
s: FAST, 6K, R34, {2} § 6.5.48 [],
s: ALL r A {2} fact is absent. Unexpected W
R33 O*
s: FAST r A {3} fact is present. {3} Missing W § 6.5.48 Ri
If {3} facts are present in {3} in
s: FAST r the required context, then Facts Not W § 6.5.48 Ri
at least one is visible. Visible
s: FAST, 6K, R34, {3} § 6.5.48 [],
s: ALL r A {3} fact is absent. Unexpected W
R33 O*
Notes and special cases: none.
3.1.22.2 Street Address Lines 2 and 3
Concept # Type or regex Meaning
dei:EntityAddressAddressLine1 {1} xs:normalizedString

29
 Concept # Type or regex Meaning
dei:EntityAddressAddressLine2 {2} xs:normalizedString
dei:EntityAddressAddressLine3 {3} xs:normalizedString

Address line 2 should only appear if the first line does, likewise, address line 3 only if address line 2 does.
This should hold in any context.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
§ 6.5.48
If a {2} fact is
{1} {2} OL1*
s: ALL a present, then a {1} 1 Dependency W
§ 6.5.51
fact is also present.
OL1*
If {2} facts are {2} in
s: FAST, Facts Not
r present, then at least W § 6.5.48 O
i: RD.CEF Visible
one is visible.
s: FAST, 6K, R34,
{2}
s: ALL i: RD.CEF, R33.US, r A {2} fact is absent. Unexpected W § 6.5.48 []
R33.FPI
§ 6.5.48
If a {3} fact is
{2} {3} OL2, OL2*
s: ALL a present, then a {2} Dependency § 6.5.51
fact is also present.
OL2, OL2*
If {3} facts are {3} in
s: FAST, Facts Not
r present, then at least W § 6.5.48 OL2
i: RD.CEF Visible
one is visible.
s: FAST, 6K, R34,
{3} § 6.5.48 [],
s: ALL i: RD.CEF, R33.US, r A {3} fact is absent. Unexpected W
OL2*
R33.FPI
Notes and special cases:
1. Condition OL1 is satisfied if address line 2 is present; address line 1 is already required.
3.1.22.3 State or Province and Country
Concept # Type or regex Meaning
dei:Entity- Postal state or province. Inline XBRL transformations
AddressState- {1} [A-Z][A-Z] that convert state and province names to postal codes
OrProvince
(e.g., TX, ON) shown in EFM § 5.2.5.12.
dei:Entity- ISO 3166-1 alpha 2 (IANA) country code. Inline XBRL
AddressCountry {2} [A-Z][A-Z] transformations convert country names to IANA () codes
(e.g., US, JP) are shown in EFM § 5.2.5.12.
Validations:
Incl Excl c Check f Codes s EFM v68 Ref
One or both {1}
s: FAST, {1} {2}
i: AF.FPI r and {2} facts are 1 Inclusive W § 6.5.48 O2
i: RD.CEF
present.
If {1} facts are
s: FAST, {1} in Facts § 6.5.48 O,
r present, then at Not Visible W
i: RD.CEF O2
least one is visible.

30
 Incl Excl c Check f Codes s EFM v68 Ref
A {2} fact is {2} Missing
i: AF.FPI r W § 6.5.48 Ri
present.
If {2} facts are
s: FAST, {2} in Facts § 6.5.48 O2,
r present, then at Not Visible W
i: RD.CEF Ri
least one is visible.
s: FAST, R34, {1} § 6.5.48 [],
s: ALL r A {1} fact is absent. Unexpected W
R33, i: RD.CEF O*
s: FAST, 6K, R34,
{2} § 6.5.48 [],
s: ALL i: R33.US, r A {2} fact is absent. Unexpected W
O*
R33.FPI
Notes and special cases: none.
3.1.22.4 Phone
Concept # Type or regex Meaning
dei:CityAreaCode {1} xs:normalizedString
dei:LocalPhoneNumber {2} xs:normalizedString

Validations:
Types Excl c Check f On failure s EFM v68 Ref
i: R34.US,
R34.CA, Neither or § 6.5.48
R33.US, both of a {1} 1, {1} {2} Oph*,
a Dependency W
R33.FPI, fact and a {2} 2 § 6.5.51 Oph,
AF.FPI, fact is present. Oph*
RD.CEF
s: 8K, QF,
i: AF.US, A {1} fact is {1} Missing
r W § 6.5.48 Ri
AF.BDC, present.
RD.CEF, AF.CA
s: 8K, QF, If {1} facts
{1} in
i: AF.US, are present, Facts Not
r W § 6.5.48 Ri
AF.BDC, then at least Visible
RD.CEF, AF.CA one is visible.
s: 8K, QF, i: AF.US,
AF.BDC, RD.CEF,
A {1} fact is {1} § 6.5.48 [],
s: ALL AF.CA, R34.US, r Unexpected W
absent. Oph*
R34.CA, R33.US,
R33.FPI
s: 8K, QF,
i: AF.US, A {2} fact is {2} Missing
r W § 6.5.48 Ri
AF.BDC, present.
RD.CEF, AF.CA
s: 8K, QF, If {2} facts
{2} in
i: AF.US, are present, Facts Not
r W § 6.5.48 Ri
AF.BDC, then at least Visible
RD.CEF, AF.CA one is visible.

31
 Types Excl c Check f On failure s EFM v68 Ref
s: 8K, QF, i: AF.US,
AF.BDC, RD.CEF,
A {2} fact is {2} § 6.5.48 [],
s: ALL AF.CA, R34.US, r Unexpected W
absent. O*
R34.CA, R33.US,
R33.FPI
Notes and special cases:
1. Check is waived when the submission type matches POS*
2. Check applies in all contexts, and appears in both 6.5.48 and 6.5.51 (business address)
3.1.23 Submission Flags
Submission flags are grouped below when they have mutually dependent or exclusive values.
3.1.23.1 Annual Report, Transition Report, Quarterly Report
Concept # Type or regex Meaning
dei:DocumentAnnualReport {1} xs:boolean
dei:DocumentTransitionReport {2} xs:boolean
dei:DocumentShellCompanyReport {3} xs:boolean
dei:DocumentShellCompanyEventDate {4} xs:date
dei:DocumentQuarterlyReport {5} xs:boolean

When certain of the above concepts are expected, only one can have the value true.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.US,
A {1} fact valued {1} Value
AF.BDC, s: TF r Missing W § 6.5.49 Y
true is present.
AF.CA
s: TF,
A {1} fact valued {1} Value § 6.5.49 N,
R34.FPI, s: QF, EBP r Missing W
false is present. N*
R34.CA
If a {1} fact valued
{1} {2}
true is present, then
i: AF.FPI r Value W § 6.5.49 TF3
a {2} fact valued Dependency
false is present.
If a {1} fact valued
{1} {3}
true is present, then
i: AF.FPI r Value W § 6.5.49 TF3
a {3} fact valued Dependency
false is present.
If a {2} fact valued
{2} {3}
true is present, then
i: AF.FPI r Value W § 6.5.49 TF3
a {1} fact valued Dependency
false is present.
If a {2} fact valued
{2} {3}
true is present, then
i: AF.FPI r Value W § 6.5.49 TF3
a {3} fact valued Dependency
false is present.

32
 Incl Excl c Check f On failure s EFM v68 Ref
If a {3} fact valued
{3} {2}
true is present, then
i: AF.FPI r Value W § 6.5.49 TF3
a {1} fact valued Dependency
false is present.
If a {3} fact valued
{3} {2}
true is present, then
i: AF.FPI r Value W § 6.5.49 TF3
a {2} fact valued Dependency
false is present.
i: AF.US, If {1} facts are
{1} in Facts § 6.5.49 Y, N,
AF.BDC, r present, then at least Not Visible W
TF3
AF.CA one is visible.
s: QF,
If {2} facts are
i: AF.US, {2} in Facts § 6.5.49 Y, N,
r present, then at least Not Visible W
AF.BDC, TF3
one is visible.
AF.CA
If {3} facts are
{3} in Facts
i: AF.FPI r present, then at least Not Visible W § 6.5.49 TF3
one is visible.
A {1} fact valued {2} Value
R34.CA r Unexpected W § 6.5.49 N*
false is present.
s: QF, i: AF.US,
AF.BDC, {1}
s: ALL r A {1} fact is absent. Unexpected W § 6.5.49 []
AF.CA, AF.FPI,
R34.CA
s: QF, i: AF.US,
{2}
s: ALL AF.BDC, r A {2} fact is absent Unexpected W § 6.5.49 []
AF.CA, AF.FPI
If {3} valued true is
{4} Value
i: AF.FPI r present, then {4} is Dependency § 6.5.49 SR
present.
If {3} valued false
{4} Value
i: AF.FPI r is present, then {4} Dependency § 6.5.49 SR
is absent.
If {4} facts are
{4} in Facts
i: AF.FPI r present, then at least Not Visible W § 6.5.49 SR
one is visible.
{4}
s: ALL i: AF.FPI r A {4} fact is absent. Unexpected W § 6.5.49 []
A {5} fact valued {5} Value
s: QF s: TF r Missing W § 6.5.49 N
false is present.
A {5} fact valued {5} Value
s: TF s: AF, EBP r Missing W § 6.5.49 Y
true is present.
If {5} facts are
{5} in Facts
s: QF r present, then at least Not Visible W § 6.5.49 Y, N
one is visible.
{5}
s: ALL s: QF r A {5} fact is absent. Unexpected W § 6.5.49 []

Notes and special cases: none.

33
3.1.23.2 Financial Statement Error Correction, Recovery Analysis
Concept # Type or regex Meaning
dei:DocumentFinStmtError-
{1} xs:boolean
Annual reports expect a flag indicating error
CorrectionFlag correction.
dei:DocumentFinStmt- If error correction is true, then a flag
RestatementRecovery- {2} xs:boolean indicating whether the restatement resulted in
AnalysisFlag an analysis of compensation recovery.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
AF.US,
A {1} fact is {1} Missing
AF.BDC, r W § 6.5.49 R
present.
AF.FPI, AF.CA
AF.US, If {1} facts are
{1} in Facts
AF.BDC, r present, then at least Not Visible W § 6.5.49 R
AF.FPI, AF.CA one is visible.
AF.US,
{1}
s: ALL AF.BDC, r A {1} fact is absent. Unexpected W § 6.5.49 []
AF.FPI, AF.CA
AF.US, If a {1} fact valued
{1} {2} Value
AF.BDC, a true is present, Dependency W § 6.5.49 RT
AF.FPI, AF.CA then {2} is present.
AF.US, If a {1} fact valued
{1} {2} Value
AF.BDC, a false is present, Dependency W § 6.5.49 RT
AF.FPI, AF.CA then {2} is absent.
AF.US, If {2} facts are
{2} in Facts
AF.BDC, r present, then at least Not Visible W § 6.5.49 RT
AF.FPI, AF.CA one is visible.
AF.US,
A {2} fact is {2}
s: ALL AF.BDC, r Unexpected W § 6.5.49 []
absent.
AF.FPI, AF.CA
Notes and special cases: none.
3.1.23.3 Non-US Filer Flags
Miscellaneous flags applying only to non-US filers.
Concept # Type or regex Meaning
AnnualInformationForm {1} xs:boolean
AuditedAnnualFinancial-
{2} xs:boolean
Statements
U.S. GAAP|International Note that the values are
DocumentAccounting-
{3} Financial Reporting case sensitive and
Standard
Standards|Other contain spaces.
Note that the values are
OtherReportingStandard-
{4} Item (17|18) case sensitive and
ItemNumber
contain spaces.
DocumentRegistration-
{5} xs:boolean
Statement

34
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: AF.CA r A {1} fact is present. {1} Missing W § 6.5.49 Ri
{1} in
If {1} facts are present, then at Facts Not
s: AF.CA r W § 6.5.49 Ri
least one is visible. Visible
{1}
s: ALL s: AF.CA r A {1} fact is absent. Unexpected W § 6.5.49 []

s: AF.CA r A {2} fact is present. {2} Missing W § 6.5.49 Ri

{2} in
If {2} facts are present, then at Facts Not
s: AF.CA r W § 6.5.49 Ri
least one is visible. Visible
{2}
s: ALL s: AF.CA r A {2} fact is absent. Unexpected W § 6.5.49 []
i: AF.FPI A {3} fact is present. {3} Missing W § 6.5.50 Ri
{3} in
If {3} facts are present, then at Facts Not
i: AF.FPI § 6.5.50 Ri
least one is visible. Visible
i: AF.FPI, {3} § 6.5.50 [],
s: ALL A {3} fact is absent. Unexpected W
R34.FPI O*
{3} {4}
i: AF.FPI, If a {3} fact valued Other is Value
§ 6.5.50 Oth,
W
R34.FP present, then {4} is present. Dependency Oth*
{3} {4}
i: AF.FPI, If a {3} fact valued Other is Value
§ 6.5.50 Oth,
W
R34.FP absent, then {4} is absent. Dependency Oth*
{4} in
If {4} facts are present, then at Facts Not
i: AF.FPI W § 6.5.50 Oth
least one is visible. Visible
i: AF.FPI, {4}
s: ALL A {4} fact is absent. Unexpected W § 6.5.50 []
R34.FPI
i: AF.FPI, If a {5} fact is present, it is {5} Value
Missing W § 6.5.49 N
AF.CA valued false.
{5} in
i: AF.FPI, If {5} facts are present, then at Facts Not W § 6.5.49 N
AF.CA least one is visible. Visible
i: R34.CA, If a {5} fact is present, it is {5} Value
Missing W § 6.5.49 Y*
R34.FPI valued true.
i: AF.FPI,
AF.CA. {5}
s: ALL A {5} fact is absent. Unexpected W § 6.5.49 []
R34.FPI,
R34.CA
Notes and special cases: none.
3.1.23.4 Period Start Date
Concept # Type or regex Meaning
DocumentTransitionReport {1} xs:boolean
DocumentPeriodStartDate {2} xs:date

The period start date fact is required only for transition reports. In the case of Form 20-F, a transition
report cannot always be determined from the submission type alone.

35
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
{1} {2}
If a {1} fact valued true is Value
i: AF.FPI r W § 6.5.49 TR
present, then a {2} fact is present. Dependency
s: TF r A {2} fact is present. {2} Missing W § 6.5.49 Ri
s: TF, If {2} facts are present, then at {1} in Facts § 6.5.49 Ri,
r Not Visible W
i: AF.FPI least one is visible. TR
s: TF, {2}
s: ALL r A {2} fact is absent. Unexpected W § 6.5.49 []
i: AF.FPI
Notes and special cases: none.
3.1.23.5 Bankruptcy Proceedings Flag
Concept # Type or regex Meaning
EntityBankruptcyProceedingsCurrent {1} xs:boolean

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: QF, If {1} facts are
i: AF.US, present, then at {1} in Facts
r Not Visible W § 6.5.49 O
AF.BDC, least one is
AF.FPI visible.
s: QF, i: AF.US,
A {1} fact is {1} § 6.5.49 [],
s: ALL AF.BDC, AF.FPI, r Unexpected W
absent. O*
R33.FPI
Notes and special cases: none.
3.1.23.6 Documents Incorporated by Reference
Form 10-K text describing documents incorporated by reference should appear in a text block fact.
Concept # Type or regex Meaning
DocumentsIncorporatedByReferenceTextBlock {1} Text block (see 8.1.1 below)
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.US, If {1} facts are present, then at {1} in Facts
r Not Visible W § 6.5.49 O
AF.BDC least one is visible.
i: AF.US, {1}
s: ALL r A {1} fact is absent. Unexpected W § 6.5.49 []
AF.BDC
Notes and special cases: none.
3.1.23.7 Current Report
Concept # Type or regex Meaning
WrittenCommunications {1} xs:boolean
SolicitingMaterial {2} xs:boolean
PreCommencementTenderOffer {3} xs:boolean

36
 Concept # Type or regex Meaning
PreCommencementIssuerTenderOffer {4} xs:boolean
EntityInformationFormerLegalOr- xs:normalizedString
{5}
RegisteredName (e.g., “OLDCO Inc.”)

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
s: 8K r A {1} fact is present. {1} Missing W § 6.5.52 Ri
If {1} facts are present, then {1} in Facts Not
s: 8K r Visible W § 6.5.52 Ri
at least one is visible.
s: ALL s: 8K r A {1} fact is absent. {1} Unexpected W § 6.5.52 []
s: 8K r A {2} fact is present. {2} Missing W § 6.5.52 Ri
If {2} facts are present, then {2} in Facts Not
s: 8K r Visible W § 6.5.52 Ri
at least one is visible.
s: ALL s: 8K r A {2} fact is absent. {2} Unexpected W § 6.5.52 []
s: 8K r A {3} fact is present. {3} Missing W § 6.5.52 Ri
If {3} facts are present, then {3} in Facts Not
s: 8K r Visible W § 6.5.52 Ri
at least one is visible.
s: ALL s: 8K r A {3} fact is absent. {3} Unexpected W § 6.5.52 []
s: 8K r A {4} fact is present. {4} Missing W § 6.5.52 Ri
If {4} facts are present, then {4} in Facts Not
s: 8K r Visible W § 6.5.52 Ri
at least one is visible.
s: ALL s: 8K r A {4} fact is absent. {4} Unexpected W § 6.5.52 []
s: 8K, If {5} facts are present, then {5} in Facts Not
r Visible W § 6.5.52 O
QF at least one is visible.
s: 8K, {5} Unexpected
s: ALL r A {5} fact is absent. W § 6.5.52 []
QF
Notes and special cases: none
3.1.24 Closed-end fund registra�on
The cover page of Form N-2 has over 30 check box, date, amendment, and file number facts, many of
which have interdependent values or are mutually exclusive. The subsections below break these facts into
related groups.
Note that unlike other Checks involving facts in the required context, violation of these is more likely to
raise an error, not a warning.
Most concepts related to these Checks are in the dei namespace; a few are specific to closed-end funds
and thus appear in the cef taxonomy.
3.1.24.1 N-2 Registration file numbers
Concept # Type or regex Meaning
Submission type from EDGAR header {1}
dei:DocumentRegistrationStatement {2} xs:boolean
dei:InvestmentCompanyActRegistration {3} xs:boolean
dei:EntityFileNumber {4} \d{1,3}-\d{1,8}(-.{1,4})?
dei:InvestmentCompanyActFileNumber {5} \d{1,3}-\d{1,8}(-.{1,4})?
cef:BdcFileNumber {6} \d{1,3}-\d{1,8}(-.{1,4})?

37
Form N-2, when submitted to EDGAR as submission type N-2, represents an initial filing in which no
SEC file number has yet been assigned. All subsequent submissions will have one or more file numbers
appearing on the cover page.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If {1} is N-2, then a {4} fact is
i: RD.CEF r 1 {4} Unexpected W § 6.5.55 []
absent.
If {1} is N-2, then a {5} fact is
i: RD.CEF r 1 {5} Unexpected W § 6.5.55 []
absent.
If {1} is N-2, then a {6} fact is
i: RD.CEF r 1 {6} Unexpected W § 6.5.55 []
absent.
Either or both a {2} fact valued
{3} {4}
i: RD.CEF a true or a {3} fact valued true Inclusive E § 6.5.55 n2c
must be present.
Neither or both a {2} fact valued {2} {4} Value
i: RD.CEF a Dependency E § 6.5.55 n2sn
true and a {4} fact exist.
If {2} facts are present, then at {2} in Facts
i: RD.CEF r Not Visible E § 6.5.55 n2sn
least one is visible.
If {4} facts are present, then at {2} in Facts
i: RD.CEF r Not Visible E § 6.5.55 n2sn
least one is visible.
Neither or both a {3} fact valued {3} {5} Value
i: RD.CEF a Dependency E § 6.5.55 n2in
true and a {5} fact exist.
If {3} facts are present, then at {3} in Facts
i: RD.CEF r Not Visible E § 6.5.55 n2in
least one is visible.
If {5} facts are present, then at {5} in Facts
i: RD.CEF r Not Visible E § 6.5.55 n2in
least one is visible.
At most one of {5} or {6} are {5} {6}
i: RD.CEF a Exclusive E § 6.5.55 n2bn
present.
If {5} facts are present, then at {5} in Facts
i: RD.CEF r Not Visible E § 6.5.55 n2bn
least one is visible.
If {6} facts are present, then at {6} in Facts
i: RD.CEF r Not Visible E § 6.5.55 n2bn
least one is visible.
If {6} facts are present, their {6} Value
i: RD.CEF a E § 6.5.55 n2bn
value must begin with 814-
Notes and special cases:
1. In general, the first form N-2 submission is not an amendment and will have no file numbers.
3.1.24.2 N-2 Registration Amendment Numbers
Subsequent submissions after the first Form N-2 will have amendment numbers that are different
depending on whether the registration is under the Securities Act or the Investment Company Act and
whether they occur before or after the registration becomes effective.
Concept # Type or regex Meaning
Submission type from EDGAR header {1}
dei:DocumentRegistrationStatement {2} xs:boolean
dei:PreEffectiveAmendment {3} xs:boolean
dei:PreEffectiveAmendmentNumber {4} xs:positiveInteger
dei:PostEffectiveAmendment {5} xs:boolean

38
 Concept # Type or regex Meaning
dei:PostEffectiveAmendmentNumber {6} xs: positiveInteger
dei:InvestmentCompanyActRegistration {7} xs:boolean
dei:InvestmentCompanyRegistrationAmendment {8} xs:boolean
dei:InvestmentCompanyRegistrationAmendmentNumber {9} xs:positiveInteger

Note that these tend to be errors, not warnings.

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If {1} is N-2, then a {3} fact is {3} Unexpected
i: RD.CEF r W § 6.5.55 []
absent.
If {1} is N-2, then a {5} fact is {5} Unexpected
i: RD.CEF r W § 6.5.55 []
absent.
If a {3} fact value is true, then {3} {2} Value
i: RD.CEF a Dependency E § 6.5.55 n2d
there is a {2} fact valued true.
If a {5} fact value is true, then {5} {2} Value
i: RD.CEF a Dependency E § 6.5.55 n2f
there is a {2} fact valued true.
If a {8} fact value is true, then {8} {7} Value
i: RD.CEF a Dependency E § 6.5.55, n2h
there is a {7} fact valued true.
Neither or both {3} fact has the {3} {4} Value
i: RD.CEF r Dependency E § 6.5.55, n2e
value true and a {4} fact exists.
Neither or both {5} fact has the {5} {6} Value
i: RD.CEF r Dependency E § 6.5.55, n2g
value true and a {6} fact exists.
Neither or both {8} fact has the {8} {9} Value
i: RD.CEF r Dependency E § 6.5.55, n2i
value true and a {9} fact exists.
If {2} facts valued true are
{2} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 n2d
visible.
If {3} facts valued true are
{3} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 n2d
visible.
If {4} facts are present, then at {4} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 n2e
least one is visible.
If {5} facts valued true are
{5} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 n2f
visible.
If {6} facts are present, then at {6} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 n2g
least one is visible.
If {7} facts valued true are
{7} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 n2h
visible.
If {8} facts valued true are
{8} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 n2h
visible.
If {9} facts are present, then at {9} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 n2i
least one is visible.
Notes and special cases:

39
 1. There are no checks for the absence of these facts in instance types other than RD.CEF.
3.1.24.3 N-2 Commencement of Sales
Concept # Type or regex Meaning
dei:ApproximateDateOf- (As soon as practicable|From time to Note that the
CommencementOf-
{1}
time) after the effective date of this text values
ProposedSaleToThe- Registration Statement\.?)|(20\d\d-(0[1- contain
Public 9]|1[0-2])-(3[01]|[012]\d))
spaces.
Validations:
Incl Excl c Check f On failure s Ref
i: RD.CEF r A {1} fact is present. 1 {1} Missing W § 6.5.55 Ri

Notes and special cases:

1. There is no check for the absence of this fact in instance types other than RD.CEF.
3.1.24.4 N-2 Rule Flags
Concept # Type or regex Meaning
dei:DividendOrInterestReinvestmentPlanOnly {1} xs:boolean
dei:DelayedOrContinuousOffering {2} xs:boolean
cef:PrimaryShelfFlag {3} xs:boolean
dei:EffectiveUponFiling462e {4} xs:boolean
dei:AdditionalSecuritiesEffective413b {5} xs:boolean

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If {1} facts valued true are
{1} in Facts
i: RD.CEF r present, then at least one is 1 Not Visible E § 6.5.55 B
visible.
If {2} facts valued true are
{2} in Facts
i: RD.CEF r present, then at least one is 1 Not Visible E § 6.5.55 B
visible.
If {3} facts valued true are
{3} in Facts
i: RD.CEF r present, then at least one is 1 Not Visible E § 6.5.55 B
visible.
If {4} facts valued true are
{4} in Facts
i: RD.CEF r present, then at least one is 1 Not Visible E § 6.5.55 B
visible.
If {5} facts valued true are
{5} in Facts
i: RD.CEF r present, then at least one is 1 Not Visible E § 6.5.55 B
visible.
Notes and special cases:
1. There is no check for the absence of this fact in instance types other than RD.CEF.
3.1.24.5 N-2 Effectiveness Dates
Concept # Type or regex Meaning
dei:EffectiveWhenDeclaredSection8c {1} xs:boolean
dei:EffectiveUponFiling486b {2} xs:boolean

40
 Concept # Type or regex Meaning
dei:EffectiveOnSetDate486b {3} xs:boolean
dei:EffectiveOnDate486b {4} xs:date
dei:EffectiveAfter60Days486a {5} xs:boolean
dei:EffectiveOnSetDate486a {6} xs:boolean
dei:EffectiveOnDate486a {7} xs:date

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If {1} facts valued true are
{1} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 B
visible.
If {2} facts valued true are
{2} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 B
visible.
If {3} facts valued true are
{3} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 B
visible.
Neither or both {3} fact has the {3} {4} Value
i: RD.CEF a Dependency E § 6.5.55 n2j
value true and a {4} fact exists.
If {4} facts are present, then at {4} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 n2j
least one is visible.
If {5} facts valued true are
{5} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 B
visible.
If {6} facts valued true are
{6} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 B
visible.
Neither or both {6} fact has the {6} {7} Value
i: RD.CEF a Dependency E § 6.5.55 n2k
value true and a {7} fact exists.
If {7} facts are present, then at {7} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 n2k
least one is visible.
Notes and special cases:
1. There is no check for the absence of this fact in instance types other than RD.CEF.
3.1.24.6 N-2 Other Flags
Concept # Type or regex Meaning
dei:NewEffectiveDateForPreviousFiling {1} xs:date
dei:AdditionalSecurities462b {2} xs:boolean
dei:AdditionalSecurities462bFileNumber {3} \d{1,3}-\d{1,8}(-.{1,4})?
dei:NoSubstantiveChanges462c {4} xs:boolean
dei:NoSubstantiveChanges462cFileNumber {5} \d{1,3}-\d{1,8}(-.{1,4})?
dei:ExhibitsOnly462d {6} xs:boolean
dei:ExhibitOnly462dFileNumber {7} \d{1,3}-\d{1,8}(-.{1,4})?

Validations:

41
 Incl Excl c Check f On failure s EFM v68 Ref
If {1} facts are present, then at {1} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 B
least one is visible.
If {2} facts valued true are
{2} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 B
visible.
Neither or both {2} fact has the {2} {3} Value
i: RD.CEF a Dependency E § 6.5.55 n2l
value true and a {3} fact exists.
If {3} facts are present, then at {3} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 n2l
least one is visible.
If {4} facts valued true are
{4} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 B
visible.
Neither or both {4} fact has the {4} {5} Value
i: RD.CEF a Dependency E § 6.5.55 n2m
value true and a {5} fact exists.
If {5} facts are present, then at {5} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 n2m
least one is visible.
If {6} facts valued true are
{6} in Facts Not
i: RD.CEF r present, then at least one is 1 Visible E § 6.5.55 B
visible.
Neither or both {6} fact has the {6} {7} Value
i: RD.CEF a Dependency E § 6.5.55 n2o
value true and a {7} fact exists.
If {7} facts are present, then at {7} in Facts Not
i: RD.CEF r 1 Visible E § 6.5.55 n2o
least one is visible.
Notes and special cases:
1. There is no check for the absence of this fact in instance types other than RD.CEF.
3.1.24.7 N-2 Registrant Type Flags
Concept # Type or regex Meaning
cef:RegisteredClosedEndFundFlag {1} xs:boolean
cef:BusinessDevelopmentCompanyFlag {2} xs:boolean
cef:IntervalFundFlag {3} xs:boolean
cef:PrimaryShelfQualifiedFlag {4} xs:boolean
dei:EntityWellKnownSeasonedIssuer {5} Yes|No
dei:EntityEmergingGrowthCompany {6} xs:boolean
dei:EntityExTransitionPeriod {7} xs:boolean
cef:NewCefOrBdcRegistrantFlag {8} xs:boolean

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If {1} facts valued true are {1} in Facts Not
i: RD.CEF r 1 E § 6.5.55 n2p
present, then at least one is visible. Visible
At most one of {1} and {2} has the {1} {2}
i: RD.CEF r 1 Exclusive Values E § 6.5.55 n2p
value true.
If {2} facts valued true are {2} in Facts Not
i: RD.CEF r 1 E § 6.5.55 B
present, then at least one is visible. Visible
If {3} facts valued true are {3} in Facts Not
i: RD.CEF r 1 E § 6.5.55 B
present, then at least one is visible. Visible
42
 Incl Excl c Check f On failure s EFM v68 Ref
If {4} facts valued true are {4} in Facts Not
i: RD.CEF r 1 E § 6.5.55 B
present, then at least one is visible. Visible
If {5} facts valued true are {5} in Facts Not
i: RD.CEF r E § 6.5.55 B
present, then at least one is visible. Visible
If {6} facts valued true are {6} in Facts Not
i: RD.CEF r E § 6.5.55 B
present, then at least one is visible. Visible
If {7} facts valued true are {7} in Facts Not
i: RD.CEF r 2 E § 6.5.55 B
present, then at least one is visible. Visible
If {8} facts valued true are {8} in Facts Not
i: RD.CEF r E § 6.5.55 B
present, then at least one is visible. Visible
Notes and special cases:
1. Some concepts in this section are drawn from the cef namespace, not dei.
2. See 3.1.11 above for checks related to this fact value for other instance types.
3.2 Expected Facts with Dimensions
Taxonomy-defined dimensions, as introduced in section 1 above, are used to define XBRL hypercubes. In
this document as in all SEC standard taxonomies a taxonomy-defined dimension is called an Axis.
Members of an axis may be its default member, a standard member, or a custom member defined by the
filer. In addition to indicators such as names and indentations within tables, concept types used in this
document are additionally color-coded as shown in Figure 1.
Figure 1. Dimension figures color-coding legend
Concept or value type Color
Concept core dimension and concepts Green
Other core dimensions and their members Gray
Fact values None
Taxonomy-defined dimension (Axis) Orange
Standard members Medium Blue
Custom members Purple
Abstract placeholder concepts not appearing in instances, such as hypercubes,
Light Blue
line items, domain defaults, and non-usable domain members.
A hypercube of only a single taxonomy-defined dimension can be visualized as a table presented in a
disclosure as illustrated in Figure 2. Note that if not specified as region 1 or 2, the value is the sum across
the two regions.
Figure 2. Example showing nine facts with a single taxonomy-defined dimension
entity: Example01 Concepts Dimension
period: FY30
units: USD Product Revenue Service Revenue Combined Revenue
Region 1 23 12 35
Region Axis Region 2 17 8 25
40 20 60
Layout and formatting for presentation of the data to a human reader does not change the meaning, and
therefore does not change the characterization of each of the nine facts. Figure 3 shows the same facts,
with the concept dimension presented as rows, and the class dimension as columns.

43
Figure 3. Example showing different presentation of the same nine facts
entity: Example01 Region Axis
period: FY30
Region 1 Region 2
units: USD
Product Revenue 23 17 40
Concepts
Service Revenue 12 8 20
Dimension
Combined Revenue 35 25 60
Data in in instances is organized into hypercubes having zero or more axes; as the previous two figures
show, they are usually thought of – and referred to as – Tables. Some axes have a set of members fixed by
a taxonomy, others are empty in the taxonomy and are populated only by custom members. Although
filers may define facts that use additional axes beyond those in the table, some taxonomy tables are closed
and restrict the facts to use only certain axes.
The representation of individual facts in Figure 2 and Figure 3 can be understood as a table whose
columns represent each dimension and the value of the fact, and each row representing a separate fact.
Where a taxonomy defined dimension (in this case, Region) is blank, that indicates it is the default of that
dimension.
Figure 4. Example showing the nine individual facts
Entity Period Unit Concept Region Value
Example01 FY30 USD Product Revenue Region 1 23
Example01 FY30 USD Service Revenue Region 1 12
Example01 FY30 USD Combined Revenue Region 1 35
Example01 FY30 USD Product Revenue Region 2 17
Example01 FY30 USD Service Revenue Region 2 8
Example01 FY30 USD Combined Revenue Region 2 25
Example01 FY30 USD Product Revenue 40
Example01 FY30 USD Service Revenue 20
Example01 FY30 USD Combined Revenue 60
The appearance of a concept and a set of facts with or without members of a given dimension may be
interpreted in various ways. The first common case is as detailed above: a numeric fact without a
dimension equaling the sum of other facts having members of that dimension. The axis represents a
disaggregation of a total.
The second common case, less common for numeric facts, but prevalent for non-numeric facts such as
text and dates, is that a fact can be inferred from the relationship between the Axis default (representing
the whole) and the absence of a member on the axis:
Entity Period Concept Region Value
Example01 FY30 Best Seller Product A
Example01 FY30 Best Seller Region 2 Product B

This case implies that product A is the company’s best seller overall and in region 1, but region 2 is an
exception where product B is the best seller; although different, it is not contradictory.
A third case is the appearance of non-numeric facts, each with a different member of the axis, but no
default:

44
 Entity Period Concept Region Value
Example01 FY30 Sponsored Team Region 1 Red Sox
Example01 FY30 Sponsored Team Region 2 White Sox

It would be meaningless to sum, merge, average or concatenate text values for this non-numeric concept
to come up with a sponsored team for the whole company. A software program might expect a sponsored
team for the whole company, or for each of its individual regions, but signal a problem if it receives
values for both the whole and the parts. In this case, the use of the axis default, and the use of individual
members, are mutually exclusive.
The interpretation of a given combination of concept and axis always impacts the expected and
unexpected facts in an instance; this is particularly true for the mostly non-numeric expected facts.
3.2.1 Business contact
When a business contact is expected, the facts are present in the business contact (bc) context defined as
the required context plus a single dimension dei:EntityAddressesAddressTypeAxis with standard
member dei:BusinessContactMember.
3.2.1.1 Contact Person
Concept # Type or regex Meaning
dei:ContactPersonnelName {1} xs:normalizedString
dei:LocalPhoneNumber {2} xs:normalizedString
dei:ContactPersonnelFax {3} xs:normalizedString
dei:ContactPersonnelEmailAddress {4} xs:normalizedString

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.FPI,
A {1} fact is {1} Missing
RD.CEF, bc W § 6.5.51 Ri
present.
AF.CA
If {1} facts are
i: AF.FPI,
present, then at {1} in Facts
RD.CEF, bc Not Visible W § 6.5.51 Ri
least one is
AF.CA
visible.
i: R34.FPI, R34.CA, A {1} fact is {1} § 6.5.51 [],
s: ALL bc Unexpected W
R33.FPI, R33.US absent. O*
One, two, or all
i: AF.FPI, three {2}, {3} or {2} {3} {4}
bc Missing W § 6.5.51 O3
RD.CEF {4} facts are
present.
A {2} fact is {2} Missing
i: AF.CA bc W § 6.5.51 Ri
present.
If {2} facts are
present, then at {2} in Facts
i: AF.CA bc Not Visible W § 6.5.51 O3
least one is
visible.

45
 Incl Excl c Check f On failure s EFM v68 Ref
i: AF.FPI, RD.CEF,
AF.CA, R34.FPI, A {2} fact is {2} § 6.5.51 [],
s: ALL bc Unexpected W
R34.CA, R33.FPI, absent. O*
R33.US
If {3} facts are
i: AF.FPI, present, then at {3} in Facts
bc Not Visible W § 6.5.51 O3
RD.CEF least one is
visible.
i: AF.FPI, RD.CEF, A {3} fact is {3} § 6.5.51 [],
s: ALL bc Unexpected W
R34.FPI, R34.CA absent. O*
If {4} facts are
i: AF.FPI, present, then at {4} in Facts
bc Not Visible W § 6.5.51 O3
RD.CEF least one is
visible.
i: AF.FPI, RD.CEF, A {4} fact is {4} § 6.5.51 [],
s: ALL bc Unexpected W
R34.FPI, R34.CA absent. O*
Notes and special cases: none.
3.2.1.2 Street, City and Zip
A business contact will have similar facts to the principal address.
Concept # Type or regex Meaning
dei:EntityAddressAddressLine1 {1} xs:normalizedString
dei:EntityAddressCityOrTown {2} xs:normalizedString
dei:EntityAddressPostalZipCode {3} xs:normalizedString

The first line of the address, the city or town, and postal or zip code, share similar validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.FPI,
A {1} fact is {1} Missing
RD.CEF, bc W § 6.5.51 Ri
present.
AF.CA
i: AF.FPI, If {1} facts are
{1} in Facts
RD.CEF, bc present, then at Not Visible W § 6.5.51 Ri
AF.CA least one is visible.
i: AF.FPI,
RD.CEF, AF.CA, A {1} fact is {1} § 6.5.51 [],
s: ALL bc Unexpected W
R34.FPI, R34.CA absent. O*
R33.FPI R33.US
i: AF.FPI,
A {2} fact is {2} Missing
RD.CEF, bc W § 6.5.51 Ri
present.
AF.CA
i: AF.FPI, If {2} facts are
{2} in Facts
RD.CEF, bc present, then at Not Visible W § 6.5.51 Ri
AF.CA least one is visible.
i: AF.FPI,
RD.CEF, AF.CA, A {2} fact is {2}
s: ALL bc Unexpected W § 6.5.51 []
R34.FPI, R34.CA absent.
R33.FPI R33.US

46
 Incl Excl c Check f On failure s EFM v68 Ref
i: AF.FPI, bc A {3} fact is {3} Missing W § 6.5.51 Ri
RD.CEF, present.
AF.CA
bc If {3} facts are {3} in Facts W § 6.5.51 Ri
Not Visible
i: AF.FPI, present in the
RD.CEF, required context,
AF.CA then at least one is
visible.
i: AF.FPI, bc A {3} fact is {3} W § 6.5.51 [],
Unexpected
RD.CEF, AF.CA, absent. O*
s: ALL
R34.FPI, R34.CA
R33.FPI R33.US
Notes and special cases: none.
3.2.1.3 State or Province and Country
Concept # Type or regex Meaning
XBRL transformations that convert state and
dei:EntityAddress-
{1}
Postal state or
StateOrProvince province names to postal codes (e.g., TX, ON) are
province
shown in EFM § 5.2.5.12.
XBRL transformations that country names to ISO
dei:EntityAddress-
{2}
Valid IANA
Country 3166-1 alpha 2 (IANA) codes (e.g., US, JP) are
country code
shown in EFM 5.2.5.12.
Validations:
Incl Excl c Check f Codes s EFM v68 Ref
One or both {1}
i: AF.FPI, {1} {2}
bc and {2} facts are Inclusive W § 6.5.51 O2
RD.CEF
present.
A {1} fact
i: AF.CA bc representing a US {1} Value W § 6.5.51 Ru
state is present.
i: AF.FPI, If {1} facts are
{1} in Facts § 6.5.51 O2,
RD.CEF, bc present, then at Not Visible W
Ru
AF.CA least one is visible.
A {1} fact
representing a {1} Value
i: R34.CA bc W § 6.5.51 Ou*
Canadian province
is present.
i: AF.FPI,
{1} § 6.5.51 [],
s: ALL RD.CEF, AF.CA, bc A {1} fact is absent. Unexpected W
O*
R34.CA, R33.US
If {2} facts are
i: AF.FPI, {2} in Facts
bc present, then at Not Visible W § 6.5.51 O2
RD.CEF
least one is visible.
i: R33.FPI, {2}
s: ALL bc A {2} fact is absent. Unexpected W § 6.5.51 []
R34.FPI
Notes and special cases: none.

47
3.2.1.4 Phone
Concept # Type or regex Meaning
dei:CityAreaCode {1} xs:normalizedString
dei:LocalPhoneNumber {2} xs:normalizedString

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
A {1} fact is {1} Missing
i: AF.CA bc W § 6.5.51 Ri
present.
If {1} facts are
i: AF.CA,
present, then at 1
{1} in Facts
AF.FPI, bc Not Visible W § 6.5.51 Oph
least one is
RD.CEF
visible.
i: AF.CA, AF.FPI,
RD.CEF, R34.FPI, A {1} fact is 1
{1} § 6.5.51 [],
s: ALL bc Unexpected W
R34.CA, R33.FPI, absent. Oph*
R33.US
A {2} fact is {2} Missing
i: AF.CA bc W § 6.5.51 Ri
present.
If {2} facts are
i: AF.CA,
present, then at {2} in Facts § 6.5. 51 O3,
AF.FPI, bc Not Visible W
least one is Ri
RD.CEF
visible.
i: AF.CA, AF.FPI,
RD.CEF, R34.FPI, A {2} fact is {2} § 6.5. 51 [],
s: ALL bc Unexpected W
R34.CA, R33.FPI, absent. O*
R33.US
Notes and special cases:
1. Neither or both CityAreaCode and LocalPhoneNumber should be present in any context, not just
the business contact context; see 3.1.22.4 above.
3.2.2 Former address
To report a former address, the facts are present in the Former Address (fa) context defined as the required
context plus a single dimension dei:EntityAddressesAddressTypeAxis with member dei:Former-
AddressMember.

3.2.2.1 Former Street, City and Zip

Concept # Type or regex Meaning
dei:EntityAddressAddressLine1 {1} xs:normalizedString
dei:EntityAddressAddressLine2 {2} xs:normalizedString
dei:EntityAddressAddressLine3 {3} xs:normalizedString
dei:EntityAddressCityOrTown {4} xs:normalizedString
dei:EntityAddressPostalZipCode {5} xs:normalizedString

The first line of the address, the city or town, and postal or zip code, share similar validations.
Validations:

48
 Incl Excl c Check f On failure s EFM v68 Ref
s: 8K, If {1} facts are present, then {1} in Facts Not
fa Visible W § 6.5.53 O
QF at least one is visible.
s: 8K, {1} Unexpected
s: ALL fa A {1} fact is absent. W § 6.5.53 [], O
QF
s: 8K, If {2} facts are present, then {2} in Facts Not
fa Visible W § 6.5.53 OL1
QF at least one is visible.
s: 8K, If a {2} fact is present, then {1} {2}
fa Dependency W § 6.5.53 OL1
QF a {1} fact is present.
s: 8K, {2} Unexpected
s: ALL fa A {2} fact is absent. W § 6.5.53 []
QF
s: 8K, If a {3} fact is present, then {2} {3}
fa Dependency W § 6.5.53 OL2
QF a {2} fact is present.
s: 8K, If {3} facts are present, then {3} in Facts Not
fa Visible W § 6.5.53 OL2
QF at least one is visible.
s: 8K, {3} Unexpected
§ 6.5.53 [],
s: ALL fa A {3} fact is absent. W
QF OL2
s: 8K, One or both {4} and {5} {4} {5} Inclusive
fa W § 6.5.53 F2
QF facts are present
s: 8K, If {4} facts are present, then {4} in Facts Not
fa Visible W § 6.5.53 F2
QF at least one is visible.
s: 8K, {4} Unexpected
s: ALL fa A {4} fact is absent. W § 6.5.53 []
QF
s: 8K, If {5} facts are present, then {5} in Facts Not
fa Visible W § 6.5.53 F2
QF at least one is visible.
s: 8K, {5} Unexpected
s: ALL fa A {5} fact is absent. W § 6.5.53 []
QF
Notes and special cases: none.
3.2.2.2 Former State or Province and Country
Concept # Type or regex Meaning
dei:Entity-
AddressAddress- {1} xs:normalizedString
Line1
dei:Entity- XBRL transformations that convert state and
AddressState- {2} Postal state or province province names to postal codes (e.g., TX, ON)
OrProvince are shown in EFM § 5.2.5.12.
XBRL transformations that country names to
dei:Entity-
{3}
Valid IANA country
AddressCountry ISO 3166-1 alpha 2 (IANA) codes (e.g., US,
code
JP) are shown in EFM 5.2.5.12.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
{1} {2} {3}
s: 8K, If a {1} is present, then one or both Inclusive
fa W § 6.5.53 F2
QF of {2} and {3} facts are present. Dependency
s: 8K, {2} {1}
If a {2} fact is absent, then {1} is Inclusive
QF fa W § 6.5.53 F2
absent. Dependency

49
 Incl Excl c Check f On failure s EFM v68 Ref
s: 8K, {3} {1}
If a {3} fact is absent, then {1} is Inclusive
QF fa W § 6.5.53 F2
absent. Dependency
{2} in
s: 8K, If {2} facts are present, then at least Facts Not
fa W § 6.5.53 F2
QF one is visible. Visible
s: 8K, {2}
s: ALL fa A {2} fact is absent. Unexpected W § 6.5.53 []
QF
{3} in
s: 8K, If {3} facts are present, then at least Facts Not
fa W § 6.5.53 F2
QF one is visible. Visible
s: 8K, {3}
s: ALL fa A {3} fact is absent. Unexpected W § 6.5.53 []
QF
Notes and special cases: none.
3.2.3 Common Stock Shares Outstanding
Common stock shares, like public float, appears in a context that is an instant period, not a duration.
Concept # Type or regex Meaning
dei:EntityCommonStockSharesOutstanding {1} decimal

Depending on whether the entity represented in the required context has zero, one, or more than one, class
of common shares or ownership units outstanding, the instance will have exactly one of the following
permitted sets of facts:
Axis in any Members in
Case Period
standard namespace distinct contexts
An instant on or after the end of the
1 No dimensions N/A
required context
StatementClassOfStockAxis
An instant on or after the end of the
2 At least two
required context
ClassesOfShareCapitalAxis
An instant on or after the end of the
3 At least two
required context
The cases are mutually exclusive. Cases 2 and 3 require that the instance be accompanied by a custom
taxonomy as covered below in section 4. The validations apply to a subsequent event (se) context as
defined above in 3.1.15, “Public Float”.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
A {1} fact is present in each
s: FAST i: AF.CA se context of exactly one of the {1} Missing W § 6.5.26
cases 1, 2 or 3.
If {1} facts are present in a
{1} in Facts
s: FAST se context, at least one is Not Visible W § 6.5.45
visible.
s: FAST, A {1} fact is not present in {1} Unexpected
s: ALL se W § 6.5.26
i: R33.FPI any context.
Notes and special cases:
1. A filer having no common stock will have 0 common stock shares outstanding under case 1, not nil.

50
3.2.4 Registered Securi�es
Depending on whether the entity represented in the required context has zero, one, or more than one type
or class of registered securities (not limited to common shares as in the previous section), an instance may
have one of the following mutually exclusive cases of permitted sets of facts about those securities:
Case Axis in any standard namespace Distinct members in contexts Period
1 No dimensions (the required context) N/A (there is only one class) Required context
2 StatementClassOfStockAxis At least two Required context
3 ClassesOfShareCapitalAxis At least two Required context
Notes:
1. No instance type requires either dei:Security12bTitle or dei:Security12gTitle. The Checks
concern only whether they are consistent with each other and other facts if they are present.
2. Members on StatementClassOfStockAxis and ClassesOfShareCapitalAxis are expected only
when there is need to distinguish different securities. An American Depositary Receipt (ADR) is an
exception: it may be the only registered security, yet still requires a dimension to indicate this.
3. The presence of members on axes other than StatementClassOfStockAxis or ClassesOfShare-
CapitalAxis does not change which of the three cases is being represented in an instance.

3.2.4.1 Security Title

The presence of facts for either of two concepts determines which of the three cases apply:
Concept # Type or regex Meaning
dei:Security12bTitle {1} xs:normalizedString up to 150 characters
dei:Security12gTitle {2} xs:normalizedString up to 150 characters
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
A {1} fact value is present
s: FAST, {1} Security § 6.5.46 Ot1,
r in at most one of the cases Axes W
R34 Ot1*
1-3.
A {2} fact value is present
s: FAST, {2} Security § 6.5.46 Ot1,
r in at most one of the cases Axes W
R34 Ot1*
1-3.
s: FAST, At most one {1} or {2} {1} {2} § 6.5.46 Ot1,
a Exclusive W
R34 fact is present. Ot1*
If {1} facts are present in a
{1} in Facts § 6.5.45
s: FAST r context, at least one is Not Visible W
§ 6.5.46 Ot1
visible.
If {2} fact values are
{2} in Facts § 6.5.45
s: FAST r present in a context, at Not Visible W
§ 6.5.46 Ot1
least one is visible.
s: FAST, A {1} fact is absent from {1} Unexpected
s: ALL r W § 6.5.46 []
R34 all contexts.
s: FAST, A {2} fact is absent from {2} Unexpected
s: ALL r W § 6.5.46 []
R34 all contexts.
Notes and special cases: none.

51
3.2.4.2 Exchanges Axis
A security may be traded on more than one exchange. Much like the exclusivity of cases 1, 2, and 3,
EntityListingsExchangeAxis permits only one listing for the security and the listings axis does not
appear, or there are multiple listings, and more than one member of the axis appears.
Concept # Type or regex Meaning
dei:Security12bTitle {1} xs:normalizedString up to 150 characters
dei:Security12gTitle {2} xs:normalizedString up to 150 characters
.
Sub Case Axes in a standard namespace Members in distinct contexts Period
a No axes N/A Required context
b EntityListingsExchangeAxis At least two Required context
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If a {1} fact is present in a context with
no member of EntityListingExchange-
{1}
s: FAST,
r Axis, then there are no {1} facts in Security W § 6.5.46
R34 contexts the same except for also having a Axes
member of EntityListingExchange-
Axis.
If a {1} fact is present in a context with a
member of EntityListingExchange-
{1}
s: FAST, Axis, then there are no {1} facts in Security
r W § 6.5.46
R34 contexts the same except without a Axes
member of EntityListingExchange-
Axis.
If a {2} fact is present in a context with
no member of EntityListingExchange-
{2}
s: FAST, Axis, then there are no {2} facts in Security
r W § 6.5.46
R34 contexts the same except for also having a Axes
member of EntityListingExchange-
Axis.
If a {2} fact is present in a context with a
member of EntityListingExchange-
{2}
s: FAST, Axis, then there are no {2} facts in Security
r W § 6.5.46
R34 contexts the same except without a Axes
member of EntityListingExchange-
Axis.

Notes and special cases: none.

3.2.4.3 Security Exchange Name
One security of a company could be traded on no national exchanges, another security on one national
exchange, and a third on several exchanges. Regardless, the presence of a dei:Security12bTitle fact
is paired with the name of the Exchange in the same context, and only that same context.

52
 Concept # Type or regex Meaning
dei:Security- {1}
12bTitle xs:normalizedString up to 150 characters
National Exchanges.
dei:Security-
{3}
NYSE|NASDAQ|CHX|BOX|BX|MIAX|MRX|NYSEAMER| Other than National
ExchangeName NYSEArca|NYSENAT|PEARL|Phlx|AF Exchanges are not
tagged.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If a {1} fact is present in a case
s: FAST, 1, {1} {3}
a 1 context, then a {3} fact value Dependency W § 6.5.46 Te
R34 2
is present in the same context.
If a {1} fact is present in a case
2 or 3 context and
1,
s: FAST, dei:AdrMember is not a {1} (3}
a 2, Dependency W § 6.5.46 Te
R34 member of either axis, then a
3
{3} fact value is present in the
same context.
If {3} facts are present in a {3} in
s: FAST a case 1 context, then they are Facts Not W § 6.5.46 Te
visible. Visible
If {3} facts are present in a {3} in
s: FAST a case 2 or 3 context, then they Facts Not W § 6.5.46 Te
are visible. Visible
s: FAST,
A {3} fact is absent from a {3}
All R34, a 2 Unexpected W § 6.5.46 []
context.
i: AF.CEF
Notes and special cases:
1. An exchange name is relevant only to 12b securities; 12g securities are not traded on national
exchanges.
2. The values of dei:SecurityExchangeName are EDGAR-defined acronyms. Inline XBRL
transformation ixt-sec:exchnameen described in EFM section 5.2.5.12 transforms commonly
displayed textual names of exchanges to these values.
3. The exchange name is neither expected nor unexpected for an ADR member on the StatementClass-
OfStockAxis or ClassesOfShareCapitalAxis.

3.2.4.4 Trading Symbol / No Trading Symbol

Whether a security has a trading symbol is represented in two mutually exclusive concepts:
Concept # Type or regex Meaning
dei:NoTradingSymbolFlag {1} Fixed value true
dei:TradingSymbol {2} xs:normalizedString up to 25 characters.
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
At most one {1} § 6.5.46 T1,
s: FAST, R34, {1} {2}
a or {2} fact 1 Exclusive W T1*
i: AF.CEF
exists. § 6.5.57
53
 Incl Excl c Check f On failure s EFM v68 Ref
s: FAST, R34, A {1} fact is {1}
s: ALL r 2 Unexpected W § 6.5.46 [], O*
RD, i: AF.CEF absent.
s: FAST, R34, A {2} fact is {2}
s: ALL r 2 Unexpected W § 6.5.46 [], O*
RD, i: AF.CEF absent.
Notes and special cases:
1. Concepts dei:NoTradingSymbol and dei:TradingSymbol may be present in AF.CEF instances but
only in class contexts.
2. Concept dei:TradingSymbol is neither expected nor unexpected in RD submissions.
3.2.4.5 Security Reporting Obligation
Concept # Type or regex Meaning
dei:SecurityReportingObligation {1} Fixed value 15(d)
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.FPI, If {1} facts are present, at least {1} in Facts
r Not Visible W § 6.5.45 O
AF.CA one is visible.
i: AF.FPI,
AF.CA, {1} § 6.5.46 [],
s: ALL r A {1} fact is absent. Unexpected W
R34.FPI, O*
R34.CA
Notes and special cases: none.
3.2.5 Open-end Fund Series
Open-end Funds (N-1A funds) and Separate Accounts Registered as Open End Funds (N-3 registrants)
contain facts for distinct series. The set of series identifiers in the scope of a submission is determined by
the content of the EDGAR Submission header element seriesClasses:
• Each seriesId results in one series;
• Each rptIncludeAllSeriesFlag results in a series for every active series.
For each series, there should be at least one additional Series Context (sc) for each Series ID reported in
the submission. Each such context will have an explicit member of the dimension with local name
LegalEntityAxis in a standard namespace. That axis should have a custom member for every series ID,
such as S000000987, named S000000987Member (EFM v68 § 6.5.41).
3.2.6 Open-end Fund Shareholder Reports
Form N-CSR contains one shareholder report per class. The set of class identifiers in the scope of a
submission is determined by the content of the EDGAR submission header element seriesClasses:
• Each rptClassId results in one class;
• Each rptIncludeAllClassesFlag results in a class for every active class in that series; and
• Each rptIncludeAllSeriesFlag results in a class for every active class in all series of the filer CIK.
For each shareholder report per class, there should be at least one additional Class Context (cc) for each
Class ID reported in the submission. Each such context will have an explicit member of the dimension
with local name ClassAxis in a standard namespace. That axis should have a custom member for every
class ID, such as C000000123, named C000000123Member.

54
 Concept # Type or regex Meaning
oef:Shareholder-
Report- ([Ss]emi[^A-Za-
{1}
AnnualOrSemi- z0-9]+)?[Aa]nnual\s+[Ss]hareholder\s+[Rr]eport
Annual
oef:FundName {2} xs:normalizedString
oef:ClassName {3} xs:normalizedString
dei:NoTrading-
{4} xs:boolean
SymbolFlag
dei:TradingSymbol {5} xs:normalizedString up to 25 characters.
NONE | BOX | BX | C2 | CBOE | CHX | EDGAR
dei:Security-
{6}
Cboe(BYX|BZX|EDGA|EDGX) | GEMX | IEX | ISE | MIAX National
ExchangeName | MRX | NASDAQ | NYSE(AMER|Arca|NAT)? | PEARL | Exchange
Phlx
Code
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: AF.CEF, {1} Missing
r A {1} fact is present. W § 6.5.57 R
HF
i: AF.CEF, If {1} facts are present, then {1} in Facts
r Not Visible W § 6.5.57 R
HF at least one is visible.
i: AF.CEF, {1}
s: ALL r A {1} fact is absent. Unexpected W § 6.5.57 []
HF

i: AF.CEF, {2} Missing

cc A {2} fact is present. W § 6.5.57 R
HF
i: AF.CEF, If {2} facts are present, then {2} in Facts
cc Not Visible W § 6.5.57 R
HF at least one is visible.
i: AF.CEF, {2}
s: ALL cc A {2} fact is absent. Unexpected W § 6.5.57 []
HF

i: AF.CEF, {3} Missing

cc A {3} fact is present. W § 6.5.57 R
HF
i: AF.CEF, If {3} facts are present, then {3} in Facts
cc Not Visible W § 6.5.57 R
HF at least one is visible.
i: AF.CEF, {3}
s: ALL cc A {3} fact is absent. Unexpected W § 6.5.57 []
HF

i: AF.CEF, If a {1} fact is present, then {1} {2} {3}

§ 6.5.57 T2*,
HF cc either {4} or a {5} fact exist 1 Exclusive E
Dependency T2
but not both.
i: AF.CEF, If {4} facts are present, then {4} in Facts
cc Not Visible W § 6.5.57 T2
HF at least one is visible.
i: AF.CEF, If {5} facts are present, then {5} in Facts
cc Not Visible W § 6.5.57 T2
HF at least one is visible.

{5} {6}
i: AF.CEF, Neither or both of {5} and Mutual
cc W § 6.5.57 T3
HF {6} facts are present. Dependency

Notes and special cases:

55
1. See also 3.2.4.4 above that requires dei:NoTradingSymbolFlag and dei:TradingSymbol to be
mutually exclusive in all contexts.
3.3 Resource Extrac�on Payments Disclosure
Exhibit 2.01 of Form SD consists of exactly two attachment types: EX-2.01.INS, an XBRL Instance, and
EX-2.01.SCH, an XBRL Schema, with custom elements and embedded linkbases. Exhibit 2.01.INS is not
an Inline XBRL document.
3.3.1 Currency and Total Payments
Concept # Type or regex Meaning
dei:EntityReportingCurrencyISOCode {1} [A-Z]{3} ISO 4217 currency code
rxp:TotalPayments {2} Monetary

Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: RXP.US, A {1} fact is {1} Missing
r W 6.5.58 R*
RXP.FPI present.
i: RXP.US, A {1} fact is {1} Unexpected
s: ALL r W 6.5.58 []
RXP.FPI absent.
i: RXP.US, A {2} fact is {2} TotalPayments
r Missing W 6.5.58 R*
RXP.FPI present.
i: RXP.US, A {2} fact is {2} TotalPayments
s: ALL r Unexpected W 6.5.58 []
RXP.FPI absent.
Notes and special cases: none.
3.3.2 Payments Axis
A Payment Context (pc) is a context having a typed dimension member of rxp:PmtAxis, an integer value
of the rxp:pmt element and a period matching the required context. There is one payment context for
each payment reported in the disclosure.
3.3.3 Boolean, Numeric and String Valued Facts
The table below lists concepts in the RXP taxonomy that characterizes a single payment or group of
similar payments. These are restricted to basic data types and may only appear in payment contexts.
Concept # Type or regex Meaning
rxp:A {1} Monetary Amount

rxp:M {2}
Well|Open Method of Extraction. Note that there are three
Pit|Underground Mining distinct values of M, two of them containing spaces.
rxp:Cm {3} xs:normalizedString Currency Conversion Method
rxp:K {4} true In-kind Payment flag
rxp:Km {5} xs:normalizedString In-kind calculation method
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: RXP.US, If a {1} fact is present, then a {2} 1 {1} {2} Value W § 6.5.58 Item
pc Dependency
RXP.FPI fact is present. 3
i: RXP.US, If a {2} fact is present, then a {1} 1 {2} {1} Value W § 6.5.58 Item
pc Dependency
RXP.FPI fact is present. 3
56
 Incl Excl c Check f On failure s EFM v68 Ref
i: RXP.US, If a {3} fact is present, then a {1} 1 {3} {1} Value W § 6.5.58 Item
pc Dependency
RXP.FPI fact is present. 3
i: RXP.US, If a {4} fact is present, then a {1} 1 {4} {1} Value W § 6.5.58 Item
pc Dependency
RXP.FPI fact is present. 3
i: RXP.US, If a {4} fact present, then a {5} 1 {4} {5} Value W § 6.5.58 Item
pc Dependency
RXP.FPI fact is present. 3
i: RXP.US, pc If a {5} fact present, then a {4} 1 {5} {4} Value W § 6.5.58 Item
Dependency
RXP.FPI fact is present. 3
i: RXP.US, pc If a {1} fact is present with {3} W § 6.5.58 Item
Unexpected
RXP.FPI unitRef matching the value of 4
EntityReportingCurrency-
ISOCode in the required context,
then a {3} fact should not be
present.
i: RXP.US, pc At least one {1} fact is present in 2 Amount for W § 6.5.58 Item
Required 12
RXP.FPI the instance with period matching Months Period
5
the 12-month reporting period
and unit matching the value of
EntityReportingCurrency-
ISOCode in the required context.

Notes and special cases:

1. There are no checks for absence of these facts in other submission types or contexts.
2. Only one such fact is needed; the check does not apply to every individual payment context.
3.3.4 Member-valued Facts
The table below lists concepts in the RXP taxonomy restricted by the taxonomy to have values that are
declared custom members (see 5.7 below) of one of the standard domains:
Concept # Type or regex Meaning
rxp:A {1} Monetary Amount
rxp:E {2} Custom member of dei:EntityDomain Entity
rxp:Co {3} Standard member of country:AllCountriesDomain Country
rxp:Sn {4} Standard member of snj:AllSubnational- Subnational
JurisdictionsDomain Jurisdiction
rxp:Gv {5} Custom member of rxp:AllGovernmentsMember Government
rxp:Pr {6} Custom member of rxp:AllProjectsMember Project
rxp:P {7} Custom member of rxp:AllPaymentTypesMember Payment Type
rxp:R {8} Custom member of rxp:AllResourcesMember Resource
rxp:Sg {9} Custom member of rxp:AllSegmentsMember Segment
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
i: RXP.US, If a {1} fact is present, 1 {1} {5} Value W § 6.5.58 Item
pc Dependency
RXP.FPI then a {5} fact is present. 3
i: RXP.US, If a {1} fact is present, 1 {1} {3} Value W § 6.5.58 Item
pc Dependency
RXP.FPI then a {3} fact is present. 3
i: RXP.US, If a {1} fact is present, 1 {1} {8} Value W § 6.5.58 Item
pc Dependency
RXP.FPI then a {8} fact is present. 3
57
 Incl Excl c Check f On failure s EFM v68 Ref
i: RXP.US, If a {2} fact present, then 1 {2} {1} Value W § 6.5.58 Item
pc Dependency
RXP.FPI a {1} fact is present. 3
i: RXP.US, If a {3} fact present, then 1 {3} {1} Value W § 6.5.58 Item
pc Dependency
RXP.FPI a {1} fact is present. 3
i: RXP.US, If a {4} fact is present, 1 {4} {3} Value W § 6.5.58 Item
pc Dependency
RXP.FPI then a {3} fact is present. 3
i: RXP.US, If a {5} fact is present, 1 {5} {3} Value W § 6.5.58 Item
pc Dependency
RXP.FPI then a {3} fact is present. 3
i: RXP.US, pc If a {6} fact present, then 1 {6} {5} Value W § 6.5.58 Item
Dependency
RXP.FPI a {5} fact is present. 3
i: RXP.US, pc If a {7} fact present, then 1 {7} {1} Value W § 6.5.58 Item
Dependency
RXP.FPI a {1} fact is present. 3
i: RXP.US, pc If a {8} fact present, then 1 {8} {1} Value W § 6.5.58 Item
Dependency
RXP.FPI a {1} fact is present. 3
i: RXP.US, pc If a {9} fact present, then 1 {9} {1} Value W § 6.5.58 Item
Dependency
RXP.FPI a {1} fact is present. 3
Notes and special cases:
1. There are no checks for absence of these facts in other submission sets, instance types, or contexts.
3.3.5 Payment Contexts
An RXP.US or RXP.FPI instance is likely to have more than one payment, and therefore more than one
payment context. The existence of even a single payment context fact requires that there exist facts to
represent the aggregated sum of individual payments by project, by government, and in total.
A set of concepts in the RXP taxonomy characterizes aggregate payments of nine types. In each case, the
existence of a non-null fact value for that aggregate concept in any context should be accompanied by at
least one Payment fact in some context with the matching member as value.
Concept # Type or regex Meaning
rxp:P {1} Custom member of rxp:AllPayment- Payment Type
TypesMember
rxp:Taxes {2} Monetary Taxes
rxp:Royalties {3} Monetary Royalties
rxp:Fees {4} Monetary Fees
rxp:Production-
{5} Monetary Production Entitlements
Entitlements
rxp:Bonuses {6} Monetary Bonuses
rxp:Dividends {7} Monetary Dividends
rxp:Infrastructure-
{8} Monetary
Infrastructure
Improvements Improvements
rxp:CommunityAnd-
{9} Monetary Community and Social
Social
rxp:OtherPayments {10} Monetary Other Payments
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If a {1} fact valued rxp:Taxes is {1} {2}
i: RXP.US, pc, Value
§ 6.5.58 Item
present, then at least one {2} fact 1 W
RXP.FPI r Dependency 7
is present in the required context.

58
 Incl Excl c Check f On failure s EFM v68 Ref
If a {2} fact is present, then a
{2} {1}
i: RXP.US, r, {1} fact valued rxp:Taxes is § 6.5.58 Item
1 Value W
RXP.FPI pc present in at least one payment Dependency 6
context.
If a {1} fact valued
{1} {3}
i: RXP.US, pc, rxp:Royalties is present, then at § 6.5.58 Item
1 Value W
RXP.FPI r least one {3} fact is present in the Dependency 7
required context.
If a {3} fact is present, then a
{3} {1}
i: RXP.US, r, {1} fact valued rxp:Royalties § 6.5.58 Item
1 Value W
RXP.FPI pc is present in at least one payment Dependency 6
context.
If a {1} fact valued rxp:Fees is {1} {4}
i: RXP.US, pc, § 6.5.58 Item
present, then at least one {4} fact 1 Value W
RXP.FPI r Dependency 7
is present in the required context.
If a {4} fact is present, then a
{4} {1}
i: RXP.US, r, {1} fact valued rxp:Fees is § 6.5.58 Item
1 Value W
RXP.FPI pc present in at least one payment Dependency 6
context.
If a {1} fact valued
rxp:ProductionEntitlements {1} {5}
i: RXP.US, pc, is present, then at least one {5} § 6.5.58 Item
1 Value W
RXP.FPI r fact is present in the required Dependency 7
context.
If a {5} fact is present, then a
{1} fact valued {5} {1}
i: RXP.US, r, § 6.5.58 Item
rxp:ProductionEntitlements 1 Value W
RXP.FPI pc is present in at least one payment Dependency 6
context.
If a {1} fact valued rxp:Bonuses
{1} {6}
i: RXP.US, pc, is present, then at least one {6} § 6.5.58 Item
1 Value W
RXP.FPI r fact is present in the required Dependency 7
context.
If a {6} fact is present, then a
{6} {1}
i: RXP.US, r, {1} fact valued rxp:Bonuses is § 6.5.58 Item
1 Value W
RXP.FPI pc present in at least one payment Dependency 6
context.
If a {1} fact valued
{1} {7}
i: RXP.US, pc, rxp:Dividends is present, then at § 6.5.58 Item
1 Value W
RXP.FPI r least one {7} fact is present in the Dependency 7
required context.
If a {7} fact is present, then a
{7} {1}
i: RXP.US, r, {1} fact valued rxp:Dividends § 6.5.58 Item
1 Value W
RXP.FPI pc is present in at least one payment Dependency 6
context.

59
 Incl Excl c Check f On failure s EFM v68 Ref
If a {1} fact valued rxp:
InfrastructureImprovements {1} {8}
i: RXP.US, pc, is present, then at least one {8} § 6.5.58 Item
1 Value W
RXP.FPI r fact is present in the required Dependency 7
context.
If a {8} fact is present, then a
{1} fact valued rxp: {8} {1}
i: RXP.US, r, § 6.5.58 Item
InfrastructureImprovements 1 Value W
RXP.FPI pc is present in at least one payment Dependency 6
context.
If a {1} fact valued rxp:
{1} {9}
i: RXP.US, pc, CommunityAndSocial is present, § 6.5.58 Item
1 Value W
RXP.FPI r then at least one {9} fact is Dependency 7
present in the required context.
If a {9} fact is present, then a
{9} {1}
i: RXP.US, r, {1} fact valued rxp: § 6.5.58 Item
1 Value W
RXP.FPI pc CommunityAndSocial is present Dependency 6
in at least one payment context.
If a {1} fact valued rxp:Other-
{1} {10}
i: RXP.US, pc, Payments is present, then at least § 6.5.58 Item
1 Value W
RXP.FPI r one {10} fact is present in the Dependency 7
required context.
If a {10} fact is present, then a
{10} {1}
i: RXP.US, r, {1} fact valued rxp:Other- § 6.5.58 Item
1 Value W
RXP.FPI pc Payments is present in at least Dependency 6
one payment context.
Notes and special cases:
1. The contexts of the monetary and the member-valued facts are distinct. The values of Amount rxp:A
facts may be reasonably expected to arithmetically sum by payment type to the aggregate fact in the
required context, but the validation process requires only that the corresponding aggregate facts exist.
3.3.6 Government Aggregate Contexts
A Government Aggregate Context (gac) is a context having a custom member of rxp:GovernmentAxis.
Concept # Type or regex Meaning
rxp:Gv {1} Custom member of rxp:AllGovernmentsMember Government
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If a government aggregate
context (gac) exists, then at {1} {2}
i: RXP.US, gac, § 6.5.58 Item
least one payment context (pc) 1 Value W
RXP.FPI pc Dependency 8
exists with a {1} fact having
that member value.
Notes and special cases:

60
1. The contexts of the monetary and the member-valued facts are distinct. The values of Amount rxp:A
facts may be reasonably expected to arithmetically sum across all members of the government axis,
but the validation process requires only that the corresponding aggregate facts exist.
3.3.7 Project Aggregate Contexts
A Project Aggregate Context (pac) is a context having a custom member of rxp:GovernmentAxis.
Concept # Type or regex Meaning
rxp:Pr {1} Custom member of rxp:AllProjectsMember Project
Validations:
Incl Excl c Check f On failure s EFM v68 Ref
If a project aggregate context
(pac) exists, then at least one {1} {2}
i: RXP.US, pac, § 6.5.58 Item
payment context (pc) exists 1 Value W
RXP.FPI pc Dependency 8
with a {1} fact having that
member value.
Notes and special cases:
1. The contexts of the monetary and the member-valued facts are distinct. The values of Amount rxp:A
facts may be reasonably expected to arithmetically sum across all members of the project axis, but the
validation process requires only that the corresponding aggregate facts exist.

4 Filing Fee Exhibits

4.1 Filing Fee Inline XBRL Atachments
An Inline XBRL Filing Fee exhibit may be prepared using EDGAR’s Fee Exhibit Preparation Tool
(FEPT) as part of EDGAR Link Online (ELO) or by a third-party Inline XBRL document preparation
tool.
The Inline XBRL Filing Fee exhibit is identified as the “EX-FILING FEES” attachment document type.
(The Inline XBRL Filing Fee exhibit (EX-Filing Fees) is a separate XBRL instance identified as
“EX-FILING FEES.”) EX-Filing Fees is independent of any primary document attachments comprising
an Inline XBRL Document Set (such as for a 10-K exhibit) or any other Inline XBRL instance. The
EX-Filing Fee taxonomy, facts, units, and their supporting contexts, should not be comingled with any
other Inline XBRL instances. Selecting a different document type will result in the submission being
suspended.
The exhibit is viewed and prepared as tables (specified by the link roles of the FFD taxonomy dimensions
hypercubes). These tables may have more than one line use per a line number typed dimension to identify
which facts are logically grouped on that line. (The line number is an integer with no constraints, it could
be sequential or anything else meaningful to the author.)
The Tables are:
Table (link role name) Table has lines (lineNo dimension members)
Submission Table No
Fees Summary Table No
Fees, by Offering Yes
Fees, by Offset Yes

61
 Fees, by Combined Prospectus Yes
Securities, 424I Yes
The words “must” or “must not” mean that if the validation fails, an error will be raised, and the
submission will be suspended.
The words “should” or “should not” mean that if the validation fails, the exhibit will be accepted, and a
warning message will be issued.
The words “may” or “may not” mean that there is no validation that would result in a warning or error.
4.1.1 Security Types Based on Rule
The following table shows the security types applicable to each rule:
Rules
Security Type 457(a) 457(o) 457(f) 457(u) 457(r) 457(s) Other
Asset-Backed Securities Yes Yes Yes No No Yes Yes
Debt Yes Yes Yes No Yes No Yes
Debt Convertible into Equity Yes Yes Yes No Yes No Yes
Equity Yes Yes Yes No Yes No Yes
Exchange-Traded Vehicle Securities Yes Yes Yes Yes Yes No Yes
Face Amount Certificates No No No No No No Yes
Limited Partnership Interests Yes Yes Yes No Yes No Yes
Mortgage-Backed Securities Yes Yes Yes No No Yes Yes
Non-Convertible Debt Yes Yes Yes No Yes No Yes
Other Yes Yes Yes No Yes No Yes
Unallocated (Universal) Shelf No Yes No No No No No
4.1.2 Offering & Transac�on Valua�on Rules Applicable for Submission Types
Rules
Submission Types 457(a) 415(a)(6) 457(f) 457(u) 457(r) 457(s) 0-11**
457(o)
Other
424I No No No Yes* No No No
F-1 Yes Yes Yes Yes No No No
F-3 Yes Yes No Yes No No No
F-3ASR Yes Yes No No Yes No No
F-3D Yes Yes No Yes No No No
N-2 Yes Yes No No No No No
N-2ASR Yes Yes No No Yes No No
S-1 Yes Yes Yes Yes No No No
S-3 Yes Yes No Yes No No No
S-3D Yes Yes No Yes No No No
S-3ASR Yes Yes No No Yes No No
S-11 Yes Yes Yes No No No No
SF-1 Yes No No No No No No
SF-3 Yes Yes No No No Yes No
F-1/A Yes Yes Yes Yes No No No
62
 Rules
Submission Types 457(a) 415(a)(6) 457(f) 457(u) 457(r) 457(s) 0-11**
457(o)
Other
F-3/A Yes Yes No Yes No No No
N-2/A Yes Yes No No No No No
N-2 POSASR Yes Yes No No Yes No No
POSASR Yes Yes No No Yes No No
POS AM Yes Yes Yes No No No No
S-1/A Yes Yes Yes Yes No No No
S-3/A Yes Yes No Yes No No No
S-11/A Yes Yes Yes No No No No
SF-1/A Yes No No No No No No
SF-3/A Yes Yes No No No Yes No
F-4 Yes Yes Yes No No No No
F-10 Yes No No No No No No
F-10EF Yes No No No No No No
N-14 8C Yes No Yes No No No No
S-4 Yes Yes Yes No No No No
S-4EF Yes Yes Yes No No No No
F-4/A Yes Yes Yes No No No No
F-10/A Yes No No No No No No
N-14 8C/A Yes No Yes No No No No
S-4/A Yes Yes Yes No No No No
PREM14A No No No No No No Yes
PREM14C No No No No No No Yes
SC 13E1 No No No No No No Yes
SC 13E3 No No No No No No Yes
SC TO-I No No No No No No Yes
SC TO-T No No No No No No Yes
SC13E4F No No No No No No Yes
SC14D1F No No No No No No Yes
PRER14A No No No No No No Yes
PRER14C No No No No No No Yes
SC 13E1/A No No No No No No Yes
SC 13E3/A No No No No No No Yes
SC13E4F/A No No No No No No Yes
SC14D1F/A No No No No No No Yes
SC TO-I/A No No No No No No Yes
SC TO-T/A No No No No No No Yes
F-3MEF Yes Yes No No No No No
N-2MEF Yes Yes No No No No No
63
 Rules
Submission Types 457(a) 415(a)(6) 457(f) 457(u) 457(r) 457(s) 0-11**
457(o)
Other
S-3MEF Yes Yes No No No No No
SF-1MEF Yes No No No No No No
SF-3MEF Yes Yes No No No No No
F-1MEF Yes Yes Yes No No No No
F-4MEF Yes Yes Yes No No No No
S-4MEF Yes Yes Yes No No No No
N-14MEF Yes No Yes No No No No
S-1MEF Yes Yes Yes No No No No
S-11MEF Yes Yes Yes No No No No
424B1 Yes Yes Yes No Yes Yes No
424B2 Yes Yes Yes No Yes Yes No
424B3 Yes Yes Yes No Yes Yes No
424B4 Yes Yes Yes No Yes Yes No
424B5 Yes Yes Yes No Yes Yes No
424B7 Yes Yes Yes No Yes Yes No
424B8 Yes Yes Yes No Yes Yes No
424H Yes Yes No No No Yes No
424H/A Yes Yes No No No Yes No
S-8 Yes No No No No No No
*Rule 457(u) is inferred on 424I submissions.
** Rule 0-11 is inferred for applicable submission types as described in section 4.5.
4.1.3 Offset Table & Combined Prospectus Rules Applicable for Submission Types
Rules
Submission
457(b) 0-11(a)(2) 457(p) 429
Types
424I No No Yes** No
F-1 Yes Yes Yes Yes
F-3 Yes Yes Yes Yes
F-3ASR Yes Yes Yes Yes
F-3D Yes No Yes Yes
N-2 Yes Yes Yes Yes
N-2ASR Yes Yes Yes Yes
S-1 Yes Yes Yes Yes
S-3 Yes Yes Yes Yes
S-3D Yes No Yes Yes
S-3ASR Yes Yes Yes Yes
S-11 Yes Yes Yes Yes

64
 Rules
Submission
457(b) 0-11(a)(2) 457(p) 429
Types
SF-1 Yes No Yes Yes
SF-3 Yes No Yes Yes
F-1/A Yes Yes Yes Yes
F-3/A Yes Yes Yes Yes
N-2/A Yes Yes Yes Yes
N-2 POSASR Yes Yes Yes Yes
POSASR Yes Yes Yes Yes
POS AM Yes Yes Yes Yes
S-1/A Yes Yes Yes Yes
S-3/A Yes Yes Yes Yes
S-11/A Yes Yes Yes Yes
SF-1/A Yes No Yes Yes
SF-3/A Yes No Yes Yes
F-4 Yes Yes Yes Yes
F-10 Yes Yes Yes Yes
F-10EF Yes Yes Yes Yes
N-14 8C Yes Yes Yes Yes
S-4 Yes Yes Yes Yes
S-4EF Yes Yes Yes Yes
F-4/A Yes Yes Yes Yes
F-10/A Yes Yes Yes Yes
N-14 8C/A Yes Yes Yes Yes
S-4/A Yes Yes Yes Yes
PREM14A No Yes No No
PREM14C No Yes No No
SC 13E1 No Yes No No
SC 13E3 No Yes No No
SC TO-I No Yes No No
SC TO-T No Yes No No
SC13E4F No Yes No No
SC14D1F No Yes No No
PRER14A No Yes No No
PRER14C No Yes No No
SC 13E1/A No Yes No No
SC 13E3/A No Yes No No
SC13E4F/A No Yes No No
SC14D1F/A No Yes No No
SC TO-I/A No Yes No No
SC TO-T/A No Yes No No
F-3MEF Yes Yes Yes Yes

65
 Rules
Submission
457(b) 0-11(a)(2) 457(p) 429
Types
N-2MEF Yes Yes Yes Yes
S-3MEF Yes Yes Yes Yes
SF-1MEF Yes No Yes Yes
SF-3MEF Yes No Yes Yes
F-1MEF Yes Yes Yes Yes
F-4MEF Yes Yes Yes Yes
S-4MEF Yes Yes Yes Yes
N-14MEF Yes Yes Yes Yes
S-1MEF Yes Yes Yes Yes
S-11MEF Yes Yes Yes Yes
424B1 Yes Yes Yes Yes
424B2 Yes Yes Yes Yes
424B3 Yes Yes Yes Yes
424B4 Yes Yes Yes Yes
424B5 Yes Yes Yes Yes
424B7 Yes Yes Yes Yes
424B8 Yes Yes Yes Yes
424H Yes No Yes Yes
424H/A Yes No Yes Yes
S-8 No No Yes No
** Offset sources are not required for 424I submission type.
4.2 Submission Table
The following submission table facts are currently specified by EFM version 68, § 6.5.21 as follows:

Exhibit Type
EX-FILING FEE
DEI Element
EntityRegistrantName X*
EntityCentralIndexKey X*

In the required context:

• X* – A non-null fact must exist.
The remainder of this section specifies table facts specific to Filing Fee attachments:
Submission
Type 424I Others*
FFD Element
RegnFileNb W WA
FormTp XS
SubmissnTp X*

66
 Submission
Type 424I Others*
FFD Element
FeeExhibitTp XF
IssrNm W, T
IssrBizAdrStrt1 W
IssrBizAdrStrt2 W2
IssrBizAdrCity W
IssrBizAdrStatOrCtryCd W2
IssrBizAdrZipCd W
CeasedOprsDt O, o
WD, DB,
RptgFsclYrEndDt
Future

In the required context:

• X* – A non-null fact should exist.
• W– A non-null fact should exist (warning).
• WA – For Amendment/MEF Filings, non-null fact should exist (submission types S-1/A, S-3/A,
S-11/A, N-2/A, F-1/A, F-3/A, SF-1/A, SF-3/A, N-2 POSASR, POS AM, POSASR, S-4/A, N-14
8C/A, F-4/A, F-10/A, SF-1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N-
14MEF, S-1MEF, S-4MEF, S-11MEF, 424B1, 424B2, 424B3, 424B4, 424B5, 424B7, 424B8,
424H, 424H/A) (warning).
• W2 – Only when IssrBizAdrStrt1 is provided.
• O– A non-null fact may or may not exist.
• XS – FormTp must match an allowed form type for the submission type (e.g., F-4 for F-4/A or
F-4MEF Submission Types).
• XF – FeeExhibitTp has the value EX-FILING FEES.
• D– EDGAR date field validations, expected Value between 1980-01-01 and 2050-12-31
(warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• WD – Required if CeasedOprsDt is not provided (warning).
• DB – When provided, must match Database record of filer registration.
• Future – Must not be a future date.
• Blank – A non-null fact should not exist.
• Others* – All submission types specified in section 4.1.2 excluding 424I.
4.3 Fees Summary Table
This table has no dimensions. This table shows the validations.

67
 Submission Type
424I SC* Others*
FFD Element

TtlOfferingAmt TtlOfferingAmt = Sum of

MaxAggtOfferingPric [1]

TtlPrevslyPdAmt NR*, TtlPrevslyPdAmt not greater than TtlFeeAmt

[3]

TtlFeeAmt NR*, Sum of

FeeAmt [2]
NR*, Sum of FeeAmt [1]
Sum of
TtlTxValtn
TxValtn [1]
TtlFeeAmt ×
FeeIntrstAmt intrstRate ×
yrs late

NR*, TtlFeeAmt + NR*, TtlOffsetAmt not greater than

TtlOffsetAmt
FeeIntrstAmt TtlFeeAmt - TtlPrevslyPdAmt
NR*, TtlFeeAmt -
NR*, TtlFeeAmt – TtlOffsetAmt -
NetFeeAmt TtlOffsetAmt +
TtlPrevslyPdAmt
FeeIntrstAmt
TtlFeeAmt +
TtlFeeAndIntrstAmt
FeeIntrstAmt

• SC* – SC 13E1, SC 13E3, SC13E4F, PREM14A, PREM14C, SC TO-I, SC TO-T, SC14D1F,

SC 13E1/A, SC 13E3/A, SC 13E4F/A, PRER14A, PRER14C, SC14D1F/A, SC TO-T/A, SC TO-
I/A.
• Others* - All submission types specified in section 4.1.2 excluding 424I and SC*.
• NR* - Must be a number ranging from 0 to 99,999,999,999,999.99 inclusive.
• [1] – From the Offerings table.
• [2]– From the 424I table.
• [3] – Regardless of whether the filer is claiming an offset or not.
Submission
Type
POS* 424B* Validation
FFD Element
ND,
NrrtvDsclsr ND
HTML
NrrtvMaxAggtOfferingPric Either
NP, NP,
ND or NP
NrrtvMaxAggtAmt NR NR

FnlPrspctsFlg O

In the required context:

• POS* – POS AM, POSASR, N-2 POSASR.

68
 • 424B* – 424B1, 424B2, 424B3, 424B4, 424B5, 424B7, 424B8
• HTML – XHTML encoded text block (^ and non-ASCII characters must be &#-encoded).
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• ND – Narrative disclosure.
• NP – Narrative price.
4.4 Offering Table
Offering table facts are grouped by lineNo integer values of the Offerings Axis into lines. Validations are
performed by line (on the facts of the table which have the same lineNo member). Missing lineNo
members results in an XBRL Dimensional syntax error.
Offering table lines are grouped into two Offering Types: Fees to be Paid and Fees Previously Paid. A
Fees to be Paid line has a value of false for the PrevslyPdFlg element. A Fees Previously Paid line has a
value of true for the PrevslyPdFlg element.
4.5 Offering Table Rule Flags
The rule flags identify the rule applicable to a line, one of Rule457aFlg, Rule457oFlg, Rule457uFlg,
Rule457rFlg, Rule457sFlg, Rule011Flg, FeesOthrRuleFlg, or Rule415a6Flg may be specified for a
line, except when Rule011Flg can be deemed to be defaulted. Rule011Flg is deemed to have the value
true when none of the other flags are true in submission types applicable to Rule 0-11 as specified in
section 4.1.2 above.
4.5.1 Rule 457(a) Lines
The following validations are provided for lines specifying Rule457aFlg, for applicable submission types
as specified in section 4.1.2 above.

Offering Type Fees to be Fees

previously Validation*
FFD Element paid
paid
PrevslyPdFlg W, FA

Should be a valid EDGAR Security

OfferingSctyTp [1] W
Type for this rule as specified in the
“Security Types Based on Rule”
section 4.1.1
OfferingSctyTitl [1] W, T
AmtSctiesRegd [1] W, NR3
MaxOfferingPricPerScty
W, NR1
[1]
AmtSctiesRegd ×
MaxAggtOfferingPric [1] W, NR DB
MaxOfferingPricPerScty
FeeRate [1] W, FD UO
FeeAmt [1] W, NR2 MaxAggtOfferingPric × FeeRate
OfferingNote HTML

In a context with lineNo dimensions:

69
 • 1
– Not applicable when Rule 457(f) is specified for the same context (see 4.5.9 Rule 457(f)).
• W– Required, including any additional validation in adjacent column (warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded)
• FA – Should be false for non-amendment submission types (S-1, S-3, S-3ASR, S-3D, S-11,
N-2, N-2ASR, F-1, F-3, F-3ASR, F-3D, SF-1, SF-3, S-4, S-4EF, N-14 8C, F-4, F-10, F-10EF,
SF-1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N-14MEF, S-1MEF,
S-4MEF, S-11MEF, S-8)
• FD – Should match the fee rate of the day submitted.
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR1 – Number ranging from 0 to 999,999,999,999.9999 inclusive.
• NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
• NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• DB – Maximum Aggregate Offering Price (MAOP) amount provided should match the prior
filing using the Security Type and Security Class Title combination for the file number specified
on the filing.
• UO – Unexpected, may be omitted.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.2 Rule 457(o) Lines
The following validations are provided for lines specifying Rule457oFlg, for applicable submission types
as specified in section 4.1.2.
Offering Type Fees
Fees to be
previously Validation*
paid
paid
FFD Element
PrevslyPdFlg W, FA
Should be a valid EDGAR
OfferingSctyTp [1] W
Security Type for this rule as
specified in the “Security Types
Based on Rule” section 4.1.1
OfferingSctyTitl [1] W, T
AmtSctiesRegd [1] NR3, UO
MaxOfferingPricPerScty
NR1, UO
[1]
MaxAggtOfferingPric [1] W, NR

FeeRate [1] W, FD UO
FeeAmt [1] W, NR2
OfferingNote HTML

70
In a context with lineNo dimensions:
• 1
– Not applicable when Rule457fFlg is specified for the same context (see 4.5.9 Rule
457(f))
• W– Required, including any additional validation in adjacent column (warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• FA – Should be false for non-amendment submission types (S-1, S-3, S-3ASR, S-3D, S-11,
N-2, N-2ASR, F-1, F-3, F-3ASR, F-3D, SF-1, SF-3, S-4, S-4EF, N-14 8C, F-4, F-10, F-10EF,
SF-1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N-14MEF, S-1MEF,
S-4MEF, S-11MEF, S-8).
• FD – Should match the fee rate of the day submitted.
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR1 – Number ranging from 0 to 999,999,999,999.9999.
• NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
• NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• UO – Unexpected, may be omitted.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.3 Rule 457(r) Lines
The following validations are provided for lines specifying Rule457rFlg, for applicable submission types
as specified in section 4.1.2.

Offering Type Fees

Fees to be
previously Validation*
paid
paid
FFD Element
PrevslyPdFlg W, FA

Should be a valid EDGAR

OfferingSctyTp W Security Type for this rule as
specified in section 4.1.1
OfferingSctyTitl W, T

AmtSctiesRegd NR3, UO

MaxOfferingPricPerScty NR1, UO

MaxAggtOfferingPric NR, UO

FeeRate O, FD UO

FeeAmt O, NR2

71
 Offering Type Fees
Fees to be
previously Validation*
paid
paid
FFD Element
OfferingNote W, HTML

In a context with lineNo dimensions:

• W– Required, including any additional validation in adjacent column (warning).
• O– Optional.
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• FA – Should be false for non-amendment submission types (S-1, S-3, S-3ASR, S-3D, S-11, N-
2, N-2ASR, F-1, F-3, F-3ASR, F-3D, SF-1, SF-3, S-4, S-4EF, N-14 8C, F-4, F-10, F-10EF, SF-
1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N-14MEF, S-1MEF, S-4MEF,
S-11MEF, S-8).
• FD – Should match the fee rate of the day submitted.
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR1 – Number ranging from 0 to 999,999,999,999.9999.
• NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
• NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• UO – Unexpected, may be omitted.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.4 Rule 457(s) Lines
The following validations are provided for lines specifying Rule457sFlg, for applicable submission types
as specified in section 4.1.2.
Offering Type Fees
Fees to
previously Validation*
be paid
FFD Element paid
PrevslyPdFlg W, FA
Should be a valid EDGAR Security
OfferingSctyTp W Type for this rule as specified in section
4.1.1
OfferingSctyTitl W, T
AmtSctiesRegd NR3, UO
MaxOfferingPricPerScty NR1, UO
AmtSctiesRegd ×
MaxAggtOfferingPric NR, UO MaxOfferingPricPerScty; 0 is
allowed.
FeeRate O, FD UO

72
 Offering Type Fees
Fees to
previously Validation*
be paid
FFD Element paid
FeeAmt O, NR2
OfferingNote W, HTML

In a context with lineNo dimensions:

• W– Required, including any additional validation in adjacent column (warning).
• O– Optional.
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• FA – Should be false for non-amendment submission types (SF-3).
• FD – Should match the fee rate of the day submitted.
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR1 – Number ranging from 0 to 999,999,999,999.9999.
• NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
• NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• UO – Unexpected, may be omitted.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.5 Rule 457(u) Lines
The following validations are provided for lines specifying Rule457uFlg, for applicable submission types
as specified in section 4.1.2.
Offering Type Fees
Fees to be
previously Validation*
paid
FFD Element paid
PrevslyPdFlg W, FA
W Should be a valid EDGAR Security
OfferingSctyTp Type for this rule as specified in
section 4.1.1
OfferingSctyTitl W, T

AmtSctiesRegd UW
MaxOfferingPricPerS UW
cty
UW
MaxAggtOfferingPric

FeeRate UW

FeeAmt UW

OfferingNote W, HTML

In a context with lineNo dimensions:

73
 • W– Required, including any additional validation in adjacent column (warning).
• O– Optional.
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• FA – Should be false for non-amendment submission types (S-1, S-3, S-3D, F-1, F-3, F-3D).
• UW – Unexpected, should be omitted.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.6 Rule “Other” Lines
The following validations are provided for lines specifying FeesOthrRuleFlg, for applicable submission
types as specified in section 4.1.2.

Offering Type Fees to be Fees

previously Validation*
paid
FFD Element paid
PrevslyPdFlg W, FA
W Should be a valid EDGAR Security
OfferingSctyTp [1]
Type for this rule as specified in the
“Security Types Based on Rule”
section 4.1.1
OfferingSctyTitl [1] W, T

AmtSctiesRegd [1] O, NR3

MaxOfferingPricPerScty O, NR1
[1]
O, NR DB AmtSctiesRegd ×
MaxAggtOfferingPric [1]
MaxOfferingPricPerScty
FeeRate [1] O, FD UO
W, NR2 MaxAggtOfferingPric × FeeRate
FeeAmt [1] When MaxAggtOfferingPric is
absent FeeAmt should equal 0.
OfferingNote [1] W, HTML

In a context with lineNo dimensions:

• 1
– Not applicable when Rule 457(f) is specified for the same context (see 4.5.9).
• W– Required, including any additional validation in adjacent column (warning).
• O– Optional.
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• FA – Should be false for non-amendment submission types (S-1, S-3, S-3ASR, S-3D, S-11, N-
2, N-2ASR, F-1, F-3, F-3ASR, F-3D, SF-1, SF-3, S-4, S-4EF, N-14 8C, F-4, F-10, F-10EF, SF-

74
 1MEF, SF-3MEF, N-2MEF, S-3MEF, F-3MEF, F-1MEF, F-4MEF, N-14MEF, S-1MEF, S-4MEF,
S-11MEF, S-8).
• FD – Should match the fee rate of the day submitted.
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR1 – Number ranging from 0 to 999,999,999,999.9999.
• NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
• NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• DB – Maximum Aggregate Offering Price (MAOP) amount provided should match the prior
filing using the Security Type and Security Class Title combination for the file number specified
on the filing.
• UO – Unexpected, may be omitted.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.7 Rule 415(a)(6) Lines
The following validations are provided for lines specifying Rule415a6Flg, for applicable submission
types as specified in section 4.1.2.
Offering Type Fees
Fees to be
previously Validation*
paid
FFD Element paid
PrevslyPdFlg UW
W Should be a valid EDGAR Security
OfferingSctyTp
Type for this rule as specified in the
“Security Types Based on Rule”
section 4.1.1
OfferingSctyTitl W, T

AmtSctiesRegd DB, NR3

MaxOfferingPricPerScty O, NR1
W, DB, NR
MaxAggtOfferingPric

FeeRate UW

FeeAmt UW

CfwdFormTp W Should be a valid EDGAR Form Type

W Validate that it has the following
CfwdPrrFileNb (Securities Act) File Number prefixes:
333, 033, 002
CfwdPrrFctvDt D, DB

CfwdPrevslyPdFee W, NR2

OfferingNote O, HTML

In a context with lineNo dimensions:

• W– Required, including any additional validation in adjacent column (warning).
• O– Optional.

75
 • D– EDGAR date field validations, expected Value between 1980-01-01 and 2050-12-31
(warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• FD – Should match the fee rate of the day submitted.
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR1 – Number ranging from 0 to 999,999,999,999.9999.
• NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
• NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• DB – Validate with EDGAR Database.
• UW – Unexpected, should not be provided.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.8 Rule 0-11 Lines
The following validations are provided for lines specifying Rule011Flg or having it deemed true as
noted in section 5, for applicable submission types as specified in section 4.1.2.
Offering Type Fees
Fees to be
previously Validation*
paid
FFD Element paid
PrevslyPdFlg W, FA
TxValtn [1] W, NR
FeeRate W, FD UO
FeeAmt [1] W, NR2, CEF MaxAggtOfferingPrice × FeeRate
OfferingNote W, HTML

In a context with lineNo dimensions:

• 1
– For amendment filings, this field may be blank for “Fees To be Paid” lines.
• W– Required, including any additional validation in adjacent column (warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• FA – Should be false for non-amendment submission types (SC 13E1, SC 13E3, SC13E4F,
PREM14A, PREM14C, SC TO-I, SC TO-T, SC14D1F).
• FD – Should match the fee rate of the day submitted.
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
• CEF – Closed End Funds (parameter) warning if overridden with 0.

76
 • UO – Unexpected, may be omitted. Warning if specified.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.9 Rule 457(f) Lines
The following validations are provided for lines specifying Rule457fFlg, which must be used on a line
(i.e., the flag facts having same lineNo dimension) with Rule457aFlg, Rule457oFlg, or
FeesOthrRuleFlg for applicable submission types as specified in section 4.1.2.

Offering Type Fees to Fees

be previously Validation*
FFD Element paid paid
OfferingSctyTp W
Should be a valid EDGAR Security Type
for this rule as specified in section 4.1.1
OfferingSctyTitl W, T
AmtSctiesRegd 457(a) W, NR3
AmtSctiesRegd 457(o),
O, NR3
Other
MaxOfferingPricPerScty UO, NR1
AmtSctiesRegd ×
MaxAggtOfferingPric W, NR MaxOfferingPricPerScty
FeeRate W, FD UO
FeeAmt W, NR2 DB MaxAggtOfferingPric × FeeRate

The following are fee note facts, usually displayed in a footnote style below table containing 457(f)
facts above
AmtSctiesRcvd W, NR3
ValSctiesRcvdPerShr W, NR1
AmtSctiesRcvd x
ValSctiesRcvd W, NR
ValSctiesRcvdPerShr
CshRcvdByRegistrantInTx O, NR
CshPdByRegistrantInTx O, NR
ValSctiesRcvd +
FeeNoteMaxAggtOfferingPric I, NR CshRcvdByRegistrantInTx -
CshPdByRegistrantInTx
OfferingNote W, HTML

In a context with lineNo dimensions:

• W– Required, including any additional validation in adjacent column (warning).
• O– Optional.
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• FD – Should match the fee rate of the day submitted.
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR1 – Number ranging from 0 to 999,999,999,999.9999 inclusive.
• NR2 – Number ranging from 0 to 999,999,999,999.99 inclusive.
77
 • NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• DB – Amount of Registration Fee provided should match the prior filing using the Security
Type and Security Class Title combination for the file number specified on the filing.
• UO – Unexpected, may be omitted.
• I– Info msg if negative, will be processed as zero.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.2.
4.5.10 General Instruc�ons II.H (Exchange Offers) and II.I (Business Combina�ons)
The validations in section 4.5.9 are also applicable for lines specifying GnlInstrIIhiFlg, which must be
used on a line (i.e., the flag facts having same lineNo dimension) with Rule457aFlg, Rule457oFlg, or
FeesOthrRuleFlg for applicable submission types F-10, F-10/A, and F-10EF.

4.6 Offset Table

Offset table facts are grouped by lineNo dimension into lines. Validations are performed by line (on the
facts of the table which have the same lineNo dimension member). Dimensional errors (missing lineNo
dimension) are according to applicable XBRL standard.
Offset table lines are grouped into two Offset Types: Offset Claim and Offset Source. An Offset Claim
line has a value of true for the OffsetClmdInd element. An Offset Source line has a value of false for
the OffsetClmdInd element.
4.6.1 Offset Table Rule Flags
The rule flags identify the rule applicable to a line, one of Rule457bOffsetFlg, Rule011a2OffsetFlg, or
Rule457pOffsetFlg may be specified for a line.
4.6.2 Rule 457(b) or 0-11(a)(2)) Lines
The following validations are provided for lines specifying Rule457bOffsetFlg or
Rule011a2OffsetFlg, for applicable submission types as specified in section 4.1.3.

Offset Type
Offset Offset
Validation*
Claim Source
FFD Element
OffsetClmdInd W
A fee offset claim line requires at least one fee
offset source line
W, T,
OffsetPrrFilerNm UW
DB
OffsetPrrFormTp W, DB Should be a valid EDGAR Form Type
Validate it includes the following (Securities
OffsetPrrFileNb W, DB Act/Exchange Act) File Number prefixes: 333,
033, 002, 001, 811, 814, 005, 000
W, D,
OffsetClmInitlFilgDt UW
Future
W, D,
OffsetSrcFilgDt UW
Future
OffsetClmdAmt W, NR UW
W, NR,
OffsetPrrFeeAmt UW
DB

78
 Offset Type
Offset Offset
Validation*
Claim Source
FFD Element
WSA,
OffsetExpltnForClmdAmt U
HTML
OffsetNote O, HTML

In a context with lineNo dimensions:

• W– Required, including any additional validation in adjacent column (warning).
• O– Optional
• WSA – Required when claiming from a Securities Act filing (file number prefixes 333, 033, 002
file number). Optional when claiming from the Exchange Act filings (file number prefixes 811,
814, 005, 001,000.
• D– EDGAR date field validations, expected Value between 1980-01-01 and 2050-12-31
(warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• DB – Validate prior filing.
• UW – Unexpected, warning.
• U– Unexpected.
• Future – Should not be a future date.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.3
above.
4.6.3 Rule 457(p) Lines
The following validations are provided for lines specifying Rule457pOffsetFlg, for applicable submission
types as specified in section 4.1.3.
Offset Type
Offset Offset
Validation*
Claim Source
FFD Element
OffsetClmdInd W
A fee offset claim line requires at least one
fee offset source line
OffsetPrrFilerNm W, T, DB
OffsetPrrFormTp W, DB Should be a valid EDGAR Form Type
OffsetPrrFileNb W, DB
Validate it includes the following (Securities
Act) File Number prefixes: 333, 033, 002
W, D
OffsetClmInitlFilgDt UW
Future
W, D,
OffsetSrcFilgDt UW
Future
OffsetClmdAmt W, NR UW

79
 Offset Type
Offset Offset
Validation*
Claim Source
FFD Element
OffsetPrrSctyTp W UW Should be a valid EDGAR Security Type
OffsetPrrSctyTitl W, T UW

OffsetPrrNbOfUnsoldScties W, NR3 UW
W, NR,
OffsetPrrFeeAmt UW
DB
OffsetNote O, HTML
TermntnCmpltnWdrwl W, HTML U

In a context with lineNo dimensions:

• W– Required, including any additional validation in adjacent column (warning).
• O– Optional
• D– EDGAR date field validations, expected Value between 1980-01-01 and 2050-12-31
(warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• DB – Validate prior filing.
• UW – Unexpected, warning.
• U– Unexpected.
• Future – Should not be a future date.
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.3.
4.7 Combined Prospectus Table
Combined Prospectus table facts are grouped by lineNo dimension into lines. Validations are performed
by line (on the facts of the table which have the same lineNo dimension member). Dimensional errors
(missing lineNo dimension) are according to applicable XBRL standard.
4.7.1 Combined Prospectus Table Rule Flags
The rule flags identify the rule applicable to a line, Rule429CmbndPrspctsFlg should be specified for each
line.
4.7.2 Combined Prospectus Lines Specifying Rule 429
The following validations are provided for lines specifying Rule429CmbndPrspctsFlg, for applicable
submission types as specified in section 4.1.3.

80
 Combined
FFD Element Validation*
Prospectus
Rule429SctyTp W Should be a valid EDGAR Security Type
Rule429SctyTitl W, T
Rule429NbOfUnsoldScties NR3, DB
Rule429AggtOfferingAmt NR, DB
Rule429EarlierFormTp W Should be a valid EDGAR Form Type
Validation includes the following (Securities Act)
Rule429EarlierFileNb W, DB
File Number prefixes: 333, 033, or 002, and that it is
not the same file number for offset claims in the
Offset Table (section 4) lines.
W, D,
Rule429InitlFctvDt
Future
Rule429PrspctsNote O, HTML

In a context with lineNo dimensions:

• W– Required, including any additional validation in adjacent column (warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• D– EDGAR date field validations, expected Value between 1980-01-01 and 2050-12-31
(warning).
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR3 – Number ranging from 0 to 999,999,999,999 inclusive.
• DB – Validate with EDGAR Database.
• Future – Should not be a future date.
• O– Optional
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.3.
4.8 Securi�es, 424I
4.8.1 Securi�es, 424I Table Rule Flags
424I table facts are grouped by lineNo dimension into lines. Validations are performed by line (on the
facts of the table which have the same lineNo dimension member). Dimensional errors (missing lineNo
dimension) are according to applicable XBRL standard.
• Note: There are no rule flags for the 424I table.
4.8.2 Submission Type 424I Table Lines
The following validations are provided for lines of submission type 424I.
Securities,
FFD Element Validation*
424I
OfferingSctyTitl W, T

81
 Securities,
FFD Element Validation*
424I
AggtSalesPricFsclYr W, NR
AggtRedRpPricFsclYr W, NR
AggtRedRpPricPrrFsclYr W, NR
Required when AggtSalesPricFsclYr greater than
AggtRedRpPricFsclYr +
NetSalesAmt W, NR AggtRedRpPricPrrFsclYr, then NetSalesAmt =
AggtSalesPricFsclYr - AggtRedRpPricFsclYr -
AggtRedRpPricPrrFsclYr
When AggtSalesPricFsclYr less than
AggtRedRpPricFsclYr +
AmtRedCdts W, NR4 AggtRedRpPricPrrFsclYr then AmtRedCdts =
AggtSalesPricFsclYr - AggtRedRpPricFsclYr -
AggtRedRpPricPrrFsclYr
FeeRate W, FD
FeeAmt W, NR
FeeNote O, HTML

In a context with lineNo dimensions:

• W– Required, including any additional validation in adjacent column (warning).
• T– EDGAR text field validations, regex:
[0-9A-Za-z`~!@#$%&*(). [\]{}|\\:;"'<>,_?/=\t\n\r\f+-]{1,150} (warning).
• HTML – XHTML encoded text block (^ and non-ASCII must also be &#-encoded).
• D– EDGAR date field validations, expected Value between 1980-01-01 and 2050-12-31
(warning).
• NR – Number ranging from 0 to 99,999,999,999,999.99 inclusive.
• NR4 – Number ranging from -9,999,999,999,999.99 to 0 inclusive.
• FD – Should match the fee rate of the day submitted.
• O– Optional
• Validation* – Excluding and unexpected for submission types not specified in section 4.1.3.
4.8.3 Submission Type 424I Entries in the Submission Table
Certain 424I FFD elements apply to the Submission Table (instead of the breakdown lines of the 424I
Table of this section). Those elements are shown above in section 4.2, “Submission Table”.

5 Custom Taxonomies
In addition to attachments containing the instance, most instance types need at least one other attachment
that contains declarations of meta data: concepts and relationships unique to the filer or to the specific
submission. This collection of attachments is the custom taxonomy for the instance. The instance type
largely determines the degree to which customization is required or permitted.

82
5.1 Custom presenta�on and label rela�onships for standard concepts
Custom taxonomies are entirely optional when there is a taxonomy entry point providing all the necessary
label, definition, and presentation relationships. For example, if company UVW were an FPI submitting a
6K.A instance type, there is no need for a custom taxonomy: the instance could reference entry point
https://xbrl.sec.gov/dei/2025/dei-sub-2025.xsd (dei-sub) that contains all relationships needed
for the expected and expected facts in the dei namespace. However, if company UVW could choose to
use entry point https://xbrl.sec.gov/dei/2025/dei-2025.xsd (dei) instead, a custom taxonomy is
needed.
5.2 File atachments for custom rela�onships
EFM v69 § 6.4 explained that the naming convention for EDGAR XBRL files consists of a mnemonic
code chosen by the filer, such as a trading symbol, followed by other distinguishing text of the filer’s
choice, followed by a dash, followed by a date in the format YYYYMMDD, and a dot with a three-
character suffix. For example, a 6-K submission for the earliest date reported of October 15, 2025, of a
company with trading symbol UVW might have file name uvw6k-20251015.htm.

• An XBRL schema file.

o Its file name is like the instance, but with suffix .xsd, e.g., uvw6k-20251015.xsd;
o A targetNamespace attribute with a fixed pattern of authority and path components, reflecting
the company mnemonic and the period, e.g., target namespace http://uvw.net/20251015
declared with authority uvw.net and path 20251015 with prefix uvw.
o An import element for entry point https://xbrl.sec.gov/dei/2025/dei-2025.xsd.
o A custom roleType declaration for a role URI such as http://uvw/role/Cover, with a
definition text such as “010000 - Document - Cover" to be potentially used on calculation,
definition, and presentation links.
• A label linkbase embedded in the schema (or in a separate file uvw6k-20251015_lab.xml referenced
by the schema).
o The label linkbase contains links for the standard concepts used in facts, such as
dei:DocumentType and dei:AmendmentFlag.
• A presentation linkbase embedded in the schema (or in a separate file uvw6k-20251015_pre.xml
linked to by the schema). It will contain relationships in each presentation base set where the filer
wants facts rendered, in this case presumably the custom Cover role.
o A root element such as dei:CoverAbstract with six parent-child relationships, one to each
concept that could appear in facts.
o Presentation relationships may also use the preferredLabel attribute to specify which label role
to use during the rendering process.
5.3 Custom presenta�on and label rela�onships
There is no need, in this example, for definition linkbase relationships, in the absence of any axes,
members, or table structure. This is illustrated in Figure 5. Concepts are color coded and indented as in
Figure 1 above; column “o” the value of the order attribute on the parent-child arc, “p” the preferred label
role, if any; column “t” indicates a relationship that exists in a standard taxonomy and cannot be
overridden; the concept labels are shown with the same indentation as the concept names.

83
For the purposes of the example, terse labels illustrate that label text need not precisely match the concept
name, nor its standard label in the taxonomy.
Also, for the purposes of this example, the final column shows fact values.
Concept dei:AmendmentDescription has no fact value because dei:AmendmentFlag is false, and
because there is no fact to display, it also needs no label.
Figure 1 above showed a coloring convention for highlighting concept types; in the figures below, the
same convention is used to illustrate linkbase relationships. The concept is shown indented with respect
to its parent element, with a column indicating its data type.
Figure 5. Custom presentation and label relationships, no dimensions
Role URI: http://uvw/role/Cover
Description: 010000 – Document - Cover
Concept p t o Label Value in Required Context
dei:CoverAbstract Cover [Abstract]
dei:DocumentType terse 1 Form 6-K
dei:AmendmentFlag terse 2 Amended false
dei:AmendmentDescription 3
dei:EntityCentralIndexKey terse 4 CIK 0000012345
dei:EntityRegistrantName terse 5 Conformed Name WXY Ltd.
dei:DocumentPeriodEndDate terse 6 Reporting Date 2025-11-05

A presentation group is a presentation base set; that is, relationships that all have the same role (in this
example, http://uvw/role/Cover). The role may be a standard role from a standard taxonomy, or it
could be a custom role as shown in this example. Even for a standard role, the set of relationships might
be a mix of standard relationships from a standard taxonomy, or custom relationships. This means that
any given presentation group might be assembled from parts in several different files. An XBRL
processor handles prohibitions (relationships that cancel each other out) and many validations to produce
a presentation group of effective relationships.
5.4 Custom rela�onships for standard concepts, with dimensions
When only standard concepts, axes and standard members of those axes appear in an instance, its custom
taxonomy can usually be limited to providing only linkbases, with no custom element declarations. This
should be evident from the validations in section 3.1, “Expected Facts in the Required Context”.
Most of the validations in section 3.2 “Expected Facts with Dimensions” require valid relationships in an
accompanying custom taxonomy. For example, in section 3.2.3, several instance types in the submission
set FAST are expected to have a value for dei:EntityCommonStockSharesOutstanding; in case 2 a fact
is expected for each member of the us-gaap:StatementClassOfStockAxis. Moreover, almost all
instance types in submission set FA have expected facts that share a common concept but are
distinguished from each other by representing a disaggregation of a total by geography, line of business,
asset class, or any one or more possible distinctions. Sometimes there is no disaggregation per se, just a
common concept applied to several different things. See sections 3.1.24 through 3.3 above for specific
examples. In this section, instance type 8K.A for US company WXY will be used for an example.
5.4.1 File atachments for custom members
The 8K.A instance may still reference the dei-sub entry point. But, if it has classes A and B of common
shares, then its custom taxonomy for that instance needs at least additional content, as described below, to
satisfy the validations of section 3.2.3:

• An XBRL schema file.

84
 o Its file name is like the instance, but with suffix .xsd, e.g., wxy8k-20251015.xsd;
o A target namespace with a fixed pattern of authority and path components, reflecting the
company mnemonic and the period, e.g., target namespace http://wxy.net/20251015 declared
with authority wxy.net and path 20251015 with prefix wxy.
o An import of entry point https://xbrl.sec.gov/dei/2025/dei-sub-2025.xsd.
• A definition linkbase, embedded in the schema (or in a separate file wxy8k-20251015_def.xml linked
to by the schema), containing these dimensional relationships:
o Axis us-gaap:StatementClassOfStockAxis has a domain default member
us-gaap:ClassOfStockDomain;

o Domain us-gaap:ClassOfStockDomain has two members us-gaap:CommonClassAMember and

us-gaap:CommonClassBMember.

• A label linkbase embedded in the schema (or in a separate file wxy8k-20251015_lab.xml referenced
by the schema).
o The label linkbase contains links from the standard concept us-gaap:CommonClassAMember to at
least a standard label such as “Common Class A [Member]”.
o The label linkbase might include other labels for the concept, such as a label “Class A” with role
terseLabel or a long label such as “Class A common shares of WXY Inc.” with role
documentation.

o Likewise, us-gaap:CommonClassBMember will have one or more labels.

• A presentation linkbase embedded in the schema (or in a separate file wxy8k-20251015_pre.xml
referenced by the schema). It will contain presentation relationships in each presentation group where
the filer wants facts with the dimension members rendered:
o Axis us-gaap:StatementClassOfStockAxis has two parent-child relationships, one to each of
the two class members. In this example, the dei-sub entry point contains presentation links in
the http://xbrl.sec.gov/dei/role/document/Cover role.
o Presentation relationships may also use the preferredLabel attribute to specify which label role
to use during the rendering process.
5.4.2 Dimensional rela�onships
Figure 6 below illustrates the definition linkbase relationships in the custom taxonomy of the WXY 8K.A
instance type. An Arc column indicates the arc role, with an exclamation point (!) in column “t”
indicating the relationship is already in an imported entry point of a standard taxonomy and need not be
customized. If a targetRole attribute is present on the arc, there is a column Target with an abbreviation
for the target role.

85
Figure 6. Dimensional relationships example 1
Role: http://xbrl.sec.gov/dei/role/document/Entity-
InformationEntityListingsTable
Description: 995405 - Document - Entity Information,
Entity Listings [Table]
Concept Type Arc o t Target
dei:EntityListingsLineItems Abstract
dei:EntityListingsTable Hypercube all (closed) 1 !
us-gaap:StatementClassOfStockAxis Axis hypercube-dimension 1
us-gaap:ClassOfStockDomain Member dimension-domain 1
us-gaap:CommonClassAMember Member domain-member 1
us-gaap:CommonClassBMember Member domain-member 2
dei:CommonStockSharesOutstanding Shares domain-member 2 !

A different, more modular organization of the definition links, places the domain members in a separate
role. This organization, as illustrated in Figure 7, has the advantage of allowing any number of different
tables to share the identical members of a shared axis:
Figure 7. Dimensional relationships example 2
Role: http://xbrl.sec.gov/dei/role/document/Entity-
InformationEntityListingsTable
Description: 995405 - Document - Entity Information,
Entity Listings [Table]
Concept Type Arc o t Target
dei:EntityInformationLineItems Abstract
dei:EntitiesTable Hypercube all (closed) 1 !
us-gaap:StatementClassOfStockAxis Axis hypercube-dimension 1 Classes
dei:CommonStockSharesOutstanding Shares domain-member 2 !

A custom target role Classes contains only standard domain members:

Role URI: http://wxy/role/Classes
Description: 001 – Document - Classes
Concept Type Arc o t Target
us-gaap:ClassOfStockDomain Domain Member dimension-domain
us-gaap:CommonClassAMember Member domain-member 1
us-gaap:CommonClassBMember Member domain-member 2

In either arrangement, the relationship between an axis and its default member only needs to be
represented once in a taxonomy, and can be a single arc in a separate definition link role:
Role URI:
http://xbrl.sec.gov/dei/role/document/Defaults
Description: 995411 - Document - Document and Entity
Information, Defaults
Concept Type Arc o t Target
us-gaap:StatementClassOfStockAxis Axis
us-gaap:ClassOfStockDomain Domain Member dimension-default 1

Most SEC taxonomies have separate roles for each domain, and one role containing all dimension-default
relationships, but this is not mandated for custom taxonomies.
In general, a custom taxonomy may contain any definition relationship having any arc role permitted by
the XBRL base specification, dimensional specification, and certain specified arc roles in the Link Role
Registry (LRR; see section 2 above). EDGAR places additional constraints on definition relationships and
the way that they are permitted to be grouped within a single link:
• All definition relationships having the same source (or parent) must have distinct values of the
order attribute.

86
 • Only a concept (custom or standard) of type domainItemType may be the target of the
dimensional relationship from an axis to a domain.
• A concept of type domainItemType may not be the source of relationships to concepts that are
not domainItemType concepts.
• Any concept may appear in any number of tables, but each table needs to be in a different
definition link role. This facilitates the detection of logical inconsistencies both in the taxonomy
and the instance.
• Tables may be defined using relationships that cross from one link to another, but such
relationships cannot “dangle”. For example, the relationship from a table to an axis can only
continue into a link if that link that has a domain for that axis.
• Dimensional relationships cannot have paths from a concept back to itself.
In practice, most if not all relationships in definition links are used to arrange table, axis, and domain
member concepts into multidimensional structures, and so in EDGAR the terms definition links and
dimensional links are frequently synonymous.
5.4.3 Presenta�on and label rela�onships
Custom taxonomies may also need custom presentation, label, and calculation relationships even when
limited to standard concepts and their labels. Continuing the WXY 8K.A instance example, a custom
taxonomy could include the presentation and label relationships in Figure 8 below. Note that the order and
nesting of the definition and presentation links may have minor differences.
Figure 8. Presentation example
Role URI: http://xbrl.sec.gov/dei/role/document/Cover
Description: 995100 - Document - Cover
Concept p t o Label
dei:EntitiesTable Entities [Table]
us-gaap:StatementClassOfStockAxis 1 Statement Class of Stock [Axis]
us-gaap:ClassOfStockDomain 1 Class of Stock [Domain]
us-gaap:CommonClassAMember 1 Common Class A [Member]
us-gaap:CommonClassBMember 2 Common Class B [Member]
dei:EntityInformationLineItems ! 2 Entity Information [Line Items]
dei:CommonStockSharesOutstanding ! 1 Common Stock Shares Outstanding

Presentation linkbases have no equivalent of the definition link targetRole feature, so that all concepts,
axes, and members that the filer wishes to appear rendered together must be in the same link role. Section
6 below, “Instance Rendering”, provides more detail on how to take advantage of this to arrange custom
presentation links and labels to have some control over the layout, formatting, and facts displayed.
5.5 Valida�on of custom rela�onships
EDGAR checks the custom taxonomy to ensure that its structure is valid with respect to XBRL
specifications – for example, that the relationship between a source concept and its target label is directed
correctly from a concept to a label, or that certain relationships do not define loops.
EDGAR performs additional validations of custom taxonomies; violations are reported as either Errors or
Warnings.
5.5.1 Valida�ons resul�ng in Errors
Among the EDGAR validations that may yield XBRL Errors:

87
• The custom namespace must exist, match a specific pattern, and not conflict with a standard
namespace;
• Each custom namespace must have a distinct prefix;
• All concepts have id attributes that are consistent with the namespace prefix;
• All concepts may have null values
• Concept types (axis, domain member) must be correct for the relationships among them;
• A concept may have at most one label for each role (standard, terse, etc.) and language combination;
• Label texts are limited in length and contain no extra whitespace;
• Restrictions on label roles for certain concepts (for example, there must be no custom documentation
labels for concepts in standard taxonomies);
• Relationships must not be redundant;
• Relationships within custom taxonomies do not override relationships in a standard taxonomy;
• Definition and presentation relationships do not have an ambiguous ordering in a list of concepts;
• No unexpected definition or presentation links on certain standard taxonomy concepts. For example,
members of the Country Axis as used in an RXP instance type must be members from the standard
country taxonomy.
• No XBRL reference linkbases. EDGAR has built-in reference linkbases for all standard taxonomies
that cannot be altered or augmented.
• No custom declarations of resource roles or arc roles.
• Standard taxonomy schemas and entry points may only be referenced at their official location;
5.5.2 Valida�ons resul�ng in Warnings
EDGAR validations on taxonomies may also yield XBRL warnings. Some of these concern data quality
and interoperability, others help filers avoid problems with custom rendering, such as:
• Presentation groups that have more than one root concept, resulting in unexpected layouts;
• An axis appears in a presentation link role, but it has no domain concept among its children, so that
nothing will be rendered in that presentation role.
• Numeric concepts with period type “duration” have labels for the “start” and “end” instants.
• Custom presentation and definition link roles have constraints on their contents.
5.6 Custom Concept Declara�ons in General
A custom taxonomy is not normally limited to links among standard members of standard axes. For many
instance types, filers are free to define custom concepts. EDGAR imposes limits on those custom
concepts. In addition, the following general principles reduce unnecessary variability both across filers
and for a single filer over time.
5.6.1 Do not duplicate pre-exis�ng concept declara�ons
(Formerly EFM v68 § 6.8.4) In preference to declaring a new concept in a custom taxonomy, filers should
normally assign an appropriate label for a concept already defined in a standard taxonomy. If the
disclosure intended by the filer is effectively a synonym for a disclosure represented by a standard

88
taxonomy’s authoritative references and documentation label, filers should assign a label to the standard
concept, in preference to defining a custom concept.
Defining a filer-specific concept should be done only under specific circumstances relevant to each type
of concept as discussed in separate sections below.
5.6.2 Avoid changes in declara�ons from period to period
(Formerly EFM v68 § 6.8.1) A custom taxonomy that changes any concept declaration from an earlier
version of itself in such a way as to be incompatible with earlier instances should use the date portion of
its target namespace to identify the new version. For example, the next 10-Q for company WXY after its
2025 10-K would define a schema with updated namespace http://wxy/20260331, without changing the
prefix wxy and preserving consistent concept names as much as possible. From submission to
submission, custom taxonomies do change, for example, to accommodate changes in concept labels. But
custom concepts should be re-used as much as possible and changes in declarations should be avoided.
5.6.3 Custom concept naming
(Formerly EFM v68 § 6.8.6) Use company- and period-specific names only for domain members. Do not
include company-specific or period-specific information in any custom concept other than a domain
member. Concepts with other item types, including (but not limited to) monetary, percent, integer, shares,
per share, string, or text block item types, should not include company-specific or period-specific
information in the concept name. Represent period-specific facts by the built in XBRL period dimension,
not through the concept name.
Domain members may, by contrast, include company-specific or period-specific information in the
concept name. For example, a custom taxonomy should not declare a custom monetary concept with the
name CostOfAcquisitionOfLargeCo or FourthQuarterAdjustment. A company-specific custom
domain member such as LargeCoMember to be used in a fact for the CostOfAcquisition standard
concept is preferable.
5.6.4 Custom concept declara�ons
Every custom concept must have a period type of either instant or duration. Numeric concepts must
be declared with period type instant if and only if it represents a value that is only meaningful as of a
point in time, typically a beginning or end of period balance. All other concepts are duration period
types.
An easy check for whether a reporting concept has period type instant is to consider whether its
reported value would be the same regardless of whether it was meant to represent the end of a year, or just
the end of the fourth quarter. If those values could be different, then it is a duration period type.
(Formerly EFM v68 § 6.8.12) Do not define separate concepts to represent the instants at the beginning
and the end of a period. The same instant represents the end of one period, and the beginning of the
next.
(Formerly EFM v68 § 6.8.13) A numeric concept that represents an adjustment of an instant concept, by
convention, have a period type duration. Facts of that concept will be in a period prior to the end-of-
period balance that it applies to.
5.7 Custom Domain Member Declara�ons
A custom taxonomy may define a custom member concept and use it in linkbases and contexts. EDGAR
validation of a custom taxonomy checks for XBRL errors in the declaration of such members:

89
• A custom concept must not have the same name as a concept in an imported taxonomy. For example,
WXY company must not define a concept wxy:DocumentType because that conflicts with the dei
concept.
• A custom member must be declared with a name that ends in the word Member or Domain (EFM v68 §
6.7.27), with type domainItemType as it is defined in the XII DTR, and with the period type
duration (EFM v68 § 6.7.28). The type has empty content and elements are usually abstract; they
cannot be used as facts (EFM v68 § 6.5.25).
Valid custom members may be linked in custom relationships in much the same way as the standard
members illustrated in section 5.1 above.
For example, suppose company WXY has a share class it calls “Uncommon” that is distinct from any of
the standard share class concepts in the us-gaap taxonomy. Its custom taxonomy must have relationships
to wxy:UncommonClassMember instead of (or in addition to) relationships for the standard members such
as us-gaap:CommonClassAMember and us-gaap:CommonClassBMember. This is illustrated in Figure 9.
Figure 9. Definition relationships with a custom member
Role URI: http://xbrl.sec.gov/dei/role/document/Entity-
InformationEntityListingsTable
Description: 995405 - Document - Entity Information,
Entity Listings [Table]
Concept Type Arc o t Target
dei:EntityInformationLineItems Abstract
dei:EntitiesTable Hypercube all (closed) 1 !
us-gaap:StatementClassOfStockAxis Axis hypercube-dimension 1
us-gaap:ClassOfStockDomain Member dimension-domain 1
wxy:UncommonClassMember Member domain-member 1
dei:CommonStockSharesOutstanding Shares domain-member 2 !

(Formerly EFM v68 § 6.8.18) Declare a custom member for a domain only if the taxonomy defining the
domain does not have members specific enough to distinguish between facts needing distinct values.
Most standard taxonomies declare a default domain member for every explicit axis, and often several
more non-default members. Define necessary domain members using mnemonic name attribute values.
Figure 10. Examples of custom domain members
Standard Default Custom Domain
Standard Axis domain member Intended Meaning Members
Separately reporting
dei:LegalEntityAxis dei:EntityDomain DefCoMember, GhiCoMember
subsidiaries
EDGAR Series S000000111Member,
dei:LegalEntityAxis dei:EntityDomain
Identifiers S000000222Member
srt:Consolidated- srt:Consolidated- Consolidated SubCo1Member,
EntitiesAxis EntitiesDomain subsidiaries SubCo2Member
srt:SegmentGeographical- UsEastMember,
srt:SegmentGeographicalAxis Regions
Domain CaribbeanMember
us-gaap:StatementClass- us-gaap:Class- EDGAR Class/Contract
C000001111, C0000011111
OfStockAxis OfStockDomain Identifiers

(Formerly EFM v68 § 6.8.19) Do not declare “Total” domain members. The domain default member of
an explicit axis serves that purpose, as illustrated in Figure 2 and Figure 3. In the WXY example, if there
were a fact that represented (say) the total market capitalization of common classes A and B combined for
the reporting period, that fact would be in the Required Context, with no Class of Stock member at all.

90
5.8 Custom Presenta�on and Label Rela�onships
A custom taxonomy influences the rendering of facts in an instance by defining custom roles, defining
presentation relationships within those roles, and assigning labels to concepts. Section 6 below details the
general operation of the EDGAR Renderer and some of its instance type- and taxonomy-specific special
cases.
5.8.1 Instance type 8K.A example – custom members
Likewise, the WXY 8K example assumes the use of the dei-sub entry point that provides presentation
and label relationships. Therefore, in addition to the custom definition links shown earlier, its custom
taxonomy needs a parent-child relationship from the class of stock domain to
wxy:UncommonClassMember, and a label for the custom member.

Figure 11. Custom presentation and label relationships with a custom member
Role URI:
http://xbrl.sec.gov/dei/role/document/Cover
Description: 995100 - Document - Cover
Concept p t o Label
dei:EntitiesTable Entities [Table]
us-gaap:StatementClassOfStockAxis 1 Statement Class of Stock [Axis]
us-gaap:ClassOfStockDomain 1 Class of Stock [Domain]
wxy:UncommonClassMember 1 Uncommon Class [Member]
dei:EntityInformationLineItems ! 2 Entity Information [Line Items]
Common Stock Shares
dei:CommonStockSharesOutstanding ! 1 Outstanding

If the base dei entry point had been used instead of dei-sub, then the WXY 8K custom taxonomy would
need to provide all the presentation and label links for all its expected facts.
Either a standard taxonomy entry point or the custom taxonomy must ensure that the presentation is
complete. This is part of EDGAR validation and XBRL errors will occur for each concept appearing in a
fact, as an axis, or as a member in an instance to ensure that:
• Is the source or target of at least one presentation relationship; and
• It has a standard label; or
• Is the target of a relationship that has a preferred label role, but the concept has no such label.
Validation will also ensure that for the link:roleType declaration:
• The custom role URI has the same first two parts as the custom namespace (http://uvw/ in this
case) followed by /role/ and additional text;
• The description text matches the format expected by the renderer to sort outputs (see section 5).
• All, and only, usedOn elements for presentation, definition, and calculation relationships are present.
5.9 Custom Calcula�on Rela�onships for Standard Concepts
Calculation relationships indicate that concepts are logically and arithmetically related, i.e., that a concept
is meant as the arithmetic sum of other concepts, and whether that summation involves additions or
subtractions. Although they do not appear in either the 6K.A nor 8K.A instance type examples shown
earlier, custom calculation relationships among standard concepts do appear in other instance types. Of
particular importance are financial statements represent in instance types of submission sets AF, HF, and
QF. The content of financial statements is governed by both SEC regulations as well as reporting
91
standards, primarily US Generally Accepted Accounting Principles (GAAP) or International Financial
Reporting Standards (IFRS). Within the limits of those standards, filers exercise judgment in choosing
the line items appearing in their financial statements. The meaning of each numeric line item is
represented in XBRL concepts via its:
• XBRL numeric data type (for example, monetary or share);
• If monetary, whether it represents an accounting credit, debit, or neither, with respect to balance
sheet and/or income statement conventions;
• Period type (measured at an instant or measured over a duration with a start and end date);
• Authoritative references (for example, a concept that is defined in an SEC regulation);
• If present, a label with role documentation as provided by the taxonomy authors.
These meta data properties are usually sufficient for a concept considered in isolation. Consider the
concept us-gaap:LimitedPartnersOfferingCosts. It has monetary data type, debit balance, and
instant period. It has a standard label text “Limited Partners’ Offering Costs,” reference link pointing to
a specific subparagraph of FASB Accounting Standards Codification 505.10.5 complete with a URL of
the full text, and its documentation label has the text “The cumulative amount of offering costs allocated
to the limited partners.”
Calculation relationships are an important complement to that concept-specific meta data. Figure 12
shows a fragment of the us-gaap taxonomy with four calculation relationships. Partners’ capital is the
sum of two items, and the limited partners’ account is the net of their contributed capital minus their
offering costs. The columns of the figure have the same meaning as in previous figures; “w” indicates the
numeric weight relating the parent concept to the child.
Figure 12. Standard calculation relationships example
Role URI:
http://fasb.org/us-gaap/role/statement/
StatementOfFinancialPositionClassified
Description: 104050 – Statement – Statement of
Financial Position, Classified
Concept w t o Label
us-gaap:PartnersCapital Partners’ Capital
us-gaap:GeneralPartnersCapitalAccount +1 ! 1 General Partners' Capital Account
us-gaap:LimitedPartnersCapitalAccount +1 ! 2 Limited Partners' Capital Account
us-gaap:LimitedPartnersContributedCapital +1 ! 1 Limited Partners' Contributed Capital
us-gaap:LimitedPartnersOfferingCosts −1 ! 2 Limited Partners’ Offering Costs

For the most part, standard calculation relationships are not in the entry points listed in EFM v68 § 6.5.
Instead, custom taxonomies for financial statement instance types should contain custom XBRL
calculation relationships to define how their use of each concept relates to the others.
For example, suppose a FA.US instance balance sheet shows facts for only four of the five concepts in
Figure 12, leaving out the intermediate value us-gaap:LimitedPartnersCapitalAccount. Figure 13
shows the calculation relationships that would appear in its custom taxonomy instead; one of them is a
copy of the standard taxonomy relationship, and the other two are new.

92
Figure 13. Custom calculation relationships with standard concepts.
Concept w t o Label
us-gaap:PartnersCapital Partners’ Capital
us-gaap:GeneralPartnersCapitalAccount +1 1 General Partners' Capital Account
us-gaap:LimitedPartnersContributedCapital +1 2 Limited Partners' Contributed Capital
us-gaap:LimitedPartnersOfferingCosts −1 3 Limited Partners’ Offering Costs

The concept us-gaap:PartnersCapital is now the sum of two items minus the third.
5.9.1 When calcula�on rela�onships are required
(Formerly EFM v68 § 6.15.2) If a financial statement shows two or more items along with their net or
total, during or at the end of the Required Context period, and the instance contains corresponding
numeric facts, then the custom taxonomy must have a calculation relationship from the total concept to
each of the contributing items. Examples:
• A balance sheet shows assets as the sum of current and non-current assets, as of the date falling at
the end of the period of the Required Context. Two relationships are required.
• An income statement shows only earnings per share and diluted earnings per share, but no
reconciling per-share amount. Calculation relationships are not required.
• An income statement shows earnings per share before and after an adjustment for change in
accounting principles, along with the adjusting amount. Two calculation relationships are
required, from the net earnings per share, to its two contributing amounts.
• A company’s cash flow from investments for the most recent quarter is shown as the sum of two
lines: Payments for plant and equipment, plus Payments for marketable securities. Two
calculation relationships are required.
• An income statement shows the line items “Revenues”, “Cost of Goods Sold” and “Gross
margin” as the net of the two values during the current quarter. Two calculation relationships are
required. In this case, the relationship subtracting Cost of Goods Sold will have a weight attribute
of -1.
• A balance sheet shows Net Receivables with a parenthetical value for Allowances. Only two
values are shown, so no calculation relationship is required.
• A footnote for ABC contains a table in which the Revenue of its separately reporting subsidiaries
DEF, GHI and JKL are totaled. But each of the four facts is in a different context, having a
different member on dei:LegalEntityAxis. This does not require any calculation relationships.
5.9.2 Avoid calcula�on rela�onship redundancy
(Formerly EFM v68 § 6.5.14) Ensure that each pair of source concept (summation) and target concept
(item) appears in at most one calculation relationship. Note that this refers to the calculation relationship,
not the concepts; any concept might occur in any number of financial statements or footnotes. Legitimate
exceptions to this rule occur when a concept is shown in different parts of the financial statement as a sum
of different, but overlapping, sets of other concepts. Examples:
• An income statement contains amounts pre-tax income, tax, and post-tax income. There are two lines
and their net; therefore, the balance sheet requires two calculation relationships. In the tax footnote
there is another occurrence of pre-tax income, tax, and post-tax income. The tax footnote does not
need two calculation relationships, because the same relationship already exists on the income
statement.

93
• A balance sheet shows Net Current Receivables with a parenthetical value for Allowances. Only two
values are shown, so no calculation relationship is required. A footnote also includes an analysis of
(the same) Net Current Receivables including, among other details, amounts for Gross and
Allowances. The footnote has those two items and their net and therefore a need for two calculation
relationships. Whether any of these facts also appear elsewhere is relevant only if it would result in
duplicated relationships.
5.9.3 A single concept may have alternate calcula�ons
(Formerly EFM v68 § 6.15.3) If different parts of a financial statement contain alternate line items that
sum to the same total amount, there must be calculation relationships for the original and the alternate line
items in distinct roles. For example:
• A tax liability is shown in a tax disclosure as the sum of current and deferred tax liabilities, and
elsewhere in the same instance as the sum of domestic and foreign tax liabilities. These are two
separate calculations, appearing in two separate calculation links, each link containing two calculation
relationships.
5.10 Custom Numeric Concepts
For many instance types, the custom taxonomy that accompanies it may declare concepts and use those
concepts in taxonomy relationships and in instance facts. A common use for such concepts is to define the
“line items” of financial statements – income statements, balance sheets, cash flows, etc. In a typical
financial statement, line items that will appear that are broader or narrower than the available standard
concepts and assigning a different text label is inappropriate. As in the guidance for defining custom
domain members, following the principles below reduce unnecessary variability both across filers and for
a single filer over time.
5.10.1 Do not duplicate numeric concepts
For example, a standard taxonomy may have the concept GrossProfit and one of its entry points assigns
the label as “Gross Profit”. The standard taxonomy does not have a concept GrossMargin because it is
defined the same as gross profit: both are used to mean “excess of revenues over the cost of revenues.” A
filer disclosing their “gross margin” in a submission should not define a custom GrossMargin concept,
but rather, use the GrossProfit concept and link it to a custom label “Gross margin”.
(Formerly EFM v68 § 6.8.10) Do not declare different elements for different values of the same
underlying line item. A line item such as “Net Income” is the same as the line item for “Net Loss”, since
the concept may appear in facts with different values, positive, negative, or zero in different periods.
Even a line item that appears to be shown with different values in the same period is still only a single
concept. For example, a cash flow statement may have a line item “Reclassification of proceeds from
Operations to Investments”; it appears in “Cash flow from Operations” as (10) and under “Cash flow
from Investments” as 10, but it is the same concept and the same fact for the same period.
(Formerly EFM v68 § 6.11.1) In an Inline XBRL document, if the concept appears as a fact in a table or
list, the custom label should be as close as possible to the text in the original document that serves as a
heading or legend for that fact (formerly [6.11.1]).
5.10.2 Monetary concepts
(Formerly EFM v68 § 6.8.9) Declare a concept having the XBRL data type monetaryItemType if the
standard taxonomy contains only monetary type concepts that, in the judgment of the filer, may be similar
but are too broadly defined for a given line item.

94
For example, a financial statement may have a line item that encompasses a significant portion, but not
all, of a nearby line item, such as this example:
Accounts payable $ 7,324
Securities lending payable 1,274
Other liabilities, current 2,362
Liabilities, current $ 11,410
Assume the standard taxonomy has concepts AccountsPayable, OtherLiabilitiesCurrent and
LiabilitiesCurrent. All three have the same XBRL attribute values: data type monetaryItemType,
period (instant) and balance (credit). Assume the standard taxonomy does not have any concept
whose meaning is narrow enough to encompass only “Securities Lending Payable”.
Meeting the accounting disclosure requirements justifies defining a custom concept named
SecuritiesLendingPayable with the same properties as the more general Accounts Payable concept,
i.e., data type (monetary), period type (instant), and balance (credit).
The requirement for calculation relationships applies in this example. Calculation relationships provide
important information to the consumer of the data with custom concepts. In this financial statement,
LiabilitiesCurrent is the sum of AccountsPayable, custom SecuritiesLendingPayable, and
OtherLiabilities. Finally, because the custom item appears in the financial statement, EDGAR
validations that either has a credit or debit balance or has a custom documentation label.
Custom monetary concepts may also be needed when a line item combines different concepts defined in
the standard taxonomy, for example:
Prepaid pension and postretirement benefits $ 8,731
Other assets, noncurrent 872
Assets, noncurrent $ 9,603
Assume the standard taxonomy has two concepts PrepaidPostretirementBenefits and
PrepaidPensionCosts, but the filer judges both to be too narrow. Meeting the accounting disclosure
requirements justifies defining a custom concept named PrepaidPensionAndPostretirementBenefits.
Here, calculation relationships would be required to indicate that AssetsNoncurrent is the sum of
PrepaidPensionAndPostretirementBenefits and OtherAssetsNoncurrent.

Whether an additional pair of relationships to indicate that the custom concept

PrepaidPensionAndPostretirementBenefits is the sum of PrepaidPostretirementBenefits and
PrepaidPensionCosts depends on whether those concepts appear elsewhere separately in the statement.
If they are not used in any facts, then they need not participate in calculation relationships.
5.10.3 Share (unit of ownership) type concepts
The built-in XBRL data type shareItemType represents units of ownership. Facts of this type must have
a unit dimension equal to the built-in value share. Despite its name, this type is not intended to be
limited to literal “shares” of stock.
Custom concepts of this type solely to make distinctions between different units of ownership are not
necessary. Better to make this distinction by using members on a standard axis such as
us-gaap:StatementClassOfStockAxis in section 5.7 above.

5.10.4 Per-share type concepts

The distinction between a monetary amount and a monetary amount per unit of ownership (e.g., per
share) is sufficiently important that standard taxonomy concepts such as “Earnings per Share” almost
always have type perShareItemType, not monetaryItemType.
95
Custom concepts representing monetary measures per unit of ownership should do the same.
5.10.5 Pure number type concepts
The built in XBRL type pureItemType represents numbers that are defined as a ratio between measures
of the same kind: for example, miles per kilometer (distance over distance). In mathematics this is called
a “pure number” and a fact of such a concept must have the XBRL unit dimension pure.
(Formerly 6.8.15) A custom concept representing a ratio of values for which its facts would have a
currency in the numerator and a different currency in the denominator must be declared as a
pureItemType. For example, “Exchange Rate” is a “pure number”, being a ratio of two monetary values
having different currencies.
5.10.6 Percent type concepts
(Formerly 6.8.14) A percentage is a special case of a pure number in which the ratio is between identical
measures. An interest rate, for example, is a ratio of two values of the same currency; it would be
declared as a percentItemType. XBRL fact values of a percentItemType concept are not scaled by 100.
A concept such as “Change in Revenues” is conventionally rendered scaled by 100 and followed by the
“%” symbol. A fact of this concept must have a unit dimension that is equal to the XBRL built in value
pure, and a value such as “.20” to represent “20%”.

Only if both the numerator and denominator would have a period type instant may the custom concept
also have period type instant; otherwise, the period type is duration.
Use a name that expresses the meaning of the ratio, using the word “Over”. For example, the concept
name “Change in Revenues Over Revenues of the Period One Year Earlier” is verbose, but it is explicit
and applicable to both quarterly and annual periods.
5.11 Custom Non-Numeric Concepts
Custom taxonomies may define custom non-numeric concepts. Guidelines for avoiding unnecessary
variability apply just as they do for numeric concepts, but non-numeric concepts cannot be related to
other concepts via calculation.
5.11.1 Custom Non-member Abstract concepts
(Formerly EFM v68 § 6.8.8) It is often desirable to arrange presentation or definition relationships into
hierarchies. Custom non-member abstract concepts fill this need. These are custom concepts whose
only purpose is to provide a root concept or an intermediate concept in a multi-level hierarchy.
There are few restrictions on declaring abstract non-member concepts, other than that the concept names
must end with Abstract or LineItems, and vice versa (EFM § 6.7.26) and that its periodType be
duration (EFM v68 § 6.7.32).

5.11.2 Custom text block type concepts

The text block is an important XBRL data type defined in the XII DTR (see 2 above) and used in nearly
every standard taxonomy. The content of a text block fact is a character string to be interpreted as
XHTML, and in EDGAR, the elements and attributes are restricted as detailed in EFM § 5.2.2.
A text block may represent anything from a sentence fragment to several pages of formatted narratives,
images, and narratives; in Inline XBRL documents, text blocks are frequently intended to enclose other
numeric and non-numeric facts – even other text blocks. The term originates from regulation S-T 405
that requires “block-text” tagging of Notes to Financial Statements.

96
Text block concepts in taxonomies other than us-gaap and ifrs for financial statements are often tied to
a specific Form instruction or disclosure requirement that is neither too broad, nor too narrow, in the same
way that standard numeric line items on a financial statement might be. For example, a disclosure
satisfying Exchange Act Rule 17AD-27(b)(1) is represented in its entirety by one standard text block
concept sro:CmspStpPlcyPrcdrSmryTextBlock having the label “CMSP STP Policies and Procedures
Summary [Text block]” regardless of how little or how much narrative, tables, or images the fact may
contain; there is no need to subdivide the text into different custom concepts, nor to create a custom
concept that merges the topic with some other standard text block. The same cannot always be said of
text blocks for financial statement notes, which are often related to multiple requirements, and may have
substantial overlap with other text blocks.
(Formerly EFM v68 § 6.8.23) Define a custom concept of type textBlockItemType with name ending
TextBlock when, in the judgment of the registrant, the standard concepts available are too narrowly
defined disclosure being tagged, or the formatted text is commingled, and it would be misleading to
include the same commingled formatted content in two or more standard text blocks. Define a custom
text block concept with name ending TableTextBlock when the formatted text is composed entirely of a
formatted table and its caption, if any.
(Formerly EFM v68 § 6.7.32) A custom concept of type textBlockItemType must have period type
duration.

5.11.3 Custom dimensional concepts

Four types of non-numeric concepts are specifically for use in dimensional relationships: domain
members, typed dimensions, explicit dimensions, and hypercubes.
Custom domain members are discussed in 5.7 above.
EDGAR does not permit custom typed dimensions in any custom taxonomy (EFM v68 § 6.5.39, EFM
v68 § 6.7.20).
In some instance types, custom domain members, explicit dimensions and hypercubes are of no use
because there are EDGAR validations preventing their participation in any dimensional relationships.
(Formerly 6.8.20) Declare a custom explicit dimension with a name ending in Axis only if the axes of no
existing standard table are sufficient to capture a complex disclosure and no standard axis (typed or
explicit) having the same meaning. For example, suppose there is a table for “Assets held for sale, by
Asset Type” with only a standard axis for Asset Type. To disaggregate an asset type (property, for
example) further according to its degree of distress, if there is no other standard dimension related to
distress, define a custom dimension such as DegreeOfDistressAxis.
(Formerly 6.7.23) Custom explicit dimension concepts must have names ending in Axis and vice versa.
(Formerly 6.8.21) Declare a custom hypercube concept with a name ending in Table and only if no
available standard taxonomy contains an appropriate combination of axes and concepts. Note that the
hypercube concept itself is only a structural placeholder for dimensional validation and it does not appear
in the instance at all.
(Formerly 6.7.24) Custom hypercube concepts must have names ending in Table and vice versa.
5.11.4 Other custom non-numeric types
Note that custom non-numeric types other than text blocks and domain members are rarely required in
any instance type. Although any built-in or derived date type may be used in a custom taxonomy, in
practice, dates and plain text strings are more than sufficient to comply with custom tagging requirements.

97
(Formerly 6.8.16) Declare a concept with the XBRL built in type dateItemType only if facts in an
instance are dates, but no concept in a standard taxonomy is appropriate. For example, a disclosure
contains a table of contracts with values and maturity dates. If there is no appropriate element in an
available standard taxonomy schema for the date, so declare a date concept such as
ContractMaturityDate.

(Formerly 6.8.17) Declare a concept with the XBRL built in type stringItemType only if facts in an
instance are plain text without XHTML markup, but no concept in a standard taxonomy is appropriate.
For example, a disclosure contains a table of contracts with the name of the project and its terms. If there
is no appropriate concept in an available standard taxonomy for the name, declare a string concept such as
ProjectNameText.

5.12 Other custom taxonomy components

Custom taxonomies must not contain:
• Custom arcroleType declarations
• Custom roles for label, footnote, or reference linkbase resource elements
• Custom fractionItemType concepts
• Custom tuple concepts.

6 Instance Rendering
Instances in all XBRL file formats (xBRL-XML or Inline) consists of a set of facts supported by meta
data: concept declarations, labels, calculation, definition, reference, and presentation relationships.
The EDGAR renderer transforms XBRL facts and meta data into human readable output in the form of
individual HTML files called “reports” or “R-files” and other supporting output such as a Filing
Summary. Each R-file has a table layout with rows, row headings, columns, column headings and
footnotes.
XBRL parent-child relationships in the presentation groups of a filing are generally the most important
determinant of the overall layout of each R-file. Facts in contexts, footnotes in the instance, roles and
data types declared in schemas, text in label linkbases, and the axis default members defined in definition
linkbases, all further contribute to producing the output.
6.1 Mo�va�on for Standardized Rendering
Human readers have expectations about the display of a data set such as an instance. Facts that represent
the value of the same concept at different times might be arranged into a row, with columns representing
dates or periods. Or, the facts might be arranged in a column, with each row representing the date. A
table might include all such facts, or there may be a list of tables, each with a specified subset. Some
facts, such as blocks of narrative text, are best shown in a sequence or list. Facts might be combined with
other comparable data collected in some other way or at a different time or shown with additional meta
data.
Even though an Inline XBRL document likely represents the preparer’s effort to present information
clearly and compactly for human consumption, it is reasonable to for a user to expect an arrangement of
similar data from different documents from different filers to be presentable in a somewhat uniform
layout. Uniformity benefits not only the end user of the information viewing the data, but also for the
preparer, who will want to ensure that fact values, concepts and other meta data is consistent with the
intent of the plain, untagged document.

98
6.2 Presenta�on groups
(Formerly EFM v68 § 6.24.1) The relationships in a presentation group form a directed graph with one
root concept having child concepts in a fixed order, child concepts of those concepts each in a fixed order,
and so on.
Each presentation group has a single role, and therefore a single role URI and role definition text.
The overall order of presentation groups in the set of reports for a single instance is determined by
lexicographic sorting of the definition texts, which is facilitated by conforming to a pattern that starts with
a numeric sort code.
For example, the first presentation group in EDGAR’s Document and Entity Information (DEI) taxonomy
entry point dei-pre has the definition text 995100 - Document - Cover suggesting that it contains
concepts typically appearing on the cover page of an SEC filing. Presentation groups that the filer wishes
to appear after the facts on the cover page could start its role definition text with any number that will sort
after 995100, such as 995101 or any number with seven or more digits starting with 995100.
The simplest report layout is one in which the presentation group contains no Axis or Domain Member
elements. All the facts in the instance whose elements appear as sources or targets of relationships in the
presentation group in contexts having no dimensions are displayed in the R-file. The facts are arranged
into columns, one for each context. The presentation group, when traversed top down and in order,
determines the order that the elements appear in the rows.
6.3 Fact selec�on
(Formerly EFM v68 § 6.24.5) A first step in rendering is to determine for each presentation group
which facts it will show. The core dimensions of a fact that determine whether it will be rendered within
in a presentation group layout are its concept, its period, the entity, the language of non-numeric facts and
the unit of measure for numeric facts. An EDGAR instance concerns only one entity, and facts in
languages other than US English are not rendered. The taxonomy-defined dimensions of a fact also
influence whether it is selected for display. The renderer selects a fact for rendering in a presentation
group when:
Custom taxonomies can limit to some degree the facts shown on a particular report by including or not
including certain axes, with or without their default and other members.
For example, suppose a presentation group is meant to filter out facts having any member of axis X. The
presentation group has just one concept A, and one axis X along with only its default member B.
• Fact A1 with concept A and no axes.
o This will be selected. It satisfies condition 1, it satisfies condition 2 because there are no
such axes in the presentation group, and it satisfies condition 3 trivially.
• Fact A2 with member C of axis X.
o This will not be selected. It fails condition 2, because member C is not in the
presentation group.
• Fact A3 with one axis Y and one member D.
o This would be selected. It satisfies condition 1; there are no such axes for condition 2,
and it satisfies 3 (case b) because the group does not mention axis Y.
As noted in section 8.10 below, duplicate facts are consolidated into a single fact for rendering purposes.
Inline XBRL formatted documents often contain the same fact reported in multiple locations of the
document. The renderer selects just one of them for rendering. A common example is a company’s net
income, reported both on an Income Statement and in a Statement of Cash Flows. The value is tagged in
two different places, resulting in an instance with duplicate facts. Inconsistent numeric values, or non-
99
numeric values that are not identical, result in XBRL errors. So long as the numeric values are consistent,
there is no error or warning; the duplicated numeric fact having the most significant digits will be selected
for rendering.
The values of xsi:nil and decimals attributes have no effect on selection whether present or not.
Non-numeric facts with values of xml:lang other than us-EN are filtered.
If the presentation group has axes but lacks descendants that would allow any facts to be selected, then a
warning is raised (EFM v68 § 6.26.1).
6.3.1 Period Selec�on
(Formerly EFM v68 § 6.24.8) The set of periods appearing in a presented set of facts constitute the
layout “period axis”. The period axis cannot be filtered.
6.3.2 Unit Selec�on
(Formerly EFM v68 § 6.24.3) All units are selected for display in a presentation group by default and
constitute the layout “unit axis”. The unit axis may be filtered using concepts having the same name as
the unitRef attribute value.
6.3.3 The Primary Axis
(Formerly EFM v68 § 6.24.4) Members of the concept dimension that do not have same name as a
unitRef attribute value, are collectively called members of the layout “primary axis”.
6.4 Basic Layout using Core and Taxonomy-Defined Dimensions
(Formerly EFM v68 § 6.24.8) Rendering places each of the dimensions on rows or columns of a table,
and to determine how dimensions are to be nested when more than one dimension is on the rows or on the
columns. In general, the concept dimension appears on the rows, and the period dimension on the
columns.
12 mo. ended
Period Dimension → Dec 31, 2033 Dec 31, 2032
Concept Dimension ↓
Line Items:
Revenue:
Assets:
If the same concept (on a row) appears with more than one unit of measure (multiple currencies, for
example) then each column representing a period may split into separate columns for each unit. The unit
dimension is said to be nested inside the period dimension.
12 mo. ended
Period Dimension →
Dec 31, 2033 Dec 31, 2032
Unit Dimension → $ € $ €
Concept Dimension ↓
Line Items:
Revenue:
Assets:
If there are facts with members on an additional axis, then the concept dimension is nested inside. For
example, if there were a geographic region axis, with some facts having no member (i.e., the default), and
others having the members Bermuda and Bonaire:

100
 12 mo. ended
Period Dimension →
Dec 31, 2033 Dec 31, 2032
Unit Dimension → $ € $ €
Region Dimension ↓ Concept Dimension ↓
Line Items:
(default) Revenue:
Assets:
Concept Dimension ↓
Line Items:
Bermuda
Revenue:
Assets:
Concept Dimension ↓
Line Items:
Bonaire
Revenue:
Assets:
The custom taxonomy could have arranged for the region dimension to be nested inside the concept
dimension. The renderer does this by using the order in which the “Line Items” and the different axes
appear as children of the Table concept.
12 mo. ended
Period Dimension →
Dec 31, 2033 Dec 31, 2032
Unit Dimension → $ € $ €
Concept Dimension ↓ Region Dimension ↓
(default)
Line Items: Bermuda
Bonaire
Region Dimension ↓
(default)
Revenue
Bermuda
Bonaire
Region Dimension ↓
(default)
Assets
Bermuda
Bonaire
All the axes expected to appear in facts in a table must be ordered in the presentation group, because any
axes that appear in facts not given an explicit nesting will appear with all the other axes nested inside.
6.5 Ordering members along a dimension
(Formerly EFM v68 § 6.24.7) For the most part, the presentation group also determines the ordering of
items along an axis. Members of the concept dimension and any taxonomy-defined explicit dimensions
are arranged into a list reflecting their ordering in the presentation group.
Typed dimension members follow their ascending natural order, typically numeric or lexical.
The period axis is different; it always follows the convention common to financial statements, in which
the dates are descending (2033 before 2032) and durations ascending (quarters before years).

101
6.6 Merged columns
(Formerly EFM v68 § 6.24.8) If every column in the default layout represented a different combination
of period and unit, then the display would often have significant empty space. In the examples below, the
Revenue element is a duration-type element, and the Assets element is an instant-type element, so that the
figures would appear this way:
3 mo. ended 9 mo. ended
Period Dimension → Dec 31, 2033 Dec 31, 2033 Dec 31, 2033
Concept Dimension ↓
Line Items:
Revenue: xxx,xxx yyy,yyy
Assets: zzz,zzz
Instead, columns representing an instant period are shown merged with the columns representing
durations that end on that date; the same fact is shown more than once, but overall, the layout is more
compact:
3 mo. ended 9 mo. ended
Period Dimension → Dec 31, 2033 Dec 31, 2033
Concept Dimension ↓
Line Items:
Revenue: xxx,xxx yyy,yyy
Assets: zzz,zzz zzz,zzz
A set of facts with different units all on distinct elements may be merged into a single column as well.
When facts whose unit is a currency, facts with unit “shares”, and facts whose unit is that same currency
“per share” have compatible periods, they are merged into the same columns.
6.7 Period Start labels
(Formerly EFM v68 § 6.24.9) An instant-type element of the primary axis that has a period start
preferred label results in a special kind of layout and column merge called a movement analysis. In a
movement analysis, duration-type facts are matched to instant-type facts whose date-times are the same as
its start and end dates. The same fact may thus appear as the ending value of one column, and the starting
value of another. In the example below, the fact shown as yyy,yyy at Dec 31, 2032, is at the end of one
period and the start of the next:
USD 12 mo. ended 12 mo. ended
Dec 31, 2033 Dec 31, 2032
Line Items:
Balance, start of period: yyy,yyy xxx,xxx
Changes: --- ---
Balance, end of period: zzz,zzz yyy,yyy
In general, the starting and ending balance facts should be matched with at least one fact representing the
duration between them; otherwise, a warning may be issued. Note that the order of elements along the
primary axis is preserved and does not affect whether the layout is considered a movement analysis; the
following example is equally valid, resembling a statement of cash flows:

102
 USD 12 mo. ended 12 mo. ended
Dec 31, 2033 Dec 31, 2032
Line Items:
Changes: --- ---
Balance, start of period: yyy,yyy xxx,xxx
Balance, end of period: zzz,zzz yyy,yyy
6.8 Column Headings and Promo�on
(Formerly EFM v68 § 6.24.10) If all column headings share the same units or period, then those
axes are “promoted” into the upper left corner of the layout to avoid redundancy.
Columns representing an instant in time are shown as (for example) "Oct. 19, 2008" or "May 07,
2009". Columns representing durations are shown as (for example) "6 months ended Oct 19,
2008" rounded to the nearest number of months. For example, the duration from Jul. 1 to Sep. 19
rounds to 3 months, but the period from Jul. 10 to Sep. 19 rounds to 2 months. Periods of more
than one year are nevertheless shown in months, for example, two years starting Jan. 1, 2008,
would be shown as "24 months ended Dec. 31, 2009".
6.9 Row Headings and Promo�on
(Formerly EFM v68 § 6.24.11) The text shown in each row heading on the primary axis is the
text of preferred label on that element position on the primary axis (see 6.11.4).
The text shown for non-primary axis members is a concatenation of the outermost member
name’s preferred label (defaulting to the standard label), followed by a vertical bar “|”, followed
by the next outermost member label, and so on.
If the default member of an axis is the first number shown in order on that axis, its label is
considered blank.
Any member that is not the only member shown for a given axis in that report is promoted into
the upper left corner of the layout.
6.10 Footnotes and Merging
(Formerly EFM v68 § 6.24.12) Footnotes of a report are displayed at the bottom of a report,
sequentially numbered, and the footnote marks are numbers that appear as a superscript to the
right of each fact to which they refer.
Every report's footnote numbering is local to that report, so that if a fact with a footnote is
displayed in two different reports, it will be displayed with the same footnote text at the bottom
of the report, but a different superscript number.
If all the facts on a row have the same footnote mark, then that footnote mark is removed from
the facts and “merged” to a position just to the right of the row labels and removed from the
cells.
If all the facts on a column have the same footnote mark, then that footnote mark is “merged”
into the heading of the column and removed from the cells.

103
6.11 Flow Through Suppression on Statements
(Formerly EFM v68 § 6.24.13) “Flow through” occurs when a fact is selected for display in more
than one presentation group. One of the most common examples is that “Net Income” appears on
both an income statement and a statement of cash flows.
Only presentation groups for which the “Type” token as described in 9.2 below has the value
“Statement” are subject to “flow through” suppression.
When a statement contains a column of facts that are all rendered in a column of some other
presentation group, the column that is a subset of the other is removed (suppressed).
If columns in two statements have identical facts, then the column in the statement that appears
first according to SortCode (section 9.2 below) is retained.
6.12 Cash Flow Statements
(Formerly EFM v68 § 6.24.14) Presentation base sets for which the “Type” token as described in
section 9.2 has the value “Statement” and the “Title” text contains the word “cash” followed by
“flow”, then the only columns shown are those with the longest duration and those which have at
least one-fourth the number of rows containing values as the columns with longest duration.
This is a special case of flow through suppression; without it, a typical cash flow statement for a
3rd quarter financial statement might display unwanted columns.
6.13 Statements of Changes in Shareholder Equity
(Formerly EFM v68 § 6.24.15) Presentation base sets for which the “Type” token has the value
“Statement”, that present facts with period start and period end labels, and the “Title” text does
not contain “parenthetical” but does contain the case insensitive pattern:
a. “stockholder”, “shareholder”, or “changes” in addition to either “equity” or
“deficit”, or
b. “partners” or “accounts” in addition to “capital”, or
c. “statement” and “equity”
are considered “Statement of Changes in Equity” statements. These have a special movement
analysis layout. These axes (if present) are shown on the rows, in this nesting order:
a. Period
b. Scenario (StatementScenarioAxis)
c. Primary
d. Creation Date (CreationDateAxis)
e. New Accounting Pronouncements
(AdjustmentsForNewAccountingPronouncementsAxis)

f. Adjustments for Change in Accounting Principle

(AdjustmentsForChangeInAccountingPrincipleAxis)

104
 g. Error corrections and Prior Period Adjustment
(ErrorCorrectionsAndPriorPeriodAdjustments-
RestatementByRestatementPeriodAndAmountAxis)
These axes (if present) are shown on the columns, in this nesting order:
a. Legal Entity (LegalEntityAxis)

b. Equity Components (StatementEquityComponentsAxis)

c. Partner Capital Components (PartnerCapitalComponentsAxis)
d. Class of Stock (StatementClassOfStockAxis)
e. (All other axes present)
f. Unit
Also, if the Scenario Axis is present then its member ordering is fixed in this order:
a. Previously Reported (ScenarioPreviouslyReportedMember)
b. Restatement Adjustment (RestatementAdjustmentMember)
c. Change In Accounting Principle (ChangeInAccountingPrincipleMember)
d. Unspecified (the default)
If the set of facts presented does not contain instant-type facts and duration-type facts in the
expected alternating arrangement, a warning may be raised.
6.14 Layout Qualifiers
(Formerly EFM v68 § 6.24.16) In addition to general layout and formatting rules there are
additional ways of altering a layout by modifying the role definition text. When the tokens
“Unlabeled”, “Elements”, or “Transposed” (case sensitive) appear in the definition text between
curly braces “{…}”, then one of three transformations apply:
1. When the definition text contains the token “{Unlabeled}”, then the elements’ labels do
not appear in the leftmost column.
2. When the definition text contains the token “{Elements}”, then the display has an
additional column to the right of the labels, showing the element id. The {Elements}
display can be useful for reviewing all the detailed content of an Interactive Data
instance. {Elements} cannot be used with the period axis on the rows.
3. When the text contains the token “{Transposed}”, then the entire display, after any other
layout has been applied, is transposed (rows on the columns and vice versa).
If more than one layout qualifier is present in a definition text, all are ignored.

105
6.15 Uncategorized Facts
(Formerly EFM v68 § 6.24.17) Facts (and their duplicates) that are not selected for display by at
least one presentation base set are shown in an “Uncategorized Facts” report. The report number
for the Uncategorized facts is 9999 and it is shown as if it had the “Elements” layout qualifier.
6.16 Numeric Forma�ng
(Formerly EFM v68 § 6.24.18) Numeric facts are scaled for presentation to reduce the
appearance of redundant sequences of “000” groups. Each set of distinct units of facts selected
for a report is scaled independently to preserve their significant digits. Note that this is performed
only with respect to the fact values; the value of the decimals attribute of a fact does not directly
affect this determination. For example, if there are three facts with unit USD:
• Revenues 1,000,000 USD, decimals=-6,
• Assets 100,000 USD, decimals=-3,
• Income 1,000 USD, decimals=0,
then all three facts would be shown scaled by thousands. Other facts in the same report with units
such as “Ratio”, “Shares”, or “USD per Share” would not be affected by the scaling of USD.
Cells in the layout have unit symbols assigned as follows:
1. Each numeric cell has a unit (USD, GBP, Shares, etc.). A nonzero number will be
displayed with a prefix consisting of the unit.
2. If all the cells in a column have the same unit, then the symbol is copied to the column
heading and removed from the cells.
3. For the non-zero cells in each column, remove a symbol from the cell if it has the same
unit as the immediately prior nonzero cell, unless it is in the last row.
4. For the non-zero cells, in each row, remove a symbol from a cell if it has the same unit as
the immediately prior nonzero cell, unless it is in the last column.
5. If there is a unique symbol for the unit ($, £, ¥, €, etc.) use that symbol as a prefix instead
of the unit’s name as a suffix.
6.17 Non-numeric Forma�ng
(Formerly EFM v68 § 6.24.19) Fact values may be non-numeric; the following rules apply when
displaying non-numeric values of an element:
1. A date item type is displayed with format “mmm d, yyyy”;
2. A time item type is displayed with format “hh:mm:ss”;
3. A datetime item type where the time part is not 00:00:00 is displayed with format “mmm
d, yyyy hh:mm:ss”;
4. A duration item type (the value looks like “P..Y..M..D..H..M..S”) is formatted as
“.. years, .. months, .. days, .. hours, .. minutes and .. seconds”, omitting any zero values.
5. A fact value that matches the regex for an XML QName [_A Za z][A Za z]*:[_A Za
z][A Za z0-9]* is displayed as follows:

106
 a. If the QName is being displayed with preferred label p and it has preferred label p
in this DTS, then display that label value;
b. If the QName as a standard label in this DTS, then display that standard label
value;
c. Otherwise display the QName unchanged.
6. A string that matches the regex [^~]*~\s+{URI}\s+[^~]*~.* is interpreted as an
embedding command;
7. A string that contains the < character followed by a QName and whitespace, “/>” or “>”
is interpreted as escaped XHTML and is rendered as XHTML.
8. Otherwise, the string is copied to the output unchanged.
6.18 The Filing Summary
(Formerly EFM v68 § 6.24.20) In addition to individual R-files, the renderer produces a Filing
Summary file that contains data about the input files, each R-file output, warnings, and error
messages logged during processing, and other information.
In particular, the Filing Summary contains for each report a computed “menu category” for each
report to assist in organizing a hierarchical menu for all reports. The renderer computes the menu
category by analyzing the report's role definition text as follows:
SortCode determines the order of appearance (9.2 below).
Type distinguishes between statements and non-statements.
Title is text to be displayed in the menu augmented with the following patterns: “(Policies”,
“(Tables”, “(Details”, layout qualifier tokens (6.14 above), and text that indicates cash flows
(6.12 above) and statements of changes in equity (6.13 above).
The order of appearance and patterns in the Title for a single Interactive Data instance are
processed as follows:
Category Condition
Cover Appears in first position and Type is not Statement
Statements Type is Statement
Notes Appears after Statements and is not Policies, Tables or Details
Policies None of the above, and Title contains “(Policies”
Tables None of the above, and Title contains “(Table”
Details None of the above, and Title contains “(Details”
Other None of the above
Uncategorized Always appears as the last report

Note that the reports are categorized in order of appearance, and their category may depend on
what report categories have already appeared.
An Uncategorized Facts report, if present, would always be in the last position by virtue of being
report number 9999.

107
6.19 Mul�ple Instances
(Formerly EFM v68 § 6.24.21) EDGAR submissions may have multiple Interactive Data
instance document attachments. The renderer processes them all together in the same order that
the instances appeared as EDGAR attachments. There is a single Filing Summary file output, and
all the reports are numbered sequentially starting at 1. Each instance has a separate set of menu
categories. When assigning a Menu Category as described in 9.2 below, any report whose
SortCode is less than the SortCode of the previous report marks the beginning of a new set of
menu categories.
If there are multiple instances each with uncategorized facts, they are numbered in descending
order 9999, 9998, etc.
6.20 Workbook Output
(Formerly EFM v68 § 6.24.22) The filing summary and reports are processed to produce a
spreadsheet workbook. Each report is shown as a separate sheet, with a name derived from the
first 32 characters of the presentation base set title. Each fact is presented in a spreadsheet cell.
Formatting of individual numeric and non-numeric facts is simplified as compared to the report
HTML format.
6.21 Resource Extrac�on Payment Rendering
(Formerly EFM v68 § 6.24.23) Instances with document type 2.01 SD are "RXP instances"; for
certain presentation groups the rows and columns are adjusted for improved layout. In
presentation groups with RXP roles, the columns are nested as:
• Primary
• Unit
In presentation groups with role URI http://xbrl.sec.gov/rxp/role/Detail, the rows are nested
in the following order:
• Period
• Legal Entity (if present)
• Typed dimension rxp:PmtAxis in numeric ascending order
In presentation groups with role URI http://xbrl.sec.gov/rxp/role/ByProject, the rows are
nested as:
• Period
• Legal Entity (if Present)
• Project
In presentation group http://xbrl.sec.gov/rxp/role/ByGovernment, the rows are nested as:
• Period
• Legal Entity (if Present)
• Government

108
6.22 Rendering of Mutual Fund Risk/Return Summary Interac�ve Data
An Interactive Data instance containing any fact whose element namespace contains the subtext
/xbrl.sec.gov/rr/ is a Mutual Fund Risk/Return Summary (RR) instance. These filings are
rendered with some differences as compared to other instances:
• The numeric value 0 is formatted as “none”.
• If any instance in a filing is an RR instance, then the menu category of each report is empty,
and all reports are shown together in a single menu called “Risk/Return Reports”.
• There is no workbook output.
RR instances are also allowed to use the additional features below.
6.22.1 Embedding Commands
(Formerly EFM v68 § 6.25.1) Conventional rendering of Interactive Data consists only of one
report per presentation base set. These are called the “top level” reports. Embedding commands
allow additional reports that are not at top level. A text block fact may contain an embedding
command, which is a section of XHTML that looks like the following, anywhere in the text
block:
~ http://xbrl.sec.gov/rr/role/ShareholderFeesData
column period compact *
row dei_LegalEntityAxis compact eg_S000005977Member
row dei_ProspectusShareClassAxis compact *
~ Comments can go here

The purpose of an embedding command is to identify a presentation base set, select a subset of
the contexts to display, and display the resulting report in place of where the content of the text
block would have been shown. An embedding command consists of:
• One Role URI, which identifies the presentation base set to use for the layout;
• A list of “iterators”, each of which:
o Places one of the axes (primary, period, unit, as described in 6.24.4 and 6.24.5) on either
the rows or columns.
o identify the style of that axis display (compact);
o indicates which members of the axis may appear in the selected contexts (6.24.2).
A “compact” display means that each axis member is shown on a separate row (or column) with
its label. Embedding layouts do not support the use of period start and period end preferred label
roles.
Embedding command syntax, and the possible warning messages that may result from
processing the command, are detailed below.
6.22.2 Bar Charts
(Formerly EFM v68 § 6.25.2) When an embedded command has a role URI that contains the
case-insensitive text barchart and the primary elements are drawn from the set
109
rr_AnnualReturn2008, rr_AnnualReturn2009, and so forth, then the renderer produces a graphic
instead of a conventional table. The text block would have a command like this:
~ http://xbrl.sec.gov/rr/role/BarChartData
column period compact *
column dei_LegalEntityAxis compact S00000123Member
column rr_ProspectusShareClassAxis compact *
row primary compact * ~

Up to 20 facts may be shown. The bar chart has a fixed height and auto-scales vertically; it has
fixed width horizontal bars. For example, three facts are displayed in the graphic shown below:
Element Value
rr_AnnualReturn2008 -0.3868
rr_AnnualReturn2009 0.0303
rr_AnnualReturn2010 0.2727

Although it is not necessary, the horizontal width of the graphic can be adjusted by adding ‘nil’
valued facts. Footnotes on the facts are ignored.

7 Valida�on Details on All XBRL atachments

EDGAR does not permit attachments to use certain technical features of the XBRL information model, no
matter the file format. Note that standard taxonomy files are not attachments, so these validations do not
apply to them.
7.1 File names and character encodings
All attachments are subject to the same validations applied by the EDGAR system.

110
 Check f On failure s EFM v68 Ref
The file name matches the regex File Name E § 6.5.1
[a-z0-9][a-z0-9\._-]*\.(htm,xml,xsd)
File Name
The file name length is 32 characters or fewer. Length E § 6.5.1
File
The file does not contain character ^ (circumflex). Character E § 6.5.2
File Entity
The file does not contain HTML entity codes. 1 Code E § 6.5.2

Notes and special cases:

3. HTML entities such as &nbsp; are not permitted, but their equivalent XML encodings such as &#160;
are.
7.2 Standard namespace prefixes
If the following namespaces appear in file attachments, then they must appear only with the following
prefixes; where there is an alternate, the prefix or alternate must be used consistently.
In this document, the shorter prefixes i: and xs: are used rather than xbrli: and xsd: respectively.
Namespace URI Prefix Alternate
http://www.sec.gov/inlineXBRL/transformation/2015-08-31 ixt-sec
http://www.w3.org/1999/xhtml xhtml (empty)
http://www.w3.org/1999/xlink xlink
http://www.w3.org/2001/XMLSchema xs xsd
http://www.w3.org/2001/XMLSchema-instance xsi
http://www.w3.org/XML/1998/namespace xml
http://www.xbrl.org/2003/instance xbrli i
http://www.xbrl.org/2003/iso4217 iso4217
http://www.xbrl.org/2003/linkbase link
http://www.xbrl.org/2003/XLink xl
http://www.xbrl.org/2006/ref ref
http://www.xbrl.org/2009/dtr dtr
http://www.xbrl.org/2013/InlineXBRL ix
http://www.xbrl.org/dtr/type/2020-01-21 dtr-types
http://www.xbrl.org/dtr/type/2022-03-31 dtr-types
http://www.xbrl.org/inlineXBRL/transformation/2015-02-26 ixt
http://www.xbrl.org/inlineXBRL/transformation/2020-02-12 ixt
http://www.xbrl.org/inlineXBRL/transformation/2022-02-16 ixt
http://xbrl.org/2005/xbrldt xbrldt
http://xbrl.org/2006/xbrldi xbrldi
http://xbrl.org/2014/extensible-enumerations enum
http://xbrl.org/2020/extensible-enumerations-2.0 enum2

Validations:
Check f On failure s EFM v68 Ref
If a namespace is used in the XML QName of an element Standard
1, Namespace
name, attribute name, or text node, then it has one of the E § 6.5.2
2 Prefix
recommended prefixes.
Standard
The prefix used for a namespace must be the same in all Namespace
1 E § 6.5.2
attachments of a submission. Prefix

111
Notes and special cases:
1. Only one binding for prefix ixt or dtr-types is permitted in each instance of a submission.
2. A consequence of other EDGAR validations is that the namespace that is prefixed xl need never
appear in a submission.
7.3 Standard loca�ons
The data file edgartaxonomies.xml defined in EFM v68 § 6.2.2 contains all the non-local taxonomy URLs
for namespaces that a submission may use, and vice versa. It may be updated with each EDGAR release.
Check f On failure s EFM v68 Ref
Attributes xlink:href, schemaLocation and
Prohibited
xsi:schemaLocation values are either a relative URL
Href Or Schema E § 6.22
resolving to a file within the submission, or an absolute Location
URL appearing in the edgartaxonomies data file.
A standard namespace must only be defined at the URL
1
defined in the edgartaxonomies data file.
Notes and special cases:
1. This is implied by the combination of other validations and SEC taxonomy conventions but is not
reported as a separate error.
7.4 Compa�ble Taxonomies
Processing an instance requires constructing the Discoverable Taxonomy Set (DTS) as defined in the
XBRL specification.
As implied by EFM v68 § 6.3, certain pairs of taxonomies are incompatible when they appear together in
a DTS.
Generally, each standard taxonomy has a four-digit year embedded in their namespace URIs. The
namespace URI syntax varies somewhat depending on its authority component:
Regex locating the four-digit year in standard taxonomy namespaces
https?://xbrl.sec.gov/[a-z0-9-]+/(yyyy)(q[234])?
https?://(xbrl.)?fasb.org/[a-z-]+/(yyyy)(q[234])?
https?://ifrs.org/taxonomy/(yyyy)-..-../.*

Taxonomies of different years cannot be used together. Namespace URIs for w3.org and xbrl.org and
custom namespaces are ignored for this check.
XBRL validation does not permit link:roleType to define the same roleURI attribute to be defined at
different URLs; since the role URI is often stable from one taxonomy version to the next, some schemas
with different years may be incompatible for that reason. A few specific entry points may be incompatible
as well and are listed below.
Validations:
Check f On failure s EFM v68 Ref
All standard taxonomy namespaces in a DTS have the same Incompatible
Schemas E 6.22.3
four-digit year component.
If an xs:schema attribute targetNamespace value matches
sec.gov/rr/ then no other target namespace matching 1, Incompatible
Schemas E 6.22.3
sec.gov/oef-rr, fasb.org, or ifrs.org appear in the same 2
DTS.

112
Notes and special cases:
1. For this check, the targetNamespace attribute of a schema must be tested even if it contains no
xs:element declarations.

2. The rr taxonomy was deprecated as of 2023.

7.5 Elements
Validations:
Check f On failure s EFM v68 Ref
Element is not i:forever Context Has Period Forever E § 6.5.38
Element is not i:scenario No Scenario E § 6.5.4
Element is not xs:include Schema Include Present E § 6.7.1
Element is not ix:fraction 1, 2 Fraction Item Type E § 6.7.31
Element is not link:arcroleType 1, 2 Custom Arcrole Referenced E § 6.9.6
Element is not link:referenceLink 1, 3 Element Has Reference E § 18
Notes and special cases:
1. Previously, this was only implied by the combination of other validations in EFM v68.
2. EDGAR standard taxonomies do not define fraction item types nor custom arc roles.
3. Most standard taxonomies have reference linkbases, either embedded or in separate files.
7.6 Element atributes
Validations:
Check f On failure s EFM v68 Ref
Element does not have attribute xml:base 1 XML Base Used E § 6.3.11
Element does not have attribute precision 2 Decimals Not Precision E § 6.5.17
Element xs:element does not have attribute Typed Domain Ref
enum2:domain Disallowed E § 6.7.2
Element xs:element does not have attribute Typed Domain Ref
enum:domain Disallowed E § 6.7.2
Element link:presentationArc has Presentation Order Missing E § 6.12.1
attribute order
Element link:calculationArc has Calculation Relationship
Order Missing E § 6.14.1
attribute order
Element link:definitionArc has attribute Definition Relationship
order Order Missing E § 6.16.1

Notes and special cases:

1. XML processors interpret this attribute differently, so it must not be used anywhere.
2. This applies to elements in substitution group i:item and elements ix:nonNumeric and
ix:nonFraction.

113
7.7 Element atribute values
Validations:
Check f On failure s EFM v68 Ref
Element i:identifier attribute scheme value is Entity Identifier
http://www.sec.gov/CIK Scheme E § 6.5.1
xs:element has attribute nillable value true Nillable Not True E § 6.7.18
If xs:element with attribute abstract value Abstract Is Instant E § 6.7.21
true, then it has i:periodType value duration
Element xs:element attribute type value is not Fraction Item Type E § 6.7.31
i:fractionItemType
If element with xlink:type value of arc has Relationship Priority
Not Less Than Ten E § 6.9.9
attribute priority, then the value less than 10.
Calculation
Element link:calculationArc attribute weight Relationship Weight E § 6.14.2
value is either -1 or 1. Not Unitary

Notes and special cases: none.

7.8 Atribute value lengths
The content of certain XML attributes and text nodes in UTF-8 must not exceed 200 bytes in length. This
length restriction applies to bytes in UTF-8 encoding, not characters. For example, an element name of
101 repetitions of character “Ā” (Unicode x0100) violates this criterion because its UTF-8 encoding has
202 bytes. The six-byte encoding of that same character, “&#256;” when read and stored as an XML text
node in UTF-8 encoding, would also be two bytes. Therefore, up to 100 repetitions of that sequence
would be allowed. Other length limits are applied similarly.
Validations:
Check f On failure s EFM v68 Ref
Name Length
Text of element i:measure is 200 bytes or fewer. Limit E § 6.5.36
Element xs:element attribute name value is 200 bytes or Name Length
Limit E § 6.7.29
fewer.
Element link:roleType Attribute roleURI value is 200 URI Length
Limit E § 6.7.30
bytes or fewer.
Element xs:schema attribute targetNamespace value is URI Length
Limit E § 6.7.30
200 bytes or fewer.
Notes and special cases: none.

8 Valida�on Details on XBRL instances

EDGAR does not permit instances to use the following features of the XBRL information model,
regardless of file format:
1. XHTML elements and attributes disallowed by EDGAR HTML,
2. XBRL footnotes that are not local or use custom relationships,
3. Use of a “decimals” attribute value to truncate non-zero digits on a numeric fact,
4. Facts having periods that overlap by less than 24 hours,
5. Facts with a non-US English language code without a corresponding English fact,
Other features are disallowed only in some instance formats:

114
 6. In xBRL-XML and Inline XBRL, context elements that duplicate the same entity, period,
and taxonomy-defined dimensions,
7. In Inline XBRL, the target and xsi:schemaLocation attributes on any elements,
8. EDGAR restrictions and enhancements of Inline XBRL found in § 5.2.2 and 5.2.5.
8.1 XHTML Valida�ons
HTML as accepted by EDGAR is detailed in § 5.2.2 and is based on HTML 3.2 elements and entities,
with extensions (such as allowing a style attribute) and restrictions (such as disallowing the textarea
element). HTML elements span, tbody, thead, tfoot, and the un-prefixed lang attribute may also be
used in Inline XBRL. The HTML must satisfy a content model derived from the BODY tag as defined in
§ 5.2.2. The content model detailed in § 5.2.2 restricts Inline XBRL, to XBRL footnotes, and to certain
non-numeric facts.
Validations:
Check f On failure s EFM v68 Ref
External
Attribute href is either a local relative URL or an absolute Reference In
URL starting with 1 href Note E § 6.5.16
https://www.sec.gov/Archives/edgar/data/ Accepted
External
Attribute src is either a local relative URL or an absolute Reference In
URL starting with 1 src Not E § 6.5.16
https://www.sec.gov/Archives/edgar/data/ Accepted
JavaScript In
Attribute href does not use scheme javascript: 1 href E § 6.5.16
The attribute src of the img element is a reference to a Graphics File
graphics file with name either .gif or .jpg and a valid 1 Has Invalid E § 6.5.16
format. Format
The attribute src of the img element is a reference to a Graphics File
1 Not Openable § 6.5.16
graphics file that is not openable.
Nested Table
A table element has no ancestor <table> elements. 1 Elements E § 6.5.16

Notes and special cases: none.

1. Applies to the content of text block facts and to the XHTML content of link:footnote
elements.
8.1.1 HTML restric�ons on Text Block facts
The XII Data Type Registry (DTR) type textBlockItemType specializes xmlNodesItemType. The
unescaped text content of such facts must have mixed content containing a simple string, a fragment of
XHTML, or a mixture of both. Facts of textBlockItemType whose unescaped content contains XML
elements must satisfy the restricted content model of § 5.2.2. In the table below, unless otherwise stated
the checks apply to the unquoted text of a fact with a concept of type textBlockItemType.
Check f On failure s EFM v68 Ref
The text does not contain unbalanced tags. For example, Text-Block-
<br> must be followed by </br>; values of attributes such 1 Not-Well- E § 6.5.15
as align must be quoted, as in align="center". Formed-XML

Notes and special cases:

1. The content of an XBRL footnote must be valid XHTML; therefore, there is no need for an
EDGAR validation for unbalanced tags.

115
8.1.2 HTML restric�ons on XBRL footnotes
Validations:
Check f On failure s EFM v68 Ref
The content of link:footnote has content satisfying Prohibited HTML
Footnote Body E § 6.5.34
the EDGAR restricted BODY content model.
Notes and special cases: none.
8.1.3 HTML restric�ons on Inline XBRL
Inline XBRL has additional restrictions defined in § 5.2.5.
Validations:
Check f On failure s EFM v68 Ref
The XHTML elements of an Inline XBRL file has content Prohibited
HTML E § 5.2.5
satisfying the EDGAR restricted BODY content model.
Notes and special cases: none.
8.2 Labels
A concept that appears in an instance in facts or contexts must have at least one label defined in either a
standard taxonomy file or in a custom taxonomy.
Validations:
Check f On failure s EFM v68 Ref
Element Used
The element of a fact has a standard label. Standard Label E § 6.10.1
An element i:explicitMember attribute dimension Element Used
Standard Label E § 6.10.1
value has a standard label with xml:lang value en-US.
An element i:typedMember attribute dimension value Element Used
Standard Label E § 6.10.1
has a standard label with xml:lang value en-US.
The QName content of an i:explicitMember element Element Used
Standard Label E § 6.10.1
has a standard label with xml:lang value en-US.
Notes and special cases: none.
8.3 Presenta�on
A concept that appears in an instance in facts or contexts must participate in at least one effective
presentation relationship in the DTS of that instance. An element “participates in a presentation
relationship” in a DTS if it is a source or target of a presentation relationship in that DTS.
An element is “a source (or target) of a presentation relationship” in a DTS if there is an effective
relationship with the defining xs:element source (or target) and an xlink:arcrole attribute equal to
http://www.xbrl.org/2003/role/parent-child in a document of that DTS.

8.4 Footnote Links

EDGAR restricts use of the link:footnoteLink element in a variety of ways in addition to restrictions
on its XHTML content.

116
Validations:
Check f On failure s EFM v68 Ref
Element link:footnoteLink must have no child Footnote
elements other than link:footnote, Substitution E § 6.5.27
link:footnoteArc, and link:loc Group
Attribute xlink:role of elements link:footnoteLink Footnote Role
Missing E § 6.5.28
and link:footnote must be present.
Attribute xlink:role of elements link:footnoteLink
Footnote Custom
and link:footnote must have a role defined in XBRL Footnote Role E § 6.5.29
2.1 or in a standard taxonomy schema.
Attribute xlink:role of element link:loc must have a
Footnote Custom
role defined in XBRL 2.1 or in a standard taxonomy Loc Role § 6.5.30
schema.
The href attribute value of a locator is local, that is, it Footnote Locator
Portable E § 6.5.32
must begin with the character #.
A link:footnote element is the target of at least one Dangling
Footnote E § 6.5.33
footnote arc.
Notes and special cases: none.
8.5 Decimals
If the decimals attribute of a numeric fact is not INF, then the value is interpreted as if certain digits were
zero. An instance must not contain usage that cause non-zero digits to be interpreted as zero. The
examples below illustrate correct and incorrect use:
Fact text decimals value Interpreted fact value Result
-2345.67 INF -2,345.67
-2345.67 2 -2,345.67
-2345.67 0 -2,345.00 Error
-2345.67 -2 -2,300.00 Error
-2345.67 -3 -2000.00 Error
-2345.67 -6 0000.00 Error
Validations:
Check f On failure s EFM v68 Ref
A non-nil numeric fact value is not truncated by the Nonzero Digits
1 Truncated E § 6.5.37
decimals attribute.

Notes and special cases:

1. The check is not symmetric; a value such as 1,000,000 may have a decimals attribute with any
value greater than -6, such as -5, -4, etc.
8.6 Contexts
An instance must not contain redundant i:context elements. For testing redundancy, the equivalence of
contexts is defined with respect to the equivalence tests defined in XBRL 2.1 Specification section 4.10.
Also, an instance must not contain any i:context elements whose id attribute value does not appear as
the value of at least one contextRef attribute.

117
Validations:
Check f On failure s EFM v68 Ref
There is no pair of contexts with structurally equal (S-equal)
Duplicate
i:identifier elements, S-equal i:period elements, and Contexts E § 6.5.7
Set-equal i:segment children.
The id value of a context appears as the value of at least one Unused
Context E § 6.5.8
contextRef attribute.

Notes and special cases: none.

8.7 Periods
The set of periods (instants and durations) used in the facts of an instance must be checked for certain
disallowed overlaps. A date in i:startDate is “midnight at the beginning of” that day. A date in
i:instant or i:endDate means “midnight at the end of” that day.

There must be no pair of periods that overlaps by 24 hours or less; that is, if the duration of a period is
more than 24 hours, then its end datetime value must be greater than the start datetime of any other period
by 24 hours or less.
For example, a company reporting at fiscal year end of May 31st, 2029, will have data in two fiscal years
that abut at midnight at the end of May 31st, 2028. This means there will be periods with end datetimes of
midnight 2028-05-31 (the prior fiscal year) as well as periods whose start datetimes are midnight at the
beginning of 2028-06-01 (the current fiscal year). Both describe the same midnight. However, it must not
have periods with start datetime of midnight at the beginning of 2028-05-31, and no contexts with end
datetime of midnight at the end of 2028-06-01.
Validations:
Check f On failure s EFM v68 Ref
Each end datetime value must be greater Start And End Dates Not
than the start datetime of any duration 1 Distinct Inconsistent With E § 6.5.9
period by 24 hours or less. Document Type
Each instant datetime value must be Start And Instant Dates Not
greater than the start datetime of any Distinct Inconsistent With E § 6.5.9
duration period by 24 hours or less. Document Type

Notes and special cases:

1. At one time, certain instance types were unlikely to have contexts with periods of more than 24
hours, but in practice, the validation applies to all instance types.
8.8 Units
Validations:
Check f On failure s EFM v68 Ref
There are no equivalent i:unit elements. 1 Duplicate Units E § 6.5.11
The concept type and unit of a fact must be
Incompatible Numeric
consistent as defined by the XII Unit Type Type And Unit § 6.5.35
Registry (UTR)
Notes and special cases:

118
 1. Units are equivalent if they have equivalent measures or equivalent numerator and denominator.
Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators
are equivalent if they have a set of equivalent measures.
8.9 Non-US English Facts
The default value of the xml:lang attribute on non-numeric facts and on element link:footnote in
EDGAR is en-US (EFM v68 § 6.5.13). There are a small number of instance types, such as AF.FPI, in
which a few text fragments may be expressed in a language other than English. An instance having a fact
with non-nil content and the xml:lang attribute not equal to en-US must also contain a fact using the
same element and all other attributes with an xml:lang attribute that is effectively en-US. For example,
the US English fact below may appear in an instance without the French fact, but the French fact must not
appear without the US English fact.
<eg:answer contextRef="x">YES</eg:answer>
<eg:answer contextRef="x" xml:lang="fr">OUI</eg:answer>

Validations:
Check f On failure s EFM v68 Ref
If a non-numeric fact exists with an xml:lang attribute value
English
not starting with en, then there must be a corresponding fact in
1 Text E § 6.5.14
the same context with no xml:lang attribute or xml:lang Missing
value en-US.
If a link:footnote exists with an xml:lang attribute value
English
not starting with en, then there must be a footnote having the
1 Text E § 6.5.14
same xlink:label value with no xml:lang attribute or Missing
xml:lang value en-US.

Notes and special cases:

1. The appearance of attribute xml:lang or lang on XHTML elements is not checked.
8.10 Duplicate facts
An instance must not have more than one fact having S-Equal element names, equal contextRef
attributes, and if they are present V-Equal unitRef attributes and xml:lang attributes effective values,
respectively, unless their values are consistent, as described below, in which case the distinct facts are
consolidated into a single fact for all other validations.
For numeric facts, all such values must be consistent with having been rounded from a single value.
Where the decimals attribute of such of facts is the same, the values MUST be numerically equal. Where
the decimals attribute is different, consistency is determined by considering a closed interval centered on
each fact value, and of size 10 to the nth power where n is the value of the decimals attribute and
checking for overlap of all such intervals. For example, a value of 500 with a decimals attribute of -2
would result in an interval of 450 to 550, inclusive. A value of 550 with decimals attribute of -1 results in
an interval of 545 to 555. These values are considered consistent as the intervals overlap; they are both
consistent with having been rounded from a value in the range 545 to 550. The use of a closed interval
means that intervals are inclusive of the end values.
Consistent numeric facts are consolidated into a single fact having the value of the fact with the maximum
specified decimals value for purposes of validation and rendering.
For non-numeric facts, the values are consistent only if they are V-Equal.

119
The xml:lang attribute effective value is relevant only for types derived from
i:normalizedStringItemType or i:stringItemType. A fact is an occurrence in an instance of an
element with a contextRef attribute. The values of the id attributes are not relevant to detection of
duplicate facts. Other rules forbidding equivalent i:context and i:unit elements ensure that duplicate
values of the contextRef and unitRef attributes can be detected without dereferencing.
The predicate V-Equal is defined in XBRL 2.1 section 1.4 and specifies that non-numeric values are
compared after whitespace normalization.
Calculation inconsistencies have no impact on the validity of EDGAR submissions, and therefore the
effect of numeric fact duplication in XBRL 2.1 section 5.2.5.2 is moot.
Validations:
Check f On failure s EFM v68 Ref
All numeric facts having the same concept, context, and unit
Duplicate
must have values that are consistent with having been rounded 1 Facts E § 6.5.12
from a single value.
All non-numeric facts having the same concept, context, and Duplicate
1 Facts E § 6.5.12
unit must have equal values.
Notes and special cases: none.

9 Valida�on Details on Custom Taxonomies

Section 5.5 above provided an informal list of validations that apply to all custom taxonomies.
9.1 Custom namespace and role URIs
For the purposes of this guide, the effective authority of a URI consists of the last part of the URI between
the // and the first / and containing at most one dot.
Regex locating the effective authority in a URI
https?://[^/]*(([a-z]+\.)?[a-z]+)/.*

For example, the effective authority of URI http://xbrl.sec.gov/dei/2025 is sec.gov and the
effective authority of URI http://uvw/20251031 is uvw. The path is any part after the authority.
Validations:
Check f On failure s EFM v68 Ref
Taxonomy Valid
The attribute targetNamespace value starts with http:// Target E § 6.7.3
Namespace
The authority part of the attribute targetNamespace value Taxonomy Valid
does not have the same authority as any standard 1 Target E § 6.7.4
namespace URI. Namespace
Taxonomy Valid
The path part of the attribute targetNamespace value is a Target E § 6.7.6
date in the pattern /yyyymmdd. Namespace
Element xs:schema binds a recommended namespace Taxonomy Valid
prefix for the targetNamespace attribute value that does 2 Target E § 6.7.7
not contain the underscore character. Namespace
Within an xs:schema element, the effective authority of Role Namespace E § 6.7.9
Mismatch
element link:roleType attribute roleURI value is the

120
 Check f On failure s EFM v68 Ref
same as the effective authority part of the
targetNamespace URI.

Notes and special cases:

1. The effective authority is a domain name controlled by the registrant, a domain name controlled
by the publisher of the schema, or if neither exists, then a mnemonic name for the registrant such
as its trading symbol or CIK (EFM v68 § 6.7.5).
2. A mnemonic such as a trading symbol of the company in lowercase is suitable.
9.2 Roles
A custom taxonomy link:roleType declaration is important for associating the role with the custom
taxonomy namespace, providing a name for a group of relationships, and ordering the appearance of
calculation, definition, and presentation groups to a user of the taxonomy. Custom roles used with
presentation relationships also communicate the order, the level of fact detail, and a human readable title
for a group of relationships and facts. The link:definition element text contains a Sort Code, a Type,
and a Title:
SortCode - Type - Title

The Type is used only to arrange presentation groups in a hierarchical menu during the rendering process.
The Title communicates the meaning of the presentation group. The SortCode is used only to sort base
sets for display. The sort code is sorted alphanumerically, not numerically, so sort code “10” would appear
before “2”.
For instances in the financial statement submission sets AF, QF, and HF (only) as governed by the text of
17 CFR 232.405-407 (i.e., regulation S-T rules 405 through 407), filers must choose a scheme for their
sort code and declare separate role types to achieve the different levels of tagging that the rule implies:
Level Content
0 Cover page and other material preceding financial statements;
1 Detail tagging of amounts in financial statements, and block-tagged notes to the financial
statements;
2 Each significant accounting policy, block-tagged;
3 Each table, block-tagged;
4 Detail tagging of amounts in the notes to financial statements.
Presentation group ordering:
1. Level 0: any cover page detail tags or block tagged content from sections of the Form appearing
before the statements.
a. Use Type “Document” for these roles.
2. Level 1: Each statement (income, balance sheet, etc.) in at least one presentation group, in the
order the statement appeared in the Inline XBRL (or original HTML/ASCII) document.
a. Use the Type “Statement” for these roles.
b. If a lengthy statement is split across more than one role, the SortCode must preserve the
original ordering.
c. A statement that contains parenthetical disclosures on one or more rows must have a
presentation group immediately following that of the Statement, where all facts in its
parenthetical disclosures appear in relationships.

121
 3. Level 1: All presentation group containing the content of notes to the financial statements;
a. Use the Type “Disclosure” for these and all subsequent roles.
b. A text block fact containing each note appearing as the target of one presentation
relationship in a base set.
4. Level 2: All presentation groups containing accounting policies, each as a separate text block.
a. End the Title of these roles with the text “ (Policy)” or “ (Policies)”.
5. Level 3: All presentation groups containing each table that appeared in the notes, each as a
separate table text block.
a. End the Title of these roles with the text “ (Table)” or “ (Tables)”.
6. Level 4: All presentation groups containing sets of detail tagged amounts from the text and tables
of the notes.
a. End the Title of these roles with the text “ (Detail)” or “ (Details)”.
Validations:
Check f On failure s EFM v68 Ref
The path part of the attribute roleURI value matches regex Role Ending
(/.+)?/role/[^/]+ Mismatch W § 6.7.9
The DTS does not contain more than one link:roleType Role Type
Duplicates E § 6.7.10
having the same roleURI attribute value.
Role Type
The text of element link:usedOn must match regex Declaration E § 6.7.11
link:(calculation|definition|presentation)Link Incomplete
Role Type
Element link:roleType must have three distinct Declaration E § 6.7.11
occurrences of link:usedOn. Incomplete
The text of element link:definition must match regex 1, Role
\d+\ -\ (Document|Statement|Disclosure|Schedule)\ - .+ 2, Definition E § 6.7.12
with no leading or trailing whitespace. 3 Mismatch
Presentation
Level 1 presentation groups precede level 2 presentation Base Set W § 6.7.12
groups, level 2 precedes level 3, and level 3 precede level 4. Order

Notes and special cases:

1. If an instance type is not in submission sets AF, QF, or HF but nevertheless has facts presented in
roles with Type Statement, it will be rendered as if it were conforming to the four-level tagging
scheme above.
2. For instances of instance types without financial statements, it is conventional but not mandatory
for roles that contain presentation relationships to have Disclosure as their Type, while roles that
are used in a custom taxonomy only for definition or calculation relationships have Document as
their Type.
3. The Type Schedule has been replaced in practice by Disclosure and will soon be deprecated.
9.3 Concepts
When constructing a custom concept name, a common convention is to capitalize the first letter, then use
mainly lowercase characters, omitting punctuation and using capitalization only to indicate a natural word
break, for example LongTermDebt or YtdReturn. If the name is originally based on a label that changes

122
in a subsequent version of the schema, that label changes, the name attribute must not be changed merely
to maintain agreement.
Validations:
Check f On failure s EFM v68 Ref
The element xs:element attribute name value does not equal
Element Name
any xs:element attribute name value in a standard 1 Same As Base E § 6.7.16
taxonomy in the same DTS.
The element xs:element attribute name value does not start Element Id E § 6.7.17
with the underscore character.
The xs:element attribute id must consist of the
recommended namespace prefix of its namespace, followed Element Id E § 6.7.17
by one underscore, followed only by its name attribute.
The xs:element attribute substitutionGroup must not be a No Tuple
Element E § 6.7.19
member of a substitution group with head i:tuple.
Notes and special cases:
1. It is not necessary to compare the name attribute to all element declarations in all standard taxonomy
schemas. Only those schemas that are present in the DTS of a specific instance being validated are
relevant.
9.4 Rela�onships
Arcs in custom taxonomies, whether they import standard taxonomy relationships or not, may form
patterns of relationships that have ambiguous or contradictory semantics; these validations test for such
patterns among relationships.
Abbreviation Relationship arc role URIs
all http://xbrl.org/int/dim/arcrole/all
dimension-domain http://xbrl.org/int/dim/arcrole/dimension-domain
dimension-default http://xbrl.org/int/dim/arcrole/dimension-default
domain-member http://xbrl.org/int/dim/arcrole/domain-member
hypercube-dimension http://xbrl.org/int/dim/arcrole/hypercube-dimension
notAll http://xbrl.org/int/dim/arcrole/notAll

summation-item
Either http://www.xbrl.org/2003/role/summation-item
or http://xbrl.org/2023/role/summation-item
Validations:
Check f On failure s EFM v68 Ref
Relationship
An arc is not ineffectual. 1 Ineffectual E § 6.9.3
All effective presentation relationships in the same
Presentation
base set with the same source element have distinct Order Duplicates E § 6.12.2
values of the order attribute.
There are no effective presentation relationships in the
Preferred Label
same base set having the same source concept, target Duplicates E § 6.12.5
concept, and preferredLabel value.
A presentation group has only one concept (the “root”) Multiple Root
Nodes W § 6.12.6
that is not the target of any arc in that set.
There are no directed cycles in effective summation- Circular
Calculation E § 6.14.4
item relationships.

123
 Check f On failure s EFM v68 Ref
The target of a dimension-domain or dimension- Dimension Domain
Target Mismatch § 6.16.3
default relationship has type domainItemType.
There are no undirected cycles in any effective
2, Domain Is
domain-member and dimension-domain directed E § 6.16.4
3 Tangled
relationship set.
Primary Element
A concept is the source of at most one all relationship Has Redundant E § 6.16.5
in each base set. Tables
Not All
A notAll relationship has attribute closed value of Relationship Is E § 6.16.6
false. Closed
Target Role With
If an arc has attribute targetRole, then it has a No Consecutive
3 E § 6.16.9
consecutive relationship. Relationships
An axis element that is the target of an effective
relationship with arc role hypercube-dimension that is
consecutive from a relationship with arc role notAll
Axis Excluded
must also be the target of an effective relationship in a 4 Not In Table E § 6.16.7
link:definitionLink having the same value of
xlink:role and which itself is consecutive from an
effective relationship with arc role all.
An arc with arc role notAll is not the target of an
effective arc with an xlink:arcrole attribute equal to Table Excludes
4 Itself E § 6.16.8
all in link:definitionLink elements having equal
values of xlink:role.
A base set having one effective presentation
relationship whose target has the same local name as
Presented Units
the unitRef attribute value of a fact of a source or 5 Incomplete Order W § 6.12.9
target element in the same base set should provide an
ordering for all such unitRef attribute values.
Notes and special cases:
1. Arcs are ineffectual when there is an equivalent relationship with the same or higher value of the
priority attribute or when it overrides an unprohibited arc. An arc with use="prohibited"
takes precedence over arcs with use="optional" when their priorities are the same. Checks
apply only to relationships in custom taxonomies; a custom relationship may override a
prohibited standard taxonomy relationship of a lower priority; it must not override another
custom relationship.
2. This also impacts financial statement line items, so that the balance at the start and end of a roll
forward cannot appear twice under a single axis. The same rendering effect is achieved by
including only the ending balance in the domain-member relationships, so that the beginning
balance will appear simply as the ending balance of the previous period.
3. The terms consecutive relationship and directed relationship set are related to targetRole
attributes and are defined in detail in the XBRL Dimensions specification.
4. The notAll arc role does not appear in any standard taxonomies and will soon be deprecated in
custom taxonomies.
5. The renderer displays sets of facts having multiple units of measure that cannot be merged into
columns (or rows) in one of two ways. Either the units are ordered by the order they are declared
in the instance, or by using the built-in unit axis ordered by relationships in a presentation group.
124
 The presentation group should either order all the units used, or none of them, so that the ordering
is not mixed.
9.5 Concept types and rela�onships
The validity of relationships may depend on the concepts that are their sources and targets.
Validations:
Check f On failure s EFM v68 Ref
An axis concept that is a target in an effective
presentation group is the source of at least one Axis Requires Domain
Child W § 6.12.8
presentation relationship that is a domain
member.
The source and target concepts of a summation- Calculation
item arc have the same attribute i:periodType Relationship Has E § 6.14.3
value. Different Period Types

Notes and special cases: none.

9.6 Concept labels and roles
Label roles fall into a few related categories that impact their use on different concept types.
Label category Label role URI
standard http://www.xbrl.org/2003/role/label
documentation http://www.xbrl.org/2003/role/documentation
http://xbrl.us/us-gaap/role/label/periodStart
http://xbrl.us/us-gaap/role/label/periodEnd
instant
http://xbrl.us/us-gaap/role/label/negatedPeriodStart
http://xbrl.us/us-gaap/role/label/negatedPeriodEnd
http://www.xbrl.org/2003/role/positiveLabel
http://www.xbrl.org/2003/role/positiveTerseLabel
http://www.xbrl.org/2003/role/positiveVerboseLabel
http://www.xbrl.org/2003/role/negativeLabel
http://www.xbrl.org/2003/role/negativeTerseLabel
http://www.xbrl.org/2003/role/negativeVerboseLabel
http://www.xbrl.org/2003/role/zeroLabel
http://www.xbrl.org/2003/role/zeroTerseLabel
http://www.xbrl.org/2003/role/zeroVerboseLabel
http://www.xbrl.org/2003/role/totalLabel
numeric
http://www.xbrl.org/2009/role/negatedLabel
http://www.xbrl.org/2009/role/negatedPeriodEndLabel
http://www.xbrl.org/2009/role/negatedPeriodStartLabel
http://www.xbrl.org/2009/role/negatedTotalLabel
http://www.xbrl.org/2009/role/negatedNetLabel
http://www.xbrl.org/2009/role/negatedTerseLabel
http://xbrl.us/us-gaap/role/label/negated
http://xbrl.us/us-gaap/role/label/negatedTotal
http://xbrl.us/us-gaap/role/label/negatedPeriodStart
http://xbrl.us/us-gaap/role/label/negatedPeriodEnd

Validations:

125
 Check f On failure s EFM v68 Ref
If the xlink:role of element link:label is not
documentation, then its text is whitespace
1 Label Disallowed E § 6.10.6
normalized, contains no &lt; characters, and is
fewer than 511 characters.
The text of element link:label has no leading or Label Not Trimmed E § 6.10.8
trailing white space.
A concept has at most one label for any combination Element Used Has
Duplicate Label § 6.10.2
of xlink:role and xml:lang values.
If a concept is used in an instance as a fact, Element Used
dimension, or domain member, then it has a standard Standard English E § 6.10.3
label with xml:lang attribute en-US. Label
More than one concept has the same standard label English Standard
Labels Duplicated E § 6.10.4
with xml:lang value en-US.
Custom
A concept in a standard namespace does not have a Documentation E § 6.10.5
custom documentation label. Standard Element
A non-numeric concept does not have any label with Numeric Label Role E § 6.10.9
a numeric role.
The target of an effective presentation relationship Period Type
with a preferredLabel value that is an instant Preferred Label W § 6.12.7
role does not have period type duration. Mismatch

Notes and special cases:

1. All labels may contain the XML whitespace characters ASCII 9, 10, 13 and 32 anywhere except
at their start or end. Documentation labels may contain sequences of extra whitespace; all other
labels must be normalized.
9.7 Rendering valida�ons
Because the rendering process involves both facts in the instance and the content of the taxonomy, it has
validations that involve both.
9.7.1 Each axis that is presented requires at least one child element.
If the default member of an Axis does not appear in an effective presentation relationship base set, then
the only facts that can be displayed by that presentation base set are facts in contexts having a non-
defaulted member on that Axis.
Check f On failure s EFM v68 Ref
If an effective presentation relationship base set has an explicit
Axis element without its default member as a descendant, then All Facts
Filtered E § 6.26.1
there is at least one fact displayed having a non-defaulted
member on that axis.
Notes and special cases:
1. If every fact in the group is defaulted on such an axis, then all facts would be filtered out. If the
instance contains no non-default member facts, then the base set will never display anything.

126
9.7.2 Matching instant and dura�on facts
Facts presented in an effective presentation relationship base set using period start or period end preferred
labels should contain alternating instant and duration facts. The renderer lays out a set of facts with at
least one column for each period, ordering the columns by increasing duration and descending date.
An effective presentation group in which facts are presented with the period start and period end roles as
described in 6.7 above is considered a movement analysis. When the renderer presents a movement
analysis of a set of facts consisting of beginning and ending values and changes that occurred during the
period, it orders the periods by alternating the instants and durations, in decreasing duration and
increasing end date order.
Check f On failure s EFM v68 Ref
For each date-time of instant facts displayed with a period Instant
start or period end label, there is at least one duration fact Without
1 Matching W § 6.26.2
in the same movement analysis presentation group with a
Duration
matching start or end date-time.
Notes and special cases: none
9.7.3 Changes in Equity presenta�on instant and dura�on type facts.
An effective presentation relationship base set that is recognized as representing a statement of changes is
a table with sets of rows having instant and duration-type elements on alternate lines.
Validations:
Check f On failure s EFM v68 Ref
For each date-time of instant facts in a statement of
No Matching
changes in equity, there is at least one duration fact with a 1 Durations W § 6.26.3
matching start or end date-time.
Notes and special cases:
2. A nil-valued duration fact will satisfy this check.
9.7.4 Text blocks containing embedding commands.
Facts of type “text block” having text content containing an embedding command must have valid
embedding command syntax. A text block fact may contain an Embedding Command. The following text
is an example of an embedding command:
~ http://xbrl.sec.gov/rr/role/ShareholderFeesData
column period compact *
row dei_LegalEntityAxis compact (eg_AaaMember, eg_BbbMember)
row rr_ProspectusShareClassAxis compact *
~

The beginning and ending “~” (tilde, ASCII hex 7E) indicate that the content of the enclosing element is
an embedding command. Any text appearing before the first or after the second tilde is ignored.
An embedding command consists of one role URI followed by zero or more iterators. Each iterator
consists of case-sensitive tokens separated by whitespace.
Any token with “_” (underscore, ASCII hex 5F) must denote an element. The text before the first
underscore is the element preferred namespace prefix as defined in 7.2 above. The string after the first
underscore must be nonempty and must be the element local name.

127
Validations:
Check f On failure s EFM v68 Ref
Embedding Command
The first token of an iterator must be row or column. Malformed Direction E § 6.26.4
Token
The second token of an iterator is one of period,
Embedding Command
unit, primary, or a token with an underscore that Malformed Axis E § 6.26.4
denotes an Axis as defined in 6.4 above.
Embedding Command
The third token is the word compact. Malformed Style E § 6.26.4
Token
The fourth token is either * meaning all, a token with
Embedding Command
an underscore that denotes a domain member, or a Malformed Member E § 6.26.4
parenthesized list of domain members.
The domain members are presentation descendants
Embedding Command
of the axis, in the presentation relationships of the 1 Invalid Member E § 6.26.4
role URI used to display the facts.
Notes and special cases:
1. A role URI having no presentation relationships would signal this error.
9.7.5 Rows and columns both required.
An embedding command must have at least one row iterator and one column iterator, either explicit or
defaulted. Embedding results in a different layout than the default layout of non-embedded reports. In an
embedding command, the primary axis is on the rows by default and all other axes are the default
columns (prior to transposition, which reverses rows and columns).
Validations:
Check f On failure s EFM v68 Ref
The embedding command contains both Embedding Command Missing
1 Iterator W § 6.26.5
row and column iterators.
The embedding command contains both Embedding Command Missing
Iterator After
row and column iterators after applying the 1 Transposition W § 6.26.5
{Transpose} token.

Notes and special cases:

2. The warning message should indicate whether the missing iterator is column or row.
9.7.6 Completeness of axes in an embedding command.
An embedding command and the effective presentation relationship base set designated by its role URI
should together provide an ordering of row axes and column axes for all facts it displays. The order of
axes displayed on rows and the axes displayed on columns first considers the order of iterators in the
embedding command. Then, for axes not named in the embedding command but used in the contexts of
facts to be displayed, axis ordering is determined by the effective presentation relationship base set whose
role URI is that of the embedding command.

128
Validations:
Check f On failure s EFM v68 Ref
If an axis is used in the context of facts that are selected from
Axis Has No
an embedding command, then the axis appears in the 1 Order W § 6.26.6
presentation group named by the command role URI.
Notes and special cases:
3. The axes will be sorted by their labels.
9.7.7 Bar Chart selected Annual Return facts
Embedding commands for bar charts are limited to AnnualReturn facts (6.22.2 above).
Validations:
Check f On failure s EFM v68 Ref
If the role URI of an embedding command contains the
Bar Chart Has
case-insensitive substring BarChart, then it contains at 1 No Facts W § 6.26.7
least one AnnualReturn fact.
If the role URI of an embedding command contains the
Too Many
case-insensitive substring BarChart, then it contains no
1 Annual Return E § 6.26.8
more than twenty AnnualReturn facts that are not Facts
duplicates.
Notes and special cases:
4. The row and column iterators define a set of Annual Return facts.
9.7.8 The {Elements} token implies "column primary" embedding.
The layout qualifier {Elements} forces the primary axis to be displayed as rows.
Validations:
Check f On failure s EFM v68 Ref
An embedding command does not have both the token
Primary Axis
{Elements} in the definition text of its URI, and an iterator On Rows W § 6.26.9
with direction token column and axis token primary.
Notes and special cases: none.
9.8 Namespace-specific Customiza�ons
In general, concepts having a namespace starting with http://xbrl.sec.gov/xyz/ may be termed
“XYZ concepts” and may impose various restrictions on custom arcs involving them, including:
• Only overrides: Custom arcs with XYZ elements as source and target must have the same role, arc
role, source, and target as an arc in the standard taxonomy, subject to all other validations. In effect
such custom arcs must appear in pairs that together prohibit and override existing relationships having
priority less than 10, thereby altering only values of arc attributes such as order.
• Only new domain members: If an arc has a specific role and/or arc role and the target concept is a
domain member, then the source element must be one of a few specific XYZ elements or a
descendant thereof with the same role and arc role.
• No XYZ sources or targets: XYZ concepts must not appear as the source or target of any custom arc,
except as an override of an existing arc or addition of a new domain member.
129
9.8.1 CEF Customiza�on
(Formerly EFM v68 § 6.12.10) Concepts having a namespace starting with http://xbrl.sec.gov/cef/
are “CEF concepts”.
Custom parent-child arcs with CEF Concepts as both source and target may only appear in role
http://xbrl.sec.gov/cef/role/N2 and must be valid overrides.

Custom parent-child arcs in role http://xbrl.sec.gov/cef/role/N2 with a target that is not a CEF
concept must have a domain member as target and have a source that is one of the Concepts in a standard
namespace: AllCoregistrantsMember, AllSecuritiesMember, AllRisksMember,
ClassOfStockDomain, DebtInstrumentNameDomain, or a parent-child descendant thereof.

In instance type RD.CEF (only) no other custom parent-child arcs with a CEF concept as source or
target are permitted in any role.
(Formerly EFM v68 § 6.14.6) No custom summation-item arc in any role may have a CEF concept as
either source or target.
(Formerly EFM v68 § 6.16.10) Custom domain-member arcs with CEF Concepts as both source and
target may only appear in role http://xbrl.sec.gov/cef/role/N2 and must be overrides.
Custom domain-member arcs with a CEF Concept as source must have link role
http://xbrl.sec.gov/cef/role/CorregistrantOnly,
http://xbrl.sec.gov/cef/role/SecurityOnly, or http://xbrl.sec.gov/cef/role/RiskOnly. The
target may be a domain member in any namespace.
No other custom arcs having arc roles starting with http://xbrl.org/int/dim/arcrole and any CEF
Concepts as source or target are permitted.
9.8.2 ECD Customiza�on
(Formerly EFM v68 § 6.14.8) Concepts having a namespace starting with http://xbrl.sec.gov/ecd/
are “ECD concepts”.
(Formerly EFM v68 § 6.14.9) No custom summation-item arc in any role may have an ECD concept as
either source or target.
(Formerly EFM v68 § 6.16.12) Custom domain-member arcs with ECD Concepts as both source and
target may only appear in roles with URI starting http://xbrl.sec.gov/ecd/role/ and ending with
Only. Such arcs must be overrides.

Custom domain-member arcs with ECD Concepts as source may only appear in roles with URI starting
http://xbrl.sec.gov/ecd/role/ and ending in Only. The target may be a domain member in any
namespace.
No other custom arcs having arc roles starting with http://xbrl.org/int/dim/arcrole/ and any ECD
Concept as source or target are permitted in any role.
9.8.3 FFD Customiza�on
Customization of EX-FILING FEES is not permitted.
9.8.4 OEF Customiza�on
(Formerly EFM v68 § 6.16.13) Concepts having a namespace starting with http://xbrl.sec.gov/oef/
are “OEF concepts”.

130
Other than instance type RD.OEF, no custom summation-item arc in any role may have an OEF concept
as either source or target.
Custom domain-member arcs with OEF Concepts as both source and target may only appear in roles with
URI starting http://xbrl.sec.gov/rr/role/ or http://xbrl.sec.gov/oef/role/ and ending with
Only. Such arcs must be overrides.

Custom domain-member arcs with OEF Concepts as source may only appear in roles with URI starting
http://xbrl.sec.gov/rr/role/ or http://xbrl.sec.gov/oef/role/ and ending in Only. The target
may be a domain member in any namespace.
No other custom arcs having arc roles starting with http://xbrl.org/int/dim/arcrole/ and any OEF
Concept as source or target are permitted in any role.
9.8.5 RXP Customiza�on
(Formerly EFM v68 § 6.14.10) Concepts in a namespace starting with http://xbrl.sec.gov/rxp/ are
“RXP concepts”.
A custom summation-item arc must not have a source or target RXP Concept in any role.
(Formerly EFM § 6.16.14) Custom domain-member arcs are restricted both with respect to RXP Concepts
and definition links with "RXP roles" (defined as role URIs starting with http://xbrl.sec.gov/rxp/).
The following RXP roles permit custom domain-member arcs with no targetRole attribute, the indicated
source concept (only), and target concept in a custom namespace.
Definition link role URI Permitted source concept
http://xbrl.sec.gov/rxp/role/ProjectsOnly rxp:AllProjectsMember
http://xbrl.sec.gov/rxp/role/GovernmentsOnly rxp:AllGovernmentsMember
http://xbrl.sec.gov/rxp/role/SegmentsOnly rxp:AllSegmentsMember
http://xbrl.sec.gov/rxp/role/EntitiesOnly dei:EntityDomain
http://xbrl.sec.gov/rxp/role/ResourcesOnly rxp:AllResourcesMember

Custom definition arcs must not appear in any other RXP role.
Custom definition arcs with arc roles starting http://xbrl.org/int/dim/arcrole/ in any role must not
have an RXP Concept as either source or target.
A member concept must not be the target of a domain-member arc in more than one RXP role.
9.8.6 VIP Customiza�on
(Formerly EFM v68 § 6.12.11) Concepts having a namespace starting with http://xbrl.sec.gov/vip/
are “VIP concepts”.
Custom parent-child arcs with VIP Concepts as both source and target may only appear in roles matching
regex http://xbrl.sec.gov/vip/role/N[346] and must be valid overrides.
Custom parent-child arcs in roles matching regex http://xbrl.sec.gov/vip/role/N[346], with a
target that is not a VIP Concept, must have a domain member as target or a parent-child descendant
thereof.
No other custom parent-child arcs with a VIP concept as source or target are permitted in any role.
(Formerly EFM v68 § 6.14.7) No custom summation-item arc in any link role may have a VIP concept as
either source or target.

131
(Formerly EFM v68 § 6.16.11) Custom domain-member arcs with VIP concepts as both source and target
may only appear in roles with URI starting http://xbrl.sec.gov/vip/role/ and ending with Only.
Such arcs must be overrides.
Custom domain-member arcs with VIP Concepts as source may only appear in roles with URI starting
http://xbrl.sec.gov/vip/role/ and ending in Only. The target may be a domain member in any
namespace.
No other custom arcs having arc roles starting with http://xbrl.org/int/dim/arcrole/ and any VIP
Concept as source or target are permitted in any role.
9.8.7 SRO Customiza�on
Concepts having a namespace URI matching .*sec.gov/sro/.* are “SRO concepts”.
Custom domain-member arcs with SRO concepts as source may only appear in roles with a URI matching
.*sec.gov/sro/([^/]*/)*role/[^/]*Only, and only as descendants of the default member of an SRO
concept explicit axis.
No other custom arcs having arc roles starting with http://xbrl.org/int/dim/arcrole/ and any SRO
Concept as source or target are permitted in any role.

10 Inline XBRL Restric�ons

Refer to EFM § 5.2.5, “Inline XBRL”, for restrictions specific to Inline XBRL attachments.

11 Tables from Filer Manual volume II Chapter 6

The tables are copied here for ease of reference and differ in no way from those in Edgar Filer Manual
version 69, volume II chapter 6.
Table 6-1. Submission Sets
Code Definition Submission Types
6K Report of FPI 6-K, 6-K/A
8-K, 8-K/A, 8-K12B, 8-K12B/A, 8-K12G3, 8-K12G3/A, 8-K15D5,
8K Current Report
8-K15D5/A
Annual 10-K, 10-K/A, 10-KT, 10-KT/A, 20-F, 20-F/A, 40-F, 40-F/A, N-CSR,
AF
Financial N-CSR/A, SP 15D2, SP 15D2/A
6-K/A, 8-K/A, 8-K12B/A, 8-K12G3/A, 8-K15D5/A, 10-K/A, 10-KT/A,
11-K/A, 11-KT/A, 20-F/A, 40-F/A, N-CSR/A, SP 15D2/A, N-CSRS/A,
17AD-27/A, SD/A#201, 424H/A, 10-Q/A, 10-QT/A, F-1/A, F-10/A, F-3/A,
AM Amending F-4/A, N-14 8C/A, S-1/A, S-11/A, S-3/A, S-4/A, S-6/A, SF-1/A, SF-3/A,
10-12B/A, 10-12G/A, 40FR12B/A, 40FR12G/A, SC 13E1/A, SC 13E3/A,
SC TO-I/A, SC TO-T/A, SC13E4F/A, SC14D1F/A, N-8B 2/A, N-1A/A,
N-2/A, N-3/A, N-4/A, N-6/A, SDR/A%KL
Employee
EBP Benefit Plan 11-K, 11-K/A, 11-KT, 11-KT/A
Annual

132
 Code Definition Submission Types
8-K, 8-K/A, 8-K12B, 8-K12B/A, 8-K12G3, 8-K12G3/A, 8-K15D5,
FAST Act
FAST 8-K15D5/A, 10-K, 10-K/A, 10-KT, 10-KT/A, 20-F, 20-F/A, 40-F, 40-F/A,
covered
10-Q, 10-Q/A, 10-QT, 10-QT/A
POS AM, F-1, F-1/A, F-10, F-10/A, F-10EF, F-1MEF, F-3, F-3/A, F-3ASR,
F-3D, F-3MEF, F-4, F-4/A, F-4MEF, N-14 8C, N-14 8C/A, N-14MEF, N-2,
N-2 POSASR, N-2/A, N-2ASR, N-2MEF, POSASR, S-1, S-1/A, S-11,
S-11/A, S-11MEF, S-1MEF, S-3, S-3/A, S-3ASR, S-3D, S-3MEF, S-4,
FE Fee Exhibit S-4/A, S-4EF, S-4MEF, S-8, SF-1, SF-1/A, SF-1MEF, SF-3, SF-3/A,
SF-3MEF, PREM14A, PREM14C, PRER14A, PRER14C, 424B1, 424B2,
424B3, 424B4, 424B5, 424B7, 424B8, 424H, 424H/A, 424I, SC 13E1,
SC 13E1/A, SC 13E3, SC 13E3/A, SC TO-I, SC TO-I/A, SC TO-T, SC
TO-T/A, SC13E4F, SC13E4F/A, SC14D1F, SC14D1F/A
Semi-annual
HF (half year) N-CSRS, N-CSRS/A
Financial
OA Other Annual 17AD-27, 17AD-27/A, SD%201, SD/A%201, SD#KL, SD/A#KL
424A, 424B1, 424B2, 424B3, 424B4, 424B5, 424B7, 424B8, 424H, 424I,
PRO Prospectus
425
DEF 14A, DEF 14C, DEFA14A, DEFA14C, DEFC14A, DEFC14C,
PX Proxy DEFM14A, DEFM14C, DEFR14A, DEFR14C, PRE 14A, PRE 14C,
PREC14A, PREC14C, PREM14A, PREM14C, PRER14A, PRER14C
Quarterly
QF 10-Q, 10-Q/A, 10-QT, 10-QT/A
Financial
F-1, F-1/A, F-10, F-10/A, F-10EF, F-1MEF, F-3, F-3/A, F-3ASR, F-3D,
F-3MEF, F-4, F-4/A, F-4MEF, N-14 8C, N-14 8C/A, N-14MEF,
33 Act POS AM#S1, POS AM#S3, POS462B#S1, POS462B#S1, POS462C#S1,
R33 Registration POS462C#S3, POSASR#F3, POSASR#S3, S-1, S-1/A, S-11, S-11/A,
Only S-11MEF, S-1MEF, S-3, S-3/A, S-3ASR, S-3D, S-3MEF, S-4, S-4/A,
S-4EF, S-4MEF, S-6, S-6/A, S-8, SF-1, SF-1/A, SF-1MEF, SF-3, SF-3/A,
SF-3MEF
10-12B, 10-12B/A, 10-12G, 10-12G/A, 40FR12B, 40FR12B/A, 40FR12G,
34 Act
40FR12G/A, SC 13E1, SC 13E1/A, SC 13E3, SC 13E3/A, SC TO-I, SC
R34 Registration
TO-I/A, SC TO-T, SC TO-T/A, SC13E4F, SC13E4F/A, SC14D1F,
Only
SC14D1F/A
40 Act
R40 Registration N-8B-2, N-8B-2/A
Only

133
 Code Definition Submission Types
485APOS#N1, 485APOS#N3, 485APOS#N4, 485APOS#N6,
485BPOS#N1, 485BPOS#N3, 485BPOS#N4, 485BPOS#N6, 485BXT#N1,
485BXT#N3, 485BXT#N4, 485BXT#N6, 486APOS#N2, 486BPOS#N2,
33 and/or 40
486BXT#N2, 497#N1, 497#N3, 497#N4, 497#N6, N-1A, N-1A/A, N-2,
RD Act (dual)
N-2 POSASR, N-2/A, N-2ASR, N-2MEF, N-3, N-3/A, N-4, N-4/A, N-6,
registration
N-6/A, POS 8C#N1, POS 8C#N2, POS 8C#N3, POS 8C#N4, POS 8C#N6,
POS AMI#N1, POS AMI#N2, POS AMI#N3, POS AMI#N4,
POS AMI#N6
Transitional
TF 10-KT, 10-KT/A, 10-QT, 10-QT/A, 11-KT, 11-KT/A
Financial

Table 6-2. Submission Set Suffixes

Suffix Meaning
#N1 The form is an N-1A.
#N2 The form is an N-2.
#N3 The form is an N-3.
#N4 The form is an N-4.
#N6 The form is an N-6.
#S1 The form is an S-1.
#S3 The form is an S-3.
#F1 The form is an F-1.
#F3 The form is an F-3.
%201 There is an Exhibit 2.01 in the submission.
%KL There is an exhibit K SDR or L SDR in the submission.

Table 6-3. Entity Sets

On failure Description
ALL Any registrant
BDC Business Development Company
CA Canadian Issuer
FPI Foreign Private Issuer
OEF Open-end Fund
CEF Closed-end Fund
V3 Separate Account Registered as Open-end Fund
V4 Variable Annuity UIT Separate Account
V6 Variable Life UIT Separate Account
RT Real Estate Investment Trust
SBS Security-based Swap Execution Facility
SDR Security-based Swap Data Repository
SF Structured Finance Company
SRO Self-regulatory Organization
UIT Unit Investment Trust
US US Operating Company

134
 Table 6-4. Instance Types
Submission Included Excluded Instance
Set Entity Set Entity Sets Exhibit Type Type
6K FPI 6K.FPI
8K ALL 8K.A
AF BDC AF.BDC
AF CA AF.CA
AF CEF AF.CEF
AF FPI AF.FPI
AF OEF AF.OEF
AF US AF.US
EBP ALL EBP.A
FE ALL EX-FILING FEES FE.A
HF OEF HF.OEF
OA FPI EX-2.01 RXP.FPI
OA SDR EX-99.L SDR L.SDR
OA SRO OA.SRO
OA US EX-2.01 RXP.US
OA SDR EX-99.K SDR K.SDR
PRO ALL CEF PRO.ANC
PRO CEF PRO.CEF
PX ALL PX.A
QF BDC QF.BDC
QF US QF.US
R33 FPI R33.FPI
R33 RT R33.RT
R33 UIT R33.UIT
R33 US R33.US
R34 CA R34.CA
R34 FPI R34.FPI
R34 US R34.US
R40 UIT R40.UIT
RD CEF RD.CEF
RD OEF RD.OEF
RD V3 RD.V3
RD V4 RD.V4
RD V6 RD.V6

Table 6-5. Standard Taxonomies on xbrl.sec.gov

Abbreviation Taxonomies on xbrl.sec.gov Guide
cef Closed-end Fund yes
country Country (ISO 3166-1)
currency Currency (ISO 4217)
dei Document and Entity Information
ecd Executive Compensation Disclosure yes

135
 Abbreviation Taxonomies on xbrl.sec.gov Guide
exch Exchanges (ISO 10383 MIC)
ffd Filing Fee Disclosures yes
fnd Funds yes
naics North American Industry Classification System
oef Open-end Fund yes
rr Risk/Return (Deprecated as of 2023) yes
rxp Resource Extraction Payments yes
sic Standardized Industrial Codes
snj Subnational Jurisdiction (ISO 3166-2) yes (in rxp guide)
sro Self-regulating Organizations yes
stpr States and Provinces
vip Variable Insurance Products yes

Table 6-6. Standard Taxonomies not on xbrl.sec.gov

Abbreviation Taxonomies located elsewhere Guide
ifrs International Financial Reporting Standards yes
ebp (or us-gaap-ebp) Employee Benefit Plan Financial Reporting yes
srt SEC Reporting yes
us-gaap US GAAP Financial Reporting yes

Table 6-7. Instance Types Mapped to Entry Points

Instance Instance Entry Point
Type Types Required (Exactly Entry Points Permitted
Included Excluded one of) (Any or all)
dei-sub, dei-lab, dei-def, dei-pre, cef,
ALL FE.A dei 1 cef-pre, country, country-def, currency,
exch, naics, sic, snj, sro, srt, stpr
6K.FPI dei 2 us-gaap, ifrs
8K.A dei us-gaap
AF.BDC us-gaap cef
AF.CA us-gaap, ifrs 2 us-gaap, ifrs, ecd
AF.FPI us-gaap, ifrs 2 us-gaap, ifrs, ecd
AF.CEF us-gaap 2 cef, ifrs
AF.OEF oef-sr
AF.US us-gaap ifrs, ecd
EBP.A ebp
FE.A ffd 3
HF.OEF oef-sr
K.SDR us-gaap
L.SDR us-gaap
PRO.A dei 2 us-gaap, ifrs, ecd
PRO.CEF dei cef, us-gaap, ecd
PXY.A dei us-gaap, ifrs, ecd
QF.BDC us-gaap 2 cef, ecd
QF.US us-gaap ecd, ifrs
136
 Instance Instance Entry Point
Type Types Required (Exactly Entry Points Permitted
Included Excluded one of) (Any or all)
R33.FPI dei us-gaap, ifrs
R33.UIT fnd-uit
R33.US us-gaap
R34.CA dei 2 us-gaap, ifrs
R34.FPI dei 2 us-gaap, ifrs
R34.US us-gaap ifrs
R40.UIT fnd-uit
RD.CEF cef, fnd-cef
RD.OEF fnd-oef, oef-rr, rr 4
RD.V3 vip-n3
RD.V4 vip-n4
RD.V6 vip-n6
RXP.FPI rxp 3
RXP.US rxp 3

Table 6-8. Instance Type – Attachment Types and Acceptable Formats

Included Excluded
Instance Instance Inline XBRL Processed xBRL-XML
Types Types Suffix attachment as IXDS attachment
FE.A .htm EX-FILING FEES No -
US.RXP,
.xml - - EX-2.01.INS
FPI.RXP
K.SDR .xml - - EX-99.K SDR.INS
L.SDR .xml - - EX-99.L SDR.INS
FE.A, K.SDR,
The primary document
L.SDR,
ALL .htm and exhibits other than Yes -
RXP.US,
EX-FILING FEES
RXP.FPI

Table 6-9. Instance Type – Consequences of XBRL Errors

Included Excluded Instance
Instance Types Types Consequences of XBRL Errors in the Instance
FE.A See EFM v68 § 7.1.
K.SDR, L.SDR Suspend.
Remove EX-2.01.INS and EX-2.01.SCH file attachments.
RXP.US,
If there are no other exhibits in the submission, then
RXP.FPI
suspend.
FE.A, K.SDR, L.SDR, Remove all attachments in the Inline XBRL Document
ALL
RXP.US, RXP.FPI Set. If that included the primary document, then suspend.

137