Blog
Yigatech Computational Thinking and Execution (CTE)
Master Concept, Curriculum Structure & LMS Architecture Brief
1. Project Context
Yigatech is a Nigerian digital skills and digital literacy training company developing a K–12 learning platform/LMS and after-school digital skills network.
A major proposed subject is:
Computational Thinking and Execution (CTE)
CTE should be designed specifically for Nigerian learners and should work in:
Formal school settings
After-school centres
Online classes
Physical classrooms
Hybrid classes
Offline/LAN environments
Low-resource environments
The goal is not simply to teach coding. The goal is to develop learners who can identify problems, think logically, design solutions, execute them, test them, debug them, improve them and explain them.
2. Definition of CTE
Formal definition
Computational Thinking and Execution (CTE) is a practical K–12 subject designed to develop learners' ability to identify, analyse and decompose real-life problems; recognize patterns; abstract essential information; develop logical algorithms and practical solutions; execute solutions using available resources and appropriate digital or non-digital tools; test, debug and optimize their work; and communicate their solutions effectively.
CTE integrates:
Computational thinking
Problem solving
Logical reasoning
Creativity
Mathematics
Digital technology
Coding
AI
Data
Automation
Collaboration
Communication
Innovation
Real-world problem solving
Learner-friendly definition
CTE teaches learners how to think through problems, create practical solutions, make them work, test them and improve them—using computers, technology or simple everyday methods.
3. Core CTE Cycle
The central learning cycle is:
PROBLEM → THINK → DECOMPOSE → PLAN → EXECUTE → TEST → DEBUG → IMPROVE → PRESENT
A shorter classroom version:
THINK → PLAN → EXECUTE → TEST → IMPROVE → EXPLAIN
For coding and computational projects:
DESIGN → CODE/BUILD → RUN → TEST → DEBUG → IMPROVE
4. CTE Is NOT Just Coding
Coding is only one method of execution.
CTE must support:
Unplugged/physical problem solving
Paper and card-based activities
Pseudocode
Flowcharts
Digital interactive activities
Simulations
Block-based coding
Text-based programming
Games
Data activities
AI activities
Automation
Projects
The central competency is computational problem solving, not mastery of a particular programming language.
5. Nigerian Context
CTE should use realistic Nigerian contexts, including:
Schools
Homes
Markets
Transportation
Agriculture
Small businesses
Community problems
Public services
Banking/payment scenarios
Queues
School attendance
School performance
Local logistics
Nigerian currency (₦)
Nigerian names
Nigerian cities
Local transportation
Football
Geography
Festivals and community activities
The objective is to make computational thinking relevant to the learner's environment.
6. Low-Resource Design Principle
CTE should be:
Technology-enabled but not technology-dependent.
If there is:
No computer → use paper/unplugged activity.
No internet → use offline/local resources.
One computer → learners collaborate.
No programming language → use pseudocode.
No robotics kit → use physical models/role play.
No electricity → continue with physical activities.
The learning objective should remain the same even when the execution method changes.
7. Three CTE Execution Modes
Every suitable CTE activity should support three possible execution paths.
Mode 1 — Digital Online
Requires:
Internet
Electricity
Devices
Examples:
Online simulations
Coding
Interactive activities
Games
Collaborative activities
Live classroom activities
Mode 2 — Digital Offline
Requires:
Devices
Electricity
But not continuous internet.
Examples:
Cached lessons
Offline coding
Local simulations
Offline quizzes
Local activities
Results synchronize with the cloud when internet becomes available.
Mode 3 — Physical/Unplugged
Requires no computer or internet.
Examples:
Command cards
Paper algorithms
Physical grids
Role play
Sorting
Group problem solving
Flowcharts on paper
Physical debugging
The physical activity should preserve the same cognitive level as the digital activity, rather than being a simplified substitute.
8. Core Activity Principle
Every activity should ideally have:
Objective
Competency
Digital Activity
Offline Digital Activity
Physical Activity
Assessment
Extension
Possible Solutions
Test
Debug
Improve
Resource Requirements
The principle is:
ONE OBJECTIVE → MULTIPLE EXECUTION PATHS → SAME COMPETENCY
9. Academic Structure
CTE is designed for:
Primary 1–6
JSS1–JSS3
SS1–SS3
Standard academic structure:
3 terms/year
10 weeks/term
3 sessions/week
1 hour/session
30 lessons/term
90 lessons/year
90 instructional hours/year
10. Spiral Progression
CTE should progressively increase in complexity.
Primary 1 — Discover
Follow and create simple instructions.
Primary 2 — Organize
Recognize patterns, rules and decisions.
Primary 3 — Decompose
Break problems into smaller parts.
Primary 4 — Design
Design computational solutions and algorithms.
Primary 5 — Build
Build simple working solutions.
Primary 6 — Apply
Apply computational thinking and technology to real-world problems.
JSS1 — Formalize
Algorithms, logic and pseudocode.
JSS2 — Develop
Data, software and computational systems.
JSS3 — Solve
Larger real-world computational problems.
SS1 — Engineer
Efficient algorithms, data and software/system design.
SS2 — Intelligize
Data analysis, AI and automation.
SS3 — Innovate
Independent solution engineering and capstone projects.
11. Detailed Class Progression
Primary 1
Term 1
Instructions, sequencing and simple problem solving.
Term 2
Patterns and classification.
Term 3
Simple decisions, rules and algorithms.
Primary 2
Term 1
Algorithms.
Term 2
Logic and decisions.
Term 3
Patterns and problem solving.
Primary 3
Term 1
Decomposition.
Term 2
Algorithms and flowcharts.
Term 3
Digital execution and block-based computational activities.
Primary 4
Term 1
Computational problem solving:
decomposition
patterns
abstraction
Term 2
Algorithms and programming:
logic
repetition
variables
Term 3
Computational projects.
Primary 5
Term 1
Computational analysis:
decomposition
abstraction
modelling
Term 2
Programming and algorithms:
variables
conditions
loops
data
Term 3
Digital solution development:
games
web
data
introductory AI
Primary 6
Term 1
Advanced problem solving:
algorithms
abstraction
modelling
Term 2
Computational systems:
programming
data
automation
Term 3
Real-world computational project.
JSS1
Term 1
Computational thinking foundations.
Term 2
Algorithms, logic and pseudocode.
Term 3
Programming and execution.
JSS2
Term 1
Data and algorithms.
Term 2
Software development.
Term 3
Computational applications.
JSS3
Term 1
Advanced algorithms.
Term 2
Systems and automation.
Term 3
Real-world computational project.
SS1
Term 1
Advanced computational thinking.
Term 2
Algorithms and data.
Term 3
Software/system design.
SS2
Term 1
Data and computational analysis.
Term 2
Artificial intelligence.
Term 3
Automation and intelligent applications.
SS3
Term 1
Advanced problem analysis.
Term 2
Innovation and solution engineering.
Term 3
Capstone and portfolio.
12. SS3 Experience
SS3 should NOT simply be Primary 1 with harder questions.
The learner should progressively move from:
following instructions → creating algorithms → building solutions → engineering systems → independent problem solving.
An SS3 learner might work through:
Problem identification
Requirements
Problem decomposition
Data requirements
Algorithm
System architecture
Prototype
Coding/building
Testing
Debugging
Optimization
Documentation
Presentation
Defence
Example projects:
School attendance system
Student performance system
Queue management system
School transport routing
Small-business inventory system
Community information system
Even without computers, SS3 learners can perform requirements analysis, architecture design, pseudocode, flowcharts, test-case design, manual debugging and project presentation.
13. CTE School Course Structure
Formal school CTE should follow the academic calendar.
Student-oriented structure
COURSE → TERM → WEEK → LESSON
Each lesson contains:
Topic
Content
Examples
Activities
10 MCQs
Example:
CTE Primary 1
→ 1st Term
→ Week 1
→ Lesson 2
→ Instructions
→ Content
→ Examples
→ Activities
→ 10 MCQs
The school structure should be simple because it is intended for regular academic delivery.
14. CTE After-School/Tutor Structure
After-school CTE should be more execution-oriented.
Recommended structure:
COURSE → MODULE → LESSON
Each lesson contains:
Course Code
Topic
Lesson Content
Examples
Learning Objectives
Teacher Demonstration
Digital Activity
Offline Digital Activity
Physical Activity
Practical Challenge
Possible Solutions
Test
Debug
Improve
Evaluation
Resources
Common Errors/Misconceptions
Expected Outcomes
Tutor Guidance
Example:
Course: CTE Primary 1
Module 1
CTEP1-101
CTEP1-102
CTEP1-103
The LMS already uses course codes for non-termly courses, so CTE should fit into that existing architecture.
15. Course Code Principle
A course code should be a stable lesson identifier, not the curriculum hierarchy.
Example:
CTEP1-102
Possible interpretation:
CTE = Computational Thinking and Execution
P1 = Primary 1
102 = lesson identifier
The exact numbering convention can be formalized later.
The important distinction is:
School organization:
Course → Term → Week → Lesson
After-school organization:
Course → Module → Lesson
Common underlying object:
Lesson → Course Code + Content + Activities + Assessment
16. Recommended CTE Architecture
Use one common CTE lesson/activity engine, while allowing different organizational structures.
CTE COURSE
│
├── SCHOOL MODEL
│ └── Term → Week → Lesson
│
└── AFTER-SCHOOL MODEL
└── Module → Lesson
│
↓
COMMON LESSON
│
┌────────────┼─────────────┐
↓ ↓ ↓
Content Activities Assessment
│
┌─────────┼─────────┐
↓ ↓ ↓
Digital Offline Physical
This avoids building two completely separate CTE systems.
17. Student Core of the LMS
The student-facing LMS should be centered around three pillars:
1. Course/Lesson — LEARN
Structured knowledge delivery.
2. Activities — PRACTISE / APPLY / ENGAGE
Activities reinforce learning and allow students to experiment, create and solve problems.
3. Analytics/Feedback — UNDERSTAND / IMPROVE
The LMS tells learners:
What they completed
How they performed
What they understand
Where they struggle
What to practise next
The student interface should therefore remain simple:
Courses → Activities → Progress/Feedback
Other engines operate underneath this experience.
18. Activities Are Broader Than Quizzes
Do not design CTE activities as merely MCQs.
Activity categories include:
Knowledge
MCQ
True/False
Multiple selection
Matching
Ordering
Thinking
Pattern recognition
Classification
Prediction
Logic
Decision making
Problem solving
Computational
Algorithm builder
Flowchart
Grid navigation
Debugging
Simulation
Block coding
Text coding
Creative
Design
Build
Create
Project
Open response
Games
Learning games
Challenges
Timed activities
Classroom games
Physical
Cards
Role play
Sorting
Group problem solving
Practical tasks
19. CTE Simulation Engine
The Simulation Engine is a subsystem of the CTE Engine.
Definition:
A controlled computational environment in which learners manipulate objects, rules, algorithms, data or systems and observe the consequences of their decisions.
Potential simulations:
Robot navigation
Maze solving
Sequence execution
Sorting
Classification
Decision trees
Flowcharts
Traffic routing
Queues
Resource allocation
Timetables
Data manipulation
Automation
Introductory AI
Basic flow:
Scenario → Student Actions → Simulation → Result → Test → Debug → Improve → Assessment
20. Simulation Builder
Tutors should eventually be able to configure simulations without coding everything from scratch.
Example fields:
Simulation title
Scenario
Level/class
Grid/environment
Starting point
Destination
Objects
Obstacles
Rules
Commands
Success condition
Failure condition
Time limit
Attempts
Score
Difficulty
Assessment
Simulation templates should be available, such as:
Robot Maze
Route Planner
Traffic Flow
Sorting Challenge
Algorithm Sequencer
Decision Tree
Flowchart Runner
Data Classification
21. Coding Lab Engine
The Coding Lab is different from the Simulation Engine.
Definition:
A secure programming environment where learners write, execute, test, debug and improve programs.
Suggested progression:
Primary
Block-based coding
Scratch-style environments
JSS
HTML
CSS
JavaScript
Secondary
Python
JavaScript
Data/AI projects
Coding architecture:
Code Editor → Validator → Secure Sandbox → Execute → Output → Test Cases → Result → Feedback
Features:
Code editor
File management
Run
Stop
Reset
Output console
Test cases
Auto-grading
Debugging
Project submission
Code history
Code must execute inside a secure sandbox.
22. Game Engine
Games should be a separate engine but integrated with CTE and the LMS.
Types
Learning games
CTE games
Coding games
Classroom games
Recreational/free-play games
Examples:
Maze Master
Bug Hunter
Sequence Rush
Logic Battle
Pattern Detective
Robot Rescue
Quiz Race
Memory games
Puzzle games
2D arcade games
Coding challenges
Game modes
Single player
Two players on the same device
Classroom multiplayer
Online multiplayer
Online multiplayer can be introduced later.
23. Game + CTE Integration
A CTE game should be able to measure computational competencies.
Example:
Robot Rescue
Student must:
Analyse the problem
Decompose it
Create commands
Execute
Test
Debug
Optimize
The Game Engine sends performance data to the CTE/Mastery Engine.
GAME → ACTIONS → PERFORMANCE → COMPETENCY → MASTERY
24. Coding + Simulation + Games
These should not be isolated systems.
CTE ENGINE
│
┌─────────────┼─────────────┐
↓ ↓ ↓
SIMULATION CODING LAB GAME
ENGINE ENGINE
│ │ │
└─────────────┼─────────────┘
↓
TEST/DEBUG ENGINE
↓
ASSESSMENT ENGINE
↓
MASTERY ENGINE
↓
LEARNER PROFILE
This allows, for example, an SS2 learner to design a traffic algorithm, code it in Python, run it against simulated traffic data, test it, debug it and optimize it.
25. Analytics and Feedback
Analytics should not simply track:
"Lesson completed."
It should track:
Attempts
Scores
Errors
Time
Completion
Retries
Activities
Competencies
Mastery
Projects
Progress
Example:
Lesson:
Introduction to Algorithms
Activity:
Robot Maze
Attempts: 4
Performance: 78%
Primary error: Sequencing
Feedback:
Review sequencing
Recommended:
Sequence Challenge 2
The core learning loop is:
LEARN → PRACTISE → APPLY → TEST → FEEDBACK → IMPROVE → RETRY → MASTER
26. Assessment Principle
Not every activity should be graded.
Distinguish:
Practice
Exploration
Challenge
Game
Assessment
Project
Therefore:
Activity ≠ Quiz ≠ Assessment
The assessment engine should support:
Automatic assessment
Tutor assessment
Hybrid assessment
Rubrics
Projects
Practical activities
Coding
Simulations
Presentations
Physical activities
27. Course Studio
The Course Studio is the curriculum-authoring environment.
Recommended navigation:
YIGATECH COURSE STUDIO
├── Dashboard
├── Course Overview
├── Curriculum
├── Lessons
├── Activities
│ ├── Digital
│ ├── Offline Digital
│ └── Physical
├── Assessments
├── Resources
├── Tutor Guide
├── Delivery
├── Student View
├── Tutor Preview
├── Analytics
└── Settings
Persistent actions:
Save Draft | Preview Student | Preview Tutor | Validate Course | Submit for Approval | Publish
28. Course Creation Options
Course Studio should support multiple ways to create content:
Create Manually
Import CSV/XLSX
Use Course Template
Duplicate Existing Course
Quick Create
Bulk Curriculum Import
Recommended UI:
Start New Course
Create Manually
Import Spreadsheet
Use Template
Duplicate Course
29. Spreadsheet/CSV Import
This is a major requirement.
The importer should support:
CSV
XLSX
Potentially XLS
Potentially Google Sheets later
The purpose is to transfer existing curriculum/spreadsheet data into LMS forms.
Flow:
UPLOAD → MAP COLUMNS → VALIDATE → PREVIEW → IMPORT → SAVE DRAFT
Example mapping:
SpreadsheetLMS fieldTermTermWeekWeekLesson No.LessonTopicTopicContentLesson ContentObjectivesObjectivesExamplesExamplesDigital ActivityDigital ActivityOffline ActivityOffline Digital ActivityPhysical ActivityPhysical ActivityChallengePractical ChallengeSolutionsPossible SolutionsEvaluationEvaluation
The imported information must remain editable through the normal Course Studio forms.
The system should support:
Automatic column matching
Manual mapping
Validation
Duplicate detection
Missing-field warnings
Import preview
Error reporting
Import history
Rollback
Downloadable Yigatech templates
A complete Primary 1 course could potentially be imported as:
3 terms × 10 weeks × 3 lessons = 90 lessons
instead of manually creating every lesson.
30. CSV/XLSX Templates
Yigatech should provide downloadable templates for:
Basic Course
Curriculum
Full Lesson
CTE Course
Assessment
Activities
A CTE template could contain:
Term
Week
Lesson No.
Course Code
Topic
Concept
Objectives
Competency
Nigerian Context
Teacher Demonstration
Digital Activity
Offline Digital Activity
Physical Activity
Practical Challenge
Possible Solutions
Test
Debug
Improve
Evaluation
Resources
31. One Master Course — Multiple Views
Do NOT create separate student and tutor courses.
Use:
ONE MASTER COURSE → STUDENT VIEW + TUTOR VIEW
Student View
Contains:
Content
Examples
Learner activities
Challenges
Assessments
Feedback
Progress
Does NOT expose:
Answer keys
Tutor notes
Possible solutions
Private analytics
Intervention notes
Tutor View
Contains:
Student-facing material
Teacher demonstration
Expected answers
Possible solutions
Common misconceptions
Intervention strategies
Assessment rubrics
Class results
Teaching notes
Resources
Delivery instructions
32. Recommended Final CTE/LMS Architecture
YIGATECH LMS
│
STUDENT EXPERIENCE
│
┌───────────────┼───────────────┐
↓ ↓ ↓
COURSE/LESSON ACTIVITIES ANALYTICS/
LEARN PRACTISE FEEDBACK
│
┌───────────────┼────────────────┐
↓ ↓ ↓
CTE SIMULATION CODING LAB GAME ENGINE
│ │ │
└───────────────┼────────────────┘
↓
EXECUTION ENGINE
↓
TEST / DEBUG ENGINE
↓
ASSESSMENT ENGINE
↓
MASTERY ENGINE
↓
LEARNER PROFILE
33. Recommended CTE Engine Architecture
CTE ENGINE
│
PROBLEM / OBJECTIVE
↓
COMPETENCY
↓
ACTIVITY DESIGN
↓
┌────────────────┼────────────────┐
↓ ↓ ↓
DIGITAL OFFLINE PHYSICAL
│ │ │
└────────────────┼────────────────┘
↓
EXECUTE
↓
TEST
↓
DEBUG
↓
IMPROVE
↓
ASSESS
↓
MASTERY
34. Important Product Philosophy
The central Yigatech CTE principle should be:
The platform should not merely deliver content. It should give learners opportunities to think, act, test, fail safely, receive feedback, improve and demonstrate mastery.
The LMS therefore becomes a learning execution platform, rather than simply a content repository.
The distinction is:
Course/Lesson = Learn
Activities = Practise, Apply and Engage
Simulation = Experiment
Coding Lab = Build and Execute Programs
Games = Engage and Challenge
Assessment = Measure
Analytics/Feedback = Understand and Improve
Mastery = Demonstrate Competency
35. Recommended Development Priority
Do not attempt to build the entire ecosystem simultaneously.
Phase 1 — Core Learning
User/role management
Course/Lesson
Student View
Tutor View
Course Studio
CSV/XLSX Import
Basic Activities
Assessments
Progress
Analytics/Feedback
Phase 2 — CTE Execution
CTE Activity Engine
Digital/Offline/Physical activity modes
Classroom Mode
CTE Simulation Engine
Test/Debug functionality
Phase 3 — Creation & Programming
Coding Lab
Coding Challenges
Secure code execution
Projects/Portfolio
Advanced simulations
Phase 4 — Engagement
Game Engine
Learning games
Classroom games
Same-device multiplayer
Online multiplayer
Phase 5 — Intelligence
Mastery Engine
Adaptive learning
AI hints
AI-generated practice
Advanced learner/tutor analytics
36. Key Architectural Decision
The most important decision is:
Do not make Term, Week, Module, Course Code, Simulation, Coding Lab or Game the fundamental learning object.
The fundamental learning object should be the:
LESSON + ACTIVITY + ASSESSMENT + COMPETENCY
The organizational structure can vary.
For example:
SCHOOL:
Course → Term → Week → Lesson
AFTER-SCHOOL:
Course → Module → Lesson
OTHER YIGATECH COURSE:
Course → Module → Lesson
BOOTCAMP:
Course → Module → Lesson
All ultimately connect to the same underlying activity, assessment, analytics and mastery infrastructure.
This allows Yigatech to support school curriculum, after-school courses, bootcamps and future digital-skills courses without rebuilding the LMS for every course type.