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.
- Period
- Spring 2026
- Role
- Solo
- Stack
- C · Make
- Source
- Repository
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.