News / public record

Checking
  1. Update / Component / Readiness · CheckingOpenLegalCore Word Connector public launch is completeThe Apache-2.0 v0.1.0-beta.1 source-only release now has a complete public component record, homepage feature, Roadmap outcome and discovery path.
  2. Update / Component / Release · CheckingOpenLegalCore Word Connector v0.1.0-beta.1 is publicThe Apache-2.0 source-only beta brings verified Slovenian legal-source research into Word for the web through OLC Engine, directly or through Open WebUI.
  3. Article · CheckingLegal RAG Can Fail Before the Model AnswersA genuine provision can still support the wrong answer. This article shows how collection scope, document splitting, filters and ranking determine which sources a legal AI model ever sees.
  4. Article · CheckingWhen a Correct Citation Leads to the Wrong LawA genuine provision and an official link do not prove that the right law was applied. This article explains why legal AI must preserve temporal versions, transitional rules and the source-selection path.
  5. Update / Project · CheckingPublic project foundation gate is completeOpenLegalCore has completed its public project foundation gate: core public routes, bounded participation channels and publication controls are operating.
  6. Article · CheckingAn Audit Trail Is Not a Log: What a Digital Legal Process Must PreserveAn audit trail is useful when it permits a reasonable reconstruction of the particular process while remaining purpose-bound, appropriately protected and subject to retention rules.
  7. Article · CheckingArticle 86 of the AI Act: Does the right to explanation already apply to Annex III systems?The legal question remains open. The technical capacity to provide an intelligible explanation should not.
  8. Update / Project · CheckingPrivate security reporting is now availableOpenLegalCore now provides a monitored project-wide private channel and a canonical security-reporting policy.
  9. Update / Component / Release · CheckingSlovenian Case Law Pipeline v0.1.7 is publicOpenLegalCore has published the production-verified Slovenian case-law ingestion component as a source-available BUSL-1.1 release.
  10. Article · CheckingA Result Is Not a Method: Why Visible Methods Matter in Legal AIWhy legal AI needs inspectable sources, provenance and human review: a legal and technical analysis of the EU Artificial Intelligence Act and GDPR.
  11. Update / Component / Release · CheckingSlovenian Legislation Pipeline v0.1.0 is publicOpenLegalCore has published the production-verified PISRS legislation-ingest component as a source-available BUSL-1.1 release.
  12. Update / Component / Release · CheckingLegal OCR Pipeline v0.1.2 is publicThe first public OpenLegalCore component is available with code, tests, offline review tooling and a bounded acceptance record.
Explore the code
Menu
Component register

COMPONENT 03 / PRIVATE · RELEASE GATE · v0.1.0

Slovenian Legislation Data Snapshots

A carefully curated and regularly maintained legislation data foundation.

Start with source-linked acts and consolidated texts already normalised in PostgreSQL and indexed in Qdrant. The inspectable Slovenian Legislation Pipeline maintains this foundation for independent legal products, semantic-search portals, research workflows or OLC Engine. Approved partners receive private access under individually agreed terms.

The public pipeline documents how records are acquired, structured and maintained. Each partner agreement defines attribution, intended use, delivery and any required support; those data terms are separate from the pipeline software licence.

Status
PRIVATE · RELEASE GATE
Partner download
AVAILABLE
Maintenance
SCHEDULED NIGHTLY
Public download
NOT OFFERED
  1. 01

    Curated from PISRS

    Source-linked acts and consolidated texts are normalised, structured and kept traceable.

  2. 02

    Scheduled maintenance

    The reviewed deployment checks and advances maintained state through controlled nightly runs.

  3. 03

    Standalone by design

    Use it for an independent portal, research workflow, legal product or OLC Engine.

  4. 04

    Private partner delivery

    Approved partners receive private data delivery without a public repository dump.

01 / VALUE

Begin with legal data already made operational.

Building useful legislation search begins long before the search box. This data product removes the need to repeat the initial acquisition, normalisation, structuring, chunking and embedding run—and keeps that foundation maintained afterwards.

STANDALONE DATA PRODUCT

Use the foundation without adopting the whole OpenLegalCore system.

The maintained data layers can serve an independent portal, an existing legal product, a private research environment or OLC Engine. Its value is the maintained legal-data layer itself—not dependency on one interface or application.

Delivery
PRIVATE DOWNLOAD
Audience
APPROVED PARTNERS
Maintenance
SCHEDULED NIGHTLY
Integration
STANDALONE OR OLC

02 / USES

Build the legal experience on top of a maintained corpus.

The same prepared foundation can support a public-facing product or a controlled internal workflow. Partners retain responsibility for their application, retrieval behaviour, user experience and legal operating context.

  1. 01

    Launch a semantic legislation portal

    Start from a maintained corpus and retrieval index while concentrating product work on search experience, ranking and editorial context.

  2. 02

    Add legislation to a legal product

    Integrate source-linked Slovenian acts and consolidated texts into an existing legal research, knowledge or professional workflow.

  3. 03

    Support private legal research

    Operate a controlled internal corpus for semantic retrieval, exploration and evidence-led legal analysis.

  4. 04

    Bootstrap OLC Engine

    Restore a prepared legal-data foundation beneath a compatible OLC Engine deployment and verify the package manifest before use.

03 / CURATION

Curated means a controlled, inspectable data process.

Curation here is operational: source-linked acquisition, stable act and document identities, structured versions, deterministic chunks, field checks, change maintenance and bounded PostgreSQL–Qdrant reconciliation. It does not claim that a lawyer has reviewed every text, that technical latest means legally valid, or that the corpus exactly mirrors PISRS.

  1. 01Official source

    PISRS legislation records

  2. 02Legislation Pipeline

    Acquire · normalise · maintain

  3. 03Maintained data layers

    PostgreSQL · Qdrant · delivery record

  4. 04Partner system

    Portal · product · research · OLC

  1. 01

    Source-linked acquisition

    Supported routes retain source identity and provenance instead of becoming an anonymous text dump.

  2. 02

    Stable act and document identity

    Register IDs, text IDs, content hashes and deterministic identifiers make change reviewable.

  3. 03

    Act–version structure

    Act metadata, consolidated texts, versions and source dates remain separately usable and traceable.

  4. 04

    Article-aware structure

    Blocks and search chunks are derived reproducibly with structural context rather than as an opaque one-off index.

  5. 05

    Nightly change maintenance

    Successful scheduled runs advance maintained PostgreSQL state while failed runs retain the last checkpoint.

  6. 06

    Bounded reconciliation

    The derived Qdrant layer is checked against authoritative state and remains rebuildable.

04 / CORPUS

A substantial maintained state, measured and bounded.

The current fact record measures authoritative operational PostgreSQL state and the derived Qdrant index. Counts below were read on 4 SEPTEMBER 2026 · 17:11–17:18 CEST; individual partner delivery details are governed by the relevant partnership agreement.

Act records
64,924
Consolidated-text versions
71,372
Structured blocks
13,576,374
Qdrant points
278,146

CORPUS COMPOSITION

Sklep
13,221
Pravilnik
13,009
Uredba
8,083
Zakon
7,826
Drugo
5,237
Remaining 28 source categories
17,548

DATA QUALITY / MEASURED AND BOUNDED

Complete where required. Explicit where source data varies.

Core identities, source text and provenance are complete across the measured state. Source-dependent metadata remains explicit rather than silently invented.

Act core
64,924 / 64,924Every act keeps its core identity.

Stable act ID, source title and source act type are present across the measured act state.

Text + provenance
71,372 / 71,372Every maintained text remains source-linked.

Each consolidated-text version retains its document identity, source URL and normalised text.

Direct act link
71,020 / 71,372Known linkage exceptions remain traceable.

The remaining 352 versions retain their NPB catalogue path rather than disappearing from the record.

SOURCE-DEPENDENT METADATA / NOT SILENTLY IMPUTED

Source fields vary. The record does not pretend otherwise.

SOP is present on 60,430 of 64,924 acts, adoption date on 60,141, and publication date on 60,410. The measurement does not establish whether each absent value is unavailable at source, not applicable or an ingestion gap, so the database preserves the absence rather than inventing a value.

Indirect act links
352Retained through the NPB catalogue path
Document dates absent
16Explicitly absent from the measured state

Coverage describes populated technical fields in the measured PostgreSQL state. It does not prove legal completeness, legal correctness or current legal validity.

05 / DATA LAYERS

Authoritative records and a rebuildable semantic index.

PostgreSQL and Qdrant are delivered together for compatible deployments, but they do not have the same authority. PostgreSQL governs maintained operational state; Qdrant is the derived retrieval layer that can be reconciled or rebuilt.

POSTGRESQL / AUTHORITATIVE OPERATIONAL STATE

The maintained legal-data state.

Source-linked records, normalised legal fields, content hashes, change state and deterministic chunks remain anchored in the database archive.

PG_DUMP · CUSTOM FORMAT

QDRANT / DERIVED

The corresponding semantic retrieval state.

Vectors and payloads accompany the package for semantic search while remaining a repairable derivative of the authoritative PostgreSQL state.

COLLECTION SNAPSHOT · 3072D COSINE

MEASURED STATE + PARTNER HAND-OFF

Measured state. Defined terms with every delivery.

The reviewed deployment contained 278,146 expected point identities in PostgreSQL and an exact Qdrant count of 278,146 on 4 September 2026. Delivery scope, permitted use, attribution and support are then defined with each approved partner.

Delivery scope
PARTNERSHIP-SCOPED
Source reference
RECORDED
PostgreSQL archive
INCLUDED
Qdrant snapshot
INCLUDED
Schema + versions
DOCUMENTED
Record + vector counts
DOCUMENTED
Attribution
AGREED PER PARTNERSHIP
Permitted use
AGREED PER PARTNERSHIP
Delivery + support
AGREED PER PARTNERSHIP

PostgreSQL and Qdrant returned the same aggregate count. A point-by-point identity and payload comparison was not part of this measurement. These measured deployment counts do not define the contents or watermark of every partner delivery.

06 / ACCESS

Private access begins with a data partnership.

The maintained PostgreSQL state and derived Qdrant index are available to approved partners as a private download. Partnership review aligns the intended deployment, technical fit, attribution, permitted use, delivery and any required support. The maintained database is not distributed through GitHub or as an anonymous public download.

FROM ENQUIRY TO DOWNLOAD

  1. 01

    Describe your deployment

    Tell us what you are building, how the data will be used and where it will operate.

  2. 02

    Review fit and terms

    We agree technical fit, attribution, intended use, delivery and support terms with you.

  3. 03

    Receive partner access

    Once scope and terms are agreed, the current private package is made available for download.

CURRENT ACCESS STATE

Status
PRIVATE · RELEASE GATE
Partner download
AVAILABLE TO APPROVED PARTNERS
Public download
NOT OFFERED
Maintenance
MAINTAINED NIGHTLY
Terms
PARTNERSHIP TERMS

The maintained state advances after successfully completed scheduled synchronisation. If a run does not complete, the last successful state remains in place. Attribution, intended use, delivery, operating expectations and support are agreed in an individual data partnership.