Pith. sign in

REVIEW 2 major objections 5 minor 2 cited by

Towards Explainable AI Planning as a Service

T0 review · 2 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Explainable Planning can be a service: a wrapper around an existing planner that compiles 'Why A rather than B?' into a hypothetical model, replans, validates, and returns the cost difference.

desk verdict A sincere, well-scoped prototype for explainable planning as a service, but the central example fails to demonstrate the main claim and the paper is best read as a roadmap with open problems. read the letter →

arxiv 1908.05059 v1 pith:LSA6SPWO submitted 2019-08-14 cs.AI

Michael Cashmore , Anna Collins , Benjamin Krarup , Senka Krivic , Daniele Magazzeni , David Smith This is my paper · ORCID
classification cs.AI
keywords explainableplanningcontrastiveexplanationasaservicePDDLhypotheticalmodelplanvalidationhuman-awareXAI
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that Explainable Planning should be a service rather than a new planning algorithm: a wrapper around the user's existing planner and domain model. When a user asks a contrastive question, typically 'Why did you do A rather than B?', the service compiles that question into a hypothetical planning problem (an HModel), invokes the original planner to solve it, validates the resulting HPlan against the original model, and returns a comparison of the two plans plus the cost difference. The authors implement a prototype for PDDL2.1 domains, demonstrate it on a warehouse robotics example, and show it supports several question types: forbidding an action, forcing an action, forcing a replacement, ordering constraints, and time-window constraints. They are explicit that the hard open problem is guaranteeing the forced action is causally essential to the alternative plan, not merely present in it.

What carries the argument

The HModel and its compilation carry the argument. The service translates the formal contrastive question into a set of constraints, compiles them into a modified PDDL2.1 domain, and generates a hypothetical plan using the original planner. For the replacement question, the compilation cuts the original plan at the state where A occurs, replaces A with B, computes the new initial state using the VAL validator's happenings, adds timed-initial literals to simulate actions still executing, and lets the planner solve from that state. The redundancy post-processing, based on Fink and Yang's categories and Chrpa, McCluskey, and Osborne's detection algorithm, is the only mechanism proposed to make forced actions essential, and the paper states that guaranteeing causal essentiality is an open question.

What would settle it

Run the service on the paper's warehouse example with the question 'Why didn't Tom pick up the pallet?' and inspect whether the returned HPlan contains the forced load action in the causal support of a goal. If the compilation alone produces a plan where the forced action is redundant, and the only remedy is hand-adding nogood constraints or refining the question, then the promise of answering contrastive questions as a service is falsified.

Watch

Extended reading notes

Core claim

The central claim is that answering contrastive questions in planning does not require a new explainable planner; it can be layered as a service around any planner that speaks PDDL2.1. The service takes as input the original domain and problem, the plan, and a formalized question; it creates a revised domain model (HModel) that encodes the user's constraint, solves it with the same planner, validates the hypothetical plan against the original model, and forms a contrastive explanation as a tuple of existing, removed, added actions and cost difference. The paper demonstrates this on a warehouse delivery domain, where asking 'why didn't Tom pick up the pallet?' compiles into an HModel that forces the load action, and the planner returns an alternative plan with a small cost penalty. The authors stress that the explanation is only trustworthy because it is produced by the user's own planner and validated against the original model. They also identify a key limitation: forcing an action into a plan is not the same as making it causally necessary for the goals, and the paper shows a generated HPlan where the forced load is immediately undone.

Load-bearing premise

The user's contrastive question can be faithfully compiled into planning constraints that make the suggested action causally essential to the alternative plan, not merely present in it; the paper's own example (Figure 7) shows a forced action being immediately reversed and states that guaranteeing essentiality is an open question.

Editorial extensions

If this is right

  • Users get explanations built from their own trusted planner and model, which matters in safety-critical settings such as oil-well drilling.
  • The service supports several contrastive question types: forbid, force, replace, order, and time-window constraints, plus an iterative tree of follow-up questions.
  • Because the framework is modular and PDDL2.1-based, it works with any conforming planner and can be integrated into robotics systems like ROSPlan.
  • The hypothetical plan is validated against the original model, so inconsistencies introduced by model revision are caught before the explanation is shown.
  • Forcing an action does not guarantee causal essentiality; the paper proposes redundancy detection plus nogood learning, but automating that refinement remains open.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The service view could be extended beyond PDDL: any planner that can accept constraint-compiled models could be wrapped, suggesting a standard protocol for 'explanation-by-replanning' across planning systems.
  • The redundancy problem might be attacked by compiling causal-support constraints directly, such as requiring that B supports a particular goal; the paper notes no current planning language expresses this cleanly.
  • The cost-difference metric in the explanation assumes plan cost is the right comparison axis; in safety-critical domains, risk or robustness differences might be more meaningful and could be added to the contrast tuple.
  • The iterative refinement tree suggests an automated explanation search driven by user feedback, turning a one-shot answer into a dialogue where the service proposes and the user critiques.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. The paper proposes Explainable AI Planning as a Service: a wrapper around an existing PDDL2.1 planner that answers contrastive questions by (1) taking the original planning problem, the current plan, and a user question, (2) compiling the question into a hypothetical model (HModel), (3) invoking the existing planner to produce a hypothetical plan (HPlan), (4) validating the HPlan against the original model, and (5) presenting a comparison between the original plan and the HPlan. The authors categorize several formal question types, describe a modular prototype implementation, and walk through a warehouse running example. They explicitly discuss limitations, including the fact that their main compilation does not guarantee that the user-suggested action is essential to the causal structure of the resulting plan, and they identify several open research directions.

Significance. The paper addresses a timely topic and its core idea—using the user's own trusted planner and model to generate contrastive explanations—is practically appealing, especially for safety-critical domains. The framework's modularity and the use of existing validation tools (VAL) are strengths, as is the candid acknowledgment of the causal-relevance problem. However, the central demonstration fails on the running example: the HPlan in Figure 7 includes the user-suggested action but immediately reverses it, so the explanation does not answer the user's actual counterfactual question. Because the paper is explicitly positioned as early-stage work and identifies this as an open problem, the contribution is best seen as a roadmap and prototype rather than a fully validated solution. The paper does not provide formal correctness guarantees, user studies, or a released implementation, but it clearly names these as future work.

major comments (2)
  1. [§3.2, Figure 7] The compilation for the paper's main question type (“Why is action A used in state S, rather than action B?”) produces an HPlan in which the user-suggested action B is immediately undone by (unload_pallet Tom p2 sh6). The paper itself notes that “This would not be a satisfactory explanation to the user” and states that guaranteeing the suggested action is essential to the causal structure is an open question. Since this is the paper's central mechanism and its only fully worked example, the claim that the service answers contrastive questions is not demonstrated. The authors should either provide a compilation that ensures causal relevance for at least this question type, or substantially reframe the contribution as an iterative framework in which the initial compilation is a heuristic and the absence of a causal-relevance guarantee is a core limitation rather than a peripheral one.
  2. [§3.2, HModel construction] The compilation step is described informally and its correctness is not specified. The paper does not define the semantics of “state S” in a temporal plan (e.g., which happenings are included, how simultaneous effects are handled), nor does it prove that the TIL times added in the new initial state are always well-defined and non-conflicting. Moreover, the HModel is introduced as a “revised domain model,” but in the example it is a modified initial state with TILs; the relationship between constraints compiled into the domain versus the problem instance is left unclear. Without a formal statement of what the compilation preserves (e.g., executability with respect to the original model, or a precise notion of “the user's intention”), it is difficult to assess whether the approach generalizes beyond the single example or to verify the validity claims made in Steps 4–5.
minor comments (5)
  1. [§3.2, TIL formula] In the definition of the timed-initial literals, the parenthetical in “where start (a j) (start (a j)) is the time at which the action a j (B) started execution” appears to be a typo; the second symbol should be start(B).
  2. [Figure 9] In the “removed” list, the action “9.001: (goto_waypoint Tom sh1 sh6)” does not appear in the original plan of Figure 4; the original plan at time 9.001 is (goto_waypoint Tom sh1 sh2). This discrepancy should be corrected.
  3. [Figure 7] The actions in Figure 7 are written with spaces (e.g., “load pallet Tom p2 sh6”), while the domain definition uses underscores (load_pallet). The figure should be made consistent with the PDDL syntax.
  4. [Abstract] The final sentence “we identify open questions for Explainable Planning as a service that identify several possible research directions” is redundant; consider rewording to “we identify open questions and several possible research directions.”
  5. [General] The paper does not state whether the prototype framework or the running-example files will be made available. A brief availability statement or link to a repository would improve reproducibility.

Circularity Check

0 steps flagged · score 1.0 of 10

No material circularity: the service architecture and compilations are independent of their inputs; the candid admission that causal relevance is not guaranteed is a correctness gap, not circularity.

full rationale

The paper proposes a service wrapper around an existing planner and demonstrates it with a prototype. Its derivation chain—formal question, constraints, HModel, replanning, validation, comparison—does not rely on fitting a parameter to the target result or on assuming the conclusion. The construction in Section 3.2 replaces action A with action B in the original plan prefix and replans from the resulting state; the HPlan is produced by an external planner and is not a restatement of the input. The paper explicitly concedes in Section 3.2 and Figure 7 that the forced action can be immediately reversed, that this 'would not be a satisfactory explanation,' and that ensuring the suggested action is essential to the causal structure 'is an open question as to whether it is possible to do this. We suspect not.' That is a candid limitation on the effectiveness of the central contribution, but it is not an input–output identity or a circular derivation. Self-citations such as Smith (2012) and Fox, Long, and Magazzeni (2017) motivate the iterative and contrastive framing, but they are not load-bearing theorems used to force the framework; the framework is implemented and checked with external tools (POPF, VAL). No prediction is a renamed fit, no uniqueness claim is imported from the authors' prior work, and no equation reduces to its own input. The score of 1 reflects only the presence of minor non-load-bearing self-citation, not circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 1 invented entities

The paper depends on several domain assumptions that it explicitly acknowledges: correctness of the model, faithful translation of user questions, and planner and VAL soundness. There are no fitted parameters. The HModel is an introduced construct with no formal semantics or independent evidence.

assumptions (3)
  • domain assumption The original planning model is correct and has no uncertainty.
    Section 5 lists this as a known limitation: "we are assuming that there is no uncertainty in the original planning model and that the model is correct."
  • domain assumption The formal question type selected by the user faithfully matches the natural-language question.
    Section 3 and Section 5 acknowledge that context matters and that automatic translation from natural language to formal questions is an open challenge; the current implementation requires the user to select a formal question directly.
  • domain assumption The planner and VAL correctly solve and validate PDDL2.1 problems.
    The framework relies on the existing planner producing valid plans and on VAL for validation; no formal correctness proof for the planner or validator is provided.
invented entities (1)
  • HModel (hypothetical model)
    purpose: A revised PDDL domain/problem that encodes constraints from the user's contrastive question; it is used to force the planner to produce an alternative plan (HPlan).
    The HModel is a proposed construct with example compilations only; no formal semantics or correctness proof is given, and the paper leaves the guarantee that constrained actions are non-redundant as an open question (Section 3.2).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Towards Explainable AI Planning as a Service." pith.science (2026). https://pith.science/paper/LSA6SPWO

@misc{pith2026190805059,
  author       = {Pith},
  title        = {Pith review of: Towards Explainable AI Planning as a Service},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LSA6SPWO}},
  note         = {Machine review of arXiv:1908.05059}
}
read the original abstract

Explainable AI is an important area of research within which Explainable Planning is an emerging topic. In this paper, we argue that Explainable Planning can be designed as a service -- that is, as a wrapper around an existing planning system that utilises the existing planner to assist in answering contrastive questions. We introduce a prototype framework to facilitate this, along with some examples of how a planner can be used to address certain types of contrastive questions. We discuss the main advantages and limitations of such an approach and we identify open questions for Explainable Planning as a service that identify several possible research directions.

Figures

Figures reproduced from arXiv: 1908.05059 by the authors.

Figure 1
Figure 1. Generating contrastive explanations for a question [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. A fragment of a robotics domain used as a running [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 5
Figure 5. Architecture for Explainable Planning as a service, [PITH_FULL_IMAGE:figures/full_fig_p003_5.png] view at source ↗
Figures from the paper (10 more)
Figure 3
Figure 3. Figure 3: A fragment of the problem instance used in the [PITH_FULL_IMAGE:figures/full_fig_p003_3.png]
Figure 4
Figure 4. Figure 4: Plan generated from the example domain and prob [PITH_FULL_IMAGE:figures/full_fig_p003_4.png]
Figure 6
Figure 6. Figure 6: Example of iterative explanations. which force action B to appear in the plan and not action A. This allows for a much wider range of explanations. Clearly the requirement of the plan being valid according to the orig￾inal model must be satisfied at each iteration. To …
Figure 7
Figure 7. Figure 7: HPlan generated with a cost of 23.504. The re￾placed action is highlighted. where start(aj) (start(aj)) is the time at which the action aj (B) started execution, duration(aj) is the planned dura￾tion of action aj , and e f f ect(aj) is the end effect of action aj . In …
Figure 8
Figure 8. Figure 8: HPlan generated with the second user constraint maintained, with a cost 21.505. The action suggested by the user is highlighted. 3.4 Forming Contrastive explanations A contrastive explanation draws from the original plan π, the HPlan πH and the validation outcome. Defi…
Figure 9
Figure 9. Figure 9: The contrastive explanation that is presented to the [PITH_FULL_IMAGE:figures/full_fig_p006_9.png]
Figure 10
Figure 10. Figure 10: Architecture of the framework for Explainable [PITH_FULL_IMAGE:figures/full_fig_p006_10.png]
Figure 11
Figure 11. Figure 11: Screenshots of the graphical user interface of the [PITH_FULL_IMAGE:figures/full_fig_p007_11.png]
Figure 12
Figure 12. Figure 12: Output of the GUI in which differences in the [PITH_FULL_IMAGE:figures/full_fig_p008_12.png]
Figure 13
Figure 13. Figure 13: Example of a causal graph which demonstrates a comparison of the original plan and HPlan. Added actions are red, [PITH_FULL_IMAGE:figures/full_fig_p008_13.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Counterfactual Explanations as Plans

    cs.AI 2025-02 conditional novelty 5.0 of 10

    A formal account in modal situation calculus that defines counterfactual explanations as minimally distant alternative plans which toggle a goal, including reconciliation through added knowledge or corrected beliefs.

  2. A Survey of Explainable Reinforcement Learning: Targets, Methods and Needs

    cs.AI 2025-07 conditional novelty 4.0 of 10

    A survey of 250+ explainable-reinforcement-learning papers proposes a What/How taxonomy and reports that sequence-level explanations are rare (11 works) compared with policy-level (175) and action-level (89) ones.

Reference graph

Works this paper leans on

28 extracted references · 26 canonical work pages · cited by 2 Pith papers

  1. [1]

    write newline

    " write newline "" before.all 'output.state := FUNCTION fin.entry add.period write newline FUNCTION new.block output.state before.all = 'skip after.block 'output.state := if FUNCTION new.sentence output.state after.block = 'skip output.state before.all = 'skip after.sentence 'output.state := if if FUNCTION not #0 #1 if FUNCTION and 'skip pop #0 if FUNCTIO...

  2. [2]

    A.; Bacchus, F.; and McIlraith, S

    Baier, J. A.; Bacchus, F.; and McIlraith, S. A. 2009. A heuristic search approach to planning with temporally extended preferences. Artif. Intell. 173(5-6):593--618

    work page 2009

  3. [3]

    Borgo, R.; Cashmore, M.; and Magazzeni, D. 2018. Towards providing explanations for AI planner decisions. IJCAI-18 Workshop on Explainable AI

    work page 2018

  4. [4]

    Cashmore, M.; Fox, M.; Long, D.; Magazzeni, D.; Ridder, B.; Carrera, A.; Palomeras, N.; Hurtos, N.; and Carreras, M. 2015. Rosplan: Planning in the robot operating system. In ICAPS

    work page 2015

  5. [5]

    Chakraborti, T.; Sreedharan, S.; Zhang, Y.; and Kambhampati, S. 2017. Plan explanations as model reconciliation: Moving beyond explanation as soliloquy. In IJCAI

    work page 2017

  6. [6]

    P.; Talamadupula, K.; Dholakia, M.; Srivastava, B.; Kephart, J

    Chakraborti, T.; Fadnis, K. P.; Talamadupula, K.; Dholakia, M.; Srivastava, B.; Kephart, J. O.; and Bellamy, R. K. E. 2018. Visualizations for an explainable planning agent. In IJCAI

    work page 2018

  7. [7]

    L.; and Osborne , H

    Chrpa , L.; Mccluskey , T. L.; and Osborne , H. 2012. Determining redundant actions in sequential plans. In ICTAI

    work page 2012

  8. [8]

    Coles, A.; Coles, A.; Fox, M.; and Long, D. 2010. Forward-chaining partial-order planning. In ICAPS

    work page 2010

Show all 28 references
  1. [9]

    Cyras, K.; Letsios, D.; Misener, R.; and Toni, F. 2019. Argumentation for explainable scheduling. In https://arxiv.org/abs/1811.05437

    2019 arXiv

  2. [10]

    Fink, E., and Yang, Q. 1992. Formalizing plan justifications. In Conference of the Canadian Society for Computational Studies of Intelligence , 9--14

    1992

  3. [11]

    Fox, M.; Long, D.; and Magazzeni, D. 2017. Explainable planning. IJCAI-17 workshop on Explainable AI abs/1709.10256

    2017 arXiv

  4. [12]

    Gerevini, A.; Saetti, A.; and Serina, I. 2006. An approach to temporal planning and scheduling in domains with predictable exogenous events. JAIR 25

    2006

  5. [13]

    Howey , R.; Long , D.; and Fox , M. 2004. Val: automatic plan validation, continuous effects and mixed initiative planning using pddl. In 16th IEEE International Conference on Tools with Artificial Intelligence , 294--301

    2004

  6. [14]

    Langley, P.; Meadows, B.; Sridharan, M.; and Choi, D. 2017. Explainable agency for intelligent autonomous systems. In AAAI

    2017

  7. [15]

    Lindner, F.; Mattm\" u ller, R.; and Nebel, B. 2018. Moral permissibility of action plans. ICAPS-18 Workshop on Explainable Planning

    2018

  8. [16]

    Long, D. 2018. Planning a way into a deep hole. In Invited talk at ICAPS Workshop on Planning and Scheduling Applications (SPARK)

    2018

  9. [17]

    Mennatallah, E.-A.; Duen Horng, C.; Adam, P.; Hendrik, S.; and Fernanda, V. 2018. Workshop on visualization for AI explainability. In http://visxai.io/

    2018

  10. [18]

    Miller, T. 2018. Contrastive explanation: A structural-model approach. arXiv preprint arXiv:1811.03163

    2018 arXiv

  11. [19]

    Miller, T. 2019. Explanation in artificial intelligence: Insights from the social sciences. Artificial Intelligence 267

    2019

  12. [20]

    Smith, D. 2012. Planning as an iterative process. In AAAI

    2012

  13. [21]

    A.; and McIlraith, S

    Sohrabi, S.; Baier, J. A.; and McIlraith, S. A. 2011. Preferred explanations: Theory and generation via planning. In AAAI

    2011

  14. [22]

    Sreedharan, S.; Chakraborti, T.; and Kambhampati, S. 2018. Handling model uncertainty and multiplicity in explanations via model reconciliation. In ICAPS

    2018

  15. [23]

    Sreedharan, S.; Srivastava, S.; and Kambhampati, S. 2018. Hierarchical expertise-level modeling for user specific contrastive explanations. In IJCAI

    2018

  16. [24]

    van Fraassen, C. B. 1980. The Scientific Image . Oxford University Press

    1980

  17. [25]

    XAI. 2017. IJCAI Workshop on Explainable AI . http://home.earthlink.net/dwaha/research/meetings/ijcai17-xai

    2017

  18. [26]

    XAI. 2018. IJCAI Workshop on Explainable AI . http://home.earthlink.net/dwaha/research/meetings/faim18-xai

    2018

  19. [27]

    XAIP. 2018. ICAPS Workshop on Explainable Planning . http://icaps18.icaps-conference.org/xaip

    2018

  20. [28]

    Zhang, Y.; Sreedharan, S.; Kulkarni, A.; Chakraborti, T.; Zhuo, H.; and Kambhampati, S. 2017. Plan explicability and predictability for robot task planning. In ICRA

    2017

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.