Vianordis
--:--:-- UTCVianordis / SUPPORT
education

Omniscola

Coming soon

Omniscola is the education and K-12 school-management system for student records, enrolment, schools, grade levels, and related administration. It is separate from Paideia, the adult and corporate learning platform.

Release-readiness guide

Omniscola pre-release readiness manual

Prepare privacy, school reference data, roles, and controlled acceptance for the Omniscola student-information preview.

Manual
Version 1.0
Product
Omniscola 0.1.0 preview
Verified
July 15, 2026
Language
English · Source
Owner
Omniscola education product, privacy, and support
Source
omniscola · a40d0f8
Review cycle
90 days
Start here

Audience, scope, and prerequisites

This is a release-readiness guide for the implemented dashboard and student-record preview. It does not document unverified course, assessment, certificate, or broader school workflows and does not authorize real student-data processing.

Who this is for

  • School and education administrators
  • Privacy and records owners
  • Release testers and support

Before you sign in

  • A formal preview invitation and non-production tenant
  • Synthetic student, school, grade, and enrolment data
  • Named education-records and privacy owners
  • Approved role, retention, export, correction, and incident policies
Access model

Roles and responsibilities

RoleAccessResponsibilities
Education administratorPreview assigned dashboard and student records.
  • Test only synthetic records
  • Verify school and tenant scope
Privacy or records ownerReview data fields, search, export, correction, retention, and access boundaries.
  • Minimize data
  • Approve evidence handling and release conditions
Release testerRun approved scenarios without operational authority.
  • Record expected and actual results
  • Stop on privacy or isolation failure
Workspace map

Navigation

Dashboard

/[locale]/dashboard

Preview tenant education summaries.

Students

/[locale]/students

Preview student search, pagination, school, grade, and enrolment status.

Chapter 01

Prepare a privacy-safe preview

Student records require strict purpose, minimization, authorization, and evidence controls before any workflow testing.

Procedure 1.1

Confirm preview authorization

Verify environment, release scope, identities, owners, and prohibited uses.

  1. 1
    Record the invitation

    Capture version, environment, test window, known gaps, support channel, and permitted routes.

  2. 2
    Verify tenant and roles

    Test assigned access and confirm an unassigned identity cannot read records.

  3. 3
    Approve synthetic data

    Use invented names and student numbers with no mapping to real learners or guardians.

  4. 4
    Set stop conditions

    Stop immediately on cross-tenant data, unintended export, real personal data, or uncontrolled logging.

Expected result

The preview has explicit authority, synthetic data, minimum roles, accountable owners, and privacy stop conditions.

Procedure 1.2

Prepare the student-record matrix

Define controlled inputs and expected visibility without importing school records.

  1. 1
    Create synthetic schools and grades

    Include multiple schools and grade levels to test scope boundaries.

  2. 2
    Create synthetic students

    Use unique student numbers, names, enrolment states, and edge-case characters.

  3. 3
    Map role visibility

    Record which tester may see which tenant, school, field, and action.

  4. 4
    Define search and paging expectations

    Specify match cases, no-result cases, record totals, page boundaries, and allowed export behavior.

Expected result

A sanitized matrix defines expected records, searches, page counts, and role boundaries.

Chapter 02

Accept the implemented preview

Limit acceptance to the routes and behavior verified in the pinned source revision.

Procedure 2.1

Test student-list behavior

Validate loading, search, paging, field display, failure states, and authorization.

  1. 1
    Open Students

    Verify the expected tenant and locale before reviewing synthetic records.

  2. 2
    Inspect displayed fields

    Confirm name, student number, grade, school, and enrolment status match the expected matrix.

  3. 3
    Exercise search

    Test exact, partial, special-character, and no-result searches and the debounce delay.

  4. 4
    Exercise pagination

    Verify totals, range labels, previous/next boundaries, and stable results.

  5. 5
    Test failure and denial

    Confirm loading, API error, expired session, missing role, and wrong-tenant cases fail safely.

Expected result

The student list returns only expected synthetic records and behaves predictably across search, paging, error, and denial cases.

Procedure 2.2

Record privacy and release acceptance

Require explicit approval before any expansion beyond the synthetic preview.

  1. 1
    Review the route inventory

    Distinguish implemented and accepted workflows from links or planned capabilities.

  2. 2
    Review privacy controls

    Assess minimization, authorization, tenant isolation, exports, logging, retention, correction, and incident response.

  3. 3
    Review usability

    Assess localization, accessibility, performance, empty states, errors, and support diagnostics.

  4. 4
    Record the decision

    Document version, scope, evidence, gaps, owners, and whether release remains blocked.

Expected result

A dated decision clearly states what was tested and confirms that production use remains unauthorized until formal release.

Operating rules

Security and data handling

  • Use invented data with no relationship to real students, guardians, employees, or schools.
  • Verify tenant and school boundaries with both positive and negative access tests.
  • Treat student numbers, exports, screenshots, and logs as protected records even in testing.
  • Do not follow unverified links or infer features from inactive controls.
  • Require privacy-owner approval before adding fields, integrations, exports, or real data.
Current release

Known limitations

Read before relying on an unsupported workflow

These limits describe the source-pinned Omniscola 0.1.0 preview scope and must be rechecked when the product changes.

  • Omniscola is listed as coming soon and this manual does not authorize production use.
  • The pinned UI source verifies only localized dashboard and student-list routes.
  • Visible Add Student, Filters, Export, and record-detail links are not evidence that those workflows are implemented or approved.
  • No source README or production release evidence was available at verification time.
  • Omniscola is a school-management/SIS product; adult and corporate course delivery belongs to Paideia.
Problem solving

Troubleshooting

You cannot sign in to Omniscola

Likely cause: The session expired, the identity is not assigned to the application, or the tenant claim is missing.

  1. Open the application from the approved portal and complete sign-in again.
  2. Confirm that the correct organizational identity and tenant are selected.
  3. If access is still denied, record the time and request an entitlement check from support.

A documented action or navigation item is not visible

Likely cause: The current role, release, tenant configuration, or feature flag does not expose that operation.

  1. Confirm the role and prerequisites listed for the procedure.
  2. Reload the page after signing in again; do not attempt to bypass the interface through direct URLs.
  3. Ask the product owner whether the feature is enabled for the tenant before reporting a defect.

A saved change or background operation is not visible

Likely cause: Validation failed, processing is still running, or the current view is stale or filtered.

  1. Review inline validation, status indicators, filters, and the selected tenant or workspace.
  2. Refresh once and search for the item by its stable name or identifier.
  3. Do not repeat irreversible or externally visible actions until the original operation status is known.

Unexpected or cross-scope student records appear

Likely cause: Tenant, school, API authorization, seed data, or session scope is incorrect.

  1. Stop testing and do not export, copy, or alter the records.
  2. Preserve only sanitized time, route, tester role, and correlation details.
  3. Report a privacy and tenant-isolation release blocker immediately.
Escalation

Contact support

Contact support when

  • A repeatable Omniscola error blocks an approved workflow
  • Expected data, permissions, or tenant boundaries appear incorrect
  • A security, privacy, compliance, or data-loss concern is suspected
  • Any real or cross-tenant student data appears
  • Student totals, search results, or paging differ from the acceptance matrix
  • A denied user can reach student data or export behavior

Include

  • The page, action, and expected result
  • The exact error text and time of occurrence, including time zone
  • Your tenant, role, browser, and a sanitized record or item identifier
  • Whether the problem can be reproduced and which troubleshooting steps were tried

Never include

  • Passwords, access tokens, API keys, recovery codes, or session cookies
  • Unredacted personal, health, financial, or other regulated data
  • Private encryption keys or complete confidential documents unless an approved channel is provided
Contact support