ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

— Position statement

Conduit

Conduit is the working name of ediverse's future EDI architecture pattern catalogue, scheduled for V5+. This page exists today to set the frame: what ediverse considers covered (the 5 patterns published today), what ediverse will cover (Conduit), and what ediverse will never cover — so it stays ediverse rather than turning into something else.

What ediverse considers in-scope for Conduit

  • Deeper coverage of the 5 current patterns. Real (anonymised) case studies from major retailers, automotive OEMs, PEPPOL Access Points. Observed metrics, observed MTTRs, audit-found anti-patterns.
  • 10 to 15 additional patterns centred on operations: distributed monitoring (golden signals applied to EDI), accounting reconciliation, partner onboarding, catalogue management, mapping versioning, blue/green deployment of a mapping.
  • Sectoral reference architectures. PEPPOL Access Point reference, automotive EDIFACT platform reference (Stellantis, VW), HIPAA provider reference, cXML operator reference (Ariba/SAP Business Network).
  • Integration patterns with LLMs and agents — assisted mapping, conversational validation, automatic DocOps generation from the canonical model.

What ediverse will not cover

  • Concrete implementations in proprietary code. ediverse documents patterns, not vendor solutions. Mulesoft, Boomi or Workato code is not on the menu.
  • Competition with OAGi or OpenPEPPOL. These bodies publish official canonicals — ediverse documents them and links out, but will not try to ship a competing standard.
  • SaaS platform or proprietary tool. ediverse stays an open-knowledge editorial platform, not a product. Patterns come with browser-side diagnostic tools (validators), not an execution runtime.
  • Bespoke advisory or vendor benchmarks. Published content is generalist and public; platform audits or vendor shortlists are outside the ediverse scope.

Why "Conduit"?

A conduit, in both English and French, denotes the flow channel between two spaces — a deliberately neutral term that describes what an EDI integration system actually does: channel business messages between different organisations without prescribing the semantics. The name avoids product or platform language and signals that ediverse writes about architecture, not about tools.

V5+ may rename the section if a better label emerges. For now, Conduit serves as a marker.

Reading list while you wait

  • Hohpe G., Woolf B. — Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley, 2003). The reference catalogue underpinning nearly every pattern in this section. enterpriseintegrationpatterns.com
  • Fowler M. — Patterns of Enterprise Application Architecture (Addison-Wesley, 2002). For ERP-side application patterns that complement integration patterns.
  • Newman S. — Building Microservices (2nd edition, O'Reilly, 2021). The inter-service resilience chapters transpose directly to EDI flows.
  • Kleppmann M. — Designing Data-Intensive Applications (O'Reilly, 2017). The replication and eventual consistency chapter clarifies idempotency questions in EDI.
  • Google SRE Book — the monitoring and incident response chapters are free and directly applicable to EDI escalation matrices. sre.google/books
  • OAGi BODs documentation — for those who want to adopt a standard canonical rather than build one. oagi.org
  • OASIS — AS4 Profile of ebMS 3.0 v1.0. Although centred on transport, this document is also an excellent "just-enough" design example worth studying. docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile

Cross-navigation