Explainable proposals: goal, steps with rationale, assumptions, risks, one alternative (optionally one you specify), validated and dry-run on the server. The scoresheet at the bottom records which explainability requirements this prototype addresses.
Assessed with the structure of the XAI scoresheet from A Scoresheet for Explainable AI (Winikoff, Thangarajah and Rodriguez, AAMAS 2025). This is a self-assessment: the development team's own assessment of this prototype, in the same sense as the worked examples in the paper. It has not been validated by external assessors and is not a certification of any kind. Related research: Contrastive explanations of BDI agents and the author's publications page.
The repository is public (linked in the Footer), so the proposal pipeline (prompting, parsing, validation, plan differences, dry run) can be inspected.
The prototype trains no model of its own: it sends requests to a hosted language model through an API, so there is no training data belonging to this system.
This is a team project developed for HEC Generative AI Cohort 3; the development team is reachable through the linked GitHub profile.
No automation-domain experts were consulted when building the prototype, and none are integrated into its explanation process.
Beliefs, rationales, assumptions, risks and the alternative are language model output with no link to any executed system, so they reflect no real decision-making process. Validation, plan differences and the dry run are computed directly from the proposal data and correspond exactly to that data.
Model-generated text and computed results are labelled separately on screen; structural validation rejects malformed proposals; the dry run is constructed to have zero side effects. No alignment testing against a real decision-making system has been performed.
The page and repository document the pipeline: a language model generates a structured proposal, the server parses and validates it, computes the plan differences and the dry run, and labels the source of every part.
Stated limitations and per-proposal risks are documented on screen and in every response. No accuracy, usability or trust evaluation of the prototype has been carried out, so no performance figures exist.
Every user asking the same question receives the same form of explanation; there is no adaptation to role, expertise or requested detail.
A user can steer one contrastive comparison by supplying a foil (asking why this instead of a named alternative), but explanations cannot be elaborated or drilled into step by step.
No confidence values are produced for model-generated content, and the prototype does not estimate uncertainty.
The stated limitations define the overall scope (structural checks only, dry run is not execution, model text unverified), and per-proposal assumptions and risks are listed, but no scope boundary is computed for a specific decision.
Extracted context and beliefs, each marked as taken from the user or assumed by the model.
Every proposal states the goal it pursues and the intended outcome.
Plan and alternative steps are typed as trigger, condition, action or review.
Trigger steps name the event a workflow listens for, but no live percept stream exists: the prototype never runs.
Explanations do not illustrate behaviour with worked examples.
No feature-based (for example data attribute) explanation is produced.
The prototype elicits no preference model and does not explain via preferences.
No value-based justification is part of the explanation format.
Workflow plans, per-step rationales and deterministic dry-run outcomes are the prototype's own explanatory concepts.
Nothing is ever executed, so there is no past behaviour to explain; the dry run is explicitly a preview, not a record.
Step rationales explain a proposal, not an execution, so no past why-question about real behaviour can be answered.
The computed difference shows which steps the alternative contains that the proposal lacks, but no causal why-not reasoning is derived.
A user-supplied foil makes the comparison answer why this plan instead of that one, with the structural differences computed deterministically (cf. the contrastive explanation paper).
The dry run states what each step would do, with zero external actions, computed from the step list.
Each step carries a rationale for why it belongs in the plan, and the proposal states the goal the plan pursues (model-generated, unverified).
Same limits as the factual form: differences are listed, causation is not derived.
The alternative plan plus the deterministic difference and trade-offs answer why this approach is preferred over the named other approach.
No counterfactual simulation is performed: changing conditions and re-running is not supported.
The prototype cannot derive the inputs needed to reach a different outcome.
The prototype cannot identify which changes would leave the outcome unchanged.
A question (a description plus an optional contrastive foil) automatically produces the proposal with all explanation sections when a model provider is configured; nothing has to be assembled by hand. When no provider is configured, the request fails honestly instead of answering.
33 assessment rows in total. The sheet covers this workflow proposal prototype; the four automation features perform no explanation generation and are therefore outside its scope.
Start building your automation by adding steps above