Tools

A standard without tools is not implemented but interpreted – and then the implementations diverge. The tools are therefore part of the standard and not a downstream project.

Principles

  • The working group builds the tools itself, with AI support.

  • Tools are developed and published continuously together with the standard. A version of the standard is not a document but a release consisting of specification and tools.

  • HL7 FHIR serves as the model: implementation guide as a website, validator as library and CLI, public reference servers, conformance suites, conformance register.

  • Self-test, certification and developer validator use the same checking logic. "Green locally, red in certification" destroys trust in the tools.

  • Existing tools are used, not rebuilt. SHACL engines, OpenAPI generators and BPMN tools are available. The working group’s capacity belongs in the standard, the conformance suite and the product model tools.

The sample insurer, MCP server, documentation website and self-tests (see Approach) are already tools in this sense. The following list complements them and is not to be read as a sequence, since the tools are developed alongside.

For the Working Group

OpenAPI, JSON-LD context, SHACL shapes and BPMN models describe the same business domain. Maintained by hand, they diverge.

  • A single source of truth with generation: The OpenAPI schemas are generated from the SHACL shapes, or both from a common description. As a fallback, double maintenance with cross-validation in the CI.

  • Linter for the standard in the CI: Every operation referenced in BPMN exists in OpenAPI, every SHACL shape has a JSON-LD term, naming conventions and mandatory labels are respected.

  • Check of the process variants in the CI: Every permitted variant is modelled in BPMN, has a term in the process knowledge vocabulary and is covered by example instances.

  • Machine-readable diff between two versions of the standard, so that insurers can plan their releases.

  • Canonical example instances for each use case, validated against SHACL and OpenAPI in the CI. They also serve as documentation, test fixtures and a basis for AI agents.

  • Decision log of the working group, so that decisions in the steering committee are traceable and not renegotiated again and again.

For Developers

  • Validator as library and CLI: instance in, conformance verdict with a precise error message out.

  • Sample insurer and sample broker as containers with pre-filled data. A broker developer must be able to work without an insurer, and vice versa.

  • Sample insurer configurable in all permitted process variants. A client must also be testable against an insurer that does not keep the draft application on the server.

  • Official SDKs for Java, .NET and TypeScript. If every implementer generates them, many variants arise.

  • Test data generator based on the SHACL shapes that produces valid and deliberately invalid instances.

  • Mock insurer generated from a product model. This is possible because product knowledge is available declaratively.

For Insurers

  • Self-test with conformance report that states the profiles met and lists the gaps. Runs in the insurer’s CI and as a web interface for non-technical use.

  • Comparison of declaration and behaviour: The self-test checks whether an insurer behaves as declared in its process knowledge. A wrong declaration is more harmful to clients than a missing one.

  • Public conformance register: which insurer meets which profiles, which lines of business, which version of the standard and which process variants.

  • Gap analysis for the wrapper: WSDL and product show which operations of the base profile can be served.

  • Regression check for product models: Does a product change break existing clients?

For Authoring Product Knowledge

Product managers at insurers do not write OWL or SHACL. Without tools for this step, nobody reaches the product knowledge profile, and the core goal of the project is not achieved. This group of tools therefore carries the highest project risk.

  • Converter that creates a draft product model from existing product documentation and tariff documents.

  • Validator that checks a product model for well-formedness and completeness.

  • Simulator that shows which configurations a product model permits, so that product managers can check without developers whether the model matches their product.

For AI Agents

  • MCP server for the standard itself, not just for the services, so that an agent can query the specification during implementation.

  • Machine-readable documentation index on the website of the standard.

  • Agent benchmark: Can an unmodified AI agent that only receives the published artefacts complete a motor insurance application end to end against the sample insurer? This is the measurable form of the goal that the services can be integrated easily with the help of AI.

Prioritisation

  1. Validator with shared checking logic, because everything else builds on it.

  2. Sandbox containers for both sides, because they lower the entry barrier the most.

  3. Source of truth for the artefacts of the standard, because divergence is hard to fix later.

  4. Conformance suite and register, because they make conformance visible and comparable.

  5. Tools for authoring product knowledge, because they decide on the product knowledge profile.

  6. Agent benchmark, because it makes the core goal measurable.

Items 3 and 5 must be tackled before the interface definition is completed, since both are expensive to catch up on later.