Skip to content
Kanishk Sama
← Projects

Self-Learning Tech Support Decision Tree

A C data-structures lab — an interactive tech-support diagnosis tool that starts from two solutions and permanently learns new ones, grafting new questions into a binary decision tree instead of hard-coding them.

SoftwareVerification
Period
Spring 2026
Role
Solo
Stack
C · Make

The problem

This was ECE 312’s Lab 4: build an interactive tech-support tool that starts from almost nothing — a two-question tree with two solutions — and grows correctly through use. Every diagnosis routes through a decision tree the program can also edit: when a suggested fix fails, the program learns a new distinguishing question and permanently grafts the new problem into the tree, rather than the tree being a fixed lookup table written in advance.

What I built

A binary decision tree of question and solution nodes, plus the supporting structures it needed built from scratch: a FrameStack for iterative (non-recursive) traversal, an EditStack for undo/redo, a linked-list queue, and a hash table mapping symptom keywords to solution IDs. Binary file persistence saves and loads a session’s tree. A shortest-distinguishing-path finder reports the fewest questions needed to tell two solutions apart, and a visual tree explorer renders the current state.

The lab’s constraint shaped the implementation as much as the feature list did: recursion was only permitted in free_tree and count_nodes — every other traversal, including the core diagnosis loop, had to be iterative, which is what FrameStack exists for.

Verification

Two things had to hold for the submission to count: the tree had to stay structurally valid after every learn/undo/redo cycle, and the knowledge base had to actually grow to at least 25 nodes through real diagnosis sessions, not a fixture loaded in from outside. Tree-integrity validation and a dedicated test suite (tests.c, test_globals.c) covered the data-structure correctness; growing the required 25-node techsupport.dat file end to end covered the behavioral requirement — that the learning loop actually works, not just that the tree functions compile.

What I’d do next

  • A fuzz-style pass that runs many randomized diagnosis sessions and checks tree integrity after each one, instead of relying on the sessions I ran by hand.
  • Full-text symptom search, extending the hash table beyond exact keyword-to-solution lookup.