Checks four structural invariants over a pasted set of GLEIF Level-2 relationship records for one subject LEI, so an inconsistency in the published graph is visible before it lands in a pack.
GLEIF Level 2ISO 17442RR-CDF 2.1Zero PIIClient-side only
🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
⚠ What a violation means, and what it does not
This flags a possible inconsistency in GLEIF's published Level-2 relationship data for this LEI. It is not an assertion about the entity's actual corporate structure, and not a finding about the entity itself. GLEIF golden-copy data is periodically corrected, so recheck against a fresh golden-copy pull before treating any violation as durable. This is a data-quality check on a published graph, nothing more.
The four invariants
1. Node validity: every startNode and endNode is a syntactically valid LEI (ISO 17442 mod-97). Violation: INVALID_NODE_LEI.
2. No direct-parent cycle: walking IS_DIRECTLY_CONSOLIDATED_BY edges never revisits a node already on the current path. Only active edges are walked, since an ended relationship legitimately points the other way in a later period. Violation: PARENT_CYCLE_DETECTED.
3. Exception-code well-formedness: every reporting-exception code is a published GLEIF category. Violation: UNRECOGNIZED_EXCEPTION_CODE.
4. No overlapping duplicate active edges: no (startNode, endNode, relationshipType) triple has two active records with overlapping validity periods. Adjacent periods that merely touch are not duplicates. Violation: DUPLICATE_ACTIVE_RELATIONSHIP.
Paste in, never fetched
Records are supplied as JSON transcribed from the Golden Copy relationship columns or the RR-CDF XML elements. This page makes zero network calls: it never queries GLEIF and is not a re-implementation of GLEIF's own reconciliation service. An empty record set returns consistent: null, not a clean pass, because nothing pasted is not evidence of consistency.
Presets
Fields per record: start_node_lei, end_node_lei, relationship_type, relationship_status, start_date, end_date, exception_code. Dates are read as an ISO 8601 date prefix; anything else is treated as unbounded on that side rather than coerced.
Result
Execution Hash & §4 Artifact
SHA-256 execution hash (JCS canonical, RFC 8785):
Chain Handoff ← art-599
Pin the underlying golden-copy record with digest_gleif_snapshot (art-599) first, then pass that execution_hash as parent_hashes[0] here so this check is bound to the exact bytes it was run against.