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-matched input 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 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/2008/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 input 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-matched input fact for a derived fact is a fact in the assertion input used to produce the derived fact that is aspect matched to the derived fact.

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-matched input facts.

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

Example 2:


      @strict

attribute usage

`@strict` attribute	Facts in input 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 in the @proportionalAcceptanceRadius 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 consistency-assertion parameters and the variables in the variable set defined by the formula being evaluated 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 Consistency assertion 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 Consistency-assertion-parameter relationships

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

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

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

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

Consistency-assertion-parameter relationships MUST be expressed by variable 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].

Just as for variable-set relationships the value of the @name attribute on a variable arc is the QName of the parameter in the consistency-assertion-parameter relationship expressed by the arc. When computing the acceptance radius for a consistency assertion, XPath variable references with this QName are references to the parameter. Note that this parameter name MAY differ from the name given in the parameter declaration.

All consistency-assertion parameters MUST be evaluated before the acceptance radius of the consistency assertion is evaluated.

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

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

A consistency-assertion parameter is any parameter that has a consistency-assertion-parameter 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-matched input facts in the input XBRL instance that do not have nil values. Note that there may be no aspect-matched input facts in the input 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-matched input 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-matched input facts is zero.

If a derived fact is not valid, based on the XBRL Specification [XBRL 2.1], then the assertion is deemed to be not satisfied, regardless of the aspect-matched input facts in the assertion data set.

If an assertion data set contains aspect-matched input 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.

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-matched input fact that it is being compared to are not consistent.

Example 4: Consistent values

Derived fact		Aspect-matched input fact		Acceptance radius	Assertion evaluation
Inferred precision	Value	Inferred precision	Value	Acceptance radius	Assertion evaluation
-	`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-matched input 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-matched input 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:

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.
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.

<link:definition>

assertion based on formula

</link:definition>

<link:usedOn>

gen:arc

</link:usedOn>

</link:arcroleType>

<link:definition>

acceptance radius depends on parameter

</link:definition>

<link:usedOn>

variable:variableArc

</link:usedOn>

</link:arcroleType>

</appinfo>

</annotation>

</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"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See ../../formula/CR-2008-12-31/formula-CR-2008-12-31.html)
GENERIC LINKS: XBRL International Inc.. "XBRL Generic Links 1.0"
Mark Goodhand, Ignacio Hernández-Ros, and Geoff Shuetrim.
(See ../../gnl/PR-2009-03-31/gnl-PR-2009-03-31.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 Validation 1.0"
Victor Morilla, and Geoff Shuetrim.
(See ../../validation/PR-2009-03-31/validation-PR-2009-03-31.html)
VARIABLES: XBRL International Inc.. "XBRL Variables 1.0"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See ../../variables/PR-2009-03-31/variables-PR-2009-03-31.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-2008-07-02.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.
09 April 2008	Geoff Shuetrim	Corrected the typo in the explanation of the XPath expression for proportional acceptance radii. This typo was identified by Takahide Muramoto.
04 June 2008	Geoff Shuetrim	Removed the redundant word "considering" in the first part of the first example. Renamed the factVariablesNotAllowed error code to variablesNotAllowed to reflect the fact that both fact and general variables are not allowed to be the targets of relationships from consistency assertions. Defined a new relationship and syntax for expressing the relationship from consistency assertions to their parameters. This is required to eliminate erroneous references to consistency assertions as variable sets. It does not alter the capabilities of the specification. This problem was identified by Victor Morilla.
05 June 2008	Geoff Shuetrim	Removed the unnecessary word "Fact" from the section heading for the various relationships defined in this specification. Made hyphenation of the term "consistency-assertion parameter" consistent throughout the text of the specification.
26 June 2008	Geoff Shuetrim	Added the variables in the variable-set of the formula being tested to the context used for evaluation of acceptance radii. This enhancement was suggested by Victor Morilla.
13 August 2008	Geoff Shuetrim	Removed un-necessary schema limitations on undirected cycles in relationship networks.
26 September 2008	Geoff Shuetrim	Modified "aspect-matching fact" term to "aspect-matched input fact to leverage a new definition in [VARIABLES]. Made explicit the outcome of assertion testing when the derived fact is not a valid XBRL fact. In such cases, the assertion is deemed to be not satisfied.
26 September 2008	Geoff Shuetrim	Fixed the id on the definition of consistency-assertion-parameter relationships to ensure internal links within the specification work.
15 December 2008	Geoff Shuetrim	Updated references to the latest errata-corrected version of the XBRL 2.1 specification.
19 March 2009	Geoff Shuetrim	Changed the term "target XBRL instance" to "input XBRL instance". Ensured that all usages of the terms input XBRL instance and output XBRL instance reference the term definition.

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 31 March 2009. 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.

Consistency Assertions 1.0

Proposed Recommendation 31 March 2009

Status

Abstract

Table of Contents

Appendices

Table

Examples

Definitions

Error codes