SAP RPT 1.5: Where Explainability Makes Responsible AI Real

[[{“value”:”

Note: This blog discusses explainability in SAP RPT 1.5, the enterprise Relational Pretrained Transformer for tabular and relational data, and the successor to SAP-RPT-1. The security foundations of the previous release are covered SAP-RPT-1: A Revolutionary Tabular ML Model and OWASP ML Top 10 Compliance. This post shows why explainability must be built into inference, and how RPT 1.5 returns an explanation with every prediction.

The Challenge: A Right Answer Isn’t Enough Without the “Why”

Trust in a model rests on a simple expectation: the reasoning behind its output should be open to inspection. It is not enough for a model to be right; there must be a way to establish why it was right, and to confirm it was not right for the wrong reasons.

That “why” is Explainability, and it is firmly rooted in SAP’s approach to Responsible and Ethical AI (see the SAP Global AI Ethics Policy and the SAP AI Ethics Handbook for more information).

Take a conventional classification or regression model, the kind trained on historical data and widely available in open-source libraries. Such a model returns a prediction and little else: it carries no indication of which inputs shaped that prediction or how much each one mattered. A strong accuracy score does not fill this gap. Accuracy measures only how often the model agrees with historical outcomes; it says nothing about which features the model actually relied on to get there. And when a model decides who is promoted, who receives a loan, or who is flagged for review, the features it relied on are the entire concern, precisely the thing these models leave unsaid.

(This is a deliberate contrast with SAP RPT 1.5, discussed later. RPT 1.5 uses in-context learning: it does not predict from patterns baked into training data, but from the input data provided with each request.)

A small, concrete example makes this easy to see.

When a Conventional Model Can’t Explain Itself

For this example, the model is a conventional open-source classification model, trained on historical data and returning only an answer with no explanation of how it was reached.

Consider a promotion dataset: nine labelled employees, four features (Name, Age, Gender, Performance_Rating), and a target column, Promotion (Yes/No). Please note that this example is only for demonstration purposes. Model predictions alone should never account for promotion decisions, and in case AI is to assist promotion decisions, the same should undergo AI Ethics Assessment and be implemented with appropriate safeguards. A conventional model is trained on these labelled records:

#	Name	Age	Gender	Performance_Rating	Promotion
1	Alice	34	F	3.2	No
2	Bruce	33	M	2.5	No
3	Catherine	35	F	4.0	Yes
4	Donald	32	M	3.9	Yes
5	Eva	33	F	1.5	No
6	Frank	36	M	1.0	No
7	Giselle	35	F	5.0	Yes
8	Henry	38	M	3.5	Yes
9	Ivanka	33	F	3.4	No

Once trained, the model is asked to predict the Promotion outcome for a new, unlabelled record, Zoey:

#	Name	Age	Gender	Performance_Rating	Promotion
10	Zoey	35	F	3.5	To Predict

This is a classification problem on structured, tabular data, not a task for a Large Language Model.

The conventional model predicts Yes with a confidence of 0.75. On the surface, nothing looks wrong: the performance rating is solid, the prediction is confident, and the decision would pass review without a second glance.

Now change a single value, and not one in Zoey’s input record. A different employee’s name is edited in the training data: Ivanka (Row 9) becomes Zelda. Zoey’s own record, including age, gender, and performance rating, is left untouched, and every other value across both tables is identical.

Change applied to training data	Predicted outcome for Zoey
Row 9 named Ivanka	Yes
Row 9 renamed to Zelda (name only, all else identical)	No

Zoey’s prediction flips from Yes to No, and the only thing that changed was someone else’s name in the training data. Nothing about Zoey moved; the age, gender, and performance rating that should determine the outcome are exactly as before.

This is not a rounding error. It means the model is deciding promotions partly on the basis of names, an attribute that has no bearing on the decision at all. Worse, the influence leaks across records: one person’s name reshapes the outcome for another. A model that behaves this way produces unreliable decisions no matter how strong its aggregate accuracy looks.

None of this is visible from the prediction alone. The accuracy metrics remain strong and the output appears sound; the dependence on names surfaces only when the model is required to explain how it reached its decision.

Why the Failure Stays Invisible

A conventional classification or regression model that returns only a verdict, such as {“Promotion”: “Yes”}, operates as a black box. The output offers no hint that a name tipped the outcome, so the flaw stays hidden until something external drags it into view, and by then the model is already in production, making decisions.

For explainability to be dependable, it has to travel with the prediction itself, produced alongside the result rather than reconstructed after the fact. Responsible AI cannot rest on a verdict that arrives without its reasoning.

SAP RPT 1.5 is built on this principle. The sections that follow examine how it returns an explanation with every prediction.

How SAP RPT 1.5 Enforces Explainability

SAP RPT 1.5, the Relational Prediction Transformer, is a foundation model for tabular and relational data. Given a table with specified cells to predict, it produces predictions in-context, without a per-dataset training run. The characteristic that matters for Responsible AI is architectural: explainability is a first-class field in the API.

RPT 1.5 can be deployed in SAP AI Core and used for inference. The underlying technology is detailed in the ConTextTab research paper published by SAP, with an open-source implementation available as ConTextTab on Hugging Face and GitHub. To try RPT for free and read the FAQs, see the SAP RPT page.

The Request: Asking for the Reasoning Up Front

A prediction is an authenticated REST call to the deployment. Alongside the specification of what to predict, the caller declares which explanation to return, within the prediction_config:

curl –request POST

–url $AI_API_URL/v2/inference/deployments/$DEPLOYMENT_ID/predict

–header ‘ai-resource-group: default’

–header ‘authorization: Bearer $AUTH_TOKEN’

–header ‘content-type: application/json’

–data ‘{

“prediction_config”: {

“target_columns”: [

{ “name”: “Promotion”, “prediction_placeholder”: “[PREDICT]”, “task_type”: “classification”, “top_k”: 1 }

“explanations”: {

“top_column_scores”: 4,

“top_relevant_context_rows”: 9

}

“rows”: [

{ “Name”: “Zoey”, “Age”: 35, “Gender”: “F”, “Performance_Rating”: 3.5, “Promotion”: “[PREDICT]” },

{ “Name”: “Alice”, “Age”: 34, “Gender”: “F”, “Performance_Rating”: 3.2, “Promotion”: “No” },

{ “Name”: “Bruce”, “Age”: 33, “Gender”: “M”, “Performance_Rating”: 2.5, “Promotion”: “No” },

{ “Name”: “Catherine”, “Age”: 35, “Gender”: “F”, “Performance_Rating”: 4.0, “Promotion”: “Yes” },

{ “Name”: “Donald”, “Age”: 32, “Gender”: “M”, “Performance_Rating”: 3.9, “Promotion”: “Yes” },

{ “Name”: “Eva”, “Age”: 33, “Gender”: “F”, “Performance_Rating”: 1.5, “Promotion”: “No” },

{ “Name”: “Frank”, “Age”: 36, “Gender”: “M”, “Performance_Rating”: 1.0, “Promotion”: “No” },

{ “Name”: “Giselle”, “Age”: 35, “Gender”: “F”, “Performance_Rating”: 5.0, “Promotion”: “Yes” },

{ “Name”: “Henry”, “Age”: 38, “Gender”: “M”, “Performance_Rating”: 3.5, “Promotion”: “Yes” },

{ “Name”: “Zelda”, “Age”: 33, “Gender”: “F”, “Performance_Rating”: 3.4, “Promotion”: “No” }

“data_schema”: {

“Name”: { “dtype”: “string” },

“Age”: { “dtype”: “numeric” },

“Gender”: { “dtype”: “string” },

“Performance_Rating”: { “dtype”: “numeric” },

“Promotion”: { “dtype”: “string” }

}

}’

The row to be scored has its target masked with the [PREDICT] placeholder, and the remaining rows serve as in-context evidence. Because the explanations field is part of the request, every call carries its own justification. Explainability is not a separate job run afterwards; it is produced together with the inference.

The Response: Every Prediction Explains Itself

The response contains the prediction together with the information required to interrogate it:

{
“explanations”: {
“top_column_scores”: [
{
“Age”: 0.165,
“Gender”: 0.188,
“Name”: 0.331,
“Performance_Rating”: 0.316
}
],
“top_relevant_context_rows”: [
[ 8, 7, 3, 4, 9, 1, 6, 5, 2 ]
]
},
“id”: “00df0b2c-b93f-4a56-9dc0-c21fd488bc0d”,
“metadata”: {
“num_columns”: 5, “num_predictions”: 1, “num_query_rows”: 1, “num_rows”: 10
},
“predictions”: [
{
“Promotion”: [
{
“confidence”: 0.83, “confidence_interval”: null, “prediction”: “Yes”
}
]
}
],
“status”: {
“code”: 0,
“message”: “ok”
}
}

Two elements are returned with the answer:

top_column_scores identifies which features drove the decision:

Feature	Influence
Name	0.331
Performance_Rating	0.316
Gender	0.188
Age	0.165

Name is the most influential feature in the model, ahead of actual job performance and well ahead of Gender and Age.

top_relevant_context_rows identifies which examples the model leaned on. The response names the specific rows (8, 7, 4, 3, and so on) that most shaped the outcome, so a reviewer can inspect the evidence behind a decision instead of taking it on trust.

The effect is straightforward but powerful: a prediction cannot leave RPT 1.5 without the material needed to examine it.

Acting on the Explanation: Removing Columns from the Features

An explanation is only useful if it can be acted upon. Because the column scores identify Name as the feature to remove, the fix is made in the same request contract that surfaced the problem. RPT 1.5 provides an index_column: a parameter used only to identify each row and returned in the response for reference, but never treated as an input feature. For more details on this and other request parameters, refer to the RPT documentation. Designating Name as the index_column takes it out of the model’s inputs entirely, without deleting it from the data:

“index_column”: “Name”,
“explanations”: {
“top_column_scores”: 4,
“top_relevant_context_rows”: 9
}

Re-running the identical request with this one change produces a response that confirms the fix:

{
“explanations”: {
“top_column_scores”: [
{
“Age”: 0.269,
“Gender”: 0.261,
“Performance_Rating”: 0.47
}
],
“top_relevant_context_rows”: [
[ 8, 7, 3, 4, 9, 1, 6, 5, 2 ]
]
},
“predictions”: [
{
“Name”: “Zoey”,
“Promotion”: [
{ “prediction”: “Yes”, “confidence”: 0.94, “confidence_interval”: null }
]
}
]
}

The result speaks for itself:

Feature	Influence (before)	Influence (after)
Name	0.331	— (excluded)
Performance_Rating	0.316	0.470
Gender	0.188	0.261
Age	0.165	0.269

Name has disappeared from the scores entirely, and Performance_Rating is now decisively the leading feature at 0.470. The prediction for Zoey holds at Yes, but its confidence rises from 0.83 to 0.94, and Name is echoed back under predictions purely as a row label, no longer as something the model weighed. The decision now rests on the attributes that should drive it, and the same explanation that exposed the flaw is what verifies the correction.

From Detection to Responsible Action

The value of the explanation lies in the actions it enables:

Identifying problematic features before deployment. A Name influence of 0.331, the model’s top feature, is a signal available on the first call, not after a complaint or an audit. As shown above, the fix is immediate: exclude Name through the index_column and re-run to confirm the model now decides on merit.
Auditing individual decisions. When an employee asks why a decision was made, a per-prediction, per-feature explanation already exists to support the response.
Establishing trust with the business. Stakeholders can approve what they can understand. A prediction accompanied by its reasoning is one that a decision-maker can stand behind.
Governing at scale. Because the explanation is structured data returned with every call, feature-importance drift can be monitored across all predictions and flagged when a model begins relying on a feature it should not.

Conclusion: Explainability by Design, Not by Afterthought

The promotion example is deliberately small, but the lesson scales without limit: a model can be accurate and still be unsafe, and accuracy alone will never tell you which one you have. Only explainability can. That is why explainability is not a feature bolted onto Responsible AI; it is the mechanism that makes Responsible AI verifiable in the first place.

Where explanation is treated as an optional, after-the-fact analysis, it is the first thing to be skipped. SAP RPT 1.5 takes the opposite approach and makes explanation a property of the prediction itself: requested in the contract, returned with the result, and impossible to quietly leave out. When renaming Ivanka to Zelda changes Zoey’s outcome, RPT 1.5 does not hide the cause; it surfaces it in the same response, as a feature-importance value that can be acted upon.

A model that explains itself is not merely more transparent. It is the only kind of model that can be deployed with confidence.

References:

– https://help.sap.com/docs/sap-ai-core/generative-ai/sap-rpt-1-5

– https://help.sap.com/docs/sap-ai-core/generative-ai/example-payloads-for-inferencing-sap-rpt-1#parameters

– SAP Global AI Ethics Policy

– SAP AI Ethics Handbook

– Trustworthy AI: How to make artificial intelligence understandable

– https://www.sap.com/india/products/artificial-intelligence/sap-rpt.html

– SAP-RPT-1: A Revolutionary Tabular ML Model and OWASP ML Top 10 Compliance

– ConTextTab research paper

– https://huggingface.co/SAP/contexttab

– https://github.com/SAP-samples/contexttab/tree/main

“}]]

[[{“value”:”Note: This blog discusses explainability in SAP RPT 1.5, the enterprise Relational Pretrained Transformer for tabular and relational data, and the successor to SAP-RPT-1. The security foundations of the previous release are covered SAP-RPT-1: A Revolutionary Tabular ML Model and OWASP ML Top 10 Compliance. This post shows why explainability must be built into inference, and how RPT 1.5 returns an explanation with every prediction.The Challenge: A Right Answer Isn’t Enough Without the “Why”Trust in a model rests on a simple expectation: the reasoning behind its output should be open to inspection. It is not enough for a model to be right; there must be a way to establish why it was right, and to confirm it was not right for the wrong reasons.That “why” is Explainability, and it is firmly rooted in SAP’s approach to Responsible and Ethical AI (see the SAP Global AI Ethics Policy and the SAP AI Ethics Handbook for more information).Take a conventional classification or regression model, the kind trained on historical data and widely available in open-source libraries. Such a model returns a prediction and little else: it carries no indication of which inputs shaped that prediction or how much each one mattered. A strong accuracy score does not fill this gap. Accuracy measures only how often the model agrees with historical outcomes; it says nothing about which features the model actually relied on to get there. And when a model decides who is promoted, who receives a loan, or who is flagged for review, the features it relied on are the entire concern, precisely the thing these models leave unsaid.(This is a deliberate contrast with SAP RPT 1.5, discussed later. RPT 1.5 uses in-context learning: it does not predict from patterns baked into training data, but from the input data provided with each request.)A small, concrete example makes this easy to see.When a Conventional Model Can’t Explain ItselfFor this example, the model is a conventional open-source classification model, trained on historical data and returning only an answer with no explanation of how it was reached.Consider a promotion dataset: nine labelled employees, four features (Name, Age, Gender, Performance_Rating), and a target column, Promotion (Yes/No). Please note that this example is only for demonstration purposes. Model predictions alone should never account for promotion decisions, and in case AI is to assist promotion decisions, the same should undergo AI Ethics Assessment and be implemented with appropriate safeguards. A conventional model is trained on these labelled records:#NameAgeGenderPerformance_RatingPromotion1Alice34F3.2No2Bruce33M2.5No3Catherine35F4.0Yes4Donald32M3.9Yes5Eva33F1.5No6Frank36M1.0No7Giselle35F5.0Yes8Henry38M3.5Yes9Ivanka33F3.4NoOnce trained, the model is asked to predict the Promotion outcome for a new, unlabelled record, Zoey:#NameAgeGenderPerformance_RatingPromotion10Zoey35F3.5To PredictThis is a classification problem on structured, tabular data, not a task for a Large Language Model.The conventional model predicts Yes with a confidence of 0.75. On the surface, nothing looks wrong: the performance rating is solid, the prediction is confident, and the decision would pass review without a second glance.Now change a single value, and not one in Zoey’s input record. A different employee’s name is edited in the training data: Ivanka (Row 9) becomes Zelda. Zoey’s own record, including age, gender, and performance rating, is left untouched, and every other value across both tables is identical.Change applied to training dataPredicted outcome for ZoeyRow 9 named IvankaYesRow 9 renamed to Zelda (name only, all else identical)NoZoey’s prediction flips from Yes to No, and the only thing that changed was someone else’s name in the training data. Nothing about Zoey moved; the age, gender, and performance rating that should determine the outcome are exactly as before.This is not a rounding error. It means the model is deciding promotions partly on the basis of names, an attribute that has no bearing on the decision at all. Worse, the influence leaks across records: one person’s name reshapes the outcome for another. A model that behaves this way produces unreliable decisions no matter how strong its aggregate accuracy looks.None of this is visible from the prediction alone. The accuracy metrics remain strong and the output appears sound; the dependence on names surfaces only when the model is required to explain how it reached its decision.Why the Failure Stays InvisibleA conventional classification or regression model that returns only a verdict, such as {“Promotion”: “Yes”}, operates as a black box. The output offers no hint that a name tipped the outcome, so the flaw stays hidden until something external drags it into view, and by then the model is already in production, making decisions.For explainability to be dependable, it has to travel with the prediction itself, produced alongside the result rather than reconstructed after the fact. Responsible AI cannot rest on a verdict that arrives without its reasoning.SAP RPT 1.5 is built on this principle. The sections that follow examine how it returns an explanation with every prediction.How SAP RPT 1.5 Enforces ExplainabilitySAP RPT 1.5, the Relational Prediction Transformer, is a foundation model for tabular and relational data. Given a table with specified cells to predict, it produces predictions in-context, without a per-dataset training run. The characteristic that matters for Responsible AI is architectural: explainability is a first-class field in the API.RPT 1.5 can be deployed in SAP AI Core and used for inference. The underlying technology is detailed in the ConTextTab research paper published by SAP, with an open-source implementation available as ConTextTab on Hugging Face and GitHub. To try RPT for free and read the FAQs, see the SAP RPT page.The Request: Asking for the Reasoning Up FrontA prediction is an authenticated REST call to the deployment. Alongside the specification of what to predict, the caller declares which explanation to return, within the prediction_config:curl –request POST