# Prepared by SEC Staff > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/agency%3Asec%3Aa23fe49809c43242 ## Record - **Collection:** Agency decision - **Document type:** Agency decision ## Text 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 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.1.9 3.1.10 3.1.11 3.1.12 3.1.13 3.1.14 3.1.15 3.1.16 3.1.17 3.1.18 3.1.19 3.1.20 3.1.21 3.1.22 3.1.23 3.1.24 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3 Expected Facts in the Required Context ........................................................................................ 12 Notation and Terminology ............................................................................................................. 12 Required Context validation .......................................................................................................... 13 Central Index Key .......................................................................................................................... 14 Registrant Name ............................................................................................................................ 14 Form or Exhibit Type..................................................................................................................... 15 Amendment Flag and Description ................................................................................................. 16 Document Period End Date ........................................................................................................... 17 Document Fiscal Year and Period Focus ....................................................................................... 18 Current Reporting Status and Interactive Data Current ................................................................. 19 Voluntary Filers, Shell Companies, and Well-known Seasoned Issuers ................................... 19 Small Business, Emerging Growth Company ........................................................................... 21 Current Fiscal Year End Date .................................................................................................... 22 Filer Category (Accelerated / Non-Accelerated) ....................................................................... 23 ICFR Auditor Attestation Flag .................................................................................................. 24 Public Float................................................................................................................................ 25 Auditor Name, Location, and Firm ID ...................................................................................... 25 Investment Company Type........................................................................................................ 27 File Number (Securities Act File Number) ............................................................................... 28 Incorporation State / Country Code ........................................................................................... 28 Tax Identification Number ........................................................................................................ 28 Primary SIC (Standard Industrial Code) Number ..................................................................... 29 Principal Office Address ........................................................................................................... 29 Submission Flags ....................................................................................................................... 32 Closed-end fund registration ..................................................................................................... 37 Expected Facts with Dimensions ................................................................................................... 43 Business contact ............................................................................................................................. 45 Former address ............................................................................................................................... 48 Common Stock Shares Outstanding .............................................................................................. 50 Registered Securities...................................................................................................................... 51 Open-end Fund Series .................................................................................................................... 54 Open-end Fund Shareholder Reports ............................................................................................. 54 Resource Extraction Payments Disclosure .................................................................................... 56 Currency and Total Payments ........................................................................................................ 56 Payments Axis ............................................................................................................................... 56 Boolean, Numeric and String Valued Facts ................................................................................... 56 Member-valued Facts..................................................................................................................... 57 Payment Contexts .......................................................................................................................... 58 3.3.6 3.3.7 Government Aggregate Contexts ................................................................................................... 60 Project Aggregate Contexts ........................................................................................................... 61 4 FILING FEE EXHIBITS ................................................................................................... 61 5 CUSTOM TAXONOMIES ................................................................................................ 82 4.1 4.1.1 4.1.2 4.1.3 4.2 4.3 4.4 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.5.7 4.5.8 4.5.9 4.5.10 4.6 4.6.1 4.6.2 4.6.3 4.7 4.7.1 4.7.2 4.8 4.8.1 4.8.2 4.8.3 5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.4.3 5.5 5.5.1 5.5.2 4 Filing Fee Inline XBRL Attachments ............................................................................................ 61 Security Types Based on Rule ....................................................................................................... 62 Offering & Transaction Valuation Rules Applicable for Submission Types ................................ 62 Offset Table & Combined Prospectus Rules Applicable for Submission Types ........................... 64 Submission Table ........................................................................................................................... 66 Fees Summary Table...................................................................................................................... 67 Offering Table................................................................................................................................ 69 Offering Table Rule Flags ............................................................................................................. 69 Rule 457(a) Lines........................................................................................................................... 69 Rule 457(o) Lines .......................................................................................................................... 70 Rule 457(r) Lines ........................................................................................................................... 71 Rule 457(s) Lines ........................................................................................................................... 72 Rule 457(u) Lines .......................................................................................................................... 73 Rule “Other” Lines ........................................................................................................................ 74 Rule 415(a)(6) Lines ...................................................................................................................... 75 Rule 0-11 Lines .............................................................................................................................. 76 Rule 457(f) Lines ........................................................................................................................... 77 General Instructions II.H (Exchange Offers) and II.I (Business Combinations)....................... 78 Offset Table ................................................................................................................................... 78 Offset Table Rule Flags ................................................................................................................. 78 Rule 457(b) or 0-11(a)(2)) Lines ................................................................................................... 78 Rule 457(p) Lines .......................................................................................................................... 79 Combined Prospectus Table .......................................................................................................... 80 Combined Prospectus Table Rule Flags ........................................................................................ 80 Combined Prospectus Lines Specifying Rule 429 ......................................................................... 80 Securities, 424I .............................................................................................................................. 81 Securities, 424I Table Rule Flags .................................................................................................. 81 Submission Type 424I Table Lines ............................................................................................... 81 Submission Type 424I Entries in the Submission Table ............................................................... 82 Custom presentation and label relationships for standard concepts............................................... 83 File attachments for custom relationships...................................................................................... 83 Custom presentation and label relationships.................................................................................. 83 Custom relationships for standard concepts, with dimensions ...................................................... 84 File attachments for custom members ........................................................................................... 84 Dimensional relationships.............................................................................................................. 85 Presentation and label relationships ............................................................................................... 87 Validation of custom relationships ................................................................................................ 87 Validations resulting in Errors ....................................................................................................... 87 Validations resulting in Warnings ................................................................................................. 88 5.6 5.6.1 5.6.2 5.6.3 5.6.4 5.7 5.8 5.8.1 5.9 5.9.1 5.9.2 5.9.3 5.10 5.10.1 5.10.2 5.10.3 5.10.4 5.10.5 5.10.6 5.11 5.11.1 5.11.2 5.11.3 5.11.4 5.12 6 6.1 6.2 6.3 6.3.1 6.3.2 6.3.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 5 Custom Concept Declarations in General ...................................................................................... 88 Do not duplicate pre-existing concept declarations ....................................................................... 88 Avoid changes in declarations from period to period .................................................................... 89 Custom concept naming................................................................................................................. 89 Custom concept declarations ......................................................................................................... 89 Custom Domain Member Declarations.......................................................................................... 89 Custom Presentation and Label Relationships ............................................................................... 91 Instance type 8K.A example – custom members ........................................................................... 91 Custom Calculation Relationships for Standard Concepts ............................................................ 91 When calculation relationships are required .................................................................................. 93 Avoid calculation relationship redundancy.................................................................................... 93 A single concept may have alternate calculations ......................................................................... 94 Custom Numeric Concepts ............................................................................................................ 94 Do not duplicate numeric concepts ........................................................................................... 94 Monetary concepts..................................................................................................................... 94 Share (unit of ownership) type concepts ................................................................................... 95 Per-share type concepts ............................................................................................................. 95 Pure number type concepts ........................................................................................................ 96 Percent type concepts ................................................................................................................ 96 Custom Non-Numeric Concepts .................................................................................................... 96 Custom Non-member Abstract concepts ................................................................................... 96 Custom text block type concepts ............................................................................................... 96 Custom dimensional concepts ................................................................................................... 97 Other custom non-numeric types............................................................................................... 97 Other custom taxonomy components............................................................................................. 98 INSTANCE RENDERING ................................................................................................ 98 Motivation for Standardized Rendering......................................................................................... 98 Presentation groups ........................................................................................................................ 99 Fact selection ................................................................................................................................. 99 Period Selection ........................................................................................................................... 100 Unit Selection .............................................................................................................................. 100 The Primary Axis ......................................................................................................................... 100 Basic Layout using Core and Taxonomy-Defined Dimensions ................................................... 100 Ordering members along a dimension ......................................................................................... 101 Merged columns .......................................................................................................................... 102 Period Start labels ........................................................................................................................ 102 Column Headings and Promotion ................................................................................................ 103 Row Headings and Promotion ..................................................................................................... 103 Footnotes and Merging ................................................................................................................ 103 Flow Through Suppression on Statements................................................................................... 104 Cash Flow Statements .................................................................................................................. 104 Statements of Changes in Shareholder Equity ............................................................................. 104 Layout Qualifiers ......................................................................................................................... 105 Uncategorized Facts ..................................................................................................................... 106 6.16 6.17 6.18 6.19 6.20 6.21 6.22 6.22.1 6.22.2 Numeric Formatting ..................................................................................................................... 106 Non-numeric Formatting ............................................................................................................. 106 The Filing Summary .................................................................................................................... 107 Multiple Instances ........................................................................................................................ 108 Workbook Output ........................................................................................................................ 108 Resource Extraction Payment Rendering .................................................................................... 108 Rendering of Mutual Fund Risk/Return Summary Interactive Data ........................................... 109 Embedding Commands............................................................................................................ 109 Bar Charts ................................................................................................................................ 109 7 VALIDATION DETAILS ON ALL XBRL ATTACHMENTS ................................... 110 8 VALIDATION DETAILS ON XBRL INSTANCES ..................................................... 114 9 VALIDATION DETAILS ON CUSTOM TAXONOMIES.......................................... 120 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 8.1 8.1.1 8.1.2 8.1.3 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.7.1 9.7.2 9.7.3 6 File names and character encodings............................................................................................. 110 Standard namespace prefixes ....................................................................................................... 111 Standard locations ........................................................................................................................ 112 Compatible Taxonomies .............................................................................................................. 112 Elements....................................................................................................................................... 113 Element attributes ........................................................................................................................ 113 Element attribute values............................................................................................................... 114 Attribute value lengths ................................................................................................................. 114 XHTML Validations .................................................................................................................... 115 HTML restrictions on Text Block facts ....................................................................................... 115 HTML restrictions on XBRL footnotes ....................................................................................... 116 HTML restrictions on Inline XBRL ............................................................................................ 116 Labels ........................................................................................................................................... 116 Presentation .................................................................................................................................. 116 Footnote Links ............................................................................................................................. 116 Decimals ...................................................................................................................................... 117 Contexts ....................................................................................................................................... 117 Periods ......................................................................................................................................... 118 Units ............................................................................................................................................. 118 Non-US English Facts.................................................................................................................. 119 Duplicate facts ............................................................................................................................. 119 Custom namespace and role URIs ............................................................................................... 120 Roles ............................................................................................................................................ 121 Concepts....................................................................................................................................... 122 Relationships ................................................................................................................................ 123 Concept types and relationships................................................................................................... 125 Concept labels and roles .............................................................................................................. 125 Rendering validations .................................................................................................................. 126 Each axis that is presented requires at least one child element. ................................................... 126 Matching instant and duration facts ............................................................................................. 127 Changes in Equity presentation instant and duration type facts. ................................................. 127 9.7.4 9.7.5 9.7.6 9.7.7 9.7.8 9.8 9.8.1 9.8.2 9.8.3 9.8.4 9.8.5 9.8.6 9.8.7 Text blocks containing embedding commands. ........................................................................... 127 Rows and columns both required. ................................................................................................ 128 Completeness of axes in an embedding command. ..................................................................... 128 Bar Chart selected Annual Return facts ....................................................................................... 129 The {Elements} token implies "column primary" embedding. ................................................... 129 Namespace-specific Customizations............................................................................................ 129 CEF Customization ...................................................................................................................... 130 ECD Customization ..................................................................................................................... 130 FFD Customization ...................................................................................................................... 130 OEF Customization...................................................................................................................... 130 RXP Customization ..................................................................................................................... 131 VIP Customization ....................................................................................................................... 131 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 computerreadable 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 dimensiondefining 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: • • • 10 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 • 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: … 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: 12 • 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; • 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 i: ALL Excl c r Check A {1} fact is present. f On failure {1} Missing s E EFM v68 Ref § 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 The CIK of any one company in the submission header The period of the submission header 13 # Type or regex Meaning {1} \d{1,10} EDGAR CIK {2} \d{1,2}-\d{1,2}-\d{4} Reporting period if present The filing date of the submission {3} Filing date, which may be the same or later than the acceptance date. \d{1,2}-\d{1,2}-\d{4} Validations: Incl Excl c Check All contexts have an identifier element value i:ALL equal to {1}. There is a context having endDate value i:ALL matching either {2} or {3}, and no segment element. f On failure s Non Matching Cik Required Context EFM v68 Ref § 6.5.3 E § 6.5.19 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 i: ALL c Assertion r i: K.SDR, L.SDR r i: K.SDR, L.SDR i: ALL r f A {1} fact is present. A {1} fact with value a full ten-digit CIK from among the co-registrants in the submission header or equal to 0000000000. A {1} fact with value a full ten-digit CIK other than 0000000000 from among the co-registrants in the submission header. On failure {1} Missing {1} Value {1} 1 Value s EFM v68 Ref E § 6.5.21 X* E § 6.5.23 E § 6.5.23 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 i: ALL r A {1} fact is present. i: ALL r A value of {1} matches the EDGAR conformed name of the company whose CIK is. s: FAST r i: AF.CA, AF.FPI, R33.FPI, R34.FPI r i: AF.CA, AF.FPI, r R33.FPI, R34.FPI i:ALL If {1} facts are present, then at least one is visible. If no {1} fact with xml:lang value en-US matches, then a matching {1} fact with a language not starting with en- is present. The matching {1} fact has xml:lang value en-US. f On failure {1} Missing s EFM v68 Ref E § 6.5.21 X, X* 1, {1} Submission E 2 Value 3 § 6.5.24 X {1} in Facts Not Visible W § 6.5.21 X*, 6.5.45 X - E § 6.5.24 {1} Submission Value E § 6.5.24 X 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 # dei:DocumentType {1} Validations: 15 Type or regex Meaning (Up to 20 characters) Form or Exhibit Type (often differs from the submission type). [A-Z0-9]+([/A-Z0-9 \.\]*[A-Z0-9])?|Other Incl Excl c Check f i:ALL FE r A {1} fact is present. i:ALL FE r The {1} fact value is among the Form types permitted for the submission type as shown in EFM § 3. i:FE r A {1} fact is absent. On failure 1, 2, 3 s EFM v68 Ref E § 6.5.20 X* {1} Value E § 6.5.20 {1} Unexpected W § 6.5.20 [] {1} Missing 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 investmentCompanyType, with or without a warning (previously § 6.5.56). Submission types 485APOS, 485BPOS 485APOS, 485BPOS 485APOS, 485BPOS 485APOS, 485BPOS, 485BXT POS AM, POS EX POS AM, POS EX POS AM, POS EX POS AM, POS EX POS AM, POS EX POS AM, POS EX POS AM, POS EX All other cases Value of dei:DocumentType N-3 N-4 N-6 Not N-3, not N-4 and not N-6 Matches POS.* Matches POS.* Matches POS.* Matches POS.* Matches POS.* Matches POS.* Matches POS.* Value of investmentCompanyType S-1 or S-3 N-1A N-2 N-3 N-4 N-6 (absent) Inferred entity sets V3 V4 V6 Inferred submission sets [§ 6.1] [§ 6.1] [§ 6.1] OEF [§ 6.1] W US OEF CEF V3 V4 V6 US RD RD RD RD RD RD R33 [§ 6.1] W W W W W W W Severity W W W 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 dei:AmendmentFlag dei:AmendmentDescription Validations: 16 # Type or regex Meaning Value is true if the content of an instance changed from a previous submission that this amends, and false otherwise. This is not the same as the “/A” indicator on {1} xs:boolean an EDGAR submission type; it is possible for an “/A” submission to amend only material that was not XBRL tagged content. {2} xs:string A description of the changes in the amendment. Incl i: ALL i: FE.A Excl i: FE.A c Check f On failure {1} Missing r A {1} fact is present. {1} Unexpected r A {1} fact is absent. If a {1} fact with value true is {1} {2} Value r present, then a {2} fact is Dependency present. {1} {2} Value r If a {1} fact with value false is Dependency present, then a {2} fact is absent. i: ALL i: ALL i: ALL i: FE.A, OA.RXP, OA.SDR r If {2} is present, it is visible. {2} in Facts Not Visible s EFM v68 Ref W § 6.5.20 R* W § 6.5.20 [] W § 6.5.20 A W § 6.5.20 A W § 6.5.20 A Notes and special cases: none. 3.1.7 Document Period End Date Concept dei:DocumentPeriodEndDate # Type or regex Meaning Many EDGAR submission types have a header field periodOfReport. For most of these, it represents the end {1} xs:date 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 s: 8K s: FAST, AF.OEF, HF.OEF s: FAST, AF.OEF, HF.OEF s: 6K, i: OA.SDR s: RD, R33, R34, R40 17 s: 8K c Check f On failure s EFM v68 Ref r A {1} fact is present. 1 {1} Missing r A {1} fact is present. 2 {1} Missing W § 6.5.20 R r If {1} facts are present, then at least one is visible. {1} in Facts Not Visible W § 6.5.45 R r A {1} fact is present. 3 A {1} fact is present. 4, 5 {1} Missing {1} Missing W § 6.5.20 R W § 6.5.20 R* W § 6.5.20 R*, O* Incl s: FAST, AF.OEF, HF.OEF, 6K, R33, R34, R40, 6K, RD, R33, R34, R40, i: OA.SDR s: ALL Excl c Check r f If the submission header field periodOfReport is present, then its date matches the value of On failure s EFM v68 Ref {1} Value W § 6.5.40 Case (2) {1} Unexpected W § 6.5.20 [], O* {1}. s: FAST, AF.OEF, HF.OEF, 6K, R33, R34, R40, r 6K, RD, R33, R34, R40, i: OA.SDR A {1} fact is absent. 5 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 # dei:DocumentFiscalPeriodFocus {2} dei:DocumentFiscalYearFocus {1} Type or regex xs:gYear (matches YYYY) Q1|Q2|Q3|FY Meaning Filer’s fiscal year. Fiscal period of the report. Validations: Incl s: AF Excl i: AF.OEF s: ALL c Check r A {1} fact is present. On failure {1} Missing r {1} {2} Mutual Neither or both {1} and 1 Dependency {2} are present. s: ALL s: FAST, R33, R34 r A {1} fact is absent. s: AF i: AF.OEF r A {2} fact is present. s: ALL s: FAST, R33, R34 r A {2} fact is absent. Notes and special cases: 1. Waived for submission types matching POS.*. 18 f 1 {1} Unexpected {2} Missing 1 {2} Unexpected s EFM v68 Ref W § 6.5.20 R* W § 6.5.20 Op* W § 6.5.20 [], Op* W § 6.5.20 R* W § 6.5.20 [], Op* 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 # dei:EntityCurrentReportingStatus dei:EntityInteractiveDataCurrent {1} {2} Type or regex Meaning Yes|No Registrant has (1) filed all reports required to be filed by Section 13 or 15(d) of the Securities Exchange Act of 1934 during the preceding 12 months (or for such shorter period that registrants were required to file such reports), and (2) have been subject to such filing requirements for the past 90 days. Yes|No The registrant has submitted electronically every Interactive Data File required to be submitted pursuant to Rule 405 of Regulation S-T during the preceding 12 months (or for such shorter period that the registrant was required to submit such files). Validations: Incl s: AF Excl i: AF.OEF s: AF i: AF.OEF c Check r A {1} fact is present. If {1} facts are present, r then at least one is visible. s: AF i: R34.CA, r R34.FPI i: AF.OEF r s: AF i: AF.OEF s: ALL i: R34.CA, r R34.FPI s: ALL r f On failure {1} Missing s EFM v68 Ref W § 6.5.21 R {1} in Facts Not Visible W § 6.5.21 R A {1} fact is absent. {1} Unexpected W A {2} fact is present. If {2} facts are present, then at least one is visible. {2} Missing A {2} fact is absent. § 6.5.21 [], O* W § 6.5.21 R {2} in Facts Not Visible W § 6.5.21 R {2} Unexpected W § 6.5.21 [], 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”. dei:EntityWellKnownSeasonedIssuer {2} Yes|No Registrant is a well-known seasoned issuer, as defined in Rule 405 of the Securities Act dei:EntityShellCompany {3} xs:boolean Registrant is a shell company as defined in Rule 12b-2 of the Exchange Act Validations: 19 Incl Excl i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.FPI i: AF.US, AF.BDC, AF.FPI s: ALL i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.BDC, AF.FPI s: ALL i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.BDC, AF.FPI i: AF.US, AF.BDC, AF.FPI c Check s EFM v68 Ref A {1} fact is present. {1} Missing W § 6.5.21 R If {1} facts are present, then at least one is visible. If header element voluntaryFilerFlag has a value, then it is equivalent to the {1} fact value. {1} in Facts W § 6.5.45 R {1} Value W A {1} fact is absent. {1} Unexpected W § 6.5.21 [] r A {2} fact is present. {2} Missing W § 6.5.21 R r If {2} facts are present, then at least one is visible. {2} in Facts Not Visible W § 6.5.45 R r If header element wellKnownSeasonedIssuerFlag has a value, then it is equivalent to the {2} fact value. {2} Value W A {2} fact is absent. {2} Unexpected W § 6.5.21 [] r A {3} fact is present. {3} Missing W § 6.5.21 R r If {3} facts are present, then at least one is visible. {3} in Facts Not Visible W § 6.5.45 R shellCompanyFlag has a value, then it is equivalent to the {3} fact {3} Value W A {3} fact is absent. {3} Unexpected W § 6.5.21 [] r r r i: AF.US, AF.BDC, r AF.FPI i: AF.US, AF.BDC, r AF.FPI Not Visible If header element r value. s: ALL i: AF.US, AF.BDC, r AF.FPI s: ALL a At most one of {1} and {2} has the value Yes or true. s: ALL a At most one of {2} and {3} has the value Yes or true. Notes and special cases: none. 20 f On failure {1} {2} Exclusive Value {2} {3} Exclusive Value § 6.5.40 Item 3 § 6.5.40 Item 4 § 6.5.40 Item 5 W § 6.5.21 WV W § 6.5.21 WS 3.1.11 Small Business, Emerging Growth Company Concept # dei:EntityEmergingGrowthCompany {2} xs:boolean Indicates a registrant that meets the emerging growth company criteria. dei:EntityExTransitionPeriod {3} xs:boolean Indicates an emerging growth company has elected not to use the extended transition period for complying with any new or revised financial accounting standards. dei:EntitySmallBusiness Type or regex Meaning Indicates that the company is a Smaller Reporting {1} xs:boolean Company (SRC). Validations: Incl i: AF.US, AF.BDC, AF.OEF, QF.US, R33.US, R34.US Excl i: AF.BDC i: AF.US, AF.BDC, AF.OEF, QF.US, R33.US, R34.US i: AF.US, AF.BDC, QF.US s: ALL s: FAST, i: R33.US, R33.FPI, R34 s: ALL 21 c Check f On failure s EFM v68 Ref r 1 {1} Missing W § 6.5.40 R, R* {1} Value W § 6.5.40 SB {1} Value W § 6.5.40 Item 9 {1} in Facts Not Visible W § 6.5.40 R § 6.5.45 r r i: AF.US, AF.BDC, AF.OEF, QF.US, R33.US, R34.US A {1} fact is present. A {1} fact with value true is absent. If header element smallBusinessFlag for the filer with the CIK of the required context, then a {1} fact is present with that fact value. 1 r If {1} facts are present, then at least one is visible. r A {1} fact is absent. 1 {1} Unexpected W § 6.5.40 [] r A {2} fact is present. 1 {2} Missing W § 6.5.40 R, R* 1 {2} Submission Value W § 6.5.40 Item 6 If there is a value for r emergingGrowthCompanyFlag in the header for the filer with the CIK of the required context, then a {2} fact is present with that value. Incl Excl s: FAST s: ALL s: FAST, R34, i: R33.US, R33.FPI, s: FAST, i: R33.US, R33.FPI, R34 s: FAST, i: R33.US, R33.FPI, R34 s: FAST s: ALL s: FAST, R34, i: R33.US, R33.FPI c Check If {2} facts are present, then r at least one is visible. f r 1 A {2} fact is absent. s {1} in Facts Not Visible EFM v68 Ref W § 6.5.40 R {2} Unexpected W § 6.5.40 [] If a {2} fact valued true is a present, then a {3} fact is present. {3} 1, {2} Value E 2 Dependency If a {2} fact does not have a value true, then a {3} fact is absent. {3} § 6.5.40 ET, 1, {2} Value W ET* 2 Dependency r If {3} facts are present, then at least one is visible. r A {3} fact is absent. § 6.5.40 ET § 6.5.40 ET, § 6.5.45 {3} Unexpected W 1 {3} Unexpected W § 6.5.40 [] 1 {3} Submission Value W If there is a value for exTransitionPeriodFlag s: ALL On failure in the header for the filer with the CIK of the required context, then a {3} fact is present with that value. r § 6.5.40 Item 7 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 # {1} dei:CurrentFiscalYearEndDate Type or regex xs:gMonthDay (matches --MM-DD) Meaning Month and day marking the end of the company’s fiscal year; it normally does not change from year to year. Validations: Incl s: AF, QF, 6K, i: K.SDR, L.SDR s: AF 22 Excl c Check f i: AF.OEF, AF.CEF r A {1} fact is present. 1 i: AF.OEF, AF.CEF r If {1} facts are present, then at least one is visible. On failure s {1} W § 6.5.21 R, R* Missing {1} in Facts Not Visible W EFM v68 Ref § 6.5.21 R § 6.5.45 Incl Excl s: 8K, AF, QF, 6K, i: K.SDR, L.SDR s: ALL s: AF, QF, 6K, i: R34.FPI, R34.CA, K.SDR, L.SDR c Check If {1} is present, and there is a value for fiscalYearEnd in the header for the filer r with the CIK of the required context, then the {1} fact is present with that value. r s: 8K r s: 8K r f On failure EFM v68 Ref {1} 2, Submission § 6.5.21 [], O*, W 3 Value § 6.5.40 Item 1 {1} A {1} fact is absent. If Item 5.03 is indicated in the header, then {1} is present. If Item 5.03 is not indicated in the header, then {1} is absent. s Unexpected W § 6.5.21 [], O* {1} 1, Submission W § 6.5.21 E503 2 Value {1} Unexpected W § 6.5.21 E503 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 --MMDD. 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 dei:EntityFilerCategory # Type or regex Meaning {1} (Large Accelerated|Accelerated|Nonaccelerated) Filer Accelerated Filer Status. Note that the possible values are case-sensitive, have spaces and a dash. Validations: Incl i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US i: AF.US, AF.BDC, QF.US, AF.FPI 23 Excl c Check f On failure s EFM v68 Ref r A {1} fact is present. 1 {1} Missing W § 6.5.21 R, R* r If {1} facts are present, then at least one is visible. {1} in Facts Not Visible W § 6.5.21 R § 6.5.45 Incl s: ALL Excl i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US c Check r i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US r i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US r i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US r i: AF.US, AF.BDC, QF.US, AF.FPI, R33.US, R34.US r An {1} fact is absent. If the value of acceleratedFilerStatus in the header for the filer with the CIK of the required context is Large Accelerated Filer, then a {1} fact value starting with Large Accelerated Filer is present. If the value of acceleratedFilerStatus in the header for the filer with the CIK of the required context is Accelerated Filer, then a {1} fact value starting with Accelerated Filer is present. If the value of acceleratedFilerStatus in the header for the filer with the CIK of the required context is neither Large Accelerated Filer nor Accelerated Filer, then a {1} fact is present in the required context with a value that starts with neither Large Accelerated Filer nor Accelerated Filer. If there is no acceleratedFilerStatus in the header for the filer with the CIK of the required context, then a {1} fact is absent. f On failure s EFM v68 Ref 1 {1} Unexpected W § 6.5.21 [] {1} § 6.5.40 Item 1 Submission W 10 Value {1} § 6.5.40 Item 1 Submission W 11 Value {1} § 6.5.40 Item 1 Submission W 12 Value 1 {1} Unexpected W § 6.5.40 Item 13 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 dei:EntityFilerCategory {1} (Large Accelerated|Accelerated|Nonaccelerated) Filer 24 Meaning Note that the possible values have spaces and a dash. dei:IcfrAuditorAttestationFlag {2} xs:boolean Validations: Incl i: AF.US, AF.BDC, AF.FPI r i: AF.US, AF.BDC, AF.FPI, AF.CA Check If the value of {1} is “Large Accelerated Filer” or “Accelerated Filer”, then a {2} fact is present. r If {2} facts are present in the required context, then at least one is visible. s: ALL Excl c i: AF.US, AF.BDC, AF.FPI, AF.CA a A {2} fact is absent. f On failure s EFM v68 Ref {2} Missing W § 6.5.21 Ra {2} in Facts Not Visible W § 6.5.45 Ra {2} Unexpected W § 6.5.21 [], O 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 # dei:EntityPublicFloat Type or regex Meaning A filer having no common shares outstanding will have {1} xs:decimal a $0 public float fact, not nil; debt and other tiers of 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 i: AF.US, AF.BDC Excl c i: AF.US, AF.BDC s: ALL i: AF.US, AF.BDC Assertion f On failure s EFM v68 Ref se A {1} fact is present. {1} Missing W § 6.5.21 R If {1} facts are se present, then at least one is visible. {1} in Facts Not Visible W {1} Unexpected W § 6.5.21 [] se A {1} fact is absent. § 6.5.21 R § 6.5.45 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 # dei:AuditorName {1} 25 Type or regex [\p{L}\p{N}].* up to 150 characters; \p{L} matches a single letter and \p{N} matches any kind of numeric character in any language. Meaning The plain text (not logo nor signature) name of the auditor dei:AuditorLocation {2} [\p{L}\p{N}].* up to 150 characters. City along with either or both of country, US state, or Canadian province dei:AuditorFirmId {3} [1-9]\d* an integer with no leading sign or The auditor’s Firm ID as assigned by the US PCAOB. zeroes. Validations: Incl i: AF.US, AF.BDC, AF.FPI, AF.CA Excl c Check f On failure s EFM v68 Ref s: AM r A {1} fact is present. 1 {1} Missing E § 6.5.21 H § 6.5.54 r If {1} facts are present in the required context, then at least one is visible. 2 {1} in Facts Not Visible W § 6.5.21 H § 6.5.54 s: ALL i: AF.US, AF.BDC, AF.FPI, AF.CA r A {1} fact is absent. 1 {1} Unexpected E § 6.5.21 [] i: AF.US, AF.BDC, AF.FPI, AF.CA s: AM r A {2} fact is present. 1 {2} Missing E § 6.5.21 H § 6.5.54 r If {2} facts are present in the required context, then at least one is visible. 2 {2} in Facts Not Visible W § 6.5.21 H § 6.5.54 s: ALL i: AF.US, AF.BDC, AF.FPI, AF.CA r A {2} fact is absent. 1 {2} Unexpected E § 6.5.21 [] i: AF.US, AF.BDC, AF.FPI, AF.CA s: AM r A {3} fact is present. 1 {3} Missing E § 6.5.21 H § 6.5.54 r If {3} facts are present in the required context, then at least one is visible. 2 {3} in Facts Not Visible W § 6.5.21 H § 6.5.54 i: AF.US, AF.BDC, AF.FPI, AF.CA i: AF.US, AF.BDC, AF.FPI, AF.CA i: AF.US, AF.BDC, AF.FPI, AF.CA 26 Incl Excl i: AF.US, AF.BDC, AF.FPI, AF.CA s: ALL c Check r A {3} fact is absent. If any of {1}, {2}, or a {3}, are present, then all three are present. s: ALL f On failure s EFM v68 Ref 1 {3} Unexpected E § 6.5.21 [] {2} {3} 1, {1} Mutual 3 Dependency E § 6.5.54 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 dei:EntityInvCompanyType {1} N-1A|N-1|N-2|N3|N-4|N-6|S-1 or S-3|S-6 Meaning Investment Company Type. Note that one of the possible values is the literal token S-1 or S-3, these are not alternative values. Validations: Incl s: RD s: ALL s: RD Excl s: RD c r r r Check A {1} fact is present. A {1} fact is absent. If header element invCompanyType for the filer with the CIK of the required context, then a {1} fact is present with that fact value. Notes and special cases: 1. Checks waived for submission types matching POS.*. 27 f 1 1 On failure {1} Missing {1} Value s W W EFM v68 Ref § 6.5.40 R* § 6.5.40 [] 1 {1} Value W § 6.5.40 Item 8 3.1.18 File Number (Securi�es Act File Number) Concept # Type or regex dei:EntityFileNumber {1} \d{1,3}-\d{1,8}(-.{1,4})? Meaning Securities (“33”) Act file number. Validations: Incl s: FAST s: ALL Excl s: FAST, 6K, i: R34.FPI, R34.CA c Assertion r A {1} fact is present. r A {1} fact is absent. f On failure {1} Missing {1} Unexpected s W W EFM v68 Ref § 6.5.47 Ri § 6.5.47 [], O* § 6.5.55 n2sn Notes and special cases: none. 3.1.19 Incorpora�on State / Country Code Concept # dei:EntityIncorporationStateCountryCode Type or regex Meaning Two-character EDGAR code. US States and Canadian provinces are represented by their postal code (e.g., WA, BC); other countries by a code matching [A-Z]\d. {1} [A-Z][A-Z0-9] Transformation ixt-sec:edgarprovcountry (EFM § 5.2.5.12) transforms the full names of countries and Canadian provinces to their EDGAR codes. Validations: Incl s: FAST Excl s: FAST s: ALL s: FAST, R33, R34 c Check r A {1} fact is present. If {1} facts are present, r then at least one is visible. r A {1} fact is absent. f On failure {1} Missing {1} in Facts Not Visible {1} Unexpected s EFM v68 Ref W § 6.5.47 Ri W § 6.5.47 Ri W § 6.5.47 [], O* Notes and special cases: none. 3.1.20 Tax Iden�fica�on Number Concept dei:EntityTaxIdentificationNumber # Type or regex Meaning Shown on forms as “IRS Employer {1} \d{2}-\d{7} ID”. Validations: Types Excl c Assertion f On failure s: FAST i: AF.CA r A {1} fact is present. {1} Missing s: FAST r If {1} facts are present, then at least one is visible. {1} in Facts Not Visible r A {1} fact is absent. {1} Unexpected s: ALL s: FAST, R34, i: AF.CA Notes and special cases: none. 28 s EFM v68 Ref § 6.5.47 Ri, W O § 6.5.47 Ri, W O § 6.5.47 [], W O* 3.1.21 Primary SIC (Standard Industrial Code) Number Concept # dei:EntityPrimarySicNumber {1} Type or regex \d{4} Meaning SEC-assigned Standard Industrial Code Validations: Incl Excl AF.CA s: ALL s: R34, i: AF.CA c Assertion If {1} are present, then r at least one is visible. r A {1} fact is absent. f On failure {1} in Facts Not Visible {1} Unexpected s EFM v68 Ref W § 6.5.47 O W § 6.5.47 [], 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 # dei:EntityAddressAddressLine1 dei:EntityAddressCityOrTown dei:EntityAddressPostalZipCode {1} {2} {3} Type or regex xs:normalizedString xs:normalizedString xs:normalizedString Meaning The first line of the address, the city or town, and postal or zip code, share identical checks. Validations: Incl Excl s: FAST s: FAST s: ALL s: FAST s: FAST, 6K, R34, R33 s: FAST s: ALL s: FAST r A {1} fact is absent. r A {2} fact is present. If {2} facts are present in the required context, then at least one is visible. r s: FAST, 6K, R34, R33 s: FAST s: ALL c Check r A {1} fact is present. If {1} facts are present in r the required context, then at least one is visible. r A {2} fact is absent. r A {3} fact is present. If {3} facts are present in the required context, then at least one is visible. r s: FAST, 6K, R34, R33 r f On failure A {3} fact is absent. {1} Missing {1} in Facts Not Visible 29 # {1} Type or regex xs:normalizedString § 6.5.48 [], O* W § 6.5.48 Ri W {2} in Facts Not Visible W § 6.5.48 Ri {2} Missing § 6.5.48 [], O* W § 6.5.48 Ri {2} Unexpected W {3} in Facts Not Visible W § 6.5.48 Ri {3} Missing {3} Unexpected 3.1.22.2 Street Address Lines 2 and 3 dei:EntityAddressAddressLine1 W § 6.5.48 Ri {1} Unexpected Notes and special cases: none. Concept s EFM v68 Ref W § 6.5.48 Ri Meaning W § 6.5.48 [], O* Concept # dei:EntityAddressAddressLine2 dei:EntityAddressAddressLine3 {2} {3} Type or regex xs:normalizedString xs:normalizedString Meaning 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: c Check f s: ALL If a {2} fact is a present, then a {1} fact is also present. 1 Dependency s: FAST, i: RD.CEF r If {2} facts are present, then at least one is visible. {2} in Facts Not Visible r A {2} fact is absent. {2} Unexpected W § 6.5.48 [] s: ALL If a {3} fact is a present, then a {2} fact is also present. {2} {3} Dependency s: FAST, i: RD.CEF r If {3} facts are present, then at least one is visible. {3} in Facts Not Visible § 6.5.48 OL2, OL2* § 6.5.51 OL2, OL2* W § 6.5.48 OL2 r A {3} fact is absent. {3} Unexpected W Incl s: ALL s: ALL Excl s: FAST, 6K, R34, i: RD.CEF, R33.US, R33.FPI s: FAST, 6K, R34, i: RD.CEF, R33.US, R33.FPI On failure {1} {2} s EFM v68 Ref § 6.5.48 OL1* W § 6.5.51 OL1* W § 6.5.48 O § 6.5.48 [], OL2* 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 dei:EntityAddressStateOrProvince dei:EntityAddressCountry # Type or regex Meaning Postal state or province. Inline XBRL transformations {1} [A-Z][A-Z] that convert state and province names to postal codes (e.g., TX, ON) shown in EFM § 5.2.5.12. ISO 3166-1 alpha 2 (IANA) country code. Inline XBRL {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 s: FAST, i: RD.CEF i: AF.FPI s: FAST, i: RD.CEF 30 c Check One or both {1} r and {2} facts are present. If {1} facts are r present, then at least one is visible. f Codes s {1} {2} W § 6.5.48 O2 1 Inclusive {1} in Facts Not Visible W EFM v68 Ref § 6.5.48 O, O2 Incl Excl i: AF.FPI s: FAST, i: RD.CEF s: ALL s: ALL s: FAST, R34, R33, i: RD.CEF s: FAST, 6K, R34, i: R33.US, R33.FPI c Check A {2} fact is r present. If {2} facts are r present, then at least one is visible. f Codes s EFM v68 Ref {2} Missing W § 6.5.48 Ri {2} in Facts Not Visible W § 6.5.48 O2, Ri r A {1} fact is absent. {1} Unexpected W § 6.5.48 [], O* r A {2} fact is absent. {2} Unexpected W § 6.5.48 [], O* EFM v68 Ref Notes and special cases: none. 3.1.22.4 Phone Concept dei:CityAreaCode dei:LocalPhoneNumber # {1} {2} Type or regex xs:normalizedString xs:normalizedString Meaning Validations: Types i: R34.US, R34.CA, R33.US, R33.FPI, AF.FPI, RD.CEF s: 8K, QF, i: AF.US, AF.BDC, RD.CEF, AF.CA s: 8K, QF, i: AF.US, AF.BDC, RD.CEF, AF.CA s: ALL s: 8K, QF, i: AF.US, AF.BDC, RD.CEF, AF.CA s: 8K, QF, i: AF.US, AF.BDC, RD.CEF, AF.CA 31 Excl s: 8K, QF, i: AF.US, AF.BDC, RD.CEF, AF.CA, R34.US, R34.CA, R33.US, R33.FPI c Check f On failure s Neither or both of a {1} a fact and a {2} fact is present. 1, 2 {1} {2} Dependency § 6.5.48 Oph*, W § 6.5.51 Oph, Oph* r A {1} fact is present. {1} Missing W § 6.5.48 Ri r If {1} facts are present, then at least one is visible. {1} in Facts Not Visible W § 6.5.48 Ri r A {1} fact is absent. {1} Unexpected W r A {2} fact is present. {2} Missing W § 6.5.48 Ri r If {2} facts are present, then at least one is visible. {2} in Facts Not Visible W § 6.5.48 Ri § 6.5.48 [], Oph* Types s: ALL Excl s: 8K, QF, i: AF.US, AF.BDC, RD.CEF, AF.CA, R34.US, R34.CA, R33.US, R33.FPI c Check r f A {2} fact is absent. On failure s EFM v68 Ref {2} Unexpected W § 6.5.48 [], O* 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 dei:DocumentAnnualReport dei:DocumentTransitionReport dei:DocumentShellCompanyReport dei:DocumentShellCompanyEventDate dei:DocumentQuarterlyReport # {1} {2} {3} {4} {5} Type or regex Meaning xs:boolean xs:boolean xs:boolean xs:date xs:boolean When certain of the above concepts are expected, only one can have the value true. Validations: Incl i: AF.US, AF.BDC, AF.CA s: TF, R34.FPI, R34.CA Excl c Check s: TF r A {1} fact valued true is present. {1} Value Missing W § 6.5.49 Y s: QF, EBP r A {1} fact valued false is present. {1} Value Missing W {1} {2} Value Dependency W § 6.5.49 TF3 {1} {3} Value Dependency W § 6.5.49 TF3 {2} {3} Value Dependency W § 6.5.49 TF3 {2} {3} Value Dependency W § 6.5.49 TF3 i: AF.FPI r i: AF.FPI r i: AF.FPI r i: AF.FPI r 32 If a {1} fact valued true is present, then a {2} fact valued false is present. If a {1} fact valued true is present, then a {3} fact valued false is present. If a {2} fact valued true is present, then a {1} fact valued false is present. If a {2} fact valued true is present, then a {3} fact valued false is present. f On failure s EFM v68 Ref § 6.5.49 N, N* Incl Excl i: AF.FPI i: AF.FPI i: AF.US, AF.BDC, AF.CA s: QF, i: AF.US, AF.BDC, AF.CA c Check If a {3} fact valued true is present, then r a {1} fact valued false is present. If a {3} fact valued true is present, then r a {2} fact valued false is present. If {1} facts are r present, then at least one is visible. r i: AF.FPI r R34.CA r s: ALL s: ALL s: QF, i: AF.US, AF.BDC, AF.CA, AF.FPI, R34.CA s: QF, i: AF.US, AF.BDC, AF.CA, AF.FPI {3} {2} Value Dependency W § 6.5.49 TF3 {1} in Facts Not Visible W § 6.5.49 Y, N, TF3 {2} in Facts Not Visible W § 6.5.49 Y, N, TF3 {3} in Facts Not Visible W § 6.5.49 TF3 {2} Value Unexpected W § 6.5.49 N* r A {2} fact is absent {2} Unexpected W § 6.5.49 [] {4} Value Dependency § 6.5.49 SR {4} Value Dependency § 6.5.49 SR i: AF.FPI r s: ALL i: AF.FPI r s: QF s: TF r s: TF s: AF, EBP r 33 W § 6.5.49 TF3 W § 6.5.49 [] r r Notes and special cases: none. {3} {2} Value Dependency {1} Unexpected i: AF.FPI s: QF EFM v68 Ref A {1} fact is absent. r s: ALL If {3} facts are present, then at least one is visible. A {1} fact valued false is present. s r i: AF.FPI s: QF If {2} facts are present, then at least one is visible. f On failure r If {3} valued true is present, then {4} is present. If {3} valued false is present, then {4} is absent. If {4} facts are present, then at least one is visible. A {4} fact is absent. A {5} fact valued false is present. A {5} fact valued true is present. If {5} facts are present, then at least one is visible. A {5} fact is absent. {4} in Facts Not Visible {4} Unexpected {5} Value Missing W § 6.5.49 SR W § 6.5.49 [] W § 6.5.49 N {5} Value Missing W § 6.5.49 Y {5} in Facts Not Visible W § 6.5.49 Y, N {5} Unexpected W § 6.5.49 [] 3.1.23.2 Financial Statement Error Correction, Recovery Analysis Concept dei:DocumentFinStmtErrorCorrectionFlag dei:DocumentFinStmtRestatementRecoveryAnalysisFlag # {1} {2} Type or regex Meaning Annual reports expect a flag indicating error xs:boolean correction. If error correction is true, then a flag xs:boolean indicating whether the restatement resulted in an analysis of compensation recovery. Validations: Incl Excl AF.US, AF.BDC, AF.FPI, AF.CA AF.US, AF.BDC, AF.FPI, AF.CA AF.US, s: ALL AF.BDC, AF.FPI, AF.CA AF.US, AF.BDC, AF.FPI, AF.CA AF.US, AF.BDC, AF.FPI, AF.CA AF.US, AF.BDC, AF.FPI, AF.CA AF.US, s: ALL AF.BDC, AF.FPI, AF.CA c Check f On failure s EFM v68 Ref r A {1} fact is present. {1} Missing W § 6.5.49 R r If {1} facts are present, then at least one is visible. {1} in Facts Not Visible W § 6.5.49 R r A {1} fact is absent. {1} Unexpected W § 6.5.49 [] {1} {2} Value Dependency W § 6.5.49 RT {1} {2} Value Dependency W § 6.5.49 RT {2} in Facts Not Visible W § 6.5.49 RT {2} Unexpected W § 6.5.49 [] If a {1} fact valued a true is present, then {2} is present. If a {1} fact valued a false is present, then {2} is absent. If {2} facts are r present, then at least one is visible. r A {2} fact is absent. 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 {2} xs:boolean DocumentAccountingStandard {3} U.S. GAAP|International Financial Reporting Standards|Other OtherReportingStandardItemNumber {4} Item (17|18) DocumentRegistrationStatement {5} xs:boolean AnnualInformationForm AuditedAnnualFinancialStatements 34 {1} xs:boolean Meaning Note that the values are case sensitive and contain spaces. Note that the values are case sensitive and contain spaces. Validations: Incl s: AF.CA Excl s: AF.CA c Check r A {1} fact is present. If {1} facts are present, then at r least one is visible. r A {1} fact is absent. s: AF.CA r s: AF.CA r A {2} fact is present. If {2} facts are present, then at least one is visible. s: ALL s: ALL s: AF.CA s: AF.CA r i: AF.FPI A {3} fact is present. If {3} facts are present, then at least one is visible. i: AF.FPI s: ALL A {2} fact is absent. i: AF.FPI, R34.FPI A {3} fact is absent. i: AF.FPI, R34.FP If a {3} fact valued Other is present, then {4} is present. i: AF.FPI, R34.FP If a {3} fact valued Other is absent, then {4} is absent. i: AF.FPI If {4} facts are present, then at least one is visible. s: ALL i: AF.FPI, AF.CA i: AF.FPI, AF.CA i: R34.CA, R34.FPI s: ALL i: AF.FPI, R34.FPI i: AF.FPI, AF.CA. R34.FPI, R34.CA A {4} fact is absent. If a {5} fact is present, it is valued false. If {5} facts are present, then at least one is visible. If a {5} fact is present, it is valued true. A {5} fact is absent. f On failure {1} Missing {1} in Facts Not Visible {1} Unexpected {2} Missing {2} in Facts Not Visible {2} Unexpected {3} Missing {3} in Facts Not Visible {3} Unexpected {3} {4} Value Dependency {3} {4} Value Dependency {4} in Facts Not Visible {4} Unexpected {5} Value Missing {5} in Facts Not Visible {5} Value Missing {5} Unexpected s EFM v68 Ref W § 6.5.49 Ri W § 6.5.49 Ri W § 6.5.49 [] W § 6.5.49 Ri W § 6.5.49 Ri W § 6.5.49 [] W § 6.5.50 Ri § 6.5.50 Ri § 6.5.50 [], O* § 6.5.50 Oth, W Oth* W W § 6.5.50 Oth, Oth* W § 6.5.50 Oth W § 6.5.50 [] W § 6.5.49 N W § 6.5.49 N W § 6.5.49 Y* W § 6.5.49 [] Notes and special cases: none. 3.1.23.4 Period Start Date Concept DocumentTransitionReport DocumentPeriodStartDate # {1} {2} Type or regex Meaning xs:boolean 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 If a {1} fact valued true is r present, then a {2} fact is present. r A {2} fact is present. If {2} facts are present, then at r least one is visible. i: AF.FPI s: TF s: TF, i: AF.FPI s: ALL s: TF, r i: AF.FPI f On failure {1} {2} Value Dependency {2} Missing {1} in Facts Not Visible {2} Unexpected A {2} fact is absent. s EFM v68 Ref W § 6.5.49 TR W § 6.5.49 Ri § 6.5.49 Ri, W TR W § 6.5.49 [] Notes and special cases: none. 3.1.23.5 Bankruptcy Proceedings Flag Concept EntityBankruptcyProceedingsCurrent # {1} Type or regex Meaning xs:boolean Validations: Incl s: QF, i: AF.US, AF.BDC, AF.FPI s: ALL Excl s: QF, i: AF.US, AF.BDC, AF.FPI, R33.FPI c Check If {1} facts are present, then at r least one is visible. r f On failure A {1} fact is absent. s EFM v68 Ref {1} in Facts Not Visible W § 6.5.49 O {1} Unexpected W § 6.5.49 [], O* 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 DocumentsIncorporatedByReferenceTextBlock # {1} Type or regex Meaning Text block (see 8.1.1 below) Validations: Incl Excl c Check i: AF.US, If {1} facts are present, then at r AF.BDC least one is visible. i: AF.US, s: ALL r A {1} fact is absent. AF.BDC f On failure {1} in Facts Not Visible {1} Unexpected s EFM v68 Ref W § 6.5.49 O W § 6.5.49 [] Notes and special cases: none. 3.1.23.7 Current Report Concept # Type or regex WrittenCommunications {1} xs:boolean {3} xs:boolean SolicitingMaterial PreCommencementTenderOffer 36 {2} xs:boolean Meaning Concept # Type or regex PreCommencementIssuerTenderOffer {4} xs:boolean {5} (e.g., “OLDCO Inc.”) EntityInformationFormerLegalOrRegisteredName Meaning xs:normalizedString Validations: Incl s: 8K Excl s: 8K s: ALL s: 8K s: 8K s: 8K s: ALL s: 8K s: 8K s: 8K s: ALL s: 8K s: 8K s: 8K s: ALL s: 8K, QF s: ALL s: 8K s: 8K, QF c Check r A {1} fact is present. If {1} facts are present, then r at least one is visible. r A {1} fact is absent. r A {2} fact is present. If {2} facts are present, then r at least one is visible. r A {2} fact is absent. r A {3} fact is present. If {3} facts are present, then r at least one is visible. r A {3} fact is absent. r A {4} fact is present. If {4} facts are present, then r at least one is visible. r A {4} fact is absent. If {5} facts are present, then r at least one is visible. r f On failure {1} Missing {1} in Facts Not Visible {1} Unexpected {2} Missing {2} in Facts Not Visible {2} Unexpected {3} Missing {3} in Facts Not Visible {3} Unexpected {4} Missing {4} in Facts Not Visible {4} Unexpected {5} in Facts Not Visible {5} Unexpected A {5} fact is absent. s EFM v68 Ref W § 6.5.52 Ri W § 6.5.52 Ri W § 6.5.52 [] W § 6.5.52 Ri W § 6.5.52 Ri W § 6.5.52 [] W § 6.5.52 Ri W § 6.5.52 Ri W § 6.5.52 [] W § 6.5.52 Ri W § 6.5.52 Ri W § 6.5.52 [] W § 6.5.52 O W § 6.5.52 [] 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 Submission type from EDGAR header dei:DocumentRegistrationStatement dei:InvestmentCompanyActRegistration dei:EntityFileNumber dei:InvestmentCompanyActFileNumber cef:BdcFileNumber 37 # {1} {2} {3} {4} {5} {6} Type or regex xs:boolean xs:boolean \d{1,3}-\d{1,8}(-.{1,4})? \d{1,3}-\d{1,8}(-.{1,4})? \d{1,3}-\d{1,8}(-.{1,4})? Meaning 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 i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF Excl c Check If {1} is N-2, then a {4} fact is r absent. If {1} is N-2, then a {5} fact is r absent. If {1} is N-2, then a {6} fact is r absent. Either or both a {2} fact valued a true or a {3} fact valued true must be present. Neither or both a {2} fact valued a true and a {4} fact exist. If {2} facts are present, then at r least one is visible. If {4} facts are present, then at r least one is visible. Neither or both a {3} fact valued a true and a {5} fact exist. If {3} facts are present, then at r least one is visible. If {5} facts are present, then at r least one is visible. At most one of {5} or {6} are a present. If {5} facts are present, then at r least one is visible. If {6} facts are present, then at r least one is visible. If {6} facts are present, their a value must begin with 814- f On failure s EFM v68 Ref 1 {4} Unexpected W § 6.5.55 [] 1 {5} Unexpected W § 6.5.55 [] 1 {6} Unexpected W § 6.5.55 [] {3} {4} Inclusive E § 6.5.55 n2c {2} {4} Value Dependency E § 6.5.55 n2sn E § 6.5.55 n2sn E § 6.5.55 n2sn E § 6.5.55 n2in E § 6.5.55 n2in E § 6.5.55 n2in E § 6.5.55 n2bn E § 6.5.55 n2bn {6} in Facts Not Visible E § 6.5.55 n2bn {6} Value E § 6.5.55 n2bn {2} in Facts Not Visible {2} in Facts Not Visible {3} {5} Value Dependency {3} in Facts Not Visible {5} in Facts Not Visible {5} {6} Exclusive {5} in Facts Not Visible 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 Submission type from EDGAR header dei:DocumentRegistrationStatement dei:PreEffectiveAmendment dei:PreEffectiveAmendmentNumber dei:PostEffectiveAmendment 38 # {1} {2} {3} {4} {5} Type or regex xs:boolean xs:boolean xs:positiveInteger xs:boolean Meaning Concept # dei:PostEffectiveAmendmentNumber dei:InvestmentCompanyActRegistration dei:InvestmentCompanyRegistrationAmendment dei:InvestmentCompanyRegistrationAmendmentNumber {6} {7} {8} {9} Type or regex xs: positiveInteger xs:boolean xs:boolean xs:positiveInteger Meaning Note that these tend to be errors, not warnings. Validations: Incl i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF Excl c Check If {1} is N-2, then a {3} fact is r absent. If {1} is N-2, then a {5} fact is r absent. If a {3} fact value is true, then a there is a {2} fact valued true. If a {5} fact value is true, then a there is a {2} fact valued true. If a {8} fact value is true, then a there is a {7} fact valued true. Neither or both {3} fact has the r value true and a {4} fact exists. Neither or both {5} fact has the r value true and a {6} fact exists. Neither or both {8} fact has the r value true and a {9} fact exists. If {2} facts valued true are r present, then at least one is visible. If {3} facts valued true are r present, then at least one is visible. If {4} facts are present, then at r least one is visible. If {5} facts valued true are r present, then at least one is visible. If {6} facts are present, then at r least one is visible. If {7} facts valued true are r present, then at least one is visible. If {8} facts valued true are r present, then at least one is visible. If {9} facts are present, then at r least one is visible. Notes and special cases: 39 f On failure s {3} Unexpected W § 6.5.55 [] {5} Unexpected W § 6.5.55 [] {3} {2} Value Dependency E § 6.5.55 n2d E § 6.5.55 n2f {8} {7} Value Dependency E § 6.5.55, n2h {3} {4} Value Dependency E § 6.5.55, n2e E § 6.5.55, n2g E § 6.5.55, n2i {2} in Facts Not E § 6.5.55 n2d {3} in Facts Not E § 6.5.55 n2d {4} in Facts Not E § 6.5.55 n2e {5} in Facts Not E § 6.5.55 n2f {6} in Facts Not E § 6.5.55 n2g {7} in Facts Not E § 6.5.55 n2h {8} in Facts Not E § 6.5.55 n2h {9} in Facts Not E § 6.5.55 n2i {5} {2} Value Dependency {5} {6} Value Dependency {8} {9} Value Dependency 1 Visible 1 Visible 1 Visible 1 Visible 1 Visible 1 Visible 1 Visible 1 Visible EFM v68 Ref 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 dei:ApproximateDateOfCommencementOfProposedSaleToThePublic {1} (As soon as practicable|From time to time) after the effective date of this Registration Statement\.?)|(20\d\d-(0[19]|1[0-2])-(3[01]|[012]\d)) Meaning Note that the text values contain 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 dei:DividendOrInterestReinvestmentPlanOnly dei:DelayedOrContinuousOffering cef:PrimaryShelfFlag dei:EffectiveUponFiling462e dei:AdditionalSecuritiesEffective413b # {1} {2} {3} {4} {5} Type or regex Meaning xs:boolean xs:boolean xs:boolean xs:boolean xs:boolean Validations: Incl i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF Excl c Check If {1} facts valued true are r present, then at least one is visible. If {2} facts valued true are r present, then at least one is visible. If {3} facts valued true are r present, then at least one is visible. If {4} facts valued true are r present, then at least one is visible. If {5} facts valued true are r present, then at least one is visible. f On failure s {1} in Facts E § 6.5.55 B {2} in Facts E § 6.5.55 B {3} in Facts E § 6.5.55 B {4} in Facts E § 6.5.55 B {5} in Facts E § 6.5.55 B 1 Not Visible 1 Not Visible 1 Not Visible 1 Not Visible 1 Not 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 dei:EffectiveWhenDeclaredSection8c dei:EffectiveUponFiling486b 40 # {1} {2} Type or regex Meaning xs:boolean xs:boolean EFM v68 Ref Concept dei:EffectiveOnSetDate486b dei:EffectiveOnDate486b dei:EffectiveAfter60Days486a dei:EffectiveOnSetDate486a dei:EffectiveOnDate486a # Type or regex Meaning {3} {4} {5} {6} {7} xs:boolean xs:date xs:boolean xs:boolean xs:date Validations: Incl i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF Excl c Check If {1} facts valued true are r present, then at least one is visible. If {2} facts valued true are r present, then at least one is visible. If {3} facts valued true are r present, then at least one is visible. Neither or both {3} fact has the a value true and a {4} fact exists. If {4} facts are present, then at r least one is visible. If {5} facts valued true are r present, then at least one is visible. If {6} facts valued true are r present, then at least one is visible. Neither or both {6} fact has the a value true and a {7} fact exists. If {7} facts are present, then at r least one is visible. f On failure s {1} in Facts Not E § 6.5.55 B {2} in Facts Not E § 6.5.55 B {3} in Facts Not E § 6.5.55 B 1 Visible 1 Visible 1 Visible {3} {4} Value Dependency EFM v68 Ref E § 6.5.55 n2j {4} in Facts Not E § 6.5.55 n2j {5} in Facts Not E § 6.5.55 B {6} in Facts Not E § 6.5.55 B 1 Visible 1 Visible 1 Visible {6} {7} Value Dependency {7} in Facts Not 1 Visible E § 6.5.55 n2k E § 6.5.55 n2k 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 dei:NewEffectiveDateForPreviousFiling dei:AdditionalSecurities462b dei:AdditionalSecurities462bFileNumber dei:NoSubstantiveChanges462c dei:NoSubstantiveChanges462cFileNumber dei:ExhibitsOnly462d dei:ExhibitOnly462dFileNumber Validations: 41 # {1} {2} {3} {4} {5} {6} {7} Type or regex xs:date xs:boolean \d{1,3}-\d{1,8}(-.{1,4})? xs:boolean \d{1,3}-\d{1,8}(-.{1,4})? xs:boolean \d{1,3}-\d{1,8}(-.{1,4})? Meaning Incl i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF Excl c Check If {1} facts are present, then at r least one is visible. If {2} facts valued true are r present, then at least one is visible. Neither or both {2} fact has the a value true and a {3} fact exists. If {3} facts are present, then at r least one is visible. If {4} facts valued true are r present, then at least one is visible. Neither or both {4} fact has the a value true and a {5} fact exists. If {5} facts are present, then at r least one is visible. If {6} facts valued true are r present, then at least one is visible. Neither or both {6} fact has the a value true and a {7} fact exists. If {7} facts are present, then at r least one is visible. f On failure {1} in Facts Not Visible 1 {2} in Facts Not 1 Visible {2} {3} Value Dependency s EFM v68 Ref E § 6.5.55 B E § 6.5.55 B E § 6.5.55 n2l {3} in Facts Not E § 6.5.55 n2l {4} in Facts Not E § 6.5.55 B 1 Visible 1 Visible {4} {5} Value Dependency E § 6.5.55 n2m {5} in Facts Not E § 6.5.55 n2m {6} in Facts Not E § 6.5.55 B 1 Visible 1 Visible {6} {7} Value Dependency {7} in Facts Not 1 Visible E § 6.5.55 n2o E § 6.5.55 n2o 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 cef:RegisteredClosedEndFundFlag cef:BusinessDevelopmentCompanyFlag cef:IntervalFundFlag cef:PrimaryShelfQualifiedFlag dei:EntityWellKnownSeasonedIssuer dei:EntityEmergingGrowthCompany dei:EntityExTransitionPeriod cef:NewCefOrBdcRegistrantFlag # {1} {2} {3} {4} {5} {6} {7} {8} Type or regex Meaning xs:boolean xs:boolean xs:boolean xs:boolean Yes|No xs:boolean xs:boolean xs:boolean Validations: Incl i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF 42 Excl c Check If {1} facts valued true are r present, then at least one is visible. At most one of {1} and {2} has the r value true. If {2} facts valued true are r present, then at least one is visible. If {3} facts valued true are r present, then at least one is visible. f On failure {1} in Facts Not 1 Visible s 1 Exclusive Values {2} in Facts Not 1 Visible {3} in Facts Not 1 Visible E § 6.5.55 n2p {1} {2} EFM v68 Ref E § 6.5.55 n2p E § 6.5.55 B E § 6.5.55 B Incl i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF i: RD.CEF Excl c Check If {4} facts valued true are r present, then at least one is visible. If {5} facts valued true are r present, then at least one is visible. If {6} facts valued true are r present, then at least one is visible. If {7} facts valued true are r present, then at least one is visible. If {8} facts valued true are r present, then at least one is visible. f On failure {4} in Facts Not 1 Visible {5} in Facts Not Visible {6} in Facts Not Visible {7} in Facts Not 2 Visible {8} in Facts Not Visible s EFM v68 Ref E § 6.5.55 B E § 6.5.55 B E § 6.5.55 B E § 6.5.55 B E § 6.5.55 B 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 Concept core dimension and concepts Other core dimensions and their members Fact values Taxonomy-defined dimension (Axis) Standard members Custom members Abstract placeholder concepts not appearing in instances, such as hypercubes, line items, domain defaults, and non-usable domain members. Color Green Gray None Orange Medium Blue Purple Light Blue 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 period: FY30 units: USD Region 1 Region Axis Region 2 Concepts Dimension Product Revenue 23 17 40 Service Revenue 12 8 20 Combined Revenue 35 25 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 period: FY30 units: USD Product Revenue Concepts Service Revenue Dimension Combined Revenue Region Axis Region 1 Region 2 23 12 35 17 8 25 40 20 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 Example01 Example01 Example01 Example01 Example01 Example01 Example01 Example01 Example01 Period FY30 FY30 FY30 FY30 FY30 FY30 FY30 FY30 FY30 Unit USD USD USD USD USD USD USD USD USD Concept Product Revenue Service Revenue Combined Revenue Product Revenue Service Revenue Combined Revenue Product Revenue Service Revenue Combined Revenue Region Value Region 1 23 Region 1 12 Region 1 35 Region 2 17 Region 2 8 Region 2 25 40 20 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 Example01 FY30 Best Seller Region 2 Product B Product A 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 # dei:ContactPersonnelName dei:LocalPhoneNumber dei:ContactPersonnelFax dei:ContactPersonnelEmailAddress {1} {2} {3} {4} Type or regex Meaning xs:normalizedString xs:normalizedString xs:normalizedString xs:normalizedString Validations: Incl i: AF.FPI, RD.CEF, AF.CA Excl i: AF.FPI, RD.CEF, AF.CA s: ALL c Check bc A {1} fact is present. bc i: R34.FPI, R34.CA, R33.FPI, R33.US bc i: AF.FPI, RD.CEF bc i: AF.CA bc i: AF.CA bc 45 If {1} facts are present, then at least one is visible. A {1} fact is absent. One, two, or all three {2}, {3} or {4} facts are present. A {2} fact is present. If {2} facts are present, then at least one is visible. f On failure s EFM v68 Ref {1} Missing W § 6.5.51 Ri {1} in Facts Not Visible W § 6.5.51 Ri {1} Unexpected W {2} {3} {4} Missing W § 6.5.51 O3 {2} Missing W § 6.5.51 Ri {2} in Facts Not Visible W § 6.5.51 O3 § 6.5.51 [], O* Incl Excl i: AF.FPI, RD.CEF, AF.CA, R34.FPI, R34.CA, R33.FPI, R33.US s: ALL i: AF.FPI, RD.CEF bc A {2} fact is absent. bc i: AF.FPI, RD.CEF bc i: AF.FPI, RD.CEF, R34.FPI, R34.CA s: ALL Check bc i: AF.FPI, RD.CEF, R34.FPI, R34.CA s: ALL c bc f On failure If {3} facts are present, then at least one is visible. A {3} fact is absent. If {4} facts are present, then at least one is visible. A {4} fact is absent. s EFM v68 Ref {2} Unexpected W § 6.5.51 [], O* {3} in Facts Not Visible W § 6.5.51 O3 {3} Unexpected W {4} in Facts Not Visible W § 6.5.51 O3 {4} Unexpected W § 6.5.51 [], O* § 6.5.51 [], 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 # dei:EntityAddressAddressLine1 dei:EntityAddressCityOrTown dei:EntityAddressPostalZipCode {1} {2} {3} Type or regex Meaning xs:normalizedString xs:normalizedString xs:normalizedString The first line of the address, the city or town, and postal or zip code, share similar validations: Incl i: AF.FPI, RD.CEF, AF.CA i: AF.FPI, RD.CEF, AF.CA s: ALL i: AF.FPI, RD.CEF, AF.CA i: AF.FPI, RD.CEF, AF.CA s: ALL 46 Excl i: AF.FPI, RD.CEF, AF.CA, R34.FPI, R34.CA R33.FPI R33.US i: AF.FPI, RD.CEF, AF.CA, R34.FPI, R34.CA R33.FPI R33.US c Check bc A {1} fact is present. {1} Missing W § 6.5.51 Ri If {1} facts are bc present, then at least one is visible. {1} in Facts Not Visible W § 6.5.51 Ri bc A {1} fact is absent. {1} Unexpected W bc A {2} fact is present. {2} Missing W § 6.5.51 Ri If {2} facts are bc present, then at least one is visible. {2} in Facts Not Visible W § 6.5.51 Ri A {2} fact is absent. {2} Unexpected W § 6.5.51 [] bc f On failure s EFM v68 Ref § 6.5.51 [], O* Incl i: AF.FPI, RD.CEF, AF.CA Excl c Check bc A {3} fact is present. i: AF.FPI, RD.CEF, AF.CA i: AF.FPI, RD.CEF, AF.CA, R34.FPI, R34.CA R33.FPI R33.US s: ALL bc If {3} facts are present in the required context, then at least one is visible. bc A {3} fact is absent. f On failure {3} Missing s EFM v68 Ref W § 6.5.51 Ri {3} in Facts Not Visible W § 6.5.51 Ri {3} Unexpected W § 6.5.51 [], O* Notes and special cases: none. 3.2.1.3 State or Province and Country Concept # Type or regex dei:EntityAddressStateOrProvince {1} Postal state or province dei:EntityAddressCountry {2} Valid IANA country code Meaning XBRL transformations that convert state and province names to postal codes (e.g., TX, ON) are shown in EFM § 5.2.5.12. XBRL transformations that country names to ISO 3166-1 alpha 2 (IANA) codes (e.g., US, JP) are shown in EFM 5.2.5.12. Validations: Incl Excl c i: AF.FPI, RD.CEF bc i: AF.CA bc i: AF.FPI, RD.CEF, AF.CA bc i: R34.CA bc s: ALL i: AF.FPI, RD.CEF s: ALL i: AF.FPI, RD.CEF, AF.CA, bc A {1} fact is absent. R34.CA, R33.US If {2} facts are bc present, then at least one is visible. i: R33.FPI, bc A {2} fact is absent. R34.FPI Notes and special cases: none. 47 Check One or both {1} and {2} facts are present. A {1} fact representing a US state is present. If {1} facts are present, then at least one is visible. A {1} fact representing a Canadian province is present. f Codes s EFM v68 Ref {1} {2} Inclusive W § 6.5.51 O2 {1} Value W § 6.5.51 Ru {1} in Facts Not Visible W {1} Value W § 6.5.51 Ou* {1} Unexpected W {2} in Facts Not Visible W § 6.5.51 O2 {2} Unexpected W § 6.5.51 [] § 6.5.51 O2, Ru § 6.5.51 [], O* 3.2.1.4 Phone Concept dei:CityAreaCode dei:LocalPhoneNumber # Type or regex {1} {2} Meaning xs:normalizedString xs:normalizedString Validations: Incl Excl i: AF.CA i: AF.CA, AF.FPI, RD.CEF i: AF.CA, AF.FPI, RD.CEF, R34.FPI, R34.CA, R33.FPI, R33.US s: ALL i: AF.CA Check A {1} fact is bc present. If {1} facts are present, then at bc least one is visible. bc A {1} fact is absent. A {2} fact is present. If {2} facts are present, then at bc least one is visible. bc i: AF.CA, AF.FPI, RD.CEF i: AF.CA, AF.FPI, RD.CEF, R34.FPI, R34.CA, R33.FPI, R33.US s: ALL c bc A {2} fact is absent. f On failure s EFM v68 Ref {1} Missing W § 6.5.51 Ri 1 {1} in Facts Not Visible W § 6.5.51 Oph 1 {1} Unexpected W {2} Missing W § 6.5.51 Ri {2} in Facts Not Visible W § 6.5. 51 O3, Ri {2} Unexpected W § 6.5. 51 [], O* § 6.5.51 [], Oph* 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:FormerAddressMember. 3.2.2.1 Former Street, City and Zip Concept dei:EntityAddressAddressLine1 dei:EntityAddressAddressLine2 dei:EntityAddressAddressLine3 dei:EntityAddressCityOrTown dei:EntityAddressPostalZipCode # {1} {2} {3} {4} {5} Type or regex xs:normalizedString xs:normalizedString xs:normalizedString xs:normalizedString xs:normalizedString Meaning The first line of the address, the city or town, and postal or zip code, share similar validations. Validations: 48 Incl s: 8K, QF Excl s: 8K, QF s: ALL s: 8K, QF s: 8K, QF c Check If {1} facts are present, then fa at least one is visible. f On failure {1} in Facts Not Visible s: 8K, QF s: 8K, QF s: 8K, QF s: 8K, QF s: 8K, QF s: 8K, QF W § 6.5.53 [], O If {2} facts are present, then at least one is visible. If a {2} fact is present, then fa a {1} fact is present. {2} in Facts Not Visible W § 6.5.53 OL1 {1} {2} Dependency W § 6.5.53 OL1 fa A {2} fact is absent. {2} Unexpected W § 6.5.53 [] If a {3} fact is present, then a {2} fact is present. If {3} facts are present, then fa at least one is visible. {2} {3} Dependency W § 6.5.53 OL2 {3} in Facts Not Visible W § 6.5.53 OL2 fa A {3} fact is absent. {3} Unexpected W {4} {5} Inclusive W § 6.5.53 F2 {4} in Facts Not Visible W § 6.5.53 F2 {4} Unexpected W § 6.5.53 [] {5} in Facts Not Visible W § 6.5.53 F2 {5} Unexpected W § 6.5.53 [] One or both {4} and {5} facts are present If {4} facts are present, then fa at least one is visible. fa s: 8K, QF s: ALL s: 8K, QF fa A {4} fact is absent. If {5} facts are present, then at least one is visible. fa s: 8K, QF s: ALL W § 6.5.53 O {1} Unexpected fa s: ALL EFM v68 Ref fa A {1} fact is absent. fa s: ALL s fa A {5} fact is absent. § 6.5.53 [], OL2 Notes and special cases: none. 3.2.2.2 Former State or Province and Country Concept # Type or regex {1} xs:normalizedString dei:EntityAddressStateOrProvince {2} Postal state or province dei:EntityAddressCountry {3} dei:EntityAddressAddressLine1 Valid IANA country code Meaning XBRL transformations that convert state and province names to postal codes (e.g., TX, ON) are shown in EFM § 5.2.5.12. XBRL transformations that country names to ISO 3166-1 alpha 2 (IANA) codes (e.g., US, JP) are shown in EFM 5.2.5.12. Validations: Incl s: 8K, QF s: 8K, QF 49 Excl c Check If a {1} is present, then one or both fa of {2} and {3} facts are present. fa If a {2} fact is absent, then {1} is absent. f On failure {1} {2} {3} Inclusive Dependency {2} {1} Inclusive Dependency s EFM v68 Ref W § 6.5.53 F2 W § 6.5.53 F2 Incl s: 8K, QF Excl s: 8K, QF c Check If a {3} fact is absent, then {1} is fa absent. fa s: 8K, QF s: ALL s: 8K, QF s: 8K, QF If {2} facts are present, then at least one is visible. fa A {2} fact is absent. fa s: ALL f On failure If {3} facts are present, then at least one is visible. fa A {3} fact is absent. {3} {1} Inclusive Dependency {2} in Facts Not Visible {2} Unexpected {3} in Facts Not Visible {3} Unexpected s EFM v68 Ref W § 6.5.53 F2 W § 6.5.53 F2 W § 6.5.53 [] W § 6.5.53 F2 W § 6.5.53 [] 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 dei:EntityCommonStockSharesOutstanding # {1} Type or regex Meaning 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: Case Axis in any standard namespace Members in distinct contexts 1 No dimensions N/A 2 StatementClassOfStockAxis At least two 3 ClassesOfShareCapitalAxis At least two Period An instant on or after the end of the required context An instant on or after the end of the required context An instant on or after the end of the 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 s: FAST i: AF.CA s: FAST s: ALL s: FAST, i: R33.FPI c Check A {1} fact is present in each se context of exactly one of the cases 1, 2 or 3. If {1} facts are present in a se context, at least one is visible. A {1} fact is not present in se any context. f On failure s EFM v68 Ref {1} Missing W § 6.5.26 {1} in Facts Not Visible W § 6.5.45 {1} Unexpected W § 6.5.26 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 1 2 3 Axis in any standard namespace No dimensions (the required context) StatementClassOfStockAxis ClassesOfShareCapitalAxis Distinct members in contexts N/A (there is only one class) At least two At least two Period Required context Required context 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 ClassesOfShareCapitalAxis 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 dei:Security12bTitle dei:Security12gTitle # {1} {2} Type or regex xs:normalizedString up to 150 characters xs:normalizedString up to 150 characters Meaning Validations: Incl Excl s: FAST, R34 s: FAST, R34 s: FAST, R34 s: FAST s: FAST s: ALL s: ALL s: FAST, R34 s: FAST, R34 c Check A {1} fact value is present r in at most one of the cases 1-3. A {2} fact value is present r in at most one of the cases 1-3. At most one {1} or {2} a fact is present. If {1} facts are present in a r context, at least one is visible. If {2} fact values are r present in a context, at least one is visible. A {1} fact is absent from r all contexts. A {2} fact is absent from r all contexts. Notes and special cases: none. 51 f On failure s EFM v68 Ref {1} Security Axes W § 6.5.46 Ot1, [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/agency%3Asec%3Aa23fe49809c43242. Public record. Not legal advice.