Product, taxonomy, and jurisdiction support

Product version

These English articles cover SolvencyBridge product version 2026.8.1. Documentation is maintained for the current minor product line; behavior from an older deployment must be checked against its own release materials.

Taxonomy support

Support is determined by the taxonomy packages installed in the deployment. A filing pins a package version. Check its version, checksum, module/template catalog, and disclosed validation coverage. The synthetic SOLVENCY-II-PILOT-FIXTURE package is not authoritative.

The filing migration control offers only installed newer releases from the same taxonomy family. Creating a successor re-runs validation and records migration evidence, but does not establish that a national profile supports the target release. Confirm the profile/release row and every required capability in the coverage catalog separately.

Jurisdiction support

The product contains authority profiles for multiple European jurisdictions, but capabilities vary by profile and release. A profile can have any combination of identity fields, forms, validations, export formats, readiness evidence, receipt recording, or portal-status interpretation.

The public coverage page expands each profile into separate taxonomy, validation, native-export, package, transport, signing, submission-test, receipt, and authority-acceptance rows. Each row shows its own status, explicit blocker when evidence is missing, and evidence refresh date. A partial transport or acceptance row does not downgrade an independently verified taxonomy row. The Ready for submission state always requires verified taxonomy, validation, native export, and package evidence. A profile can declare an additional pre-submission requirement when the pinned authority workflow requires it. Slovakia NBS and Czech CNB currently also require verified signing evidence. Submission testing, receipt, and authority acceptance remain later lifecycle evidence and cannot be used as readiness prerequisites. The downloadable catalog also exposes the exact taxonomy checksum, complete form-code inventory, common validation-rule count, national validation status, package state, known limitations, and source freshness for every profile and release.

Catalog schema version 2 adds a solvencyIIReview2027 record for every jurisdiction profile. For EU profiles it distinguishes not observed, no notified measures listed, and official measures notified. For Iceland, Liechtenstein, and Norway it separately records EEA incorporation and national implementation. Official notification is an operational evidence gate; it is not a claim that transposition is complete, correct, legally sufficient, or verified by the European Commission.

A 2.10.0 filing may be created for preparation after an explicit, checksum-bound confirmation when national evidence is incomplete. That confirmation never satisfies taxonomy, validation, native-export, package, signing, transport, submission-test, receipt, or authority-acceptance evidence. Export and authority-package generation continue to fail closed until the current legal and authority gates pass.

The public profile inventory is pinned to a dated baseline. Adding a profile after that baseline fails closed until a partner-approved representative filing dossier and checksum-bound, passed regression evidence cover the new profile. Synthetic samples can verify the gate itself but cannot qualify a profile for publication. Every baseline profile/release row also exposes its publication-evidence backfill state. A baseline exemption preserves an existing row; it is not representative-filing evidence. Missing, unbound, or stale dossier regression evidence remains an explicit blocker and is preferred as the row's next evidence action.

Commercial commitments for the Slovakia and Czechia anchors are recorded separately from implementation status. An absent commitment is not presented as a promise. A recorded commitment names exact capabilities and cannot pass the coverage verifier unless each capability is independently verified for the exact profile and release. A non-empty commitment ledger must not postdate the coverage assessment, and an overdue review blocks publication until the promise is reconfirmed or removed.

Jurisdiction status measures whether everything officially published and applicable at the evidence date is implemented and verified. It is separate from successor-release availability. The downloadable coverage catalog records the latest supported release, successor status, evidence date, refresh deadline, national-form state, and export state. A successor marked not_published, partially_published, or authority_unavailable is never reported as implemented merely because the common EIOPA taxonomy is bundled. An export is partial when a published national form or authority-native artifact is not fully implemented, and not_available when the authority has not made the release applicable.

For every partial jurisdiction, the catalog includes an implementation blocker with the exact published requirement, missing authority artifact or safe tool, evidence date, refresh deadline, and reopening trigger. A partial state without that blocker record is rejected by the coverage verifier.

Export completeness is independent of jurisdiction-taxonomy completion. A taxonomy-complete profile can therefore have exportState: partial when an authority-native filename, binding set, signing artifact, or packaging contract is unavailable. The catalog includes an exportBlocker for every such state; common EIOPA export availability is not presented as proof that every required national artifact can be produced. NBS and FMA Austria currently identify the missing authority-artifact publication as partially_published; this does not make their implemented jurisdiction taxonomy partial.

How to verify support

1. Select the exact reporting entity, period, taxonomy, and jurisdiction.
2. Read the controls and limitations shown for that filing.
3. Inspect the installed release provenance and validation coverage.
4. Obtain current authority instructions and approved downstream acceptance evidence.
5. For 2027 periods, inspect solvencyIIReview2027, including its legal path, evidence date, refresh deadline, source checksum, and blockers.
6. Treat an absent capability or evidence record as unsupported, not implied.

Boundary

Profile presence is not authority endorsement. Support for preparation does not automatically include authority-native export, transport, or acceptance verification.