Responsible AI Principles and Course Review

16.1 Explainability, Interpretability and Transparency — Three Distinct Principles

A responsible AI system must let humans understand, inspect and trust its decisions. Three terms describe this requirement, and they are not synonyms, even though some research papers use them interchangeably. Each answers a different question.

The three terms sit on one line from the whole system down to a single decision. The table below summarizes how they differ:

In traditional software engineering the distinction matters less, because software is deterministic. You write an algorithm or pseudocode, you run it, you get an output and you can read the code to understand why. Machine learning is different. Many things happen behind the scenes in the algorithm, especially during learning and inference, and that is why these three terms exist.

The relationship among them was examined directly. If a model is explainable — if it can produce a prediction and explain that prediction — does it imply it is already interpretable and transparent? The answer given is yes, inherently. Explainability depends on there being some visibility into logic and a way to interpret steps. The practical caveat is whether that visibility is made explicit. Logging intermediate results, surfacing feature contributions or rendering a decision structure makes interpretability and transparency concrete. An explainable model should be interpretable and transparent, but only when the implementation records and exposes the intermediate reasoning rather than leaving it implicit.

16.1.1 Formal Intuition and Why Trust Matters

Explainable AI is defined as a set of tools and methods that help humans understand how a model reached a decision. Without it, trust fails. An illustration used is a model that tells a judge to convict. Without proof or a reason, the judge cannot execute the decision. Trust in the judgment requires understanding the basis. Explainable AI fills that gap by making the prediction auditable: inputs can be questioned, factors can be inspected, and the decision can be challenged.

The productive way to keep score for interpretability is to think of each feature as adding or subtracting risk points, so the total is a transparent sum rather than a single mysterious number. Reference treatments of the subject add two distinctions that sharpen the picture. A model is intrinsically interpretable when a human can understand its internal workings directly — a small decision tree, a short rule list, or the scorecard that appears next in this lecture. When the internals stay hidden, we can still attach post hoc explanations to individual predictions, for instance by identifying which inputs mattered most for a specific outcome. Those two routes are not equally strong: an explanation derived from outside observations of an opaque model is an approximation, and for high-stakes decisions — sentencing, bail, medical treatment — the safer engineering choice is usually an intrinsically interpretable model whose full logic can be inspected, rather than an opaque model wrapped in explanations.

This is why trust is the real subject here. In policy discussions, transparency means disclosure: telling users and the public what the system does, what data trained it, and how it was evaluated. Auditing a system for fairness, safety or security is far easier when the internals can be inspected, and affected individuals can contest a decision only when they can see its basis. In practice, explainability is used for model debugging more often than for anything else: developers check whether a model that performs well is actually relying on the right signals rather than on shortcuts such as background pixels or uninformative metadata.

Explanations serve five distinct purposes, and the right explanation depends on which one is in play: debugging (sanity-checking that the model predicts for the expected reasons), auditing (checking fairness, safety or security properties of a decision rule), human oversight (a judge or doctor deciding when to trust or override the model), dignity and appeals (letting affected people see the basis of a decision and contest it — for example, a defendant whose wrong age was used in a risk score), and discovery (scientists using explanations of opaque models to form hypotheses). The same model may need different explanations for a developer, a judge and the person being decided about.

Picture a transparency spectrum with a pure black box at one end and a fully readable white box at the other: a black box has zero visibility, a small decision tree sits near the white end because every split can be rendered, and a deep network sits close to the black end — its structure technically exists, but the number of steps makes it unreadable in practice. The spectrum is the takeaway: acceptable transparency is not uniform across model families.

Each boundary above has a practical consequence for how students misuse the terms:

In the criminal-justice and credit industries this distinction is not academic: regulators and courts increasingly expect an auditable, additive explanation of a high-stakes score rather than a single probability, which is why scorecards remain a preferred production pattern — and why the opaque alternative has generated sustained public controversy over bias and auditability.

16.1.2 Student Questions and Answers

16.2 Explainable AI in Action — Recidivism Risk and the Interpretability Scorecard

Two concrete scoring designs illustrate the difference between an opaque model and an interpretable, explainable one.

16.2.1 Recidivism Risk Assessment — Opaque Versus Explainable

A model predicts the risk that a person who has already offended — theft, assault or other crimes — will re-offend. The input features are the same in both designs: age of the person, number of prior arrests, criminal history and other factors. The algorithm consumes these inputs and outputs a risk level.

In the opaque (black box) design the single output is high risk of re-offending. When that prediction reaches a judge, the natural question is how the model arrived there. The answer is unknown because the internal mapping is hidden. The decision is difficult to understand, to audit or to contest.

In the explainable design each parameter carries an explicit point contribution. The model is no longer a single score: it is a small, inspectable arithmetic rule. Suppose the person is 25 years old. Because the person is young and may live to 60 or 70, there remain 40 to 50 years of expected life during which re-offending is statistically possible, so youth adds risk. In the illustration age contributes $+2$ points. Prior arrests are counted directly: four prior arrests contribute $+4$ points (one point per arrest). A misdemeanor history or poor behavioural history contributes $+3$ points.

The judge now receives not only the label high risk but also the nine-point breakdown, the per-feature contributions and the threshold logic. The inputs can be questioned, the factors audited and the decision challenged. That auditability is what explainability provides.

Picture the scorecard as a horizontal bar chart. The horizontal axis lists the features — age, prior arrests, history — and the vertical axis is risk points. Three bars rise above the zero line: +2 (age), +4 (prior arrests), +3 (history), and a horizontal rule at 7 marks the high-risk cut. The total bar reaches 9, visibly past the rule; the reader can see in one glance which feature pushed the score over the threshold. That single picture is the difference between a number and an explanation.

These three assumptions define when the scorecard story is honest — and the traps below are where the story gets misread:

16.2.2 Interpretability Scorecard and Credit Risk

The second illustration uses a credit risk scorecard to show that contributions can be both positive and negative. Positive points raise risk; negative points lower it. The verbal description is: plus 2 points if income is less than \$30,000 (low income may increase risk of defaulting), plus 3 points for a previous loan default, minus 2 points for stable employment (stably employed individuals carry lower risk), minus 1 point for a long credit history.

Interpretability here is exactly the ability to see that a minus sign can reduce risk, not only increase it. The verbal distinction reinforced alongside this math is: interpretability describes how humans understand the logic and reasoning inside the model (the additive steps), while explainability describes the ability to explain the final output for a specific person — for example, Person A has high risk because prior arrests contribute strongly and young age contributes moderately.

The same bar-chart picture now has bars in both directions: two bars rise above zero (+2 for low income, +3 for prior default) and two bars hang below it (−2 for stable employment, −1 for long credit history). The net total of +2 is small because the negative bars cancel most of the positive ones. Seeing the shape — which bars push up and which pull down — is what makes the score interpretable, and stating "for this applicant, stability offset the risky signals" is what makes it explainable.

These limits are the flip side of the scorecard's strength — and the traps below are the common mistakes that follow:

In practice, additive scorecards of this form are a production standard in consumer lending: when a loan is declined, the applicant can see which factors drove the decision, and regulators can audit whether protected attributes enter the rule at all. The same auditable-sum pattern appears in criminal-justice risk assessment — including the proprietary recidivism tool that public reporting criticized for opaque scoring, where researchers have shown that a transparent scorecard trained on the same data reaches comparable accuracy while letting a judge see every input and boundary. Expect to reason through a similar additive scorecard in an exam: given per-feature points and a threshold, compute the total, map it to a risk band, and justify why a factor adds or subtracts points.

16.3 Explainability Across Predictive, Generative and Agentic AI

Explainability is not confined to one paradigm. It can appear in all three phases of modern AI.

A practical implementation choice cuts across all three: save outputs. Even intermediate outputs generated along the way should be persisted, whether in a database or a log, so that later review is possible. Memory management for agents — where a multi-step task is only complete at the final step but intermediate state must be retained — was referenced as already covered around the seventh and eighth sessions.

The pattern across the row "what to persist" is the unifying idea of this section: explainability in every phase is really the discipline of keeping step-level evidence.

16.3.1 Student Questions and Answers

16.3.2 Tools and Resources

The Explainable AI conference (often held in October, with a history of at least seven to eight years — active already in 2018–2019, before generative AI was widely discussed) is a recommended venue for open-source and commercial explainability tools and papers. Participation in 2018 and 2019 was noted as particularly informative.

An interactive explainability website from AWS was highlighted as a strong learning aid. Between roughly 2021 and 2024, AWS allowed users to manipulate visual images and input parameters on the left and showed on the right what happened behind the scenes for basic ML algorithms (decision tree, Naive Bayes) and deep learning algorithms, with concise written explanations. The link that appeared in a 2022 slide deck no longer resolves, and a current equivalent was not located at the time of the session. The pattern — left-side parameter variation with right-side explanation — remains a useful design template for any explainability interface.

Reasoning-oriented models and general models differ. Reasoning models such as DeepSeek expose stepwise justification directly; general models require an explicit prompt to emit reasoning. Platform example given: Hugging Face for testing DeepSeek reasoning behavior.

16.4 Fairness and Bias — Systems Concern and Six Sources

Fairness is a system-wide concern, not a dataset-only concern. Bias must be anticipated at every level: in the training data, in the model itself and in real-world outcomes. Bias can appear at multiple stages, so a single-stage fix is insufficient.

The canonical industry example is the AI recruiting engine at a large e-commerce company in 2013 that showed bias toward men. The engine was trained on historical hiring patterns over a ten-year period (2003–2013) in which the training data reflected roughly $78\%$ male and $22\%$ female representation (summarized elsewhere as $80\%$–$20\%$). Because the past data already encoded male dominance, the model learned and amplified that pattern and effectively predicted no women for recruitment. The root cause identified is historical bias — a biased past that cannot be changed retroactively, though today synthetic data generation could be used to augment underrepresented groups.

16.4.1 Sample Versus Population

In statistics, population means every single instance available — for example all 3,000 students in an engineering college. Sample means a small subset drawn from that population. Several sampling techniques exist. Random sampling gives every member of the population an equal chance of being picked, but by luck it can under-represent a small group — if one classroom holds most of the female students, a random draw may pick almost no women at all. Stratified sampling splits the population into groups (strata) and draws a fixed number from each, guaranteeing each group is represented.

Many biases trace to how sampling is performed. The six sources of bias presented are from the course textbook.

16.4.2 The Six Sources of Bias

1. Historical bias. Data reflects a biased past even when collection itself was faithful. The hiring history described above is the textbook case. Formally, if $p_{\text{train}}(y\mid x)$ inherits an earlier skewed distribution $p_{\text{history}}$, then modelling will reproduce that skew — the model simply reports what the past already decided. No direct correction to the past is possible; mitigation includes resampling, reweighting or synthetic generation to reduce the disparity before training.

2. Tainted label (label bias). Human labeling introduces conscious or unconscious bias. The example given: in a region where the local dialect sounds harsh or rude, annotators conditioned by their own judgment may label speech from that region as negative, angry or rude. The judgment is subjective and may be untrue — the speakers are not rude, their speech merely appears that way to outsiders — yet the label bias propagates into the model. This is especially problematic in subjective tasks, where the "correct" label is itself a matter of judgment.

3. Skewed (cued) sample. Data is collected in a way that over- or under-represents certain groups or situations, so the sample does not represent the population. The electoral polling example was used: post-election interviews with a non-representative set of voters may favor one party, and then the actual results diverge sharply. The crime dataset illustration is that records drawn mostly from high-policing neighborhoods while missing low-policing areas create a skewed sample that distorts the model's view of crime distribution — police look more where they expect crime, find more there, and the data confirms their expectation.

4. Limited features. The model is built from an incomplete or non-comprehensive feature set. For a credit scoring model one might include income, trade history and education but omit rent payment history. Omitting that relevant signal limits the model's ability to assess creditworthiness correctly. This is a feature-selection omission rather than a sampling imbalance: the data collected is fine, but it does not carry the information needed for fair decisions for everyone.

5. Sample size disparity. Two groups have vastly different data volumes. Group A has 10,000 records, Group B has 200 records. With so little data for Group B no good judgment can be made — either Group B is ignored (which itself is a fairness problem) or extra effort is needed to increase its sample size. This source is closely related to skewed sample but emphasizes count imbalance rather than geographic or demographic coverage: a model trained mostly on one group simply has little signal about the other, so it treats the minority group's sparse records almost like noise.

6. Proxy. Direct data is unavailable so an indirect signal is used as a stand-in. The example is a zip code in Bangalore (Sadashi Nagar) where many politicians and affluent households reside. Using that zip code as a proxy for wealth allows an assumption that the roughly 50 families in the zip code are all rich households without visiting each household. The proxy may be directionally correct but is not perfectly accurate. It can misclassify non-rich households living in the same area, and it misses affluent households in nearby areas whose zip codes were not included. Proxies are common when direct access to a region or population is unavailable, but they introduce clear bias risk — and note that proxies also appear when a protected attribute is removed deliberately: the model may simply learn a correlated stand-in such as an address.

The six sources were presented visually in the textbook, and students were invited to contribute examples for historical bias and tainted labels during the session. Picture the figure as a horizontal pipeline with six boxes feeding a model: history (the past), labeling (the annotators), sampling (how data is collected), features (what is collected), volume (how much is collected per group), and proxies (what stands in for what is missing). Each box is a different stage, which is why the same diagram makes the core message visible — bias can enter at any one of the six boxes, so fixing a single box never suffices.

In practice these six sources surface constantly: election polling misses the actual result because the interviewed voters were not representative; crime datasets skew toward the neighborhoods that are policed more; and zip-code-based wealth inference is a standing example of proxy bias in credit and marketing decisions.

16.4.3 Student Questions and Answers

16.5 Safety — Robustness, Monitoring and Alignment

Safety was defined as prevention of system failure or malfunction that results in death or serious injury. That is the most critical reading, but safety also includes loss of or severe damage to property — illustrated by landslides and earthquakes that move or destroy entire properties, including heavy rains in Coorg, Karnataka in the last two years that dismantled structures — and harm to the environment or society.

In machine learning, safety concerns arise from incorrect predictions and unexpected behavior. As autonomy increases — self-driven cars, humanoid robots, ML-controlled aircraft (Boeing, Airbus), autonomous road navigation, medical devices such as pacemakers, railway collision-avoidance and traffic control, nuclear-plant anomaly detection and safety monitoring, industrial robots — a wrong decision can directly cause death, injury, equipment damage or environmental harm.

A useful reference cited is mlsafety.org for further reading on ML safety categories.

Three categories organize ML safety work: robustness, monitoring and alignment.

16.5.1 Robustness — Handling Unexpected Inputs

Robustness concerns the input. How does the system behave when inputs are abnormal, unexpected, corrupted, adversarial or deliberately manipulated? The textbook uses a stop-sign example. The model is trained on a canonical sign: red background with the word STOP. In reality the same physical sign may be defaced with white or black patches or other occlusions, obscuring the red background or the text.

Robustness is the property that the system still behaves safely in those conditions. In practice this is often handled with a confidence score and a threshold. A clean sign may score $100\%$ for the STOP class. With occlusion, modern computer-vision and image-processing advances still yield a score around $60\%$ to $70\%$.

The challenge is that not every unusual or corrupted input can be included in training. The model must generalize at runtime to handle novel corruptions. The distinction emphasized is that interpretability typically targets thresholds and fallback logic explicitly, whereas training-time coverage of every corruption is infeasible.

Picture the decision rule on a horizontal confidence axis from 0 to 1. The clean-sign score sits at the far right near 1.0, and the occluded-sign scores cluster around 0.6–0.7. A vertical line at $\tau =0.7$ divides the axis: everything right of the line means stop, everything left means fallback. Moving the line right makes the stop region smaller (more caution); moving it left enlarges the stop region (more risk). The visual takeaway: the safety behavior is set by where the vertical line stands, not by the training data alone.

When these assumptions fail, the pitfalls below are what usually goes wrong:

16.5.2 Monitoring — Detecting Anomalies Continuously

Monitoring is observing the model and detecting anomalies on a 24-hours-a-day, 365-days-a-year basis. This capability today is associated with MLOps, LLMOps and AgentOps practices. The system continuously monitors application health, infrastructure signals such as CPU and memory usage, and model behavior, so that problems can be detected beforehand and corrective action taken before a disaster occurs.

Concretely, monitoring watches three layers at once: the infrastructure (CPU, memory, latency, error rates), the application (whether requests succeed and how long inference takes), and the model itself (distribution of predictions, confidence levels, and signs of drift — input data shifting away from what the model saw in training, or the model's predictions shifting even on stable inputs). An alert fires when a metric crosses a threshold, so degradation is caught in days or hours rather than after a disaster. Monitoring therefore complements robustness: robustness asks whether the model can tolerate a single unusual input; monitoring asks whether the deployed fleet is drifting or degrading over time and whether early warning is possible.

16.5.3 Alignment — Doing What Was Actually Intended

Alignment asks whether the system is doing exactly what its designers intended, or whether it has found a technically successful but misaligned way to satisfy the stated objective. This is described as a million-dollar question.

Alignment is especially relevant for AI agents that execute multi-step plans. For predictive models and single-turn generative models it may be less central, but for agents that act over time and optimize a stated goal, misalignment can create safety consequences. Students were invited to propose additional alignment examples in chat. The same failure pattern shows up in ordinary products: a recommendation system told to maximize watch time can steer users toward ever more extreme content, and a pricing model told to maximize revenue can learn to exploit loyal customers — both satisfy the literal objective while violating the intent behind it.

16.5.4 Industry Applications for Safety

Aircraft flight-control logic, autonomous vehicle pedestrian and road handling, implantable medical devices, railway traffic control, nuclear-plant monitoring and industrial robotics are all cited as domains where ML safety failures carry immediate physical consequences. In each, a wrong prediction is not a rounding error but a possible death, injury or environmental event — which is why robustness, monitoring and alignment must be designed into the system rather than added after testing.

16.6 Security and Privacy

Security and privacy were presented as the final two principles in the responsible AI arc.

16.6.1 Security — The CIA Triad and Beyond

Security is the protection of assets, data, systems and individuals from threats, risks and harm. The scope includes application-level, data-level and image-level security, and in DevOps it has matured into distinct disciplines such as DevSecOps, SecDevOps and DevOpsSec.

The classic security characteristics are summarized as CIA — confidentiality, integrity, availability — plus three complementary properties: authentication, authorization and non-repudiation.

Taken together, CIA plus authentication, authorization and non-repudiation characterize application security in general. The three additional properties complete the picture:

Data security has additional characteristics that were not examined in detail here.

When these principles are applied to machine learning, the assets broaden. Confidentiality means protecting not only code or application endpoints but also datasets and models from unauthorized access. Integrity means an attacker should not be able to modify training data to influence the deployed model, nor manipulate the model or deployed artifacts. Availability means ML prediction services — typically inference endpoints — should remain available to legitimate users despite malicious requests.

16.6.2 Privacy — Control Over Personal Information

Privacy is the ability of an individual or group to control what information about them is shared and how shared information may be used. The assessment offered is that privacy has been broadly mishandled in consumer platforms such as Facebook and Instagram. Even when users sign agreements and companies assure data privacy, it is unclear how much assurance is truly honored, and ML systems amplify the problem because they can quietly learn sensitive information that users provide unknowingly, including through chat systems.

AI can infer sensitive information that a person never explicitly provided by combining weak signals.

Applications built on such inference include personalized advertisement, product recommendations and customer profiling, where the inferred segment then receives targeted marketing. The inference is not explicitly supplied; it is derived.

This generalizes. Signals noted in discussion include a model inferring strengths, weaknesses or age range from behavioral and metadata traces even when the user never typed an explicit age (for example, an age prediction model that infers demographic range without an explicit "age 25" statement), or a model reapplying knowledge of a prior employer's domain after a job change because that history was retained from earlier conversation. An additional example raised was inferring behavior patterns that enable password guessing.

The counterpoint raised in class is important. When data is not identifiable as an individual, the privacy trade-off is often considered fair business practice and may be compliant with regulations such as GDPR — the COVID dataset was cited as an example where only features like sex or other attributes are shared without names or locations, so individual privacy is preserved. The same logic applies to aggregated inference: as long as no individual is identified, no privacy violation is asserted under that reading. The response confirms that view while noting that once identifiers or linkable details are present, the threat becomes real and is increasing.

Think of the privacy problem as a scale of identifiability. At one end, data carries direct identifiers (name, phone number) — private without question. In the middle, data is de-identified but linkable: a zip code, birth date and job title together may single out a person even though each alone is harmless. At the other end, data is genuinely aggregate — the COVID-style dataset — and no individual can be recovered. The inference examples in this section sit dangerously in the middle: no single query identifies anyone, but the combination of weak signals can profile a person well enough to act on. The GDPR debate turns on exactly which end of this scale a system operates at.

Personalization pipelines for advertising and recommendation are the canonical deployment context for such inferences — which is why the same weak signals that power targeted marketing are also the ones that make privacy debate genuinely difficult.

16.6.3 AI Regulations — Self-Study

AI regulation sits with individuals, organizations, nations and the world at large. The session explicitly frames this segment as self-study and not comprehensive. Reference pointers provided were the Microsoft Responsible AI Transparency Report 2025, Azure Responsible AI Principles (both covering many of the principles discussed across the last one to one-and-a-half sessions), and a Mint Foundry link surveying AI regulations across the world, with many other references available for deeper study.

16.7 Course Review — Eight Modules over Sixteen Weeks and Evaluation Structure

The course Software Engineering for Machine Learning spans eight modules across sixteen weeks. The structure reviewed at the close of the course was:

Module 1 — Foundations of ML Systems Engineering. Overall context for applying software engineering thinking to ML.

Module 2 — Requirements Engineering for ML Systems. Emphasis on goal-oriented requirements for ML and the three views used to capture requirements.

Module 3 — Architecture and Design. Multiple software architectures and their ML applicability: microservices architecture, Blackboard pattern, CQRS and others. For agentic AI, the Saga pattern (orchestration-based versus choreography-based) was introduced in the sixth and seventh sessions. Saga addresses multi-step transactions that span several services or agents: if one step fails, compensating actions roll back or reconcile the workflow. That architectural choice connects directly to agent task execution.

Module 4 — Implementation and Code Sharing. Post-midterm focus including object-oriented programming and design — inheritance, polymorphism and runtime polymorphism. The mapping to agentic AI used was: an agent is modeled as a class, with a base class for common agent behavior and derived classes for specific agents, and runtime polymorphism selects the appropriate agent behavior at execution time. Examples were shown in class.

Module 5 — Quality Assurance. Brief coverage of QA concerns for ML systems.

Module 6 — Deployment. Significant time on containers and Kubernetes, system images and custom images, deployment mechanics, deployment strategies such as canary and blue-green, and inference after deployment — particularly accessing a model through an API endpoint via FastAPI. While the steps of creating an image and pushing it to Docker Hub were shown, the end-to-end cluster-creation and global accessibility flow remains an area planned for deeper hands-on work in future batches. A run-pod-based approach for creating clusters and deploying was mentioned as the next step.

Module 7 — Responsible ML Engineering. The principles detailed in this lecture: explainability, interpretability, transparency, safety (robustness, monitoring, alignment), security, privacy, versioning, reproducibility, lineage and prominence. The prior session closed on versioning, reproducibility, prominence and lineage; this session completes the arc with explainability, safety, fairness, security and privacy.

Module 8 — Application of SE Principles for Agent TK. This did not run as a standalone module. Its content was integrated into other modules — notably architecture and design (Saga pattern) and implementation and code sharing (OOP and polymorphism). A planned handout revision will make that integration explicit for subsequent batches.

Experiential learning was emphasized. No dedicated remote or virtual lab was run for this inaugural batch. Lab assignments 1 and 2 were given (coding was only one part of those assignments). Instead the course relied on in-class demos: roughly 24 demos from the third or fourth session through the final session, typically three to four per session whenever a concept or architecture benefited from a live illustration — notably microservices and retrieval-augmented generation (RAG) architecture and others. The plan for future batches is to expand hands-on lab activities further, connecting earlier RAG teaching to actual deployment on Kubernetes-style clusters.

The eight modules in one view:

RunPod for cluster creation and deployment, FastAPI for inference endpoints, Docker Hub for image distribution, and the Saga pattern for distributed agent transactions are the concrete technologies referenced across the deployment and architecture modules.

16.7.1 Evaluation Components

Except for the end-semester examination, all other evaluation components are complete. The scheme shared in the first class is:

Quiz 1 carries 5 marks as a course quiz. Situated learning (referred to by students as Quiz 2) carries 5 marks and was confirmed as announced on the Taxila portal; students were directed to reach out to the lead learning facilitator if marks are not visible. Assignments 1 and 2 carry 10 marks each (pre- and post-midterm), and together with the two quizzes these form the EC1 component of 30 marks. The midterm examination (EC2) carries 30 marks and was closed-book; students noted that EC2 results were not visible on the Mercer Mettl or Taxila portal — the learning facilitators confirmed valuation is complete, and students were advised to email the lead learning facilitator with the instructor in copy. The end-semester examination carries 40 marks, is open book, and is the only remaining component. Regular and makeup papers are separate; four sets of question papers have been set (two regular, two makeup), with separate papers for students writing from UAE and Saudi Arabia.

Infrastructure notes: MS Teams recordings for the course remain available for two years. Webinars were conducted as four sessions (two before midterm, two after); recordings are available on MS Teams for those who could not attend live. A consolidated watermarked PDF covering the full course was uploaded last week, and a whitespace-reduced revision was requested for upload. Students who prefer two or four slides per page can configure that via the print settings of their PDF viewer.

16.7.2 Student Questions and Answers on the Course

16.8 Exam Guidance

All questions will be scenario-oriented, as in the midterm. The style will not ask for generic definitions such as differentiate, explain or describe in the abstract. Instead each question presents a scenario to analyze.

No code will be asked — code was already assessed in the assignments.

No tool-specific questions will be asked. For example, for continuous deployment either Argo CD or Flux CD could be used, but the examination will test fundamentals only, not tool choice. Questions will stay strictly within what was taught and within the consolidated watermarked PDF that constitutes the course material.

16.8.1 Student Questions and Answers on the Exam

Exam Guidance Summary

• Open book end-semester exam for 40 marks; midterm was closed book for 30 marks; EC1 assignments and quizzes total 30 marks. Combined total is 100.
• Only the end-semester component remains; all other components are complete. Portal visibility issues for marks should be resolved via the lead learning facilitator.
• Sample questions (no previous paper exists for this inaugural course) and LLM Ops / Agent Ops reference material will be published on Taxila after this session.
• Authoritative revision source is the consolidated watermarked PDF (whitespace-reduced revision). MS Teams recordings remain available for two years; four webinars (two pre-, two post-midterm) are available on Teams.
• Question paper is scenario-based, 5–6 questions per set, no code, no tool-specific tooling questions. Four sets exist (two regular, two makeup, with separate geography-based sets for UAE and Saudi). Fundamentals from taught slides only.
• Marks split per set: at least 60% post-midterm, at most 40% pre-midterm; observed variations 60-40, 70-30, 75-25. Provide assumptions explicitly and present calculations in tables where helpful.
• Do not expect back propagation through time on the exam. Do not expect pre-midterm to be excluded.

Key Industry Applications

Recidivism risk scoring and credit scorecards illustrate how additive, auditable scorecards explain high-stakes decisions to judges and analysts — the applicant or defendant can see which factors drove the score, and regulators can audit whether protected attributes enter the rule.

Interactive explainability dashboards (left-side parameter controls, right-side outcome explanation) from a major cloud provider demonstrate how varying income, age or employment features changes predicted risk and how the explanation updates live.

Reasoning models that emit chain-of-thought traces (tested on Hugging Face with binary-search reasoning) versus general models that require an explicit prompt to emit reasoning show two implementation paths for generative explainability.

Election polling and crime datasets drawn predominantly from high-policing neighborhoods illustrate skew and sample-size disparity and their downstream fairness effects.

Zip-code proxies such as the Sadashi Nagar example illustrate how indirect signals stand in for direct household-level data and where proxy bias arises.

Aircraft (Boeing, Airbus) flight control, autonomous vehicles, implantable pacemakers, railway collision-avoidance and traffic control, nuclear-plant anomaly detection and industrial robots illustrate where ML safety failures in robustness, monitoring or alignment cause physical, property or environmental harm.

Amazon recruiting engine 2013 — Amazon's 2013–2014 AI recruiting engine trained on ten years (2003–2013) of $78\%$ male / $22\%$ female historical data — illustrates historical bias amplification.

Personalization engines for advertising, product recommendation and customer profiling that infer pregnancy or demographic ranges from behavioral signals, and password-guessing from behavior patterns, illustrate privacy inference from non-explicit data.

Agent tasks such as booking a flight from Bangalore to New Delhi and generating abstractive summaries illustrate where explicit logging of tool calls and intermediate generations preserves explainability.

RunPod for cluster creation, Docker Hub for image distribution, FastAPI for inference endpoints, and the Saga pattern (orchestration vs choreography) for multi-step agent transactions illustrate deployment and architectural choices taught with in-class demos (approximately 24 demos across the course).