News / public record
CheckingPage map
01 / 10OpenLegalCore / legal-tech infrastructure
Open-source components. A private, reviewable system core.
Inspect the code. Control the deployment. Verify the method.
OpenLegalCore develops a legal AI engine adapted to the law of each jurisdiction, together with the components around it. It connects GOVERNMENT WEBSITE / GOVERNMENT OFFICE FOR LEGISLATIONPISRS — Legal Information System of the Republic of SloveniaA government website providing access to legislation, case law and other legal information from Slovenia and the EU. It is administered by the Government Office for Legislation. Unofficial consolidated texts make legislation easier to consult, but are not official publications. PISRS also provides access to authentic electronic editions of the Official Gazette of the Republic of Slovenia from 1 March 2026.Open PISRS , OFFICIAL SOURCE / SUPREME COURT OF THE REPUBLIC OF SLOVENIASlovenian case lawSlovenia's authoritative national public case-law collection, published through the judiciary's official service administered by the Supreme Court of the Republic of Slovenia. It is the complete public corpus available through that service; statutory publication rules do not require every decision issued by every Slovenian court to appear.Open the official collection and private documents into controlled, traceable workflows whose operation and results remain open to human verification.
Component relationships · not a release sequence
Who OpenLegalCore is for
OpenLegalCore components are independently governed building blocks. They can be inspected, challenged and—where status and access allow—combined for a defined legal or administrative process.
Read public code and component records, reproduce tests, trace interfaces and contribute implementation, documentation or evaluation work. Private access begins only with a named component and a defined task.
Inspect public repositoriesExamine how the system treats authority, applicable dates, evidence, provenance, matter state, analysis, uncertainty and human review. Legal expertise can strengthen the method without becoming a code-only contribution.
Review the legal methodDefine one legal or administrative workflow and the components it may require. Purpose, data, authority, security, review, licensing and publication boundaries are agreed before any integration, evaluation or pilot begins.
Review deployment patternsReuse boundary / a reusable component is not a universal solution. Fitness, access and responsibility remain use-specific.
Why open / why this core exists
Open code is only the beginning.Legal infrastructure must preserve an inspectable record from source to use: what entered the system, how it was transformed, which limits apply, what human review covered and who remains responsible.
The standard /
For OpenLegalCore, a legally material result is incomplete unless its sources and transformations can be traced, its method reviewed, its stated limits challenged, its human-review status recorded and responsibility for its use kept explicit. That inspectability is an engineering requirement—not a claim that open software makes the result correct.
The accountability record / five elements
01Source
02Transformation
03System limits
04Human review
05Responsibility
Across the record / four obligations
Code, methods, source handling and the scope of each claim must remain examinable within their stated access boundaries. Openness does not prove correctness; it makes unsupported claims easier to detect.
Institutions must be able to choose their infrastructure, models and deployment boundary instead of making legal documents and system behaviour dependent on one opaque service.
Within OLC, OCR, legal-data pipelines, extraction and orchestration must remain separately governed, reusable components that can be inspected, tested, adapted and improved—not rebuilt behind closed interfaces.
Legally material output must remain traceable, reviewable and contestable. A system may support a decision; the person or institution making it remains responsible.
Required outcome /
Every legally material claim must remain connected to its sources, transformations, stated limits, review status and responsible person or institution.
Inspect component recordsSYSTEM CORE / ACTIVE DEVELOPMENT
The cognitive architecture of legal work.
OLC Engine is being built as OpenLegalCore's general-purpose legal cognition core. It brings maintained legal sources, matter context, specialist legal functions and controlled drafting into one inspectable architecture. Slovenia is its first reference jurisdiction, not its product boundary.
Open the engine recordREFERENCE ARCHITECTURE / SIX FUNCTIONAL LAYERS
The diagram shows the full reference architecture, including functions in development and planned functions.PISRS, Slovenian case law and controlled matter documents.
Case Memory and task-specific context.
Rules, retrieval and specialist calculations.
Bounded Analyzer and Strategist functions.
An optimised Writer with reviewable output.
Workspace, compatible client or embedded workflow.
Working foundation
Active development
Planned functions
Engine deployment / Interface optional
OLC Engine does not require a web interface. It can run as a standalone service, API or workflow node inside infrastructure controlled by the organisation.
Its source, retrieval, model-provider and review boundaries can be adapted to a bounded legal or administrative process under separately agreed implementation terms.
Propose a defined pilotRun the engine as a service inside an existing internal legal or administrative system. A web interface is optional.
Use a bounded engine in high-volume claims work in a law firm or insurer, with process-specific rules, documents and review.
Embed the engine in a defined public-administration workflow for draft-decision preparation while keeping sources and human responsibility explicit.
Connect existing databases, document stores, PostgreSQL environments, retrieval pipelines and vector infrastructure, including Qdrant.
Document access, data movement, model-provider routes, review obligations and operational ownership.
Illustrative boundaryThese are deployment patterns, not customer, partner or production-deployment references.
Engineering boundarySecurity depends on the complete operating environment: access control, updates, secrets, backups, network isolation and the selected model-provider path.
Interface + client boundary
One verified reference path is kept separate from the named clients still under evaluation. Tested versions, interface surfaces and claim boundaries are documented in the full record.
View the full compatibility recordInterface surface
GET /v1/models · POST /v1/chat/completions · Bearer auth · SSE and non-streaming responses.
Reference client
The current verified reference client through the direct engine endpoint.
First-party interface
A planned matter-centred web and desktop workspace for uploaded or permissioned local files, evidence, AI Notes and verifiable sources.
Evaluation paths
Named-version capability tests remain pending.
Claim boundaryOpen WebUI is the current verified reference client. LibreChat, Jan, Onyx and LobeChat remain named evaluation paths; inclusion does not imply verified compatibility with a tested version.
Component map / Access disclosed
The register follows the system from its orchestration core through authoritative legal data, document intake and structured facts to interfaces and connectors. Release order remains a separate roadmap question.
Licence boundaryCode, data, documentation and brand rights are decided separately for each component. No project-wide licence should be inferred from this register.
Legal AI / traceability contract
A legally material result is incomplete unless the system can show its authoritative source, applicable version, retrieved passage, model and provider route, stated limits and human-review status. Together, these elements form its chain of custody.
Reference modelRequired behind every legally material output
Featured component OpenLegalCore Word Connector PUBLIC BETA / SOURCE CODE · v0.1.0-beta.1
OpenLegalCore Word Connector
Ask freely—or start with exactly what you selected.
Word Connector returns source-linked analysis beside your draft. Review the answer and its sources; nothing changes in the document without your approval.
The add-in source code is public; access to OLC Engine is not included.
Milestones and conditions for further development
Below are completed milestones, work in progress and the longer-term direction. The dates refer to releases already published. Further releases depend on each component’s conditions, not on a promised deadline.
View the full roadmapIdentity, release discipline and the public/private boundary are defined. Component licences remain component-specific.
The AI-native OCR pipeline, offline review tooling and canonical acceptance record are public under APACHE-2.0.
The source repository and canonical acceptance record are public; the source filing and generated acceptance artefacts remain private and outside the package.
The project home, canonical registers, contribution paths, monitored security channel and publication controls are operating.
Open focused RFCs and contribution work, then grow reviewer, maintainer and partner relationships through trust.
Three further public outcomes are recorded: Slovenian Legislation Pipeline v0.1.0, Slovenian Case Law Pipeline v0.1.7 and OpenLegalCore Word Connector v0.1.0-beta.1. Together with Legal OCR Pipeline, OpenLegalCore now has four public components. Selective opening continues component by component; every private or gated component retains its own release gate.
The source repository is public; PISRS credentials, legislative text and legislation data snapshots remain outside the package and behind separate access and release boundaries.
The source repository is public; case-law records and data snapshots remain behind their separate release gate.
The Apache-2.0 source-only beta, documentation, tests and Word-for-the-web evidence are public. It includes no hosted OpenLegalCore service, production backend, legal database, protected staging access or Office Store distribution; Word for Windows and Word for Mac remain untested.
Build stable releases, active maintainership, verified uses and sustainable support for shared infrastructure.
Governance / Operating truth
OpenLegalCore begins with founder-led governance. Public discussion is welcome; product direction, access, releases and the project identity retain clear accountability.
Public foundation
Working software, documentation, tests, synthetic examples, evaluation tools and review methods are released only after the relevant readiness gate.
No deliberately crippled teaser repositoriesPrivate incubation
Unfinished components, sensitive integrations and production evidence remain private until rights, limits and release conditions are resolved.
No promised opening dateMaintainer rights are earned through sustained judgement and trusted work.
Code, data, documentation and brand rights are handled separately. Public component licences are named individually; unreleased component licences remain undecided.
Private legal documents, evidence packages and credentials stay outside public repositories.
Suspected vulnerabilities now have a monitored project-wide private channel. Public issue trackers must not be used for security reports.
Report privatelyFunding does not buy governance, maintainer status or automatic access to private source code.
Articles / Long-form reading
Long-form work on verifiable legal AI, public methods, system design and the limits of automation.
View all articlesOPENLEGALCORE / CORE ARGUMENT
Public code can enable inspection without proving control of the whole system. Follow versions, provenance, data sovereignty, exit and regulatory roles in legal AI.
LATEST PUBLICATIONS
Law-firm data security
From public record to shared work
Public components are open to inspect. Private components are shared only within defined contributions, evaluations, integrations or pilots—with purpose, scope and access agreed first.
Access follows the work. Start with your role.
Name the component, the problem and what you can contribute. Code, tests, documentation, legal-method review and source expertise are all valid starting points. Public repositories remain open for direct work.
Legal teams, public institutions and technology partners can propose a pilot, integration, evaluation or scoped adaptation. If the work requires private access, its purpose and scope—and the licensing and publication boundaries—are agreed first.
Access boundaryPrivate access is scoped to agreed work. It does not create ownership, maintainer status or decision rights.
A concrete problem is enough to begin.
Project accountability
Open participation broadens the work without blurring who is accountable for project direction, releases and public–private boundaries.
FOUNDER · MAINTAINER
Rajko Majcen is a technology founder, technical project leader and product builder with more than three decades of work across security engineering, electronic banking, telecommunications, enterprise systems, open-source infrastructure and applied AI. He founded OpenLegalCore to bring that systems experience to transparent, verifiable legal technology.
