It does not flag things without grounds
Every finding arrives with the clause it rests on. If no clause is broken, it says so. That is time your team does not spend chasing down whether a warning was real.
Product
Every finding comes with the reason and the fix.
MirrorMere is the XBRL validation engine that runs inside the product you already sell. Every finding carries where it is, which clause it breaks, and what to change.
Ontology and Why Path
“Why” is possible because XBRL itself is an ontology here.
A validator that only returns error codes cannot explain itself. MirrorMere ties concepts, rules, errors and clauses into one ontology and reasons over it with SHACL, so the path the reasoning took is the reason: what went wrong, why, and what to change come out at once. That path is what you see as Why Path.
ixbrlo:illegalMultipleUseOfId
a owl:Class ;
rdfs:subClassOf ixbrlo:ValidationError ;
rdfs:comment "id attribute reused across iXBRL elements that require uniqueness."@en ;
skos:note "Inline XBRL 1.1, Section 3 — ixe:illegalMultipleUseOfId"@en ;
skos:note "Inline XBRL 1.1, Section 4 — ixe:illegalMultipleUseOfId"@en ;
owl:equivalentClass <http://www.xbrl.org/2013/inlineXBRL/errors#illegalMultipleUseOfId> .The vocabulary is the W3C standard one; the last line points at the error identifier XBRL International publishes. Nothing here is a name we invented.
Input
The file being validated.
Rule
The XBRL 2.1 §3–§5 checks that ran.
Clause
Two violations, both bound to XBRL 2.1 §5.1.3.4.
What to fix
The role http://xbrl.org/role/conformance cannot be used on link:label.
That last line is the whole point: it names the fix, not just the failure.
Results you can rely on
When this engine says it passed, it passed.
A validation result ends up as the grounds for an audit or a submission. So two things matter: the answer must not wobble, and “passed” must actually mean passed. Nothing here guesses or answers by probability — put the same document in a hundred times and you get the same answer a hundred times.
It never calls unchecked “passed”
A check it could not run is reported as not executed and counted apart from the passes. Nothing slips through in silence, so you can take a clean result at face value.
An upgrade will not change your answers
The standard test suites run on every build, and a change that breaks even one of them never ships. Taking a new release does not overturn what you concluded last month.
- Version that produced it
- Ties any result back to the exact build that produced it.
- Runtime and platform
- Tells you whether a difference came from the environment rather than the document.
- Which taxonomies were read
- Lets two sides confirm in one line that they were looking at the same taxonomies.
- Files it could not find
- If this is not zero, that much was left unchecked — and it says so rather than passing quietly.
Run it again. Same answer.
Validation core
One module per specification.
Every specification is a separate module. Take the whole engine, or take only the ones you actually deal with.
| Specification | What it checks |
|---|---|
| XBRL 2.1 Core | Whether figures, periods, units and concept definitions hold together |
| XBRL Dimensions 1.0 | Whether breakdowns such as segment or region are combinations the taxonomy allows |
| XBRL Formula 1.0 | Whether the extra calculation and business rules set by the company or regulator hold |
| XBRL Table Linkbase 1.0 | Whether the report comes out in the table layout the regulator prescribed |
| Inline XBRL 1.1 | Whether what a reader sees and what a machine reads say the same thing |
| Open Information Model 1.0 | Whether the same content keeps its meaning across XML, JSON and CSV |
| Extensible Enumerations 1.0 / 2.0 | Whether a field meant to be chosen from a fixed list really holds a value from it |
| Report Packages 1.0 | Whether the submission bundle is packed the way the rules require |
| Taxonomy Packages 1.0 | Whether a taxonomy package is packed correctly and resolves without internet access |
| Units Registry 1.0 | Whether units such as currency, shares and percentages follow the standard register |
| Link Role Registry 1.0 | Whether the roles used are the ones published in the standard register |
| Transformation Rules Registry v3 / v4 / v5 | Whether “1,234” or “March 2025” on the page converts into the data value the rules prescribe |
Calculation 1.1 comes with the core. Whichever set you pick, the findings all come back in the same shape.
Pure Java and performance
The whole standard test suite finishes in about 20 seconds.
Pure Java — no native code, nothing extra to install. And still quick enough to run the whole suite inside your build. Not once per release: every time you change something.
100%
of the XBRL International test set passed
~20s
to run the whole set
0
things to install alongside it
Timings vary by machine; what matters is the order of magnitude, not the exact number. The tests are published, so you can measure it on your own hardware.
Java 17 or later
If a JVM runs there, this runs there. Nothing else to install, no native libraries in the box.
Evaluation
Start with your own filings.
The fastest way to judge an engine is to point it at documents you already know the answer for.