In this article, we will explain how we created a solution to simplify, improve, and automate the difficult task of articulating courses in the transfer application process from one (or more) colleges to another institution.
The Need - Why Is Articulating Courses a Problem?
A Higher Education institution can receive thousands of transfer applications each semester. Students from all over the country may want (or need) to change from one institution to another, and of course, they would love to be able to “convert” all the courses they have taken and passed in their old institution into credits and courses in their new institution.
When an institution receives a transfer application, the application will always include a list of the courses the student has completed at their previous institution.
At this point, someone, or something, needs to look at those external courses and articulate them, or make a decision about which courses in the new institution are equivalent to the courses from the previous institution.
Luckily for articulators, some states have tools to help. For example, in California, a system called ASSIST publishes the articulation rules each year for articulating courses for most of the institutions in the state. So, if I want to articulate CS 112 from Allan Hancock College to the right courses in another institution in the state, I can search and download a pdf file with articulation rules for each major or department with information like this:
Fig 1. Simple Assist articulations
However, even when articulators have these files to help, articulations can be complex.
In many cases, the articulation rule does not map a single external course to another single course. Courses can be a part of a group that is articulated to another group of courses, like this:
Fig 2. Group Assist articulation
Sometimes an external course is a member of more than one of these articulation groups. In this case, their different articulations should be mutually exclusive so students do not earn too many credits. But if you choose one articulation result for the student and ignore the others, you can negatively impact the student’s transfer credits.
This is an example of multiple articulations for a set of physics courses:
Fig 3. Multiple group Assist articulations
And, to make it more complicated, the course PHYS 141 is equivalent to the course HNRS 134, which is another thing to consider when articulating.
When there are several options to articulate an external course, a student may have more or less chances to be accepted into the major they are applying to, depending on the articulation that is chosen. For example, a student can have ART 203 from the College of Someplace, and this course can be articulated to DRAW303 or ARCH204. But we do not want to articulate it to both, because that would be more credits than the student deserves. If the student wants a major in Architecture, ARCH204 will be better for him, but if he is pursuing Design, DRAW303 would be better. Decisions like this make the articulation process time-consuming.
And, of course, the same course PHYS 141 taken in 2006 could need a different articulation than if it was taken in 2022.
What if the student, instead MATH 203, wrote MATH203 or MATH-203 in the transfer form? Or MAT 203 (without the H)?
If the articulation process is manual, it can take a long time per application to study each course and each possible combination to give the student the best outcome of the articulation process. And, well… imagine doing this for ten thousand applications each semester!
We can see that this process is complicated, tedious, and slow. It’s also very prone to simple human errors that can affect students’ futures in a very complex way.
The Idea: An Automatic Articulation Tool
To improve this process, a customer asked Unicon to create a new articulation application that could automatically articulate a transfer student’s external courses to the best possible combination of courses based on the major for which they were applying.
The goal was for this system to be able to ingest articulation rules from as many sources as possible. Because the customer was in California, ASSIST was designated as the main source, but there were still a lot of other possible sources for rules that could be loaded into the system. And of course, the system needed to support a manual definition of articulation rules.
The articulation tool also needed to be flexible enough to allow one to overwrite and edit uploaded rules, because sometimes rules would change before new ASSIST data was available.
There are many courses at any institution that do not articulate to courses in other institutions. There are also cases where an application has typos or incorrect course numbers. In this case, we needed the system to display alerts when a course couldn’t be articulated based on any of the existing rules. Then we needed to provide a capability for the users to respond to the alerts, by creating a manual rule for the course, or, in the case of typos (“MAT-202” instead “MAT 202”) assigning course prefixes that are equivalent, or even indicating that it is correct for the course to have no articulation.
Of course, the tool needed a friendly user interface to make all these actions easy and fluid.
And very, very, very important: The articulation system needed an API so other systems (for example, the system that evaluates the applications and scores them) could use it.
There were some other interesting requirements related to the architecture and the security of the system that were defined as we began development. And of course, more requirements surfaced as we continued and started testing.
The Implementation. Divide and Conquer!
The Universal Rule Model
One of the first challenges was to design how we were going to define a rule. We needed to store the rules in the database and to convert all the different formats of rules to that basic “rule definition.”
As a starting point, we looked at ASSIST. ASSIST allows you to export the rules in an XML format. This XML format provided us with some ideas about the information that a rule needed, but, sadly, it was over-complicated, it was missing some of the information we needed to store in the rules, and we found it ambiguous in some scenarios. Additionally, XML could be more user-friendly. Due to all this, we decided not to reuse the ASSIST format as our main rule format and designed our own.
We created a JSON model where we added all the information needed for a rule. We started by defining the logical expression that was defining the rule. We could use “and” and “or” and build a complex Boolean expression that would be true with the right courses.
Then we needed to store the outcomes of that rule, which could be one or many, as we have explained before. We called these “rule variants” where a rule with a unique Boolean expression could have different outcomes. This included the possibility of changes to the rule over time, because the rule could have an outcome with one set of courses from 2006 and a different set of courses from 2023.
Of course, we also needed to include all the information about credits, general education codes, the institution origin of the rule, and some metadata such as the creation date, modified date, created by, and modified by.
The Database
Once we had the needs of the universal rule format defined, we could define the database to store all the needed entities.
An interesting feature was that we needed to be sure that the rule allowed us to evaluate its Boolean expression using all the equivalents of the course prefix (MAT 202, MAT202, MAT-202, MATH202…etc.) So, we created a separate table for the external courses with the capability to define equivalent prefixes, and the reference to that table is what is used in the Boolean expression in the rule.
We also stored all the additional entities needed in the database, such as the external institutions, and the list of courses from our own institution to use in the variants. We needed to store extra things useful for other features as well, such as the alerts that the articulation tool generated when it could not find a rule for a course.
The Translators
Our tool needed to support different sources for the rules. Initially, one source was ASSIST and the other was “manual.” Later on, other sources were added. Each source was completely different, and to include them in our common format, we created an application for each one that converted them to our common format. In that way, in the future, if there is a new format that must be added to the system, only a converter from that format to our common format will be needed, and the tool will work with it seamlessly.
Fig 4. Simplified diagram for the articulation system
The API
We created an API that was designed to allow the most basic CRUD operations and more complex operations, such as articulating a list of courses to all their possible rules.
This API was able to read common format rules and insert them cleverly into our database, merging them with existing rules if needed and creating the correct variants.
The objective of this API was to be as quick as possible and keep the code simple. We decided not to include the capability to calculate the best articulation for a student within this tool to streamline the articulation and re-articulation process. Instead, it calculated ALL the possible articulations for a list of courses provided. The calculation of the best outcome possible was executed using a different tool. That code was created by our team, too, in another application.
The UI
We created a UI to upload ASSIST files and CSV files containing articulation rule information. When a file is uploaded to the right bucket, the conversion from “some-format” to “common-format” is triggered. Once this converter finishes, it drops a file with the common-format JSON rules into another bucket. Another trigger is called, and then the ingest process that is able to ingest rules in a common format using the API is called.
This process involves multiple systems and generates a series of logs that the UI can render visually and allows users to understand if any error happens and where, or displays a report of the success statistics.
We also developed a page to search and view rules, and a rule editor UI to support creating new rules and editing existing rules. The UI also includes a page to display alerts when a course is not in any rule, making it easy to create a rule or take another action to correct that issue.
The UI also provides capabilities to maintain the list of external courses, allowing users to add aliases to account for typos, so that the course MATH202 from some university can have the alias MAT202. And that is useful for handling honors equivalencies in the articulations, so that MATH202 could be equivalent to HNRS202 too.
The Articulation Process
As mentioned above, the articulations happen in the articulation tool. However, the calculation of the best possible combination of articulations occurs in some code that is in a different part of the application.
The articulation process follows these steps:
- The articulation tool receives an external course from the student’s application and returns all the possible rules available for that course.
- The logic to evaluate the rules finds all the rules that use the same course and therefore are mutually exclusive.
- As the application can only use courses for one rule, the process creates a list of all the possible combinations of articulations with the courses with more than one possible rule based on mutually exclusive information.
- In the application evaluation process, the evaluation logic evaluates the list of possible combinations of rules generated in step #3 and, based on admissions requirements, selects the combination that is the most beneficial for the student.
The Benefits
We can divide the benefits from the articulation application into two big blocks: savings and fairness.
For our customer, the original process to evaluate transfer articulations was very time-consuming. It required transfer students to spend time making decisions about how their courses mapped to the customer’s requirements, which were often inaccurate and incomplete. This resulted in time spent by a team of several persons following up and validating student inputs. In the new process, the initial ingestion of data and application process was also time consuming, as the team needed to spend time updating the database with rules not provided from ASSIST, providing alternate course prefixes to accommodate typos and other updates. Nevertheless, with each additional application cycle, the process is completed more and more quickly and efficiently as the database of rules grows.
The team can now complete preliminary rounds of admissions decision-making in a relatively short time frame. This time reduction allows the team to focus on quality and refinements to how well admissions criteria match with major requirements, and to attend better to the exceptions and students with questions.
Fairness is the second strong advantage of this service. Articulations are consistent across all students. Each student receives the best possible set of articulations. Students can no longer misrepresent their courses’ mappings to the customer’s requirements. There is no dependency on human articulator judgment and possible biases. Students are not rejected due to human error. Students are no longer conditionally accepted when they should not be, only to have acceptance withdrawn later.
In addition, there is now a dictionary of rules that is fast and easy to access and can be consulted using the UI in cases where students seek advice about what courses to take and how to optimize their chances for admission.
The Future
As explained before, this system has saved time and added quality to the articulation service, but it still can be improved. Here are some possible improvements that we are thinking of for future versions.
- Use of AI to propose articulations for courses without rules. When a course does not have a rule in the database, an AI system could propose the most appropriate ones and the human articulator only needs to agree, instead of generating the rule.
- Use of AI to detect and clean the typos/errors from the applications. Avoid alerts based on slight modifications in the prefix and have the AI system evaluate if there is a course that should be used based on the prefix and name of the course.
- Ingest new sources of rules. At this moment, the source of rules is ASSIST, but the system is designed to in the future allow the addition of multiple new sources, just by adding the translator piece between the source and the rule common format that we designed.
Last comments
We are very proud of the work we did with this system. It was complex, but our implemented solution covered the requirements and sometimes exceeded them. The feedback we receive from the users about it always puts a smile on our faces. And, as Unicon, we love our job in education because the direct or indirect result of all our projects is to help people to learn and become better versions of themselves, improving the world and the future of humankind.
