# Consistency Assertions 1.0

## Candidate Recommendation 28 March 2008

Copyright ©2008 XBRL International Inc., All Rights Reserved.

This version:
  <http://www.xbrl.org/Specification/consistencyAssertions/CR-2008-03-28/consistencyAssertions-CR-2008-03-28.html>
Editors:
  Victor Morilla, Banco de España <victor.morilla@bde.es>
  Geoff Shuetrim, Galexy <geoff@galexy.net>
Contributors:
  Paul Bull, Morgan Stanley <paul.bull@morganstanley.com>
  Herm Fischer, UBMatrix / Mark V Systems <fischer@markv.com>
  Mark Goodhand, Decisionsoft <mrg@decisionsoft.com>
  Masatomo Goto, Fujitsu <mg@jp.fujitsu.com>
  Roland Hommes, Rhocon / Consultant to Netherlands Tax and Customs Administration <roland@rhocon.nl>
  Jim Richards, JDR & Associates <jdrassoc@iinet.net.au>
  Michele Romanelli, Banca d'Italia <michele.romanelli@bancaditalia.it>

## Status

Circulation of this Candidate Recommendation is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to formula-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

## Abstract

This specification is an extension of the Validation specification [VALIDATION]. It specifies syntax for assertions that can be used to test the consistency of a fact produced by a formula with fact contained in an XBRL business report.

# 1 Introduction

The XBRL Formulae specification [FORMULA] defines a syntax that expresses rules for transforming information in XBRL business reports and their supporting discoverable taxonomy sets into new XBRL facts.

This specification extends the XBRL Validation specification [VALIDATION], defining an assertion that uses formulae to define tests on XBRL business reports. These assertions can test the consistency of the fact produced by a formula evaluation with aspect-matching facts in the XBRL business report.

This design enables the one formula resource to be used to produce new facts and to check the consistency of existing facts with other facts in their containing XBRL business report. A regulator can use this kind of assertion to test the quality of data received and producers of business reports can use the common formula to derive the facts being reported in a manner that is consistent with the requirements of the regulator.

This kind of assertion facilitates the definition of business rules that perform checks like those set out in Example 1.

Example 1: Consistency assertions

- The total income reported for a company is equal to the cumulated income reported for each market segment, taking into account considering the precision of reported total income and the precision of the cumulated income based on reporting of market segments.
- The difference between net income reported and net income calculated as total income minus operating expenses, must be less than ten percent of calculated net income.
- The difference between the reported ending balance and the ending balance computed from the flows during the intervening period and the starting balance, must be less than an amount defined by an external parameter.

Many of the syntax constraints imposed by this specification are set out in the normative schema Appendix A. To eliminate the potential for conflicts, this specification only enunciates syntax features that are not expressed in the normative schema.

## 1.1 Background

This specification is a member of a suite of similar specifications that define specific types of assertions tested against the information contained in XBRL business reports.

## 1.2 Relationship to other work

This specification builds on the foundation provided by the XBRL Validation Specification [VALIDATION] and the XBRL Formulae Specification [FORMULA].

## 1.3 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

## 1.4 Terminology

This specification is consistent with the definitions of any of the terms defined in specifications that it depends on.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].

## 1.5 Document conventions (non-normative)

Documentation conventions follow those set out in the XBRL Variables Specification [VARIABLES].

## 1.6 Namespaces and namespace prefixes

Namespace prefixes [XML NAMES] will be used for elements and attributes in the form `ns:name` where `ns` is the namespace prefix and `name` is the local name. Throughout this specification, the mappings from namespace prefixes to actual namespaces is consistent with Table 1.

The prefix column in Table 1 is non normative. The namespace URI column is normative.

Table 1: Namespaces and namespace prefixes

Prefix | Namespace URI
--- | ---
`formula` | `http://xbrl.org/2008/formula`
`validation` | `http://xbrl.org/2008/validation`
`ca` | `http://xbrl.org/2008/assertion/consistency`
`xbrlcae` | `http://xbrl.org/2008/assertion/consistency/error`
`eg` | `http://example.com/`
`fn` | `http://www.w3.org/2005/xpath-functions`
`link` | `http://www.xbrl.org/2003/linkbase`
`xbrli` | `http://www.xbrl.org/2003/instance`
`xfi` | `http://www.xbrl.org/2005/function/instance`
`xbrldi` | `http://xbrl.org/2006/xbrldi`
`xbrldt` | `http://xbrl.org/2005/xbrldt`
`xl` | `http://www.xbrl.org/2003/XLink`
`xlink` | `http://www.w3.org/1999/xlink`
`xs` | `http://www.w3.org/2001/XMLSchema`
`xsi` | `http://www.w3.org/2001/XMLSchema-instance`
`gen` | `http://xbrl.org/2008/generic`
`variable` | `http://xbrl.org/2008/variable`
`iso4217` | `http://www.xbrl.org/2003/iso4217`

## 1.7 XPath usage

XPath usage is identical to that in the XBRL Variables Specification [VARIABLES].

# 2 Syntax

This specification only provides a textual declaration of syntax constraints when those constraints are not expressed by the normative schema supplied with this specification.

Explanations of elements and attributes are only supplied when explanations are not already provided in other specifications.

Unless explicitly stated otherwise, a reference to a specific element MUST be read as a reference to that element or to any element in its substitution group.

## 2.1 Consistency assertions

A consistency assertion is a statement of expectations in relation to the consistency of facts in an XBRL instance with the values that can be derived for those facts from the same XBRL instance by processing formulae [FORMULA].

Consistency assertions are expressed by the `<ca:consistencyAssertion>` element in the normative schema supplied with this specification.

Consistency assertions have relationships to formulae, defined by XLink arcs. See Section 2.1.1.1 for details.

A derived fact is any one of the facts that can be produced by evaluating a formula in the set of consistency assertion formulae, given the assertion input.

An aspect-matching fact for a derived fact is a fact in the assertion input used to produce the derived fact that has aspect values that match those of the derived fact for all of its aspects and that have no additional aspects. Aspect value matches are determined using the aspect test for each aspect of the relevant aspect model.

The relevant aspect model is identified by the `@aspectModel` attribute on the formula that produced the derived fact.

Consistency assertions are tested by comparing the values of derived facts with the values of aspect-matching facts in the assertion input for consistency.

The `@strict` attribute on a consistency assertion influences which derived facts can be used to test a consistency assertion.

A consistency assertion is strict if it has a `@strict` attribute that is equal to `true`. Otherwise it is not strict.

If a consistency assertion is not strict then it MUST NOT be evaluated for derived facts if they do not have aspect-matching facts.

If the consistency assertion is strict then the consistency assertion MAY be evaluated for derived facts even if they do not have aspect-matching facts. Such assertions can be used to test for both the presence of aspect matching facts as well as for consistency of their values.

Example 2: `@strict` attribute usage

`@strict` attribute | Facts in target instance | Assertion formula | Can be evaluated?
--- | --- | --- | ---
`false` | a, b, c | a = b * c | Yes
`true` | a, b, c | a = b * c | Yes
`false` | b, c | a = b * c | No
`true` | b, c | a = b * c | Yes (but never satisfied)

The acceptance radius of a consistency assertion is a number that represents the maximum difference between the numerical value of two facts for them to be considered consistent.

The acceptance radius can be defined as an absolute value, in which case the consistency assertion contains an `@absoluteAcceptanceRadius` attribute.

Alternatively, the acceptance radius can be defined as a proportion of the derived fact value, in which case the consistency assertion contains a `@proportionalAcceptanceRadius` attribute.

If the acceptance radius is an absolute value, then it is the result of evaluating the XPath expression at the `@absoluteAcceptanceRadius` attribute.

If the acceptance radius is proportional, then it is the result of evaluating the XPath expression:

`. * ( #proportionalAcceptanceRadius )`

where `#proportionalAcceptanceRadius` is the XPath expression at the `@absoluteAcceptanceRadius` attribute.

The context when evaluating these two XPath expressions MUST:

- have as the context item an atomic value equal to the numeric value of the derived fact; and
- include assertion parameters among the in-scope variables.

Error code xbrlcae:acceptanceRadiusConflict MUST be thrown if a consistency assertion contains both an `@absoluteAcceptanceRadius` attribute and a `@proportionalAcceptanceRadius` attribute.

Example 3: Acceptance radius

Attribute / value | Derived fact value | Acceptance radius
--- | --- | ---
No attribute defined | Any | Not defined
`@absoluteAcceptanceRadius` = `100` | Any | 100
`@absoluteAcceptanceRadius` = `$margin` | Any | Value of the parameter `margin`
`@proportionalAcceptanceRadius` = `0.5` | `500` | `250`
`@proportionalAcceptanceRadius` = `0.5`, `@absoluteAcceptanceRadius` = `500` | Any | Error: acceptance radius definition conflict

Consistency assertions have a variety of relationships to other XLink resources, expressed by XLink arcs. These relationships are explained in the following section.

### 2.1.1 Fact consistency assertions relationships

#### 2.1.1.1 Consistency-assertion-formula relationships

A consistency-assertion-formula relationship is a relationship between a consistency-assertion and a formula expressed by an XLink arc.

To declare a consistency-assertion-formula relationship an XLink arc MUST:

- have an arcrole value equal to `http://xbrl.org/arcrole/2008/consistency-assertion-formula`
- have a consistency-assertion at the starting resource of the arc
- have a formula at the ending resource of the arc

The arcrole value, `http://xbrl.org/arcrole/2008/consistency-assertion-formula`, is declared in the normative schema for consistency assertions.

Consistency-assertion-formula relationships MUST be expressed by generic arcs as indicated by the restrictions imposed by the arcrole declaration in the normative schema. Violations of this requirement will be detected by validation against the XBRL Specification [XBRL 2.1].

The set of formulae related to a consistency assertion by consistency-assertion-formula relationships are known as the consistency-assertion formulae.

A consistency-assertion-formula is any formula in a set of consistency-assertion formulae.

A consistency assertion checks the consistency of reported facts with the facts produced by each of its consistency-assertion formulae on a stand-alone basis. Thus, the tests possible for one consistency assertion associated with two formulae, are identical to the tests implied by two consistency assertions, one related to one formula and the other related to the other formula.

#### 2.1.1.2 Variable-set relationships for consistency assertions

A consistency assertion variable-set relationship is a relationship between a consistency assertion and a parameter expressed by an XLink arc.

A consistency assertion MAY be related to parameters by variable-set relationships.

Error code xbrlcae:factVariablesNotAllowed MUST be thrown if a consistency assertion has a variable-set relationship to a fact variable or to a general variable.

A consistency assertion parameter is any parameter that has a variable-set relationship to it from a consistency assertion. These parameters are part of the in-scope variables of the evaluation of acceptance radius expressions, but MUST NOT be considered part of the variable-set of the consistency assertion formulae.

# 3 The processing model for consistency assertions

Aside from the exceptions described below, each different evaluation of a consistency assertion formula defines a different assertion data set that the consistency assertion can be tested with. The assertion data set of a consistency assertion is the derived fact produced by an evaluation of a consistency assertion formula plus all of the aspect-matching facts in the target XBRL instance that do not have nil values. Note that there may be no aspect-matching facts in the target XBRL instance that meet the conditions necessary to be included in the data set defined by a derived fact.

One exception to this rule is that a derived fact does not define an assertion data set if:

- the consistency assertion is not strict; and
- there are no aspect-matching facts for the derived fact.

The second exception to the rule is that a derived fact does not define an assertion data set if:

- the derived fact is numeric; and
- the derived fact is not nil; and
- the derived fact does not have a data type that is `xbrli:fractionItemType` and that is not derived from the `xbrli:fractionItemType` data type; and
- the consistency assertion does not define an acceptance radius; and
- the implied precision of the derived fact or any of its aspect-matching facts is zero.

If an assertion data set contains aspect-matching facts, then the derived fact MUST be consistent with all of them for the consistency assertion to be satisfied for that assertion data set. Otherwise the consistency assertion is not satisfied for that assertion data set.

Two facts are consistent if they have consistent values. Whether two facts have consistent values depends upon their data types.

If the two facts have data types that are not numeric then they are only consistent if their values are s-equal2.

If the two facts have data types that are numeric, and their data types are not `xbrli:fractionItemType` or derived from the `xbrli:fractionItemType`, and the acceptance radius is not defined, then they are only consistent if the numeric values `A` and `B` are x-equal where `A` is obtained by rounding the value of the first fact to `N` significant figures and `B` is obtained by rounding the value of the second fact to `N` significant figures noting that `N` is the lower of the specified or inferred precision for the first fact and the specified or inferred precision for the second fact.

If the two facts have data types that are numeric, and their data types are not `xbrli:fractionItemType` or derived from the `xbrli:fractionItemType`, and the acceptance radius is defined, then they are only consistent if the following XPath expression evaluates to an effective Boolean value of `true`:

`fn:abs(#A - #B) le fn:abs(#acceptance)`

where `#A` is the numerical value of the first fact, `#B` is the numerical value of the second fact and `#acceptance` is the value of the acceptance radius.

Formulae, as defined in the XBRL Formula Specification [FORMULA] cannot produce facts that have data types that are or are derived from the `xbrli:fractionItemType`. For this reason, consistency assertions cannot be used to test such facts for consistency and so value consistency is not defined in this specification for such facts.

If none of these conditions for consistency are satisfied then the derived fact and the aspect-matching fact that it is being compared to are not consistent.

Example 4: Consistent values

Derived fact | Aspect-matching fact | Acceptance radius | Assertion evaluation
--- | --- | --- | ---
Inferred precision | Value | Inferred precision | Value
- | `foo` | - | `foo` | Any | Satisfied
- | `foo` | - | `bar` | Any | Not satisfied
`INF` | `315.5` | `INF` | `315.5` | Not defined | Satisfied
`INF` | `315.5` | `INF` | `315.50001` | Not defined | Not satisfied
`0` | `315.5` | `INF` | `1000000` | Not defined | Not evaluated
`2` | `10` | `2` | `10.4` | Not defined | Satisfied
`2` | `10` | `3` | `10.4` | Not defined | Satisfied
`2` | `10` | `3` | `10.5` | Not defined | Not satisfied
Any | `10.0000001` | Any | `10.0000001` | `0` | Satisfied
Any | `10` | Any | `10.0000001` | `0` | Not satisfied
Any | `25` | Any | `30` | `5` | Satisfied
Any | `25` | Any | `30.000001` | `5` | Not satisfied

If an assertion data set does not contain any aspect-matching facts, then the derived fact MUST have a nil value if the consistency assertion is to be satisfied for that assertion data set. Otherwise the consistency assertion is not satisfied for that assertion data set.

Example 5: Consistency assertions involving nil values

`@strict` attribute | Derived fact | Aspect-matching facts | Assertion evaluation
--- | --- | --- | ---
`false` | Nil | None | Not evaluated
`false` | Not nil | None | Not evaluated
`false` | Nil | Not nil only | Not satisfied
`true` | Nil | None | Satisfied
`true` | Not nil | None | Not satisfied
`true` | Nil | Not nil only | Not satisfied

# Appendix A Normative schema

The following is the XML schema provided as part of this specification. This is normative. Non-normative versions (which should be identical to these except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.

NOTE: (non-normative) Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows:

1. While any schema is the most current RECOMMENDED version and until it is superseded by any additional errata corrections a non-normative version will reside on the web in the directory `http://www.xbrl.org/2008/` - during the drafting process for this specification this directory should contain a copy of the most recent published version of the schema at http://www.xbrl.org/2008/consistency-assertion.xsd.
2. A non-normative version of each schema as corrected by any update to the RECOMMENDATION will be archived in perpetuity on the web in a directory that will contain a unique identification indicating the date of the update.

<schema xmlns:ca="http://xbrl.org/2008/assertion/consistency" xmlns:validation="http://xbrl.org/2008/validation" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:variable="http://xbrl.org/2008/variable" xmlns:gen="http://xbrl.org/2008/generic" xmlns:link="http://www.xbrl.org/2003/linkbase" targetNamespace="http://xbrl.org/2008/assertion/consistency" elementFormDefault="qualified">
<import namespace="http://www.xbrl.org/2003/XLink" schemaLocation="http://www.xbrl.org/2003/xl-2003-12-31.xsd"/>
<import namespace="http://xbrl.org/2008/variable" schemaLocation="variable.xsd"/>
<import namespace="http://xbrl.org/2008/validation" schemaLocation="validation.xsd"/>
<annotation>
<appinfo>
<link:arcroleType id="consistency-assertion-formula" cyclesAllowed="none" arcroleURI="http://xbrl.org/arcrole/2008/consistency-assertion-formula">
<link:definition>
assertion based on formula
</link:definition>
<link:usedOn>
gen:arc
</link:usedOn>
</link:arcroleType>
</appinfo>
</annotation>
<element id="xml-consistency-assertion" name="consistencyAssertion" substitutionGroup="validation:assertion">
<complexType mixed="true">
<complexContent mixed="true">
<extension base="validation:assertion.type">
<attribute name="strict" type="boolean" use="required"/>
<attribute name="absoluteAcceptanceRadius" type="variable:expression" use="optional"/>
<attribute name="proportionalAcceptanceRadius" type="variable:expression" use="optional"/>
</extension>
</complexContent>
</complexType>
</element>
</schema>

# Appendix B References

DIMENSIONS
  XBRL International Inc.. "XBRL Dimensions 1.0"
  Ignacio Hernández-Ros, and Hugh Wallis.
  (See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
FORMULA
  XBRL International Inc.. "XBRL Formulae 1.0, Public Working Draft"
  Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
  (See ../../formula/CR-2008-03-28/formula-CR-2008-03-28.html)
GENERIC LINKS
  XBRL International Inc.. "XBRL Generic Links 1.0 (Public Working Draft)"
  Mark Goodhand, Ignacio Hernández-Ros, and Geoff Shuetrim.
  (See ../../gnl/PWD-2008-03-07/gnl-PWD-2008-03-07.html)
IETF RFC 2119
  IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
  Scott Bradner.
  (See http://www.ietf.org/rfc/rfc2119.txt)
VALIDATION
  XBRL International Inc.. "XBRL Validations 1.0, Public Working Draft"
  Victor Morilla, and Geoff Shuetrim.
  (See ../../validation/CR-2008-03-28/validation-CR-2008-03-28.html)
VARIABLES
  XBRL International Inc.. "XBRL Variables 1.0, Public Working Draft"
  Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
  (See ../../variables/CR-2008-03-28/variables-CR-2008-03-28.html)
XBRL 2.1
  XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1"
  Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
  (See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2006-12-18.htm)
XLINK
  W3C (World Wide Web Consortium). "XML Linking Language (XLink) Version 1.0"
  Steve DeRose, Eve Maler, and David Orchard.
  (See http://www.w3.org/TR/xlink/)
XML NAMES
  W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Second Edition)"
  Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.
  (See http://www.w3.org/TR/REC-xml-names/)
XML SCHEMA STRUCTURES
  W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
  Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn.
  (See http://www.w3.org/TR/xmlschema-1/)
XPATH 2.0
  W3C (World Wide Web Consortium). "XML Path Language (XPath) 2.0"
  Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon.
  (See http://www.w3.org/TR/xpath20/)

# Appendix C Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

# Appendix D Acknowledgements (non-normative)

This document could not have been written without the contributions of many people including the participants in the Formula Working Group.

# Appendix E Document history (non-normative)

Date | Author | Details
--- | --- | ---
30 June 2007 | Geoff Shuetrim | Initial draft created.
22 July 2007 | Geoff Shuetrim | Converted to XML format.
15 October 2007 | Geoff Shuetrim | Adapted to XBRLspec syntax.
25 November 2007 | Victor Morilla | Split from validation report specification Adapted and included variable, group filter and precondition augmentation
26 November 2007 | Geoff Shuetrim | Modified the definition of a consistency assertion. Changed the consistency-assertion element name to camel case to conform with the naming convention used by other XBRL specifications. Eliminated the default value for the strict attribute on consistency assertions to conform to the broader approach of always being explicit at the syntax level.
03 December 2007 | Victor Morilla | Simplified and adapted to new variables specification Included an acceptance radius as suggest by G.S Included possibility of parameters to determine the acceptance radius as suggested by Herm Fischer.
04 December 2007 | Victor Morilla | Moved assertion-formula relationship to this specification as suggested by Geoff Shuetrim. Removed obsolete comments.
06 December 2007 | Victor Morilla | Included examples. Removed obsolete comments. Description of `@strict` rewritten. References to the definition of the assertion data set.
09 December 2007 | Victor Morilla | Consistency-assertion-formula relationships now used on `<gen:arc>`element. `@aspectModel` attribute obtained from formulae producing fact instead of the assertion resource.
10 December 2007 | Victor Morilla | Adapted to be in the substitution group for assertions (not in the substitution group for variables). General variables associated with assertions removed.
16 December 2007 | Victor Morilla | Changed namespace of consistency assertions from http://xbrl.org/2008/consistency-assertion to http://xbrl.org/2008/assertion/consistency
31 January 2008 | Geoff Shuetrim | Standardised the format of the hyperlinks to the normative schema. Standardised the boilerplate text for errata.
01 February 2008 | Geoff Shuetrim | Changed the acceptance radius from not defined to 100 for the example where the absolute acceptance ratio was set to 100, as suggested by Masatomo Goto. Changed the example stating incorrectly that a consistency assertion is satisfied if the derived fact is nil but the corresponding facts are not.
02 February 2008 | Victor Morilla | Clarified behaviour of zero precision facts consistency checks when acceptance radius is not defined as suggested by Masatomo Goto. In these cases, consistency cannot be verified, and so the assertion is not evaluated.
06 February 2008 | Geoff Shuetrim | Changed the name of the consistency assertion element in the specification text to match the normative schema. Removed obsolete comments. Changed the term "corresponding fact" to the more expressive term "aspect-matching fact". Simplified the explanation of the `@strict` attribute usage. Combined the errors relating to variable-set relationships and consistency assertions. Deleted the tables setting out the aspect tests to use for the aspects defined in the two aspect models set out in the variable specification because that is already done in the variable specification. Moved the definition of an aspect-matching fact to an earlier part of the specification to better clarify the many references to aspect-matching facts. Refined the definition of the assertion data set to simplify the determination of the conditions for consistency. The assertion data set no longer includes nil valued aspect-matching facts. This more closely integrates the `@strict` attribute into the assertion data set definition.
07 February 2008 | Victor Morilla | Removed wrong introductory paragraph from value assertions. Corrected reference to assertion input. Included clarification of the scope of consistency assertion parameters.

# Appendix F Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Formula Working Group up to and including 28 March 2008. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.