Teaching / Learning Systems

Teaching as systems engineering for human capability.

I design learning around authentic decisions, readiness and evidence — not content coverage alone. Students should leave able to explain, build, test and defend an engineering choice under realistic constraints.

20 UnitsStructured weekly lecture grammar in iSCARB
5 CLOsExplicit learning outcomes mapped to evidence and readiness
Engineering FirstProblems, mechanisms, trade-offs and defensible decisions
Evidence DrivenStudents demonstrate capability rather than recall alone
Teaching philosophy

Start with a consequential problem. End with evidence of capability.

My teaching approach treats a course as an operating system for learning. Each week begins with an ill-structured engineering problem, establishes the domain spine, teaches the mechanisms that make the problem solvable, exposes common misconceptions, then asks students to produce evidence that they can act.

01 · FRAME

Make the decision visible

Begin with a real engineering dilemma so students know what the knowledge is for.

02 · UNDERSTAND

Teach mechanisms, not slogans

Build the technical spine: architecture, failure modes, constraints, measures and trade-offs.

03 · TEST

Surface misconceptions

Use polls, pause-and-discuss prompts, cases and collaborative work to make weak reasoning visible.

04 · EVIDENCE

Require a defensible artifact

Students finish by explaining, building, testing or defending a choice against explicit criteria.

COURSE · 01

CPIT-455 — Software Engineering II

A senior software-engineering course centered on reliability, safety, security, resilience, reuse, distributed systems and systems of systems.

Focus: dependable and large-scale software systems
Method: engineering cases, evidence and explicit decision trade-offs
Output: students reason about failure, architecture and system consequences
Visit course site →
SYSTEM · 02

iSCARB — AI-assisted lecture engineering

A structured system for turning source material into evidence-rich weekly learning experiences while preserving technical depth and enforcing a fixed pedagogical grammar.

Grammar: 20 units from hook and domain spine to readiness
Constraint: technical fidelity before visual decoration
Quality: alignment checks, interaction requirements and evidence gates
R&D · 03

CIMT → IMAM → iSCARB

My curriculum-design work evolves through iterative educational R&D: culturally responsive computing, GenAI-assisted curriculum design, and increasingly explicit readiness and evidence systems.

Question: how does AI improve instruction without flattening disciplinary meaning?
Design: cycles of implementation, reflection and refinement
Goal: scalable instructional quality with visible pedagogical logic
BRIDGE · 04

Research-to-classroom

Research questions become teaching cases, and teaching failures become research questions. The boundary between scholarship and course design is deliberately porous.

Research informs: cases, mechanisms and evaluation
Classroom informs: usability, misconceptions and design constraints
Result: teaching systems that can be studied, not merely delivered
What students practice

Engineering judgment under constraints.

The objective is not to memorize a definition of reliability, safety or security. It is to know what evidence changes the decision and what compromise the system can tolerate.

ExplainTranslate technical mechanisms into a defensible engineering argument.
DesignChoose architecture and controls against explicit requirements.
TestEvaluate failure modes, assumptions and evidence.
DefendJustify a decision when every option carries trade-offs.

Interested in curriculum design, educational AI or teaching collaboration?

I collaborate on higher-education readiness, engineering education, GenAI curriculum systems and evidence-centered learning design.

Collaborate →