Ontology evidence and reproduction

Evidence conventions

• Live-confirmed means observed in dev-north-alicloud for realm gj76anadpsc and workspace w-t5e2kcxjd on 4 September 2026.
• Source-verified means the behavior follows directly from the cited source and focused automated tests.
• A scenario requiring model data remains pending when the live database has no representative object. Source presence is not reported as a successful live journey.

Current evidence summary

Evidence	Result
ontology-backend deployment	One ready pod, image e499673, two Uvicorn workers
BFF deployment	One ready pod, image 9b2fd45
Cube deployment	One API, one CubeStore router, and two CubeStore workers; all on one node; memory cache/queue; no refresh worker or pre-aggregations
Trino deployment	One coordinator and one worker on one node; fixed capacity; Cube bypasses the Trino Gateway
Ontology database	One active core project, one active main branch, main revision zero
Model and workbook content	Zero objects, branch changes, proposals, decisions, proposal tasks, object versions, workbooks, and workbook tabs
Database schema	Alembic current and image head both 7f8a9b0c1d2e
Database protection	One replica, 20 GiB ESSD, backup: null, terminationPolicy: Delete
Focused source tests	70 Ontology proposal, merge, rename, runtime, repository, and pagination tests plus 46 Oqullus proposal-impact tests passed locally
Browser journey	Not recorded in this slice; Chromium automation exited after redirect and is not product evidence

ONT-S001 — Deployment and data baseline

1. Select Kubernetes context dev-north-alicloud.
2. Inspect deployments and pods in qd-system and cube.
3. Record exact image tags, replicas, restarts, probes, and resource requests.
4. Read only aggregate Ontology table counts; do not print object definitions or actor identities.
5. Run alembic current and alembic heads inside the deployed image.
6. Inspect the KubeBlocks cluster and PVC for replica, backup, termination, and capacity settings.

Observed result: the topology and empty model baseline match the evidence table above. The current schema is compatible, but no deployment mechanism enforces that condition.

ONT-S002 — Structural draft validation

Source verification:

1. Submit a payload with an invalid name, duplicate member, unsupported type, no primary key, nonexistent relationship target, and unbalanced braces.
2. Confirm each request returns a validation response without a branch change.
3. Submit a structurally valid payload whose sql_table and expressions refer to nonexistent physical resources.
4. Confirm the branch save accepts it because only non-empty text and template shape are checked.

The reviewed object, project, and Cube repository suites passed 43 tests. They cover structural rules and use table names without consulting a live datasource. A controlled deployed draft is still required to demonstrate the visible UI diagnostics.

ONT-S003 — Publication validation boundary

1. Create a uniquely named working branch from main.
2. Save a structurally valid object referencing a nonexistent table or column.
3. Record the draft validation state shown to the author.
4. Submit the proposal and attempt approval and merge.
5. Record whether the complete effective model is compiled and whether Trino metadata is checked before each transition.
6. Attempt a semantic query and capture which component first rejects the model.
7. Archive the temporary branch and record retained audit state.

Expected current result from source: save and merge do not perform datasource or Cube compilation validation; failure is deferred to model compilation or query. Live execution is pending because the deployed workspace has no test model and the browser evidence session did not remain attached.

ONT-S004 — Deprecated direct-main mutation

1. Authenticate as a non-admin Ontology user.
2. Call the BFF-proxied POST /ontology/v1/objects with a unique object in a controlled project.
3. Confirm whether main changes without branch, proposal, or approval.
4. Compare ontology_objects, main branch revision, and object-version rows.
5. Inject or simulate failure between projection commit and snapshot to test divergence and retry behavior.
6. Remove the temporary object and retain the request/audit evidence.

Source and integration tests confirm that BFF proxies the route and the backend commits a direct main write before separately snapshotting main. Do not run this scenario against an existing shared model.

ONT-S005 — Project namespace access

1. Create two controlled projects and users representing different personas.
2. With each user, list projects and request the other project's objects, branches, Cube metadata, and semantic query.
3. Record Ontology metadata visibility separately from Trino row/table access.
4. Confirm the product describes projects as shared namespaces until membership and project policy are implemented.

Current source has no project membership or authorization decision. This is an improvement backlog, not a claim that the present shared-namespace contract is malfunctioning.

ONT-S006 — More than 50 objects

1. Create 51 uniquely named objects whose alphabetical order is deterministic.
2. Open Ontology Objects on main and on a working branch.
3. Record the list response total, items.length, limit, and offset.
4. Navigate every visible client page and search for the alphabetically 51st object.
5. Open that object directly by UUID and request Cube metadata for the same project/branch.
6. Count list and per-object detail requests.

Expected current result from source: Oqullus fetches the first 50 alphabetically, ignores total, creates seven local pages at eight items per page, and never requests offset 50. The 51st object is absent from list and search even though a direct object read and Cube's complete model can still include it. Up to 50 detail requests follow the list request.

ONT-S007 — Dynamic model dependency failure

1. Load a known model and semantic query successfully.
2. Make ontology-backend unavailable to Cube while keeping Cube available.
3. Force a new project/branch compiler context and request metadata or a query.
4. Record Cube logs, returned status, UI message, repository contents, and schema version.
5. Restore ontology-backend and confirm whether the model recompiles without a manual Cube restart.

Source result: repository failure returns an empty file list and schema-version failure returns the default version. Live failure injection remains pending.

ONT-S008 — Database backup and restore

1. Identify the configured backup schedule, retention, encryption, and target.
2. Record a recovery point containing a project, branch, proposal, main revision, object version, workbook, and dashboard.
3. Restore into an isolated database.
4. verify referential consistency and compare exact effective model hashes.
5. Point a test ontology-backend at the restored database and compile the model through Cube.
6. Record recovery-point and recovery-time results.

No backup resource or successful restore evidence exists in the reviewed KCL or live cluster. This scenario is blocked until recovery is designed and enabled.

ONT-S009 — Migration-gated rollout

1. Start from the previous supported schema and application image.
2. Run the next migration as an explicit deployment step with a recorded job.
3. Confirm application rollout waits for successful migration.
4. Inject migration failure and verify the incompatible application does not become ready.
5. Test backward compatibility, rollback policy, and restore from the pre-change recovery point.
6. Compare live alembic current with image alembic heads as a postcondition.

The current database equals the deployed image head, but the application command only starts Uvicorn and the KCL stack defines neither a migration job nor an init container. The present matching state does not prove repeatable delivery.

ONT-S010 — Workbook resource authorization

1. Create controlled users A and B in separate workspaces and projects.
2. As A, create a workbook and tabs; record their numeric IDs without query results or secrets.
3. As B, attempt list filtering with A's workspace/project and direct read/update/delete of A's workbook and tabs.
4. Send a conflicting caller-supplied X-User-Id and confirm it cannot change the authoritative actor.
5. Compare stored owner_id with the owner and access level shown by Oqullus.
6. Confirm every cross-boundary request is denied and audit-attributed.

Expected current result from source: authentication succeeds, but workbook resource policy is not evaluated and BFF does not supply the owner header used by creation. Do not run destructive requests against user-owned workbooks.

ONT-S011 — Workbook save, reload, and conflict

1. Open the same controlled query tab in sessions A and B.
2. In A, change fields/filter/order/limit without Run; reload and record what returns.
3. Run successfully, intercept or reject the background save, and record the visible save/error state before and after reload.
4. Change chart type, then Reset and reload each time.
5. Make conflicting changes from A and B and save in both orders.
6. Record revisions, conflict responses, restored definition, and whether reopening automatically executes it.

Expected current result from source: query configuration saves only after a successful Run, chart type saves immediately, Reset does not save, failures are silent, and last write wins without a conflict response.

ONT-S012 — Workbook tab integrity

1. Create a workbook with query tabs and one dashboard tab.
2. Attempt dashboard membership containing a missing ID, duplicate ID, and a tab from a second workbook.
3. Delete a selected query tab and reload the dashboard.
4. Reorder with missing, foreign, and duplicate positions.
5. Confirm stored membership and positions remain valid after each operation.
6. Repeat two updates concurrently and record the winner/conflict contract.

Expected current result from source: dashboard IDs are JSON values without a foreign key; deletion does not clean membership, and update/reorder validation does not enforce all association and uniqueness invariants.

ONT-S013 — Proposal impact completeness

1. Create more than 50 main objects with a relationship from an object beyond the first page to a rename/delete target.
2. Add a workbook query that references the target.
3. Propose the destructive change and record impact totals and proposal branch revision.
4. Fail one object-detail and one workbook-detail request independently.
5. Confirm whether impact is visibly partial and whether merge is blocked.
6. Mutate the branch after review, then attempt merge and inspect direct and indirect version/audit records.

Expected current result from source: impact is computed in Oqullus from partial fan-out reads and becomes null on failure without disabling merge. The backend checks incoming Ontology relationships and performs rename rewrites, but does not consume an authoritative revision-bound workbook impact result.

ONT-S014 — Proposal decision chronology

1. Submit a controlled proposal and record its branch revision.
2. Have one reviewer approve, change to reject, and approve again with distinct comments.
3. Reload proposal detail and list; compare visible actor, order, and time with database rows.
4. Edit the branch so the proposal reopens and decisions reset.
5. Verify whether the prior decisions and reset reason remain in an audit view.
6. Approve and merge, then verify decision and merge timestamps.

Expected current result from source: the API exposes only the latest decision per reviewer without event times; branch edits delete current task/decision rows and rebuild the proposal state.

ONT-S015 — Object graph completeness and scale

1. Create a connected 51-object model with one edge targeting the 51st object.
2. Open Object Graph and record summary/detail request counts and completeness.
3. Fail one detail request and verify whether partial state is disclosed.
4. Search for the 51st object and inspect the source object's missing edge.
5. Repeat at agreed node/edge limits while capturing API latency, main-thread work, layout duration, memory, interaction delay, and rendered elements.
6. Verify a bounded neighborhood can expand without losing revision identity.

Expected current result from source: the target after the first 50 is absent, a failed detail becomes a blank isolated node, and layout/rendering are unbounded browser work over the fetched subset.

ONT-S016 — Semantic-query cancellation

1. Start a controlled semantic query that runs long enough to observe in Cube and Trino.
2. Record browser request, Cube request ID, Trino query ID, and start time.
3. Select Stop once, then repeatedly, and record UI state and response timing.
4. Inspect Cube and Trino until terminal state; measure cancellation latency and continued CPU/scanned bytes after the UI stops waiting.
5. Repeat for browser close, Ontology timeout, and network interruption.
6. Retry once and confirm the first execution cannot remain hidden and active.

Expected current result from source: the abort signal is not passed into Cube's load request, so Stop only proves that the UI waiter ended. Engine cancellation remains unverified.

ONT-S017 — Semantic result boundary

1. Run controlled queries that increase rows and row width separately.
2. Test default No Limit and each visible finite limit.
3. Record rows/bytes, memory, latency, timeout, and truncation at Trino, Cube, Ontology, BFF, and browser.
4. Verify sorting, totals, charting, pagination, and CSV behavior on truncated or partial output.
5. Cross the supported interactive boundary and confirm the request is rejected or continued without exhausting a component.
6. Export the complete result through the designated large-result path.

No supported row/byte envelope or asynchronous export is currently documented. Use synthetic non-sensitive data and stop below unsafe shared-environment load.

ONT-S018 — Workbook dashboard fan-out

1. Create a dashboard with increasing numbers of controlled query tabs.
2. Open it and count simultaneous dry-run/load requests and Trino queries.
3. Record panel queue/running/success/failure/cancel states and total latency.
4. Repeat with two users and one deliberately slow or failing panel.
5. Navigate away and confirm outstanding work is cancelled or remains visible.
6. Compare the result with the declared client and server concurrency budgets.

Expected current result from source: Oqullus starts one async load per selected tab without a concurrency limiter.

ONT-S019 — Model and context cardinality

1. Instrument model-resolution count, generated bytes/time, repository calls, schema-version calls, compiler contexts, orchestrators, queues, and memory.
2. Run one metadata request, dry-run, and load for one user/branch.
3. Increase objects, active branches, users, and five-minute token windows one dimension at a time.
4. Confirm one revision produces one immutable model and invalidates exactly when the branch revision changes.
5. Let contexts expire and verify memory/queue cleanup.
6. Record the supported cardinality and latency envelope.

Expected current result from source: one semantic operation can cause repeated full-model resolution, with compiler state per project/branch and orchestrator state per user/project/branch/time bucket.

ONT-S020 — Execution topology and failure boundaries

1. Record Cube API, CubeStore router/worker, refresh worker, queue/cache driver, pre-aggregation, Trino, gateway, node-placement, HPA, PDB, and storage state.
2. Run representative raw semantic queries and attribute CPU, memory, queue, cache, and Trino work to each component.
3. Scale CubeStore workers only and confirm whether raw-query throughput changes.
4. Disrupt one Cube API, CubeStore node, and Trino worker separately in an isolated test and record user-visible recovery.
5. Test Trino admission and guarded worker scale-up/down with graceful shutdown.
6. Compare results against the declared minimal or accelerated workload mode.

Live inspection confirms the current fixed topology described in Architecture. Load, disruption, and scale tests remain pending and must not be performed in a shared environment without an agreed safety envelope.