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

SECURITY / PRIVATE REPORTING

Report vulnerabilities privately.

Suspected vulnerabilities in OpenLegalCore code, this website or related public infrastructure should not be posted to public issues. Use the private channel below.

Channel
PRIVATE EMAIL
Public issues
DO NOT USE
Disclosure
COORDINATED
Security guarantee
NONE

PROJECT-WIDE PRIVATE CHANNEL

Send the first report directly.

security@openlegalcore.org

Use the subject “OpenLegalCore security report”. Begin with a concise description; do not send credentials, private legal material or third-party confidential data.

  1. 01

    WHAT BELONGS HERE

    Suspected technical vulnerabilities.

    Report a weakness that may affect OpenLegalCore code, this website, a public project service or related project-controlled infrastructure. This includes paths that may expose data, credentials, access controls or the integrity of public artefacts.

  2. 02

    CHOOSE THE PRECISE CHANNEL

    Use component reporting when it exists.

    For Legal OCR Pipeline, GitHub Private Vulnerability Reporting and its versioned security policy remain the most precise first route. The project email is the fallback for cross-project, website or unclear reports.

  3. 03

    WHAT TO INCLUDE

    Enough detail to investigate safely.

    Name the affected asset and version, the observed behaviour, reproducible steps and the likely impact. Include only evidence that can be shared safely and a contact path for clarification. A complete exploit is not required for the first report.

  4. 04

    WHAT NOT TO SEND

    Describe sensitive material; do not attach it.

    Do not send personal or legal documents, credentials, tokens, private keys, production datasets or third-party confidential data. If such material may be involved, describe its category and wait for instructions for a suitable exchange.

  5. 05

    WHAT HAPPENS NEXT

    Private triage before public disclosure.

    The report is reviewed privately, clarification is requested when needed and any disclosure is coordinated after a safe fix or mitigation is available. The project does not publish a response-time promise or operate a bug bounty.

  6. 06

    EXPLICIT BOUNDARY

    Reporting guidance is not testing permission.

    Do not disrupt services, use social engineering, access third-party data, establish persistence or exfiltrate information. This page does not grant permission to test any system or alter any legal or contractual boundary.

ROUTING / THREE DISTINCT PURPOSES

Send each matter to the right public boundary.