OntoL Bank 0.2.3: How a 44-Case Ontology Library Uses M/E/R Ratings & Guardrails

OntoL Bank version 0.2.3 (2026-10-27) is a running instance that currently publishes 44 ontology cases. The product focuses on concrete, verifiable data rather than conceptual vision. The homepage shows four live database metrics: published cases, industry catalogs, business scenarios, and traceable sources. Search supports case name, industry, and scenario keywords with preset entries such as FIBO 监管, 楼宇设备, and 化工 合同. The UI uses skeleton screens and true empty states — no demo data filler.

Case Discovery: Filters in the URL

The /cases page allows combined filtering by industry, business scenario, case type, maturity (M), evidence level (E), and reuse level (R), with sortable columns. All filter state is encoded in the URL so a shared link reproduces the exact result set. Three real cases illustrate the rating spread:

NHS England Federated Data Platform – M3·E2·R1: production use but evidence from public sources only, not independent acceptance.

Gene Ontology – M4·E3·R1: long-term large-scale operation with verifiable delivery artifacts.

Manufacturing ERP Integrated Ontology – M1·E1·R1: only project-supplied table structures and field descriptions, no production runtime evidence.

The three ratings are deliberately kept separate; a case can be M3+E1 or M1+E2, and the system never merges them into a single “verified” badge.

Case Detail: Nine Sections, Four Queryable Content Types

Opening a case (e.g., Manufacturing ERP) reveals structured counts: 14 model classes, 19 object relations, 64 fields, 6 functions, 6 indicators, 6 capability questions, and 1 source. The body is organized into nine fixed sections: Overview, Business Background, Ontology Solution, Capability Questions, System Architecture, Implementation Process, Effect Indicators, Limitations & Risks, and Reuse Guidance. A case may have multiple scenarios (sub-cases); switching scenarios replaces all nine sections entirely.

Fields Are Not Just “Has a BOM”

Field tables show modeling-ready attributes with type, cardinality, unit, and description. Examples: Material.safety_stock: decimal, required, unit “material unit”, safety stock threshold. Inventory.expiry_date: date, 0..1, for near-expiry alerts. ExecutionItem.batch_no: string, 0..1, fulfillment batch number for inventory traceability. Alert.level: string, controlled vocabulary “high, medium”.

Object relations are listed separately (e.g., Order→Counterparty, Fulfillment→Order, FulfillmentLine→OrderLine, Inventory→InventoryFlow, Finance→FulfillmentDoc) and never mixed into the field table.

Functions and Indicators Have Concrete Signatures

Six functions are listed with specific signatures. Indicators include formulas and units. Capability questions reflect business-user phrasing, such as “What is the fulfillment progress and unreceived/unshipped quantity for a given order?” or “Which fulfillment order received a given batch and how much remains?” All of this lives as structured data inside the same case record, not as a separate documentation set.

Trust Mechanisms: Ratings, Gates, and Sources Are Hard Constraints

1. Three Ratings Computed Independently

Maturity answers “how far done”, evidence answers “why believe it”, reuse answers “what can be taken”. The NHS case is tagged M3/E2 with 2 sources, 10 indicators, and 5 capability questions. Its claimed 7-year benefit of ~£780M, lifecycle cost ~£1.04B, and benefit-cost ratio 4.92 are explicitly marked as estimates with attribution disputes noted — not presented as realized gains. The Manufacturing ERP case, having only PostgreSQL schemas from the project, is M1/E1; its effect indicators column states “project materials did not provide quantifiable runtime effects” with no invented benefit numbers.

2. Publish Gate Is Not Copywriting

A case must pass seven checks before publication: complete title and abstract, at least one business scenario, at least one valid source URL, every quantitative indicator bound to a source, all nine core sections filled, M3/M4 must explain judgment basis, R2/R3 must provide real files and verification records. Broken source links move the case to a re-review queue instead of silent deletion. Published cases cannot be edited in place; they must be archived and a new edit opened, preserving revision history.

3. No Download Button Without Assets

All 44 current cases are R0 or R1; none have R2/R3 assets. Consequently the detail page shows no active “download landing package” button — only the honest message “This case has not published a downloadable landing package.” Landing packages are generated only for R2/R3 published assets and must contain a manifest, model files, validation checklist, and license declaration. Empty packages are never created, avoiding the “download yields an empty file” problem.

Backend Authoring Workflow

Admin entry points live under /dashboard and /admin/*: /admin/cases – case list and state management /admin/cases/new – create new case /admin/reviews – review desk /admin/taxonomy – industry and scenario maintenance /admin/sources – source management /admin/assets – solution packages and assets /admin/audit-logs – content audit trail

State flow is fixed: draft → review → publish → archive. Editing, review, publishing, and archiving share the same account, organization, role, permission, and audit chain — no separate backend. Write operations declare permission dependencies; operation logs and login logs record key actions. For content operators the daily work is: create draft, fill nine sections, attach sources, fill indicator definitions, submit for review; if rejected, revise; after publish, if a source breaks, the case enters the re-review queue.

AI Assistant: What It Can and Cannot Do

Configuration at /ai/models manages model categories, configs, default model, and connectivity tests. API keys are stored encrypted; the UI shows only masks. If no usable model exists, the chat page disables input and redirects to model config.

In /ai/chat, the assistant follows a strict sequence:

Search internal cases, industries, and scenarios; read case fields, body, sources, and scenario details.

If internal evidence is insufficient, perform web search and fetch page content for verification.

Answer with cited URLs and actual written results.

Write operations have hard boundaries:

Only modify draft or rejected cases.

Require account with case:edit permission AND the “Allow case modification” toggle on the page.

Published cases must be archived first before re-opening.

Writes go through the human-edited save_case function; validation, state gates, revision, and audit are identical to manual edits.

New sources must come from real search results or page reads; indicators must bind to existing case sources.

Page fetching only allows public http/https; localhost and private addresses are rejected.

Thus the assistant acts like an editorial aide who knows the ingestion rules, not a content generator that bypasses review. Tool-call limits apply; model tests and chats incur real API costs.

Deployment & Integration Status

Port : fixed 8020, listening on 0.0.0.0.

System DB : SQLite data/ontol_sys.db storing users, organizations, roles, permissions, menus, logs, model configs.

Business DB : MySQL 8.0 database ontol storing industries, scenarios, cases, sources, assets, and publish snapshots.

Cross-DB Rule : only ID strings stored; no database-level foreign keys.

Frontend : scripts, styles, fonts, icons all self-hosted, no CDN; responsive breakpoints at 375, 768, 1024, 1440 px.

Page States : skeleton screens, true empty states, error retry all implemented.

Integration APIs under /api/integration/v1/* serve OntoL product pulls of cases and assets; publishing generates a manifest with SHA-256 snapshots. Controlled import still needs joint debugging, so the front end does not show a “one-click import” entry; deep-link visibility is also governed by server-side config. In short: browsing, retrieval, evaluation, method reuse, and file landing-package rules are live; controlled import is not disguised as available.

Recommended First-Time Path

Search “楼宇设备” on the homepage to reach Brick Schema, RealEstateCore, IFC/ifcOWL cases.

Compare their M/E/R — currently all M1/E2/R1: public model artifacts exist but no production evidence, suitable for method reuse, not for claiming production validation.

Open detail pages; focus on “Fields”, “Limitations & Risks”, and “Reuse Guidance” to decide which models and fields to bring into your project.

For overall solution view go to /solutions; for deployment boundaries go to /about/ontol-integration.

Team maintaining own cases: enter /dashboard, create draft at /admin/cases/new, complete per publish gate, submit for review.

OntoL Bank today delivers a runnable workflow: 44 published cases, nine-section structured bodies, asset-driven M/E/R ratings, traceable sources, draft-to-publish review chain, and a bounded AI assistant. It does not sell “many cases” as a feature, nor does it surface unvalidated capabilities as buttons. Judging a case’s worth still comes back to three questions: How far done? Why believe it? What can be taken?

Product version 0.2.3 · 2026-10-27 · This article describes only features already implemented and verifiable in the current instance.