The curriculum is the institution's promise. Most institutions keep it in a document.
Programmes, courses, outcomes, mappings and the catalog as one governed, versioned object. Proposed, reviewed, approved, published, then read by registration, scheduling, examinations and accreditation without being retyped.
The problem
Ask five systems what a programme requires and you get five answers.
The approved curriculum lives in a council minute. The catalog is a PDF regenerated once a year. Registration enforces its own prerequisite table. The timetable was built from last year's course list. The accreditation file has a mapping matrix someone rebuilt from memory. None of them is wrong on purpose; they simply diverged the moment the curriculum stopped being a single object.
Three things go wrong every cycle. Approval happens outside the system, so what was agreed and what is being taught drift apart. The curriculum has no version, so amending it silently changes the requirements of a cohort halfway through. And the catalog is a publication, not a source, so every downstream system keeps its own copy of the truth.
The operating model
Propose it, govern it, version it, publish it once.
Four design choices turn the curriculum from a document into an operating layer: design is a workflow with reviewers, the plan is versioned by regulation year, the catalog is the source rather than a publication, and an offering can never contradict the approved course.
Design is a workflow, not a document
A programme or course begins as a proposal with objectives, structure, credits, prerequisites, outcomes and accreditation alignment, then routes through department head, curriculum committee and academic council with comments, revisions and status tracking. Approval is a recorded act with a date and a signatory.
The plan is versioned by regulation year
Each curriculum plan carries a version and an effective session. A new iteration is created from the existing planner, history stays traceable, and a student remains mapped to the version they entered under, so amending next year's plan cannot change this year's requirements.
The catalog is the source, not the output
Publishing does not generate a PDF that systems copy from. It makes the approved version readable by registration, scheduling, examinations and accreditation directly, so there is one definition of what a course is and what it requires.
An offering inherits, it does not redefine
A term offering adds sections, faculty, capacity and delivery mode to an approved course. Credits, outcomes and prerequisites come from the catalog entry and cannot be edited locally, so an offering can never quietly teach something else.
What it does
Five things curriculum design needs. One record.
Programme design, course design, outcomes and mapping, versioning and governance, and the catalog with its term offerings. Pick one to see what sits inside it.
Click any block to explore
A programme proposed, reviewed and published as one object.
- Programme proposal workflow with objectives, structure and resource requirements
- Programme type, study level and category
- Duration, terms, minimum credits and minimum CGPA
- Programme educational objectives and programme outcomes
- Multi-stage approval by department head, curriculum committee and academic council
- Status tracking from draft through review to publish
- Bulk programme import for existing structures
A course defined once, completely, before it is ever offered.
- Course proposal workflow with review routing, comments and revisions
- Course name, code, credits and category such as core, elective or lab
- Course objectives and course outcomes with Bloom taxonomy alignment
- Learning mode configuration: in-person, hybrid, online, hyflex
- Syllabus and instructional plan attached to the course
- Prerequisites and co-requisites with AND and OR logic and equivalents
- Course marks structure, delivery tools and bulk course import
Coherence you can see, not a matrix rebuilt for an audit.
- CO to PO mapping with numeric correlation indicators
- Articulation matrix across the whole programme
- Threshold attainment setup, minimum achievement level per outcome
- Curriculum mapping analytics with visual coverage view
- Unmapped course and orphan outcome warnings
- Alignment to accreditation frameworks and graduate attributes
- Mapping handed to Outcomes & Attainment for measurement
Change the curriculum without rewriting anyone's past.
- Curriculum plan versioning by regulation year or academic session
- New iterations created from an existing planner
- Version control for programmes and for courses independently
- Backward compatibility for student mapping and audit
- Role-based access for programme designers, course designers and curriculum managers
- Curriculum activity history of every edit and approval
- Notification on every workflow action, with a submission dashboard
The approved course, delivered in a term.
- Course offerings by programme, batch, semester and campus
- Section creation with capacity, soft caps, overflow and waitlist rules
- Primary and secondary faculty, teaching assistants and guest lecturers
- Faculty reassignment with workload analysis and clash detection
- Cross-listed courses shared across departments with separate reporting
- Offering cloning from a previous term, and bulk offering import
- Enrolment demand forecasting and offering approval workflow
Inside the product
The whole curriculum cycle, in one place.
This is the application, not a diagram. Move through the surfaces your designers and curriculum office work in: the programme builder, the course builder, the mapping matrix, the approval queue, the version history, and the catalog with its term offerings.
| Department | School | Code | Status |
|---|---|---|---|
| Computer Science and Engineering | Academic [ACD] | CSE-01programs and modules linked | Active |
| Institute of Health Sciences | Academic [ACD] | IHS-01programs and modules linked | Active |
| School of Digital Marketing | Academic [ACD] | DMSMprograms and modules linked | Active |
| Bucket | Course | Code and credits | Requisites |
|---|---|---|---|
| CORE | Machine Learning | AI503 · 3credits 6, range 3 to 20 | Set |
| CORE | Python Programming for AI | AI502 · 3sub bucket assignable | Set |
| ELECTIVE | AI Fundamentals | AI501 · 3credits 3, range 3 to 20 | Set |
Lifecycle or product
The lifecycle is the operating model. This is the product that runs it.
Two pages, two jobs. Read the lifecycle to understand how curriculum, policy and programme strategy are governed; read this page to see the application your programme and course designers open on Monday.
One of the institutional lifecycles: the governed model for curriculum, programmes, academic policy, strategy and KPIs.
The application that runs curriculum design: proposals, outcomes, mapping, versioning, catalog and offerings.
How is the academic offer decided, governed and held to account?
What do programme designers, course designers and curriculum managers actually see and do in each screen?
The full governance model, including policy, programme portfolio, committees and institutional KPIs.
Proposal to offering: programme and course design, outcomes, mapping, versioning, catalog and sections.
You are designing the operating model or comparing architectures.
See the operating model →
You are replacing a catalog document and a curriculum spreadsheet.
See inside the product →
Displacement
A catalog document tells students what you teach. It cannot stop you teaching something else.
Catalog tools and curriculum management add-ons produce a beautiful published artefact. But the artefact is downstream of the decision and disconnected from delivery: registration keeps its own prerequisite table, the timetable was built from last year's list, and the accreditation matrix is rebuilt by hand. The document is accurate on the day it is published, and diverging by the second week of term.
A committee minute, filed separately.
A workflow stage on the record, with date and signatory.
Overwrites, and quietly moves the goalposts.
A new regulation-year version; prior cohorts unaffected.
Each system keeps its own copy.
Registration, timetable and exams read this version.
Good at publishing. Disconnected from approval, delivery and the systems that must enforce it.
Also part of the operating system
Curriculum & Catalog is the definition every other lifecycle reads.
Connect it and registration enforces the approved prerequisites, the timetable is built from live offerings, examinations inherit the outcome map, and accreditation evidence points at the version that was actually taught.
Built for every role
One curriculum. Five views of the same definition.
Builds a programme as a proposal and watches it move through review without chasing anyone.
Defines outcomes, requisites and syllabus once, and every term offering inherits them.
Approves or returns with comments, and the whole pipeline is visible on one dashboard.
Registration and scheduling read the approved version, not a copied prerequisite table.
The mapping matrix exists because the curriculum was designed in it, not rebuilt for a visit.
What academic teams say about running curriculum on Creatrix.
Creatrix Campus has helped us centralise all student information in one reliable and intuitive system, improving efficiency and reducing errors. We use it to manage student data, schedule sessions, and automatically generate transcripts, which has simplified many of our academic processes.
Creatrix provides an excellent platform for planning and coordinating teaching activities with a clear line of sight to learning outcomes, assessments, professional competency standards, entrustable professional activities, and graduate attributes.
Go deeper
From the Creatrix library.
Blogs, whitepapers and case studies for the people who own the offer: programme designers, curriculum managers, registrars and accreditation officers.
Frequently asked
Plain answers about curriculum and the catalog.
How does a new programme or course get approved?
Through a structured proposal workflow rather than a document circulated by email. The proposal captures objectives, structure, credit hours, prerequisites, learning outcomes, accreditation alignment and resource requirements.
It then routes through multi-stage review by department heads, the curriculum committee and academic council, with comments, revisions, status tracking and automatic notification at every action.
How does curriculum versioning work?
A curriculum plan is versioned by regulation year or academic session. A new iteration can be created from an existing planner, and historical changes stay traceable.
Backward compatibility is maintained for student mapping and audit, so changing next year's syllabus never rewrites the plan a graduating cohort studied under.
Can we map course outcomes to programme outcomes?
Yes. Course outcomes are defined with Bloom taxonomy alignment and mapped to programme outcomes using numeric correlation indicators, producing an articulation matrix.
Threshold attainment levels are set per outcome, and mapping analytics show coverage and correlation strength across the whole programme. The same mapping is what Outcomes & Attainment measures against later.
Who can do what in curriculum design?
Access is role based. Programme designers, course designers and curriculum managers hold different privileges and visibility, and review is separated from authoring.
Every edit and approval is written to a curriculum activity history for compliance and governance, with a submission dashboard showing where each item sits.
What is the difference between the catalog and a course offering?
The catalog is what the institution teaches: an approved, versioned course with its outcomes, credits, prerequisites and syllabus. An offering is that course delivered in a specific term to a specific batch, with sections, capacity, faculty assignment and a delivery mode.
One catalog entry produces many offerings, and none of them can drift from the approved definition.
How are prerequisites and capacity handled on an offering?
Prerequisite and co-requisite chains are validated automatically, including AND and OR conditions, equivalent course recognition and waiver workflows.
Sections carry capacity with soft caps, overflow sections, waitlist rules and enrolment balancing, and cross-listed courses are shared across departments with unified scheduling and separate departmental reporting.
Can we run it standalone?
Yes. It runs on its own as the system of record for programmes, courses and the catalog, with bulk import for existing structures, and it connects into the Academic Operating System when you are ready, so registration, scheduling, examinations and attainment all read the same approved curriculum version.
SEE IT ON YOUR OWN CURRICULUM
Bring one programme and its approval chain. We will build it live.
A tailored proof session uses your programme structure, your outcome framework and your real committee stages, not a canned demo. Leave with a named, dated next step.