A course becomes a product when its answers create expectations that the team must support, correct and improve. The moment an AI faculty clone gives two students conflicting guidance, the work expands from publishing lessons to managing a system people rely on.
At 8:14 on Monday, Ama reported that the clone had contradicted the answer it gave her classmate. That ticket forced a harder decision than choosing which response sounded better. The course team now owed both students an explanation, a correction where needed and a way to prevent the same disagreement from quietly reaching the next student.
The support ticket changed the team’s responsibility
Before the ticket, the clone could be described as part of the learning experience. It answered questions, extended access to the faculty member’s material and made the course feel more responsive.
Ama’s report changed the category of the problem. A student had acted on one answer while another student received something different. The team could no longer judge the clone by how fluent or helpful it sounded in a demonstration. They had to judge it by what happened when two outputs collided.
The immediate temptation is to patch the disputed answer. Update the prompt, add a paragraph to the source material and close the ticket.
That may settle one exchange. It does not settle what the team owes every learner who asked a similar question before the patch. Nor does it reveal whether the contradiction came from ambiguous course material, retrieval failure, model variation or a question that should have been escalated to a person.
A useful support process has to preserve the evidence before changing the system: Ama’s exact question, her classmate’s question, both answers, the source material available at the time and the model configuration that produced them. Without that record, the team can fix an output while learning very little about the product.
A chatbot answer can become a company promise
In 2022, Jake Moffatt used Air Canada’s website while arranging travel after his grandmother died. The airline’s chatbot told him he could apply for a bereavement fare after completing the trip. Air Canada later refused the request because its published policy required a different process.
The dispute reached British Columbia’s Civil Resolution Tribunal. In 2024, tribunal member Christopher Rivers rejected Air Canada’s attempt to separate the chatbot from the company behind it. The decision held Air Canada responsible for the information presented through its website and ordered it to compensate Moffatt. The case was reported by CBC News and documented in the tribunal’s published decision.
The mechanism matters here. A company placed an automated answer in front of a customer, the customer relied on it, and the company later discovered that another part of its system said something else. The contradiction did not remain a content-quality issue. It became a question of responsibility.
Ama’s ticket carries the same product lesson at a smaller scale. Once a course puts an AI representative between faculty material and a student’s decision, the team owns the answer path. A disclaimer may set limits, but it cannot replace correction, traceability and a clear route to human review.
Consistency needs a product decision
The team first has to decide which questions the clone may answer with confidence. Course logistics might allow a direct response from approved material. Interpretive questions may need citations and uncertainty. Advice that affects grades, money, safety or a student’s next major commitment may require escalation.
That boundary should appear in the product itself. Students need to know when an answer comes directly from course material, which source supports it and how to challenge it. The course team needs a review queue that groups similar reports instead of treating every ticket as an isolated complaint.
There is also a communication obligation. If Ama received a corrected answer, her classmate should not be left with the conflicting version. If the issue could have affected other students, the team needs a defined threshold for contacting them too. Quietly improving tomorrow’s output leaves yesterday’s reliance untouched.
This is where a faculty clone stops behaving like recorded content. A video can contain an error, but it gives everyone the same error until someone replaces it. A generative system can produce different errors for similar questions, which makes detection harder and correction more selective. Product operations must account for that variability.
The same principle applies when deciding what an AI representative must refuse before it uses someone’s identity. I explored that boundary in What Must Ama’s AI Avatar Refuse Before Her Face Is Approved?. Approval should follow tested decisions, including what the system cites, escalates and declines.
Close the loop before adding more capability
The next release should begin with Ama’s ticket, not a new feature list. Reproduce both answers. Identify the source of the disagreement. Decide whether either student relied on incorrect guidance. Correct the record with everyone affected. Then turn the case into a permanent evaluation that the clone must pass before another release.
Air Canada’s chatbot dispute reached a tribunal because conflicting information remained attached to the organisation that published it. A course team does not need to wait for stakes that high. One contradictory ticket is enough to establish the operating rule: every automated answer needs an owner, every correction needs a reach and every unresolved boundary needs a human path.
Comments
No comments yet.