Intégration

Vous n'avez pas à construire un moteur de validation.

MirrorMere n'est pas un outil pour écrire du XBRL, mais un moteur qui vérifie que celui que vous avez produit est conforme. Vos écrans, vos processus et vos contraintes de déploiement restent tels quels ; seule la vérification entre à l'intérieur.

Demander une évaluation technique Travailler ensemble

Les intégrations possibles aujourd'hui

Indiqué à son état réel d'avancement.

Rien n'est présenté comme disponible avant de l'être. Ce qui relève de la feuille de route est signalé comme tel.

Disponible

SDK Java

Ajoutez un jar à votre build et appelez-le. Aucun agent, aucun service à faire tourner à côté.

Disponible

CLI et traitement par lots

Un jar exécutable, lancé en ligne de commande ou par un traitement par lots. Il s'insère dans un pipeline que vous avez déjà.

Disponible

Conteneur et déploiement privé

Fonctionne sans contrainte dans un réseau fermé. Rien de vos documents n'en sort.

Sur accord commercial

OEM et marque blanche

Intégrez-le dans la solution que vous vendez déjà, sous la forme qui convient. Les conditions se négocient au cas par cas.

Prévu

API REST

Une API XBRL sur HTTP est prévue pour le second semestre 2026.

MirrorMere reste invisible.

SDK Java

Ce qui revient vous dit où, pourquoi, et quoi examiner.

Ce qui revient n'est pas une liste de codes d'erreur. Chaque constat indique où il se situe dans le document, quelle clause il enfreint, et donc ce que la personne qui tient le dépôt doit examiner. La forme est la même, que ce soit Dimensions ou Inline XBRL qui l'ait attrapé : vous pouvez le lui mettre directement sous les yeux.

ValidationOutcome outcome = validator.validate(report);

for (ValidationFinding f : outcome.errors()) {
    f.code();      // what went wrong
    f.specRef();   // the clause it breaks
    f.location();  // where in the document
}

Un seul appel, et tout ce qu'il faut pour l'examen s'y trouve déjà : où, pourquoi, et quoi corriger.

CLI et traitement par lots

Trois commandes suffisent à tout. Rien d'autre n'est nécessaire.

validate: Vérifie un dépôt. Donnez-lui un paquet de soumission, un jeu de fichiers Inline XBRL ou un document seul : plusieurs fichiers appartenant au même dépôt sont vérifiés ensemble, comme un tout.
cts: Exécutez vous-même les tests standards publiés : en totalité, ou seulement la partie qui vous intéresse. C'est de là que viennent les chiffres de la page certification.
doctor: Vérifie la machine avant que vous ne fassiez confiance à un résultat : les taxonomies sont-elles à leur place, l'environnement est-il sain ? Un fichier manquant ressort ici comme un problème de configuration, et non plus tard comme un feu vert.

Réseaux fermés

Là où il n'y a pas d'Internet, il tourne quand même.

Les équipes finance et audit travaillent souvent sur des réseaux coupés d'Internet. Les moteurs qui vont chercher sur le Web ce qui leur sert de référence s'y arrêtent net. Pire encore : certains continuent en vérifiant moins, sans rien dire. MirrorMere, lui, ne sort jamais.

Les taxonomies sont fournies sous forme de fichiers que vous détenez. Rien n'est téléchargé pendant l'exécution.
S'il lui manque quelque chose, il le dit. Il ne laisse pas passer le document à la place.
Chaque exécution note quelles taxonomies ont servi : si deux machines divergent, on compare au lieu de discuter.
Aucun trafic sortant, d'aucune sorte : ni remontée d'usage, ni vérification de licence.

Si vous utilisez déjà un outil libre

L'open source est un bon choix.

Il existe des validateurs XBRL libres et gratuits, dont certains détiennent la même certification Validating Processor que nous. Si vous ne devez vérifier un dépôt que de temps en temps, ils feront l'affaire. Vendre un produit qui embarque la validation demande trois choses de plus.

Une bibliothèque, pas un programme à faire tourner à côté

MirrorMere est une bibliothèque en pur Java conçue pour vivre dans votre produit : un fichier dans votre build, appelé directement depuis votre code. Aucun processus séparé à maintenir en vie, aucune passerelle à entretenir.

Il y a quelqu'un à qui demander

Quand une spécification évolue, suivre est notre obligation, pas quelque chose que vous attendez. Et si vous bloquez, la question arrive à ceux qui ont écrit le moteur.

Vous n'êtes pas obligé de choisir. Faire tourner les deux et comparer est une démarche raisonnable : quand deux implémentations indépendantes aboutissent au même verdict, cet accord est en soi une preuve.

Engagement sur les normes

Les spécifications bougent sans cesse. Les suivre, c'est notre travail, pas le vôtre.

Versions: Chaque résultat porte la version qui l'a produit. Si une réponse change des mois plus tard, vous pouvez voir ce qui a changé au lieu d'en débattre.
Suivi des spécifications: Quand une spécification ou sa suite de tests est révisée, toute la suite est rejouée avant toute publication.
Support: Un contact technique direct avec ceux qui construisent le moteur, sans file de tickets pour les précéder.
Déploiement: Le déploiement sur site et en réseau fermé est le cas normal, non une exception à négocier.
Licence d'évaluation: Une licence couvrant toute la durée de l'évaluation, sans limite de postes ni de volume pendant vos tests.
Licences tierces: Les bibliothèques tierces et leurs licences sont livrées avec le produit, prêtes à être transmises telles quelles à votre service juridique.

La chasse au « pourquoi » disparaît.

Commencez ici

Dites-nous ce que vous construisez.

Dites-nous ce que vous construisez et où ça bloque, et nous le démêlerons avec vous. C'est cela qui vaut d'être acheté, pas le fichier.

Vous recevez le moteur, l'exécuteur en ligne de commande et l'outillage de test — le build que nous utilisons nous-mêmes.
Lancez-le sur vos propres dépôts, pas sur un échantillon que nous aurions choisi.
Tous les chiffres de ce site sont à reproduire : les suites sont publiques et l'exécuteur est dans le paquet.
Un accord de confidentialité d'abord, avant que quoi que ce soit ne circule.

Vous préférez l'e-mail ? Écrivez-nous directement. manager@codebplat.co.kr